Звучит сложновато! Ну окей, переставлю питон в конец списка по приоритету.

тебе и идеи Larry Hastings небось симпатичны?)

тебе и идеи Larry Hastings небось симпатичны?)

Не в курсе)

Для кодинга небольшой игры имеет смысл кодить на питоне (panda3d) или ставить юнити сразу?

Подскажите, каким образом можно проверить IP-подсети на пересечение?

Для кодинга небольшой игры имеет смысл кодить на питоне (panda3d) или ставить юнити сразу?

Питон - так себе для игр

Не в курсе)

Этот господин не перестает хейтить питон за наличие gil и невозможности ему использовать питон в геймдеве, а Хеттингер отбивается от него asyncio

Питон - так себе для игр

А куда лучше смотреть? Кодю на питоне, кодил на Дельфи,asm,c

А куда лучше смотреть? Кодю на питоне, кодил на Дельфи,asm,c

Ну юнити норм. Или жс - тоже универсальная платформа

Dankè, посмотрю после работы

Подскажите, каким образом можно проверить IP-подсети на пересечение?

Для начала можно сравнить подсети, если не хватает, то можно пройтись по адресам https://docs.python.org/3/library/ipaddress.html#ipaddress.IPv6Network.subnets

но прям пересечение подсеть и подсеть с ответом новой подсети в либе не вижу

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

может быть можно решить как-то иначе?

Мне главное понимать, что подсети не пересекаются. Например, пользователь может по ошибке указать: 10.0.0.0/24 и 10.0.0.0/16

может быть можно решить как-то иначе?

Ну смотри, есть compare_networks, можно просто сравнить, можно нажать supernet и повычитать (address_exclude) отдельно A и B, если сети разные, результат будет разный, вариантов масса

Окей. Сейчас пробегусь по библиотеке. Спасибо за наводку

Окей. Сейчас пробегусь по библиотеке. Спасибо за наводку

Мне кажется такой вариант ок, поправьте если не прав, если адреса пересекаются, то при вычете из меньшей подсеток большей - в ответе будет непустой список: list(ip16.address_exclude(ip24))

Осталось сообразить, как проверить на пересечение все подсети из спсика...

Ну, как минимум, микросервисы нужны далеко не всем. Опять же, способ решения задачи у вас все равно может поменятся изз-за смены языка.

А что вместо них? :)

Разве, например, в python распараллеливание не дороже, чем в c, потому что в первом вы можете использовать только распараллеливание через процессы, так как в первом можно использовать потоки и шаринг общей памяти? И не может быть такого, что из-за перехода с С на python распараллеливание станет бессмысленным?

В си нет потоков.

Осталось сообразить, как проверить на пересечение все подсети из спсика...

Возьми все начала, все концы, отсортируй и убедись, что соседи не пересекаются

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

Чувак, ты - мой кумир

А что вместо них? :)

Ты не поверишь, как в старые - добрые времена, одно цельное приложение. Зачем микросервисы, если не нужен быстрый деплой?

Возьми все начала, все концы, отсортируй и убедись, что соседи не пересекаются

Спс! Хорошая идея :) Попробую редьюсом пробежаться..

Попробуй лучше циклом фор пробежаться

Здесь только есть небольшое но - если попробовать вычесть из net3 net1, то будет ValueError, то есть тебе перед вычетом нужно и сравнить к тому же

Я уже понял, что арифметические операции не реализованы в этом классе. Уже пробовал

Ты не поверишь, как в старые - добрые времена, одно цельное приложение. Зачем микросервисы, если не нужен быстрый деплой?

Меньше время на downtime, проще искать проблемы итп

Я уже понял, что арифметические операции не реализованы в этом классе. Уже пробовал

да, херовая либа, не хватает исключающего или

Есть только проверка на эквивалентность и для адресов проверка "больше" / "меньше"

пересечений не хватает

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

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

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

То есть тебе удобней разобрать 100к строк в монолите, чем локализовать за 5 минут по логам и разбрать уже 10к, если разбито на 10 микросервисов?

А почему такое же крутое логгирование не запилить в монолите?)

На самом деле еще зависит от качества монолита, но в целом его сложней поддерживать

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

Не. Ещё принудительно слабая свазность

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

Не. Ещё принудительно слабая свазность

Не-а. Есть даже такой антипаттер - распределенный монолит

Ужс

На самом деле еще зависит от качества монолита, но в целом его сложней поддерживать

Почему?

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

Ага, потом в коммитах появляются "hotfix", "mutherfuckhotfix", "prodinfire" и выясняется, что появилась связность, потому что никто технически это не запрещено, а что не запрещено технически, то будет эксплуатироваться

Ага, потом в коммитах появляются "hotfix", "mutherfuckhotfix", "prodinfire" и выясняется, что появилась связность, потому что никто технически это не запрещено, а что не запрещено технически, то будет эксплуатироваться

А, простите, как вы запретите технически связаность при микросервисах? Судя по тому, что существуют такие вещи, как "распределенный монолит" это так тоже не работает.

А, простите, как вы запретите технически связаность при микросервисах? Судя по тому, что существуют такие вещи, как "распределенный монолит" это так тоже не работает.

Связность микросервисов через endpoint происходит, это и не связность вовсе, а взаимодействие посредством сообщений!

А почему такое же крутое логгирование не запилить в монолите?)

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

А, простите, как вы запретите технически связаность при микросервисах? Судя по тому, что существуют такие вещи, как "распределенный монолит" это так тоже не работает.

разные адресные пространства. чтобы их преодолеть, придется явно втаскивать механизмы IPC

Связность микросервисов через endpoint происходит, это и не связность вовсе, а взаимодействие посредством сообщений!

да, message passing - наше всё. собственно, можно и соединения так передавать.

Связность микросервисов через endpoint происходит, это и не связность вовсе, а взаимодействие посредством сообщений!

У вас связность появляется тогда, когда вы определяете формат для сообщений. И как только из-за косяков проектирования получается ситуация, когда все 10 сервисов (ну или 7 из 10) надо задеплоить одновременно вместе, потому что у одного из них надо было поменять формат ответов, а во всех остальных надо поменять формат, что бы они умели в ним работать - вот тогда у вас появляется связность. Понижать связность в коде можно изоляцией модулей и абстракциями - эффект такой же, но проще и обходится дешевле.

разные адресные пространства. чтобы их преодолеть, придется явно втаскивать механизмы IPC

Всмысле? Так же делается, "hotfix" в один микросервис, "hotfix" в другой и "задеплойте их вместе, пожалуйста".

Всмысле? Так же делается, "hotfix" в один микросервис, "hotfix" в другой и "задеплойте их вместе, пожалуйста".

это если наговнякать в оба. микросервисы - это в каком-то смысле развитие идеи процессов операционной системы: если в нем что-то пошло не так, его можно убить/перезапустить.

монолитом так не получится.

хороший способ ограничть размеры failure domain

это если наговнякать в оба. микросервисы - это в каком-то смысле развитие идеи процессов операционной системы: если в нем что-то пошло не так, его можно убить/перезапустить.

Наговнякать в микросервисы - проще пареной репы, достаточно не проработать API, что встречается довольно часто и вуаля. Если вы не можете проработать API классов, с которыми будете работать, почему с микросервисами должно быть по другому?

Наговнякать в микросервисы - проще пареной репы, достаточно не проработать API, что встречается довольно часто и вуаля. Если вы не можете проработать API классов, с которыми будете работать, почему с микросервисами должно быть по другому?

см выше про failure domain size.

Ну да, это все следствия того, что можно деплоить части приложения независимо. Но опять же, это не нужно всем, особенно учитывая цену.

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

вообщем-то, это очевидные принципы построения систем массового обслуживания.

все это можно тупо заимствовать из erlang/otp

все эти деревья супервизоров, let it crash итп

Всем привет. Сталкивался кто то с паковкой проекта в standalone сборку ? в том плане что бы можно было завести проект у человека у которого даже python не установлен ? (пока пробую разобраться с pyinstaller и ему подобными но не совсем получается так как проект не маленький и обладает своими конфигами и ресурсами) куда копать ? возможно ли это ?

Всем привет. Сталкивался кто то с паковкой проекта в standalone сборку ? в том плане что бы можно было завести проект у человека у которого даже python не установлен ? (пока пробую разобраться с pyinstaller и ему подобными но не совсем получается так как проект не маленький и обладает своими конфигами и ресурсами) куда копать ? возможно ли это ?

docker

это уже прикрутил )

и даже работает ) правда требует у клиента поставленый докер.. что логично

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

До определенного предела. Опять же таки, как-то куча систем работает и без такого подхода, например, при помощи сервисно-ориентированной архитектуры и кучи воркеров. Та же магическая связка django + celery + rabbitmq + rdbs. Даже если какая-то celery задача упала или сильно грузит ресурсы, то при правильном подходе будет почти такой же эффект.

и даже работает ) правда требует у клиента поставленый докер.. что логично

здорово, теперь донеси клиенту, что докер дефакто-стандарт поставки в современном мире и дело сделано

здорово, теперь донеси клиенту, что докер дефакто-стандарт поставки в современном мире и дело сделано

) понял, спасибо! просто увы на python пишу только последние пол года, до этого не сталкивался с его дистрибуцией

Сейчас докер все заказчики принимают и даже радуются, что не что-то другое

