Обновить

Бэкенд

Сначала показывать
Порог рейтинга

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

В прошлый раз я рассказал про Голема — кодинг-агента в 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

Теги:
+1
Комментарии0

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

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

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

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

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

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

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

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

Теги:
+2
Комментарии0

Логистическая регрессия на 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

Теги:
+1
Комментарии0

Как я научил 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.

Теги:
-9
Комментарии2

Статья #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. Пройдешь раздел по коллекциям без единого мата — налью тебе Мальбека. А пока — иди, переделывай.

Теги:
-12
Комментарии1

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

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

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

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

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

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

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

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

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

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

Теги:
+4
Комментарии4

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

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

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

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

Теги:
+4
Комментарии0

Написал небольшой микросервис на 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
Там будет подробное описание транзакции, включая все "входы" и "выходы", количество отправленных монет, комиссию сети, заплаченную отправителем и так далее.

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

Теги:
+3
Комментарии0

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

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

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

Теги:
0
Комментарии0
Москва - СУБД Digital Q.DataBase
Москва - СУБД Digital Q.DataBase

🚨 Мы в 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

Теги:
Всего голосов 4: ↑4 и ↓0+4
Комментарии0

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

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

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

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

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

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

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

https://github.com/ComputerPers/YandexMusic_to_AppleMusic

Теги:
Всего голосов 2: ↑2 и ↓0+2
Комментарии4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Теги:
Всего голосов 2: ↑1 и ↓1+2
Комментарии2

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

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

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

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

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

https://gitverse.ru/anarchic/licensedog

Теги:
Всего голосов 3: ↑2 и ↓1+2
Комментарии3

Ближайшие события

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

Теги:
Всего голосов 5: ↑3 и ↓2+2
Комментарии0

Краткая версия Интервью Гвидо ван Роуссума с core-разработчиком Python Бреттом Кэнноном:

import textwrap


def print_bubble(text: str, name: str, side="left"):
    wrapped = textwrap.wrap(text, width=45)
    max_len = max(len(line) for line in wrapped)
    width = max_len + 2

    if side == "left":
        indent = ""
        tail = "╲|"
        bottom = indent + "╰" + "─" * (width - 1) + tail
    else:
        indent = " " * 52
        tail = "|/"
        bottom = indent + tail + "─" * (width - 1) + "╯"

    print(indent + "╭" + "─" * width + "╮")
    print(indent + name)
    for line in wrapped:
        print(indent + "│ " + line.ljust(max_len) + " │")
    print(bottom)


dialog = [
    ("left", "Гвидо:", "Как ты нашёл Python?"),
    ("right", "Бретт:", "Искал язык для ООП в 2000-м, попробовал Python — сразу зашло."),
    ("left", "Гвидо:", "И что дальше?"),
    ("right", "Бретт:", "Через Python Cookbook попал в сообщество, потом в python-dev."),
    ("left", "Гвидо:", "Быстро втянулся?"),
    ("right", "Бретт:", "Да, начал писать обзоры, отправлять патчи, добавил strptime, стал core-разработчиком в 2003."),
    ("left", "Гвидо:", "Каким было сообщество тогда?"),
    ("right", "Бретт:", "Небольшим, всё держалось на энтузиастах."),
    ("left", "Гвидо:", "А позже?"),
    ("right", "Бретт:", "Участвовал в переходе на Python 3, развитии стандартной библиотеки и управлении."),
    ("left", "Гвидо:", "Самый сложный момент?"),
    ("right", "Бретт:", "Твой уход и кризис управления помогли перейти к другой модели руководства."),
    ("left", "Гвидо:", "В итоге?"),
    ("right", "Бретт:", "Случайно попробовал Python и стал ключевым участником проекта."),
]

print("Нажимайте ENTER (или пробел) для следующего сообщения.\n")

for side, name, text in dialog:
    input()
    print_bubble(text, name, side)

print("\n Вы прочитали краткую версию. Подробнее читайте на https://habr.com/ru/articles/1017676/ \n")
Теги:
Всего голосов 5: ↑4 и ↓1+3
Комментарии1

Хотели бы побыть в шкуре чиновника-технофоба, блокирующего в интернете всё, до чего могу дотянуться пухленькие ручки?

Мне показалось это хорошая идея для первоапрельской Telegram Mini App и я написал PZDNET — где гильдии чиновников и общественников борются за максимальное количество блокировок в интернете.

Никакого здравого смысла. Только холодный расчет и нездоровая жажда «регулирования».

Приходи, интернет сам себя не заблокирует.

Теги:
Всего голосов 9: ↑5 и ↓4+2
Комментарии0
Digital Q.DataBase 18 - SSRS
Digital Q.DataBase 18 - SSRS

🔹 Всем привет. Сегодня хочу рассказать Вам о том, как мы склонировали у себя один из самых "прикладных" сервисов из поставки Microsoft SQL Server.

