Хочу перейти на английскую "мову"

Сейчас я живу и работаю в Подмосковье. Практически все мои заказчики функционируют в Москве, куда ехать полтора часа. Но вот не покидает желание романтики. Поясню.
В 2006 сотрудничал я с одним IT-журналом, по заданиям которого бывал в нескольких коротеньких командировках по СНГ и за его пределами. Красота! Жаль только что журнализм это не совсем моё. Собственно тогда окончательно и сформировалась мечта - поработать за границей. Даже не столько ради денег, а вот просто ради обстановки. К примеру, сидишь себе в Праге, пишешь на ноутбуке код и чувствуешь себя счастливым. Или на Багамах, с видом на тёплое море. Даже согласен на месяц кодинга во Львове или в Киеве на крайний случай (конечно в рамках исторических центров).
Поэтому решил продвигать своё корпоративное начало в англоязычной блогосфере. План прост - набираю штук десять постов на тему всяческих подробностей PHP, фреймворков и производительности, затем начинаю продвигать блог по различным блогроллам и аггрегаторам (параллельно не забывая конечно про разработку текущих проектов) и может быть, когда нибудь удастся поработать хотя бы временно за бугром. Собственно сменить обстановку.
Конечно, скажете вы, а что мешает просто взять да поехать на месяц за этот самый бугор и работать там над своими проектами, благо сейчас туристическая поездка, даже на месяц в некоторые страны может быть очень доступной. Купил себе, скажем, ту же Чехию за пару тысяч евро и пиши код из гостиницы в Хостиварже, или прямо в господках где нибудь у подножия Вышеграда или поближе к туристической мекке Градчан и Староместской площади. Но такой вариант, скажу я вам, хорош только для туризма. Тем более что проходили - писали много буков на Средиземноморье и держали суппорт прямо из под коня короля Вацлава на одноимённой площади.
Хочется именно участия в совместном проекте, когда в зарубежье выезжаешь не просто попить пива, а именно работать совместно с коллегами, общаться на другом языке и чувствовать себя гражданином мира. Именно поэтому, хочу приблизиться к англоязычному сообществу. Надеюсь мне будет что сказать.

Универсальность и Красота VS Работающий код

Когда я работал наёмным веб-разработчиком в компании, то старался всегда делать свой код максимально универсальным, красивым и модульным. Доходило до того, что каждый мельчайший объектик системы (я говорю не об экземпляре РНР-класса, а имею ввиду объект с аналитической точки зрения) реализовывал в базе данных. Выходило не идеально, но хотя бы честно перед собой. Так вот, история только начинается.
Уйдя на практику полностью независимой разработки я конечно продолжил применять свои навыки и подходы в работе. Первый более-менее большой проект показался очень интересным с точки зрения проектирования. О, сколько тут будет сущностей! О, какие будут шикарные SQL-запросы!
По проекту, в админке можно было конструировать чуть ли не Вавилонскую башню с предполагаемым хеппи-эндом. Но реальность меня, конечно, приземлила. Тут я столкнулся с такой штукой, как хотение заказчика получить работающие сервисы и практически полное безразличие к тому, что "у её внутре" (конечно если речь не шла про аякс и другие модные фишки - это заказчику нравится, собственно говоря заслуженно). Начав поднимать титана я не справился со сроками, тем более что заказчику тоже не всегда видно с первого раза чего он хочет. А переделывать вроде бы модульную, но сложную по своей логике систему не так просто. Залезаешь в код ядра ядра ядра, а там - электроны вертятся так, что не поймаешь.
В одном из своих новых проектов я решил учесть тот опыт, не смотря на то, что уж очень хотелось реализовать всё ну очень красиво (опыт программирования ведь тоже подрос), да и заказчик говорил что, дескать, вот тут и тут будем усложнять потом функционал. Но я взял себя в руки и решил следовать плану - ориентироваться прежде всего на реализацию текущих задач и только после этого думать про расширяемость. Конечно, я не агитирую за бездумный подход, но полагаюсь на свою интуицию - бурчащего червячка идеальности. Если он только ворчит под нос, то я позволяю себе делать менее расширяемый, но дающий результаты код. Уж если он заорёт благим матом и начнёт пинать по почкам, то я, конечно, перестаю писать HTML в бизнес-логике.

Один из обычных дней

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

7 утра. Еду из своей подмосковной Коломны в Москву. Собственно весь основной контент дня происходить будет там. Ночь не спал да и в дороге уснуть не получается.

11 утра. Приехал на Сокол к ру_центру, мекке регистрации отечественных и прочих доменов. В 12 должен встретить заказчика и передать ему ранее купленные на моё имя домены. Этим действом должна завершиться сдача проекта, посему приехал заранее. На фотографии слева запечатлён ставший легендарным указатель.

Пока заказчик спешит на встречу, я приземлился на верхнем этаже метро-маркета в Ростиксе. Небольшой завтрак

Полдень. Вместе с заказчиком заходим в офис ру_центра, оформляем договор на его имя и передав два специальных письма, переводим домены под юрисдикцию аккаунта заказчика, хотя, конечно, все пароли к этому аккаунту хранятся у меня. Всё равно мне ими управлять.

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

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

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

