Insight IT

Реинкарнация сайта

Иван Блинков — Sat, 30 May 2015 20:10:00 +0300

После, пожалуй, самого длительного периода без обновлений в истории Insight IT, сайт прошел через "реинкарнацию" - был переделан с нуля, сохранен лишь контент. Этого сложно не заметить, если Вы здесь не впервые. Желающих получить ответы на вопросы в духе "как так?", "зачем?", "что поменялось?" и "что дальше?" - прошу читать далее.

Как так?

Многие годы, занимаясь Insight IT, я совмещал приятное с полезным: по большому счёту оставаясь просто хобби, сайт помогал мне знакомиться с будущими партнерами, клиентами, коллегами, что долгое время позволяло мне обходиться без стабильного источника дохода. Когда я в итоге "сдался" и пошел работать в крупную компанию за зарплату - эта дополнительная ценность стала менее значимой. Во многом из-за этого здесь нельзя найти ни одной записи датированной прошлым годом (хотя есть и другие причины, конечно, но об этом в заключении).

Зачем?

Резонный вопрос - зачем вкладывать столько сил, чтобы всё переделать на в заброшенном сайте? Началось всё со спортивного интереса: я начал замечать, что постепенно теряю хватку в мирах opensource и веб-разработки. В Яндексе вокруг меня по большей части разный backend внутренней разработки. Кандидат для экспериментов в лице Insight IT нашелся быстро, что из этого получилось - в следующем разделе.

Что поменялось?

R.I.P. WordPress

Первые 6 c половиной лет своего существования Insight IT проработал на WordPress в качестве CMS. С пьедестала самой популярной CMS в мире, насколько я знаю, за всё это время WordPress так никто и не сместил. Думаю, в первую очередь благодаря крайне простому в использовании интерфейсу для управления сайтом, а во вторую - выдающемуся ассортименту плагинов и тем. Плюс имевший место в 2008-м акцент на блоги отходит в сторону, сейчас на нем какие только сайты не делают.

Но за ~~красоту~~ простоту приходится платить:

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

Вопрос с производительностью решается агрессивным кешированием и клиентской оптимизацией. Не раз занимался этим для других сайтов, в том числе и на WordPress, но для некоммерческого проекта не понятно как оправдать трудозатраты на изначальную настройку и поддержание этого всего в рабочем состоянии. Зачастую плагины разрабатываются без оглядки на то, что, например, JavaScript-библиотека, от которой они зависят, может быть ещё не быть загружена и пытаются ей пользоваться в распечатанном прямо вперемешку с HTML JavaScript, что даже само по себе плохо, а с перенесенными вниз зависимостями и вовсе не работает.

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

Уже в 2009-м минусы WordPress для меня начали перевешивать плюсы. Тогда достойной альтернативы, увы, не нашлось и всё осталось как есть. Но не в этот раз.

Статические сайты

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

Вместо хранения в базе данных статьи и другой контент приравнивается к исходному коду, то есть:
- Хранятся в системе контроля версий в виде файлов в специализированном формате (как правило, Markdown или ReStructured Text), который удобен для написания человеко-читаемых текстов и однозначно преобразовывается в чистый, валидный, HTML.
- Пишутся в текстовых редакторах, ориентированных на разработчиков, с подсветкой синтаксиса, автодополнением и т.п.
- При необходимости легко начать использовать общепринятые инструменты для работы с кодом, в том числе совместной (ревью кода, ветвление, непрерывная интеграция, отслеживание проблем).
С помощью make или аналога сайт собирается примерно так же, как это делала бы программа на C++:
- Создается output директория с будущим результатом.
- В ней генерируются все страницы сайта - для статей с помощью шаблонизатора добавляется вся необходимая HTML-обвязка, а навигационные страницы (по категориям и тегам, с по-страничным выводом) создаются с нуля, тоже по шаблону.
- Весь клиентский код на JavaScript и CSS, а также статические файлы вроде изображений, группируются и прогоняются через разные фильтры для уменьшения количества файлов и их размеров.
- Внутренние ссылки в исходном коде как правило реализованы по путям в локальной файловой системе, а как они будут выглядеть в итоговом сайте конфигурируется и тоже применяется при сборке.
В итоге, чтобы посмотреть на результат в браузере подойдет любой веб-сервер, умеющий отдавать статические файлы из папки, то есть совсем любой за вычетом специализированных.
Как легко такую папочку кешировать на всех уровнях, а также как быстро и дешево можно такой сайт показывать пользователям, рассказывать, думаю, не нужно.
Но у отсутствия динамической серверной логики есть и минусы:
- ~~Тоска по гламурной админке WordPress.~~
- Для реализации некоторого функционала (в нашем случае - комментариев и поиска по сайту) требуется как-то изворачиваться, возможные варианты:
  - Воспользоваться сторонним сервисом - Disqus уже использовался и раньше, а обе лидирующие поисковые системы предоставляют сервис поиска по конкретному сайту, так что я пошел по этому пути).
  - Поселить рядом с кучей статики какой-о набор скриптов, но не очень понятно как их интегрировать с системой сборки сайта, которая по сути выполняет роль CMS.
  - Реализовать его на JavaScript - скажем для поиска по сайту можно при сборке сложить весь контент в один большой JSON, и искать по нему уже на клиенте. Но я решил пожалеть пользователей с долгоиграющими ноутбуками, особенно новых без вентиляторов. Раньше ещё можно было пожалеть владельцев смартфонов, но когда их стали делать восьми-ядерными...
- Время, которое технически необходимо для публикации нового контента или изменений в шаблонах, начинает зависеть от размера самого сайта - не смотря на попытки реализовать кеширование при сборке, многие изменения требуют перегенерации примерно всего сайта.
И, напоследок, ввиду низкой серверной ресурсоемкости таких сайтов, для него легко найти качественный хостинг бесплатно.

Взвесив "за" и "против", я решил, что для Insight IT такой вариант очень даже подходит. Осталось выбрать конкретную реализацию такой системы сборки сайта.

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

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

