Ne v kontakte Asocial programmer's blog

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

И так, технических причин, побудивших меня отказаться от Drupal, которым я пользовался последние 5 лет, было три:

1. Хлопотность обслуживания. Помимо регулярных патчей для самого движка едва ли не каждую неделю выходили обновления для парочки из трех десятков используемых модулей. А автообновления в Drupal 6 предусмотрено не было.
2. Избыточная сложность. Все-таки Drupal предназначен для создания куда более сложных и развесистых сайтов, чем личный блог. Поэтому многие его возможности в лучшем случае играли роль мертвого груза, а в худшем — требовали совершать лишние клики, действия и шанс как-нибудь накосячить.
3. Тяжеловесность. За функционал надо платить, и плата выражается в потребляемой памяти, скорости работы и занимаемом дисковом пространстве. В последний год Drupal завел дурную привычку отжирать до 150 Мб в БД под какие-то свои кэши. И это при том, что объем всего контента этого блога на данный меньше 30 Мб, включая картинки, приаттаченные файлы и так далее. На мой взгляд, это как-то совсем неприлично для скромного блога.

Неудивительно, что, выбирая замену, я ударился в другую крайность, и рассматривал исключительно генераторы статических сайтов.

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

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

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

Одним из первых таких генераторов стал Jekyll, за которым последовала масса клонов на самых разных языках и с разной специализацией. Вот несколько из них, наиболее известных: Octopress (ruby), Pelican (python), Second Crack (php), Blacksmith (node.js), Nikola (python), Hyde (опять python).

Среди всего этого многообразия я выбрал Acrylamid по трем причинам. Во-первых, он изначально ориентирован на блоги. Во-вторых, из коробки он умеет очень многое из того, что мне было нужно, а значит, не требовал мучительного поиска плагинов на каждый чих. В-третьих, написан он на python, который я знаю гораздо лучше ruby или node.js.

Вот краткий список того, что он умеет:

• markdown,
• живая перекомпиляция сайта при редактировании и локальный предпросмотр,
• перекомпиляция только изменившихся страниц,
• типографика и формулы,
• постраничный вывод списка постов,
• многоязычные посты,
• компиляция LESS,
• интеграция с Disqus
• и много другого полезного.

И самая важная фитча — «живой» разработчик, который активно развивает движок и охотно принимает pull request’ы. Выбор оказался удачным — для удовлетворения всех моих капризов мне хватило нескольких модификаций, которые были оперативно приняты в апстрим.

Однако, техническая разница между acrylamid и Drupal настолько велика, что перенос контента казался задачей очень нетривиальной. Само собой, терять посты и комментарии за 7 лет я был неготов. В качестве дополнительного усложнения задачи служило желание не накосячить в глазах поисковиков, так как смена движка вела к почти неизбежной смене структуры адресов страниц. В следующей заметке я как раз к этим вопросам и обращусь :-)

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

• Во-первых, реальный мир требовал невероятное количество моего внимания, в моей жизни поменялось очень многое: я сменил работу, переехал, многое переосмыслил, слетал в Лондон на научную конференцию, и еще многое другое.
• Во-вторых, серьезно-статейный формат, который сложился в начале 2012 года требовал слишком много времени и усилий на написание новых постов, их у меня просто не оставалось. В то же время, Twitter успешно взял на себя роль носителя мелких сиюминутных мыслей.
• В-третьих, количество технических долгов перед блогом у меня накопилось немыслимое — движок давно не обновлялся, часть модулей глючила и, что самое критичное — отломался модуль редактора, добавив дискомфорта процессу написания постов.

В результате, примерно с год назад была затеяна история по освежению блога, включая смену движка и дизайна блога. И, как водится, затянулась на гораздо больший срок, чем я рассчитывал. Более того, в какой-то момент она двинулась в совершенно ином направлении, чем я планировал. Вместо того, чтобы писать свой собственный движок, я (слава богу!) решил обратиться к готовому решению но, в противовес тяжеловесному Drupal, максимально легкому и простому. Выбор пал на acrylamid — статический блоговый движок, написанный на Питоне. Перед ним я рассматривал более популярный Jekyll и его дочку Octopress, но натянутые отношения с Ruby и из рук вон плохое поведение rvm в Ubuntu тех времен заставили искать альтернативы.

С дизайном все тоже было все не очень просто. Мне изрядно поднадоела холодно-синяя гамма, царившая у меня на сайте уже лет пять, но долгие искания так ни к чему хорошему и не привели. Поэтому я решил пойти другим путем: сохранив основной стиль и гамму, освежить и усовершенствовать дизайн, попутно переверстав его на Twitter Bootstrap. Выход третьей версии застал меня врасплох в самом конце работы, но, взвесив все «за» и «против», я решил переверстать шаблон на новой версии во имя Mobile First и светлого будущего. Сейчас мне кажется, что это был верный шаг — результат мне понравился.

