3 День второй
3.1 Инфраструктура Facebook - особенности крупных социальных приложений
- http://rit2008.ru/paper.html?id=7547&conf_id=6394
- http://rutube.ru/tracks/620673.html?v=230bc79ad67561b8c0a61b51a19a2aef
Автор (http://moskalyuk.name) удачно рекламировал свое детище (http://www.facebook.com/), с позиции уверенного превосходства («Мы первые среди …», «Вторые по …», «тут меряли криво, но так и быть мы третьи по …»). Забавный момент был в комментах ответах на вопросы — на вопрос «у вас бесплатный MySQL или Entreprise версия», докладчик ответил «не знаю, но так как Brian Aker из MySQL постоянно у нас ошивается — наверно платная». Т.е. чисто анекдот «не знаю кто в машине, но шофер у него — сам Путин». Ну также «у нас работают разработчики ключевых технологий вебдваноля: Firebird, Firefox, Memcached».
Ключевой момент — заманивают разработчиков для разработки Facebook-приложений. Утверждается, что возможности для этих приложений (API и т.п.) не слабее, чем возможности стрежневых модулей Facebook, которые архитектурно равнозначны приложениям сторонних разработчиков (одинаковые интерфейсы и т.п.).
Т.е. уже веб три-ноль получается — если два-ноль был это когда используют энергию толпы, людей, то три-ноль — мощь креатива роботов, т.е. массы сторонних приложений.
Не удержался и зарегистрировался и на facebook.com. Однако быстро заскучал — русских там как-то вообще нет (в отличие от badoo.com), и забросил.
3.2 Кэширование в nginx
- http://rit2008.ru/paper.html?id=7548&conf_id=6394
- http://rutube.ru/tracks/620185.html?v=6b2f565cd57460216cf99deec521c7e6
Удачные шутки автора — «все упоминали платиного спонсора — микрософт, и я сейчас это сделаю: я буду как Микрософт, говорить о том, чего еще нет», «Microsoft любит интерактив — давайте тоже устроим детский сад». В отличие от аудитории, мы пользователями nginx'а не являемся, разве посмотрели на «виновника» знаменитых ошибок «502 Bad Gateway Timeout».
Рассказывал о новых возможностях кеширования — теперь nginx запущенный перед тормозящей вебсистемой, может полностью скрыть не только ее торможение, но и полную неработоспособность — т.е. система может месяц как полностью сдохнуть, а кеш будет возвращать пользователю «свет давно умершей звезды».
3.3 Новый PostgreSQL 8.3: превосходя ожидания
Тема, представленная одними из самых крутых экспертов по Постгрессу в России (http://postgresmen.ru/), о ключевых преимуществах именно версии 8.3.
Т.е. если вы судите о PostgresQL по предыдущим версиям — то вы не в теме, если вы помните, что «PostgresQL — это что-то про слонов, и видимо такое же медленное» — то это больше не так.
Автор привел прекрасный аргумент — графики падения раза в три процессорной загрузки, и уменьшение где-то на порядок дисковой активности, после апгрейда PostgresQL баз для хоть стартапной, но уже достаточно здоровой социальной сети (http://mirtesen.ru) с версии 8.2 до 8.3. Причем апгрейд сделан между рабочими днями, и график транзакционной загрузки показывает, что дело не в вымирании (или какой-либо другой флуктуации) пользователей. Реально хочется верить в хорошее, и есть желание портировать какой-либо здоровый учетный проект с Oracle на PG, заодно проделав нагрузочное тестирование.
Минус докладчика — презентация почти по методу Такахаши (см. «Как сделать презентацию за час до доклада?» ниже), т.е. крупные блоки текста — и докладчик слово в слово зачитывал их. Так никогда делать нельзя! У людей параллельно работают и визуальный и аудиоканалы, и если им одновременно грузить ровно одно и то же, происходит интерференция и теряется внимание! Т.е. если на экране текст — говорите другими словами, а еще лучше — визуально только картинки, символы, ключевые слова и цифры — остальное хорошим устным текстом.
3.4 PostgreSQL. Лучшая СУБД для Web 2.0
По сути было продолжение предыдущей темы, но теперь в первую очередь обращенную для веб 2.0 разработчиков, т.е. аргументировалась предпочтительность PostgresQL перед MySQL.
Автор (http://samokhvalov.livejournal.com/), являясь не только Postgres-экспертом, но и состоявшимся веб-дваноль разработчиком (1 (http://moikrug.ru), 2 (http://mirtesen.ru)), делился некоторыми рецептами простого решения (с перекладыванием основной работы на PG) стандартных вебдванольных задач (структурирование контента тегами и каталогами, построение индексов по нетривиальным типам aka геокоординаты, «быстрый и суггестивный поиск» а-ля подсказки Google).
Насколько вебразработчики повелись на это — для меня непонятно. Оптимальность по скорости им скорее не так важна, надежность прохождения каждой тразакции — тоже (подумаешь страничка упала ― перегрузят или перезальют). Целостность всегда разменивается на скорость. Им важно, чтобы данные не терялись уж совсем, и все было максимально беспроблемно — было много инструментов для всевозможных задач, база широко распространена — можно найти дешевого специалиста из ПТУ на поддержку, любая проблема типа «как сделать бла-бла-бла» сто раз обсуждена в форумах и гуглится на раз.
Мне же интересно, насколько PG может атаковать позиции Oracle, причем в заказных разработках (финансы, учет), где нельзя терять (ни задержать) ни одной транзакции. Да, мне нравится идея, вместо того, чтобы искать по перегретому рынку дорогих (и редко вменяемых Oracle DBA), плюс бухать огромные деньги за лицензии с совершенно никакой поддержкой, платить за техподдержку баз парням, которые разбираются у СУБД внутри.
Мы в принципе собираемся портировать наш супер фреймворк для PostgresQL (сейчас поддерживается Oracle и MySQL), но, когда решение о выборе СУБД принимает заказчик, то даже в идеальном и «безоткатном» случае, нужны очень серьезные и разные аргументы (бенчмарки, графики надежности, прецеденты, знающий персонал), чтобы убедить заказчика рискнуть.
Поэтому сейчас очень интересны первопроходцы в учетных-финансовых системах. 1C уже начали ставить на Postgres, и это хорошо.
Возможно действительно, мы присутствуем при историческом моменте — начале конца гегемонии Оракла на рынке СУБД.
3.5 Там, где не поможет база данных. Узкие места баз в веб-окружении. Задачи, которые не решаются пока никак
Разочаровался. Думал будут рассказывать о преимуществах нереляционных систем хранения — иерархических, файловых (≈PyTables/HDF5), кубов и прочих денормализованных кешей, а докладчик достаточно уныло и протяжно перечислял места, где действительно, реляционные СУБД не очень. Так как за полдоклада от проблем к решениям он так и не перешел, я с доклада ушел.
3.6 Кризисы роста в ИТ-компании
Известный гуру IT-маркетинга пояснил, что основная причина проблем в растущей IT-компании — ее старые сотрудники. Переход от специалистов знающих «ничего обо всем», и полезных для стартапов и небольших команд, к специалистам «все о ничем», рулящим в больших компаниях неизбежен, и первые в большой компании будут минимум бесполезны и морально разлагающи для остальных, максимум — вредны. Приводились рецепты, что делать — от эвтаназии увольнения, до гуманных методов — дайте им пенсию, творческий отпуск на несколько лет, долю в компании (на худой конец — опционы).
Ну раз доктор сказал «в морг!», значит мне туда. Но я требую гуманного отношения — да, пенсию, или хотя бы ренту плюс творческий отпуск.
3.7 Бизнес и Agile: оптимизация процесса компании
Ну глупо наверно пересказывать известного SCRUM/Agile-тренера от ведущей российской Agile-организации http://agilerussia.ru.
Пара наблюдений.
1. В отличие от SECR-2007, где все было как-бы под знаком CMMI, и еще более безумных тяжелых практик (типа Six Sigma) и Agile-практики выглядели как некоторое освобождение порабощенного и затраханного разработчика от всяких регламентов, бизнес-процессов и метрик, то в этой анархической вольнице веб-разработчиков, SCRUM выглядел наоборот — какие то ограничения, регламенты и странные практики, когда в «партизанской банде» веб-разработчиков ваще полная свобода (по результатам общения в кулуарах с одним из веб-разработчиков).
2. SCRUM уже стал некоторым buzz-word, даже последние комиксы Dilbert стали проходится по ежедневным скрам-митингам (верный признак потери «очарования молодости»):
- http://dilbertru.blogspot.com/2008/04/20080415-10.html
- http://dilbertru.blogspot.com/2008/04/20080416-5.html
Поэтому уже недостаточно позиционироваться как «альтернатива пути CMMI», или просто кивать на запад — нужно показывать работающие примеры, успешные примеры компаний и проектов, говорить о реальных проблемах и путях решения.
Собственно об этом и был следующий доклад.
3.8 Практика внедрения Scrum: трудности и пути их преодоления
- http://rit2008.ru/paper.html?id=7675&conf_id=7539
- http://www.custis.ru/docs/publishing/2008-04-15-scrum-from-custis-show.pdf
- http://www.custis.ru/docs/publishing/2008-04-15-scrum-from-custis-article.pdf
Докладчик (mailto:andrew@custis.ru) неторопливо и методично, с минимумом buzz-words разобрался тонкости внедрения SCRUM в реальных проектах. Очень качественные слайды, но вместо «кокаинового возбуждения» свойственного сейлзам или «технологическим евангелиствам», имел место быть стиль типа «медленно, медленно мы спустимся с горы и…».
Показателем интереса аудитории может служить тот факт, что зал был забит чуть более чем полностью, плюс презентация с вопросами заняла на полчаса больше — но никто не думал прерывать шоу (что обычно проделывали с другими докладчиками — тупо выгоняли «обсуждать в кулуары») или расходится.
Вопросов было много, часть из них в духе «Доктор, смогу ли я после удаления аппендицита играть на скрипке?…», часть к смежным темам («системы материальной мотивации» и т.п.) да и после того, как совесть заставила докладчика и вопрошающих освободить зал под следующий доклад, общение продолжилось в этих самых кулуарах до самого окончания конференции.
Докладчика на всех не хватало, и некоторым желающим пороли отсебятину отвечали на вопросы коллеги докладчика (в частности я). Видимо, будет еще смысл провести один или несколько семинаров с обсуждением по этой теме на нашей площадке, где можно показать и живых разработчиков, и SCRUM- инструменты и практики.
Комментариев нет:
Отправить комментарий