Бэкенд

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 в Центре разработки инфраструктуры Авито;

• Евгений Харченко, руководитель отдела по развитию практик в разработке и эксплуатации в Райффайзен Банк.

Смотреть VK
Смотреть YouTube

Подписывайтесь на канал 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

→ Иногда лучший старт — просто начать из любопытства.

Что нужно знать про Unicode.

Большая часть сложностей с кодировками ушла в прошлое. Сейчас у нас есть Unicode. Он признаётся как универсальный стандарт всеми современными ОС.

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

Проблема только в том, что Unicode имеет несколько актуальных видов, которыми он может быть закодирован. И всё же, жизнь стала значительно проще.

Тематику Unicode затронул Джоэл Спольски ещё в далёком 2003 году, но она актуальна и на сегодняшний день.

Его статью можно часто встретить как стартовую рекомендацию, когда речь заходит о Unicode. И к этой рекомендации я могу только присоединиться.

Статья не просто имеет место быть, но обязательна для ознакомления, если Вы работаете с текстом на уровне байт.

Статья на сайте Джоэла Спольски: https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-software-developer-absolutely-positively-must-know-about-unicode-and-character-sets-no-excuses/

Райан Даль, создатель Node.js, одной из ключевых технологий современного веба: времена, когда код писали люди, всё.

Даль сформулировал свою позицию в посте в X: «Это говорили уже тысячу раз, но я тоже вставлю слово: времена, когда код писали люди, закончилась. Это тревожно для тех из нас, кто называет себя инженерами ПО, но от этого не менее верно. Это не значит, что у инженеров больше не будет работы, но про написание синтаксиса напрямую она больше не будет».

Не пользуюсь LLM-агентами, если могу. Давно замечаю: просто избегаю запускать LLM прямо в проекте, потому что боюсь разучиться кодить и думать. Поход в ChatGPT себе разрешаю — это как встать с дивана, чтобы пойти в магазин, а не заказывать доставку на дом. Там нужно правильно сформулировать запрос, потому что он не может добрать контекст проекта сам. Можно перекинуться парой мыслей, как с товарищем на работе. Надо подумать, как применить ответ, что выкинуть. В итоге я всё равно как-то худо-бедно программирую сам.

Пока я отрицаю прогресс, из мира агентов доносится много шума про управление контекстом и токенами. Агенты в ответ на запросы жрут лимиты по токенам, выделенные на отрезок времени. Ну либо запросы по API просто тарифицируются. Причем чем дольше общаешься с нейросетью, тем больше контекста ей нужно держать, учитывать, корректировать, сжимать. Помимо этого, нейронка ещё подглядывает правила проекта в .md-файлах, что-то помнит между переписками.

Чем больше у нейронки пузырь вашего контекста, тем хуже она работает. Путается в постоянно пополняющихся правилах, корректировках и ограничениях. Наконец, контекстный оверхед — это еще очень дорого. Каждый запрос к API содержит тысячи «мусорных» токенов и выжирать лимиты получается еще быстрее.

В ответ на это индустрия на венчурные деньги придумывает и продвигает свои «велосипеды», чтобы с помощью агентов эффективнее и дешевле решать задачи:

• В Cursor IDE есть Rules, которые накладывают ограничения поверх ваших промптов. Их можно применять вручную или автоматически; говорят, автомат работает хуже.

• Anthropic пиарит Skills (еще пример Playwright Skill). Это интерфейс для решения типовых задач с адаптивными ступенями контекста в зависимости от сложности.

• Есть MCP (Model Context Protocol) — условное API, которое расширяет возможности агентов, чтобы они не писали собственные инструменты и не тратили контекст и токены на типовые задачи: открыть браузер, прочитать Jira, отправить письмо и т. д.

• Также есть субагенты; их оркестрирует агент-оркестратор. У субагентов чистый контекст: они получают задачу, выполняют её и идут на «свалку».

И вот среди этого новояза я – старпер со своим ChatGPT: после 2–3 запросов удаляю чат и начинаю новый. Вот моя экономика токенов и галлюцинаций. Меня и Альтмана маркетингом не проведешь!

Что общего между счетами за коммуналку и облачными сервисами?

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

1. Вынесите счетчик из подвала

Трудно экономить воду, если счетчик спрятан в темном углу за слоем пыли или вообще, запрятан внутри самого поставщика. В ИТ всё так же: команды не начнут оптимизировать код, пока не увидят, сколько стоит их «пробег». Поэтому начните с активации расширенных панелей мониторинга (Billing Dashboards). Расходы должны быть на виду у тех, кто их генерирует, а не только у бухгалтерии в конце месяца.