Третье изменение — блог наконец-то сменил домен на nevkontakte.com. Это должно было произойти еще года полтора назад, но произошло лишь недавно. Старый домен nevkontakte.org.ru я буду поддерживать еще неопределенный срок, но он будет лишь редиректом.

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

Надеюсь, те немногочисленные подписчики, что еще остались у меня не будут разочарованы.

Два с половиной года назад я представил два скрипта: Google Cache Dumper и Bing Cache Dumper. Как нетрудно догадать по названию, их задача состояла в вытаскивании страниц заданного сайта из кэша соответствующего поисковика.

Оба скрипта я поставил на продажу по цене в $2 и $1 соответственно, и до сих пор их поддерживал. В качестве площадки для продаж по принципу наименьшего сопротивления я выбрал сервис Digiseller. Могу сказать, что на протяжении долгого времени меня всё более чем устраивало: скрипты потихоньку продавались, мне капала копеечка на хостинг, людям — польза в виде возможности хотя бы отчасти восстановить потерянный сайт.

Однако, в минувшем году Digiseller преподнёс один за другим два неприятных сюрприза. Сначала он потребовал персональный аттестат WebMoney для продажи через магазин на своем домене. Большой нужды у меня в этом сертификате не было, руки до него вечно не доходили, так что я пошел по пути наименьшего сопротивления: перенес продажи на их площадку-партнера plati.ru. Но и там был через некоторое время заблокирован без объяснения причин, о чем вчера узнал из комментов. Никаких уведомлений на почту, ничего.

Поразмыслив, я понял, что самым честным решением будет попросту открыть исходники этих скриптов, чему и посвящен этот пост.

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

1. Google Cache Dumper (скачать последнюю версию).
2. Bing Cache Dumper (скачать последнюю версию).

P.S. Если вы подумали, что в качестве картинки к посту я разместил задницу, то это вовсе не так. Это не задница, а стилизованная буква W, официальный логотип лицензии WTFPL. Сравните с ©.

Сегодня вечером пришел нежданчик от Last.fm:

Last.fm вносит ряд изменений в радио, которое ранее было доступно во всем мире. Мы тщательно обдумали эти изменения, и эти изменения не случайны: они были приняты в ответ на на ряд факторов, в разной степени влияющих на наш бизнес в разных странах.

До сегодняшнего дня радио было функцией только для подписчиков. Однако начиная с 15 Янв 2013 мы вынуждены прекратить предоставление потокового радио в твоей стране в связи с лицензионными ограничениями. Это значит, что ты больше не сможешь слушать радио Last.fm.

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

Подписчики по-прежнему смогут пользоваться своими преимуществами: сайтом без рекламы, доступом к демонстрациям в разделе Last.fm Playground и другие возможностями, которые будут добавлены в дальнейшем.

Однако ты вправе отказаться от подписки. В этом случае тебе следует ознакомиться с соответствующим разделом FAQ. Там ты найдешь информацию об отмене. Если ты заранее оплатил(а) подписку сроком более чем на 30 дней, ты можешь запросить возмещение.

Мы продолжим отслеживать состояние рынка в разных странах и надеемся расширить нашу аудиторию в будущем, когда это будет целесообразно.

Прочитай наше объявление. Там ты найдешь более подробную информацию об изменениях Last.fm, новости и сведения о других музыкальных службах, совместимых с Last.fm.

Будем рады пользователям, которые решат остаться с нами.

Спасибо, Команда Last.fm

Для тех, кому лень было читать, краткое резюме: в России даже платные подписчики теперь не смогут слушать радио. Но пусть они не унывают: у них по-прежнему останется сайт без рекламы, доступ к красивым графикам на playground и стильный значок VIP в профиле.

Для тех, кому читать не лень, вот то же самое, но подробнее в блоге lasf.fm.

Так как для меня в last.fm ценность представляют только подборка исполнителей по вкусу и стримминг радио, то после закрытия радио смысл в платной подписке пропадает.

Вопрос о том, куда мигрировать сейчас активно обсуждается на Хабре, а я скорее всего перейду на Яндекс.Музыку. Ещё есть libre.fm, но интерфейс и выбор на нём странноват. Кстати, и на YouTube музыку тоже можно послушать, хотя и не очень удобно.

Хочу предложить вашему вниманию историю, которая приснилась мне не далее как сегодня под утро. Проснувшись, я первым делом подумал: “ну и к чему вообще мне это приснилось?..”, но потом понял, что этот нехитрый сюжет имеет прямое отношение к нашей отрасли. Строго говоря, это применимо к молодым специалистам практически в любой области, но именно в программировании это цветёт пышным цветом и даёт сочные плоды :-) Сон получился на удивление связный, так что привожу его почти без литературной правки.

