Архив за 2008

Mourner передал мне эстафету: 5 советов IT-специалисту — советы по управлению проектами…
Давать советы кому-то абстрактному не хочется: ведь подойдут они не всем, потому в этой заметке будут советы, которые я нынешний дал бы самому себе четырехлетней давности.

1. Управление проектами — это работа с людьми. Умение завоевать уважение команды и клиентов в тыщу раз важнее умения рисовать диаграммы Ганта. Ни в коем случае не поддавайся рассказам всяких менеджеров-теоретиков, считающих PMBOK важнейшей книгой для управленца: эти клоуны могут долго рассуждать о преимуществах и недостатках методологий RUP, CRYSTAL или XP, но понятия не имеют, что делать, если разработчик длительное время работал с нормальной эффективностью, а потом резко «опустился», они не чувствуют, когда стоит делегировать полномочия, а когда этого делать нельзя.
2. Постоянно учись, читай, постоянно экспериментируй, постоянно сомневайся в себе, совершай ошибки и исправляй их последствия. Ошибок не допускает только тот, кто топчется на месте. Да, постоянные изменения и нескончаемое обучение означают постоянный стресс — и с этим ничего не удастся поделать, но со временем начинаешь спокойнее относиться к собственным ошибкам и неудачам, легче переносить стресс.
3. Бери на работу только тех людей, которые эту работу обожают: тех, кто с гордостью рассказывают о своих заслугах, интересуются твоей компанией, следят за новинками в отрасли. Если этого не соблюдать — легко получишь обыкновенный ленивый офисный планктон, который работает «из-под палки», самостоятельно не обучается и довольно медленно растет в профессиональном плане. Людей, которые в целом любят свою работу, и мотивировать гораздо проще, и работать с ними интереснее. Тебе не нужен сисадмин, мечтающий заниматься журналистикой, или разработчик, который на самом деле хочет быть дизайнером, а код писать ненавидит и каждый раз «переступает через себя», чтобы выполнить новую задачу. Тебе нужны такие люди, которых сам будешь выгонять из офиса, чтобы не просидели до ночи, изучая новую технологию. На эту тему немало эссе написал Джоэль Спольски.
4. Учись отступать и проигрывать. Очень важно уметь вовремя остановить провальный проект. Иногда необходимо отказаться от проекта, иногда — даже уволиться. Запятнанную репутацию нелегко «отбелить». Как ни крути, а у жизни тоже есть свой дедлайн, потому не инвестируй временной ресурс своей жизни в мертворожденные проекты, эти инвестиции не окупятся.
5. Хочешь выстроить четкую систему в работе, наладить процессы, чтобы все было четко и без сюрпризов? Начни с себя: без жесткого контроля собственного времени никак не обойтись. GTD — не только модный акроним, но и реально полезная методология, которая при грамотном обращении поможет убивать в себе оптимизм и не забывать ничего важного. Учись мгновенно принимать правильные решения, много решений… Если не выходит — устанавливай дедлайн принятия решения: и руководство/клиенты, и подчиненные будут тебе за это благодарны.

Интересно, как я буду смотреть на эти советы через 5 лет?

Встречаются как-то два психолога. Первый начинает разговор за жизнь:
— Я себе недавно купил навороченный Феррари…
А второй сначала косо смотрит на первого, а потом и говорит:
— Слушай, мы же все-таки профессионалы. Давай просто расстегнем брюки и померяемся!

Есть у меня приятель, занимающийся мелкооптовой торговлей бельем — типичный представитель мелкого бизнеса. Его компании потребовался сайт в интернете, и приятель попросил меня подсказать, где лучше его заказать, а также спросил об ориентировочных ценах. Когда я назвал приблизительную стоимость разработки несложного сайта-визитки в надежных Киевских веб-студиях, приятель в ужасе схватился за голову: он не мог представить, что это может стоить так дорого! Когда приятель узнал, что все это можно сделать и дешевле, но либо в «шарашках», либо у фрилансеров, где нет никаких гарантий — совсем расстроился…

Знаете, это реальная проблема на территориях пост-совка: к сайту компании у нас принято относиться не как к инструменту зарабатывания денег, но как к красивым картинкам и просто фактору престижа. Такой сайт приятно показать друзьям, коллегам, клиентам, жене, в конце концов… но стоит ли он вложенных средств? Да, сайты в экс-СССР стоят очень дорого, как для стран 3-го мира: совершенно реальна ситуация, когда компании, торгующие, например, сантехникой, платят за разработку сайта в Киеве или Москве дороже, чем их коллеги в Нью Йорке или Сан Франциско. Уверен, вы сразу подумали о Студии Лебедева, но на самом деле я имею в виду не только ее, а множество компаний. Кроме того, за рубежом САЛ знают, в основном, как компанию, занимающуюся промышленным дизайном, а не сайтами… Ну, не привыкли там платить за дизайн больше, чем он может принести. Как вы думаете, многие ли компании в России и Украине думают о том, какой ROI будет у их сайта: как быстро сайт окупится и окупится ли вообще?

При таких высоких ценах сайты ухитряются делать с отвратительного качества CMS‘ками, подчас слабее бесплатных Joomla и Drupal, а часто выбирают и просто отвратительный Bitrix…

В интернете можно найти минимальные цены ведущих веб-студий России за 2006 год, как вы понимаете, сейчас эти цены повысились.
А что делать? Ведь нужно платить дизайнерам, которые сделают эксклюзивный дизайн (возможно, и несколько макетов на выбор)… Скорее всего, макет еще придется дорабатывать — и утверждение макета может растянуться надолго… И все это время нужно платить менеджерам, потом верстальщикам надо сверстать макет, еще позже макет нужно будет прицепить к CMS’ке, вполне возможно, что эту самую CMS’ку придется под конкретный сайт доделывать. В общем, не с потолка цены берутся…

Но задумывались ли вы когда-нибудь, что будет, если отказаться от эксклюзивности — если не придется разрабатывать новые макеты дизайна, не придется вносить в них правки и не придется утверждать дизайн, не придется верстать его и не придется подключать сверстанный дизайн к CMS, не придется доделывать эту самую CMS?

Что будет, если подстроить свое видение веб-сайта под уже сложившиеся стандарты? Чем же плохо использование чужого дизайна или просто шаблонного, проданного десятку разных клиентов? А ничем, по большому счету, это не плохо, кроме того, что вы лишитесь понт-фактора. Но подумайте хорошенько, важен ли он для бизнеса?

Представьте себе ситуацию: жители соседних деревень Виларибо и Вилабаджо открыли магазины авто-запчастей — с одинаковым ассортиментом, ценами и уровнем обслуживания. Вскоре оказалось: через интернет можно привлечь много новых клиентов. Деревня Виларибо обратилась в солидную студию веб-дизайна, где им за 100 наноюнитов в два месяца сделали сайт под ключ с эксклюзивным дизайном. По прикидкам жителей Виларибо, затраты на сайт должны окупиться через 12 месяцев. Жители деревни Вилабаджо быстро отреагировали: они пришли в студию поскромнее и заявили: «Пожалуйста, возьмите сайт магазина «Виларибо», измените название на «Вилабаджо», поставьте наш контент и все настройте». Через месяц всего за 25 наноюнитов владельцы авто-магазина «Вилабаджо» получили свой сайт — такой же, как у «Виларибо»…
Прошло полгода… В деревне Вилабаджо праздник — ведь их веб-сайт уже окупился и теперь стабильно приносит прибыль… А жители деревни Виларибо все еще «в минусе».

Конечно, такой подход подойдет далеко не всем: дорогие бутики, студии дизайна, многие банки и страховые компании — у них у всех бизнес зависит от понтов (или престижа, кому как больше нравится), потому им необходим эксклюзив, точно так же и для промо-сайтов нужен эксклюзив, но я имею в виду «сайты-визитки». Но ведь большинству представителей мелкого и среднего бизнеса разработка эксклюзивного сайта в надежной веб-студии просто «не по зубам».

Некоторым кажется, будто шаблонный дизайн хуже эксклюзивного — это фикция: качество и эксклюзивность дизайна никак между собой не связаны. Например, на сайтах большинства софтверных компаний дизайн откровенно убогий, но он эксклюзивен! Более того, в серийных продуктах гораздо проще поддерживать качество на высоком уровне, чем в штучных: отличным примером этого служит McDonalds. В Макдональдс используют шаблонный конвейерный метод, в большинстве ресторанов — эксклюзивный. При этом еда в Макдональдс приготовлена качественнее, чем в большинстве ресторанов. Серьезно! — Она не изыскана, она не красива, она вредна для здоровья, но приготовлена качественно — в точнейшем соответствии с рецептурой, одинаково качественно для каждого посетителя, потому что за ней стоит настолько отточенная система, какую ни один ресторан не сможет обеспечить. McDonalds и прочие фастфуды не уничтожили ресторанный бизнес, но четко заняли свою нишу: в дешевых фастфудах питается гораздо больше людей, чем в дорогих ресторанах. Точно так же постепенно произойдет и с разработкой веб-сайтов: эксклюзив останется только для тех, кому это нужно и кто способен за это платить. Делать все сайты-визитки эксклюзивными — не естественнее, чем увидеть всех женщин на улицах в одежде от кутюр.

Конечно, дизайнеры не захотят со мной согласиться — ведь их основная работа состоит в том, чтобы производить эксклюзивный дизайн… Трудно признаться себе, что ты делаешь нечто переоцененное и ненужное… Мне кажется, сейчас отрасль находится на своем пике и года через 2-3 начнет двигаться в сторону упрощения и удешевления. В первую очередь, от этого пострадают дизайнеры, которых просто окажется слишком много — конкуренция на рынке повысится, а зарплаты, соответственно, снизятся.

Но это неизбежно в условиях, когда спрос рождает предложение. Подобные ситуации уже встречались в истории: к примеру, автомобили до Генри Форда тоже были дорогими и не-массовыми, но все мы знаем, что случилось потом…

Продолжаем ежемесячный обзор потоков прошедших через мою RSS-ленту.

Успешно прошли

• LiveDev — интересный и приятный русскоязычный блог о веб-разработке, в том числе на Django. Побольше бы таких сайтов в рунете!
• Психологический журнал «Искусство быть собой» — за последние год-два я еще не встречал настолько качественного сайта о саморазвитии и «популярной» психологии. В отличии от большинства подобных сайтов радует авторский контент и отсутствие «тупых понтов» у автора. Надеюсь, Олег Сатов, автор сайта, и дальше будет продолжать в том же духе.
• Антикорпоратив.ру — сайт о бизнесе, корпоративной среде (вернее, о ее вреде), «лайфхаках». Наиболее полезен работникам больших бездушных компаний.
• Управление проектами в картинках — интересный менеджерский блог, о нем я уже писал в прошый раз.
• 4 конверта — блог о финансовом самоконтроле. Все сказано в названии. Интересный проект Макса Крайнова, недавно отделившийся от его основного сайта.
• ContraMarketing — толковый блог с наблюдениями бывшего маркетолога. Искренний и циничный.

