Вовсе не обязательно самую дорогую GPU. У меня всё прекрасно работает на Macbook Pro M4 Max 36 Gb, модель 2023 года. Поставил LM Studio, качаю всякие Gemma, Qwen, Mistral, GLM, каждая хороша по своему. LLM специально адаптированны под Mac процессоры и их unified memory. Если просто початиться, то в LM Studio есть чатик, ну а для кодинга использую opencode. Решение достойное, но надо привыкать ставить правильно задачи, в Cursor с этим проще. Самый главный плюс LM Studio + opencode это то, что вся эта конструкция работает без интернета и для меня, как заядлого путешественника, это крайне важно. Из минусов то, что аккумулятор садится значительно быстрее
как же хорошо, что на lichess дела c читерами обстоят в разы лучше, там даже писать и жаловаться не надо, система сама анализирует все рейтинговые партии и блочит явных нарушителей, а тебе только отчётики присылает, что ваш рейтинг восстановлен, так как противник оказался читером
У Go давно появился отличный логгер из коробки, а люди зачем-то продолжают использовать древние решения. И не просто древние решения, а обёртки над ними, преподнося это как киллер-фичу. Кажется было бы на много лучше написать реализацию подобного функционала представив её в виде `slog.Handler`тогда подключить ваше решение не составить никакого труда. А так, просто представьте, надо будет везде внедрять зависимость в виде `emitlog`, кто на такое пойдёт? А потом ещё выпиливать если вдруг что-то пойдёт не так. Ну уж нет.
Это резко снизило затраты и ускорило выпуск новых курсов.
Ну-ну, месяцев 5 прошло как я достиг максимального уровня в "Сове" в рамках изучения английского. С тех пор ни одного нового задания не вышло. Вместо этого "умные алгоритмы" каждый день подсовывают мне в качестве повторения одни и те же задания, даже простой рандом по имеющимся материалам не освоили)
Но вообще приложение хорошее, ничего лучше я пока не встречал, жду, надеюсь, верю, что моё обучение продолжится, пока мой интерес не пропал из-за такого вот "захватывающего" повторения
Не совсем понял, что конкретно вы предлагаете. В рамках одной транзакции мне надо вызвать 2 обновления у двух разных репозиториев, у каждого из них свой юзкейс. Единственный выход, который вижу я, это на уровне хэндлера создавать транзакцию и далее её прокидывать через юзкейс в репозиторий, но кажется этот вариант нарушает созданные нами же ограничения о том, что юзкейс не должен ничего знать о технических деталях, плюс на уровне хэндлера надо где-то хранить указатель на коннект к базе, а из репозитория убирать указатель на базу, так как теперь он будет приходить из вне. То есть мы опять придём к тому, что перемешаем мух с котлетами
А где в этой схеме живут транзакции? Существует масса ситуаций, при которых в рамках одного http запроса надо выполнить более, чем одну операцию на запись в базу и при этом сущности которые мы хотим менять разные, а значит репозитории разные, юзкейсы разные. В каком слое стартует транзакция, в каком завершается, где хранится указатель на базу, с которого стартует транзакция?
Тут возможны, как мне кажется, всего два варианта. Либо сообщения из канала вам важны и вы блокируетесь на записи, либо сообщения не важны и вы их выкидываете при заполненном буфере.
Варианты с временным "расширением" вместимости канала кажутся странными и как минимум это переусложнение на ровном месте, можно просто сделать канал больше, но это путь в никуда. Можно "выкидывать" данные в другой канал, заполнение которого будет явно свидетельствовать о проблеме и тут уже можно будет "бить в колокол".
Размер канала в 50 кажется странным решением. Зачем вам ещё одна очередь? Что станет с данными в канале, если сервис вдруг "упадёт"? Вероятно стоит поднять количество обработчиков, если очерёдность не важна, ну и канал с нулевым буфером тоже напрашивается сам собой. Ну и конечно же добавить метрику по тому, на какой промежуток времени блокируетесь при записи в канал, либо сколько выкидываете данных и после на данную метрику повесить алерты.
Вот благодаря таким библиотекам появляются "сеньёры", которые понятия не имеют о том, как распараллелить обработку массива штатными средствами, как обрабатывать паники, как запускать/останавливать горутины.
Что-то тут не сходится. Магазин должен содержать список товаров, что вроде как соответствует начальному заданию. Но добавляете в магазин вы почему-то машину, которая товаром не является, а лишь содержит его. Не машина должна содержать товар, а товарная единица должна в себе иметь машину, что в нынешних реалиях go легко реализуется с помощью дженериков
1-й этап. Разбираемся, как связываются слова в языке. Это самый сложный и ответственный этап, когда помощь преподавателя действительно необходима. В английском я изучал это самостоятельно
а можно подробнее о том, как вы это делали? ну или хотя бы ключевые слова для поиска. я +/- знаю грамматику английского, но подозреваю, что это не то
А что если спустя время нельзя будет работать IT-шником, если тебя нет в данном реестре? Говоря it-шник имеется ввиду работник it-компании, которая получает льготы, предусмотренные государством. Сейчас попадание туда бесплатно, далее кто знает. Понятное дело, что можно будет устроиться условным дворником и продолжать распиливать монолиты, но тогда не будет льгот.
Вовсе не обязательно самую дорогую GPU. У меня всё прекрасно работает на Macbook Pro M4 Max 36 Gb, модель 2023 года. Поставил LM Studio, качаю всякие Gemma, Qwen, Mistral, GLM, каждая хороша по своему. LLM специально адаптированны под Mac процессоры и их unified memory. Если просто початиться, то в LM Studio есть чатик, ну а для кодинга использую opencode. Решение достойное, но надо привыкать ставить правильно задачи, в Cursor с этим проще. Самый главный плюс LM Studio + opencode это то, что вся эта конструкция работает без интернета и для меня, как заядлого путешественника, это крайне важно. Из минусов то, что аккумулятор садится значительно быстрее
как же хорошо, что на lichess дела c читерами обстоят в разы лучше, там даже писать и жаловаться не надо, система сама анализирует все рейтинговые партии и блочит явных нарушителей, а тебе только отчётики присылает, что ваш рейтинг восстановлен, так как противник оказался читером
Спецификация Go гарантирует, что поля структуры располагаются в памяти именно в том порядке, в котором они объявлены
А в сторону S2 от Google не смотрели? У них кажется отличное решение для Geo поиска
Не понятен выбор в пользу 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 при сборке бинарника