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

Про Self-Contained Systems часто говорят на уровне принципов: автономность, изоляция, отказоустойчивость. Но как понять, что эти идеи действительно работают в ландшафте из сотен и тысяч приложений, а не остаются красивыми словами в архитектурных гайдах? В статье показан практический подход, как превратить архитектурные принципы в ежедневные измеримые проверки и управлять трансформацией к SCS на уровне всей организации, опираясь на данные, а не на ощущения.

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

Привет, Хабр! Вы когда-нибудь обновляли ноду Kubernetes-кластера и замечали, как несколько ваших подов сразу пропали в процессе? Не самое приятное ощущение, верно?

Запускаете плановое обновление, kubectl drain начинает выгонять поды с ноды, и вдруг сервис теряет половину реплик. Клиенты начинают получать ошибки. Что пошло не так? Вы забыли про PodDisruptionBudget.

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

Сегодня я расскажу про библиотеку Python River, которая позволяет обучать модели машинного обучения в потоковом режиме.

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

Новые пользователи приходят каждый день, события генерируются каждую секунду. Модель в продакшене устаревает, если не переучивать её регулярно. Переобучение с нуля нарастающим объёмам данных — удовольствие ниже среднего: долго, ресурсозатратно, да и не всегда возможно, если данные бесконечны (например, поток кликов или показателей датчиков).

Привет!

Если вы администрируете PostgreSQL или хотя бы раз пытались понять, почему ваш отчёт выполняется полчаса, то наверняка натыкались на интересную настройку work_mem. Одна строчка в конфиге, а может превратить черепашку в гепарда. Или наоборот, положить сервер.

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

Cегодня разберём экспериментальную фичу Kotlin 2.2 — контекстные параметры. C помощью контекстных параметров функции и свойства могут объявлять зависимости, которые неявно передаются при вызове.

Допустим, есть сервис логирования UserService, который нужно часто передавать во многие функции. Без контекстных параметров пришлось бы всюду писать fun outputMessage(users: UserService, msg: String). С параметрами контекста достаточно объявить функцию так:

Flaky-тесты — это вполне измеряемая форма недетерминизма, вокруг которой в исследованиях накопился свой язык. В разных статьях одни и те же слова могут означать чуть разное: где-то считают переходы pass↔fail, где-то смотрят на энтропию истории прогонов, где-то обсуждают карантин и компромисс FR против LFD. В этой статье — короткий словарь самых ходовых терминов, чтобы говорить о нестабильности тестов точным языком.

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

Сегодня я расскажу, как можно улучшить проекты с помощью Git‑хуков в среде 1C:EDT. Если вы разрабатываете на «1С:Предприятии» и используете Git, но еще не подружились с хуками, самое время это сделать.

В экосистеме 1С исторически существовало собственное хранилище кода, и Git долгое время казался чужаком. Но прогресс не стоит на месте, сейчас 1C:Enterprise Development Tools умеет работать с Git по дефолту, поддерживает групповую разработку и Git‑хуки. Хуки — это скрипты, которые автоматом выполняются при наступлении определенных событий в репозитории: коммит, пуш, слияние и так далее.

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

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

Сегодня поговорим про один из самых незаметных, но любопытных моментов языка C. Если вы пишете на C, скорее всего вы никогда не использовали ключевое слово restrict. А зря — этот квалификатор указателя может дать вашему коду неплохой прирост производительности. Правда, для этого придётся дать компилятору честное слово насчёт своих указателей.

Разработка сервисов с интеграцией в AWS быстро упирается в компромиссы: либо работать с реальным облаком и платить за каждый эксперимент, либо замокать инфраструктуру и надеяться, что в продакшене всё «взлетит». В статье показано, как с помощью .NET Aspire и LocalStack выстроить полноценное локальное AWS-окружение — с S3, CDK и реальной оркестрацией — так, чтобы один и тот же код без условностей работал и локально, и в проде.

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

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

Для того, чтобы решить эту проблему, мы построим простую систему RAG (Retrieval-Augmented Generation) – в которой генеративная языковая модель (LLM) получает доступ к внешним источникам информации для улучшения точности и достоверности ответов. То есть, вместо того чтобы использовать только внутренние знания модели, RAG будет обращаться к внешним источникам: базам данных, текстовым архивам и другим.

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

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

Сегодня поговорим о событиях в Solidity — одном из важных механизмов, с помощью которого смарт‑контракты общаются с внешним миром. Если вы интересиовались разработкой на Ethereum, то наверняка слышали про события: например, каж��ый токен ERC-20 при трансфере генерирует событие Transfer, благодаря чему кошельки и блоксканеры сразу видят движение токенов. Но что же такое events, как они работают и как их правильно использовать?

Планировщик Linux долгое время оставался зоной, куда можно было заглянуть, но почти невозможно вмешаться без пересборки ядра. С появлением sched_ext эта граница сдвинулась: теперь логику планирования можно описывать кодом на C и загружать в ядро через eBPF. В статье разберём минимальный рабочий планировщик, посмотрим, как он взаимодействует с ядром, и обсудим, какие новые возможности это открывает для экспериментов и диагностики поведения системы под нагрузкой.

Привет, Хабр! Cегодня рассмотрим, как ускорить интеграционные тесты в Spring Boot с помощью специальных slice аннотаций.

Начнём с того, почему вообще тесты могут быть медленными. Используя @SpringBootTest, мы просим Spring Boot поднять весь контекст приложения для каждого тестового класса. У нас доступны все бины, но часто все это избыточно. Например, хочется протестировать контроллер, а Spring загружает ещё и базу данных, и сервисы, и шлёт запросы к Kafka. В результате простой тест метода контроллера может запускаться несколько секунд, пока поднимется веб‑сервер, инициализируется база, подтянутся все классы.

Эту проблему осознали и добавили так называемые test slice‑аннотации. Все простоб грузим не весь контекст, а только срез приложения, например, только веб‑слой или только слой доступа к данным. Spring Boot содержит готовые slice‑аннотации для основных слоёв: @WebMvcTest для веб, @DataJpaTest для JPA‑репозиториев, и ещё пачку для других случаев.

Рассмотрим на примерах двух интересных слайса: @DataJpaTest и @WebMvcTest.

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

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

В 1980-м Intel 8087 превратил «плавающую точку» из мучения в рабочий инструмент для IBM PC — и заодно задал архитектурные решения, отголоски которых мы чувствуем до сих пор. В этой статье автор делает то, что обычно остаётся за пределами даташитов: вскрывает 8087, фотографирует кристалл и по слоям восстанавливает, как физически реализованы стековые регистры x87 и логика, которая двигает вершину стека, адресует ST(i) и ловит переполнения. Это разбор на уровне транзисторов, где дизайн ISA встречается с RC-задержками, SRAM-матрицами 8×80 и микрокодом, который реально «крутит» железо.