Привет! Если мы еще не знакомы - я пишу в основном о том, как попытаться определить грейд разработчика не привлекая его на множество собеседований. Если Вы - .Net-разработчик, буду признательна, если пройдете этот опрос с небольшим заданием на кодинг. Ваши ответы позволят мне понять, правильно ли я двигаюсь и верные ли инструменты использую. Чем больше ваших ответов - тем проще будет мне) Заранее спасибо!
P. S. Прекращаю рассылку ответов, спасибо всем, кто участвовал! Но если хотите помочь исследованию - буду благодарна за новых респондентов) (можно написать в комментарии, если хотите получить результаты, но проверяйте, что доступ для сообщений открыт)
Освойте навыки, которые сейчас нужны рынку — со скидкой в апреле
Рынок меняется быстрее, чем успевают обновляться резюме. Чтобы не догонять, а двигаться наравне, важно учиться на актуальных инструментах и практиках — тех, которые уже используются в работе.
В Яндекс Практикуме мы регулярно обновляем программы: добавляем работу с нейросетями, пересматриваем стек и усиливаем практическую часть, чтобы знания можно было применять сразу, а не «когда-нибудь потом».
До 30 апреля действует скидка 15% на все курсы — можно выбрать направление и начать обучение на более выгодных условиях.
Если давно откладывали переход в новую сферу или хотели прокачать навыки — это хороший момент, чтобы начать.
Изначально строю некоторый каркас, который буду достраивать и наполнять содержанием. Это будет удобно для прототипирования.
Для работы с данными создам некоторый дополнительный уровнь абстракции, что бы не привязываться к конкретному формату данных/библиотеке и менять его налету для сравнения.
Сделано
Данные клиента будут храниться в space’ах - это будет аналог таблиц в БД. Для начала будет только key-value space что бы можно было подумать уже сейчас о WAL клиенской библиотеке для java и сетевом уровне в целом и конечно же о транзакциях.
Aximo — локальный STT API на Rust для CPU-only inference
Недавно сделал Aximo — self-hosted микросервис для speech-to-text, который можно запускать локально без облака и без зависимости от внешних SaaS.
Идея была довольно простая: хотелось собрать вменяемый STT API, который работает на CPU, поднимается как обычный сервис и при этом остается достаточно прозрачным с инженерной точки зрения.
В основе — Rust, локальный inference через Parakeet v3, HTTP API для обычной транскрибации и WebSocket-слой для realtime-сценариев. Из коробки также добавил Docker, OpenAPI и разбиение на несколько crates, чтобы проект не выглядел одноразовой демкой и оставался удобным для дальнейшего развития.
На текущем этапе это скорее крепкий MVP, чем законченный production-ready продукт, но уже сейчас сервис можно запускать локально, тестировать на своих аудиоданных и использовать как основу для дальнейших экспериментов.
Из интересного: доработал Swagger, добавив возможность отправки записи с микрофона:
Сейчас для моего движка понадобилась мультиязычность. Ну как понадобилась - на гитхабе прозрачно намекнули, что негоже одной гордой cms для ведения блога быть сугубо на русском языке.
И понеслась...
Процесс перевода движка
Это хорошо, что сейчас есть нейросети и они здорово упрощают процесс перевода. Но - по старинке все делаю вручную, каждый файл...Сначала размечаю обыкновенными дефайнами либо класс контроллера, либо шаблона, ну а потом выношу это все в соответствующие языковые папки.
Вайбкодеры меня наверняка закидали бы тапками, мол - все можно автоматизировать и перевести хоть тонну файлов за 20 минут. Но - мне это не в кайф =)
Мне не так часто в последнее время попадаются книги, где есть что-то ценное, кроме пары идей, которые автор повторяет по 10 раз разными словами. Однако книга «Проектирование веб-API» от французского разработчика веб-стандартов и публичных API Арно Лоре прямо сильно порадовала.
Фактически это такая книга-чеклист, где автор поднимает вопросы создания публичного API и делится тем, что API должно учитывать при разработке. Помимо этого он приводит свои таблички, которые использует при согласовании веб-API, и делится опытом использования инструментов в практическом поле.
Отдельно автор уделяет внимание использованию формата OpenAPI (бывший Swagger), который автор сам и развивал как активный участник OpenAPI-сообщества. Это немного иронично, ибо автор опубликовал эту книгу в 2019 году, а в 2022 году ушёл работать в Postman, которые развивают фактически конкурирующий стандарт.
В своей книге автор делится ссылками на разные ресурсы, которые помогают разрабатывать публичное API. Однако на текущий момент большая часть этих ресурсов либо закрыта, либо находится в заброшенном виде. Ибо ИИ сейчас неплохо решают вопросы «страха перед белым листом» и неплохо советуют по подходам.
В общем, кто разрабатывает публичные API, эту книгу рекомендую прочитать, чтобы понять, что вообще стоит учитывать и какие подходы существуют. Мега-полезная книга.
p.s. делитесь своими книгами и ресурсами по проектированию api, которые вам понравились
Бэкенд «тормозит», API ломаются, а архитектура трещит: уроки, которые помогают закрыть эти проблемы
У бэкенд-разработки есть неприятная особенность: большинство сложностей проявляется не в момент, когда пишется первый сервис, а позже — когда API начинает обрастать интеграциями, фоновые задачи конкурируют за ресурсы, поиск и хранилище требуют разных подходов к данным, а архитектурные решения внезапно начинают влиять на скорость разработки не меньше, чем качество кода.
В этой подборке — бесплатные демо-уроки от преподавателей-практиков про те части бэкенда, которые обычно и забирают больше всего времени в реальной работе. Это хороший способ посмотреть на чужой инженерный подход, познакомиться с экспертом, задать вопросы по своей ситуации и заодно закрыть конкретные пробелы: в API, тестировании, нагрузке, инфраструктуре, работе с данными и проектировании систем.
За последние пару недель в Кулере появилось много всего: счётчики переходов по ссылкам из постов, генератор коротких ссылок, даже страничка-визитка - вот моя: cooler.debug-leg.ru/my-link/debug-leg
Но главного: кросспостинга в VK с фото до сих пор нет. И вот почему.
Я думал, это будет просто. Создал API-ключ в группе VK, дал ему права на стену, фото, файлы, потом попросил ИИ написать код. Первая публикация прошла. Текст лёг на стену как надо. Добавил фото и сразу ошибка:
error_code: 27 — Group authorization failed: method is unavailable with group auth.
Окей. Гуглю. Оказывается, для загрузки фото нужен пользовательский токен, а не токен сообщества. Иду за ним. Получаю:
error_code: 15 — Access denied: no access to call this method with current scopes.
В предыдущих постах Разбираемся в in-memory базах и Выбираем базу я написал, что собираюсь сделать исследовательский проект по in-memory базам данных и имя ему MemifyDB. Так же выбрал направление движения: это key-value хранилище, которое потом доработаю до документо-ориентированной системы.
Теперь ключевой вопрос: как клиенты будут с ней общаться?
Протокол обмена — это мост между сервером и клиентом. От его дизайна зависит скорость, удобство и даже то, какие фичи мы сможем реализовать.
Human readable (JSON, XML and etc.)
В современных системах активно используется как для транспорта так и для хранения текстовый формат данных, а точнее json и его вариации. У этого подхода есть несколько несомненных плюсов, например:
Простота реализации: не нужно поддерживать разные типы на уровне протокола, всё передаётся как строки, а клиент сам разбирается.
Гибкость: строкой можно закодировать что угодно — число, JSON, бинарные данные.
Но у этого подхода есть обратная сторона:
❌ Нет нативной поддержки типов: Клиент сам должен сериализовать/десериализовать.
❌ Оверхед на парсинг: Каждый раз нужно преобразовывать “42” в число и обратно.
❌ Неэффективное использование памяти: Число 123456 занимает 6 байт как строка, хотя в бинарном виде — 4 или 8.
❌ Невозможность частичного обновления сложных структур: Чтобы изменить одно поле в JSON-объекте, приходится переписывать весь объект (можно конечно поспорить).
## 🎯 Наш подход: типизированные данные с рождения В MemifyDB мы пойдём другим путём. Мы будем хранить данные в памяти в типизированном виде: строки, числа, списки, хеши, документы — каждый тип со своим внутренним представлением.
И протокол обмена с клиентом должен это отражать. Мы не хотим, чтобы клиент упаковывал число в строку только потому, что так проще. Мы хотим передавать по сети те же бинарные структуры, которые лежат в памяти.
Это даст:
Типизированность Формат должен явно различать типы данных: строки, числа (разной разрядности), булевы значения, null, массивы, объекты (документы). Это позволит серверу правильно интерпретировать данные без дополнительных метаданных.
Компактность Формат не должен раздувать данные. Число 42 должно занимать 8 байт (или 4, если это int32), а не 2 символа ASCII.
Быстрая навигация Мы должны иметь возможность быстро «прыгнуть» к определённому полю документа без полного парсинга. Это важно для частичных обновлений и запросов.
Потоковость Формат должен допускать частичную отправку/приём, чтобы можно было обрабатывать большие документы по частям.
Самодостаточность Данные должны содержать всю информацию для интерпретации, но при этом не дублировать имена полей без необходимости (как в JSON).
🔍 Что дальше?
Существуют несколько бинарных: CBOR, BSON, FlatBuffer и пр. Если у вас есть опыт работы с этим форматами, пишите в комментариях какие у них есть плюсы, минусы и подводные камни.
Прежде чем погружаться в код, нужно чётко ответить на вопрос: а что именно мы строим? Этот пост — не про хардкорный кодинг, а про так называемое видение системы (system vision). Мы разберём, какие вообще бывают in-memory базы данных, чем они отличаются и почему наш путь будет таким: key-value → документная БД.
Поехали!
📚 Типы in-memory баз данных
1. Key-Value хранилища
Самый простой и быстрый вид. Данные хранятся как пары «ключ — значение», где значение — обычно строка, число или бинарный объект.
Хранят сущности (узлы) и связи между ними (рёбра). Оптимизированы для обходов графа.
Примеры: RedisGraph (модуль Redis), Neo4j (с in-memory режимом).
Сценарии: социальные сети, рекомендательные системы, сети связей.
Плюсы: эффективные запросы связей, интуитивная модель для связанных данных.
Минусы: узкая ниша, сложность шардирования.
5. Time-series БД
Специализированы для временных рядов — метрик, логов, событий. Оптимизированы для записи и запросов по временным интервалам.
Примеры: InfluxDB, TimescaleDB (in-memory части).
Сценарии: мониторинг, IoT, финансовые тикеры.
Плюсы: высокая скорость записи, сжатие старых данных, встроенные функции по времени.
Минусы: слабо подходят для произвольных данных.
…## 🧭 Наш курс: от Key-Value к документам
Для MemifyDB я выбрал путь, который кажется самым прагматичным:
Создаём ядро Key-Value Это фундамент. Мы реализуем:
потокобезопасное in-memory хранилище;
поддержку разных типов значений (строки, списки, хеши, числа);
механизмы TTL и эвикшена (LRU);
бинарный протокол, близкий к внутреннему представлению.
Key-value движок даст нам максимальную скорость и стабильность, а также позволит отточить все низкоуровневые механизмы (аллокаторы, сериализацию, сетевое взаимодействие).
Надстраиваем документный слой Поверх key-value ядра мы добавляем возможность интерпретировать значение как JSON-подобный документ:
индексация по полям;
поддержка частичного обновления;
запросы с фильтрацией по содержимому.
При этом сами документы будут храниться в key-value хранилище как обычные значения, а индексы — как дополнительные структуры (хеш-таблицы, B-деревья) в памяти.
Такая двухслойная архитектура даёт:
гибкость — можно работать и как с обычным кэшем, и как с документной БД;
производительность — key-value ядро остаётся быстрым, а документные операции добавляются без потери эффективности;
расширяемость — позже можно добавить другие модели (например, колоночные агрегаты) как отдельные слои.
Я пишу на этой полгода. За это время я опубликовал 80+ статей, собрал вокруг себя небольшую аудиторию и вложил немало сил в развитие технического комьюнити (отдельное спасибо всем, кто читает и комментирует мои материалы).
Естественным шагом для меня стало желание присоединиться к Программе поощрения авторов (ППА). По правилам Хабра, для этого нужно соответствовать ряду критериев, один из которых — наличие значка «Старожил» (выдается через 3 года после регистрации, а так же карма 50+).
И тут начался квест, который я пока не могу пройти.
Согласно моему профилю, я зарегистрирован 13 апреля 2023 года, а так же имею карму 81. Заветная дата наступила, три года прошли. Но значок в профиле так и не появился.
Я, как и положено, обратился в службу поддержки с просьбой проверить, не закрался ли баг, или, возможно, я упускаю какие-то скрытые условия. Я писал им через форму на сайте и дублировал на почту. Прошло уже достаточно времени, но в ответ — полная тишина. Ни ответа, ни привета, ни значка.
Пишу этот пост-обращение по двум причинам:
Привлечь внимание администрации Хабра. Ребята, если вы это читаете, посмотрите, пожалуйста, мой профиль. Возможно, мой тикет просто потерялся в горе других обращений.
Узнать у сообщества: сталкивался ли кто-то из авторов с подобной задержкой при получении ачивок? Выдаются ли они кроном раз в месяц, или сейчас всё работает в ручном режиме?
На прошлой неделе провёл два техсобеса на Kotlin-разработчика и в очередной раз словил абсолютный кринж: кандидаты пытаются проходить интервью с ChatGPT, и делают это максимально тупо.
Почему-то люди думают, что если они не шарят экран, то собеседующий ничего не замечает. Но вот как выглядит этот «стелс» на практике:
*️⃣ Стук клавиш. Я задаю вопрос, человек задумчиво молчит, зато в микрофон радостно начинает лупить механическая клавиатура. Напокупали себе кастомных механик с громкими свитчами, а теперь палятся на первом же промпте.
*️⃣ Светомузыка на лице. Кандидат сидит в полутёмной комнате, и ровно после моего вопроса его лицо внезапно озаряется белым светом - открылась спасительная вкладка браузера.
*️⃣ Бегающий взгляд. Прямо на камере видно, как глаза двигаются влево-вправо, считывая строчки сгенерированного текста.
Как выглядит сам диалог с таким «киборгом»?
Например, прошу объяснить, что такое ACID. Кандидат сначала зависает на 5–7 секунд. Мнётся, выдаёт невнятное мычание в духе «ну… это короче про базы данных и надежность».
А потом в него вселяется Википедия. Он внезапным дикторским голосом начинает чеканить:
ACID — это Atomicity, Consistency, Isolation, Durability…
и выдает все расшифровки книжным языком. Переход от “не могу связать два слова” к “я лектор по базам данных” занимает ровно одну загрузку ответа.
И это не моя личная паранойя. В Huntflow я всё чаще вижу в карточках от других интервьюеров пометки: “кажется, использует ИИ”, “вероятно, зачитывает ответы с экрана”.
Как я на это реагирую в моменте? Не рублю с плеча и не устраиваю сцен. Сначала даю шанс, пытаюсь помочь наводящими вопросами. Но когда понимаю, что человек на том конце провода не рассуждает, а просто работает кожаным интерфейсом между мной и LLM, я перестаю его вытаскивать. Просто прогоняю по оставшимся вопросам в x2 скорости и сворачиваю звонок.
Знаете, в чём главная ирония? Я вообще не из лагеря морализаторов: обманул на собесе - в ад.
Если ты как-то схитрил, прошёл собес, а потом вывез испытательный срок и нормально тащишь задачи - да тока вперед. Важно то, как ты работаешь, а не как попал в компанию. Разраба в бою проверить очень легко.
Кринж в другом. Взрослые инженеры ведут себя как напуганные школьники, неумело списывающие у доски. Собеседование — это не экзамен, это попытка найти себе адекватного коллегу. А по итогу получается просто трата времени.
Иллюзия автоматизации: почему 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 сможет общаться с нами.
🗺 Дорожная карта: что и когда разберём
Ядро: потокобезопасное KV-хранилище в памяти. Как работают LRU и TTL?
Persistence: снапшоты и WAL. Как не потерять данные при краше?
Сеть: пишем TCP-сервер. Netty vs Loom — кто быстрее?
Транзакции: реализуем MULTI/EXEC, WATCH. Нужен ли MVCC?
Репликация и 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-разработка. Создание интерфейсов и всего, что пользователь видит и с чем взаимодействует в браузере.
В прошлый раз я рассказал про Голема — кодинг-агента в 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++ и микросервисов
Привет, Хабр. Эти уроки проведут преподаватели курсов Отус в преддверии старта новых потоков. На них можно узнать о формате обучения, пообщаться с экспертами и заодно закрыть пробелы в знаниях по интересующей теме. Участие бесплатное. Присоединяйтесь!
Логистическая регрессия на MNIST (0 vs 1) на PHP: простой пример
Если вам хочется не просто читать про машинное обучение, а попробовать сами – вот хороший учебный кейс.
Разбираем классическую задачу: бинарная классификация цифр (0 vs 1) на датасете MNIST (12 666 обучающих и 2 116 тестовых примеров) с помощью логистической регрессии, обученной через gradient descent. Всего 5 эпох – но результат всё равно шокирующе высокий. :)
Что тут интересного:
можно наглядно посмотреть, как модель работает с изображениями (в виде векторов)
становится понятно, где линейные модели начинают "ломаться"
можно посмотреть код чистой реализации на PHP и самому покопаться в коде – точность: 99.91%
и сравнить с более практичным вариантом на RubixML – точность: 99.95%
Это хороший переход от теории к практике: без заумных вещей, с понятной математикой и кодом.