Не прошли карантин

• SitePoint — крупное сообщество посвященное веб-разработке, управлениию небольшими интернет-проектами, маркетинге и дизайне в интернете. К сожалению, окончательно скурвился: минимум практических материалов.
• LUK!Around — блог о путешествиях. Испортился: вместо блога о путешествиях превратился в блог о Берлине, где в каждом новом посте содержится совсем немного информации — складывается впечатление, что автору не о чем писать, потому он так поступает. Странно, что совпало это с активной рекламой у Давыдова. Надеюсь, в будущем сайт снова наберет обороты.

Временно в карантине

• Иван Пирог в режиме онлайн — недавно открывшийся блог Ивана, организатора семинаров Exception. Он обещает писать статьи на темы самосовершенствования и самомотивации, IT-бизнеса. Пока что на сайте всего 3 статьи, но довольно познавательные. Уверен, сайт и дальше будет радовать качественным авторским контентом.
• Agile-сообщество Беларуси — с одной стороны интересный сайт про agile-методологии. С другой — пока не могу понять, стоят ли его статьи затрачиваемого на чтение времени.
• AGOGE — сообщество сильных. Блог с дурацким названием о личностном развитии современного человека. Пока не понятно, насколько он самобытен, время покажет.
• David Cramer — интересный и полезный с практической точки зрения блог python-разработчика. Много информации о фреймворке Django и шаблонизаторе Jinja.
• Mac OS от Винтика и Шпунтика — простой и забавный сайт о MacOS и софте для нее.
• Пепелсбей.net — сайт о верстке с приятным дизайном. Негатива не вызывает, но статей на сайте пока слишком мало чтобы сформировать окончательное мнение.
• Подлипенский Павел — Блог о технологиях и деньгах. В название все сказано. Молодой и интересный сайт об IT-бизнесе. Рекомендую!
• MediaRevolutiuon — добротный русский сайт о маркетинге в средствах интернет-медиа. Радует обилие статистики вроде «Мужчины в возрасте 18-34 лет — наиболее активные зрители видеоконтента в Сети, 74% опрошенных заявили, что смотрят онлайновое видео по меньшей мере раз в неделю. Треть опрошенных мужчин в возрасте 18-24 лет смотрят онлайновое видео каждый день.».

В предыдущей статье, «Неправильный Scrum» я рассказал о примере низкой эффективности и хаосе, вызванных неправильным применением agile-методологий. Не секрет, что все они предназначены, в первую очередь, для небольших локальных команд. Но как же действовать командам немаленьким при распределенной разработке — в целом и при аутсорсинге — в частности?

Напомню, основными проблемами у нас были: низкое качество взаимодействия людей в распределенных командах, множество времени, тратящегося на коммуникацию, излишняя бюрократизированность отчетности из-за менеджмента в стиле «прикрой жопу, потом работай», слишком короткие итерации и слабая связь цикла разработки с циклом тестирования.

Существуют различные способы масштабирования гибких методологий — я расскажу о тех, которые применили мы, уже наученные горьким опытом Лжескрама.

1. Пожалуй, самое главное, что удалось сделать — разделить один большой проект на целый пакет мелких и средних проектов, таким образом, каждая рабочая группа, состоящая из 2-5 человек, стала заниматься одним и только одним проектом.
2. Вместе с разделением крупного проекта на мелкие изменилась и стратегия коммуникаций. Теперь команды разработки и их тимлиды регулярно взаимодействовали лишь с техническими руководителями в США, решая тактические вопросы и согласовывая API, а с локальными руководителями проектов вывяли текущие проблемы. В свою очередь, руководители проектов общались между собой и с высшим руководством сугубо о вопросах стратегии, рисков, интеграции проектов и изменения состава групп, а технические руководители между собой решали сложные архитектурные вопросы, утверждали API и следили за документированием технических решений. Отойдя от формальностей, можно сказать — главной задачей руководителей проектов и технических руководителей стало устранение преград на пути своих команд и интеграция проектов, но никак не отчетность.
3. Часть команд стали проводить регулярные стоячие совещания, что было простым и дешевым способом для участников проекта «находиться на одной волне» и выявлять реальные и потенциальные проблемы своевременно. Без разделения «1 проект — 1 команда» это было бы невозможно.
4. Длину итераций увеличили с одной до двух недель и стали планировать их так, чтобы в конце всегда оставался запас в пару дней. Это частично позволило избавиться от постоянной гонки, в которой все чувствуют себя проигравшими — когда работаешь в нормальном ритме, то и ошибок допускаешь меньше.
5. Оценки сроков и планы перестали «спускаться сверху»: теперь оценки сроков задач проводилась их непосредственными исполнителями под присмотром тимлидов, после чего согласовывалась с руководителем проекта и техническим руководителем, которые, как правило, срок увеличивали, учитывая дополнительные риски и сложности.
6. Стали использовать средства Continuous Integration. Полноценного TDD у нас все равно не получилось, но удалось заставить разработчиков тестировать свой код и более-менее стабилизировать качество билдов продукта.
7. Ввели т.н. «development blogs», куда разработчики (реально — тимлиды) должны были каждый день записывать свои достижения и проблемы, с которыми они столкнулись. Эти блоги на некоторое время стали главным средством коммуникации удаленных команд (ведь они находились в разных офисах), кроме того, это заставляло разработчиков писать! Впрочем, когда объем взаимодействия между разными командами уменьшился, от блогов мы отказались для большинства проектов.
8. Постепенно мы разработали различные автоматические средства отчетности и оценки сроков (используя идеи evidence based scheduling Джоэля Спольски), реализовав их как Jira plug-ins. Но постепенно отказались и от ежедневной формальной отчетности. Вести ее можно было разве что по собственному желанию, чтобы лучше ощущать «пульс проекта». Руководитель проекта теперь отвечал строго за успешное окончание каждой итерации, а не за успешное бумагомарание.
9. Стали проводить ретроспективы (к сожалению, они проводились между руководством разных проектов без участия разработчиков) в конце итераций. Это не произвело чуда, но помогло увидеть проблемы с разных точек зрения и, конечно же, не наступать на одни и те же грабли дважды.
10. Ввели еженедельную оценку оффшорных команд людьми из главного офиса в США, где каждый мог по пятибалльной шкале оценить уровень коммуникации, качества кода и адекватного восприятия документации. Локальные руководители проектов получали информацию и видели, кто какую оценку поставил. Многим поначалу казалось, что это сделано с целью найти козлов отпущения и показать «вот мы тут белые-пушистые, а они там за океаном бездельники и мудаки». На самом же деле, все эти оценки позволяли увидеть, кто конкретно не доволен взаимодействием, после чего не гадать — а связаться с этим человеком и узнать, чем именно он не доволен и совместно с ним улучшить рабочий процесс. Медленно, но уверенно все это получилось. Как всегда в распределенной разработке, главная трудность — коммуникация, а самый трудно контролируемый фактор — фактор человеческий.

Выводы

Пусть agile-процесс изначально и рассчитан под небольшие проекты и локальные команды — его вполне можно масштабировать. Главное для этого — открытость и смелость проектных команд и, в первую очередь, руководства.
Откажитесь от ложных целей вроде бюрократичной отчетности и стратегии прикрытия задницы, сконцентрируйтесь на получении необходимого вам продукта. Экспериментируйте с длительностью итераций, составом команд, способами взаимодействия и тестирования… Да, вы будете совершать ошибки, но суть гибкого адаптивного процесса в том, чтобы признавать свои ошибки, учиться на них и постоянно улучшать процесс, а не пытаясь скрыть ошибки и искать козлов отпущения. Технологии и процессы несовершенны, люди несовершенны, мир несовершенен… но это не означает, что не мы не должны учиться и улучшать качество своей работы.

А вы масштабировали agile-процесс? Если да, то как?

«То, что в первом приближении может очень походить на agile на самом деле может быть просто хаосом и способом траты денег, не имеющих четких целей и демотивирующих проектную команду.».

Алексей Кривицкий, тренер SCRUMguides

Гибкие (agile) методологии разработки ПО в последние годы активно набирают популярность. Они позволяют снизить риски проекта, уменьшить объем «бумажной волокиты» и попросту удешевить разработку.
Однако облегченность (например, в сравнении с «моделью водопада») этих методологий вовсе не означает, что их можно применять не разобравшись до конца в самой сути agile-процесса.

Данная история — пример хаоса, возникающего при неправильном обращении с agile-методологиями.
В прошлом году я участвовал в нескольких проектах, которые формально делались по методологии Scrum. Проекты были аутсорсинговыми, наш клиент продавал их своему клиенту как Scrum, соответственно, контракта с фиксированной оплатой не было, оплата шла повременная. Схема разработки была итерационной, каждая итерация включала в себя демо-версию продуктов и сессию планирования следующей итерации. Приоритеты требований менялись в зависимости от результатов демо. Так что же было не так?

