emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc. – Telegram
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
3.48K subscribers
119 photos
15 videos
22 files
1.14K links
Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, Extreme Programming, SDLC, Agile, etc.

Chat: https://news.1rj.ru/str/emacsway_chat

Persistence: https://dckms.github.io/system-architecture/
Download Telegram
Рассказывая про атрибуты качества, я раньше приводил в пример страницу из Википедии, их тут перечисленно 92 штуки.

Иногда выводил из на один слайд, получается впечатляюще.

Но теперь я нашел ещё более ужасающую картинку.

Это граф, в котором перечислено 162(!) атрибута качества и 104 примера требований, связанных с этим ограничениями. У каждого атрибута есть описание, то есть это не просто картинка, а целая энциклопедия (на английском).

Кажется, это исчерпывающий каталог атрибутов качества, куда уж больше.

Основа тут - восемь главных областей. Система должна быть:
- Надежной (Reliable)
- Безопасной (Safe), иногда переводят "свободной от неприемлемых рисков" - никого не убьет и не обанкротит, ничего не разрушит
- Защищенной (Secure) от атак, у нас обычно именно это называют "безопасностью"
- Пригодной к использованию (Usable)
- Подходящей (Suitable), пригодной для этих условий, функций и ограничений
- Эффективной (Efficient), тут деньги против ресурсов
- Работоспособной (Operable), то есть её можно запустить и поддерживать в работоспособном состоянии
- Гибкой (Flexible), легко можно менять. Coupling and Cohession - сюда.

Можно посмотреть примеры формулировок нефункциональных требований (тоже на английском): https://quality.arc42.org/requirements/

Требования описаны в трехчастной схеме: контекст-источник-метрика/критерий приемки.

Авторы говорят, что подход ISO 25010 не слишком прагматичный, поэтому они разработали свой . Возьмите, говорят, 7 категорий стейкхолдеров (пользователи, менеджмент, эксперты в предметной области, владелец продукта, разработчики, тестировщики, админы), и спросите у них, что им важно из общих или конкретных качеств системы. Ну да, из этих 162.

Получится очень прагматично.
👍8🤔31
Forwarded from SWE notes
Putting the “You” in CPU

Отличный материал для погружения в работу ПК на примере Linux.

Простым языком описано что такое прерывание, мультизадачность и прочие системные вещи

#sysprog #linux #os
👍5🔥2
Forwarded from Ivan Ryabov
А я то думаю, что не так со мной)
😁28🔥6
Forwarded from Сергей Баранов
„Если ты хочешь построить корабль, не надо созывать людей, планировать, делить работу, доставать инструменты. Надо заразить людей стремлением к бесконечному морю. Тогда они сами построят корабль…“ —  Антуан де Сент-Экзюпери
🔥14👍6👎3
Очень часто слышу "бизнес-логика" от слова "бизнес" - зарабатывать деньги.

Бизнес переводится с английского "дело".

"It's not your business!" - "Не твое дело!"

Бизнес логика - это то, что будет "делать" система или сервис. Это причина его возникновения.

В большинстве случаев "бизнес-логика" тождественна "доменной модели", когда система призвана автоматизировать какой-то процесс предметной области.

[UPDATE]:
Business - Software intersects with the Real World. Imagine that.

-- Ward Cunningham
http://wiki.c2.com/?CategoryBusiness
👍19🔥31
Stay ahead, lead the future of AI in project management
Artificial intelligence (AI) is here to stay. Join us in leading the AI transformation where the future of project management blends AI and human ingenuity, fueled and guided by our global community.

https://www.pmi.org/learning/ai-in-project-management
This media is not supported in your browser
VIEW IN TELEGRAM
Из г...глины и палок? Чтобы работало? Легко! В руках мастера, как говорится...

Даже не знаю, что меня смущает больше — деревянный мотоцикл или глиняный шлем.
🔥5😁5👍3🤩1
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
В предыдущем посте говорилось, что pessimistic scenario не совсем корректен в Taskjuggler. Картинка демонстрирует, как должны быть сложены две оценки. Мы видим, что оценки пересекаются. Вот почему мы должны сложить отдельно вероятностную оценку и среднеквадратичное…
Добавил в TaskJuggler поддержку подсчета Standard Deviation:
https://github.com/emacsway/TaskJuggler/tree/standard_deviation

Ранее я объяснял, почему использование пессимистического сценария для подсчета пессимистического срока некорректно.

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

Из трех значений плагин выводит вероятностную оценку и среднеквадратичное отклонение. Если хотите посчитать вручную, то это можно сделать с помощью PERT-калькулятора. Далее эти оценки по специальным правилам суммируются, но в контекста TaskJuggler функции и возможности плагина нам уже не интересны.

