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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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