Привет, Хабр! Меня зовут Юрий Никулин, и я руководитель направления документирования Cloud. Сегодня расскажу, как мы перешли с документирования в Word на подход docs as code и почему в качестве языка разметки выбрали reStructuredText.

Добрый день.

Меня зовут Игорь Хапов. Я руководитель разработки в Научно-техническом центре IBM. И сегодня я хотел бы вам помочь окунуться в мир периферийных вычислений, или edge computing, как его ещё называют. Я расскажу о том, что же такое edge computing и как он может повлиять на наш с вами мир. Также хотелось бы пояснить различия между edge computing и fog computing, какие преимущества даёт этот подход. В статье я также описал референсную архитектуру приложения на edge computing. И под конец немного расскажу о проекте с открытым исходным кодом Open Horizon, который совсем недавно присоединился к Linux Foundation.

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

Поэтому, несмотря на эту снисходительность, относиться к созданным диаграммам приходится со всей ответственностью. В связи с этим логично задуматься, а как правильно создавать архитектурные артефакты: документы с описанием, диаграммы, модели? Как сделать так, чтобы архитектурные документы были максимально полезны и использовались другими техническими специалистами в проекте? Как не допустить ошибок? Есть ли уже описанные процессы, специальные инструменты, да и просто рекомендации? Если проект сложный и в нем участвуют несколько архитекторов в разных ролях (к примеру, от инфраструктуры, от прикладных модулей и корпоративный), то как правильно распределить обязанности, кто что делает и в каком формате?

Расписание на эту неделю:

Разработку можно сравнить с картиной, где художник — ведущий разработчик. Создание элегантного микросервисного приложения — с творениями лучших архитекторов — модернистов. А вот поставить процесс на поток и оставить возможность выбирать — искусство. В первой статье из серии мы хотим рассказать о том, как создавался и работает облачный сервис IBM Kubernetes service и IBM Managed OpenShift, а также рассказать, как вы можете бесплатно развернуть и протестировать свой кластер Kubernetes в облаке IBM.

Добрый день, дорогие хабровчане.
Я являюсь разработчиком научно-технического центра IBM в Москве. Мы ведем разработку продуктов IBM совместно с другими лабораториями по всему миру. Если позволяет время и есть желание, то у нас разрешено использовать часть рабочего времени на проекты, которые не являются основной занятостью. Такой подход расширяет кругозор и поддерживает творческий настрой. Для меня такой областью является разработка блокчейн-решений на Hyperledger Fabric. Тем более, что такие проекты стали востребованы на нашем рынке.
Надеюсь, что статья будет не о блокчейне, а о том, что мы используем для разработки таких решений, но тем не менее стоит все-таки начать с предметной области.
Статья не претендует на полноту и нацелена на создание рабочего облачного окружения для разработки блокчейн-проектов на Hyperledger Composer. В результате наших практических изысканий мы должны получить следующую инфраструктуру: