Бэкенд

по сути же получается нужно меньше разработчиков сейчас? Интересно как это выглядит с точки зрения владельца бизнеса

Регулярно стал видеть подобные вопросы. Если растет производительность, то логично, что надо сокращаться? Если речь идет про избыточную разработку и цель оставаться на том же уровне производительности, то да, избыточность можно уменьшить. Но реальность и капитализм работают чуть сложнее.

Регулярно стал видеть подобные вопросы. Если растет производительность, то логично, что надо сокращаться? Если речь идет про избыточную разработку и цель оставаться на том же уровне производительности, то да, избыточность можно уменьшить. Но реальность и капитализм работают чуть сложнее.

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

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

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

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

Больше про разработку в моем телеграм-канале Организованное программирование

Про Null References.

Популярные современные ЯП позволяют переменным-ссылкам иметь значение NULL. И это уже привело к огромным проблемам, рассказывает Тони Хоар на выступлении.

Борьба с NULL принимает разные виды.

Дизайн каких-то ЯП оставляет это на откуп линтерам, не обременяя себя вопросами времени компиляции и исполнения.

Другие ЯП разрешают хранить NULL только в переменных, которые имеют знак вопроса после типа. Пример: Object? a = null. Нет знака вопроса — переменная не может быть NULL.

Отдельные ЯП имеют монаду Maybe или Optional в стандартной системе типов. Так они кардинально избавляются от самого концепта NULL.

Так или иначе, определённо ясно, что NULL — исключительно техническая необходимость прошлого. А в моделировании предметной области использовать NULL просто не получится.

Презентация на сайте InfoQ: https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/

Пока все отдыхали на праздниках и доедали оливье, эксперт-«скалист» из компании «Криптонит» уже вовсю работал над базой знаний по Scala!

5 января Артём Корсаков, руководитель группы Scala-разработчиков в «Криптоните», опубликовал в своём проекте Scalabook обновления, над которыми он работал больше двух месяцев.

Делимся!

• Создание нового проекта на Scala 3

• Основные типы задач

• Статусы и типы задач

• Локализация

• Работа с базой данных (CRUD операции)

• Генерация SQL через макросы

• Реализация CRUD операций

• Интеграционное тестирование с базой данных

Отправляйте этот пост коллегами, которые пишут на Scala!

Scalabook — это уникальная русскоязычная база знаний по Scala. На сайте представлены материалы о функциональном программировании, алгоритмах и структурах данных, классах типов, переводы статей. Также у проекта есть телеграм-канал с новостями — @scalabook. Подписывайтесь!

Мы иногда во внутреннем чате обмениваемся фрагментами кода с неочевидными ошибками, которые обнаруживаются с помощью PVS-Studio в каком-нибудь открытом проекте. Мол, кто быстро сообразит, что не так с кодом?

Вчера коллега поделился вот таким фрагментом кода из проекта SereneDB:

template <typename T>
struct NumericParameter : public Parameter {
  using ValueType = T;
  ....
  std::string name() const override {
    if constexpr (std::is_same_v<ValueType, int16_t>) {
      return "int16";
    } else if constexpr (std::is_same_v<ValueType, uint16_t>) {
      return "uint16";
    } else if constexpr (std::is_same_v<ValueType, int32_t>) {
      return "int32";
    } else if constexpr (std::is_same_v<ValueType, uint32_t>) {
      return "uint32";
    } else if constexpr (std::is_same_v<ValueType, int64_t>) {
      return "int64";
    } else if constexpr (std::is_same_v<ValueType, uint64_t>) {
      return "uint64";
    } else if constexpr (std::is_same_v<ValueType, size_t>) {
      return "size";
    } else if constexpr (std::is_same_v<ValueType, double>) {
      return "double";
    } else {
      static_assert("unsupported ValueType");
    }
  }
  ....
};

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

Ответ:

Анализатор PVS-Studio выдаёт предупреждение V591 Non-void function should return a value. parameters.h 222

На первый взгляд предупреждение странное и смахивает на ложное срабатывание, ведь не может быть, что функция закончила работу, не вернув значение с помощью оператора return. Если выбирается ветка else, то там static_assert, и код просто не должен скомпилироваться. Во всех остальных случаях есть return "что-то";.

Но есть нюанс!

Ещё раз посмотрите на эту строчку:

static_assert("unsupported ValueType");

static_assert используется неправильно: пропущен bool-constexpr. Вернее, строковый литерал неявно конвертируется в значение true, и static_assert никогда не прервёт компиляцию. В итоге else-ветка функции ничего не возвращает, и её поведение будет не определено для всех специализаций NumericParameter, кроме указанных ранее в цепочке if constexpr.

Правильный вариант:

static_assert(false, "unsupported ValueType");

A Micro-Manual for LISP.

LISP имеет удивительный по простоте синтаксис. Это делает его одним из самых популярных кандидатов для программирования своего интерпретатора.

Такой интерпретатор — замечательный пример пет-проекта, который расширит кругозор и познакомит с элегантностью LISP. Быть может, разожжёт интерес к Clojure и Scheme.

Отличной подмогой для проекта будет работа Джона Маккарти. В своём микро-руководстве он описал базовые блоки для построения минимального интерпретатора.

Маккарти формулирует основу LISP всего в десятке правил и пяти основных аббревиатурах, сопровождая этот набор дополнительными примерами.

И это описание занимает всего две страницы! Фантастика!

Статья на сайте ACM: https://dl.acm.org/doi/pdf/10.1145/960118.808386

Функция date меняет поведение в PHP 8.x

При переносе Legacy-проекта с PHP 7.4 на 8.4 столкнулся с недокументированной проблемой изменения поведения функции date при передаче в качестве параметра timestamp значения NULL Один и тот же код даст разный результат:

echo date("Y-m-d H:i:s", null);

// PHP 7.4 и ниже 1970-01-01 00:00:00

// PHP 8.0 и выше 2026-01-14 08:11:56

В примере NULL передается в явном виде, но в рабочем коде он вполне может прилетать из БД или других переменных, поэтому потенциальная ошибка может остаться незамеченной. Вообще, по принципам ООП, явное всегда лучше неявного, да и сам я сторонник использования \DateTime. В этом случае, результат кода:

$date = new \DateTime();
$date->setTimestamp(null);
echo $date->format("Y-m-d H:i:s");

был бы одинаковый, а с версии 8.1 вы бы начали получать предупреждение

Deprecated: DateTime::setTimestamp(): Passing null to parameter #1 ($timestamp) 
of type int is deprecated
1970-01-01 00:00:00

Я бы рекомендовал перед миграцией версий PHP в Legacy-проектах либо учитывать эту особенность поведения функции date и убедиться, что NULL не приходит в параметр timestamp, либо сразу сделать рефакторинг на \DateTime, чтобы в принципе избежать таких проблем.

Kotlin и Hyperskill: как я искал курс и что получил в итоге.

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

Я перепробовал разные форматы обучения (платные и бесплатные), поэтому в этот раз подход был простой: найти платформу, где есть структурированная программа и много практики. В итоге я добрался до Hyperskill (hyperskill.org). Это не реклама — просто личный опыт, кому-то он может сэкономить время.

Как я пришёл к ресурсу.

Изначально искал курсы по Kotlin на привычных площадках. На Stepik в тот момент не нашёл того, что мне подходило по структуре (возможно, сейчас ситуация лучше). Видео-курсы на крупных “известных сайтах” сознательно не рассматривал: мне удобнее формат “прочитал → сделал → получил проверку”.

Дальше — обычный путь через поисковик и сравнение нескольких платформ. Из того, что выглядело цельно и практично, больше всего зацепил Hyperskill. Отдельно сыграло роль то, что платформа связана с JetBra…. (то есть ребята явно понимают, как устроена экосистема вокруг Kotlin и IDE).После регистрации быстро становится понятно: платформа активно ведёт к подписке.Раньше в сети встречались статьи про возможность оформить бесплатную подписку на полгода, но это устаревшая информация — сейчас такой опции нет (по крайней мере, в том виде, в каком её описывают старые гайды).

