Общекомпьютерное → Отчет о конференции ADD-2010 в Ярославле

Побывал 23-24 сентября на конференции Application developer days в Ярославле. Вот решил написать краткий отчет. Сперва об организационных моментах.

Организация

В целом организация неплохая. Неудобно было только то, что добираться в Ярославль к началу конференции было практически не на чем (не считая собственного транспорта). Поэтому пришлось выезжать за день до начала конференции. С жильем решили не выпендриваться и поселились в Профилактории Железнодорожник, который расположен в пяти минутах ходьбы от места проведения конференции и ЖД вокзала (и в 2-х минутах от кладбища).

Само мероприятие проходило в ДК Железнодорожник.

Профилакторий «Железнодорожник»	ДК «Железнодорожник»
ДК изнутри. Холл перед секцией А	ДК изнутри. Холл перед секцией А

Доклады

Сама по себе конференция общего профиля, т.е. не тематическая. Просто посвящена программированию и программистам. Доклады шли в три потока, соответственно по секциям A, B и C. Зал секции A раза в 3 больше других, в нем предполагается проводить доклады, на которые придет больше всего слушателей (почему-то все время был заполнен процентов на 10-20). Секция B — секция для докладов с аудиторией поменьше (тут места практически всегда не хватало) и секция C — это зал совещаний с круглым столом, здесь читали некоторые доклады и проводили непосредственно круглые столы.

С программой конференции можно ознакомиться по ссылке http://it-conf.ru/ru/content/331.htm

День первый

После церемонии открытия конференции и отпаивания кофе с пирожками, первый доклад на который мы решили пойти:

Стас Фомин, «Золотая середина. Открытые системы поддержки разработки»

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

Рассматривал варианты выбора систем поддержки разработки (багтрекеры, Wiki, VCS). Противопоставлялись коммерческие системы и открытые. Плюсы коммерческих систем — коммерческая поддержка и, как правило, более широкий функционал, у открытых — открытый код и возможность расширять и дописывать системы самостоятельно.

Так же обсуждался выбор между интегрированными системами — комбайн «все в одном», когда и Wiki и трекер и прочие компоненты это один проект (такие как Redmine, Trac и т.п.) и специализированные системы собранные и собственноручно склееные из отдельных компонентов. В первом варианте указывают на то, что компоненты такого «комбайна» будут уступать по функционалу специализированным решениям (Wiki редмайна будет уступать Mediawiki а трекер BugZill-е). Таким образом докладчик высказался в пользу последнего варианта, рассказал как в своей компании они связывали MediaWiki, BugZilla и SVN, сказал, что эту связку они планируют выложить на SourceForge в свободный доступ.

От себя/вывод: я все же считаю, что объем работы по интеграции отдельных систем будет довольно большой и оправдан только для действительно крупных команд. Лично меня Redmine устраивает абсолютно всем.

Олег царев, Кирилл Коринский, «Сравнительный анализ хранилищ данных»

Выступление примечательно тем, что его читают два докладчика (когда по очереди, когда одновременно).

Начали с оценки требований к серверу на котором может храниться база графа друзей на FaceBook, Vkontakte и Мой мир. Пришли к выводу, что на одном сервере такая база не сможет храниться физически из-за ограничений на пропускную способность RAM, соответственно не обойтись без распределения БД... и через несколько минут кто-то из слушателей сообщил, что только что написал на коленке программу-эмулятор, прогнал ее и получил результат в 200 раз отличающийся от результатов докладчика. Забавно.