История приключилась с двумя мальчишками-приятелями, будем называть их Сашей и Петей. День был солнечный, тёплый — пожалуй, идеальный день с точки зрения шестиклассника на каникулах. Поэтому, когда Петя зашёл за Сашей и позвал его гулять, Саша немедля согласился, задержавшись лишь чтобы завязать шнурки кроссовок. Родители были на работе, а потому предполагалось, что они не против прогулки, по крайней мере, если они о ней не узнают.

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

В этот раз, спускаясь по лестнице вниз и обсуждая с Петей, кого бы ещё позвать, чтобы поиграть в мяч, Саша заметил, что на стене у одного из лестничных пролётов краска некрасиво облупилась и раскрошилась (наверное, кто-то тащил по лестнице что-то тяжёлое и задел стену углом). В принципе, мелочь, но Саше стало как-то обидно, что их подъезд теперь не такой аккуратный, как раньше.

— Петь, смотри, какой-то дурак нам стену покорябал! Кажется, у нас дома в коридоре как раз стояла банка с краской именно такого цвета! Ты спускайся и зови пацанов в футбол, а я сейчас подкрашу и к вам!

— А ты умеешь вообще красить? А то влетит тебе от старших, если криво намажешь, или цвет не тот.

— Да не, меня папка учил, мы в ванной стену подкрашивали. И это точно та самая краска, сто пудов.

— Ладно, но если что, я не при чём. И ты надолго не зависай, мы же гулять пошли.

— Да я вообще мигом, тут такое маленькое место, на два взмаха кисти.

Саша побежал обратно в квартиру, а Петя пошёл вниз, звать остальных друзей гулять. Через полчаса Петя вместе с тремя другими приятелями и мячом подходили к Сашиному подъезду. По подьъезда оставалось метров десять, когда с крыши с грохотом рухнула какая-то железяка. Следом за ней показался виновато улыбающийся Саша:

— Сори, пацаны, эта железяка тут мешала! Я её приладил удобнее, но она тут как поедет, да как жахнет вниз!

— А ты вообще какого фига на крышу-то полез?!

— Да я закрасил ту дырку, а пока красил, понял, что это не долбанули, а с крыши вода протекла во время дождя, вот краска и обвалилась. Я подумал, что лучше уж починить крышу, пока и нашу квартиру не затопило по самые окна!

— Не гони, не затопит! Вы же не на верхнем этаже живёте! Да и не умеешь ты крыши чинить!

— Ну мало ли, в подъезде вот затопило, аж краска полезла. И не на последнем этаже! И вообще, я тут гамал в симулятор строителя, супер-новый, и знаю, как делать крыши!

— Мы тебя сто лет ждать будем?

— Не, я мигом! Я уже всё разобрал, осталось только обратно сложить, только правильно. Идите на поле, я вас догоню!

Мальчишки пошли на поле, но Саша их не догнал. Не пришёл он и через час, так что Петя забеспокоился, не грохнулся ли он с крыши. Крикнув остальным никуда пока не уходить, он побежал к Сашиному дому. Подойдя к дому, он обнаружил, что дом как будто бы стал чуток ниже. И действительно, чердака как ни бывало. Зато наверху вовсю кто-то грохотал, не иначе как Саша.

— Санёк! Са-а-анё-ё-ёк! Ну где ты там?! Ты чего творишь?!

— Чо?! Щас, один сек! Да я тут, понимаешь, переделывал крышу, а часть стены чердака как рухнет! Вон, внизу валяется, глянь! В общем, я посмотрел, а тут кладка неправильная! Мне брат рассказывал, как они с другом помогали его папке дом на даче строить, и как кирпичи надо класть! А тут всё не так! Ну я решил, что раз уж я крышу разобрал, надо и стены переделать по уму. А то когда ещё кто-нибудь возьмётся! В общем, я через пол часа буду, не сваливайте!

— Да ну тебя! — ответил Петя и вернулся на стадион.

Естественно, Саша не пришёл и через час. Более того, не пришёл он и на следующий день, и даже через неделю, и вот почему. Всё дело в том, что когда в шестом часу его родители приехали с работы, они застали на месте дома котлован и Сашу, увлечённо ругающего строителей-недоумков, которые даже котлован правильно вырыть не могут, потому что чуть тронешь фундамент, и он тут же разваливается. И естественно, “старшие” не оценили Сашины старания по достоинству, в наказание запретив ему выходить гулять следующие три недели, хотя он ещё чуть-чуть и построил бы самый правильный и надёжный дом на свете. Вот, чесслово, если бы они в пробке задержались, он бы уже успел!

