У Go давно появился отличный логгер из коробки, а люди зачем-то продолжают использовать древние решения. И не просто древние решения, а обёртки над ними, преподнося это как киллер-фичу. Кажется было бы на много лучше написать реализацию подобного функционала представив её в виде `slog.Handler`тогда подключить ваше решение не составить никакого труда. А так, просто представьте, надо будет везде внедрять зависимость в виде `emitlog`, кто на такое пойдёт? А потом ещё выпиливать если вдруг что-то пойдёт не так. Ну уж нет.
Это резко снизило затраты и ускорило выпуск новых курсов.
Ну-ну, месяцев 5 прошло как я достиг максимального уровня в "Сове" в рамках изучения английского. С тех пор ни одного нового задания не вышло. Вместо этого "умные алгоритмы" каждый день подсовывают мне в качестве повторения одни и те же задания, даже простой рандом по имеющимся материалам не освоили)
Но вообще приложение хорошее, ничего лучше я пока не встречал, жду, надеюсь, верю, что моё обучение продолжится, пока мой интерес не пропал из-за такого вот "захватывающего" повторения
Не совсем понял, что конкретно вы предлагаете. В рамках одной транзакции мне надо вызвать 2 обновления у двух разных репозиториев, у каждого из них свой юзкейс. Единственный выход, который вижу я, это на уровне хэндлера создавать транзакцию и далее её прокидывать через юзкейс в репозиторий, но кажется этот вариант нарушает созданные нами же ограничения о том, что юзкейс не должен ничего знать о технических деталях, плюс на уровне хэндлера надо где-то хранить указатель на коннект к базе, а из репозитория убирать указатель на базу, так как теперь он будет приходить из вне. То есть мы опять придём к тому, что перемешаем мух с котлетами
А где в этой схеме живут транзакции? Существует масса ситуаций, при которых в рамках одного http запроса надо выполнить более, чем одну операцию на запись в базу и при этом сущности которые мы хотим менять разные, а значит репозитории разные, юзкейсы разные. В каком слое стартует транзакция, в каком завершается, где хранится указатель на базу, с которого стартует транзакция?
Тут возможны, как мне кажется, всего два варианта. Либо сообщения из канала вам важны и вы блокируетесь на записи, либо сообщения не важны и вы их выкидываете при заполненном буфере.
Варианты с временным "расширением" вместимости канала кажутся странными и как минимум это переусложнение на ровном месте, можно просто сделать канал больше, но это путь в никуда. Можно "выкидывать" данные в другой канал, заполнение которого будет явно свидетельствовать о проблеме и тут уже можно будет "бить в колокол".
Размер канала в 50 кажется странным решением. Зачем вам ещё одна очередь? Что станет с данными в канале, если сервис вдруг "упадёт"? Вероятно стоит поднять количество обработчиков, если очерёдность не важна, ну и канал с нулевым буфером тоже напрашивается сам собой. Ну и конечно же добавить метрику по тому, на какой промежуток времени блокируетесь при записи в канал, либо сколько выкидываете данных и после на данную метрику повесить алерты.
Вот благодаря таким библиотекам появляются "сеньёры", которые понятия не имеют о том, как распараллелить обработку массива штатными средствами, как обрабатывать паники, как запускать/останавливать горутины.
Что-то тут не сходится. Магазин должен содержать список товаров, что вроде как соответствует начальному заданию. Но добавляете в магазин вы почему-то машину, которая товаром не является, а лишь содержит его. Не машина должна содержать товар, а товарная единица должна в себе иметь машину, что в нынешних реалиях go легко реализуется с помощью дженериков
1-й этап. Разбираемся, как связываются слова в языке. Это самый сложный и ответственный этап, когда помощь преподавателя действительно необходима. В английском я изучал это самостоятельно
а можно подробнее о том, как вы это делали? ну или хотя бы ключевые слова для поиска. я +/- знаю грамматику английского, но подозреваю, что это не то
А что если спустя время нельзя будет работать IT-шником, если тебя нет в данном реестре? Говоря it-шник имеется ввиду работник it-компании, которая получает льготы, предусмотренные государством. Сейчас попадание туда бесплатно, далее кто знает. Понятное дело, что можно будет устроиться условным дворником и продолжать распиливать монолиты, но тогда не будет льгот.
Установил, работает, даже фотку запостил. Не особо пользовался оригиналом, этим тоже пользоваться не буду. Кажется главная фишка оригинала не в том, что там можно постить фотки.
Планируется ли интеграция со всякими там вконтактиками или одноклассниками?
Больше зарабатывает тот, кто смог себя более выгодно продать работодателю. Абсолютно не важно какой у тебя опыт или образование, в данном вопросе решает способоность продать себя
если N достаточно велико, то это вполне нормально, за это время изобрели новые материалы, новые инструменты, новые подходы, зачем продолжать поддерживать старое, когда можно стильно-модно-молодёжное
Не понятен выбор в пользу Gorilla Mux, оно ничего не даёт, кроме зависимости. Стандартный http.ServeMux умеет точно так же.
zerolog и zap давно в прошлом, стандартный log/slog ничем им не уступает
У Go давно появился отличный логгер из коробки, а люди зачем-то продолжают использовать древние решения. И не просто древние решения, а обёртки над ними, преподнося это как киллер-фичу. Кажется было бы на много лучше написать реализацию подобного функционала представив её в виде `slog.Handler`тогда подключить ваше решение не составить никакого труда. А так, просто представьте, надо будет везде внедрять зависимость в виде `emitlog`, кто на такое пойдёт? А потом ещё выпиливать если вдруг что-то пойдёт не так. Ну уж нет.
Ну-ну, месяцев 5 прошло как я достиг максимального уровня в "Сове" в рамках изучения английского. С тех пор ни одного нового задания не вышло. Вместо этого "умные алгоритмы" каждый день подсовывают мне в качестве повторения одни и те же задания, даже простой рандом по имеющимся материалам не освоили)
Но вообще приложение хорошее, ничего лучше я пока не встречал, жду, надеюсь, верю, что моё обучение продолжится, пока мой интерес не пропал из-за такого вот "захватывающего" повторения
Не совсем понял, что конкретно вы предлагаете. В рамках одной транзакции мне надо вызвать 2 обновления у двух разных репозиториев, у каждого из них свой юзкейс. Единственный выход, который вижу я, это на уровне хэндлера создавать транзакцию и далее её прокидывать через юзкейс в репозиторий, но кажется этот вариант нарушает созданные нами же ограничения о том, что юзкейс не должен ничего знать о технических деталях, плюс на уровне хэндлера надо где-то хранить указатель на коннект к базе, а из репозитория убирать указатель на базу, так как теперь он будет приходить из вне. То есть мы опять придём к тому, что перемешаем мух с котлетами
А где в этой схеме живут транзакции? Существует масса ситуаций, при которых в рамках одного http запроса надо выполнить более, чем одну операцию на запись в базу и при этом сущности которые мы хотим менять разные, а значит репозитории разные, юзкейсы разные. В каком слое стартует транзакция, в каком завершается, где хранится указатель на базу, с которого стартует транзакция?
Это не создание миллиона структур, это время подсчёта среднего значения в слайсе из миллиона значений
Тут возможны, как мне кажется, всего два варианта. Либо сообщения из канала вам важны и вы блокируетесь на записи, либо сообщения не важны и вы их выкидываете при заполненном буфере.
Варианты с временным "расширением" вместимости канала кажутся странными и как минимум это переусложнение на ровном месте, можно просто сделать канал больше, но это путь в никуда. Можно "выкидывать" данные в другой канал, заполнение которого будет явно свидетельствовать о проблеме и тут уже можно будет "бить в колокол".
Размер канала в 50 кажется странным решением. Зачем вам ещё одна очередь? Что станет с данными в канале, если сервис вдруг "упадёт"? Вероятно стоит поднять количество обработчиков, если очерёдность не важна, ну и канал с нулевым буфером тоже напрашивается сам собой. Ну и конечно же добавить метрику по тому, на какой промежуток времени блокируетесь при записи в канал, либо сколько выкидываете данных и после на данную метрику повесить алерты.
всё по факту. не смотря на тег "1 апреля", как минимум с половиной утверждений согласен) сам я пишу на go с версии 1.4
Вот благодаря таким библиотекам появляются "сеньёры", которые понятия не имеют о том, как распараллелить обработку массива штатными средствами, как обрабатывать паники, как запускать/останавливать горутины.
Что-то тут не сходится. Магазин должен содержать список товаров, что вроде как соответствует начальному заданию. Но добавляете в магазин вы почему-то машину, которая товаром не является, а лишь содержит его. Не машина должна содержать товар, а товарная единица должна в себе иметь машину, что в нынешних реалиях go легко реализуется с помощью дженериков
я бегло пробежался по всем вашим постам, ответа на свой вопрос не нашёл, получается данный ответ тоже не без риска
Звучит как преложение пойти погуглить, но ключевых слов я не знаю. Однако, спасибо
а можно подробнее о том, как вы это делали? ну или хотя бы ключевые слова для поиска. я +/- знаю грамматику английского, но подозреваю, что это не то
Цель такая же, как и у обязательной маркировки товаров - дополнительные поборы
А что если спустя время нельзя будет работать IT-шником, если тебя нет в данном реестре? Говоря it-шник имеется ввиду работник it-компании, которая получает льготы, предусмотренные государством. Сейчас попадание туда бесплатно, далее кто знает. Понятное дело, что можно будет устроиться условным дворником и продолжать распиливать монолиты, но тогда не будет льгот.
Двоякое ощущение от новости.
Для уменьшения размера(и не только) так же стоит указать флаг -trimpath при сборке бинарника
Установил, работает, даже фотку запостил. Не особо пользовался оригиналом, этим тоже пользоваться не буду. Кажется главная фишка оригинала не в том, что там можно постить фотки.
Планируется ли интеграция со всякими там вконтактиками или одноклассниками?
Больше зарабатывает тот, кто смог себя более выгодно продать работодателю. Абсолютно не важно какой у тебя опыт или образование, в данном вопросе решает способоность продать себя
"Привет" + "Вася" = "Привет Вася". То есть язык за меня решает, что я хочу вставить между словами пробел?
если N достаточно велико, то это вполне нормально, за это время изобрели новые материалы, новые инструменты, новые подходы, зачем продолжать поддерживать старое, когда можно стильно-модно-молодёжное