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

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

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

Приветики. Каждый из нас в этом этом чудесном году находит свой способ скоротать время. Я вот, например, пишу книгу. Книгу о том, что знаю и люблю — про API. (Кто я такой и какой опыт имею в разработке можно посмотреть здесь)

→ Пока что написал первую часть — о принципах проектирования API «сверху вниз»

→ PDF-версию можно скачать отсюда

Вопросы, пожелания и предложения принимаются. Книга распространяется бесплатно на условиях CC-BY-NC. You're welcome!

Книга Мир после капитала американского инвестора немецкого происхождения Альберта Венгера — один из наиболее значимых текстов об экономике после капитализма.

Этот перевод мы делаем сообществом энтузиастов совершенно бесплатно.

В эпоху продуктовой разработки с постоянным использованием гибких методологий и «насаживанием» их везде (порой даже не к месту) хочется напомнить об одной из классических методологий проектного управления. Вопрос классических методологий всё еще актуален для договорных отношений Заказчик – Исполнитель и проектов с каскадной формой управления. 

Упомянутый в заголовке статьи стандарт PRINCE2 также актуален и для проектов с гибкими методологиями, так как Agile-методы очень четко и структурировано рассказывают, как правильно разрабатывать продукт (и управлять именно процессом разработки продукта), но как именно управлять проектной деятельностью (а это, как известно, не только один процесс производства продукта) гибкие методологии покрывают не всегда и не полностью. 

В силу своей разрекламированности PMBOK всегда был более востребованный и популярный, вместе с этим очень перегруженный по группам процессов (например, для IT-проектов). Многим руководителям проектов использование проектной методологии PRINCE2 в сравнении с PMBOK (в силу лаконичности и структурированности первого) позволяет более изящно управлять проектами разного масштаба и структур. 

Как измерить прогресс?

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

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

Поэтому я не хотел писать еще одну статью с описанием техники Red-Green-Refactor. Мне хотелось взглянуть на TDD немного глубже и описать, как и почему TDD влияет на поведение человека.

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

Тезисы

1.    4я промышленная революция (Industry 4.0, цифровизация) подразумевает полную интеграцию:

a)   традиционных информационных потоков планирования и управления производства, поставок и

b)   средств исполнения: люди, машины и механизмы, оборудование…

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

2.    При этом, кибер-физические системы Industry 4.0 (далее – I4.0) основываются на фундаменте базовых процессов разработки (изделий), планирования/управления производством, поставками, используемые сейчас предприятиями (Industry 3.0 – I3.0.).

3.    Очевидно, что без построения фундамента в виде I3.0, попытки внедрить элементыI 4.0 не приведут к принципиальным улучшениям. Т.к. будут работать на локальные области оптимизации, без синхронизации как со всей «горизонталью» цепочкой поставок, так и с «вертикалью» создания продукции для потребителя. Под последним имеется в виду цикл: «разработка à испытания à ввод в «серию» (не обязательно – вывод в массовое, но обязательно – вывод из опытного производства) à планирование, закупка, производство à передача потребителю».

4.    Т.о., цифровизация традиционных российских предприятий должна обязательно и первостепенно включать построение фундамента (I3.0), с цифровизацией (внедрением элементов I3.5 и 4.0) только там, где необходимо и оправдано (в узких местах процесса создания продукции для потребителя). Так, как это делали западные, а теперь уже и восточные, более эффективные производства. В любом другом случае все это будет выглядеть (и выглядит, судя по регулярно рапортуемым «успехам» наших «цифровизирующихся», как правило, не на деньги частных собственников, заводов), как попытка взобраться на 4й этаж со 2го, по приставной лестнице, у которой нет перекладин вначале….    

Ниже представлена концепция цифровизации (читай – повышения эффективности через цифровизацию) для производств, только осваивающих I3.0 и представляющих подавляющее большинство нашей промышленности.

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

Как проверить себя на эффект Даннинга-Крюгера, и преодолеть его?

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

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

Мы используем Redmine для управления задачами. Это несколько старомодный, но удобный и проверенный временем бесплатный инструмент. Фатальным недостатком в нашем случае оказалось отсутствие понятной общей сводки по текущим задачам.