Добрый день, Хаброжители!

Стартовала июльская распродажа от издательства «Питер».

Лето – время для отдыха, приключений и, конечно, для новых книг!

Как получить прозрачность в бизнес-процессах, если архитектура строится на микросервисах и событийных потоках? В своей статье Бернд Рюкер, сооснователь Camunda, делится практическими подходами к отслеживанию и управлению процессами в распределённых системах. Он объясняет, как переход от простого мониторинга событий к полноценной оркестрации помогает лучше понимать происходящее, своевременно реагировать на инциденты и сохранять контроль над сложными бизнес-операциями. В статье разбираются плюсы и минусы различных подходов — от Elastic-подобного мониторинга до использования движков рабочих процессов, а также рассматривается важность баланса между оркестрацией и хореографией.

Очень часто в проектах необходимо использовать передачу сообщений между компонентами распределенной системы по определенным правилам. И перед разработчиком встает вопрос — какой инструмент наиболее эффективно можно использовать для этого? И сегодня мы рассмотрим брокер сообщений, который позволяет это делать «прямо из коробки» и это будет RabbitMQ.

RabbitMQ — это популярный брокер сообщений, который реализует стандарт AMQP и который позволяет эффективно управлять коммуникацией между сервисами через очереди. И в этой статье мы разберем основные типы обменников (exchange): Direct, Topic, Headers и Fanout, которые напрямую участвуют в процессе маршрутизации, а также приведем примеры их настройки в Spring Boot.

Меня зовут Михаил, я работаю в Magnit Tech и занимаюсь внедрением 1C платформы на операционную систему Linux. В этой статье я расскажу, как реализовать создание резервных копий бакетов S3-совместимого объектного хранилища MinIO.

(Сразу дам спойлер: нам удалось это сделать с наименьшими затратами места на диске с использованием инкрементальных бэкапов).

Привет!
Задумывались, какую версию квантованной LLM выбрать: Q4_K_M, Q6_K или Q8_0? Насколько Q6_K хуже справляется с задачами по сравнению с Q8_0? И что вообще означают все эти буквы в суффиксах?

Примечание: это адаптированный перевод моей статьи на Medium. Перевод был сделан при помощи мозга, а не нейросетей или Google Translate.

И один падающий лист предвещает наступление осени.

Японская пословица.

Самурай без меча подобен самураю с мечом, но без меча.
Японская пословица.

Больные одной болезнью симпатизируют друг другу. Несчастные понимают друг друга.

Японская пословица.

Привет, Хабр! Вы — трудоголики? А как вам тот факт, что отдых больше помогает работе, чем лишний час перед ПК? И что, на самом деле, вы работаете, когда гуляете, нежитесь в ванной или режете морковь. И что это куда продуктивнее, чем сидеть в IDE или Confluence. Звучит немного парадоксально: как отдых может помочь быть более продуктивным в работе? 

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

Минцифры кричит о нехватке миллиона IT-специалистов, министр труда и социальной защиты заявляет о «всего» ста тысячах. Параллельно рынок труда захлестнула волна сокращений. А тут ещё и слухи об AGI — суперумном ИИ, который захватит все рабочие места. Парадокс? Нет, скорее болезненная трансформация от иллюзий к реальности. 

На связи CEO Surf Владимир Макеев. Я в разработке с 2011 года, почти с самых истоков развития мобильных приложений в РФ. Сегодня поделюсь своим взглядом на то, как накопленный кризис управленческих иллюзий повлиял на IT-сферу и почему за последний год уволили так много специалистов. И как на ситуацию влияет развитие ИИ, который может заменить разработчиков.

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

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

🔰 ЦЕЛЬ: Создать разработчика, который является архитектором и оптимизатором сложных систем, способным эффективно использовать ИИ как мощный инструмент, но не зависящим от него для критических инженерных решений.

Всем привет, меня зовут Стас, я техлид в Mish Product Lab.

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

Именно так родилась идея провести сравнительный анализ производительности HAProxy, Envoy, Nginx, Caddy и Traefik с поддержкой SSL/TLS. Мы хотели понять, какой из инструментов «из коробки» предоставляет наилучшую производительность и минимальные накладные расходы, особенно при обработке SSL-трафика, который, как известно, требует дополнительных ресурсов из-за шифрования и дешифрования.

Сколько себя помню, меня всегда привлекали счётчики памяти в Linux: смотришь в условный htop – в плане потребления CPU вроде всё +/- понятно, а вот память всегда считалась как-то не так, как ты это на первый взгляд ожидаешь, и долгое время у меня было довольно наивное и ошибочное представление о механизмах её работы.

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

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

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

На первых порах разработчики часто реализуют флаги «локально» – в виде переменных конфигурации, констант или параметров в коде приложения. Такой локальный флаг хранится и меняется непосредственно в приложении (или на сервере, где оно запущено). Этот подход может сработать в небольшом проекте, но в масштабе команды и множества окружений у него быстро обнаруживаются недостатки. Во-первых, если значение флага жёстко прописано в конфигурации или коде, для его изменения зачастую требуется выкатывать новую версию приложения (то есть делать повторный деплой). Возможность динамически «покрутить тумблер» теряется, и смысл фич-флагов частично сводится на нет. Во-вторых, появляется рассинхрон между окружениями: например, в продакшене новый флаг включён через удалённую конфигурацию, а в тестовой сборке по умолчанию выключен. В итоге тестировщикам приходится вручную приводить локальные значения флагов в соответствие с продакшеном, что неудобно и чревато ошибками. Кроме того, без общего подхода трудно отслеживать, какие флаги существуют в системе, кто и когда их включал, и на что они влияют.

Привет, Хабр! Я Оля Жучкова, живу в Казани, в МТС работаю Cluster lead Data Steward. А еще у меня есть любимое хобби — северная ходьба. Обычно, когда это говорю, собеседники улыбаются и записывают меня в пенсионерки. Вот поэтому сегодня хочу подробнее рассказать о своем увлечении и развеять миф о «бабушкином спорте».

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

В новой статье из цикла «Как жить без IntelliJ IDEA» команда Spring АйО изучила альтернативы DB‑клиенту от JetBrains, входящему в состав Ultimate и полюбившемуся многим разработчикам.

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