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

Короткая ссылка: RIT2010V

Ссылки сюда (3) →

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

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 на улице, он конечно очень порадовался, что при такой температуре оборудование ещё живо, пообещал внести изменения в конструкцию (шланги, кажется), лишь бы мы его домой отпустили :)

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

Стас Фомин 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).

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

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

Вообще ни о чём. Говорит я хотел сделать управление рисками проще для вас всех, при этом подача информации совершенно унылая, с кучей чего-то там, первые 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 — не надо, если дорого готовится итерация».

---

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