Мораль сей басни… думаю, она не нуждается в особых комментариях. Молодым программистам очень хочется делать всё “по науке”, как они читали в умных книгах, но в жизни, когда дело касается реальных продуктов, попытки внедрить все правильные подходы как правило превращают неплохой, в сущности, продукт в хаос. И даже маленький фикс может положить ему начало.**В то же время, задумывался ли Саша, что это наверняка далеко не первая царапина, возникшая в подъезде, и аккуратно закрашенная кем-то, благодаря кому Сашин подъезд выглядел красиво и опрятно? И если у его отца была банка краски в точности, как стена в подъезде, то, может быть это он и следил за порядком, и стоило хотя бы посоветоваться с ним? В прочим, я начинаю писать азбучные истины, а это не к добру, так что я закруглюсь :-)**P.S. Признаюсь, время от времени, я еле успеваю перехватить себя за руку, чтобы не разобрать очередной дом до основания во имя правильной архитектуры.

Поводом к этому посту стала одна дискуссия об хороших и плохих сторонах открытого софта, в которой мне довелось участвовать. Я являюсь давнишним пользователем Linux, а потому поневоле постоянно имею дело с большим количеством open-source проектов. Более того, так повелось, что большинство инструментов и фреймворков для веб-разработки, которой я занимаюсь, так же является открытым. Поэтому в ходе того обсуждения у меня сформулировалось мнение, заслуживющее отдельного упорядоченного изложения.

На мой взгляд, современный open source радикально отличается от того, каким он был ещё лет семь назад, и состоит он из четырёх мало пересекающихся миров, представители которых различаются буквально во всём.

Мир первый: большой Open Source.

Сюда относятся крупнейшие открытые проекты, над которыми работают сотни людей. Именно о них упоминают в первую очередь, когда хотят проиллюстрировать важную роль открытого ПО в IT-индустрии: ядро Linux, Apache, FreeBSD, KDE, GNOME, Mozilla Firefox. Следом за ними идут продукты менее именитые, но от того не менее важные: Drupal, phpBB, OpenJDK, Eclipse, целая плеяда языков программирования и многие другие.

У этих проектов одна общая черта: за ними стоят различные коммерческие организации, которым открытое ПО служит основой их бизнеса. Для Linux это в первую очередь RedHat, в Apache заинтересована практически вся хостинговая индустрия, FreeBSD прочно прописался на высоконагруженных серверах, в KDE и GNOME заинтересованны множество (полу-)коммерческих дистрибутивов, спонсирующих их разработку, Mozilla Foundation имеет спонсорские соглашения со многими интернет-компаниями, в числе которых Google. Факт тот, что именно наличие заинтересованного бизнеса позволяет открытому проекту перейти в клан тяжеловесов, получая инвестиции в виде долларов или человеко-часов.

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

Мир второй: клубы по интересам.

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

Работа над ними ведётся потому, что это приятно и интересно самим разработчикам, и как правило вокруг таких проектов собирается достаточно тёплое и заинтересованное сообщество, в которое несложно влиться, если только ваши интересы совпадают с интересами сообщества. Часто сообщество тоже участвует в разработке, особенно если проект живёт на GitHub, но каждый отдельно взятый человек вносит вклад сравнительно небольшой и эпизодический.

Мне очень симпатичны такие сообщества, и, если в большом Open Source — сила, то здесь — гибкость и свежая кровь. Именно поэтому проекты из этой сферы может ждать самое разнообразное будущее: они могут перейти в лигу тяжеловесов, получив поддержку коммерческих структур и вырастив большое сообщество, могут тихо увянуть, если разработчики потеряют интерес и некому будет подхватить падающее знамя, а могут на многие годы остаться в этом состоянии, не спеша развиваясь на радость фанатам.

Мир третий: соло-проекты.

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

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

На мой взгляд, сейчас таких проектов количественно больше всего, и это легко проиллюстрировать, порывшись на том же гитхабе. Будущее у большинства из них не самое радужное — с угасанием интереса основателя, он наверняка будет заброшен, а сколько продлится интерес, предсказать сложно. Шанс, что проект всё же перехватят, невелик так как вокруг них редко бывает активное сообщество. Признаюсь, у меня самого есть несколько таких вот заброшенных проектов, за что мне иногда бывает стыдно, но едва ли у кого-то нет таких “скелетов в шкафу”.

Мир четвёртый: сделал для себя, поделился с остальными.

Такие проекты возникают по принципу: “Возникла проблема, я её решил, вдруг кому-то пригодится?”

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

Если к первому названному миру я отношусь с уважением, ко второму — с восхищением, а к третьему — с пониманием, то к этому, четвёртому, я испытываю самые противоречивые чувства. Тут можно найти всё, что угодно, но найти и заставить работать настолько сложно, что проще самому написать. А от сюда возникает огромное количество велосипедов, что не облегчает поиск в следующий раз :-) И если уж говорить про гитхаб, то у них есть отдельный подсервис специально для таких вот проектов: GitHub:Gist.

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

Каждому своё

