Когда проект только стартует, в воздухе витает амбиция - Мы обязательно сделаем всё правильно. Чистая архитектура, ясные зоны ответственности, аккуратные контракты между сервисами, но реальность не знает о ваших планах.

Не потому, что кто-то не знал паттернов проектирования или выбрал не ту СУБД, а потому бизнес требует фичи "на вчера". И шаг за шагом архитектура сдаёт позиции. Что самое интересное - разрушение происходит незаметно. Никакого взрыва вертолетов на заднем фоне не будет. Только десятки небольших компромиссов, которые за относительно короткое время могут превратить систему в клубок боли. Тихо и буднично. Конечно, количество спринтов будет больше трех, но основной сути это не меняет.

Поэтому подготовил для тебя, системный аналитик (и не только), гайд “Как убить архитектуру за три спринта” даже если в начале все было относительно под контролем. Чтож… Щас выскажусь!)))

19 марта 2025 года вышла стабильная версия Valibot — библиотеки для валидации данных в JavaScript/TypeScript. Разработанная как альтернатива популярному Zod, она сочетает минималистичный дизайн с мощными возможностями.

В этой статье мы сравним Valibot и Zod по трём ключевым параметрам: синтаксису API, размеру библиотеки и скорости работы. Вы узнаете, чем эти решения отличаются друг от друга и почему стоит использовать специализированные инструменты валидации входящих данных.

Когда-то я относился к документации по-старому: написал – и забыл. Думаю, многие разработчики меня поймут. Традиционный подход зачастую сводится к тому, что документацию пишут в конце проекта или от случая к случаю, а затем она покрывается пылью. В эпоху Agile и DevOps такой подход не работает: изменения в коде происходят постоянно, и статичные тексты не успевают за ними. В результате документация стремительно устаревает, вводя команду в заблуждение и порождая ошибки​. Настала пора пересмотреть взгляд на эту часть разработки.

Хочу поделиться тремя подходами, которые кардинально изменили мой подход к документации. Это Continuous Documentation (непрерывная документация), MVD (Minimum Viable Documentation) – минимально жизнеспособная документация, и «документация как продукт». Каждый из них появился как ответ на боль, с которой мы сталкивались в гибкой разработке: как держать документацию актуальной, достаточной и полезной для пользователей. Расскажу о каждом по порядку – на примерах из собственного опыта, с живыми кейсами и свежими идеями. Возможно, эти подходы перевернут и ваше представление о том, какой должна быть документация в современных проектах.

Почему инвесторы аплодируют убыточным компаниям, а прибыль вызывает раздражение? Разбираемся, как работает парадокс «прибыльных убытков» на примерах ВКонтакте, Ozon и Amazon. Что отличает стратегические инвестиции от банального сжигания денег, можно ли перенести эту модель в офлайн-бизнес — и почему не стоит повторять путь WeWork.

О полезных функциях и процессе установки GrapheneOS - одной из самых безопасных мобильных операционных систем.

Хочу начать с личной предыстории. Давным‑давно, как и многие из вас, я читал умные книжки: «Чистый код» и «Чистая архитектура» Роберта Мартина, «Совершенный код» Стива Макконнелла и другие.

Также не обошли меня и классические принципы проектирования — SOLID, KISS, DRY — и, думаю, каждый читатель добавит сюда свои.

Безусловно, это всё важные и фундаментальные вещи.

Но однажды на горизонте появилось DDD — предметно‑ориентированное проектирование в изложении Эрика Эванса. Именно его «синяя книга» стала культовой и задала язык для архитектурного мышления.

Позже я открыл и «красную книгу» Вона Вернона, где DDD уже рассматривался с точки зрения практической имплементации: архитектура, код, реальные подходы в проектах.

Читая Эванса, рассматривая его диаграммы классов и примеры кода, я всё думал: как он это делает?

Самым большим открытием для меня стало то, что книга DDD хоть и показывает стратегические и тактические приёмы — агрегаты, объекты‑значения, спецификации, фабрики и т. д. — но не учит проектировать саму предметную область.

Складывалось ощущение, что мы это уже откуда‑то должны были знать. А откуда — остаётся загадкой.

Хочу поделиться с сообществом свой наработкой по мониторингу бэкапов PostgreSQL.

Для того чтобы делать сами бэкапы, используется сторонний open source инструмент pg_probackup (разработка компании Postgres Professional).

