Мурк Дотком Голосов: 1 Адрес блога: http://mourk.com/blog/ Добавлен: 2008-04-13 19:50:24 блограйдером ld100

Веб-дизайн — цена эксклюзива

0000-00-00 00:00:00 (читать в оригинале)

Встречаются как-то два психолога. Первый начинает разговор за жизнь:
— Я себе недавно купил навороченный Феррари…
А второй сначала косо смотрит на первого, а потом и говорит:
— Слушай, мы же все-таки профессионалы. Давай просто расстегнем брюки и померяемся!

Есть у меня приятель, занимающийся мелкооптовой торговлей бельем — типичный представитель мелкого бизнеса. Его компании потребовался сайт в интернете, и приятель попросил меня подсказать, где лучше его заказать, а также спросил об ориентировочных ценах. Когда я назвал приблизительную стоимость разработки несложного сайта-визитки в надежных Киевских веб-студиях, приятель в ужасе схватился за голову: он не мог представить, что это может стоить так дорого! Когда приятель узнал, что все это можно сделать и дешевле, но либо в «шарашках», либо у фрилансеров, где нет никаких гарантий — совсем расстроился…

Знаете, это реальная проблема на территориях пост-совка: к сайту компании у нас принято относиться не как к инструменту зарабатывания денег, но как к красивым картинкам и просто фактору престижа. Такой сайт приятно показать друзьям, коллегам, клиентам, жене, в конце концов… но стоит ли он вложенных средств? Да, сайты в экс-СССР стоят очень дорого, как для стран 3-го мира: совершенно реальна ситуация, когда компании, торгующие, например, сантехникой, платят за разработку сайта в Киеве или Москве дороже, чем их коллеги в Нью Йорке или Сан Франциско. Уверен, вы сразу подумали о Студии Лебедева, но на самом деле я имею в виду не только ее, а множество компаний. Кроме того, за рубежом САЛ знают, в основном, как компанию, занимающуюся промышленным дизайном, а не сайтами… Ну, не привыкли там платить за дизайн больше, чем он может принести. Как вы думаете, многие ли компании в России и Украине думают о том, какой ROI будет у их сайта: как быстро сайт окупится и окупится ли вообще?

При таких высоких ценах сайты ухитряются делать с отвратительного качества CMS‘ками, подчас слабее бесплатных Joomla и Drupal, а часто выбирают и просто отвратительный Bitrix…

В интернете можно найти минимальные цены ведущих веб-студий России за 2006 год, как вы понимаете, сейчас эти цены повысились.
А что делать? Ведь нужно платить дизайнерам, которые сделают эксклюзивный дизайн (возможно, и несколько макетов на выбор)… Скорее всего, макет еще придется дорабатывать — и утверждение макета может растянуться надолго… И все это время нужно платить менеджерам, потом верстальщикам надо сверстать макет, еще позже макет нужно будет прицепить к CMS’ке, вполне возможно, что эту самую CMS’ку придется под конкретный сайт доделывать. В общем, не с потолка цены берутся…

Но задумывались ли вы когда-нибудь, что будет, если отказаться от эксклюзивности — если не придется разрабатывать новые макеты дизайна, не придется вносить в них правки и не придется утверждать дизайн, не придется верстать его и не придется подключать сверстанный дизайн к CMS, не придется доделывать эту самую CMS?

Что будет, если подстроить свое видение веб-сайта под уже сложившиеся стандарты? Чем же плохо использование чужого дизайна или просто шаблонного, проданного десятку разных клиентов? А ничем, по большому счету, это не плохо, кроме того, что вы лишитесь понт-фактора. Но подумайте хорошенько, важен ли он для бизнеса?