6 часов вечера. Еду домой с Выхино. Наконец-то удалось заснуть, поэтому полтора часа пролетели совсем незаметно.

В районе 9 вечера. Сел за PHP-код одного из постоянных проектов. Точнее, за код я не особо брался - настраивал алиасы к основному домену через панель управления Plesk и немного поковырялся в модуле поиска, который на новом сервере (проект переезжал на днях) выдавал ошибки.

Лёг спать.

Business continuity для фрилансера

Существует в мире такая штука как стратегия business continuty. Об этом мне не так давно довелось написать статью в журнал сетевых решений LAN на примере "Дойчебанка UFG". Суть всей концепции сводится к разработке и обеспечению полного списка мер по обеспечению работоспособности бизнеса в случае возникновения форсмажорных обстоятельств (землетрясение, пожар, атака террористов) приведших к большим потерям.
Фрилансер - это конечно не огромная компания, но ведь если случается какое либо происшествие, то его бизнес так же находится под угрозой. Если обычный наёмный программист может только порадоваться простою компании (дескать можно лишний раз уйти раньше домой или поболтаться на кухне с тестерами), то для фрилансера простой - это риск и угроза.
Далеко ходить за примерами не надо. На днях я готовился сдавать этап одного проекта и тут - бац, авария. У соседей снизу (я работаю дома) прорвало батарею, их не было дома и в итоге залило всё до подвала, в том числе распредщитки со светом, которые выдавали феерверк при попытке восстановления подачи энергии. И всех жильцов сослали на ТРИ дня к родственникам, ибо жить три дня без света в наше время очень сложно. Теперь представьте мою ситуацию - через день надо сдавать этап, а я даже не могу включить компьютер чтобы что-то скопировать, не говоря о том чтобы работать. Но я, к счастью, оказался более-менее подготовлен к подобному ходу событий и теперь хочу поделиться, что необходимо предпринять для профилактики остановки рабочих процессов.
1. Ноутбук. Он меня очень выручил. Хоть я работаю на десктопе, ноутбук с установленными PHP, Apache, MySQL, phpMyAdmin у меня есть (с пропатченой WinXP для поддержки виртуальных хостов).
2. Альтернативный Интернет. На моём домашнем-рабочем месте подведён относительно широкий канал с анлим тарифом. Но любой провайдер периодически падает, поэтому я купил для себя ещё и вполне выгодную мобильную симку и, таким образом, организовал альтернативное подключение через GPRS. Конечно это не ахти какая скорость, но не теряться из аськи и почты, а так же закачивать обновления проектов по ФТП это позволяет с лихвой. Когда произошла авария со светом - я уехал к родственникам и "сидел" от них с ноутбуком и GPRS.
3. Веб-среда. Очень полезно держать последние/текущие версии всех проектов в сети. К примеру в SVN-репозиториях или ФТП-серверах. Так же лучше иметь веб-интерфейс к почте (с настройками чтобы письма оставались на сервере и под рукой всегда была история переписки) и ко всяким паролям. Тут отлично подойдут проекты google. И, наконец, если работает команда, то проект лучше вести не на локальной проектной системе, а на такой же системе в сети, где всегда будут видны ТЗ, отчёты, обсуждения, ключевые файлы и т.д.
4. Набор программ. Вот с чем я проколося, так это с некоторыми программами. На ноутбуке у меня небыло ФТП- и SVN-клиентов. Их пришлось качать, что съело немного конечно, но энное количество денег, так как мобильный траффик для скачки софта уже пригоден, но не такой он уж копеечный.
Если подготовиться заранее, то всякую проблему можно избежать. И нужно учитывать, что проблема может быть не только со светом или интернетом, но стоит ожидать и сгорания жёсткого диска и прочих коварных неприятностей и к любой из них нужно готовиться.

Сон как вторичный объект эксперимента

Последнее время совсем сбил своё внутреннее ощущение дня и ночи. Уже четвёртые сутки подряд работаю по расписанию с 22.00 до 07.00, потом отрывками сон, потом, часам к 17.00 работаю частично (т.е. могу отвлекаться на прогулки, магазин и установку DVD-рома и Nero соседу). Перед новой трудовой ночью (шо путана!) можно ещё часик поспать. Для работы такой ритм вполне даже ничего, так как ночью очень спокойно вокруг и можно сконцентрироваться. При определенной выучке, предварительном отдыхе, помноженном на энергетики, даже не хочется спать до самого утра.
Правда такой режим совсем не позволяет вести какую либо лично-семейную жизнь и домашние не в восторге. Думаю тот чувак, которым я стану в будущем, меня за эти ночи будет очень критиковать, покрякивая от болей в сердце, желудке и печени раньше положенного. Вобщем полный нот-гут, но переломить такой режим в условиях дедлайна не вижу возможности, так как для этого придётся сутки поспать сначала. Но суток нету, ведь речь идёт не о том перманентном дедлайне в условиях которого живёт (и размножается!) любой программист, а о дедлайне-дедлайне (привет пятому элементу).
Такие ситуации у меня уже случались. Доводят до того, что ложишься спать потом как нормальный человек после просмотра "спокойной ночи малыши", а просыпаешься как раз к началу эротических программ по ДТВ, т.е. часам к двум-трём ночи и это ещё в лучшем случае. Бывает что и в 12 ночи уже вскакиваешь с незакрываемыми глазами и готовностью забраться на Эверест.
Как я от этого ночного синдрома избавлялся: купил себе в аптеке снотворного (вредно, но обещали без привыкания - вроде пару месяцев обхожусь уже без него после разового поедания). Уснул в 9 вечера, проснулся в 15.00 следующего дня и был счастлив. Потом повторяем процедуру следующей ночью и на утро уже свободны от зависимости. Но вот беда - такой режим несовместим с активной работой, поэтому могу прописать только совсем загнувшимся стахановцам или людям на отдыхе. Перед началом этой программы выздоровления посоветуйтесь с врачом :)

