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

Доброго времени суток, господа и дамы! Иногда у некоторых людей возникает желание заняться откровенным непотребством в программировании — то, что не несет практической пользы напрямую, но помогает развлечься. И я — не исключение. В этой статье я хочу рассказать вам о лайфхаках, трюках (магических и не очень), алгоритмах на языке C!

Идея написать эту статью зародилась из моего поста, после него я написал статью «Математика, биты, магия и немного ненормального программирования на C», «Фокусы, хаки, магия и прочее ненормальное программирование на C» и «Тёмная сторона Си: трюки, хаки, магия и алгоритмы», которые раскрывали много интересных моментов.

Увидев, что многим понравилась, я решил продолжить, чтобы узнать насколько глубоко кроличья нора!

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

Всех, кто заинтересовался — прошу под кат.

Недавно написал статью о проблемах использования ИИ (Иллюзии Интеллекта) при разработке программного обеспечения / Хабр, и решил не ждать у моря погоды, когда (и если) провайдеры исправят ситуацию на своей стороне, а попытаться самостоятельно выработать приемлемый алгоритм работы с ИИ, который был бы экономически выгодным и целесообразным при разработке ПО хотя бы лично для меня.

Данная статья - это очередной Хабрахак с подведением итогов и получением обратной связи об использовании ИИ-помощников при разработке программного обеспечения с примерами кода и итоговыми выводами о целесообразности использования ИИ в том или ином проекте.

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

В этом посте будут объяснены две стратегии оптимизации WebAssembly, которые не так давно были реализованы в движке V8 и вошли в версию браузера Google Chrome M137. Речь пойдёт о спекулятивном встраивании call_indirect inlining и о поддержке деоптимизации в WebAssembly. В сочетании два этих приёма помогают генерировать более качественный машинный код, так как основаны на допущениях, которые строятся, исходя из обратной связи, поступающей от среды исполнения. Благодаря этому, WebAssembly выполняется быстрее, особенно это касается программ WasmGC. Например, проверив эти приёмы на наборе микробенчмарков, написанных на Dart, видим, что комбинация двух оптимизаций даёт ускорение в среднем более чем на 50%. В более крупных и реалистичных приложениях и на тех бенчмарках, которые рассмотрены ниже, достигается ускорение между 1% и 8%. Деоптимизации — также очень важная составляющая для дальнейшей оптимизации в будущем.

Привет!

Разберём ReadyToRun (R2R) — технологию предкомпиляции в .NET. Многие включают её, надеясь на супер ускорение, а потом удивляются результатам. Посмотрим, как это работает на самом деле и где реально помогает.

ReadyToRun — это AOT-компиляция для .NET. Обычно приложение поставляется в IL-коде, который JIT превращает в машинный код во время выполнения. R2R компилирует код заранее при публикации проекта — в итоговых DLL лежит и IL, и готовые машинные инструкции. При запуске CLR просто берёт нативный код без пауз на компиляцию.

Всем привет! Меня зовут Щепетков Константин, я TechLead бэкенд разработки компании ZeBrains, работаю в роли TeamLead бэкенда на проекте мобильного приложения Бургер Кинг.

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

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

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

Тут не будет инструкций к конкретным ИИ-иструментам, но при этом поделюсь практическим опытом применения ИИ. Статья будет полезна не только бэкенд‑разработчикам, но и всем, кто хочет использовать ИИ-инструменты осознанно.

Привет, я Павел Таланов из команды Yandex Infrastructure. Вместе с командой мы создаём SourceCraft — платформу для полного цикла разработки IT‑продуктов. Хочу рассказать о прикольной задаче на стыке бэкенда и IDE, которую мы решали, чтобы сделать ещё более удобную навигацию по коду в SourceCraft — когда индексация кода проходит с нужной скоростью, а подсказки и другие фичи навигации всегда готовы к открытию пул‑реквеста.

Расскажу про требования, которые мы выявили для поиска по коду, чуть‑чуть про предметную область, а также о том, какая архитектура индексации у нас в итоге получилась — и почему.

