Вступление от переводчика. Я довольно редко по доброй воле берусь за переводы чужих статей, но в этот раз я всё же хочу поделиться с вами небольшой заметкой, написанной Эриком Венделином "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 коммьюнити, но нет-нет, да и напишет кто-нибудь в личку с предложением написать какой-нибудь мод.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Специфика домашних серверов такова, что это машина, которая делает абсолютно все: сетевая файлопомойка, 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, серевого принтера и т. п.), пост и без того гигантский. Если вы дочитали до сюда, ничего не пропуская, я восхищен. Может быть, я расскажу, как я настраивал стриминг видео из сетевого хранилища, но это после того, как донастрою его. Отдельным постом я, наверное, оформлю бенчмарки с сервера, но это тоже чуть позже. Ну а на этот раз достаточно :-)

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