Хочешь прогресс - иди в нормальное место, где занимаются МСМК/ЗМС/МС и прочие, на их фоне и с той атмосферой легко выйдешь на приличный уровень.
Желательно все эти знания о прогрессиях, подходах и прочем максимально делегировать - то есть у тебя есть тренер/парни в зале, которые все подскажут и расскажут - как и что делать, а свою голову не нужно перенагружать этим контекстом. Потому что знать все на эффективном уровне - почти фул тайм работа.
В странах СНГ это можно делегировать очень дешево, особенно айти специалистам - буквально 100 долларов в месяц достаточно, чтобы заниматься с людьми уровня международных соревнований или Олимпиады.
Лично мой опыт - пошел в Казахстане к МСМК по пауэрлифтингу, пожал 100кг от груди за два месяца тренировок, свой вес 67-70кг. А так мог бы ходить в качалку пару лет "просто так" и мечтать о сотке, вместо направленных хороших тренировок у тренера высокого уровня.
Среди людей с ВО меньше "ошибок", чем среди людей без ВО, и так далее.
Тут как с кредитами в Америке - можно очень топорно давать только белым семьям среднего класса, чтобы точно отдали, а другим - не давать, тогда и МЛ/анализ не нужен. А можно и применить глубокий анализ, чтобы найти хорошего кредитора в черном гетто.
Считаю, в IT найме также - можно по широким коррелирующим признакам, типа ВО или пятерок в школе, отсеять людей, а можно каждого собесить, собирать вторичные признаки и находить "алмазы в грязи".
У меня повышенная концентрация во время голода. То есть время пообедать, но если я затяну и поработаю голодным - очень концентрирован и продуктивен. В итоге выбор между массонабором и продуктивностью.
Мне кажется тут полностью текут абстракции, слоенность нарушена, не пахнет какой-либо архитектурой, а статью писал технический писатель.
Почему в слое бизнес логики есть понятие Database? session? EntityDatabaseModel? Это все детали конкретной реализации инфраструктурного слоя, если быть точнее - orm/sql специфика. У вас могут entity создаваться через http запросы, к примеру, и вам придется все переписывать.
С нормальным расслоением у вас будет EntityRepository(к примеру) интерфейс, который можно реализовать как DatabaseEntityRepository, где в методе create уже будет вся специфика базы данных - как создание session, всякие ОРМ модели и тп. А можно реализовать как HttpEntityRepository, где уже своя специфика - работа с json и обработка статус кодов. В вашем коде все переплетено сильным coupling, слой бизнес логики зависит от слоя инфраструктуры(должно быть наоборот, если что), а DI и не пахнет.
В настоящей слоеной архитектуре слой бизнес логики не зависит от других слоев, все зависят от него. Из других слоев ничего не импортируется, а все слои зависят от слоя бизнеса, принимая и возвращая его сущности, а также реализуя его интерфейсы.
Покажу на примере, сначала ваш код:
def create(dto: bll_schemas.DTO()) -> bll_schemas.dto:
with database.start_session(): # Это не бизнес логика, sql специфика
if database.get(**object): # специфика базы данных
raise bll_exc.DuplicateError("Object is already created") # ошибка ОРМ
database_entity = database_models.Entity(**object.model_dump()) # ОРМ модель
database.create(session=session, object=database_entity) # вызов ОРМ
return self.service_schema.from_orm(database_entity) # слой представления знает о слое архитекртуры
И как это могло быть:
def business_create(dto: EntityDomain, repo: EntityRepo) -> EntityDomain: # EntityRepo - интерфейс, можно послать любую реализацию
try:
res = repo.create(dto)
except DuplicateError: # бизнес ошибка
...
...
return res
class SQLEntityRepo(EntityRepo): # SQL-пример репозитория, EntityRepo определен в бизнес слое как абстракция для реализаций
def create(self, dto: EntityDTO) -> EntityDTO:
q = database_models.Entity(**object.model_dump())
try:
session.add(q)
session.commit()
session.refresh()
except DatabaseException as exc:
session.rollback()
raise DuplicateError # Рейзим именно бизнес ошибку
return dto
class HTTPEntityRepo(EntityRepo): # Http-пример репозитория
def create(self, dto: EntityDTO) -> EntityDTO:
res = requests.post("create-url", data=dto.dict())
if res.status_code == 409:
raise DuplicateError
return EntityDTO(**res.json())
Детали реализации мы прячем, к примеру бизнес кейс "DuplicateError" в случае sql - это IntegrityError, а в случае http - статус код и какой-то текст в json. Бизнес слою об этому знать не надо, репозиторий обрабатывает все и выдает уже бизнес ошибку DuplicateError. В вашем же коде почему-то бизнес обрабатывает IntegrityError конкретной ORM. С кодом выше - именно бизнес слой изолирован, у нас есть интерфейс для инфраструктурного слоя, который можно реализовать как угодно, в тестах можно через DI протестировать бизнес логику, послав специальный тестовый репозиторий и т.д.
Все максимально книжно и утрированно, в реальном мире есть побольше абстракций - всякие Gateways, Interactors, UoW и тп, но для примера - это и есть слоенная архитектура. Если честно, не понимаю, как можно прочитать хотя бы одну из книг по теме и написать то, что написано в статье. А у вас подача, словно вы перечитали их много, вот ваша цитата: "Думаю многие читали кучу книжек по поводу Hexagonal, Onion, Clean, Layer Architecture".
Согласен, пока это про простые и интуитивные алгоритмы уровня "прицепи побольше hashmap'ов" и подобные, но когда идут задачи, которые не решаемы без знания подхода, по типу DFS или подобного, то это не связано с работой. В работе не юзают рекурсию, потому что у нее в популярных языках ограничен стек, в целом рекурсию и протестить тяжело, и поддерживать, а многие middle/hard задачи не такие уж и сложные, но если не знаешь всякие DFS/мемоизации/backtracking и тп, то могут быть в принципе не решаемыми. Пример - найти все возможные пермутации чисел из списка. Зная как такое решается - решается мгновенно, не зная - не решается в принципе.
Офигенный бизнесмен =) Пройдемся по вашему "сервису":
На сайте bothub.ai невалидный сертификат. Браузеры туда не запустят.
В футере написано Copyright 2016-2018. Сейчас если что 2023 год.
Лендинг на конструкторе с вотермарками вордпресса и thrive themes.
Кривой английский на лендосе - пример "Our partners and support platforms" - supported platforms, а не support platforms. "Trusted by the world's leading business" - businesses, там множество бизнесов, а не один. И такого много, машинный перевод в общем.
Очередной богато-успешный инфоцыганин без своего бизнеса учит делать бизнес.
А практика судов и разбирательств была какая-то? Просто я еще с весны 2022 года эти вопросы задаю разным юристам - все по-разному трактуют эти законы и положения. У кого не спрашивал из уехавших - ни с кого еще не было "спроса" - многие тихо-молча получают зарплату в Армении/Казахстане/Турции и пр, но никого никак не уведомляли и ничего подобного не делали, но судя по многим вот таким F.A.Q - они уже нарушили закон.
Накрадываются мысли о массовой амнистии, просто ну очень много людей "нарушили" закон.
Если представить ситуацию - из вашего же скриншота - кто-то попросил фронтенд оптимизировать скорость билда и в целом это решить. Это же теперь исключительно задача одного squad'а? Или все же есть задачи не по squad'ам, а по гильдиям? А то один фронтендер из одного squad'а все сделает не очень очевидным образом, а потом нужен будет как минимум knowledge transfer, синки и прочие мероприятия.
Просто как я вижу если один squad делает какие-то не очень очевидные апдейты - надо все всем рассказать, пояснить и так далее. "Сетка рушится" - как с такими ситуациями обходиться? Возвращаться к долгим встречам и тредам на 10+ человек?
В веб Python стандартная практика иметь своих наследников Exception, которые ловятся на уровне фреймворка специальными error handler'ами, для выдачи стандартизированных 4хх(а может и 5хх) ошибок. Обычно они имеют свои атрибуты - для детализации ошибки. Странно, что в статье об этом не упомянуто.
В своём опыте не встречал, к сожалению, кросс-процессорных/ядровых/процессовых потоков, все всегда было в рамках одного процесса, выше - только уже воркеры и тп, максимально за абстракциями. Что-то уровня 1 ядро = 1 процесс и около того.
На уровне одного процесса у асинка меньше оверхед, и он даст результат лучше в плане RPS и прочего.
UPD. в случае многоядерного ЦПУ - просто много асинхронных воркеров под количество ядер, вот и утилизация на 100%. Думаю даже оверхед выиграет.
Продвинутые(в моём понимании) виды параллельности, что вы описали, как компановка операций в один тик, межпроцессовые треды в рамках одной задачи и тп думаю в самом деле перебьют асинк, ибо "пул" больше, но в стандартном вебе такого не встречал.
У меня такое представление: Треды/Потоки тоже не исполняются одновременно, разница лишь в том, что потоки - "рандом", и на уровне ОС решается, какой поток должен исполняться в конкретный промежуток времени(кроме Greenlet), а асинхронность - да, цикл и прочее, но тоже одна задача в промежуток времени исполняется, просто всё решается на уровне приложения.
Я не слышал о таком, чтобы потоки были действительно параллельны, как процессы. Именно параллельны, то есть одновременно исполяющиеся, а не последовательны. Может есть какие-то бонусы от памяти/контекста исполнения, но используя 100% CPU что асинк, что многопоточность будут примерно одинаковы, ибо на самом деле делают считай одни и те же вещи - "прыгают" от ожидающей задачи к готовой к исполнению. Просто у асинка все делает eventloop и реализация приложения/языка, а у тредов - ОС(кроме зеленых тредов).
И собственно говоря мой вопрос отсюда и возник - где треды берут "лишнюю" работу ЦПУ? От физики не уйти, как вы сказали. И все будет ограничено железом ну и оверхедом от реализаций/вызовов и тп.
П.С про процессы все понятно, к ним вопросов нет. Но даже они обычно - воркеры, считай копии приложения, а не подресурс в одном контексте исполнения(зависит от приложения, конечно).
У меня искренний вопрос, а как мультипоточность может дать выигрыш над асинхронностью? Треды также будут ограничены ресурсом CPU же? Или я что-то не так понимаю?
Да, тогда понятно. Ну я бы отредактировал, а то неоднозначно можно воспринять текст.
Про множественное число асинхронных потоков я удивился в контексте одного процесса - зачем, это лишь оверхед. Если в разных воркерах/процессах - конечно, там все "отдельное".
выполняя все функции с синхронным I/O в отдельном потоке
Я не совсем понял - поток же быстро "застрянет"? Одна блокирующая операция на несколько секунд заставит все остальные ждать. И так быстро дойдет до сотен секунд. Почему один поток для синхронных операций? Почему много потоков для асинхронных операций? Наоборот же.
Резюмируя: есть веские причины обрабатывать всю синхронную нагрузку вне асинхронных потоков
Множественное число у асинхронных потоков - почему? Асинхронность - про один тред с event loop и прочим, если мы про async, а не более глобально(параллельность).
Может произошла коллизия терминов, и вы имели ввиду под "потоками" не Thread из ОС, а в целом нечто абстрактное как "работа". Но думаю, если вы про Threads, то что-то странное написано...
Месяц назад примерно. Сейчас несколько дней назад Каспи одобрили, но мне он не особо актуален - там нет долларовых счетов.
Фридом финанс тоже одобрил с месяц назад, но там убогая двойная конвертация валюты, не стал открывать.
UPD. Решил упомянуть, что я тут лично нахожусь, снял квартиру, получил ИНН и выгляжу как казах(бурят), может эти факторы сыграли как-то. Никаких доверенностей и тд.
Выдают в БЦК, других банках поменьше. Я лично в КЗ приехал после Грузии, мне там не понравилось. В БЦК открыл, в Халыке и прочих отказали. ИНН обязателен.
Хочешь прогресс - иди в нормальное место, где занимаются МСМК/ЗМС/МС и прочие, на их фоне и с той атмосферой легко выйдешь на приличный уровень.
Желательно все эти знания о прогрессиях, подходах и прочем максимально делегировать - то есть у тебя есть тренер/парни в зале, которые все подскажут и расскажут - как и что делать, а свою голову не нужно перенагружать этим контекстом. Потому что знать все на эффективном уровне - почти фул тайм работа.
В странах СНГ это можно делегировать очень дешево, особенно айти специалистам - буквально 100 долларов в месяц достаточно, чтобы заниматься с людьми уровня международных соревнований или Олимпиады.
Лично мой опыт - пошел в Казахстане к МСМК по пауэрлифтингу, пожал 100кг от груди за два месяца тренировок, свой вес 67-70кг.
А так мог бы ходить в качалку пару лет "просто так" и мечтать о сотке, вместо направленных хороших тренировок у тренера высокого уровня.
False positives и False negatives.
Среди людей с ВО меньше "ошибок", чем среди людей без ВО, и так далее.
Тут как с кредитами в Америке - можно очень топорно давать только белым семьям среднего класса, чтобы точно отдали, а другим - не давать, тогда и МЛ/анализ не нужен. А можно и применить глубокий анализ, чтобы найти хорошего кредитора в черном гетто.
Считаю, в IT найме также - можно по широким коррелирующим признакам, типа ВО или пятерок в школе, отсеять людей, а можно каждого собесить, собирать вторичные признаки и находить "алмазы в грязи".
У меня повышенная концентрация во время голода. То есть время пообедать, но если я затяну и поработаю голодным - очень концентрирован и продуктивен.
В итоге выбор между массонабором и продуктивностью.
Мне кажется тут полностью текут абстракции, слоенность нарушена, не пахнет какой-либо архитектурой, а статью писал технический писатель.
Почему в слое бизнес логики есть понятие Database? session? EntityDatabaseModel? Это все детали конкретной реализации инфраструктурного слоя, если быть точнее - orm/sql специфика. У вас могут entity создаваться через http запросы, к примеру, и вам придется все переписывать.
С нормальным расслоением у вас будет EntityRepository(к примеру) интерфейс, который можно реализовать как DatabaseEntityRepository, где в методе create уже будет вся специфика базы данных - как создание session, всякие ОРМ модели и тп. А можно реализовать как HttpEntityRepository, где уже своя специфика - работа с json и обработка статус кодов. В вашем коде все переплетено сильным coupling, слой бизнес логики зависит от слоя инфраструктуры(должно быть наоборот, если что), а DI и не пахнет.
В настоящей слоеной архитектуре слой бизнес логики не зависит от других слоев, все зависят от него. Из других слоев ничего не импортируется, а все слои зависят от слоя бизнеса, принимая и возвращая его сущности, а также реализуя его интерфейсы.
Покажу на примере, сначала ваш код:
И как это могло быть:
Детали реализации мы прячем, к примеру бизнес кейс "DuplicateError" в случае sql - это IntegrityError, а в случае http - статус код и какой-то текст в json. Бизнес слою об этому знать не надо, репозиторий обрабатывает все и выдает уже бизнес ошибку DuplicateError. В вашем же коде почему-то бизнес обрабатывает IntegrityError конкретной ORM. С кодом выше - именно бизнес слой изолирован, у нас есть интерфейс для инфраструктурного слоя, который можно реализовать как угодно, в тестах можно через DI протестировать бизнес логику, послав специальный тестовый репозиторий и т.д.
Все максимально книжно и утрированно, в реальном мире есть побольше абстракций - всякие Gateways, Interactors, UoW и тп, но для примера - это и есть слоенная архитектура.
Если честно, не понимаю, как можно прочитать хотя бы одну из книг по теме и написать то, что написано в статье. А у вас подача, словно вы перечитали их много, вот ваша цитата: "Думаю многие читали кучу книжек по поводу Hexagonal, Onion, Clean, Layer Architecture".
Согласен, пока это про простые и интуитивные алгоритмы уровня "прицепи побольше hashmap'ов" и подобные, но когда идут задачи, которые не решаемы без знания подхода, по типу DFS или подобного, то это не связано с работой.
В работе не юзают рекурсию, потому что у нее в популярных языках ограничен стек, в целом рекурсию и протестить тяжело, и поддерживать, а многие middle/hard задачи не такие уж и сложные, но если не знаешь всякие DFS/мемоизации/backtracking и тп, то могут быть в принципе не решаемыми.
Пример - найти все возможные пермутации чисел из списка. Зная как такое решается - решается мгновенно, не зная - не решается в принципе.
Офигенный бизнесмен =) Пройдемся по вашему "сервису":
На сайте bothub.ai невалидный сертификат. Браузеры туда не запустят.
В футере написано Copyright 2016-2018. Сейчас если что 2023 год.
Лендинг на конструкторе с вотермарками вордпресса и thrive themes.
Кривой английский на лендосе - пример "Our partners and support platforms" - supported platforms, а не support platforms. "Trusted by the world's leading business" - businesses, там множество бизнесов, а не один. И такого много, машинный перевод в общем.
Очередной богато-успешный инфоцыганин без своего бизнеса учит делать бизнес.
А практика судов и разбирательств была какая-то? Просто я еще с весны 2022 года эти вопросы задаю разным юристам - все по-разному трактуют эти законы и положения. У кого не спрашивал из уехавших - ни с кого еще не было "спроса" - многие тихо-молча получают зарплату в Армении/Казахстане/Турции и пр, но никого никак не уведомляли и ничего подобного не делали, но судя по многим вот таким F.A.Q - они уже нарушили закон.
Накрадываются мысли о массовой амнистии, просто ну очень много людей "нарушили" закон.
Если представить ситуацию - из вашего же скриншота - кто-то попросил фронтенд оптимизировать скорость билда и в целом это решить. Это же теперь исключительно задача одного squad'а? Или все же есть задачи не по squad'ам, а по гильдиям? А то один фронтендер из одного squad'а все сделает не очень очевидным образом, а потом нужен будет как минимум knowledge transfer, синки и прочие мероприятия.
Просто как я вижу если один squad делает какие-то не очень очевидные апдейты - надо все всем рассказать, пояснить и так далее. "Сетка рушится" - как с такими ситуациями обходиться? Возвращаться к долгим встречам и тредам на 10+ человек?
В веб Python стандартная практика иметь своих наследников Exception, которые ловятся на уровне фреймворка специальными error handler'ами, для выдачи стандартизированных 4хх(а может и 5хх) ошибок. Обычно они имеют свои атрибуты - для детализации ошибки.
Странно, что в статье об этом не упомянуто.
В своём опыте не встречал, к сожалению, кросс-процессорных/ядровых/процессовых потоков, все всегда было в рамках одного процесса, выше - только уже воркеры и тп, максимально за абстракциями. Что-то уровня 1 ядро = 1 процесс и около того.
На уровне одного процесса у асинка меньше оверхед, и он даст результат лучше в плане RPS и прочего.
UPD. в случае многоядерного ЦПУ - просто много асинхронных воркеров под количество ядер, вот и утилизация на 100%. Думаю даже оверхед выиграет.
Продвинутые(в моём понимании) виды параллельности, что вы описали, как компановка операций в один тик, межпроцессовые треды в рамках одной задачи и тп думаю в самом деле перебьют асинк, ибо "пул" больше, но в стандартном вебе такого не встречал.
Спасибо за разъяснения, узнал новое для себя.
У меня такое представление:
Треды/Потоки тоже не исполняются одновременно, разница лишь в том, что потоки - "рандом", и на уровне ОС решается, какой поток должен исполняться в конкретный промежуток времени(кроме Greenlet), а асинхронность - да, цикл и прочее, но тоже одна задача в промежуток времени исполняется, просто всё решается на уровне приложения.
Я не слышал о таком, чтобы потоки были действительно параллельны, как процессы. Именно параллельны, то есть одновременно исполяющиеся, а не последовательны. Может есть какие-то бонусы от памяти/контекста исполнения, но используя 100% CPU что асинк, что многопоточность будут примерно одинаковы, ибо на самом деле делают считай одни и те же вещи - "прыгают" от ожидающей задачи к готовой к исполнению. Просто у асинка все делает eventloop и реализация приложения/языка, а у тредов - ОС(кроме зеленых тредов).
И собственно говоря мой вопрос отсюда и возник - где треды берут "лишнюю" работу ЦПУ? От физики не уйти, как вы сказали. И все будет ограничено железом ну и оверхедом от реализаций/вызовов и тп.
П.С про процессы все понятно, к ним вопросов нет. Но даже они обычно - воркеры, считай копии приложения, а не подресурс в одном контексте исполнения(зависит от приложения, конечно).
У меня искренний вопрос, а как мультипоточность может дать выигрыш над асинхронностью? Треды также будут ограничены ресурсом CPU же? Или я что-то не так понимаю?
Да, тогда понятно. Ну я бы отредактировал, а то неоднозначно можно воспринять текст.
Про множественное число асинхронных потоков я удивился в контексте одного процесса - зачем, это лишь оверхед. Если в разных воркерах/процессах - конечно, там все "отдельное".
Я не совсем понял - поток же быстро "застрянет"? Одна блокирующая операция на несколько секунд заставит все остальные ждать. И так быстро дойдет до сотен секунд. Почему один поток для синхронных операций? Почему много потоков для асинхронных операций? Наоборот же.
Множественное число у асинхронных потоков - почему? Асинхронность - про один тред с event loop и прочим, если мы про async, а не более глобально(параллельность).
Может произошла коллизия терминов, и вы имели ввиду под "потоками" не Thread из ОС, а в целом нечто абстрактное как "работа". Но думаю, если вы про Threads, то что-то странное написано...
Месяц назад примерно. Сейчас несколько дней назад Каспи одобрили, но мне он не особо актуален - там нет долларовых счетов.
Фридом финанс тоже одобрил с месяц назад, но там убогая двойная конвертация валюты, не стал открывать.
UPD. Решил упомянуть, что я тут лично нахожусь, снял квартиру, получил ИНН и выгляжу как казах(бурят), может эти факторы сыграли как-то. Никаких доверенностей и тд.
Выдают в БЦК, других банках поменьше. Я лично в КЗ приехал после Грузии, мне там не понравилось. В БЦК открыл, в Халыке и прочих отказали. ИНН обязателен.