Бэкенд

ChatGPT на собесе: инструкция по провалу

На прошлой неделе провёл два техсобеса на Kotlin-разработчика и в очередной раз словил абсолютный кринж: кандидаты пытаются проходить интервью с ChatGPT, и делают это максимально тупо.

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

*️⃣ Стук клавиш. Я задаю вопрос, человек задумчиво молчит, зато в микрофон радостно начинает лупить механическая клавиатура. Напокупали себе кастомных механик с громкими свитчами, а теперь палятся на первом же промпте.

*️⃣ Светомузыка на лице. Кандидат сидит в полутёмной комнате, и ровно после моего вопроса его лицо внезапно озаряется белым светом - открылась спасительная вкладка браузера.

*️⃣ Бегающий взгляд. Прямо на камере видно, как глаза двигаются влево-вправо, считывая строчки сгенерированного текста.

Как выглядит сам диалог с таким «киборгом»?

Например, прошу объяснить, что такое ACID. Кандидат сначала зависает на 5–7 секунд. Мнётся, выдаёт невнятное мычание в духе «ну… это короче про базы данных и надежность».

А потом в него вселяется Википедия. Он внезапным дикторским голосом начинает чеканить:

ACID — это Atomicity, Consistency, Isolation, Durability…

и выдает все расшифровки книжным языком. Переход от “не могу связать два слова” к “я лектор по базам данных” занимает ровно одну загрузку ответа.

И это не моя личная паранойя. В Huntflow я всё чаще вижу в карточках от других интервьюеров пометки: “кажется, использует ИИ”, “вероятно, зачитывает ответы с экрана”.

Как я на это реагирую в моменте? Не рублю с плеча и не устраиваю сцен. Сначала даю шанс, пытаюсь помочь наводящими вопросами. Но когда понимаю, что человек на том конце провода не рассуждает, а просто работает кожаным интерфейсом между мной и LLM,  я перестаю его вытаскивать. Просто прогоняю по оставшимся вопросам в x2 скорости и сворачиваю звонок.

Знаете, в чём главная ирония? Я вообще не из лагеря морализаторов: обманул на собесе - в ад.

Если ты как-то схитрил, прошёл собес, а потом вывез испытательный срок и нормально тащишь задачи - да тока вперед. Важно то, как ты работаешь, а не как попал в компанию. Разраба в бою проверить очень легко.

Кринж в другом. Взрослые инженеры ведут себя как напуганные школьники, неумело списывающие у доски. Собеседование — это не экзамен, это попытка найти себе адекватного коллегу. А по итогу получается просто трата времени.

Дебаж 🐞с ноги в TG, VK и Дзен

Иллюзия автоматизации: почему API не гарантирует легкую миграцию

Мы в Хайстекс любим API-интеграции, это стандарт и архитектурная основа нашего продукта. Когда нужно мигрировать сотни машин в зрелые публичные облака, API — оптимальный выбор. Но у любого вендора СРК и миграции есть бэклог с кейсами, где API превращается из помощника в серьезную издержку.

Этот пост — для инженеров и архитекторов, которые занимаются миграциями ВМ и регулярно упираются в стоимость и сроки поддержки API-интеграций под каждую новую целевую площадку.

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

В таких сценариях команда тратит ресурсы на борьбу с интерфейсом платформы вместо того, чтобы просто переносить данные. Именно поэтому архитектура должна уметь работать «в поле», не дожидаясь ответа от управляющего контура облака.

Если API целевой среды — это нестабильная переменная, логично вывести её за скобки. Так появилась архитектура Direct2Target (D2T). Это метод, позволяющий сделать целевую сторону миграции полностью воспроизводимой без зависимости от API конкретного облака. В сценарии D2T целевая ВМ-«болванка» подготавливается заранее — вручную или с помощью ваших привычных скриптов («инфраструктура как код»). Решение не тратит время на попытки договориться с облаком о создании ресурсов, а сразу приступает к главной задаче: доставке данных напрямую в диски подготовленной машины.

D2T — не замена API-подходу, это «план Б». Функция позволяет развернуть машину в условиях архитектурных ограничений целевой площадки, не дожидаясь доработок со стороны провайдера.

О том, как реализовать миграцию «в обход» API, почему это в 5 раз быстрее и как перестать превращать переезд в вечную разработку — поговорим на вебинаре 29 апреля в 11:00 (МСК). Регистрация по ссылке.