При этом у Hyperskill есть бесплатный режим, и я проходил курс именно так.

Что я проходил: Introduction to Kotlin.

На платформе несколько треков по Kotlin, я начал с Introduction to Kotlin. По ощущениям, это “введение с практикой”:

• около 9 учебных проектов

• порядка 60–70 тем

• внутри тем — задачи/тренажёры с автоматической проверкой

В целом структура понравилась: материал подаётся дозировано, и почти сразу закрепляется практикой. Похожая на Степик.

Система “кристаллов” и лимиты.

Самая спорная часть бесплатного режима — ограничения на попытки.

У Hyperskill есть внутренняя валюта (“кристаллы”): ошибаешься в заданиях — кристаллы списываются. Когда кристаллы заканчиваются, обучение может блокироваться на 12–24 часа. Да, кристаллы можно зарабатывать активностью и выполнением некоторых задач, но при активном обучении и регулярных ошибках (что нормально) этого может не хватать.

Подписка проблему снимает, но именно этот момент сильнее всего влияет на комфорт обучения в бесплатном режиме.

Проекты: что внутри и зачем это полезно.

Сильная сторона Hyperskill — проекты. Они не выглядят как “игрушки ради галочки”, а позволяют постепенно потрогать основные конструкции языка.

Из того, что запомнилось:

• “Сапёр”

• “Крестики-нолики”

• “Чат-бот”

• “Кофемашина”

Например, в проекте “кофемашина” уже нормально используются циклы, классы и базовые элементы ООП. В таком формате проще понять, “зачем оно нужно”, чем на изолированных задачках.

Минус: часть проектов закрыта платной подпиской, и это немного обидно — именно проекты дают максимальную пользу и ощущение прогресса.

Проверка решений: не всегда понятно, почему “не принято”

Ещё один недостаток — качество обратной связи в тестах. Иногда тесты “падают” так, что ты видишь только факт ошибки, но не понимаешь причину: что именно ожидалось, на каком кейсе сломалось, где расхождение.Часть проектов проверяется через IntelliJ IDEA, и здесь иногда всплывают технические нюансы: несовпадение версий, необходимость обновить IDE или компилятор, странные падения на конкретном проекте.

Хороший момент: поддержка отвечает. По моему опыту, вопросы не игнорируют, и проблемы реально разбирают.

Итоги:

• бесплатный режим может раздражать лимитами на ошибки (кристаллы и блокировки)

• часть контента (включая проекты) закрыта подпиской

• обратная связь тестов местами недостаточно информативная

  Если готовы, то вперед!

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

Но это, конечно, не так. За свою 20-летнюю карьеру видел пяток увольнений самых-пресамых незаменимых. 

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

Во-вторых, даже если человек реально приносит огромную пользу и по-своему незаменим, то порой руководство просто поступает нелогично и увольняет всё равно. Иногда последствия бывают совсем неочевидны и отложены во времени (медленнее пилятся фичи, вылезают непонятные критические баги на проде), их никто никогда с Васей уже и не свяжет. Даже если объективное расследование бы показало, что денег в итоге потрачено больше. Короче, это или неправильная системная оценка или просто банальная глупость/лень менеджмента.

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

Короче, будьте бдительны. Нужно всегда быть готовым менять работу. Незаменимых не бывает.

Cross-пост из tg-канала Cross Join

Call for Pioneers: Launching the StarRocks Russian Community

Hello, Russian Developers!

We are the team behind StarRocks, a next-generation, high-performance analytical database (OLAP) widely adopted by leading tech companies globally for its blazing-fast query speeds and unified architecture.

We have always admired the Russian tech community. From ClickHouse to Nginx, Russia has a legendary reputation for engineering excellence and database innovation. We believe StarRocks has a lot to offer to this vibrant ecosystem, but we face a challenge: Language.

To bridge this gap, we are launching the StarRocks Russia Localization Program. We are looking for 3-5 technical experts to become the founding contributors of our Russian community.

The Mission

We don't just need translators; we need technical evangelists. Your goal is to help us localize high-quality technical content (Architecture deep dives, Benchmarks, User Cases) from English/Chinese into native, professional Russian, ensuring the local community can access the best resources.

