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

Привет, Хабр!
Я - AddRaiser, фронтендер с 6 годами опыта и геймдевелопер по вечерам :)

Сегодня было бы интересно собрать основные причины упадка на рынке айти и собрать ваши мнения, которые могли повлиять на ухудшение ситуации.
Буду благодарен, если проголосуете в конце в голосованиях по этому поводу. И напишете свое видение этого вопроса, я вполне мог что-то забыть.
Сразу скажу, статья будет больше про субъективное мнение со стороны того, кто и нанимался и нанимал, однако я постараюсь добавлять ссылки на вещи, которые я изучал. И никаких ссылок на ТГ или вроде того, кроме одной ссылки на игру выше.
Я вам не инфоцыган :)

GitHub только что анонсировал изменения в ценообразовании Actions. Ранее GitHub Actions имел бесплатный control plane. Это означало, что если вы использовали GitHub Actions, но запускали задачи вне GitHub-hosted runners — будь то ваши собственные машины или в вашем собственном AWS аккаунте — вы ничего не платили GitHub за эти минуты; вы платили только за вычислительные ресурсы. Теперь подход изменился. Команда Spring АйО подготовила перевод анонса команды Github.

В новой статье от команды AI for Devs разбираемся, как организовать вайб-кодинг с плагином Kilo Code в VS Code и IntelliJ IDEA из России. Пошагово настраиваем Kilo Code через RouterAI, подключаем Claude, GPT, DeepSeek и другие модели, разбираем роли агента, diff-патчи, правила проекта и нюансы работы с контекстом.

Команда Go for Devs подготовила перевод статьи о самых коварных и трудноуловимых гонках данных в Go. Автор показывает на реальных примерах, как даже опытные разработчики легко попадают в ловушки конкурентности: от случайных захватов переменных в замыканиях до неправильного срока жизни мьютексов и скрытых гонок в стандартной библиотеке.

Всем привет! Это продолжение статей про мою ECS with Sectors в моём движке Stellar Forge!

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

Статья будет полезна всем, кто пишет performance-critical код на C++: геймдев, HFT, обработка данных, embedded.

Если преподавание помогает развить навыки, то создание образовательного курса с нуля — по-настоящему проверяет на прочность.

Меня зовут Вова Тарасов, я программный эксперт курса «Мидл Java‑разработчик» в Яндекс Практикуме, в прошлом — разработчик в Яндекс Маркете. В этом материале я расскажу, как мы создавали курс, какую роль в этом процессе играл я и почему я рекомендую поучаствовать в создании учебных программ каждому, кто давно в разработке и верит в свои силы.

AsmX G3 v30.0.0-rev1.0 — крупное архитектурное обновление, которое делает ассемблер не «инструментом 90-х», а полноценным современным языком системного программирования. Главные изменения: пакетная сборка --multiboot с Supervisor, атомарная очистка --multiclean, поддержка изменяемых данных (.data), новые ISA-инструкции (включая inc/dec и movsxd) и выразительный синтаксис функций с экспериментальной поддержкой возвращаемых типов.

Одной командой теперь можно собрать загрузчик, ядро, модуль ядра и динамическую библиотеку — и Supervisor гарантирует консистентность и изолированность ошибок в подзадачах. Для разработчиков это означает: CI в 3–5 строк вместо громоздких Makefile, меньше рутины и полная управляемость сборки.

Языковые улучшения (честные строки, @syscall, @fn share, @fn static, полноценная .data) переводят AsmX G3 в категорию «язык для реальных проектов»: библиотеки .so, production-модули .ko и микро-ОС — всё это теперь удобно писать, собирать и отлаживать на чистом ассемблере.

Если вы работаете с ядром, драйверами или пишете рантаймы, v30 — релиз, который стоит испытать прямо сейчас: меньше хака, больше гарантий, полный контроль над железом — и при этом современный синтаксис.

На сегодняшний день трансформеры правят балом хайпа в мире машинного обучения, особенно после появления ChatGPT и ему подобных языковых моделей. Это стало возможным благодаря лежащему в основе их архитектуры механизму внимания (attention), однако он же и является слабым местом с точки зрения производительности и потребления памяти. Хотя в связи с этим и была разработана изящная концепция Flash Attention (Tri Dao), её существующие реализации имеют ряд ограничений.