Менеджмент процессов разработки

Вот какой умный заголовок я придумал для этого поста.
На днях, в общении с сотрудником в очередной раз подняли тему того, что рабочий процесс у нас не налажен. Я сам уже задолбался если честно совершать лишние движения в разработке поэтому решили "что-то менять" и причём уже завтра.
Итак, как налажен процесс сейчас и чего хочется поменять.
1. Версии кода. Сейчас: Код хранится на наших локальных машинах (хотя коллега предпочитает работать сразу с удалённым фтп), так же на тестовых сайтах и, наконец, уже на боевых серверах. У некоторых проектов тестовых сайтов нет. Код хранится "как есть", т.е. просто на ФТП без каких либо систем контроля. уже устали иметь локально, на тестовом и на боевом сайте совершенно разные версии, каждая из которых частично актуальна и при обновлении боевого сайта приходится вручную (с araxis merge правда) сшивать из трёх в одно . Как хочется: хочется контроля версий с возможностью автоматического развёртывания из SVN сразу на сайты, хотя бы тестовые. Т.е. разработали новую фичу локально, залили в SVN-систему синхронизированную с тестовым сайтом, заказчик на тестовом принял работу, выложили на боевой сайт.
2. Документация и стандарты. Сейчас: работаем как минимум вдвоём, зачастую приходится пересекаться в использовании общих библиотек и других компонентов. Соответственно, возникают ситуации, когда не зная о существовании уже готового кода, который написан коллегой для решения его задачи, пишется свой код, хотя можно было заюзать код коллеги. Иногда о существовании кода знаешь, но чего у него там внутри - нужно вдумчиво глядеть на монитор читая "пицот буков" и делая умное лицо. Всё потому что нет чётких стандартов кодирования (именования, форматирования текста) и документации кроме комментов вроде "превед вегерчики". Как хочется: документировать хотя бы библиотеки в едином формате, скорее всего phpDocumentor, чтобы можно было посмотреть не только комменты, но и легко генерировать "книжечку" с перечнем и описанием готовых библиотек по проекту. Чтобы брать их и использовать вторично и десятирично.
3. Бекапы. Сейчас: мой коллега не поднимал вопросы бекапа, так как организационные вопросы решаю я, будучи директором-ведущим-программистом-проджектом-аккаунт-менеджером. Но вопрос остаётся несомненно. Не дай бог упадёт какой сайт, или сами по невнимательности удалим какие-то строки в боевой базе данных - то останется надежда только на хостера. Но как показала практика - надежда эта может быть хрупкой, да и зачем иметь себе лишний риск? Как хочется: выработать единую систему собственного бекапа баз данных подшефных проектов и бекапов кода (здесь правда SVN поможет, но значит файлы SVN тоже надо бекапить).
Пока вроде всё. Если удастся разобраться с этим - можно будет бодро двигаться дальше.

Пластилин

Решая задачу по работе с большими объемами данных в условиях ограниченных ресурсов, я испытал уже хорошо подзабытое ощущение творца, креатора и генератора идей. Многие последние проекты, в которых приходилось участвовать были довольно однотипными, не смотря на то, что принципиально различались по своей сути. Всё равно на уровне данных были одни и те же связи, выборки, передачи массивов в шаблонизатор etc.
Но тут попался трудный орешек. Многоуровневые данные, их необходимо анализировать и выводить текущие показатели, а так же тренды по ним. Скрипты анализа данных просто умирали в условиях шаред-хостинга. Я сижу и пытаюсь решить задачу уже десятым наверное способом, урезая лишние переменные, вынужденно делая unset массивам после использования, эксперементируя со скоростью for и foreach, оптимизирую базу и SQL. И в голове наблюдаю приятное ощущение, что я творец, что у меня есть пластилин (глина, конструктор, дерьмо - выбирайте на вкус :) ) и я могу построить как вавилонскую башню, так и уютный отель на берегу Индийского океана, где я бы сейчас с удовольствием оказался...
*************
Прошло около трёх часов помоему. Согласно тестам - решить проблему удалось. В некоторых местах прирост скорости составил до 20 раз, что не может не радовать конечно. Правда такое ускорение достигалось при полном переосмылении подхода и переписывании процентов пятидесяти кода (в рамках узкой библиотеки разумеется), а не за счёт точечной оптимизации.
PHP как дышло - куда повернул туда и вышло.