Представьте себе ситуацию: жители соседних деревень Виларибо и Вилабаджо открыли магазины авто-запчастей — с одинаковым ассортиментом, ценами и уровнем обслуживания. Вскоре оказалось: через интернет можно привлечь много новых клиентов. Деревня Виларибо обратилась в солидную студию веб-дизайна, где им за 100 наноюнитов в два месяца сделали сайт под ключ с эксклюзивным дизайном. По прикидкам жителей Виларибо, затраты на сайт должны окупиться через 12 месяцев. Жители деревни Вилабаджо быстро отреагировали: они пришли в студию поскромнее и заявили: «Пожалуйста, возьмите сайт магазина «Виларибо», измените название на «Вилабаджо», поставьте наш контент и все настройте». Через месяц всего за 25 наноюнитов владельцы авто-магазина «Вилабаджо» получили свой сайт — такой же, как у «Виларибо»…
Прошло полгода… В деревне Вилабаджо праздник — ведь их веб-сайт уже окупился и теперь стабильно приносит прибыль… А жители деревни Виларибо все еще «в минусе».

Конечно, такой подход подойдет далеко не всем: дорогие бутики, студии дизайна, многие банки и страховые компании — у них у всех бизнес зависит от понтов (или престижа, кому как больше нравится), потому им необходим эксклюзив, точно так же и для промо-сайтов нужен эксклюзив, но я имею в виду «сайты-визитки». Но ведь большинству представителей мелкого и среднего бизнеса разработка эксклюзивного сайта в надежной веб-студии просто «не по зубам».

Некоторым кажется, будто шаблонный дизайн хуже эксклюзивного — это фикция: качество и эксклюзивность дизайна никак между собой не связаны. Например, на сайтах большинства софтверных компаний дизайн откровенно убогий, но он эксклюзивен! Более того, в серийных продуктах гораздо проще поддерживать качество на высоком уровне, чем в штучных: отличным примером этого служит McDonalds. В Макдональдс используют шаблонный конвейерный метод, в большинстве ресторанов — эксклюзивный. При этом еда в Макдональдс приготовлена качественнее, чем в большинстве ресторанов. Серьезно! — Она не изыскана, она не красива, она вредна для здоровья, но приготовлена качественно — в точнейшем соответствии с рецептурой, одинаково качественно для каждого посетителя, потому что за ней стоит настолько отточенная система, какую ни один ресторан не сможет обеспечить. McDonalds и прочие фастфуды не уничтожили ресторанный бизнес, но четко заняли свою нишу: в дешевых фастфудах питается гораздо больше людей, чем в дорогих ресторанах. Точно так же постепенно произойдет и с разработкой веб-сайтов: эксклюзив останется только для тех, кому это нужно и кто способен за это платить. Делать все сайты-визитки эксклюзивными — не естественнее, чем увидеть всех женщин на улицах в одежде от кутюр.

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

Но это неизбежно в условиях, когда спрос рождает предложение. Подобные ситуации уже встречались в истории: к примеру, автомобили до Генри Форда тоже были дорогими и не-массовыми, но все мы знаем, что случилось потом…

---

5 советов по управлению проектами

0000-00-00 00:00:00 (читать в оригинале)

Mourner передал мне эстафету: 5 советов IT-специалисту — советы по управлению проектами…
Давать советы кому-то абстрактному не хочется: ведь подойдут они не всем, потому в этой заметке будут советы, которые я нынешний дал бы самому себе четырехлетней давности.

