Wikilogs

Много вожусь с SVG-файлами — это свободный векторный формат, для которого есть прекрасный редактор (Inkscape), в нем я делаю большинство иллюстраций к книгам, документации и презентациям. Добивало одно — не было возможности предпросмотра в Windows Explorere (да, я пользуюсь связкой FAR+Explorer в качестве файловых менеджеров). Но наконец-то обнаружил, что это теперь не проблема — надо поставить Thumbnail Plugin, от компании Examotion.

Наконец-то Гугл сделал то, что я навязчиво желал уже лет пять, а именно, «персонализации поискового пространства» хоть в каком-нибудь виде. С этой навязчивой идеей я ломился и в Яндекс, и в другие поисковые системы (общался с программистами и т.п.). Убивало то, что необходимость этого (для меня очевидную) совершенно непонимали, отмазываясь несущественными трудностями технического плана.

Конечно, SearchWikiдалек от идеала — например, наткнувшись на спамопомойку, естественное желание любого пользователя убрать ее со всех своих запросов (а не только с текущего, как сейчас). Название не очень удачное («казалось бы, а причем тут Лужков Вики?» — ведь никакого влияния на общий поиск пока совершенно нет), есть такое ощущение, сделано для борьбы с поисковиком «Wikia Search», первой стартовавшим на поле коллаборативного глобального поиска.

Но самое главное — я вижу, что реальность развивается в правильном направлении («погоды стоят предсказанные» ©), и я теперь могу расслабиться и не думать на эту тему.

Пару месяцев назад прочитал Robin Williams «The Non-Designers Design Book».

Особых восторгов высказать не могу, информации достаточно мало, тянет скорее на пару-тройку статей («немного о принципах дизайна визиток», «немного о шрифтах», …), весь объем, т.е. почти две сотни страниц, обеспечивается огромным числом примеров. Это с одной стороны хорошо, с другой — все эти задачи и примеры для технологий прошлого века — чернобелая бумажная печать. Ничего разумного про вебдизайн или работу с цветами нет.

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

Но в целом, пролистать-прочитать можно. Существует в электронном виде, говорят есть даже не слишком вменяемый перевод. Но кому лень, прилагаю свой конспект-майндмап ниже (может хотя бы станет ясно, имеет смысл читать, или нет). Вообще наверно теперь буду сопровождать свои рецензии на книги/курсы/другоеГрузилово майндмапами. В первую очередь, я делаю это для себя, но думаю, может быть кому-нибудь полезно. Лично я, с удовольствием бы потыкался в фрагменты майндмапа, перед тем, как прорубаться через текст (даже рецензии).

Смотреть mindmap можно через Java-applet (да, несколько тяжеловат, но по современным меркам, однократная загрузка 800кб — ерудна, это уже среднеблоггерская говнофотка столько весит, зато обеспечивает наиболее корректную отрисовку) или Flash (для тех, кто с явой не дружит, но там отрисовка может быть далека от оригинала). Майндмап: Java-версия или Flash-версия

Решил провести некоторую диверсификацию блога. Если раньше это у меня был такой канал «обо всем встреченном и потенциально полезном ищущим», то теперь ограничу его тематику околоITшными вещами — обзоры технологий, книг, курсов, мероприятий, решения встреченных проблем. По прежнему, никакой копипасты, т.е. только личный опыт.

Остальное теперь пойдет в другие блоги. Всякая потребительская аналитика (товарные отзывы) уйдут в stas-fomin.ya.ru, рецензии на худлит, видео и мультфильмы — туда же или на belonesox.imhonet.ru, оргвопросы по преподаванию будут на ispras-courses.blogspot.com, ну и кое-что пойдет в блог компании team.custis.ru.

Ну и если что-то из перечисленного заинтересует, подписаться на корректный набор каналов без лишнего шума явно станет проще.

Был на AgileDays, попробовал выступить видеооператором.

Отчет и видео тут.

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

Следующая проблема, это низкочастотный DLP-проектор дал при записи на камеру экрана проектора раздражающее (по-крайней мере меня) мерцание. Я пробовал разные видеофильтры к VirtualDub, но ни одним из них убрать мерцание не удалось. Deflicker от Graafa вообще не повлиял, MSU_Deflicker вроде уменьшил мерцание, но дал столько других мерзких артефактов, что лучше нээ…

