Ne v kontakte Asocial programmer's blog

Google Cache Dumper и Bing Cache Dumper — бесплатно!

Feature image

Два с половиной года назад я представил два скрипта: 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. Сравните с ©.

RIP Lastfm.ru, ты был хорошим другом.

Feature image

Сегодня вечером пришел нежданчик от 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 музыку тоже можно послушать, хотя и не очень удобно.

Притча о Junior’е

Feature image

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Четыре лика Open Source

Feature image

Поводом к этому посту стала одна дискуссия об хороших и плохих сторонах открытого софта, в которой мне довелось участвовать. Я являюсь давнишним пользователем 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 — это его сила, надо лишь уметь ею пользоваться :-)

Полгода радиомолчания

Feature image

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

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

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

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

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

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

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

10 фитч в Firebug, о которых вы не знали.

Feature image

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

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

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

Firebug Screenshot

  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, то вы, наверное, потратили кучу денег на что-то, вероятно, не сильно лучше.

Обновления для разработчиков и людей — несерьезно о серьезном.

Feature image

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

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

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

  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 января, так как соответствующие изменения уже были учтены в момент установки копии Вадима. А вот если бы наши друзья использовали скрипт, обновляющий с релиза на релиз, Вадим бы оказался в очень неприятной ситуации: с одной стороны, у него уже готова куча отличных тестовых данных, с другой — чтобы их использовать для тестирования новой версии их нужно либо заново вводить, либо самому писать обновлятор, попутно разбираясь, что и как поменялось.

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

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

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

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

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

Путь во фрилансеры

Feature image

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

Сам я довольно долго занимался фрилансом, в основном выполняя заказы, связанные с форумным движком 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, так что теперь будет много новых песен :-)

Съемка видео о гаджетах — mini how-to.

Feature image

Пользуясь свободным временем на каникулах, я решил проапгрейдить ssd в своем нетбуке Asus Eee PC 901. Стоявшие там изначально SSD (4+12 Gb в моей Linux-версии) давно прославились как редкостные тормоза, да и четырех гигабайт системного раздела под весь необходимый софт мне едва хватало. С другой стороны, этот нетбук можно было трести, ронять (в разумных пределах, конечно ;-) и даже использовать в подпрыгивающей на каждом метре маршрутке без страха убить винчестер. Поэтому я решил заменить один из родных накопителей на устройство побыстрее и пообъемнее.

В результате поисков и сравнений выбор пал на Renice X3 Mini PCI-E 60Gb (50mm), который был приемлем по цене и, что важно, имелся в продаже. В прочем, этот пост не о том, как делалась замена, а о том, как я снимал видео по ней — не найдя в интернете годного руководства, я решил заодно исправить и это упущение. Желающие могут увидеть результат съемки на ютубе.

Главный инструмент съемки — китайская no-name веб-камера со сносным разрешением в два мегапикселя и светодиодной подсветкой, которая, впрочем, не особенно пригодилась. При помощи бумажного скотча, линейки и полки камера была закреплена над столом. Высота была подобрана так, чтобы в кадр как раз помещался нетбук и чуть-чуть пространства вокруг, чтобы детали было видно как можно лучше. Выглядело это вот так:

100_4253.jpg

Чтобы видео не было слишком темным в одних областях и пересвеченным в других, нужно обеспечить равномерную яркость объектов во всем поле зрения камеры. Для этого из четырех листов А4 был склеен (все тем же бумажным скотчем) “задник”:

100_4250.jpg

Если бы нетбук был черным, нужно было бы наоборот делать фон темнее.

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

100_4252.jpg

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

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

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

Могу так же дать пару рекомендаций по самому процессу записи:

  1. Пишите небольшими фрагментами, один фрагмент — одно логическое действие. Каждый фрагмент сразу пересматривайте, чтобы можно было сразу переснять, если он получился неудачно.
  2. Опять же, после каждого логического действия убирайте руки из кадра — проще будет вырезать неудачные куски.
  3. Не трогайте камеру во время записи (такой огрех у меня так же имеет место быть ;-).
  4. Старайтесь не шевелить ноутбук относительно камеры, это тоже облегчит жизнь во время монтажа.