Каждый из миров, о котором я говорил, имеет свои достоинства и недостатки для разработчиков и конечных пользователей. Где-то ценою за надёжность становится гибкость в развитии, где-то разработчики готовы пожертвовать стабильностью во имя пребывания на острие технологий. Часто люди сталкиваются лишь с одним из ликов открытого программного обеспечения и пугаются, думая что есть только оно, и совершенно напрасно. Многоликость open source — это его сила, надо лишь уметь ею пользоваться :-)

Три раза пытался начать этот пост, и три раза получалась полная ерунда — предыдущий пост был написан пол года назад, и, похоже, навык написания постов на человеческом языке я слегка растерял. Почему я упомянул про “человеческий” язык? Да потому, что за эти пол года мне пришлось написать вагон и маленькую тележку текста на академическом жаргоне, но обо всём по порядку.

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

Самым главным квестом была защита диплома — отныне я дипломированный бакалавр информационных технологий. Осознавать это приятно, но, честно говоря, наличие формального диплома мало что изменило. Быть может я окажусь в меньшинстве, но от наличия корочек пользы куда меньше, чем от обучения, им предшествовавшего. Полагаю, мне очень повезло с универом, так как большинство преподавателей действительно знали, о чём говорят, и умели это  объяснить. И хотя в повседневной работе я не пользуюсь большей частью высоких наук, которые мне довелось познать, расширению сознания они весьма поспособствовали. А вот умение абстрактно мыслить в программировании — это наше всё, и математика даёт прекрасный шанс этому научиться.

Отдельную пару слов посвящу своему дипломному исследованию, посвящённому гомоморфной криптографии. Особенность данного вида шифрования в том, что над зашифрованными данными можно выполнять математические операции таким образом, что после расшифрования результат совпадёт с результатом тех же вычислений над незашифрованными данными. Это, в свою очередь, ключ к безопасным облачным вычислениям и базам данных — данные можно хранить и всячески обрабатывать, но без ключа враг не сможет эти данные прочитать, даже если у него есть доступ к серверам. Если будет время, я, пожалуй, напишу парочку постов об этом с изложение всей этой науки “на пальцах”.

В конце мая я так же делал доклад на эту тему на Positive Hack Days в секции Young School. Кажется там даже была выложена запись презентации, но я за это не поручусь — не проверял. Впечатления от самой конференции остались самые радужные, тем более, что это мой первый опыт участия в конференциях такого уровня.

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

Последующие два осенних месяца пролетели практически моментально, но писать тут не о чем — сплошная рутина, которая, наконец, стала принимать регулярный характер, и стало легче выкраивать время на дела типа блога :-)

Вступление от переводчика. Я довольно редко по доброй воле берусь за переводы чужих статей, но в этот раз я всё же хочу поделиться с вами небольшой заметкой, написанной Эриком Венделином “10 Things you didn’t know about Firebug”. И хотя я довольно давно пользуюсь FireBug’ом, до прочтения этой заметки я знал лишь о трёх из упомянутых “фитч”.

Мне доводилось работать со многими инструментами разработки, но Firebug меня просто поразил. Firebug - это расширение для Firefox, предназначенное для отладки и оптимизации CSS, JavaScript, HTML… и многого другого!

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

1. Вы можете отслеживать время загрузки ваших скриптов (прим. переводчика: и не только скриптов) во вкладке “Net”. Бонус: FireBug выделяет запросы, которые обслуживаются из локального кэша светло-серым цветом, что полезно при оптимизации времени загрузки.
2. Правый клик на метке брекпойнта позволяет задать условие останова.
3. Вывод отладочной информации в консоль с помощью console.log чрезвычайно удобен, но знали ли вы, что эти записи можно группировать с помощью методов console.group(“Group Name”) и console.groupEnd()?
4. Используйте console.profile() и console.profileEnd() для замера времени исполнения каждого вызова функции. А ещё можно просто воспользоваться профайлером.
5. Если вы во вкладке CSS наведёте курсор на код цвета, то FireBug покажет вам записку этого цвета.
6. Вы можете не только в реальном времени наблюдать изменения структуры HTML вашей страницы, но и самостоятельно менять всё, что угодно.
7. Если вы используете FireBug на экране с большим разрешением, и надписи в его интерфейсе для вас слишком мелкие, вы можете увеличить размер шрифта, кликнув по картинке с тараканом и выбрав “Размер текста” → “Увеличить размер текста”.
8. Вы можете использовать команду debugger; в вашем JavaScript-коде, чтобы приостановить его исполнение и вызвать панель FireBug.
9. Вы можете логгировать все вызовы какой-либо функции просто сделав правый клик на её имени и выбрав “логгировать вызовы myfunction”.
10. И наконец… вы можете использовать FireBug в IE, Opera, Safari и Chrome, скачав FireBug Lite! Правда, в этом режиме функциональность будет несколько ограничена.

Если вы всё ещё не хотите начать использовать FireBug, то вы, наверное, потратили кучу денег на что-то, вероятно, не сильно лучше.

