Еще есть люди, такие как SERIAL(гуглил инфу и наткнулся) — они играют по Миру Тьмы, уже несколько лет и 9 компаний(арок) отыграли. И мир учитывает изменения, произошедшие «в прошлых эпизодах».
Так вот, там как раз имеется такая услуга: «Сопровождение» персонажа. Это означает, что если вы куда-то уехали/заболели/хотите сделать перерыв/вас нет на мероприятии, но при этом желаете, чтобы Ваш персонаж продолжил как-то действовать в мире игры, мастера это обеспечивают.»
А с чего это вы взяли, что интернет — Ваш?
Интернет принадлежит владельцам сайтов и инфраструктуры, а самые крупные из них(первых) — Гугл, Амазон и Фейсбук, корпорации. В Китае — Tencent и Alibaba group, потому что от США они отгородились фаерволом. Вторые — тем более.
К пользователям они прислушиваются только потому, что в противном случае теряют прибыль.
Да и к государствам они прислушиваются ровно по той же причине.
Во-первых, примем, что пользователь делает запрос к серверу Mozilla/Cloudflare/Троя Ханта. Потому что сейчас сервисом "проверь свой пароль" интересуются люди технически подкованные, которые фишингом не обманешь, а когда инструмент будет встроен в Firefox, адрес будет зашит в него.
А если мы знаем логин пользователя, пароль к которому он проверяет(без этого знать пароль бесполезно), и если мы имеем MITM(потому что мы перехватили запрос к серверу) либо заразили его компьютер, то пользователю и без использования этого сервиса пипец. С такими возможностями можно просто сделать тот же session hijacking.
Ну и к тому же сервис Firefox будет проверять логины, а не пароли. Еще более бесполезно для злоумышленника.
Firefox отправляет первые 6 символов(24 бита), а приходят полные хэши SHA-1(160 битов). Итого — 2^136 вариантов, которые нужно перебрать «злоумышленнику». Причём не на своём компьютере, а отправив их запрашивающему.
Проблема цитат в интернете в том, что люди сразу верят в их подлинность (с) В.И.Ленин
Собственно дополнять свои слова цитатой знаменитого человека научились задолго до интернета. Думаю, хотя бы пару перлов за свою жизнь произносит каждый, но публичных людей записывают и перечитывают — особенно таких публичных.
А касательно ёмкости и универсальности — сразу вспоминается «О мертвых либо хорошо, либо нечего», у которой пропал конец «кроме правды». Формулируют и полная, и обрезанная цитаты вполне универсальный принцип, но достаточно сильно различающийся.
Меньше использовалось — меньше КИУМ — больше стоимость за единицу мощности — менее выгодная генерация.
Станции на угле(которые дешевая базовая генерация) за несколько секунд не запустишь — нужно строить новые станции.
Горячий резерв — например, на случай если внезапно кончился ветер. Точнее, совсем внезапно — это вращающийся, горячий это до часа кажется — если внезапно облака, например. Естественно, и в системе с диспетчеризуемой генерацией есть резерв на случай отказов, но прерывистая генерация заставляет держать его больше, и обходится это дороже.
Ветер пропасть может запросто. Я уже говорил, посмотрите для примера на ситуацию в Австралии в январе 2018. Там и средняя цена электричества за пару безветренных недель подскочила раза в 3, и в пике до 14 тысяч австралийских долларов за МВт*ч доходила, и блэкаут у них был.
Из недавнего — [Фейсбук просил полный доступ](https://www.securitylab.ru/news/493398.php)
Конечно же, они отговорились технической ошибкой, *но мы-то знаем...*
Можно, не спорю. Вот такая ГАЭС в Японии, уже почти 20 лет, например.
И вот обзор похожего проекта (солнце + ГАЭС) для Чили. Впрочем там отмечается, что всё равно дешевле купить несколько АЭС.
Другое дело, что еще можно построить ТЭС на угле с современной системой фильтрации и избавиться от проблем с прерывистой генерацией за меньшие деньги. Но это же не зелёное получается, и не модное.
Для экологии-то может и хорошо, а для цен — нет. Если сравнить плотность населения в Китае и в Австралии — сразу станет понятно, что таких проблем там должно быть меньше.
Угольные станции, даже с учетом фильтров и прочих примочек — выходят дешевле газовых станций. Особенно учитывая запасы угля в Австралии.
К тому же если вы останавливаете станцию в часы активности солнца/ветра — вы не используете ее мощности. При этом горячий резерв иметь всё равно надо. А это — дополнительные расходы.
Проблема солнца, ветра и т.п. не только в том, что их может не быть какое-то время, их может не быть внезапно.
Как например в жарком январе 2018, когда цена на э/э на оптовом рынке доходили до 14 тыс. австралийских долларов за МВт*ч, плюс блэкаут на 50000 человек в Мельбурне.
Просто "лишнего места" — да, хватает. Но для ГАЭС внезапно нужна еще и вода. И перепад высот.
"Остров" — в контексте того, что соседей с энергосистемой у них нет. Да и самих австралийцев — всего 25 миллионов. Соответственно дисбаланс становится заметным раньше.
Германии легче, у них вся Европа в интерконнектах и свое нестабильное электричество можно перекинуть соседям, или занять у них когда свои ветряки стоят. А Австралия — большой остров, и скинуть проблемы не на кого.
Да и касательно «хранить» — на сегодня сколько-нибудь хороших решений нет. Единственная технология, позволяющая строить система хранения достаточно масштабные и достаточно дешевые — это ГАЭС. И у неё свои недостатки — например, нужно хорошее место.
Люди ставят солнечные электростанции -> дешевые станции на угле закрываются, потому что рассчитаны на постоянную нагрузку -> электричество для всех дорожает -> еще больше людей ставят солнечные электростанции.
И получается замкнутый цикл деградации энергосистемы.
С другой стороны, CDA в действие не привели, как и следующую за ним COPA, а CIPA признали законным только в 2004, потому что суды. А вот DMCA в 1988 сразу прошел в действующие законы.
Видимо, за порно, в отличие от против копирайта, было кому занести.
>Например, если в элементарных действиях делается lock на ресурс, то ее реквизиты нужно сохранить в контексте и в функции on-result-fn этот lock нужно освободить.
Допустим, вы берете лок и потом кидаете exception (в одном элементарном действии). Вопрос: откуда вы узнаете, что был взят лок? Ведь у вас есть только контекст до начала действия?
>А как мы сможете это сделать только через комбинирование действий, если у вас нет начального контекста?
Начальный контекст это то, что мы передали как параметр первому(скомбинированному) действию. Этот параметр в вызывающей функции никуда не делся, и мы можем просто использовать его еще раз.
Только вот вы эти проблемы тоже не решаете.
1) Вы передаёте в on-result-fn контекст, каким он был до выполнения кинувшей exception функции. Ни что это за функция, ни какой был exception — вы не узнаёте. Более того, вы даже не знаете, on-result-fn вызывается после успешного выполнения или из-за ошибки, если не впихнёте это в context.
Если вам достаточно такого странного — можно сделать свой instance монады и доопределить bind. Если нет, вам тоже придется придумывать тот же самый велосипед.
2) А вам что делать? У вас нет «продолжить отсюда». Вы можете только стартовать все операции с начала, и пропускать внутри те, которые уже были выполнены — проверяя внутри это контест. Так и я могу. Или же как-то допилить ваш велосипед, дополнив его еще парой костылей.
К тому же мы сделали rollback согласно пункту 1, то операции в любом случае нужно выполнять опять.
Может быть, решает, да. Но с моей точки зрения вы просто переизобрели велосипед — монаду Either.
> Элементарное действие принимает контекст единственным параметром.
Не вижу сложностей. Просто не делайте других параметров. И кстати, как вы тогда будете реализовывать действие «вернуть первые N записей»? Требовать, чтобы N было в вашем контексте под каким-то именем? Согласитесь, это же некрасиво. Особенно если это действие — первое в списке из нескольких. Потому что более никому ненужный параметр N так в контексте и останется.
> Результат нужно возвращать после применения элементарных действий над текущим контекстом.
Извиняюсь, не заметил, что промежуточные значения вы просто кладете в контекст. (Впрочем, until-first-error так и так возвращает updated-context, а не результат.) Только вот это порождает сразу несколько проблем. Как минимум, ломается изоляция — последующие функции видят результат всех предыдущих, если его явно не удалили из контекста. А удалять — значит это вы рассчитываете, что после функции a будет в цепочке функций всегда b, которая удалит результат a из контекста. Но тогда эти две функции разумно объединить.
>Является ли контекстное программирование заменой монадного программирование и решает ли он те же задачи, что и монады?
Не является. И не решает. Но все костыли вашего контекстного программирования заменяются использованием монады Either, даже не требуя глубокого понимания «что такое монады».
Так вот, там как раз имеется такая услуга: «Сопровождение» персонажа. Это означает, что если вы куда-то уехали/заболели/хотите сделать перерыв/вас нет на мероприятии, но при этом желаете, чтобы Ваш персонаж продолжил как-то действовать в мире игры, мастера это обеспечивают.»
Интернет принадлежит владельцам сайтов и инфраструктуры, а самые крупные из них(первых) — Гугл, Амазон и Фейсбук, корпорации. В Китае — Tencent и Alibaba group, потому что от США они отгородились фаерволом. Вторые — тем более.
К пользователям они прислушиваются только потому, что в противном случае теряют прибыль.
Да и к государствам они прислушиваются ровно по той же причине.
А. На самом деле это просто бессмысленно.
Во-первых, примем, что пользователь делает запрос к серверу Mozilla/Cloudflare/Троя Ханта. Потому что сейчас сервисом "проверь свой пароль" интересуются люди технически подкованные, которые фишингом не обманешь, а когда инструмент будет встроен в Firefox, адрес будет зашит в него.
А если мы знаем логин пользователя, пароль к которому он проверяет(без этого знать пароль бесполезно), и если мы имеем MITM(потому что мы перехватили запрос к серверу) либо заразили его компьютер, то пользователю и без использования этого сервиса пипец. С такими возможностями можно просто сделать тот же session hijacking.
Ну и к тому же сервис Firefox будет проверять логины, а не пароли. Еще более бесполезно для злоумышленника.
Firefox отправляет первые 6 символов(24 бита), а приходят полные хэши SHA-1(160 битов). Итого — 2^136 вариантов, которые нужно перебрать «злоумышленнику». Причём не на своём компьютере, а отправив их запрашивающему.
Собственно дополнять свои слова цитатой знаменитого человека научились задолго до интернета. Думаю, хотя бы пару перлов за свою жизнь произносит каждый, но публичных людей записывают и перечитывают — особенно таких публичных.
А касательно ёмкости и универсальности — сразу вспоминается «О мертвых либо хорошо, либо нечего», у которой пропал конец «кроме правды». Формулируют и полная, и обрезанная цитаты вполне универсальный принцип, но достаточно сильно различающийся.
Станции на угле(которые дешевая базовая генерация) за несколько секунд не запустишь — нужно строить новые станции.
Горячий резерв — например, на случай если внезапно кончился ветер. Точнее, совсем внезапно — это вращающийся, горячий это до часа кажется — если внезапно облака, например. Естественно, и в системе с диспетчеризуемой генерацией есть резерв на случай отказов, но прерывистая генерация заставляет держать его больше, и обходится это дороже.
Ветер пропасть может запросто. Я уже говорил, посмотрите для примера на ситуацию в Австралии в январе 2018. Там и средняя цена электричества за пару безветренных недель подскочила раза в 3, и в пике до 14 тысяч австралийских долларов за МВт*ч доходила, и блэкаут у них был.
Конечно же, они отговорились технической ошибкой, *но мы-то знаем...*
Вот такая ГАЭС в Японии, уже почти 20 лет, например.
И вот обзор похожего проекта (солнце + ГАЭС) для Чили. Впрочем там отмечается, что всё равно дешевле купить несколько АЭС.
Другое дело, что еще можно построить ТЭС на угле с современной системой фильтрации и избавиться от проблем с прерывистой генерацией за меньшие деньги. Но это же не зелёное получается, и не модное.
Для экологии-то может и хорошо, а для цен — нет. Если сравнить плотность населения в Китае и в Австралии — сразу станет понятно, что таких проблем там должно быть меньше.
Угольные станции, даже с учетом фильтров и прочих примочек — выходят дешевле газовых станций. Особенно учитывая запасы угля в Австралии.
К тому же если вы останавливаете станцию в часы активности солнца/ветра — вы не используете ее мощности. При этом горячий резерв иметь всё равно надо. А это — дополнительные расходы.
Проблема солнца, ветра и т.п. не только в том, что их может не быть какое-то время, их может не быть внезапно.
Как например в жарком январе 2018, когда цена на э/э на оптовом рынке доходили до 14 тыс. австралийских долларов за МВт*ч, плюс блэкаут на 50000 человек в Мельбурне.
Просто "лишнего места" — да, хватает. Но для ГАЭС внезапно нужна еще и вода. И перепад высот.
"Остров" — в контексте того, что соседей с энергосистемой у них нет. Да и самих австралийцев — всего 25 миллионов. Соответственно дисбаланс становится заметным раньше.
Да и касательно «хранить» — на сегодня сколько-нибудь хороших решений нет. Единственная технология, позволяющая строить система хранения достаточно масштабные и достаточно дешевые — это ГАЭС. И у неё свои недостатки — например, нужно хорошее место.
И получается замкнутый цикл деградации энергосистемы.
Видимо, за порно, в отличие от против копирайта, было кому занести.
Допустим, вы берете лок и потом кидаете exception (в одном элементарном действии). Вопрос: откуда вы узнаете, что был взят лок? Ведь у вас есть только контекст до начала действия?
>А как мы сможете это сделать только через комбинирование действий, если у вас нет начального контекста?
Начальный контекст это то, что мы передали как параметр первому(скомбинированному) действию. Этот параметр в вызывающей функции никуда не делся, и мы можем просто использовать его еще раз.
1) Вы передаёте в on-result-fn контекст, каким он был до выполнения кинувшей exception функции. Ни что это за функция, ни какой был exception — вы не узнаёте. Более того, вы даже не знаете, on-result-fn вызывается после успешного выполнения или из-за ошибки, если не впихнёте это в context.
Если вам достаточно такого странного — можно сделать свой instance монады и доопределить bind. Если нет, вам тоже придется придумывать тот же самый велосипед.
2) А вам что делать? У вас нет «продолжить отсюда». Вы можете только стартовать все операции с начала, и пропускать внутри те, которые уже были выполнены — проверяя внутри это контест. Так и я могу. Или же как-то допилить ваш велосипед, дополнив его еще парой костылей.
К тому же мы сделали rollback согласно пункту 1, то операции в любом случае нужно выполнять опять.
> Элементарное действие принимает контекст единственным параметром.
Не вижу сложностей. Просто не делайте других параметров. И кстати, как вы тогда будете реализовывать действие «вернуть первые N записей»? Требовать, чтобы N было в вашем контексте под каким-то именем? Согласитесь, это же некрасиво. Особенно если это действие — первое в списке из нескольких. Потому что более никому ненужный параметр N так в контексте и останется.
> Результат нужно возвращать после применения элементарных действий над текущим контекстом.
Извиняюсь, не заметил, что промежуточные значения вы просто кладете в контекст. (Впрочем, until-first-error так и так возвращает updated-context, а не результат.) Только вот это порождает сразу несколько проблем. Как минимум, ломается изоляция — последующие функции видят результат всех предыдущих, если его явно не удалили из контекста. А удалять — значит это вы рассчитываете, что после функции a будет в цепочке функций всегда b, которая удалит результат a из контекста. Но тогда эти две функции разумно объединить.
>Является ли контекстное программирование заменой монадного программирование и решает ли он те же задачи, что и монады?
Не является. И не решает. Но все костыли вашего контекстного программирования заменяются использованием монады Either, даже не требуя глубокого понимания «что такое монады».