Подходящую альтернативу искать долго не пришлось: выбор пал на Pelican, практически единственный вариант на Python. Готовых плагинов у него не так много, но самое основное есть, а недостающее мне определенно было не сложно допилить, благо с экосистемой Python я тесно знаком. В качестве шаблонизатора используется Jinja2, лучше которого я по-прежнему ничего не видел. Про сам перенос сайта можно написать отдельный пост, и не один, что я надеюсь и сделаю в скором будущем, так что здесь эту тему дальше развивать не буду.

https://

Как при желании можно было заметить, Insight IT уже много лет живет за CloudFlare - многофункциональной распределенной прокси, выполняющей роль CDN, DNS,защиты от разного рода атак и многого другого. Изначально поддержка SSL была доступна только на платном тарифе, который некоммерческому проекту был ни к чему, но с недавних пор это стало не так и я за компанию решил перейти на https://, раз уж всё равно все внутренние ссылки переехали. Плюсы не критичны, но всё же есть:

Само отображение защищенного соединения в адресной строке браузеров внушает уверенность если не всем, то какой-то части посетителей
Поддержка современных протоколов в лице SPDY и, вероятно, со временем HTTP/2.0
Говорят, использование защищенного соединения положительно сказывается на репутации сайта в глазах как минимум поиска Google
Владельцы публичных WiFi точек не могут показывать свою рекламу на сайте

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

К слову, стоявший за CloudFlare простенький VPS тоже заменен, на наиболее популярный среди хостингов статичных сайтов GitHub Pages.

Контент

В состав Pelican входит инструмент для конвертации статей из XML-формата WordPress в Markdown, которым я и воспользоваться. Большую часть работы он сделал, но всё равно потребовался ручной просмотр и адаптация всех страниц сайта. Это заняло уйму времени, но в целом того стоило:

Везде причёсан HTML, во многом благодаря Markdown; лучше оформлены изображения и врезки, ещё раз проверены опечатки.
Исторически статьи раскладывались по рубрикам по мере написания, по-этому общая структура сайта была хаотичной. Теперь разбил их на категории по-другому, на этот раз, надеюсь, более логичным образом.
Пока перечитывал осознал, что значительная часть контента морально устарела и годится только для совсем начинающих или как историческая перспектива. Решил сделать некоторый акцент на годе публикации - теперь он присутствует в URL статей, а также в оглавлении публикаций об архитектуре высоконагруженных интернет-проектов. Совсем-совсем неактуальным пришлось пожертвовать или явно подписать соответствующим образом.
Как следствие из предыдущих двух пунктов, в очередной раз полностью поменялась структура ссылок сайта. По-возможности со старых адресов сохранены редиректы, но, к сожалению, в концепции статических сайтов возможны только клиентские, через meta-тег или JavaScript. Поисковые системы же предпочитают серверные, через 301/307 HTTP-код и заголовок Location.
В общем, позиции Insight IT в поисковых системах определенно пострадают, остается лишь надеяться что не катастрофическим образом - ведь сейчас это основной источник посетителей. Если вам не безразлична судьба сайта - твиты, лайки и прочие входящие ссылки по новым адресам крайне приветствуются.
Теперь весь контент публикуется под лицензией Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License, о чем свидетельствует значок в правом-нижнем углу каждой страницы.

Дизайн

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

За всё те же последние несколько лет Twitter Bootstrap стал решением по-умолчанию для подобных ситуаций благодаря низкому порогу входа и хорошей комбинации встроенного функционала, кроссбраузерности и приличного внешнего вида. По иронии ровно это и стало причиной моего от него отказа в данном случае: уж больно он всем приелся и на каждом углу почти без изменений используется.

В своё время мне приглянулось своей стройностью и логичностью концепция Material Design от Google, которую они активно внедряют сами и всем советуют. Не долго думая, я пошел поискать opensource решения с готовой реализацией для веб-сайтов и остановился на варианте, который одновременно имел достаточный функционал, сколько-либо большое сообщество и минимум зависимостей, особенно от громоздких JavaScript-библиотек, чем грешили альтернативные варианты.

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

Итого, с моей субъективной колокольни получилось заметно лучше прежнего, но хочется всё же услышать и ваше мнение в комментариях.

Что дальше?

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

С закрытием Google Reader два года назад число подписчиков на счетчике от FeedBurner упало почти на два порядка, так что можно считать, что сейчас и правда для Insight IT всё начинается почти с начала.

Вакансии: разработчики облачной IaaS платформы в Крок

Иван Блинков — Thu, 19 Sep 2013 19:40:00 +0400

Вакансии более не актуальны

Ведущая российская ИТ-компания ищет талантливых, креативных и энергичных инженеров и разработчиков для развития коммерческой облачной платформы КРОК, предоставляющей услугу типа «Инфраструктура как сервис» (IaaS). В современном высокотехнологичном офисе Вас ждет дружная сплоченная команда профессионалов, занимающаяся разработкой передовой «облачной» платформы, у которой всегда найдется для Вас множество интересных, сложных и разнообразных задач, способных удовлетворить даже самые заоблачные амбиции!

Разработчик на платформе Linux

Обязанности

Проектирование архитектуры компонентов «облачного» решения;
Разработка и интеграция модулей облачной платформы;
Исследования в области распределенных высоконагруженных систем.

Требования

Опыт в области shell-программирования;
Уверенное знание Python, приветствуется знание С++ или Java;
Владение средствами разработки (autotools, git, svn и др.);
Опыт администрирования ОС Linux от 1 года (преимущественно RHEL, CentOS, Debian или SLES);
Опыт работы с технологиями виртуализации (Qemu/KVM, XEN, Hyper-V или VMware);
Знание «облачных» технологий особенно приветствуется.

Инженер по облачным решениям

Обязанности

Общение с техническими специалистами заказчика для определения задач и специфических требований, предъявляемых к информационной системе;
Исследовательская работа по поиску, тестированию и внедрению различных технологий;
Участие во внедрении решений для автоматизации ИТ-инфраструктуры;
Тестирование различных вариантов исполнения инфраструктурных решений;
Техническая поддержка внедряемых решений решения.

Требования

