Бодрый кодер

Гоферы есть? Я для генерации OpenAPI всегда использовал oapi-codegen, но у него до сих пор нет поддержки 3.1, странное структура json на выходе и так по мелочи. Но из плюсов - стабильный и понятный. Тут натолкнулся на ogen, выглядит очень интересно. Кто-то пользовался?

У меня много лет была одна любимая табличка — считал в ней зарплату с премиями, бонусами, всем этим счастьем. Простая, понятная, проверенная временем. И вот сегодня поймал себя на мысли: она вообще не учитывает прогрессивный налог. Который, на секундочку, уже пару лет как есть. Дальше всё по классике. Любой нормальный человек открыл бы формулу, поправил пару строк и пошёл дальше. Но нет. Я решил чуть заоверинжинерить и вместо фикса таблички сделал небольшой сервис — https://paycalc.ru/ Сейчас там две вещи, которые мне самому постоянно нужны: — посчитать зарплату с учётом налогов — сравнить две зарплаты, например текущую и оффер Особенно второе оказалось полезным. Потому что “+50к к офферу” на бумаге и “сколько реально придёт на руки” — это иногда две разные истории. В итоге задача на 10 минут превратилась в отдельный сервис. Но зато теперь не надо каждый раз лезть в таблицу и вспоминать, где я там что сломал в формулах 🙂

У меня много лет существует красивая табличка, которая позволяет считать ЗП - с учетом премий. Но сегодня осознал что она у меня без прогрессивного налога, который в РФ уже пару лет как существует. Я как любой нормальный программист, вместо того что бы просто поменять формулу, решил заоверинжинерить - запилил простой сервисы https://paycalc.ru/. У него всего две простые функции: 1. Считать зарплату и налог 2. 2

До постов руки не доходят, в субботу ожидаем нагрузку и выдержим или нет - будет понятно через пару дней. Пока поделюсь новым не большим отркрытием - https://www.trae.ai. Это более дешевая альтернатива Cursor, выглядит очень интересно, буду тестировать на следующей недели более активно, пока однозначно нравится.

Всю прекрасную половину - с праздником!

А у меня есть iOS-ники в подписчиках? Сейчас многие стали предлагать вместо скачивания приложения в AppStore (потому что там больше приложения нет) - установка pwa. И естественно оно у всех разного качества. У Авито и Тбанк я в целом разницы особо не вижу. Что реально не может дать PWA, по сравнению с нативкой, кроме макро оптимизаций? Сходу я могу подумать про Bluetooth/NFC доступ. А что еще? На сколько сейчас вообще актуально создавать нативное приложение, когда основной продукт - вебовский и мобилка дополнение?

Сегодня в чате менторов было довольно горячее обсуждение одной статьи на Хабре: https://habr.com/ru/articles/1003434/ Если коротко, история такая. Парень нанял себе «супер-синьора» с зарплатой около 300к, а потом постепенно выяснилось, что практически все задачи тот решает с помощью ИИ. Причём не просто использует его как инструмент, а фактически полностью на него полагается. Поймать за руку долго не получалось, пока ему не дали одну задачу с конкретным алгоритмом. Алгоритм действительно существует, но для этой задачи он вообще не подходит. ИИ сгенерировал решение, разработчик его принес, и в этот момент стало понятно, что человек даже не задумался, применим ли этот алгоритм к задаче. И вот у меня после этого обсуждения появилось несколько мыслей. Во-первых, мне кажется, уже пора спокойно принять факт, что ИИ пришёл надолго. Это не временный хайп и не очередной модный инструмент, который через год исчезнет. Его будут использовать всё больше и больше: разработчики, аналитики, тестировщики, DevOps — вообще все, кто работает с информацией. Поэтому если в компании это не запрещено требованиями безопасности или внутренними правилами, то использование ИИ — абсолютно нормальная история. По сути это просто ещё один инструмент. Когда-то мы гуглили решения, копировали куски кода со StackOverflow, читали документацию, спрашивали коллег. Теперь к этому списку добавился ИИ. Во-вторых, интересный момент связан с оплатой труда. Формально сотруднику платят за рабочие часы. Но по факту компания всегда ожидает, что за эти часы сотрудник будет приносить определённое количество пользы. И вот здесь важно не столько то, сколько часов человек сидит за компьютером, сколько то, какой результат получается на выходе. И если сотрудник использует какие-то инструменты, которые позволяют ему делать больше с тем же уровнем качества, это скорее хорошо, чем плохо. В этом смысле ИИ ничем принципиально не отличается от хорошей IDE, автодополнения, линтеров или CI. Это просто инструмент, который может повысить продуктивность. Сам факт того, что разработчик использует ИИ, на мой взгляд, не означает, что ему нужно платить меньше. Но при этом подразумевается другая вещь: если у тебя появился мощный инструмент, ты потенциально можешь создавать больше ценности за то же время. И это нормально. Проблема, как мне кажется, не в ИИ. Проблема в том, понимает ли человек то, что делает. Если разработчик использует ИИ как ускоритель — формулирует задачу, проверяет результат, понимает архитектуру и ограничения, — то это просто хороший рабочий инструмент. Но если ИИ превращается в костыль, когда человек просто копирует ответы и даже не пытается разобраться, тогда рано или поздно это может привести к серьезным последствиям. ИИ может написать код. Но он не несёт ответственность за то, что этот код делает. И в какой-то момент всегда возникает ситуация, где нужно не просто получить ответ, а понять, почему решение работает именно так. Мне кажется, в ближайшие пару лет на собеседованиях появится новый стандартный вопрос. Не «используете ли вы ИИ», а «как именно вы его используете в работе и как он повышает вашу продуктивность». И хороший ответ на этот вопрос будет скорее плюсом, чем минусом.

