РИТ-2010: Отчёт Виталия Филиппова — различия между версиями

Версия 15:08, 30 октября 2013

Сайт конференции: http://www.ritconf.ru/
Даты проведения: 12-14 апреля 2010
Место проведения: Infospace (ИнфоПространство)

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

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

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

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

День первый

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

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

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

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

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

Доклад частично был «ни о чём», условно говоря:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рассказывали про то, какой у них скрам:

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

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

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

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

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

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

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

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

В докладе таких высказываний много и все очень интересны, пересказать всё не могу, смотрите презентацию.

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

Просто доклад про Sphinx и то, какой он хороший полнотекстовый и не только индексатор. Конкретно про удобство использования в связке с MySQL было мало.

День второй

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

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

Ссылки: Erlyvideo, презентация.

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

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

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

Нюансы:

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

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

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

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

Было пространное обсуждение окружения дата-центра — магистрали, история площадки, что находится рядом (места беспорядков?) и т. п. (вывод — дата-центр нужно закапывать — прим.вред). Было обсуждение фальшпола, фальшпанелей и т. п., в котором я как-то не очень разобрался, но понял что

а) это всё нужно и
б) фальшпол нужно располагать не меньше чем в 60 см до ближайшего препятствия.

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

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

Warning: Стас Фомин 19:19, 18 августа 2010 (UTC): Ага, не пугайтесь. Как там сказано про причины пожара в Hosting.ua: «Установленная в нем самая современная система оповещения о пожаре почему то не сработала, хотя по некоторым данным она была отключена вручную.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Инструмент, который написан нормально, но цель чисто личная — что-то типа CSS Tidy (Tidy — инструменты для чистки кода и code-style’а, например HTML Tidy), сортировка CSS свойств в порядке, который можно задать руками. Ну типа такой ложный перфекционизм, смысл на самом деле можно и потерять при этом. Малополезно.

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

Товарисч написал на событийной машине AnyEvent аналог ab. Пробовали в реальном времени положить http://ritconf.ru/ (сайт конференции), чем очень порадовали аудиторию. Положили, время от времени он давал ошибки :)

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

Тема ПРАВИЛЬНАЯ, содержание забыл. Сводится, по-моему, к тому, что лично он использует Embedded Perl (EP) шаблоны из Mojolicious'а и лично ему нравится, и что TT — таки действительно зло. Подтверждаю. Мои размышления на схожую тему — Не используйте Template Toolkit.

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

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

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

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

День третий

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

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

По сути, доклад про OpenDS (LDAP на жабе) и OpenSSO (Single Sign-On на жабе), рассказ про то, что это такое. Не особо слушал.

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

Системы хранения у нас делятся на:

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

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

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

NFS от Sun’а передан IETF в ~2000 году. Они родили 4-ую версию, взявшую что-то от CIFS, AFS. Новости 4-ой версии (NFS 4.x, 4.1):

Возможность mandatory locking (безусловные блокировки при открытии файлов).
Кроссплатформенность (4.1), лёгкость расширения спецификации.
Compound RPC — несколько операций можно складывать в один пакет для уменьшения задержек.
«Кэширование» двух последних файловых дескрипторов (ну прям $_ :)). Типа «читай из последнего», не надо говорить, какого.
UTF-8.
Все отдельные экспорты («папки») наконец-то стали склеиваться в один корень!
Кэширование, делегирование (дал файл — работай локально, потом вернёшь исправленный).

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

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

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

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

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

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

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

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

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

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

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

Стас как всегда жёг, рассказывал реинкарнацию доклада с 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 — не надо, если дорого готовится итерация».