Пост вышел многабукаф, поэтому ленивые могут пропускать части, помеченные как иллюстративные.

При разработке хоть сколь-нибудь сложных систем среди прочих всегда возникает проблема обновлений, а именно — миграции данных со старой версии в новую. И все бы ничего, но структуры данных имеют свойство меняться от версии к версии. Для веб-приложений это в первую очередь касается схемы БД, но сюда же относится изменение формата конфига, удаление/добавление отдельных параметров настроек, пересборка разных кэшей, индексов и так далее.

Типичный подход к решению этой проблемы выглядит так:

1. Делается публичный релиз продукта.
2. Начинается работа над следующим релизом, в ходе которой пишется и обновляется конвертор с предыдущего релиза в будущий. Таким образом, текущий релиз всегда можно обновить до dev-ветки.
3. Публикуется новый релиз, который способен спокойно обновиться с предыдущего, пользователи счастливы.

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

Чтобы осчастливить разработчиков нужно изобрести механизм обновления с любого билда на любой более новый. Такой механизм, если я не ошибаюсь, впервые получил широкое распространение во фреймворке Ruby on Rails под названием “Database Migrations”, а теперь пробрался и во многие другие среды, например в мой любимый PHP-фреймворк Yii. И так, что же нам предлагают миграции?

Ключевым элементом в этой схеме является “миграция” — как правило небольшой скрипт, производящий одну более-менее атомарную операцию над файлами данных программы. Каждая миграция должна иметь свой порядковый номер, при чем более новые миграции должны иметь большие номера, чтобы можно было выстроить и запускать их в порядке появления. В качестве такого номера проще всего использовать UNIX timestamp момента создания миграции, чтобы понизить шансы появления миграций с одинаковыми номерами у разных разработчиков.

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

Запуском миграций управляет отдельная сущность, будем называть её менеджером миграций. Во-первых, он хранит список миграций, которые уже были применены, в момент начальной установки все имеющиеся миграции помечаются как установленные. Во-вторых, при наступлении какого-либо события (например, после установки обновления), этот менеджер получает список доступных приложению миграций и сравнивает его со списком уже установленных. Если найдутся такие миграции, которые не были установлены, менеджер миграций запускает их в хронологическом порядке и добавляет в список установленных.

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

Чтобы немного облегчить понимание изложенного, сделаю лирическое отступление о том, как это работает. Пусть над проектом трудятся три программиста — Алексей, Борис и Вадим, и пусть они пишут CMS, ядро которой уже написано и опубликовано как релиз 1.0 перед новым годом, а теперь они заняты добавлением разных фитч.

1. В понедельник, с похмелья, Алексей решил написать систему оценки комментариев. Для этого он добавил в таблицу cms_comments поле comment_ratinnnng и был очень доволен, оформив эту операцию в виде миграции, получившей номер 10-01_10:23:14 (10 января, 10 часов, 23 минуты, 14 секунд). Вместе с логикой голосования он ее закоммитил и пошёл домой.
2. В тот же понедельник непьющий Борис успел написать модуль обратной связи, добавив таблицу cms_feedback (в виде миграции с номером 10-01_09:43:55), а так же усовершенствовал профиль пользователя, привнеся в него возможность указать свой логин в skype. Для этого он создал миграцию за номером 10-01_15:20:31.
3. Вадим же в понедельник вообще не пришёл, и это полностью на его совести.
4. Во вторник утром Вадим в порыве отваги (или угрызений совести за прогул) решил протестировать то, что они в суматохе писали перед новым годом за час до релиза, и, поставив свежую копию из репозитория, принялся заполнять CMS огромным количеством тестовых данных.
5. На этот раз Алексей был бодр и свеж, и первым делом обновил свою рабочую копию, в которой ему приехали труды Бориса. Залив эту копию на свою тестовую машину, он запустил менеджер миграций, который подхватил обе миграции Бориса, предотвратив ошибки в духе “unknown kolumn user_skype in table cms_users”. Заметим, что миграция Алексея повторно запущена не была — менеджер миграций исполнил её ещё вчера, как только Алексей её написал, и больше её запускать не будет. Вторым делом Андрей достал запасённую банку пива и больше ничем серьёзным не занимался.
6. Борис же заметил, что Алексей вчера опечатался в названии столбца comment_ratinnnng и по доброте душевной поправил ошибку в коде, заодно создав миграцию 11_01-11:05:27, которая исправляла ошибку в базе. А ещё Борис решил, что тексты страниц лучше вынести в отдельную таблицу для улучшения производительности. Сделав это, он написал ещё и миграцию 11_01-21:05:01, которая переносит тексты в новую таблицу и удаляет из старой.
7. А вот в среду миграции спасли Андрея и Бориса от насильственной смерти, поскольку Вадим закончил наполнять тестовыми данными свою копию CMS и перед тем, как начать её всерьёз тестировать, решил подтянуть из репозитория свежие правки, чтобы заодно протестировать и их.