1. Начнем с того, что проекты были крупными и распределенными. Над одним проектом могло работать 35-45 человек, находящихся в разных офисах в разных городах в разных часовых поясах. Согласитесь, серьезное осложнение для процесса, где по канонам все должны работать в одном офисе (в идеале — в одной комнате), ведь живое общение — одна из основ agile-процесса: именно живое общение снижает уровень бумажной бюрократии.
2. В первую очередь, наши клиенты восприняли Scrum с его ежедневными «стоячими совещаниями» как отличный способ получения отчетности (одна из величайших проблем крупного бизнеса в том, что отчитаться о проделанной работе часто важнее, чем эту самую работу качественно выполнить). Выглядело это так: каждый день для общения по телефону собирались руководители разработки из разных офисов и докладывали американскому руководству о состоянии текущих задач и дальнейших планах, после чего координировали работу со своими командами. Но у этих руководителей было по несколько групп разработчиков, а это в сумме — 20-25 человек на каждого… Реалистично отчитаться о задачах каждого из них — задача нетривиальная, потому к совещаниям вскоре подключили и руководителей команд. Даже для тимлидов не всегда было по силам досконально описать ситуацию в текущих задачах и способы ее решения, потому к совещаниям время от времени стали подключать и ключевых разработчиков. В итоге, большинство ключевых сотрудников стало отвлекаться на час-полтора каждый день, чтобы посовещаться. Это называлось «daily scrum» (который по правилам длиться должен не более 15 минут) и не могло не вредить общей продуктивности.
3. Вскоре клиенты признали — такой подход не годится. Ведь больше всего о конкретных задачах проекта знают сами разработчики — значит они и должны отчитываться о своей работе, как это написано в книгах по Scrum’у. Но в команде проекта 30-40 разработчиков, притом, работающих в разных офисах, выслушать их всех и не потерять нить обсуждения крайне трудно. Выход был найден: вместо телефонных разговоров стали использовать групповой чат, логи которого всегда можно было перечитать. Но теперь уже не только ключевые сотрудники, но и вся проектная команда тратила ежедневно 1-2 часа на отчетность.
4. Отчетность эволюционировала: когда стало понятно, что 1-2 из 8 рабочих часов ежедневно — это неприличная роскошь, схему пришлось изменить. Теперь разработчикам просто задавали подряд 3 классических для Scrum вопроса: «Что сделали за прошедший день?», «Что делаете теперь?», «Есть ли у вас препятствия на пути?», а разработчики должны были синхронно ответить на эти вопросы в чате. Больше никаких индивидуальных обсуждений… Позже американское руководство анализировало логи этих чатов… Зато все успевали «выговориться» за 15 минут. Было понятно, что подобные «daily scrum’ы» — чистый формализм, к счастью, разработчики воспринимали этот идиотизм с юмором.
5. Впрочем, отчеты разработчиков вовсе не освобождали локальных руководителей разработки от собственных отчетов (еще более формальных) и за каждую итерацию, и за каждый день в отдельности. Я до сих пор не могу понять, где наши американские коллеги находили время для чтения всех отчетов.
6. Все без исключений agile-методологии итеративны. В конце итерации (в Scrum они называются спринтами) мы получаем билд продукта, готовый к демонстрации. Создатели методологии XP предпочитают короткие итерации в 1-2 недели, Scrum — длинные в 1-2 месяца. Наш клиент решил сделать итерации максимально короткими — 1 неделя, то есть 5 рабочих дней. А иногда у нас бывали и микро-итерации — 2-3 дня… Клиент надеялся таким образом иметь больший контроль над процессом: ведь 1 неделя работы в неправильном направлении не так губительна, как две или даже четыре недели. Кроме того, если итерации недельные — значит и отчеты о результатах итерации можно получать каждую неделю. На практике же недельные итерации приводили к спешке: разработчики торопились, чтобы успеть закончить хоть что-то значимое в столь короткие сроки (впрочем, это скорее ошибка менеджмента), из-за чего уделяли минимум времени тестированию собственного кода. Осложняло ситуацию еще и то, что из 5 дней спринта реально на разработку оставалось всего 4, так как день уходил на «разворачивание» продукта, подготовку демо-версии и.т.п.. Каждый новый билд кишел глюками и мелкими недоработками.
7. Роль тестировщиков в agile-процессе до сих пор слабо освещена. Клиента это нисколько не смущало, потому тестировщики у нас не были интегрированы в процесс разработки, а разработчики — в процесс тестирования. Если демо у нас в проектах проводилось каждый понедельник, то тестировщики (находящиеся не в тех же офисах, где работали разработчики) приступали к работе над тестированием нового билда лишь во вторник. Сессии планирования (стоит ли рассказывать, что, вопреки принципам Scrum’а, рядовые сотрудники в них не участвовали?) у нас проходили по четвергам, тестирование последнего билда в это время все еще длилось. Таким образом, просто не получалось составить план следующей итерации так, чтобы сначала исправлялись глюки, а лишь затем разрабатывался новый функционал. Можно было лишь предполагать что-то вроде «40% времени мы потратим на исправление ошибок». Такой подход вел к неконтролируемому распространению глюков.
8. Сами заказчики продуктов были удалены от проектных команд. Такой инструмент гибких методологий как «пользовательские истории» тоже не использовался. Таким образом, заказчики и конечные исполнители не находились «на одной волне» и нередко воспринимали одни и те же требования по-разному. А ведь это одна из проблем, которую должны решать гибкие методологии.
9. Не было и «ретроспектив». В конце каждого спринта команды не собирались вместе, чтобы обсудить слабые стороны итерации и решить, как можно улучшить процесс: распределенная природа разработки этого не позволяла. Иногда такие вопросы обсуждались руководителями на сессиях планирования, но решались лишь локальные вопросы — глобальные (а их было большинство) требовали многократного утверждения высшим руководством в США и «повисали» на неопределенный срок.

Думаю, читая об этих проблемах, вы подумали, что вся работа у нас провалилась. Это не так: мы закончили все проекты, некоторые даже в срок. Однако, это было сделано ценой переработок, понижения итогового качества продуктов, сильного раздувания бюджета проектов, а позже — сокращения части раздутого штата сотрудников. Кроме того, локально мы втайне от клиента проводили ежедневные стоячие совещания, ретроспективы, интегрировали в процесс собственных тестировщиков и прочими способами спасали (насколько это было возможно) проекты от вредоносного лжескрама.

В последующих проектах совместно с клиентом нам удалось изменить стратегию, мы масштабировали agile-процесс для работы распределенных команд, отказались от понятия «Scrum» и побороли большинство проблем, описанных в этой статье, что увеличило продуктивность работы в несколько раз. Хотите узнать, как мы этого добились, как внедряли изменения? — это тема следующей статьи.

«Сначала тебя игнорируют, затем над тобой смеются, затем с тобой борются, затем ты побеждаешь».

Махатма Ганди

Давайте мысленно вернемся в 2003-2004 годы: еще не существовало понятие AJAX, еще не было блога у каждой третьей студентки в большом городе, закругление уголков и зеркальное отражение логотипов еще не стало модной тенденцией веб-дизайна, а сайты с возможностью поиска одних пользователей другими еще не называли социальными сетями. В эти же годы со словом «фотобанк» в интернете ассоциировались Getty Images и Corbis.

Фотобанками пользовались и пользуются студии дизайна, рекламные и туристические агентства, издательства и многие другие, кому нужны фотографии на заданную тему, но не хочется (или нет возможности) нанимать для этой цели фотографов. В интернете фотобанки являлись логичной эволюцией информационных агентств вроде ИТАР ТАСС или Рейтерс.
Подход у этих служб был соответствующим: например, Corbis (основаный в 1989 году Биллом Гейтсом) не работал со сторонними фотографами, предпочитая все делать собственными силами, либо скупать традиционные информационные и фото-агентства. В Корбисе был целый штат аналитиков, следящих за мировыми тенденциями в политике, спорте, культуре, науке… и решающих, какие темы и стили фотографий будут наиболее ходовыми в ближайшее время. Наготове всегда был штат фотографов и моделей, светотехников, гримеров и костюмеров, экономистов и юристов. Если в Корбисе хотели снять фотосессию на медицинскую тематику — они просто арендовали настоящую больницу на ночь, привозили туда оборудование, моделей, часть декораций и проводили сессию.
Как видите, накладные расходы получались астрономическими, но фотобанки компенсировали это высокой стоимостью самих фотографий. Сколько я помню, 100-200 баксов за фотографию в низком разрешении считалось нормальной ценой.

На фоне этих гигантов возник проект iStockPhoto — фотобанк, являющийся посредником между фотографами и потребителями фотографий. Его цены были мизерными по сравнению со старшими братьями и составляли всего 1-20$ за фотографию. Большинство серьезных фотографов, игнорировали фотобанк, считая ниже своего достоинства продавать фотографии за 1-20$ (не считая комиссионных iStockPhoto). Игнорировали его и «старшие братья». Но фотобанк рос, набирая базу за счет любителей и средненьких фотографов.
Оказалось, что «любительские» фотографии тоже сильно востребованы и нередко оказываются по качеству не хуже «профессиональных» при значительно меньшей стоимости.
Вскоре бизнес-модель iStockPhoto стали копировать и появились новые фотобанки, такие как Dreamstime, Shutterstock (предлагающий абонементы вместо поштучной оплаты фотографий). Вслед за ними на рынок вышли Fotolia, StockXpert, BigStockPhoto… Этот тип фотобанков назвали «Микростоками» (Microstocks), и являлись они типичными представителями того, что сейчас принято называть «web 2.0».

Осенью 2005 года Киеве проходила презентация Zefa/Corbis. В это время я руководил разработкой Fotolia и, конечно же, хотел побольше узнать о конкурентах. Я спросил у представителя Corbis, как они относятся к конкуренции со стороны микростоков. Представитель улыбнулся и объяснил, что микростоки с их качеством фотографий не являются конкурентами Corbis и Getty Images.

Сейчас 2008 год. По данным Alexa iStockPhoto (проданый 2 года назад Getty Images) по своей популярности значительно обошел все остальные фотобанки — как микростоки, так и крупные. Затем идет Getty Images, с небольшим отрывом от нее следуют Fotolia и ShutterStock. Замыкает пятерку Corbis, запустивший собственный микросток — Snap Village.

Именно так энергичные стартапы побеждают «корпоративное зло», простые гибкие методологии разработки постепенно вытесняют бюрократизированные так же, как динамические языки программирования вытесняют статические.

Вслед за февральским обзором сайтов, прошедших через мою RSS-читалку, с небольшим опозданием публикую мартовский.

Успешно прошли

• Блог Henrika’а Kniberg’а — лучшее из всего что видел за последний год по теме гибких методологий разработки ПО. Хенрик умещает все основы методологии Scrum в один mindmap, описывает схемы работы с системами контроля версий при итеративной разработке, интеграцию тестировщиков в agile-процесс и многое другое.
• Микромаркетинг — очень приятный сайт о маркетинге и бизнесе. Все написано простым понятным языком. Прочитал этот сайт «от корки до корки».
• Ukrainian SCRUM Portal — продолжатель дела Agile Ukraine. Наиболее качественный украинский сайт со статьями о гибких методологиях разработки.
• Персональные вопросы — интересный блог о тонкостях работы кадровых отделов (в IT).
• Интернет нового века — автор этого блога недавно выступал на семинаре Exception 07, его доклад мне показался поверхностным и непродуманным… в то же время его блог о разработке с использованием фреймворка Django оказался значительно глубже и статьи несут практическую пользу.
• Блог об IT бизнесе — интересный и толковый авторский сайт об IT, один из лучших подобных сайтов, как мне кажется. Минус всего один — автор болен «синдромом блоггера»: пишет довольно часто, но разбавляет классные продуманные статьи откровенной халтурой. Если бы статей стало в 3 раза меньше и оставались только хорошие — стало бы гораздо лучше.
• Дедлайн как стиль жизни — толковый менеджерский блог. Освещаются темы управления проектами, мотивации, самоорганизации и различных «лайфхаков». К сожалению, как и большинству других менеджерских блогов, этому не хватает одного — изюминки.

Не прошли карантин

