Вы тоже устали вручную заполнять Dockerfile и docker-compose.yaml под каждый новый проект?

Я всегда задумывался, применяю ли я известные best practices, когда пишу конфиг для Docker, и не занесу ли я случайно какие-нибудь уязвимости, вручную заполняя конфиг-файлы.

Что же, теперь мне больше не придется беспокоиться об этом, благодаря добрым людям из Docker, которые недавно реализовали инструмент для этого - docker init .

Интересно, как экономить время и быстро генерировать конфиги, даже если вы не профи в Docker? Прошу под кат.

Divide et impera (разделяй и властвуй) – древний принцип для управления чем-то большим и сложным.

Многие из нас программируют. Многие из нас делают системы, сложные системы. Но некоторым повезло работать в ситуации, когда объёмы по-настоящему огромны и требования кажутся невыполнимыми. Шардировние – один из излюбленных счастливчиками, которых зовут приключения, приемов.

Что-нибудь разбить на кусочки – это круто! Переходите на сторону шардирования у нас есть печеньки!

Небольшая заметка с технологиями и полезными ссылками, которые позволили мне пройти собеседование и работать в Сбере.

При разработке больших web-проектов нам часто приходится взаимодействовать с API сторонних или внутренних микросервисов. Когда количество таких взаимодействий растёт, настройки вызовов к другому API и подробности самих вызовов кратно множатся и могут растекаться по проекту.

В Домклике у нас микросервисная архитектура, и каждому сервису приходится взаимодействовать с десятком других. Чтобы межсервисное взаимодействие было предсказуемым, надёжным, удобным и отслеживаемым, мы следуем ряду практик при разработке, и в этой статье я расскажу вам о них.

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

На помощь приходит Reactive Manifesto — документ, который обобщил опыт целого ряда компаний по созданию распределенных систем. Манифест формулирует главные принципы, на которые стоит опираться на этапе проектирования и эксплуатации таких систем.

Меня зовут Андрей Василевский, я системный архитектор в Lamoda Tech. В этой статье я на примерах из своей работы покажу, как применять Reactive Manifesto на практике. Статья будет полезна тем, кто только начал изучать распределенные системы, хочет закрепить теорию или тем, кто хочет структурировать проектирование микросервисов в своей компании.

По мотивам Adidas Running (ex. Runtastic)

Как я бы проектировал это интересное, но малоизвестное у нас приложение в роли архитектора.

Предыстория

Рынка систем электронных соревнований (в 2012 г) нет, но есть огромный интерес к спортивному образу жизни и к соревнованиям. В США не менее 50 миллионов (!) человек (это примерно 15% всего населения) хотя бы раз в неделю выходят на пробежку.

Адидас имеет объем продаж 20–30 млрд долл. в год.

Основной рынок – США, остальные страны – второстепенные рынки.

Привет, Хабр! Я Женя, архитектор интеграционной платформы в Точке, отвечаю за асинхронный обмен сообщениями между внутренними сервисами, за ESB и за брокеры сообщений.

В этой статье я постарался кратко и последовательно изложить основные моменты, о которых полезно помнить при использовании RabbitMQ, если важны стабильность обмена и сохранность данных.

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

Руслан Гнатовский aka @Number55 в свой статье Когда ни туда, ни сюда, или в поисках оптимальной границы Domain слоя описал известную проблему протекания бизнес-логики из агрегата, в случае если эта логика зависит от данных которые находятся вне агрегата, и предложил несколько решений этой проблемы, каждое из которых не лишено недостатков. Многие из этих недостатков были описаны в статье а также в комментариях поэтому я не буду здесь дублировать эту информацию а попытаюсь предложить решение которое этих недостатков лишено.

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

...

Попробую, попытаюсь объяснить. Наверное, для кого-то это будет оправданием, но я просто объясняю.