➡️ Речь пойдет об SQL Server Reporting Services (SSRS) - механизме, который позволяет получать разнообразные отчеты, запрашивая их построение по API или по расписанию.

➡️ Представьте ситуацию: Вы использовали Microsoft SQL Server и у Вас было несколько сотен разнообразных отчетов, что ранее строились на основе данных в Ваших БД. И тут импортозамещение! Надо переходить на российское решение из Реестра Минцифры.
Для замены СУБД самый легкий вариант такого перехода - Digital Q.DataBase. Мастер переноса БД поможет перенести данные, Мастер сравнения БД проверит корректность переноса, Digital Q.CDC обеспечит синхронизацию данных в обеих СУБД, что позволит сократить до нескольких минут сам момент перехода.
Но что делать с сотнями отчётов, что привыкли получать Ваши пользователи?

Оставить как есть, пусть строятся при помощи зарубежного инструмента?
Вряд-ли это приемлемо. Какое-то очень кусочное импортозамещение получается!

Переписать на другом инструменте? Даже из расчета по дню на отчёт это сотни человеко-дней "ручного труда", а потом тестирование, выгребание ошибок, восстановление порушенных интеграций (построение некоторых отчетов могло запрашиваться извне, через API). Тоже так себе вариант!

➡️ Мы предлагаем более живую альтернативу: воспользоваться нашей реинкарнацией службы отчетов. 

На приложенных скриншотах два отчёта. Один построен в оригинальном инструменте, второй у нас. Как видите, они очень похожи, более того построены по одному и тому же шаблону, что был перенесен из оригинала к нам при замене СУБД.

Внешний вид и API - все сохранено. Как говорят наши "заокеанские партнеры" - настоящий "drop-in replacement" (безшовная замена одного инструмента другим).
Именно так и должно выглядеть хорошо проработанное импортозамещение.

Благодарю за внимание к этому посту!

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

Теги:
Всего голосов 7: ↑6 и ↓1+5
Комментарии0

Cursor или Harvi Code: какой ИИ для кодинга в 2026 году реально работает в России без VPN и головной боли с платежами

В 2026 году почти каждый разработчик в России стоит перед одним и тем же выбором: хочешь мощный ИИ, который реально ускоряет разработку, или хочешь, чтобы всё работало просто, без посредников и ежемесячных нервов с оплатой.

Cursor — это сейчас, пожалуй, самый продвинутый AI-редактор на рынке. По сути, это VS Code, в который встроили настоящий искусственный интеллект на стероидах. Composer позволяет одной командой править сразу десяток файлов, агент понимает весь проект, хорошо справляется с рефакторингом, поиском багов и даже архитектурными решениями. Качество кода от Claude Sonnet 4.5 или свежих GPT часто вызывает искреннее «вау».

Но есть большая ложка дёгтя. Cursor — американский продукт, и российские карты он не принимает. Чтобы купить подписку Pro, приходится либо использовать виртуальные карты через крипту, либо платить посредникам (Oplatym и подобные), либо покупать готовые аккаунты (что рискованно). Сам редактор после оплаты работает без VPN, но первоначальная настройка оплаты — это отдельный квест. Бесплатная версия быстро упирается в лимиты, особенно если активно юзаешь мощные модели.

Harvi Code Первый в России AI кодинг-агент. Российский ответ на все эти заморочки. Это полноценный AI-агент прямо внутри VS Code. Пишешь задачу в чате — он генерит код, рефакторит, фиксит баги, работает с контекстом всего проекта. Не тормозит, контекст держит хорошо, интерфейс привычный.

Самое приятное — модели на любой бюджет. Есть топовые (Claude Sonnet 4.5, GPT-5.4 и другие). А главное — очень низкая стоимость токенов. Для каждой модели есть свой коэффициент стоимости. Для большинства повседневных задач их хватает с головой, и можно вообще почти не тратить деньги. Оплата — российскими картами или СБП, без всяких посредников и VPN.

Коротко по делу:

  • Если тебе нужен мощный multi-file agent и ты готов один раз настроить оплату через проверенного посредника — бери Cursor. Он до сих пор в топе по возможностям.

  • Если хочешь работать стабильно, без лишних телодвижений и не думать каждый месяц про «как бы оплатить» — Harvi Code сейчас выглядит гораздо практичнее для российского разработчика.

А вы как сейчас кодите с ИИ? Пробовали оба варианта? Что в итоге оставили в основном редакторе? Пишите в комментариях, интересно почитать реальный опыт.

Теги:
Всего голосов 4: ↑0 и ↓4-4
Комментарии0

Я не разработчик, но сделал Telegram-бота для Hysteria 2

Я не программист, языков не знаю, я небольшой руководитель отдела в айти, неплохо знаю серверную архитектуру. Но у меня была простая боль: недавно завел для себя и родни сервер Hysteria 2, до этого было с VLESS на сервере и устал каждый раз руками править YAML, когда нужно:

