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

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

Простых и понятных примеров на Python тоже мало, так как они заставляют вас вникать не только в особенности различных вариантов маршрутизации RabbitMQ, но и в особенности используемых библиотек. Для человека, который видит что-то pika-подобное первый раз, это может быть испытанием.

Поэтому я и решил написать эту статью: она нацелена на "чайников" - вы легко можете показать ее вашим джунам, и этого уже должно быть достаточно для начала работы с RabbitMQ.

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

Часть 1
Часть 2
Часть 3
Часть 4

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

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

Привет, Хабр! Меня зовут Алексей Колосков, я DevOps/Cloud-инженер в Hilbert Team. Вместе с моим коллегой Михаилом Кажемским в этой статье мы расскажем об особенностях DevSecOps-пайплайна и концепции Shift Left. Вы узнаете об основных этапах DevSecOps-пайплайна, автоматизированных проверках безопасности при разработке ПО, бесплатных и опенсорс-инструментах. Также найдёте советы, которые помогут раньше обнаруживать уязвимости и улучшать безопасность приложения. 

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

Есть такие ребята — SRE (с англ. Site Reliability Engineering), которые выросли из старых добрых и бородатых системных администраторов. Но они устали заниматься ежедневной рутиной и решили всё автоматизировать. Именно поэтому 50% времени SRE пишут код.

Глобальный каталог LDAP стал неотъемлемой частью современной ИТ инфраструктуры любой крупной организации. Сама технология каталога LDAP у большинства плотно ассоциируется с Active Directory от Майкрософт. Однако сейчас все больше организаций пытаются уйти от решений данного вендора и перейти на софт с открытым исходным кодом.

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

Введение

На плате Alchitry Cu выделена FPGA Lattice iCE40 HX	На плате Alchitry Au выделена FPGA Xilinx Artix 7

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

• для синхронизации файлов на разных устройствах,
• дедупликации,
• резервного копирования,
• сжатия.

Модульный монолит — это подход к проектированию приложений, который позволяет, с одной стороны, отложить во времени операционную сложность использования микросервисов, а с другой — избежать превращения монолитной системы в большой комок грязи. Сама идея модульности не нова и основана на давно известных принципах Separation of Concerns и Information Hiding. Но не так-то просто перейти от абстрактных принципов к пониманию, как их реально использовать на практике.

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

Я работаю тимлидом уже несколько лет и с уверенностью могу сказать, что это направление развития мне очень нравится. А помню, я чуть не запорол свою карьеру тимлида в самом начале, на переходном этапе разработчик - тимлид. Я тогда работал разработчиком в большой компании и, в общем, работа мне нравилась. У нашей команды был номинальный тимлид - хороший, душевный человек, которому очень нравилось ковыряться в своих железках, а в жизни команды его участие ограничивалось только вопросами на дейлике “как дела?”. В общем, проблемы в команде копились, и никто ими не занимался, и меня это беспокоило. В итоге мне предложили попробовать себя тимлидом. Я эту историю рассказываю к тому, что я начинал свой путь с огромном воодушевлением, но уже через 3-4 месяца я почти выгорел и хотел вернуться в разработку или вообще уволиться. Поразмыслив тогда, я решил, что не могу так бесславно уйти и должен попытаться разобраться в ситуации и найти другое решение. Я сформулировал 4 основные причины такого быстрого выгорания, которое случилось со мной на этом переходном этапе. Мне удалось найти решение этих возникших трудностей и продолжить работу.

Итак, четыре проблемы начинающего тимлида.

g++ -o test1 test1a.o test1b.o
test1a.o(.text+0x18): In function `main':
: undefined reference to `findmax(int, int)'
collect2: ld returned 1 exit status

Приветствую!

На прошлом шаге мы дошли до входной точки Postgres. Сегодня мы пройдемся по ней до главного цикла. Будут рассмотрены:

— Модули для работы с файлами и файловой системой

— Как SIGUSR1передает множественные значения

— Реализации хэш‑таблиц

— Представление и хранение GUC

и многое другое.

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

Процессоры с P и E ядрами появились сравнительно недавно и как с ними уживаться все еще ломают голову разработчики.

Однако на самом деле эта дискриминация на первоклассные и второсортные ядра процессора появилась еще раньше. И пришлось изобретать свои костыли, чтобы важное запускалось на быстрых, а неважное на медленных ядрах.

Речь идет о турбо частоте. Суть в том, что практически у любого процессора базовая частота не имеет никакого значения. В режиме энергосбережения частота может быть сильно ниже базовой, а под полной загрузкой всех ядер частота также немного выше базовой (all core turbo). И конечно же, при условии отсутствия нагрузки на других, одно или несколько ядер могут повышать частоту еще выше до значения turbo.

Однако есть линейки процессоров (в частности это Xeon E5 v4), у которых определенные ядра ни при каких условиях не могут поднять частоту выше all core turbo. Будем называть их "медленными".

Программные брокеры сообщения уже стали стандартом при построении больших и сложных систем. Однако до сих пор не все ИТ-специалисты понимают, как работают эти инструменты. Главный системный аналитик «Иннотех» Павел Малыгин помогает разобраться в брокерах сообщениях и их работе.