‼ЗАДАЧА О ДВУХ ГЕНЕРАЛАХ. ЧАСТЬ 1.

Конечно технологии идут вперед и брокеры сообщений пытаются обеспечить надежную доставку сообщений, но нет 100% гарантии. Поэтому при работе с брокерами сообщений очень важно понимать следующие семантики:

➡️ at least once («хотя бы один раз») - если мы не получили подтверждение от «посыльного», мы можем отправить еще одного через какое-то время. В чем тут проблема: получатель может получить оба этих письма, и хорошо если в них одинаковые сообщения, а если разные?)
➡️ at most once («не более одного раза») - если мы не получили подтверждение от «посыльного», мы ничего повторно не отправляем, дабы избежать путаницы в сообщениях у получателя. Тут проблема, что часть посланий получатель может не получить, а это может оказаться критичным для ряда случаев (например при штурме замка, или если вы отправляете событие в логистику о создании заказа)
➡️ exactly once («строго однократная доставка») - то чего, как мы поняли из задачи, добиться очень тяжело. Если мы отправим несколько посыльных, получатель должен получить только одно письмо. Чаще всего это достигается с помощью специальной «пометки» на письме - ключа идемпотентности. Получатель (или коллективный разум посыльных, если такой бы был) по этой метке понимает, является ли данное сообщение дубликатом уже прочитанного сообщения или нет, и игнорирует его.

Одним из инструментов, позволяющим реализовать любую из данных семантик, является Apache Kafka. Это довольно гибкий и производительный брокер сообщений. Но за счет его гибкости на разработчика возлагается БОЛЬШАЯ ответственность при разработке системы: от выбора семантики обмена сообщениями, до выставления необходимых настроек на клиенте и брокере. Поэтому, я считаю, что понимание данных основ обязательно для Senior разработчиков.
__________________________

❓А каких еще брокеров сообщений вы знаете, и какие семантики они способны обеспечить?

👩‍💻 ВНУТРЕННЕЕ УСТРОЙСТВО ПЛАНИРОВЩИКА GO!

Ранее я говорил, что очень не равнодушен к статьям и докладам про внутренние устройство языков и технологий. А особенно, если это про Go!

📆 23 апреля в 19:00 по МСК мой коллега по цеху, Владимир Балун, проведет бесплатный открытый урок по внутреннему устройству планировщика Go.

Если вы давно хотели разобраться как устроен Go под капотом — это отличная возможность! В программе открытого урока множество тем, которые обычно любят задавать на собеседовании.
Не пропустите такую возможность, регистрируйтесь на открытый урок!

Регистрация доступна по ссылке.

📌 Частый вопрос на собеседование про SQL: последовательность выполнения SQL команд.

Обратите внимание, что LIMIT и OFFSET выполняются в самом конце. Т.е если вы делаете пагинацию через LIMIT+OFFSET, то БД будет проделывать всю выборку и только потом ограничивать выдачу запроса.

На эту тему есть хорошая статья про пагинацию в PostgreSQL.

👩‍💻 PostgreSQL - СОВЕТЫ ПО ЭФФЕКТИВНОЙ РАБОТЕ.
ЧАСТЬ 1.

PostgreSQL - в настоящая время одна из самых популярных СУБД на рынке. Все компании и разработчики любят Posgtres за его надежность, производительность, поддержку ACID транзакций и многое другое. Я бы сказал что PostgreSQL - это швейцарский нож в кармане любого уважающего себя backend-разработчика.

PostgreSQL - тот инструмент, который легко внедрить и использовать в production решениях. Но с ростом проекта и нагрузок на первый взгляд может показаться, что производительности PostgreSQL уже не хватает. На самом деле это не всегда так. И вот верные способы выжать ПО МАКСИМУМ из этого прекрасного слоника:

1️⃣CONNECTION POOLER