В программе:

• Прикладные сценарии: когда D2T эффективнее классической интеграции по времени и ресурсам.

• Технологический стек: как обеспечить воспроизводимость миграции на любых площадках без зависимости от API.

• Live Demo: подготовим таргет-ВМ и запустим миграцию в прямом эфире.

Приносите в комментарии баги облачных API, из-за которых сроки проектов улетали в бесконечность. Обсудим, как D2T мог бы упростить вам жизнь в тех кейсах. 

🧠 Разбираемся, как устроены in-memory БД: пишем MemifyDB с нуля.

Redis быстр, но не всегда удобен. SAP HANA — мощь, но ценник…
А что, если заглянуть под капот и создать свою enterprise in-memory СУБД?
Не чёрный ящик, а полностью прозрачную, современную, open-source — и при этом готовую к высоким нагрузкам. Разбираемся как это работает!

Знакомьтесь — MemifyDB.

📌 Что это будет?
Настоящая in-memory система уровня enterprise, в которой мы разберёмся до винтика:

• живёт в RAM, отвечает за микросекунды;

• сохраняет данные на диск (RDB + WAL) — никакой потери после ребута;

• реплицируется и шардируется «из коробки»;

• поддерживает транзакции (не хуже MULTI/EXEC, но с возможным rollback);

• и при этом не просит продать почку за лицензию.

Весь код — open source, все решения — с объяснениями.

🛠 Технический фундамент (выбираем стек вместе)
Платформа — JVM. Я сейчас выбираю между Java 21 (Loom) и Scala 3 (ZIO / Akka).

• Сеть: Netty или виртуальные потоки — посмотрим на бенчмарках.

• Память: off-heap + собственный slab-аллокатор на ByteBuffer. GC не мешает, фрагментация под контролем.

• Конкурентность: Lock-Free структуры данных, чтобы не блокировать потоки.

• Протокол: RESP-совместимость — redis-cli сможет общаться с нами.

🗺 Дорожная карта: что и когда разберём

1. Ядро: потокобезопасное KV-хранилище в памяти. Как работают LRU и TTL?

2. Persistence: снапшоты и WAL. Как не потерять данные при краше?

3. Сеть: пишем TCP-сервер. Netty vs Loom — кто быстрее?

4. Транзакции: реализуем MULTI/EXEC, WATCH. Нужен ли MVCC?

5. Репликация и Raft: как достичь консенсуса в распределённой системе?

Каждый этап — открытый код, пост с разбором, грабли и профит.

🤔 Зачем я это делаю публично?
Во‑первых, разобраться самому и дать шанс разобраться другим.
Во‑вторых, фидбек сообщества ловит ошибки на берегу.
В‑третьих, хочется сделать реально полезный инструмент, а не очередной pet‑project.

💬 Вопрос к залу:
Какой стек предпочтительнее для enterprise in‑memory БД — Java 21 + Loom или Scala + ZIO/Akka?
Какие фичи вы бы добавили в дорожную карту?
Пишите в комментариях — лучшие идеи уйдут в реализацию!

👉 Подписывайтесь, чтобы не пропустить:

• глубокий разбор off‑heap аллокатора;

• сравнение моделей конкурентности на реальных бенчмарках;

• историю о том, как одна строка unsafe кода валила прод три дня.

Господа фрилансеры!

20 лет я жил фрилансом. Искал заказы на fl.ru, договаривался на почасовую оплату, и спокойно работал в своем темпе. Поднимал сложные проекты, немного тимлидил, рос в навыках и т.п. Казалось, так будет всегда. Начинал я с PHP 3, каши из кода, вперемешку с html. Потом писал самопальные фреймворки, ускоряющие разработку. Со временем код становился чище, я освоил yii, yii2, Laravel втянулся в solid, научился в high load и т.п

Работа никогда не была моим средством самореализации. Это просто некая "дань этому миру", чтобы обслуживать тело. Я переехал в небольшой домик у озера в лесу, разбил огород, завёл хозяйство, тренировался по 4 часа в день, а работе уделял вечера.