Who We Are Looking For

- Native Russian Speaker: You have a high command of technical writing.

- Tech Savvy: You have mastered SQL, OLAP, and Data Warehousing, and your current job involves working with OLAP databases.(Experience with ClickHouse or PostgreSQL is a huge plus).

- Language Skills: You have a good understanding of English (or Chinese).

- Passion: You are active on Habr, Reddit or Telegram tech groups, or GitHub.

What You Will Get

- Competitive Bounties: We pay for every high-quality article translated or proofread.

- Official Recognition: We will be launching an official website in Russia, where you will be certified and listed as a Community Evangelist (subject to your consent for public disclosure).

- Inner Circle Access: Direct communication with our core R&D team and early access to new features.

- Exclusive Swag: Limited edition StarRocks geek gear.

Поиск партнёра для совместной инженерной проверки идей (не найм)

Сразу обозначу границы, чтобы не тратить время друг друга.

Я не ищу работу, не нанимаю, не продаю услуги и не собираю команду.
Интересует формат равного партнёрского взаимодействия на уровне мышления и проверки гипотез.

Контекст

Мой бэкграунд - backend / инфраструктура / системы.
Умею проектировать и собирать техническую часть, доводить до рабочего состояния, автоматизировать, поддерживать.

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

Что именно ищу

Ищу одного человека, с которым можно:

• разбирать идеи без романтизации

• проверять гипотезы на реализуемость и смысл

• делать небольшие, ограниченные по времени и объёму пробы (MVP / прототип / концепт)

Речь не про «стартап мечты», а про инженерный подход к неопределённости.

Кого не ищу

• менторов и гуру

• инвесторов

• людей, ожидающих «готовый проект»

• мотивационные разговоры без действия

Формат

• асинхронная переписка

• созвон 45–60 минут

• если не совпали по подходу - спокойно расходимся

Без обязательств, без разговоров про доли, без долгих ожиданий.

Почему сейчас

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

Контакт для связи: Telegram @sachconzales

When to Make a Type.

Мартин Фаулер размышляет о ярких преимуществах выделения новых типов и мастерски формулирует лаконичный ответ на этот вопрос.

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

В деталях об этой идее, но немного с другого ракурса, пишет Эрик Эванс в книге "Предметно-ориентированное проектирование" (Domain-Driven Design).

Книга Эванса требует глубокого погружения в концепты DDD. Что такое доменный объект? Как он связан с реальными бизнес-сущностями? Что такое объект-значение? И т.д.

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

Рекомендую к ознакомлению!

Статья на сайте Мартина Фаулера: https://martinfowler.com/ieeeSoftware/whenType.pdf

Интерактивность в разработке.

Брэт Виктор отлично презентует своё видение мира. Попутно он затрагивает вопрос о необходимости моментального визуального отклика на изменения в исходном коде. Рассказывает о том, как интерактивность позволяет получить совсем иной опыт разработки. Более динамичный.

Примеры, которые он показывает, отчасти напоминают мне о возможностях, которые даёт подход Event Sourcing. Ведь Event Sourcing позволяет работать с перепроигрыванием событий и делать быстрые эксперименты даже над целыми системами в локальном окружении.

Поменял параметр, прогнал цепочку событий, посмотрел на результат. Конечно, это не по-настоящему моментальный отклик, но уже достаточно близко.

Впрочем, всегда есть, куда стремиться.

Презентация на Vimeo: https://vimeo.com/906418692

Демо Smalltalk-76.

Иногда просто поражает масштаб того, что разрабатывали в Xerox PARC.

На этом видео Дэн Инголлс презентует Smalltalk-76, объединённую интерактивную среду исполнения и сам язык программирования. Два в одном! И это в 1976 году!

Smalltalk исторически повлияет на большое количество современных ЯП с ООП. Отдельно стоит отметить яркое влияние на ЯП, где в основе лежит модель акторов.

В то время ООП было не столь про термины "инкапсуляция", "полиморфизм" и "наследование". Скорее про то, что всё есть "объект", а объекты общаются между собой исключительно путём обмена сообщениями.

