Изменения

РИТ-2010: Отчёт Виталия Филиппова

51 940 байтов добавлено, 12:08, 30 октября 2013
Новая страница: «;Сайт конференции: http://www.ritconf.ru/ ;Даты проведения: 12-14 апреля 2010 ;Место проведения: [http://www.inf…»
;Сайт конференции: http://www.ritconf.ru/
;Даты проведения: 12-14 апреля 2010
;Место проведения: [http://www.info-space.ru/ Infospace] (ИнфоПространство)

Организация нормальная. Затупов не было. Только Джонатан Вортингтон, разработчик Perl 6 / Rakudo, который очень любит ''beer/vodka'' и так далее, то ли не приехал, то ли приехал, но очень увлёкся ''beer/vodka'' и так далее, в первый день вместо него выступал Шитов. С едой всё в порядке, обед раздёлен на два — по часу с 45-минутным интервалом между ними, во время каждого «обеда» прекращает работу только один зал, а в остальных продолжаются доклады. Кофе-брейк вечером, очень мало плюшек, их сожрали в момент. В последний день было пиво и шашлык <s>из кролика</s>. Кстати, о кролике: там был один товарищ, который умудрился купить билет на РИТ по тестовой цене в 50 рублей, которую после выкладки на боевой сервер не успели поменять. За скорость тестирования ему вручили приз — живого кролика, правда, карликового (то есть малопригодного для еды).

Была видеозапись и онлайн-трансляция (6 камер в каждом зале). Есть надежда, что видео с конференции не будет столь же бездарно пролюблено, как это было с Highload’ом.

«У меня сразу плохая новость — обед идёт сейчас и кончится где-то посередине доклада, так что … решайте …»

«Стас, ты сейчас либо оставишь людей без кофе-брейка, либо следующего докладчика — без аудитории»

== День первый ==

=== Engineering Culture at Facebook / Эндрю «Boz» Босуорт ===

Доклад на английском языке. Я думал, будет что-то об организации/культуре «инженерии» у них, а был в основном рассказ про то, какой фейсбук классный, и то, что социальность — это будущее интернета, а будущее уже наступило. Про культуру тоже чуть-чуть было, например, у них есть команда каких-то крутых чуваков, которые лабают крутые инструменты для остальных :) например у них тоже есть внутренние блоги, только они называются «обсуждения».

«Вот смотрите, фотохостинг фейсбука — самый популярный в мире <цифры>. В то же время, фотохостинг в фейсбуке, наверное, самый ужасный из всех. В чём же дело? Два слова — ''photo tagging''. Возможность отметить друзей на фото. Социальность.»

=== Смена веб-платформы на лету / Евгения Фирсова ===

«Леди Ада Лавлес» (за причёску), большая любительница [[CVS]]’а (кажется) и рефакторинга, из ''Яндекс.Денег''.
Доклад про то, как они меняли платформу приложения («НоваяПлатформа»). То есть про очень конкретное изменение — когда меняется всё и принципиально, и когда не получается одну и ту же версию просто потихоньку править. А приложение большое, фич много, постоянно идут новые запросы, а миграция долгая и остановить работу на это время невозможно. Они в итоге обновляли функциональность по частям — ставили рядом сервера с разными версиями приложения, старой и новой, и от одной запросы к некоторой функциональности проксировали к другой. Соответственно появляются варианты — что поставить на входе? Старую или новую? Ставили новую, чтобы не было непредсказуемости при ''предстоящем'' переносе фронтенда и чтобы не нужно было ещё раз тестировать. Ещё была проблема — как везде одновременно включить новую версию? Ну, можно, например, её везде пронести, а потом конфигом синхронно переключить — это первый вариант, и второй, более традиционный — часть серверов исключить из балансировки, обновить и включить обратно все вместе. Но второй, если половина серверов не держит нагрузку, не подходит. ''(Вообще-то странная ситуация — нагрузка же не равномерна в течение суток, днём её сильно больше, и учитывая, что весь набор серверов держит пиковую нагрузку, ночную нагрузку половина серверов должна выдержать вполне. Так что обновляйтесь ночью, и все дела — прим.вред)''

