Бэкенд

Хабр, привет! Меня зовут Сергей Бережной, я директор по взаимодействию с разработчиками и CTO в Яндекс Практикуме. Занимаюсь обучением в IT, наблюдаю за тем, как меняется рынок, — и вижу изнутри, как эволюционирует работа с ИИ в командах разработки. В этом посте хочется порассуждать, как меняется подход к ИИ-инструментам, что это значит для начинающих программистов и какие навыки становятся критичными прямо сейчас.

Первая часть. Общие вопросы — https://habr.com/ru/articles/1047336/

Вторая часть. Установка библиотеки и пример работы с ней — https://habr.com/ru/articles/1048882/

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

Представим задачу: хайлоад-сервис гонит поток данных — логи, IP-адреса, ID пользователей, миллиарды записей в сутки. Ваша задача — посчитать количество уникальных посетителей за неделю.

Первым решением может показаться завести HashSet и кидать туда ключи, а в конце посмотреть размер. Решение неплохое, но когда речь заходит о миллиардах записей — память будет слабым местом. Один IP-адрес (4 байта) как ключ в HashSet потянет за собой накладные расходы на ноды, указатели и хеши. На практике один элемент сжирает не меньше 50–100 байт. Поток в миллиард уникальных записей потребует под сотню гигабайт оперативной памяти. Это дорого, а если инстансов десять — то просто нереально.

Но существует алгоритм, который способен решить эту задачу примерно в 1.5 килобайта памяти с погрешностью около 2%? Без хранения самих данных и гигантских кластеров. Достаточно одного прохода по потоку и пары битовых трюков — именно так и работает HyperLogLog, алгоритм родом из математической статистики, который перевернул подход к подсчёту уникальности в Big Data.

HyperLogLog используют в Redis, BigQuery, ClickHouse, Presto. В этой статье мы разберем и реализуем этот алгоритм на C, а также узнаем его предысторию.

Я взял одного и того же агента (Claude Code), менял у него ровно одну вещь — какой MCP-сервер отдаёт контекст по коду, — и гонял по 26 задачам на apache/superset. Четыре «руки»: filesystem (grep + read), graphlens (структурный граф), serena (LSP) и codegraph. Три модели (haiku / sonnet / opus), три сида — 936 прогонов.

Главный результат: вывод переворачивается в зависимости от типа задачи.

Когда у каждого репозитория есть свой Tx, код может выглядеть чисто, но атомарность всё равно сломается: один Store откатится, другой уже успеет закоммитить изменения.

В статье показан более надёжный вариант для Go-кода: репозитории остаются небольшими интерфейсами, транзакционная логика уезжает в Unit of Work, а сервис работает с готовым набором хранилищ, построенных поверх одного sql.Tx.

Запускаем большой проект? Значит, берём SOLID. Мы не раз слышали это от CPO и менеджеров продукта. О нём, кажется, знают все — и все хотят применить. Но он не спасёт масштабные проекты. Например, устойчивый умный город с решениями на основе машинного зрения на одном SOLID не построить. По канонам SOLID можно писать аккуратный код, но это не создаст архитектуру всей системы. Что на самом деле работает — подобранный под бизнес-цели набор инструментов, направленный на защиту ядра приложения.

В статье — кейс Сергея Францишкова, начальника отдела разработки «Фалькон Тех», о рабочих решениях для крупной архитектуры и внедрении GRASP + Clean Architecture.

Хотите не забывать детали диалога или то, что вас просили купить в магазине? Конечно, можно по старинке открывать блокнот в телефоне или чат в избранном и записывать все руками, но в потоке задач это неудобно. Гораздо проще надиктовать мысли голосом или записать разговор, а расшифровку доверить сервису. 

