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

Откройте любой пулл‑реквест в проекте с любой «чистой архитектурой» и вы скорее всего увидите не обсуждение бизнес‑логики, а срач. «Это нельзя класть в UseCase, это логика домена!», «Зачем тут еще один DTO, мы же просто поле прокидываем!», «Этот интерфейс не нужен, у нас никогда не будет другой реализации!». Полагаю, очень много людей с таким сталкиваются.

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

Не думаю, что за мою 45-летнюю карьеру какой-то другой язык удивлял меня сильнее, чем Zig. Могу с уверенностью сказать, что Zig — это не только новый язык программирования, но и, на мой взгляд, совершенно новый способ написания программ. Задача этого языка — далеко не только замена C или C++.

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

Когда-то ты спорил на форумах о том, что лучше — tabs или spaces, а теперь просто настраиваешь .editorconfig и идешь пить кофе. Этот текст — не про карьеру, не про зарплаты и не про мотивацию. Это про то, как постепенно меняется восприятие кода, ответственности и хаоса, когда годы коммитов превращают энтузиазм в инженерное спокойствие. Здесь не будет морали — только наблюдения, немного иронии и чуть-чуть боли.

Год назад на конференции VideoTech ваш покорный слуга сделал большой доклад, в том числе про прогресс современных метрик качества видео (которыми мы довольно плотно занимаемся: тык, тык, тык, тык, тык, тык, тык, тык). А на открытой дискуссии тем же вечером представитель крупного российского видеосервиса поднялся и высказал всем мнение (своего менеджера):

«Измерение качества видео — это лишняя операция. Бизнес — это вообще-то про деньги. Поэтому в бизнесе главное — это бизнес-метрики: user retention, DAU, MAU и вообще ARPU. А все эти ваши PSNR, SSIM, VMAF — от лукавого. Если пользователи платят деньги и не отписываются, значит всех всё устраивает и это главная метрика качества».

«И вообще в свое время в Toyota был внедрен подход Lean Manufacturing, где одна из «семи потерь» — это потери из-за лишних этапов обработки (waste on over-processing), к которому, очевидно, относится измерение качества. Эти материи проходят на курсах MBA, которые довольно дороги. Поэтому далеко не все российские технари в теме этих важнейших понятий и не в состоянии осознать их критическую важность для бизнеса компаний».

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

«Слушай, а почему у меня на даче YouTube через Роскомнадзор работает лучше Rutube без Роскомнадзор?»

(видеоверсия — доклад на VideoTech доступен тут)

Ну-с, господа, «которых всё устраивает!» Поехали! 

Привет, Хаброжители!

Чёрная пятница началась — Сколько вы сэкономите?

Всем привет! Меня зовут Бронислав Алексеев, я разработчик и один из организаторов сообщества Python-разработчиков в Новосибирске — PythoNSK.

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

И да, нам удалось привлечь Никиту Соболева, core-разработчика CPython. Рассказываю, как это было с нуля: бронирование помещения, поиск участников, составление расписания.

Кстати, эта статья написана в преддверии второго митапа PythoNSK - он будет в субботу 22 ноября, а в этой статье мы разберем плюсы и минусы нашего первого митапа, проведенного 13 сентября 2025 года!

Но обо всём по порядку. Всех интересующихся - просим под кат.

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

Если вам надоело слушать проповеди про «безопасность памяти» — эта большое эссе именно для вас, усталых скептиков. Эндрю Лилли Бринкер — ведущий инженер компании MITRE в области безопасности программного обеспечения — спокойно разбирает факты и доказывает: безопасность памяти — не прихоть и не религия Rust‑евангелистов, а экономически оправданный шаг в сторону надёжного, дешёвого и безопасного софта.

Rust, Java, Go и им подобные языки не делают программистов «лучше» — они просто предоставили ремни безопасности в сам процесс разработки. И, как в случае с автомобилями, это спасает тысячи «жизней» приложений.

Привет! Меня зовут — Евгений, работаю в финтехе и проектирую системы, которые обрабатывают миллионы запросов, интегрируются с десятками внешних сервисов и живут в Kubernetes. А еще я преподаю Java/Spring Boot и рассказываю студентам, как не наступать на чужие грабли, а создавать свои и прыгать на них.

Больше 10 лет в разработке — и за эти годы в череде проектов я видел одну и ту же боль: отсутствие системного подхода к наблюдаемости. Логи, метрики и трейсы появляются «по остаточному принципу»: что‑то добавили при отладке, что‑то прилетело из чужой либы, что‑то настроили на проде. Итог — инженеры часами разбирают простые инциденты, а продуктовые команды теряют скорость.

В статье поделюсь нашим опытом: как мы строим наблюдаемость в системах, почему OpenTelemetry — это больше чем стандарт и какими принципами мы руководствуемся.

Всем привет! Меня зовут Макс Теричев. Я старший инженер по разработке ПО в YADRO. В первый день работы в компании меня отправили пройти Go Tour. После этого я приступил к работе по автоматизации тестирования Control Path сервисов в СХД. Чтобы увеличить их тестовое покрытие, был создан специальный фреймворк, который интегрировал написание тестов в процесс разработки. Что входит в этот подход, насколько дорого обходятся ошибки в разработке систем хранения данных и какие два вида мотивации здесь работают — читайте под катом.