Одна фич, которая вышла в Go 1.26 b и мне зашла - slog.NewMultiHandler. Логи можно отправлять сразу в несколько каналов, да еще и по условиям.

package main

import (
    "log/slog"
    "os"
)

func main() {
    // Handler для консоли - только INFO и выше
    consoleHandler := slog.NewTextHandler(os.Stdout, &slog.HandlerOptions{
        Level: slog.LevelInfo,
    })

    // Handler для файла - DEBUG и выше
    file, _ := os.OpenFile("app.log", os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0644)
    defer file.Close()

    fileHandler := slog.NewJSONHandler(file, &slog.HandlerOptions{
        Level: slog.LevelDebug,
    })

    // Объединяем оба Handler'а
    multi := slog.NewMultiHandler(consoleHandler, fileHandler)
    logger := slog.New(multi)

    // DEBUG попадёт только в файл
    logger.Debug("starting application", "config", "/etc/app.conf")

    // INFO попадёт и в консоль, и в файл
    logger.Info("server started", "port", 8080)

    // ERROR попадёт в оба места
    logger.Error("connection failed", "host", "db.example.com")
}

GPT-5.3 поъехала, Instant. Теперь меньше снисхождения, лучше поиск и быстрей отвечает. Убрали всю воду, которая генерировала тонны бесполезных токеновю

Давно не заходил в Grafana Cloud и, если честно, был уверен, что они в основном продолжают развиваться вокруг OSS-экосистемы. Но сейчас посмотрел на их облачный продукт — и он реально оказался очень удобным. Особенно с точки зрения быстрого подключения и анализа всех слоев приложения: метрики, трейсы, логи — всё поднимается довольно быстро и сразу дает нормальную картину происходящего. Поймал себя на мысли, что, скорее всего, все свои пет-проекты всё-таки закину в Kubernetes-кластер и обмажу полной наблюдаемостью: метрики + трейсы + логи. Что бы потестить на реальных данных В бесплатной версии Grafana Cloud, дают: • хранение данных — 14 дней • около 500 часов нагрузки в месяц Для тех, кто просто хочет посмотреть интерфейс и потыкать руками — у них есть демо: https://play.grafana.org/ В целом приятно удивился тому, насколько всё стало проще и удобнее. Хочу все это в OSS :)

Оказывается в k6, если использовать официальное приложение, можно записывать все действия пользователя в браузере и автоматически сгенерировать тест для нагрузочного тестирования. Если кто не знает - k6 сейчас наверное один из самых популярных инструментов для нагрузочного тестирования. Раньше я тупо ручками собирал все URL и писал скрипт.

Ответ короче очень простой - что бы узнать баланс, надо отправить смс на номер 10010 с текстом cxhf.

