Тут балуюсь с оптимизацией сборки Next.js приложения, при сборке docker образа, отжирается 50 гигов. Самое приложение, меньше гига.

Люблю фронтенд.

После оптимизации удалось добавиться увелечение только на 6 гигабайт, после окочания джобы + 1 гиг на кэш.

#cicd #nexjs #reacr

Вышла GPT5.1. Как всегда быстрее, лучше, умнее.

Я пока сильно разницы не заметил, кроме скорости.

Так же появилась кастомизация «стиля» ответа.

#openai #chatgpt #gpt5.1

Сижу готовлюсь к выступлению, остался час.

Буду рассказывать о GitOps, и как методология может помочь аналитикам и командам.

#analystdays #ad21

Сейчас слушаю доклад, как внедрили ИИ в подбор.

Там прям классная и очень правдивая мысль — за последние 5 лет вопросы, которые можно найти в статье на Хабре «Топ 50 вопросов к системному аналитику», как задавали, так и задают.

Первый вопрос, который задают, — чем отличается POST от GET? Конечно же вопрос на позицию не меньше Senior.

#собесы

Ехал на закрытие Analyst Days 21 с полной уверенностью, что хорошо выступил, но совсем не ожидал что мой доклад займет третье место. 🥉

Понадобилось три конференции и два года что бы повторить результат весны 2023 (AD 19)

Это мотивируют выступать еще больше, ещё качественней (благо есть куда расти).

Докладчики-победители Analyst Days #21
🥇1 место — Аня Гурова
🥈2 место — Аня Казаченко
🥉3 место — Лев Немировский

Языку Go сегодня 16 лет. Из,наверное, самых классных функций последнего времени - это новый сборщик Green Tea, который пока в бета.

Причем не верится в такую дату, честно говоря. Помню как смеялись, когда требование в вакансиях было 5 лет, а языку 2-3 года. Прям себя сильно олдом почувствовал.

#go #golang

Завтра понедельник, а это повод размяться немного перед рабочей неделей.

Представьте, что вам надо сделать контракт, OpenAPI. Для трех сущностей - Страна, Регион, Город.


Как бы вы сделали? Какие ручки у вас получились? И почему?

Свой вариант завтра вечером опубликую.

Сегодня понедельник — самое время выдать свой вариант по странам, регионам, городам.

Сначала, конечно, тянет сделать что-то такое:

`/countries/{id}/regions/{id}/cities/{id}`

Красиво же! Иерархично! Прямо видно структуру данных!
Но это ощущение проходит примерно через пять минут — как только начинаешь думать о реальном использовании.

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

Во-вторых, фильтрация потом превращается в цирк:
если тебе нужны «все города страны с населением больше 100к и без метро», то в лесенке из URL это выглядит максимально странно.

Поэтому финальный, рабочий и жизненный вариант у меня такой:

1. Каноничные ресурсы — плоские

GET /countries
GET /countries/{country_id}

GET /regions
GET /regions/{region_id}

GET /cities
GET /cities/{city_id}

Каждая сущность доступна сама по себе. Это убирает лишние проверки, упрощает клиентам жизнь и делает API устойчивым.

2. Отношения — через коллекции

GET /countries/{country_id}/regions
GET /regions/{region_id}/cities
GET /countries/{country_id}/cities

Каждая сущность доступна сама по себе. Это убирает лишние проверки, упрощает клиентам
Это удобно для навигации — но не обязательно для CRUD.

3. Фильтры — через параметры

```
GET /cities?country_id=1&population_gt=100000
GET /cities?region_id=42&has_metro=true
```

Это гибче, чище и не ломается от каждого нового поля.

Но в общем — вот так.

Главное случайно не зайти на другой сайт.