HackDay #21 - заметки игрока

Начну с брюзжания: с того, что многое можно было предсказать еще до открытия. Просматривая вечером в пятницу список проектов, я понимал, что играть в принципе не за кого. Сугубо субъективное ощущение, но именно такое. Было несколько более-менее "съедобных" вариантов, но ни от одного не "текли слюнки". Сперва думал вписаться на проект "приятельских займов", но потом решил присоединиться к Антону Колмакову на проект "покупки автобусных билетов".

Почему? У Антона есть определенный менеджерский талант (весьма важный, на мой взгляд) - команды под его руководством достигают результата без напряга, как нечто само собой разумеющееся. А потому было ясно, что в этой команде "если и не догоним, то хоть согреемся" (то есть игра будет занимательной). Да и проект был в общем-то симпатичный с точки зрения моей субъективной этики (в отличие, например, от проекта "торговли друзьями").

Итак, на момент старта заявлен 21 проект. ( http://hackday.ru/events/hackday-21/projects/ Да, странное совпадение с названием мероприятия. "Видимо, это карма..." Хотя нет, я ошибся - реально их было 22 - проект с "игрой в мячик" не был объявлен заранее.) К финишу пришли лишь 10, остальные тихо слились где-то между началом и окончанием. Некоторые эмоции на эту тему мне случилось пронаблюдать. Как жалобы инициаторов проектов: "- Я такую классную бизнес-идею придумал. Думал, как набегут программисты, да как все сделают... И где?" А вот не набегают, и более того, значительная часть программистов ушла сразу после первичных презентаций. Ибо "невкусно". И на мой взгляд, это был важный урок мероприятия: программистам далеко не все равно, над каким проектом работать и обещания будущих золотых гор здесь недостаточно. С одной стороны, существует такая штука, как интуитивный "фермерский здравый смысл", который подсказывает, что "золотых гор" не случится. А с другой,.. в коридоре я услышал фразу об одном из проектов: "- Мараться не хочется, слишком дурно пахнет..." Короче, у части "бизнесменов" наблюдалось сильно искаженное представление о разработчиках.

Оставим в стороне двенадцать "растворившихся" проектов (пожалел только о том, что не увидел "скандинавских карт", остальные - ушли и ушли). Скажу о десяти оставшихся. Здесь тоже не все гладко. Макеты приложений из них предоставили только четыре или шесть (в зависимости от того, считать ли "макетом" одну страничку с кнопкой загрузки файла). Остальные же четверо ограничились только презентациями. И хотя среди них были полезные идеи (типа "голосового твиттера для слепых"), но все же задачи HackDay ни в плане формирования команды, ни в плане проверки реализуемости идеи на макете выполнены не были (если считать, что ставились именно заявленные задачи, конечно). Остается четыре проекта. О них подробнее. Жюри не стало называть победителей, и вроде как получилось, что "все равны", но я выстрою собственный субъективный порядок, отложив в сторону идеи (и так о них много сказал) и ориентируясь только на работу за два дня.

Начну безусловно с проекта "приятельских займов", который повел Антон Патрушев. В команде - два программиста и дизайнер. Делали (если не ошибаюсь) на Python. И то сказать - молодцы ребята. И хотя на итоговой демонстрации программа "упала", все равно было видно, что сделано много. Антон вроде бы расстроился из-за этого "падения", но для проекта с таким количеством интеграции (например, с sms), требующих серьезной отладки, времени на которую не было - все нормально. Я поставил бы в минус только сырость основной идеи. Чисто субьективно я бы таким сервисом не стал пользоваться, что-то там сильно отталкивает. Но с другой стороны, у нас ведь по правилам игры "День Хакера", а хакеры о таких нюансах не обязаны задумываться.

Следующий проект, в котором команда "круто поработала", - портирование на мобильники браузерной игры в мячик (не помню, как она называется). На чем писали, не знаю. Команда - четверо разработчиков, давно знакомых между собой и работающих вместе. Ну что сказать... портировали. Можно было играть. Правда, получилась некоторая лажа с "физикой" (мячик оказался куда тяжелее игроков), но это правится. Коммерческий элемент тут не заявлялся, да и незачем (типа "истинные хакеры"). А ребята оттянулись по полной, и это было видно.

Дальше скажу о нас. Проект "покупка автобусных билетов", инициатор Антонов Степан, а я и Колмаков Антон как бы "примазавшиеся". Итого, в команде три человека, два менеджера-маркетолога и один разработчик. В связи с таким ролевым составом, основной акцент был сделан на проработку бизнес-идеи, а макет я писал только "в поддержку". Работалось классно, Степан веселый парень и "электровеник", задавал и настроение, и темп. (Уже придя вечером домой, заметил, что говорю несколько быстрее, чем обычно.) Хорошо, когда в команде есть люди с такой энергией. А Антон направлял все это в конструктивное русло. Писал я на RubyOnRails. Когда стало ясно, что дизайнера/верстальшика нам не найти, решил взять (и изучить попутно, раз уж случай представился) один из css-фреймворков. Остановился на blueprint.css и, надо сказать, он мне существенно помог не отвлекаться на нюансы верстки.

И четвертый проект, в котором макет был, это проект "заявок на документы" Саши Чернина. Он меня крайне огорчил. И дело даже не в том, что Саша показывал то, что сделал в последние часы, а труд бессонной ночи отправился в …

Один слой ошибок Саша назвал сам: "технология Х - гадость", а "технология Y требует лишку времени и от нее пришлось отказаться". На мой взгляд, этот слой - не главный. Важнее то, что называют "стратегией выхода по неудаче", или говоря простым языком - "сползать с елки вовремя". Понятно, если пробуешь новую технологию, она может оказаться "гадостью". Или какая-то технология может не подходить к проекту. Но... я, честно говоря, имел иллюзии, что технологическая интуиция и опыт позволят разработчику и менеджеру в одном лице распознать это раньше, чем написана первая строчка кода. Ну или уж по крайней мере, сориентироваться при первых же тревожных звоночках. Однако... Говорю об этом столь подробно, поскольку неумение "вовремя вернуться", на мой взгляд, достаточно распространенная беда в компании. (Более того, упорная долбежка лбом в стену тупика у нас порой почитается за "достоинство" разработчиков, хотя говорит только о непробиваемости лба.) В общем, грустно. Сильно этот эпизод мне сбил настроение от игры. Саш, извини, за обсуждение, но эмоции...

Highload++ 2011 (заметки с конференции)

Сайт конференции.

Лично для меня новой информации немного. Но послушать было интересно и временами забавно. Поэтому описываю здесь личные субъективные впечатления.

День первый. "Жесткий PR" Erlang.

Я очень хорошо отношусь к этому языку и платформе OTP в целом (когда-то давно имел возможность на ней поработать), но все же подбор докладов оказался несколько специфическим. Рассказывались success story из разных областей, от нагруженных сайтов до интернет-видео, но ни слова не было сказано о границах применимости этой платформы. А потому опасаюсь, что у "впечатлившихся" могут возникнуть "истории обломов". Поскольку после такого народ начнет нагибать Erlang под те задачи, для которых он не оптимален.

День для меня начался с доклада Alvaro Videla про архитектуру сервиса на основе RabbitMQ и, соответственно, Erlang. Архитектура в целом разумная, хотя не представляющая ничего нового (разрезка подсистем, использование асихронности, неблокирующие вызовы). Но вот для какой цели они страницы рендерили на Erlang, для меня так и осталось загадкой (разве что "для единообразия").

Дальше - сообщение от русскоязычного подразделения google на тему управления проектами. В целом, на мой взгляд, "ни о чем". Высказывались тривиальные тезисы, разве что с большим пафосом. Но был упомянут интересный момент: они делают ревью кода случайным программистом команды (кубик кидают?) перед каждым коммитом задачи. При этом в разговорах косвенно выяснился средний размер разработческой задачи: 1 - 1,5 дня. Заметил, как еще один аргумент "не мельчить задачи", что в некоторых конторах порою встречается (и даже считается особым писком управления).

Следующим Макс Лапшин опять хвалил Erlang. Одновременно таки упомянув о некоторых ограничениях и проблемах записи в сокеты большого количества видео-потоков. Ну так ожидаемо.

Дальше последовали пара-тройка докладов, не оставивших никаких иных воспоминаний, кроме большого количества "воды". Хотя среди них, правда, был и один содержательный - от Josh Berkus, о системах сбора данных (то, что в России зовут "телеметрией"). Хорошо рассказано, но "для чайников". Для тех, кто сталкивался с этой областью задач, ничего нового в нем нет. Мне он оказался полезен в контексте конференции, а точнее - того "мелко нарезанного салата", на который была похожа ее программа. Может быть, именно благодаря такой смеси в голове сложились аналогии между телеметрическими задачами и другими обсуждавшимися темами. Например: в баннерных системах есть задача исчерпания оплаченного лимита показов (или кликов). Она аналогична задаче выхода измеряемого параметра за "уставку" (скажем, температуры в помещении, когда уже пора объявлять пожарную тревогу). Но это уже мысли по поводу - в выступлении об аналогиях сказано не было.

Затем шла большая лекция Robert Virding об устройстве виртуальной машины Erlang. Хорошая, подробная, но очень усыпляющим тоном прочитана. Примерно половину автор посвятил сравнению архитектур виртуальных машин Erlang и Java. В частности, механизмам работы с памятью и тому, почему в Erlang-машине не возникает роста памяти под нагрузкой и не требуются паузы на сборку мусора. В общем, очень красиво контрастировал с докладом другого дня, в исполнении Алексея Розгина на тему о сборке мусора в Java.

К вечеру первого дня следовала парочка выступлений, общий смысл которых в следующем: если у вас в сервисе есть сильно нагруженная обработка, то можно взять исходники какого-нибудь легкого http-сервера (например, nginx или подобного) и написать на С в него необходимый прикладной функционал. Получится специализированный прикладной серверок, быстрый и легкий. Да, получится... на мой взгляд, это очевидно. О чем столько говорить?

Еще оказалось неожиданно интересным выступление Сергея Рыжикова (из "1C-Битрикс"). Честно говоря, не знал, стоит ли идти на него, или лучше посетить альтернативную секцию. Все-таки пошел, и не пожалел. Доклад оказался об истории хостинга их сервиса и приключениях с площадкой Amazon. Хорошо, внятно и живо. Кроме того, были помянуты планы вывода SaaS сервиса "Битрикс24". Похоже, к концу года можно ожидать новостей на российском SaaS-рынке.

О втором дне конференции скажу более кратко. Количество содержания в выступлениях сократилось (по сравнению с первым днем), а количество бреда и ощущение балагана усилилось. Так и хотелось спросить докладчиков: "Где вы такую траву берете?" (особенно отличились ребята из "Комсомольской правды"). Ожидал чего-то интересного от доклада по AJAX, команды "ВКонтакте", но... ничего нового, сверх того, что уже было десятки раз пережевано на habrahabr.

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

Другой - рассказ про сборку памяти в различных Java-машинах. Честно говоря, тема сильно вне зоны моих интересов и про содержательную часть доклада пусть лучше напишет кто-нибудь другой. Я же выскажу только свои эмоции: "Подозревал, что дело плохо, но не ожидал, что настолько!" Короче, по мнению докладчика:

- Если у вас объем памяти приложения превысил 4Гб, то остановки приложения для сборки мусора (в самый неподходящий момент) на время от 30 сек до нескольких минут, это не баг - это фича. Типа "так и задумано".

- Если в вашем приложении время жизни объектов отличается от "стандартного спектра", вам придется особенно скверно.

Мой вывод для себя. Виртуальная машина рассчитана на редкие всплески активности (которые надо обработать быстро, наплевав на память), и продолжительный "сон" между ними, примерно как сидеть-сидеть в засаде, вдруг резко схватить добычу, захавать, и заснуть на все остальное время крупному хищному пресмыкающемуся. При постоянной высокой нагрузке и постоянно требуемом малом времени отклика - проблемы гарантированы, организм не заточен под такой образ жизни. И здесь как раз кстати вспоминается рассказ о виртуальной машине Erlang, из первого дня.