Этот инструмент умеет делать инкрементные бэкапы, а также автоматизирует сопутствующие процессы, такие как, сжатие данных, merge, удаление старых бэкапов и wal-файлов.

Остается проблема мониторинга. Предположим, мы настроили pg_probackup и он трудится упорно, вызываемый регулярно через cron.

Как мы узнаем, о том, что что-то сломалось?

Для решения этой проблемы был написан небольшой экспортер метрик pg_probackup для Prometheus.

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

Глубокое копирование в JavaScript всегда было немного проблемой. До тех пор, пока в языке не появился structuredClone() — метод, который решил многие наши проблемы.

🚀 Qwen2.5-Omni — революция в мире искусственного интеллекта!

Представьте AI, который понимает не только текст, но и изображения, звуки и даже речь — и делает это мгновенно, в режиме реального времени! Qwen2.5-Omni от Alibaba Group — это прорывная мультимодальная модель, которая объединяет все эти возможности в единую мощную систему.

✨ Почему это меняет всё?
✅ Полная мультимодальность — обработка текста, изображений и аудио в одной архитектуре.
✅ Мгновенное взаимодействие — потоковая передача данных без задержек.
✅ Универсальность — идеально подходит для чат-ботов, анализа медиа, голосовых ассистентов и многого другого!

Хотите узнать, как Qwen2.5-Omni превосходит конкурентов и какие уникальные возможности предлагает?

Читайте наш технический обзор и убедитесь сами — это будущее AI уже здесь!

Как я отказался от оверинжиниринга и переместился с 30 места на 7 в Enterprise RAG Challenge. И чего не хватило до 1 места.

Сейчас облась ИИ – дикий запад. Никто не знает, как правильно решать задачи, а результаты экспериментов лежат приватными под NDA. Тем ценнее, когда кто-то делится реальным опытом с разбором деталей и подводных камней. Так что делюсь с хабром своей мартовской статьей про участие в Enterprise RAG Challenge от Рината LLM под капотом

Если вы интересуетесь разработкой продуктов поверх LLM, то

Миллионы пользователей ежедневно заходят на Яндекс Маркет. И одна из ключевых задач сервиса — показывать им точные сроки доставки на поиске и в корзине. При пиковых нагрузках это около 40 тысяч запросов в секунду. Как обеспечить столь быструю и точную обработку данных о доставке?

Привет, Хабр! Меня зовут Никита Деревянко. Я руковожу разработкой логистической платформы Яндекс Маркета. Люблю играть в шахматы, бильярд и программировать. Изучаю японский язык, чтобы тренировать мозг и смотреть аниме в оригинале. Расскажу о том, как построить логистический runtime на Go, не являясь Golang-разработчиком. Рассмотрим, как справиться с большим объёмом данных и какие преимущества может (или не может) предложить Golang для масштабной задачи.

В 2ГИС мы знаем: лучшие продукты создаются вместе с пользователями. Уже почти 7 лет наше комьюнити помогает нам дополнять и актуализировать справочник. Мы называем этих людей спецагентами — они уточняют информацию, пишут отзывы, добавляют фотографии и делают 2ГИС удобнее для миллионов пользователей. 

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

• плохая работа в офлайне;
  
• отсутствие поддержки lossless;
  
• абонентская плата;
  
• неполная фонотека;
  
• многое другое...

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

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

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

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

В этой статье быстро разберём, как устроен PostgreSQL – от хранения данных в Heap и работы с FSM/VM до создания своего FDW с компрессией на базе zlib.

Go 1.24 привнес в язык новый тип указателей – слабые указатели (weak pointers). В этой статье разберёмся, что они из себя представляют, как устроены внутри компилятора и runtime, а также как их использовать для оптимизации кода. Мы подробно изучим внутреннее устройство новых указателей, примеры их применения (например, для создания самоочищающихся кешей) и посмотрим, как они работают под капотом с точки зрения управления памятью и производительности.

Привет! Я Дима Стоянов, MLE в команде разработки фундаментальных моделей. Мы продолжаем рассказывать о наших моделях T-lite и T-pro. Общие характеристики и результаты бенчмарков описывали в предыдущей публикации. В этой статье раскроем детали предобучения: от подготовки данных до финальных экспериментов, а совсем скоро поделимся особенностями этапа post-training.

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

Всем привет! Меня зовут Сергей Хорошеньких, я руковожу службой исследований и разработки в Яндекс Доставке. Наша команда изучает и внедряет алгоритмы, которые повышают операционную эффективность сервиса.

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

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