А как?
Как?
Реально, как? Скажите мне. Почему это происходит так..
Исключения — самый коварный механизм C++. Код компилируется, тесты проходят, но в продакшне система падает из-за partially constructed object или утечки в деструкторе. Результат — часовой дебагг и нестабильность.
Основная ошибка: путаница между Basic и Strong guarantee. «Валидный» объект ≠ «корректный». Вы нарушаете инварианты, даже не подозревая об этом.
На вебинаре «Exception Safety в C++: как писать код, который не ломается» развенчаем мифы об Exception Safety. Не теория, а разбор реальных антипаттернов из кодовых баз:
➕ Исключения в деструкторах и как RAII решает это.
➕ Где noexcept ломает гарантии, а где — критически важен.
➕ Move-семантика и её скрытые опасности.
‼️Вы получите: чёткую ментальную модель и чек-лист для код-ревью, который можно применять уже на следующий день.
📅 Дата: 5 февраля
⏰ Время: 17:00-18:00 (Мск)
👨🎓 Спикер: Козырев Дмитрий — специалист в области разработки на C++.
➡️ Регистрация ⬅️
Hypermedia Systems.
HATEOAS и Hypermedia получают, на мой взгляд, недостаточно внимания. Подходы, которые описывал в докторской Рой Филдинг, всё реже трактуются в связке с HATEOAS.
Это удивительно, потому как слово REST в обсуждениях я слышу часто. Но только в формате “используйте HTTP глаголы для описания действий”. Или, еще хуже, как синоним HTTP JSON API.
Как же так? Как обсуждать REST без учёта концепции зрелости Ричардсона? Это тема, которая требует дополнительного обсуждения, ведь HATEOAS — высший уровень зрелости REST.
К чему я? Прочитал за два дня книгу Hypermedia Systems. Авторы до этой книги работали над HTMX.
Хоть и сталкивался с HTMX, книга помогла дополнительно прояснить, как HTMX соотносится с HATEOAS. Авторы представляют уверенную аргументацию, что простой HTML можно рассматривать как ключевой элемент реализации HATEOAS. И что SPA с раздутыми JavaScript-фреймворками для маппинга JSON API в HTML — тупиковая ветвь эволюции.
Книгу можно и последовательно читать, и использовать как справочник по HTMX. Она есть в публичном доступе.
Если Вы ещё не встречались с HTMX, HATEOAS, Hypermedia, и не знаете, что это такое, рекомендую всеми руками, объём достаточно небольшой.
Ненулевая толерантность к багам, код-фриз и другие приключения команды разработки
Встречайте новый эпизод второго сезона подкаста ПВЗ.
ПВЗ — Почти Всё Знают — наш подкаст о технологиях, которые проникают во все сферы жизни. Его ведут эксперты Ozon Tech: Марина Самойлова, руководитель платформы данных, и Виктор Корейша, руководитель Managed Services.
Гость этого эпизода — Алексей Шевенков, CTO Hepsiburada, крупнейшего турецкого маркетплейса. Вместе с ним ведущие пытаются найти баланс между скоростью разработки и надёжностью продукта. Существует ли он? У каких операционных задач есть TTM? Что такое бюджет на ошибки и когда допустима ненулевая толерантность к багам?
Ответы на эти вопросы, а также проблем-менеджмент, сезонные и культурные особенности в e-com, — в новом эпизоде.
Приятного просмотра:
VK Видео
YouTube
и прослушивания!
Книга Pro Git.
Несмотря на кажущуюся сложность, на повседневной основе для работы с Git не требуется большой набор знаний. Checkout, fetch, branch, commit, amend, rebase, revert, reset, pull и, наконец, log. Это — большинство нужных команд. Изредка пользуюсь еще config, бывает нужно.
В общем-то, Git достаточно прост с точки зрения пользователя. Проблема: понимание простоты Git приходит именно с опытом работы с тем самым Git. А по началу хочется иметь под рукой какую-нибудь книжку.
Скотт Чакон и Бен Страуб составили замечательное справочное пособие для тех, кто хочет окунуться с головой в детали работы с Git. Издание есть в виде сайта, PDF, EPUB и MOBI. Распространяется Pro Git бесплатно.
Книга рассчитана на начинающих пользователей или тех, кто имеет конкретные вопросы по механикам Git и им нужен подручный справочник. Что немаловажно, сайт и книга переведены на русский язык.
Pro Git не раз мне пригодился в прошлом, рекомендую.
Страница Pro Git: https://git-scm.com/book/ru/v2
Хочу поделиться записью моего последнего вебинара - в преддверии следующего. Буду рад всем, кто посмотрит.
📘 Часть 1. Теория и философия Digital Q.DataBase
Разбираем фундаментальные вопросы:
• Как Digital Q.DataBase объединяет три SQL-диалекта
(T-SQL, PL/SQL, PL/pgSQL) в одном ядре?
• Как продукт обеспечивает простоту и высокую скорость миграции?
• Что входит в базовый состав коробочной версии?
🛠 Часть 2. Практика: установка и работа с диалектами
• скачиваем и устанавливаем Digital Q.DataBase,
• получаем документацию,
• выполняем практику по SQL-диалектам на демостендах.
Да, это тот самый момент, когда теория превращается в конкретику - и вы сами видите, как работает гибридная архитектура продукта.
📎 Полезные ссылки
🔹 Бесплатное получение дистрибутива: https://database.diasoft.ru
🔹 Документация: доступна внутри дистрибутива
🔹 Telegram-сообщество Digital Q.DataBase: https://t.me/dqdatabase
Новые вакансии в SSP SOFT на конец января
Кто мы? Лидеры («одни из», конечно) найма ИТ-специалистов на российском рынке — за прошлый год мы наняли 179 сотрудников! Занимаемся заказной разработкой ПО и предоставляем крупным клиентам выделенные команды на ИТ-аутсорсинг.
У нас новый московский офис, который открылся в 2025 году у самой Красной площади! А еще есть вакансии в офис в Томске и на удалёнку из любой точки России.
Команда в SSP SOFT — это реальные проекты, дружная атмосфера, где работать — продуктивно, без выноса мозга и микро-менеджмента. В январе 2026 ищем гуру, кто готов в новое профессиональное будущее вместе с нами.
1️⃣ Python AI разработчика
2️⃣ Java Tech Lead
3️⃣ Data Разработчика (Oracle, Greenplum) (https://vk.cc/cTLO9g)
4️⃣ Системного аналитика (ритейл) (https://vk.cc/cTLOcv)
Что вас ждет в SSP SOFT:
✅ Рост: Центр компетенций для максимального апгрейда скиллов.
✅ Свобода геолокации: Возможность работать удаленно, гибрид или офис.
✅ Баланс work-life: Работаем, чтобы жить, а не наоборот.
🎁 Приятные бонусы: ивенты для всей команды, ДМС для штата, обучение и бенефиты.
Подробности о вакансиях читайте на нашей странице ХХ.ру, но туда откликаться необязательно. Ждем резюме в ЛС нашему HR Lead Алине (https://t.me/AONikitina).
Не забудьте добавить «секретную фразу» в сопроводительное письмо, «Увидел(а) вашу вакансию на Хабре».
Желаем всем хабровцам успешной карьеры в 2026 году 🚀)
Событие Pizza, Bugs & Fun - 29-30 января 2026 года.
Уже несколько лет в мире Joomla проводятся мероприятия "Pizza, Bugs & Fun" (#PBF), где каждый может посвятить несколько часов своего мозгового времени тому, чтобы наша любимая CMS стала ближе к идеалу.
Ссылки на видео и статьи из этого поста рассказывает об организационных вопросах, которые пригодятся для участия в PBF, а так же что и как делать. Координация международного сообщества Joomla происходит в Mattermost (присоединиться).
В рамках события PBF все желающие могут собираться в общий онлайн чат, обсудить вопросы Joomla и приложить к их разрешению свою руку. Самый классный вариант, когда эта встреча происходит оффлайн: тогда организовывается пицца, напитки по вкусу и несколько часов совместного творчества.
Каждый помогает тем, что он умеет:
кто-то пишет недостающую документацию,
кто-то пишет код,
кто-то тестирует как исправлены ошибки или сделан новый функционал.
На сайте события есть карта, можно "захостить" свою локацию. Практически все движки в мире развиваются за счёт спонсирующих их компаний. Joomla одна из немногих, где развитие идёт только усилиями международного сообщества энтузиастов.
На момент написания данного поста в репозитории Joomla 810 открытых Issue (как правило это баги) и 236 Pull request (PR, исправление багов и новый функционал). Все PR обязательно тестируются минимум двумя участниками сообщества, дабы в конечный код движка не проскочила ошибка.
Если каждый из участников только нашего сообщества сделает даже одно тестирование, то, боюсь, PR и Issue на всех не хватит 😀 И ничего не останется нашим коллегам из международных Joomla-чатов.
Как тестировать Joomla PHP-разработчику? Компонент Patch tester. (кстати, не только PHP разработчику)
Куда можно сбежать из разработки, чтобы не умереть с голоду?
Ищу работу уже несколько месяцев, и ощущение такое, что рынок полуживой. По вакансиям — требования «знай всё на свете», а если верить hh, то на некоторые позиции по 400–500 откликов.
Невольно возникает вопрос:
а есть ли вообще адекватный выход из разработки?
Я .NET-разработчик с 6+ годами опыта и хотелось бы понять, куда можно перейти, чтобы мой бэкграунд был полезен, а не обнулялся в ноль — и при этом не остаться без средств к существованию.
Возможно, у кого-то уже был похожий путь. Буду рад, если поделитесь, из чего выбирали и на чём в итоге остановились.
Lazygit.
При работе с Git я почти не пользуюсь отдельными программами. В корпоративной разработке у меня под рукой есть IntelliJ с достаточно удобной панелькой Git. А для своих проектов я привык пользоваться Git CLI.
И всё же, время от времени, нужно посмотреть изменения в разрезе нескольких коммитов. Делать тучу git diff не очень удобно, особенно когда нужно дать хэш конкретного коммита.
И тут на помощь приходит Lazygit. Этот TUI позволяет удобно шастать по дереву Git стрелками. Окна в программе настраиваются, мышка поддерживается, темы оформления есть.
Можно делать stage для кусков кода, а не целых файлов. Можно делать commit, fixup, revert, amend… В общем, все (или почти все) функции Git в наличии.
Благодаря тому, что это TUI инструмент, им можно пользоваться на удалённых машинах по SSH. Очень удобно и практично.
Где учиться бэкенду?
На Хабр Карьере мы отобрали курсы, в которых качественная теория сочетается с сильной практикой — так, чтобы полученные знания можно было сразу применять в работе.
А сегодня мы собрали подборку курсов по backend-разработке: языков и инструментов тут много, поэтому собрали все в одном месте, чтобы вы могли сравнить и выбрать то, что вам по душе:
— Python. Веб-приложения, анализ данных, машинное обучение, автоматизация.
— PHP. Серверная логика сайтов и веб-сервисов.
— Java. Корпоративные системы и высоконагруженные сервисы.
— C#. Enterprise-приложения, веб-сервисы, продукты под экосистему Microsoft.
— Ruby. Веб-приложения и прототипирование.
— Node.js. Серверная часть веб-приложений, real-time сервисы, API.
→ Выбирайте направление и начинайте прокачивать навыки уже сегодня.
UTF-8 Everywhere.
На неделе вспомнил про wchar_t в Си, пока в очередной раз работал с Unicode, но в Windows. Штука… Неоднозначная.
Часть WinAPI жёстко завязана на WCHAR (wchar_t). Но в Windows он до сих пор определён размером в 16 бит. Тот же GCC на Debian мне говорит, что у него wchar_t — все 32 бита.
Т.е. перевод строки из char в wchar_t генерирует валидный UTF-16 в Windows, но UTF-32 в Linux…
Кажется, char32_t должен решить эту чехарду в будущем… Хотя бы с точки зрения размерности… Пусть это и не исправит проблемы WinAPI…
Но действительно ли так часто нужно работать с полноценным code point в Unicode? Зачем? Только чтобы посчитать общее количество символов? Это же просто сделать и на основе char!
Авторы UTF-8 Everywhere дают развёрнутый ответ на этот и многие другие вопросы. Идея хорошо проработана, есть даже прекрасный FAQ для любопытных.
На этой веб-странице собрали самые веские доводы для использования исключительно UTF-8. Везде. Всегда.
Веб-сайт UTF-8 Everywhere: https://utf8everywhere.org/
Всё зелёное — значит, всё ок?
В новом выпуске подкаста «В SREду на кухне» обсуждаем суть мониторинга и причины его хронических сбоев. В фокусе — метрики и алерты: как не утонуть в потоке предупреждений, отсеять ложные сигналы и выстроить эффективную систему. Говорим о том, как SRE анализируют графики, какие показатели бизнес считает ключевыми, и развенчиваем миф о том, что «зелёный» статус всегда означает успех.
Ведущие:
Михаил Савин, SRE Community Lead в Авито;
Андрей Волхонский, руководитель юнита System в Центре разработки инфраструктуры Авито;
Евгений Харченко, руководитель отдела по развитию практик в разработке и эксплуатации в Райффайзен Банк.
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
Ближайшие события
Ответьте мне на один простой вопрос: зачем в наше время вообще нужны HR?
Ни для кого не секрет, что найм сегодня сломан. Бесконечные этапы собеседований, которые якобы должны отсекать «вкатунов в IT», по факту отсеивают и нормальных разработчиков.
Причём даже в эффективности этого «фильтра» есть серьёзные сомнения: по сети уже гуляют AI-оверлеи, которые в реальном времени анализируют вопросы интервьюеров и подсказывают ответы. Так о каком объективном отборе вообще идёт речь?
При этом у HR — бесконечный поток, условно говоря, «подопытных кроликов», на которых можно тестировать гипотезы, улучшать процессы и действительно чинить найм.
Но вместо этого они просто копируют чужие, далеко не самые успешные практики.
Почему HR не выполняют своё прямое предназначение, а действуют по шаблону?
И главный вопрос: каким образом лайв-кодинг должен подтверждать или опровергать мои навыки, если:
могут дать абсолютно любую задачу и в штатном порядке, я залезу гуглить документацию, а на собесе я это сделать не могу?
Короче говоря — как же у меня с этого горит.
Go To Statement Considered Harmful.
Легендарное письмо Эдсгера Дейкстры обсуждалось учёными и программистами довольно долго. Даже сейчас встречаются разные взгляды на присутствие GOTO в программе.
Краткое содержание (парафразирую): GOTO нарушает простую навигацию по коду и, самое главное, возможность сопоставить код с тем, что мы имеем как состояние процесса в определённый момент времени.
Сам Дейкстра пишет, что ничего нового не говорит, о том же уже выступали Тони Хоар, Никлаус Вирт и ряд других учёных.
Дейкста и его коллеги в 1970-х дадут старт “структурному программированию”. В основу ляжет теорема Бёма-Якопини.
Оригинал статьи есть в свободном доступе библиотеки ACM.
Что интересно, этот вариант вырезки содержит и другие письма от 1968 года в редакцию журнала ACM.
К примеру, одно из них про то, что ЯП и их среды не должны быть защищены торговыми марками. Другое про дихотомию килобайты-кибибайты. Ещё одно про необходимость включения пост-мортем дампов (stacktrace или coredump) как обязательную часть высокоуровневых ЯП…
Иногда кажется, что мы застряли в каком-то странном лимбо, где всё уже было придумано или обдумано за нас. Нам же надо только иногда почитывать работы прошлого…
Letters to Editor на сайте ACM: https://dl.acm.org/doi/pdf/10.1145/362929.362947
При написании интеграционных тестов для Spring Boot приложения часто возникает проблема, что разработчики бездумно добавляют аннотации @MockBean, @SpyBean, @DirtiesContext или переопределяют прямо в тестовом классе различные property. Всё это приводит к изменению Spring Context, невозможности использовать закэшированный контекст и следовательно созданию нового. Часто создание нового контекста это длительная операция.
Существуют инструменты по отслеживанию этих процессов. Самым простым способом увидеть количество контекстов и количество попаданий в кэш является добавление логирования либо через свойство logging.level.org.springframework.test.context.cache=DEBUG либо настройкой вашего логгера.
Один известный автор статей про тестирование на Java / Spring Boot, Philip Riecks (со товарищи), создал инструмент с открытым исходным кодом Spring Test Profiler при помощи которого можно получить html отчёт о поднимаемых контекстах во время тестов, о количестве и типе бинов в этих контекстах. На Хабре есть перевод его статьи в сообществе Spring АйО.
У нас на проекте стал вопрос, как нам показать разработчикам, что их тест порождает новый Спринг Контекст. Мы решили считать контексты в тестах и при превышении ожидаемого количества падать. Это "руинит" сборку и CI/CD пайплайн.
Для этого мы добавили реализацию интерфейса ContextCustomizer
class LimitingSpringContextCustomizer implements ContextCustomizer {
private static final AtomicInteger CONTEXT_COUNTER = new AtomicInteger();
private static final int EXPECTED_SPRING_TEST_CONTEXT_COUNT = 16;
@Override
public void customizeContext(ConfigurableApplicationContext context, MergedContextConfiguration mergedConfig) {
int numberOfContexts = CONTEXT_COUNTER.incrementAndGet();
log.info("Number of Spring Test Contexts: {}/{}", numberOfContexts, EXPECTED_SPRING_TEST_CONTEXT_COUNT);
Assert.state(numberOfContexts <= EXPECTED_SPRING_TEST_CONTEXT_COUNT,
() -> "Number of test contexts exceeds configured maximum: " + EXPECTED_SPRING_TEST_CONTEXT_COUNT);
}
@Override
public boolean equals(Object obj) {
return (obj != null) && (getClass() == obj.getClass());
}
@Override
public int hashCode() {
return getClass().hashCode();
}
}Здесь, согласно документации интерфейса ContextCustomizer необходимо корректно переопределить методы equals и hashCode.
WARNING: implementations must implement correct equals and hashCode methods since customizers form part of the MergedContextConfiguration which is used as a cache key.
Далее добавляем фабрику.
class LimitingSpringContextCustomizerFactory implements ContextCustomizerFactory {
@Override
public ContextCustomizer createContextCustomizer(Class<?> testClass,
List<ContextConfigurationAttributes> configAttributes) {
return new LimitingSpringContextCustomizer();
}
}Затем регистрируем эту фабрику при помощи spring.factories чтобы она применялась ко всем тестам.
Для этого создаём в тестовых ресурсах файл по пути src/test/resources/META-INF/spring.factories со следующим содержимым
org.springframework.test.context.ContextCustomizerFactory=\
com.mycompany.app.support.spring.LimitingSpringContextCustomizerFactoryТеперь, если во время выполнения тестов будет превышено количество инициализированных тестовых контекстов, то мы увидим ошибку в тестах и сборка завершится неудачей.
Возможно, это пример поможет кому-нибудь повысить скорость прохождения своих тестов путём отслеживания количества запускаемых тестовых Спринг контекстов.
Подборка инструкций по Python для начинающих специалистов
Привет, Хабр! Вот и наступила пятница, а значит, пришло время очередной подборки материалов для тех, кто решился взяться за изучение Python. Сегодня у нас несколько базовых инструкций, бесплатный курс и небольшой квиз.
Как работать с PostgreSQL в Python. Эта статья-шпаргалка научит работать с модулем psycopg2, чтобы немного упростить себе жизнь при администрировании PostgreSQL.
Рукописный редактор на Python: инструкция для тех, кто хочет «рисовать» код. Создадим виртуальный лист, на котором можно набросать код от руки — и он будет исполняться!
Как создать голосового помощника на Python. С помощью простых инструментов и библиотек разработаем голосового помощника на Python, сделав его полезным и удобным в повседневной жизни.
Квиз: хорошо ли вы разбираетесь в Python? Тест на владение синтаксисом Python. Позволит оценить свои знания и отыскать пробелы.
Изучаем Python: теория, практика, настройка инструментов. Да, это подборка в подборке. Внутри несколько материалов, все доступно бесплатно. Для тех, кто хочет научиться не только писать код, но и запускать его в облаке, внутри курса спрятан промо-код на услуги Selectel.
Книга Modern C.
В течении нескольких последних дней активно почитывал книгу Дженса Густеда “Modern C”.
Книга будет хороша как общий справочник, набор best practices кодинга на C, да и просто посмотреть, какие трюки в C23 можно делать.
Удивительно, что столь детальную и кропотливую работу можно найти в свободном доступе. Распространяется книга по лицензии CC 4.0 в вариации BY-NC-ND. Это очень радует.
Книга структурирована по уровню вовлечённости в C. От самых базовых элементов до многопоточных программ.
Для опытных разработчиков больше всего будут интересны Takeaways. Они резюмируют текст и позволяют фокусироваться на самом интересном. В конце книги есть листинг всех Takeaways, разбитый по разделам книги.
Рекомендую для любителей C.
Книга на сайте HAL Open Science: https://inria.hal.science/hal-02383654v2/file/modernC.pdf
Не надо делать по красоте. Надо делать MVP.
Никто так говорить, кроме менеджеров, не любит. А я вдруг внезапно полюбил такой подход в работе. Стал бить себя по рукам и делать дешево.
Оказывается, мозгу легче уйти в кроличью нору, чем просто делать задачу. Через час потной работы начинаешь зарываться в тонны документации, смотреть примеры кода на форумах или в репах на работе, переписывать свои модули по десять раз. Ощущение, будто стек собираешь, и он никак не схлопнется. Это обычная прокрастинация через усложнение.
MVP-подход тут мне стал очень помогать на моем, локальном уровне. Суть очень простая: делаю минимум и быстро. А потом добавляю на кости мяса. Надо сделать сохранение строк файла в БД? Пока сделаю построчно и поставлю # TODO. Потом сделаю батчем. Нужна отправка сотен объектов из БД в API? Пока тоже построчно. Нужна еще одна очередь Redis для этапа в обработке файла — потом. Пока и с одной очередью и воркером справимся.
MVP-подход требует некоей выдержки, особенно на пет-проектах. Код пишешь ты сам с собой. Выступаешь внутренним критиком и, зачастую, самым строгим. Но делать все дешево и сердито стало помогать мне лично держать фокус на цели: дать максимум ценности за минимум усилий. И при этом не сгореть от объема, быть в тонусе.
Риски, конечно тоже есть. У TODO нет хозяев, кроме нас. Дешевое Г становится иногда продом. Техдолг это вообще бесконечная тема и, пожалуй, не для этого поста. Пост про эффективность.
MVP-промтинг работает и с нейронками таким же образом. Берем чистый контекст, делаем простой прототип. А дальше по кускам его обтесываем, заменяем, улучшаем. Может, у нас есть с ними что-то общее?
У каждого человека есть свое определение голого минимума. Поэтому примеры выше могут кому-то показаться тривиальными. Очевидно, и сам подход не для всех. Но мне лично он развязал немного руки и помог выдохнуть на одной из недавних душных задач. Может быть такой ход мысли поможет и вам.
Где бесплатно учиться веб-разработке?
Многие боятся пробовать что-то новое, потому что опасаются потратить деньги на обучение впустую, хотя курсы сейчас — отличный способ сменить работу или получить полезный навык.
Хорошая новость: получить полезные навыки можно без рисков и вложений. На Хабр Карьере есть множество бесплатных и полезных курсов.
Присмотритесь к веб-разработке:
— Frontend-разработка. HTML, CSS, JavaScript.
— Backend-разработка. Python, Node.js, SQL
— Fullstack-разработка. JavaScript, React, Node.js
→ Иногда лучший старт — просто начать из любопытства.