2. Распределите ответственность

У каждой «лампочки» должен быть хозяин. Назначьте ответственных за каждый ресурс, сервис, базу данных или инстанс, но не для галочки, а специалиста, который понимает, как работает этот ресурс и сколько он стоит. Да, на старте это потребует времени (и, возможно, обучения сотрудников), но в итоге вы получаете прозрачность. Золотое правило: если ресурс нельзя идентифицировать — он не должен существовать. Только так можно понять, кто «льет воду», а кто экономит.

3. Проводите регулярную поверку

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

4. «Умный дом» для бюджета

Современные системы защиты перекрывают воду автоматически, как только датчик на полу зафиксировал протечку. В облаках такая страховка также обязательна. Настройте пороговые значения и оповещения о расходах, которые предоставляют облачные провайдеры. Своевременное уведомление о том, что лимит бюджета исчерпан на 80% на первой неделе, спасет вас от крайне неприятного сюрприза в конце месяца.

5. Энергоэффективность на этапе чертежа

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

Переезд в облако не избавляет от ответственности за инфраструктуру, он просто меняет фокус, с обслуживания «железа» на оптимизацию процессов. Ни один облачный провайдер не придет к вам, чтобы выключить за вами свет. Это ваша «цифровая квартира», и уют (как и бюджет) в ней зависит только от вас.

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

Я же опять стал студентом. Спустя 20 лет. На этот раз учусь в ВШЭ. И поймал себя на странном ощущении, что правила игры теперь совсем другие.

Двадцать лет назад учеба в университете была похожа на жонглирование (а еще и покуралесить с однокурсниками надо было успеть). Стандартная лекция: слушаешь лектора, пытаешься понять и одновременно лихорадочно конспектируешь. Мысль теряется, пока записываешь. Запись теряет смысл, пока ловишь мысль. Были, конечно, уникумы, которые умудрялись успевать записывать и делать качественные конспекты. Такие конспекты ходили по рукам, переписывались и были на вес золота. Тогда это была норма, так все учились. 

Вернувшись в аудиторию на Executive Master in Management, я поначалу действовал по старинке. Слушаю, записываю. Перечитываю иногда. Но что-то было не так…
Хорошо, что довольно быстро понял: я застрял в 2005-м, а мир ушел далеко вперед.

Сегодня у меня совершенно другой алгоритм.
На лекции я просто слушаю, задаю вопросы, связываю новое с опытом. На все 100% сфокусирован на понимании и осознании материала.
А все остальное делают технологии:

• Структура и ключевые тезисы от преподавателя,

• Аудиозапись лекции на телефон

• Транскрибация в mymeet 

• Claude, который превращает полтора часа живой речи в аккуратный 20-страничный конспект,

• Алиса Про (бывший Яндекс Нейроэксперт) сшивает все конспекты в единую базу знаний, с которой легко взаимодействовать.

Рутина практически исчезла. Я переоткрыл для себя обучение. Появилась необычайная легкость и еще большее желание учиться.

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

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

А вы уже пересобрали свой способ учиться или все еще учитесь так, как будто ИИ не существует?

Тестовый фреймворк для Си.

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

На практике это не всегда так.

Да, мир Си — дикий запад. Но, тем лучше, всегда есть выбор.

Джон Брюер приводит превосходный пример того, каким может быть минималистичный фреймворк для тестирования. Всего пара макро и одна переменная, восхитительно!

Статья на сайте Джона Брюера: https://jera.com/techinfo/jtns/jtn002

AI не заменяет - AI меняет роль

Спор про скорость - ловушка. Правильный вопрос: что стало узким местом?

55% компаний, которые уволили людей из-за AI, теперь жалеют (Orgvue, 2025). Исследование METR показало странное - разработчики думают что с AI работают на 20% быстрее, а объективно на 19% медленнее (METR, июль 2025).

Хинтон говорит что скоро AI будет делать за минуты работу на месяц. CEO AWS называет отказ от найма джуниоров "одной из самых глупых вещей" (MIT Tech Review).

Кто прав? Мой опыт говорит - оба мимо. AI не заменяет и не замедляет. Он меняет распределение труда.

Что отдал AI

Почти всю черновую аналитику:

• Spec drafts - первые версии спецификаций по сырым требованиям

• C4 диаграммы - контейнеры, компоненты, контекст

• Sequence diagrams - потоки взаимодействия

• Поисковые запросы - сбор контекста из документации и кодовой базы

• Тест-кейсы - acceptance criteria по спецификации

Ручное кодирование сократил до точечных мест: интерфейсы, критичные участки, отладка. Всё остальное - через агента.

