Промокод ушел.

С разницей в час появились новые версии Chat GPT 5.3 и Claude Opus 4.6

Быстрее, лучше. Как всегда.

Из интересного - Claude имеет контекст 1м токенов.

Chat GPT говорят может кодить часами, но Codex длиннее 10 минут не разу не видел.

Новая Claude реально тема, особенно по сравнению с режимом “auto” в Cursor.

Качество кода на таком уровне, что не хочется немедленно исправлять. Понятно есть ошибки, понятно есть приколы.

Но это был первый раз, когда Cursor пишет, запускает тесты и они работают. А не 10 итераций, я исправил, ой, не работает.

Но лимит я съел за пару часов :)

Горячий период, поэтому пишу не так часто.

Недельку решал интересную задачу. До конца ещё не решил, но уже на финишной прямой. Понадобилось описать существующую инфраструктуру в Яндекс Облаке в виде Terraform-файлов.

Как любой настоящий программист, решил найти готовое решение и даже нашёл — terraformer. Там всё прекрасно, кроме отсутствия поддержки ЯО (импорт нескольких типов ресурсов не считается). Сначала подумал, что проще будет форкнуть и дописать, но потом понял, что дольше буду разбираться в коде, чем писать самому.

Второй итерацией стало формирование всех ресурсов с параметрами в JSON через яндексовский SDK — в целом несложно. Дальше подключил LLM, чтобы по параметрам генерировались .tf. Затем запускал import, делал plan и вносил правки. Сначала всё шло неплохо: на маленьком тестовом файле всё работало. Но когда я загрузил свою инфраструктуру на 20 тысяч строк JSON — стало, конечно, больно. Каждая итерация занимала 30–50 минут: отладка и снова запуск. Я честно выгорел и решил всё же попробовать обойтись без LLM.

Третьей итерацией стала ручная генерация — тут всё стало сильно стабильнее. Но отлаживать и добавлять недостающие параметры я, конечно, запарился. Сейчас завис на стадии plan: много ошибок, пробую отладить работу LLM, чтобы она всё исправляла за меня. Посмотрим, что из этого выйдет. Если за сегодня не добью — план всё же доделаю руками и, наверное, положу проект на полку. Если получится довести до ума — выложу в open source.

Короче, это вообще смех. Clause Code пользоваться не реально, три небольших сессий и все.

Буду пробовать Codex.

Я это сделал - генератор тераформ на основе существующей инфраструктуры ЯО.

Работает без LLM.

В OpenSource выложу, пока альфа версия - надо кейсов больше накопать.

Готово, в паблике - https://github.com/nemirlev/yc-terraform

Качество кода мне не нравится, как будет время, буду вычищать

Видимо это была неделя про инфраструктуру.

Натолкнулся тут на инструмент прикольный, рисуешь диаграмму с инфраструктурой, под это генерится код terraform. Причем есть синхронизация и типо инфраструктурой управляешь через схему.

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

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

Базово всё просто: есть шаблон, папки = разделы, .md файлы = страницы.

Когда в прошлом году понадобился персональный сайт, взял Hugo.
Из функций нужна была только шаблонизация и деплой через git. Смотрел разные варианты, но выбрал Hugo из-за скорости и знакомого языка.

В этом году делал новую версию сайта и решил ещё раз посмотреть альтернативы.
Попробовал Astro. В прошлый раз меня отпугнуло, что там можно писать на React/Vue — казалось, что на JS-фреймворке нормальную скорость не выжать.

Ошибался.

Все компоненты написал на React, но по скорости почти не отличается от простого HTML-сайта на Hugo без JS.
На мобильном открывается <0.5 сек, на десктопе <1 сек.

PageSpeed Insights на десктопе даёт идеальные показатели.
На телефоне почему-то показал хуже, хотя в браузере при тестах было 100/100 и на мобиле, и на десктопе.

Фактической скоростью, я приятно удивлен.

Кажется, многие уже знают (я вроде писал), что в прошлом году MinIO фактически перестал быть нормальным open-source — репозиторий теперь в архиве.

Если вы используете S3 у облачного провайдера — вообще никаких проблем.
Но если у вас своё железо и MinIO стоял как основное хранилище — вот тут становится интересно.

По сути главная альтернатива MinIO — это Ceph.
Но Ceph — очень тяжёлая штука. Он сделан под огромные объёмы и большие файлы.
Если у вас S3 используется только под картинки, аватары и статику — будете страдать. Слишком сложный и тяжёлый для таких задач.

Я решил посмотреть, какие вообще есть альтернативы. Они есть, но почти все довольно молодые.