Навыки администрирования современных ОС GNU/Linux и Windows;
Понимание принципов виртуализации вычислительных ресурсов;
Приветствуется опыт написания сценариев на языках shell и Python;
Личные качества: коммуникабельность, общительность, активная жизненная позиция.

Условия

Конкурентная заработная плата по результатам собеседования;
Возможность профессионального и карьерного роста;
Компания оплачивает обучение и сертификацию;
Социальный пакет (медицинская страховка, бесплатное питание в офисе, спортивные программы и компенсация фитнеса, английский язык);
Компания оказывает помощь при переезде в Москву (оплата стоимости проезда для прохождения собеседований, «подъемные» при выходе на работу).

Куда отправлять резюме?

Вакансии более не актуальны

Вакансии: PHP и Python разработчики в Киеве

Иван Блинков — Thu, 20 Sep 2012 20:16:00 +0400

Вакансии более не актуальны

Киевская команда разработчиков игр для социальных и мобильных платформ Level UP ищет опытных специалистов по веб-разработке на Python и PHP.

Senior Python Developer

Задачи:

Разработка высоконагруженных веб-приложений;
Разработка внутренних и публичных API;
Разработка архитектуры комплексных сервисов;
Конвертирование бизнес-задач в технические решения (R&D).

Требования:

Опыт разработки на Python более 3х лет;
Сильные навыки применения реляционных и нереляционных баз данных;
Опыт в разработке высоконагруженных веб-приложений;
Дружба с Linux и Git;
Хорошее знание клиентских технологий (HTML, CSS, Javascript);
Опыт работы в команде.

Плюсом будет:

Опыт разработки комплексных проектов на PHP или серверном Javascript (node.js);
Опыт разработки инструментов для верстки, автоматизации верстки, шаблонизаторов и пр.

Senior PHP Developer

Задачи:

Разработка высоконагруженных социальных веб-приложений;
Работа в небольшой дружной команде до 15 человек;
Решение нетривиальных задач и создание инструментов для внутреннего использования;

Требования:

Опыт разработки на PHP более 3х лет;
Опыт работы с MySQL и MongoDB;
Опыт в разработке высоконагруженных веб-приложений;
Дружба с Linux и Git;
Хорошее знание клиентских технологий (HTML, CSS, Javascript);
Опыт примененения функционарного и юнит тестирования.

Плюсом будет:

Опыт разработки на Python или серверном Javascript (nodejs).

Условия для обоих вакансий

Зарплата в диапазоне \$2500-4000 в месяц по результатам собеседования;
Полный рабочий день в Киевском офисе, иногородним помощь с переездом;
За успешную рекомендацию специалиста по данным вакансиям компания выплачивает бонус в размере $1000 так что сообщите своим знакомым, кому-то это может быть интересно.

Заинтересовало?

Вакансии более не актуальны

Не лишним будет, если кроме резюме Вы напишите - почему Вам нравится серверная разработка на Python или PHP и почему Вам интересна данная вакансия. Плюс упомяните, пожалуйста, что Вы узнали о данной вакансии через Insight IT.

Архитектура Tumblr

Иван Блинков — Tue, 21 Feb 2012 16:29:00 +0400

Tumblr - одна из самых популярных в мире платформ для блоггинга, которая делает ставку на привлекательный внешний вид, юзабилити и дружелюбное сообщество. Хоть проект и не особо на слуху в России, цифры говорят сами за себя: 24й по посещаемости сайт в США с 15 миллиардами просмотров страниц в месяц. Хотите познакомиться с историей этого проекта, выросшего из простого стартапа?

Введение

Как и всем успешным стартапам, Tumblr удалось преодолеть опасную пропать между начинающим проектом и широко известной компанией. Поиск правильных людей, эволюция инфраструктуры, поддержка старых решений, паника по поводу значительного роста посещаемости от месяца к месяцу, при этом в команде только 4 технических специалиста - все это заставляло руководство Tumblr принимать тяжелые решения о том над чем стоит работать, а над чем - нет. Сейчас же технический персонал расширился до 20 человек и у них достаточно энергии для преодоления всех текущих проблем и разработки новых интересных технических решений.

Поначалу Tumblr был вполне типичным большим LAMP приложением. Сейчас же они двигаются в направлении модели распределенных сервисов, построенных вокруг существенно менее распространенных технологий. Основные усилия сейчас вкладываются в постепенный уход от PHP в пользу более "правильных" и "современных" решений, оформленных в виде сервисов. Параллельно с переходом к новым технологиям идут изменения и в команде проекта: от небольшой группы энтузиастов к полноценной команде разработчиков, имеющей четкую структуру и сферы ответственности, но тем не менее жаждущей реализовывать новый функционал и обустраивать совершенно новую инфраструктуру проекта.

Платформа

CentOS на серверах, Mac OS X для разработки
Apache - основной веб-сервер
PHP, Scala, Ruby - языки программирования
Finagle - асинхронный RPC сервер и клиент
MySQL, HBase - СУБД
memcached, Redis - кэширование
Varnish, nginx - отдача статики
HAProxy - балансировка нагрузки
kestrel, gearman - очередь задач
Thrift - сериализация
Kafka - распределенная шина сообщений
Hadoop - обработка статистики
ZooKeeper - хранение конфигурации и состояний системы
git - система контроля версий
Jenkins - непрерывное тестирование

Статистика

Около 500 миллионов просмотров страниц в день
Более 15 миллиардов просмотров страниц в месяц
Посещаемость растет примерно на 30% в месяц
Пиковые нагрузки порядка 40 тысяч запросов в секунду
Около 20 технических специалистов в команде
Каждый день создается около 50Гб новых постов и 2.7Тб обновлений списков последователей
Более 1Тб статистики обрабатывается в Hadoop ежедневно
Используется порядка 1000 серверов:
- 500 веб-серверов c Apache и PHP-приложением
- 200 серверов баз данных (существенная их часть - резервные)
  - 47 пулов
  - 30 партиций (шардов)
- 30 серверов memcached
- 25 серверов Redis
- 15 серверов Varnish
- 25 серверов HAProxy
- 8 серверов nginx
- 14 серверов для очередей задач

