Бэкенд

Границы между системным администрированием, DevOps и DevSecOps сегодня настолько размыты, что часто на сайтах поиска работы пишут: «Ищем DevOps-инженера со знанием безопасности».

Отсюда разнятся и ожидания от специалиста. Одни думают, что DevOps будет чинить принтеры и одновременно обслуживать базы данных, другие — что это инженер, проектирующий и развивающий ИТ-инфраструктуру.

Обсуждаем это всё в новом подкасте #Криптонит_говорит о системных инженерах!

Смотрите на любой удобной платформе:

• VK Видео

• YouTube

• Rutube

• Подкаст в telegram

• Я.Музыка

В выпуске приняли участие:

• Александр Телевной, директор департамента инфраструктуры в «Криптоните»;

• Артём Пузанков, руководитель отдела консалтинга безопасной разработки в «Бастионе»;

• Иван Морщагин, ИТ-консультант

Как разглядеть инженера за AI-агентом?

У вашего удалённого коллеги может быть идеальное резюме, GitHub, живой аватар в корпоративном чате и безупречно заполненные документы любого вида - да хоть на японском. Количество кода и даже его функциональность тоже мало что о нём скажут: результат его труда, весьма вероятно, произведён или основательно переработан LLM и несёт её характерный «акцент». Да, известно, что все носят маски. Однако теперь эту маску обеспечивает технология.

Распределённые инженерные команды уже стали нормой: доступ к широкому рынку труда перевешивает неудобства. Однако лёгкой такая работа не бывает - фокус, общий ритм, культура команды и обмен опытом на удалёнке держатся плохо, и оптимальной схемы мы, похоже, так и не нашли. А AI-агенты ещё и добавляют сложности в эту, несовершенную, систему.

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

Зачем нам вообще знать реальное положение дел? Что в действительности умеет коллега? Насколько он вдумчив и ответственен, насколько критичен к результатам своего труда? Без ответов нельзя планировать, оценивать трудоёмкость и прикидывать сроки. Но важнее другое: нельзя решить, кому доверить архитектурно значимый кусок системы.

Внимательный читатель резонно спросит: если результат проекта — это продукт, и он создаётся по графику, какая разница, что происходит на стороне удалённого коллеги?

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

Приведу пример из практики — Self-Join Elimination в PostgreSQL. Фича шла в ядро семь лет, один раз откатывалась уже после коммита и после релиза 18 продолжала собирать багфиксы. Недавно Tom Lane переделал её. Раньше, обнаружив самосоединение, Postgres удалял избыточный JOIN и перестраивал все ссылки на него в дереве запроса и структурах плана. Tom от этого отказался: новая реализация правит только дерево запроса и перезапускает планирование с нуля уже по новому дереву. По формальным меркам решение выглядит хуже - планирование дорожает. Выигрыш в другом: исчезает целый класс ошибок, которыми фича успела обрасти.

Заметьте, где здесь виден инженер. Ни диф, ни зелёные тесты не покажут, что человек осознанно заплатил скоростью планирования за надёжность. Мы знаем об этом только потому, что он это проговорил. И это, пожалуй, единственная зацепка, которая у нас остаётся: требовать от коллеги не код с тестами, а сформулированные компромиссы — почему так, чем заплатили, от чего отказались. Ровно то, чего pgsql-hackers требует от любого патча: без обоснования он принят не будет.

Таким образом, качественный и сложный код сам по себе перестал быть мерилом уровня инженера и что должно придти этому на смену, пока непонятно. А какие методы работают у вас при управлении распределённой командой в эпоху AI-агентов? Что помогает, а что уже очевидно устарело?

THE END.
11 сентября 2026 г., Утрехт, Голландия.

Со 2 по 8 сентября на Бирже заказов Инфостарта появились новые заказы для разработчиков, аналитиков и консультантов 1С. Среди задач — доработка конфигураций, интеграции, перенос данных, автоматизация учета и консультации.

• Функциональный анализ задач в 1С:УТ 11.5

• Проведение чека ККМ в РМК без фискализации

• Подсистема управления задачами для документов и справочников

• Синхронизация клиента ЭДО с CRM, УНФ и Бухгалтерией

• Объединение 17 файловых баз «Инфокрафт: Формула ЖКХ + Бухгалтерия»

• Модуль «Торги» для 1С Рарус

• QR-код на кассовом чеке

• Подключение двух служб ТС ПИоТ и двух ККТ на одном компьютере

• Печатная форма спецификации к договору в УНФ

• Автоматическое заполнение ЭТрН для торговых сетей

• Эмуляция и настройка сканера штрихкода в 1С 7.7 и 1С 8

• Внешняя печатная форма для заказа клиента в УТ 11.5

• Генерация SSCC-кодов для упаковок и палет в УНФ

• Синхронизация «Альфа-Авто» с каталогами и системами КАМАЗ

• Автоматизация бухгалтерских процессов с интеграцией 1С и ИИ

• Отчет на СКД для сопоставления фактических данных с планом

• Перенос базы из УТ 10.2 в облачную «1С-Рарус: Розница 8»

• Обработка банковской выписки

• Консультация по закрытию месяца в УНФ

• Перепродажа маркируемой продукции между организациями

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

🤔 Как не терять requestId в логах не пробрасывая его через параметры методов?

Классическая проблема NodeJS разработки: логи не читаемы. При дебаге когда пользователь один, разобрать что происходит ещё можно. Но после запуска в прод в логах сборная солянка из запросов и восстановить трейс вызова композиции методов нельзя

import { scoped } from "di-scoped";

export interface IRequestContext {
  userId: string;
  requestId: string;
  serviceName: "mobile" | "desktop";
  version: number;
}

export const RequestContextService = scoped(
  class {
    constructor(readonly context: IRequestContext) {}
  }
);

export type TRequestContextService = InstanceType<
  typeof RequestContextService
>;

export default RequestContextService;

Согласно MVC, делается два слоя: View и Controller. На уровне view кладем requestId в контекст исполнения через RequestContextService.runInContext

import { inject } from "di-kit";

export class SocketViewService {
  readonly loggerService = inject<LoggerService>(TYPES.loggerService);
  readonly socketControllerService = inject<SocketControllerService>(TYPES.socketControllerService);

  public sendNewOrder = async (
    request: TRequest<{ room: string; orderId: string }>,
  ): Promise<TResponse<SendNewOrder>> => {
    this.loggerService.log("socketViewService sendNewOrder", { request });
    try {
      const data = await RequestContextService.runInContext(
//                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        async () =>
          await this.socketControllerService.sendNewOrder(request.data),
        request,
      );
      return { status: "ok", serviceName: request.serviceName, version: request.version, userId: request.userId, requestId: request.requestId, data };
    } catch (error: any) {
      this.loggerService.log("socketViewService sendNewOrder error", { request, error: errorData(error) });
      return { status: "error", error: VerificationError.getErrorMessage(error), errorCode: VerificationError.getErrorCode(error), serviceName: request.serviceName, version: request.version, userId: request.userId, requestId: request.requestId };
    }
  };
}

Voila! Во всех вложенных сервисах к записи в лог будет приложен идентификатор requestId. Дополнительно, этот код позволяет сериализовать ошибки так, чтобы передавать их по шине gRPC

import { inject } from "di-kit";
import { createLogger } from 'pinolog';

const logger = createLogger("socket.log");

export class LoggerService {

  readonly requestContextService = inject<TRequestContextService>(TYPES.requestContextService);

  private get context() {
    if (RequestContextService.hasContext()) {
      // в лог - только конверт IRequestContext; scoped-контекст. но дебаггеру виден весь запрос
      const { serviceName, version, userId, requestId } = this.contextService.context;
      return { serviceName, version, userId, requestId };
    }
    return {};
  }

  public log = (topic: string, ...args: any[]) => {
    logger.log(topic, ...args, this.context);
  }

}

Как не провалить пилот ESB: разберем два реальных сценария на онлайн-конференции

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

На практике вопросов гораздо больше.

• Что именно включать в пилот?

• Какие сценарии действительно показательны?

• Нужно ли проверять только функциональность или еще производительность, мониторинг и удобство сопровождения?

• Стоит ли отдавать пилот интегратору или пробовать силами внутренней команды?

15 сентября в 11:00 вместе с DATAREON проведем онлайн-конференцию «Архитектурная лаборатория: как выбрать ESB под вашу ИТ-архитектуру». Разберем не только возможности платформы, но и то, как организовать пилот так, чтобы он действительно помог принять решение.

Что будет в программе

Сергей Скирдин, технический директор «Белого кода», расскажет:

• как сегодня выглядит российский рынок шин данных;

• какие критерии стоит учитывать при выборе ESB;

• в чем преимущества DATAREON Platform;

• зачем пилотировать платформу на реальном ИТ-ландшафте;

• какие задачи стоит закладывать в пилот.

Иван Макушов, аналитик Ikon Tyres, поделится опытом пилота с внешним подрядчиком:

• как в компании подходили к выбору новой интеграционной платформы;

• какие технические требования сформировали;

• какие сценарии включили в пилот;

• на что стоит обратить внимание при работе с интегратором..

Дмитрий Сидоренков, архитектор 1С «Уральской Агропромышленной Группы», расскажет про другой путь — пилот и дальнейшее внедрение внутренними силами:

• почему одного обучения недостаточно, чтобы начать реальный проект;

• какие специалисты нужны внутри команды;

• почему хотя бы один человек должен быть глубоко погружен в проект;

• где самостоятельной команде все же полезна внешняя экспертная поддержка;

• как перейти от первого работающего обмена к самостоятельному развитию интеграций.

По сути, сравним два сценария:

пилот с подрядчиком
и
пилот внутренней командой.

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

15 сентября, 11:00 по МСК

Участие бесплатное, нужна регистрация.

Регистрация

🤡 Новый фреймворк на NodeJS

Это не draft, а работающий код из прода. Посмотрите код сервиса, код http контроллера и код декларации

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

import { provide, inject } from "di-kit";

export class WalkerLogicPublicService {

  private readonly loggerService = inject<LoggerService>("loggerService");

  ...

}

...

provide("loggerService", () => new LoggerService());

Вот почему нельзя просто вот так? Никаких минусов нет, выносите типы в enum, создавайте изолированные пространства имен.

import { createActivator } from "di-kit";

export const { init, inject, provide } = createActivator("separate-scope");

RAG (Retrieval-Augmented Generation) — подход, при котором генеративные модели ищут ответы не только в своей внутренней «памяти», но и в ваших данных через векторный поиск и используют их для ответа. Так вы получаете более точные результаты без дообучения модели.

На бесплатном вебинаре «Создание RAG-системы на базе Qdrant» покажем процесс создания RAG-системы с использованием векторной базы данных Qdrant.

📆 Когда: 10 сентября в 18:00 (Мск)
👨‍🎓 ️Спикер: Елисеев Илья, эксперт в области Python и машинном обучении, анализе данных и бизнес-процессов

Вы узнаете:
👾 Что такое RAG и как расширить «память» генеративных моделей без их дообучения.
👾 Типы векторных данных. Полнотекстовый и семантический поиск.
👾 Чанкинг данных: как разбивать текст на части для эффективного поиска.
👾 Основы работы с Qdrant: установка, настройка и использование.
👾 Создание RAG-системы: пошаговое руководство по интеграции генеративной модели с Qdrant.
👾 Практика: пример создания RAG на базе редких литературных текстов и LLM.

✍️Записаться

Как оптимизировать хранение строк в ClickHouse

Помню как-то спорили с дата-инженерами, стоит ли использовать LowCardinality в DDL-запросах на создание объектов или это бесполезная фича и особого профита вообще не дает. С их стороны даже исследование какое-то было проведено. Как итог, LowCardinality стали использовать, но никто так и не смог наглядно показать в чем его преимущество.

На самом деле достаточно провести несколько тестов и все становится очевидно.

Создадим две таблицы. В одной тип данных определим как String во второй LowCardinality:

-- Таблица с обычным String
CREATE TABLE test_string (
    id UInt64,
    category String
) ENGINE = MergeTree()
ORDER BY id;

-- Таблица с LowCardinality
CREATE TABLE test_low_cardinality (
    id UInt64,
    category LowCardinality(String)
) ENGINE = MergeTree()
ORDER BY id;

Загружаем в каждую по 100 млн строк:

-- Заполняем первую таблицу (это займет пару секунд)
INSERT INTO test_string
SELECT 
    number AS id, 
    concat('category_name_', toString(number % 50)) AS category
FROM numbers(100000000);

-- Заполняем вторую таблицу такими же данными
INSERT INTO test_low_cardinality
SELECT 
    number AS id, 
    concat('category_name_', toString(number % 50)) AS category
FROM numbers(100000000);

Смотрим сколько данные занимают на диске:

SELECT 
    table,
    column,
    type,
    formatReadableSize(data_uncompressed_bytes) AS uncompressed_size,
    formatReadableSize(data_compressed_bytes) AS compressed_size_on_disk
FROM system.columns
WHERE table IN ('test_string', 'test_low_cardinality') 
  AND column = 'category'
ORDER BY table;

table               |column  |type                  |uncompressed_size|compressed_size_on_disk|
--------------------+--------+----------------------+-----------------+-----------------------+
test_low_cardinality|category|LowCardinality(String)|95.68 MiB        |750.46 KiB             |
test_string         |category|String                |1.56 GiB         |9.19 MiB               |

Можно заметить невооруженным глазом, что с LowCardinality данные на диске (compressed_size_on_disk) занимают в разы меньше места чем если бы мы просто хранили их в String. При распаковке данных (uncompressed_size) при чтении LowCardinality также сильно выигрывает. В оперативку будет загружено на порядок меньше данных, следовательно и сами запросы должны будут выполняться быстрее.

Проверим это на простых запросах на агрегацию:

-- Без LowCardinality
SELECT 
    category, 
    count() AS cnt
FROM test_string
GROUP BY category;

50 rows in result, 0.10 sec.
100.0%, Read 100.00 million rows, 2.38 GB

-- С LowCardinality
SELECT 
    category, 
    count() AS cnt
FROM test_low_cardinality
GROUP BY category;

50 rows in result, 0.02 sec.
100.0%, Read 100.00 million rows, 100.00 MB 
 

Запрос с LowCardinality выполнился в 5 раз быстрее и задействовал всего 100 MB RAM против 2.38 GB.

Вот и говорите потом, что LowCardinality не дает профита.

P.S. Главное правило: используйте LowCardinality только для полей с небольшим количеством уникальных значений (статусы, категории, типы). Для уникальных ID или URL он только навредит.

Ссылка на доку.

Мои статьи по ClickHouse на Хабре.

Если вы знакомы с ISA-L, Jerasure, Leopard-RS, klauspost/reed-solomon, то полагаю пояснений к картинке выше не нужно, вот ссылка -- забирайте.

Ну а теперь некоторые пояснения: выше перечислены известные библиотеки, реализующие коды Рида-Соломона под CPU для задачи стирания, т.е. у вас есть блоков, вы к ним добавляете еще блоков и получаете право потерять любые блоков из, РС код позволит восстановить потерянное. РС код состоит из нескольких рутин с многочленами, реализация за -- уровень сложного практического задания на курсе по вычислительной алгебре. В теории еще с 80-х годов было подозрение, что эти рутины можно полностью сделать на основе FFT, получить вычислительную сложность хотя бы и быстрый алгоритм на его основе. На практике с этим было много проблем, первая и по большому счету единственная практическая реализация со сложностью появилась в 2016 году в Leopard-RS на основе работы Лина-Чуна-Хана и соответствующего FFT-подобного преобразования (LCH transform). В этом году вышел обновленный алгоритм от авторов исходного подхода с улучшенным декодером, реализация доступна тут. Моя роль тут инженерная: я скрестил Leopard с XDRS, добавил GFNI, отполировал интерфейс и получил

• Совместимый с Leopard РС код с произвольными параметрами (Leopard только поддерживает только , у XDRS параметры должны быть степенями двойки)

• Выделенные интерфейсы для LCH преобразования и затьюненные вычислительные ядра под AVX2 и GFNI

• Ускорение по сравнению и с Leopard, и с XDRS

• Единый воспроизводимый бенчмарк

Спасибо за внимание

Четвёртый день Летнего ТехФеста — в нашем влоге

Мы встретились в пространстве Garage Eight, чтобы поговорить об AI для работы. Доклады, живые дискуссии и тёплая атмосфера — всё это мы засняли для тебя.

Смотри видео, чтобы погрузиться в событие!

Ещё больше о мероприятиях — в нашем TG-канале.

Digital Q.DataBase 18.2 | Выполняем Oracle-скрипты в DBeaver и qclient

В этом коротком видео я демонстрирую работу модуля Onyx в Digital Q.DataBase и выполнение PL/SQL-скриптов, написанных для Oracle Database.

► В основном примере (через qclient) выполняется полноценный PL/SQL-сценарий: создаётся таблица, объявляются PACKAGE и PACKAGE BODY с процедурами, используется отдельная функция и анонимный PL/SQL-блок.

В скрипте используются характерные для Oracle механизмы: NUMBER, VARCHAR2, CLOB, SYSDATE, DUAL, ADD_MONTHS, а также пакеты DBMS_LOB и DBMS_OUTPUT. Скрипт компилируется и выполняется непосредственно в модуле Onyx.

► Также показываю, что работать с Onyx можно привычным способом через DBeaver. 

Подключаемся к Digital Q.DataBase по характерному для Oracle порту 1521 и прямо из SQL-редактора выполняем обычный PL/SQL-скрипт: создаём таблицу employees_1, хранимую процедуру add_employee_1, вызываем её через CALL и проверяем результат обычным SELECT.

То есть для разработчика работа выглядит привычно: DBeaver, PL/SQL, процедуры, Oracle-типы и Oracle-синтаксис - но исполняется всё в Digital Q.DataBase Onyx.

Это позволяет переносить существующие Oracle-приложения и PL/SQL-код с минимальным объёмом изменений.

При этом для работы с Digital Q.DataBase можно использовать и привычные специалистам по Oracle инструменты: существующие средства администрирования, разработки и подключения могут работать с модулем Onyx через Oracle-совместимый интерфейс и порт 1521.

Видео также доступно на:
VK 
RuTube  
Dzen 
YouTube

► С 1 сентября 2026 года компания «Диасофт» переходит на новую лицензионную политику СУБД Digital Q.DataBase (до 4-х ядер бесплатно). 

🔹 Бесплатное получение дистрибутива: 
https://database.diasoft.ru/?utm_source=andrei
🔹 Документация: доступна внутри дистрибутива
🔹 Telegram-сообщество Digital Q.DataBase: https://t.me/dqdatabase
🔹 MAX: https://max.ru/channel_dqdatabase
🔹 RuDB : https://database.ru

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

СУБД, которая понимает диалекты Oracle, MS SQL и PostgreSQL,– без переписывания кода приложений.

Насколько хорошо вы знаете свой основной стек?

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

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

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

Можно оценить знания по направлениям:

— Java: язык, JVM, коллекции, многопоточность и практики разработки;
— Go: особенности языка, конкурентность, работа с памятью и создание сервисов;
— C# и ASP.NET: платформа .NET, веб-разработка и ключевые инструменты экосистемы;
— Rust: владение памятью, система типов и особенности безопасной разработки.

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

Java Professional •• Go Developer Professional •• ASP.NET •• Rust Developer

>> тесты по другим направлениям

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

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

В общем, писать софт для кибербеза с другими дедами мне пока рано. Слишком молодой специалист.

С 26 августа по 2 сентября на Бирже заказов Инфостарта появились новые задачи для разработчиков, консультантов и аналитиков 1С. Основные темы недели - маркировка, электронные перевозочные документы, интеграции и доработка конфигураций.

Среди новых заказов:

• Этикетка Wildberries для УТ 10.3

• Перепродажа маркируемой продукции между организациями

• Внедрение процессов в 1С:Документооборот 3.0

• Исправление загрузки госконтрактов из ЕИС

• Консультация по агрегации марок в УНФ

• Загрузка реквизитов из Excel и обмен с InSales

• Загрузка финансовой модели в 1С

• Поддержка Bluetooth-сканера в мобильной платформе

• Выгрузка товаров во Фронтол 6

• Разработка документа «Рекламация»

• Настройка «Контур.Логистики» для 1С:КА

• Загрузка цен ЖНВЛП с сайта ГРЛС

• Отображение цены в подборе 1С:Розницы 2.0.

• Подключение УНФ к «Честному знаку»

• Интеграция УТ 11 с расширением ESD от СБИС Настройка обмена между УТ 11.5 и 1С:Бухгалтерией.

• Настройка телефонии в Альфа-Авто 6

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

Digital Q.DataBase 18.2 | Выполняем MS SQL скрипты в DBeaver и Python

В этом коротком видео я демонстрирую, как Digital Q.DataBase 18.2 исполняет нативный T-SQL скрипт через DBeaver (в SSMS тоже делает), а также как те же объекты доступны из Python через библиотеку pymssql по протоколу TDS.

► В примере используются GO, SET DATEFORMAT, OBJECT_ID, sys.objects, INFORMATION_SCHEMA, вычисляемые столбцы, хранимые процедуры GetSalesReport и CalculateManagerBonus, а также их вызов из Python с обработкой нескольких наборов результатов.

Видео также доступно на:
VK 
RuTube  
Dzen 
YouTube

► С 1 сентября 2026 года компания «Диасофт» переходит на новую лицензионную политику СУБД Digital Q.DataBase (до 4-х ядер). 

🔹 Бесплатное получение дистрибутива: 
https://database.diasoft.ru/?utm\_source=andrei
🔹 Документация: доступна внутри дистрибутива
🔹 Telegram-сообщество Digital Q.DataBase: https://t.me/dqdatabase
🔹 MAX: https://max.ru/channel_dqdatabase
🔹 RuDB : https://database.ru

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

СУБД, которая понимает диалекты Oracle, MS SQL и PostgreSQL,– без переписывания кода приложений.

#DigitalQDataBase #Diasoft #MSSQL

Open-source-проект — это не просто код под открытой лицензией.

Недавняя покупка DuckLabs - создателя DuckDB, — вызвала немало обсуждений в сообществе разработчиков баз данных и не только (см., например, обсуждение на news.ycombinator.com). Вставлю и я свои пять копеек.

Относительно короткая история open-source уже научила нас тому, что настоящая сила таких проектов в разнообразии контрибьюторов и их искреннем желании двигать проект вперёд, которое растёт из глубокой внутренней мотивации. Другой источник силы - многолетняя верность проекту, порождающая пусть узких, но профессиональных инженеров. Такая специализация редко случается в корпоративном мире, где мы меняем работу раз в несколько лет.

Насколько я вижу как сторонний наблюдатель, до сих пор все ключевые решения в DuckDB принимала небольшая группа core-разработчиков. Внешних контрибьюторов немало (вспомним хотя бы команду MotherDuck), но само ядро принимающих решения «разнообразным» назвать трудно. Так что это был открытый код, но не open-source-проект в моём понимании - со всеми спорами, компромиссами, голосованиями и вообще той самой динамикой открытых сообществ.

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

Поэтому, на мой взгляд, AWS сделала умный ход: наняла разработчиков, а проект оставила открытым. Возможно, там читали свежие исследования на эту тему (см., например, Vasilescu et al., 2015 и Tamburri et al.) и хотят снизить риск «Death Spiral» для этого вполне себе оригинального проекта. Моя гипотеза: они таким образом пытаются подтолкнуть других игроков рынка вкладываться в проект.

Так это или нет - станет понятно из их дальнейших шагов: как быстро люди из других компаний начнут появляться в списке core-коммиттеров и в управлении проектом. Первый ориентир - технический консультативный совет, анонсированный при DuckDB Foundation. Если это случится скоро, а независимые новички действительно расширят проект - это будет новая страница в истории open-source-модели разработки. По крайней мере, той её части, которую знаю я.

Может таким макаром и bare-metal инженерные проекты также смогут получать поддержку больших компаний при использовании открытой модели разработки? Было бы любопытно иметь в открытом доступе полное КД на новую модель автоваза (без деталей реализации корпоративного форка, конечно) или паровой турбины ТЭС - а вы что думаете?

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

Главная выгода от использования единой экосистемы redb (RedBase) вместо разрозненных библиотек — это радикальное сокращение стоимости и времени разработки (Time-to-Market).

Автор спроектировал все четыре компонента (Core, Route, Tsak, Identity) так, чтобы они идеально знали друг друга «из коробки». Для бизнеса и разработчиков это дает пять ключевых преимуществ:

1. Архитектурная гармония (Один стек — один стиль)

В классическом .NET-приложении вам приходится собирать «зоопарк» из чужеродных технологий: Entity Framework для БД, MassTransit для очередей, Keycloak для авторизации и Hangfire для задач. Каждый инструмент имеет своего автора, свои правила.

• Выгода: В redb вся экосистема написана в едином стиле на чистом C#. Вы один раз понимаете логику работы фреймворка, и вам больше не нужно переучиваться при переходе от работы с базой данных к настройке безопасности или очередей сообщений.

2. Избавление от «инфраструктурного ада»

Чтобы начать enterprise-разработку по классическому пути, вам нужно развернуть десятки сервисов, настроить SQL-миграции, прописать Docker-контейнеры.

• Выгода: С RedBase вы забываете про SQL-миграции. База данных сама адаптируется под ваши C#-классы при старте. А благодаря встроенному серверу авторизации redb.Identity и движку redb.Route, вам не нужно разворачивать тяжелые внешние сервисы вроде Keycloak или Apache Camel — всё работает внутри единого .NET-процесса.

3. Колоссальная экономия времени на старте ( я бы выделил это отдельно)

Вместо того чтобы тратить первые недели (или даже месяцы) проекта на настройку авторизации, логирования, интеграционных шин и доступов к СУБД, разработчик использует готовые шаблоны dotnet new redb.

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

4. Экстремальная производительность (In-Memory мосты)

Когда ваши микросервисы общаются между собой, они обычно гоняют трафик по сети через HTTP или gRPC, что тратит ресурсы процессора и создает задержки (latency).

• Выгода: Компоненты экосистемы redb общаются друг с другом в памяти одного процесса через специальный direct-vm - мост (redb.Route.Core). Например, проверка прав пользователя в Identity или передача сообщения в шину Route происходит мгновенно, без сетевых задержек.

5. Снижение стоимости владения и поддержки (Zero-Key Pro)

Многие современные фреймворки завлекают бесплатной базовой версией, но требуют огромных денег за коммерческие «Pro»-функции (кэширование, массовые операции, аудит).

6. DevOps-рантайм готовый к эксплуатации (redb.Tsak): Этот компонент полностью закрывает вопросы девелопмента и поддержки в проде. Он предоставляет готовый кластерный контейнер для Kubernetes с нативными пробами, сбором метрик (OpenTelemetry/Prometheus) и встроенным веб-дашбордом. Самая крутая фича для админов — Hot-Reload модулей без перезапуска процесса, что позволяет обновлять бизнес-логику на лету, не теряя сообщения «в полете» и давая возможность дежурному вручную «переигрывать» упавшие транзакции прямо из панели управления. Как микросервисом так и монолитом, или можно собрать свою версию.

• Выгода: Все Enterprise-пакеты экосистемы RedBase с приставкой .Pro являются абсолютно бесплатными. Вы получаете оптимизированные bulk-операции, продвинутый трекинг изменений и кэш без покупки лицензионных ключей.

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

Если было полезно, ⭐ на GitHub поможет другим это найти.

Другие мои статьи — redb.ru/articles, ещё — на Хабре.

Заманчивая вакансия на Python‑раба от владельца‑вайбкодера

Она довольно внушительная, LLM не поскупилась на требования к кандидату, но если кратко:

• нужен один разработчик

• весь бэкенд нужно построить с нуля, так как сейчас он держится на решениях из го*на и гугл таблиц

• весь свой опыт в разработке специалист должен описать в х*евоей горе.md файлов, чтобы владелец мог управлять проектом с помощью Cloude Code без разработчика

• агентный слой из роя агентов в проде тоже очень надо

• фронтенд на next.js тоже очень надо

• работать напрямую с владельцем, но он не технарь, поэтому важен опыт создания технической х*ни для «нетехнических» людей

• Cloude Code, Cloude Code, Cloude Code

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

Так выглядит рынок нанимателя 2026.

И так...

Две статьи с полным разбором найма в IT позади (раз, два), цифры и графики посмотрели. Но всё равно, статистика это конечно хорошо, но пока не натыкается на живого человека с конкретной историей.

Я запустил сбор реальных историй найма в IT-шечку))

