среда, 31 октября 2007 г.

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

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

суббота, 20 октября 2007 г.

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

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

пятница, 19 октября 2007 г.

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

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

Пластилин

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

понедельник, 24 сентября 2007 г.

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

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

понедельник, 6 августа 2007 г.

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

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

пятница, 13 июля 2007 г.

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

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