Начало нового проекта

Долго у меня созревала идея одного проекта. Вот в конце августа принял решение - воплотить задумку в жизнь. Первого октября начинается разработка сайта туристической направленности! Подробности пока держу в секрете :)
Почему именно первое октября? Потому что ровно в этот день у меня заканчивается большой этап в другом коммерческом мероприятии, после которого я смогу немного расслабиться... нет не в Турции или Таиланде, а за компьютером, создавая проект не на заказ а по собственной идее. Этим постом открываю дневник проекта с ярлыком "trvl"!

Презентация бета-версии системы у заказчика

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

Журналисты must die!

Во время проведения конференции PHPConf 2007 мне случилось давать по телефону интервью журналистке "Комсомольской правды" (хотя она, как мне показалось, представлялась от издания со словом "Московский"). Тема статьи, для которой испрошали мое мнение была "Офисные бедуины", т.е. люди, которые не сидят в конкретном рабочем кабинете а работают дома, на пляже, по дороге на верблюде и т.д. Это не обязательно про фрилансеров - это про стиль работы.
Негативный восторг у меня вызывает не только искажение моей фамилии (я привык уже), но и приписка меня к бог пойми какой компании, а также литературное появление у меня "знакомых сисадминов", которые по сюжету, якобы, раскрывают мне тайны траффика, а в следующей сцене я экономлю на бензине (это при отстутствии у меня автомобиля!).
У меня возникает вопрос. Это я так криво рассказал, либо меня так криво услышали или просто написали как посчитали "более красивым"?

Работа для души, но не для денег

Даже в любимой сфере деятельности всегда найдется работа, которая нравится и которая не нравится. Проектирование и разработка двух разных приложений будут совершенно разными по своему интересу в зависимости от характера создаваемых систем и цели их создания. Примеров из разных плоскостей может быть много. Вот, скажем, есть задача построить большой каталог фирм с их отраслями, карточками товаров и загрузкой логотипов. Рядом есть другая задача за те же деньги - построить туристический сайт с кучей рич медиа (mp3-подкасты, видеоблоги...), использованием карт Google и нестандартной интеллектуальной связкой между объектами сайта. Что выберет уставший от неразличимых PHP-классов программист? Что выберет уставший от однотипных ER-диаграмм проектировщик? Конечно с условием, что это средне-статистические разработчики, а не профильные производители CMS для туристических порталов.
Другая плоскость -конечная сфера/цель применения приложения. Допустим, есть два совершенно одинаковых с технической точки зрения ресурса. Пусть это будут новостные аналитические сайты. При этом, первый сайт посвящен тематике огородников-любителей, а второй - острой политической теме. Лично я за бесплатно (да и платно надо еще на сумму посмотреть) не сяду делать огуречный портал при нынешней стоимости нефти на нью-йоркской бирже, но в то же время уже работаю над подобным проектом посвященным моим политическим убеждениям.
Попытался вот сделать выводы - что мною при этом движет? Нашел следующие "приятности":

• Работаю с проектами и людьми, которые раньше (и сейчас разумеется) вызывали мое уважение. Приятно быть частью проекта, когда остальная команда при этом раньше делала ресурс, зачитанный мною условно говоря до дыр. Теперь вот я сам демиург в этой теме.
• Открываешь для себя новых знакомых и, возможно, связи. Оказывается на планете существуют очень интересные люди, у которых темы разговоров касаются не только серверов и программ. Если не считать жену конечно.
• Просто приятно поиметь в портфолио еще немножко скриншотов и линков. Хуже ему не будет точно.

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

Был докладчиком на PHPConf 2007

Как сообщалось ранее в этом блоге, я должен был участвовать в конференции в качестве докладчика. В итоге вышло так, что я не столько "участвовал с докладом", сколько "выступал с докладом" не отбрасывая всей театральности слова "выступал".
Название доклада: что-то вроде "Независимая веб-разработка (Freelance)".
Приехал на конференцию уже после обеда, сразу с мероприятия Acer в Балчуг Кемпински и со встречи с заказчиком в Enjoy на Кузнецком мосту. Послушал доклад и вышел с докладом сам. Конечно, я запас пару шуток "на тему" и планировал сделать доклад достаточно живым, но в итоге получился еще лучший экспромт.
Для меня конференция прошла как и ожидалось - в общении с коллегами, которых уже давно знаю. Обсуждали не тонкости РНР, а собственные планы, проекты, перспективы и нелегкую долю :) . Ради этого я и приезжаю всегда на PHPConf.
После конференции продолжили общение в фастфуде с пивом (место обусловлено количеством желающих участников). Компанией из нескольких человек (представителей Москвы, Киева, Львова, СПБ и, собственно, Коломны) помотались по ночной Москве и в конце концов частями осели дома у Кузьмы [kvf77]. Во втором, завершающем дне конференции, я не участвовал.
А теперь слайды: http://digited.ru/files/phpconf2007.ppt.

Препятствия на пути эффективной работы

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

• Домашние заботы. Да, когда работаешь дома, то часто бывает нужно или сбегать в магазин, или пойти на кухню приготовить еду или сделать еще что-то другое. Слава богу, что я изначально побеседовал со своими близкими о том, что дома я не просто нахожусь, а именно работаю, поэтому с фразами типа "ты же все равно дома сидишь, так убрался бы" или "мне нужно съездить по мелким делам, не мог бы ты прийти посидеть с бабушкой, раз ты все равно дома" - ко мне не пристают. К этой же категории можно отнести и ситуации, когда семья в твое рабочее время находится дома и полноценно работать может не получиться, потому как то слышен телевизор, то с кухни раздаются звоны кастрюль, то нужно домашним с чем нибудь помочь и т.д. Нужен большой дом с отдельным кабинетом :)
• Соблазны похалявить или неправильный расчет времени. Серьезно обновил свой компьютер и поставил на него сразу три игрухи, которые на предыдущей машине даже не инсталлились. Передо мной открылись новые миры, в которые хочется уйти с головой как миниммум на неделю. Но при этом, я веду два проекта с напряженными графиками. Что делать? Возникают соблазны "я сейчас пару часиков поиграю, а потом вечерком лучше наверстаю". С этим нужно бороться, так как вечером наверняка появятся другие дела и в результате сегодняшний план полетит к чертям и будет сдвинут график работ.
• Параллельные работы. Распланировка и разведение параллельных работ - это помоему искусство. А уж соблюдение этих планов - так вобще магия. Понятное дело, что фрилансер обычно ведет не один проект, иначе он получает большой риск остаться без денег какое-то время, поэтому, иногда возникают ситуации, когда "завтра срочно нужен этот и этот функционал" сразу в нескольких проектах. Лично у меня, как человека склонного не только к программингу, но и ИТ-журналистике, бывали ситуации, когда нужно ехать на важное ИТ-мероприятие и в этот же день сдавать какой либо важный и срочный кусок работ по сайту. Такие нахлесты не всегда можно предвидеть и поэтому они приводят к бессонным ночам. И кодинг, замечу вам, не всегда самое опасное, что может "нахлестнуться". У фрилансера ведь жизнь состоит не только из написания программ, но и из общения с заказчиками. Часто случается, что нужно ехать на переговоры с одним потенциальным заказчиком, но при этом "горит" другой проект и приходится разрываться. Еще более мучительными бывают ситуации, когда в одном из проектов огромное количество "горящей" работы, а к вам приходит новый клиент и говорит - "мне срочно нужен сайт, за срочность доплачу". И вот тут нужно соразмерить свои силы. С одной стороны не стоит просто так бросаться клиентами, но с другой стороны, лучше выполнить один проект и получить за него деньги и славу, чем напортачить в двух и остаться с носом.
• Алкоголь. Не хочу сказать, что у меня на этой почве проблемы, но бывает так, что в жаркий день хочется пивка перехватить или, к примеру, работа идет в стрессе и тянет махнуть коньячку бокальчик. В офисе босс может дать по голове даже за кружку пива, а дома ты сам себе хозяин. Но алкоголь - однозначный враг рабоче-программерского процесса и себя нужно дисциплинировать в этом плане.
• Сторонние контакты. ICQ не только наш друг, но и враг. Это относится ко всем средствам общения, включая телефон и электронную почту. Бывает так, что в напряженное время начинают ломиться друзья, коллеги по сообществу, совершенно посторонние люди и т.п. Начинаешь отвлекаться вроде бы на пустячный разговор, а тут на тебе - полтора часа рабочего процесса минус, да еще нужно посчитать время, которое понадобиться чтобы снова загнать в голову тот объем данных, который там был до отвлечения.
• Собственные проекты. Программист - это несомненно творческая личность. Сколько идей по новым CMS, новым сайтам, тестированию новых продуктов и т.п. Бывает так, что неделя прошла, оглядываешься назад - вроде семь дней за компом безвылазно сидел, а по рабочим проектам особо нечего показать. В чем проблема? Слишком много внимания уделил "левым" проектам. Да, они интересны, да, они в итоге могут быть полезны (как например изучение нового сто первого фреймворка), но все это мусор. Фрилансер эффективен не просиженными часами, а выполненными работами за период времени. Заказчику плевать, что вы там изучили что-то новое и проапгредились до седьмого уровня программистского армора, если вы провалили сдачу этапа его проекта. Отсюда мораль - нужно прежде всего делать проекты, которые приносят выгоду (сами определите что считать за выгоду, это не обязательно наличные рубли).

Это неполный список вещей, которые мешают фрилансеру добиться славы и денег. Думаю он будет пополняться в последующих постах.

Мысли по поводу самомотивации

