Diagramming with pure *.txt files:
- https://youtu.be/cIuX87Xo8Fc

Думаю, что фанаты ADR на *.md это оценят.

#SoftwareArchitecture #Emacs

🔷 "Big Data is Dead" by Jordan Tigani
- https://motherduck.com/blog/big-data-is-dead/

#DistributedSystems

Часто спрашивают, что лучше - Evernote или Notion?

Ребята из Zapier сделали неплохой сравнительный обзор:
- https://zapier.com/blog/notion-vs-evernote/

P.S.: Лично я использую обычные текстовые файлы, но такой аскетичный способ приемлем не всем.

#KnowledgeManagement

Как относиться к ошибкам. Не про ИТ, но очень релевантно:

💬 "Я всегда советую людям смотреть на всё спокойнее. Это всего лишь игра. Иногда вы выигрываете, иногда чему-то учитесь. Берегите нервы. Большинство людей никогда не выигрывает, потому что очень бояться проиграть. В этом виновата школа. Школа учит нас, что ошибки — это плохо, нас наказывают за допущение ошибок. Но если посмотреть в корень вещей, ведь именно на ошибках люди и учатся. Мы учимся ходить, падая и вставая. Если мы никогда не падали, мы бы никогда не пошли. А вспомните, как учились ездить на велосипеде. У меня до сих пор шрамы на коленях, но сегодня я свободно езжу на велосипеде. То же самое касается и зарабатывания хороших денег. К несчастью, главная причина, почему большинство людей не богаты в том, что они ужасно бояться проигрывать, терять. Победители не боятся проигрывать. Проигрывающие боятся. А ведь неудача — составная движения к успеху. Люди, которые избегают неудачи, также избегают и успеха.
Я смотрю на деньги, почти как на Игру в теннис. Я старательно играю, допускаю ошибки, исправляю их допускаю ещё больше ошибок, исправляю их и играю лучше. Если я проигрываю игру, я подхожу к сетке, обмениваюсь через сетку рукопожатием с соперником, улыбаюсь и говорю: «Увидимся в следующую субботу»."

-- Богатый папа, бедный папа. Роберт Кийосаки.

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

Тут то же самое. Есть разница между "не бояться" и "не уметь управлять рисками". Коротко уже я говорил об этом здесь. Краткий курс по управлению рисками от Финам для новичков на фондовом рынке можно посмотреть здесь. Ну и вообще, на тему финансового управления рисками написано немало книг, например, "Financial Risk Manager Handbook" by Philippe Jorion.

Об управлении рисками в архитектуре я уже промолчу.

Прав ли Кийосаки в данном конкретном примере? Да, прав, по двум конкретным причинам:

1. Знание отличается от мнения, как известно, отсутствием противоречий в результате эмпирической проверяемости. Как сказал Эдисон: «Я не терпел поражений. Я просто нашёл 10 000 способов, которые не работают». Без эмпирической проверяемости, без выявленных противоречий и ошибок, не было бы и знаний.

2. Мы, как архитекторы, прекрасно понимаем, что неопределенность может быть разрешена как заблаговременно, путем логического вывода (prediction), так и эмпирически (adaptation). Задача архитектора - определить уровень неопределенности и выбрать наиболее оптимальную для него SDLC-модель таким образом, чтобы она сочетала в себе и Prediction, и Adaptation в пределах своей экономической целесообразности.

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

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

Иными словами, он говорит - будьте смелыми, но не глупыми.

Успешная архитектура всегда создается в результате разумного сочетания Prediction & Adaptation, и Grady Booch даже считает одной из ключевых причин неудач проектов - отсутствие "application of a well-managed iterative and incremental development lifecycle". По этой же причине на практике обычно не встречается в чистом виде ни Top-Down, ни Bottom-Up Design Approache, но обычно их разумное сочетание.

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

Не стоит рассчитывать на то, что его книга даст исчерпывающие знания (впрочем, он сам призывает изучать другие источники). Но с точки зрения психологии мне его книга показалась достаточно познавательной. Кстати, если кому интересно, - краткий курс по психологии для начинающего инвестора от Финам.

Kent Beck: 💬 "I'm a Programmer".

