У меня есть ряд интересных идей, которые можно использовать в борьбе со всемогущими инопланетянами. Считаю, что ограничения, которые они вложили в технологию, указывают на их слабости, и поэтому эти ограничения следует эксплуатировать по максимуму.
Ограничение в 2033 м — правильно ли я понял, что имеется в виду, что нам доступна для просмотра полоса от 2033 м ниже уровня моря до 2033 м выше уровня моря? Это означает, что:
Мы сможем хранить секретные материалы вне этого диапазона. Согласитесь, нетрудно представить себе секретные эксперименты где-нибудь на высокой горе или вообще на орбитальной станции, ну или хранение опасных материалов где-нибудь в глубоченной скважине.
Непонятно, как это будет работать с поиском людей по фотографии. Если они выйдут за пределы диапазона — что из этого получится? Мы сможем выйти за пределы ограничений в 2033? А камеру там крутить можно будет? А двигать? Похоже на дыру в системе.
Следует запустить группу каких-нибудь нейросетей на автоматическое исследование всех доступных фрагментов поверхности Земли и мирового океана на пределах видимости сайта. Возможно, мы сможем найти там что-то интересное — какие-нибудь неучтённые постройки или элементы инфраструктуры, ведущие «в никуда», которые на самом деле приведут нас в логово тех, кто всё это замыслил. Зачем нейросети? А на случай, если фрагменты изображений будут цензурироваться: по несоответствиям границ кадров или ещё каким-нибудь косвенным признакам можно будет попробовать это установить.
Очень интересным кажется свойство защиты от лукавого, вот вам несколько идей:
Во-первых, нужно исследовать границы технологии: маскируются только прямые трансляции непосредственно с сайта? А что, если смотреть их в записи? А что, если смотреть фрагменты записей? Фотографии, вырезанные из записей, или и фрагменты? А что, если художник, глядя на фотографию записи, будет её перерисовывать краской — в какой момент будет включаться цензура, и что она будет цензурировать?
Видится, что действия пользователей сайта всё равно можно будет отслеживать, просто наблюдая за движениями их рук (какие клавиши нажимают на клавиатуре) или подслушивая их голосовые команды.
Ну и, наконец, как вам такое? Наши сотрудники будут работать с документами не напрямую, а разглядывая их через средства сайта. Таким образом, нельзя будет понять, с чем же работает сотрудник, и некоторый уровень секретности будет сохранён.
Нарядим наш спецназ в костюмы, на поверхность которых проецируются изображения с сайта. И встроим прожекторы, которые на все окрестности тоже проецируют изображения с сайта. Приведёт ли это к полноценному цензурированию всех освещённых поверхностей? Можно ли будет на сайте что-то рассмотреть во время применения такой «светомузыки»?
Поиск людей по фотографии — тоже интересная затея сама по себе. Что, если взять фотографии, снятые до временной отсечки? Ну, Туринскую плащаницу какую-нибудь, а — ведь говорят, что она тоже была создана типа фотографическим способом? Или изображения с камер-обскур, если сохранились. Попахивает как минимум ещё одной волной сектантов :) А что, если мы начнём искать мёртвых людей — будет ли сайтик показывать нам, где находятся их тела, или же покажет из загробную жизнь? А что, если генерировать лица людей и пытаться найти по ним что-нибудь? Это будет работать? Не найдём ли мы таким способом чего интересного, если сгенерируем триллион зелёнокожих лиц? Не попадём ли рано или поздно в одного из инопланетян?
Вы исходите из предпосылки, что F# — это только про ФП. А между тем там есть и ООП-штуки, и некоторые из них очень интересные — object expressions, например, которых временами не хватает в C#.
Сильно зависит от вашего опыта в работе с тем и другим. Я бы вот скорее сказал, что моему опыту это утверждение не соответствует: интероп обычно прозрачен и прост.
Ваш случай с сетевыми пакетами и колбэками очень хорошо и аутентично решается в Erlang (в котором, если я правильно помню, вообще нет мутабельных переменных): этот функциональный язык программирования вообще хорошо подходит для решения такого рода задач. Здесь решение будет строиться на акторах: заведём, например, какого-нибудь глобального диспетчера, которому будут приходить сообщения из колбэков ОС, а он будет их раздавать акторам — которые, например, считают количество полученных сообщений. Код внутри акторов не мутирует никаких переменных, а просто принимает старое состояние (и пришедшее сообщение), а возвращает новое состояние (ну или рекурсивно себя вызывает с этим новым состоянием).
(При этом я полагаю, что где-то в глубине акторного фреймворка может быть мутабельный код, но в Erlang его вам никто не показывает.)
В F# может быть использовано то же самое решение — ведь у нас в .NET тоже есть акторные фреймворки — а ещё есть встроенные акторы в стандартной библиотеке F#, которые также позволят обойтись без mutable в пользовательском коде.
Если я правильно помню, одним из критериев, который разрешает отдавать любую информацию о вас, в соответствии с GDPR является требование закона. Иначе сервисы бы и от их собственных правоохранителей были обязаны скрывать информацию, а это абсурдно.
Ну, в таком случае нам остаётся пригласить товарища в багтрекер расширения: пускай оформит там возникшие у него проблемы, и тогда их можно будет починить!
А что бы вы хотели «из коробки»? Уже за вас всё реализовано. Вы просто берёте и пишете код на любом .NET-совместимом языке, который использует возможности библиотеки Avalonia. Я добросовестно пытаюсь понять, чего именно вам в библиотеке не хватает для того, чтобы начать писать код на VB.NET, но пока что не понял.
Попытаюсь перефразировать. Разработка с использованием Avalonia на языке VB.NET ничем не отличается от разработки с использованием Avalonia на языке C# — за исключением, разумеется, того, что вы весь код пишете на VB.NET :) Оба этих языка являются first-class citizens в экосистеме Avalonia, между ними нет разницы. Avalonia нигде не привязывается к какому-то конкретному языку (ну, кроме её собственного внутреннего кода — но вам-то его снаружи не видно, если вы его специально не открыли и не начали читать).
VB.NET поддерживается в полном объёме: XAML-разметку пишете так же, а вместо C# используете кодбехайнд и модели на C#. Энтузиасты используют для работы с Avalonia даже F# и PascalABC.NET — что уж говорить про поддержку VB.NET, одного из (официально) основных языков платформы .NET.
Не беспокойтесь, с поддержкой языков в Avalonia всё в полном порядке — даже получше, чем в WPF (который, к примеру, не считает F# за first-class citizen).
Мне кажется, проблему с Lazy можно было бы решить более изящно (не перенося ответственность по инициализации значений на вызывателя):
var dictionary = new ConcurrentDictionary<MyKey, MyValue>();
var lazy = new Lazy<MyValue>(() => new MyValue());
var value = dictionary.GetOrCreate(key, _ => lazy.Value);
Этот код так же защищён от множественных одновременных вызовов .Value, но при этом наружу из него Lazy не торчат — клиент получает обычный ConcurrentDictionary<MyKey, MyValue>.
Явно указывать ExecutionAndPublication тоже, кстати, необязательно — это и есть режим по умолчанию.
Обязательно стоит упомянуть это в тексте статьи (и в книге тоже)! Это крайне важная ремарка. Без неё у моих коллег сразу возникло резкое недоверие к материалу.
Это хорошая и правильная идея — предоставлять свой код для оценки сообществом (даже если вы новичок, в этом нет ничего зазорного). Другой разговор, что сообщество Хабра, возможно, для этого не лучшим образом подходит (на этом ресурсе люди всё-таки чаще ожидают каких-то законченных материалов для специалистов среднего и высокого уровня). Мне кажется, что куда больше фидбэка вы сможете получить, если обратитесь в места с более высокой концентрацией .NET-разработчиков.
Та же самая проблема будет, если вы не используете EditorConfig: работаешь с одним проектом — ставь глобально табы, работаешь с другим — ставь глобально пробелы.
Похоже, единственной адекватной опцией при работе с Visual Studio (в которой нет концепции локальных настроек отступов) является использование EditorConfig везде, на всех проектах. При этом «засорять» сторониие репозитории этим файлом необязательно — можно просто помещать его уровнем выше относительно *.sln. В такой конфигурации он тоже должен работать (но, честно признаюсь, я проверял довольно давно).
Ну и начиная с 2017 студии можно держать несколько её инсталляций, заточенных на разные проекты (наверное, и настройки отступов тоже будут разные). Но из-за такой мелочи держать отдельную инсталляцию Visual Studio — это, конечно, оверхед.
У меня есть ряд интересных идей, которые можно использовать в борьбе со всемогущими инопланетянами. Считаю, что ограничения, которые они вложили в технологию, указывают на их слабости, и поэтому эти ограничения следует эксплуатировать по максимуму.
Вы исходите из предпосылки, что F# — это только про ФП. А между тем там есть и ООП-штуки, и некоторые из них очень интересные — object expressions, например, которых временами не хватает в C#.
Писанины сразу станет значительно больше.
Это очень хороший и интересный язык, но, кажется, он умер? Поддержки .NET Core нет, растительности нет, жизни нет :(
Не каждый: React поддерживает и функциональные компоненты.
Сильно зависит от вашего опыта в работе с тем и другим. Я бы вот скорее сказал, что моему опыту это утверждение не соответствует: интероп обычно прозрачен и прост.
Ваш случай с сетевыми пакетами и колбэками очень хорошо и аутентично решается в Erlang (в котором, если я правильно помню, вообще нет мутабельных переменных): этот функциональный язык программирования вообще хорошо подходит для решения такого рода задач. Здесь решение будет строиться на акторах: заведём, например, какого-нибудь глобального диспетчера, которому будут приходить сообщения из колбэков ОС, а он будет их раздавать акторам — которые, например, считают количество полученных сообщений. Код внутри акторов не мутирует никаких переменных, а просто принимает старое состояние (и пришедшее сообщение), а возвращает новое состояние (ну или рекурсивно себя вызывает с этим новым состоянием).
(При этом я полагаю, что где-то в глубине акторного фреймворка может быть мутабельный код, но в Erlang его вам никто не показывает.)
В F# может быть использовано то же самое решение — ведь у нас в .NET тоже есть акторные фреймворки — а ещё есть встроенные акторы в стандартной библиотеке F#, которые также позволят обойтись без
mutableв пользовательском коде.Если я правильно помню, одним из критериев, который разрешает отдавать любую информацию о вас, в соответствии с GDPR является требование закона. Иначе сервисы бы и от их собственных правоохранителей были обязаны скрывать информацию, а это абсурдно.
Возможно, вас повеселит или заинтересует эта статья от Microsoft: Windows Update может создавать повышенную нагрузку, если в ОС существует пользователь с именем, содержащим подстроку "user".
Меня заинтересовали ваши идеи. Как планируете публиковать? Куда подписаться, чтобы узнать о публикации?
Разве? Кажется, Mono вполне себе живёт и развивается (постепенно объединяя части кода с .NET Core).
Спасибо, ваш рассказ мне понравился. Хотелось бы услышать и о реальной истории тоже.
Ну, в таком случае нам остаётся пригласить товарища в багтрекер расширения: пускай оформит там возникшие у него проблемы, и тогда их можно будет починить!
А что бы вы хотели «из коробки»? Уже за вас всё реализовано. Вы просто берёте и пишете код на любом .NET-совместимом языке, который использует возможности библиотеки Avalonia. Я добросовестно пытаюсь понять, чего именно вам в библиотеке не хватает для того, чтобы начать писать код на VB.NET, но пока что не понял.
Попытаюсь перефразировать. Разработка с использованием Avalonia на языке VB.NET ничем не отличается от разработки с использованием Avalonia на языке C# — за исключением, разумеется, того, что вы весь код пишете на VB.NET :) Оба этих языка являются first-class citizens в экосистеме Avalonia, между ними нет разницы. Avalonia нигде не привязывается к какому-то конкретному языку (ну, кроме её собственного внутреннего кода — но вам-то его снаружи не видно, если вы его специально не открыли и не начали читать).
К счастью, вы ошиблись :)
VB.NET поддерживается в полном объёме: XAML-разметку пишете так же, а вместо C# используете кодбехайнд и модели на C#. Энтузиасты используют для работы с Avalonia даже F# и PascalABC.NET — что уж говорить про поддержку VB.NET, одного из (официально) основных языков платформы .NET.
Не беспокойтесь, с поддержкой языков в Avalonia всё в полном порядке — даже получше, чем в WPF (который, к примеру, не считает F# за first-class citizen).
Мне кажется, проблему с
Lazyможно было бы решить более изящно (не перенося ответственность по инициализации значений на вызывателя):Этот код так же защищён от множественных одновременных вызовов
.Value, но при этом наружу из негоLazyне торчат — клиент получает обычныйConcurrentDictionary<MyKey, MyValue>.Явно указывать
ExecutionAndPublicationтоже, кстати, необязательно — это и есть режим по умолчанию.Обязательно стоит упомянуть это в тексте статьи (и в книге тоже)! Это крайне важная ремарка. Без неё у моих коллег сразу возникло резкое недоверие к материалу.
Это хорошая и правильная идея — предоставлять свой код для оценки сообществом (даже если вы новичок, в этом нет ничего зазорного). Другой разговор, что сообщество Хабра, возможно, для этого не лучшим образом подходит (на этом ресурсе люди всё-таки чаще ожидают каких-то законченных материалов для специалистов среднего и высокого уровня). Мне кажется, что куда больше фидбэка вы сможете получить, если обратитесь в места с более высокой концентрацией .NET-разработчиков.
Вот тут перечислено несколько .NET-сообществ в Telegram, приходите :)
Та же самая проблема будет, если вы не используете EditorConfig: работаешь с одним проектом — ставь глобально табы, работаешь с другим — ставь глобально пробелы.
Похоже, единственной адекватной опцией при работе с Visual Studio (в которой нет концепции локальных настроек отступов) является использование EditorConfig везде, на всех проектах. При этом «засорять» сторониие репозитории этим файлом необязательно — можно просто помещать его уровнем выше относительно
*.sln. В такой конфигурации он тоже должен работать (но, честно признаюсь, я проверял довольно давно).Ну и начиная с 2017 студии можно держать несколько её инсталляций, заточенных на разные проекты (наверное, и настройки отступов тоже будут разные). Но из-за такой мелочи держать отдельную инсталляцию Visual Studio — это, конечно, оверхед.