SeaweedFS — лицензия Apache, разворачивается легко, всё достаточно понятно. Наверное сейчас основной кандидат на замену MinIO, если не нужно огромное и сложное файловое хранилище. Но до требований крупных компаний местами не дотягивает.

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

RustFS — тоже лицензия Apache, свежий проект на Rust. Честно, понравился больше всех: выглядит аккуратно и быстрым. Но почти нет больших внедрений, поэтому ставить в прод можно, но придётся быть первопроходцем.

В целом сейчас картина простая.
Если у вас облако — можно не переживать.
Если своя инфраструктура — придётся выбирать и тестировать.

Лично я пока больше всего смотрю в сторону SeaweedFS и RustFS.
MinIO был слишком удобным, чтобы его исчезновение прошло совсем безболезненно 🙂

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

• нормальной документацией
• очень крутым интерфейсом

Как водиться OSS.

Ради эксперимента решил сделать UI для auth-портала. Отдельный домен, изолированная история — чтобы не зависеть от конкретного бэкенда и IdP. Давно руками в интерфейсы не лез — стало интересно, как сейчас «правильно».
Пошёл смотреть, что происходит на рынке. И внезапно — пароли почти никто уже не любит.

Самый популярный подход сейчас — passwordless.
Без «придумайте сложный пароль из 12 символов, включая спецсимволы и кровь единорога».

Если вход по телефону — OTP код.
Если по email — magic link. Нажал в письме — ты внутри.

Я сначала скептически относился к магической ссылке. Казалось, что это дольше и неудобнее. Но если честно — потери времени нет вообще. Особенно если сессия живёт 30–60 дней и не выкидывает тебя каждую неделю.

Зато:
– нет восстановления пароля
– нет «неверный пароль»
– нет хранения хэшей
– меньше точек атаки
– проще UX

Интересно, какие крупные сервисы вы знаете, которые полностью отказались от паролей?

Удобно вам так заходить? Или всё-таки пароль + менеджер паролей спокойнее?

Я очень люблю китайские интерфейсы.

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

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

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

Если кто не знает - k6 сейчас наверное один из самых популярных инструментов для нагрузочного тестирования.

Раньше я тупо ручками собирал все URL и писал скрипт.

🚀 GPT-5.3 подъехала — Instant.

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

Одна из фич, которая вышла в 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")
}

Сегодня в чате менторов было довольно горячее обсуждение одной статьи на Хабре:
https://habr.com/ru/articles/1003434/

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

Во-первых, мне кажется, уже пора спокойно принять факт, что ИИ пришёл надолго. Это не временный хайп и не очередной модный инструмент, который через год исчезнет. Его будут использовать всё больше и больше: разработчики, аналитики, тестировщики, DevOps — вообще все, кто работает с информацией. Поэтому если в компании это не запрещено требованиями безопасности или внутренними правилами, то использование ИИ — абсолютно нормальная история. По сути это просто ещё один инструмент. Когда-то мы гуглили решения, копировали куски кода со StackOverflow, читали документацию, спрашивали коллег. Теперь к этому списку добавился ИИ.

Во-вторых, интересный момент связан с оплатой труда. Формально сотруднику платят за рабочие часы. Но по факту компания всегда ожидает, что за эти часы сотрудник будет приносить определённое количество пользы. И вот здесь важно не столько то, сколько часов человек сидит за компьютером, сколько то, какой результат получается на выходе. И если сотрудник использует какие-то инструменты, которые позволяют ему делать больше с тем же уровнем качества, это скорее хорошо, чем плохо. В этом смысле ИИ ничем принципиально не отличается от хорошей IDE, автодополнения, линтеров или CI. Это просто инструмент, который может повысить продуктивность.
Сам факт того, что разработчик использует ИИ, на мой взгляд, не означает, что ему нужно платить меньше. Но при этом подразумевается другая вещь: если у тебя появился мощный инструмент, ты потенциально можешь создавать больше ценности за то же время. И это нормально.

Проблема, как мне кажется, не в ИИ. Проблема в том, понимает ли человек то, что делает. Если разработчик использует ИИ как ускоритель — формулирует задачу, проверяет результат, понимает архитектуру и ограничения, — то это просто хороший рабочий инструмент. Но если ИИ превращается в костыль, когда человек просто копирует ответы и даже не пытается разобраться, тогда рано или поздно это может привести к серьезным последствиям.

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

Мне кажется, в ближайшие пару лет на собеседованиях появится новый стандартный вопрос. Не «используете ли вы ИИ», а «как именно вы его используете в работе и как он повышает вашу продуктивность». И хороший ответ на этот вопрос будет скорее плюсом, чем минусом.