Промышленное веб-программирование (т.е. разработка "за деньги") это процесс не только интересный, но и местами скучный. Зачастую хочется получить результат "уже сегодня", но он еще далек и впереди много дней написания кода, работы с СУБД, FTP и прочими умными словами. Хорошо когда нужно изобретать, обкатывать идеи, пробовать новые подходы...
Но коммерческие решения очень часто бывают похожи одно на другое и работа в таких случаях становится однотипной, лишь с небольшими различиями. При этом нельзя сказать "а пусть будет так, вроде сойдет" и приходится все оттачивать и шлифовать до конца. Такая работа может утомлять и ощущение ее "неодолимого" объема будет угнетать и понижать мотивацию к труду. Для независимого разработчика такое состояние рабочего духа не просто неприемлемо, а смертельно. С профессиональной точки зрения конечно, так как фрилансер несет личную ответственность за проект и не может переложить ее на плечи своего руководителя, что приведет к его дискредитации, прямым и косвенным финансовым потерям.
Но тут я заметил вот что. Лично мне работается гораздо лучше даже в самом заурядном проекте, если я не пытаюсь свернуть сразу всю гору и серьезно уменьшаю "размер" каждой итерации в процессе разработки. Каждая итерация должна быть доступна для реализации примерно за 1-2 рабочих дня, чтобы ее окончание зафиксировать похлопыванием себя по плечу и получить дозу гормона счастья, так как проект на еще один шаг станет ближе к завершению (получению денег/статуса/новых деловых связей/просто удовольствия). Эта идея близка к понятию "Ежедневный билд" для компилируемых проектов.
Это важно не только с точки зрения самомотивации, но еще и упрощает процесс оценки оставшегося объема работ относительно попадания в запланированные сроки, хотя для себя я нашел пользу прежде всего в сфере самомотивации.

Я - докладчик на РИФе!

РИФ (Российский Интернет Форум) - это самое большое событие в Рунете, на котором собирается большое количество специалистов, работающих с всемирной паутиной. Это отнюдь не только программисты, дизайнеры и хостеры, но все остальные, чьей сферой деятельности является Сеть. Впрочем, чего это я объясняю.
В рамках РИФа наш клуб PHPClub проводит семинар по поводу использования технологии PHP в корпоративных веб-разработках. Ключевые слова "РНР" и "Корпоративный". Мероприятие строится таким образом: я выступаю с докладом, а Александр Смирнов (Основатель phpclub.ru), Дмитрий Коробицын (kdk, Директор "РБС Дизайн") и Денис Гусев (Директор PHPCENTER) участвуют в раунде вопросов и ответов в качестве приглашенных экспертов вместе со мной.
Презентацию надеюсь выложить сюда.
-----
Презентацию и небольшой отчет можно найти тут: http://phpinside.ru/?q=node/634

Еще два проекта сданы!

Честно говоря, март 2007 стал для меня самым результативным. Я сдал за это время два сайта и вел работу над третьим большим. Первый сданный сайт принадлежит заводу строительных изделий, а второй сайт - это мои древние партнеры, решившие расширить автомобильную тематику на средства отделки для яхт.
Каких-то организационных и технических особенностей не возникло - просто создал ресурсы на базе своей "корпоративной" CMS-CMF, что очень помогло со сроками. Без CMS-CMF я бы точно застрял, хотя сайты являются очень простыми по своей сути. Завтра поеду забирать подписанный акт выполненных работ на завод и жду появления денег на расчетном счету моего ООО. Скорее всего обновлю свои "средства производства", куплю себе наконец ЖК монитор, благо я не дизайнер.

Подписание договора с Заводом

На один из подмосковных заводов меня вывел заказчик, с которым я сейчас веду проект. Отдел сбыта на предприятии озаботился тем, что покупатели их продукции в последнее время часто спрашивают "можно ваш прайс скачать в сети?" или "у вас на сайте есть схема проезда, чтобы наш шофер не заблудился?" и на все эти вопросы приходилось отвечать - "к сожалению у нас пока нет веб-сайта". Если еще пару лет назад разработчикам веб-решений приходилось рисовать подобную картину директорам заводов, то теперь всю работу начинают делают сами клиенты, хотя я считаю, что Пришествие Века Сайтов только начинается, как бы странно это не звучало.
Так что же насчет договора?
Руководство сообщило мне, что будет работать только с юридическим лицом, что означало введение в действие моего ООО. Не будь фирмы - небыло бы и заказа.
Этапы работы с момента первой встречи до момента заключения договора были следующими:

1. Первая встреча. Обоюдное знакомство, выяснение целей заказчика, которые он ставит перед сайтом. Это нужно прежде всего для того чтобы я мог оценить сроки работы, тяжесть и самое главное для обеих сторон - цену вопроса. Примерную цену я назвал сразу, предложив два варианта реализации: примерно то что было нужно заказчику (скажем так light version) и более "тяжелый" вариант. Цены соответственно тоже различались.
2. Во вторую встречу я привез драфт договоров, коммерческое предложение с окончательной ценой. Руководство завода (Директор, Начальник отдела сбыта и гл. бухгалтер) дали согласие на заключение договора с небольшими поправками (в основном это касалось сроков и этапов проплаты на мой расчетный счет).
3. В третюю встречу я подвез оригиналы договоров с печатью моего ООО и сразу же после подписания встречался со специалистами Завода (Сбыт, Зам. Директора, ПТО - где в автокаде "рисуют" модели продукции) на предмет получения информации для наполнения сайта и выявления его структуры. Забрал пару каталогов с пометками на полях и договорился о подготовке для меня набора моделей (в т.ч. 3D) продукции. Так же, в сбыте мне обещали подготовить текст "О компании".

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