Так вышло, что последние 7 лет я полностью перешел на постоянных заказчиков. Просто раз в пару месяцев выставлял им счет, исходя из 1000-1500р в час потраченного времени - всех все устраивало, мне платили без лишних вопросов, доверяли на слово. Но ничто не вечно в этом мире - старые проекты себя исчерпали, и пора искать новую работу. И тут я обнаружил, что старый подход больше не работает. Fl почти умер, заказов не найти. На hh - по 500-1000 откликов к каждой вакансии. Да и не хочу я работать с 9 до 18.

Появились какие-то новые биржи, основанные на попроектной оплате (типа, вставить виджет за 1к рублей). Но так полную занятость, обеспечивающую ежемесячный доход хотя бы в 150к, не найти. Ведь на поиск заказа, обсуждение деталей, получение доступов, вкуривание в новый код и т.п. уходит целый день, и, получается, что фактическая стоимость часа - 100-200р в час. А разработку сложных проектов не оценить сразу - в процессе всегда задачи разрастаются в несколько раз.

Что делать? Как в нынешних реалиях найти работу простому кодеру, привыкшему к свободному графику и обладающему огромным "жизненным опытом"?) Чтобы просто можно было заполнить весь рабочий месяц, работать по 4-6 часов в день, без беготни по задачкам на 1-2к рублей.

P.S. в качестве пруфа, что история не выдуманная, ссылка на профиль https://www.fl.ru/users/namo/portfolio/

Как устроен компилятор?

Мы каждый день пишем код, но часто воспринимаем компилятор как "чёрный ящик". Сегодня приоткроем завесу тайны над работой компилятора, расскажем о его жизненном цикле и объясним, на каком этапе в игру вступают деревья.

Под капотом скрывается целый конвейер, который включает в себя построение дерева, оптимизацию и генерацию кода. Мы разобрали все этапы на конкретных примерах и написали статью для тех, кто хочет понять, как работает компилятор.

Как выбрать направление в веб-разработке?

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

Если вы уже определились с направлением — можно переходить к практике. Например, заглянуть на Хабр Карьеру и выбрать полезный курс с понятной структурой и фокусом на реальные навыки.

Собрали для вас учебные программы по каждому из направлений:

— Frontend-разработка. Создание интерфейсов и всего, что пользователь видит и с чем взаимодействует в браузере.

— Backend-разработка. Разработка серверной части и работа с базами данных.

— Fullstack-разработка.  Сочетание frontend и backend: подойдёт тем, кто уже освоил одно направление и хочет расширить навыки.

→ Выбирайте направление и погнали учиться 🚀

Голем: как в нём устроен анализ кода

В прошлый раз я рассказал про Голема — кодинг-агента в Telegram. Сейчас хочу показать, что у него под капотом. А именно — как работает анализ кода.

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

Нужно было что-то менять.

Гибридный анализ: четыре утилиты вместо одной LLM

Теперь перед тем, как отдать код модели, его прогоняют четыре статических анализатора:

bandit, ruff, semgrep, pip_audit = await asyncio.gather(
    run_bandit(project_dir),      # безопасность
    run_ruff(project_dir),        # стиль и баги
    run_semgrep(project_dir),     # глубокий анализ
    run_pip_audit(project_dir)    # зависимости
)

Каждая утилита отвечает за свою область:

• Bandit ищет уязвимости безопасности: SQL-инъекции, использование eval(), хардкод паролей.

• Ruff проверяет стиль и очевидные ошибки: неиспользуемые импорты, синтаксис, голые except.

• Semgrep находит сложные паттерны: XSS, утечки данных, опасную десериализацию.

• pip-audit сверяет зависимости с базой CVE и сообщает о дырявых пакетах.

Все четыре запускаются параллельно через asyncio.gather. На проекте среднего размера это занимает 10-15 секунд вместо 40-50 при последовательном запуске.

LLM получает только проблемные строки

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

Теперь всё иначе. Анализаторы возвращают конкретные проблемные строки, и модель получает только их с контекстом в 3-4 строки вокруг:

# main.py:42 — Bandit HIGH
query = f"SELECT * FROM users WHERE id = {user_input}"  # SQL-инъекция

Результат:

• Расход токенов сократился в 10 раз.

• Галлюцинации про «незавершённый код» исчезли полностью.

• Анализ работает одинаково быстро на проекте из 10 файлов и из 500.

Асинхронный режим

ZIP-архивы и GitHub-репозитории анализируются в фоне. Пользователь отправляет файл и сразу получает ответ «анализ запущен», а результат приходит отдельным сообщением через минуту-две. Бот не висит, можно продолжать с ним работать.

