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

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

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

Разумеется, по эго это бьёт иногда больно, и некоторые моменты вспоминать не очень приятно. Самое страшное, что я когда-либо делал — коммитил приватный ключ в публичной репо. Вот написал и мне опять стыдно. Но я осознаю, что это всё я.

Но внезапно я открыл для себя тот факт, что не во всех ошибках моя вина. То есть да, это моя голова думает код, это мои руки печатают этот код, но ошибка идёт не от меня. Ошибка заложена ещё раньше, вообще задолго до меня, а иногда даже задолго до моего рождения.

Сейчас я вам это покажу. Будет интересно, но впереди много боли. Я предупредил.

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

Меня зовут Алекс, и я мейнтейнер Symbiote.js - библиотеки для создания UI-компонентов и изоморфных приложений на самых современных веб-стандартах. Сегодня я расскажу про наше важное мажорное обновление - версию 3.x.

Статья основана на личном шестимесячном опыте автора по внедрению Cursor в процессы разработки моделей, сервисов и MLOps-процессов. Делается вывод, что роль разработчика смещается от написания кода к постановке задач, проектированию архитектуры и контролю качества, при этом ИИ берёт на себя реализацию и рутинные операции.

Пробуем написать своё приложение для удалённого рабочего стола.

Начал замечать, что на Хабре часто появляются статьи в духе «Я написал замену AnyDesk, бесплатный, но платный. И тут мне пришла мысль: а что, если попробовать самому? Хотя я не программист».

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

Всё это реальные вопросы. Но они об инструменте. О том, насколько хорош молоток — а не о том, что изменилось в строительстве.

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

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

Первое, что нужно понять: процессор не является абстрактным вычислителем, а вполне себе реальный кусок кремния размером примерно с ноготь большого пальца, на котором размещены миллиарды транзисторов и когда мы говорим «данные передаются из памяти в регистр», то мы буквально имеем в виду, что электрический сигнал проходит по металлическому проводнику длиной в несколько миллиметров или сантиметров. И это тоже расстояние, пусть и ничтожное по человеческим меркам, но при тактовой частоте 3–4 ГГц оно уже имеет значение, просто потому что за один такт сигнал в идеальных условиях будет проходить всего 10 сантиметров, а в металлическом проводнике на кристалле и того меньше.

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

Python славится своей гибкостью. Мы можем передавать функции как аргументы, возвращать их из других функций и даже "записывать" внутрь них состояние. Но как это работает под капотом? И при чем тут странное слово nonlocal?

В этой статье мы проследим эволюцию: начнем с глобальных переменных, разберемся с замыканиями (closures), поймем магию nonlocal, а затем соберем всё это вместе, чтобы понять, как работают декораторы — один из самых элегантных механизмов Python.

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

Параллельные и распределённые вычисления часто ставят рядом, но это далеко не одно и то же. В новом переводе от команды Spring АйО разберем, как устроены обе модели, чем отличаются их архитектура, способы обмена данными, масштабируемость и отказоустойчивость. Статья подойдет тем, кто хочет понять, когда достаточно ресурсов одной машины, а когда без сети из нескольких узлов уже не обойтись.

Привет, Хабр! Меня зовут Александр Зевайкин, и мы с командой делаем YDB (СУБД Яндекса). В конце прошлого года Яндекс представил специализированного ИИ‑помощника — Нейроюриста, для которого обучил языковую модель на основе Alice AI LLM. Сервис работает на базе RAG, под капотом у которого находится YDB c миллионами различных юридических документов.

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

Привет, Хабр. Меня зовут Владимир, я бэкенд-разработчик. Это моя первая статья здесь — о том, как пет-проект для нишевого варианта шахмат прошёл путь от «а что, если...» до первого места в рейтинге на chess.com. Без нейронок. На чистом alpha-beta поиске, написанном на Rust.

Статья будет полезна тем, кто интересуется шахматным программированием, оптимизацией CPU-bound задач или связкой Python + Rust через PyO3.

Всем привет! Если вы следите за темой вайбкодинга, то наверняка замечали как быстро всё меняется. Ещё год назад я генерил одностраничные HTML-файлы, радовался жизни и был уверен что вайбкодинг - он вот про это. Странички, кнопочки, красивый фронтенд. А потом как-то незаметно оказалось что мне нужна база данных, авторизация, платёжная система и тесты. Это как зайти в IKEA за свечкой и выйти с кухней.