Про то, как я монтировал ролик рассказывать не буду, ничего интересного там не было, хотя времени заняло раза в 4 больше, чем съемка. Зато в процессе я убедился, что Openshot хоть и выглядит простым и удобным, но на деле постоянно падает, а самые простые действия типа стоп-кадра или субтитров там делаются через такую задницу… В общем, годика через три им можно будет пользоваться, а пока — только врагам своим буду его советовать.

Еще раз ссылка на получившееся видео, приятного просмотра :-)

Собираем домашний сервер. Часть 2, софтовая.

Feature image

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

Операционная система

Специфика домашних серверов такова, что это машина, которая делает абсолютно все: сетевая файлопомойка, DNS, DHCP, маршрутизация, торренты, GIT и еще бог весть что, вопреки всем рекомендациям экспертов по безопасности. Я тоже поддался на это искушение, успокоив себя тем, что это во-первых, удобно, во-вторых, дешево и, в-третьих, наружу будет торчать VPN-сервер и больше ничего. Зато изнутри будет виден весь зоопарк сервисов, необходимых для комфортной жизни гика.

Таким образом, выбор ОС делался из соображений “изкоробочной” поддержки всех необходимых сервисов и удобного интерфейса к ним. Безусловно, настроить все это самому можно без особых проблем, но оно мне надо? После того, как настройка софта из фана превращается в производственную необходимость, удобство и скорость управления резко возрастают в цене.

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

Zentyal

Поиск не был долгим. Увидев трехстраничный список роутерных дистрибутивов в википедии, я просто выбрал те названия, которые были мне хоть чуть-чуть знакомы и сосредоточился на них. И очень быстро выяснил, что из них только Zentyal (бывший eBox) удовлетворяет последнему пожеланию, а именно, в его основу легла Ubuntu 10.04, хорошо мне знакомая.

Разработчиики позиционируют свой дистрибутив как Small Business Server, но балогдаря развитой модульной структуре, он прекрасно подходит и для домашнего сервера. Сам по себе дистрибутив является не только бесплантым, но еще и лицензирован под GPLv2. Основной козырь этого дистрибутива - хорошо продуманный веб-интерфейс, покрывающий 95% лично моих нужд. Из коробки в нем нет разве что торрентов, но это не проблема.

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

Немного об установке и настройке

Ставится Zentyal так же как и Ubuntu Server и единственной проблемой оказалось, что не очень понятно, как его инсталлировать в headless режиме. Мне  оказалось проще подключить монитор, чем устраивать сложности с ssh, но не для всех это будет хорошим выходом.

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

Наиболее тонким моментом был процесс плавного переключения домашней сети со старого роутера на новый сервер. Напомню, что до сего момента, в центре нашей домашней сети стоял роутер ASUS WL-520GU (очень хорошая и надежная машинка, кстати) с прошивкой от Олега, он раздавал все остальным интернет через NAT и локальные IP из подсети 192.168.171.0/24. В конце лета к нам к квартиру пришел интернет от РосТелекома и, как более шустрый, вытеснил прежнего провайдера (HomeNet) из WAN порта, оставив его болтаться без дела.

Поэтому на период первичной настройки подключил HomeNet к новому серверу в качестве WAN и настроил LAN на тот же диапазон, что и “боевую” сеть, то есть на 192.168.171.0/24. Процесс настройки сети меня приятно поразил своей простотой и продуманностью — задание параметров сетевых интерфейсов и настройка одного из них как WAN прошла как по нотам. В итоге у меня возникло две параллельных сети с очень похожей топологией, и в процессе настройки я переключал свой ноутбук с WiFi соединения на Ethernet и обратно, чтобы попасть в общую и новую сети соответственно. Сконфигурировав сетевые подключения, я прогулялся по квартире, собрав MAC-адреса всех имеющихся устройств и внес их в настройки DHCP-сервера, не забыв и роутер (это важно, да).