Пока по видео сделал две версии — 12 кадров в секунду, для желающих посмотреть мимику докладчика, и 4 кадра в секунду (мерцание становидся редким и не раздражающим) для внимания к экрану — и слайды и скринкасты вполне при такой частоте смотрибельны, а вот движения докладчиков напоминают брейкданс на танцполе со стробоскопом.

Но вообще, нравится мне идея узкоспециализированных конференций-семинаров, как любое дешевое и эффективное решение. Правда было бы удобней, если бы площадка была в центре. Мне, например, очень нравится площадка ГУ ВШЭ, где проводится много околософтверных семинаров, см. http://blog.styleru.net/

А если семинар относительно небольшой — не больше 50 человек, то отличная площадка у нас в компании, стационарно оборудованная (мощный проектов, 4 метровый экран, и т.п) для презентаций. Если тема нам сокультурна (а спектр интересных нам тем достаточно широк), то вполне можно совершенно бесплатно договорится и провести семинар у нас.

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

Однако в любом случае уже будет баян, ибо встречайте серию современных книг по математике «The Manga Guide to …».

Случилось невозможно страшное — сутки у меня был неработоспособен Gmail. «Temporary Error (502)» сразу после логина. Первый час было забавно, к ночи стало не до шуток.

Где трехкратное дублирование с автоматическим восстановлением? Вот тебе бабушка и «вебдваноль и профиль в сети», вот тебе SaaS… .

Наблюдения:

• Русской техподдержкой пользоваться бесполезно — отправил репорт через http://mail.google.com/support/bin/request.py?contact_type=gtag_server&ctx=gtag_server&hl=ru — реакции никакой.
• Англоязычная техподдержкаhttp://mail.google.com/support/bin/request.py?contact_type=gtag_server&ctx=gtag_server&hl=en видимо работает — и ответ получил с извинениями, и ящик к утру заработал.

Выступление Андрея Бибичева, я к сожалению, проспал (всю ночь записывал диски с portable-версией MediaWiki), и конечно, хотя дали под выступление большой зал, раннее время — штука подлая. После первого унылого дня народу стало сильно меньше, а уж поднять себя на эту унылость к 9:00 смогли не все. Но вменяемые люди оценили — например, распорядитель первого зала был явно удивлен глубиной доклада (по сравнению с некоторой поверхностностью стандартных докладов ажайл-евангелистов), о чем он собственно и заявлял прямым текстом.

Выступление Андрея Сатарина посмотреть удалось, в целом было удачно, в передних рядах народ был вполне в теме, и сразу стали атаковать вопросами в стиле «Continuous Integration для детских проектов, а наши проекты настоящего King Size размера, их фиг за ночь соберешь, не то, что по commit-у» (наезжающие стали соревноваться в длине сборки между собой). Тут я вмешался, и мне кажется, удачно парировал наезды, аргументируя необходимостью грамотной системы сборки, с использованием make/ant/scons — так как при нормальной, модульной структуре проектов и иерархических зависимостях, объем необходимой пересборки в среднем при любом коммите будет весьма ограничена. Например, если разбить объем сборки на сбалансированное бинарное дерево длины l с узлами равного объема, то даже в худшем случае (коммит «попал» в листовой узел) нужно выполнить объем в раз меньший полного объема. Исключения, когда объем небъется на части есть — «создание базы и заполнение тестовыми данными», например, но для таких случаев тоже есть лайфхаки (например, база в памяти). Плюс, возможно придется бить на части набор юнит-тестов — (выполняемые по каждому коммиту, еженощно и т.п.). Как это делать, у меня конечно есть идеи (статистика срабатываний, важность накрываемого функционала и т.п), но надо посмотреть, что на этот счет говорит наука. Возможно при доработке этой презентации или разработки отдельной темы («Тонкости Continous Integration…») надо этот момент расписать и проиллюстрировать.

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

В целом, за пару недель мониторинга по блогам, видно, что онлайн-реакция слабая, всего пара отзывов. Кое-какая дискуссия развернулась здесь.

