Архив за February, 2008

На рабочем компьютере у меня стояла 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.

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

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