В современном мире разработка программного обеспечения стала неотъемлемой частью бизнес-процессов, требующей не только высокой производительности, но и надежной защиты от угроз безопасности. В этом контексте DevSecOps выступает как ключевая парадигма, интегрируя принципы безопасности непосредственно в процессы разработки и поставки. Особое внимание уделяется инструментам, способствующим обеспечению безопасности приложений на каждом этапе их жизненного цикла. В данной статье мы сосредоточим взгляд на сочетании двух мощных технологий — Kubernetes и SonarQube, и рассмотрим, как их совместное использование в рамках DevSecOps способствует созданию надежных и безопасных решений.

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

Введение

Хотя подключение GPT к интерфейсу Gradio кажется тривиальной задачей, у некоторых новичков возникают трудности, поэтому мы максимально подробно расписали весь процесс создания чат-бота.

В статье рассказано, как вам может помочь утка при работе с данными, с OLAP-нагрузкой и как она может плавать в вашем Data Lake. Вы узнаете всё самое важное про DuckDB и сможете попрактиковаться в работе с DuckDB.

Всем привет! С вами Женя, разработчик Dodo Engineering и один из ведущих подкаста «Читаем вместе». Он посвящен IT-книгам. В каждом сезоне мы планируем читать и разбирать одну книгу. Уже подходит к концу первый сезон, который мы посвятили книге Fundamentals of Software Architecture. Она написана архитекторами для архитекторов, но разработчикам, особенно тем, которые интересуются, как создавать работающие системы, тоже может быть очень интересна и полезна.

Глава про архитектурные решения сильно нас зацепила, потому что в своей работе мы напрямую столкнулись с описанными в ней проблемами. 

Не можете найти концов, почему было принято то или иное решение? Рассказываете коллегам по сто раз одно и то же? Обсуждения в мессенджерах превращаются в срачи на десятки сообщений?

Знакомо? Нам тоже. Но мы смогли победить эти проблемы.

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

- Саш, админы говорят, что у нас 400 полетели адово. Глянь, в чем проблема.
- Странно… все же было хорошо.

Пару часов спустя...

- Коллеги, и в очередной раз у нас изменены контракты без согласования и оповещения! Это уже не первый случай!

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

Волшебный сказ с лубочными картинками.

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

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

_{Дисклеймер: Не беспокойтесь. С Wednesday все в порядке. Пострадала только косичка и потом, мы же с вами знаем что это не её кровь.}

Сегодня в сообществе ИТ архитекторов, поддерживающих подход “Архитектура как код”, все чаще появляются упоминания о его перспективах выйти на уровень нового индустриального стандарта. Можно было бы сказать, что любое общество должно быть амбициозным и видеть себя в “Центре Вселенной”. Поэтому, не стоит об этом раньше времени статьи написывать. Но важно заметить, что архитекторы облечены ролью и должностью существенно влиять на решения о выборе стека и подходов в крупных компаниях. Поэтому, кажется, важно уже сегодня рассказать, что лежит в основе таких предположений.

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

Теория ограничений (ТОС) — это управленческая методология, предложенная Элияху Голдраттом в 1984 году в его книге «Цель». Она базируется на простом, но мощном принципе: любая система, будь то производство, бизнес‑процесс или команда разработки, всегда ограничена одним или несколькими узкими местами. Эти ограничения или «бутылочные горлышки» сдерживают общую эффективность системы и являются теми ключевыми элементами, которые необходимо обнаружить и устранить для значительных улучшений.

В условиях разработки продуктов, где скорость поставки, качество и удовлетворение клиентов критически важны, применение теории ограничений может привести к существенным улучшениям процессов и результатов. Давайте рассмотрим, как ТОС работает на практике и каким образом она может помочь командам разработки.

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

В этой статье на примере JSON-схемы и спецификации OpenAPI рассматривается проектирование метода REST API с пагинацией, предназначенного для запроса данных из БД.

Данный текст преимущественно ориентирован на начинающих системных аналитиков и всех, кто интересуется проектированием IT-систем.

Давненько я не публиковал новостей по развитию инструмента описания архитектуры кодом. А похвастаться есть чем. Сегодня я исправлю свою досадную оплошность.

Из этой статьи вы узнаете о типах требований и рассмотрите пример их оформления, познакомитесь с основными методами их сбора, рассмотрите основные типы диаграмм (Use Case, Sequence, State, Class, ER-diagram, BPMN) и инструменты, используемые при их документировании.

Предыдущая статья: Системный аналитик. Краткий гайд по профессии. Часть 1