Лично я получил всего пару приглашений в мойкруг и писем с критикой. Хотя критикой полезной, ибо совсем забыл про проблему русских имен файлов под переносимой под Windows сборкой MediaWiki, эту проблему нужно все равно будет решать.

С другой стороны, вполне можно повторить тему доклада про MediaWiki (проработав дополнительные части, например UML-графы по текстовому описанию), на конференции типа РИТ, без боязни прослыть «баянистом» (если возьмут, конечно).

И все же, надо продолжать светится при возможности на этой конференции, ибо аудитория этой конференции есть, и она почти не пересекается с «интернетными» конференциями РИТ/Highload (возможно поэтому отзывов в блогах и мало, может по курилкам-то обсуждения и пошли). На SECRе есть такие редкие категории, как участники из регионов, депутаты, IT-бизнесмены и менеджеры и т.п.

Отчет о конференции SECR-2008, а также куча мыслей о правильной организации IT-конференций.

Интересная реклама микрософта на башорге:
Много вопросов — а разгадка однаответ один — «Микрософт!».

Обнаружил, что теперь в Google Docs можно грузить PDFы. Но убиться веником — поиска-то по документам нифига нет. Google-сервис и без поиска — ерунда какая-то. Зачем-то сделан Flash-preview страниц, причем есть ощущение, что по сети гоняют растровые картинки. Зачем? PDFы смотреть гораздо удобней в родных вьюверах, тут я имею в виду как адобовских, так и любых других, не-веб-флеш вьюверы. А ведь есть полезный сценарий, оправдывающий сию поделку — функциональность комментирования. Т.е. рецензент может просматривать PDF, и вставлять в заинтересовавшем его месте (на странице) метки-сноски, и привязать к меткам-сноскам обычный текстовый комментарий (ну там понятно со стандартной функциональностью комментариев к блогам — извещения по почте и т.п.)

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

Разродился комментом, может поймут и учтут.

Кстати, acrobat.com тоже посмотрел, но там полная смерть от флеша, что мне не надо. Хотя приятно, что вроде как нет ограничений на объем — 30Mb пдф залился без проблем.

Внезапно перестал засыпать (и standby и hybernation) ноутбук. Местами еще BSOD 0x0…08e при загрузке. Т.е. полная задница, ибо без режима сна пользоваться ноутбуком (да и наверно уже чем угодно, кроме постоянно включенной рабочей станции) невозможно. Гуглил — вариантов сотни, ничто не подходит. Пытался откатываться назад «восстановлением» — на пару дней назад не помогло, а потом и вовсе перестала откатываться. Пошуршит полчаса, перегрузится, и вердикт — «восстановление не удалось». Меланхолично так, блин.

«scansfc /now» тоже не помог.

Стал исследовать память через AVZ, скачал Debugging Tools и пакет символов ядра, стал смотреть разбор коредампов.

Нашел причину. От удаленных Daemon Toolsов, что бы им пусто было, остался SPTD — SCSI Pass Through Direct layer. Он то, гад и давал прикурить.

Выкорчевал его, и все стало хорошо. Но времени и нервов потратил изрядно, да.

Заболел Firefox толи после очередного апгрейда, толи от «старости» — адресная строка перестала работать, плюс во всех вкладках, кроме первой, шла индикация типа «идет загрузка». Причем заболел только один, основной профиль. Проблема совершенно не гуглилась, но решить ее удалось. Надо удалить нафиг файл places.sqlite из каталога профиля.

Вообще универсальное лечение для всех болезней FF — грохнуть *.sqlite файлы в каталоге используемого профиля. Ничего критического не погибнет — всякую персонализацию (пароли там и т.п.) вы вспомните, история наполнится снова, закладки и прочие ценные настройки распарсятся и загрузятся из текстовых файлов.

Завтра и послезавтра наши парни будут на  SECR-2008. Заранее публикую презентации и статьи докладов.

• Андрей Сатарин, «Continuous Integration или каша из топора»: презентация, статья;
• Андрей Бибичев, «Аналитик в Agile: Анахронизм или необходимость?»: презентация, статья;
• Стас Фомин, «MediaWiki: серебряная пуля или швейцарский нож?»: презентация, статья.

