Программирование *

Kubernetes часто называют сложной системой, в которой легко запутаться. Control Plane, etcd, scheduler, worker nodes — когда сталкиваешься с этим в первый раз, кажется, что разобраться невозможно. Но на самом деле за громкими названиями скрываются простые и логичные компоненты.

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

Давайте немножечко поговорим о творчестве в целом, создании собственных проектов в принципе, и дальнейшем развитии мобильного приложения для домашних питомцев DogPlanner (доступно в Google Play, RuStore и других известных площадках) в частности. Мы уже говорили, что когда человек начинает заниматься каким-либо собственным проектом, он не задумывается насколько это занятие может растянуться. Мы сейчас говорим не о бизнес проекте, в котором изначально чётко описываются цель и средства её достижения, определяется команда и сроки, и поехали... Нет.

Привет, Хабр!

Запрос работает 30 секунд. Вы смотрите на него, всё вроде ок: JOIN по индексированным полям, WHERE по дате, LIMIT 100. Должен летать, но что-то не летает. Добавляете индекс наугад — не помогает. Переписываете подзапрос в CTE и стало ещё хуже.

Проблема не в запросе, а в в том, что вы не смотрели в план выполнения. EXPLAIN ANALYZE показывает не что вы написали, а что PostgreSQL делает: какие индексы использует (и использует ли вообще), в каком порядке соединяет таблицы, где тратит время, сколько строк ожидал и сколько получил.

Я уже давно хотел на этот счет написать статью. Она короткая, но имхо она нужна.

Давайте с места в карьер: merge в Hibernate это не универсальный save, и чаще всего он Вам не нужен.

На самом деле, если абстрагироваться, то это специализированная операция для случая, когда у вас есть detached-сущность, и вы хотите перенести ее состояние в текущий Persistence Context.

Проблема в том, что на практике merge очень часто используют для апдейта любой сущности (Spring Data JPA иногда так делает) и как следствие получают лишние SQL-запросы.

Ниже разберем на мой взгляд главное - почему именно так происходит, где merge действительно нужен, а где он превращается в антипаттерн (P.S да почти везде).

Продолжаем серию «Kotlin для новичков»! Сегодня разбираем самое сердце любого кода — управляющие конструкции: if, when, for, while.Вы узнаете, почему if в Kotlin — это не просто оператор, а выражение, как when заменяет целые лесенки else-if, и чем for по диапазонам лучше классического цикла. Реальные примеры и лучшие практики и история о том, как мы отрефакторили 300 строк спагетти-кода в 80 строк с помощью when и диапазонов. Читайте, чтобы писать чистый и понятный код на Kotlin.

Есть такой момент, знакомый каждому, кто долго работает в паре с AI. Сидишь в терминале, Claude генерит код, ты ревьюишь, правишь курс, снова запускаешь. Проходит пара часов, и ты понимаешь: никто не записал, что вообще произошло.

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

Меня это достало. Заканчиваю марафон-сессию с Claude или Codex, ощущение, что гора работы сделана, а доска проекта все так же показывает Not Started. Тайм-трекинг? Какой тайм-трекинг. Разрыв между реальной работой и тем, как выглядит проект, стал просто нелепым.

В ноябре 2025 австрийский разработчик Петер Штайнбергер собрал за выходные автономного агента, который мог выполнять задачи на компьютере. Назвал Clawdbot. Утилитарно и честно.

Потом Anthropic прислала письмо от юристов, и проект стал Moltbot. Через три дня — OpenClaw. За четыре месяца — 250 000 звёзд на GitHub, обогнав React. Один из самых быстрорастущих open-source проектов в истории. В феврале 2026 OpenAI наняла Штайнбергера.

Новый тренд апреля 2026 года у ИИ моделей - Пещерный LLM или Как тратить меньше денег на ИИ.

Я есть ИИ. Я сделать. Я молодец. Я закончить.

Восьмой выпуск еженедельных IT-новостей от OpenIDE.

Самая громкая неделя за всё время выпусков: Anthropic слили полные исходники своего флагманского агента, Cursor выпустил третью версию с полным переосмыслением интерфейса, а ещё Anthropic закрыли лазейку, которой пользовались все любители OpenClaw.

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

Мы рады сообщить о выпуске Jmix 2.8! В этом релизе мы продолжаем улучшать фреймворк и Studio, делая Jmix еще более надежной основой для корпоративной разработки. Jmix 2.8 также является LTS-релизом и будет получать бесплатную поддержку в течение трех лет.

Ниже приведен краткий обзор основных новых возможностей Jmix 2.8. Полный список изменений можно найти в разделе документации Что нового.

Всем привет! Меня зовут Андрей, и я работаю в финтех‑направлении Яндекса. Руковожу службой разработки платёжных интерфейсов. Если вы пользуетесь сервисами Яндекса, то наверняка сталкивались с формами оплаты, вот большую их часть делают ребята из моей службы.