Типичное использование

Tumblr используется несколько по-другому, чем другие социальные сети:
- При более чем 50 миллионах постов в день, каждый из них попадает в среднем к нескольким сотням читателей. Это и не несколько пользователей с миллионами читателей (например, популярные личности в Twitter) и не миллиарды личных сообщений.
- Ориентированность на длинные публичные сообщения, полные интересной информацией и картинками/видео, заставляет пользователей проводить долгие часы каждый день за чтением Tumblr.
- Большинство активных пользователей подписывается на сотни других блоггеров, что практически гарантирует много страниц нового контента при каждом заходе на сайт. В других социальных сетях поток новых сообщений переполнен ненужным контентом и толком не читается.
- Как следствие, при сложившемся количестве пользователей, средней аудиторией каждого и высокой активностью написания постов, системе приходится обрабатывать и доставлять огромное количество информации.
Публичные блоги называют Tumblelog'ами, они не так динамичны и легко кэшируются.
Сложнее всего масштабировать Dashboard, страницу, где пользователи в реальном времени читают что нового у блоггеров, на которых они подписаны:
- Кэширование практически бесполезно, так как для активных пользователей запросы редко повторяются.
- Информация должна отображаться в реальном времени, быть целостной и не "задерживаться".
- Около 70% просмотров страниц приходится именно на Dashboard, почти все пользователи им пользуются.

Старая архитектура

Когда проект только начинался, Tumblr размещался в Rackspace и последние выдавали каждому блогу с собственным доменом A-запись. Когда они переросли Rackspace, они не смогли полноценно мигрировать в новый датацентр, в том числе из-за количества пользователей. Это было в 2007 году, но у них по-прежнему часть доменов ведут на Rackspace и перенаправляются в новый датацентр с помощью HAProxy и Varnish. Подобных "унаследованных" проблем у проекта очень много.
С технической точки зрения проект прошел по пути типичной эволюции LAMP:
- Исторически разработан на PHP, все началось с веб-сервера, сервера баз данных и начало потихоньку развиваться.
- Чтобы справляться с нагрузкой они начали использовать memcache, затем добавили кэширование целых страниц и статических файлов, потом поставили HAProxy перед кэшами, после чего сделали партиционирование на уровне MySQL, что сильно облегчило им жизнь.
- Они делали все, чтобы выжать максимум из каждого сервера.
- Было разработано два сервиса на C: генератор уникальных идентификаторов на основе HTTP и libevent, а также Staircar, использующий Redis для обеспечения уведомлений в реальном времени на Dashboard.
Dashboard использует подход "разбрасывать-собирать", так как из-за отсортировонности данных по времени традиционные схемы партиционирования работали не очень хорошо. По их прогнозам текущая реализация позволит им рости еще в течении полугода.

Новая архитектура

Приоритетным направлением стали технологии, основанные на JVM, по причине более быстрой разработки и доступности квалифицированных кадров. Мотивация несколько спорная, особенно если учесть, что речь идет в первую очередь о Scala, а не о Java.
Основная цель - вынести все из PHP приложения в отдельные сервисы, что сделает его лишь тонким клиентом к внутреннему API.
Почему выбор пал именно на Scala и Finagle?
- Многие разработчики имели опыт с Ruby и PHP, так что Scala был привлекательным (цитата, логики мало)
- Finagle был одним из основных факторов в пользу JVM: это библиотека, разработанная в Twitter, которая решает большинство распределенных задач вроде маршрутизации запросов и обнаружение/регистрацию сервисов - не пришлось реализовывать это все с нуля.
- В Scala не принято использовать общие состояния, что избавляет разработчиков от забот с потоками выполнения и блокировками.
- Им очень нравится Thrift в роли программного интерфейса из-за его высокой производительности (он кроссплатформенный и к JVM никак не относится)
- Нравится Netty, но не хочется связываться с Java, еще один аргумент в пользу Scala.
- Рассматривали Node.js, но отказались так как под JVM проще найти разработчиков, а также из-за отсутствия стандартов, "лучших практик" и большого количества качественно протестированного кода.
Старые внутренние сервисы также переписываются с C + libevent на Scala + Fingle.
Был создан общий каркас для построения внутренних сервисов:
- Много усилий было приложено для автоматизации управления распределенной системой.
- Создан аналог скаффолдинга - используется некий шаблон для создания каждого нового сервиса.
- Все сервисы выглядят одинаково с точки зрения системного администратора: получение статистики, мониторинг, запуск и остановка реализованы одинаково для всех сервисов.
- Созданы простые инструменты для сборки сервисов без вникания в детали используемых стандартных решений.
Используется 6 внутренних сервисов, над которыми работает отдельная команд. На запуск сервиса с нуля уходит около 2-3 недель.
Новые, нереляционные СУБД, такие как HBase и Redis, вводятся в эксплуатацию, но основным хранилищем по-прежнему остается сильно партиционированный MySQL.
HBase используется для сервиса сокращенных ссылок для постов, а также всех исторических данных и аналитики. HBase хорошо справляется с ситуациями, где необходимы миллионы операций записи в секунду, но он не достаточно стабилен, чтобы полностью заменить проверенное временем решение на MySQL в критичных для бизнеса задачах.
Партиционированный MySQL плохо справляется с отсортированными по времени данными, так как один из серверов всегда оказывается существенно более "горячим", чем остальными. Также сталкивались с значительными задержками в репликации из-за большого количества параллельных операций добавления данных.
Используется 25 серверов Redis с 8-32 процессами на каждом, что означает порядка 300-400 экземпляров Redis в сумме.
- Используется для уведомлений в реальном времени на Dashboard (о событиях вроде "кому-то понравился Ваш пост").
- Высокое соотношений операций записи к операциям чтения сделало MySQL не очень подходящим кандидатом.
- Уведомления не так критичны, их потеря допустима, что позволило отключить персистентность Redis.
- Был создан интерфейс между Redis и отложенными задачами в Finagle.
- Сервис коротких ссылок также использует Redis как кэш, а HBase для постоянного хранения.
- Вторичный индекс Dashboard также построен вокруг Redis.
- Redis также используется для хранения задач Gearman, для чего был написан memcache proxy на основе Finale.
- Постепенно отказываются от memcached в пользу Redis в роли основного кэша. Производительность у них сопоставима.
Внутренним сервисам необходим доступ к потоку всех событий в системе (создание, редактирование и удаление постов, нравится или не нравится и т.п.), для чего была созданна внутренняя шина сообщений (англ. firehose, пожарный шланг):
- Пробовали использовать в этой роли Scribe, но так как оно по сути свелось к пропусканию логов через grep в реальном времени - нагрузки оно не выдержало.
- Текущая реализация основана на Kafka, решению аналогичной задачи от LinkedIn на Scala.
- MySQL также не рассматривался из-за большой доли операций записи.
- Внутри сервисы используют HTTP потоки для чтения данных, хотя Thrift интерфейс также используется.
- Поток сообщений хранит события за последнюю неделю с возможностью указать момент времени с которого считывать данные при открытии соединения.
- Поддерживается абстракция "группы потребителей", которая позволяет группе клиентов вместе обрабатывать один поток данных вместе и независимо, то есть одно и то же сообщение не попадет дважды к клиентам из одной группы.
- ZooKeeper используется для периодического сохранения текущей позиции каждого клиента в потоке.
Новая архитектура Dashboard основана на принципе ячеек или ящиков входящих сообщений:
- Каждая "ячейка" отвечает за группу пользователей и читает новые события с шины сообщений, если один из её пользователей-подопечных подписан на автора только что опубликованного поста, то пост добавляется в "почтовый ящик" подписанного пользователя.
- Когда пользователь заходит в Dashboard его запрос попадает в его ячейку, которая возвращает ему нужную часть непрочитанных постов.
- Каждая ячейка состоит из трех групп серверов:
  - HBase для постоянного хранения копий постов и почтовых ящиков;
  - Redis для кэширование свежих данных;
  - Сервис, читающий данные из шины и предоставляющий доступ к ящикам посредством Thrift.
