Классная статья, спасибо!
Вопрос насчет вашей системы логирования на основе эластика: сколько ГБ логов туда попало за день при максимальной нагрузке(если не секрет конечно)?
Alerting из X-Pack приятная штука, но цена подписки оказывается неподъемной для небольших компаний. Сами пользовались триалом- понравилось, но теперь придется искать бесплатную альтернативу оповещениям.
Статья — какой-то рекламный буллшит, местами с перевиранием и притягиванием за уши удобных примеров.
Лучше бы вместо отого описали реальные кейсы, в которых Go применять действительно удобно.
спрошу здесь в надежде, что увидят и ответят: почему hashCode возврщает именно int, а не long? это так исторически так сложилось или есть какая-то объективная причина?
«людям нельзя говорить, как делать работу,»
Абсолютно не соглаесен. Если ты читаешь чужой код и видишь, как в каком-либо моменте можно сделать лучше, чем есть, обязательно стоит это предложить. Если автор кода аргументированно с тобой не согласен, он объяснит, почему он сделал именно так. В том числе и в этом есть смысле ревью.
Хорошая статья. Согласен практически со всем написанным.
Еще важный момент — пресекать холивары, которые могут зарождаться вокруг какой-нибудь фигни. Как правило для этого достаточно немного доброй воли. Для других случаев у нас в команде действует следующее правило, если ревьювер и автор кода прицнипиальное не согласны в каком-либо моменте(условно спорят больше 5 минут), зовем 3го и делаем так как он говорит.
Спасибо за статью. Тоже сейчас присматриваемся к ELK. Скажите, есть ли у вас в системе ситуации, когда один объект(запрос) проходит
обработку в нескольких сервисах?
Пример: пришел запрос от пользователя, он попадает сначала в сервис1, затем сервис1 в рамках обработки этого запроса обращается в сервис 2, сервис 2 лезет в сервис 3 и т.д.
Если да, то отслеживаете ли вы в логах историю его обработку в разных сервисах и как у вас это реализовано(можно ли вытащить все логи из всех сервисов по этому запросу и понять, допустим, какой сервис тормозил)?
Вопрос насчет вашей системы логирования на основе эластика: сколько ГБ логов туда попало за день при максимальной нагрузке(если не секрет конечно)?
Лучше бы вместо отого описали реальные кейсы, в которых Go применять действительно удобно.
Абсолютно не соглаесен. Если ты читаешь чужой код и видишь, как в каком-либо моменте можно сделать лучше, чем есть, обязательно стоит это предложить. Если автор кода аргументированно с тобой не согласен, он объяснит, почему он сделал именно так. В том числе и в этом есть смысле ревью.
Еще важный момент — пресекать холивары, которые могут зарождаться вокруг какой-нибудь фигни. Как правило для этого достаточно немного доброй воли. Для других случаев у нас в команде действует следующее правило, если ревьювер и автор кода прицнипиальное не согласны в каком-либо моменте(условно спорят больше 5 минут), зовем 3го и делаем так как он говорит.
обработку в нескольких сервисах?
Пример: пришел запрос от пользователя, он попадает сначала в сервис1, затем сервис1 в рамках обработки этого запроса обращается в сервис 2, сервис 2 лезет в сервис 3 и т.д.
Если да, то отслеживаете ли вы в логах историю его обработку в разных сервисах и как у вас это реализовано(можно ли вытащить все логи из всех сервисов по этому запросу и понять, допустим, какой сервис тормозил)?