Привет! С вами снова Алексей, Android-разработчик из Облака Mail. В прошлой статье я подробно разобрал, как менялись правила фоновой работы в Android на протяжении всех версий ОС. А сегодня я расскажу, какие инструменты реально работают на последних версиях системы и как их правильно использовать. Везде также будут примеры кода и ссылки на документацию.

Привет, хабровчане! На связи Алиса — тимлид в e-commerce агентстве KISLOROD.

Кто о чем, а я продолжаю рассказывать, как сшипперить Bitrix и Laravel. В первой части я рассказывала, как подружить Laravel с Битриксом так, чтобы никто не пострадал. Во второй — как устроить единый вход без шаринга сессий, ускорить каталог с OpenSearch, внедрить outbox-публикации и навести порядок в наблюдаемости. Теперь третий шаг — разгружаем чтение.

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

Привет, Хабр! На связи руководитель проектов редакции компьютерной литературы издательства «БХВ» @Holmogorov. C 15 по 19 октября во Франкфурте проходило, пожалуй, самое известное мероприятие, которое каждый год собирает сотни тысяч читателей и тысячи книгоиздателей со всего мира. Речь идет о международной книжной ярмарке, известной под  названием [Frankfurt Book Fair](https://en.wikipedia.org/wiki/Frankfurt\_Book\_Fair), или, на языке организаторов, Frankfurter Buchmesse. Несмотря на сложную международную обстановку и объективные трудности, превращающие получение европейских виз в увлекательный квест, мы побывали на этой выставке, чтобы оставаться в курсе последних тенденций на рынке компьютерной и технической литературы. О том, что мы там увидели и услышали, мы хотим вам сегодня рассказать.

Java-разработчикам теперь доступен мощный инструментарий для работы с агентными ИИ-системами: Spring AI представила проекты Agents и Bench. В новом переводе от команды Spring АйО рассмотрим, как первый обеспечивает удобную абстракцию для работы с CLI ИИ-агентами, а второй — предлагает реалистичные бенчмарки для оценки их эффективности в задачах enterprise-разработки.

Разработчики на GitHub осталось без аналитики трафика своих репозиториев. Уже месяцы функция недоступна, а сайт статуса сервисов Github показывает, что всё хорошо. Разбираемся почему одна из крупнейших IT-компаний мира не может починить простейшую функцию. 

Асинхронность — слово, от которого у разработчиков дергается глаз и теплеет сердце. Корутины, горутины, event loop, трэдпулы — за этими терминами скрывается целая философия, меняющая взгляд на то, как писать высоконагруженные системы.

Привет, Хабр! Меня зовут Дмитрий Буров, я Golang-разработчик, автор Telegram-канала Go Advocate, а также лидер Go-сообщества в Lamoda Tech. В IT свитчнулся из военного дирижера. В коммерческой  разработке — более 10 лет, начинал как фуллстек-разработчик на стеке JS, PHP, CSS, а последние шесть пишу только на Go. В этой статье по мотивам моего доклада для GolangConf расскажу про асинхронность и её роль в современных высоконагруженных системах. Разберём исторический аспект, концепцию и реализацию корутин в разных языках, эволюцию асинхронных подходов, сравним корутины и горутины, выясним, зачем Go добавил в рантайм пакет coro и чем это может обернуться.

Привет! Меня зовут Анна и я QA-инженер в Банки.ру. В этой статье я расскажу о том, как мы сделали инструмент нагрузочного тестирования доступным для каждого инженера в компании.

Представьте: команда запускает новый микросервис, который будет отдавать информацию о банковских продуктах. Сервис покрыт автотестами, билды зеленые, все работает штатно. Но через пару часов после деплоя в прод сервис начинает падать под наплывом пользователей, время ответа превышает 10 секунд, разделы лежат, ПАНИКА!

Знакомо? У нас было подобное. В статье расскажу подробно про наш опыт!

В мире микросервисной архитектуры качественная документация API — это не роскошь, а необходимость. Она ускоряет интеграцию, снижает количество ошибок и упрощает жизнь как разработчикам, так и потребителям вашего сервиса. Исторически документация часто отставала от кода, но с появлением стандарта OpenAPI (ex‑Swagger) и его глубокой интеграции с экосистемой Spring этот процесс можно полностью автоматизировать.

В этой статье мы подробно рассмотрим, как профессионально подойти к документированию API, используя связку OpenAPI и Spring Boot. Чтобы материал был максимально практическим, мы создадим простой PersonService и на его примере покажем, как из кода генерируется всегда актуальная и интерактивная документация.

Привет, Хабр! В предыдущих статьях — «Rust без прикрас: где мы ошибаемся» и «Rust без прикрас: где мы продолжаем ошибаться» мы обсудили всякие неприятные грабли: бездумное использование unwrap(), игнорирование ошибок через let _ =, чрезмерное клонирование, проблемы с хвостовой рекурсией и прочие оплошности. Теперь пришло время взглянуть на другой пласт проблем.

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