💬 "My business proposition is to help your engineering/product/design organization grow from 100+ people to 1000+ people." -- там же

Dmitriy Zaporozhets: 💬 "I'm a Software developer". Основатель GitLab.

💬 "Я сейчас сам программирую свой проект и мне это нравится" - мой товарищ, к.т.н., основатель консалтинговой компании в области архитектуры решений, известный паблик-спикер.

💬 "Хороший специалист всегда осознает строго ограниченные размеры своего черепа, поэтому подходит к задачам с максимальной скромностью.

The competent programmer is fully aware of the strictly limited size of his own skull; therefore, he approaches the programming task in full humility"
—Edsger W. Dijkstra, 1972

💬 "Ты что, фу-фу-фу, я - не программист, я - супер-пупер-важный-ентерпрайз-солюшен-главный архитектор решений я, вот... , я не такой как все - я особенный..." (💥 звук разорвавшейся сопли пузырем).

P.S.: После долгого перерыва попрограммировал пару недель и получил наслаждение. Я тоже программист, и не стыжусь этого.

Откуда на рынке фуфло? Коллеги, помогите разобраться, пожалуйста. Был недавно на одной выставке, интересовался продукцией (ПАК) определенного назначения (не хочу конкретизировать дабы не бросить ни на кого тень). Были образцы очень интересные. Но было немало образцов, которые по уровню своего исполнения вызывали, мягко говоря, вопросы, и недоумение по поводу цены. И что-то мне подсказывает, что разработчики этих комплексов прекрасно понимали, что делают фуфло. Понимали, но все равно делали. И вот стоит некая компания на выставке и с умным видом демонстрирует то, что лучше было бы спрятать. Представитель не знает даже базовых вещей о своей продукции. Зачем ему тонны оперативы для того, на что сегодня достаточно пару сотен метров, он ответить тоже не может. И ведь получает зарплату. А значит, кто-то это покупает, иначе он стоял бы не на выставке, а на рынке труда. Что не так? Что нужно изменить?

💬 "Дисциплина - это действие сдерживающих начал в действии личности" -- А.С. Макаренко "О воспитательной системе"

Великолепное определение, хорошо понятное мне исходя из принципов разрешения противоречий в архитектуре.

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

#SoftwareArchitecture #Management

💬 "Дисциплина часто противополагается свободе. Это дико. Свобода не воля. Воля - это уединенная возможность всякого действия. Воля - понятие, противоположное неволе, плену, связанности. Свобода - это социальный институт, это не уединенная позиция в небесах, а часть блага общего. Если я имею свободу, то имеет ее и мой сосед. Иначе говоря, она не результат моего уединения, а именно результат общественного договора. Свободу нужно противополагать произволу. Дисциплина в обществе, направленная к ограничению произвола, ставит меня в точное отношение ко всем элементам общества и тем самым позволяет мне точно учитывать обстановку и точно выбирать действие. Воля - это ваш бег в пустом пространстве. Свобода - это ваше спокойное движение по Тверской или Невскому, когда вы уверены, что трамвай идет по рельсам, автомобили и рысаки держат праавую сторону, а семиэтажные дома выстроены под наблюдением строительных законов и не обрушатся на вашу голову."
-- А.С. Макаренко "О воспитательной системе"

Очень точное высказывание, проливающее свет на псевдо-дилемму Agile vs. Architecture. Архитектура противостоит произволу, а не свободе.

#SoftwareArchitecture #Management

В течении последнего месяца я попробовал программировать и по DDD + CQRS (no ORM), и по документации Django.

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

К слову, на Django я программировал более 10 лет, т.е. порога вхождения не испытываю.

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

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

И то, и другое, требует опыта. Но в одном случае опыт привязывается к конкретному инструменту, и ощущение буквы зю остается надолго, а в другом случае формируется профессиональный простор.

Несмотря на то, что я глубоко знаю потроха целого ряда ORM, и даже реализовал несколько своих собственных в своей практике, я предпочитаю обходиться без ORM, и согласен с Martin Fowler в его утверждении:

