1. Хороших сотрудников нужно искать постоянно.
2. Хорошие сотрудники есть и они обязательно найдутся, если следовать п.1.

Ну а теперь про качества этого самого идеального программиста.

Личные качества

Неконфликтность, дружелюбность. Представьте: заказчик – это приложение, проект-менеджер – драйвер, программист – биос. Приложения обычно не обращаются к биосу напрямую, они используют для этого драйверы. Биос выполняет допустимые команды драйвера и не конфликтует ни с драйвером, ни с приложением. Такой конфликт в компьютере приводит к синему экрану смерти. Программист должен осознавать свою роль как специалиста в программной части сайта и роль менеджера как своего защитника перед необузданной фантазией заказчика. Программист должен понимать, что менеджер – это его соратник, с которым они могут сделать проект лучше и качественнее.

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

Чувство юмора. Уныние – грех. Все унылые люди должны работать в сберкассах и в отделениях связи. К этому я уже привык при оплате ЖКХ. Делать сайты нужно весело. Мы работаем в современной, динамичной сфере. По интернету бродят Медведы, Упячки, Онотоле, Трололо и прочие замечательные мемы. Несколько раз в день есть повод для бугага. Если во время работы сотрудник не может со всеми тупо поржать – это не значит, что он серьезный спец. У него просто проблемы с социализацией, а такие не могут работать в команде.

Адекватное ЧСВ. Часто у программистов с этим проблемы. Ведь в этом непонятном коде мало кто че понимает. Вот и возникает ощущение что ты шаман и делаешь всегда все правильно. А тут эти неорганизованные менеджеры лезут с доработками. Хотя щас становится все лучше. Технологии так быстро развиваются, что даже сисадмины уже не могут годами пить пиво, глядя на настроенный сервер. Перемены делают айтишников постоянными студенами, а значит постоянными недоучками. Вот такой нам и нужен – вечный ученик.

Профессиональные навыки

PHP/MySQL. Если вы не родились со знанием PHP – его просто нужно выучить. На это нужно время. Мне на это понадобилось года 2. Одаренная молодежь я думаю за годик управится. Мы не можем учить PHP программиста в офисе. Нет, я не КО, я реально получил много резюме от людей на должность PHP программиста, не знающих PHP. Знать язык – это не значит досконально знать синтаксис. Нужно уметь решить любую задачу с использованием языка. Неважно на сколько грамотно, главное быстро и прозрачно.

Фреймворки, сервисы, новинки. Программист должен быть в курсе происходящего вокруг него. Он должен просто пожирать все новую и новую информацию. Не читаете IT блоги, не следите за развтием Гугла, не знаете тенденции стартапов – во просто IT мусор, милый старый Wall-E, не более. Быть в курсе очень трудно. Это тоже работа. Нужно следить за развитием PHP, JS, CSS фреймворков, всякими API, появлением новых технологий, долей IE6, кармой Boomburuma.

HTML/CSS. Веб-программист должен уметь верстать. Да, вот прям взять PSD макет и сварганить HTML, CSS и кучу картинок. Если человек работает в этой сфере и не верстает или просто «читает» HTML – он профнепригоден. Конечно такие слова могут обидеть серьезных спецов, считающих, что верстка – это удел дизайнеров или низкоквалифицированных верстальщиков. Но правда состоит в том, что верстка HTML страницы – это программирование на языке HTML и CSS. Это часть вашего кода, которая должна работать вместе с серверными скриптами как оркестр. Современный сайт невозможен без тесной интеграции сервера и клиента. И все чаще функционал переползает на клиента.

Javascript. Не знаете javascript? Наверное вы пишете парсеры и серверные API. Если это не так – вы профнепригодны. Для веб-программиста должен быть открыт  мир jquery, mootools и других замечательных фреймворков. Веб-приложения прекрасно стилизуются с помощью jqueryui. А ведь веб-приложения – это будущее. Эт тенденция. Сайты постепенно превращаются в агрегаторы различных API. Еще пара лет и вы забудете что такое аплоад файлов на сервер. Вместо этого будут сервисы хранения, сервисы обработки и сервисы отдачи данных. И этому учиться нужно уже сегодня.

Идеальный программист – это не какой-то супер человек, все это умеющий и обладающий всеми перечисленными качествами. Такие люди есть и у нас в городе. Но как правило они испорчены другими работодателями ввиду отсутствия стимулов к развитию. А главный стимул – интересные и сложные, даже невозможные задачи. В поточном сайтостроительстве от программиста многого не требуется. На тебе верстку, на тебе bitrix/umi/netcat – прикрути все это. Отсюда и термины, в которых программисты описывают свою работу: прикрутить модуль, собрать сайт, натянуть дизайн, поднять на движке, установить шаблон. Все это задачи не для программистов. Это низкоквалифицированный труд, и оплачиваться он должен скудно. Нам нужны, если говорить юридически, законодатели, а не правоприменители.

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

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

