Собеседования без шансов: как менторы формируют неравные условия

Я умею работу работать и понятия не имею, проходить этот ненужный фильтр

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

Их не спрашивают - вы проходите HR-скрининг резюме автоматом, если вас кто-то порекомендует внутри компании

Собеседования без шансов: как менторы формируют неравные условия

Сложно сказать без конкретики. А откуда вы знаете про оценку 5+? Вы пытались связаться? Иногда просто бывают технические ошибки - условные ВК по моей оценке нанимает 120 человек в неделю, учитывая воронку там под 1000 собеседований каждую неделю

Собеседования без шансов: как менторы формируют неравные условия

Извините, если вам кажется это оскорблением. Если вы реально не можете пройти HR-фильтр после десяти лет опыта, то этому есть два объяснения - какие-то явные проблемы в резюме или не релевантный опыт. Обе проблемы можно за небольшие деньги независимо оценить, а первую еще и быстро исправить

Собеседования без шансов: как менторы формируют неравные условия

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

Собеседования без шансов: как менторы формируют неравные условия

Не понимаю этой проблемы для человека с 10 годами опыта, как вы пишете. Сейчас во всем российском бихтехе есть практика привлечения по рекомендации (за это еще обычно доплачивают 1-2 оклада привлеченного специалиста). Если у вас за 10 лет не нашлось никого, кто вас может так порекомендовать, то тут вопросы скорее к вам

DI в Python, Easy-DI: спаситель в сложном мире зависимостей

Есть проблема когда объекту А нужен объект Б, которому нужен объект С, который контекстный менеджер, а вам нужен именно А. Приходится через всю ирерахию протаскивать enter/__exit__

Я чего-то не понимаю пример. Если у зависимость А стала контекстным менеджером, то ее создание я заменил на with и передал в конечное место и больше ничего не нужно менять. Если объект C стал контекстным менеджером, я заменил его создание на with передал дальше в конструктор Б. Если у меня нормальный код, абстракции уровня С не текут вниз и мне больше ничего не надо менять. Или я не понял пример?

Контейнер имеет смысл только в интеграционных тестах (то есть там где уже всё сложно), в обычных тестах я пишу так как вы сказали - просто передаю мок/фейк

В интеграционном тесте вы создаете почти всю иерархию объектов, подменив на тестовые только некоторые инфраструктурные зависимости, и не меняете зависимости слоя бизнес-логика. Я не понимаю в чем тут экономия. Вы будете вынуждены написать новую функцию, которая собирает composition root и зарегистрировать все зависимости инфрового уровня некоторые, как некоторые как обычно. Я сделаю просто создам их

DI в Python, Easy-DI: спаситель в сложном мире зависимостей

Уточню, что я не считаю IoC-контейнер must-have инструментом, без которого приложение жить не может

А я считаю, что он не нужен, так как не решает никаких проблем

Это вспомогательная штука для создания вот таких фабрик. Его прелесть раскрывается когда фабрик становится много и среди них начинают встречаться контекстные менеджеры или какой-нибудь объект меняет скоуп

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

dep = Constructor()

заменяется на

with Constructor() as dep

Количество строк не меняется, вы явно видите, где у вас контекстный менеджер

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

Кстати про тесты - где там экономия?

С контейнером

1. Создается контейнер

2. Создается мок зависимости

3. Регистрируется мок зависимости

4. Внедряется контейнер в тестируемый объект

Без

1. Создается мок зависимости

2. Внедряется мок в тестируемый объект

DI в Python, Easy-DI: спаситель в сложном мире зависимостей

Да, стало. Теперь чтобы создать 10 объектов и прокинуть куда надо какие надо с переисползованием мне нужно писать 20+ строк фабрик и потом ещё неизвестно сколько чтобы в тестах переопределять

Вот это не понял. Если скоуп все приложение, то создаете один экземпляр в сomposition root приложения и передаете его и проблем нет. Если скокуп более более узкий, то пишите одну универсальную типизированную обертку для создания фабричной функции и передаете фабричную функцию

class Factory[D, **P]:
    def __int__(self, dep_type: type[D], *args: P.args, **kwargs: P.kwargs) -> None:
        self._dep_type = dep_type
        self._args = args
        self._kwargs = kwargs

    def __call__(self) -> D:
        return self._dep_type(*self._args, **self._kwargs)

Если у вас контекстный менеджер, то вызываете его перед предачей и передаете ровно так же, как у вас вызывается контекстный метод для создания скоупа

Я вам более того скажу я если честно не видел приложений, где зависимостей много и при этом можно обойтись механикой скоупов. Реальных в приложениях, где зависимостей много возникает и сложная логика создания зависимостей. Вот примерчик. Есть платежный движок с многими десятками интеграций с банками. В рамках скоупа платежа создается соответствующий адаптер. Казалось бы лафа для вашего DI, но оказывается что еще есть несколько десятков типов платежей и в результате каждый из адаптеров нужно параметраризировать под каждый вид платежа при создании по разному. И вы все равно пишете развернутую логику создания зависимостей