💬 "ORMs are complex because they have to handle a bi-directional mapping. A uni-directional problem is much easier to work with, particularly if your needs aren't too complex and you are comfortable with SQL. This is one of the arguments for CQRS."
-- https://martinfowler.com/bliki/OrmHate.html

Коллеги, подскажите, пожалуйста, хорошую open-source альтернативу для Jira. Пересмотрел более десятка решений, и выглядит так, что никто ничего лучше старого доброго Trac так и не создал. Да, вяло развивается (за малостью можно пренебречь). Да, до сих пор нет стабильной версии под Python 3 (про плагины вообще молчу). Но в целом вполне можно собрать приличный инструмент для гибридного SDLC, благо - плагинов для моих целей предостаточно.

На втором месте мне видится OpenProject/Redmine.

Что я упускаю?

Хочется иметь разные типы задач с независимо настраиваемыми workflow, иерархические структуры типов PBI (Epic -> Story -> Task -> Subtask), поддержку Kanban и итеративной модели (Scrum, XP), оценивание по PERT (или хотя бы наличие возможности написать свой плагин), планирование итераций и релизов по оценкам, интеграцию с Git, поддержку компонентов, тегирования, версии (релизов).

О спорах. Получил в рассылке, материал заинтересовал, особенно там, где говорится, что причиной спора является подавление когнитивного диссонанса спорщика.
https://megaplan.ru/blog/management/camye-chastye-lovushki-sporshchikov/

#SoftSkills

Коллеги, в архитекторских кругах в свое время активно обсуждалась статья https://ebanoe.it/2016/07/20/shitcoders/ , и я недавно в очередной раз имел возможность убедиться в её достоверности.

Именно по этой причине я всегда избегал заказную разработку (под этим термином я не разделяю outsource и outstaff) и предпочитал работать на продуктах.

Когда я начинал свой путь в ИТ, я избегал работать в legacy-проектах, т.к. они сопровождались низкой скоростью разработки и высоким уровнем морально-психологических издержек. По мере моего архитектурного становления я, наоборот, начал предпочитать такие проекты, т.к. они становились благодатной почвой для проявления моей квалификации. Поэтому, моим негласным профессиональным символом стал белый медведь - он выживает в условиях Заполярья, где выжить могут далеко не все.

Но заказная разработка отличается от обычного legacy-проекта двумя критериями:
1. Подрядчик кровно заинтересован в поддержании низкого качества и в переусложнении, т.е. это позволяет ему продавать больше часов. Еще Edsger W. Dijkstra говорил: "Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.". А это уже проблема не архитектурная, и я не знал, как её решить.
2. Малоразмерные проекты (основная ниша заказной разработки) никогда не обладали карьерной привлекательностью для высококвалифицированных специалистов, поэтому они всегда испытывали квалификационный голод. Эта проблема тоже не архитектурная.

Не зная, как решить проблему, я предпочитал обходить её стороной.

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

Не берусь судить хватит ли у меня средств и упорства осуществить это решение на практике, но эта цель меня заинтересовала и я серьезно задумался о её осуществлении.

#Management #SoftwareDesign #Goal

Единственное, что смогло вызвать у меня неподдельный интерес по тематике управления после диалектической философии - это "Теория Игр" (а конкретней - "Теория Контрактов"). Если интересно, посмотрите видео о теории контрактов https://youtu.be/pjEhGZpQLn0 или полистайте книгу "Теория игр: Искусство стратегического мышления в
бизнесе и жизни" Авинаш Диксит и Барри Нейлбафф ("The Art of Strategy: A Game Theorist's Guide to Success in Business and Life" by Avinash K. Dixit, Barry J. Nalebuff).

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

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

Я так же понял что в reference application https://github.com/emacsway/grade мы неосознанно применили принципы теории игр. Развитие этого проекта будет продолжено в ближайшее время. Мне он нужен для систематизации своих собственных знаний по организации структуры кода и для обучения программистов. Кроме того, он представляет интерес и как реально функционирующее приложение (не только демонстрационное) с акцентом на функциональность карма-движка для телеграм-сообществ и профессиональных коллективов, о чем я писал в свое время в п.3 здесь.

#Management

извините )) не мог удержаться ))