Кстати, эта осень жирна на конференции. 23 и 24 октября  будет Software Engineering Conference (Russia) 2008, на которой я буду приглашенным докладчиком (invited speaker, высокая честь).

Планирую раскрыть тему вик и их выбора — «Mediawiki: Серебряная пуля или швейцарский нож?». Думаю, будет весело и интересно, более того, кроме речей я планирую раздачу слонов — работающих portable медиавик, с кучей наших расширений, на WAMP-платформе (т.е. под Windows и переносимых копированием), чтобы те, кто еще не  в теме, погрузились и прониклись немедленно.

Кроме меня будут еще пара интересных и актуальных докладов от наших парней.  Вот на «РИТ: Высоких нагрузках» в кулуарах оказался втянут в всего в два разговора — один, «что делать скучающему аналитику в Agile» — эту тему должен раскрыть доклад «Аналитик в Agile – архаизм или необходимость?», и на тему Continuous Integration — тут будет выступать наш перспективный QA-инженер с докладом «Введение в непрерывную интеграцию или каша из топора».

Ну и конечно, можно будет активно устно пообщаться.

Заметки о посещенных на конференции Highload++-2008 докладах.

Раньше сделать это не мог — была сумасшедшая неделя, где кроме конференции у меня были лекции в МГУ и МФТИ, к которым пришлось готовится ночами, плюс куча работы, в общем спал мало, и вообще провел неделю на кофеине с ноотропами.

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

Кстати, трубки Siemens Gigaset S44 (которые к Siemens Gigaset S645 идут) — полное дерьмо. И трубка из комплекта, и дополнительная уже во второй раз попадает в ремонт. Ремонт тянет на 60-70% их стоимости, а судя по реакции сервисменов, болезни их известны и широко распространены. Что было — год назад обе трубки «ослепли» — перестал работать дисплей-индикатор, а вот только что — оглохли, одна за другой с интервалом в пару недель — перестал работать динамик. В результате сдал их в ремонт, недели полторы без домашнего телефона дома — жена не простит… Луч ненависти сименсу. 

 Прошелкурс «Стратегия управления взаимоотношениями с клиентами (CRM)».

Разумный курс, времен моды на внедрение CRM-систем. (Да, автор курса тоже уже пару лет как не в этом бизнесе, да и сейчас крупным заказчикам вместо CRM/ERP-систем принято «продавать» сервисную архитектуру, ESB, SOA, плюс Master Data Management, а CRM теперь есть всего лишь производный аспект вышеперечисленного).

Автор пишет легко, и в целом разумно, регулярно приводя бизнес-кейсы. Конечно, те, кто на острие маркетинговой мысли (как признак — читают блог Сета Година) , вряд ли узнают какие-либо откровения, но разработчику или внедренцу сервисных приложений читать полезно весьма — даже не в смысле узнать что-то волшебное, а как чисто набор шаблонов/заготовок для всяких внедренческих бумаг (коммерческих предложений, техобследований, ТЗ, НИРов и т.п.).

Вопросы простые, но часто используется плохая форма тестов — multiple select (экспонента вариантов), и смущает, что часто надо отмечать все варианты для правильного ответа (спойлер!).

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

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

Вообще мне стыдно, но надо признаться, что в году 1999 я даже на АвтоВАЗ писал (тогда у них емайл был только у вебмастера сайта), убеждал внедрить CRM-систему с системой регистрации дефектов, советовал багзиллу. (Ничего не ответила рыбка). Прошло десятилетие, рабочие и инженеры ВАЗа попали в инет, но судя по веткам типа этой [1], сие ВАЗу уже не поможет.

Теперь уже полно «народных» CRM на любой вкус в модели SaaS с недорогой арендой. Но то, что они не так распространены — мне видится несколько причин. В определенном смысле весь интернет целиком (совокупность вебресурсов) стал CRM-системой с размазанной информацией о клиенте, а локальные CRM-системы, в каждой из которых нужно отдельно регистрироваться, отпугивают массового пользователя. Ну и опять таки, светить денежные потоки в какой-то общей системе — для РФ, видимо будет неприемлимо весьма долго. 

