livedev.org

Сегодня важное событие у меня. Я наконец-то смог выродить подкаст о веб-разработке, который планировал оч давно записать. Даже не только планировал, но и пробывал. Итак, это моя третья попытка — более-менее удачная. Не могу сказать что я на 100% доволен результатом, но как говориться «первый блин можно и простить» :-)

Для меня намного важнее узнать ваше мнение, уважаемые читатели! На сколько вам был бы полезен вообще подкаст о веб-разработке. И о каких темах вы бы хотели услышать выпуски в будующем. Любые ваши комментарии (желательно конструктивные) будут мотивировать меня для дальнейшей записи. А так как я не диктор и не работал никогда на радио, дается мне сие записывание нелегко... Так что хотелось бы знать интересно ли будет что-то подобное для вас. Жду фидбека, а пока качайте 10 минутное mp3 весом в 14Мб :-)

Отдельный фид для подкаста скоро будет.

Update: сделал еще копию подкаста с битрейтом 128 на 10Мб

Долго не мог принять эстфаету от Ивана — 5 инструментов хе-хе. Загруз был последнее время, но буду исправляться. Написал свой скупой список из пяти наиболее используемых инструментов в работе. Кого что-то заинтересует более подробно — спросите в комментариях, с удовольствием расскажу.

1. MacBookPro — это действительно инструмент, такой как рубанок, дрель или лопата :-) Отличное устройство, я использую его мощь на полную катушку. Не буду особо распыляться как все круто, т.к. пиара маков в сети куча и без меня...

2. Из софта — TextMate. Это мега-удобный редактор. Программирую и пишу статьи в нем.

3. Шелл (shell) или терминал или командная строка — это то, что позволяет мне работать с файлами и процессами на компе эффективно.

4. Firebug — наше все для дебага javascript/ajax и css.

5. Зеленый чай с лимоном (особенно в холодное время года). Горячее меня бодрит и заставляет мозги думать лучше, плюс кофеин и витамин C из лимона поднимают тонус.

Пост для поднятия настроения в понедельник :-)

Коллега вчера вечером прислал ссылку, я посмеялся и отправил товарищам по проекту. А сегодня утром подумалось, что будет весело всем.

via ehlo - by Luchian Alexandru

Хочу поделиться своими впечатлениями о работе в моем текущем проекте глазами разработчика, так сказать изнутри.

А если точнее то своим впечатлением от управления проектом по методологии agile. На сегодня слово agile уже набило оскому, не смотря на то, что точного перевода этого английского слова (в отношении к разработке) я еще не встречал. Поэтому все так и пишут — в оригинале. Как же эта красивая теория приживается на практике, в злободневной рутине?..

Лично мне до сих пор не понятно, почему именно разработчики в таком восторге от очередной новой теории управления проектами или методологии разработки. Ведь если разобраться, то любая из них направлена на то, чтобы выжать из команды максимум возможного результата (читай «заставить работать на полную катушку»). Что в принципе вполне оправдано со стороны начальства и заказчика, но в итоге не всегда легко решается самими разработчиками. Я не пишу, что agile — это зло или просто очередной «гемор» для разработчика, но он им может стать…

Итак, главная фишка agile методологии разработки — это непосредственное общение внутри команды, с минимумом спецификаций и других технических документов и с максимумом реального общения. Т.е. когда заказчик (или бизнес-представитель) сидит рядом с разработчиками и рассказывает что, как и где должно работать (очень упрощенное объяснение). Наиболее распространенный вариант agile-разработки — scrum еще подразумевает ежедневные встречи команды для кратких отчетов кто над чем работает и что собирается делать в ближайшие рабочие часы. Плюс процесс самой разработки делится на итерации (иногда так называемые «спринты») — временные отрезки с набором задач. В конце каждой итерации, понятное дело, подбивается итог и по общей успеваемости разработчиков можно рисовать картину успеваемости самого проекта.

Про преимущества agile, scrum и остального зоопарка по управлению проектами вы найдете кучу статей, а вот про недостатки я расскажу далее. На самом деле в самих теориях управления проектами как правило все гладко, но мы то знаем, что теория не стопроцентно ложится на рабочую действительность. Итак, типичные проблемы, которые появляются в работе agile-команд:

• команда распределена регионально (в смысле люди сидят в разных зданиях); сильно ухудшает коммуникацию; на самом деле при таком раскладе нормальный agile почти невозможен;
• бизнес/заказчик все таки пишет подробные спеки; в этом случае пролеты гарантированы, т.к. скорее всего спеки нормально писать в agile темпе никто не сможет;
• командой управляет не технический менеджер или менеджер который не может прочитать/подправить код; это просто беда, такой менеджер скорее всего будет стопорить работу лишними вопросами и пустыми разговорами;

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

Итак простой вывод для читателей-разработчиков: если на собеседовании на новую работу/проект вы услышали волшебное слово agile, не спешите радоваться :-) позадавайте побольше общих вопросов о команде, менеджерах и заказчиках.

Любой разработчик часто или не очень, но решает этот вопрос. Всё зависит от того насколько часто вы меняете работу или учите и используете что-то новое (языки, технологии и т.д.)

Обычно при выборе решают такие вопросы:

• какую ось выбрать;
• какой ide;
• как организовать исходники;
• опционально: как организовать команду;
• важный вопрос по организации самого кода;
• стоимость платформы (да бывают и платные компоненты :-)
• скорость развертывания платформы;
• насколько будет портабельно приложение.

В принципе можно много всего перечислить, но это что пришло в голову сразу.

На самом деле на такие темы можно книги писать. Я просто напишу пару наблюдений. Всё дело в том, что практически под каждый язык программирования приходится искать почти с нуля решение по платформе. Но как правило любая команда/фирма/фрилансер уже имеет свой джентельменский набор интсрументов и обычно всё обходится его небольшим дополнением/модификацией.

Лично я и моя команда сейчас наоборот только в поиске интсрументов, с платформой уже определились. Мы выяснили несколько важных вопросов для себя.

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

Поэтому я хочу чтобы мы разделили платформу с понятием инструмента. Для себя я решил назвать платформой тот минимум, без которого приложение просто не сможет работать + систему контроля версия исходников. Т.е. это ОСь, необходимые библиотеки и сервер приложений/интерпретатор для языка. Всё остальное остается на усмотрение программиста. Я просто могу предложить проверенные инструменты для конкретного частного случая, не более.

Итак, если коснуться конкретики… Наша команда занимается веб-разработкой. Это сайты и веб-приложения средней сложности. На данный момент я активно использую python + django, но бывает еще приходится возвращаться к php. Для веб-приложения очень важен момент портабельности, поэтому выбор платформы в плане ОСи уже пал на юникс. Большинство хостинговых серверов работает на юниксе. Плюс мы делаем портирование при необходимости на винду.

Но в целом программист остается свободным в выборе интсрументов. Есть тестовый сервер, на котором всё должно работать, он просто делает периодические сверки и тесты работоспособности системы. Конкретизируя, приведу пример. Если человек работает на винде, то обычно он использует vmware с юниксом для основной разработки. Если человек изначально работает под юниксом, всё намного проще. Весь софт работает тогда под родной системой. В любом случае в нашем случае программист подстраивается под целевую ОСь, на которой всё будет работать – это и есть ограничение, остальное на его усмотрение.

Конечно же в любой команде есть свои правила по написанию кода, форматированию и документированию, но это уже не относится к теме.

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