ОБЯЗАТЕЛЬНО используйте пуллер соединений. Для чего он нужен? Когда у вас много инстансов вашего приложения, становится очень сложно контролировать количество соедиенеий к Postgres, а на каждое соединение СУБД тратит не мало ресурсов на их обслуживание. Пуллеры соединения решают эту проблемлему: они становятся прокси серверами между вашим приложением и БД и контролируют заданное число соединений, да еще и утилизируют из по максимум. github.com/yandex/odyssey - один из самых лучших пуллеров соедиеней на сегодняшний день.

2️⃣НИКАКОЙ БИЗНЕС ЛОГИКИ В БД

Откажитесь от триггеров, хранимых процедур, внешних ключей, лишних и жестких сonstraint-ов, которые лишний раз валидируют то, что должно валидировать ваше приложение! В 2024 году ваше приложение должно заботиться о валидности и консистетности данных. БД - просто инструмент для хранения и получения данных. Помните: приложение масштабировать (скейлить) сильно проще, чем вычислительные ресурсы БД.

3️⃣ИЗБЕГАЙТЕ ШИРОКИХ ТАБЛИЦ

Если в вашей таблице 40+ колонок, вы что-то явно делаете не так. Дело все в том, что Postgres хранит записи таблицы в файлах по строчно друг за другом, и когда вы делаете обновление строк, на самом деле это запись новой версии строки, и, если обновляете 2-3 поля, остальные ваши поля кочуют баластом. PostgreSQL на много лучше управляет относительно небольшими строками, а если они еще и фиксированной длинны, тогда место на дисках и в кеше экономится значительно больше. Также лучше все колонки переменной длинны располагать в конце таблицы.

4️⃣ИЗБЕГАЙТЕ ТАБЛИЦ С ГИГАНТСКИМ КОЛИЧЕСТВОМ СТРОЧЕК

Тут все просто - чем больше записей в таблице - тем больше размер индекса. Чем больше размер индекса - тем больше файлов индекса требуется прочитать БД. Если индекс весит несколько гигабайт, он не умещается в оперативной памяти Postgres и тогда происходит уже чтение с диска, а это довольно медленная операция. Но как быть если записей и правда много и нам все их надо хранить? Ответ кроется в следующем пункте.

👩‍💻 PostgreSQL - СОВЕТЫ ПО ЭФФЕКТИВНОЙ РАБОТЕ.
ЧАСТЬ 2.

5️⃣РАЗДЕЛЯЙ И ВЛАСТВУЙ

При проектировании схемы БД и модели данных сразу прогнозируйте объем данных через год-два. Если вы понимаете, что число записей сильно переваливает за миллион, стоит задумать о том по какому принципу стоит делить эти данные. Например, если у вас интернет магазин и вы храните записи о заказа клиента, скорее всего заказы сделанные давно вам редко будут нужны. В этом случае поможет партиционирование таблицы по временному интервалу (в данном случае ключ партиционирования - время создания заказа). Postgres будет иметь набор условно маленьких табличек, каждая из которых содержит свои маленькие индексы. в 90% случаях вы будете работать со свежими заказами, и все запросы будут идти в последние партиции, которые уже полностью могут помещаться в кеш Postgres. Вы можете выбрать ключом партиционирования что угодно, главное, чтобы партиции были +- одного размера и обращения происходили к минимальному их количеству.

6️⃣RAM - НАШЕ ВСЁ

Берегите оперативную память Postgres. Не бойтесь накидывать больше оперативной памяти кешу Postgres - чем больше он, тем больше данных там поместится, и тем меньше будет чтений с диска, и, соотвественно, меньше задержек. Но оперативная память нужна не только кешу, она нудна также для обработки запросов приложения. Следите за потреблением памяти вашими запросами, старайтесь доставать как можно меньше данных из БД. По максимум фильтруйте записи, где это возможно. Не делайте 10 JOIN-ов ради того, чтобы обогатить ответ парочкой полей, которые могли бы хорошо закешироваться в вашем приложении.

7️⃣ДЕНОРМАЛИЗАЦИЯ ДАННЫХ

3-я нормальная форма - это конечно хорошо, но если 90% запросов в БД - это чтение с постоянными одними и теме же JOIN-ами, то стоит задуматься о денормализации данных. Денормализованные данные сложнее обновлять, но довольно просто получать по одному ключу.