Я очень люблю китайские интерфейсы. Как вы думаете, где здесь посмотреть баланс мобильного телефона (это приложение одного из операторов)?

Ради эксперимента решил сделать UI для auth-портала. Отдельный домен, изолированная история — чтобы не зависеть от конкретного бэкенда и IdP. Чисто фронт, UX, формы, состояния, ошибки. Давно руками в интерфейсы не лез — стало интересно, как сейчас «правильно». Пошёл смотреть, что происходит на рынке. И внезапно — пароли почти никто уже не любит. Самый популярный подход сейчас — passwordless. Без «придумайте сложный пароль из 12 символов, включая спецсимволы и кровь единорога». Если вход по телефону — OTP код. Если по email — magic link. Нажал в письме — ты внутри. Я сначала скептически относился к магической ссылке. Казалось, что это дольше и неудобнее. Но если честно — потери времени нет вообще. Особенно если сессия живёт 30–60 дней и не выкидывает тебя каждую неделю. Зато: – нет восстановления пароля – нет «неверный пароль» – нет хранения хэшей – меньше точек атаки – проще UX Интересно, какие крупные сервисы вы знаете, которые полностью отказались от паролей? Удобно вам так заходить? Или всё-таки пароль + менеджер паролей спокойнее?

Мне неожиданно понравился ZITADEL, как продукт для реализации IAM / CIAM. Работает в целом быстро, но больше покорили:

Кажется, многие уже знают (я вроде писал), что в прошлом году MinIO фактически перестал быть нормальным open-source — репозиторий теперь в архиве. Если вы используете S3 у облачного провайдера — вообще никаких проблем. Но если у вас своё железо и MinIO стоял как основное хранилище — вот тут становится интересно. По сути главная альтернатива MinIO — это Ceph. Но Ceph — очень тяжёлая штука. Он сделан под огромные объёмы и большие файлы. Если у вас S3 используется только под картинки, аватары и статику — будете страдать. Слишком сложный и тяжёлый для таких задач. Я решил посмотреть, какие вообще есть альтернативы. Они есть, но почти все довольно молодые. SeaweedFS — лицензия Apache, разворачивается легко, всё достаточно понятно. Наверное сейчас основной кандидат на замену MinIO, если не нужно огромное и сложное файловое хранилище. Но до требований крупных компаний местами не дотягивает. Garage — французский проект, интересный по архитектуре, но S3 поддержка не полная и лицензия AGPL (для многих это стоп). Скорее вариант для небольших проектов и экспериментов. RustFS — тоже лицензия Apache, свежий проект на Rust. Честно, понравился больше всех: выглядит аккуратно и быстрым. Но почти нет больших внедрений, поэтому ставить в прод можно, но придётся быть первопроходцем. В целом сейчас картина простая. Если у вас облако — можно не переживать. Если своя инфраструктура — придётся выбирать и тестировать. Лично я пока больше всего смотрю в сторону SeaweedFS и RustFS. MinIO был слишком удобным, чтобы его исчезновение прошло совсем безболезненно 🙂

Есть такая штука — статические генераторы сайтов. Чаще всего их используют для простых корпоративных сайтов, блогов и пользовательской документации. Базово всё просто: есть шаблон, папки = разделы, .md файлы = страницы. Когда в прошлом году понадобился персональный сайт, взял Hugo. Из функций нужна была только шаблонизация и деплой через git. Смотрел разные варианты, но выбрал Hugo из-за скорости и знакомого языка. В этом году делал новую версию сайта и решил ещё раз посмотреть альтернативы. Попробовал Astro. В прошлый раз меня отпугнуло, что там можно писать на React/Vue — казалось, что на JS-фреймворке нормальную скорость не выжать. Ошибался. Все компоненты написал на React, но по скорости почти не отличается от простого HTML-сайта на Hugo без JS. На мобильном открывается <0.5 сек, на десктопе <1 сек. PageSpeed Insights на десктопе даёт идеальные показатели. На телефоне почему-то показал хуже, хотя в браузере при тестах было 100/100 и на мобиле, и на десктопе. Фактической скоростью, я приятно удивлен.

Готово, в паблике - https://github.com/nemirlev/yc-terraform Качество кода мне не нравится, как будет время, буду вычищять.