Это — основа современной акторной модели.

Да, Smalltalk сейчас — довольно нишевый и редкий язык, но в прошлом это был аналог и прямой конкурент молодого, только появившегося Java...

Презентация на YouTube: https://youtu.be/NqKyHEJe9_w

HR, простите, но у меня не было выбора - Как я потратил несколько сотен часов на ИИ-ассистента для поиска работы

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

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

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

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

Что не так с процессом поиска

Проблема не в самом поиске, а в том, как он реализован.

1. Массовая рассылка вместо выбора.
Осознанный подбор вакансий быстро превращается в пролистывание списков и надежду на статистику.

2. Отклики как механика.
Сопроводительные письма отличаются формально: поменять название компании, чуть переписать вводную — и так десятки раз.

3. Неэффективные затраты времени.
Квалифицированный специалист тратит часы на задачи с минимальной ценностью, причём этот цикл повторяется при каждом новом поиске.

Инженерный взгляд

Если абстрагироваться, поиск работы — это:

• входные данные (резюме, требования вакансии),

• правила сопоставления,

• повторяемые действия,

• измеримые результаты.

С инженерной точки зрения — кандидат на автоматизацию.
Так появилась идея проекта OfferMate, который берёт на себя рутинную часть процесса.

Коротко о разработке

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

Довольно быстро стало понятно, что задача сложнее, чем кажется:
нестабильные источники, антибот-механизмы, разные форматы вакансий, неоднородные данные.

За 4+ месяца разработки мы:

• несколько раз пересобрали архитектуру,

• получили жёсткий фидбек,

• убедились, что это не история про «просто прикрутить LLM».

Технические детали осознанно опускаю — при интересе разберу отдельно.

Что получилось в итоге

Сейчас OfferMate — это ассистент, который:

• ищет релевантные вакансии на hh.ru и в Telegram,

• автоматизирует отклики,

• формирует сопроводительные письма под конкретные вакансии,

• работает в фоне, минимально вовлекая пользователя.

Им пользуются кандидаты разного уровня — от начинающих до опытных специалистов.

Про сопроводительные письма

Корректнее говорить не «ИИ пишет письма», а что система:

• анализирует резюме,

• разбирает требования вакансии,

• ищет пересечения,

• и на их основе формирует текст.

Это не делает письмо идеальным, но делает его релевантным, что на практике влияет на отклик.

Куда дальше

Сейчас мы работаем над следующей версией проекта.

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

Вместо вывода

Этот пост — попытка взглянуть на поиск работы как на инженерную задачу и попробовать решить её соответствующими методами.

Если интересно последить за проектом, все новости публикуем в этом Tg-канале:

👉 https://t.me/offermatecrew

Также буду рад вопросам и обсуждению в комментариях.
Если тема зайдёт — сделаю отдельный технический разбор.

Шаблонный сервис

Я всячески люблю, когда разработка идёт предсказуемо – и многое для этого делаю.  

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

Так зачем же нужен шаблонный сервис?

Легко ориентироваться в других сервисах. Иногда нужно залезть в сервис коллег, или поддерживаешь несколько сервисов. Никаких проблем – структура везде одинаковая, всё знакомо, не нужно тратить время на раскопки.

Быстрый старт. Стартуете новый сервис? Полчаса – и он готов. Никаких лишних приседаний.

Единые практики. Шаблон определяет, не только структуру, но и то, как мы, например, делаем ретраи, какие у нас зависимости. как устроен circuit breaker, обработка ошибок и т.д.    

Лучшие практики – в одном месте. Если появляется что-то классное, мы добавляем это в шаблон и новые сервисы сразу это наследуют.     

Обсервабилити, логирование, работа с секретами – готово из коробки. И меньше шансов, что кто-то забьёт на логирование до лучших времён»:)    

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

Просто экспериментировать. Создал веточку от шаблона – и прикручиваешь свою новую махарайку, не тратя время на базовую структуру.