asyncio.create_task(
    _analyze_directory_async(context, temp_dir, source, llm, user_id)
)
await update.message.reply_text("🔍 Анализ запущен в фоне")

Что дальше

Сейчас Голем умеет анализировать только Python-проекты. В ближайших планах:

• Поддержка JavaScript/TypeScript (ESLint + npm audit)

• Поддержка Go (golangci-lint + govulncheck)

• Поддержка Rust (clipp +cargo-audit )

Также хочу добавить команду /fix — автоматическое исправление проблем, которые находит Ruff. Часть ошибок можно починить без участия человека, и Голем будет делать это сам.

Попробовать

Бот живёт в Telegram: @Golem666bot
Там же можно посмотреть другие проекты и следить за разработкой: @system_develope

13 демо-уроков апреля для разработчиков: от REST API и SQL до Bun, C++ и микросервисов

Привет, Хабр. Эти уроки проведут преподаватели курсов Отус в преддверии старта новых потоков. На них можно узнать о формате обучения, пообщаться с экспертами и заодно закрыть пробелы в знаниях по интересующей теме. Участие бесплатное. Присоединяйтесь!

15 апреля, среда:

• 18:00 — Основы протокола HTTP

• 20:00 — OpenAPI + Spring

• 20:00 — Локализация текстов в Symfony: от статических переводов к динамическим данным из базы

• 20:00 — Основы проектирования бизнес-логики в микросервисной архитектуре

16 апреля, четверг:

• 20:00 — Облегчённые (Slim) примитивы синхронизации

• 20:00 — Архитектура ИИ-сервисов для High-Load и Low-Latency инференса

21 апреля, вторник:

• 20:00 — Функции в SQL: вычисления и переиспользование кода

• 20:00 — Производительность кода на примере алгоритмов сортировки

22 апреля, среда:

• 20:00 — Bun + ИИ: создаём быстрый сервер нового поколения на JavaScript (Bun — современная среда выполнения JavaScript; ИИ — искусственный интеллект)

• 20:00 — Symfony Workflow: конечный автомат для реализации бизнес-логики

23 апреля, четверг:

• 20:00 — Многопоточность в C++: как писать быстрые и безопасные приложения

• 20:00 — Паттерны RESTful API. Как проектировать удобные, масштабируемые и гибкие API?

29 апреля, среда:

• 20:00 — PHP-разработчик. Продвинутый уровень

Логистическая регрессия на MNIST (0 vs 1) на PHP: простой пример

Если вам хочется не просто читать про машинное обучение, а попробовать сами – вот хороший учебный кейс.

Разбираем классическую задачу: бинарная классификация цифр (0 vs 1) на датасете MNIST (12 666 обучающих и 2 116 тестовых примеров) с помощью логистической регрессии, обученной через gradient descent. Всего 5 эпох – но результат всё равно шокирующе высокий. :)

Что тут интересного:

• можно наглядно посмотреть, как модель работает с изображениями (в виде векторов)

• становится понятно, где линейные модели начинают "ломаться"

• можно посмотреть код чистой реализации на PHP и самому покопаться в коде
  – точность: 99.91%

• и сравнить с более практичным вариантом на RubixML
  – точность: 99.95%

Это хороший переход от теории к практике: без заумных вещей, с понятной математикой и кодом.

Разбор:
https://apphp.gitbook.io/ai-for-php-developers/chast-iii.-klassifikaciya-i-veroyatnosti/logisticheskaya-regressiya/prakticheskie-keisy/mnist-binarnaya-klassifikaciya-otlichaem-0-ot-1

Примеры:
https://aiwithphp.org/books/ai-for-php-developers/examples/part-3/logistic-regression/case-0/mnist-0-1

Как я научил Telegram-бота помнить то, что LLM положено забывать

LLM по своей природе — без памяти. Каждый новый диалог с ChatGPT, Claude или DeepSeek начинается с чистого листа. Разработчики пытаются решать это костылём: запихивают в контекст последние N сообщений.

Но это не память. Это дорогое, конечное и очень прожорливое контекстное окно. Хранить всю историю — разоришься на токенах. Учить модель на лету — пока фантастика.

Поэтому я сделал по-другому.

Встречайте: настоящая долговременная память для Golem (В том виде, в каком она нужна кодинг-агенту)

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