Решения тут 2 (ну если не усложнять):

- Флэшер. Либо дилетант, который зафигачит карту и зашьет туда все данные по участкам. Либо профи, который организует ajax подгрузку контента.

- Карта на javascript/css/html с подгрузкой контента с сервера.

Проблема в обоих случаях будет одна и та же. Как наносить на карту участки? Я думаю существует немало решений этого вопроса. Хочу рассказать как его решали мы.

Писали мы для одного сайта такой контрол в админку, который позволяет отмечать на картинке точки и сохранять координаты в БД. Вот так, например:

Ничего особенного. Просто при заполнении описания девушки на большой картинке ставится точка, которая будет якорем для описания.

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

После завершения фигуры с сервера подгружается пнгшка, отрисованная по коодинатам точек

Ну я не отличаюсь аккуратностью выделения объектов, как это видно из картинки, однако идея я думаю понятна, тем более участки на плане поселка несколько «поквадратнее» и их легче обозначить.

Все, объект сохранен в базе. Осталось его показать посетителям сайта.

Для этого делаем прозрачную картинку, размером с фотографию, которую размечали. К этой картинке прикрепляем MAP cкучей AREA типа POLY. Координаты берем из базы. Для красоты на движения мыши навешиваем подгрузку прозрачной пнгшки, где цветом залита выделенная область и получаем что-то типа вот этого:

http://zdemo.magwai.ru/point

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

Весь исходный код этого и других примеров доступен с http://github.com/magwai/. Также на скорую руку сделан сайт о zkernel – ядре, на котором основан код наших сайтов: http://zdemo.magwai.ru/. Он будет пополняться новыми примерами и описаниями работы zkernel. Исходный код этого сайта также доступен в репозитории на github.

Вот список текущих (на мой взгляд) тенденций веб-разработки:

- Возрастающая динамичность сайтов: ajax, json, canvas, svg, js фреймворки.

- Важность клиентской оптимизации: сжатие js, css, корректные заголовки, кэширование статики, спрайты, быстродействие селекторов в css.

- Интеграция различных веб-сервисов: google (карты, календари, контакты), picasa, panoramio, всякие фиды (rss, atom), twitter, авторизация по openid.

- Медиа возможности: интеграция видеоплееров, хранение видео в аккаунте youtube, потоковые трансляции, интеграция javascript и flash интерфейсов.

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

Как со всем этим жить? Сложно. Нужно постоянно развиваться, быть в курсе тенденций, развития библиотек, узнавать о появлении новых плагинов в этим библиотекам, быстро все это интегрировать и использовать новшества как конкурентные преимущества.

Как мы отвечаем на все эти вызовы? Изменяемся. Постоянно пробуем новое. Сначала мы хотели развивать свои наработки в полноценную CMS. У меня есть опыт создания и развития движка сайта. Начался он конечно на предыдущем месте работы: веб-студии Интерволги. Где для нужд портала volga34.ru был написан движок kernel (iKernel вроде сейчас продолжает существовать на нескольких десятках сайтов, ну и на Волге34 естественно). Но то был именно «движок», набор скриптов с навешенной на них админкой. На основе заложенных в него идей я попытался сделать CMS. Хотелось в 2 клика создавать сайты. Результат: vizitka.magwai.ru. Продукт, подзабытый нами ввиду отказа от создания неадекватно дешевых сайтов. В пике своего развития на нем были написаны сайты: modno-byt-rebenkom.ru, rabota498.ru, viaborse.ru.

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

Постепенно сформировались требования к программной основе сайтов нашей студии:

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

- Не должна заставлять проект-менеджеров думать в рамках системы. Чтобы новости могли быть не только списком сверху вниз, но и по кругу и летать могли, и прыгать. Чтобы не было понятия модуль, блок, сетка. Выдали на верстку Джаконду – программируем Джаконду, чтоб не только смотрела загадочно, но и подмигивала.

- Должна быть стабильна, масштабируема и модульна. По себе заметил, что пик эффективности разработки наступает через пол года после освоения библиотеки. Важно, чтобы за пол года библиотека не оказалась на обочине прогресса. Мы не можем рассчитывать на то, что модно. Нужны проверенные технологии.

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

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

Итак, мы выбираем ZendFramework. Эта библиотека отвечает всем указанным требованиям. Переход на нее планировался 6 месяцев, 3 из которых были посвящены разработке собственной среды (оболочки) для удобного сайтостроения и интеграции компонентов ZendFramework с десятками других библиотек. Эта оболочка была оформлена в виде отдельной библиотеки, включающей в себя множество php классов для задач: построения панели управления, работы с графикой, javascript, css, множество js компонент (jqueryui, datagrid, colorpicker, uploadify…). Название этой надстройки над Zend – Zkernel.