8️⃣ДОЛГИЕ ТРАНЗАКЦИИ - ЗЛО

Любая транзакция несет много накладных расходов, а долгоживущая транзакция - это ноша, которая тяжелеет с каждой новой параллельно выполненной транзакцией. Долгая транзакция также не позволяет пуллеру переиспользовать соединение с БД для других запросов. Также не стоить делать большое число изменений/удалений в рамках одной транзакции, это может вызвать bloat.
Маленькие быстрые транзакции лучше себя ведут.

9️⃣МАСШТАБИРОВАНИЕ

Postgres можно мастшабировать двумя способами:

1. За счет добавления реплик и чтения из них. В этом случае не стоит использовать мастер только на запись, так как Postgres собирает статистику использования данных только с мастера. Эта статистика очень хорошо помогает при планировании исполнения запросов. При чтении с мастера эта статистика попадет в реплики и они начнут более эффективно строить планы запросов.
2. За счет шардирования. Тут все просто, вы разделяете ваши данные по разным инстансам и контролируете где какие лежат. К сожалению из коробки PostgreSQL не умеет шардировать данные и вам скорее всего придется использовать сторонние решения.

🔟 МОНИТОРИНГ

Ну и последний совет: собирайте статистику и метрики, которые предоставляет Postgres. Обеспечьте мониторинг вашей БД 24/7 и своевременно находите узкие места. Анализируйте запросы. Не увлекайтесь ненужными индексами, они не всегда ускоряют запросы. Создавайте индексы под определенные частые запросы.

Вот и прошли майские праздники 📆

Давно не ходил на конференции, да и некогда особо...
Наткнулся на онлайн конференцию по любимому 👩‍💻 - Podlodka Go Crew (кстати, темы там не только по Go). Взял себе билет🎫Конференция идет всю неделю по 2 доклада в день.

Решил, что буду всю неделю делиться своим мнением по докладам тут. Вы тоже можете в комментариях делиться свои мнением)

Сегодня уже было два доклада:
1. «SQLite как основная база данных» / Никита Галушко (ВКонтакте)
2. «Мокирование vs предзаполнение базы данных» / Павел Вирский (Озон Банк), Глеб Карпушкин (Ozon Fintech)!

Естественно онлайн я пропустил, приходится ночью досматривать записи)

По первому докладу могу сказать, что идея использовать в простых системах SQLite может быть оправдана. Но на мой взгляд, если поддержка инфраструктуры (IaaS, DBaaS) в компании автоматизирована и на высоком уровне (как например в Ozon), то проще развернуть маленький Postgres по клику кнопки, чем потом с SQLite слезать при масштабировании сервиса.

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

Вот и прошла еще одна рабочая неделя. Все эти 5 дней я со своей командой занимался разработкой нового сервиса с нуля. Было очень много дискуссий, обсуждений, черновиков, записей, созвонов и, конечно же, вопросов, которых осталось еще не мало…

Ну и в общем-то я понял, что задачи разработчика глобально можно разделить на 3 типа:

1️⃣Разработка новых решений с нуля (ресерч)

Это то, о чем мечтают многие разработчики и спрашивают на собеседованиях у работодателя. Конечно, в разработке с нуля есть ряд плюсов:
✅не надо разбираться в чужом коде,
✅можешь спроектировать космолет по всем правила и канонам сам
✅и вообще применить все свои наработки, подходы и т. д.
Но также есть и минусы таких задач: очень много вопросов о конечном продукте (чаще всего новые проекты - это какие-то MVP, которые не всегда понятно как будут расширяться потом и куда пойдут).
Можно уйти в долгую полемику выбора архитектуры, проработки API, схемы БД (ведь хочется сразу все сделать универсально и на века!). Также вы можете столкнуться с проблемой, которую никто до вас еще не решал, и это может стать настоящим rocket since (но есть и те, кого это драйвит).

2️⃣Поддержка и развитие существующего проекта, технологии