• Urbansheep — пишет только в LJ. Там его и читаю.
• Amazing development — никакой активности вот уже месяц, думаю, сайт сдох.
• GeoSpot — «много букф». И сайт явно рассчитан больше на туристов чем на путешественников.
• Agile Ukraine — теперь все полезное идет на scrum.com.ua.
• Аналитика Cnews — сухая подача материала из мира больших корпораций.
• How To Change the World — уже пару месяцев от Гая Кавыасаки никаких практических материалов, никакой пользы.
• IT и Бизнес, сайт превратился в помойку «корпоративных новостей» крупных компаний бывшего СССР.
• Overclockers Software — новости о софте для виндовс больше не интересуют.
• Алена C++, наверное, я слишком далек от мира C++ и компьютерных игр, потому что посты жены Сагалаева совсем не цепляют.
• Блог про Google Apps — все это и так публикуется на Хабрахабре.
• The Meanwhile — словил себя на мысли, что в последние месяцы читаю блог Ильи Бирмана «на автомате», а чего-то полезного для себя не нахожу.
• Agile Dokuwiki — проект морально устарел на пару лет и почти не обновляется.
• Sitepoint Blogs PHP — мало аналитики, много информации для новичков PHP. Мне такое не нужно.
• Блогбастер — блог о блогах. Довольно слабый и с малым количеством собственного контента.
• ITC.ua — сайт о компьютерах. С одной стороны новостей много и адекватных, с другой — тут вперемешку и новости «софта», и «железа», и интернета, что прилично раздражает, хочется читать только определенную тематику.
• XHTML.RU — сайт о верстке. Ничего плохого, но о самых интересных вещах все-равно читаю на «Хабре».
• У Wadа — об этом сайте я уже писал в прошлом обзоре. Увы, автор мешает интересные статьи о бизнесе, обществе потребления и.т.п. с историями «как я катался по Америке на авто»… последнего, к сожалению, больше.
• GUI.RU — неплохой сайт о юзабитили, но все его материалы, как оказалось, дублируются на «Хабре», так зачем же плодить сущности?

Временно в карантине

• Популярная веб-механика — довольно перспективный, на первый взгляд, блог о веб-разработках, но с мизерным количеством контента. Посмотрим: умрет ли сайт или будет жить.
• SitePoint — известный ресурс о веб-разработках: дизайне, верстке, программировании, управлении проектами и маркетинге. Читаю его уже 4 года, но в последнее время толковых статей становится все меньше и меньше, в основном публикуют довольно поверхностные материалы уровня «для чайников».
• Пепелсбей.net — сайт о верстке с приятным дизайном. Негатива не вызывает, но статей на сайте пока слишком мало чтобы сформировать окончательное мнение.
• Антикорпоратив — интересный блог о бизнесе, корпоративной среде (вернее, о ее вреде), «лайфхаках». Наиболее полезен работникам больших бездушных компаний. Серьезно смущает, разве что, обилие ненужных картинок к постам.
• Управление проектами в картинках — забавный менеджерский сайт. Картинки со схемами с него мне нравятся, а вот тексты — так себе…

В прошлом я пользовался разными «standalone» wiki-системами: WackoWiki, MediaWiki, DokuWiki, Confluence (по работе пользуюсь ей и сейчас).
Постепенно решил отказаться от использования standalone wiki в личных целях. Вначале перевел большую часть информации в Google Docs & Spreadsheets… Но вскоре выяснилось, что информацию в нем удобно редактировать, хотя ориентироваться в ней неудобно – D&S все-таки офисный пакет, а не wiki. Вскоре я нашел сервис WikiDot. Сервис показался довольно качественным, и через него можно было даже повесить wiki на собственный домен через DNS. Однако с удобством навигации в WikiDot явно прогадали: вместо иерархической структуры страниц авторы предпочли плоскую + теги… да и дизайн часто раздражал своей неаккуратностью.
В общем, я все еще искал альтернативу.

Около месяца назад в Интернетных Штучках написали о запуске нового сервиса Google Sites — и я решил попробовать.

• Google Sites обладает приятным внешним видом, хотя и без изысков. На выбор дается несколько тем оформления. На мой взгляд, тема по умолчанию наиболее приятна.
  
• Сама Google не позиционирует Sites как wiki, потому здесь нет wiki-разметки, зато есть удобный и функциональный WYSIWYG-редактор.
  
• На выходе WYSIWYG дает HTML-код, который можно редактировать и вручную.
  
• Текст на страницах можно размещать как в одну, так и в две колонки.
• Sites может вставлять в страницы оглавление (table of contents) — это очень удобно, когда у вас в wiki находятся страницы с большим количеством разных подзаголовков.
• Кроме оглавления, можно вставлять множество объектов из других сервисов гугла: Calendar, Docs&Spreadsheets, youtube, Picasa Web Albums…
  
• На мой взгляд, это особенно удобно для вставки данных из Google Spreadsheets.
  
• Также можно вставлять и гаджеты iGoogle — будь то прогнозы погоды, свежие ролики с youtube или новости сайта wired.
• Система ссылок в редакторе хорошо продумана — в модальном окне можно выбрать внутреннюю страницу либо ввести внешний адрес.
  
• Управление главным меню сделано схожим образом — из дерева разделов мы можем выбрать основные ссылки.
  
• Помимо простых страниц, в Sites можно создавать страницы новостей «Announcements», файлохранилища «File Cabinet», страницы-агрегаторы типа «Dashboard» и страницы списков «List».
  
  Если с первыми двумя все понятно, то о последних двух стоит рассказать подробнее. Dashboard представляет собой страницу с несколькими местами для вставки гаджетов iGoogle и прочих внедряемых компонентов, как в меню «Insert» wysiwyg-редакторв. List позволяет создавать списки с разными наборами полей и сортировать их: это удобно для списков задач, покупок, сотрудников и.т.п.
  
  
• Как и WikiDot, Sites можно прикрутить через DNS к вашему домену, правда, вас все равно перебросит на http://sites.google.com/a/siteaddress.
• Есть в Sites и серьезные недостатки. Главный, как мне кажется, — невозможность изменить URI страницы: представьте, что вы создали страницу «GoodPage» — адрес для нее будет вида http://sites.google.com/a/siteaddress/sitename/goodpage/. Если сменить название, например, на «BadPage» — адрес страницы все равно останется прежним — http://sites.google.com/a/siteaddress/sitename/goodpage/. С русскими названиями страниц проблем еще больше — приходится сначала давать странице название латиницей для URI, а затем переименовывать на русский. Думаю, это ограничение в гугле ввели, чтобы упростить работу с деревом сайта, но с точки зрения пользователя оно очень мешает. Надеюсь, что в будущем ограничение уберут.
• Второй серьезный недостаток — негибкая система прав доступа. Вы можете менять права доступа на разные Site’ы, но управлять правами конкретных разделов и страниц нельзя. Конечно, можно немного смягчить эффект, используя несколько «сайтов», например, публичный и частный. Но это всего лишь «костыль» и целиком проблему не решает.
• Третий недостаток — продукт является частью Google Apps (for your domain), потому недоступен бездоменным.
• Странно, что Google не внедрила в Sites такие свои сервисы, как Analytics и AdSense.

Итог

У Google (или JotSpot?) получился качественный и «человечный» продукт для малого бизнеса (для среднего и крупного бизнеса я рекомендовал бы Confluence) и частных лиц. Продукт, рассчитанный, в первую очередь, на обычных пользователей, а не гиков… Сервис очень хорош — более удобной wiki-системы я не встречал, но советовать его всем и каждому не стану из-за мелких недоработок и ограничений функционала.

Приходит Петька к Василию Ивановичу: «Васильываныч, хочу быть тимлидом!..»

Неоднократно мне приходилось читать (например, на DOU), как при обсуждении той или иной IT-компании, люди хвалят или ругают работодателей за их отношение к профессиональному росту персонала: «Отличная компания, я пришел сюда разработчиком, а недавно стал тимлидом!» или «Лучше сюда не идите, в компании стараются брать руководящие кадры со стороны вместо того, чтобы повышать своих рядовых сотрудников».
Я успел побывать как в роли повышаемого, так и в роли повышающего. Потому уверен, что подобные заявления достаточно наивны. На самом деле, в большинстве IT-компаний (кроме самых маленьких) проблема состоит не в том, что расти программисту некуда, а в том, что «двигать» некого.

Работодатели

В принципе, любой работодатель заинтересован в продвижении проверенных сотрудников, а не в приглашении на руководящие посты людей со стороны. Притом, исходит он не из этических соображений, а из очень даже меркантильных: новый человек в команде — это отчасти «кот в мешке» — до конца не знаешь, что он собой представляет (в отличие от проверенного своего сотрудника) — вот почему и существует испытательный срок. Недобросовестный руководитель проекта или тимлид может нанести бизнесу гораздо большие убытки (даже в течение испытательного срока), нежели рядовой сотрудник. Именно потому, ради уменьшения рисков, стараются повышать своих, а не приглашать новых. Если же руководящие кадры приглашаются со стороны — это, скорее всего, означает, что руководство компании не видит достойных претендентов среди собственного персонала.

Что делать?

Итак, вы все-таки хотите стать тимлидом:

1. Для начала подумайте, нужно ли вам это? Если вы очень любите программировать — знайте, что на программирование у вас останется гораздо меньше времени. С расширением полномочий уровень ответственности тоже увеличится: придется отвечать не только за себя, но и за всех членов своей команды. Стрессов станет побольше, особенно, в первое время и при сдаче проектов. А зарплаты тимлидов, замечу, не выше обычно, чем у ведущих специалистов.
2. Вам придется научиться говорить «нет», проявлять твердость характера: кому нужен тимлид, которому сотрудники «садятся на голову»?
3. Беритесь за организационную деятельность: неважно — будет ли это нечто связанное с текущими проектами, общим рабочим процессом компании или банальной организацией «пьянок» для сотрудников. Главное — чтобы это приносило пользу компании.
4. Необходимо не только проявлять активность, но и брать на себя ответственность: подход «все пидорасы — один я д’Артаньян» вряд ли приблизит вас к поставленной цели.
5. Помните, что ваше руководство — не телепаты: сообщите им о своем желании стать тимлидом. В этом нет ничего зазорного или унизительного. Зато руководство будет знать о вашей цели и может посодействовать — подсказать, чему стоит подучиться.
6. Необходимо качественно выполнять свою текущую работу: если вы регулярно нарушаете дисциплину, срываете сроки и недобросовестны — вас скорее уволят, чем повысят.
7. Постарайтесь заслужить уважение коллектива: если «коллеги по цеху» не считают вас профессионалом и приятным человеком — не воспримут и как реального руководителя.
8. Очень важно хорошо говорить и писать. Как правило, в полемике выигрывает лучший оратор. Руководитель, слабый в дискуссиях и спорах, легко может растерять авторитет.
9. Учитесь не только программированию, но и методам управления. Для этого придется штудировать, кроме книг по «паттернам» проектирования и языкам программирования, также книги и статьи по менеджменту, методологиям разработки, работе с рисками, несомненно, по человеческому фактору…
10. Тимлиду в аутсорсинговой компании может понадобиться и свободное владение английским.

Такого набора качеств и действий, в принципе, достаточно, чтобы вас заметили и повысили.
 Дерзайте!