Доклад частично был «ни о чём», условно говоря:
* «Ну вот мы выкатываем новую версию… мы можем ошибиться. где мы можем ошибиться?» — а дальше список, который сводится к тому, что '''везде''' мы можем ошибиться.
* «Ну вот у нас изменения, они серьёзные, поэтому мы их проносим потихоньку… но с другой стороны потихоньку плохо, потому что так можно 5 лет переходить. поэтому нужно форсировать переносы крупных фич, после которых уже пути назад не будет и придётся переходить. ну, могут быть скандалы, ну и что — у нас был»

Да, ещё шрифт был мелкий.

=== Rakudo Perl 6 / <s>Джонатан Вортингтон</s> Андрей Шитов ===

«Вортингтона не завезли, но завтра он наверное будет — он большой любитель ''beer vodka'' и т. п.»

Ничего особенного, очередная презентация про <tt>Perl 6</tt>, его синтаксис и про то, что сейчас происходит (в частности модули <tt>Blizkost</tt>, <tt>Zavolaj</tt>). Вновь наводит на мысли о http://lurkmore.ru/Perl#Perl_6

«Вот этот пример тем, кто никогда на 5-ом перле не писал, может показаться странным — вроде просто функция с аргументами, но тем, кто на перле писал, он очень актуален, ибо они знают, что в 5-ом перле просто вот так аргументы функций писать нельзя, их приходится доставать из … неудобного места, а в 6-ой версии они решили всё-таки повернуться к народу тем мест.. то есть повернуться лицом».

Многие считают, что это не взлетит, а Шитов считает, что взлетит. Будет релиз «совсем скоро» — весной. Да, этого года. Поживём, увидим! :) а пока что оно очень тормозное и есть не всё.

''Моё мнение — если и взлетит, то через постепенную эволюцию от 5-ого перла, а не как сейчас''.

=== Виртуализационный бум, о чём молчат вендоры / Денис Гундарев ===

Очень правильный доклад! Все так помешались на виртуализации, что кошмар :) тем временем нужно понимать, что есть «мифы» виртуализации:

; «Персонал дешевле»: Да ни фига он не дешевле! Зарплата САПера падает, а ВМВарьщика растёт. Кроме того, первичен-то софт, а не система, в которой он работает, и администратор софта всё равно нужен, а тут он может оказаться не у дел (всё уже настроено?), и персонал легко ещё и потерять.
; «Мы поддержим старые дистры и ОС»: То, что под вашей вмварью или цитриксом запускается и работает полуось (OS/2) или винда NT4, это не значит, что его кто-то поддерживает. Поддерживаете, разбираетесь в ошибках и выпускаете обновления безопасности для старых ОС не вы, а те, кто их создал. Неподдерживамые дистры не станут волшебным образом поддерживаемыми после установки на виртуалку.
; «Отказоустойчивость»: По сути она эквивалентна отказоустойчивость на уровне железа. Нет, очень красиво, когда вытаскивают питание из сервера, а виртуалка мигрирует на другой и живёт дальше, но если вы хотите сделать себе такую отказоустойчивость, железа-то вам всё равно нужно больше. А бывают и случаи, когда кластер из двух виртуалок работает на одной физической железке — ну и где тут отказоустойчивость?
; «Безопасность»: Схренали? Гипервизор — это дополнительное ПО, это лишняя прослойка, в которой, как и во всех остальных программах, находят баги и дыры безопасности. При этом, взломав гипервизор, взломщик может нанести гораздо больший вред, чем если он взломает одну железку — например, если под виртуалкой работает виртуальное Сисько, то он уже перехватит весь траффик всей сети вообще. А если и не работает, то он взломает все виртуалки. Кроме того, виртуалки плодятся обычно быстрее реальных машин, и во всевозможных машинах для разработки, тестирования и т. п. взломщику потенциально проще спрятаться. ''Эксперты по безопасности говорят: '''Don’t add security, remove insecurity'''.''
; «Упрощается планирование ресурсов»: Планирование-то упрощается, зато расход ускоряется, потому что виртуалку проще и быстрее развернуть — а надо помнить, что если это винда, на каждую виртуалку нужно ещё и оплатить лицензию. Которую часто берут по умолчанию максимум (Ынтырпрайз), а он стоит в 5 раз дороже, чем обычный сервер.

=== Mojolicious. Веб в коробке! / Анатолий Шарифулин (Точка Кипения) ===

Точка кипения — вообще чуваки без комплексов, конечно. Во второй день, например, был Кудинов с феерически бредовым докладом, но об этом потом.
Но этот доклад нормальный.

{{CPAN|Mojolicious}} — достаточно неплохой веб-фреймворк под Perl. Правда, а) довольно пионерский, есть баги, пока не дошёл до 1.0 и б) довольно обычный (тысячи их) — с ''handler''’ами, с жёсткими ''workflow'', с диспетчерами и ''router''’ами (от компонента к компоненту), чтобы как-то избежать жёстких ''workflow'', с «PerlHTML» шаблонами (называются «EP» — ''Embedded Perl'' — просто HTML с Perl-вставками), со ''stash''’ами в шаблонах (''аааа!!! ну сколько же можно!!!'')… По сути, это Perl-on-Rails.

«Mojolicious позволяет использовать несколько шаблонных движков, например, если у нас один программист пишет на <tt>Template Toolkit</tt>, ещё один на <tt>EP</tt>, ещё один на <tt>CTPP2</tt>, <s>то у нас грёбаный бардак — прим.вред</s> то мы сможем использовать их все вместе».

Из интересных фич там есть — надёжная автоматическая перезагрузка модулей (больное место <tt>Perl</tt>’а), шаблоны в <tt>__DATA__</tt> (в конце файла с программой).

=== AnyEvent — высоконагруженные приложения на скорую руку / Владимир Перепелица (Рамблер) ===

Доклад про Perl-событийную машину {{CPAN|AnyEvent}}. ''Кстати, {{CPAN|Coro}} — зелёные потоки (green threads) на перле''.

Что такое высокая нагрузка? Это исчерпание тех или иных, а лучше всего — всех ресурсов железа. Если переписать софт на событийную модель, загрузка будет меньше, а КПД больше. И кучу соединений сможем держать легко (пример — <tt>Nginx</tt>). НО все ожидания нужно выносить на события, а долгие вычисления — лучше куда-нибудь наружу, так как они будут задерживать других клиентов. Всё, как всегда.

Клиент к базам ({{CPAN|AnyEvent::DBI}}) есть, но он форкает отдельный процесс, который ждёт базу, а мы будем ждать его. То есть «не совсем честный». Интересно, есть ли драйвер <tt>mysql</tt> на событийной машине.

=== Почему нужно использовать SCRUM в вашем веб-проекте. Опыт Моего Круга / Евгений Курышев ===

Рассказывали про то, какой у них скрам:
* JIRA + GreenHopper.
* Etherpad.
* Taskboard из потолочной плитки (8 рублей ему цена). ''А ещё из неё авиамодельки можно делать — прим.вред.''
* Сборка обратной связи — яндекс поиском по блогам. <br /> «Тег МК-баг (неточно), мы придём и как Человек-Грызлов тихо поправим всё».
* ''Planning Poker'', демонстрации на проекторе и доски с маркерами у них тоже есть.

=== Быстроменяющиеся требования и фиксированные бюджеты / Денис Ермаков (WEBlime) ===

Что-то про Agile и про то, как бывает сложно его продать заказчику. Слегка отключился, нифига не помню :))

=== Методы оценки качества требований и работы аналитика / Александр Байкин (UML2.ru) ===

Всё ещё пребывал в отключённом состоянии, да и тема мне не сильно интересна, помню что было много всего, какие-то классификации требований и т. п.

=== Top‐20 глупых высказываний о QA и что на них ответить / Екатерина Рощина (Нивал) ===

Презентация: http://www.slideshare.net/rit2010/ekaterina-roshchina-top-20

О! Замечательный доклад в защиту тестировщиков. В докладе были собраны «глупости» типа: '''«давайте наймём обезьянок, всё равно там работа тупая»''', '''«пропустил баг — плохой тестер»''', '''«много багов нашёл — хороший тестер»''' (можно договориться с программистом, и их ''будет'' много, особенно если ему платят за исправленные баги), '''«пускай программисты тестируют»''', '''«пусть тестера собеседуют программисты»''' (это будет плохой программист, а не хороший тестер), от тестера: '''«почему я до сих пор junior, хотя уже 5 лет занимаюсь ручным тестированием?»''' (вот потому и джуниор, что 5 лет занимаешься ручным тестированием), от программиста: '''«это не баг, а фича»''' (можно у пользователей спросить… фича ли), '''«давай я тебе на словах расскажу»''' (лучше напиши — надёжнее). И т.п.

В докладе таких высказываний много и все очень интересны, пересказать всё не могу, смотрите [http://www.slideshare.net/rit2010/ekaterina-roshchina-top-20 презентацию].

=== Improving MySQL‐based applications performance with Sphinx / Maciej Dobrzanski (Percona) ===

Просто доклад про [http://www.sphinxsearch.com Sphinx] и то, какой он хороший полнотекстовый и не только индексатор. Конкретно про удобство использования в связке с MySQL было мало.

== День второй ==

=== Erlyvideo — создание видеостримингового сервера на erlang / Максим Лапшин ===

Сам не слушал, но отмечаю, потому что доклад, судя по всему, был действительно интересный. Быстренько написали видеовещательный сервер на Erlang’е ''(гы, теперь в России не 3, а 4 разработчика на эрланге — прим.вред, шутка)'', который умеет основное — <tt>RTMP</tt>, бесконечные <tt>FLV</tt>, также на айфон и видеоприставки, держит высокую нагрузку (1 гигабит видео, 1800 пользователей с одного сервера), читать из файлов, с плат захвата, с IP и обычных камер, из программных и аппаратных перекодировщиков, умеет организовывать видеоконференции и прямой эфир с отмоткой назад. Короче, хорошая, годная штука.

Ссылки: [http://erlyvideo.org/ Erlyvideo], [http://www.slideshare.net/rit2010/max-lapshin-erlyvideo-v2 презентация].

=== СSS анимации в боевых условиях: преимущества и недостатки / Сергей Чикуенок ===

Чувак последнее время писал под айфон. Посему и в теме разбирается немного. Вкратце тема сводится к тому, что флешовые анимации с траекториями, переходами и т. п. перетаскивают в CSS. Перетаскивают, правда, весьма плавно и на данный момент все три части полуготовой спецификации — CSS ''Transforms'', ''Transitions'' и ''Animations'' — поддерживаются только в WebKit’овых браузерах — <tt>Chrome</tt> и <tt>Safari</tt>. Поддерживаются везде они, естественно, только через vendor prefix (<tt>-chrome-*</tt>, <tt>-o-*</tt>, <tt>-moz-*</tt>). <tt>Transforms</tt> поддерживается всеми нормальными браузерами, <tt>Transitions</tt> WebKitом и Operой.

* Преобразования (''Transforms'') — имеются ввиду аффинные.
* Переходы (''Transitions'') — плавные переходы какого-то свойства от одного значения к другому.
* Анимации (''Animations'') — более сложные, с заданием траекторий и поддерживающие события.

Нюансы:
* ''vendor prefix'' удобно определять через <tt>if(typeof(element.style.webkitTransform) != 'undefined')</tt>.
* Наличие анимаций удобно определять, определяя в CSS стилях секцию <tt>@media screen and (-webkit-transform-3d) { }</tt> и в ней задавая какой-то стиль, и проверяя его наличие <tt>javascript</tt>’ом.
* Избегайте CSS анимации блоков шире 2000 пикселей ''/* с чего бы это вдруг :-) */''. В айфоне — 1024 и лучше анимировать минимум элементов.

=== Дата-центр своими руками: best practices / Максим Климко ===

Выступали товарищи из Оверсана в рыжих футболках с надписью «Самые пиzдатые дата-центры» ''(из песни слова не выкинешь)''.

Нюансы выбора места для дата-центра. В Москве площадок мало, но найти в принципе можно, кто ищет — найдёт. «Но есть нюанс» (ц). Например, часто есть электричество, но нет на него документов, их могут обещать привезти через неделю из отпуска с Канарских островов или ещё откуда-нибудь. Или наоборот — место обалденное, но электричества нет. Или наоборот — площадка и не очень удобная вроде, но зато электричества — заешься. Может и стоит рассмотреть её тогда. Вообще с электричеством в Москве не так плохо, как, например, в Лондоне — там электричества нет ''(ездят на осликах — прим.вред)''. Или было такое — разлили ртуть, потом конечно собрали, но всё равно там людям находиться как-то не очень, наверное… Или — хранили фосфор, потом построили дата-центр.

Было пространное обсуждение окружения дата-центра — магистрали, история площадки, что находится рядом (места беспорядков?) и т. п. ''(вывод — дата-центр нужно закапывать — прим.вред)''. Было обсуждение фальшпола, фальшпанелей и т. п., в котором я как-то не очень разобрался, но понял что
* а) это всё нужно и
* б) фальшпол нужно располагать не меньше чем в 60 см до ближайшего препятствия.
Про чиллеры (ну это такие кондиционеры большие) — у них как-то итальянский (ну считается самые супер) немного то ли сломался, то ли чего-то нужно было сделать, а специалист никак не приезжал, в итоге приехал гендиректор и сам сделал, сам гайки крутил. Вот попробуйте говорит наших гендиректоров чего-то покрутить. ''(только сотрудников на …)'' Это он приезжал, когда было −25 на улице, он конечно очень порадовался, что при такой температуре оборудование ещё живо, пообещал внести изменения в конструкцию (шланги, кажется), лишь бы мы его домой отпустили :)

