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

Недавно в Амстердаме прошла конференция Vue.js Amsterdam 2026 — ежегодное мероприятие, посвящённое экосистеме Vite и современным инструментам фронтенд-разработки.

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

В этой статье разберём основные анонсы конференции: Vite 8, Vite+, Void Cloud, а также обновления Vue и Nuxt.

Собрали гайд по работе с Git для новичков. 

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

Сохраняйте и пользуйтесь.

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

За это время проект заметно изменился. Если раньше это был в первую очередь детектор клонов, то 2.0.0b1 — уже скорее инструмент для контроля структурного здоровья проекта в CI.

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

В новом переводе от команды Spring АйО разберем, почему stringly-typed API со временем становятся хрупкими, чем помогают метамодели вроде Querydsl и JPA Criteria, и как новый механизм в Spring Data даёт более лёгкую и естественную альтернативу без лишней инфраструктуры сборки.

Привет, Хабр! Меня зовут Vlad, я начинающий Python‑разработчик и энтузиаст изучения языков.

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

Я решил закрыть эту боль кодом. Моя цель была амбициозной: создать Telegram‑бота, который:

1. Слушает голосовые сообщения и распознает речь без дорогих облачных API.
2. Оценивает точность произношения в процентах, сравнивая с эталоном.
3. Поддерживает живой диалог через LLM, исправляя ошибки на лету.
4. Работает быстро и экономно на слабом VPS.

В этой статье я подробно разберу архитектуру проекта, покажу, как интегрировать бинарный whisper.cpp в асинхронный aiogram 3.x, реализую алгоритм оценки речи и расскажу про управление состояниями (FSM). Под капотом — Python, нейросети и немного магии.

Устаревшая документация хуже, чем её отсутствие — она отравляет контекст LLM. Агент доверяет тому, что видит. Garbage in — garbage out, только garbage выглядит как аккуратный markdown.

Это вторая часть серии. Первая часть — «Слепое пятно LLM-разработки: контекст за пределами кода».

Поклонники вайбкодинга и агентных инструментов говорят, что стали продуктивнее в 2, в 10, а то и в 100 раз. Кто-то собрал целый браузер с нуля. Впечатляет!

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

Посмотрим на PyPI — центральный репозиторий Python-пакетов. Он большой, публичный и стабильно измеримый, так что AI-эффект должен быть хорошо заметен.

Когда процесс зависает, молчит в логах и при этом продолжает жить своей странной жизнью, обычные инструменты наблюдения быстро упираются в потолок. В таких ситуациях strace полезен не как «ещё одна консольная утилита», а как прямой способ увидеть, чем процесс занят на уровне системных вызовов: что он открывает, чего ждёт, куда пишет и на чём реально тормозит. В статье — коротко и по делу о том, как читать этот поток событий и применять strace в типовых продовых расследованиях, где дебаггер, исходники и лишние эксперименты недоступны.

Шестой выпуск еженедельных IT-новостей от OpenIDE: Java прощается с аплетами навсегда, Cursor не соблюдает лицензию Kimi, а менеджеры придумали новую единицу измерения продуктивности разработчика.

В этом руководстве мы разберёмся, как в игровом движке Ursina определять расстояние между объектами. Это очень важно для создания интерактивных игр: чтобы враги замечали игрока, предметы можно было подбирать, а интерфейс реагировал на действия пользователя.

Также приведено несколько практических примеров с подробными комментариями для начинающих:
1. Простое обнаружение стены
2. Подбор предмета (альтернатива distance)
3. Пуля и враг
4. Система подбора предметов
5. ИИ врага — зона обнаружения
6. Столкновения в Pong

На любой DevOps-конференции рано или поздно возникает один и тот же момент. Слушаешь про архитектуру, пайплайны, масштабирование, observability — всё звучит разумно и красиво. А потом в голове появляется простой вопрос: «Окей, а чем вы это всё делаете?». То есть буквально: какие инструменты стоят под капотом, как они внедрялись, где с ними было больно и где они действительно экономят время команде.

Именно для таких бесед на DevOpsConf 2026 будет отдельное пространство — продуктовая аллея!

Baidu Maps — китайский картографический сервис с собственным API. Он активно используется внутри КНР и поддерживает стандартные сценарии: отображение карты, маркеры, полигоны, кластеры.

На первый взгляд интеграция выглядит как обычно. Но при работе с реальными данными появляются отличия. Используется система координат BD-09. Мир не повторяется по долготе. Поведение геометрии отличается от Google Maps и Яндекс Карт.

Привет, я Екатерина Плаксина, фронтенд-разработчик Далее. В этой статье разберу каждую проблему отдельно и поделюсь своими решениями.

