Forwarded from Архитектура ИТ-решений
В далеком 1987-м Джон Захман предложил любую модель системы причислять к одному из трех фундаментальных типов: описание данных, описание функций или описание физической структуры системы.
Cловом архитектура обычно обозначают модели третьего типа. А вот решение о выделении фрагмента системы в отдельный модуль завязано на элементах моделей первых двух. Модуль включает в себя либо некоторый набор данных, либо некоторый набор функций.
Не так уж всё и сложно, правда?
Cловом архитектура обычно обозначают модели третьего типа. А вот решение о выделении фрагмента системы в отдельный модуль завязано на элементах моделей первых двух. Модуль включает в себя либо некоторый набор данных, либо некоторый набор функций.
Не так уж всё и сложно, правда?
Forwarded from Блог Сергея Баранова
Закон Конвея. Перевод статьи «How Do Committees Invent?»
Так как статья – не художественное произведение, да еще и написана в далеком 1968 году, ее перевод может (да, наверное, и должен) восприниматься как весьма косноязычный и местами непонятный, но так уж излагали мысли ученые в 68-м. Посчитал, что для научной статьи адаптивный перевод может привести к потере смыслов (хотя и понимаю, что на русском языке смысл может исказиться). Всячески рекомендую оригинал (ссылка в конце статьи), а переводом пользоваться только в том случае, если недостаточно знаний английского.
http://agilemindset.ru/закон-конвея-перевод-статьи-how-do-committees-invent/
Несколько цитат:
👉«никогда не бывает достаточно времени, чтобы сделать что-то правильно, но всегда есть достаточно времени, чтобы сделать это заново»
«Каждый раз, когда осуществляется делегирование и сужается чья-то область исследования, также сужается и класс вариантов решений по проектированию, которые могут быть эффективно реализованы.»
«Как только определены сферы деятельности, возникает проблема координации. Координация между рабочими группами, хотя и снижает продуктивность отдельных сотрудников в небольшой группе, обеспечивает единственную возможность того, что отдельные рабочие группы смогут объединить свои усилия в единую систему.»
«осознание первоначальными проектировщиками того, что система будет большой, вместе с определенным давлением в организации делает непреодолимым искушение назначить для разработки дизайна слишком много людей»
«Менеджер должен отдать в субподряд важную и сложную задачу по проектированию. Он выбирает между двумя подрядчиками: небольшой новой организацией, которая предлагает интуитивно привлекательный подход за гораздо меньшие, чем заложено в бюджете, деньги, и давно зарекомендовавшей себя, но традиционной организацией, которая требует более «реалистичную» плату. Он знает, что, если яркая молодая организация не сможет добиться достаточных результатов, его обвинят в неумелом управлении, а если потерпит неудачу проверенная организация, это будет доказательством того, что проблема действительно сложна.
В чем тут сложность? Большая ее часть относится к рассуждениям об измерении ресурсов, вытекающим из традиционной теории бухгалтерского учета. Согласно этой теории, единицей ресурса является доллар, и все ресурсы должны измеряться с использованием единиц измерения, конвертируемых в доллары. Если ресурсом является человеческий труд, единицей измерения является количество часов, отработанных каждым человеком, умноженное на его почасовую ставку, суммированные для всей рабочей силы.
Одним из заблуждений, лежащих в основе этого расчета, является свойство линейности, согласно которому два человека, работающие в течение года, или сто человек, работающие в течение недели (при одинаковых почасовых ставках на человека), являются ресурсами равной ценности. Если предположить, что два человека и сто человек не могут работать в одной и той же организационной структуре (это интуитивно очевидно и будет обсуждаться ниже), наш гомоморфизм говорит, что они не будут проектировать подобные системы; поэтому ценность их усилий может быть даже несопоставимой. По опыту мы знаем, что два человека, если они правильно подобраны и имеют нужный опыт, дадут нам лучшую систему. Предположения, которые могут быть достаточными для чистки картошки и возведения кирпичных стен, не годятся для проектирования систем.»
«Даже в умеренно небольшой организации возникает необходимость ограничить общение, чтобы люди могли выполнить какую-то «работу».»
«Необходима философия управления дизайном систем, которая не основывается на предположении, что простое добавление рабочей силы повышает производительность.» – Закон Конвея именно об этом, хоть и звучит как «организация, проектирующая систему (в принятом здесь широком смысле), производит дизайн, являющийся копией коммуникационных структур этой организации»
Так как статья – не художественное произведение, да еще и написана в далеком 1968 году, ее перевод может (да, наверное, и должен) восприниматься как весьма косноязычный и местами непонятный, но так уж излагали мысли ученые в 68-м. Посчитал, что для научной статьи адаптивный перевод может привести к потере смыслов (хотя и понимаю, что на русском языке смысл может исказиться). Всячески рекомендую оригинал (ссылка в конце статьи), а переводом пользоваться только в том случае, если недостаточно знаний английского.
http://agilemindset.ru/закон-конвея-перевод-статьи-how-do-committees-invent/
Несколько цитат:
👉«никогда не бывает достаточно времени, чтобы сделать что-то правильно, но всегда есть достаточно времени, чтобы сделать это заново»
«Каждый раз, когда осуществляется делегирование и сужается чья-то область исследования, также сужается и класс вариантов решений по проектированию, которые могут быть эффективно реализованы.»
«Как только определены сферы деятельности, возникает проблема координации. Координация между рабочими группами, хотя и снижает продуктивность отдельных сотрудников в небольшой группе, обеспечивает единственную возможность того, что отдельные рабочие группы смогут объединить свои усилия в единую систему.»
«осознание первоначальными проектировщиками того, что система будет большой, вместе с определенным давлением в организации делает непреодолимым искушение назначить для разработки дизайна слишком много людей»
«Менеджер должен отдать в субподряд важную и сложную задачу по проектированию. Он выбирает между двумя подрядчиками: небольшой новой организацией, которая предлагает интуитивно привлекательный подход за гораздо меньшие, чем заложено в бюджете, деньги, и давно зарекомендовавшей себя, но традиционной организацией, которая требует более «реалистичную» плату. Он знает, что, если яркая молодая организация не сможет добиться достаточных результатов, его обвинят в неумелом управлении, а если потерпит неудачу проверенная организация, это будет доказательством того, что проблема действительно сложна.
В чем тут сложность? Большая ее часть относится к рассуждениям об измерении ресурсов, вытекающим из традиционной теории бухгалтерского учета. Согласно этой теории, единицей ресурса является доллар, и все ресурсы должны измеряться с использованием единиц измерения, конвертируемых в доллары. Если ресурсом является человеческий труд, единицей измерения является количество часов, отработанных каждым человеком, умноженное на его почасовую ставку, суммированные для всей рабочей силы.
Одним из заблуждений, лежащих в основе этого расчета, является свойство линейности, согласно которому два человека, работающие в течение года, или сто человек, работающие в течение недели (при одинаковых почасовых ставках на человека), являются ресурсами равной ценности. Если предположить, что два человека и сто человек не могут работать в одной и той же организационной структуре (это интуитивно очевидно и будет обсуждаться ниже), наш гомоморфизм говорит, что они не будут проектировать подобные системы; поэтому ценность их усилий может быть даже несопоставимой. По опыту мы знаем, что два человека, если они правильно подобраны и имеют нужный опыт, дадут нам лучшую систему. Предположения, которые могут быть достаточными для чистки картошки и возведения кирпичных стен, не годятся для проектирования систем.»
«Даже в умеренно небольшой организации возникает необходимость ограничить общение, чтобы люди могли выполнить какую-то «работу».»
«Необходима философия управления дизайном систем, которая не основывается на предположении, что простое добавление рабочей силы повышает производительность.» – Закон Конвея именно об этом, хоть и звучит как «организация, проектирующая систему (в принятом здесь широком смысле), производит дизайн, являющийся копией коммуникационных структур этой организации»
Forwarded from Russian Association of Software Architects (Ivan Zakrevsky)
Raft - Understandable Distributed Consensus
- https://thesecretlivesofdata.com/raft/
- простая и понятная интерактивная визуализация алгоритма.
#DistributedSystems
- https://thesecretlivesofdata.com/raft/
- простая и понятная интерактивная визуализация алгоритма.
#DistributedSystems
Forwarded from Архитектура ИТ-решений
📖 Метод QUERY возможно появится в протоколе HTTP. (Драфтом IETF RFC поделился Ivan Begtin в своем telegram-канале ). Мотивация такого расширения протокола достаточно очевидна. Так же, как и метод GET, новый метод QUERY будет безопасным и идемпотентным. Однако параметры запроса будут передаваться не в строке, а в теле запроса. Собственно, возможные ограничения длины адресной строки и были основной причиной использования для передачи запросов метода POST, который изначально был придуман для публикации команд.
Драфт RFC предусматривает два варианта ответа.
Подробности: https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-method-w-body/
Драфт RFC предусматривает два варианта ответа.
Direct Response вернет результаты на ваш запрос в теле ответа. Indirect Response вернет 303 код, расшифровываемый как See Other, и гиперссылку в параметре Location по которой можно будет запросить результаты обработки запроса методом GET.Подробности: https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-method-w-body/
Telegram
Ivan Begtin
Тем временем, буквально недавно, в июле, появилось предложение по изменению в стандарт HTTP добавлением типа запроса QUERY для запросов в базы данных [1] [2] нечто что имеет самое непосредственное отношение к современным базам данных, индексированию веб сайтов…
Forwarded from Библиотека питониста | Python, Django, Flask
🛠 Как использовать REST API: полное руководство для начинающих
Лонгрид о концепциях, особенностях стиля архитектуры и проблемах REST API.
https://proglib.io/sh/qlGMvA6ie8
Лонгрид о концепциях, особенностях стиля архитектуры и проблемах REST API.
https://proglib.io/sh/qlGMvA6ie8
Forwarded from Сингулярити 🎉
Дуров рассказал о стоимости поддержки Telegram. Ну, не прям рассказал...
Он написал, что хватит премиум подписки от 2,5% пользователей. Которых сейчас 700 млн. При цене в $5 (а она примерно такова) получаем простое решение:
700 * 0.025 * 5 * 12 = 1050 (млн долларов)
Миллиард долларов в год стоит поддержка инфраструктуры Телеграма.
В принципе, мы так и прикидывали. На основе стоимости поддержки ФБ.
Так что наше удивление продолжается: Откуда деньги, Паша??
Долю Дурова при продаже VK оценили в $400 млн.
Еще $1,7 млрд Телеграм привлек от инвесторов в 2018 году на TON.
Еще $1 млрд год назад на размещении облигаций.
Так появились $3 млрд живых денег. И куда более высокие оценки состояния самого Дурова. Но то оценки.
Так откуда средства на поддержку мессенджера, затраты на которую дошли до $1 млрд в год? Деньги, где вы были 8 лет?
Крипта? Или что я упустил?
Он написал, что хватит премиум подписки от 2,5% пользователей. Которых сейчас 700 млн. При цене в $5 (а она примерно такова) получаем простое решение:
700 * 0.025 * 5 * 12 = 1050 (млн долларов)
Миллиард долларов в год стоит поддержка инфраструктуры Телеграма.
В принципе, мы так и прикидывали. На основе стоимости поддержки ФБ.
Так что наше удивление продолжается: Откуда деньги, Паша??
Долю Дурова при продаже VK оценили в $400 млн.
Еще $1,7 млрд Телеграм привлек от инвесторов в 2018 году на TON.
Еще $1 млрд год назад на размещении облигаций.
Так появились $3 млрд живых денег. И куда более высокие оценки состояния самого Дурова. Но то оценки.
Так откуда средства на поддержку мессенджера, затраты на которую дошли до $1 млрд в год? Деньги, где вы были 8 лет?
Крипта? Или что я упустил?
Forwarded from Сингулярити 🎉
Ну, в принципе... В принципе, если последний столбец MAU соответствует затратам в $1 млрд/год.
То еще плюс второй справа столбец и пропущенный между ними (за 2021 год) потянут как раз на $3 млрд.
А предыдущие суммарно еще миллиарда на 2.
Ну да, можно и на крипте вытянуть было.
https://www.statista.com/statistics/234038/telegram-messenger-mau-users/
То еще плюс второй справа столбец и пропущенный между ними (за 2021 год) потянут как раз на $3 млрд.
А предыдущие суммарно еще миллиарда на 2.
Ну да, можно и на крипте вытянуть было.
https://www.statista.com/statistics/234038/telegram-messenger-mau-users/
Forwarded from Derp Learning
Forwarded from Библиотека программиста | программирование, кодинг, разработка
Перед вами «Пирамида код-ревью», цель которой — помочь сосредоточить внимание на тех частях, которые наиболее важны во время код-ревью (во всяком случае, на взгляд автора), а также на том, какие части можно и нужно автоматизировать.
Нижние части пирамиды должны лежать в основе код-ревью и занимать его большую часть.
Скачать оригинал
Нижние части пирамиды должны лежать в основе код-ревью и занимать его большую часть.
Скачать оригинал
https://why-upgrade.depesz.com/show?from=11.13&to=13&keywords=
Просто шикарный сервис для понимания нафига обновляться на свежий постгрес и что обновление даст
Просто шикарный сервис для понимания нафига обновляться на свежий постгрес и что обновление даст
== Индексы. вводная
https://telegra.ph/Pss-paren-indeks-nuzhen-05-05
https://telegra.ph/Pss-paren-indeks-nuzhen-05-05
Telegraph
Псс, парень… индекс нужен?
Самый больной вопрос для любого разработчика, которому приходится вычитывать данные из базы: "Как сделать мой запрос быстрее?". Классический ответ - необходимо создать подходящий индекс. Но куда именно его стоит "накатывать", да и как вообще он должен выглядеть?..…
Forwarded from Russian Association of Software Architects (Ivan Zakrevsky)
SAGA - подборка ссылок из обсуждений чата канала:
🔷 Первоисточник по SAGA: "SAGAS" by Hector Garcia-Molina, Kenneth Salem
🔷 Перевод первоисточника по SAGA: "Гектор Гарсия-Молина и Кеннет Салем — «Саги»" / Михаил Ланкин
🔷 Applying the Saga Pattern • Caitie McCaffrey • GOTO 2015
🔷 Saga distributed transactions pattern
🔷 Process Manager Pattern
🔷 Compensating Transaction pattern
🔷 Пример реализации SAGA на Enterprise Integration Patterns (source code)
🔷 Пример реализации Process Manager от сообщества Microsoft (комментарий Greg Young). Альтернативы и обоснование.
🔷 Patterns and implementations for a banking cloud transformation
🔷 Несколько реализаций саг:
- https://axoniq.io
- https://eventuate.io/abouteventuatetram.html
- https://github.com/eclipse/microprofile-lra
- https://github.com/jbosstm/narayana/tree/master/rts/lra
🔷 Awesome workflow engines
🔷 "A long-running transaction model of workflow" by Quanzhou Hu; Jia Liu; Yi Zhuang; Yi Liu
🔷 "The CORBA Activity Service Framework for supporting extended transactions" by Iain Houston, M. C. Little, Ian Robinson, Santosh K. Shrivastava, Stuart M. Wheater
🔷 "What are long running processes?" by Bernd Rücker
🔷 Чем отличается SAGA от Process Manager:
- https://event-driven.io/en/saga_process_manager_distributed_transactions/
- https://stackoverflow.com/a/33652837
- https://blog.devarchive.net/2015/11/saga-vs-process-manager.html?m=1
🔷 "Eventually consistent" by Werner Vogels
🔷 "ACID properties of transactions"
🔷 "Atomicity :: Chapter 12. Berkeley DB Transactional Data Store Applications"
🔷 "Atomic - indivisible, not capable of being cut/divided into smaller pieces"
🔷 "Consistency Models"
🔷 интервью "Modeling Uncertainty with Reactive DDD" by Vaughn Vernon reviewed by Thomas Betts, в котором V.Vernon предлагает использовать Process Manager Pattern для обработки процессов, охватывающих несколько агрегатов в условиях Eventual Consistency.
Посмотреть реализацию в исполнении V. Vernon, включая ProcessTimedOut (о чем часто спрашивают), можно здесь:
- Java
- .Net
🔷 "Camunda Platform 8 Docs :: BPMN coverage"
🔷 Eclipse Microprofile стандарт имеет понятие LRA - Long Running Application. это есть их интерпретация саг
🔷 Microprofile-compatible фреймворки а-ля micronaut.io
🔷 RedHat развивает референс имплементацию Microprofile в виде своего фреймворка quarkus.io
🔷 Red Hut Summit "Saga: The new era of transactions in a
microservices architecture" by Giovanni Marigi, Mauro Vocale. BOSTON, MA | MAY 7-9, 2019
🔷 Вот пример Camunda. их интерпретация и имплементация саг )). Там всё очень упрощено и декларативно.
🔷 Architecture standard определяет сагу в пункте 21.2.7. Ensuring Global Consistency with Saga Patterns
Спасибо, что развиваете отрасль с помощью нашего чата!
#DistributedSystems #Многоликий
🔷 Первоисточник по SAGA: "SAGAS" by Hector Garcia-Molina, Kenneth Salem
🔷 Перевод первоисточника по SAGA: "Гектор Гарсия-Молина и Кеннет Салем — «Саги»" / Михаил Ланкин
🔷 Applying the Saga Pattern • Caitie McCaffrey • GOTO 2015
🔷 Saga distributed transactions pattern
🔷 Process Manager Pattern
🔷 Compensating Transaction pattern
🔷 Пример реализации SAGA на Enterprise Integration Patterns (source code)
🔷 Пример реализации Process Manager от сообщества Microsoft (комментарий Greg Young). Альтернативы и обоснование.
🔷 Patterns and implementations for a banking cloud transformation
🔷 Несколько реализаций саг:
- https://axoniq.io
- https://eventuate.io/abouteventuatetram.html
- https://github.com/eclipse/microprofile-lra
- https://github.com/jbosstm/narayana/tree/master/rts/lra
🔷 Awesome workflow engines
🔷 "A long-running transaction model of workflow" by Quanzhou Hu; Jia Liu; Yi Zhuang; Yi Liu
🔷 "The CORBA Activity Service Framework for supporting extended transactions" by Iain Houston, M. C. Little, Ian Robinson, Santosh K. Shrivastava, Stuart M. Wheater
🔷 "What are long running processes?" by Bernd Rücker
🔷 Чем отличается SAGA от Process Manager:
- https://event-driven.io/en/saga_process_manager_distributed_transactions/
- https://stackoverflow.com/a/33652837
- https://blog.devarchive.net/2015/11/saga-vs-process-manager.html?m=1
🔷 "Eventually consistent" by Werner Vogels
🔷 "ACID properties of transactions"
🔷 "Atomicity :: Chapter 12. Berkeley DB Transactional Data Store Applications"
🔷 "Atomic - indivisible, not capable of being cut/divided into smaller pieces"
🔷 "Consistency Models"
🔷 интервью "Modeling Uncertainty with Reactive DDD" by Vaughn Vernon reviewed by Thomas Betts, в котором V.Vernon предлагает использовать Process Manager Pattern для обработки процессов, охватывающих несколько агрегатов в условиях Eventual Consistency.
Посмотреть реализацию в исполнении V. Vernon, включая ProcessTimedOut (о чем часто спрашивают), можно здесь:
- Java
- .Net
🔷 "Camunda Platform 8 Docs :: BPMN coverage"
🔷 Eclipse Microprofile стандарт имеет понятие LRA - Long Running Application. это есть их интерпретация саг
🔷 Microprofile-compatible фреймворки а-ля micronaut.io
🔷 RedHat развивает референс имплементацию Microprofile в виде своего фреймворка quarkus.io
🔷 Red Hut Summit "Saga: The new era of transactions in a
microservices architecture" by Giovanni Marigi, Mauro Vocale. BOSTON, MA | MAY 7-9, 2019
🔷 Вот пример Camunda. их интерпретация и имплементация саг )). Там всё очень упрощено и декларативно.
🔷 Architecture standard определяет сагу в пункте 21.2.7. Ensuring Global Consistency with Saga Patterns
Спасибо, что развиваете отрасль с помощью нашего чата!
#DistributedSystems #Многоликий
Telegram
RASA Chat
Группа тг-канала объединения ИТ-архитекторов (@ru_arc)
Правила группы: https://news.1rj.ru/str/ru_arc_chat/2036
По бизнес-вопросам (ИП, ООО, ВЭД):
@rasa_business
Практические кейсы:
@archicases
Предложить доклад для митапа: @ru_arc_meetup_bot
Правила группы: https://news.1rj.ru/str/ru_arc_chat/2036
По бизнес-вопросам (ИП, ООО, ВЭД):
@rasa_business
Практические кейсы:
@archicases
Предложить доклад для митапа: @ru_arc_meetup_bot
Forwarded from LEFT JOIN
🔥 SQL-запрос для проведения ABC-анализа
Если вы работали с аналитикой ассортиментной матрицы или продаж, то вы точно сталкивались с таким методом, как ABC-анализ.
И сегодня вместе с ребятами из IT Resume мы решили подробно разобрать: как сделать ABC анализ с помощью всего одного SQL-запроса.
Интересно, что некоторые используют ABC-анализ даже в личном тайм-менеджменте. Все потому что он основан на законе Парето, который легко можно переформулировать на абсолютно любую сферу. Например:
20% ваших действий приносят 80% результата
20% ваших клиентов приносят 80% прибыли
20% вашего ассортимента приносят 80% продаж
Ну дальше вы поняли... Кстати, узнать все про тайм-менеджмент вы сможете в сегодняшнем выпуске подкаста Data Heroes 👾
Если вы работали с аналитикой ассортиментной матрицы или продаж, то вы точно сталкивались с таким методом, как ABC-анализ.
И сегодня вместе с ребятами из IT Resume мы решили подробно разобрать: как сделать ABC анализ с помощью всего одного SQL-запроса.
Интересно, что некоторые используют ABC-анализ даже в личном тайм-менеджменте. Все потому что он основан на законе Парето, который легко можно переформулировать на абсолютно любую сферу. Например:
20% ваших действий приносят 80% результата
20% ваших клиентов приносят 80% прибыли
20% вашего ассортимента приносят 80% продаж
Ну дальше вы поняли... Кстати, узнать все про тайм-менеджмент вы сможете в сегодняшнем выпуске подкаста Data Heroes 👾