Звучит как будто всё отдал. Но нет.

Что не отдам

Здоровье. Доктор может использовать AI - это хорошо. Но это должен быть доктор с образованием и опытом. AI как инструмент - да. AI вместо врача - нет.

То же с психологом и коучем. Всё что связано со здоровьем и осознанностью - только к профессионалам.

В коде аналогично: security-критичные участки, интерфейсы с внешними системами, инварианты бизнес-логики - там доля ручной работы и глубокой экспертизы остаётся выше. AI ускорил черновики и сбор вариантов, но ответственность за модель и критерии - на мне.

Про "парадокс продуктивности"

Подозреваю, что люди измеряют "ощущение скорости", а система измеряет "время до принятого PR".

Не согласен с интерпретацией METR.

Раньше: пробуешь 1-2 варианта, выбираешь, идёшь. Натыкаешься на проблемы - третья версия. Четвёртая. Legacy копится.

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

Микро-кейс: фича интеграции с внешним API. Раньше - 3 дня на реализацию, потом 2 дня на переделку когда выяснились edge cases. Сейчас - 1.5 дня, но 40% времени ушло в спецификацию и тест-контракты. Переделок ноль.

Это не замедление. Это сдвиг: меньше "time-to-code", больше "time-to-confident".

Джуниоры: как меняется обучение

CEO AWS: "Как это будет работать через 10 лет, когда никто ничему не научился?"

Согласен. Передача знаний должна быть. С AI можно делать сайты без образования - но индустрия не только про сайты. Есть вещи где нужна математика и computer science.

Но джуниор теперь не "пишет CRUD". Джуниор учится:

• Формулировать требования так, чтобы агент понял

• Писать тест-контракты до реализации

• Дебажить и верифицировать результат

• Понимать, когда AI галлюцинирует

Сдвиг роли

Меньше клавиатурной работы, больше постановки, проверки и ответственности за инварианты.

Раньше - исполнитель. Теперь - проектировщик и валидатор.

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

Что стало важнее

Системный подход. "Герой-разработчик" и "пожаротушитель" - уходит. Ценятся люди, которые системно решают задачи.

И новый навык: строить свою систему работы с AI.

Это мой актив. Моя интеллектуальная собственность. Я трачу время не только на задачи, но и на эту систему.

Про The Clean Architecture.

Конечно, говоря про Clean Architecture, нельзя обойти стороной книгу Роберта Мартина “Чистая Архитектура”.

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

Но не менее полезной можно считать дистиллированную версию в блоге Clean Coder. Автор заметки — тот же Роберт Мартин. Если Вы не знакомы с Clean Architecture, то статья станет хорошей отправной точкой.

Статья в блоге Clean Coder: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

Про воркеры простыми словами

На работе мне понадобилось реализовать воркер. Описываю, как сам эту тему разобрал.

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

Пример
Сборщик мусора в БД: пройтись раз в час, например, и удалить старые записи. Или, как у меня задача на работе: обработать xlsx-файл, который передали в ручку.

Зачем
Чтобы сделать работу приложения асинхронной. Представим задачу, которую можно обработать дольше, чем за 10 секунд. Клиент на вашем сайте не будет сидеть и смотреть в экран эти 10 секунд. Он перезагрузит страницу, сессия прервётся, и задача не выполнится. Или веб-сервер вернёт клиенту таймаут. В описанном сценарии обработка запроса — синхронная процедура. Она плохо подходит для быстрых веб-сервисов. А вот асинхронная обработка: кинули запрос, получили ответ 200 OK и пошли чилить, пока задача исполняется — это то, что нужно. Воркер как раз для этого.

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

Триггеры
Триггерами для воркера могут быть:

• крон

• таймер

• событие

Очереди
Воркеры по событию обычно подписаны на очередь. В моём случае это как раз Redis Queue (библиотека rq, например https://python-rq.org/ ). Запрос в ручку получает 200 OK. Мой сервис создаёт запись в БД типа «задача id такой-то, статус processing» и публикует событие в очереди. Воркер забирает событие, чтобы другие воркеры не могли задачу задублировать, и пробует выполнить свой коллбэк. Если всё ок, воркер пишет в БД данные по выполненной задаче и подтверждает в очереди прочтение события. Иначе воркер может ретраить, может завалить задачу и вернуть её в очередь, а может и сам упасть.

Воркер-пул
Воркеров может быть несколько. Они могут выполнять как несколько разных задач, так и одну вместе. Увеличение числа воркеров требует оркестрации и иногда для этого также выделяет контейнер с оркестратором. Воркеры могут передавать задачи друг другу. Могут конкурировать за задачи, если очередь организовать неправильно. А могут вообще читать разные потоки и быть никак не связаны друг с другом.

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

Образ
Воркер собирается из того же образа, что и ваше приложение, но у него отдельный энтри-поинт. Вместо запуска через main.py у, например, worker.py, есть строчка вида:

def main():

    ... # Какая-то логика по инициализации воркера и очереди

if name == '__main__': 

    main() # Если запускают этот модуль напрямую, выполни команду main()

Из-за этого кода модуль можно вызвать напрямую python -m app.worker. В main(), как правило, скрыта логика какого-то while-true цикла и шатдауна на случай завершения работы воркера.

🎣 14 собесов за неделю благодаря КАРАСЮ — и да, вам не показалось)

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

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

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