А вот здесь следует проявить серьёзность и разобраться, какая ситуация сложилась у Вадима. У него установлена версия CMS, отличающаяся от релиза 1.0 наличием рейтинга у комментариев, лишним полем в профиле и возможностью обратной связи. К сожалению, в его версии все ещё присутствует опечатка в имени столбца. В среду, когда Вадим извлек свежую версию cms, благодаря механизму миграций, у него были запущены миграции 11_01-11:05:27 и 11_01-21:05:01, и не запущены те, что были добавлены 10 января, так как соответствующие изменения уже были учтены в момент установки копии Вадима. А вот если бы наши друзья использовали скрипт, обновляющий с релиза на релиз, Вадим бы оказался в очень неприятной ситуации: с одной стороны, у него уже готова куча отличных тестовых данных, с другой — чтобы их использовать для тестирования новой версии их нужно либо заново вводить, либо самому писать обновлятор, попутно разбираясь, что и как поменялось.

Резюмируя, у миграций есть следующие плюсы:

• Возможность обновления с любой ревизии на любую.
• Меньше шансов забыть какие-либо изменения, поскольку миграция пишется всегда сразу.
• Проще разобраться в сути отдельной миграции, так как они друг от друга логически независимы.

Однако, у миграций есть и некоторые недостатки, которые иногда играют важную роль:

• Если какое-то изменение в БД было решено отменить, то придётся не удалить ненужную миграцию, а добавить новую, которая будет возвращать все назад. С точки зрения времени выполнения обновления миграции могут оказаться менее эффективными, чем единый скрипт.
• У механизма миграций больше дополнительные накладные расходы на запуск.
• Когда миграций становится много, в них становится трудно ориентироваться, особенное если они лежат все вместе и просто пронумерованы порядковыми номерами, а не датами как в примере выше.

Моё мнение на основе всего вышесказанного — в подавляющем большинстве случаев миграции приносят значительную выгоду проекту и его разработчиком, упрощая как процесс разработки, так и поддержку обновлений, особенно при правильной организации. Единственным случаем, когда миграции могут быть не оптимальны мне представляются системы максимальной доступности, да и то с оговорками. Более того, мне кажется, что следует задуматься и во внедрении этого механизма, даже если вы ведете старый проект с большим наследием эпохи мамонтов — тут даже небольшое облегчение поддержки будет как глоток воздуха утопающему.

Сегодня у меня немного философское настроение, и по такому случаю я хочу поделиться кое-каким своим опытом, связанным с фрилансом. В первую очередь, я, опираясь на свой опыт, попытаюсь описать ещё один способ начала фрилансерской деятельности.

Сам я довольно долго занимался фрилансом, в основном выполняя заказы, связанные с форумным движком phpBB. В прошедшем времени — потому что этот род деятельности мне наскучил, мне стало больше нравиться заниматься длительными и сложными проектами вроде Plesk Mobile или phpBB Constructor. Однако, это не значит, что во фрилансе нет денег или там только нудятина. Наоборот, он прекрасно подойдет тем, кто любит делать много не очень больших, но разнообразных проектов.

И так, если вы желаете заняться фрилансом, вот что я могу вам посоветовать.

0. Специализируйтесь.

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

Кроме того, такая специализация позволит вам обойти стороной крупные фрилансерские биржи, пропитанные духом недоверия, жадности и кидалова, обосновавшись в более приятных тематических сообществах. Разница примерно как между барахолкой и антикварным клубом.

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

1. Бесплатность или открытость. Это избавит вас от покупки лицензий для изучения продукта, а открытый исходный код даст возможность ближе познакомиться с его подноготной.
2. Кастомизируемость. Достаточно очевидный пункт, ведь если в продукте невозможно поменять решительно ничего, то за что вам будут платить? Разве что за установку, но это по-настоящему скучно.
3. Развитое сообщество. Степень развитости сообщества характеризует популярность продукта и, следовательно, наличие потенциальных заказчиков. Масса народу хочет сделать блог на Wordpress, и едва ли вы найдете десяток тех, кто спит и видит сайт на Mosquito CMS, да ещё и готов вам заплатить. Оборотная сторона популярности — повышенная конкуренция, но к этому я ещё вернусь.

В 2005-м году мой выбор пал на phpBB, при том довольно случайно. Мне был интересен движок, интересно его сообщество. О фрилансе я тогда не думал (и даже слова такого не знал :-), но популярность движка и развитость сообщества в будущем обеспечили мне достаточное количество заказов.

1. Работайте на сообщество.

Это особенно актуально на начальном этапе, когда вам нужно стать узнаваемым. Вливайтесь в сообщество, участвуйте в обсуждениях, помогайте, оказывайте поддержку другим членам сообщества бесплатно. Пишите моды, аддоны, расширения и публикуйте их. Предлагайте заказчикам скидки в обмен на право публикации разработанного вами модуля.