Поэтому представляю вашему вниманию первую и единственную open-source реализацию Flash Attention 2 на Triton с поддержкой Linux и Windows, Turing-Blackwell архитектур (теперь можно работать в Google Colab и Kaggle), гомо и гетерогенных кластеров, опциональным детерминизмом, а также возможностью ручной кастомизации ядер (kernels) для более гибкой настройки под каждую GPU архитектуру отдельно. Более подробно о том как это устроено и не только — далее в статье.

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

Многим кажется, что await работает только с Task и ValueTask, но на самом деле язык позволяет сделать любой объект ожидаемым — нужно лишь реализовать определённый паттерн.

Итак, зачем нужен свой await? Бывают случаи, когда вам хочется написать асинхронный метод, но результат приходит не из готового Task или таймера. Например, ждёте какое-то событие, изменение файла, считывание из сокета, или просто хотите встроить задержку без запуска Task. Когда вы пишете await expr, компилятор в глубине понимает так: берётся результат expr.GetAwaiter(), затем вызывается awaiter.IsCompleted. Если false, он подписывается на awaiter.OnCompleted, когда завершится, и потом берёт awaiter.GetResult().

Готов поспорить, вы кодите на Python достаточно давно, чтобы чувствовать себя уверенно... ровно до того момента, как открываете терминал в понедельник утром и думаете: «Должен же быть способ получше, чтобы автоматизировать весь этот бардак».

Хорошие новости: он есть.

После 4 с лишним лет создания автоматизаций, отладки катастроф, которые я сам же и устроил, и написания скриптов, которые каким-то образом выставляют меня кибер-волшебником в глазах друзей, далёких от Python, я отобрал 11 чрезвычайно практичных и редких Python-скриптов, которые сделают ваш ежедневный рабочий процесс гладким, как свежеустановленный дистрибутив Linux.

Поехали.

Команда AI for Devs подготовила перевод резонансного расследования о том, как "приватные" VPN-расширения на самом деле зарабатывают на ваших ИИ-переписках. 8 миллионов пользователей, Featured-бейджи от Google и Microsoft, полный доступ к ChatGPT, Claude и Gemini — и всё это утекает дата-брокерам. История о том, почему обещания безопасности в браузере стоит читать особенно внимательно.

В 2013-м я получил свою первую вакансию джуна. Требования: PHP, MySQL, jQuery. Всё. Я открыл tutorial, за выходные накодил todo-лист, через месяц уже чинил баги в проде.

Вчера смотрел вакансию для джуна. Требования занимали два экрана. Node.js ИЛИ Python ИЛИ Go. React ИЛИ Vue ИЛИ Angular. PostgreSQL + Redis + MongoDB. Docker обязательно. Kubernetes — плюсом. GraphQL знание приветствуется. Плюс микросервисы, CI/CD, облака...

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

А что сейчас?

Сейчас — это Node.js, Deno, Bun для JavaScript-бэкенда. Go, Rust, Elixir для хайлоад. Python с FastAPI, Django, Flask. Kotlin, Java, Scala для enterprise. Плюс Ruby, PHP (еще жив), C#/.NET... И это только языки и рантаймы. А еще базы: PostgreSQL, MySQL, MongoDB, Redis, Cassandra, ElasticSearch. Очереди: RabbitMQ, Kafka, NATS. Контейнеризация: Docker, Kubernetes, Helm. CI/CD: GitLab, Jenkins, GitHub Actions, CircleCI. Облака: AWS, GCP, Azure.

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

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

Теперь давайте поговорим про оставшиеся этапы нового рабочего процесса.

Привет, Хабр! Меня зовут Дмитрий Бабаев, я руковожу R&D в GigaCode — это ИИ‑ассистент для разработчиков от Сбера. Сегодня расскажу про очередной этап развития наших кодовых моделей. Недавно мы выпустили новую версию inline‑модели автодополнения кода (code completion). Это первая в мире MoE‑модель, созданная специально для этой задачи, мы полностью разработали и обучили её с нуля.

Доброго времени суток, господа и дамы! Иногда у некоторых людей возникает желание заняться откровенным непотребством в программировании — то, что не несет практической пользы напрямую, но помогает развлечься. И я — не исключение. В этой статье я хочу рассказать вам о лайфхаках, трюках (магических и не очень), алгоритмах на языке 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 — когда индексация кода проходит с нужной скоростью, а подсказки и другие фичи навигации всегда готовы к открытию пул‑реквеста.

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