Про пожарную сигнализацию — даже хорошо, когда ручная, а не автоматическая, потому что автомат может отсигнализировать, когда уже всё сгорело на хрен (ну не настолько, но всё-таки). А датчики мониторинга температуры, влажности и т. п., которые всегда надо везде ставить и мониторить, гораздо более чувствительные и могут гораздо раньше отследить начало пожара или даже условия, которые изначально к нему приводили, и вообще предотвратить. Так что не пугайтесь, если в ДЦ как-нибудь увидите индикатор «автоматика отключена». :)

{{warning}} [[Участник:StasFomin|Стас Фомин]] 19:19, 18 августа 2010 (UTC): Ага, не пугайтесь. Как там сказано про причины пожара в <tt>Hosting.ua</tt>: «Установленная в нем самая современная система оповещения о пожаре почему то не сработала, хотя по некоторым данным она была отключена вручную.

Про охрану — она конечно хорошо, но лучше делать, чтобы клиенты всё-таки могли всегда к себе попасть без эскалации насилия до уровня гендиректора и выше. Например, придумать систему печати разовых пропусков.

Про оранжевые стены :) это их любимый цвет, но делать их не пришлось, потому что неоптимально. Оптимальны светлые. А вообще самый распространённый цвет в русских дата-центрах — цвет бетона.

=== Облачная футурология по материалам западных конференций / Дмитрий Лоханский (Oversun Scalaxy) ===

Они ещё живы :-) но как-то немного более грустны, в прошлом году он был на офигенно положительном настрое, такой весь инновационный :) сейчас более спокойный, и с презентацией!! (в прошлый раз был без).

Доклад был про общие вопросы облаков, про приватные облака, смешанные облака, про то что амазон всё ещё офигенно рулит по сравнению с остальными ''over 3000'' облаками. Из него я вынес две вещи: совет прочитать книгу «В центре Торнадо» Джеффри Мура и идею «а вот представьте если чтобы дома было электричество, надо было покупать токамаки и ставить на коло в дата-центр» :)

=== Реальный опыт использования облачного хостинга для высокопосещаемых сайтов / Евгений Потапов (Сумма АйТи) ===

Ооооо! Грёбаный ад!!! Вот уж действительно — я ожидал серьёзного доклада про высокопосещаемый сайт, а было … Про makemebabies точка com, рассчитанный на западную аудиторию. Название и целевая аудитория уже многообещающая. Что-то много примеров видел, как западные посетители используют такие идиотские сайты, что ужас какой-то. Или там просто пользователей больше, а соответственно, в абсолютном числе больше и идиотов? Так вот, идея сайта в том, что берутся две фотографии «папы» и «мамы» (или даже одна?), как-то там от балды комбинируются и обрабатываются, и создаётся фотография возможного ребёнка :-D был даже случай — случайно сервисом воспользовалась какая-то мексиканская локальная поп-звИзда и у неё получилось похоже на реального ребёнка — от радости она тут же выступила в шоу, и к ним навалило клиентов. При всём этом в докладе звучали фразы «у нас очень серьёзные API-клиенты, они требуют доступности 24x7». Мда. Как страшно жить.

Если шутки в сторону, простой ресурсов был, после миграции в облако стало меньше, но мгновенно отреагировать на нагрузку всё-таки не получается — логично, нельзя очень быстро сервера создавать, время создания от 10-60 минут. SMB в облаке не работает. XEN-овые виртуалки плохо реагируют на высокую дисковую нагрузку — после неё ещё минут 10 остаётся фатально долгий <tt>iowait</tt> и время от времени падает производительность дисков ''(наверное, от других таких же мэйкмибэйбисов — прим.вред)''.

