😩 Университетская аттестация в самом разгаре. Но вместо усердной подготовки мы изучаем блокчейн. Как бы то ни было, будет что рассказать сослуживцам. А пока расскажу вам...

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

Автор Tal Kol в своей статье How a Blockchain Can Help You on a Deserted Island описал, как блокчейн поможет решить данный вопрос.

В конце статьи будет ссылка на продолжение о том, как группа выжевших всё-таки реализовала спасший их блокчейн.

Удивляет, как быстро нейронные сети ворвались в нашу повседневность. Теперь даже в Notion добавили поддержку ИИ. Он умеет продолжать текст, упрощать, сокращать, удлинять и делать выводы. Весьма удобно при написании конспектов.

🏗 Как неправильное применение патернов может принести больше вреда чем пользы?

Я думаю многие слышали о SOLID и его OCP. Часто люди, прочитав "чистую архитектуру" обмазываются интерфейсами под предлогом "так завещал дядя Боб". Пожалуйста, не нужно делать вещей, которые вам в данный момент не нужны. Вот статья Владимира Хорикова на эту тему: OCP vs YAGNI

DRY, думаю, впитывается у программистов с молоком матери. Многие любят им злоупотреблять и ссылаться на него даже там, где это абсолютно не нужно. Про это есть статья Miłosz Smółka из Three Dots Labs: Things to know about DRY (aka When to stay away from DRY)

🚽 Самое интересное из Technology Radar 29

Ниже представлены инструменты, языки и фреймворки, которые привлекли моё внимание в последнем радаре.

Я рассматриваю утилиты, которые можно смело использовать в своих проектах — Adopt, а так же те, к которым стоит присмотреться — Trial.

🔹 Adopt tool ruff — современный линтер и код форматтер, собравший в себе лучшее из популярных подобных решений. Уже активно используется такими проектами, как FastAPI и Pandas.

🔹 Adopt tool mermaid — утилита для генерирования разного рода схем из текста, весьма удобно для проектирования.

🔹 Trial tool Jetbrains HTTP client plugin — плагин для IDE для отправки http запросов, аля user friendly curl. Думаю может быть полезен для каких-нибудь тестов.

🔹 Trial tool mockserver — инструмент для создания мок http сервера. Можно красиво внепроцессорные неконтролируемые зависимости. Мне кажется довольно удобное стредство для разработчиков различных клиентских библиотек.

🔹 Adopt framework playwright — фреймворк для создания e2e тестов. Очень удобный и гибкий инструмент. Тесты можно писать на python, js, java. Go, к сожалению, нет, но думаю это не критично.

🔹 Trial framework mockery — GoLang инструмент для создания моков. Он выглядит очень симпатично, однако не очень явно и немного "волшебно", складывается ощущение, что писал шарпист. Moq мне нравится больше.

🔹 Trial programming language Dart — мне кажется о дарте знают все и говорить здесь нечего. Очень соблазнительный язык программирования для разработки кросс-платформенных приложений. Думаю, если бы я устал от бекенда, я бы полез в него.

🔹 Trial framework armeria — фреймворк для разработки микросервисов на Kotlin (Java). Мне показался интересным проект. Я не вникал, но выглядит, как Nginx с Django...

Недавно мне довелось выполнять простое тестовое задание. Его суть заключалась в том, чтобы реализовать простой CRUD для пользователей и Basic Auth через gRPC. Несмотря на всю простоту и примитивность проекта, я бы хотел поделиться им с вами. Комментарии открыты, я рад любой обратной связи. Предлагаю обсудить то, что у меня получилось: что вы бы делали иначе и почему?
https://github.com/F0rzend/grpc_user_auth

Очень интересный хак Web 3.0 фронтенда происходит прямо сейчас на наших глазах 👀

Под удар попал пакет леджера – ConnectKit, который используется для подключения Ledger Live к приложениям.