- В HBase используется две таблицы:
  - Отсортированный список идентификаторов постов для каждого пользователя в ячейке, именно в том виде, как они будут отображены в итоге.
  - Копии всех постов по идентификаторам, что позволяет выдать все данные для отрисовки Dashboard без обращений к серверам вне одной ячейки.
- Ячейки представляют собой независимые единицы, что позволяет легко масштабировать систему при росте числа пользователей.
- Платой за относительно безболезненность масштабирования является чрезвычайная избыточность данных: при том что ежедневно создается лишь 50Гб постов, суммарный объем данных в ячейках растет на 2.7Тб в день.
- Альтернативой было бы использование общего кластера со всеми постами, но тогда он бы стал единственной точкой отказа и потребовалось бы делать дополнительные удаленные запросы. Помимо этого выигрыш по объему был бы не велик - списки идентификаторов занимают значительно больше места, чем сами посты.
- Пользователи, которые подписаны или на которых подписаны миллионы других пользователей, обрабатываются отдельно - страницы с их постами генерируются не заранее (как описывалось выше), а при поступлении запроса - это позволяет не тратить впустую много ресурсов (этот подход называется выборочная материализация).
- Количество пользователей в одной ячейке позволяет управлять балансом между уровнем надежности и стоимостью содержания этой подсистемы.
- Параллельное чтение их шины сообщений оказывает серьезную нагрузку на сеть, в дальнейшем из ячеек можно будет составить иерархию: только часть будет читать напрямую из шины сообщений, а остальным сообщения будут ретранслироваться.
Tumblr географически по-прежнему находится в одном датацентре (если не считать незначительное присутствие в Rackspace), распределение по нескольким лишь в планах.

Развертывание

Начиналось как несколько rsync-скриптов для распространения PHP-приложения. Как только машин стало больше 200 такой подход стал занимать слишком много времени.
Следующий вариант был основан на Capistrano: были созданы три стадии процесса развертывания (разработка, тестирование, боевой). Неплохо справлялся с десятками серверов, но на сотнях также был слишком медленным, так как основывался на SSH.
Итоговый вариант основан на Func, решении от RedHat, позволившим заменить SSH на более легковесный протокол.

Разработка

Поначалу философия была такова, что каждый мог использовать любые технологии, которые считал уместным. Но довольно скоро пришлось стандартизировать стек технологий, чтобы было легче нанимать и вводить в работу новых сотрудников, а также для более оперативного решения технических проблем.
Каждый разработчик имеет одинаковую заранее настроенную рабочую станцию, которая обновляется посредством Puppet:
- Настроена публикация изменений, тестирование и развертывание новых версий.
- Разработчики используют vim и Textmate.
Новый PHP код систематически инспектируется другими разработчиками.
Внутренние сервисы подвергаются непрерывному тестированию посредством Jenkins.

Структура команд

Проект разбит на 6 команд:

Инфраструктура: все, что ниже 5 уровня по модели OSI - маршрутизация, TCP/IP, DNS, оборудование и.т.п.
Платформа: разработка основного приложения, партиционирование SQL, взаимодействие сервисов.
Надежность (SRE): сфокусирована на текущие потребности с точки зрения надежности и масштабируемости.
Сервисы: занимается более стратегической разработкой того, что понадобится через один-два месяца.
Эксплуатация: отвечает за обнаружение и реагирование на проблемы, плюс тонкая настройка.

Найм

На интервью они обычно избегают математики и головоломок, основной упор идет в основном именно на те вещи, которым придется заниматься кандидату.
Основной вопрос: будет ли он успешно решать поставленные задачи? Цель в том, чтобы найти отличных людей, а не в том, чтобы никого не брать.
Разработчиков обязательно просят привести пример своего кода, даже во время телефонных интервью.
Во время интервью кандидатов не ограничивают в наборе инструментов, можно даже гуглить.
Поиск людей с опытом в крупных проектах достаточно сложен, так как всего нескольких компаниях по всему миру решают подобные проблемы.

Подводим итоги

