из серии "тула, где ты была раньше?" https://jakearchibald.com/2021/cors/playground/
как по нормальному работать CORS
демка для каждого из запроса
удобно и понятно
как по нормальному работать CORS
демка для каждого из запроса
удобно и понятно
Forwarded from Вебня (Roman Dvornov)
Monorepo.tools
"Все что вам нужно знать о монорепах и инструментах, чтобы их построить" – с таким слоганом запустился новый сайт про моно-репозитории. На нем собраны основные тезисы и материалы в пользу монореп, а так же разобраны ключевые иструменты для их построения (Bazel, Gradle, Lage, Lerna, Nx, Rush и Turborepo) с разбивкой по фичам и сводной таблицей. Хорошая отправная точка для тех кто задумывается о монорепе или ищет подходящий инструмент.
"Все что вам нужно знать о монорепах и инструментах, чтобы их построить" – с таким слоганом запустился новый сайт про моно-репозитории. На нем собраны основные тезисы и материалы в пользу монореп, а так же разобраны ключевые иструменты для их построения (Bazel, Gradle, Lage, Lerna, Nx, Rush и Turborepo) с разбивкой по фичам и сводной таблицей. Хорошая отправная точка для тех кто задумывается о монорепе или ищет подходящий инструмент.
Toxiproxy
https://github.com/Shopify/toxiproxy
проксисерв для того что бы сэмитировать плохую сеть.
рандомно рвет провода, кидается говном... все как в жизни короч
https://github.com/Shopify/toxiproxy
проксисерв для того что бы сэмитировать плохую сеть.
рандомно рвет провода, кидается говном... все как в жизни короч
GitHub
GitHub - Shopify/toxiproxy: :alarm_clock: A TCP proxy to simulate network and system conditions for chaos and resiliency testing
:alarm_clock: :fire: A TCP proxy to simulate network and system conditions for chaos and resiliency testing - GitHub - Shopify/toxiproxy: :alarm_clock: A TCP proxy to simulate network and system co...
Forwarded from Хитрый Питон
Возможно, вы слышали о AST — это встроенная в питон библиотека для построения абстрактного синтаксического дерева кода. AST используется, например, при написании линтеров. Минус в том, что он позволяет анализировать код, но при этом выкидывает части кода, которые не важны для компилятора, но важны для нас (например, комментарии).
Некоторое время назад Instagram выложил LibCST - которая гораздо бережнее относится к коду и соответственно может использоваться не только для проверки, но и для модификации кода.
В статье разобран хороший пример, как с помощью LibCST можно написать инструмент для ручного рефакторинга кода, который было бы сложно сделать другими инструментами (и долго и неудобно вручную). Если вам интересна тема разработки инструментария для python - рекомендую https://engineering.instawork.com/refactoring-a-python-codebase-with-libcst-fc645ecc1f09
Некоторое время назад Instagram выложил LibCST - которая гораздо бережнее относится к коду и соответственно может использоваться не только для проверки, но и для модификации кода.
В статье разобран хороший пример, как с помощью LibCST можно написать инструмент для ручного рефакторинга кода, который было бы сложно сделать другими инструментами (и долго и неудобно вручную). Если вам интересна тема разработки инструментария для python - рекомендую https://engineering.instawork.com/refactoring-a-python-codebase-with-libcst-fc645ecc1f09
Medium
Refactoring a Python Codebase with LibCST
How can an engineering team maintain consistent conventions in a growing codebase? When working on new code, engineers add new patterns to…
Forwarded from Коробка с питоном
Тут часть ядра pydantic переписали на Rust и он стал в 17 раз быстрее (код бенчмарка тут) чем обычный Pydantic.
Пока что WIP, выглядит многообещающее, но нет самой интеграции с pydantic, поэтому схемы могут делаться только через словари. Целью стоит увеличение скорости работы в ДЕСЯТЬ раз.
Пока что WIP, выглядит многообещающее, но нет самой интеграции с pydantic, поэтому схемы могут делаться только через словари. Целью стоит увеличение скорости работы в ДЕСЯТЬ раз.
GitHub
GitHub - pydantic/pydantic-core: Core validation logic for pydantic written in rust
Core validation logic for pydantic written in rust - pydantic/pydantic-core
Forwarded from Питонические атаки
Небольшая подборка flake8 плагинов для тех, кто уже использует 3.10 и хочет писать тайп-хинты красиво:
1. flake8-new-union-types — заставляет переписывать
2. flake8-pep585 — заставляет использовать встроенные классы, например,
Знаете ещё полезное? Делитесь в комментариях!
#flake8
1. flake8-new-union-types — заставляет переписывать
Union[X, Y] на X | Y;2. flake8-pep585 — заставляет использовать встроенные классы, например,
list[dict[str, int]], без импортов из typing.Знаете ещё полезное? Делитесь в комментариях!
#flake8
GitHub
GitHub - xome4ok/flake8-new-union-types: Flake8 plugin to enforce the new Union and Optional annotation syntax defined in PEP 604
Flake8 plugin to enforce the new Union and Optional annotation syntax defined in PEP 604 - GitHub - xome4ok/flake8-new-union-types: Flake8 plugin to enforce the new Union and Optional annotation sy...
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