добавить или удалить пользователя, выдать доступ, проверить статус, перезапустить сервис и при этом ничего не сломать

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

Сразу честно: делал с помощью LLM. Статью эту тоже, кстати. Панаму я приготовил. Цель статьи не выпендреж, а просто рассказать о боте, что бы его уже нормальные разработчики посмотрели переделали, может на основе его сделали адекватный продукт

Почему не SSH?

Да, можно через SSH, nano и systemctl. Но когда делаешь это регулярно — растёт шанс ошибки.

Хотелось проще: открыть Telegram, нажать пару кнопок и выдать доступ без ручного редактирования config.yaml.

Веб-панель тоже рассматривал, но бот оказался быстрее и удобнее “на ходу”.

Что умел MVP

Минимум, который был нужен:

/status — жив ли сервис /users — список пользователей add / delete / enable / disable генерация hy2:// ссылки /logs — последние логи /restart — перезапуск с подтверждением

Звучит просто. Пока не думаешь о безопасности.

Главная проблема: бот ≠ root

Первая (и плохая) идея — дать боту полный доступ: пусть сам правит YAML, дергает systemctl и читает логи.

Это почти готовый root-доступ извне.

Я сделал иначе:

Бот — это интерфейс, не исполнитель.

Бот хранит данные (SQLite) Все опасные действия делает отдельный helper на сервере Helper: генерирует YAML делает backup валидирует только потом применяет и перезапускает

В sudoers разрешены только конкретные команды helper-а, а не shell.

Безопасность (без этого смысла нет)

Сделал максимально жёстко:

deny by default доступ только по Telegram user ID (не username) админ-команды только в личке в группах — никаких опасных действий delete/apply/restart — через подтверждение audit log: кто, когда и что сделал

Бот должен быть параноидальным, а не “удобным для всех”.

Грабли, на которые я наступил

  1. Права на конфиг permission denied на /etc/hysteria/config.yaml — лечится не перезапуском, а нормальными правами.

  2. Cert/key Один неправильный путь — сервис не стартует. Плюс легко сломать доступ к privkey.pem.

  3. URI и userpass

hy2:// и hysteria2:// формат username:password спецсимволы нужно кодировать

Очень легко получить “почти рабочую” ссылку.

  1. Клиенты На iOS импорт URI иногда работает хуже, чем ручной ввод.

  2. OpenWrt + sing-box Сначала “не работает”, потом “работает, но не так”, и только после настройки DNS и роутинга — всё нормально.

Что получилось

Сейчас это нормальный админ-пульт:

управляю доступами из Telegram не трогаю YAML руками опасные действия подтверждаются и главное — нет полного root-доступа у бота

Удобство появилось без видимых дыры в безопасности.

Про LLM

Да, я использовал нейронку. Но это не “магическая кнопка”.

Без продуманной архитектуры (права, границы, apply, валидация, rollback) получилась бы просто опасная игрушка.

Что бы сделал иначе сразу делал бы helper-архитектуру добавил бы audit log с самого начала разделил бы read и write операции по правам сделал бы preflight-проверки перед apply

Что дальше

Планирую:

улучшить UX, возможно добавить лёгкую веб-панель, оставить Telegram, как быстрый пульт

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

P.S. Это моя первая статья, готов ко всем минусам, хейту и так далее. Единственная цель этого поста - рассказать о боте и дать его в народ

ссылка не репу https://github.com/Ramisya4ka/hysteria-bot-manager (внутри есть очень подробное Readme)

Теги:
Всего голосов 4: ↑4 и ↓0+5
Комментарии0

Какой user-side подход выбрать?

Может многие и не задавались вопросом, но я думаю это интересная тема, которую можно прояснить.

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

В моём случае каждая строчка кода дорога. Работаю я в одиночку.

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

Телеграм-бот

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

Да и ещё в добавок в Russian Federation начали блокировать тг, поэтому пользоваться им приходится с костылями, а бот перестал стабильно работать.

Вывод: тг-бот - для простого функционала, но довольно нестабилен и ограничен функционал

Хотя, есть mini-app, но в их подробности я не вдавался.

Веб-приложение

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

Но есть проблема. Допустим, человек пользуется чем-то на постоянной основе и хочет максимально быструю и адаптированную работу. Он будет постоянно заходить в браузер и копаться во вкладках? Или лучше тогда выбрать мобильное приложение?

Мобильное приложение

Наверное самый сложный и трудозатратный, но по моему мнению в нынешнее время самый перспективный вариант. Да, по сравнению с веб-собратом работать оно будет не везде, а только на мобилке, при том на определённой (IOS или Android).

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

Небольшая сводка

Для чего бот: для простого функционала. Можно использовать как небольшое дополнение к какой-либо инфраструктуре. Этот подход наименее трудозатратен.

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

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

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

PS: интересно узнать чужое мнение, так как возможно здесь много субъективщины.

Теги:
Рейтинг0
Комментарии0