Вообще таких задач, как правило, больше остальных.
➕Из плюсов: уже есть устоявшаяся архитектура, подходы и технологии. Могут попасться изящные примеры и подходы в коде, на которых можно всегда научиться и поднять свою экспертизу.
🌟Из минусов: как правило, требуется не мало умственных усилий на погружение в проект, уменьшается гибкость разработки новых фич. Иногда приходится ломать голову, как не сломать все и при добавлении новой функциональности (тут требуется скилл ювелирного внедрения).

3️⃣Поддержка легаси

Легаси - это что-то старое, страшное, запутанное, мало освещенное, но худо-бедно работающее решение.
Ночной кошмар для большинства разработчиков: ты пришел в новую IT компанию, чтобы разрабатывать новые крутые проекты, а тебе дают ЭТО... И вот 3 бессонные ночи ты отлаживаешь код, чтобы понять, что тут вообще происходит и что автор кода пытался донести.
Но и в таких задачах можно найти жилу радости и успеха: переписывание легаси! Если сделать его качественно, быстро, да еще если это закроет существующие проблемы... Оооо, вам обеспечено место на доске почета в компании, такое точно запомнят!

Самое смешное, что как только надоедает один тип задач, хочется другой. Но и он тоже надоест, и так по кругу... Одна из причин ухода разработчика в другую команду/компанию, как правило, становится как раз "однообразие задач".

Если всегда давать задачи на ресерч или создание с 0 космолетов, разработчик просто выгорает. Если давать задачи на развитие сервиса - рано или поздно развитие проекта может затормозиться. Такое бывает, когда кардинально новых идей нет и все задачи сводятся к точечному улучшению функционала. Это быстро надоест, так как нет особо развития новых компеценций у разработчика. Ну и легаси: поддержка легаси приемлема, когда это временная мера, пока не появится что-то новое и лучше. Если продолжать трогать и расширять легаси код, то скорее всего к вам в команду потом никто не придет.

📌В общем, совет руководителям: следите за разнообразием задач у разработчиков.
Разработчики - не бойтесь просить у лидов смену характера задач, когда понимаете, что уже начинает надоедать. Уйти всегда можно)

❔А какой тип задач сейчас у вас на данный момент?

👨‍💻Junior Go разработчик:

for i := range jobs {
    job()
}

👨‍💻Middle Go разработчик:

var wg sync.WaitGroup
for i := range jobs {
    wg.Add(1)
    go func(job jobType) {
        defer wg.Done()
        job()
    }(jobs[i])
}
wg.Wait()

👨‍💻Senior Go разработчик:

var workersNum = runtime.NumCPU()

var (
    wg sync.WaitGroup
    in = make(chan jobType, workersNum)
)
for i := 0; i < workersNum; i++ {
     wg.Add(1)
     go func() {
         defer wg.Done()
         for job := range in {
             job()
         }
     }()
}

for i := range jobs {
    in <- jobs[i]
}
close(in)
wg.Wait()

🧠Lead Go разработчик:

import "github.com/sourcegraph/conc/iter"


iterator := iter.Iterator[jobType]{MaxGoroutines: runtime.NumCPU()}

iterator.ForEach(jobs, func(job jobType) {
   job()
})

Да, асинхронность в 👩‍💻 довольно изящна и проста (если сравнивать с другими языками). Но все же она требует от разработчика внимательности и хорошего знания языка. А в случае ошибки вам будет обеспечена утечка памяти или deadlock.

Что отличает ведущего (Lead) разработчика от других? Он пишет эффективные решения довольно быстро, а главное эти решения надежные и, в идеале, изящны. Часто это достигается путем использования проверенных инструментов.

Одним из таких инструментов - github.com/sourcegraph/concНа мой взгляд это то, чего не хватает в стандартной библиотеке Go. Максимально изящная асинхронность, спрятанная за синтаксическим сахаром. С этой библиотекой шансов словить утечку памяти резко уменьшаются, а скорость проведения код ревью увеличивается.

Делайте вещи проще! (KISS)

УБИЙЦА GO И RUST?

