Pull to refresh
68
0
Александр Гутников @alxgutnikov

frontend

Send message
Спасибо! Обязательно гляну
Привет Кость! Классный пост, давно ждал когда вы про это напишите. Есть пара вопросов:

1) Есть ли у вас какой-то бюджет на загрузку страниц. Ну например вы такие собрались подумали и решили что главная страница почты должна открываться за 2 секунды по 75-ой перцентили. И если есть то как и исходя из чего вы его определяете?

2) Мериете ли вы отдельно кешированный/некешированный флоу ( ну типа пользователь зашел первый раз/ и последующие )?

3) Что таки используется для подсчета перцентилей ( я думаю что вряд ли гугл аналитика )? есть ли оно в опенсорсе?

4) Мониторите ли вы что-то постоянно? или просто после релизов смотрите не просели ли где-то?

5) Есть ли аномали детекшн может какой
Да, интересно конечно — присылайте в личку, как и обещал все передам. Спасибо!
Спасибо за комментарий, вы правы — не все в компетенции разработчиков, но вы можете сейчас что-то предложить, а я обязательно передам это продуктовым менеджерам. Идет?
Да, спасибо, мы знаем про sentry — отличное решение, но у нас для сбора и агрегации клиентских ошибок уже достаточно давно написано свое, и оно по-сути очень похоже на то как работает sentry/raven.js. Тут же речь именно про препродакшн тестирование и про то, что нам важно не только как интерфейс выглядел, но и то что при этом не сыпались какие-нибудь ошибки, и если все же сыпались — то вот как мы их привязываем к результату прогона
Спасибо, возьмем на заметку ))

Мы используем подход, похожий на тот что используется в raven.js от sentry. Если по-простому, то любая возникающая ошибка в итоге попадает в try {} catch() {} на уровнях выше, после чего со своим стектрейсом и разной дополнительной информацией отправляется на сервер.

На сервере ошибки агрегируются по разным признакам: номеру билда, браузеру, сообщению и т д. Так же можно посмотреть когда и как часто эта ошибка вопроизводилась до этого
console.log вроде же зависит от конкретной реализации console.spec.whatwg.org/#printer. В хроме например value выводится в том числе
Да, спасибо за замечание, все верно говорите.

Насколько я помню там речь шла не про вывод в консоль, а про выражения вида:

foo(1)(2)(3) == 6
foo(1)(2)(3) + 4 == 10
foo(1)(2)(3) > 5

и т д

Добрый вечер! Задачу можно решить как-то так:

function foo(value) {
	var acc = value;
	function addNext(next) {
		acc += next;
		return addNext;
	}
	addNext.valueOf = function() {
		return acc;
	}
	return addNext;
}


Теперь вы должны прислать нам вопрос на замену этому.
У нас все достаточно гибко, любой разработчик может настроить для себя проксирование статики из:
1) мастера ( по дефолту )
2) из шота ( про шоты можно почитать вот в этой статье например habrahabr.ru/company/badoo/blog/317700 )
3) с девела другого разработчика

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

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

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

Для сжатия используем UglifyJS, для сборки большей части статики мы используем webpack. Всем кому нужно работать над js/css — запускают его локально, тем же кто работает только с серверной частью — по умолчанию отдается собранная актуальная статика из мастера — им ничего запускать не нужно.
Потому что для этой задачи достаточно регулярных выражений или инструмента из первого примера, а вот дальше описывается более мощное средство jscodeshift
И еще один: насколько я знаю некоторые из проектов в mail.ru ушли в сторону TypeScript и строгой типизации. Что ребята из облака об этом думают, планируете ли использовать ts,flow или что-то подобное?
Привет! А вот про UI команду ( которая верстка и JS ) вы маловато как-то рассказали ))) Интересно узнать, есть ли какие-то KPI на скорость загрузки интерфейса? если есть, то каким образом вы за ними следите: может быть какая-то система сбора/агрегации метрик своя есть?
Вам спасибо! Рад что понравилось
Есть мнение что стартапы хоронят люди а не статьи
Рад что кому-то было полезно
Спасибо, за замечание — сейчас поправлю. опыта с brotli действительно не было.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity