Сергей Озеранский

Почему-то вспомнил о самом, наверное, странном фрилансе в моей жизни. И нет, это не история про то, как меня кинули Мне кажется, это был примерно 3–4 курс института. Учился я тогда в Курске, в Курском институте менеджмента, экономики и бизнеса. И вот каким-то чудом (уже даже не помню каким образом) связала меня судьба с воинской частью. Точнее — с заказчиком оттуда. Моим заказчиком оказался сотрудник воинской части, а задача звучала примерно так: Есть старый компьютер на Windows (и, кажется, там был даже не XP, вроде как Windows 2000, а может даже Windows 98), и нужно разработать десктопную программу для журналирования действий. В определенное время оператор ЭВМ должен нажимать кнопку в программе, а это действие логируется. Примерно как в Lost  (возможно я спас мир?). Так как у нас в институте Java была основным языком на ООП, я и выбрал Java. Сама задача была максимально простая. Но максимально странная И я, если честно, так и не понял, зачем вообще была нужна эта программа. Чтобы установить программу, я носил ее на флешке в воинскую часть и ставил на компьютер в каком-то кабинете. Достаточно атмосферно  сейчас бы я не пошел . К слову, если память не изменяет, писал тогда программу на Java 6 или 5 (если это был Windows 98). А у вас были странные задачи/заказы/проекты? Больше постов у меня в Telegram-канале: t.me/...kii или через поиск в Telegram по запросу «Сергей Озеранский».

На фоне очередного инцидента в GitHub, вспомнил о существовании интересного ресурса mrshu.github.io/...ses Это более подробная информация о статусе GitHub сервисов, чем та, что на официальном www.githubstatus.com Кому-то будет возможно полезно. Этот ресурс из интеренсо показывает реальный SLA. И, по моему мнению, это крайне низкий показатель uptime.is/....75 И еще, "забавный" факт damrnelson.github.io/...ime Этот график показывает Uptime GitHub до покупки их Microsoft и после. Даже не знаю какой вывод сделать Больше постов у меня в Telegram-канале: t.me/...kii или через поиск в Telegram по запросу «Сергей Озеранский».

Я очень долго ждал этой фичи в Grafana. Я люблю декларативный подход в описании конфигураций и всего остального. Изъясняться as code намного проще, полезнее и даже безопаснее, чем "накликивать" что-то в UI. И так уж сложилось, что в Grafana годами не было нативного адекватного способа работы с декларативным описанием дашбордов. Да, был экспорт в JSON, и его можно было руками сохранять в Git, но это не решало проблему (в момент, когда я искал решение) единого источника правды и не давало удобного способа описывать дашборды как код. Несколько лет назад я искал инструменты, чтобы иметь возможность описывать дашборды на том же Python, и находил что-то, но выглядело это как нечто экспериментальное и не особо активно развивающееся. Сейчас мы приблизились к решению - Grafana Foundation SDK и Git Sync. Очень интересно. Больше постов у меня в Telegram-канале: t.me/...kii или через поиск в Telegram по запросу «Сергей Озеранский».

Стало интересно "пузомеркой" (олды слово вспомнят) помериться Возьмите свой самый большой сервис и напишите в комментариях • кол-во тестов (параметризиация считается), то есть сколько тестов реально выполняется за прогон всего, всех. • время за которое прогоняются все тесты у вас на машине. Предполагаю что это в среднем MacBook Pro 2-3 летней давности. • язык на котором написан сервис Больше постов у меня в Telegram-канале: t.me/...kii или через поиск в Telegram по запросу «Сергей Озеранский».

Как мой шестилетний сын подобрался к семафорам Пекли сегодня с сыном (6 лет) пирожки с разными начинками (важно для контекста). Сели есть. Он показывает мне конфету и читает по обертке название - "Semaphor". Меня триггернуло флешбеками (*мем про собаку и Вьетнамские флешбеки*), и я говорю: "Слушай, а ведь в программировании тоже есть семафоры". Он подумал секунду и выдает: "Пап, а давай я угадаю, зачем они нужны". Я: "Давай." Далее ответ шестилетки: "Если у вас что-то идет, в программировании, чтобы это попало в нужное место назначения. И чтобы другое прошло, они ждут то, что надо, чтобы прошло. Ну, например, чтобы изюм попал в пирожок, а слива - в сырник. Чтобы не попало изюм в сырник, а слива в пирожок - вот для этого семафоры." Я сначала сказал: "Ну, сигнал от семафора ждут, да, ты прав". А потом, пока мы продолжали разговор и уже рефлексируя над его мыслями, я начал понимать, что все не так просто. Что описал ребенок. Он самостоятельно, хоть и имея уже за плечами свой первый "Hello, World!" (на Python, конечно же) за плечами, он пришел к идее, что в программе что-то может кого-то ждать. Человек приоткрыл дверь в в мир конкурентности, и он ее открыл сам. Конкретно его метафора, про изюм в пирожок и сливу в сырник, это скорее маршрутизация: каждому ингредиенту свое изделие, каждый едет своей дорогой. В коде это две независимые очереди, и они физически не пересекаются. Семафор тут формально не нужен, но интуиция "что-то должно следить, чтобы все попало куда надо" как раз семафорная по духу. Он почувствовал задачу раньше, чем научился ее точно формулировать, а это, честно говоря, и трудная задача в программировании. Где тут семафор живет по-настоящему. Я попробовал поправить: "Тут скорее, чтобы слива попала по своей очередности в пирожок в тот же, куда попадал изюм". То есть пирожок один, и изюм со сливой оба хотят в него попасть - нужна очередность, кто-то первый, кто-то ждет. Это уже ближе: один общий ресурс, несколько претендентов, правило доступа. Это мьютекс (семафор со счетчиком 1). А если развернуть дальше, то N одинаковых ресурсов и M претендентов, где M > N. Десять пирожков на столе, пятьдесят ягод рвутся внутрь. Пускаем по десять за раз, остальные ждут. Вот это уже полноценный семафор Дейкстры со счетчиком больше единицы. Классический пример в реальном коде это пул из десяти коннекшенов к базе и пятьдесят воркеров, которые эти коннекшены честно делят. Мы с ним по сути прошли путь от интуиции к определению за один разговор на кухне. Он задал верное направление, "что-то ждет, чтобы не было путаницы", а точная модель (одно место, несколько претендентов, очередность) дошла уже дальше при рассуждениях. Больше постов у меня в Telegram-канале: t.me/...kii или через поиск в Telegram по запросу «Сергей Озеранский».

Я использую в работе, каждый день Claude code. Технология LLM продуктов развивается каждый день, что я не успеваю успевать пробовать новое Накидайте, пожалуйста, ваши любимые MCP, RAG и прочее что вы используете и для чего. У меня набор сейчас крайне маленький: - context7 - Sequential Thinking Чего я хотел бы, это попробовать долговременную память и больше в агентов и скиллы. Я описываю инструкции для проектов для Claude code, но кажется этого мало Больше постов у меня в Telegram-канале: t.me/...kii или через поиск в Telegram по запросу «Сергей Озеранский».

И да, мы люди, нам тяжело удерживать эти правила в голове, это нормально. Поэтому существуют инструменты, которые нам помогают не забывать. Это такие инструменты как разного рода линтеры, чекеры и аудиторы. Они как раз и закрывают эту проблему. Вот, например, интересный инструмент для статического анализа GitHub Actions: github.com/...mor docs.zizmor.sh И в нем как раз есть правило docs.zizmor.sh/...own про тот самый dependency cooldown. Я zizmor пока не пробовал, но планирую его попробовать на github.com/...tap

В чате моего Telegram-канала интересовались полезными правилами и ссылками про то, как общаться в команде. Я собрал все воедино что у меня было и подготовил документ, который можно as is забирать в ваши процессы onboarding'а. Можно импортировать в Notion. MD универсален по сути, поэтому проблем с применением не возникнет Документ у меня в Telegram-канале: t.me/...kii или через поиск в Telegram по запросу «Сергей Озеранский».