|
 |
Персональные инструменты
Просмотры |
|
Персональные инструменты |
|
||
|
|
ADD-2010: отчет Игоря БеспальчукаМатериал из CustisWiki
Содержание
22 сентябряИз-за неудобного расписания поездов мы решили ехать на конференцию на машинах, с ночевкой в Ростове Великом. До Ростова пришлось пилить по мокрой темной дороге 4 часа (один выезд по Ярославке из Москвы занял час). Так что отдых в Ростове оказался очень даже кстати. Гостиница в Ростове оказалась на удивление милой, за что спасибо нашим HR. В Ярославль мы поехали уже утром 23го. 23 сентябряОткрытиеКонференция проходила в Ярославле, в ДК Железнодорожника. Мы приехали в середине церемонии открытия, Стас Фомин уже говорил свое вступительное слово. Слово было не слишком коротким, я даже успел заскучать. А сразу после слова неожиданно объявили кофе-брейк. В итоге, начало было здорово затянуто – регистрация начиналась в 8:30, а первый доклад – в 10:30. Кофе-брейкиНа кофе-брейках кофе не было. Но был чай (только черный), и еще бутерброды с ветчиной (иногда) и пирожки с плюшками. И вода в бутылочках. Вообще, почти во всей организации чувствовалась здоровая экономия, причем, что приятно, не сказывавшаяся на качестве докладов. А то последнее время так – по организации и придраться, бывает, не к чему, а вот доклады скучные. Jazz"- Microsoft, Jira, Open source – это все отлично интегрируется в jazz!"
На конференции было три трека. Судя по всему, самые ранние доклады специально поставили не слишком интересные, чтобы не жалко было тем, кто опоздает с приездом в Ярославль. Много народу ушло слушать доклад про состояния рынка труда IT — тема животрепещущая, люди стояли, но говорят, что в итоге было не слишком интересно. Я же решил хоть раз послушать целиком доклад про платформу IBM Jazz, где наоборот, в огромном главном зале сидело 15 человек. Одно слово — вендорский доклад в максимально агрессивной среде. Докладчик, Дмитрий Халецкий из IBM, рассказывал как немеряно крута платформа Jazz. Это большое и тяжеловесное (как это свойственно для IBM) решение для организации работ над разными проектами, причем вроде бы не только в области разработки ПО. IBM постаралась сделать jazz открытым продуктом без открытых кодов — привлекает сообщество на специальный портал, где можно скачать демо-версии, а также расширения сторонних фирм, пообщаться с пользователями jazz, и все такое. Jazz — хорошо расширяемая платформа. В нее интегрированы как продукты старых IBM-овских линеек типа Clear Case, так и продукты нового поколоения, типа Team Concert. Вот я уже три абзаца говорю про jazz — а вы поняли, что это такое? Нет? Вот так почему-то было и с докладом. За 45 минут с трудом удалось представить, что же все-таки эта штука делает. Фирменные IBM-овские слайды с мельчайшим текстом вокруг нескольких картинок, много общих слов о расшияремости, поддержке всего на свете, трассировке к бизнес-задачам, интегрируемости и дифференцируемости jazz’a как-то не создали общего представления о продукте. В конце было несколько скриншотов, но очень мелких, они не исправляли ситуацию. Вопросы из зала также не помогали, скорее наоборот — укрепляли во мнении, что ничего конкретного узнать не удастся, кроме того, насколько же это замечательный продукт. «Microsoft, Jira, Open source — это все отлично интегрируется в jazz» — поведал докладчик. Jazz состоит из интеграционной платформы, на которую нанизаны конкретные приложения, покрывающие разные этапы и деятельности в RUP-цикле разработки приложения (т. н. ALM-решение, Application Lifecycle Management). Есть приложения для работы с требованиями, для управления процессом разработки, для контроля версий и конфигурационного управления, для ручного и автоматизированного тестирования, в том числе тестирования UI и тестирования безопасности, и многое другое. Конечно, в рамках доклада невозможно было рассказать подробно обо всем этом, докладчик бежал по слайдам, и остались только общие позитивные установки о том, что «там все есть, что нужно». Говорят, в России около 10 крупных внедрений. Цены в отрыве от конкретного клиента назвать невозможно. Похоже, что решение действительно только для крупняка, в этом смысле, вряд ли стоило делать доклад о нем в такой аудитории. С доклада ушел успокоенный — понял, что никто мне толком не расскажет, что же такое Jazz. Сравнение хранилищ данныхЯ сперва думал что это будет про SAS/NAS/SAN'ы. Оказалось – нет, это про «SQL и NoSQL» - тема, которая звучала на конференции очень часто. Может быть, даже слишком часто. Два «классических программиста» – один пухлый и лохматый, другой тощий, и оба в майках (в отличие от костюмчика из IBM). Олег Царев и Кирилл Корецкий – два этих голоса мы слышали на протяжении двух дней тоже очень часто. Может быть, даже слишком часто. Презентация также представляла собой печальный образец того, что чаще всего приходилось видеть на конференции – белый фон, черные bullet’ы. Программисты – явно не мастера подать результаты своей работы. Докладчики рассматривали задачу анализа большого объема данных на примере Facebook'а и других социальных сетей. 500 миллионов пользователей, 5 миллионов запросов в секунду – действительно, потрясающие воображение показатели. Нам очень долго объясняли, почему это никак не получится обработать на одном компьютере. Доказывали, можно сказать, с цифрами в руках. Докладчики ввели для слушателей несколько корявых определений, попутно споря друг с другом о формулировках. Потом на основе этих определений дали CAP-теорему. Теорема гласит, что для распределенной вычислительной системы из трех важнейших свойств – атомарности изменений, целостности данных и устойчивости к сбоям узлов – увы, одновременно выполняться могут только два. В докладе очень не понравилось то, что авторы регулярно начинали спорить между собой о том, чье определение лучше, как правильнее расклассифицировать способы «партицирования» (как они это называют), и вообще, как будто между слов скатываясь к тому, кто из них более настоящий программист. Это все продолжалось довольно долго, слушать перепалки было неприятно, большой пользы видно не было, и я ушел, немного не дождавшись окончания доклада. Дополненная реальностьДоклад Андрея Бибичева, напротив, не обманул ожиданий. Было интересно, познавательно, красочно, весело. Андрей навострился делать просто мастерские презентации, с которых можно просто брать пример. В то же время понятно, что одной презентации мало — нужно и мастерство докладчика, и качество самого подаваемого материала. Здесь все было здорово. Андрей рассказывал про популярное сегодня направление в computer science, которое назвается «AR», то есть дополненная реальность. Вкратце, суть в том, что вычислительная система (КПК, телефон или большой съемочный комплекс) все более интерактивно взаимодействует с человеком и окружающим его миром, порождая новые, невиданные доселе артефакты. Компьютеры научились определять местоположение, скорости и ускорения, углы поворота устройств, и знают, куда смотрит человек и какой жест показывают его пальцы. И, могут соответственно реагировать на это. Рассказ Андрея представлял собой калейдоскоп разных тем, так или иначе затрагивающих различные технологии, применающиеся в AR — анализ изображений, работу с новыми мобильными устройствами (акселерометром, компасом, гироскопом). Презентация изобиловала видео-вставками, демонстрациями и просто хорошими иллюстрациями. Местами, как мне показалось, был некоторый перегруз узкоспециализированной математикой. Зато это внушало уважение зала! Думаю, что не так уж много разработчиков реально столкнутся с этими задачами в будущем в своей работе. Но как пользователи — скорее всего, столкнемся все, как сталкиваемся с новыми фичами в телефонах. В общем, настоятельно рекомендую посмотреть видео-запись доклада и презентацию, надеюсь, они будут доступны в сети.
ОбедВ отличие от открытия конференции, на обед времени было в обрез. Обедали мы в близкорасположенной кафешке, кормили просто, не слишком вкусно, но вполне съедобно. На удивление мы попадали в какой-то такой момент, что очереди не было и ждать не приходилось – все приносили быстро. На весьма пафосных конференциях частенько приходится сперва простоять в длинной очереди с двумя тарелками в руках. Круглый стол про системы контроля версий"– Ты сюда зачем пришел, обсудить проблему или просто пофлеймить?? – Ну, вообще-то.. просто пофлеймить." (Диалог в президиуме круглого стола)
Круглый стол проходил в аудитории, очень неплохо оснащенной технически. На длинном столе – индивидуальные экраны и микрофоны, плюс экраны в торце зала. На все экраны транслировалось изображение с экрана ноутбука Стаса Фомина, который в online-режиме строил mind-map обсуждения (думаю, уже все видели, на что этот процесс похож, Стас регулярно это делал на встречах Agile Russia). Впрочем, организация круглого стола на этом заканчивалась. Экраны есть, mind-map есть, а в остальном – «каждый сам за себя». В результате круглый стол по большому счету проходил в одном его углу, где собрались несколько наиболее активных участников конференции, знакомых между собой. Это уже упомянутые Олег Царев, Кирилл Корецкий, а также Андрей Аксенов, человек, известный как автор поискового движка Sphinx. Время от времени высказывались (причем очень неплохо высказывались) и другие участники, но этой троицы звучало больше всего Может быть, даже слишком много. Обсуждали в основном Subversion, Bazaar и Git, а также массу смежных тем (типа LaunchPad vs GitHub). Не хочу долго рассказывать про банальные выводы типа «для каждого сценария использования – свой инструмент, кому-то и CVS с SourceSafe будет лучше». Что же интересного было сказано по сути? Отпишу по пунктам, что мне показалось новым и интересным. Ветки в SubversionПро ветки в SVN говорили много и с жаром, примерно так: «– Они вообще не работают! – Нет, работают. Это они так работают. – Ну, знаете, предупреждать надо! У меня проект! – У всех проект. Проверять инструменты надо.» Речь о том, что в SVN действительно была объявлена важная функциональность в версии 1.5, но выяснилось, что работает она очень странно. Если вы сделали ветку, вносите в нее изменения (B), в это время в основном стволе также производятся изменения (A), то вы можете командой –reintegrate-branch влить изменения A в ветку. Но когда вы попытаетесь влить изменения B из ветки обратно в остновной ствол, SVN попытается применить к нему не только изменения B из ветки, но и изменения A, хотя в основном стволе они уже есть. Эта ситуация будет диагностирована как конфликт. Мы сталкивались с такими проблемами в RMS, и пришли к тому, что все-таки слияние- исключительно ручная операция. Но утверждается, что с версии 1.5.4 (или 1.6) Subversion стал в этом отношении лучше и теперь правильно выполняет слияние веток. Это стоит проверить детальнее и четко знать, на что способен наш инструмент контроля версий, а на что – нет. Git и fetch & rebaseОказывается, в мире Git очень популярна стратегия «fetch & rebase». Представители других религий крутят пальцем у виска, но git'овцы довольны. Эта стратегия заставляет разработчиков искусственно линеаризировать все изменения в основном стволе продукта, упрощая (противники говорят – «искажая») историю изменений в ветках. Суть стратегии в том, что взяв однажды для работы некоторую ревизию репозитория, разработчик вносит какие-то изменения, а затем фиксирует их обратно в репозиторий, но таким образом (rebase), что они обязаны примениться к текущему, последнему, изменившемуся его состоянию. И в истории изменений эти фиксации видны не как параллельные изменения, которые затем кому-то нужно сливать, а как единая линейная последовательность изменений. При высоком уровне автоматизации причина и автор ошибок находится методом бинарного поиска (с прогоном тестов на разных ревизиях). Эту стратегию и git в целом защищал Иван Сагалаев – человек из Яндекса, который произвел на меня исключительно хорошее впечатление (в отличие от наиболее активных участников конференции). В кулуарах мы пообщались также на эту тему с Андреем Бибичевым, и он сказал, что для него fetch & rebase – тоже совершенно новое знание, но что ему эта идея страшно понравилась. Похоже, что git – действительно одна из самых мощных распределенных и бесплатных систем контроля версий на сегодняшний день, хотя почти все, от кого я про нее слышал, говорят, что она нетривиальна в изучении. Несколько мненийЗаписал несколько экспертных мнений, относительно которых у меня самого пока нет четкой позиции. 1. Если вам не нужен fetch & rebase и вы боитесь сломать историю изменений, но хочется иметь распределенную систему контроля версий – берите Mercurial. 2. Распределенные системы контроля версий плохо подходят для работы в стратегии «ветка-на-фичу», если над фичей должны работать несколько человек. Приходится делать еще один репозиторий на фичу. Видеохостинг на ErlangМаксим Лапшин рассказывал о том, как он написал сервер видеостриминга Erlyvideo на Erlang, и почему этот язык оказался наилучшим средством для этой специфической задачи. Доклад мне очень понравился, хотя презентация была унылая – белый фон, черные bullet'ы. Максим докладывал четко, понятно, без лишней воды и не занудно. Фактически, слайды были и не нужны. Специфика задачи видеостриминга состоит в том, что подключенному клиенту нужно обеспечить непрерывное вещание в течение нескольких часов или даже суток. При этом уже нельзя относится к управлению памятью и устойчивости сервиса так же наплевательски, как в случае простого веб-сайта, где легко можно recycle'ить рабочие процессы на случай, если где-то имеет место утечка. Сервер нельзя останавливать, у него не должна течь память, он должен масштабироваться и обслуживать большое число клиентов. При этом его еще нужно как-то обновлять. А если все-таки с каким-то клиентом случится что-то нехорошее – то другие не должны пострадать. Задача звучит достаточно внушительно, правда? Так вот оказывается, что Erlang одной своей природой и стандартным комплектом поставки эту сложную задачу наполовину решает сразу, причем радикально. Главная особенность Erlang’а состоит в том, что для параллельно исполняющихся потоков не бывает общей памяти. Просто не бывает. Потоки общаются между собой исключительно посылкой и приемом сообщений. Это в принципе убирает главные проблемы многопоточности, известные из традиционных языков. Далее, как следствие, вся, абсолютно вся выделенная память всегда принадлежит одному потоку, который, собственно, ее и запросил. А это, в свою очередь, означает, что если с одним потоком что-то пошло не так, то его можно относительно безболезненно убить и освободить всю его память. И это не повлияет на работу остальных потоков. В стандартный комплект поставки Erlang входит весьма продвинутый инструментарий для такого рода анализа и наладки программ. И, наконец, Erlang предоставляет очень редкую возможность обновления выполняемого кода на лету. В случае с сервером стриминга Erlyvideo это означает, что функционал может быть обновлен без прерывания трансляции, причем не только для новых клиентов, но и для тех, которые уже подключены и принимают поток видео. Таким образом, Erlang хорошо подходит для организации устойчивых информационных сервисов, работающих с большим числом клиентов, под нагрузкой. Некоторый минус (для меня) состоит в том, что Erlang – динамически типизированный язык. Не люблю я их почему-то. Максим говорил, что в его случае это не было проблемой, хотя для реализации сложной бизнес-логики типа банковской он бы тоже поостерегся выбирать Erlang и предпочел бы язык со статической системой типов. Напоследок было отмечено, что Erlang сам по себе язык очень простой и когда Максиму потребовалось найти разработчика, он нашел его очень быстро. Это был разработчик на Java, который освоил Erlang в считанные дни.
Адаптивная архитектураFail'овый доклад. Автор рассказывал о том, что (кто бы мог подумать!) для каждой задачи нужно выбирать оптимальную архитектуру, а если в задаче все меняется, то и архитектуру можно поменять. Рассказывал медленно, долго, занудно, скучно. Апофеозом был вопрос к залу «Я не слишком быстро говорю?», после которого в зале раздался нервный смех тех, кто еще не уснул. Свои идеи автор иллюстрировал историями из практики. Например, была высказана мысль, что архитектуру нужно подлаживать и под команду. Мне это показалось престранным - я всегда думал, что нужно команду, как более динамичное звено подбирать/обучать под архитектуру, которая более статична в силу статичности задачи (исключая, конечно, совсем клинические случаи). Автор иллюстрировал свою идею примерно так: «У нас была задача. А из людей был только студент, знавший ASP и опытный DBA. Если бы мы стали делать трезвенную архитектуру, все бы закончилось плохо. Вместо этого мы написали всю логику на триггерах, а на ASP – сделали очень простое отображение данных. И все работает, проект сдан.» Может, это только мне кажется странным примером «success story» об архитектуре? Пожалуй, единственное, что мне понравилось в докладе – это фотография аппарата из эксперимента Милднера. Этот психологический эксперимент наглядно демонстрирует огромную силу авторитета (любого, ну, например, Мартина Фаулера). Человек может быть очень сильно подвержен влиянию авторитета в каком-то вопросе, причем сам этого не осознавать. Подробнее об этом эксперименте, а также многих других удивительных психологических эффектах влияния можно прочитать в прекрасной книжке Роберта Чалдини «Психология влияния». Рекомендую к прочтению всем, независимо от рода деятельности. Еще были упомянуты несколько статей, думаю, их стоит посмотреть:
Статические проверки кода в DDD-фреймворкеДоклад Леши Алексеева и Коли Гребнева про наш CIS Uni.Net. Ребята волновались, где-то затягивали изложение, где-то, наоборот, слишком ужимали. Ну, как говорится, первый блин комом, а дальше будет лучше. В целом мне понравилась практика доклада вдвоем. Представление о предмете получается более объемное, один докладчик при случае может поддержать второго. Что касается собственно фреймворка, то, кажется, люди не слишком хорошо поняли, что же он из себя представляет. Это не очень удивительно – с этим докладом мы зашли сильно «сбоку», фреймворка целиком не было видно. Зато людям немножко вынесли мозг структурами Крипке, формулами темпоральной логики, и они ходили под впечатлением: «Ух ты! У CUSTIS есть фреймворк для статической проверки кода!». Интересно еще узнать, что люди пишут (если пишут) в блогах по поводу этого докалада. А может, так и делать? У меня даже возникла идея следующего доклада «сбоку» - про систему прав в CIS-Uni.Net на основе ролей и предикатов. Искусственный интеллект в играхПрелюбопытный доклад о том, какие алгоритмы используются в современных играх. Игра не должна быть справедливой, она должна быть интересной :) Поэтому точки зрения математики и геймдева на то, что такое "хороший" генератор случайных чисел, очень разные. Гостиница в ЯрославлеГостиница в Ярославле оказалась дороже и хуже, чем в Ростове. Организаторам наше "фи". Плюс к тому, обнаружилась накладка - четырех наших человек не было в списке, долго разбирались с организаторами и администраторами. 24 сентября...пока осталось только в блокноте...
Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».
|
 |
 |
 |