Да, это требует много усилий, и это “окупится только когда-нибудь потом”, но если вы хотите работать, а не клянчить копеечные заказы, вам лучше быть известным. Более того, ваш авторитет со временем позволит вам диктовать условия сделки, упростит убеждение заказчика в спорных технических моментах и создаст поток заказов, который будет литься к вам сам по себе. Кроме того, если вы сделали удачный выбор продукта, то вся эта деятельность должна наоборот быть вам приятна. Или же вы не испытываете удовольствия, улучшая нечто нравящееся вам?

Кстати, что касается бесплатной техподдержки. Мне кажется удачной позиция, которая сформировалась в знакомом мне сообществе русского phpBB: техподдержка на форуме является бесплатной (но добровольной для членов сообщества), поскольку публичное решение проблемы идёт на пользу всему сообществу; если хотите техподдержки в индивидуальном порядке — будьте готовы, что вас попросят заплатить. Замечу, что в phpBB-сообществе нередки прецеденты, когда денег не берут: проблема пустяковая, или наоборот её нетривиальность принесла удовольствие самим процессом её решения. Так же бывают и отказы даже в платной поддержке, но они как правило обусловлены грубостью или неадекватностью заказчика — здесь никто никому не обязан заранее.

Если вернуться к моему собственному опыту, то, активно участвуя в жизни сообщества, я со временем попал в команды обоих русских сайтов поддержки phpBB и это практически избавило меня от необходимости конкурировать за заказы и даже искать их самому.

2. Уважайте заказчика.

При чем с самого начала, даже до того, как он вообще предложит вам деньги. Это обеспечит вам взаимное уважение, снизит шанс быть кинутым и поможет уладить проблему, например, небольшого опоздания по срокам. А может и побудит со следующим заказом прийти уже сразу к вам. Опять же, не стесняйтесь помочь бесплатно, если просьба почти не требует от вас услилий.

Стремитесь побудить заказчика вернуться к вам не с помощью грязных трюков типа неподдерживаемого кода, демпинга и шантажа, а качеством работы и адекватностью в общении. Я посчитал — примерно 70% людей, с которыми я работал, делали мне более одного заказа. Работать с постоянным партнёром удобнее и вам, и заказчику, создает доверие. Интересно, что единственным, для кого я ещё время от времени выполняю мелкие работы является мой самый первый заказчик. Представьте себе уровень доверия: я не знаю, сколько он мне заплатит до тех пор, пока я не закончу работу, но ни разу я не был расстроен этой суммой. Мы даже не обсуждаем этот вопрос. Безусловно, тут есть доля везения, мне попался очень порядочный человек, но и я плачу ему тем же, работая на совесть.

Что ещё можно сделать, чтобы заказчик проникся к вам уважением? Например, “на берегу” оговорить, что будет, если вы не справитесь с работой. Заметьте, это не означает, что вы не уверены в своих способностях, это означает, что вы уважаете время и деньги заказчика. В конце концов, вы можете заболеть и проваляться с температурой под 40 пару недель, и на этот случай и вы, и заказчик должны знать, как будет решаться проблема сроков.

Золотой совет: Не жадничайте!

Наконец, если вы по каким-то причинам не берете заказ, дайте совет, к кому ещё можно обратиться. Со временем вы будете неплохо ориентироваться в том, кто из ваших коллег с какими заказами лучше справляется, и можете упростить поиск хорошего исполнителя. Вам ничего не стоит, а потенциальному заказчику приятно. И вашим коллегам тоже, кстати. И не рекомендую браться за посредничество, если вы не ассоциируете себя со словом “менеджер”, то игра в глухой телефон не для вас.

3. Уважайте коллег.

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

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

К сожалению, такое сложно практиковать на фрилансерских биржах, где конкуренция куда как жёстче сталкивает фрилансеров лбами. Там специалисты разного профиля скорее объединяются в команды, чем просто обмениваются клиентами.

Когда я буду большим и сильным…

Со временем к вам придёт своего рода известность среди вашего сообщества и уважение в нем. Что это даст вам как фрилансеру?

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

Во-вторых, вы получите право “капризничать”, выбирая среди доступных заказов те, которые вам интересны, или набивать цену на неинтересные. У меня было некоторое количество заказов, за которые мне по тем или иным принципам не хотелось браться, и я абсолютно честно говорил человеку: этот заказ мне по таким-то причинам не хочется брать, вы можете обратиться вот к этим людям, а если хотите, чтобы его делал именно я, то по только такой-то цене. А цену называл примерно вдвое выше рыночной. Однако здесь не следует перегибать палку, набивая цену на все — потеряете с таким трудом заработанную репутацию, и только.

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

В заключение,…

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

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

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

Я тут недавно купил подписку на last.fm, так что теперь будет много новых песен :-)