Унификация линтинга. Конфиги линтеров лежат в шаблоне. Ничего настраивать не нужно, а код-ревью идёт быстрее – обо всём уже однажды договорились и зафиксировали.

Базовый CI/CD. Для шаблонного сервиса существует шаблонный ci/cd – и это очень удобно.

Мы активно использовали шаблонный сервис в микросервисной архитектуре, но и для монолитных решений он тоже отлично зашёл – стартовали с ним несколько проектов.

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

В общем – заходите, смотрите, ставьте звездочки. И если с чем-то не согласны – пишите в комменты, автор обязательно ответит 🙂

Работаем из Java с устройствами с serial-интерфейсом (COM и USB) без JNI — по TCP.

Раньше пользовались rxtx, затем jssc. После очередных крэшей JVM в коде нативных библиотек решил не выбирать замену, а отказаться от них полностью.

В качестве прокси serial-TCP можно взять ser2net или поэкспериментировать с socat, но я запилил свое простое (Rust, mio), под конкретную задачу:

1. Запускается из основного приложения, свой процесс для каждого устройства

2. Конфигурация через аргументы запуска и переменные окружения

3. Завершает работу при отсутствии или отключении устройства (для USB), отключении или отсутствия подключения TCP-клиента

В качестве TCP-клиента Netty. Для интеграции с легаси данные читаются в кольцевой буфер ( OneToOneRingBuffer из agrona), а оттуда уже используются по месту в удобное время.

За счет неблокирующего чтения и использования epoll в mio и Netty минимальные задержки, моментальное оповещение о наличии данных (без Thread.sleep) и об отключении USB-устройства.

Задержки настолько меньше, что пришлось адаптировать кривой код, который не был готов к тому, что драйвер железного serial-порта в Linux отдает данные порциями по 8 байт. Решилось реализацией ByteToMessageDecoder, где возможно, а где нет — буферизацией на стороне прокси и отправкой по таймеру.

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

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

Dotfiles для NVIM v0.10.

За прошедший год меня несколько раз спрашивали: каким конфигом NVIM я пользуюсь?

Люблю брать дефолтный NVIM и накидывать минимум плагинов, которые чуть-чуть упрощают жизнь. Для локальной машины добавляю LSP, линтинг, авто-форматтеры и тему.

Единственная особенность конфига — прибиваю гвоздями версии плагинов, чтобы они были совместимы с NVIM v0.10. Некоторые плагины уже требуют v0.11+, но я на Debian Trixie и в стабильных репах живёт только v0.10. Бэкпортов пока не завезли...

В общем как-то так, вот репа на GitHub.

Podman, OCI и HEALTHCHECK.

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

Compose файлы, которые там есть — предельно простые. Есть цепочка сервисов, которые запускаются друг за другом. Первым стартует БД, никаких проблем. Вторым — сервис с API для загрузки данных в БД. Опять никаких проблем. Третьим — контейнер с wrk для нагрузочного тестирования. И вот тут загвоздка. Контейнер зависал в бесконечном состоянии "Created".

Подебажил. Оказалось, что при сборке образа API никак не фиксировался HEALTHCHECK! Podman по-умолчанию использует именно OCI спеку контейнеров, а не Docker, и там нет поддержки HEALTHCHECK. Из-за этого не срабатывал condition: service_healthy в Compose-файле, подвешивая контейнер с wrk.

Чтобы решить эту проблему, нужно явно указать формат спеки как Docker при сборке Dockerfile/Containerfile. У Podman это выглядит так:

podman build --format docker .

А вот так для Podman Compose:

podman-compose --podman-build-args='--format docker' build

Альтернативный вариант, если не хочется передавать аргумент каждый раз — установить переменную окружения:

export BUILDAH_FORMAT=docker

Вот такие пироги :)

Раздолбайский дух Sanic.

StackOverflow сдаёт позиции. Количество задаваемых вопросов на StackOverflow близится к полному нулю

Спад начался еще несколько лет назад, когда начали хайпить нейросети, но сейчас количество задаваемых вопросов достигло рекордно низких значений. Так, за весь декабрь поступило всего 3800 вопросов, а за первые дни января около 300

Больше интересного тут