Компания Apple всегда поражала меня своим подходом к бизнесу и маркетингу в частности — им удается делать как замечательные продукты, так и откровенную халтуру, сбагривая ее под лозунгами «инновационное» или «думай иначе»!
У Apple есть верная армия фанатов, готовых с пеной у рта доказывать, будто продукт не халтурный и не переоцененный. А ты — архаичный консерватор индустриального общества, не понимающий великого iСтиля.

Давайте на минуту отойдем от Apple и поговорим о восточных учениях. На востоке существует такая замечательная вещь — Йога: средство, научиться управлять своим телом и сознанием, она помогает обрести физическое здоровье и жить в гармонии с миром.
Все это замечательно и я с радостью занялся бы йогой, если бы не одно но: чтобы йога давала нечто большее чем эффект плацебо нужно радикально перестроить свою жизнь, свою систему ценностей… я слишком люблю свою жизнь такой, какой она есть чтобы радикально что-то менять.

Аналогичная ситуация и с iTunes. Всякий раз, когда жалуюсь кому-нибудь из мак-фанатов на качество этого «плеера» — выслушиваю лекцию о том, что к музыке нужно относиться как к музыке, а не как набору файлов. Всей оцифрованной музыке необходимо указывать ID3-теги и, вообще, нужно ее сортировать, а не держать свалкой на винчестере. Каждый порядочный мак-юзер обязан потратить N дней на указание ID3-тегов к своей музыке, а затем наслаждаться.
Только после этих монологов мне удается, наконец, рассказать, что вся (или 99%) музыка в mp3/ogg у меня снабжена тегами, рассортирована в формате исполнитель/год – альбом/номер трека – название песни, а сборники лежат отдельно и отсортированы по тому же принципу.

Увы, iTunes не позволяет легко и красиво с ней работать.

Как же выглядит работа iTunes с организованной коллекцией музыки? Первым делом «тюнс» пытается скопировать мои 70 гигабайт музыки к себе в папку. Какая разница, что они находятся не на сменном носителе?
Затем вся музыка импортирована и… о ужас! что случилось со всеми сборниками? В них стало очень тяжело ориентироваться, ведь в сортировке «по исполнителю» каждый сборник превратился в 10-15 песен разбросанных по плейлисту. Оказывается, необходимо выделить все эти песни и указать в настройках, что они являются частью одной компиляции. А когда слушаешь сборники — надо переключаться в режим сортировки музыки не по исполнителю, а по альбому (если в сборнике у всех композиций одинаковое поле «Альбом»). Еще менее прилично ситуация обстоит с музыкантами, которые нередко выпускают композиции в соавторстве: конечно же, Black Sun Empire, Black Sun Empire VS Concord Dawn и Black Sun Empire feat Illy Emcee — разные исполнители, плевать, что они все находятся на одном альбоме. Конечно, можно переключиться в режим альбома и нормально видеть все эти треки, но в этом случае неудобно будет пользоваться остальным плейлистом.

В iTunes, банально, нет возможности отсортировать музыку в том порядке, в каком файлы лежат в файловой системе (например, в WinAmp такой режим сортировки присутствует наряду с остальными) — мы, ведь, не должны думать о файлах, мы должны думать о музыке! Конечно же, музыку желательно не выкачивать с «торрентов», не «грабить» с дисков, а покупать в iTunes Store… Затем удобно сортировать в iTunes, сделать плейлист и закачать его для прослушивания в свой iPod.

Но я не хочу заново сортировать музыкальную коллекцию, не хочу указывать, какие песни входят в сборники, не хочу переключаться между разными режимами сортировки коллекции, не хочу создавать десятки плейлистов и не хочу выкачивать обложки альбомов из iTunes Music Store. Моя музыкальная коллекция и так в порядке. Я просто хочу список всей своей музыки, отсортированный по ее местоположению в файловой системе и удобный поиск по этому списку — все!

В отместку за все мои страдания шлю Эпплу, его маркетологам и Стиву Джобсу лично луч свирепой диареи!

В прошлой статье я рассказал о достоинствах и недостатках MacOS Leopard. В этой статье речь пойдет о программах в MacOS, которыми я пользуюсь каждый или почти каждый день.

1. Mail app + Адресная книга MacOS. С 2005 года это мой любимый почтовый клиент. Конечно, после выхода Thunderbird 2, Mail уже не кажется на голову выше всего остального, тем не менее, остается самым удобным почтовым клиентом из всех, что я видел. Смущают в программе только 2 вещи: настройки папок IMAP не всегда находятся в логичных местах, кроме того «из коробки» в программе не поддерживаются приоритеты писем (только «флаг», как в Gmail), решается эта проблема специальным плагином.
2. Adium — великолепный многопротокольный IM-клиент. Сделан на том же движке, что и Pidgin, но Pidgin крайне убог в плане дизайна и эргономики, Adium же радует глаз, интуитивен и функционален. Ближайшим аналогом является Trillian в Windows, но, в отличии от триллиана, Adium не глючит с кодировками в ICQ. Есть у Adium’а и серьезный недостаток, доставшийся ему по наследству от Pidgin’а — нет возможности управлять ignore/visible/invisible-списками в ICQ.
3. Skype — Скайп, он везде скайп. Правда, внешний вид у него в MacOS мне нравится больше чем в Linux-версии и намного больше чем в Windows. Еще одним важным для меня плюсом является поддержка Yugma, которой в Linux-версии Skype попросту нет.
4. OmniWeb — очень качественный и быстрый коммерческий броузер, его можно считать аналогом Opera, но на движке Safari. Единственный ощутимый минус — нет функции «undo close tab».
   Многие используют в MacOS родной броузер Safari: мне кажется, Safari — броузер быстрый и простой, но функционально находится на уровне IE 7.
   Firefox 2-й версии в MacOS представляет из себя тормозную поделку глючащую с русскими шрифтами. Но, уже неделю я пользуюсь последней версией Firefox 3 beta, он работает почти так же быстро, как и OmniWeb, выглядит как родное mac-приложение, быстр в работе и глюков с русскими шрифтами нет. Однако, еще не все плагины нормально работают в 3-й версии, а некоторые сайты (например, Google Docs & Spreadsheets) здесь глючат. Я полностью откажусь от OmniWeb, когда выйдет финальная версия Firefox 3.
5. Unison — клиент для конференций Usenet (протокол NNTP). Не скажу, что в восторге от программы, но удобнее ничего не нашел. В отличии от большинства NNTP-клиентов программа позволяет прикреплять файлы к сообщениям и отдельно выводить список файлов конференции, что является несомненным плюсом. С другой стороны — нет возможности посмотреть сводку о новых сообщениях во всех конференциях на одной странице.
6. Vienna — качественная бесплатная программа для чтения RSS/Atom. К сожалению, для конфиденциальных потоков приходится использовать ее, а не Google Reader. Но сама программа, однозначно, хороша.
7. Transmit — добротный двухпанельный FTP-клиент. Все работает легко и стабильно. Не хватает, только, возможности использовать несколько вкладок, как в FTPRush.
8. Calculator — без комментариев.
9. iTunes + Last.FM — аудио-плеер. Пожалуй, самая спорная программа Apple. Я всячески пытался найти ей альтернативы, 4 недели использовал сыроватый Cog, но в итоге пользуюсь iTunes. Вскоре напишу о нем отдельную статью.
10. Visual Paradigm — кросс-платформенный инструмент для UML-моделирования. О нем тоже будет отдельная статья.
11. iWork — офисный пакет производства Apple, совместимый с MS Office и Open/NeoOffice. В отличии от MS Office простой и удобный в использовании, при том внешне iWork больше похож на Windows-версию офиса, чем на mac-весию. Умеет проверять русскую орфографию. В отличии от бесплатного NeoOffice красиво выглядит. В состав входят Pages (аналог Word), Numbers (аналог Excel) и Keynote (аналог PowerPoint). Numbers я не использую, так как хватает Google Spreadsheets, Keynote не нужен вовсе, а вот Pages активно использую, когда нужно писать тексты и важна проверка правописания.
12. Dictionary — стандартный словарь входящий в поставку MacOS. Был бы ничем не примечательным, если бы не словари Lingvo 12, которые я туда интегрировал.
13. MacPorts — MacOS, это ведь unix-система. Мак-порты — это упрощенный аналог портов во FreeBSD. Через порты я ставил Python, Mercurial, Midnight Commander, Wget (хотя, последнее время, чаще пользуюсь iGetter’ом).
14. VMWare Fusion — виртуальная машина, о ней можно почитать в предыдущей статье.
15. FreeMind — кросс-платформенное средство для рисования MindMap’ов.
16. MuCommander — двухпанельный файловый менеджер, аналог Total Commander’а. Инструмент нормального geek’а, Finder’ом для активной работы с файлами пускай пользуются «гламурные блондинки». Удивительно, но бесплатный MuCommander понравился мне значительно больше платного DiskOrder.
17. TextMate — самый удобный и приятный из всех программистских текстовых редакторов, которыми я пользовался (для честности скажу — Vim не осилил). За счет встроенных плагинов (они называются bundles) обладает богатым функционалом. Подкупает обилие встроенных цветовых схем, большинство из которых предполагает работу со светлым текстом на темном фоне. Редактор мне понравился так сильно, что дома в Windows стал пользоваться его клоном — E-TextEditor.
18. AppZapper — честное удаление программ. Многие знают, что удалять программы в MacOS очень просто, для этого достаточно перетащить иконку приложения из папки applications в корзину. Но, лишь, немногие знают, что большинство приложений оставляют за собой мусор в виде кеша, файлов настроек, логов… При удалении программ через AppZapper это проблема решается.
19. Disco — простое и удобное средство записи CD/DVD-дисков.
20. iGetter — менеджер закачек, аналог ReGet/FlashGet/Download master. В паре с плагином FlashGot для Firefox показывает чудеса удобства (как и Reget в Windows).
21. Transmission — удобный и простой в использовании Bit Torrent клиент. Сильно напоминает uTorrent в Windows. Большинство программ для MacOS я выкачиваю из торрентов.
22. CHMox — просмотрщик CHM-файлов. Apple посчитала лишним включать в систему поддержку стандартного формата help’ов из Windows. Однако, большинство электронных книг представлены именно в этом формате.
23. Perian — набор кодеков для Quick Time. Вместе с ним Quick Time превращается из чего-то убого-платного в полноценный удобный видео-плеер.
24. KeyboardRemap — небольшая утилита, позволяющая расширить функционал клавиатуры. Я с ее помощью отключил NumLock в MacOS.
25. JumpCut — небольшая утилита, сохраняет историю буфера обмена. Аналог Ditto в Windows.
26. Jing — великолепное бесплатное средство для и захвата снимков и видео с экрана. Мне понравилось больше чем SnagIt. Тут отличный интерфейс, удобный захват снимков, удобные средства подписей этих снимков, а самое главное — кроме сохранения файлов-скриншотов Jing умеет закачивать их на Flickr или на сайт программы.
    Хотя, многие вполне довольны связкой встроенного в ОС средства скриншотов и фотошопа.
    На сайте сказано, что существует версия Jing и под Windows.