Как это работает:

• /remember текст — Golem сохраняет факт в SQLite

• /recall — показывает все ваши заметки

• /forget ID — удаляет ненужное

Заметки автоматически подгружаются в начало каждого запроса, работают в любой сессии и переживают перезапуски бота. Никакой магии — просто грамотная архитектура.

Реальные примеры из жизни:

Вы пишете: /remember Я работаю над проектом X на Django + PostgreSQL. Никогда не предлагай MongoDB.

Через неделю спрашиваете: «Как оптимизировать запросы?» — Golem сразу учитывает стек и не несёт чушь про NoSQL.

Или: /remember Голем, не отвечай на вопросы про погоду. Это тупо.

Теперь на «какая погода?» он спокойно посылает вас в Google и не жрёт токены.

Это сильно круче простого увеличения контекста: вы сами решаете, что важно, а что — мусор.

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

→ Подписывайся на основной канал «СИСТЕМА»

Там я показываю внутреннюю кухню разработки Golem, полные архитектурные разборы и то, что обычно не выношу на Хабр.

Где потрогать бота прямо сейчас: https://t.me/Golem666bot

Пробуйте, ломайте, кидайте в комментариях:

• Какие факты вы бы хотели, чтобы бот помнил о вас?

• Каких ещё фич не хватает идеальному AI-ассистенту?

Жду ваших кейсов и идей — лучшие разберём вместе с Golem.

Статья #2: Сказ о том, как Dictionary дырявым стал, или Почему Пол «потерял» данные

Действующие лица:

• Пол (МП): Год в индустрии, MacBook в наклейках, верит в магию фреймворков и то, что .NET сам всё порешает за его спиной.

• Дядя Паша (ДП): 47 лет, архитектор старой закалки. Помнит времена, когда память выделяли дескрипторами, а за неэффективный алгоритм могли и из проекта попросить. Пьет Мальбек, смотрит на Пола как на жертву современного маркетинга.

Диалог

Пол: — Дядь Паш, ну это издевательство! .NET точно дырявый. У меня Dictionary<UserContext, string>, я туда записываю данные, а через секунду стучусь по точно такому же ключу — и KeyNotFoundException! Я дебажил три часа: поля в объекте идентичны, ID совпадает до бита. Где мои данные? Они что, протухли?

ДП: (медленно отрезает кусок эмпанады и смотрит на Пола с плохо скрываемой жалостью) — Эх, Пол... Жертва ты «быстрых курсов за 30 дней». Тебя там научили кнопки нажимать, а как шестеренки внутри хрустят — забыли. Ты мне скажи, соколик, как твой Dictionary поймет, что это один и тот же ключ, если ты ему каждый раз подсовываешь новый адрес в памяти?

Пол: — Ну как... Поля же одинаковые! UserId, TenantId. Разве он не внутрь объекта смотрит?

ДП: — Внутрь он посмотрит, когда ты его заставишь. А пока твой class UserContext — это ссылочный тип. Для рантайма твои два объекта — это как две одинаковые бутылки вина: этикетки одни, а пробки разные. Ты один объект в словарь положил, адрес его запомнил, а потом пришел с другим адресом. Для Dictionary это разные ключи. Он идет искать в другую «корзину» (bucket) и, естественно, находит там только дырку от бублика.

Пол: — И что теперь? Опять писать эту бесконечную портянку: Equals, GetHashCode, проверять на null, комбинировать поля? Это же прошлый век!

ДП: (прищуривается, делает глоток Мальбека) — Слушай сюда, инженер «счастливого будущего». В C# есть record. И это не просто «синтаксический сахар» для ленивых.

Запомни, Пол: Record — это архитектурный контракт на Value-based equality.

Когда ты пишешь public record UserContext(int Id), компилятор сам, за тебя, пишет правильный GetHashCode, который считается по значениям полей, а не по адресу. И Equals он пишет такой же. Для Dictionary два разных инстанса одного рекорда с одинаковыми данными будут одним и тем же ключом. Понимаешь? Одна строчка кода закрывает проблему, на которой вы жжете тысячи долларов облачного бюджета.

Пол: — Ладно, с «исчезновением» понятно. Но это же просто удобство, так? На производительность-то это как влияет?