1. Управление проектами — это работа с людьми. Умение завоевать уважение команды и клиентов в тыщу раз важнее умения рисовать диаграммы Ганта. Ни в коем случае не поддавайся рассказам всяких менеджеров-теоретиков, считающих PMBOK важнейшей книгой для управленца: эти клоуны могут долго рассуждать о преимуществах и недостатках методологий RUP, CRYSTAL или XP, но понятия не имеют, что делать, если разработчик длительное время работал с нормальной эффективностью, а потом резко «опустился», они не чувствуют, когда стоит делегировать полномочия, а когда этого делать нельзя.
2. Постоянно учись, читай, постоянно экспериментируй, постоянно сомневайся в себе, совершай ошибки и исправляй их последствия. Ошибок не допускает только тот, кто топчется на месте. Да, постоянные изменения и нескончаемое обучение означают постоянный стресс — и с этим ничего не удастся поделать, но со временем начинаешь спокойнее относиться к собственным ошибкам и неудачам, легче переносить стресс.
3. Бери на работу только тех людей, которые эту работу обожают: тех, кто с гордостью рассказывают о своих заслугах, интересуются твоей компанией, следят за новинками в отрасли. Если этого не соблюдать — легко получишь обыкновенный ленивый офисный планктон, который работает «из-под палки», самостоятельно не обучается и довольно медленно растет в профессиональном плане. Людей, которые в целом любят свою работу, и мотивировать гораздо проще, и работать с ними интереснее. Тебе не нужен сисадмин, мечтающий заниматься журналистикой, или разработчик, который на самом деле хочет быть дизайнером, а код писать ненавидит и каждый раз «переступает через себя», чтобы выполнить новую задачу. Тебе нужны такие люди, которых сам будешь выгонять из офиса, чтобы не просидели до ночи, изучая новую технологию. На эту тему немало эссе написал Джоэль Спольски.
4. Учись отступать и проигрывать. Очень важно уметь вовремя остановить провальный проект. Иногда необходимо отказаться от проекта, иногда — даже уволиться. Запятнанную репутацию нелегко «отбелить». Как ни крути, а у жизни тоже есть свой дедлайн, потому не инвестируй временной ресурс своей жизни в мертворожденные проекты, эти инвестиции не окупятся.
5. Хочешь выстроить четкую систему в работе, наладить процессы, чтобы все было четко и без сюрпризов? Начни с себя: без жесткого контроля собственного времени никак не обойтись. GTD — не только модный акроним, но и реально полезная методология, которая при грамотном обращении поможет убивать в себе оптимизм и не забывать ничего важного. Учись мгновенно принимать правильные решения, много решений… Если не выходит — устанавливай дедлайн принятия решения: и руководство/клиенты, и подчиненные будут тебе за это благодарны.

Интересно, как я буду смотреть на эти советы через 5 лет?

---

Инфраструктура Ruby on Rails

0000-00-00 00:00:00 (читать в оригинале)

С Ruby on Rails в рунете сложилась непростая ситуация: вроде, есть блогеры, о нем пишущие, есть специализированные сайты, но почему-то людям, желающим попробовать рельсы и начинающим rails-разработчикам, найти полезную информацию по Rails крайне трудно.

Знаете, что происходит в итоге? Рождается масса заблуждений препятствующих распространению мощной технологии. Например:

• «Гибкая разработка веб-приложений в среде Rails» — лучшая книга для любого Rails-разработчика» — бред собачий! Это книга «для чайников», не отражающая реалий rails-разработки.
• «Rails — это вещь в себе» — еще больший бред. Rails, вообще-то, обладает мощной инфраструктурой, включающей множество сторонних сервисов и библиотек.

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

Развертывание приложения

В Ruby есть очень мощный инструмент для работы с удаленными unix-серверами — Capistrano. Он же является стандартом де-факто для развертывания рельсов на production/staging серверах.

Принцип работы Capistrano в контексте рельсов простой — разработчик с локальной машины запускает capistrano, который в свою очередь подсоединяется к удаленному серверу через SSH и выполняет ряд команд: вытягивает свежую версию приложения из репозитория, создает для нее отдельную директорию и устанавливает символические ссылки для директорий со статическим контентом, перегружает веб-сервер и другие сервера (например, сервер для полнотекстовой индексации и поиска данных). Большим плюсом Capistrano в сравнении с аналогичными инструментами является поддержка rollback’ов. То есть в случае неудачного развертывания проекта Capistrano откатит все в исходное состояние.

