Forwarded from Заметки программиста
📌 Шпаргалка по шаблонам проектирования
Сохраняй себе и делись с друзьями! Версия в исходном качестве снизу.
#cheatsheet
Сохраняй себе и делись с друзьями! Версия в исходном качестве снизу.
#cheatsheet
Forwarded from Заметки программиста
https://youtube.com/playlist?list=PL4_hYwCyhAvYyx4TIRk6tLG0c8CLGzhE5
Как проектировать HighLoad системы. Целый курс. Препод шикарнейший
Как проектировать HighLoad системы. Целый курс. Препод шикарнейший
YouTube
Highload (4 курс, весна 2021)
Share your videos with friends, family, and the world
Forwarded from Блог Сергея Баранова
Разрабатываемые нами вычислительные системы по своей природе асинхронны. Есть задержки, есть переключения регистрови контекстов, задержки в сети и так далее. В двух словах разница между синхронным и асинхронным взаимодейсвтии в предположениях о времени.
Асихнронная модель взаимодействия не делает никаких предположений о времени (нет синхронности процессов, задежка сообщений хоть и конечна, но не ограничена и нет верхней границы на время выполнения запроса процессом) в то время как синхронное взаимодействие делает в отношении времени строгие предположения (процессы синхронизированы, передача и доставка сообщения за один логический шаг, наличие известной верхней границы на на время выполнения запроса).
Проектировать и тестировать проще синхронное взаимодействие. Но строить синхронную систему и организовать доставку сообщений за ограниченное время сложнее. Проектирование синхронное взаимодействия будет неизбежно включать в себя задержки и/или блокировки. Синхронность – это абстракция, требующая усилий по синхронизации процессов.
О чем всегда стоит помнить – это каскадные сбои при синхронных взаимодействиях. Какой-то процесс в глубине системы при блокирующих вызовах замедляется, поток на клиенте ждет и потребляет ресурсы/память, одновременно начинают происходить вертикальный (клиент клиента и так далее по цепочке ждут и потребляют ресурсы) и горизонтальный (если запросы повторяются и встают в ожидании, то соседние потоки ждут и потребляют ресурсы) отказы. Если это происходит в транзакции, то начинают тормозить базы данных и соответственно соседние потоки, все это распространяется по системе, cервера начинают перезагружаться, нарастает нагрузка на соседние ноды, они тоже падают. Всё останавливается. Все получают timeout error или нечто подобное. Экран гаснет.
Были в вашей практике каскадные сбои? =)
Хотел было заменить термин «процесс» на термин «сервис», отойти от строгости, но смысл тогда искажается, хотя Мартин Фаулер в своем определении микросервиса и указал, что «это подход, при котором единое приложение строится как набор небольших
сервисов, каждый из которых работает в собственном процессе…», но для точности следует отметить, что множество экземпляров, то есть процессов, остаются одним сервисом, даже если внутренняя, распределенная природа такой структуры скрыта за экспортируемым во внешний мир интерфейсом.
Асихнронная модель взаимодействия не делает никаких предположений о времени (нет синхронности процессов, задежка сообщений хоть и конечна, но не ограничена и нет верхней границы на время выполнения запроса процессом) в то время как синхронное взаимодействие делает в отношении времени строгие предположения (процессы синхронизированы, передача и доставка сообщения за один логический шаг, наличие известной верхней границы на на время выполнения запроса).
Проектировать и тестировать проще синхронное взаимодействие. Но строить синхронную систему и организовать доставку сообщений за ограниченное время сложнее. Проектирование синхронное взаимодействия будет неизбежно включать в себя задержки и/или блокировки. Синхронность – это абстракция, требующая усилий по синхронизации процессов.
О чем всегда стоит помнить – это каскадные сбои при синхронных взаимодействиях. Какой-то процесс в глубине системы при блокирующих вызовах замедляется, поток на клиенте ждет и потребляет ресурсы/память, одновременно начинают происходить вертикальный (клиент клиента и так далее по цепочке ждут и потребляют ресурсы) и горизонтальный (если запросы повторяются и встают в ожидании, то соседние потоки ждут и потребляют ресурсы) отказы. Если это происходит в транзакции, то начинают тормозить базы данных и соответственно соседние потоки, все это распространяется по системе, cервера начинают перезагружаться, нарастает нагрузка на соседние ноды, они тоже падают. Всё останавливается. Все получают timeout error или нечто подобное. Экран гаснет.
Были в вашей практике каскадные сбои? =)
Хотел было заменить термин «процесс» на термин «сервис», отойти от строгости, но смысл тогда искажается, хотя Мартин Фаулер в своем определении микросервиса и указал, что «это подход, при котором единое приложение строится как набор небольших
сервисов, каждый из которых работает в собственном процессе…», но для точности следует отметить, что множество экземпляров, то есть процессов, остаются одним сервисом, даже если внутренняя, распределенная природа такой структуры скрыта за экспортируемым во внешний мир интерфейсом.
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=
Просто шикарный сервис для понимания нафига обновляться на свежий постгрес и что обновление даст
Просто шикарный сервис для понимания нафига обновляться на свежий постгрес и что обновление даст