Пожалуй лучшее объяснение, почему я оставляю вещи на стуле😅

Первый месяц на позиции TeamLead выглядит именно так😅

Говорят, чтобы стать профессионалом в любой сфере, нужно 10 000 часов практики.

Если тратить на развитие по 40 часов в неделю — это 250 недель, то есть примерно 5 лет непрерывной работы (именно поэтому в вакансиях для уровня senior требуют опыт работы от 5 лет). Надо 5 лет, чтобы выйти на уровень эксперта…

Но давайте честно: а можно ли быстрее?

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

По-настоящему мы растём, когда сами ищем новое, пробуем, экспериментируем, ошибаемся и исправляемся. Не ждём «особой задачи», которая вдруг нас вытащит на новый уровень, а сами становимся источником своего роста.

Потому что правда проста: ни ваш руководитель, ни компания, ни коллеги, ни даже ментор не заинтересованы в вашем развитии так, как вы сами.
За ваши навыки отвечаете только ВЫ.

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

А когда и что нового вы в последний раз изучили в своей сфере?

У кого хоть раз такое было?)

🚀 Меньше двух недель до нашего backend-митапа

Приходи, чтобы погрузиться в многопоточность, микросервисы, промпт-инжиниринг и System Design с разработчиками из BigTech. Разбираем то, что нужно для работы и успешных собеседеоний.

• Когда: 20 сентября
• Где: Москва, Пространство «Весна»

🎟️ Еще остались билеты, поспеши!

Приобрести билет можно по ссылке: https://clck.ru/3Nd8ea

Отличная дискуссия получилась — и да, большинство гуру Postgres ответило верно! Давайте спокойно разберёмся, почему.

«Совсем плохой» способ — просто сделать колонку NOT NULL:

ALTER TABLE some_big_table
  ALTER COLUMN foo_field SET NOT NULL;

Почему так делать очень плохо на большой таблице?

Чтобы убедиться, что в столбце нет NULL, Postgres сканирует всю таблицу. Такие изменения вокруг ADD CONSTRAINT/SET NOT NULL обычно требуют ACCESS EXCLUSIVE — самый сильный DDL-лок, конфликтующий со всеми операциями, включая чтения. Это легко превращается в stop the world на таблице, если операция длится долго.

Правильный подход: через NOT VALID → VALIDATE

Идея — разделить «включить проверку для новых записей» и «проверить историю» на два шага.

1. Добавляем ограничение без проверки истории (не блокирует обновления надолго):

ALTER TABLE some_big_table
  ADD CONSTRAINT some_big_table_foo_field_not_null
  CHECK (foo_field IS NOT NULL) NOT VALID;

С флагом NOT VALID добавление не сканирует таблицу и может быстро зафиксироваться. Новые/изменённые строки уже обязаны удовлетворять условию.

2. Отдельно валидируем историю:

ALTER TABLE some_big_table
  VALIDATE CONSTRAINT some_big_table_foo_field_not_null;

VALIDATE CONSTRAINT сканирует только существующие строки и берёт уже SHARE UPDATE EXCLUSIVE (гораздо мягче), так что записи не блокируются так сурово, как при прямом SET NOT NULL.

Что именно могло заблокировать таблицу в нашем кейсе?

Наша SQL миграция выглядит так (все в одной транзакции):

BEGIN;

ALTER TABLE ... ADD CONSTRAINT ... CHECK (...) NOT VALID;
ALTER TABLE ... VALIDATE CONSTRAINT ...;

COMMIT;

В примере я специально указал, что оба действия выполнятся в рамках одной транзакции (многие это заметили).

Однако, когда мы используем сторонние решения для миграций (напрмер goose), мы получаем неявное повдение — миграции в одном файле будут также исполняться в рамках одной транзакции (если не укажем обратное).

В таком случае:
- Мы берем блокировку ACCESS EXCLUSIVE для добавления CONSTRAINT
- Далее эта блокировка будет удерживаться до конца работы транзакции
- Валидация нагрузки происходит долго, что приводит к тому, что транзакция превращается в долгоживующую => таблица заблокирована надолго.

Практический вывод: Делайте ADD CONSTRAINT ... NOT VALID и фиксируйте сразу (быстрый COMMIT). А VALIDATE CONSTRAINT запускайте отдельной миграции и, желательно, в спокойный период.

А чтобы не переживать насчет ваших миграций, вы можете настроить линтер: squawkhq

Cloudflare нашли редчайший баг — прямо в компиляторе Go для ARM64

Да, это не опечатка: не рантайм, не гасе condition в их коде, а чистый косяк в сгенерированном машинном коде Go. И баг был настолько редким, что проявиться он мог только в инфраструктуре масштаба Cloudflare при 84 миллионах НТТР-запросов в секунду.

Не завидую парням, сам пол недели фикшу баги в драйвере на go…

Признавайтесь, у кого так было?)

⚠️ Когда API молчит - страдает клиент

Представьте, у вас есть метод:

rpc GetUsers(GetUsersRequest) returns (GetUsersResponse);

message GetUsersRequest {
  repeated string ids = 1;
  optional string city = 2;
  int32 page = 3;
  int32 page_size = 4;
}

Вы вызываете GetUsers с 200 идентификаторами, ожидаете получить всех.
А сервер молча возвращает 100.
Без ошибки и без всякого предупреждения.

Почему? Да потому что в коде спрятан жёсткий limit = 100, о котором никто не знал.

Такие вещи ломают доверие к API.
Когда контракт неявный, клиенту остаётся только гадать: это баг, фильтр, лимит, пагинация или оптимизация?

А ещё хуже, когда такое поведение всплывает на production, и выясняется, что система теряла данные неделями (классика жанра).

💡 Хорошее API — прозрачное API.

— если есть лимиты, они должны быть явно задокументированы или возвращаться в ответе;
Часто вижу, что разработчики в gRPC не оставляют никаких комментариев в .proto - поверьте, просто спецификации НЕДОСТАТОЧНО. Клиент должен понимать не только что вызвать, но и чего ожидать.

— если что-то отфильтровано, клиент должен понимать, почему;
даже простая метка filtered=true , partial=true или список missing_ids уже делает API дружелюбнее.

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

Хорошо спроектированное и описанное API спасает от множетсво багов и недопониманий в будущем. Проводите ревью API тщательно, господа.

P.S. На мой взгляд хорошее gRPC API описано примерно так:

// Pagination - пагинация
message Pagination {
  option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_schema) = {
    json_schema: {
      noscript: "Pagination"
      denoscription: "Пагинация"
    }
  };

  // page_number - номер страницы. По умолчанию 1
  uint64 page_number = 1 [
    json_name = "page_number",
    (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_field) = {default: "1"}
  ];

  // page_size - размер страницы. По умолчанию 50
  uint64 page_size = 2 [
    json_name = "page_size",
    (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_field) = {default: "50"}
  ];
}

// PageInfo - информация о странице
message PageInfo {
  option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_schema) = {
    json_schema: {
      noscript: "PageInfo"
      denoscription: "Информация о странице"
    }
  };

  // total_count - общее кол-во записей
  uint64 total_count = 1 [json_name = "total_count"];

  // count - кол-во полученных записей на текущей странице
  uint64 count = 2 [json_name = "count"];

  // page_number - текущий номер страницы
  uint64 page_number = 3 [json_name = "page_number"];

  // page_total - общее кол-во страниц
  uint64 page_total = 4 [json_name = "page_total"];

  // page_size - размер страницы
  uint64 page_size = 5 [json_name = "page_size"];
}

А вы как считаете?