• Прежде всего, перед подписанием они очень хотели посмотреть на дизайн сайта. По прежнему многие полагают, что его красота это главный фактор, хотя разработчикам известно, что дизайн, следуя терминологии Герцберга - это гигиенический фактор. Другими словами - эффективность сайта и его полезность бизнесу определяет не дизайн, хотя плохой дизайн, несомненно, может ухудшить эту самую эффективность. Благо, что я сразу предупреждал - все работы только после, как миниммум, подписания договора.
• Договор могут не читать сразу (точнее пробегаются быстро, но не вдумчиво). Есть вероятность, что будут вам звонить на следующий день после подписания (!) и спрашивать - "а что означает вот это?".
• Договор, это вобще не самоцель. Это просто бумажка, которая для заказчика является путем решения их проблемы. Когда я пришел с драфтом, мне сказали что-то вроде "а, бумажки принес, а мы бы хотели на диске уже что нибудь посмотреть".

Конкретно в этом проекте мне было важно оценить заказчика и его потребности (хотя это важно всегда!). К примеру, я узнал, что интернет им провели всего пару недель назад и он есть только у Директора и Главбуха. Это значит, что поддержкой сайта заниматься на заводе будет некому. Остальной персонал, компетентный в вопросах продукции - люди, у которых на рабочих столах компьютеров нет в принципе. Из этого следует, грубо, три варианта моего поведения:

1. Сделать им сайт сайт и забыть про него. Он вскоре станет неактуальным (устареют цены и список продукции как минимум). Значит уже через полгода завод будет искать разработчиков для нового (!) сайта или будет постоянно твердить клиентам: "это есть на нашем сайте, но там не все верно". Обо мне будет не лучшее мнение, но зато это будут легкие деньги.
2. Сделать им сайт с админкой. Но представьте, персоналу помимо их постоянных обязанностей и головной боли прибавится администрирование, а значит еще и изучение системы управления сайтом! Хорошо, когда есть знакомые с офисными приложениями сотрудники, которым это не в тягость, но здесь бы все пошли против меня (читай - против новых забот) и не факт, что вся работа была бы возможна.
3. Сделать сайт и предложить его техподдержку за дополнительную плату. Главный плюс: получить больше денег (да еще регулярность их поступления). Главный минус: нужно будет постоянно работать с людьми, которые не знакомы со спецификой и их нужно будет понимать и пытаться находить лучшее решение в рамках их знаний.

Настоящая работа - это вариант №3. Есть желание денег? Нужно желание работы.

Написание ТЗ. Нужно учить матчасть

Столкнулся с проектом средней тяжести реализации. Разработку запланировано вести в несколько самостоятельных стабильных промежуточных этапов.
Для того чтобы не держать кучу информации в голове (тем более, что это невозможно для обычного человека), а также, чтобы согласовать все с заказчиком и зафиксировать в письменном виде, мы решили составить полноценное Техническое Задание. Казалось бы, как можно вобще работать без ТЗ? Но на моей практике такое случается сплошь и рядом, хотя, конечно, в маленьких проектах.
Итак, первое ТЗ состоит из следующих разделов:

• Введение. В основном, здесь идет описание наших целей. Т.е. что это будет за сайт и какие у него будут цели существования, потенциальная аудитория.
• Общие требования к сайту. В этот раздел попадает список общих для всего сайта требований, таких как структура URI, критичная скорость загрузки, принципы шаблонизации и безопасности. Безопасность, впрочем, можно вынести и в отдельный раздел, но в моем случае практически ничего кроме шифрования паролей в md5 не указывалось (используемый PHP-фреймворк by default закрывает проверку входящих данных и т.п.).
• Пользовательские роли. Тут описывается практически вся реализация пользовательской части. В моем случае это описание основных групповых политик и ролей.
• Объекты. В данной части подробно описываются объекты сайта (новость, событие, пользователь,товар...) с указанием всех полей (в т.ч. обязательных) и состояний. При разработке повлияет на ОО-структуру и схему базы данных.
• Страницы и модели поведения. Этот раздел описывает основные страницы (ведь сайт, это по сути набор страниц или фактических состояний). Для примера, зафиксировано, что на странице новостей будет выводится список из 10 последних по дате новостей. Список будет состоять из даты новости, ее заголовка и текста аннотации и т.д. и т.п. вплоть до модели поведения системы при клике на заголовке новости. В этом же разделе можно описать систему администрирования.

Чего здесь не хватает? После нескольких редакций документ разросся и ему не хватает подробного содержания и краткого руководства "Как пользоваться этим документом". Еще здесь не хватает следующих вещей:

• Требований к дизайну и юзабилити (в частности, как будет выглядеть и логически работать календарь для выбора даты).
• Более научного подхода, к примеру UML диаграмм не только классов, но и Cases, т.е. тех самых моделей поведения, записанных не на словах, а в диаграммах.

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