Но всё-таки после устаканивания проблем повысилась стабильность, повысилась надёжность при пиках нагрузки, и несколько понизилась цена аренды (повторяем, всё-таки '''после''' устаканивания). А ещё очень хочется уйти от инстансов нафиг к вычислениям с автоматическим масштабированием, вроде <tt>Google AppEngine</tt> — вот оно, реальное облако, это тебе не виртуалки ''(но наверняка будут свои проблемы и нюансы)''.

''Кстати, мне кажется, что когда (и если) «тру-облака» типа AppEngine станут популярны, то есть когда все будут платить только за вычисления, вычисления в дневное время сразу подорожают :) для большего пикового объёма вычислений всё равно же нужно больше мощностей, никуда не денешься!''

=== Технологии Яндекс. Пробок / Михаил Левин (Яндекс) ===

Рассказ про то, как обрабатываются данные от GPS-ников и не только для осознания пробок. Кстати, про существование светофоров и съездов, на которых бывает пробка в то время, когда остальные ряды едут, они знают, но пока не сделали. Презентация была прикольная, рисованная на доске маркером и цветных листочках, клееных на эту доску.

Требования к системе у них — нагрузоустойчивость, живучесть — чтобы можно было убить все дата-центры, кроме одного, актуальность данных, отсев неверных данных. Всё это в условиях, когда GPS довольно много глюков гонят — на малых скоростях человека как будто колбасит по всему району, координаты не очень точные, к карте могут не очень хорошо привязываться. А ещё есть пешеходы и товарищи, которые останавливаются поп.. в смысле покурить, и их надо отсеивать. Их отсеивают методом голосования — для того, чтобы нарисовать пробку, нужна хотя бы парочка машин. Работают некие серверы <tt>UsersHandler</tt> и <tt>SegmentsHandler</tt>, которые сохраняют состояние при мягких перезапусках, на входе в каждый ДЦ диспетчер, он взаимодействует также и с другими ДЦ.

Ещё есть асессоры, которых нанимают в районе, кажется, 20, и они ездят по заданным маршрутам и проверяют качество яндекс-пробок. Вроде ездят по 3 часа.

=== Костыли — это кошерно! / Павел Кудинов (Точка Кипения) ===

Феерический бред на темы, которые первыми попали под руку. Чувак без комплексов. Вселенные — способ размножения богов, компьютеры скоро сами будут писать программы, ну хотя бы отлаживать, и т.п. Зал угорал над ним и мечтал спросить, ''чем он бахается'' (то есть — какие тяжёлые наркотики употребяет). Эмоций положительных у меня доклад не вызвал, грешно над такими смеяться, это как South Park, только сильно хуже и тупее :D. Или как блондинки — без них жизнь была бы неинтересна, так одна моя знакомая говорит.

''Надо ему ноги сломать, дать костыли и сказать, что это кошерно.''

''В общем, я считаю, что очень зря этот доклад пустили на конференцию.''

=== Блиц-доклады ===

==== Андрей Шитов — Say Perl на весь мир ====