Большие языковые модели часто используют как один большой "мозг": написал промпт, нажал Enter - и сразу запускаешь сгенерированный код. Быстро, удобно и наполненно магией. Такой подход можно называть вайб-коддингом.

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

В этой статье я покажу, как относиться к LLM не как к "герою-одиночке", а как к команде ролей (аналитик, ресерчер, архитектор, разработчик, ревьюер, QA, техписатель, валидатор) и собрать полноценный AI-Driven Development (AIDD) процесс с понятными договорами и quality-гейтами на каждом шаге.

Это практический how-to: от минимальной версии до более строгого процесса с ролями, гейтами и интеграцией с CI. Все примеры - на базе Claude Code, но принципы подхода можно перенести и на другие инструменты (Cursor, Copilot, локальные агенты и т.п.).

Меня зовут Александр, я fullstack разработчик с 20+ годами опыта (php+js+golang и всякое по мелочи). Количество мифов и заблуждений о разработке через ИИ превысило, на мой взгляд, все разумные пределы.

Я хотел бы порассуждать о причинах таких заблуждений.

Типичные заблуждения не-разработчиков звучат так:

Стабильность E2E-тестов: как добиться 100% успешных прогонов ?

Практика, проверенная на реальном проекте.

Флаки-тесты убивают доверие к автоматизации. В этой статье — проверенные подходы, которые помогают превратить нестабильные E2E-прогоны в надёжный инструмент проверки продукта.

Есть у меня один знакомый. Преподаватель. Примерно, раз в месяц принимает экзамены у студентов, с курсов повышения квалификации. Студенты решают задания на компьютерах, а он ходит между ними, вопросы задает и двойки ставит.

Только вот, ходить приходится с бумажными ведомостями, которые постоянно падают. Студенты в них подглянуть наровят. Если в ведомости надо что-то исправить, то приходится зачеркивать и грязь разводить. А затем, результаты надо внести в компьютер.

И настолько эта возня с бумагой его достала, что знакомый решил:
"Хватит это терпеть! Говорят, в соседнем дворе бабушка сама написала себе "ЦИАН" (находясь под воздействием). А я что? Лысый что-ли?!
Вон, даже курсы по вайбкодингу продаются! Напишу сам себе электронную ведомость!
Ведь может же сейчас обычный человек написать любую программу. Ну не будут же врать в Интернете."

Я почти 20 лет пишу код на С++ за деньги, и почти все это время ощущаю неприязнь к инструменту, который позволяет мне безбедно жить. К тому же я занимаюсь системным программированием, а это налагает дополнительные требования к знанию языка.

Я долго не мог выразить вербально, что меня так отталкивает в C++. Однажды из любопытства меня заинтересовал Rust. Я влюбился в него не сразу, сделав не менее 3х подходов к снаряду изучению, пока наконец-то не нащупал интуитивное понимание. С этого момента Rust превратился для меня в эталон инструмента для системного программирования.

Supabase — это краеугольный камень многих low-code и no-code платформ (Lovable — хороший тому пример) и он получил широкое распространение с приходом эпохи vibe-coding. Не просто так - им (супер)легко пользоваться как AI-кодинг агентам, так и углеродным формам жизни.

В некотором смысле он убирает необходимость иметь отдельного девопс / админа / администратора БД. Для стартапа преимущества очевидны: свободного времени и рук почти никогда не бывает. И, если честно, кому вообще хочется этим заниматься? Гораздо приятнее потратить это время более продуктивно - например, на думскроллинг в Twitter.

Команда Python for Devs подготовила перевод статьи о двух новых Rust-базированных анализаторах типов для Python — pyrefly и ty. Оба пока в ранней альфе, но уже демонстрируют впечатляющую скорость, разные подходы к выводу типов и новые возможности.

Команда Spring АйО подготовила перевод про Fray — инструмент для обнаружения и воспроизведения ошибок многопоточности в Java-программах. Основанный на научных исследованиях и написанный на Kotlin, Fray использует технику теневой блокировки для выявления взаимоблокировок и других проблем синхронизации. Он уже доказал свою эффективность на таких проектах, как Kafka, Flink и Lucene.