Выше описан простейший пример работы Capistrano, который обычно выполняется с помощью его стандартных рецептов (скриптов). Вообще же с помощью капистрано можно можно разворачивать приложения в нескольких окружениях, можно разворачивать приложения сразу на кластерах серверов, можно на этих кластерах удаленно чистить кеш и вообще выполнять любые команды, которые можно выполнить в консоли unix-сервера. Существуют отдельные наборы рецептов капистрано, например capistrano-ext, Dump или rubaidhstrano, позволяющие автоматизировать резервное копирование баз данных и синхронизировать статические файлы (как и базы данных) в локальном окружении разработчика с production’ом.

Кстати, capistrano совсем не обязательно использовать с рельсами, впервые я с ним столкнулся полтора года назад, тогда с помощью Capistrano мы разворачивали PHP(symfony)-приложения на кластерах серверов.

Нет предела совершенству. В след за Capistrano появились проекты Shadow Puppet и Moonshine. Shadow Puppet — это инструмент для автоматизации настройки самих unix-серверов, с его помощью можно автоматизировать установку всего софта, библиотек, создание пользователей, настройки безопасности — очень полезный инструмент системного администратора. Moonshine представляет собо надстройку над Capistrano и Shadow puppet, позволяющую автоматически настроить «голый» удаленный сервер и развернуть на нем Rails-приложение, имея на удаленном сервере всего лишь пользователя с sudo-правами. К сожалению, в настоящий момент Moonshine поддерживает только Ubuntu Server 8.10 и Git-репозитории.

Существует альтернатива Capistrano — Vlad the Deployer, он проще в использовании, но на фоне Capistrano функционал Влада кажется скудным.

Профилирование, мониторинг производительности, слежение за ошибками

Представим, что вы запустили свой rails-проект. Он оказался настолько удачным, что новость о нем появилась на главной странице Wired или Digg. После чего проект в лучшем случае стал работать очень-очень медленно, в худшем же просто повалился нахуй. После этого работа резко принимает авральный характер, вы анализируете тонны логов, заново прогоняете стресс-тесты и прочими способами пытаетесь найти узкие места в системе и устранить проблемы.

Задачу профилирования и мониторинга производительности решают такие сервисы, как Five Runs, New Relic и Scout. Функциональность у всех трех похожа, потому расскажу о таких средствах на примере NewRelic’а, являющегося лидером тройки.

Когда приложение развернуто в production-окружении, начинает работать специальный rails-плагин NewRelic RPM. Он собирает информацию о каждом запросе к приложению, о каждом запросе к базе данных, времени выполнения этих запросов (и, соответственно, времени загрузки страниц), нагрузке на процессор, вызванной этими запросами. Время от времени эти данные отправляются на сервер NewRelic фоновым процессом. После этого на сайте NewRelic’а можно посмотреть множество отчетов, показывающих, например, самые медленные контроллеры, самые медленные SQL-запросы и отдельные транзакции, причем, легко можно посмотреть использование индексов в запросах. Кроме того, NewRelic хранит статистику, потому можно отслеживать динамику нагрузок, удобно сгруппированные отчеты об ошибках (мы же не хотим читать длинные логи?) и многое другое.

Естественно, можно использовать NewRelic и в development-окружении, в этом случае он является больше инструментом профилирования, нежели мониторинга и статистики.

Для тех, кому не нужна настолько подробная (и дорогая) статистика, которую дает NewRelic, но нужно удобно отслеживать ошибки, происходящие на production-серверах, есть простой сервис — HopToad. Можно, конечно, для этой цели пользоваться rails-плагином с говорящим именем «Exception Notifier», но он может в определенных ситуациях может неприятно заспамить ваш почтовый ящик.

Тестирование, проверка качества кода

Честно говоря, автоматическое тестирование — один из моих любимых аспектов Rails, такое обилие разнообразных крутых инструментов тестирования я видел, пожалуй, только в Java.