Но у меня есть идея для нового вебсервиса —  система бронирования времени в сфере услуг. Т.е. поставщики — предприятия или частные мастера. Парикмахерские (парикмахеры), врачи (терапевты или стоматологи), высококвалифицированные строители-ремонтники (типа «крутой электрик-сантехник», а не «комплексный ремонт за год»), репетиторы, массажистки,  ну и вообще, на что фантазии хватит (ЕВПОЧЯ)…

Поставщики держат в системе календари занятости. Потребители идентифицируются с помощью Open-Id (контакты-адреса нужно хранить безопасным образом в системе), и могут заказывать услуги поставщиков, выбирая и аллокируя свободное время (календари со свободным временем доступны). Т.е. не надо звонить, мучительно согласовывать «точку встречи» с секретарями и т.п. Можно хранить историю посещений-отношений, вести обратную связь, электронную репутацию, а деньги выносятся за скобки (как договорятся). Можно также привязать Google Maps (координаты), и загнать в сервис алгоритмы составления-рекомендации оптимальных расписаний — это даст уникальность (УТП) и труднокопируемость сервиса.

И сбудется мечта Пелевина — человек человеку будет не друг, не брат и не волк, а дилер и эксклюзивный дистрибьютер.

3 День второй3.1 Sphinx в примерах и задачах

Мне ужасно стыдно, но я проспал. Хотя тема явно интересная, уже есть два эффективных бесплатных и опен-сорс движка полнотекстового поиска — Sphinx и встроенный поиск PostgreSQL. Очень интересно кто-кого, и даст ли «синергию» конкуренция и перекрестное опыление.

Например в некоторых наших внутренних MySQL-системах я уже подключил Sphinx для поиска, в некоторых — думаю подождать и сразу перейти на PostgreSQL, и делать полнотекстовый поиск с морфологией напрямую в БД.3.2 Организация асинхронной обработки задач

Частично опоздал, но в целом доклад не оправдал моих ожиданий. Судя по названию можно было бы ждать опыта использования специализированных продуктов — от вендоров, типа Oracle Advanced Queuing (в тезисах говорилось про оракл), IBM WebSphere MQ,…, а может даже и опен-сорс. Увы, рассказали о простом самодельном решении на оракле. Как-то невозбуждающе.3.3 Практическое использование Hadoop в системе интернет-статистики

Разумное и модное решение задачи параллельной обработки и агрегации логов посещения сайтов. Используется фреймворк Hadoop (параллельные вычисления в парадигме map/reduce), который для таких задач вроде как идеально предназначен, и в общем-то единственно доступный (опен-сорс), ибо гугловый аналог закрыт, а больше вроде ничего нет.

Кластер относительно небольшой (12 восьмиядерников с 8Gb памяти), но справляется. Два прохода:

Схлопывание текстовых многополевых атрибутов в idы (индексирование).

Обработка (агрегация разного рода) полученных индекс-файлов, получени отчетов.

Ну и всякие там хитрости, вроде все разумно. Опять таки, убьют наверно баннерорезки и этот бизнес.3.4 CAS — сервер приложений C++

Как-то не. Ждал «сервер приложений C++». Оказалось, «не сервер», «не приложений», «не C++». То есть ребята написали очередной шаблонизатор, для вызова из скриптовых языков. Вроде как быстрый (судя по картинке-гистограмме с неподписанными осями и без единой цифре), но как-то не то, что ожидалось.3.5 Виртуализация в среде highload servers

Вроде по содержанию маркетинговый доклад, подвигающий фишку виртуализации от SWSoft — вместо выполнения виртуальных машин целиком (VMWare, Hyper-V, Virtual PC, VirtualBox, …), на хост машине размещается одно ядро операционной системы, а виртуализуется все остальное — файловая система и все что на ней.

Для маркетингового доклада выглядел как-то вяло, но оказалось, что докладывал не маркетолог, а инженер техподдержки (для него это нормально).

