Pull to refresh

Comments 24

Похоже что буквально все, в разрез go way.


Реимплеминтировали руби на готрунтайме.

Людям надо было продукт запускать, главное что одумались.
По сути, самое важное содержится в конце статьи :)

Сегодня мы уже ушли от Beego и Gorm, подробнее об этом будет в следующей статье.
Сегодня мы уже ушли от Beego и Gorm

<Шумно выдохнул...>
Ну раз ушли, следующая статья обещает быть интересной. Ждём.
Он нагрузок бежать к ноде, смех и грех. Типизированные языки удобнее для серьезной разработки, все больше людей это понимает.
А логи чем парсите? Как обычно, с утра за кофе? Или авто поиск аномалий прикрутили?
Автопоиск аномалий было прикручивали, но потом открутили — предупреждения от него приходили уже когда метрики в NewRelic'е были красными. Если говорить про логи, то сейчас у нас ELK, агрегируем в одно хранилище из всех сервисов. Еще есть превентивный алертинг на базе бизнес- (сколько заказов на стадии поиска водителя, например) и технических метрик (память, диск, скачки сетевой активности, апдекс и тд).

Несколько печально, что изначально не попробовали на go писать, как на go.
Но я рад, что многократно отказывался от ваших hr.

Не. Опять проходить азы гошки, ждать, когда команды дойдут до того, что монстрячие фреймворки не нужны, или что не нужно рядом с типом сразу писать его интерфейс. Так можно потерять года 3-4 на рост команды, а интересных задач даже рядом не будет.

Ну, пришло бы 3-4-5 с опытом и не было бы фреймворков.

А что делать эти 3-4 года? Без роста-то?

Да не было бы их, я видел как несколько всего персоналий могут весь тренд переломить.

Ну ребята сами пишут, что у них ушла пара лет, чтобы из монстрячего фреймворка до gorm дойти. Сколько ещё уйдёт лет, чтобы от gorm до чего-то без 150 аллокаций памяти на update дойти? Ну и второй момент, заметьте, что в статье ребята не упоминают о разработке своих инструментов. А это на уровень ниже даже mail.ru, который неплохой easyjson сделал.

Помнится, будучи в командировке в Израиле, благодаря вашему сервису, я узнал о идемпотентности в биллинге на практике. 3 раза деньги списали, из за проблем со связью, в итоге они конечно вернулись, но где-то месяц были залочены.
Ага, стажёр Вася тогда ещё видимо не случился. Eventual consistency в биллинге это большое зло, которое крайне раздражает пользователей. И запоминается надолго.
Все, кажется, сильно проще. Недавно починили баг, из-за которого в некоторых случаях отмена авторизации не посылалась, и только сам банк ее отменял сильно позже. Это могло быть причиной.
MgDuke прости за неудобства.

Статья в целом приятная, удивил вот этот кусок:


Были смешные истории, когда человек реализовывал какую-то фичу, и только на код-ревью или вообще случайно узнавал, что, оказывается, нужно делать Go-сборку. А задача уже закрыта.

Это прямо из ряда вон, очень странное отношение к работе, может быть какая-то редкостная скриптовая закостенелость мышления...

А я вот из этого куска не понял, как задача могла быть закрыта, если еще не прошел code-review?
Использование Beego.me для такой серьезной компании связано, видимо, с привычной, оставшейся еще от Ruby
(для тех кто не программирует на Go серьезные системы — в мире Go полноценные фреймворки не получили большого распространения; удобнее оказалось делать на узкозаточенных микрофреймворках, что реализуют небольшую часть функционала)
Как все знакомо :)

Beego и не go way выбран был в пользу плавного перехода для программистов(надо еще и фичи писать параллельно) Когда люди писали на RoR MVC им проще понимать куда код кидать в beego.

Далее мы с именем NewrelicStop регистрируем функцию startSegment, которая просто вызывает Go-агент и открывает новый сегмент обращения к базе данных.


Тут наверно имелось ввиду NewrelicStart
Спасибо, поправил.
Sign up to leave a comment.