Автоматизация - ключ к успеху крупного проекта.
При партиционировании MySQL может масштабироваться, но лишь при преобладании операций чтения.
Redis с отключенной персистентностью легко может заменить memcached.
Scala достойно себя проявляет в роли языка программирования для внутренних сервисов, во многом благодаря обширной Java-экосистеме.
Внедряйте новые технологии постепенно, поначалу работать с HBase и Redis было очень болезненно, они были включены в основной стек технологий только после испытаний в некритичных сервисах и подпроектах, где цена ошибки не так велика.
Проект должен строиться вокруг навыков его команды, а не наоборот.
Нужно нанимать людей только если они вписываются в команду и в состоянии довести работу до результата.
При выборе технологического стека одну из ключевых ролей играет доступность соответствующих специалистов на кадровом рынке.
Читайте публикации и статьи в блогах. Ключевые аспекты архитектуры, включая "ячейки" и частичную материализацию были позаимствованы из внешних источников.
Поспрашивайте своих коллег, кто-то из них мог общаться с специалистами из Facebook, Twitter, Google или LinkedIn - если нет прямого доступа, всегда можно получить нужную информацию через одно-два "рукопожатия".

Статья написана на основе интервью Blake Matheny, директора по разработке платформы Tumblr.

Архитектура DISQUS

Иван Блинков — Wed, 02 Mar 2011 03:37:00 +0300

DISQUS - самая популярная система комментирования и одновременно самое большое в мире Django-приложение. Она установлена более чем на полумиллионе сайтов и блогов, в том числе и очень крупных, таких как Engadget, CNN, MTV, IGN. Основной особенностью в её реализации является тот факт, что DISQUS не является тем сайтом, который хотят увидеть пользователи, он лишь предоставляет механизмы комментирования, авторизации и интеграции с социальными сетями. Пики нагрузки возникают одновременно c появлением какой-то шумихи в Интернете, что достаточно непредсказуемо. Как же им удается справляться с этой ситуацией?

Платформа

Linux - операционная система
Python - язык программирования
Django - основной framework
Apache 2.2 + mod_wsgi - веб-сервер
PostgreSQL - СУБД
memcached - кэширование
HAProxy - балансировка нагрузки
Slony - репликация данных
heartbeat - обеспечение доступности

Статистика

До 17 тысяч запросов в секунду
500 000 сайтов
15 миллионов зарегистрированных пользователей
75 миллионов комментариев
250 миллионов посетителей (на август 2010г.)

Основные трудности

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

Архитектура

Оборудование, в сумме около 100 серверов:
- 30% веб-серверов (Apache + mod_wsgi)
- 10% серверов баз данных (PostgreSQL)
- 25% кэш-серверов (memcached)
- 20% балансировка нагрузки и обеспечение доступности (HAProxy + heartbeat)
- 15% прочие сервера (Python скрипты)
Балансировка нагрузки:
- HAProxy:
  - Высокая производительность
  - Интеллектуальная проверка доступности
  - Неплохая статистика
Репликация:
- Используется Slony-I
- Основана на триггерах
- Master/Slave для обеспечения большего объема операций чтения
Высокая доступность:
- heartbeat
- Пассивная копия мастер баз данных на случай сбоя основной
Партиционирование:
- Реализовано на уровне кода
- Простая реализация, быстрые положительные результаты
- Два метода разделения данных:
  - Вертикальное:
    - Создание нескольких таблиц с меньшим количеством колонок вместо одной (она же нормализация)
    - Позволяет разделять базы данных
    - Данные объединяются в коде (медленнее, чем на уровне СУБД, но не намного)
    - Бартер производительности на масштабируемость
    - Более эффективное кэшировние
    - Механизм роутеров в Django позволяет достаточно легко реализовать данный функционал
  - Горизонтальное:
    - Некоторые сайты имеют очень большие массивы данных
    - Партнеры требуют повышенного уровня доступности
    - Помогает снижать загрузку по записи на мастер базе данных
    - В основном используется все же вертикальное партиционирование
Производительность базы данных:
- Особое внимание уделяется тому, чтобы индексы помещались в оперативную память
- Логирование медленных запросов (автоматизировано с помощью syslog-ng + pgFouine + cron)
- Использование пулов соединений (Django не умеет этого, используется pgbouncer, позволяет экономить на ресурсоемких операциях установления и прекращения соединений)
- Оптимизация QuerySet'ов:
  - Не используется чистый SQL
  - Встроенный кэш позволяет выделять части выборки
  - Но это не всегда нужно, они убрали этот кэш
- Атомарные операции:
  - Поддерживают консистентность данных
  - Использование update(), так как save() не является thread-safe
  - Отлично работают для таких вещей, как счетчики
- Транзакции:
  - TransactionMiddleware поначалу использовалось, но со временем стало обузой
  - В postgrrsql_psycopg2 есть опция autocommit:
    - Это означает что каждый запрос выполняется в отдельной транзакции
    - Обработка каждого пользовательского HTTP-запроса не начинает новую транзакцию
    - Но все же транзакции из нескольких операций записи в СУБД нужны (сохранение нескольких объектов одновременно и полный откат в случае ошибки)
    - В итоге все HTTP-запросы по-умолчанию начинаются в режиме autocommit, но в случае необходимости переключаются в транзакционный режим
Отложенные сигналы:
- Постановка в очередь низкоприоритетных задач (даже если они не длинные по времени)
- Асинхронные сигналы очень удобны для разработчика (но не так, как настоящие сигналы)
- Модели отправляются в очередь в сериализованном виде
Кэширование:
- Используется memcached
- Новый pylibmcна основе libmemcached в качестве клиента (проекты django-pylibmc и django-newcache)
- Настраиваемые алгоритмы поведения клиента
- Используется _auto_reject_hosts и _retry_timeout для предотвращения повторных подключений к вышедшим из строя кэш-серверам
- Алгоритм размещения ключей: консистентное хэширование на основе libketama
- Существует проблема, когда одно очень часто используемое значение в кэше инвалидируется:
  - Множество клиентов одновременно пытаются получить новое значение из СУБД одновременно
  - В большинстве случаев правильным решением было бы вернуть большинству устаревшие данные и позволить одному клиенту обновить кэш
  - django-newcache и MintCache умеют это делать
  - Заполнение кэша новым значением вместо удаления при инвалидации также помогает избежать этой проблемы