Zkernel лицензирована как опенсорс. Под самую открытую лицензию – MIT. Для проекта создан репозиторий на github. Исходный код ядра наших сайтов может быть просмотрен кем угодно, и кем угодно использован для создания своих сайтов или интеграции в другие системы.

ZendFramework будет использован на всех последующих сайтах студии. Ну а в данный момент мы можем продемонстрировать достаточно крупный интернет-магазин, написанный полностью на новой системе: palerom.ru. Это хороший пример для демонстрации возможностей движка, потому что на Палероме есть все: корзина заказов, видео, формы чата,  каталог на несколько тысяч позиций, поиск с использованием Lucene, генерация xls прайса, система управления с разделением прав на админов и менеджеров, система рассылок и внутренняя почта сайта.

Ааа, только не спрашивайте нас больше, что у нас за CMS. У нас нет и не будет CMS! Увы, пока не сделали станок для создания шедевров живописи. Неужели вы думаете, что кто-то уже написал для него идеальную программу?

Последнее время узким местом сервера стала его способность отдавать миру несколько десятков гигабайт картинок в сутки, так как мы хостим проект, генерирующий кучу подобного траффика и попутно других проблем. Решение у меня появилось уже давно благодаря нескончаемым постам на хабре. Это nginx. Но подступиться к нему было боязно: все-таки сервер у нас один и находится он не в одной тысяче километров отсюда. Но когда-то нужно было начинать. Итак, сейчас мы имеем прекрасную связку apache2 + nginx 0.7. Все оказалось невероятно просто: ставим nginx, убрав все лишнее из опций сборки, переводим апач с порта 80 на порт 8888, пишем правила в nginx.conf, которые делают его ответственным за всю статику, все динамическое перенаправляем на тяжелый апач.

Результат поражает. Нагрузка на процессор снизилась раз в 10. Время открытия страниц сократилось в 4 раза, все заголовки статики в норме, все что нужно сжимается gzipом. Субъективно сайты с нашего сервера просто летают. Ну как пример можно покликать по magwai.ru. В логах апача осталось только то, что требует php – все остальное отдает nginx.

Рекомендую всем, кто думает о покупке еще одного сервера

Что я пробовал для JavaScript:

1. Хранить minified версии нужных скриптов на сервере, а при отдаче клиенту склеивать их в один файл, затем сохранять его в кэше. При последующих обращениях склеенный файл просто отдается как статика с корректными заголовками и e-tagом от апача. Именем файла является md5 от всех имен подключенных скриптов. Недостатком является «немобильность» кэша. Единожды созданный он разрастается до больших размеров при изменении исходных файлов и по сути на каждую версию скриптов создается по файлу – плохо для разработки. Также отсутствует контроль заголовков скрипом сайта.

2. При загрузке страницы делать запрос на JavaScript, в котором закодированы имена всех нужных файлов. Сервер отдает JavaScript динамически с проставлением нужных заголовков. Недостаток – нечитаемый и длинный URL для JavaScript, ограничение на длину запроса (т. е. нельзя подключить много скриптов).

3. Используемый сейчас метод. Сжатие вообще всех JavaScript сайта с помощью установки хэндлера апач.

Action mh «/x_gs/»
AddHandler mh .css .js

То есть любой скрипт будет обработан php скриптом по адресу /x_gs/. Там происходит сжатие скрипта с помощью yuicompressor и его отдача. При этом контролируются все заголовки: Expires устанавливается на месяц вперед, Last-modified равен дате изменения файла скрипта, e-tag – md5 от имени файла + дата модификации Все это обжимается gzip. При повторном запросе проверяется e-tag и last-modified. Это позволяет при последующих обращениях отдавать только 304 ответ. У этого подхода есть недостаток – при большом количестве посещений можно нагрузить сервер сжатием yuicompressor. Например jquery 1.3.2 в среднем жмется около 500 мс – очень долго. Для обхода этой проблемы сжатый скрипт кэшируется в memcached с ключем – именем файла + дата модификации, что позволяет использовать такое кэширование на всем сервере сразу, а не в рамках отдельного сайта. Если на хостинге нет java – используется JSMin.

Что я пробовал для CSS:

Практически то же самое, за исключением той особенности CSS, что нельзя просто склеить все цсски в 1 файл, если они из разных каталогов, так как background картинки в них прописываются относительно положения файлов. Сейчас CSS отдается так же как и JavaScript. Сжимается тем же yuicompressor. Если нет java – CSSTidy.

Результат очень неплох. Размер скриптов минимален. Разработку вести удобно, так как нет кэшей, которые бы не зависили от времени изменения файла. Никаких каталогов к эшами. Нагрузка на сервер упала, так как в большинстве случаев видим 304 ответ. Особенно приятно видеть, что сжимается не только то что я использую на самом сайте, но и скрипты MCE/FCK редакторов в панели управления.