DI в Python, Easy-DI: спаситель в сложном мире зависимостей

Это конечно лучше, но все равно не понятно, какую проблему это решает. Стало кода меньше - нет. Стал он понятней - нет. Тогда зачем это нужно?

Гарантируете вы, что при вызове container.get(SomeDeps), что чего-то вернется - думаю нет, привет эксепшен в рантайме

Вы в любом месте приложения можете дернуть container.get получить любую зависимость в результате у вас нет четких границ между уровнями абстракции в коде и все постепенно превращается в big ball of mud

DI в Python, Easy-DI: спаситель в сложном мире зависимостей

Когда зависимость стало много особенно не стоит полагаться на магию. Чего-нибудь отвалится, задублируешь или неправильно напишешь ключи и замучаешься разбираться. Нетипизированные dict[str, Any], глобальные переменные по капотом и инициализация размазанная по всему коду очень «помогают» пониманию кода. Явное лучше не явного - лучше в одном месте явно передать зависимости, с нормальными типами, чтобы редактор или mypy тебя лишней раз проверил

DI в Python, Easy-DI: спаситель в сложном мире зависимостей

Одно радует, что в голосовании большинство проголосовало за не использует. Почему нельзя заинъектить зависимости руками не понятно

Карты (maps) в Go

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

Карты (maps) в Go

Это лишь свидетельствует о том, что переводчики совсем не в теме предметной области. Map происходит от устойчивого выражения map into - в нашем конкретном случае map keys into values

Социализм vs Капитализм — когда мифы важнее фактов

С выборами действительно много разных концептуальных проблем:

• Математически ваш голос ни на что не влияет в реальных даже самых честных выборах - вероятность, что вы сдвинете решение исчезающе мала

• Согласно теореме Эрроу выборы не обеспечивают логическую не противоречивость решений

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

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

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

Социализм vs Капитализм — когда мифы важнее фактов

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

Социализм vs Капитализм — когда мифы важнее фактов

Можете расшифровать определение "уровень жизни"? Среднее количество бабла на душу?

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

А дальше я не очень понял с каким моим тезисом вы спорите и чего пытаетесь доказать

Социализм vs Капитализм — когда мифы важнее фактов

Я честно не видел таких анализов, хотя они наверняка есть, но думаю там тоже не все так однозначно - по тому же Джини у США все не очень, в европейских демократиях по лучше, а в социалистических диктатурах обычно очень хорошо. Но диктатуры бывают разные, например, страны персидского залива, там Джини не очень, но уровень жизни выше чем с передовых демократиях. Мир сложнее, чем кажется:)

Социализм vs Капитализм — когда мифы важнее фактов

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

Вот есть США там было рабство и геноцид индейцев, потом поражение в правах индейцев и негров, массовое помещение в концлагеря японцев, сажание на большие сроки голубых, и все это время она считалась демократией. А сей час есть крупнейшая демократия в мире Индия - там не очень сладко живется, если вы там бывали. Или южно американские страны - во многих странах там нет диктаторов, но вот например в Мексике несколько десятков тысяч человек убивают в год и очень часто заживо пилят бензопилами. Или вот был диктор Садам - нехороший человек развязал войну и убил около несколько десятков тысяч курдов. Пришли демократичные США убили злого Хусейна, а за одно по независимым оценкам 0,5-1,5 миллионов человек так и не постоив демократию - так ли плох был на этом фоне Хусейн

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

Социализм vs Капитализм — когда мифы важнее фактов

Я не усреднял, а лишь цитирую профессиональных исследователей в этой области, например Daron Acemoglu. Если грубо, то есть некоторые критерии демократичности, по которым выставляют степень демократичности. Дальше вы можете взять какой-нибудь показатель, например темпы роста душевого ВВП (показатель скорости развития), или дисперсию роста душевого ВВП (показатель предсказуемости экономической ситуации) и т.д. и посмотреть зависимость этих показателей от степени демократичности, провести стат тест, насколько это зависимость значима статически и сделать выводы - сильных экономических аргументов в пользу демократий нет, повторю часть предыдущей цитаты This result is surprising and even perhaps disturbing

https://en.wikipedia.org/wiki/The_Economist_Democracy_Index

Социализм vs Капитализм — когда мифы важнее фактов

Не понял вашу метафору. Если про ваш первый вопрос, который мне понятен, то думаю рост важен, но есть и другие факторы, например, люди ценят предсказуемость и этот вопрос тоже исследовался экономистами. Тут тоже не все так очевидно с демократиями. Не демократии обычно обеспечивают большую предсказуемость short run, но в не демократиях чаще случаются редкие, но сильные потрясения, обычно связанные со сменой авторитарного правителя. Тут как говорится, как повезет - нарвешься ты на это редкое событие или нет. Если усреднить, то опять какой-то существенной разницы не видно