Выгоды сферической виртуализации в вакууме понятны, угрозы тоже (взлом виртуальной машины высоковероятно приводет к взлому машины хостера, и конец всей сотне виртуальных машин). См. например An Empirical Study into the Security Exposure to Hosts of Hostile Virtualized Environments. Да и без всяких взломов, как выяснилось, трудно рулить физическими ресурсами — например можно ограничить виртуальную память каждой машине, но живую память квотировать нельзя — соответственно одна «оборзевшая» виртуальная машина может поставить «раком» остальных.

Сравнений с конкурентами тоже не было. Но тема интересная. Может доживем до момента, когда и монстры типа яндекса, будут жить на виртуальных серверах, переползающих с одного железа на другое.3.6 Application Streaming

Жесткий маркетинговый («парилово») доклад от ENDEAVORS. Презентация с гламуром и анимацией, причем разработанная видимо зарубежом — ни слова по-русски (даже не локализовали).

Суть — очередные модели SaaS, не только как вебприложений, но как скачиваемых в специальную среду rich-приложений, работающих ограниченное время (за плату). Почему-то утверждалось, что CRM-системы на вебинтерфейсе невозможны (вроде как неправда).

Постоянно упоминались куча софтварных патентов, за которых этой конторе вынуждены отстегивать собственно производители типа Microsofта, технологии защиты цифрового контента, и прочие штуки, которые я ненавижу. Надеюсь в светлом будущем не придется арендовать фильмы в виде защищенного этой технологией одноразового приложения, а все эти технологии благополучно сдохнут. Пусть разве что останутся честные SaaSовсцы, предоставляющие (пусть за деньги) приложения на своем хостинге.3.7 Архитектура Photofile.ru

История эволюции архитектуры фотохостинга, от совсем любительской (на одном сервере), до более-менее масштабируемой. В деталях, как появлялись разные узкие горла, и какими эвристиками с ними боролись — как включали второй сервер, как перетаскивали файлы, оставляя на их месте симлинки, как делали шардинг через Dynamic DNS и т.п.

Алсо, ругали Cache Smarty.

В общем, с появлением таких монстропроектов, как «я.фотки», «netprint.ru», с огромным машинным и человеческим ресурсом, с изначально масштабируемой архитектурой, фотофайлу наверно высокие нагрузки более не угрожают.3.8 Архитектура и реализация сервиса печати фотографий netprint.ru

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

Архитектура — Java, вроде как разваленная на вебсервисы (JMS), плюс PHP+XCACHE+LightHttpd для вебморды. Кстати, опять таки PostgreQL.

Максимальная асинхронность, все операции не более константной сложности, причем константу загоняют до нижнего предела:

вместо удаления — пометка об удалении, удаляет специальный демон потом;

перекодировка изображений — написали сами оптимизированный под Intel код, вроде как порвал ImageMagick в десятки раз.

Ребята не ведутся на марки, тренды и авторитетов:

бэкап делают на ленты, ибо посчитали, что чуть дешевле (для новых систем вроде как ленты лет уж пять как похоронили общемировым консенсусом).

опять таки самописная обработка изображений,

RAID — sucks.

тренировки по восстановлению в формате «внезапная пожарная тревога» (может шутили?),

изучение поведения системы под нагрузкой в дни естественных пиков (пост-праздники, НГ).

Попытался после конференции передать свои пожелания к системе. Например, печать EXIF-дат фото на обратной стороне. Когда я еще печатался в мелкой локальной фотолаборатории, моя самописная утилита переименовывала имена файлов под ISO-дату, и как-раз первые восемь символов имени файла печатались сзади. Очень удобно, легко понять, когда это фото и что. Когда начал печататься в нетпринте, халява закончилась — там все фотки при загрузке переименовывались. Это меня теперь сильно останавливает от печати — не хватало еще усугублять файловый бардак, бардаком с бумажными фото. Подождем, может сделают. На самом деле, им даже не нужно патчить софт в машинах-фотолабораториях, проще написать «переименовывающий фильтр» перед подачей этих файлов в машины.3.9 Решение проблем высоких нагрузок на примере проекта Яндекс. Фотки

