Видео доклада

Текстовая Версия

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


Индексы и тела писем составляют 15 % объёма, файлы — 85 %. Место для оптимизаций надо искать в файлах (аттачах в письмах). На тот момент у нас не была реализована дедупликация файлов; по нашим оценкам, она может дать экономию в 36 % всего объёма почты: многим пользователям приходят одинаковые письма (рассылки социальных сетей с картинками, магазинов с прайсами и т.д.). В этом посте я расскажу про реализацию такой системы, сделанной под руководством PSIAlt.

В среду, 2 декабря, мы приглашаем frontend-разработчиков в наш московский офис, чтобы поделиться опытом и обсудить нюансы работы. Разработчики проектов Почта и Главная страница расскажут, как в Mail.Ru Group оптимизируют код клиентской части приложений, с какими особенностями внедрения компонентного подхода они столкнулись и какие инструменты использовали. Гостей также ждет мастер-класс, на котором спикеры продемонстрируют способы ускорения процесса разработки, поддержки и интеграции.

В процессе улучшения Почты Mail.Ru мы постоянно выкатываем новый функционал. Сегодня я хочу поделиться с вами тонкостями того, как проходит обновление продукта с многомилионной аудиторией, на примере сложной и интересной задачи — редизайна Почты. Забегая вперед, перечислю этапы тестирования, которые проходит перед внедрением большая и сложная фича:

1. Малая группа (как правило, это сами разработчики)
2. UX-лаборатория
3. Коллеги по компании
4. Бета-пользователи
5. Пользователи, которые сами включили обновление
6. Сплит
7. Все пользователи Почты

Почта в новом дизайне — внутри мы ее назвали «Септима» — должна была успешно пройти все эти этапы.

Тестирование интерфейса в юзабилити-лаборатори

Я уверен, каждый из вас проходил этап от «мне фича нравится — значит, нравится всем» до «если конверсия по графикам растет, значит, фича нужная». Поэтому «как побороть в себе слепое» я рассказывать не буду. А поделиться хочу нижеописанным опытом.

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

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

Я хочу рассказать о простой задаче — вывод даты на главной странице Mail.Ru. Маленькая задача, нетривиальное решение.



Решение в лоб:

function print_date(date){
	return date.getDate() + ' ' + getMonth(date.getMonth()) …
}

print_date( new Date() );

Зачем?

Вопрос “Зачем?” — самый главный при принятии любого решения. В нашем случае причин было несколько.

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

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

Но в Mail.Ru Group есть целая команда высококвалифицированных людей, знающих JS, способных самостоятельно написать инструмент, а самое главное — они же им и будут пользоваться.

Во-вторых, задачи. Возьмем проект Почта@Mail.ru. Мы не можем отказаться от шаблонизации на сервере – нам нужна быстрая загрузка при первом входе. Мы не можем отказаться от шаблонизации на клиенте – люди должны видеть высокую скорость реакции на их действия, а значит, обязателен AJAX и шаблонизация на клиенте.

Проблема очевидна: два набора совершенно разных шаблонов на сервере и на клиенте. А самое обидное, что решают они одну и ту же задачу. Дублирование логики нас просто измотало.

v8 — это интерпретатор JavaScript, а значит, мы можем получить один шаблон, который работает как на сервере, так и на клиенте.

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

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

Доклад Андрея Сумина (_{хабрапрофиль}) «Как не утонуть в мегабайтах JS-кода?» — очередной в серии расшифровок с Форума Технологий Mail.Ru 2011. Подробности о том, как работает система расшифровки докладов — см. в статье «Изнанка» Форума технологий Mail.Ru: Хай-тек в event-management. Там же, а также на сайте Форума (http://techforum.mail.ru) — ссылки на расшифровки других докладов.

(Скачать видеоверсию для мобильных устройств — iOS/Android H.264 480?368, размер 170 Mb, видеобитрейт 500 кбит/с, аудио — 64 кбит/с )
(Скачать видеоверсию большего разрешения H.264 624?480, размер 610 Mb, видеобитрейт 1500 кбит/с, аудио — 128 кбит)
(Скачать слайды презентации, 4.7Мб)

Скажу сразу, в этом посте не будет даже упоминаний про последние, внедренные браузерами «фишки». Более того, первый раз эту тему я освещал в 2007 году. Я расскажу про некоторые приемы организации кода, которые вот уже 5 лет помогают мне и моим коллегам успешно разрабатывать проекты с большим количеством JS-кода.