Рассказ про существующие и несуществующие агрегаторы новостей по теме perl’а и про то, что с некоторых сайтов новости можно брать и переводить google translate’ом, чтобы читать всяких японцев. Короче — [http://planetperl.ru/ Planet Perl]. Я его читаю :)

==== Вячеслав Олиянчук — CSScomb.ru: инструмент для сортировки CSS свойств ====

Инструмент, который написан нормально, но цель чисто личная — что-то типа <tt>CSS Tidy</tt> (<tt>Tidy</tt> — инструменты для чистки кода и ''code-style''’а, например [http://tidy.sourceforge.net/ HTML Tidy]), сортировка CSS свойств в порядке, который можно задать руками. Ну типа такой ложный перфекционизм, смысл на самом деле можно и потерять при этом. Малополезно.

==== Шафиев Наим — AnyEvent::HTTPBenchmark ====

Товарисч написал на событийной машине {{CPAN|AnyEvent}} аналог [http://httpd.apache.org/docs/2.0/programs/ab.html ab]. Пробовали в реальном времени положить http://ritconf.ru/ (сайт конференции), чем очень порадовали аудиторию. Положили, время от времени он давал ошибки :)

==== Анатолий Шарифулин — Template Toolkit — зло?! ====

Тема ПРАВИЛЬНАЯ, содержание забыл. Сводится, по-моему, к тому, что лично он использует Embedded Perl (EP) шаблоны из {{CPAN|Mojolicious}}'а и лично ему нравится, и что TT — таки действительно зло. ''Подтверждаю. Мои размышления на схожую тему — [http://yourcmc.ru/wiki/Template_Toolkit#.C2.AB.D0.9D.D0.B5_.D0.B8.D1.81.D0.BF.D0.BE.D0.BB.D1.8C.D0.B7.D1.83.D0.B9.D1.82.D0.B5_Template_Toolkit.21.C2.BB Не используйте Template Toolkit].''

==== Виталий Филиппов (я) ====

Я выступал с двумя блицами про наши расширения к MediaWiki, если интересно — вики-статьи с дуализьмом статья-презентация вот: [[Google Notebook на MediaWiki]] и [[Презентация-трансформер: S5 на MediaWiki]] (для просмотра презентации нажимать на картинку с подписью «Slide Show» справа вверху страницы).

==== Стас Фомин — ShowTeamWork — визуализация работы команды ====

Стас рассказывал про [[ShowTeamWork]].

== День третий ==

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

=== Альтернативы Active Directory в мире UNIX / Филипп Торчинский (Sun) ===

По сути, доклад про [http://www.opends.org/ OpenDS] (LDAP на жабе) и [https://opensso.dev.java.net/ OpenSSO] (<tt>Single Sign-On</tt> на жабе), рассказ про то, что это такое. Не особо слушал.

=== (p) NFS v4.x и не только — развитие сетевых файловых систем / Андрей Пантюхин ===

Системы хранения у нас делятся на:
; DAS (''Direct Attached Storage''): Все стандартные интерфейсы подключения хардов к компьютеру — <tt>IDE</tt>, <tt>SATA</tt>, <tt>SAS</tt>, <tt>USB</tt> и т. п.
; NAS (''Network Attached Storage''): <tt>SMB</tt>, <tt>NFS</tt> и так далее. Высокие задержки при обращении, которые, правда, сглаживаются кэшированием в лучшую сторону. Кластеризация: <tt>Lustre</tt>, <tt>NetApp GX</tt>, <tt>Isilon</tt>, <tt>Panasas</tt> — проверенные, фокус на скорости.
; SAN (''Storage Area Network''): <tt>Fibre Channel</tt>, <tt>FCoE</tt>, <tt>AoE</tt> ([[wikipedia:ATA_over_Ethernet|ATA over Ethernet]]), <tt>iSCSI</tt> и т. п. Низкие задержки при обращении, которые, правда, сглаживаются файловой системой в худшую сторону. Кластеризация: <tt>Oracle Exadata</tt>, … (???) — сыровато, фокус на надёжности.

Есть ещё «гибридное» решение — '''pNFS''' (''parallel NFS''), когда на файловом сервере хранится только каталог, где что лежит, а сами данные отдаются с других мест по тому же <tt>Fibre Channel</tt> независимо.

Вообще <tt>NFS</tt> (''Network File System'') живёт с 1984 года, она независима от транспорта, хорошо восстанавливается после сбоев, относительно простая, довольно шустрая — на 5-15 % медленнее FC и на 5-10 % быстрее iSCSI.

<tt>NFS</tt> от Sun’а передан IETF в ~2000 году. Они родили 4-ую версию, взявшую что-то от <tt>CIFS</tt>, <tt>AFS</tt>. Новости 4-ой версии (NFS 4.x, 4.1):
* Возможность ''mandatory locking'' (безусловные блокировки при открытии файлов).
* Кроссплатформенность (4.1), лёгкость расширения спецификации.
* <tt>Compound RPC</tt> — несколько операций можно складывать в один пакет для уменьшения задержек.
* «Кэширование» двух последних файловых дескрипторов (ну прям <tt>$_</tt> :)). Типа «читай из последнего», не надо говорить, какого.
* UTF-8.
* Все отдельные экспорты («папки») наконец-то стали склеиваться в один корень!
* Кэширование, делегирование (дал файл — работай локально, потом вернёшь исправленный).

NFS 4.1 (RFC 5661) — самый длинный RFC. 600 страниц. «Но воды там нет, всё по делу :) так что читается легко :)»

=== Хроники окопной войны / Денис Бугров ===

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

«Продукт не так важен, как маркетинг». ''Вот-вот, продукты все ваши платные — отстой потому что (прим.вред).''

=== Создание картографического сервиса на коленке (PostGIS/MapServer) / Андрей Костенко (Рамблер) ===

Докладчику для его http://visamap.net/ (карты, куда можно получить визу?) понадобился картографический сервис. Который был реализован на [http://postgis.refractions.net/ PostGIS] (геофункции в <tt>PostgreSQL</tt>’е), данных из [http://www.openstreetmap.org/ OpenStreetMap] (укороченного набора, полный «многовато» весил) и [http://mapserver.org/ MapServer]'е. В качестве клиента брали гугловский (Google Maps) JS-клиент, доработанный напильником (уж очень им понравилось приближение колёсиком мыши).

«Кривые в PostGIS кривые :) — некоторые функции не работают.»

«MapServer: отвинчиваем тормоза.»

Картографические проекции бывают с искажениями как минимум либо длин, либо углов, либо площадей, либо форм. Обычно везде используют [[rupedia:Проекция Меркатора|проекцию Меркатора]].

Функции PostGIS: содержание фигуры в фигуре, площадь, расстояние, преобразования проекций, упрощение (обязательно использовать в сервисе!), минимум/максимум x/y, <tt>bounce</tt> (обвести точку кружком), преобразование кривых в полигоны.

=== Хранители: Свободные [веб]системы, спасающие разработчиков / Стас Фомин (CustIS) ===

Стас как всегда жёг, рассказывал реинкарнацию доклада с [http://team.custis.ru/2007/11/secr-2007.html SECR-2007]. Есть видео — [[Свободные_системы,_спасающие_разработчиков_(РИТ-2010)]].

В твиттер писали «Стас Фомин — прекрасный буйный», «доклад Стаса Фомина — то, ради чего можно было жить весь третий день конференции». :)

{{CONFIDENTIAL-BEGIN}}
А у нас есть запись в блоге: [[Блог:Стас Фомин/2010-04-19 Мое выступление на РИТ-2010]].
{{CONFIDENTIAL-END}}

=== Управление рисками / Денис Самосеев ===

Вообще ни о чём. Говорит я хотел сделать управление рисками проще для вас всех, при этом подача информации совершенно унылая, с кучей чего-то там, первые 15 минут слайды не листал, задержал следующего минут на 15 тоже, «я — вообще самый крутой PM в Москве, но я разленился и меня сейчас наверное выпрут».

Ну, типа риски. Ими типа никто не управляет. Ну а типа надо. Экселевским файлом. :-D

=== Грабли в Agile на опыте Afisha.ru (3-летний опыт) / Виктор Ламбурт (Афиша.ру) ===

Презентация: http://www.slideshare.net/rit2010/lamburt-viktor-agile-2010-0413

* Начало перехода на Agile — падает производительность. Сразу хочется — вернуть контроль. Не надо! Agile сдохнет :) лучше сразу подготовиться к тому, что производительность упадёт.
* Ломание итерации — вставка в итерацию исправления багов. Предусмотрите на них время на планировании (10-30 %). При изменении требований переносите в следующую итерацию.
* Пропуск ретроспектив — если такое начинается, надо исправлять и проводить их обязательно! Это основной инструмент прогресса.
* Желание отдать крупномасштабное планирование разработчикам — не получится! Agile это «о том, что сегодня и завтра», но никак не через полгода или год.
* Ощущение бега в колесе (фиг там новизна, фиг там свобода…) — нужно делать бонусные задачи и ленивые итерации (например, «подчищать хвосты»).

Дальше у них чисто свои проблемы — у них тестеры и проектировщик(и?) работают не по Agile, и поэтому возникает затуп в районе проектирования/дизайна — они-то типа медленнее. Ну… что делать. Нужно добавлять ресурсов туда. Отсюда же — неуловимый Product Owner (всё время с дизайнерами), что есть плохо — он нужен, планировать надо обязательно с ним и т. п.

«Agile ради Agile — не надо, если дорого готовится итерация».

[[Категория:РИТ-2010|Ф]]