У меня уже есть несколько крутых историй: Ветеринар, который дорос до дата-аналитика в банке и застрял на "теневом айти", тимлид, которого молча назначили руководить отделом, системный аналитик, прошедший 5 кругов собеса в Т-Банке только чтобы услышать "мы взяли внутреннего кандидата" и рассказ о том как устроен коучинг в найме IT, за полторы месячные зарплаты!!!. Всё это не укладывается ни в какую аналитику.

По этому:

Хочу собрать из таких историй отдельный материал, что-то вроде "IT-найм 2026 года глазами тех, кто через него прошёл".

Так что если за последние полгода ты искал работу в IT, удачно или нет (не важно) - напиши мне в личку.

Конечно же я всё обезличу)) Шаблона нет, по этому в свободной форме, вот как душа захочет рассказать так и рассказывайте... Примерно публикацию планирую на 14-ое сентября)

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

PostgreSQL 18, локальные LLM, ClickHouse и Playwright: что разобрать на этой неделе

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

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

В посте собрали бесплатные уроки этой недели по PostgreSQL 18, ClickHouse, локальным LLM, Playwright, Linux, ML‑системам и другим темам. Можно выбрать направление под текущую задачу и посмотреть, как с ним работают на практике.

AI, ML и автоматизация

• 31 августа, 20:00. «Построение программ без кода: создание умного помощника и автоматизаций в n8n». Записаться
  _{Соберём AI‑помощника и автоматизации без кода.}

• 1 сентября, 20:00. «Практическое применение нейросетей для моделирования процессов». Записаться
  _{Разберём нейросети для работы с бизнес‑процессами.}

• 3 сентября, 20:00. «Как руководителю внедрить ИИ в работу команды: от выбора процесса до рабочего сценария». Записаться
  _{Пройдём путь от идеи до рабочего AI‑сценария.}

• 3 сентября, 20:00. «Локальные LLM‑модели для разработки». Записаться
  _{Разберём запуск и применение локальных LLM.}

• 7 сентября, 18:00. «Учимся готовить данные для ML‑моделей». Записаться
  _{Подготовим данные к обучению ML‑моделей.}

• 7 сентября, 20:00. «Почему 90% ML‑проектов не доходят до продакшена? Разбираем архитектуру настоящей ML‑системы». Записаться
  _{Разберём архитектуру production‑ready ML‑системы.}

Базы данных и бэкенд

• 1 сентября, 20:00. «PostgreSQL 18: асинхронный I/O и io_uring на практике». Записаться
  _{Посмотрим, как работает асинхронный I/O в PostgreSQL 18.}

• 3 сентября, 20:00. «Векторный поиск в ClickHouse». Записаться
  _{Разберём возможности векторного поиска в ClickHouse.}

• 3 сентября, 20:00. «ASP.NET Core API под нагрузкой: как сделать сервис устойчивым к сбоям и росту трафика». Записаться
  _{Поговорим об устойчивости API под нагрузкой.}

Тестирование

• 2 сентября, 20:00. «ИИ для тестировщика: инструменты, которые уже меняют профессию». Записаться
  _{Посмотрим на AI‑инструменты для задач тестирования.}

• 3 сентября, 20:00. «UI и API‑тестирование с Java и Playwright». Записаться
  _{Разберём автоматизацию UI‑ и API‑тестов.}

Linux и системное программирование

• 3 сентября, 19:00. «Первый веб‑сервер на Linux: Nginx, Apache и проверка доступности». Записаться
  _{Поднимем и проверим первый веб‑сервер на Linux.}

• 7 сентября, 20:00. «Linux для Windows‑администратора за 60 минут». Записаться
  _{Разберём базовые инструменты Linux через знакомые аналогии.}

• 7 сентября, 20:00. «Работа с памятью на языке C». Записаться
  _{Поговорим об указателях и управлении памятью.}

1С и бизнес‑анализ

• 2 сентября, 20:00. «Как аналитику выбрать решение 1С для автоматизации казначейства: сравниваем 1С:ERP, 1С:УХ и 1С:ERP.УХ». Записаться
  _{Сравним решения 1С для автоматизации казначейства.}

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

Все ближайшие открытые уроки собраны на одной странице в дайджесте.