27. ClamXav — бесплатный антивирус для MacOS. О вирусах в этой системе я уже слышал. Учитывая, что часто качаю патчи для программ из неблагонадежных источников — время от времени проверяю систему на наличие вирусов.
28. Porrasturvat — игра, румынский симулятор сбрасывания человека с лестницы. Отличное средство чтобы расслабить мозг. Есть версия и для Windows.
29. TeeWars — снова игра, снова кросс-платформенная. Двухмерная мультиплеерная аркада, очень веселая. Опять же, отличное средство отвлечься на 5-15 минут.

Единственная программа, которая нужна мне каждый день и аналога которой я не нашел для MacOS — Punto Switcher. Если быть точным — аналог есть, RuSwitcher но у меня в Leopard он не заработал.

Выводы из статьи делайте сами.

С MacOS я знаком давно, еще, будучи учеником, в школе работал два года за старенькими маками (MacOS, кажется, тогда был 8-й версии) на уроках информатики. За компьютерами с MacOS Tiger я некоторое время работал в 2005 и 2007 годах.
В январе 2008 попробовал MacOS Leopard, при том, впервые работал не на родном mac-железе, а на обычном «пацюке» с интеловской платформой и «патченым» дистрибутивом MacOS: это еще называют Hackintosh.
После всех неприятностей с линуксовым софтом хотелось чего-то более качественного, но на «куцый» виндовс возвращаться не хотелось, компромиссным вариантом стал MacOS Leopard (Kalyway 10.5.1).

Установка и первый запуск

С первого раза систему установить не получилось — она не хотела ставиться на дополнительный раздел диска, где уже стояли Windows XP и Linux Ubuntu. Вскоре оказалось, что MacOS ставится только на главный раздел диска: пришлось попрощаться с обеими системами и переразбить диск. Далее при установке пришлось выбрать «патченное» ядро под процессоры SSE2 (на работе у меня Pentium D, если бы был чуть более новый, Core 2 Duo — смог бы воспользоваться «родным» ядром под процессоры с SSE3). Оставшаяся часть установки прошла, на удивление, гладко.
При первом старте системы порадовало чувство юмора сотрудников Apple: при настройке временной зоны по-умолчанию, стоит не Нью-Йорк или Вашингтон, а Купертино (маленький городок в Кремниевой Долине Калифорнии, где находится штаб-квартира Apple). Еще сильней порадовало другое — все оборудование компьютера нормально определилось и заработало как родное: и процессор, и звук (Intel HDA), и видео(nVidia Geforce 7300GS) и, даже, сеть (что-то на чипе Realtek). Различные USB-кардридеры и Bluetooth dongle тоже работают без проблем.

А как же проблемы «хакинтоша»?

За более чем месяц использования проблемы действительно возникли.
Первой оказался наш сетевой принтер, HP 1022n. Драйвера для принтера ставились, но в системе он не определялся, думаю, в этом виновато «патченное» ядро. В макосе я разбираюсь не настолько, чтобы собственноручно портировать драйвер принтера к хакинтошу, потому решил поставить виртуальную машину с Windows, ведь печатаю я не так уж часто.
Родная виртуальная машина Parallels оказалась унылым говном — система от нее неприлично тормозила и, даже, зависла один раз. VMWare Fusion оказалась значительно лучше: проблема принтера с ней решилась, пусть и не самым красивым способом. Впечатлил режим эмуляции Unity: в этом режиме окна «гостевой» системы просто размещаются внутри «родительской», на youtube можно посмотреть как это выглядит. Порадовало, что в режиме эмуляции окну с «вирту-виндовсом» можно как угодно менять размер (драйвер видео-карты vmware это позволяет) и получать экзотические разрешения, хоть 138x1024. Рендеринг окон внутри vmware происходит через систему «мака», а не «винды» (если у вас Windows — попробуйте захватить мышкой открытое окно и резко подергать его, за окном будет оставаться неприятный короткий шлейф, в макосе же рендеринг окон плавный).
Проблемой номер два оказался режим «сон», в хакинтоше его можно переименовать в «каматоз», потому что заснувший компьютер разбудить уже нельзя. У меня стационарный компьютер, а не ноутбук, потому режим сна я отключил и не страдал по этому поводу.

Преимущества и недостатки

Леопард мне понравился. Прогресс, по сравнению с Тигром, вполне ощутим. Особенно хорошо система смотрится на фоне провальной Windows Vista.
Теперь система, как и Linux, поддерживает несколько рабочих столов. Переключение между ними, конечно, не такое эффектное, как Desktop Cube но вполне приемлемо. Основное отличие многодесктопности от линукса: тут окна программ не перетягивают из одного рабочего стола в другой, а зажимают мышкой активное окно, после чего переключают рабочий стол с клвиатуры.
Не меньше обрадовало появление Time Machine, которая куда более человечна и удобна в использовании, чем привычные backup-утилиты.
Кроме того, в Леопард, наконец-то, добавили поддержку windows-клавиатур. Остальные улучшения MacOS для меня не были столь важны.

В MacOS я не заметил особых проблем с софтом: для всех (почти) моих нужд нашел необходимое ПО и оно было не менее качественным, чем в Linux/Windows. Все это ПО выполнено в едином стиле (интерфейсы, поведение). В отличии от Linux, тут работают Photoshop и Lightroom, тут есть MS Office и Apple iWork. Вопреки стереотипам, под мак тоже есть вирусы… и антивирусы!
С консолью все тоже шоколадно: она такая же как во FreeBSD. По-умолчанию используется тот же Bash. Существуют МакПорты, через которые я ставлю весь консольный софт и библиотеки, будь то свежая версия Python или Wget.

Однако, система не лишена серьезных недостатков. Ради упрощения интерфейсов Apple отказалась от возможности «вырезать» файл в Finder’е: файл можно копировать, можно удалять, а если нужно его просто переместить на другой физический раздел диска — только скопировать, а затем удалить. В MacOS очень слабые возможности «кастомизации»: обои, размер и эффекты дока, шрифты, расцветка шелла — по-моему, это все, что мы можем сменить. Выглядит довольно бедно на фоне мощи Linux’а. Впрочем, наверняка существуют какие-то сторонние программы, позволяющие гибче настроить систему, просто я ими не пользовался.
Софта под мак много и качественного, но почти весь он платный, даже плагины к Safari и Mail. Процент бесплатного ПО заметно ниже чем в Windows.
Система прожорлива в отношении оперативной памяти. У меня на компьютере стоял 1 гигабайт, чего для удобной работы не хватало. После добавления еще 1 гигабайта проблемы ушли. Удивительно, что компьютеры Mac Mini продаются даже с 512 мегабайтами оперативной памяти.
Такого удобного средства управления пакетами, как Apt-Get (и его аналогов) из Linux здесь нет.

Напоследок

MacOS — система, состоящая из сплошных компромиссов: между удобством пользования и гибкостью, между ориентацией на рядовых пользователей и geek’ов, между качеством софта и его ценой. Я не в восторге от этой системы и ее функционала, тем не менее — это лучшее, что есть сегодня на рынке операционных систем: золотая середина между консервативным Windows и технологичным, но неряшливым Linux.
После 5-6 недель эксплуатации у меня не возникает желания использовать в офисе что-то другое, зато появляется стойкое желание пользоваться MacOS и дома.
В следующей статье я расскажу подробнее о софте, что использую в MacOS.

На рабочем компьютере у меня стояла Windows XP. Полгода назад я отказался от MS Office в пользу «Google Docs & Spreadsheets» и, вскоре после этого, обнаружил, что могу отказаться и от самой Windows: все программы, что мне нужны для работы, либо работали через браузер, либо были кросс-платформенными, либо, без особых проблем, можно было найти аналоги.
С различными unix-системами (в основном, на серверах), я работаю уже 7 лет и, по разным причинам, хотел на работе перейти на них с windows… Выбрал для себя Linux Ubuntu. Выбрал по нескольким причинам: во-первых она заточена под Gnome(KDE мне никогда не нравился), во-вторых — хорошо документирована и, в конце концов, в каком еще линуксе существует такая классная поддержка оборудования?

Что понравилось в системе?

1. Работает любой специализированный юниксовый софт, будь то стресс-тестировщик Siege, редкие модули PHP или консольный «качек» Wget.
2. Очень гибкие возможности настройки: я настраивал под себя тему оформления и иконки в GTK, «декораторы» окон через Emerald и эффекты Compiz Fusion. Устанавливал и настраивал док — Avant Window Navigator. Менял шрифты и способ их сглаживания… Консоль (bash) тоже ручками расцвечивал. В общем, получилось очень приятно и удобно.
3. Весь софт, которым я пользовался — бесплатен. Соответственно, нету никаких проблем с поиском «крека» и активацией.
4. Управляться с установленными программами и библиотеками через Apt-get — одно удовольствие. Он снимает 90% трудностей связанных с обновлением системы. Оставшиеся 10% — это, пожалуй, мелкие правки конфигурационных файлов.
5. Несколько рабочих столов — это очень удобно, когда у вас много открытых окон. У меня на одном рабочем столе находятся браузер и почтовая программа, на втором — мессенджеры, на третьем — аудио-плеер и консоль… и везде достаточно места!
6. На Ubuntu Forums находятся ответы на абсолютное большинство вопросов по системе.
7. Эффекты XGL довольно приятные, хотя нравятся не всем. Главное — отключить прилипание окон к краям экрана.
8. Очень удобная среда для разработчика: много программистских редакторов и IDE, имеются все возможные сервера приложений, ставятся без танцев с бубном любые СУБД(ну, кроме MS SQL Server)… ну и присутствие «взрослой» консоли конечно же.

К сожалению, за все приходится чем-то платить: минусы у системы, тоже, весомые.

Что не понравилось?