Сервис очень хороший, и докладчики наверно хорошие (редкий зверь — два докладчика, практически «парный конферанс»), но доклад вызвал раздражение и аллергию.

Презентация намеренно сделана «банально-попсовой», символы архитектуры заменены всякой порнографией (типа женский бюст — Cisco, банан с двумя апельсинами — сами додумайте и т.п.). Плюс дурацкие фото, как эмоциональная иллюстрация идей. Что-то похожее я видел на презентациях с конференции автоматизаторов торговых сетей — тупые и тривиальные тезисы слайдов засыпаны содержимым с fishki.net чуть более чем полностью.

Но возможно это лично мое извращенное мнение, аудитория вроде реагировала живо, наверно понравилось. По сути, конференция — это гибрид похода в кино, театр, тусовку и ресторан одновременно, и народ алкает зрелищ и развлечений.

А так типа все круто, масштабируемость, распределенные датацентры, супернадежность (мониторинг мониторинга) — остальным фотохостингам остается или закрыватся, или искать нишу (ЕВПОЧЯ).3.10 Доставка контента пользователям

Обнаружил, что есть сервис smotri.com, позиционирующийся как самый крутой в рунете. Вообще в этой теме (протоколы передачи видео и т. п.) практически не разбираюсь, посмотрел архитектуру — местами «стандартно фотохостинговая», местами есть специальные гитики.

Средняя температура по больнице — 4 минуты на ролик, 250Кб/сек — доставка. Отметил, что пользуются WebDAVом для трансляции операций по загрузке и редактированию и не жалуются.

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

Вроде всех все устраивает, другая оптимизация не нужна. Хотя может если видео пойдет в большем качестве, то наконец все упрется не в диски-память, а в сеть, и тут понадобится более серьезная оптимизация.

2 День первый2.1 Что такое нагрузка

Хороший доклад, «еще раз о компьютерной архитектуре от практика-железячника».

Диски, память, сеть. Кэш, кэш, кэш.

Прочувствуйте «физику» процесса, подивитесь огромному GAPу эффективности диска на последовательном и рандомном доступе.

Мимоходом «похоронены» SAS/SCSI диски — их удел только в «кеширующих» машинах с высоковероятным рандом-доступом, а в основном нечего выделываться, берите обычные SATA и используйте правильные алгоритмы, (сортировки дисковых массивов — только слиянием и т. п.).

RAIDы вроде тоже заругали (или в другом докладе, не помню) — смысл, что надежность должна обеспечиваться уровнем выше, типа вместо 3 живучих «Тигров» пусть будет 30 Т-34.

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

AMD с привязкой памяти к процессорам must die.2.2 О проектах, отягощенных производительностью

Очень ценный доклад, наиболее профильный для нашей компании. Докладчик сразу отметил, что сейчас есть два самых распространенных полюса систем:

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

корпоративные системы — сложная логика, то есть одна транзакция дает движение в куче таблиц-счетов и т. п., и вообще объем кода в строчках и человеко-годах огромен. Ошибаться нельзя, падать нельзя, но нагрузка плевая.Но есть и редкий третий тип. Речь зашла о редких высоконагруженных «бизнес-логичных» системах (такие имеет смысл ловить наверно только в ЖКХ — офигически сложные расчеты всяких там льгот, куча транзакций и т. п.), или какой другой массовый биллинг (телекоммуникационный). Банки думаю не — кроме яндекс.денег, любой интернет-банк по нагрузке отдыхает.

Ну а дальше, докладчик прошелся по всем аспектам разработки таких систем, разрушая мифы, раздавая эпитеты и приговоры различным технологиям:

СУБД кроме Oracle, DB2, MySQL и PostgreSQL — ересь,

Oracle DBA зажрались и в массе лохи,

Java есть современный надежный Cobol, и это есть хорошо.

С# сам по себе ничего, но развертывание дороговато, (в основном за виндовс-сервер-лицензии).

Python прет (Django?), возможно будущее за Java+Python.

Всех (обоих) творцов на Erlangе гнать-избегать,

RoR — тормозит,

двухзвенка масштабируется отстойно (привет «Oracle и PL/SQL» подходу), по сравнению с трехзвенкой,