Системные программисты годами живут в вынужденном компромиссе. Когда вы пишете ОС, гипервизор или драйвер ядра, у вас два пути. Первый — чистый ассемблер (NASM/GAS), где вы имеете 100% контроль над железом, но теряете систему типов и тонете в ручном управлении памятью. Второй — использование inline asm вставок в C/C++, которые превращают ваш код в строковый «черный ящик», ломают пайплайн оптимизатора и могут взорваться в рантайме из-за ошибки в одной букве (Fragile Constraints).

Мы решили исправить эту историческую несправедливость.

Спустя месяцы безумной разработки мы представляем AsmX Raptor Engine — первый в мире конвейер компиляции, где высокоуровневая типизация и машинные инструкции живут в едином, неразрывном абстрактном синтаксическом дереве (AST).

В этой статье мы заглянем под капот нового движка и разберем:

Frontend-Backend Split: Как Pratt Parser (алгоритм сортировочной станции) и логика lookahead навсегда избавили нас от костылей C++.

Reference Collapsing и CV-квалификаторы: Почему наш тайпчекер ударит вас по рукам, если вы попытаетесь перезаписать const или неправильно примените reinterpret_cast<T>.

Kernel-Mode Orchestration: Как мы научили компилятор быть Version-Agnostic и собирать модули ядра (.ko) под любую версию Linux на лету через вытягивание метаданных из dmesg.

Operand Bridge: Трансляция абстракций в интеллектуальные инструкции железа.

Мы не пытаемся заменить C++. Мы возвращаем инженерам абсолютный контроль над каждым байтом, не лишая их мощи статического анализа. Добро пожаловать в манифест эффективности AsmX Raptor.

Язык проектировался простым, лёгким в освоении, готовым для написания сервисов с первого дня. Он мог бы таким и остаться, если бы не одна проблема. Проблема отбора.

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

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

На собеседованиях мы слышим или говорим сами, что поиск в массиве медленнее, чем в хеш-таблице. Кто-то даже вспоминает, что поиск в массиве имеет линейную сложность или O(n), а в хеш-таблице — константную O(1). Но работает ли это на практике? Что, если есть ситуации, когда поиск в массиве оказывается быстрее? Давайте не будем торопиться с выводами.

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

Сначала переехали почта и офисные приложения. Потом пришли трекеры задач, инструменты для дизайна. Даже обработка видео и трёхмерная графика теперь доступна онлайн. И вот, казалось бы, последний бастион — полноценные IDE — тоже дрогнул.
Настройки окружений, специфичные для ОС зависимости, вечные «оно работает у меня» — всё это становится анахронизмом. Удобнее открыть вкладку и просто начать работать без установки, обновлений и потерянных на настройку выходных.

Если вы тимлид, DevOps или поддерживаете живой репозиторий, то наверняка знаете эту ситуацию: нужно быстро поправить README, обновить контент для Pages или внести небольшую правку по итогам рецензирования. Изменений на несколько минут, а дальше стандартный сценарий: клонировать репозиторий, открыть IDE, дождаться индексации, вспомнить, в какой ветке вообще планировалась правка. Сам код при этом простой, а контекст задачи давно понятен.

Мы в GitVerse регулярно сталкивались с такими случаями — и как пользователи, и как команда продукта. Поэтому решили не «делать ещё одну IDE», а упростить именно этот класс задач. Об этом и расскажем в статье.

RooCode — расширение для VS Code с многоагентной системой (встроено 5 Модов: Orchestrator, Ask, Architect, Code, Debug)
Ключевые преимущества: синхронное выполнение задач (предсказуемость), гибкая настройка модов, MCP-серверы для снижения ошибок и количества запросов к LLM
Основная идея настройки: каждый Мод отвечает за свою задачу, Оркестратор распределяет работу между ними
Настройка идёт по спирали: от базовых настроек → скиллы → моды → провайдеры → итеративное улучшение

Я ненавижу писать фронтовые тесты. Не потому что я против тестирования, а потому что в какой-то момент они превращаются в бессмысленный ритуал. Особенно когда от тебя требуют покрыть ими вообще всё.

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

В каждом проекте рано или поздно появляется логика вида «этот пользователь может редактировать этот пост, а тот нет». И начинается: if ($post->getAuthor() === $currentUser) в контроллерах, в сервисах, в шаблонах. Копипаста расползается, а потом приходит новое требование — «модератор тоже может редактировать, но только в своей категории» — и вы бегаете по двадцати файлам, молясь, что ничего не забыли.

Symfony Voters — механизм, который выносит всю логику авторизации в одно место. Не аутентификации (тип кто ты?), а именно авторизации (что тебе можно?). Разберём, как это работает.