Если вы работаете с BI‑системами, наверняка сталкивались с ситуацией, когда стандартных визуализаций не хватает. Хочется добавить свой график, который идеально подходит под задачи бизнеса.

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

Здравствуй Хабр.

Полтора миллиарда лет назад, когда я учился в начальной школе, нам задали домашнее задание: написать сочинение в свободной форме, про наступающую весну. Я воспринял задание с воодушевлением. С детства люблю свободные формы. Решил написать сочинение в стихах. Написал, и, довольный собой, сдал на проверку. На следующий день, учительница меня резко отчитывала и стыдила перед всем классом за то, что я сдал сочинение, которое написал НЕ САМ. Она просто не могла поверить, что ребенок мог написать такое самостоятельно. Знаете, я далеко не Есенин, и то было довольно наивное произведение, вполне детского уровня. Но я старался. Вложил душу. И мне было до ужаса обидно. А еще я понял, что взрослые - только на вид взрослые, а на деле - ни черта не понимают.

На днях, подобная несправедливость случилась со мной снова.

Представьте ситуацию: на демо клиент испытывает VR-тренажер «Работы на высоте».

Легкий ветерок, стальной пролет, панорама города. Красота. Клиент поднимается по лестнице, останавливается на краю и с восхищением говорит: «Как круто вы сделали, что от вида вниз у меня голова закружилась!» Мы переглядываемся. Потому что «круто» — это не мы сделали. Это заслуга плохой оптимизации раннего прототипа.

Пока персонаж карабкался, движок героически пытался «на лету» подгрузить пачку тяжелых моделей. FPS просел, рендер начал задыхаться, и вестибулярка клиента объявила забастовку. Иммерсивность —10/10, комфорт — где-то в районе отрицательных значений. Если голова кружится, это должно быть запланировано геймдизайнером, а не видеокартой. 

Привет, я backend-разработчик SimbirSoft Андрей. В этой статье разберем, как сделать так, чтобы VR-проекты на Unity работали стабильно и были дружелюбны к вестибулярному аппарату игрока.

Эта статья дополняет предыдущую. Там мы зафиксировали проблемы. Здесь разберем, что именно мы сделали со стороны Amplicode, чтобы агент начал работать как опытный software engineer: опираясь на структуру проекта, детерминированные генераторы и понятные высокоуровневые операции.

Если коротко, в первой статье было несколько основных болей:

– LLM часто обучены на слегка устаревшем мире, и это вылезает в мелочах (и не только).
– Галлюцинации и нехватка контекста идут рука об руку: «кажется, в этой библиотеке должен быть такой метод» и пошло-поехало.
– Переизбыток контекста тоже зло: агент прочитал половину репозитория, потратил деньги, запутался, а потом еще и забыл начало чата.
– Типичный агентный workflow: «сгенерил простыню кода, оно не компилится, давай чинить, ой теперь сломалось другое».

И на этом фоне появляется логичный вопрос: а можно сделать так, чтобы агент работал не с сырыми файлами, а с моделью проекта и сущностями фреймворка? Чтобы он не гадал, где DTO, как принято именовать контроллеры и какие миграции у вас используются?

Собственно, Spring MCP от Amplicode про это.

Команда Go for Devs подготовила перевод статьи о трёх языках, которые всё чаще оказываются в одном ряду, но на самом деле решают принципиально разные задачи: Go, Rust и Zig. Автор несколько месяцев изучал каждый из них и попытался понять, какие ценности стоят за их устройством. Go выбирает минимализм и корпоративную предсказуемость, Rust — безопасность и максимальную выразительность, Zig — радикальный контроль и отказ от ООП-мышления. Получился честный и местами провокационный разбор того, зачем нужны эти языки и кому из разработчиков они подходят.

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

Меня зовут Стас Иванкевич, я техлид в команде разработки управляющего слоя Platform V DropApp в СберТехе. В управляющий слой входят установщик кластера, консоль, API, другие компоненты и самое релевантное для этой статьи — наши многообразные операторы.

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