1. Как всегда в опенсорсе — качественного desktop-софта очень мало. Ведь разработчикам интересно разрабатывать фреймворки и библиотеки, а не улучшать эргономику интерфейсов.
2. Avant Window Navigator(из репозитория), время от времени, вылетает. В более старых версиях нет красивых тем оформления.
3. Firefox работает заметно медленней, чем в Windows.
4. Я не нашел удобного и гибкого Multi-IM клиента (как Trillian и Miranda в Windows или Adium в MacOS): Pidgin, Kopete и Sim показались до неприличия убогими. В одном нельзя сортировать группы как мне нужно, в другом неудобно управлять статусами разных служб, в третьем уродливый интерфейс и.т.п. Самым качественным для меня, как ни странно, оказался консольный CenterIM.
5. Не нашел удобного аудио-плеера уровня WinAmp-5. Ближе всего оказался Audacious, но это уровень второго WinAmp’а, а не 5-го… то есть, морально устарел на 4-5 лет. Amarok не понравился, уже не помню чем.
6. XNeur (аналог Punto Switcher) неприлично глючит.
7. Шрифты, поставляемые с системой, по умолчанию, никуда не годятся: они попросту небрежны, если сравнивать с аналогами Microsoft и Apple. В итоге, приходится тратить много времени, чтобы подобрать себе приличные шрифты для всего софта.
8. Не всегда нормально работает буфер обмена, один и тот же текст я могу, например, копировать между Firefox и Thunderbird, но в Gajim скопировать его, уже, не могу.
9. Бывают случаи, когда Google Docs не хватает(например, нужна проверка правописания). OpenOffice ни по скорости работы, ни по эргономике и внешнему виду никак не дотягивает до MS Office и iWork.
10. Иногда я на работе фотографирую сотрудников и мероприятия, затем эти фотографии нужно обработать. Gimp никак не тянет на замену Photoshop, а аналога Lightroom‘а в линуксе нет вообще.
11. Google Docs & Spreadsheets глючат в Firefox. Это, явно, проблема Gnome, у коллег с KDE все работает нормально.
12. У KDE/QT программ внешний вид ощутимо отличается от GTK’шного и настраивать его нужно отдельно, что, иногда, напрягает.

Если внимательно посмотреть — видно, что почти все мои нарекания не к самой Ubuntu или Linux, а к качеству линуксового софта.
Нарекания настолько серьезные, что, время от времени, я переключался назад в Windows, радовался, что софт работает стабильно и предсказуемо… И так до тех пор, пока не начинало бесить отсутствие нормальной консоли с привычными grep и wget, всего один рабочий стол, устаревшие эффекты оформления и появляющиеся, почти каждый день, «синие экраны смерти».
Вскоре я пересел на MacOS, но об этом в следующий раз.

О книге «Building Scalable Websites» Кэла Хендерсона (ведущий разработчик Flickr) я узнал из рецензии на сайте developers.org.ua. Сразу загорелся и, спустя несколько месяцев, достал и прочитал книгу.
Впечатлений от книги осталось много, в основном — плохих. Кэл, похоже, не знает о существовании технологий вне PHP-мира, да и писатель из него странный. Давайте рассмотрим книгу по главам.

Краткое содержание книги

• Глава об архитектуре приложений свелась к тому, что приложение должно иметь слои, а логика представления должна отделяться от логики приложения. В этой же главе рассказано, что «взрослые системы» работают, как правило, в условиях сильно отличающихся от большинства shared hosting’ов. При этом, о шаблонах проектирования таких приложений не сказано вообще. А очень стоило бы сослаться на Мартина Фаулера.
• В главе 3 (Development Environments) рассказывается, для чего нужна система контроля версий (говорится о них очень мало, недостаточно для нормальной работы, о распределенных системах контроля версиями не сказано вовсе), система сборки проекта (в один шаг) и система учета задач. Также сказно, что без общих конвенций кодирования далеко не уедешь. И все!
  У Джоэля Спольски эти же вещи описаны значительно лучше, без воды и, всего, в нескольких параграфах!
  Убивает рассказ о юнит-тестах, сводящийся к тому, что тесты существуют в природе. Масштабные интернет-системы делаются, как правило, не маленькими командами, потому я бы в главу добавил информации про Continuous Integration. Без CI-систем довольно быстро разработка превращается в вопли разработчиков «Бляяядь, после апдейта снова все сломано!»… С CI же на смену такому режиму приходит «Блядь, я сломал билд, надо срочно откатить код, пока никто не заметил!». Но, ведь, в PHP нету своих CI-систем (на самом деле можно использовать джавовский CruiseControl с PHP-проектами), откуда же о них знать Кэлу Хендерсону?
  Удивительно, как можно писать о стандартах кодирования, в то время как книга кишит примерами кода вроде этого:

  
  function store_file_2($host, $filename){
          ...
          if ($connection_failed){
                  return 0;
          }
          ...
          if ($operation_failed){
                  return 0;
           }
           return $result;
  }
  

  Что такое store_file_2()? За такие имена методов, вообще-то нужно по рукам бить. Делать логику метода нечеткой и отдавать либо результат операции, либо ноль (хотя операция совсем не обязательно должна возвращать Integer) — один из любимых приемов быдлокодеров. Как правило, он лечится, когда такой разработчик сталкивается со строгой типизацией в других языках, либо с веб-сервисами.
• Главу об интернационализации и юникоде безболезненно можно ужать до одной страницы, где будет сказано, что может быть одна кодировка — UTF-8 и будет рассказано, как с ней работать в PHP и MySQL, а также в JavaScript и при отправке писем. Автор ухитрился растянуть эту информацию на 20 страниц.
• В главе о безопасности написано о всяких разных XSS-хаках, SQL-injection’ах и способах фильтрации контента. В общем, о том, чем кишат всякие говнограммы вроде PHPBB, Joomla, PHPNuke. Я считаю, разработчик масштабных интернет-систем заведомо обязан это знать. В книге о масштабировании подобная тема нужна, явно, с одной целью — набить килобайтов текста, за которые автору платит издатель.
• Глава об электронной почте — самое ценное, что есть в книге, говорю это без всякого сарказма. На тему мобильной загрузки, мобильного постинга в блоги и методов разбора электронных писем толковых материалов существует не так уж много. Уверен, эту часть Flickr’а Хендерсон сам и разрабатывал… иначе, почему в этой главе много полезной информации и мало воды, а не как в остальных?
• Глава про «remote services», естественно, свелась к перечислению реализаций этих самых сервисов (старичка CORBA, конечно же, не упомянули… ведь в PHP нету его реализаций). Какой-то аналитики на тему «чем сервис X лучше сервиса Y в условиях Z» ожидать не стоит.
• Глава «bottlenecks» написана неплохо, однако ее практическая часть полезна исключительно PHP-разработчикам.
  В то же время, презентация Бреда Фицпатрика «Inside LiveJournal’s Backend» гораздо лучше отображает проблему «узких мест».
• Главу «Scaling Web Applications» можно считать в книге главной и написана она вполне прилично: тут и теория и практика с примерами из жизни. Нареканий только два: во-первых мало, а во-вторых описан, опять же, исключительно LAMP-стек.
• Затем идут водянистые главы про мониторинг серверов и построение API (эту главу можно рассматривать как продолжение главы о remoting’е).. все, Книга окончена!

Подводя итоги

Книга рассчитана на специалистов интернет-разработок настолько же, насколько книги Дейла Карнеги рассчитаны на профессиональных психологов, а книга «бизнес в стиле фанк» — на бизнесменов… то есть, вообще ни разу не рассчитан! Профессионалы, скорее всего, не найдут в книге ничего нового.

Новичкам книгу тоже не порекомендуешь: общие темы рассмотрены поверхностно(зато впечатляет их количество: тут упомянули использование wiki для документации и, даже, итеративные методологии разработки), наверняка, о них уже написано в более простых книгах. А на основной вопрос «Как строить масштабируемые веб-приложения?» книга так и не отвечает.

Впрочем, книга не такая плохая, как могло показаться из моего описания. Она тянет на уверенную троечку по пятибалльной системе. От того что почитаете эту книгу хуже наверняка не станет, просто, то же время можно потратить с куда большей пользой и почитать High Scalability.
Книгу стоило бы переименовать, скажем, в «Scaling PHP applications in a nutshell» и сократить в 3 раза, стало бы значительно честнее, но за что тогда брать $26.39?

Выводы

Кэл чем-то напоминает плохого журналиста, ну знаете, такого специалиста широкого профиля, который легко пишет и о политике и о культуре и о нано-технологиях: рядовой обыватель это успешно хавает, а специалисты любой из этих областей плюются. Забавно, книга понравилась многим уважаемым мною людям и на Amazon у нее рейтинг тоже высокий.

Для себя я сделал следующие выводы:

• Для желающих разобраться в масштабировании веб-приложений лучшими вариантами остаются High Scalability, общение с коллегами, посещение семинаров вроде Exception и практика-практика-практика.
• Издательство O’Reilly менее добросовестное чем Addison Wesley. Оно вполне может выпускать низкокачественные книги, потому что их раскупят благодаря имени автора.
• Многие готовы купить книгу просто из-за ходового названия и приписки «От создателя Фликра». Мало кто знает, что Flickr не блестал изяществом архитектуры и с машстабированием у него были серьезные проблемы перед продажей гиганту Yahoo.

Однажды я нашел полезную статью и поделился с коллегой, статья могла помочь нам обоим упростить рабочий процесс. Коллега сказал «Спасибо! Но у меня нет времени ее читать — очень много работы». У всех иногда бывают авралы, потому спустя неделю я снова показал статью коллеге, но у него, к сожалению, опять не было времени на чтение. Через месяц я показал ему другую полезную статью, времени на ее прочтение опять не нашлось. Вскоре я понял, у моего коллеги, в принципе, нет времени для самообучения: его рабочее время полностью расходуется на текущие задачи.

Реальность и стереотипы

Ужасно, но очень многие работники умственного труда считают, что на работе они обязаны тупо «фигачить» 8 часов в день, а когда не остается сил — делать вид, будто «фигачат».
Когда-то я пришел на новое место работы: подчиненные стыдливо прятали открытые окна Хабрахабра и Гуглридера, когда я входил к ним в комнаты.
Многим, в таком подходе, виноваты стереотипы недальновидных руководителей, но если им потакать — ситуация наемных сотрудников не улучшится.

Получение актуальной профессиональной информации и самообучение — это такая же часть работы, как и все остальные. Читать профессиональную литературу и быть в курсе событий вашей отрасли — значит учиться на чужих ошибках, что куда дешевле, чем учиться на собственных. Кроме того, совершенствуясь, вы становитесь более ценными сотрудниками для работодателя.
Читая специализированные форумы и блоги специалистов в разных областях вы можете учиться у лучших в отрасли. RSS — отличное средство мониторинга такой информации. Как же находить время для чтения?

7 простых советов

