Привет Кость! Классный пост, давно ждал когда вы про это напишите. Есть пара вопросов:
1) Есть ли у вас какой-то бюджет на загрузку страниц. Ну например вы такие собрались подумали и решили что главная страница почты должна открываться за 2 секунды по 75-ой перцентили. И если есть то как и исходя из чего вы его определяете?
2) Мериете ли вы отдельно кешированный/некешированный флоу ( ну типа пользователь зашел первый раз/ и последующие )?
3) Что таки используется для подсчета перцентилей ( я думаю что вряд ли гугл аналитика )? есть ли оно в опенсорсе?
4) Мониторите ли вы что-то постоянно? или просто после релизов смотрите не просели ли где-то?
Спасибо за комментарий, вы правы — не все в компетенции разработчиков, но вы можете сейчас что-то предложить, а я обязательно передам это продуктовым менеджерам. Идет?
Да, спасибо, мы знаем про sentry — отличное решение, но у нас для сбора и агрегации клиентских ошибок уже достаточно давно написано свое, и оно по-сути очень похоже на то как работает sentry/raven.js. Тут же речь именно про препродакшн тестирование и про то, что нам важно не только как интерфейс выглядел, но и то что при этом не сыпались какие-нибудь ошибки, и если все же сыпались — то вот как мы их привязываем к результату прогона
Мы используем подход, похожий на тот что используется в raven.js от sentry. Если по-простому, то любая возникающая ошибка в итоге попадает в try {} catch() {} на уровнях выше, после чего со своим стектрейсом и разной дополнительной информацией отправляется на сервер.
На сервере ошибки агрегируются по разным признакам: номеру билда, браузеру, сообщению и т д. Так же можно посмотреть когда и как часто эта ошибка вопроизводилась до этого
У нас все достаточно гибко, любой разработчик может настроить для себя проксирование статики из:
1) мастера ( по дефолту )
2) из шота ( про шоты можно почитать вот в этой статье например habrahabr.ru/company/badoo/blog/317700 )
3) с девела другого разработчика
либо может запустить сборку статики локально, что тоже довольно нетрудно.
Обычно на начальном этапе и фронтенд и бэкенд разработчик могут сделать какую-то часть работы независимо друг от друга. Когда же необходимо тестировать совместную работу — бэкэнд разработчик может собрать шот для клиентской задачи и взять статику оттуда, либо может подмерджить клиентскую задачу и собирать статику локально.
Вы попали в точку, языков действительно много, и когда-то у нас была старая система сборки в которой действительно были такие проблемы. К счастью мы над этим поработали и теперь локализационные бандлы генерируются и хранятся отдельно. Это позволило решить проблемы со скоростью и количеством файлов, а так же сильно повысило скорость генерации. Все что касается переводов, в том числе и сервер, генерирующий бандлы — написано нашей командой backoffice — это свое решение, и оно нас более чем устраивает.
Для сжатия используем UglifyJS, для сборки большей части статики мы используем webpack. Всем кому нужно работать над js/css — запускают его локально, тем же кто работает только с серверной частью — по умолчанию отдается собранная актуальная статика из мастера — им ничего запускать не нужно.
Потому что для этой задачи достаточно регулярных выражений или инструмента из первого примера, а вот дальше описывается более мощное средство jscodeshift
И еще один: насколько я знаю некоторые из проектов в mail.ru ушли в сторону TypeScript и строгой типизации. Что ребята из облака об этом думают, планируете ли использовать ts,flow или что-то подобное?
Привет! А вот про UI команду ( которая верстка и JS ) вы маловато как-то рассказали ))) Интересно узнать, есть ли какие-то KPI на скорость загрузки интерфейса? если есть, то каким образом вы за ними следите: может быть какая-то система сбора/агрегации метрик своя есть?
1) Есть ли у вас какой-то бюджет на загрузку страниц. Ну например вы такие собрались подумали и решили что главная страница почты должна открываться за 2 секунды по 75-ой перцентили. И если есть то как и исходя из чего вы его определяете?
2) Мериете ли вы отдельно кешированный/некешированный флоу ( ну типа пользователь зашел первый раз/ и последующие )?
3) Что таки используется для подсчета перцентилей ( я думаю что вряд ли гугл аналитика )? есть ли оно в опенсорсе?
4) Мониторите ли вы что-то постоянно? или просто после релизов смотрите не просели ли где-то?
5) Есть ли аномали детекшн может какой
На сервере ошибки агрегируются по разным признакам: номеру билда, браузеру, сообщению и т д. Так же можно посмотреть когда и как часто эта ошибка вопроизводилась до этого
Насколько я помню там речь шла не про вывод в консоль, а про выражения вида:
foo(1)(2)(3) == 6
foo(1)(2)(3) + 4 == 10
foo(1)(2)(3) > 5
и т д
Теперь вы должны прислать нам вопрос на замену этому.
1) мастера ( по дефолту )
2) из шота ( про шоты можно почитать вот в этой статье например habrahabr.ru/company/badoo/blog/317700 )
3) с девела другого разработчика
либо может запустить сборку статики локально, что тоже довольно нетрудно.
Обычно на начальном этапе и фронтенд и бэкенд разработчик могут сделать какую-то часть работы независимо друг от друга. Когда же необходимо тестировать совместную работу — бэкэнд разработчик может собрать шот для клиентской задачи и взять статику оттуда, либо может подмерджить клиентскую задачу и собирать статику локально.
Вы попали в точку, языков действительно много, и когда-то у нас была старая система сборки в которой действительно были такие проблемы. К счастью мы над этим поработали и теперь локализационные бандлы генерируются и хранятся отдельно. Это позволило решить проблемы со скоростью и количеством файлов, а так же сильно повысило скорость генерации. Все что касается переводов, в том числе и сервер, генерирующий бандлы — написано нашей командой backoffice — это свое решение, и оно нас более чем устраивает.
Для сжатия используем UglifyJS, для сборки большей части статики мы используем webpack. Всем кому нужно работать над js/css — запускают его локально, тем же кто работает только с серверной частью — по умолчанию отдается собранная актуальная статика из мастера — им ничего запускать не нужно.