Наконец, я произвел слияние новой и старой сетей при помощи вот таких нехитрых шагов:

  1. Перевел роутер в режим точки доступа (т. е. отключил NAT и все, что с ним связано). В результате WAN-порт функционально уравнялся с другим четырьмя портами роутера.
  2. Отключил DHCP на роутере, поскольку эту функцию теперь возьмет на себя сервер.
  3. Вместо WAN’a от РосТелекома я подключил роутер ко внутреннему сетевому интерфейсу сервера, а РосТелеком воткнул во второй внешний интерфейс сервера.
  4. Ребутнул роутер и перезапустил сеть на всех девайсах.

И, о чудо! Ничего не сломалось, все девайсы получили правильные адреса, включая роутер, и интернет спокойно пошел через HomeNet. Далее я настроил второй внешний интерфейс, который был подключен к РосТелекому, а так же две полезных фитчи: traffic balancing и WAN failover. Первая означает балансировку трафика между двумя внешними каналами, а вторая - оперативное переключение трафика на один канал, если второй вдруг откажет. Это делается тоже на удивление просто, если следовать советам в документации. Именно поэтому я не стану приводить никаких конфигов — не скриншоты же веб-гуя мне вам показывать? :-) Там и так все предельно ясно.

Файлопомойка

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

Виртуальные машины

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

Начну с того, что Zentyal умеет работать с двумя типами виртуальных машин — qemu-kvm и VirtualBox, но при том он не умеет работать с виртуалками разных типов одновременно, а выбором по умолчанию является kvm. Kvm мне показался несколько тормознутым, да и с настройками сетевых интерфейсов в bridged режиме у него было мутно (хоть я в конце концов и разобрался, но это можно честно считать вторым камнем). Недолго думая, я удалил из системы qemu-kvm, поставил VirtualBox и был очень удивлен, когда только что созданная машина отказалась запускаться, а в тексте ошибки было что-то про неизвестный системе тип виртуальной машины hvm. Гугл ничего посоветовать не смог, и мне пришлось заглянуть в сорцы, благо, они открыты. Оказалось, что Zentyal ориентируется не по наличию в системе kvm, а по наличию libvirt, через который он с ним работает, а вот этого в документации уже не было. После удаления libvirt Zentyal замечательно определил наличие VirtualBox’a и даже позволил создать и запустить одну виртуалку :-)

С настройкой bridged режима в vbox все проще некуда — надо лишь потом не забыть настроить DHCP на выдачу вирутальной машине постоянного IP адреса, а вот для kvm пришлось бы один из физических интерфейсов переводить в bidged режим (при этом теряя все привязанные к нему настройки), а потом привязывать виртуальную машину в появившемуся интерфейсу br1.

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

GIT-хостинг

Здесь, я, пожалуй, закончу с диферамбами по Zentyal’у и похвалю еще один продукт. Этим продуктом будет Indefero — система для управления проектами, выполненная в стиле Google Code, но обладающая тремя несомненными преимуществами: open-source, поддержка GIT, SVN и Mercurial в качестве репозитория, и очень легко устанавливающаяся, по крайней мере на Ubuntu, для которой есть ppa с актуальными пакетиками. По приведенной мною ссылке вы найдете исчерпывающую информацию о проекте и его использовании, а я лишь заявлю, что если вам нужна простая, функциональная система, да непременно на своем сервере, и вас не пугает отсутствие дизайна, тогда эта система для вас.

Еще вкусняшки?

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

Ну и, кстати, насчет вкусняшек. Вся эта деятельность не развивалась бы так бурно, если бы не вкусняшки, которыми меня все это время подкармливала жена. И кое-какие рецепты она наверняка опубликует, правда, Солнышко? ;-)