Согласен, я практически не знаю химию и биохимию и исхожу только из умений анализировать википедию. В целом я пропустил шаг, согласно википедии (тот еще источник), этанол "запускает активность ингибиторных ГАМК", которые, в свою очереди, и являются нейромедиаторами. (тут, в пункте "Головной мозг" и тут в первом же абзаце).
Но мой посыл был в том, что опьянение — это искажение работы мозга нейромедиаторами, а не отмирание части клеток мозга из-за кислородного голодания.
Вы только что описали микроинсульт. И он уж точно не воспринимается как эйфория.
Этанол является нейромедиатором, который приводит к замедению передачи сигналов в мозге и их искажению, а так же нарушает и ph баланс, и баланс гормонов в крови (что и приводит к эйфории) ещё метабализируется в не менее токсичные вещи (что вероятно приводит к похмелью). А не пространственный микроинсульт.
но помню да, в годах 2005 нас пугали этим в школе, было дело
Но вообще смешно видеть пару тезисов чуть ли не из википедии и всё ради рекламки. Причем тезисы то спорны:
у мембранных клавиатур обычно оно составляет 2 (2KRO), 3 (3KRO) или 6 (6KRO). У механических — таких ограничений вообще нет (NKRO).
Электроника не имеет отношения к механики клавиатуры. И те и другие можно найти и с блокировкой клавиш и без.
Большинству пользователей нравится именно второй вариант: по ощущениям, так приятнее печатать.
Особенно коллегам пользователей. И нет, практически все конструкции механических клавиатур достаточно громкие чтобы бесить коллег.
Срок службы: обычные мембранные клавиатуры рассчитаны на 5 миллионов нажатий. Механические клавиатуры могут пережить 50 миллионов нажатий. Если, например, вы печатаете по 6 часов (а 1 час — это 60 минут) в день и совершаете 30 нажатий клавиш в минуту, то срок службы механической клавиатуры составит почти 12 лет: 50 миллионов / 365 / (6 60 30). По более скептическим оценкам — от 3 до 5 лет.
Если вы 6 часов в день нажимаете одну и ту же кнопку каждые 2 секунды — вы что-то делаете не так в жизни. Но, справедливости ради, ни разу не видел даже мембранные клавиатуры, которые именно бы износились, а не протерлись (или не были залиты), так что аргумент так себе.
PS Ничего не имею против механических клавиатур и сам их предпочел бы, но статья уж совсем высосана из пальца.
Рассинхрон редко прям очень, но бывает что не сильно заморачиваются с дженериками и просто ставят any, скажем, как возможный ключ. Но тоже редко и обычно хорошо локализируется. Рассинхрон типов с бэкэндом более частая проблема, и для неё пока особо нет стандартного решения, хотя можно накрутить поверх свагера.
А я вот считаю, что самым эффективным вкладом является как раз таки противоположное - увеличение портребления. Если у индустрии будет больше денег и необходимости в новых источниках энергии, компании будут готовы тратить больше денег на расерч и на модернизацию сетей и станций.
Ну и у меня совесть чиста, покуда я точно знаю что я трачу «зелёную энергию».
А вам советую посмотреть сколько потребляет холодильник, который включён постоянно, и лимитировать его открытие до раза в день на 5 секунд, нечего выхоложивать его
Справедливости ради эта система в любом случае будет программной, покуда для принципа ее функционирования необходимо обсчитывать показания с акселерометров и анализировать. А вот что там дополнительная логика, да ещё с блютусом - это конечно просто невероятно. Надеюсь, что у них за это хотя бы разные контроллеры отвечают.
При аварии всего в 50 км/с на ремни приходится нагрузка в 2.5 тонны Источник (если ремень не растягивается).
Ремень, конечно, может быть с запасом, но механизмы могут и отказать от такой нагрузки, и не хочется это выяснить при создании такой нагрузки в следующий раз.
В европах этих (и в России, к слову, тоже) следует держаться скорости потока, но строго в рамках ограничения скорости, превышать нельзя. Но при этом запрещается безосновательно тащиться 40 где можно ехать 70, потому что это будет провоцировать обгоны. Вас даже привлечь могут если вы ехали безосновательно медленно, кто-то решил вас обогнать и не смог (продолжить маршрут).
Еще хотел добавить что в воздухе витает идея прикрутить ShadowDom, но я так и не смог заставить стили (сгенерированные вебпаком) монтироваться в нужное место, поэтому пока живем без него.
Есть пакет который называется namespace/core, он подключается как обычный модуль ко всем федерациям, у него внутри три основные функции: ProvideFeredationContext, useFederationContext och RemoteComponent. Expose еще.
Первые два — собственно внедрение зависимостей поверх реактовских контекстов (главное отличие — он "выживает" внутри удаленного компонента).
Третий — принимает как аргумент модуль, который мы хотим внедрить, загружает его, монтирует в внутренний дивчик (ReactDom.render, сделано чтобы гарантированно разорвать все контексты внутри и предотвратить двойной контекст редакса, да и вообще мало ли), ну и передает контекст. expose — обертка над… экспортируемым реакт компонентом, необходимо для работы контекста (а еще создает контексты темы, локали и history для реакт роутера).
Есть хостовая федерация, которая грузит всё остальное, задает начальное состояние для контекстов и реализует RemoteComponent (внутри ядра просто типизированная заглушка для этого компонента). Хост так же отвечает за проксирование и где вообще лежат другие федерации.
Такой подход работает довольно хорошо в нашем случае, но есть проблемы когда мы считаем что что-то слишком маленькое чтобы быть федерацией, но достаточно важное чтобы это реализовать в единственном экземпляре, при этом это обладает логикой. Решение — передвинуть логику на бэк, например с помощью graphql, но если бы всё было так просто.
И еще одна раздражающая вещь, которую кажется можно решить, но как-то вот не решается:
const Foo = () => {
const a = useContext(A);
}
const Bar = () => {
const b = useContext(A);
return <RemoteComponent module="..."><Foo /></RemoteComponent>;
}
Из-за разрыва контекста в RemoteComponent, а внутри Foo будет undefined. (Фуу мы передаем как ребенка внутрь чужой федерации по тем или иным причинам).
Собаку съел (да что уж там, целую стаю собак) на федерациях, спешу поделиться.
Ну первое и главное — оно работает и работает довольно круто, решая проблемы для решения которых оно предназначено (у нас три огромных приложения, разрабатываемые несколькими разными командами, и мы теперь можешь включать части чужого приложения в наше по необходимости, а так же команды внутри разъехались в отдельные репозитории с отдельнымии пайплайнами, в общем всё хорошо и красиво).
Но к недостаткам:
Вообще основные недостатки связаны с необходимостью что-то пошарить между модулями. Но этот конкретно — внедрение данных (в первую очередь, авторизации, но у нас это еще тема, локаль, окружение и какие-то системные вещи). Если коротко — все способы обладают теми или иными недостатками и компромисы кусаются. Мы остановились на системе поверх контекстов реакта, разве что весь контекст передается автоматически внутри аналога LazyService из статьи, но каждая федерация обязана быть обернутой в специальный метод. Главный принципиальный недостаток (помимо того что мы передаем ссылку на контекст внутри этого же контекста, хех) — сложность реализации вне реакта. А еще всё должно быть помещено внутрь реакт компонента, покуда вне его к контексту очевидно нет доступа. Но это отдельная большая тема, больше чем можно вместить в комментарий.
shared из вебпака работает далеко не так радужно как хотелось бы. На самом деле некоторые пакеты очень требовательны к версии (реакт и реакт дом), для других (антд) мы генерируем общий файл стилей в зависимости от темы только один раз, как следствие, все остальные федерации так же должны использовать конкретную версию. Если коротко — есть набор пакетов, версия которых должна быть жестко зафиксирована и использоваться одинаковой во всех федерациях. Не было бы проблем, если бы package.json можно было бы наследовать, но, к сожалению, миграция пакетов на более новую версию та еще эпопея. И да, решить можно просто перестав шарить пакеты между приложениями, но тогда теряется смысл с федераций. Да и вообще, иногда кажется что с system.js было бы проще. П.С. history для реакт роутера обязан быть одинаковым во всей системе, и генерирует отдельный слой сложности.
Иногда в голову приходит идея "давайте переиспользуемые компоненты вынесем в некий общий пакет, который будет использоваться всеми". В общем, работает только при правильно настроенном деплое этого общего пакета и только если в нем чистые глупые компоненты / функции. Иначе очень быстро всплывают проблемы синхронизации этого пакета из п.2, только в квадрате.
Это из крупных проблем. (Ну и еще избавить от momentjs который по волшебной причине игнорирует то что он шаренный и грузится в полном объеме в каждом пакете та еще задача, но это решаемо). Мелких камушков очень много, но они уже не так портят жизнь. Например, чтобы удобно запускать всё это локально пришлось написать свой собственный мини-сервер, который определяет запущенно локально и что нет и проксирует на локальный вебпак или берет с тестового стенда. Впрочем, один день работы на этот прокси, зато результат просто поразительный.
Ну и совет, он очень капитанский, но делюсь опытом: если решите внедрять федерации, делайте ровно по шагу: обновление до пятого вебпака, потом всё — первая большая федерация, потом система загрузки федераций как в статье (там чуть больше сложностей связанных с тем что обычно есть некий importmap чтобы когда какая-то команда решила что-то изменить, им не пришлось просить другие команды отобразить это изменение у себя), затем первые небольшие федерации, на которых можно обкатать внедрение зависимостей, и так дальше. Моей ошибкой было желание вынести авторизацию в отдельный модуль как можно скорее, в итоге это затянуло миграцию на месяцы.
Понятно что Хабр живет только с рекламы. Но реклама разной бывает: статьи с околонулевым рейтингом преследующие цель впарить что-то непосредственно аудитории хабра (читай: интеграции), или даже очень неплохие статьи, пусть и рекламные, или как этот пример: эксплуатация популярности ресурса ради продвижения в поисковой выдаче. Глупо думать что они рассчитывают на публику хабра, а полный игнор в комментариях это только подтверждает.
И проблема, как я вижу, тут в основном в подрыве доверия к ресурсу среди посетителей и потенциальная потеря, значительно превышающая зароботок от этой рекламы. Представьте что все набегут сюда клепать рекламные статьи по три штуки в день только чтобы забить ключевые слова. Я удивлён что до такого топорного способа додумались продажники довольно посредственного продукта, но не удивлюсь если подхватят и другие.
Да бросьте. Просто кто-то решил что Хабр хорошо индексируется и статьи на ключевую тему выводится выше. Поэтому если замусорить весь ресурс всеми комбинациями слов RAID и восстановление данных, то при поиски «восстановить данные с raid” в топе окажутся эти заминусованные статьи с указанием целевой рекламируемой программы. У несведущих вообще может сложится впечатление что это чуть ли не единственный способ. И им все равно на рейтинг и что тут пишут, это очень грязное СЕО, реинкарнация перепродажи ссылок из двухтысячных.
Я бы на месте администрации хабра обратил внимание на наглую эксплуатацию ресурса исключительно в рекламных целях, а то смотрите и кто-то ещё подхватит, в итоге превратив ресурс в сплошную заминусованную рекламу.
К слову, вот вопрос: нужно переводить «литературно точно» (я бы сказал в стиле prompt — thread значит нить и контекст не важен), использовать общепринятое название, использовать оригинал покуда это название конкретной технологи или переводить технически точно, но очень отдаленно от оригинальной фразы (виртуальная многоядерность или что-то в этом духе для hyper threading)? И что делать с квантовой механикой, где куча терминов — просто случайные слова, которые выбраны просто потому что и не отражают истинное значение. (Запах, спин. Спин, к слову, вообще принято оставлять спином, хоть русский аналог слова существует).
Опустим что звучит максимально не по-русски, оно искажает смысл: звучит как-будто это поддержка каких-то особых нитей, господи упаси, но они там самые обычные, необычная компоновка процессора. А само название просто придумка, которую, наверное, не стоит переводить буквально.
Вы можете верифицировать конкретную версию, однако хром обновляет расширения скрытно, а раз у разработчиков есть ключ, он может залить какую-то зловредную версию ручками, у вас автоматом обновится версия на зловредную. Ведь никогда такого не случалось, когда злоумышленник получал несанкционированный доступ к ключам.
Понятное дело что риск и в хроме и в фаирфоксе, но в webassembler сложнее находить подобные уязвимости на этапе принятия в стор. Впрочем логика работает только если приложения вообще хоть как-то ревьюатся перед принятием, в противном случае разницы нет.
Согласен, я практически не знаю химию и биохимию и исхожу только из умений анализировать википедию. В целом я пропустил шаг, согласно википедии (тот еще источник), этанол "запускает активность ингибиторных ГАМК", которые, в свою очереди, и являются нейромедиаторами. (тут, в пункте "Головной мозг" и тут в первом же абзаце).
Но мой посыл был в том, что опьянение — это искажение работы мозга нейромедиаторами, а не отмирание части клеток мозга из-за кислородного голодания.
Вы только что описали микроинсульт. И он уж точно не воспринимается как эйфория.
Этанол является нейромедиатором, который приводит к замедению передачи сигналов в мозге и их искажению, а так же нарушает и ph баланс, и баланс гормонов в крови (что и приводит к эйфории) ещё метабализируется в не менее токсичные вещи (что вероятно приводит к похмелью). А не пространственный микроинсульт.
но помню да, в годах 2005 нас пугали этим в школе, было дело
Мне кажется, или уже куча раз было?
Но вообще смешно видеть пару тезисов чуть ли не из википедии и всё ради рекламки. Причем тезисы то спорны:
Электроника не имеет отношения к механики клавиатуры. И те и другие можно найти и с блокировкой клавиш и без.
Особенно коллегам пользователей. И нет, практически все конструкции механических клавиатур достаточно громкие чтобы бесить коллег.
Если вы 6 часов в день нажимаете одну и ту же кнопку каждые 2 секунды — вы что-то делаете не так в жизни. Но, справедливости ради, ни разу не видел даже мембранные клавиатуры, которые именно бы износились, а не протерлись (или не были залиты), так что аргумент так себе.
PS Ничего не имею против механических клавиатур и сам их предпочел бы, но статья уж совсем высосана из пальца.
Memoize с кешем, который ещё и сбрасывать можно, для слабаков.
Но подход интересный, хотя основная проблема в значительной сложности при чтении этого кода и неустойчивость к рефакторингу.
Рассинхрон редко прям очень, но бывает что не сильно заморачиваются с дженериками и просто ставят any, скажем, как возможный ключ. Но тоже редко и обычно хорошо локализируется. Рассинхрон типов с бэкэндом более частая проблема, и для неё пока особо нет стандартного решения, хотя можно накрутить поверх свагера.
Такое ощущение, что они всего лишь добавили немного мыльца и поправили тон и насыщенность цвета.
/Сарказм мод: у меня такая комбинация на кухне лежит, за 10 рублей за штуку, желтый многослойный круглый овощь. Каждый раз плачу, когда режу.
А я вот считаю, что самым эффективным вкладом является как раз таки противоположное - увеличение портребления. Если у индустрии будет больше денег и необходимости в новых источниках энергии, компании будут готовы тратить больше денег на расерч и на модернизацию сетей и станций.
Ну и у меня совесть чиста, покуда я точно знаю что я трачу «зелёную энергию».
А вам советую посмотреть сколько потребляет холодильник, который включён постоянно, и лимитировать его открытие до раза в день на 5 секунд, нечего выхоложивать его
Справедливости ради эта система в любом случае будет программной, покуда для принципа ее функционирования необходимо обсчитывать показания с акселерометров и анализировать. А вот что там дополнительная логика, да ещё с блютусом - это конечно просто невероятно. Надеюсь, что у них за это хотя бы разные контроллеры отвечают.
При аварии всего в 50 км/с на ремни приходится нагрузка в 2.5 тонны Источник (если ремень не растягивается).
Ремень, конечно, может быть с запасом, но механизмы могут и отказать от такой нагрузки, и не хочется это выяснить при создании такой нагрузки в следующий раз.
В европах этих (и в России, к слову, тоже) следует держаться скорости потока, но строго в рамках ограничения скорости, превышать нельзя. Но при этом запрещается безосновательно тащиться 40 где можно ехать 70, потому что это будет провоцировать обгоны. Вас даже привлечь могут если вы ехали безосновательно медленно, кто-то решил вас обогнать и не смог (продолжить маршрут).
Еще хотел добавить что в воздухе витает идея прикрутить ShadowDom, но я так и не смог заставить стили (сгенерированные вебпаком) монтироваться в нужное место, поэтому пока живем без него.
Ну и заодно как мы сделали:
Есть пакет который называется namespace/core, он подключается как обычный модуль ко всем федерациям, у него внутри три основные функции: ProvideFeredationContext, useFederationContext och RemoteComponent. Expose еще.
Первые два — собственно внедрение зависимостей поверх реактовских контекстов (главное отличие — он "выживает" внутри удаленного компонента).
Третий — принимает как аргумент модуль, который мы хотим внедрить, загружает его, монтирует в внутренний дивчик (ReactDom.render, сделано чтобы гарантированно разорвать все контексты внутри и предотвратить двойной контекст редакса, да и вообще мало ли), ну и передает контекст. expose — обертка над… экспортируемым реакт компонентом, необходимо для работы контекста (а еще создает контексты темы, локали и history для реакт роутера).
Есть хостовая федерация, которая грузит всё остальное, задает начальное состояние для контекстов и реализует RemoteComponent (внутри ядра просто типизированная заглушка для этого компонента). Хост так же отвечает за проксирование и где вообще лежат другие федерации.
Такой подход работает довольно хорошо в нашем случае, но есть проблемы когда мы считаем что что-то слишком маленькое чтобы быть федерацией, но достаточно важное чтобы это реализовать в единственном экземпляре, при этом это обладает логикой. Решение — передвинуть логику на бэк, например с помощью graphql, но если бы всё было так просто.
И еще одна раздражающая вещь, которую кажется можно решить, но как-то вот не решается:
Из-за разрыва контекста в RemoteComponent, а внутри Foo будет undefined. (Фуу мы передаем как ребенка внутрь чужой федерации по тем или иным причинам).
Собаку съел (да что уж там, целую стаю собак) на федерациях, спешу поделиться.
Ну первое и главное — оно работает и работает довольно круто, решая проблемы для решения которых оно предназначено (у нас три огромных приложения, разрабатываемые несколькими разными командами, и мы теперь можешь включать части чужого приложения в наше по необходимости, а так же команды внутри разъехались в отдельные репозитории с отдельнымии пайплайнами, в общем всё хорошо и красиво).
Но к недостаткам:
Вообще основные недостатки связаны с необходимостью что-то пошарить между модулями. Но этот конкретно — внедрение данных (в первую очередь, авторизации, но у нас это еще тема, локаль, окружение и какие-то системные вещи). Если коротко — все способы обладают теми или иными недостатками и компромисы кусаются. Мы остановились на системе поверх контекстов реакта, разве что весь контекст передается автоматически внутри аналога LazyService из статьи, но каждая федерация обязана быть обернутой в специальный метод. Главный принципиальный недостаток (помимо того что мы передаем ссылку на контекст внутри этого же контекста, хех) — сложность реализации вне реакта. А еще всё должно быть помещено внутрь реакт компонента, покуда вне его к контексту очевидно нет доступа. Но это отдельная большая тема, больше чем можно вместить в комментарий.
shared из вебпака работает далеко не так радужно как хотелось бы. На самом деле некоторые пакеты очень требовательны к версии (реакт и реакт дом), для других (антд) мы генерируем общий файл стилей в зависимости от темы только один раз, как следствие, все остальные федерации так же должны использовать конкретную версию. Если коротко — есть набор пакетов, версия которых должна быть жестко зафиксирована и использоваться одинаковой во всех федерациях. Не было бы проблем, если бы package.json можно было бы наследовать, но, к сожалению, миграция пакетов на более новую версию та еще эпопея. И да, решить можно просто перестав шарить пакеты между приложениями, но тогда теряется смысл с федераций. Да и вообще, иногда кажется что с system.js было бы проще. П.С. history для реакт роутера обязан быть одинаковым во всей системе, и генерирует отдельный слой сложности.
Иногда в голову приходит идея "давайте переиспользуемые компоненты вынесем в некий общий пакет, который будет использоваться всеми". В общем, работает только при правильно настроенном деплое этого общего пакета и только если в нем чистые глупые компоненты / функции. Иначе очень быстро всплывают проблемы синхронизации этого пакета из п.2, только в квадрате.
Это из крупных проблем. (Ну и еще избавить от momentjs который по волшебной причине игнорирует то что он шаренный и грузится в полном объеме в каждом пакете та еще задача, но это решаемо). Мелких камушков очень много, но они уже не так портят жизнь. Например, чтобы удобно запускать всё это локально пришлось написать свой собственный мини-сервер, который определяет запущенно локально и что нет и проксирует на локальный вебпак или берет с тестового стенда. Впрочем, один день работы на этот прокси, зато результат просто поразительный.
Ну и совет, он очень капитанский, но делюсь опытом: если решите внедрять федерации, делайте ровно по шагу: обновление до пятого вебпака, потом всё — первая большая федерация, потом система загрузки федераций как в статье (там чуть больше сложностей связанных с тем что обычно есть некий importmap чтобы когда какая-то команда решила что-то изменить, им не пришлось просить другие команды отобразить это изменение у себя), затем первые небольшие федерации, на которых можно обкатать внедрение зависимостей, и так дальше. Моей ошибкой было желание вынести авторизацию в отдельный модуль как можно скорее, в итоге это затянуло миграцию на месяцы.
Понятно что Хабр живет только с рекламы. Но реклама разной бывает: статьи с околонулевым рейтингом преследующие цель впарить что-то непосредственно аудитории хабра (читай: интеграции), или даже очень неплохие статьи, пусть и рекламные, или как этот пример: эксплуатация популярности ресурса ради продвижения в поисковой выдаче. Глупо думать что они рассчитывают на публику хабра, а полный игнор в комментариях это только подтверждает.
И проблема, как я вижу, тут в основном в подрыве доверия к ресурсу среди посетителей и потенциальная потеря, значительно превышающая зароботок от этой рекламы. Представьте что все набегут сюда клепать рекламные статьи по три штуки в день только чтобы забить ключевые слова. Я удивлён что до такого топорного способа додумались продажники довольно посредственного продукта, но не удивлюсь если подхватят и другие.
Да бросьте. Просто кто-то решил что Хабр хорошо индексируется и статьи на ключевую тему выводится выше. Поэтому если замусорить весь ресурс всеми комбинациями слов RAID и восстановление данных, то при поиски «восстановить данные с raid” в топе окажутся эти заминусованные статьи с указанием целевой рекламируемой программы. У несведущих вообще может сложится впечатление что это чуть ли не единственный способ. И им все равно на рейтинг и что тут пишут, это очень грязное СЕО, реинкарнация перепродажи ссылок из двухтысячных.
Я бы на месте администрации хабра обратил внимание на наглую эксплуатацию ресурса исключительно в рекламных целях, а то смотрите и кто-то ещё подхватит, в итоге превратив ресурс в сплошную заминусованную рекламу.
К слову, вот вопрос: нужно переводить «литературно точно» (я бы сказал в стиле prompt — thread значит нить и контекст не важен), использовать общепринятое название, использовать оригинал покуда это название конкретной технологи или переводить технически точно, но очень отдаленно от оригинальной фразы (виртуальная многоядерность или что-то в этом духе для hyper threading)? И что делать с квантовой механикой, где куча терминов — просто случайные слова, которые выбраны просто потому что и не отражают истинное значение. (Запах, спин. Спин, к слову, вообще принято оставлять спином, хоть русский аналог слова существует).
Я бы использовал общепринятые названия.
Опустим что звучит максимально не по-русски, оно искажает смысл: звучит как-будто это поддержка каких-то особых нитей, господи упаси, но они там самые обычные, необычная компоновка процессора. А само название просто придумка, которую, наверное, не стоит переводить буквально.
А теперь hyperthreading. Гипернитность?
Хорошо.
Вы можете верифицировать конкретную версию, однако хром обновляет расширения скрытно, а раз у разработчиков есть ключ, он может залить какую-то зловредную версию ручками, у вас автоматом обновится версия на зловредную. Ведь никогда такого не случалось, когда злоумышленник получал несанкционированный доступ к ключам.
Понятное дело что риск и в хроме и в фаирфоксе, но в webassembler сложнее находить подобные уязвимости на этапе принятия в стор. Впрочем логика работает только если приложения вообще хоть как-то ревьюатся перед принятием, в противном случае разницы нет.