ДП: (отставляет бокал и смотрит на Пола, как на человека, утверждающего, что старый фермерский пикап и болид Формулы-1 едут одинаково, потому что у обоих по четыре колеса)

— «Просто удобство»? Эх, Пол... Ты хоть раз заглядывал под капот? В реальном проекте, когда ты меняешь свой тяжелый класс на компактный record, скорость поиска в Dictionary взлетает в три раза. Минимум!

Пол: — В три раза?! Да ну, за счет чего? Это же тот же самый поиск в хэш-таблице!

ДП: — За счет инженерной точности. Компилятор генерирует для рекорда максимально эффективный код: без лишних кастов и с идеально подогнанным вычислением хэша. Твой рекорд залетает в пазы Dictionary как деталь от швейцарских часов, а твой класс — как ржавый болт, который нужно еще полчаса подпиливать напильником.

Пол: — Слушай, дядь Паш... Я ведь реально думал, что Dictionary — это просто. А тут — магия адресов, хэш-коллизии, контракты рекордов... Откуда ты всё это знаешь?

ДП: — Я это не помню, я это знаю. Потому что в наше время учили строить фундамент, а не клеить обои на гнилые стены. Современные курсы тебе этого не скажут — им выгодно, чтобы ты бесконечно покупал их «продвинутые уровни».

— Хочешь знать, где еще у тебя «дыры»? Я систему собрал. Там 15+ тысяч вопросов, которые вытрясут из тебя всю дурь и покажут, где ты реально профи, а где просто заголовки на Medium читал.

— Называется «Я хочу знать .NET». Ссылка у тебя есть — iwanttoknow.net. Пройдешь раздел по коллекциям без единого мата — налью тебе Мальбека. А пока — иди, переделывай.

Как стать 1C-программистом?

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

Чтобы вам было проще начать, мы на Хабр Карьере собрали целую витрину полезных курсов. На ней вы сможете ближе познакомиться с 1С-программированием и выбрать учебную программу, которая подходит именно вам.

А сегодня ловите подборку основных инструментов, которые стоит освоить, чтобы стать востребованным 1C-разработчиком:

— XML. Обмениваемся данными между 1С и другими системами.

— REST API. Получаем и отправляем данные в сайты, приложения, сервисы.

— HTTP. Основа для обмена между 1С и веб-сервисами.

— СКД. Строим отчёты, таблицы и аналитику без сложного программирования.

— Конфигурирование 1С. Создаем решения и меняем их в 1С под задачи бизнеса.

→ Витрина курсов с удобными фильтрами

Летние школы Яндекса 2026 — набор открыт

Этим летом — ИТ-смена в московском офисе Яндекса среди единомышленников. Внутри каждой Школы — общение с лекторами, менторами и оунерами проектов из десятков сервисов: CTO, инженеры и разработчики. За полтора месяца можно взять от Яндекса лучшее — технологии, навыки, подходы, знакомства.

• Школа бэкенд-разработки (Java и C++)

• Школа мобильной разработки (iOS и Android)

• Школа разработки интерфейсов (фронтенд и фулстек)

• Школа аналитиков-разработчиков

Теперь полностью офлайновый формат в Москве — лекции по вечерам, командная работа над проектами по выходным. Ребятам из других городов оплатят дорогу и поселят в Айтиобщагу Яндекса. Лучшие выпускники станут стажёрами уже этой осенью.

Подробнее на сайте →

Написал небольшой микросервис на FastAPI, помогающий взаимодействовать с блокчейном Litecoin для принятия платежей. Сервис напрямую подключается к любой ноде на протоколе ElectrumX.

Список нод можно взять здесь: https://1209k.com/bitcoin-eye/ele.php?chain=ltc
Либо же можно захостить свою ноду, но пока нам будет достаточно удалённой.

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

Можем взглянуть на исходный код и перейдём к обзору функционала.
https://github.com/CryptoWrapAPI/litecoin-wallet-rpc

Для начала нужно получить свой ключ к блокчейну, проще говоря, сид-фразу.
Но не каждая сид фраза подойдёт, вкратце, нужна сид фраза стандарта BIP39.
Такую сид фразу можно сгенерировать с помощью new_wallet.py

Для этого нам понадобится Python версии 3.12, потому что библиотека bip_utils пока что поддерживает только эту версию.

Mnemonic string: 
rather nasty bright aisle craft spare blood room village resource special region winter gesture despair slender tiger wall state fashion grass trophy crack monster