До определенного предела. Опять же таки, как-то куча систем работает и без такого подхода, например, при помощи сервисно-ориентированной архитектуры и кучи воркеров. Та же магическая связка django + celery + rabbitmq + rdbs. Даже если какая-то celery задача упала или сильно грузит ресурсы, то при правильном подходе будет почти такой же эффект.

окей, вот у вас долгоживущий(десятки часов) коннект и вам надо рестартовать воркер - что вы делать будете?

Сейчас докер все заказчики принимают и даже радуются, что не что-то другое

Думаю пока на нем и остановлюсь... извращатся со всякими py2exe, pyinstaller и им подобными смысла нету

окей, вот у вас долгоживущий(десятки часов) коннект и вам надо рестартовать воркер - что вы делать будете?

Мне кажется, иметь долгоживущие коннекты, которые не умеют в рестарт - это немного антипаттер. Но тем не менее, большинство современных инструментов умеет делать graceful shutdown, когда дожидаются, пока все коннекты отключатся.

Мне кажется, иметь долгоживущие коннекты, которые не умеют в рестарт - это немного антипаттер. Но тем не менее, большинство современных инструментов умеет делать graceful shutdown, когда дожидаются, пока все коннекты отключатся.

ну вот есть, например, websocket.

И первое, что стоит научить делать вебсокет - это реконнект, потому что сеть дофига ненадежная

Мне кажется, иметь долгоживущие коннекты, которые не умеют в рестарт - это немного антипаттер. Но тем не менее, большинство современных инструментов умеет делать graceful shutdown, когда дожидаются, пока все коннекты отключатся.

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

Так люди так и делают, перенося точку терминации на nginx, зачем тут микросервисы? Ну и как я уже писал раньше - долгие коннекты, которые не умеют в реконнект - это игрушка дьявола. Моргнет сеть и все развалится, а сеть так довольно часто делает.

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

Так люди так и делают, перенося точку терминации на nginx, зачем тут микросервисы? Ну и как я уже писал раньше - долгие коннекты, которые не умеют в реконнект - это игрушка дьявола. Моргнет сеть и все развалится, а сеть так довольно часто делает.

ты не перенесешь терминацию вебсокета на nginx. вместо вебсокета можно взять http2 или какой-нибудь quic.

или любой другой протокол, который nginx не умеет.

например, у тебя сервис умеет redis-протокол

потому что куча библиотек и кода

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

Опять же таки, я не совсем понимаю, почему нельзя сделать тоже самое, просто втыкнув сервис, который будет это делать перед монолитом?

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

В случае распределения и делегирования ответственности на мироксервисы их и держать в голове проще и при разрастании также продолжать декомпозицию

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

Давай по классике, есть user, есть orders, два сервиса, как ты видишь себе возможное размытие границы в микросервисах? А вот размыть эти границы в монолите очень даже просто

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

Вы понимаете разницу между кооперативной и вытесняющей многозадачностью? И последствиями ошибок в кооперативной многозадачности? И зачем вообще нужна защита памяти, например?

Давай по классике, есть user, есть orders, два сервиса, как ты видишь себе возможное размытие границы в микросервисах? А вот размыть эти границы в монолите очень даже просто

Хм ... подскажите, как их размыть в монолите? Что-то в духе "user.get_orders()?)

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

это не архитектурные костыли. это обычные требования к живучести. ровно по той же причине делают переборки на кораблях/подлодках.

Вы понимаете разницу между кооперативной и вытесняющей многозадачностью? И последствиями ошибок в кооперативной многозадачности? И зачем вообще нужна защита памяти, например?

Возможно, я не прав, но мне казалось, что расшарить read-only данные можно без проблем.

Хм ... подскажите, как их размыть в монолите? Что-то в духе "user.get_orders()?)

Хотя бы даже это - нахождение в одной базе и хождение друг к другу через базу, минуя бизнес-логику сверху в каких-нибудь вьюхах, через которые ты ходить не можешь

в csv можно переделать из dbf

Хотя бы даже это - нахождение в одной базе и хождение друг к другу через базу, минуя бизнес-логику сверху в каких-нибудь вьюхах, через которые ты ходить не можешь

потом люди начинают ходить в обход orm, потом апдейтить тулзами сбоку, потом начинают манкипатчить код, чтобы не ходить через mq

это не архитектурные костыли. это обычные требования к живучести. ровно по той же причине делают переборки на кораблях/подлодках.

Как можно требовать живучести, если ее обеспечить можно только в комнатных условиях?

Ну за это уже по рукам, а получить в монолите объект напрямую без логики вьюхи это общепринятый паттерн, а если вдруг выясняется, что хотелось бы эту логику провернуть, то мы ее куда-нибудь вытащим и будем использовать отовсюду! Ура успех, реюзабельность

Как можно требовать живучести, если ее обеспечить можно только в комнатных условиях?

ну каких комнатных? 2бп, 2 отдельных ввода, резервирование коммутаторов и аплинков.