🚀 Что получилось в первой версии

Мы создали ассистента, который:

• 🔎 Искал вакансии на hh.ru и в Telegram-каналах.

• 🤖 Автоматизировал отклики через официальное API.

• ✍️ Генерировал сопроводительные письма, анализируя резюме и требования вакансии.

• ⚙️ Работал в фоне, экономя пользователям до 10-15 часов в неделю.

Мы набрали несколько сотен активных пользователей. И получили огромное количество фидбеков и результатов, одним из которых поделюсь

🎯 Эксперимент «Карась» и неожиданный результат

Чтобы протестировать систему на реальной нагрузке, мы запустили в блоге условный «челлендж»: попросили желающих оставить в комментариях слово «КАРАСЬ». Это был сигнал для подключения к бета-тесту.

Результаты нас ошеломили. Один из «карасей» поделился статистикой: за 5 рабочих дней — 18 откликов от HR, 9 скринингов и 5 технических собеседований. И при этом это был не единичный случай! Мы получили несколько подобных фидбеков и увидели, что система реально работает и приносит результаты. А также получили огромный заряд мотивации. 💥

⚡️ Переворотный момент

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

🏗️ OfferMate 2.0: фундамент на годы вперёд

И пока все наслаждались новогодними праздниками, наша команда копалась в деталях. Мы не стали наращивать «костыли» на старую архитектуру, а начали строить новый фундамент.

🔥 Наше ключевое изменение:
Мы реализовали механизм, который работает напрямую через пользователя, полностью имитируя человеческие действия в браузере. Это безопасно и снимает внешние ограничения, давая беспрецедентную стабильность.

Грубо говоря, мы учим систему «работать руками» пользователя)

✨ Что в итоге мы реализовали в 2.0?

• 🛡️ Абсолютная стабильность. Больше никаких внезапных остановок из-за изменений на стороне площадок.

• ⚙️ Полная автоматизация рутины. Система может автономно управлять всем циклом: поиск → подъём резюме → отклик → отслеживание статусов.

• 🎭 Глубокая оптимизация сопроводительных писем под культуру конкретной компании.

• 🧠 Автоматизация прохождения типовых онлайн-тестов (New)

• 📊 Централизованные уведомления со статистикой (New)

⏱️ Когда запуск и как попасть в 2.0

Сейчас мы на стадии закрытого бета-тестирования и готовимся к релизу нашего продукта.

Самый сложный технологический этап пройден. Сейчас мы интегрируем новую логику в бота и проводим стресс-тесты под нестандартными сценариями.

Хотим всё хорошо оттестировать и ворваться в новый сезон найма, чтобы разрывать его вместе с вами! 💥

Публичный запуск планируем в конце января. 🗓️🎄

❗️Чтобы обеспечить качество, мы откроем только 100 слотов на 3 дня. 

Это осознанное решение для контроля нагрузки и получения концентрированной обратной связи.

Мы хотим, чтобы OfferMate 2.0 вышел не «сырым анонсом», а готовым инструментом, которому можно доверить карьерный маневр.

🤝 Как поучаствовать

Присоединиться к запуску и поучаствовать в тестировании — можно будет в нашем Telegram-канале: https://t.me/offermatecrew
Мы приглашаем сообщество Хабр помочь нам в разработке лучшего ИИ-ассистента для поиска работы!

P.S. В комментариях готов подискутировать на тему пользы автоматизированных откликов и ответить на технические вопросы 👇

Я подумал, что было бы интересно сделать дотошное исследование кода, который обеспечивает функционирование исключений в С++, и написать статью об этом. Разные платформы могут реализовывать исключения по-разному, поэтому показалось логичным сконцентрироваться на мире Linux.

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

Всё рассмотрение строится на конкретном примере. Где возможно, опираюсь на библиотеку libcxx от LLVM, а в остальных случаях — на libstdc++ от GCC.

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