Мониторинг:
- Информация о производительности запросов к БД, внешних вызовов и рендеринге шаблонов записывается через собственный middleware
- Сбор и отображение с помощью Ganglia
Отключение функционала:
- Необходим способ быстро отключить новый функционал, если оказывается, что он работает не так, как планировалось
- Система должна срабатывать мгновенно, по всем серверам, без записи на диск
- Позволяет запускать новые возможности постепенно, лишь для части аудитории
- Позволяет постоянно использовать основную ветку кода
- Аналогичная система используется и в Facebook
Масштабирование команды разработчиков:
- Небольшая команда
- Месячная аудитория / количество разработчиков = 40 миллионов
- Это означает:
  - Автоматическое тестирование
  - И максимально простой процесс разработки
- Новый сотрудник может начать работать уже через несколько минут, нужно лишь:
  - Установить и настроить PostgreSQL
  - Скачать исходный код из git
  - С помощью pip и virtualenv установить зависимости
  - Изменить настройки в settings.py
  - Выполнить автоматическое создание структуры данных средствами Django
Непрерывное тестирование:
- Ежедневное развертывание с помощью Fabric
- Hudson обеспечивает регулярно осуществляет и тестирует сборки
- Интегрирован Selenium
- Быстрое тестирование с помощью Pyflakes и post-commit hooks
- 70 тысяч строк Python кода, 73% покрытие тестами, прогон всех тестов занимает 20 минут
- Собственная система исполнения тестов с поддержкой XML, Selenium, подсчета количества запросов, тестирования Master/Slave базы данных и интеграцией с очередью
Отслеживание проблем и задач:
- Переключились с Trac на Redmine (из-за поддержки под-задач)
- Отправка исключений на e-mail - плохая идея
- Раньше использовали django-db-log, но теперь опубликовали свою систему сбора ошибок и логов под названием Sentry

Делаем выводы

Язык программирования, каким бы он ни был, не является проблемой
Django в целом очень хорош (но приходится все же использовать набор собственных патчей)
Даже при использовании низкопроизводительного framework можно построить масштабируемую систему
Вертикальное партиционирование позволяет пожертвовать производительностью в пользу масштабируемости
Даже небольшой командой разработчиков можно добиться высоких результатов, если не пренебрегать автоматизацией тестирования
Большое значение имеет возможность вовремя отслеживать и оперативно реагировать на сбои

Источник информации

Данная статья написана на основе выступления Jason Yan и David Cramer на DjangoConf 2010. В презентации можно найти примеры кода, ссылки на упоминаемые проекты и дополнительные материалы:

Другие статьи по масштабируемости высоконагруженных систем можно почитать в соответствующем разделе, а вовремя узнавать о новых - подписавшись на RSS. Вчера, кстати, прикрутил DISQUS к Insight IT, приглашаю постоянных читателей и всех остальных потестировать :)

Мероприятия всякие разные

Иван Блинков — Sat, 02 Oct 2010 17:44:00 +0400

Не знаю как во всем в мире, но в Москве пора айтишных и не очень конференций и мероприятий - это осень. Посещать их я еще не совсем обленился, а вот с написанием отчетов все как-то не складывалось. К сожалению, бюджет не позволил сходить на платные мероприятия, особенно Highload++. В общем в итоге я решил написать этот краткий обзорный пост по мероприятиям, на которые меня занесло этой осенью. Обо многом пишу спустя большое количество времени - возможны неточности и провалы в памяти.

Mail.ru Technology Forum

14 сентября

Честно говоря я подъехал на мероприятие лишь к обеду и не досидел до конца, так что могу лишь прокомментировать середину, то есть самый разгар.

В первую очередь я пошел в технологическую секцию, где Tom Preston-Werner, сооснователь и тех. директор проекта GitHub, рассказывал о том, как устроен их проект, какие технологии и костыли они используют. Если в двух словах, то у них используются три протокола: http, git и ssh, для каждого используется свой маршрут обработки запроса внутри системы. Основными продуктами, которые они используют являются Ruby on Rails, Unicorn, HAProxy, и собственно git и sshd. Вообще возможно стоило бы под эту историю написать отдельный пост - детали явно выходят за рамки данного повествования, а доклад и правда был интересным. Постараюсь вернуться к этой истории как только появится возможность.

Следующими в этом зале выступали представители самого mail.ru - честно говоря у меня хватило терпения слушать их очередное расхваливание Imagine Framework, который можно посмотреть только устроившись к ним на работу, только первые минут 15 наверное и я благополучно перекочевал во второй зал, где основной тематикой были социальные игры. Вообще за последний год мне довелось немного поработать в данной области и секция могла бы оказаться интересной, но качество докладов тоже было не на высоте - ничего нового ни про монетизацию, ни про привлечение аудитории услышать не удалось. В основном доклады представляли собой либо кейсы, основанные на конкретных не очень успешных приложениях, либо на каких-то общих рекомендациях и так лежащих на поверхности.

Кстати еще на одном из докладов представители мэйла заикались о некой NoSQL базе данных их разработки, которую они опубликовали под opensource лицензией - впоследствии попытался найти, но на http://opensource.mail.ru какая-то другая муть расположена, а гуглится что-то совсем не то. Если кто в курсе - поделитесь ссылкой, пожалуйста.

"MIT Way" by Richard Kivel

20 сентября

Ричард в целом продемонстрировал себя как успешного бизнесмена в сфере информационных и био технологий, но при этом практическая ценность его выступления была невелика. Он является презедентом MIT Enterprise Forum, а также председателем правления Rhapsody Biologics. Выступление проходило в здание ГУ-ВШЭ при поддержке HSE Inc.

Основными моментами его выступления были следующие тезисы:

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

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

