Нас уже больше 15 000 🥳🎊🎂! Спасибо за интерес к «Библиотеке Go-разработчика».

🧰 Вышла новая версия генератора случайных фейковых данных GoFakeIt 6.25.0, написанного на Go

👀 Под капотом 260 функций для генерации таких имен, электронных писем, местоположений, цветов, user-агентов, продуктов для завтрака и многого другого.

☑️ В версии 6.25.0 появилась опция шаблонов, позволяющая генерировать более сложные кастомные данные.

👉 GitHub

🧰 Как устроены мапы под капотом: гайд для Go-разработчика

Павел Комаров из AvitoTech в подробностях рассмотрел процесс записи и чтения данных в мапы, важность передачи количества элементов при создании мапы, а также уделил внимание проблеме переполнения и эвакуации элементов, даже до уровня отдельных битов.

👉 Читать

💡Перепроверьте ваши embedding структуры

◆ Embedding (встраивание) структур позволяет одной структуре наследовать поля и методы другой, делая их частью себя. Это может использоваться для создания новых типов данных, которые включают в себя свойства и функциональность существующих структур.

📌 Предположим, у вас есть структура:

type Person struct {
    Name    string
    Address string
    SSN     string
}

и вы хотите создать тип customer.

type Customer struct {
    Person
    ID int
}

◆ Person является embedded структурой. Все ее поля и методы встраиваются во внешнюю структуру.

◆ Приложению, которому нужен тип Customer, не интересен номер социального страхования клиента и не должен быть, но SSN неизбежно встраивается в Customer вместе с полями Name и Address.

◆ Любой код, имеющий доступ к переменной Customer, таким образом, имеет доступ и к SSN клиента.

func main() {
    p := Person{
        Name:    "John Doe",
        Address: "Doe Blvd, Doe City"
        SSN:     "123-45-6789",
    }
    c := Customer{
        Person: p,
    }
    fmt.Println(c.SSN)
}

◆ Будьте осторожны с встраиванием структур. Это очень полезная техника, но вы можете случайно открыть доступ к полям или функциям, к которым клиентский код не должен иметь доступа.

#tip

🤌DDD в Go: превозмогая трудности

DDD — сложный набор правил, который требует насмотренности. Автор рассмотрел подход, который заставит думать в рамках терминов предметной области и событий, которые там происходят. Он легко ложится на приложения с CQRS и Event Sourcing.

💬 В комментариях пишут, мол, автор тащит подходы из Java в Go. А вы как думаете?

🗺 Извлечение данных из OpenStreetMap на Go: пример использования пакета osmpbf

OpenStreetMap — некоммерческий веб-картографический проект, который может использовать каждый для извлечения и анализа данных. Например, можно узнать, сколько ресторанов суши существует в Манхэттене.

👉 Читайте на Medium или в PDF

🌟 Представлены релизы Go 1.21.5 и 1.20.12

🔐 Новый выпуск включает исправления безопасности для net/http (CVE-2023-39326), cmd/go (CVE-2023-45285) и path/filepath (CVE-2023-45283 update).

👉 Анонс

#новости

🤔 Context vs структура: следует ли передавать информацию, специфичную для запроса, через context.Context?

HTTP-обработчики могут использовать контекст для управления тайм-аутами запросов или отменой в рамках запроса. Тип Context также позволяет передавать значения (например, идентификатор пользователя, связанный с запросом) другим функциям.

❓Следует ли использовать этот механизм для передачи информации по цепочке вызовов запроса? Или лучше использовать обычную структуру?

Вот две причины, по которым использование Context для передачи значений может быть плохой идеей:

Значения в Context представляют собой пары ключ/значение, где ключ и значение являются пустыми интерфейсами (т. е. any). Другими словами, значения в контексте — это как мешок со всем подряд. Компилятор не может помочь вам отловить ошибки типов или даже проверить, есть ли информация. Удачи в устранении неполадок 😉

Если вы видите функцию, принимающую параметр Context, вы не можете сказать, что внутри. Если вы видите функцию, которая принимает параметр структуры, вы можете ясно видеть, что данные передаются, и что это за данные.

❓Но разве doSomething(ctx) не выглядит намного чище, чем doSomething(ctx, someStruct)?

Чистый код сам по себе не является целью. Код не чист только потому, что он короткий. Код чистый, если читатель может ясно видеть, что он делает.

❓Так context.WithValue() следует избегать?

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

💡Если данные важны для вашей бизнес-логики, не помещайте их в Context.

#tip