Master key (bytes): 865fcb279555a25bf50e2e33d37ef68b363b3eb322a68456609526f80be28a7e
Master key (extended): zprvAWgYBBk7JR8GkiSjUUwyhei9mSTEMd5ENS9xywYxsf6WLuFvq9eJjE7eFCjw3sT4AreK7cRiBgF4x8CiL5sPUhwZA3rBhFbKD1poA3iWQCg
Master key (WIF): T7ZBZxkT8ebmYHyz1vHdG9G4of2UPJm2hVky1x19kX2xtQSKKCu4

Далее для деривации (создания отдельных адресов для принятия платежей) нам понадобится extended мастер-ключ.

Отправляем его вместе с account index и address index на эндпоинт /derive (запустим тест python tests/test_derive.py)

Индексы мы можем представить как координаты адреса по оси X и Y

============================================================
TEST: Address Derivation
============================================================
XPRV: zprvAWgYBBk7JR8GkiSj...
Account index: 0
Address index: 0

Status: 200
Response:
{
  "address": "ltc1qt25zdkgj4shgyp4xw770hsjtdph6kn70zz8h06",
  "account_index": 0,
  "address_index": 0,
  "chain": "external"
}

✓ Derived address: ltc1qt25zdkgj4shgyp4xw770hsjtdph6kn70zz8h06
============================================================

Теперь этот адрес кошелька можно отправить клиенту нашего сервиса.

Чтобы проверить, поступил ли платеж, мы можем обратиться к методу get_history
https://electrumx.readthedocs.io/en/latest/protocol-methods.html#blockchain-scripthash-get-history

// В этом примере адрес начинается с tltc1 вместо ltc1 
// Потому что это testnet блокчейн :)
// Сменить testnet/mainnet можно в .env

  "tltc1qayq6ppmzztpgy354r45lkp8vjdafnhtf0yhutm": {
    "transactions": [
      {
        "tx_hash": "6803c0769c89e2cd9bbbda1d1e8715c5b11c1e69f8f9a7d46c1cd6adc2103c6a",
        "height": 4672171
      },
      {
        "tx_hash": "10bdb766e7c8a42e468862a97b10260955fafe7a0fcd219f025b4dd105077e5e",
        "height": 4672208
      }
    ],
    "count": 2,
    "timestamp": "2026-04-10T01:23:37.448442+00:00"
  }

Мы видим две транзакции, height здесь - это номер блока, в который включена транзакция, если она всё ещё находится в мемпуле (ожидает подтверждения майнерами), то мы увидим -1 или 0.

Частота блоков в Litecoin составляет ~2 минуты. То есть примерно через 2 минуты транзакция будет включена в цепочку блоков.

Узнать детали транзакции можно с помощью эндпоинта /transactions
Там будет подробное описание транзакции, включая все "входы" и "выходы", количество отправленных монет, комиссию сети, заплаченную отправителем и так далее.

На этом у меня всё, спасибо за внимание!

Подключайся ко второму онлайн-митапу MWS для Python-разработчиков 🎙️

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

Будет интересно Python-разработчикам, аналитикам и другим ИТ-специалистам, кто интересуется применением ИИ в разработке.

• 📅 Когда: 15 апреля (среда) в 15:00 по мск

• 📍 Где: онлайн 

• 👉 Зарегистрироваться

🚨 Мы в Diasoft запускаем свою серию мероприятий по СУБД.
Первое — уже 21 апреля 2026: конференция о промышленной эксплуатации и архитектуре корпоративных данных.

❯ Место проведения — Москва, Кибердом.

Я выступлю с двумя докладами:

🔥 Как мы воспроизводим функциональность MS SQL и переносим решения без переписывания
🔥 Digital Q.CDC — когда критична синхронизация изменений данных.

❯ В нашей программе намечается много интересного, в том числе обсудим:

🔹 как мы воспроизводим функциональность Oracle
🔹 практика импортозамещения и работа с высоконагруженными системами
на базе Digital Q.DataBase
🔹 Low-Code подходы и замещение зарубежных платформ
🔹 единая работа данных для OLTP и OLAP
🔹 развитие инструментов управления СУБД
🔹 как формируется СУБД за счет объединения компетенций и технологий

Наши профессионалы подробно объяснят реальные кейсы и практику внедрения.