Интеграционный скрипт при экспорте задач из Jira в TaskJuggler извлекает эти оценки и высчитывает вероятностную оценку (effort) и среднеквадратичное отклонение (stdev).

Для контейнерного типа задач TaskJuggler суммирует stdev как корень квадратный суммы квадратов. Значение получается в человеко-днях уже с учетом фокус-фактора.

Для нахождения пессимистического срока эпика используется правило 3×sigma. Т.е. к сроку, полученному на основании вероятностных оценок, добавляется еще три среднеквадратичных отклонения, преобразованных в календарные дни (т.е. с учетом выходных дней, например, при σ=5 это будет три календарные недели).

Список литературы по планированию см. здесь.

#Estimation #Scheduling #TaskJuggler #PERT
🔥111👍1🙏1
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Добавил в TaskJuggler поддержку подсчета Standard Deviation: https://github.com/emacsway/TaskJuggler/tree/standard_deviation Ранее я объяснял, почему использование пессимистического сценария для подсчета пессимистического срока некорректно. Как это работает…
Зачем нужно стандартное отклонение?

Существует три качества оценки:

1. Honest (честность)

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

3. Precise (точность, т.е. сужение диапазона вероятности оценки, например, утверждение о том, что задача будет выполнена 11 октября 2025 года в 15:45:10.0639 - это Precise, но не Accurate)

Было хорошее видео на эту тему "YOW! 2016 Robert C. Martin - Effective Estimation (or: How not to Lie)", но сейчас оно, к сожалению, недоступно. Может можно найти его копии где-нибудь.

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

Оценка - это диапазон. И диапазон с вероятностной распределенностью.

На этом построен принцип оценивания PERT, который снимает психологическое напряжение и позволяет выразить степень неопределенности оценки в виде среднеквадратичного отклонения. Коротко этот подход описан на 3-х страницах книги "The Clean Coder" by Robert C. Martin, "Chapter 10 Estimation :: PERT". На русском она называется "Иделальный программист".

Для каждой стори снимаются 3 оценки - пессимистическая, номинальная и оптимистическая.

При коллективном оценивании для пессимистической берется самая пессимистическая из всех, для номинальной - средняя, для оптимистической - самая оптимистическая.

Вычисление можно легко осуществить в excel-файлике. Вероятностая оценка находится по формуле μ = (O + 4 N + P) / 6. А среднеквадратичное отклонение распределения времени выполнения стори находится по формуле σ = (P − O) / 6. Этот параметр выражает точность оценки.

Далее суммируются вероятностные оценки для всех сторей релизного цикла простым математическим сложением, это несложно сделать в excel. А вот среднеквадратичное отклонение распределения времени выполнения всех сторей высчитывается немного сложней, и равно квадратному корню суммы квадратов среднеквадратичных отклонений сторей, т.е. σ sequence = (∑ (σ story ^ 2)) ^1/2. Это тоже несложно автоматизировать в excel.

Ну а далее, как я уже говорил, для нахождения пессимистического срока релиза используется правило 3×sigma. Т.е. к сроку, полученному на основании вероятностных оценок, добавляется еще три среднеквадратичных отклонения, преобразованных в календарные дни (т.е. с учетом выходных дней, например, при σ=5 это будет три календарные недели).

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

Важно понимать, что планирование - это не предсказание (Kent Beck). А прогноз - это не обязательство (Robert Martin).

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

Проблемой для бизнеса является не сам факт отклонения от плана, а когда он слишком поздно узнает об отклонении и уже не может ничего предпринять.
🔥8👍7🙏3
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Физические Agile-доски до сих пор активно используются в крупных IT-компаниях, даже в таких, как Thoughtworks. Это никакой не исторический рудимент. Они используются даже для распределенных команд - в удаленном офисе на самом видном месте устанавливается большой…
Прошло уже 3 месяца, как в моей практике появился физический бумажный ежедневник.

Теперь могу уверенно ответить на вопрос о том, есть ли от него реальная польза, или это просто эффект новизы.

Главное отличие, которое я заметил - это необычайно глубокое владение обстановкой и высокий уровень самоорганизованности.

Я обсуждал этот вопрос с моим товарищем, к.т.н., который работает над докторской, и тоже пользуется бумажным ежедневником. Я не спец в физиологии и не могу в точности передать содержание разговора, но он мне объяснил о наличии некой связи между нейронами, отвечающими за мелкую моторику, и нейронами, отвечающими за память. Эта тема даже неплохо освещена в интернете, например:
https://hi-tech.mail.ru/news/119776-pismo-ot-ruki-luchshe-prokachivaet-nejronnye-svyazi-chem-pechat-novye-dannye/

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