Вайбкодинг за последний год изменился до неузнаваемости. Сейчас это не "сгенерь мне страничку" - это полноценная разработка с бэкендом, PostgreSQL, OAuth авторизацией, эквайрингом от Т-Банка, тестами и автодеплоем. Настоящий небоскрёб. И каждый кирпичик в нём выбран не случайно - самые беспроблемные технологии которые я нашёл за время своих скитаний по разным стекам и агентам. Чтобы строить легко и с удовольствием. Ну или хотя бы без желания выкинуть ноутбук в окно.

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

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

Меня зовут Алексей Мартынов, я разработчик и предприниматель с 25-летним опытом работы в IT, программный директор и ведущий эксперт направления веб-разработки в Яндекс Практикуме. В этом материале я рассуждаю о будущем разработки через 5, 10 и 25 лет, а также даю советы новичкам.

Что если защита от копирования вообще не содержит ни одного условного перехода? Ретро-разбор библиотеки 2009 года, где вместо if (key == valid) используется вычисление адреса следующей функции, любая ошибка в данных уводит процессор в никуда.

Классический взломщик ищет в дизассемблере инструкции JZ/JNZ и инвертирует их ("Magic Jump"). Здесь этот приём не работает: нет точки принятия решения, нет и цели для патча. Вместо этого серийный номер диска, CRC32 исполняемого файла и системная дата складываются в единственно верный адрес перехода. Чуть изменил данные - получил Access Violation в случайном месте памяти.

Pandas — швейцарский нож дата-аналитика. Пара строк, и данные отфильтрованы, сгруппированы и готовы к работе. Но часто бывает так: изящный скрипт, летавший на тестовом датасете, на реальных объемах превращается в тормозящего монстра, который воет кулером и выплевывает MemoryError.

Почему так происходит? Главная беда — наши привычки из чистого Python. Циклы for, apply и построчная обработка идут вразрез с архитектурой Pandas, построенной поверх массивов NumPy.

В этой статье разберем 5 самых частых (и фатальных) ошибок при работе с DataFrame. Посмотрим, как безобидные решения убивают производительность и память, и научимся переписывать код так, чтобы всё работало быстро, элегантно и «по-пандасовски». Спойлер: циклов не будет.

Приветствую всех, кто хочет делать свой код быстрым и оптимальным. Традиционно, если нам нужно большое количество объектов какого-то класса, мы создаем массив этих объектов. Однако, каким бы простым и очевидным не казался данный подход, он не всегда эффективен. Рассмотрим плюсы и минусы каждого из подходов к размещению большого числа объектов в памяти, их область применения и, конечно же, рассмотрим их на примерах.

Работая над архивными фотографиями Сочи, я заметил, что на Pastvu люди иногда годами обсуждают в комментариях, откуда сделан тот или иной снимок. Мне стало интересно: можно ли это вычислить математически? Оказалось, что да. Если на снимке видны три узнаваемых объекта и известны их координаты, задача решается через алгоритм PnP (Perspective-n-Point). Я собрал браузерный инструмент, который делает это автоматически. Первый тест на реальном снимке Сочи дал совпадение с точностью до улицы.

Оригинал книги «Kotlin Crash Course: Fast-track your programming skills with practical experience» вышел в июне 2024 года от автора с серьезным опытом в крупной разработке. Русское издание «Котлин. Краткий курс» выходит в марте 2026, и в настоящий момент это самое свежее руководство по Kotlin на русском языке. В предисловии читателям обещают «быстрое погружение», но если открыть оглавление, становится понятно, что предстоит осилить около 600 страниц довольно плотного и структурированного материала. В рецензии разберем, что внутри, кому эта книга подойдет и насколько она остается актуальной к марту 2026 года.

У индустрии есть любимая форма самоуспокоения. Каждый раз, когда речь заходит про AI в разработке, люди начинают обсуждать качество кода. Смотрят на демки, ловят модель на галлюцинации, смеются над кривыми PR, вспоминают, что она не понимает бизнес-контекст, и на этом месте выдыхают. Кажется, что профессия снова отбилась. Ну да, игрушка интересная, местами полезная, местами смешная, но до реальной инженерной работы ей еще бесконечно далеко.

Легко поддаться этому успокоению, вспомнив первые версии Claude, Copilot или ChatGPT. Многие говорят, что это просто очередной инструмент, как экскаватор вместо лопаты. Ошибка этой аналогии в том, что Copilot - это действительно экскаватор, которым управляет человек. Но агентные системы, работающие в цикле CI/CD, это не инструмент. Когда у вас появляется система, способная самостоятельно делать десятки итераций проверки и исправления за секунды, без участия человека, единица человеческого труда меняется необратимо.

Мне кажется, в этот момент люди смотрят мимо главного.

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

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