• Для начала признайте, что вы не фигачите по 8 часов в день. Наверняка вы тратите немало времени на проверку почты, разговоры в IM, чтение баша, перекуры и что-то подобное. Попробуйте использовать хотя бы часть этого времени для чтения.
• Выделяйте каждый день определенное количество времени для чтения. Сообщите остальным, что в это время вы заняты. Обычно, проблемы связанные с самообучением на работе появляются тогда, когда человек вместо выполнения своей основной работы тратит часы в поисках истины, либо же бездельничает, как офисный планктон: установите себе временные рамки для чтения и проблема вас минует. Например, я пользуюсь Google Calendar и указываю в нем время для чтения. Затем даю доступ к этому календарю тем, кто может назначить какие-то совещания с моим участием. Прошлым летом мне нужно было проводить много собеседований, наш отдел кадров четко знал, что в большинстве случаев с 14:00 до 15:00 собеседования назначать нельзя — я занят.
• Постарайтесь выделять каждый день одно и то же время для чтения, многим подходит время сразу после обеда или в конце рабочего дня, когда за сложные задачи уже не берешься.
• Пользуйтесь «карантином», выбрасывайте RSS-ленты, которые не приносят много пользы.
• Выставляйте приоритеты важности для информационных ресурсов. Если вы уже пару недель пропускаете материалы сайта с высоким приоритетом — скорее всего, вы лжете себе на счет важности этих материалов, удалите их, либо поместите в карантин.
• Если вы руководитель, либо фрилансер — все просто, если же вы просто наемный работник и начальство гневно относится к чтению в рабочее время — покажите им эту статью, ничего криминального здесь нет. Чтение RSS — это не трата времени, а инвестирование его в решение текущих и будущих задач.
• Если вы пользуетесь общественным транспортом — постарайтесь читать RSS там с КПК или мобильного телефона. Увы, не все возвращают в RSS полные тексты статей.

Помните, все вышесказанное относится строго к работникам умственного труда. Клерки, например, к ним не относятся.

Возможно, вы можете дополнить эти советы?

Так получается, что, интересных регулярно обновляемых сайтов, которые меня интересуют, всегда оказывается больше чем времени на их прочтение. Потому, уже год практикую следующее: в RSS-читалке имеется раздел «quarantine», куда добавляются все новые подписки. Через неделю-месяц становится понятно, стоит ли ресурс затрачиваемого на него времени и, соответственно, попадает либо в одну из «настоящих» категорий RSS-читалки, либо в мусорку. RSS-потоки, которые надоели или испохабились я тоже не удаляю просто так, отправляю их в карантин — всегда лучше иметь второй шанс.
Итак, каждый месяц буду проводить мини-обзор сайтов побывавших в карантине.

Успешно прошли

• Design For Masters (язык — русский). Отличный ресурс о веб-разработке, эргономике, поисковой оптимизации и прочему.
• Django is for the Aware (язык — английский). Среднего качества блог, зато в нем множество практического материала по фреймворку Django.
• Крайнов (язык — русский). Узнал о нем благодаря блогу Давыдова. Отличный авторский сайт о маркетинге, саморазвитии и всяких там «лайфхаках».
• LUK!Around (язык — русский). Просто добротный сайт о путешествиях, у него нету изюминки, но и чего-то отталкивающего тоже нету.
• Smashing Magazine (язык — английский). Очень качественный интернет-журнал для дизайнеров и тех, кому важны темы эргономики в вебе, инфо-дизайна, инноваций в гажетах.
• Startup Cube (язык — русский). Сайт Крайнова о бизнесе.
• Владимир Губарков (язык — русский). Отличный блог о языке Python.
• Блог в помощь (язык — русский). Блог о блогах. Не всегда качественно, но где еще русскоязычный блоггер может почерпнуть столько полезной информации?
• Оптимизация черная и белая (язык — русский). Из названия все ясно, в остальном же — качественный сайт сеонитса, человеческий язык.

Не прошли

• ajaxed — Все самое модное (язык — русский). Не плохой ресурс, но все значимые новости из мира джаваскрипт-инноваций и так можно узнать с тематических сайтов вроде Хабрахабра.
• IBM Developer Works Россия: Linux (язык — русский). За месяц не появилось ни одной важной статьи по серверному линуксу.
• EffBot (язык — английский). Добротный по содержанию, но слабый по уровне подачи сайт о языке Python. Выдавать в RSS-ленте только названия статей без аннотацийполного текста — хамство.
• Etoday (язык — русский). Отличный фотожурнал. Фотографии из мира культуры, политики, музыки… Довольно плотный трафик, в среднем в день по 3-10 новостей. Однако, в последнее время, обилие светских хроник, фотографий с показов мод или, просто, оригинальной одежной рекламы убивает все хорошее.
• Django Weblog (язык — английский). Жаль, что новости на сайтах фреймворков очень редко оказываются полезными, Django — не исключение.
• Маркетинг, за который платят (язык — русский). Пусть кто-то платит, но на тему маркетинга предпочитаю читать Крайнова и Давыдова, которые и пишут лучше и дурацких картинок в посты не вставляют.
• Productivity 501 (язык — русский). Это как-то сильно непродуктивно читать сайт о лайфхаках и продуктивности, где большая часть заметок банальна до неприличия и адаптирована строго под американцев.
• Аквариум (язык — русский). Java-блог компании SUN о сервере приложейний Glassfish. С одной стороны, полезно иметь свежие новости, с другой — все-равно я их обычно «прокскроливаю», а о самом интересном читаю на The Server Side.

Остались в карантине

• Urbansheep (язык — русский). Автор уже 2 месяца ничего не пишет.
• Amazing Development. Блог о html вёрстке, юзабилити и управлении проектами (язык — русский). Пока еще мало информации чтобы понять, нужен ли мне этот блог. Но качество контента однозначно высокое.
• ITC.ua (язык — русский). Сайт о компьютерах. С одной стороны новостей много и адекватных, с другой стороны — тут в одной ленте и новости софта и железа и интернета, что прилично раздражает, хочется читать только определенную тематику. Посмотрим еще пару-тройку недель.
• У Wada (язык — русский). Сайт о самосовершенствовании и бизнесе. Пока не могу понять, насколько он хорош, но интересные посты точно бывают.

В некоторых языках программирования (Python, Ruby, JavaScript и некоторые другие) есть возможность переопределять атрибуты и методы классов во время исполнения программы. На этой возможности была построена целая техника программирования, она называется Monkey Patching.

Откуда взялось такое название?

Изначально термин назывался guerilla patch (партизанский патч): разработчик незаметно добирался до чужого кода, изменял на лету поведение этого кода, не заботясь о соблюдении каких-либо правил, установленных создателем, а потом так же незаметно исчезал, оставив создателю порцию говна, в виде кода не работающего, как надо, без видимых на то причин. Поскольку, слова Guerilla и Gorilla звучат очень похоже — вскоре эту технику стали называть «горилла патч», что в конце концов трансформировалось в monkey patch. Именно этот термин прижился, поскольку лишен негативной окраски предшественников.

Практическое применение

Думаю, главное практическое применение техники обезьяних патчей — расширение функционала чужих продуктов (фреймворков, библиотек) без непосредственного вмешательства в их код, а также, т.н. security patches. Хотя, как инструмент террора, эта техника не менее хороша.

Пример из жизни

Существует замечательный, но не лишенный недостатков, фреймворк для веб-приложений — Django. В нем уже существует модель пользователя (User), используемая для авторизации, разграничения прав доступ, хранения самих пользователей… Естественно, эту модель нужно использовать. На практике оказывается, что у пользователя могут быть дополнительные атрибуты (не предусмотренные фреймворком), например, пол или телефон. Первое, что хочет сделать здравомыслящий разработчик, — написать новый класс пользователя, унаследовав его от джанговского. Увы, один из главных минусов django — его ORM не поддерживает наследование моделей, то есть модель то создастся… но она всего лишь продублирует все поля родителя в новую таблицу базы данных, создав тем самым избыточность.
В нашем случае можно сделать дополнительный класс UserProfile для дополнительных полей и связать его с классом User отношением один-к-одном,. но признайтесь, это, явно, не самое красивое решение, тем более, когда-нибудь в django доработают ORM. Патчить исходные коды django — вариант еще хуже, так как все нормальные разработчики пользуются его версией из репозитория (SVN), которая обновляется почти каждый день… выход один — monkey patching!
В любом файле (желательно в моделях) пишем слудующее:

from django.contrib.auth.models import User

GENDER_CHOICES = (
        ('M', 'Male'),
        ('F', 'Female'),
)
User.add_to_class('gender', models.CharField(max_length=1, choices=GENDER_CHOICES))
#Вцелом, этого уже достаточно, но для самой админки django добавим следующее:
User._meta.admin.fields += (
('Additional', {'fields': ('gender',)}),
)
User._meta.admin.list_display = User._meta.admin.list_display + ('gender', )

Все, отныне, никаких бесполых пользователей!Точно так же можно расширять функционал встроенного в django модуля FlatPages, представляющего из себя простейшую CMS-систему и многое-многое другое.

Меры предосторожности

Не стоит забывать, что monkey patching — это именно хак, а не нормальное поведение программы и применять его стоит только в тех случаях, когда иначе ситуацию решить нельзя. Будьте уверены, если такой патч, в будущем, вызовет ошибки в коде — наверняка, после многочасовых поисков причины, кто-нибудь захочет вас больно побить. Избежать этого довольно просто: всякий раз, когда применяете monkey patching, заботьтесь о том, чтобы этот код был покрыт автоматическими тестами.

Несколько недель назад по рекомендации Андрея Ясинецкого попробовал перейти с del.icio.us на memori.ru… и хорошо так попробовал, желания вернуться назад не возникло.

Если вркатце — del.icio.us уже давно меня раздражал своим убогим дизайном и бездумным отношением к эргономике. В свое время, думал перейти на BlueDot, но через пару дней сбежал оттуда и решил, что такое сырое говно как блудот обязано умереть… и знаете что? оно таки умерло!
Чем же memori.ru оказался настолько лучше старого доброго делишеза?

1. Приятный дизайн
2. Сохраняются favicon’ы ссылок
3. Вместо длинного списка теги организованы в облако
4. Есть разграничения доступа к закладкам, а не просто public/private как в делишезе
5. Удобно реализована групповая работа с закладками
6. Нагляднее реализованы «родственные теги»
7. Возможна сортировка списка тегов по разным параметрам
8. Грузится быстрее (у меня во всяком случае)

Конечно же, есть у сервиса и минусы, их я нашел всего два:

1. Присутствует баннерная реклама.
2. Сервис менее распространен чем del.icio.us, соответственно, реже можно получить подсказки по тегам к определенному адресу

Memori умеет импортировать закладки из del.icio.us и тоже имеет свой плагин для firefox, хотя, и без плагина сервисом пользоваться вполне удобно. В итоге, memori — это именно то, чем стал бы del.icio.us, если бы уделял больше внимания дизайну и удобству использования. Всем, кто следил за моими закладками через RSS, решительно советую удалить старый поток и начать следить за закладками через мой RSS-канал в memori.

Сайт открыт. Здесь будут публиковаться различные заметки на тему интернета, социальных веб-проектов, современных технологий и программирования, управления проектам и работы с людьми, самосовершенствования, в конце концов. Упор делается на собственные материалы, в том числе аналитические, перепечатка «горячих» новостей с других ресурсов определенно не планируется.

С увеличением количества материалов будет меняться и сам сайт, появятся новые разделы, функции, элементы интерфейса.