💡Запускаем Go-бинари прямо из репозитория

Про возможность установки бинаря из репозитория через go install знают все. Менее известным фактом является то, что мы можем запускать двоичные файлы прямо из репозитория, например, так:

$ go run github.com/cosmtrek/air@latest

🤩Никакой установки, никакого клонирования, никакого Makefile, и ваш бинарь всегда в актуальном состоянии.

💬В таком случае нужно всегда быть онлайн?

☑️go run подключается к go proxy при каждом вызове для проверки на наличие более новой версии.

☑️Но мы можем обойти это поведение, заменив @latest фиксированным номером версии (например, @v1.45.0). Тогда команда будет нормально работать в автономном режиме.

#tip

💡Перепроверьте ваши 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

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

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

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

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

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

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

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

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

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

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

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

#tip

🤔 Где искать библиотеки и инструменты для своих проектов?

🧰 Подборка для Go-разработчика:

🔗 pkg.go.dev

Здесь вы можете найдете пакеты по различным критериям и получите информацию о версии, лицензии и многом другом.

🔗 GitHub

Вводите в поисковую строку language:go + свой запрос и анализируете результаты.

🔗 Awesome Go

Один из самых старых и самых поддерживаемых кураторских списков по Go.

🔗 Libhunt.com

Коллекция Go-проектов, отфильтрованных по количеству упоминаний, звезд или другим критериям.

🔗 go-recipes

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

#tip

🤔 Вы когда-нибудь путались в «первом» и «последнем» индексах при операциях вроде этой:

s := a[3:7]

Она создает срез из массива a, начиная с третьего элемента (с нулевым индексом) и до, но не включая, элемента седьмого элемента.

Таким образом, «последний» индекс кажется указывающим за пределы a.

Вместо того, чтобы напрямую сопоставлять индекс с элементом...

| G | o | p | h | e | r | s |   |
^   ^   ^   ^   ^   ^   ^   ^
0   1   2   3   4   5   6   7?

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

| G | o | p | h | e | r | s |
^   ^   ^   ^   ^   ^   ^   ^
0   1   2   3   4   5   6   7

Тогда срез a[3:7] вполне естественно относится к элементам между индексом №3 и индексом №7.

#tip

💡Как тривиально проверить значения интерфейса на nil?

В Go новички часто сталкиваются с проблемой интерфейсных переменных, которым присваивается nil указатель. В таком случае, хотя значение в интерфейсе является nil, сама переменная интерфейса не равна nil.

Пример: создаем переменную x как указатель на int, который по умолчанию nil, и переменную y как пустой интерфейс, который тоже nil по умолчанию. После присваивания x переменной y, интерфейс y уже не является nil, хотя x все еще nil.

var x *int
var y any
y = x

📌 Что вернет y == nil?

Вернет false. Это потому, что интерфейс не просто представляет значение, которое ему присвоено, а действует как контейнер для этого значения.

Для проверки, является ли значение в интерфейсе nil, нужно использовать утверждение типа. Например, для проверки y на nil, используем:

y.(*int) == nil

Это показывает, что интерфейс y не nil, но содержащееся в нем значение — nil. Полный пример здесь.

#tip

🤔 Как исключить зависимости разработки из бинарных файлов в Go: по мотивам статьи Redowan Delowar

В настоящее время, в отличие от Python или NodeJS, Go не позволяет указывать зависимости разработки отдельно от зависимостей приложения. Однако автор предпочитает явно указывать зависимости разработки для лучшей воспроизводимости.

Работая над новым CLI-инструментом для проверки неработающих URL-адресов в файлах markdown, автор столкнулся с интересным соглашением: можно указать зависимости разработки в файле tools.go и затем исключить их при сборке бинарного файла, используя тег сборки.

Вот как это работает. Предположим, у нашего проекта foo есть следующая структура:

foo
├── go.mod
├── go.sum
└── main.go

Файл main.go содержит простую функцию "hello-world", использующую стороннюю зависимость:

package main

import (
    "fmt"

    // Cowsay - это сторонняя зависимость приложения
    cowsay "github.com/Code-Hex/Neo-cowsay"
)

func main() {
    fmt.Println(cowsay.Say(cowsay.Phrase("Hello, World!")))
}

Здесь Neo-cowsay — это зависимость приложения. Для инициализации проекта запускаются следующие команды:

go mod init example.com/foo   # создает файлы go.mod и go.sum
go mod tidy                   # устанавливает зависимости приложения

Теперь предположим, что мы хотим добавить следующие зависимости разработки: golangci-lint для линтинга проекта в CI и gofumpt как более строгий gofmt. Поскольку эти инструменты не импортируются напрямую, они не отслеживаются инструментарием сборки.

Но можно воспользоваться следующим воркфлоу:

1. Разместить файл tools.go в корневой директории.
2. Импортировать зависимости разработки в этом файле.
3. Запустить go mod tidy, чтобы отслеживать как зависимости приложения, так и зависимости разработки через go.mod и go.sum.
4. Указать тег сборки в tools.go, чтобы исключить зависимости разработки из бинарного файла.

В этом случае файл tools.go выглядит следующим образом:

// go:build tools

package tools

import (
    // Зависимости разработки
    _ "github.com/golangci/golangci-lint/cmd/golangci-lint"
    _ "mvdan.cc/gofumpt"
)

Теперь, если вы запустите go mod tidy, инструментарий Go будет отслеживать зависимости через файлы go.mod и go.sum. Вы можете проверить зависимости в go.mod.

Хотя зависимости разработки отслеживаются вместе с зависимостями приложения, тег сборки // go:build tools в начале файла tools.go скажет инструментарию сборки игнорировать их при создании бинарного файла.

Из корневой директории foo можно собрать проект, запустив:

go build main.go

Это создаст бинарный файл main в корневой директории. Чтобы убедиться, что бинарный файл не содержит зависимости разработки, запустите:

go tool nm main | grep -Ei 'golangci-lint|gofumpt'

Это не вернет ничего, если зависимости разработки не упакованы в бинарный файл.

Но если вы сделаете это для зависимости приложения, она выведет артефакты:

go tool nm main | grep -Ei 'cowsay'

Команда выведет:

1000b6d40 T github.com/Code-Hex/Neo-cowsay.(*Cow).Aurora
1000b6fb0 T github.com/Code-Hex/Neo-cowsay.(*Cow).Aurora.func1
1000b5610 T github.com/Code-Hex/Neo-cowsay.(*Cow).Balloon
1000b6020 T github.com/Code-Hex/Neo-cowsay.(*Cow).Balloon.func1
...

Если по какой-то причине вы хотите включить зависимости разработки в свой бинарный файл, вы можете передать тег tools при сборке бинарного файла:

go build --tags tools main.go

#tip