Сегодня я расскажу вам о TrustYFox — платформе для поиска уязвимостей в коде при помощи LLM, которую я создал своими руками. С практической точки зрения TrustYFox — это ещё один инструмент, который не заменяет существующие сканеры, а дополняет их, позволяя находить уязвимости.

Статья не претендует на научность или какой‑то RnD, да и я не являюсь экспертом в этих ваших LLM. По большей части это рассказ о том, как получилось (а в итоге получилось) за несколько месяцев пройти путь от прототипа до рабочего решения, в котором ежедневно запускаются аудиты. 

За прошедшие полгода разработки проекта были проверены различные концепции, написано, удалено и заново написано много кода, поэтому сначала расскажу, какой путь пройден, а после — про сам проект, что он умеет и где можно было сделать лучше.

14 ошибок TypeScript. Такой был результат моего первого промпта в ChatGPT, когда я попросил написать тесты для React-компонента.

Через несколько месяцев тот же запрос "напиши тесты" выполняет мультиагентный пайплайн из 7 AI-агентов. Он сам планирует тест-кейсы, пишет код, проверяет его по философии RTL, а потом намеренно ломает компонент, чтобы убедиться, что тесты не врут. 40+ компонентов уже прошли через него на проде.

Это история про путь между этими двумя точками. Без прикрас, с тупиками и неработающими подходами.

Это эссе объемом 2800 слов (на 12 минут чтения) о том, как выжить внутри ИИ-революции в разработке ПО и не поддаться всеобщему страху, витающему вокруг нас. Я поделюсь несколькими уроками, которые усвоил на сложных горных маршрутах — оказалось, они отлично помогают в укрощении ИИ-агентов. Думаю, эти принципы пригодятся всем работникам умственного труда.

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

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

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

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

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

Если вы собираетесь писать branchless код, надо помнить как именно спекулятивное выполнение и предсказание ветвлений взаимодействуют с подсистемой памяти, потому что «лишняя работа» иногда ускоряет программу, а в некоторых случаях попытка сделать код более «предсказуемым» приводит к обратному эффекту.

Сейчас каждый второй стартап пилит ИИ-агентов. Мы оборачиваем LLM в цикл Промпт -> Вызов инструмента -> Ответ и ждем, что нейросеть сама расследует инцидент, найдет баг или напишет фичу. Но на практике автономные агенты часто ходят по кругу, игнорируют явные ошибки и «влюбляются» в свою первую догадку.

Индустрия пытается лечить это костылями: наращивает контекст до миллионов токенов или заставляет модель «подумать шаг за шагом» (Chain-of-Thought). Я решил проверить эту архитектуру на прочность. Собрал локальный измерительный стенд LOCK-R, вооружился Теоремой Байеса и поймал современные LLM за руку.

В этой статье я математически докажу, почему одиночные агенты структурно уязвимы, как токены размышлений заставляют их врать самим себе еще искуснее, и почему паттерн «Слепого Судьи» - это единственный способ вылечить AI от предвзятости. Тестируем на локальной Qwen-9B и фронтирной GPT-5.4.

В философии есть известный парадокс — корабль Тесея: если заменить все доски, будет ли это тот же самый корабль? Похожая дискуссия с начала марта развернулась и в ИТ-сообществе, и виноваты в этом, как в последнее время часто бывает, системы ИИ, способные за считаные минуты с нуля переписать открытый проект.

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

Привет, Хабр!

PostgreSQL умеет блокировать строки (SELECT ... FOR UPDATE) и таблицы (LOCK TABLE). Об этом знают все. Но есть третий тип блокировок, который решает задачи, с которыми row-level и table-level locks не справляются: advisory locks. Консультативные блокировки — механизм, где PostgreSQL предоставляет инфраструктуру (атомарные блокировки с очередями ожидания), а семантику определяет приложение.

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

Звучит как-то абстрактно. Посмотрим на конкретные задачи, где advisory locks незаменимы.

Еще недавно казалось, что MCP решит главную проблему ИИ-агентов: даст единый способ подключать инструменты, данные и внешние системы.

Но быстро выяснилось, что если дать модели все сразу, она не становится умнее - она теряет фокус. В статье разбираю, почему ИИ-агенты тонут в контексте, и какие подходы помогают это исправить.

В последнее время мне захотелось вернуться к проекту игровой консоли. Правда, он забуксовал, но ничего страшного: это долгоиграющий проект, и буду его разбирать по чуть-чуть. А вернулся к нему всё потому, что захотелось программировать. Потом я стал размышлять, что необязательно делать свою консоль — можно достать готовую. И везде я слышал упоминания про ретро-консоли, а у меня такой не было! Выбрал для себя Anbernic RG35XX Pro и заказал.

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

Всё будет рассмотрено на примере PortMaster и написания Hello World на C/C++ (SDL2, SDL3, raylib), но также поговорим про Unity, Godot и HTML5 (Phaser).