Кто сшил костюм

Август 23rd, 2011

Вот как объяснить эту задумку:

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

Вообще ощущение от редизайна тягостное. И так то была каша, но хоть привычная, теперь это каши стало по ощущения раза в три больше. Хотелось бы “взглянуть в глаза, кто это сшил”:

Сдача сайта: контроль

Июнь 4th, 2011

Обычная история взаимоотношений с заказчиком на этапе сдачи:

Нашу систему *** делало. И что? Те же ..ца, только в профиль.
После сборки дорабатывал напильником: привинтил скрипты для автомат.формирования новости и по шедулеру выгрузки на сайт, рассылка отдельным скриптом от оригинального.
Только кэш местами корректней работает, не творит таких чудес.
Сдали они проект на полгода позже, чем планировалось. Надо было видеть этап тестирования!..

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

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

Жизненный цикл этапа сдачи разбит на этапы:
Continue reading →

Реализация среды для анализа кода

Май 13th, 2011

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

Для контроля качества кода у нас используется связка Fisheye+Crucible регулярно мониторищая репозитарий через который проходят все изменения.

Техническая проблема состоит при этом в том, что Fisheye/Crucible с одной стороны потребляют значительное количество ресурсов и, при практическом использовании, регулярно доводят сервер до неспособности обслуживать другие сервисы, с другой же стороны постоянный мониторинг SVN репозитария при использовнии и svn-протокола и, тем более, http оказывается неприемлемо медленным.

Решение пришло в виде микро-инстанции Amazon EC2 – ее стоимость вполне допускает выделенный J2EE сервер обслуживающий только Fisheye/Crucible, а NFS доступ “только чтение” к другой инстанции EC2 на которой расположен SVN репозитарий по внутренней сети Amazon Cloud обеспечивает и быстрое сканирование и практически нулевую стоимость сетевого трафика.

Организация среды разработки

Апрель 28th, 2011

Идея иметь разделенные среды для рабочих систем и для разработки не нова, но специфика разработки веб-сайтов требует в том, чтобы среда разработки создавалась максимально быстро и не добавляла значительной стоимости к цене проекта.

В результате мы пришли к такой схеме:

Единственный инструмент, который нужен разработчикам, это Subversion. В самом начале работы разработчики получают из SVN структуру папок для будущего сайта. Каждый раз, когда они сохраняют свои изменения в репозитарий, эти изменения мгновенно копируются в каталоги виртуальных серверов и становятся доступными для проверки.

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

1 2   »