Сегодня ASR-системы нового поколения способны учитывать контекст беседы и выдавать осмысленный текст. Однако у любой медали есть обратная сторона — архитектурные ограничения. Чтобы понять, готовы ли эти модели к жизненным сценариям, мы устроили им бенчмарк на Hugging Face. Ниже — разбор того, ломается ли контекстное окно алгоритмов на длинных видеозаписях и как фоновый шум влияет на итоговое качество транскрибации.

Два месяца назад я опубликовал статью про свой pet-проект — E2EE-мессенджер.

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

И, что самое приятное, часть вещей, которые тогда были только в roadmap, за это время удалось реализовать.

Первая часть:

https://habr.com/ru/articles/1030854/

Проект:

https://github.com/vaazhen/chaos-e2ee-messenger

Вообще, за эти два месяца я понял одну простую вещь.

Написать чат оказалось не так сложно.

Написать E2EE-мессенджер — уже сложнее.

А вот понять, почему Signal делали столько лет, оказалось совсем другой историей.

Сначала кажется: ну есть же документация, есть X3DH, есть Double Ratchet, есть WebCrypto, есть статьи, есть спецификации. Осталось просто аккуратно всё собрать.

Примерно в этот момент где-то вдалеке начинает смеяться инженер из Signal.

Сразу оговорюсь: chaos messenger — это не замена Signal и не “готовый безопасный мессенджер”, а open-source pet-проект, на котором я разбираюсь, как E2EE-системы устроены изнутри.

Большинство ошибок с памятью в C++ не выглядят как ошибки. Код компилируется, тесты проходят, приложение работает неделями. А потом внезапно появляется Segmentation fault, повреждённая куча или утечка памяти, которую приходится искать часами.

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

Manticore Search 27.1.5 выпущен. Этот релиз приносит встроенные аутентификацию и авторизацию, шардированные таблицы, conversational search, более быструю сборку HNSW, улучшенные фасетирование и агрегации, а также длинный список исправлений в KNN, репликации, совместимости протоколов и других областях.

Этот пост - сводка всего, что вышло с 25.0.1 по 27.1.5.

В 1865 году британский журналист Томас Майн Рид написал роман "Всадник без головы", который послужит нам отправной точкой в вопросе о том, что же такое "безголовая" CMS и какие из них представлены сейчас на рынке веб-разработки.

Ранее в рубрике Skill of the Week мы уже разбирали Skill для Spring Data JPA. И, что предсказуемо, в комментариях нашлись те, кто увидел в нём лишнее доказательство простого тезиса: «вот видите, JPA не нужна, она слишком сложная». Аргумент понятный — у AI Agent-а с JPA действительно регулярно случаются «пожары»: ошибки в настройке связей между сущностями, странности с конфигурацией базовых типов, путаница с контекстом персистентности и разными состояниями сущности. Что характерно, ровно на этих же местах спотыкаются и живые разработчики — так что претензия скорее к технологии, чем к модели.

Раз JPA такая сложная — почему бы не взять что-нибудь попроще? Чистый JDBC многим кажется слишком низкоуровневым, и взгляд естественным образом падает на Spring Data JDBC: те же репозитории и сущности, но без прокси, lazy loading и кэша первого уровня. Технология проще — значит, и никакой Skill тут не нужен, верно?

А вот и нет. Умение AI «пользоваться» той или иной технологией зависит не столько от её когнитивной сложности, сколько от того, сколько кода с её использованием модель видела на этапе обучения. Spring Data JDBC объективно проще JPA, но кода с ней в открытом доступе на порядки меньше. Парадокс, но именно для технологий «с малым количеством кода» Skill даёт наибольший эффект: он закрывает ровно тот пробел, который модели нечем заполнить самостоятельно.

В сегодняшнем эпизоде еженедельной рубрики Skill of the Week разберёмся, как, используя Spring Data JDBC Skill, научить своего агента важным навыкам при работе со Spring Data JDBC.

