"Куда все идут"

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

Но для меня это сейчас — Сервис с большой буквы, потому что именно это тот самый "большой сервис на Джанго", который я до сего времени периодически упоминал, и который мы писали аж с мая прошлого года. И вот мы его выпустили в прошлый вторник, за остаток недели отловили несколько веселых багов, и теперь я хочу представить вам свое пострелизное мыслеизлияние :-).

Исторические факты

Просто так для завтравки хочется привести несколько фактов, которые никуда особенно больше не приткнешь.

• В процессе запуска было 12 бет, 7 release candidate'ов, 1 (естественно) релиз и 4 минорных пострелиза с фиксами (во, сколько жаргонизмов!).

• Внутреннее изначальное название сервиса — "Яндекс.Офлайн". Подразумевалось, что это сервис по организации встреч друзей в офлайне. Я продолжаю поминать его по этому имени, потому что во-первых привык, а во-вторых оно короче и проще склоняется (то есть склоняется в принципе).

• Публичное же название сервиса "утекало" до его запуска два раза: здесь у Коли, который сервис придумал и здесь у меня (жирно в середине). Но, конечно, никто, кроме участников процесса, ничего не понял :-).

• 8 месяцев разработки от идеи до запуска не кажутся такими длинными, если учесть, что по ходу:

  • один раз кардинально поменялась концепция сервиса
  • один раз кардинально поменялась концепция разработки
  • один раз сменился менеджер проекта
  • один раз сменился верстальщик

Изменчивая судьба

Немножко подробней хочу рассказать про последний пункт.

Автор общей идеи о разработке сервисов в Яндексе на Джанго — Григорий Бакунов (Bobuk). И хоть человек он харизматичный, и слушают его обычно внимательно, такая большая идея, как использование нового фреймворка, нуждается в серьезных основаниях. Особенно учитывая, что в Яндексе есть свой работающий и отлаженный способ делать веб-приложения. Поэтому концепция разработки сервисов на Джанго изначально называлась "прототипированием". Если я правильно понимаю, предполагалось быстро делать "на каком-то там Питоне" прототип, а после этого, если сервис всем нравится, его надо было переписать заново (!) по-нормальному :-).

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

Это было про смену концепции разработки. Смена концепции сервиса звучит прозаичней. Изначально Офлайн задумывался так, что будет жестко завязан на сервис Я.ру. А потом идея поменялась на то, что сервисом могут пользоваться и люди, у которых нет странички на Я.ру. Скажете, "всего-то"? Для нас это значило в середине разработке, когда основной объем кода уже был и работал, что у нас появляется целый новый класс пользователей — те, у кого нет дневника на Я.ру. А значит у них нет аватаров, имен и "друзей" (в Я.рушном понимании). И значит по всему коду мы должны были обработать все места, где преполагалось, что все это уже есть. И самое главное: нужно было приделать в наш интерфейс совершенно новую форму заведения страницы в Я.ру, которая серьезно поменяла интерфейс присоединения к событию, а также чувствительно усложнила этот процесс внутри. А, и еще мы получили под конец большой ворох дурацких проблем с подсчетом количества людей, потому что цифры перестали совпадать с количеством аватарок, которые мы отображаем. Я думаю, там до сих пор еще могут вылезать всякие несоответствия :-)

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

Смена же верстальщика означает, что пока view-source сайту делать рано: верстка сейчас представляет смесь двух разных подходов. Наш нынешний верстальщик — Женя Якушевский, с которым у меня есть уверенность, что мы в итоге доведем сайт до очень хорошего и, что немаловажно, модного технологического уровня.

Ну вот. С отмазками, вроде, покончил :-) Хотя нет, вот еще одна. Да, мы знаем, что на сайте сейчас нет места, где можно посмотреть, куда идет конкретный человек. В том числе и сам пользователь не может посмотреть свои события. То, что так случилось, говоря откровенно, обычный легкий бардачок в договоренностях между несколькими командами. В следующей версии прикрутим :-).

Программирование

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

Это мой первый проект, где бо́льшую часть кода я пишу не сам. Пока что я все еще учусь ускользающему навыку под названием "передача отвественности". Это когда, получая описание какой-то фичи, мне нужно думать не о том, как я буду писать код, а о том, что надо перевести описание задачи в термины нашей архитектуры и передать ее другому программисту. И еще очень сложно привыкнуть к тому, что другой человек пишет код совсем не так, как ты сам, и разделять при ревью кода то, что нужно сделать объективно по-другому, и то, что просто выглядит странно лично для ревьюера. Я вообще думаю, что наш программист Ваня Бибилов скоро будет меня тихо ненавидеть за мелочные докапывания к названиям переменных :-).

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

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

Во время разработки я все время настаивал на том, чтобы мы не занимались тонкой оптимизацией по производительности. И чем дальше, тем больше я думаю, что это правильный подход. Система сильно менялась, во многих тяжелых запросах необходимость просто отпала, а некоторые наоборот появились. Если бы мы каждый раз тратили время на оптимизацию, много бы потеряли. Занявшись же оптимизацией в самом конце, мы потратили на нее примерно неделю. Больше всего тормозов добавляла старая как мир проблема — слишком много запросов в базу из-за доставания дополнительных данных отдельными запросами на каждый объект. Лечилось обычно: кешированием в памяти, хранением в таблицах предрасчитанных количеств, использованием SQL-запросов с "group by".

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

• Кеширующий шаблонный тег для информеров, которым я как-то делился в форуме.

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

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

Интересный момент, который я вначале никак не предвосхищал — расположение статических файлов, как CSS'а с Javascript'ом, так и файлов от пользователей. Как я уже сказал, у нас четыре машины, на которых крутится Джанго. Запросы к ним распределяются равномерно неким балансером. Запрос от пользователя, который загружает по HTTP некий файл (картинку), приходит на одну из машин, и сохраняется в локальную файловую систему. Другой запрос, которому нужна будет эта картинка, может прийти на совсем другую машину, и файла этого на ней не окажется. Решений у этой задачи, на самом деле, много, и я даже использовал ее на собеседованиях, когда мы искали программистов. Мы пока решили ее так, что запустили на всех этих машинах распределенную файловую систему — GPFS — которая объединяет несколько директорий с разных машин в одно пространство. И сейчас каждая машина считает, что складывает и забирает файлы к себе, хотя реально может таскать их с какой-то из соседних. К слову сказать, для Джанги сейчас есть практически готовая система подключаемых файловых бэкендов, которая отучит ее складывать файлы всегда только на локальный диск, и тогда проблемы такого рода можно будет решать более гибко.

Главное — trunk

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

Вскоре (пока еще не планировали когда именно) у нас будет очередной релиз версии уже 1.1, в основном построенный на комментариях после запуска. Хотя будет и кое-что новое интересное. А за ней будут еще и еще. И через какое-то время, я надеюсь, сервис действительно станет полезным :-).