Пакет внутри себя загружает в глобальную область видимости js скрипт, расположенный на cdn.jsdelivr.net с дрейнером. Прикладываю кусок кода, где расположен импорт в самой библиотеке

Следовательно, если вы используете какую-то библиотеку для обработки подключения к Ledger Live – ваш фронтенд не безопасен и пользователи подвержены дрейну после авторизации (afaik заменено модальное окно подключения кошелька, так что владельцы любого кошелька в опасности, не только использующие Ledger Live)

🧱 Что там с ошибками в Go?

Ошибки в го настолько хороши, насколько ужасны. Отсутствие какого-то синтаксического сахара вынуждает разработчика писать кучу шаблонного кода. Это бесит абсолютно всех.

Проблема не нова и, естественно, известна разработчикам языка.
С нетерпением ждём, что же придумают и сделают во второй версии языка.
Пойдём и посмотрим в issue языка, что там пишут по поводу обработки ошибок. У нас, всё-таки, опен сорс.

Начнём с 40432: резюме по основным решениям.
Check/handle подход, на который я ссылался в одном из постов, был отменён из-за возможной путаницы между handle и defer. На его основе была выдвинута новая идея, которая, на данный момент, имеет больше всего шансов на появление в ожидаемой версии.

Идея в том, чтобы добавить для переменных catch-id (синтаксически, это обычное имя переменной, чем-то выделяющееся, например, символом # в начале имени). После одного или нескольких таких определений, следует блок catch по этому самому id, который обрабатывает ошибку (это может быть любой тип, не обязательно реализующий интерфейс ошибки) если она не пустая. Один блок catch может обработать несколько прежде полученных в один идентификатор ошибок.

Выглядеть это может следующим образом

func (db *Db) GetX(data []byte) (int, error) {
   n, #return := db.name()                       // специальное зарезервированное имя для ошибки, которая вернётся из функции
   
   f, #err := os.Open(n)                         // если файл не найден, возникнет ошибка, которая будет обработана ниже в блоке catch
   defer f.Close()
   _, #err  = f.Seek(42, io.SeekStart)
   l, #err := f.Read(data)
   
   #return = db.process(data)
   
   catch err error {                             // обработка всех #err ошибок
      if !os.IsNotExist(err) { log.Fatal(err) }
      log.Println(n, "not found; proceding")
   }

   #return = db.index(data)                      // если catch не завершил выполнение программы, продолжаем работу
   return l, nil
}

Подход мне кажется не очень привычным и немного запутанным. Хотя так всегда относишься к чему-то новому. Думаю, это всяк лучше того, что мы имеем сейчас. Преимуществом подхода отмечают сходтво с блоком try-catch без блока try.

Есть много нерешенных вопросов касательно этого подхода, подробнее о котором вы можете почитать здесь.

🔄 Range Over Functions: Quick Start

Уже стал доступен первый Release Candidate Go 1.23, который вносит в язык синтаксический сахар в виде итераторов, наконец не в experiment.

Этот пост — быстрый тур в грядущее обновление

Цель: стандартизация

Сама фича позволяет нам теперь в качестве аргумента оператора range использовать функцию, имеющую следующие сигнатуры

func(yield func() bool)
func(yield func(K) bool)
func(yield func(K, V) bool)

(название аргумента, конечно же, может быть любым)

При создании конструктора, чтобы не прописывать трудно читаемый тип возвращаемой функции, можно использовать iter.Seq[T] и iter.Seq2[T]

Легче всего понять что и как на примере.
Вот пример функции

package slices

import "iter"

func Backward[E any](s []E) iter.Seq2[int, E] {
    return func(yield func(int, E) bool) {
        for i := len(s)-1; i >= 0; i-- {
            if !yield(i, s[i]) {
                return
            }
        }
    }
}

Вот пример использования

s := []string{"hello", "world"}
for i, x := range slices.Backward(s) {
    fmt.Println(i, x)
}

Тем временем компилятор заменит код следующим образом:

slices.Backward(s)(func(i int, x string) bool {
    fmt.Println(i, x)
    return true
})

Становится понятно, что никакой магии здесь нет. Тело цикла попадает в виде функции-аргумента (yield) в функцию-итератор. Если внутри цикла встречается break — yield возвращает false и итерацию нужно прекратить. В противном случае будет паника.

Собственно, этой информации вам будет достаточно, чтобы писать свои итераторы. Вот набор ссылок по теме:
* 1.23rc1 Release Notes
* Issue с "мотивацией"
* Go Wiki: RangeOverFunctions Experiment
* Proposal of iter library (С чего всё началось)
* go iter package

📖 Про slog

Ещё недавно в Go не было встроенного структурированного логгера (логгера по уровням, со всякими key=value полями, который может писать json в разные системы сбора). Поэтому в большинстве проектов использовались сторонние логгеры (хотя, есть и люди, которые пишут log.Printf("[DEBUG] something happend") и радуются жизни, но я не из таких). Я же, в свою очередь предпочел zerolog.

zerolog предлагает возможность (хотя и не заставляет) прокидывать логгер через контекст. Таким образом вы можете внутри middleware добавлять в логер какие-то поля, такие как request_id, и использовать "расширенный" логгер в хендлере.
Хотя и "фу, context.WithValue", я привык к такому решению и мне оно казалось стандартным допущением.

Однако в стандартной библиотеке появился log/slog. К моему удивлению, функционала для вставки и извлечения логгера из/в контекст не оказалось. Меня это удивило и я, не долго думая, сам реализовал этот функционал. Но потом задумался: "разработчики go ведь не идиоты (хотя я лично знаю много людей, готовых спорить с этим утверждением), как они предлагают использовать логгер?".

slog умеет держать логгер в глобальном atomic.Pointer. И я начал анализировать, а нормально ли использовать глобальный логгер для приложения? С одной стороны весьма удобно, импортировал и юзаешь. Но это немного усложняет тестирование, выходит не очень явно и в целом как-то так себе, глобалы всё-таки...

Но главной причиной отказа от этого решения для меня являлось не понимание того, как же мне заткнуть request_id в логгер и прокинуть в handler логгер вместе с ним. Ведь не буду я в каждом логе руками request_id прописывать.

Хочу подчеркнуть, проблемой было непонимание. Здесь я углубился: на что способен slog? И был приятно удивлён. После стандартного логгера в python примитивность slog меня огорчила. Ведь всё, что у нас есть, текстовый и json логгер (handler) и пара методов для записи логов. Но в моменте мне открылась сила декораторов. Дело в том, что декорируя Handler, который использует логгер, вы можете сделать всё. Буквально всё. От цветного вывода в консоль и записи в несколько источников (хоть в telegram сообщения шли), до тех же самых request_id.

Осознав это, я будто познал тайны мироздания...
Вот, как я решил проблему request_id:

type RequestIDLogger struct {
  slog.Handler
}

func (l *RequestIDLogger) Handle(ctx context.Context, r slog.Record) error {
  request := getRequestID(ctx)

  r.AddAttrs(slog.String("request_id", request))

  err := l.Handler.Handle(ctx, r)
  if err != nil {
    return fmt.Errorf("failed to run parent of RequestIDLogger handler: %w", err)
  }

  return nil
}

Но использовать глобальный логгер я всё равно не захотел, поэтому распихал их по структурам, как обычно в Go делается dependency injection.
Кажется, это наилучший компромисс между всеми подходами.

Теперь middleware генерирует для каждого запроса request_id и добавляет его в контекст, а handler в slog.Logger извлекает его и добавляет при записи логов.

Кстати, slog уже оброс кучей всяких handler. Много интересного можно найти в awesome slog (думаю, тут есть всё, что вам может пригодиться).

#go #golang #logging #slog