Существует в мире такая штука как стратегия business continuty. Об этом мне не так давно довелось написать статью в журнал сетевых решений LAN на примере "Дойчебанка UFG". Суть всей концепции сводится к разработке и обеспечению полного списка мер по обеспечению работоспособности бизнеса в случае возникновения форсмажорных обстоятельств (землетрясение, пожар, атака террористов) приведших к большим потерям.
Фрилансер - это конечно не огромная компания, но ведь если случается какое либо происшествие, то его бизнес так же находится под угрозой. Если обычный наёмный программист может только порадоваться простою компании (дескать можно лишний раз уйти раньше домой или поболтаться на кухне с тестерами), то для фрилансера простой - это риск и угроза.
Далеко ходить за примерами не надо. На днях я готовился сдавать этап одного проекта и тут - бац, авария. У соседей снизу (я работаю дома) прорвало батарею, их не было дома и в итоге залило всё до подвала, в том числе распредщитки со светом, которые выдавали феерверк при попытке восстановления подачи энергии. И всех жильцов сослали на ТРИ дня к родственникам, ибо жить три дня без света в наше время очень сложно. Теперь представьте мою ситуацию - через день надо сдавать этап, а я даже не могу включить компьютер чтобы что-то скопировать, не говоря о том чтобы работать. Но я, к счастью, оказался более-менее подготовлен к подобному ходу событий и теперь хочу поделиться, что необходимо предпринять для профилактики остановки рабочих процессов.
1. Ноутбук. Он меня очень выручил. Хоть я работаю на десктопе, ноутбук с установленными PHP, Apache, MySQL, phpMyAdmin у меня есть (с пропатченой WinXP для поддержки виртуальных хостов).
2. Альтернативный Интернет. На моём домашнем-рабочем месте подведён относительно широкий канал с анлим тарифом. Но любой провайдер периодически падает, поэтому я купил для себя ещё и вполне выгодную мобильную симку и, таким образом, организовал альтернативное подключение через GPRS. Конечно это не ахти какая скорость, но не теряться из аськи и почты, а так же закачивать обновления проектов по ФТП это позволяет с лихвой. Когда произошла авария со светом - я уехал к родственникам и "сидел" от них с ноутбуком и GPRS.
3. Веб-среда. Очень полезно держать последние/текущие версии всех проектов в сети. К примеру в SVN-репозиториях или ФТП-серверах. Так же лучше иметь веб-интерфейс к почте (с настройками чтобы письма оставались на сервере и под рукой всегда была история переписки) и ко всяким паролям. Тут отлично подойдут проекты google. И, наконец, если работает команда, то проект лучше вести не на локальной проектной системе, а на такой же системе в сети, где всегда будут видны ТЗ, отчёты, обсуждения, ключевые файлы и т.д.
4. Набор программ. Вот с чем я проколося, так это с некоторыми программами. На ноутбуке у меня небыло ФТП- и SVN-клиентов. Их пришлось качать, что съело немного конечно, но энное количество денег, так как мобильный траффик для скачки софта уже пригоден, но не такой он уж копеечный.
Если подготовиться заранее, то всякую проблему можно избежать. И нужно учитывать, что проблема может быть не только со светом или интернетом, но стоит ожидать и сгорания жёсткого диска и прочих коварных неприятностей и к любой из них нужно готовиться.
среда, 31 октября 2007 г.
суббота, 20 октября 2007 г.
Сон как вторичный объект эксперимента
Последнее время совсем сбил своё внутреннее ощущение дня и ночи. Уже четвёртые сутки подряд работаю по расписанию с 22.00 до 07.00, потом отрывками сон, потом, часам к 17.00 работаю частично (т.е. могу отвлекаться на прогулки, магазин и установку DVD-рома и Nero соседу). Перед новой трудовой ночью (шо путана!) можно ещё часик поспать. Для работы такой ритм вполне даже ничего, так как ночью очень спокойно вокруг и можно сконцентрироваться. При определенной выучке, предварительном отдыхе, помноженном на энергетики, даже не хочется спать до самого утра.
Правда такой режим совсем не позволяет вести какую либо лично-семейную жизнь и домашние не в восторге. Думаю тот чувак, которым я стану в будущем, меня за эти ночи будет очень критиковать, покрякивая от болей в сердце, желудке и печени раньше положенного. Вобщем полный нот-гут, но переломить такой режим в условиях дедлайна не вижу возможности, так как для этого придётся сутки поспать сначала. Но суток нету, ведь речь идёт не о том перманентном дедлайне в условиях которого живёт (и размножается!) любой программист, а о дедлайне-дедлайне (привет пятому элементу).
Такие ситуации у меня уже случались. Доводят до того, что ложишься спать потом как нормальный человек после просмотра "спокойной ночи малыши", а просыпаешься как раз к началу эротических программ по ДТВ, т.е. часам к двум-трём ночи и это ещё в лучшем случае. Бывает что и в 12 ночи уже вскакиваешь с незакрываемыми глазами и готовностью забраться на Эверест.
Как я от этого ночного синдрома избавлялся: купил себе в аптеке снотворного (вредно, но обещали без привыкания - вроде пару месяцев обхожусь уже без него после разового поедания). Уснул в 9 вечера, проснулся в 15.00 следующего дня и был счастлив. Потом повторяем процедуру следующей ночью и на утро уже свободны от зависимости. Но вот беда - такой режим несовместим с активной работой, поэтому могу прописать только совсем загнувшимся стахановцам или людям на отдыхе. Перед началом этой программы выздоровления посоветуйтесь с врачом :)
Правда такой режим совсем не позволяет вести какую либо лично-семейную жизнь и домашние не в восторге. Думаю тот чувак, которым я стану в будущем, меня за эти ночи будет очень критиковать, покрякивая от болей в сердце, желудке и печени раньше положенного. Вобщем полный нот-гут, но переломить такой режим в условиях дедлайна не вижу возможности, так как для этого придётся сутки поспать сначала. Но суток нету, ведь речь идёт не о том перманентном дедлайне в условиях которого живёт (и размножается!) любой программист, а о дедлайне-дедлайне (привет пятому элементу).
Такие ситуации у меня уже случались. Доводят до того, что ложишься спать потом как нормальный человек после просмотра "спокойной ночи малыши", а просыпаешься как раз к началу эротических программ по ДТВ, т.е. часам к двум-трём ночи и это ещё в лучшем случае. Бывает что и в 12 ночи уже вскакиваешь с незакрываемыми глазами и готовностью забраться на Эверест.
Как я от этого ночного синдрома избавлялся: купил себе в аптеке снотворного (вредно, но обещали без привыкания - вроде пару месяцев обхожусь уже без него после разового поедания). Уснул в 9 вечера, проснулся в 15.00 следующего дня и был счастлив. Потом повторяем процедуру следующей ночью и на утро уже свободны от зависимости. Но вот беда - такой режим несовместим с активной работой, поэтому могу прописать только совсем загнувшимся стахановцам или людям на отдыхе. Перед началом этой программы выздоровления посоветуйтесь с врачом :)
пятница, 19 октября 2007 г.
Менеджмент процессов разработки
Вот какой умный заголовок я придумал для этого поста.
На днях, в общении с сотрудником в очередной раз подняли тему того, что рабочий процесс у нас не налажен. Я сам уже задолбался если честно совершать лишние движения в разработке поэтому решили "что-то менять" и причём уже завтра.
Итак, как налажен процесс сейчас и чего хочется поменять.
1. Версии кода. Сейчас: Код хранится на наших локальных машинах (хотя коллега предпочитает работать сразу с удалённым фтп), так же на тестовых сайтах и, наконец, уже на боевых серверах. У некоторых проектов тестовых сайтов нет. Код хранится "как есть", т.е. просто на ФТП без каких либо систем контроля. уже устали иметь локально, на тестовом и на боевом сайте совершенно разные версии, каждая из которых частично актуальна и при обновлении боевого сайта приходится вручную (с araxis merge правда) сшивать из трёх в одно . Как хочется: хочется контроля версий с возможностью автоматического развёртывания из SVN сразу на сайты, хотя бы тестовые. Т.е. разработали новую фичу локально, залили в SVN-систему синхронизированную с тестовым сайтом, заказчик на тестовом принял работу, выложили на боевой сайт.
2. Документация и стандарты. Сейчас: работаем как минимум вдвоём, зачастую приходится пересекаться в использовании общих библиотек и других компонентов. Соответственно, возникают ситуации, когда не зная о существовании уже готового кода, который написан коллегой для решения его задачи, пишется свой код, хотя можно было заюзать код коллеги. Иногда о существовании кода знаешь, но чего у него там внутри - нужно вдумчиво глядеть на монитор читая "пицот буков" и делая умное лицо. Всё потому что нет чётких стандартов кодирования (именования, форматирования текста) и документации кроме комментов вроде "превед вегерчики". Как хочется: документировать хотя бы библиотеки в едином формате, скорее всего phpDocumentor, чтобы можно было посмотреть не только комменты, но и легко генерировать "книжечку" с перечнем и описанием готовых библиотек по проекту. Чтобы брать их и использовать вторично и десятирично.
3. Бекапы. Сейчас: мой коллега не поднимал вопросы бекапа, так как организационные вопросы решаю я, будучи директором-ведущим-программистом-проджектом-аккаунт-менеджером. Но вопрос остаётся несомненно. Не дай бог упадёт какой сайт, или сами по невнимательности удалим какие-то строки в боевой базе данных - то останется надежда только на хостера. Но как показала практика - надежда эта может быть хрупкой, да и зачем иметь себе лишний риск? Как хочется: выработать единую систему собственного бекапа баз данных подшефных проектов и бекапов кода (здесь правда SVN поможет, но значит файлы SVN тоже надо бекапить).
Пока вроде всё. Если удастся разобраться с этим - можно будет бодро двигаться дальше.
На днях, в общении с сотрудником в очередной раз подняли тему того, что рабочий процесс у нас не налажен. Я сам уже задолбался если честно совершать лишние движения в разработке поэтому решили "что-то менять" и причём уже завтра.
Итак, как налажен процесс сейчас и чего хочется поменять.
1. Версии кода. Сейчас: Код хранится на наших локальных машинах (хотя коллега предпочитает работать сразу с удалённым фтп), так же на тестовых сайтах и, наконец, уже на боевых серверах. У некоторых проектов тестовых сайтов нет. Код хранится "как есть", т.е. просто на ФТП без каких либо систем контроля. уже устали иметь локально, на тестовом и на боевом сайте совершенно разные версии, каждая из которых частично актуальна и при обновлении боевого сайта приходится вручную (с araxis merge правда) сшивать из трёх в одно . Как хочется: хочется контроля версий с возможностью автоматического развёртывания из SVN сразу на сайты, хотя бы тестовые. Т.е. разработали новую фичу локально, залили в SVN-систему синхронизированную с тестовым сайтом, заказчик на тестовом принял работу, выложили на боевой сайт.
2. Документация и стандарты. Сейчас: работаем как минимум вдвоём, зачастую приходится пересекаться в использовании общих библиотек и других компонентов. Соответственно, возникают ситуации, когда не зная о существовании уже готового кода, который написан коллегой для решения его задачи, пишется свой код, хотя можно было заюзать код коллеги. Иногда о существовании кода знаешь, но чего у него там внутри - нужно вдумчиво глядеть на монитор читая "пицот буков" и делая умное лицо. Всё потому что нет чётких стандартов кодирования (именования, форматирования текста) и документации кроме комментов вроде "превед вегерчики". Как хочется: документировать хотя бы библиотеки в едином формате, скорее всего phpDocumentor, чтобы можно было посмотреть не только комменты, но и легко генерировать "книжечку" с перечнем и описанием готовых библиотек по проекту. Чтобы брать их и использовать вторично и десятирично.
3. Бекапы. Сейчас: мой коллега не поднимал вопросы бекапа, так как организационные вопросы решаю я, будучи директором-ведущим-программистом-проджектом-аккаунт-менеджером. Но вопрос остаётся несомненно. Не дай бог упадёт какой сайт, или сами по невнимательности удалим какие-то строки в боевой базе данных - то останется надежда только на хостера. Но как показала практика - надежда эта может быть хрупкой, да и зачем иметь себе лишний риск? Как хочется: выработать единую систему собственного бекапа баз данных подшефных проектов и бекапов кода (здесь правда SVN поможет, но значит файлы SVN тоже надо бекапить).
Пока вроде всё. Если удастся разобраться с этим - можно будет бодро двигаться дальше.
Пластилин
Решая задачу по работе с большими объемами данных в условиях ограниченных ресурсов, я испытал уже хорошо подзабытое ощущение творца, креатора и генератора идей. Многие последние проекты, в которых приходилось участвовать были довольно однотипными, не смотря на то, что принципиально различались по своей сути. Всё равно на уровне данных были одни и те же связи, выборки, передачи массивов в шаблонизатор etc.
Но тут попался трудный орешек. Многоуровневые данные, их необходимо анализировать и выводить текущие показатели, а так же тренды по ним. Скрипты анализа данных просто умирали в условиях шаред-хостинга. Я сижу и пытаюсь решить задачу уже десятым наверное способом, урезая лишние переменные, вынужденно делая unset массивам после использования, эксперементируя со скоростью for и foreach, оптимизирую базу и SQL. И в голове наблюдаю приятное ощущение, что я творец, что у меня есть пластилин (глина, конструктор, дерьмо - выбирайте на вкус :) ) и я могу построить как вавилонскую башню, так и уютный отель на берегу Индийского океана, где я бы сейчас с удовольствием оказался...
*************
Прошло около трёх часов помоему. Согласно тестам - решить проблему удалось. В некоторых местах прирост скорости составил до 20 раз, что не может не радовать конечно. Правда такое ускорение достигалось при полном переосмылении подхода и переписывании процентов пятидесяти кода (в рамках узкой библиотеки разумеется), а не за счёт точечной оптимизации.
PHP как дышло - куда повернул туда и вышло.
Но тут попался трудный орешек. Многоуровневые данные, их необходимо анализировать и выводить текущие показатели, а так же тренды по ним. Скрипты анализа данных просто умирали в условиях шаред-хостинга. Я сижу и пытаюсь решить задачу уже десятым наверное способом, урезая лишние переменные, вынужденно делая unset массивам после использования, эксперементируя со скоростью for и foreach, оптимизирую базу и SQL. И в голове наблюдаю приятное ощущение, что я творец, что у меня есть пластилин (глина, конструктор, дерьмо - выбирайте на вкус :) ) и я могу построить как вавилонскую башню, так и уютный отель на берегу Индийского океана, где я бы сейчас с удовольствием оказался...
*************
Прошло около трёх часов помоему. Согласно тестам - решить проблему удалось. В некоторых местах прирост скорости составил до 20 раз, что не может не радовать конечно. Правда такое ускорение достигалось при полном переосмылении подхода и переписывании процентов пятидесяти кода (в рамках узкой библиотеки разумеется), а не за счёт точечной оптимизации.
PHP как дышло - куда повернул туда и вышло.
Подписаться на:
Сообщения (Atom)