Мы в Beeline Cloud рассказывали о сборках для желающих погрузиться в тему селф-хостинга. Рассмотрим еще несколько примечательных проектов в данной области.
Привет, Хабр! 27 ноября обсудили на Golang Meetup Wildberries & Russ, как строить надёжную бизнес-логику, оптимизировать работу с памятью и проектировать масштабируемую событийную архитектуру. В статье делимся записями докладов.
Команда Python for Devs подготовила перевод статьи о новых фоновых задачах в Django 6.0. Фреймворк наконец получил встроенный API для очередей задач — но без воркеров, так что чудес пока ждать рано. Автор показывает, зачем это обновление всё равно важно, как оно работает внутри и что можно построить поверх него уже сегодня.
Привет, Хабр! Я Дмитрий Смотров, тружусь бэкендером в Astra Linux в команде продукта ACM — микросервисной системе, разворачиваемой на клиентских мощностях. Мы позволяем удаленно управлять клиентской инфраструктурой. Сначала я разрабатывал функциональность снятия инвентаризации и удаленного выполнения команд установки и удаления ПО, но в один момент моя жизнь резко изменилась. На проекте возникла необходимость в функциональности красивой и настраиваемой отчетности, в чем я увидел возможность проверить себя в новой для себя области. Я вызвался разобраться и помочь продукту стать еще лучше.
Под катом расскажу о том, с какими трудностями столкнулся в процессе, как я их решал и что в итоге получилось. Приятного чтения :-)
Меня зовут Андрей Серебрянский, и я люблю Apache Kafka. И гарантии доставки exactly once. И рассказывать обо всём этом на конференциях. Пять лет я строил платформы потоковой обработки данных в финтехе, а теперь вместе с командой работаю над YDB Topics: частью YDB (СУБД Яндекса), которая заменяет Apache Kafka в роли брокера сообщений. СУБД Яндекса уже некоторое время поддерживает Apache Kafka API. Недавно мы расширили этот API, добавив поддержку Kafka-транзакций.
Но наличия транзакций в брокере сообщений недостаточно для получения гарантий exactly once. Чтобы неудачно зависший или перезагрузившийся сервер не привёл к дублированию или потере сообщений, нужно хорошо понимать, как именно работают транзакции в брокерах сообщений вообще и в Apache Kafka в частности.
Эта статья будет полезна начинающим разработчикам и тем, кто хочет освежить знания или разобраться в тонкостях exactly once обработки данных с помощью YDB Topics или других брокеров сообщений.
Осторожно, спойлеры! Не читайте, пока хотите решить задачу самостоятельно.
В этой челлендж-серии статей, начатой с прошлогоднего эвента, попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2025.
Возможно, SQL не самый подходящий для этого язык, зато мы рассмотрим его различные возможности, о которых вы могли и не подозревать.
Команда Go for Devs подготовила перевод статьи о том, как работает первый этап компиляции Go — сканер. Автор подробно показывает, как исходный код превращается в поток токенов, что происходит с каждым символом и откуда берётся автоматическая вставка точек с запятой. Если вы хотите понять Go «изнутри» — начинайте именно отсюда.
Пол года назад у меня была простая идея: большинство соискателей проводят часы на hh.ru, листая сотни вакансий, но редко находят то, что идеально подходит. Чем больше вакансий, тем дольше поиск. Тем выше риск упустить что-то стоящее. Я подумал — а что если создать платформу, которая использует ИИ для умного анализа?
Так родилась идея HHBro.ru — приложение, которое не просто показывает вакансии с hh.ru, а анализирует каждую через призму вашего резюме и находит идеальные совпадения.
Это был проект, который я разрабатывал в одиночку — от концепции до деплоя. Без финансирования, без команды, только идеи и энтузиазм.
Важное замечание: Как соло-проект без инвестиций, HHBro развивается медленнее, чем хотелось бы. Есть недостатки и баги, есть фичи, которые я хочу добавить, но на которые пока нет времени. Но я полон идей и энтузиазма! В этой статье я поделюсь не только тем, что получилось, но и тем, как я подошел к разработке, какие решения принимал, и как планирую развивать проект дальше.
TL;DR
Мы собрали рабочего ИИ‑агента‑разработчика, который сам анализирует задачи в Jira, уточняет детали, пишет код, запускает сборку, фиксит ошибки, создаёт MR в GitLab и отправляет его человеку на ревью. Он работает параллельно на нескольких задачах, благодаря чему суммарное время выполнения пачки задач падает почти втрое. Команда избавилась от рутины, а скорость разработки выросла без расширения штата.
Использовали: Ollama + Qwen3 Coder, PostgreSQL, Docker, GitLab/Jira API, систему строгих JSON‑действий.
Столкнулись с контекстом, «галлюцинациями», GPU и самовольными правками кода — всё решаемо архитектурой.
ИИ не заменяет разработчиков, он снимает тупую монотонную работу и экономит деньги.
Привет, Хабр. С вами снова Вадим.
В прошлом посте я рассказывал, как написал AI‑бота Аврора, который ищет вакансии вместо меня.
Статья залетела, и к нам пришли первые 100 тестеров. И тут началось веселье.
Представьте: вы нажимаете кнопку «Найти работу», а бот молчит. 10 секунд, 20 секунд. Вы думаете: «Сломалось» и жмете кнопку еще 5 раз.
А на самом деле бот не сломался. Он просто «ушел на кухню готовить».
В этой статье расскажу, как мы переписали архитектуру с «однорукого повара» на «промышленный конвейер», зачем использовали SQL вместо модного Redis и как наша скорость стала нашей проблемой.
Если вы разработчик — найдете тут код про SKIP LOCKED.
Если вы ищете работу — поймете, почему наш бот теперь быстрее, чем пальцы любого рекрутера.
Недавно купил книгу «Кванты. Как волшебники от математики заработали миллиарды и чуть не обрушили фондовый рынок», которую её автор Скотт Паттерсон написал ещё в 2010 году. Книга издана на русском языке в 2014, но я познакомился с ней только недавно и понял что в книге очень хорошо расписана хронология развития алгоритмической торговли и чем она заканчивалась. Спойлер: ничем хорошим в итоге, но в моменте очень выгодно для участников.
Решил сделать статью по мотивам книги — краткую выжимку идей о том, какими алгоритмами и в какое время зарабатывались деньги. Первая часть этой статьи — на основе этой книги, а вторая этой часть — на основе открытых данных из интернета.
Причём странная деталь — заказал книгу на обычном маркетплейсе, но книга шла из‑за рубежа и пришла даже без указания тиража — то есть какая‑то условно китайская копия — раньше с такими не сталкивался.
Зачем сразу тянуть в проект тяжёлую артиллерию типа Elasticsearch, если нужно просто поискать по тексту статей? Ведь у PostgreSQL есть свой, встроенный полнотекстовый поиск. Многие о нём забывают.
Недавно мне в очередной раз довелось читать молодым коллегам курс по языку Python. По самому языку мы прошлись и начали говорить о паттернах проектирования и их реализации. В итоге захотелось мне превратить материалы курса в несколько статей. Это первая. Статья получилась большая, сначала я планировал рассказать в одном тексте обо всех порождающих паттернах, но, поглядев на размер, передумал и разбил историю на части.
Первым паттерном, который мы рассмотрим, разумеется, станет синглетон. Как только его по-русски не называют, кстати. Синглтон. Синглетон. Наконец, ОДИНОЧКА. Не, ну вы представляете, ОДИНОЧКА?! Покажите мне живого человека, который так говорит? Я ни одного за 30 лет использования паттернов GoF не видел.
Казалось бы, что о нём можно сказать разумного, доброго, вечного, а главное — нового? Паттерн довольно тривиальный, всего лишь способ создать объект класса, который нельзя инстанцировать более одного раза, а потом использовать этот объект везде, где нужно (часто в совсем разных местах). И довольно спорный во многих случаях. Особенно в Python, где я обычно не советую его использовать так, как в C++.
«Зачем беспокоиться о том, чего не произойдёт?»
Этот вопрос председателя КГБ Чаркова из сериала «Чернобыль» может стать хорошей эпитафией для сотен закончившихся катастрофами проектов по разработке, модернизации и эксплуатации ПО. Провалы в этой сфере происходят везде, они не зависят от страны и размеров компаний. Они случаются в коммерческих, некоммерческих и государственных организациях, вне зависимости от статуса и репутации.
За двадцать лет мировые траты на ИТ в расчёте на доллары 2025 года увеличились втрое, с 1,7 триллиона до 5,6 триллиона, и продолжают расти. Несмотря на дополнительные траты, показатели успеха за эти годы повысились незначительно. Из-за этого потери бизнесов и общества становятся всё серьёзнее, ведь ПО проникает во всё большее количество аспектов нашей жизни.
Не стоит и надеяться на то, что ИИ-помощники и кодинг-копилоты вскоре обеспечат успех крупномасштабных ИТ-проектов. В обозримом будущем возможности ИИ в контролировании миллиона аспектов и компромиссов системной разработки, управления проектами, финансами и бизнесом останутся сильно ограниченными. Лишь немногие ИТ-проекты демонстрируют примеры рационального принятия решений, на которых может учиться ИИ. Как знают люди, занимающиеся разработкой ПО, такие проекты и так страдают от галлюцинаций и иллюзий руководства, поэтому ИИ лишь усугубит ситуацию.
Как я говорил двадцать лет назад, причинами краха проектов часто становятся крах человеческого воображения, нереалистичные или несформулированные цели проектов, неспособность справиться со сложностью проекта или неучтённые риски. Всё это регулярно приводит к ИТ-катастрофам и сегодня. Существует и множество других причин, часть которых выявил глава кафедры бизнес-технологий Школы бизнеса Университета Виллановы Стефен Андриоле; его диаграмма, показанная ниже, впервые была опубликована в Forbes в 2021 году. Было бы крайне удивительно обнаружить проект, потерпевший крах каким-то уникальным, незадокументированным ранее образом, потому что подавляющее большинство таких неудач вызваны вполне преодолимыми факторами, за десятки лет изложенными в сотнях отчётов, научных исследований, технических книг и учебников по управлению. Читая литературу о таких катастрофах, часто испытываешь дежавю.
Сегодня стартовал Advent of Code 2025!
Осторожно, спойлеры! Не читайте, пока хотите решить задачу самостоятельно.
В этой челлендж-серии статей, начатой с прошлогоднего эвента, попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2025.
Возможно, SQL не самый подходящий для этого язык, зато мы рассмотрим его различные возможности, о которых вы могли и не подозревать.
Всем привет! Меня зовут Сергей, я занимаюсь backend-разработкой уже больше 15 лет, а последние несколько лет разрабатываю объектное хранилище для ваших файлов в компании Сloud.ru. Мы пишем свое собственное распределенное хранилище данных с нуля.
В этой статье я хочу рассказать про грабли, которые часто вижу в проектах и на которые периодически наступаю сам. Рассказываю, как их избежать, чтобы сделать ваши сервисы более стабильными и предсказуемыми. Статья будет полезна junior- и middle-разработчикам.
На написание статьи меня сподвигла статья «Pydantic V2: Почему dataclasses вам больше не нужны» и меткий комментарий:
«Спасибо за статью, но мне кажется Вы учите детей плохому. »
Давайте попробуем разобраться, почему и датаклассы хороши, и pydantic V2 прекрасен, а вместе – они становятся ещё лучше.
В первой части было показано общее поведение configuration cache на простых примерах. Теперь перейдем в плоскость практики: рассмотрим с какими проблемами сталкиваются разработчики плагинов и как их можно решать.
Configuration cache должен был стать обязательным в Gradle 9, но требования, в итоге, смягчили. В любом случае, рано или поздно он станет обязательным и авторам плагинов придется его поддерживать.
Я не могу сказать что документация по кэшу плохая, но в ней очень мало практики: каждому разработчику приходится тратить время на эксперементы. Так вот, под катом те самые недостающие эксперименты - как работает gradle configuration cache на примерах.
О вечном — о разумной длине строк кода. Мы недавно встретили ошибку, которая одновременно демонстрирует, чем плох "код-колбаса", "эффект последний строки" и последствия неудачного copy-paste.