Обязательно регистрируйтесь

https://dbd.diasoft.ru/?utm_source=andrei#programme

Увидимся! 🚀

📎 Полезные ссылки 
🔹 Бесплатное получение дистрибутива: https://database.diasoft.ru/?utm_source=andrei
🔹 Документация: доступна внутри дистрибутива 
🔹 Telegram-сообщество Digital Q.DataBase: https://t.me/dqdatabase
🔹 Канал в MAX: https://max.ru/join/orlthIssLJbjj37mjlEEYARWFyuJk5yMixLlGPISIzc

Яндекс Музыка цензирирует (замалчивает) отдельные слова в песнях и их названиях.

По этому я принял решение переехать с нее на Apple Music.

Создал по быстрому скрипт по переносу, но не просто по выгрузка-загрузке, а через мэтчинг и использовании API Apple и Yandex.

Точность миграции составила 80%. Apple удивил дедупликацией песен.

Общий алгоритм выгрузить Favorites Яндекс музыки. И через API Apple создать плейлист и добавлять найденные песни туда. Что не нашлось (у меня это составило 38 песен) выгружаются в mp3 с Яндекса и уже вы из ручками добавляете (просто папку) в Appe.

Все тестировалось и целилось на работу под OSX .

Выкладываю As Is.

https://github.com/ComputerPers/YandexMusic_to_AppleMusic

Расскажу о внедрении новой методологии в работе с AI-агентами.

Последний месяц днями и ночами погружаюсь в мультиагентскую систему - и я долго пытался всё держать в одном контуре. Разработка, контент, управление сообществом, публикации - всё через одних и тех же агентов, одни и те же файлы.

Работало? Ну, как-то работало. Но постоянно что-то ломалось, роли путались, задачи терялись. Вдобавок я использую DeepSeek chat у которого хорошая цена/качество, но малое контекстное окно.

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

Первая - чисто под разработку. TDD, оркестратор который координирует входящие, структурированная навигация. Агенты заточены только под код и архитектуру.

Вторая - под управление сообществом. Свои AI-роли с чёткими зонами ответственности, INBOX-система для передачи задач между ролями, тактическое планирование, автопубликация контента.

Между собой системы общаются через общий файл обмена данными и единую навигацию по проекту.

Что изменилось после разделения:

• Перестали ломаться цепочки. Если падает что-то в контент-пайплайне, разработка не замечает.

• Агенты стали точнее. Когда роль узкая - меньше галлюцинаций и отклонений.

• Я сам стал быстрее ориентироваться, потому что знаю куда смотреть.

• Каждая система может развиваться независимо. Обновляю логику публикаций - код в безопасности.

Несколько вещей, которые оказались критически важными на практике:

Во-первых, единый файл навигации. У меня это yaml, в котором описана полная структура проекта, все AI-роли и циклы их взаимодействия. Без этого агенты начинают «забывать» где что лежит и дублировать работу.

Во-вторых, промежуточный файл для обмена между ролями. Что-то вроде почтового ящика - одна роль оставляет результат, другая подхватывает. Простая идея, но именно она решила проблему потерянных задач.

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

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

Если интересна тема оркестрации AI-ролей — могу отдельно рассказать подробнее про архитектуру и как это всё настраивать с нуля. Дайте знать. Ну и заглядывайте в моё сообщество.

#ПолныйСтек #МультиагентскиеСистемы #AIРазработка

Если кто-то вдруг использует мой Licensedog для сбора информации о техстеке.

С сегодняшним обновлением, оно успешно разыскало в интернете и проверило все 5546 зависимости одного из наших проектов, кроме 4 мусорных внутренних библиотек.

Научил работать с Java (раньше были только Python, JS и Go). Починил целую пачку багов.

Это такой краулер, который принимает на вход SBOM (в виде CSV или cyclonedx) и потом сомневается в нем: старается обойти интернет, и на самом деле физически найти файлы с лицензиями. Выкачать их репозиториев, распаковать из архивов, или даже открыть в барузере их сайты и распарсить веб-странички. И фактически проверить на соответствие. В отчете описывает, что и откуда взялось, и почему она думает что лицензия на самом деле не MIT а GPL. На выходе получается CSV или JSONL файл, который можно отгружать безопасникам на ревью.

Исходники - как всегда, на GitVerse.

https://gitverse.ru/anarchic/licensedog

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