Часто спрашивают, что лучше - 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

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

Вопрос к тем, кто использует ADR и считает полезным. Как вы решаете проблему, описанную @mxsmirnov здесь: https://www.youtube.com/live/9vtf33NIJrE?feature=share&t=40m30s на 40:30?

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

#SoftwareArchitecture

Коллеги, спасибо всем за активное и качественное обсуждение в чате канала. В результате этой дискуссии у меня сформировалось понимание: https://news.1rj.ru/str/emacsway_chat/5759

Возвращаясь к вопросу, который озвучил @mxsmirnov . Полный контекст вопроса https://www.youtube.com/live/9vtf33NIJrE?feature=share&t=38m20s начинается с 38:20.

Максим обращает внимание на то, что архитектурное решение - это ассоциация в архитектурной модели, причем n-арная.

Иными словами, ассоциации находятся не между ADR, а внутри ADR между мотивационными элементами (требованиями, ограничениями, целями, драйверами, стейкхолдерами и т.д.).

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

Хороший пример приводит Игорь Беспальчук: "Пилоту нужно уворачиваться от зениток, а бомбардиру нужно чтобы вели ровно, чтобы лучше прицелиться. Конфликт неизбежен и успех в поиске баланса."

Другой пример - добавили mtls - повысили безопасность, но ухудшили performance.

Какая причина появления ADR? Как писал сам Michael Nygard https://www.cognitect.com/blog/2011/11/15/documenting-architecture-decisions , он пытался найти баланс между тяжеловесностью традиционной архитектурной документации и её полным отсутствием в условиях Agile.

О чем это говорит? Почему в Agile требования выражаются чаще всего посредством PBI (Story)? Почему не делают спецификаций и трассировок? Потому что трассировки нужны для предвидения (prediction) последствий решения, в то время как Agile основан на итеративной модели, где основной способ обработки неопределенности осуществляется опытным путем (adaptation). Long read по теме:

- https://dckms.github.io/system-architecture/emacsway/it/sdlc/models/agile/agile.html

- https://dckms.github.io/system-architecture/emacsway/it/sdlc/uncertainty-management/balancing-prediction-adaptation.html

Иными словами, Agile был ориентирован на проекты, где создание артефактов для заблаговременного (prediction) разрешения неопределенности путем логического вывода себя не оправдывает экономически, ибо дешевле, как говорится, проверить "методом тыка" (adaptation).

Отсюда вывод - если сам способ выражения требований в Agile (PBI) не обеспечивает трассировки (связи между PBI являются зависимостями, а не трассировками), то и в ADR она и подавно не нужна.

Если мы посмотрим на дату статьи Michael Nygard, то увидим 2011 год. О чем это говорит? Это говорит о том, что в это время на рынке происходит рост сложности и размера среднего проекта. Именно по этой же причине на рынке возникает запрос и на микросервисы, и на гибридные SDLC-модели разработки (цель которых сводилась к снижению доли Adaptation в пользу Prediction). Dean Leffingwell в 2011 выпустил книгу Agile Software Requirements и первый релиз SAFe.

Примерно через пару лет Brandolini изобретает Event Storming, потому, что:

💬 "...iterative development [на тот момент стал - прим. мое] is expensive. It is the best approach for developing software in very complex, and lean-demanding domains. However, the initial starting point matters, a lot. A big refactoring will cost a lot more than iterative fine tuning (think splitting a database, vs renaming a variable). So I'll do everything possible to start iterating from the most reasonable starting point."
—"Introducing EventStorming: An act of Deliberate Collective Learning" by Alberto Brandolini

💬 "Upfront is a terrible word in the agile jargon. It recalls memories the old times analysis phase in the worst corporate waterfall. Given this infamous legacy, the word has been banned from agile environments like blasphemy. But unfortunately ...there's always something upfront. Even the worst developer thinks before typing the firs line of code."
—"Introducing EventStorming: An act of Deliberate Collective Learning" by Alberto Brandolini

Еще через пару лет выходит статья "Insights from 15 Years of ATAM Data: Towards Agile Architecture". ATAM в Agile!!!

Появляется MiniQAW.

Таким образом, был конкретный рыночный запрос на рост доли Prediction в обработке неопределенности в силу роста размера среднего проекта на рынке, который Michael Nygard пытался решить путем введения компромиссной формы документирования, о чем он сам же и говорит.

Продолжение следует...

В предыдущем посте мы установили, почему ADR не содержит трассировок - за ненадобностью в своем историческом контексте ввиду того, что они создавались для такой SDLC-модели, в которой преобладает эмпирический способ обработки неопределенности (adaptation), в то время как трассировка больше нужна для заблаговременного способа обработки неопределённости путем логического вывода (prediction).

Исторический контекст появления ADR сопровождался ростом размера среднего проекта на рынке, численностью команды (и команд) его разработки, ростом доли scaled agile и гибридных SDLC-моделей, появлением новых практик заблаговременного разрешения неопределенности. Выделим важное - маятник Prediction/Adaptation двигался в сторону Prediction. Очень хорошо этот момент отражается в Open Agile Standard:

💬 "When combining intentional and emergent architecture, decisions that come from intentional architecture may change. New ones are added and past decisions can be reversed. Therefore, it is important to document the motivations behind past decisions. An Architecture Decision Record (ADR) provides an Agile and lightweight way of doing this."
-- "Open Agile Architecture™ :: 5.2. Architecturally Significant Decisions"

Обратите внимание на фразу "intentional [Prediction] architecture may change [Adaptation]". Эта фраза хорошо выражает причины появления ADR.

На рынке сложилась ситуация, когда на среднем рыночном проекте без архитектурной документации уже нельзя, а с полновесной архитектурной документацией еще нельзя. Эта ситуация привела к появлению ADR, Event Storming, C4 Model и других легковесных практик intentional architecture.

По правде говоря, существуют инструменты, способные создавать связи между ADR, например, https://github.com/npryce/adr-tools

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

Из всех архитектурных артефактов я чаще всего на практике применяю мотивационную диаграмму и Event Storming в терминах C.1.10. Business Process Cooperation Viewpoint.

Вообще говоря, предпочитаемые мною методы документирования архитектуры описаны в
https://publications.opengroup.org/g20e

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

И вот теперь я позволю себе переформулировать вопрос, поставленный Максимом Смирновым. Agile за это время изменился. Если раньше преобладали single-team модели, то сегодня - scaled agile. Стремительно увеличилась доля гибридных SDLC-моделей разработки на рынке, в коллективах разработки появились выделенные роли аналитиков и архитекторов, работа с требованиями обрела полноценный характер, стали популярны системы управления требованиями. Сохранил ли при этом формат ADR, предложенный Michael Nygard, свою актуальность? Не пора ли добавить ему полноценную поддержку ассоциаций?

Если мы посмотрим на шаблоны ADR, то мы увидим следующее (продолжение следует):