Ne v kontakte Asocial programmer's blog

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

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

Покойся с миром, Деннис Ритчи

Feature image

8-го октября, на 71-м году жизни скончался Деннис Ритчи (Dennis Ritchie). Об этом стало известно из сообщения его коллеги Роба Пайка.

Дэннис Ритчи — один из величайших инженеров современности, создатель вездесущего языка C и один из авторов ОС UNIX. Сложно переоценить влияние этого человека на современную IT-индустрию: его идеи легли в основу подавляющего большинства современных систем, и почти все повсеметсно использованные ОС написаны на языке Си.

Но его труды не ограничиваются этими двумя вещами. Он занимался развитием операционных систем Plan 9 и Inferno, развивавших концепции UNIX и устранявших его недостатки, а так же языком Limbo. Он занимался общей теорией создания ОС и писал книги, одна из которых, «Язык программирования C» стала хрестоматийной.

Покойся с Миром, Дэннис Ритчи. Человечество благодарно тебе за твои труды.

Собираем домашний сервер. Часть 1, железная.

Feature image

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

На всякий случай напомню ключевые требования, которые предъявлялись к серверу:

  • Дешевизна железа (бюджет был установлен 5000 руб. ± 1000 руб.).
  • Возможность постепенного наращивания мощности в максимально широких рамках.
  • При всем при том как можно менее шумный.

Нетрудно заметить, что первые два пункта слегка конфликтуют с последним. Впрочем, как оказалось, не фатально. Устроенная ревизия закромов показала, что у меня уже есть в наличии две сетевых карты на 100 Мбит с интерфейсом PCI и жесткий диск Seagate на 160 Гб, которые решено было использовать. Для основного хранилища будет использован внешний жесткий диск от WD, работающий в текущем сервере. Исходя из этих требований, были выдвинуты уже более технические требования к железу:

  • Процессор на сокете LGA 1155 (как-то сложилось, что в интеловских процессорах я ориентируюсь лучше, поэтому AMD был отброшен из рассмотрения). Это даст возможность апгрейда процессора аж до Core i7, буде оно потребуется.
  • Память DDR3. Желательно с возможностью апгрейда до 8 или 16 Гб.
  • Минимум 2 слота PCI (для сетевых карт) + гигабитный интерфейс Ethernet на самой материнке, который будет смотреть в локальную сеть.
  • Дополнительно слот PCI или PCI-E, чтобы в будущем добавить Wi-Fi адаптер, желательно с поддержкой стандарта 802.11n.
  • SATAIII-интерфейсы.

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

Учитывая, что у меня уже были две сетевых карты и жесткий диск для системы, мне удалось уложиться в 6000 с вот таким набором железа:

Суммарно — 5746 руб.

Оказалось, что найти материнскую плату, полностью отвечающую пожеланиям, нелегко: из-за “свежести” сокета цены на материнки несколько задраны, и платы форм-фактора ATX, на которые реально упихнуть 4 слота для памяти и 4 слота PCI + пару PCI-E, стоят довольно дорого и позиционируются как профессиональные-производительные. Поэтому пришлось ограничиться платой mATX всего с двумя слотами PCI, одним PCI-E и парой слотов памяти.

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

На десерт выложу несколько фотографий процесса сборки.

Запчасти перед сборкой:

100_4004.JPG_smaller.jpg100_4006.JPG_smaller.jpg100_4007.JPG_smaller.jpg100_4010.JPG_smaller.jpg

Установленная мать:

100_4014.JPG_smaller.jpg

Ну и после сборки:

100_4015.JPG_smaller.jpg

Из небольших “твиков” при сборке стоит упомянуть, пожалуй, только одну тонкость. На системнике присутствуют индикаторы как для жесткого диска, так и для питания, при том индикатор питания довольно яркий. Но чтобы этот индикатор не мешал по ночам, имеет смысл его просто отключить; включенность легко определить по шуму. Либо, если сервер не планируется использовать в качестве файлопомойки, можно поменять местами индикаторы жесткого диска и питания. Тогда яркий индикатор будет загораться очень редко. Но если использовать машину и для файлохранилища, то такого лучше не делать, ибо часто моргающий яркий огонек будет раздражать неизмеримо сильнее, чем горящий постоянно.

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

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

Feature image

Этим постом я начинаю серию, в которой расскажу о процессе сборки, настройки и эксплуатации домашнего сервера.

Начать же я хочу с изложения предпосылок, которые обусловили выбор железа, софта и настроек, о которых будет рассказано далее.

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

В этом отношении и моя семья не стала исключением. В качестве роутера у нас трудился ASUS WL-520GU с прошивкой от Олега. ну а семейной файлопомойкой работал допотопный ноутбук Toshiba Satellite Pro 4600 с подключеным внешним USB HDD. До поры до времени эта конструкция всех устраивала, хотя скорость работы роутера под нагрузкой былаа не ахти какой, а старенький ноутбук делал файлопомойку не слишком шустрой. Стояло все это дело под столом:

100_4016.JPG_smaller.jpg

Но в один прекрасный момент HomeNet устроил нам эпичный факап с недельным отсутствием интернета, а РосТелеком как раз в это время заменил у нас телефонную линию на оптическую G-Pon, предложив заодно более дешевый и быстрый интернет. Подключение к HomeNet мы решили сохранить на всякий случай, перейдя на младший тариф.

Одновременно с этим меня начала неколько раздражать запутанность нашей домашней сети, в которой теперь болтались роутер, G-Pon модем (это 2 NAT'a на пути во внешку), файлопомойка, все остальные девайсы и два провода от разных провайдеров, которые надо было по мере необходимости перетыкать руками. Безобразие? Безобразие.

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

  1. Максимально тихий.
  2. Недорогой, верхняя планка бюджета — 6000 рублей на все.
  3. Возможность постепенного апгрейда железа в перспективе.

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