Как быстро зафейлить новый проект Java? Просто взять и применить все, что ты услышал на последней Java конференции;) Как быстро сделать энтерпрайзный проект минимальной командой в короткие сроки? Верно — подобрать оптимальную архитектуру и правильные инструменты. Senior Developer из команды Jmix Дмитрий Черкасов рассказывает о компромиссном варианте между хайповыми (все еще) микросервисами и монолитами, который называется Self-Contained Systems. Кажется, он выпьет меньше крови и сохранит ваши нервы. Дальше — рассказ от первого лица.

Извечный вопрос: должен ли тимлид обладать самой крутой технической экспертизой в команде? Споры будут идти ещё много тысячелетий, но где, как не в крупной компании, лучше в этом разобраться?

Сегодня поговорим о техническом лидерстве, где оно может лежать в команде разработки, обязательно ли это тимлид или всё-таки не обязательно. А поможет нам в этом Анастасия Абрашитова, руководитель службы инструментов репозитория в Yandex Infrastructure.

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

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

Статей о селектах хватает, попробуем про апдейты. "ТОП-100" вопросов не обещаю - тут бы с одним разобраться. Разработчиков OLTP-систем под MS SQL Server и кандидатов на подобные вакансии приглашаю под кат.

Код на T-SQL, и он идеален. Атомарности нет, целостность вернём ручными апдейтами, изоляция с дюрабилити только мешают. Программируем без оглядки на ACID, который жив лишь в статье википедии.

Если ты DevOps, который работает с adult‑проектами, то твой типичный «взрослый контент» будет выглядеть примерно так.

Одна из самых традиционных тем на Хабре — это внезапные карьерные перемещения из различных профессий в IT и обратно. У меня, вот, чудесный коллега — профессиональный мясник с соответствующим образованием. Мониторинг настраивает как боженька и умеет убедительно отстаивать свою точку зрения. Образование позволяет.

Меня тоже можете принимать в свои ряды людей со странной сменой профессии. Как многие помнят по моим старым постам — я изначально врач, который свернул в направлении фундаментальной науки и тканевой инженерии. Все вот эти развлечения со стволовыми клетками, выращиванием органов в биореакторах и прочими нетиповыми экспериментальными задачами. И вот тут меня внезапно позвали на собеседование в крупный телеком… Короче, очнулся я уже будучи DevOps в компании, которая занимается сложными проектами, некоторые из которых про adult‑видео. Ну вот те самые специальные обучающие фильмы для взрослых, которые двигатель прогресса. С петабайтами отданного трафика, набегами миллионов пользователей и прочими радостями.

Работает у нас это примерно так — у бизнеса наступает момент, когда приходит осознание, что все. Приехали. Инфраструктура работает, вроде бы все в порядке, но построена на костылях, которые заботливо укладывали три поколения сотрудников назад. Документации нет, как все это работает — никто не помнит. Если сервер сдохнет, воскресить в случае чего никто не сможет.

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

Предлагаю перейти под кат, а я попробую рассказать, как выглядит вся эта индустрия глазами врача/био‑инженера/DevOps.

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

Если у вас есть собственные кейсы, которыми вы бы хотели поделиться, пишите в комментариях. 

Время от времени необходимо пересматривать свои методы TDD и напоминать себе, каких моделей поведения следует избегать.

Процесс TDD концептуально прост, но по мере его выполнения вы обнаружите, что он бросает вызов вашим навыкам проектирования. Не путайте это с тем, что TDD - это сложно, сложно именно проектирование!

В этой статье приводится ряд антипаттернов TDD и тестирования, а также способы их устранения.

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

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

Redis и Memcached – два из самых популярных и мощных инструментов для реализации кэширования. Redis, изначально разработанный как in-memory хранилище данных, позволяет эффективно хранить и быстро извлекать информацию в памяти, что делает его идеальным выбором для кэширования. Memcached, с другой стороны, специализируется исключительно на кэшировании данных и предоставляет простой, но мощный способ ускорить доступ к данным.

Гуд ньюз эвриван! Спустя полтора года работы восьми айтишников с суммарным опытом в IT 130 лет достигнут результат в виде учебника по тестированию, которого еще никто и никогда не делал.