По умолчанию рельсы используют стандартный рубишный Test::Unit в качестве тест-фреймворка. Однако, в последнее время все более модным становится т.н. Behavior Driven Development, и в руби появился свой BDD-фреймворк — RSpec, который плотно интегрируется с рельсами. Судя по коду разных современных проектов, RSpec в ruby-мире сейчас даже более популярен, чем Test::Unit.

В RSpec входит собственное средство для создания mock-объектов (необходимых, например, при тестировании контроллеров), однако вместо него можно использовать более развитые Mocha и Flex Mock.

С целью минимизации времени, затрачиваемого на рутинное написание тестов, был разработан Shoulda — набор макросов для совместного использования Rails и Test::Unit. Посмотрите, насколько более простым и читабельным он делает код тестов. Специально для людей, предпочитающих RSpec был выпущен аналог Shoulda под названием Remarkable.

Для заполнения приложения тестовыми данными в рельсах по умолчанию применяется механизм fixtures, однако это не всегда удобно, например, в случаях, когда нужно сгенерировать много сущностей, — в таких случаях на помощь приходит генерация через фабрики объектов, наиболее известным средством для этого в рельсах является factory_girl.

Хотите «настоящего» BDD, чтобы можно было описывать требования к будущему функционалу простым языком и в итоге превращать их в функциональные/интеграционные тесты? — попробуйте Cucumber. Если вам, как и мне, Cucumber кажется излишеством, существует другой мощный инструмент — WebRat. Задача «крысы» — интеграционное тестирование, то есть пройтись по страницам сайта, прокликать формы, убедиться в том, что сервер вернул ожидаемый результат. Сценарии WebRat писать очень просто и он интегрируется с любыми тест-фреймворками для Ruby. В обычном режиме работы WebRat’у даже не нужен броузер для прогона тестов. Однако бывают ситуации, когда нам необходимо тестировать операции, выполняемые JavaScript’ом, в этом случае WebRat можно запустить в другом режиме работы: он будет использовать Selenium(который, в свою очередь, использует броузер) для прогона тестов. Поддерживать же подобные webrat-тесты ощутимо проще, чем чистые Selenium-тесты.

Специально для проверки уровня покрытия кода тестами существует инструмент RCov. Кроме RCov, существуют инструменты для автоматической проверки сложности кода и просто «детекторы говнокода». Их можно запускать по отдельности, а можно воспользоваться metric_fu, включающим в себя все эти проверки вместе с rcov.

Непрерывная интеграция

При работе над масштабным проектом, или просто в случае распределенной разработки часто возникают проблемы из серии «Петя, после твоего коммита опять сломался билд, срочно чини!» или более характерное для славянских программистов «Ебаный в рот! Кто сломал билд?». Одним из очевидных спобов решения таких проблем является «непрерывная интеграция». Для Ruby в целом и рельсов в частности существует своя версия известного CI-средства — CruiseControl.rb. Существует также альтернатива — Integrity, но ее я ни разу не пробовал.

Сервера приложений

Стандартным сервером приложений Rails является однопоточный Mongrel. Как правило, его запускают кластером из нескольких серверов, после чего балансируют нагрузку между ними при помощи apache или nginx. Такой способ запуска Rails-приложений является наименее эффективным (с точки зрения потребления ресурсов) из всех возможных.

Лучшим решением запуска rails-приложений является Phusion Passenger (также известный как mod_rack и mod_rails). Passenger встраивается модулем в веб-серверы Apache и Nginx и динамически выделяет ресурсы рельсам, подобно mod_wsgi для python и mod_php для PHP. Естественно, это позволяет экономнее расходовать ресурсы сервера и упрощает развертывание приложений.

Для полноты картины стоит отметить Thin. Это сервер, работающий аналогично Mongrel’у, но быстрее и потребляя при этом меньше ресурсов.

Асинхронное выполнение задач