В итоге правда оказалось, что основная цель данной лекции была вовсе не научить делать технологический бизнес, а привлечь дополнительных участников в сообщество MIT EF, представительство которого недавно открылось и в России. Мотивацией для присоединения к сообществу было как раз расширение сети бизнес-знакомств и контактов, особенно зарубежом. Членские взносы составляют довольно приличную сумму по меркам московских студентов (которых было большинство в зале) - что-то в районе 150\$/год.

Startup Weekend Brainstorm

25 сентября

Мероприятие являлось по сути подготовкой к самому Startup Weekend, о котором я напишу чуть ниже. Организатором обоих мероприятий является компания Главстарт, целью которой является расширение рынка технологических стартапов, для чего они проводят эти самые мероприятия, занимаются подбором экспертов и менторов, а также помогают проектам получить посевные инвестиции.

Как не трудно догадаться, подготовительная часть под названием Брейншторм направлена на генерацию идей для интернет-проектов. Участников мероприятия разбили на группы по интересам, около 20 человек на группу, где под руководством массовика-затейника и эксперта они придумывали различные идеи проектов, сервисов, целевых аудиторий и их потребностей и проблем. За почти целый день у каждой группы получилось около 10 более-менее продуманных идей, из которых гипотетически могли бы вырости проекты на следующем этапе - самом Startup Weekend.

Сами идеи проектов позвольте не озвучивать - многое не помню, да и большинство из не прошедшх отбор были на грани бреда.

Yet Another Conference

1 октября

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

Первый доклад, на который я пришел где-то к середине, вел инженер из Google и рассказывал про data races и инструмент для их поиска ThreadSanitizer - вроде все понятно и на самом деле слабо пересекается с областью моих интересов. Вторым докладом в этой секции шел Intel и уже через 15 секунд после начала стало понятно, что будет сплошная реклама их линейки проектов для разработки многопоточных приложений - сразу же встал и сбежал в соседнюю секцию.

В другом зале была самореклама уже продукта Яндекса, но уже несколько более завуалированная. Речь шла об их собственном веб-сервере Phantom, который они используют в баннерокрутилке. Основной его фишкой является приоритезация хэндлеров запросов в рамках одного сервера. Написан с нуля на плюсах, с использованием корутин и чуть ли не вообще без использования каких-либо библиотек. Основной плюс: в отличии от других докладчиков, рекламирующих свое детище, они хотябы обещали открыть исходные коды продукта как только допилят поддержку протокола FastCGI.

После перерыва я вернулся в первый зал, где началась длинная секция про системы хранения и обработки большого объема данных, я прослушал три доклада:

Apache Hadoop и прочие проекты вокруг него, выступал Константин Швачко из Yahoo. Жалко, что в этом проекте так мало всего изменилось за тот год, что я с ним не работал, даже решение проблемных ситуаций с NameNode толком не решили видимо. Слушал и думал "сколько же я уже раз это все слышал и сам рассказывал другим".
Собственная реализация Map Reduce от Яндекса, Александр Дмитриев. Визуально красиво сделанная презентация, судя по твиттеру очень многим понравилось, правда за этим всем терялась суть доклада - слушал честно говоря краем уха, так как судя по всему публиковать в opensource данный проект они пока не планируют. Специфичная реализация публично-известного подхода, реально приспособленная только под конкретные задачи Яндекса - впечатление осталось именно такое.
Евгений Поляков из Яндекса рассказывал о распределенной хэш-таблице Elliptics Network. Об Эллиптикс я ни разу ранее не слышал, а докладчик рассказывал очень вкусно о данном проекте. Основным плюсом данной системы хранения данных является модульность: особенно интересна возможность использовать различные технологии записи данных на диск, а также различные интерфейсы и протоколы, с помощью которых можно получать доступ к данным. Постараюсь на досуге подробнее изучить вопрос и если обнаружится что-то интересное - опубликовать свое более детальное впечатление о данном проекте.

Поводом сбежать с данной секции стал некий разработчик системы статистики для ЖЖ из SUP Fabrik - молодой человек еле ворочал языком, что делало практически невозможным понимание сути доклада. В другом зале как раз началась медийная секция, опять полная саморекламы. Докладчик из проекта videomost.com (видео-конференции) в целом сосредоточил свое внимание на том, что видео-конференции - это очень сложно, что популярные технологии, часто используемые в видео-трансляциях, там работают плохо - и вообще будущее за проприетарными специализированными протоколами, кодеками и системами. В повестке доклада значились способы обхода firewall'ов и NAT'а - но в докладе все ограничилось лишь большой красивой диаграммкой и фразой что-то в духе "в нашем проекте аж 14 способов решать эти проблемы", без каких-либо деталей.

Второй доклад медийной секции вел Richard Cole, продукт менеджер из Skype, показывал много красивых фотографий с людьми, пользующимися Skype в разных ситуациях. По делу у него был только одно сообщение: скоро для широкой публики будет доступен их SDK, который сейчас находится в стадии бета-тестирования.

Startup Weekend

1-3 октября

Это мероприятие еще не закончилось, я написал этот пост как раз во второй день - по идее в самый разгар. Как уже возможно стало понятно: основная суть мероприятия заключается в превращении идей интернет-проектов в готовые команды и прототипы. По идее здесь можно найти недостающих членов команды, получить советы экспертов, заключить менторское соглашение и найти посевного инвестора. Вчера были выступления представителей идей/проектов, сегодня - приехали "эксперты": сначала выступали в elevator pitch, потом общение с представителями проектов в формате speeddating, потом консультации по расписанию. Выглядит это все хаотично, организаторы пытаются каким-то образом способствовать созданию проектов, но все равно мотивации явно не хватает, чтобы по сути с незнакомыми людьми сделать хоть сколько-нибудь стоящий проект. Что из всего этого выйдет станет ясно завтра, возможно обновлю пост, если будет что сказать.

Заключение

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

В планах посещения мероприятий в этом году остался разве что Google Developer Day, подтверждение участия еще не пришло, но надеюсь все же попасть и не забыть написать отчет.

Если Вы дочитали до конца, но не подписаны на RSS - сейчас самое подходящее время, чтобы это сделать :)