Пока 👩‍💻 и 👩‍💻 разработчики спорят друг с другом чей же язык круче и лучше, Marco Sampellegrini, автор книги The Simple Haskell Handbook и разработчик системы непрерывной интеграции Quad CI,
написал новый язык программирования — Borgo.

Borgo пытается быть более выразительным, чем Go, но менее сложным, чем Rust. Он комбинирует лучшие черты Go и Rust, восполняя недостатки каждого из языков. Компилятор написан на Rust. Сам язык совместим с пакетами Go (можно вызывать гошный код).

Что-ж, там есть enum :)

go:use fmt

enum NetworkState {
    Loading,
    Failed(int),
    Success(string),
}

let msg = match state {
    NetworkState.Loading => "still loading",
    NetworkState.Failed(code) => fmt.Sprintf("Got error code: %d", code),
    NetworkState.Success(res) => res,
}

Начнут ли все переходить на Borgo? Думаю, вряд ли… Пиар команда слабая и нет локомотивного комьюнити. Но мб это хороший толчок к скорому Go 2.0🤔

А вас заинтересовал Borgo?
Ставь:
🔥 - да
❤ - Go one love
😎 - пошел писать дальше на Rust

👩‍💻 Docker заблокировал доступ к своему главному репозиторию Docker Hub для пользователей из России!

Что ж... еще одна компания придерживается принципов "демократии", "свободы слова" и за справедливость во всем мире!

Docker - не первый и не последний, кто уходит из РФ или блокирует доступ:
- Redis
- Buf.build
- Swagger
- Jetbrains
- ...
Список можно продолжать бесконечно...

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

Инструкция по восстановлению доступа к Docker Hub для пользователей из России

🔗 Читать статью
🔗 Зеркало

ЗАПИСЬ ОТКРЫТОГО УРОКА ОСНОВЫ gRPC В GO❗️

👉ссылка тут 👈

Ставь 🔥, если хочешь узнать больше о gRPC!

❗РАБОТА С PROTOBUF НА ОТРАСЛЕВОМ УРОВНЕ. ЧАСТЬ 1.

1️⃣ В любом современном языке есть средства форматирования, например prettier для 👩‍💻, gofmt для 👩‍💻 и rustfmt для 👩‍💻. К сожалению долгое время форматирования в protobuf отсутствовало на должнем уровне. И вот в CLI buf появилась функцию format, которая позволяет форматировать Protobuf файлы в соответствии с отраслевыми стандартами.

Вот пример отформатированного файла:

syntax = "proto3";

package moguchev.my.awesome.package.api.users;

import "google/api/field_behavior.proto";
import "protoc-gen-openapiv2/options/annotations.proto";
import "validate/validate.proto";

option csharp_namespace = "Moguchev.My.Awesome.Package.Api.Users";
option go_package = "github.com/moguchev/my/awesome/package/pkg/api/users;users";

// GetUsersRequest - GetUsersRequest request
message GetUsersRequest {
  option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_schema) = {
    json_schema: {
      noscript: "ListServicesRequest"
      denoscription: "ListServices request"
      required: [
        "pagination"
      ]
    }
  };
  // pagination - пагинация
  Pagination pagination = 1 [
    json_name = "pagination",
    (google.api.field_behavior) = REQUIRED,
    (validate.rules).message.required = true
  ];

  // ids - идентификаторы сервисов
  repeated uint64 ids = 2 [json_name = "id"]; // query param: ?id=1&id=2
}

Форматирует buf реально круто, но есть нюанс - нет возможности настроить правила форматирования. Разработчики buf посчитали, что отформатировать .proto файл можно лишь единственным образом. К сожалению инструмент еще не завезли в VSCode 👩‍💻 и IntelliJ 👩‍💻, но обещают в скором времени добавить. Ждем!)

❗РАБОТА С PROTOBUF НА ОТРАСЛЕВОМ УРОВНЕ. ЧАСТЬ 2.

2️⃣ Следить за форматированием и качеством оформления, нейминга и т.д. вручную почти невозможно и конечно же линтеры были созданы для этой рутинной задачи.