Существует ряд задач, которые выполняются сравнительно долго, например, конвертация видео или загрузка файлов на Amazon S3. Такие задачи желательно (а во многих случаях — обязательно) выполнять в фоне. Долгое время наиболее распространенным инструментом асинхронного выполнения задач в рельсах был BackgroundRB, однако brb потребляет неприлично-много ресурсов, потому рекомендую альтернативный инструмент — Workling.

По умолчанию Workling работает в паре с message queue сервером Starling, разработаным изначально для Twitter’а, однако не советую использовать Starling в production’е. Вместо старлинга можно использовать любой amqp-совместимый сервер, например, RabbitMQ или ActiveMQ.

Мониторинг процессов

Одним из главных недостатков Ruby являются утечки памяти. В Ruby Enterprise Edition и Ruby 1.9 эту проблему частично решили. Но в суровые времена, когда все гоняли рельсы сугубо на Mongrel’ах и Ruby 1.8.6, проблема стояла значительно серьезнее, чем сейчас, потому необходимым было средство, которое следило бы за процессами Mongrel’а и перегружало его при достижении лимита потребляемой памяти. Чаще всего для этих целей использовали совсем не рубишный Monit и его Ruby-аналог — God (который, на мой взгляд, значительно удобней и гибче в конфигурации). Доходило даже до того, что все процессы мониторили God’ом, а сам God — Monit’ом.

К счастью, ситуация стала лучше, но God и Monit (который использовался и используется для мониторинга баз данных, веб-серверов и многих других вещей в unix-системах) все еще остаются простыми и удобными средствами мониторинга процессов, сфера применения которых выходит далеко за рамки перегрузки Mongrel’а при достижении лимита памяти.

Запуск консольных команд

Давно уже для Ruby разработали Rake — инструмент для автоматизации сборки программного кода по типу GNU Make или Apache ANT. Но, в отличие от Make и ANT, Rake-скрипты пишутся на самом Ruby, что сделало их легко расширяемыми и более удобными в написании. В итоге в Rails стали использовать Rake для выполнениях любых консольных команд, например, для запуска тестов, миграций или обновления Rails.

Также существуют дополнительные наборы Rake-задач, выполняющие рутинные операции, например: создание резервных копий базы данных и статических файлов rails-приложения, отображение информации о внешних ключах в базе данных, для которых нет индексов, и многие другие. Отличные примеры дополнительных rake-задач для Rails — limerick_rake и dump.

Визуализация объектной модели

В данном случае лучше один раз увидеть. RailRoad рисует диаграммы объектной модели ваших Rails-приложений. Посмотрите примеры моделей и контроллеров.

Специализированый хостинг

Большинство коммерческих Rails-проектов хостятся на VPS’ах, выделенных серверах и cloud-хостингах вроде Amazon EC2. Однако существуют и специализированные Rails-хостинги (большая их часть — это все те же VPS’ы и надстройки над EC2, куда уже установлены популярные ruby/rails библиотеки, apache с passenger’ом и.т.п.).

• Heroku
• Engineyard
• Rails Machine
• Brightbox

Среды разработки

Существует стереотип, будто все rails-разработчики используют для разработки либо TextMate на маке, либо юниксовые vim/emacs/gedit, и для Ruby/Rails нет «взрослых» IDE.

Отчасти это правда, действительно подавляющее большинство Rails-разработчиков не пользуются IDE, но далеко не все! Качественные IDE для Ruby существуют: Aptana RadRails на основе Eclipse, JetBrains RubyMine на основе IntelliJ Idea, NetBeans (который мне не удалось запустить на маке). Лично я предпочитаю RubyMine за его отслеживание ошибок в коде, автодополнение, удобный поиск внутри проекта, отладку кода прямо в IDE и автоматизацию рефакторинга.

В целом, как мне кажется, ситуация с IDE для Ruby хуже чем у Java и .NET, но лучше, чем у Python и PHP.

Вместо заключения

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

Статья написана для сайта developers.org.ua