Наверное, поэтому С.И. Поварнин в своей книге "Как читать книги" рекомендует конспектировать прочитанное.

Иногда намеренно записываю информацию в бумажный ежедневник, а затем сканирую текст приложением "Почерк в текст конвертор", чтоб перенести в цифровой блокнот.

Я пользуюсь форматами A6 и Personal. A6 удобней, но мне подвернулся по хорошей цене оригинальный новый Montblanc формата Personal.

Самым удобным форматом наполнения для меня оказался https://myfineplan.ru/product/blok-nedelya-v2-2 , т.к. он содержит страницу для заметок на каждую неделю. Но, если честно, места на странице недельного расписания (т.е. на левой) частенько не хватает.

Какие и где блокноты можно купить?

1. https://myfineplan.ru/
У этой мастерской есть телеграм-канал:
https://news.1rj.ru/str/myfineplan

2. На Авито часто бывают в продаже шикарные ежедневники из натуральной кожи Petek в непритронутом виде (просто лежал у кого-то дома в заводской упаковке). По непонятной для меня причине они лучше находятся по фразе "записная книжка Petek". Иногда попадаются Dupont и Montblanc.

3. На Aliexpress можно купить блокноты Moterm и Filofax. Мне очень нравится Filofax Holborn формата Personal, который есть в моей коллекции.

Цифровой блокнот из моей практики не исчез, продолжаю пользоваться
https://github.com/orgzly-revived/orgzly-android-revived
, который подкупил меня внутренним качеством своей кодовой базы по сравнению с другими Open Source решениями.

P.S.: Знаете чем обусловлен успех Юрия Никулина? Что для него было самым ценным, и прошло с ним через всю войну? Блокнот (в виде тетради), в который он записывал анекдоты.
9👍6🔥1
Вообще я сегодня должен был написать либо про философские доклады с BiasConf, либо про InBetween.

Но внезапно я сделал новую версию карты интеграций: https://github.com/yksi12/integrations/blob/main/Integrations%20Tech%201.0.1.pdf

Добавил туда JSON-RPC, т.к. он в последнее время стал популярен в связи с MCP — протоколом для взаимодействия LLM с внешними источниками данных и сервисами. Также он используется в блокчейн-проектах (они не на слуху, но вообще-то вполне себе живы и развиваются).

На картинке видно, что протокол легковесный: вся линейка почти пустая.

Впрочем, карта уже дает предсказательную силу — ну не опишешь ведь RPC ни в OpenAPI, ни в AsyncAPI. Но должен же быть формат для описания спецификаций? Ну вот он и есть: OpenRPC! https://open-rpc.org/

То есть, когда вы сталкиваетесь с какой-то новой для себя технологией или приёмом, можете задать себе всё те же вопросы:
— Верхнеуровневый паттерн: это удаленный вызов или обмен сообщениями (надеюсь, общую БД и файловый обмен вы не используете)
— Это синхронно или асинхронно?
— Какая метафора используется? Какая семантика взаимодействия? Вызов процедуры, CRUD над ресурсами, гипермедиа, запрос данных, извещение, подписка на событие, очередь? У некоторых авторов это называется "интеграционный стиль"
— На каком это протоколе? HTTP, HTTP/2, TCP с какой-то своей нашлепкой? И если HTTP, то только как транспорт, или по полной, как в REST? Протокол-то вообще бинарный или текстовый? И вообще, этот метод завязан на конкретный протокол, или может использоваться с разными?
— В каком формате передаем данные? Есть ли у этого формата схема? Строгая ли типизация в этом формате? Он плоский, или допускает вложенность? Насколько сложным по структуре может быть ответ?
— Если нам нужно преобразование данных, то есть ли штатные средства для этого?
— Что с обработкой ошибок? Можно ли определить и возвращать собственные коды ошибок и дополнительную информацию?
— Что с безопасностью? Аутентификация и разделение полномочий? Есть ли штатные средства? Или всё ограничивается TLS/SSL и OAuth?
— Что с производительностью, скоростью и гарантиями доставки?
— В чем мы это будем описывать, какие есть языки спецификаций и инструменты тестирования? Где мы эти спецификации храним и как обеспечиваем их актуальность?

И если мы берем какую-то совершенно новую технологию, нужно просто задаться всеми этими вопросами. И мы можем сравнить две технологии — дублируют ли они друг друга? Можно ли использовать на одном проекте RabbitMQ и Kafka? Что выбрать — GraphQL или gRPC?

В общем, кажется, схема работает. Про что ещё можно спросить в отношении технологий интеграции, чтобы сравнить их друг с другом?
🔥4👍2