В buf также есть команда lint. Но на мой взгляд есть более удобный линтер protobuf - protolint, который можно гибко конфигурировать с помощью yaml файла. Также в VSCode 👩‍💻 можно поставить расширение protolint. И protolint довольно легко интегрировать в CI/CD:

protolint:
  image: yoheimuta/protolint:latest
  stage: lint
  noscript: protolint -config_path ./.protolint.yaml ./proto/

3️⃣ Экосистема protobuf и gRPC активно развивается, хоть и не так быстро как хотелось бы. На мой взгляд, gRPC и protobuf постепенно становятся отраслевым стандартом разработки микросервисов. Хотите узнать больше про protobuf и быть в курсе последних тенденций? ⬇️

📚Protocol Buffers Handbook: Getting deeper into Protobuf internals and its usage (2024) - Clement Jean

Эта книга поможет вам войти в мир протокольных буферов, раскрыв сложные нюансы синтаксиса Protobuf и расскажет о всех опциях и продвинутых плагинов.

-----------

❓А вы используете в своих проектах protobuf или gRPC?

🎬 ОТКРЫТОЕ СОБЕСЕДОВАНИЕ GO РАЗРАБОТЧИКА

Первое мое открытое mock собеседование: https://www.youtube.com/watch?v=sy09jrBhWzY

Задал самые частые вопросы и темы по теории Golang. К сожалению не хватило времени на вопросы про дженерики и паттерн контекст.

✔️100 ПОДПИСЧИКОВ ✔️

Спасибо всем, кто подписан на мой канал, это, правда, очень важно для меня ☝🏻

Сейчас нахожусь в отпуске. В следующем посте поделюсь впечатлениями о 2-х странах для релокации: Турция и Грузия.

ИДЕАЛЬНАЯ СТРАНА ДЛЯ РЕЛОКАЦИИ РАЗРАБОТЧИКА

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

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

Итак, первая страна — Турция🇹🇷. В 2022 большой поток русских устремился именно туда. Первая причина — на тот момент там было все сильно дешевле, чем в России. Вторая причина — Турция - это довольно развитая, южная страна с хорошей инфраструктурой, солнцем, морем и т.д. Сейчас в Турции цены сильно выросли и недвижимость тоже, так что финансово свободно там себя уже не почувствуешь. Совет по городам для проживания: Стамбул (развитый город со всеми привычными благами цивилизации), Измир (современный город без туристов), Каш (тихий городок у моря, подойдет для жизни пару месяцев летом).

Вторая популярная страна для «релокантов» стала… ГРУЗИЯ!🇬🇪
Не просто так: граничит с Россией и можно даже на машине туда попасть, вкусная еда, красивые виды, есть море. Многие говорят на русском (хоть сейчас там антироссийские настроения, на русском и английском вас всегда поймут). В Грузии я выделил два города, где большинству будет привычно - Тбилиси (столица со своей атмосферой, антуражем) и Батуми («мини Дубай» в стадии зачатка с огромным числом продающейся и сдающейся недвижимости). Но цены там не ниже московских, а на что-то даже выше.

Армения 🇦🇲 — дружественная страна для России. Здесь принимают карту МИР (актуально для тех у кого нет зарубежной), все спокойно говорят на русском. Для жизни подойдет наверное больше всего Ереван. Но будьте готовы, наши соотечественники вызвали тут рост цен во всех сегментах: аренда жилья, цены в ресторанах, аренда авто, отели, гостиницы и т д. Жизнь тут в среднем на 15-45% дороже чем в Москве.

Азербайджан 🇦🇿 — почему-то не такая популярная страна и, на мой взгляд, недооцененная. Выбор тут из городов для жизни, пожалуй, единственный, но очень хороший - Баку. Поистине столица! Тут точно есть все условия для жизни, инфраструктура, жилье и прочее. А цены на жизнь и аренду еще не разогнаны до околокосмических цифр.

——————

Надеюсь, было интересно. Если кто-то живет сейчас в этих странах, поделитесь пожалуйста в комментариях🙂