а что останется от Раста без стандартной библиотеки? Будет ли это Растом?
Да, будет. Автор статьи отломал только импорты. Сам язык от этого не перестал быть языком. Можно все так же использовать высокоуровневые абстракции, чем активно пользуются разработчики.
Есть еще сайт Game UI Database - https://www.gameuidatabase.com/ Там можно посмотреть интерфейс, в том числе HUD, почти тысячи игр, включая десктопные, мобильные и консольные.
Другая картина: квартира, та же задача. Раздражение ментора, потому что вы обращаетесь, когда он максимально занят.
В нашей компании у ментора в такой ситуации нет права быть раздражённым, потому что "помочь новичку" — это конкретная задача, на которую выделяется время. Более того, это не для джунов, это для любого человека, который пришёл в компанию "только вчера". Как часть т.н. onboarding. Если я скажу начальству, что задача задерживается, т.к. я помогал новому разработчику, он поймёт и будет только рад, т.к. в его понимании — это освобождает от тупых вопросов его самого. Обратная сторона — если время будет тратиться очень часто, то нового разработчика всё-таки уволят, потому что мы джунов не нанимаем и об этом во второй половине поста.
А уж если заранее известно, что вы нанимаете человека без опыта, но при этом освоиться ему люди должны помогать в своё свободное время, никак не прописанное в распорядке дня, то что-то пошло серьёзно не так.
А ещё есть чудесная практика парного программирования через зум, когда один человек пишет, а другой на ходу делает ревью. Это хорошо работает даже для опытных программистов, например если ты фуллстэк и въезжаешь в какую-то принципиально новую для себя технологию, гораздо удобнее будет если тебя в неё посвятит человек для которого это главное или вообще единственное направление. У меня так было например со стэком Elixir+Ecto+LiveView.
В общем, это было о хорошем, а теперь о плохом.
У нас джунов не хотят брать не потому, что они чего-то не знают, а потому, что по определению начальства, джун — это человек, который думает о выполняемой задаче на принципиально неправильном уровне. То есть, он думает не о том, что делает (бизнес-логику и внешний вид), а о том, как пишет код. Это те самые джинны, которые выполняют желания слишком буквально, порождая недоработки и баги. Они не думают о том, как выглядит и работает существующая логика, бывшая до них. Честно говоря это может прозвучать грубо, но по-моему иногда они не думают вообще.
На случай, если этот коммент каким-то чудом будет читать человек, которому это когда-нибудь пригодится в работе, приведу парочку примеров типичных косяков джуниора в моём понимании (на самом деле эти косяки в нашей компании допускали люди, которые формально джуниорами не являлись и получали з/п от условных 2000$). Некоторые существенные, некоторые нет, но все из них отнимают время команды на фидбек от QA+заказчика, открытие багов, переоткрытие задач и т.п.
Кастомный кликабельный UI-элемент, в котором не будет прописано user-select: none или cursor: pointer, даже если во всей остальной платформе в подобных случаях оно прописано. Отсутствующий эффект ховера или нажатия, если его нет в дизайне. (Большинству дизайнеров пофиг с большой колокольни на ховеры, это не их уровень высоты художественного видения, так сказать)
Невнимательное чтение чужого кода при рефакторинге или переписывании, отсутствие тестирования совместимости с предыдущим кодом на всех промежуточных этапах. Конкретно этот пункт связан с записью JSON-данных в БД, но может произойти где угодно, где есть какие-то исторические вещи, с которыми нужно сохранять совместимость.
Цельный пулл реквест, содержащий одну фичу с нуля, которая не работает end-to-end. Например, фича регистрации через емейл, где емейл тупо не приходит или приходит в сильно поломанном виде. Или фича входа через OAuth, которая падает в 500 при попытке залогиниться через гугл. Это как правило указывает на то, что человек работает в режиме райт-онли и даже отдалённо не пытается свою логику тестировать, и ему норм.
Подпункт: реализация REST API условного микросервиса по спеку, по которому в этот API будут обращаться другие сервисы. Почему пункт здесь? А потому, что реализовано было абсолютно не по спеку, а по какому-то внутреннему пониманию программиста, и этого никто не замечал пока не пришли ко мне с "ничего не работает".
Боязнь задавать вопросы заказчику, дизайнеру и т.п. при явных несхождениях каких-то новых фич со старыми. Например, если заказчик скинул иконку, которая ни к селу ни к городу, она будет воткнута прям в таком виде, несмотря на то, что на самом деле имелось в виду что её надо использовать как референс и найти что-то похожее, но более уместное.
Сравнение в данном случае, я привел для того, чтобы человеку яснее было, что покупают нфт на данной площадке такие же "перекупы", как и в видеокартах, как и в кроссовках, как и во многом другом.
Я не раз сам участвовал в их аукционах, и, о чудо, каждый раз покупают одни и те же кошельки с определенного сообщества и перепродают потом все это на опенси (когда в минус, когда в плюс, но это не важно).
Так что, тезис местных разоблачителей, что чувак сам у себя со старта покупал картинки, в принципе не канает.
На ваш вопрос постараюсь ответить про дорогие нфт-коллекции, а не всякий скам, который пилится на коленке за вечер.
С ростом популярности nft у криптоэнтузиастов появилась возможность показывать свой статус, а не просто циферки на кошельке.
Если вы откроете твиттер по тематике крипты, то увидите, что почти у каждого серьезного аккаунта с кучей фолловеров стоит какой-либо Bluechip проект на аватаре (Bayc, Azuki, CryptoPunks, Moonbirds). Ну и сам твиттер запилил возможность ставить именно nft, а не просто картинку, чтоб все видели какой ты молодец (https://twitter.com/BelfortNFT/nft - как пример).
По юзкейсу все просто, люди знают, что это дорогая вещь -> начинают подписываться.
Почему бы не приобщиться, если ты фанат его творчества, да еще и имеешь пару свободных eth?
Я довольно часто захожу послушать твиттер-спэйсы (аудиоразговоры как в skype/discord), которые проводят авторы после дропов своих коллекций и там прям реально люди с упоением обсуждают какая крутая коллекция и как они довольны, что ее купили.
Сейчас еще стало очень модно добавлять так называемое утилити, например, nft конкретных коллекций может служить пропуском на различные фестивали, такие как NFT NYC, либо на эвенты по типу BIG3, либо на концерты всяких популярных исполнителей.
Я считаю, для простого человека вся тема с нфт гораздо понятнее, чем осознать что такое условный bnb coin и почему он сейчас стоит 270$ и нахрена он вообще нужен, когда есть биткоин.
Ну и в целом, покупают, потому что могут. 2021 год был щедрый для криптанов, думаю это вы и без меня знаете.
Конечно, многие считают это инвестицией с возможностью заработать. Ограниченное количество и вера в конкретные проекты дают о себе знать.
Я сам задавал такие вопросы до лета 2021, а сейчас сижу с жабой из коллекции Cryptoadz. Почему купил? Зашли, как и в целом и все работы художника Gremplin, + когда варишься во всей этой движухе какие-то коллекции волей не волей начинают нравиться. Кому-то нравится мона лиза, а мне вот жаба!
Понимаю, что для обывателя это звучит дико, но уж как есть, диагноз тут мне уже подобрали :)
Странно, что не увидел тут отсылки к книге Accelerate (Forsgren, Humble, Kim). Кстати кому тема интересна, и нормально с английским могу порекомендовать канал "Continuous Delivery" Дейва Фарли
Дейв Фарли - соавтор небезызвестной книги по непрерывному развертыванию
Надо сказать я когда первый раз познакомился с подходом Continuous Delivery, меня тут же прошибло: "Вот оно! Вот к чему нужно идти". Тут же на место встают все практики разработки, ведения команд, тестирования, бережливого производства и пр.
Однако, есть нюансы. Например деплой происходит "через штакетник". Есть шлюз безопасности на стороне заказчика и сперва твой релиз болтается в "предбаннике", пока его не ощупают и не заберут в запретную зону на прод. Но! Ничего не мешает разогнать свою частоту поставок до "предбанника", а потом сказать: "Мы можем быстрее,бутылочное горлышко на вашей стороне".
Мутабельность данных, от которой нельзя избавиться - ключевые слова final, const и иже с ними (val/var) есть давно в примерно каждом языке, на котором я писал и который я помню.
Неумение разделять данные и ошибки, данные и отсутствие данных - всякие там "монады" (на самом деле не во всех языках они реализованы стандартно как честные монады - например, джавовый Optional монадические законы нарушает) Optional/Maybe/Try.
Неотключаемое значение 0 по умолчанию для числовых полей структур (забыл проинициализировать - страдай), которое притом не кидает ошибок компиляции - ну достаточно было просто так не делать, что и произошло в других языках.
Посмотрите A* алгоритм, имеет много преимуществ. Кстати, в геофизике алгоритмы роутинга очень даже востребованы - это и растровый роутинг при разворачивании интерферограммы (unwrapping), и анализ множества перекрывающихся интервалов смещений на SBAS диаграмме и так далее.
Видимо, вы правы. Моих знаний в геофизике и правда мало - только программа вуза, не больше. На таком уровне знаний собственных идей быть не может. А вот математика - это да, почти что мой конёк. Тут я своего реализовал много: на одном только алгоритме Дейкстры сколько всего наворотить можно и пользователи годами будут счастливы.
неинтересно, потому что это тупиковая ветка эволюции. Сейчас очень многие компании переходят на облачные сервисы и как пример - гугл документы. Там есть аналог экселя. Но вот VBA там не работает. Что делать? Ну, писать скрипты на местном аналоге, или использовать low или nocode решения. https://vas3k.ru/blog/nocode/ Ознакомьтесь. За этим будущее. Все будут использовать различные SaaS решения. Одно для общения. Второй - почта. Третье - какая-нибудь таблица в гугле. Это все нужно связать вместе. И желательно не нанимать дорогущих инженеров. А VBA... он прибивает гвоздями к экселю и более того - конкретной версии экселя. Чудес ведь не бывает.
При этом полученный на задачах на VBA опыт можно конвертировать в опыт промышленного программирования. Достаточно добавить знание какого-нибудь более вменяемого языка. Джавы той же
Потому что данные и логику смешивать вредно. - В случае когда бизнес-логика выносится из сервисного слоя приложения, то начинается её многократное дублирование.
- Так-же такую логику тяжелее поддерживать и расширять.
- В разныех БД по разному пишутся хранимки и по разному оптимизируются. Это значит, что в случае миграции с PostgreSQL ну например на Oracle будет большая боль в процессе переноса этой логики. В случае когда вся логика находится внутри приложения, то придётся просто переключить драйвер и может поправить миграции, которые идут в обход ORM.
- В рамках одной БД от версии к версии может поменяться фнкциональный набор для написания хранимок. Например что-то что было deprecated - уберут. И такое изменение не позволит осуществить переезд.
- Одним из существенных минусов использования хранимых процедур - это значительные трудности поддержания версий кода.
- Масштабирование приложений со сложной логикой - проще и дешевле чем масштабирование бд
- Логика в приложении гораждо проще поддаётся качественному тестированию
На самом деле - это очень холиварная тема. Если вы знаете что делаете и для чего, то возможно хранимки вам подойдут. С другой стороны, хорошей архитектуры у приложения добиться скорее всего будет очень сложно, а зависимось от базы будет очень жёсткой.
Вот есть пост тут от 2014 года где активно холиварят. Вот пост тут от 2020 статья в более пессимистичном духе к хранимкам
Посмотрите, почитайте, а там ужа сами решайте, нужно вам это или нет
Начиная с 89го года, на поправку Джексона-Вэника каждый год накладывали мораторий. Так что она по сути не действовала.
"закон Магнитского" направлен на конкретных людей, ответственных за нарушение прав человека (на текущий момент в районе 40 человек). Он не был направлен на экономику РФ. Кстати, стоит напомнить, что в ответ, РФ приняла «Закон Димы Яковлева» , или как его называют в народе - «закон подлецов».
Так что никакого отношения к какому-то мифическому "блоку", с которого вы начали эту ветку, данные законы не имеют.
Про Мюнхенский сговор уже написали, ещё погуглите Декларацию о неприменении силы между Германией и Польшей, а также Пакт четырёх. В то время в я Европа друг с другом пакты заключала и сферы влияния делила, но вспоминают, почему-то только Молотова. Удобно, да..
С документацией одна беда -- она не user-friendly и не для начинающего входить в эту тему, для меня ее полезность стала актуальной только когда я полез в исходники asyncio. На своем курсе по Python я активно рекламирую цикл уроков от bbc https://bbc.github.io/cloudfit-public-docs/ и вишенкой на торте -- шикарнейшие видеокасты от David Beazley, который пишет свой микро asyncio -- после этого наступает просветление и кристалльное понимание, что никакой магии там не происходит. После -- разбор концепций структурного асинхронного программирования (trio / anyio), потом депрессия от понимания, что асинхронность в Python безвозвратно продолбана и наконец -- посыл Python к чертовой матери и переход на Go =D
Да, будет. Автор статьи отломал только импорты. Сам язык от этого не перестал быть языком. Можно все так же использовать высокоуровневые абстракции, чем активно пользуются разработчики.
Например, эмбеддеры пишут библиотеки, где на уровне типов нельзя выстрелить в ногу (хех) микроконтроллеру с неправильно сконфигурированными портами или переполнить стек. Разработчики операционных систем пишут абстракции конкуренции и доступа к ресурсам, не позволяющим их использовать неверно.
Но они видимо Столярова не посещали и не знают, что это невозможно.
Вообще, кому интересно рекомендую книгу Rust Embedded.
Держи, подруге понравится!
Есть еще сайт Game UI Database - https://www.gameuidatabase.com/
Там можно посмотреть интерфейс, в том числе HUD, почти тысячи игр, включая десктопные, мобильные и консольные.
В нашей компании у ментора в такой ситуации нет права быть раздражённым, потому что "помочь новичку" — это конкретная задача, на которую выделяется время. Более того, это не для джунов, это для любого человека, который пришёл в компанию "только вчера". Как часть т.н. onboarding. Если я скажу начальству, что задача задерживается, т.к. я помогал новому разработчику, он поймёт и будет только рад, т.к. в его понимании — это освобождает от тупых вопросов его самого. Обратная сторона — если время будет тратиться очень часто, то нового разработчика всё-таки уволят, потому что мы джунов не нанимаем и об этом во второй половине поста.
А уж если заранее известно, что вы нанимаете человека без опыта, но при этом освоиться ему люди должны помогать в своё свободное время, никак не прописанное в распорядке дня, то что-то пошло серьёзно не так.
А ещё есть чудесная практика парного программирования через зум, когда один человек пишет, а другой на ходу делает ревью. Это хорошо работает даже для опытных программистов, например если ты фуллстэк и въезжаешь в какую-то принципиально новую для себя технологию, гораздо удобнее будет если тебя в неё посвятит человек для которого это главное или вообще единственное направление. У меня так было например со стэком Elixir+Ecto+LiveView.
В общем, это было о хорошем, а теперь о плохом.
У нас джунов не хотят брать не потому, что они чего-то не знают, а потому, что по определению начальства, джун — это человек, который думает о выполняемой задаче на принципиально неправильном уровне. То есть, он думает не о том, что делает (бизнес-логику и внешний вид), а о том, как пишет код. Это те самые джинны, которые выполняют желания слишком буквально, порождая недоработки и баги. Они не думают о том, как выглядит и работает существующая логика, бывшая до них. Честно говоря это может прозвучать грубо, но по-моему иногда они не думают вообще.
На случай, если этот коммент каким-то чудом будет читать человек, которому это когда-нибудь пригодится в работе, приведу парочку примеров типичных косяков джуниора в моём понимании (на самом деле эти косяки в нашей компании допускали люди, которые формально джуниорами не являлись и получали з/п от условных 2000$). Некоторые существенные, некоторые нет, но все из них отнимают время команды на фидбек от QA+заказчика, открытие багов, переоткрытие задач и т.п.
Кастомный кликабельный UI-элемент, в котором не будет прописано user-select: none или cursor: pointer, даже если во всей остальной платформе в подобных случаях оно прописано.
Отсутствующий эффект ховера или нажатия, если его нет в дизайне.
(Большинству дизайнеров пофиг с большой колокольни на ховеры, это не их уровень высоты художественного видения, так сказать)
Невнимательное чтение чужого кода при рефакторинге или переписывании, отсутствие тестирования совместимости с предыдущим кодом на всех промежуточных этапах. Конкретно этот пункт связан с записью JSON-данных в БД, но может произойти где угодно, где есть какие-то исторические вещи, с которыми нужно сохранять совместимость.
Цельный пулл реквест, содержащий одну фичу с нуля, которая не работает end-to-end. Например, фича регистрации через емейл, где емейл тупо не приходит или приходит в сильно поломанном виде. Или фича входа через OAuth, которая падает в 500 при попытке залогиниться через гугл. Это как правило указывает на то, что человек работает в режиме райт-онли и даже отдалённо не пытается свою логику тестировать, и ему норм.
Подпункт: реализация REST API условного микросервиса по спеку, по которому в этот API будут обращаться другие сервисы. Почему пункт здесь? А потому, что реализовано было абсолютно не по спеку, а по какому-то внутреннему пониманию программиста, и этого никто не замечал пока не пришли ко мне с "ничего не работает".
Боязнь задавать вопросы заказчику, дизайнеру и т.п. при явных несхождениях каких-то новых фич со старыми. Например, если заказчик скинул иконку, которая ни к селу ни к городу, она будет воткнута прям в таком виде, несмотря на то, что на самом деле имелось в виду что её надо использовать как референс и найти что-то похожее, но более уместное.
Сравнение в данном случае, я привел для того, чтобы человеку яснее было, что покупают нфт на данной площадке такие же "перекупы", как и в видеокартах, как и в кроссовках, как и во многом другом.
Я не раз сам участвовал в их аукционах, и, о чудо, каждый раз покупают одни и те же кошельки с определенного сообщества и перепродают потом все это на опенси (когда в минус, когда в плюс, но это не важно).
Так что, тезис местных разоблачителей, что чувак сам у себя со старта покупал картинки, в принципе не канает.
На ваш вопрос постараюсь ответить про дорогие нфт-коллекции, а не всякий скам, который пилится на коленке за вечер.
С ростом популярности nft у криптоэнтузиастов появилась возможность показывать свой статус, а не просто циферки на кошельке.
Если вы откроете твиттер по тематике крипты, то увидите, что почти у каждого серьезного аккаунта с кучей фолловеров стоит какой-либо Bluechip проект на аватаре (Bayc, Azuki, CryptoPunks, Moonbirds). Ну и сам твиттер запилил возможность ставить именно nft, а не просто картинку, чтоб все видели какой ты молодец (https://twitter.com/BelfortNFT/nft - как пример).
По юзкейсу все просто, люди знают, что это дорогая вещь -> начинают подписываться.
Так же есть те кому реально нравится арт, либо фанаты конкретного художника. Рискну предположить, что многие видели комиксы Джоана Корнелла, а у него вот есть целая коллекция https://opensea.io/collection/official-moar-by-joan-cornella
Почему бы не приобщиться, если ты фанат его творчества, да еще и имеешь пару свободных eth?
Я довольно часто захожу послушать твиттер-спэйсы (аудиоразговоры как в skype/discord), которые проводят авторы после дропов своих коллекций и там прям реально люди с упоением обсуждают какая крутая коллекция и как они довольны, что ее купили.
Сейчас еще стало очень модно добавлять так называемое утилити, например, nft конкретных коллекций может служить пропуском на различные фестивали, такие как NFT NYC, либо на эвенты по типу BIG3, либо на концерты всяких популярных исполнителей.
Я считаю, для простого человека вся тема с нфт гораздо понятнее, чем осознать что такое условный bnb coin и почему он сейчас стоит 270$ и нахрена он вообще нужен, когда есть биткоин.
Ну и в целом, покупают, потому что могут. 2021 год был щедрый для криптанов, думаю это вы и без меня знаете.
Конечно, многие считают это инвестицией с возможностью заработать. Ограниченное количество и вера в конкретные проекты дают о себе знать.
Я сам задавал такие вопросы до лета 2021, а сейчас сижу с жабой из коллекции Cryptoadz. Почему купил? Зашли, как и в целом и все работы художника Gremplin, + когда варишься во всей этой движухе какие-то коллекции волей не волей начинают нравиться. Кому-то нравится мона лиза, а мне вот жаба!
Понимаю, что для обывателя это звучит дико, но уж как есть, диагноз тут мне уже подобрали :)
Странно, что не увидел тут отсылки к книге Accelerate (Forsgren, Humble, Kim).
Кстати кому тема интересна, и нормально с английским могу порекомендовать канал "Continuous Delivery" Дейва Фарли
Дейв Фарли - соавтор небезызвестной книги по непрерывному развертыванию
Надо сказать я когда первый раз познакомился с подходом Continuous Delivery, меня тут же прошибло: "Вот оно! Вот к чему нужно идти". Тут же на место встают все практики разработки, ведения команд, тестирования, бережливого производства и пр.
Однако, есть нюансы. Например деплой происходит "через штакетник". Есть шлюз безопасности на стороне заказчика и сперва твой релиз болтается в "предбаннике", пока его не ощупают и не заберут в запретную зону на прод. Но! Ничего не мешает разогнать свою частоту поставок до "предбанника", а потом сказать: "Мы можем быстрее,бутылочное горлышко на вашей стороне".
Мутабельность данных, от которой нельзя избавиться - ключевые слова final, const и иже с ними (val/var) есть давно в примерно каждом языке, на котором я писал и который я помню.
Неумение разделять данные и ошибки, данные и отсутствие данных - всякие там "монады" (на самом деле не во всех языках они реализованы стандартно как честные монады - например, джавовый Optional монадические законы нарушает) Optional/Maybe/Try.
Неотключаемое значение 0 по умолчанию для числовых полей структур (забыл проинициализировать - страдай), которое притом не кидает ошибок компиляции - ну достаточно было просто так не делать, что и произошло в других языках.
Посмотрите A* алгоритм, имеет много преимуществ. Кстати, в геофизике алгоритмы роутинга очень даже востребованы - это и растровый роутинг при разворачивании интерферограммы (unwrapping), и анализ множества перекрывающихся интервалов смещений на SBAS диаграмме и так далее.
Видимо, вы правы. Моих знаний в геофизике и правда мало - только программа вуза, не больше. На таком уровне знаний собственных идей быть не может. А вот математика - это да, почти что мой конёк. Тут я своего реализовал много: на одном только алгоритме Дейкстры сколько всего наворотить можно и пользователи годами будут счастливы.
неинтересно, потому что это тупиковая ветка эволюции. Сейчас очень многие компании переходят на облачные сервисы и как пример - гугл документы. Там есть аналог экселя. Но вот VBA там не работает. Что делать? Ну, писать скрипты на местном аналоге, или использовать low или nocode решения. https://vas3k.ru/blog/nocode/ Ознакомьтесь. За этим будущее. Все будут использовать различные SaaS решения. Одно для общения. Второй - почта. Третье - какая-нибудь таблица в гугле. Это все нужно связать вместе. И желательно не нанимать дорогущих инженеров. А VBA... он прибивает гвоздями к экселю и более того - конкретной версии экселя. Чудес ведь не бывает.
При этом полученный на задачах на VBA опыт можно конвертировать в опыт промышленного программирования. Достаточно добавить знание какого-нибудь более вменяемого языка. Джавы той же
Берёте любой серверный фрэймворк и не изобретаете велосипед, тот же Vaadin например.
Потому что данные и логику смешивать вредно.
- В случае когда бизнес-логика выносится из сервисного слоя приложения, то начинается её многократное дублирование.
- Так-же такую логику тяжелее поддерживать и расширять.
- В разныех БД по разному пишутся хранимки и по разному оптимизируются. Это значит, что в случае миграции с PostgreSQL ну например на Oracle будет большая боль в процессе переноса этой логики. В случае когда вся логика находится внутри приложения, то придётся просто переключить драйвер и может поправить миграции, которые идут в обход ORM.
- В рамках одной БД от версии к версии может поменяться фнкциональный набор для написания хранимок. Например что-то что было deprecated - уберут. И такое изменение не позволит осуществить переезд.
- Одним из существенных минусов использования хранимых процедур - это значительные трудности поддержания версий кода.
- Масштабирование приложений со сложной логикой - проще и дешевле чем масштабирование бд
- Логика в приложении гораждо проще поддаётся качественному тестированию
На самом деле - это очень холиварная тема.
Если вы знаете что делаете и для чего, то возможно хранимки вам подойдут. С другой стороны, хорошей архитектуры у приложения добиться скорее всего будет очень сложно, а зависимось от базы будет очень жёсткой.
Вот есть пост тут от 2014 года где активно холиварят.
Вот пост тут от 2020 статья в более пессимистичном духе к хранимкам
Посмотрите, почитайте, а там ужа сами решайте, нужно вам это или нет
Начиная с 89го года, на поправку Джексона-Вэника каждый год накладывали мораторий. Так что она по сути не действовала.
"закон Магнитского" направлен на конкретных людей, ответственных за нарушение прав человека (на текущий момент в районе 40 человек). Он не был направлен на экономику РФ. Кстати, стоит напомнить, что в ответ, РФ приняла «Закон Димы Яковлева» , или как его называют в народе - «закон подлецов».
Так что никакого отношения к какому-то мифическому "блоку", с которого вы начали эту ветку, данные законы не имеют.
Про Мюнхенский сговор уже написали, ещё погуглите Декларацию о неприменении силы между Германией и Польшей, а также Пакт четырёх. В то время в я Европа друг с другом пакты заключала и сферы влияния делила, но вспоминают, почему-то только Молотова. Удобно, да..
Очень советую курс Романа Лисовского по concurrency (многопоточность, асинхронность и многое другое) для тех, кто хочет разобраться подробно в вопросе. https://youtube.com/playlist?list=PL4_hYwCyhAva37lNnoMuBcKRELso5nvBm
С документацией одна беда -- она не user-friendly и не для начинающего входить в эту тему, для меня ее полезность стала актуальной только когда я полез в исходники asyncio. На своем курсе по Python я активно рекламирую цикл уроков от bbc https://bbc.github.io/cloudfit-public-docs/ и вишенкой на торте -- шикарнейшие видеокасты от David Beazley, который пишет свой микро asyncio -- после этого наступает просветление и кристалльное понимание, что никакой магии там не происходит. После -- разбор концепций структурного асинхронного программирования (trio / anyio), потом депрессия от понимания, что асинхронность в Python безвозвратно продолбана и наконец -- посыл Python к чертовой матери и переход на Go =D
да не очень и тяжелый, https://mujs.com/
их vm занимает примерно 145кб рантайма, сделан специально под ембед платформы
все плюшки js в наличии