Далее лично я (как, думаю и все остальные) ожидали какого-то реального сравнительного обзора существующих решений хранилищ данных, холиваров SQL/NoSQL, рекомендаций в каких случаях какую БД стоит использовать, но на самом деле я даже не понял, что происходило на второй части доклада — докладчики постоянно друг друга перебивали, немного обсудили CAP теорему, толком не рассмотрели ни одной БД и пришли к выводу, что « серебрянной пули нет, для каждой проблемы нужно подбирать свое решение». Привет Капитану Очевидность ((.

От себя/вывод: для меня доклад запомнился как «разочарование конференции». Все-таки ожидал какого-то практического обзора, опыта внедрения, конкретики короче,а получил абстрактного коня в вакууме и вывод от КО. К тому же докладчики постоянно друг друга перебивали, что только еще больше портило впечатление. Все надежды на круглый стол SQL vs NoSQL...

Круглый стол, «Системы управления версиями»

Первый круглый стол. Обсуждаем системы контроля версий. Вспомнили наиболее популярные сейчас системы: Subversion, GIT, Mercurial, Bazaar и даже коллекции патчей. Обсуджали модели разработки с блокировкой доступа к файлам ( locking) и со слиянием ( merging). Дискуссия завязалась довольно живая, мне даже показалось, что не обошлось без троллинга, т.к. 90% времени говорили 2 или 3 человека.

Насчет merging vs locking: метод с блокировкой неудобен тем, что над файлом одновременно может работать только один человек. Если он вдруг заболеет/уйдет в отпуск и забудет снять блокировку, то доступ к файлу кому-то еще получить будет проблематично. В то же время о merging говорили, что сам процесс слияния довольно сложный и может стать причиной множества багов. Проскользнула мысль, что locking эффективен в команде низкоквалифицированных разработчиков/Junior Developer-ов или студентов, т.к. меньше шанс что-то сломать при слиянии.

Subversion ругали за то, что в нем особенно сильно проявляются проблемы слияния ветвей и что реализовано это в нем крайне примитивно. На этом фоне GIT смотрится гораздо приятнее. Из плюсов Subversion/централизованных VCS — централизованный контроль прав доступа, удобство составления плана релизов и то, что централизованные репозитории не дают разработчикам расслабиться (т.к. все коммиты попадают в центральный репозиторий и за этим процессом может наблюдать начальство). Таким образом Subversion хорош в основном для корпоративных разработок.

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

Немного касались платформ для разработки. Поговорили о Launchpad, GitHub, GoogleCode.

От себя/вывод: еще раз подтвердилась мысль о том, что использовать Git в качестве основного репозитория в компании не очень удобно, SVN с этой задачей справляется достаточно хорошо. А для своих проектиков Git и другие DVCS — самое то. Хотя на работе я все равно использую git-svn: на рабочем месте использую Git, а потом экспортирую коммиты в корпоративный SVN. Довольно удобно, я уже привык.

Максим Лапшин, «Разработка видеохостинга на Erlang»

Пожалуй этот доклад мне понравился больше всего. Хороший докладчик, рассказывал о разработанном им сервере для потокового вещания аудио/видео ErlyVideo http://erlyvideo.org/ и о языке Erlang в целом.

Erlang — функциональный интерпретируемый язык программирования enterprise уровня с динамической типизацией и простым синтаксисом. Основные преимущества — легковесные независимые потоки/нити, простота создания параллельных программ и поддержка горячего обновления кода. На нем написан самый популярный Jabber сервер ejabberd и еще множество различных хорошо масштабируемых отказоустойчивых сервисов. В частности, докладчик разрабатывал на Erlang бэкенд для лидирующей в рейтинге приложений Вконтакте игры "Лицемер".

Сам видеосервер успешно работает на нескольких видеохостингах и уделывает всех конкурентов по производительности и стабильности.

От себя/вывод: все-таки разрабатывать параллельные и асинхронные программы на объектно ориентированных языках менее эффективно, чем на функциональных. Думаю в ближайшем будущем попробовать поучить Erlang. Заинтересовало. До этого из функциональных ЯП работал только с XSLT и впечатления остались исключительно положительные.

Андрей Аксенов, «3D — графика на трех пальцах»

Андрей Аксенов больше всего прославился как разработчик поискового сервера Sphinx, на этой конференции про Sphinx не прочитал ни одного доклада, зато рассказал об основах 3D графики.

Основная идея — все улучшения в современных техниках рендеринга представляют из себя микрооптимизации направленные не столько на реалистичность, сколько на улучшение восприятия. « Главное не чтобы было реалистично, главное чтобы было красиво».

От себя/вывод: В вопросах 3D графики разбираюсь слабо, но для общего развития послушать можно.

Алексей Алексеев, Николай Гребнев, «Предупреждение ошибок программиста с помощью статического анализа кода и доменной модели»

Докладчики разрабатывают на C# или .NET с которыми я не знаком, поэтому понимал о чем говорят с трудом. Обсуждали ORM, Linq и еще что-то. Так ничего и не поняв, решил переместиться на параллельный доклад.

Кирилл Коринский, «Информирование о загрузке базовых станций Yota»

К сожалению, когда мы подошли доклад уже заканчивался. Что успел понять: нагрузки в их системе огромные, они написали и внедрили свою InMemory базу данных, которая отлично справляется с возложенными на нее задачами, и за время эксплуатации не было ни одного сбоя. Ну что ж, замечательно. Остается порадоваться.

Елена Сагалаева, «Искусственный интеллект в играх»

Елена Сагалаева ведет довольно популярный блог посвященный разработке на C++ http://alenacpp.blogpost.com/, прочитала доклад о том, как создаются боты в компьютерных играх. Хоть игрушки и не мой профиль, но было довольно интересно.

Узнал что по настоящему «Искусственный интеллект» - нейронные сети в играх не используются, т.к. это не удобно по ряду причин. Основная — поведение обученной сети довольно трудно менять, поэтому в играх сейчас используют ботов работающих на обычных алгоритмах. Рассказали об алгоритмах поиска оптимального пути бота на карте, об алгоритмах следования за лидером, о приемах применяемых в компьютерных гонках.

Интересный вывод — бота надо сделать таким, чтобы человек у него все же выигрывал. Т.е. бот должен поддаваться, но делать это незаметно.

От себя/вывод: просто довольно интересный обзорный доклад. В принципе получился коротковатый, можно было сделать подлиннее.

День второй

Думали на первую линейку докладов не ходить, но пересилили соблазн. Заинтересовал:

Андрей Карпов, «Современный статический анализ кода»

Андрей Карпов — разработчик статического анализатора кода C++ для 64-битных и многопоточных программ PVS-studio. Много статей писал на Хабре о разработке на 64-битной платформе и параллельном программировании http://habrahabr.ru/search/?q=viva64

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

От себя/вывод: как я понимаю, во все современные IDE встроен статический анализатор, так что его работу как-то не замечаешь и не задумываешься. А ведь без него было бы гораздо тяжелее. Открыл для себя, что статические анализаторы бывают и отдельно от IDE. Надо будет поискать какие решения существуют для PHP, Python, JavaScript. А ведь они помимо поиска ошибок умеют еще и за стилем кода следить (всякие там отступы/табуляции, где ставить открывающую скобку и т.п.) и отслеживать неоптимальные решения.

Владимир Климонтович, «Apache Hadoop»

Здесь рассказали о запатентованном Google алгоритме Map-Reduce и основанной на нем распределенной базе данных Apache Hadoop

Сам алгоритм Map-reduce довольно прост, но чтобы понять всю его мощность и потенциал, надо немного вникнуть. Основное его преимущество — легкость масштабирования. Т.е. написав задачу для обсчета на map-reduce можно запустить ее хоть на одном, хоть на любом другом количестве серверов без изменения кода. Еще интересно было увидеть как SQL запросы выражаются с помощью map-reduce. Жаль что сам map-reduce в докладе был рассмотрен не так подробно — непосвященным было бы трудно понять. Неплохо было бы добавить несколько примеров и картинок и было бы вообще отлично.

Apache Hadoop — нереляционная распределенная база данных основанная на принципе map-reduce. Для хранения своих баз использует собственную распределенную файловую систему. Предназначена для обработки огромных объемов данных на кластерах. На устраиваемом Yahoo соревновании по скоростной сортировке 100GB массива заняла первое место. На практике эта БД применялась в поисковике Yahoo для создания поискового индекса; на last.fm для подсчета рейтинга композиций (чартов) и еще много где. Сам докладчик сказал, что они успешно используют эту БД для анализа (на кластере) логов показов в сети контекстной рекламы, которых накапливается под сотню Гб в сутки.

От себя/вывод: вообще map-reduce довольно интересная технология но, как я понимаю, реальные ее преимущества можно почувствовать только при больших объемах данных и распределенной архитектуре. Так что по мере появления необходимости буду вникать, а пока отложу на будущее. Опять же, процедуры для hadoop пишут на Java, с которой я на Вы.

Круглый стол, «SQL vs NoSQL»

Вот он, долгожданный холивар.

Обсуждение было довольно сбивчивым и к какому-то однозначному выводу прийти не смогли. Но все же, как мне показалось, верх одержали реляционные базы данных как более надежные, ынтырпрайзные и привычные. Прежде чем решаться использовать какую-то новую/экзотическую БД нужно 10 раз подумать. В качестве примера вспоминали уволенного начальника отдела разработки digg.com, т.к. под его руководством целый год безуспешно пытались перевести digg на Cassandra.

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

Довольно часто упоминался Яндекс маркет, т.к. у него довольно сложная структура данных со множеством различных атрибутов товаров, по которым необходимо делать фильтрацию, сортировку и пр., что довольно проблематично реализуется в рамках реляционных SQL БД. Представители Яндекса сознались, что в Маркете действительно используется самописная InMemory база данных.

Андрей Майоров рассказал об успешном использовании XML полей в MSSQL (оказывается по ним можно строить индексы и делать выборки/фильтрации с помощью XPath). XML поля имеются в MSSQL и Oracle.

От себя/вывод: ждем когда допилят нереляционные БД до enterprise уровня, а пока продолжаем использовать старый добрый MySQL/Postgres. Хотя, конечно, в не самых ответственных или очень специфических случаях можно и пробовать прикручивать экзотику, но только если это на самом деле оправдано. Например Redis рекомендуют использовать в качестве менеджера очередей, Hadoop для распределенной обработки больших объемов информации. И еще — создание собственной БД для своего специфического проекта вполне реально и иногда оправдано (на примере Яндекс Маркета и Yota).

Илья Кантор, «Удобная кросс-доменная авторизация»

Илья Кантор — создатель сайта http://javascript.ru. Проводит мастер-классы по JavaScript и основанных на нем технологиях. Рассказал одновременно и как противостоять DDOS атакам, и как организовать кроссдоменную авторизацию и как реализовать персонализацию сайта для незарегистрированных пользователей.

Для отражения DDOS предлагается использовать связку Varnish и Redis. Varnish — это быстрый кеширующий прокси-сервер, позволяющий подключать свои модули, Redis — нереляционная key-value база данных, преимущественно InMemory. Суть трюка в том, что версия сайта для незарегистрированных пользователей (и, соответственно, ботов) загоняется в глубокий кеш Varnish-а, а персональные версии для зарегистрированных пользователей уже генерирует бэкенд. Главная хитрость заключается в том, что авторизация проверяется не на бэкенде, а непосредственно в Varnish. Клиент обращается к Varnish, varnish обращается к Redis (в котором хранятся сессии пользователей) для проверки залогинен ли пользователь. Если да — перенаправляет к бэкенду, если нет — отдает версию из своего кеша. Нагрузка на бэкенд снята, DDOS отражен.

Персонализация достигается за счет хранения сессий и прочих персональных данных на основе сессионной куки в Redis.

А кросс-доменная авторизация работает с использованием мастер-сервера авторизации с которого подключается специальный JavaScript файл, выставляющий авторизационную Cookie. Не все браузеры позволяют выставлять cookie с другого домена, для регулирования этих политик используются P3P HTTP заголовки. Но Safari не всегда доверяет этим заголовкам. В таком случае используется хак с отправкой POST запроса через IFRAME на мастер-домен.

От себя/вывод: технологии довольно интересные и прогрессивные, думаю найдут применение в наших проектах. Насколько я помню, кросс-доменная авторизация используется на vkontakte.ru и vk.com.

Илья Кантор, «Приватности в интернете нет» (секретный доклад)

Доклад не анонсированный в программе конференции, занял половину обеденного времени). Было рассказано о способах идентификации в интернете не только с помощью Cookie. Довольно интересные и неочевидные способы идентификации через комбинации HTTP заголовков браузера, через Flash, Java, HTML5 LocalStorage и прочее.

От себя/вывод: может пригодиться как для защиты от идентификации, так и для отслеживания или надежного «забанивания» пользователя.

Евгений Кирпичев, «Многопоточное программирование»

Рассказали о Линейной темпоральной логике ( LTL), следование которой позволяет писать корректные параллельные программы. Есть анализаторы кода, позволяющие выявлять, используя LTL, потенциальные проблемы в параллельных программах (deadlocks etc.). Рассмотрены подходы и основные паттерны параллельной разработки (семафоры, мьютексы, блокировки). Не обошли стороной и асинхронное программирование. Мне показалось, что многовато математической теории, поэтому не все моменты были понятны.

Далее были рассмотрены возможности реализации параллельных программ на языках программирования Haskell, Erlang, Clojure, F#.

От себя/вывод: все-таки параллельные и асинхронные программы гораздо аккуратнее выглядят и легче пишутся на языках, которые специально предназначены для написания таких программ. Приведенный пример на F# это наглядно подтвердил. Пожалуй, функциональные ЯП для параллельного программирования подходят больше других. Хотя есть и такие паттерны как, например, Deferred, которые позволяют довольно успешно писать параллельные программы на ОО языках без потери читаемости.

Домой

После было еще две линейки докладов, розыгрыши призов и закрытие конференции, но у нас были куплены билеты на поезд, так что на этом месте наше пребывание на конференции заканчивается. Всем спасибо, мы едем домой!

Общие впечатления

Понравилось что вокзал, гостиница и место проведения конференции расположены максимально близко, так что во время обеда успевали дойти до номера и передохнуть. Так же приятно порадовало что нас обеспечивали стабильным WiFi интернетом на протяжении всей конференции. Сам ДК Железнодорожник оказался весьма удачным местом для мероприятия — чистенькие отремонтированные залы, много свободного места, где можно пообщаться, пирожки и чай/кофе в неограниченном количестве. В общем атмосфера была дружелюбной и располагающей к общению.

Теперь негатив. Мне не понравилось то, что конференция была уж очень широкого профиля. Каждый рассказывал о том, о чем хотел. Секции тоже не тематические. На любой секции могли расказывать про БД, потом про Java, после про разработку игр, поэтому приходилось часто бегать из зала в зал.

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

Еще немного подвел слабенький проектор в секции А — на многих интересных докладах трудно было разглядеть иллюстрации. Мелочь конечно, но отметить стоит.

Далее, обеды были ну совсем никакие. Спасли ситуацию только пирожки с кофе.

В общем и целом считаю, что конференция прошла удачно, но хотелось бы больше тематичности. Спасибо!