Сейчас планирую дополнительно изучить литературу по выработке, фиксации и контролю исполнения требований к ПО. В частности это будет часть книги Лешека Мацяшека и еще пару изданий.

Похоже, я буду докладчиком на PHPConf 2007

По предложению Александра Смирнова, создателя и идейного вдохновителя http://phpclub.ru я написал тезисы к докладу о независимой PHP-разработке (фрилансе), чтобы выступить в мае 2007 года на http://phpconf.ru.
В докладе планируется обобщить личный опыт и провести обзорное исследование феномена независимой РНР-разработки (фриланса) в России. Главный ориентир - не совмещение фриланса с основной работой full time, а полностью независимая разработка.Основные вехи доклада:

• Попытка классификации: полная занятость full time и удаленно, частичный freelance, полностью независимая разработка.
• Организационный вопрос: ИП, ООО, "неофициальная" занятость, физическое лицо по договору. Налоги.
• Наработка опыта и клиентской базы.
• Взаимоотношение с заказчиком (гарантии оплаты, варианты оплаты, коммуникации, технические задания).
• Фриланс vs Full Time: за и против.

Удастся ли в итоге, и что из этого получится будет видно только в мае. Ждите продолжения :)

Первая встреча с одним из заказчиков

Вчера встречался с потенциальным заказчиком. На меня его вывел один мой коллега, знакомый по phpclub, который снабдил его положительными рекомендациями (спасибо!).
Изначально я планировал встречу таким образом: мы встречаемся в центре Москвы (по договоренности это была кофейня n-joy на Кузнецких Воротах), знакомимся друг с другом и я рассказываю ему немного о своих профессиональных навыках, портфолио и прочих вещах по которым он сможет хоть как-то определить - подхожу я для его проекта или нет. В то же время, хотелось посмотреть и на него, чтобы понять - адекватен человек или проект сразу рискует превратиться в работу для камикадзе. Такая беседа очень хорошо помогает определиться, хотя бы предварительно. Методика заказчика по определению моей адекватности состояла из следующих направлений вопросов:

• Каким я вижу решение организационных вопросов (взаимные гарантии, взаимодействие в процессе разработки, разделение работы на этапы и оплату). По моему мнению, опытному заказчику мои ответы могли не только прояснить как мы можем сотрудничать конкретно с ним, но и в целом дать представление - есть у меня опыт решения таких вопросов или нет. Ведь если я ни бум-бум здесь, то встает вопрос - а были ли у меня раньше фрилансовые заказы или я выдаю себя не за того, кем являюсь.
• Чем данный проект будет для меня интересен? Тоже грамотный вопрос. Если проект не интересен с точки зрения реализации (а не денег) то для заказчика есть как минимум два риска - что я буду работать медленно без проявления фантазии и что проект мне надоест через месяц и я буду пытаться всеми силами выйти из него. Понятно, что оба риска вполне серьезны.
• В каких проектах я участвовал и что это за проекты? В моем конкретном случае у заказчика была рекомендация, а значит он не пытался устраивать мне тестирование на знание языка, но вопросы наподобие этого всегда позволяют оценить опыт разработчика в тех или иных сферах.

Я же специальных вопросов не задавал, но для меня были интересны следующие моменты:

• Сколько денег заказчик готов реально заплатить за проект. Нужно, чтобы он назвал конкретную сумму.
• Готов ли он платить дополнительно, если вдруг решит расширить проект или будет пытаться "вписать" новые задачи в старое ТЗ. Здесь в любом случае стоит предусматривать такой оборот дел, но лучше прояснить для себя все в самом начале.
• На какие сроки он рассчитывает и готов ли морально к их нарушению. Проект может разрастись, или могут вылезти неожиданные трудности - это все случается, причем не всегда по вине разработчика - некоторые вещи действительно сложно предугадать. Поэтому нужно понять - будет ли заказчик неадекватен или при должном обосновании с вашей стороны сможет как-то попытаться справиться с ситуацией. В любом случае, здесь разработчик должен всегда стараться предугадать тонкие места и как можно заранее предупреждать заказчика о возможных трудностях. О ленивости разработчика я здесь не говорю - мы рассматриваем ситуацию, когда программист действительно нацелен на успех проекта.
• Когда я получу первые деньги и что я должен для этого сделать?

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

Теперь, я должен буду выяснить о всех нужных функциях поподробнее, сформировать ТЗ и нарисовать статическую (HTML или в Visio) модель сайта. Тогда мы утвердим точный срок реализации этапа и деньги за его прохождение. Информация выясняется на дополнительных встречах путем интервьюирования заказчика.

Чем это хорошо? Во-первых, заказчик сможет за этот этап (2-4 недели) понять - действительно ли я могу реализовать то, что он хочет получить. Одно дело интуиция на собеседовании, а совсем другое - на практике. Если я не справлюсь с первым этапом, то он потеряет не полгода, а две недели, что тоже неприятно, но поправимо. С другой стороны, я, как разработчик смогу выявить платежеспособность и адекватность заказчика на практике и в крайнем случае потеряю также не полгода, а две недели.

Начало нового блога

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