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 и микрокодом, который реально «крутит» железо.
Всем привет! Заключительная часть о требованиях, которые вспоминают в последний день перед релизом.
В первой части мы говорили о производительности и масштабируемости, во второй — о сопровождаемости, надёжности и безопасности.
Сегодня в повестке требования, которые влияют на пользовательский опыт и ощущение качества продукта. Да, вы верно догадались, речь про юзабилити, совместимость и переносимость.
Продакшен не ломается «в целом» — он ломается в логах, сетевых правилах, бэкапах и одном неудачном деплое. Поэтому в этом дайджесте собрали образовательные ресурсы на темы, которые реально держат систему на плаву: CI/CD в GitLab, платформа на Kubernetes, observability без хаоса, сеть и безопасность. В конце — статьи, которые хабровчане уже проверили на прочность своим вниманием.
В 2010 году в C# 4.0 появилось ключевое слово dynamic. Тогда казалось, что это очень круто — наконец‑то можно обойти строгую типизацию там, где она откровенно мешает. Прошло пятнадцать лет, и эйфория давно улеглась. Теперь dynamic воспринимается скорее как специализированный инструмент с узкой областью применения.
Привет, Хабр!
Прошел все технические этапы, решил задачи на алгоритмы, обсудил архитектуру, показал опыт — и вдруг отказ. Без объяснений, с размытой формулировкой про «другого кандидата» или «культурное несоответствие». Знакомо?
Техническая часть — это только входной билет. Финальный раунд решается по совсем другим критериям. Разберем, что влияет на решение после успешной техсекции.
Декларативные шаблоны Vue решают 90% задач фронтенда. Но периодически возникают ситуации, где шаблонного синтаксиса оказывается мало. Нужен более тонкий контроль над рендерингом или возможность вынести часть компонента за пределы его естественной позиции в DOM-дереве. Для таких случаев Vue 3 послал нам render-функции и встроенный компонент Teleport.
В версии 8.4 наконец‑то появилась одна из тех фич, о которых давно мечтали многие, — хуки свойств. Что это такое? По сути, это встроенные механизмы get/set для свойств объектов, которые позволяют добавить свою логику при чтении или записи значения прямо внутри определения свойства. Никаких больше громоздких геттеров и сеттеров, никаких загадочных get и set, теперь всё можно сделать красиво и понятно на уровне самих свойств.
Внедряя системы класса Business Intelligence (BI), приходилось в проектах разрабатывать систему показателей для различных бизнес-процессов. Почему пришлось создать данный подход? Потому что представители заказчика часто не могли сформулировать перечень ожидаемых показателей по процессу, и поэтому пришлось проектировать систему показателей для анализа процесса за них. Подробнее про показатели процессов и основные определения (бизнес-объект, метрика, аналитический разрез и показатель) можно прочитать в моей ленте ранее. В данной статье хочу «спуститься» от системы показателей по процессу к структуре данных на примере процесса подготовки коммерческого предложения.
В качестве примера приведу систему показателей процесса разработки коммерческого предложения для продажи услуг в области обучения на рынке B2B. Сразу хочу сказать, что процесс не оптимален, но для данного примера он необходим для погружения в предметную область.