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

📕 Книги: 

➡️ Михалис Цукалос «Golang для профи: Создаем профессиональные утилиты, параллельные серверы и сервисы», 3 издание

➡️ Тейва Харшани «100 ошибок Go и как их избежать» 

➡️ Том Стил, Крис Паттен, Дэн Коттман «Black Hat Go: Программирование для хакеров и пентестеров»

➡️ Натан Козыра, Мэтт Батчер, Мэтт Фарина «Go на практике», 2 издание

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

Интерфейсы:

Разбираемся с интерфейсами в Go

Интерфейсы в Go — как красиво выстрелить себе в ногу

Погружение в интерфейсы Go

От интерфейсов переходим к зависимостям: 

Все равно не обойдетесь! Использование интерфейсов и внедрение зависимостей для долговечного проектирования

Внедрение зависимостей в GO

Go-inject — Dependency Injection Library for Go

Да, между последними двумя статьями можно прокачать английский. 

Теперь беремся за тестирование:

Табличные тесты в Go с использованием Gomock

И представление о контексте нам тоже надо:

Разбираемся с пакетом Context в Golang

Golang: context изнутри

Параллелизм и каналы мы тоже хотим:

Погружение в параллелизм в Go

Анатомия каналов в Go

Под капотом Golang — как работают каналы. Часть 1 и Часть 2

Подборка почти готова, добавим немного SOLID:

Принцип SOLID в языке Go

SOLID в Go и щепотка паттернов

Чуть не забыли про выделение памяти:

A visual guide to Go Memory Allocator from scratch (Golang)

Сборщик мусора (можно читать вечером, за плохую примету не считается):

Dumpster diving the Go garbage collector

Мы прокачали уровень, теперь нам доступны ультимативные гайды: 

Планировщик Go — самый подробный гайд простым языком

Учимся разрабатывать REST API на Go на примере сокращателя ссылок

Пишем gRPC сервис на Go — сервис авторизации

▶️ Эти ультимейты и много чего еще есть на канале Николая Тузова. Горячо советуем. 

Ну и про официальный сайт с обучениями не забывайте. 

Сохраняйте подборку себе и отправляйте коллегам. И пишите в комментах, про что мы забыли.
#польза

В рабочих чатах полно асапных задач, согласований и правок, но не хватает любви? Забирайте стикерпак, с которым общаться с коллегами станет еще приятнее.

Вообще-то мы пишем о любви не раз в год, а довольно регулярно. Если вы пропустили, вот подборка постов о любви к профессии:

➡️ Чем QA-инженеры отличаются от волков и змей

➡️ Кто такой товарищ программист Си

➡️ Как кошка съела акулу, и почему ИИ должен дружить с БД

➡️ Кому звонят, когда падает прод

➡️ У какого детектива лицензия на производительность

Поделитесь стикерами и постами с коллегами — несите любовь в рабочие чаты.

PGMeetup.SPB/26 — традиционная февральская встреча Postgres Professional и Selectel

Встречаемся 26 февраля в Санкт-Петербурге, чтобы поговорить о том, как строить эффективную инфраструктуру, когда требования СУБД встречаются с реальными возможностями железа и облаков.

Зимним вечером увидимся на Цветочной улице и обсудим темы, которые с флорой никак не связаны: как устроены современные S3-хранилища, как тестируют аналитические СУБД, и наконец разберемся в споре вокруг P- и E-ядер.

Программа:

➡️ Кошкино время
Михаил Жилин, Postgres Professional — директор департамента системной производительности

Как измерять время выполнения, когда нужны доли секунды и от вас ждут конкретных цифр. На примере тестирования OLAP-запросов в Postgres Pro и ClickHouse — и с неожиданными параллелями к баг-репорту эмулятора PlayStation 3 и исследованиям про фотоэмиссию.

➡️ Как мы строим S3 в Selectel
Александр Гришин, Selectel — руководитель по развитию продуктов хранения данных
Алексей Миронов, Selectel — директор по облачной инфраструктуре

Что такое объектное S3-хранилище и зачем оно нужно. Как выглядит S3 на физическом уровне: ЦОДы, стойки, серверы, дисковые подсистемы. А еще — архитектура приложения (layered design, микросервисы, ключевые компоненты), клиентские кейсы и использование S3 как основы для дата-платформ.

➡️ Эпоха универсальных CPU закончилась: как выбрать между P- и E-ядрами Xeon 6
Максим Башмаков, Selectel — руководитель отдела тестирования оборудования

Зачем Intel разделил Xeon 6, куда смотрят облака и почему универсальные CPU перестали быть оптимальными. Плюс типовые ошибки при выборе сервера или CPU и результаты тестов.

📍 Где и когда:

Санкт-Петербург, офис Selectel, ул. Цветочная, 19

26 февраля, 18:30

Регистрируйтесь и приходите с хорошим настроением и вопросами к спикерам.

На входе понадобится паспорт. До встречи!

На DUMP SPB 2026 Евгений Пажитнов, технический менеджер Postgres Professional, выступил с докладом «Снижение количества критичных инцидентов при эксплуатации продуктивных систем».

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

И только часть инцидентов имеет чисто технические причины. Остальное обычно упирается в людей и процессы.

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

Этот мини-чеклист нужен тем, кто отвечает за стабильность прода: DBA, SRE и инженерам эксплуатации, тимлидам и владельцам критичных сервисов. Он помогает за 10 минут понять, где в повседневной эксплуатации у вас слабые места, которые чаще всего превращают небольшой сбой в критичный инцидент.

✔️ Мониторинг работает 24x7, шлет уведомления, и у предупреждений есть владелец?

✔️ Зафиксирован базовый уровень и отклонения для CPU, дискового ввода-вывода, задержки диска, памяти и пользовательской нагрузки?

✔️ Обновления ставятся регулярно, есть тестовое окружение, и для каждого изменения предусмотрен откат?

✔️ Есть план аварийного восстановления, детализированный до команд, и его регулярно прогоняют с фиксацией времени восстановления?

✔️ Ведется журнал изменений с датой, автором, старым и новым значением и причиной?

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

Если набралось несколько «Нет», это уже системный риск: при следующем сбое команда будет импровизировать, а простой почти наверняка затянется.

Сначала отработайте аварийное восстановление и фиксируйте реальное время возврата сервиса. Затем наведите порядок в изменениях: тестовый контур, откат, журнал. И уже после усиливайте мониторинг и базовые показатели, чтобы ловить отклонения до аварии.