потому что кэш СУБД слишком тупой-низкоуровневый.

нефиг выделываться с XML-сериализацией — CPU на ветер.

Другие мысли:

на инфраструктуру — 10 % прибыли.

автоматизация тестирования форм — обязательно (видимо имелись в виду веб-формы).

В общем, наверно самый полезный для нас доклад, надо дождаться видео (я даже запросил DVD-диски, может пришлют), и смотреть всем.2.3 Как писать высокопроизводительные сервера

Жаркий дискуссионный вопрос. Давным-давно, во времена первого апача, порождавшего при обслуживании пул с трудом переключаемых процессов, все уяснили, что переключение контекста процесса есть штука чудовищно дорогая, и ее надо минимизировать. На помощь пришли методы телекоммуникационщиков из систем реального времени — никакой многозадачности с планировщиком («кузнец нам не нужен»), должна быть однопроцессная система с конечным автоматом (FSM), обрабатывающем события. На таких принципах реалован очень популярный вебсервер статики nginx. Но много минусов — кроме статики он ничего не умеет, стандартные вебфреймворки к нему не прикрутишь.

Автор же доклада принес благую весть — треды в apache2 уже достаточно эффективны и хороши, можно держать их тысячами и пользоваться всеми благами апача (или они пока только в BSD хороши, а в линуксе тормозят — уже не помню, но это не принципиально).

А если применить собственный механизм переключения облегченных тредов (которых обозвали «зелеными тредами», «ко-рутинами»), то вообще никакого проигрыша конечному автомату не будет. Да, у этих корутин есть некоторые болезни (для переключения используется тот же механизм, что для обработки C++ исключений, поэтому от исключений придется отказаться), но в целом, это прогресс и возможно гвоздь в гроб идеи FSM.

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

Вроде как проверено на крупных яндекс-проектах, типа краулера и верхнего уровня поиска.

Была жесткая дискуссия, требовали доказательств, цифр, корректного эксперимента.

Я лично склонен поверить докладчику.

Причем с корутинами думаю не столкнусь, а то что апач2 с тредами хорош (пусть даже чуть хуже FSM) — это хорошо, возможно альтернативы ему отомрут сами со временем.2.4 HCS — система хранения данных в Рамблере

Расшифровку аббревиатры забыл — некая библиотека для реализации некоторой алгебры операций (слияния, фильтрация, агрегация,…) над сверхбольшими плоскими файлами. (1011 строк, 10Tb/ 200Gb обновлений в день).

Работает быстро (сравнивали правда с неоптимизированными движками MySQL), но, насколько я понял, это не параллелиться (а ведь есть Hadoop, который вроде как можно было бы применить для этих задач).

Вроде готовится к публикации в опен-сорс.2.5 Сервис хранения данных на базе SQL Server Data Services

Маркетинговый доклад. Верный признак «чисто маркетинга», когда всякие «архитектурные» картинки рисуются блоками с градиентной заливкой, всякий гламур и анимация на слайдах. По сути некая компиляция whitepaperов разных технологий (SaaS, DaaS, PaaS,… все модные buzzwords, все в кучу).

Интерес (судя по заполненности зала) был слабоват.2.6 Проблемы работы с большими объемами реляционно слабосвязанных данных в высоконагруженных веб-проектах

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

В общем и новизны нет, и не похоже, что решение оптимально и вообще адекватно задаче.2.7 Масштабирование системы баннерной рекламы с централизованной базой данных

Примитивная и кривоватая реализация баннероторговли и баннеропубликации на Oracle.

Зачем там Oracle — совершенно непонятно, скорее всего унаследованный код финансовых модулей на PL/SQL, которых лень переписывать, вокруг чего начали воротить все остальное. Ибо надежность там не нужна, транзакционность и немедленность реакции — тоже (грузят апельсины бочками данные SQLLoaderом), вообще как-то все ---. Похоже еще есть момент экономии на лицензиях (другой логики для централизованности СУБД я не вижу).

Бизнес примитивный и надеюсь скоро вымрет, когда баннерорезки будут у всех, кроме полных даунов (и накручивающих трафик роботов), а реклама станет контекстной и уйдет в поисковики.