Несколько месяцев назад в публичном пространстве появилась история, которую в engineering-сообществе стали называть поучительной. Команда AWS использовала внутренний AI-инструмент Kira для ускорения работы. Kira предложила джуниорам сценарий: переразверни продакшн-слой. Инженеры согласились. Следующие шесть часов весь AWS не работал. После разбора полётов компания объявила новое правило: финальный апрув на изменения, предложенные агентом, должен давать сениор-инженер.

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

История AWS точно формулирует главный вызов 2025-2026 годов: AI научился быстро писать код, но индустрия пока не научилась с такой же скоростью его доставлять, проверять и принимать решения о нём. Данные, собранные в рамках масштабного исследования State of AI4SDLC, это подтверждают.

Как мы пришли к локальному скану, фильтру Блума и переезду очереди на Kafka — и почему это всё случилось 

Привет, Хабр. Я Данил Кислов, разработчик команды хранилищ. У нас в One-cloud (внутренняя корпоративная облачная платформа) лежит собственная S3-совместимая реализация — one-object-storage. Хочу рассказать, как эволюционировал метастор S3— та часть, что отвечает за метаданные объектов: списки версий, индексы, настройки бакетов и прочую служебную мелочь.

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

Хотели избежать копирования данных, придумали свою служебную разметку, а потом обнаружили: она занимает почти столько же места, сколько сам исходный текст. Мы перестали гадать, посмотрели на реальные данные и применили простые, но эффективные подходы: числа переменной длины, отказ от double в пользу целых типов и умные if-else вместо switch. 

Итог: мы сжали разметку в 2,5 раза и при этом даже немного выиграли в скорости. Рассказываем, как знание предметной области помогло нам не усложнять код, а сделать его быстрее и легче.

Ещё несколько лет назад рефлексия считалась нормой для.NET‑приложений. Сегодня Microsoft последовательно выносит всё больше работы из runtime в этап компиляции: JSON‑сериализация, логирование, регулярные выражения, конфигурация и даже тестовые фреймворки всё чаще опираются на source generators.

Разбираемся, почему рефлексия начала сдавать позиции, где кодогенерация уже стала стандартом и что это меняет для разработчиков.NET.

Что, если мы создадим такой интерфейс в 1С, чтобы он был удобнее, чем в Excel? Да не просто удобнее — а чтобы сотрудники сказали: «Ого, это же как игра!» С вами снова Ведущий специалист модуля разработки 1С Михеев Антон. Давайте вместе сделаем эту игру идею реальностью

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

ORM — Object-Relational Mapping — Объектно-реляционное отображение — это технология, позволяющая связывать SQL-ые БД с ООП кодом. Самая известная из них — Hibernate.

Hibernate — очень красивая технология. Она формирует ощущение магии.

Ты просто создаёшь объект, — хлабысь! — он уже в базе данных. Никакого SQL, никаких соединений, никаких ResultSet. Всё происходит как будто само собой. Прелесть.

Именно поэтому отказаться от Hibernate так тяжело.

Это напоминает Кольцо Всевластия из «Властелина колец». Оно не просто давало силу — оно меняло сознание своего владельца. Оно внушало мысль, что без него уже нельзя. Что именно оно даёт власть и контроль.

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

И ты начинаешь бояться.

Бояться, что без Hibernate придётся писать бесконечный SQL. Бояться, что потеряешь контроль над данными. Бояться, что любая операция с базой превратится в мучение.

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

В новом переводе от команды Spring АйО рассмотрим решение старой проблемы в Java: полноценные классы часто слишком дорогие для памяти и процессора.

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

Project Valhalla добавляет value class. Это обычный на вид класс с полями, конструктором и методами, но без идентичности объекта. JVM сможет хранить такие данные плотнее: например, прямо внутри массива, без отдельного объекта для каждого значения.

JEP 401 планируют включить в JDK 28 как preview. Это еще не финал: value class пока может быть null, а полная поддержка быстрых generics и плотных коллекций появится позже. Но первый рабочий шаг Valhalla уже близко.

Как перестать искать подходящее расширение и написать его самому. Отличия API Firefox и Chrome Extensions.