Как автор утилиты dpi-ch констатирую: к сожалению, вы правы, в текущей статье нейрослоп❗
Среди прочего, никогда ключей --target / --mode / --timeout не было, это tui утилита с .yaml конфигом (и ключи там используются в очень ограниченном кол-ве). С одной стороны лестно, что написано о моем проекте, но нельзя с большим прискорбием не заметить, что сама статья выглядит как плод неких фантазий, не имеющих отношения к реальности (в т.ч. с точки зрения того, как работает утилита и как она выглядит). Неплохо бы модераторам отреагировать.
Далее, постараюсь ответить на другие ваши "варианты":
у автора dpich несколько минорных релизов (которые при этом ломают cli) менее чем за сутки
Такого нет, в минорных релизах не ломается обратная совместимость (а мажорный никогда ещё не увеличивался).
github автора dpich взломан в последние сутки и там совсем другое
Такого также, к счастью, не наблюдается.
автор статьи сам не проверял команды которые приводит (а что тогда ЕЩЕ не проверялось?)
Очевидно это так, ибо с ключами из статьи (несуществующими) утилита просто уйдет в ошибку на старте. Причем такое поведение будет даже на самых старых версиях.
По крайней мере, можно автоматизированно определить ОДЗ для параметров "anti-DPI" утилит, а далее (также, автоматизированно) перебрать оставшиеся варианты одновременно тестируя их через dpi-ch — и выбрать наиболее оптимальный.
Термин ТСПУ применим только в РФ (по большей части), репозиторий же рассчитан на международное использование. Напр., есть ещё Китай, Иран и т.д.
В общем смысле мы называем это интернет-цензурой, а актора – цензором. Но для массового пользователя термин DPI является более привычным и удобным, хоть и не совсем точно раскрывает смысл.
На данной площадке затруднительно обсуждать что нам это "даст". Но, напр., понимание ситуации и диагностику средств обхода интернет-цензуры (исключительно в образовательных и/или исследовательских целях).
В общем-то и так ясно <...>
Да, это один из сценариев использования — автоматизация диагностики.
Как бы этот сканер не привлёк повышенного внимания к абоненту <...>
Гипотетически этого исключать нельзя, пользователи (см. соотв. warning в репозитории) сами несут за это ответственность.
И к тем сервисам, которые ещё не заблокированы
Вероятность этого, на мой взгляд, минимальная. В т.ч., но не ограничиваясь, из-за того, что утилита dpi-ch мимикрирует под работу обычного браузера (использование utls и проч.). Мало того, обычно причины блокировки сервисов не связаны с их анализом пользователями.
Репозиторий рассчитан на международные утилиты и нацелен не только на домашние провайдеры (напр., можно тестировать дата-центр), т.е., в каких-то местах DPI может вовсе не быть. Однако, применительно к РФ — да, вы в целом правы.
Денис, а каким образом k8s, исходя из его предназначения, решает задачу отказоустойчивости точки входа в веб-сервис? Etcd можно использовать и там и там, — тут вы правы. Ну и что?
Роман, были порывы назвать статью в таком ключе. Но, к сожалению, далеко не все поймут, о каком HtmlHelper'e идет речь. Более того, тут достаточно «жестко» предлагается прятать DTO во ViewModel, это неразрывная концепция описанной мной идеи.
Также речь не только об TextBoxFor, речь о любом контроле, который поддерживается стандартной реализацией HtmlHelper.
Однако, после ваших слов, ухожу на очередную итерацию, направленную на более подходящее название. Спасибо!
Не вижу очевидных причин не соглашаться с вашим утверждением на тему формального описания. Однако, не для хабра это статья получится (а в данном случае даже плашка Tutorial висит). Да и на тему формализма у меня в целом двоякое чувство, ещё со времен работы с математическим аппаратом.
Чтобы генератор кода мог генерировать DTO'шки, ему необходимо знать о заложенных правилах бизнес-логики (иными словами, что ожидается на вход от пользователя). Ведь добрая часть полей генерируется сервисом во время запроса (яркий пример — ID).
Чтобы искомый генератор «знал» о данных правилах, их нужно описать. Описать в формализованном и общем виде. А данная операция, на мой взгляд, едва ли менее трудоемкая, чем сразу написать соответствий DTO вручную (это и будет, в частности, манифест который требуется «на вход» генератору).
Однако, в действительности можно представить, что вы в используемой IDE графически выделяете нужные свойства в модели, нажимаете кнопку генерации и получается соответствующий DTO-класс, тогда неплохо.
С контроллером вообще все сложно (впрочем, CRUD функции можно сгенерировать в некотором общем виде для сущности, и сопутствующие сервисы тоже, тут вы правы).
Уверен, что это в любом случае задача IDE.
Понял вас. В действительности, многие разработчики задумываются о подобной генерации кода, и я не исключение. Однако, меня всегда останавливало следующее:
Если данный генератор кода будет универсальным в предельно общем смысле, то его настройка будет более сложна, чем механическое написание данного кода.
Это из той же серии (утрированно), что и написание некоторой универсальной системы в принципе.
// Когда-то я с товарищами задумал написать программный комплекс, эмпирически решающий подавляющее большинство типичных задач по ТВиМСу с помощью моделирования на основе входных данных, да так, чтобы любой неподготовленный человек сумел воспользоваться. Однако, на стадии прототипирования стало понятно, что настройка и формирование входных данных на комплекс — задача более трудоемкая, чем «по-быстрому» закодить это на том же Python'e и посмотреть результаты. Это впоследствии послужило большим уроком в аспекте универсальных подходов.
А вот шаблоны, гайдлайны — приветствую, ибо там действительно одно и тоже (и это хорошо!). Соответственно, написать генератор кода по заданным шаблонам — пожалуйста.
Роман, верно ли я понимаю, что вы о названии статьи? Могли бы вы раскрыть содержание вашего комментария более подробно? С удовольствием выслушаю. // upd: превентивно изменил название, надеюсь, так будет более уместно.
Здравствуйте! Если вы про то что будущее за SPA — быть может, вы и правы, однако, в статье данный вопрос не затрагивается. А до тех пор, пока есть MPA — есть и Razor (и другие server-side шаблонизаторы). Готов побеседовать на данную тему не рамках данного поста, а, например, в личной беседе.
Добрый вечер, Леонид. Простите, что простые примеры ввели в заблуждение. Разумеется, в реальном проекте они всегда сложнее. Тем не менее, идеи, описанные в данной статье, ни в коей степени не являются исключительно «академическими» — всё это, напротив, получено и придумано в непосредственном процессе разработки.
Предлагаемая архитектура позволяет масштабироваться проекту (и, при необходимости, сужаться) при малых затратах благодаря малой связности компонентов системы.
Действительно, это выглядит как оверхед на примере в статье, но ведь контент рассчитан на читателей, которые уже столкнулись с данными проблемами, и была надежда, что сложные примерны ни к чему. Удачного вам остатка дня!
Алексей, тут необходимо определиться с понятием «альтернативная базисная функция». По той простой причине что функции в действительности являются разными, но имеют конечный набор одинаковых пар точек на плоскости. Надеюсь, это и подразумевалось.
В силу того, что расчет набора a,b,c,d… в зависимости от выбора функций находится за разное время (сравните логарифмическую и радикальную формы), то, разумеется, один быстрей, другой медленнее. Поэтому ваше предположение верно.
В конце статьи также приведен графический способ применения (можно также попробовать перенести алгоритм в трехмерное пространство).
Спасибо, поправил.
А это классический нейрослоп и есть...
Как автор утилиты dpi-ch констатирую: к сожалению, вы правы, в текущей статье нейрослоп❗
Среди прочего, никогда ключей --target / --mode / --timeout не было, это tui утилита с .yaml конфигом (и ключи там используются в очень ограниченном кол-ве). С одной стороны лестно, что написано о моем проекте, но нельзя с большим прискорбием не заметить, что сама статья выглядит как плод неких фантазий, не имеющих отношения к реальности (в т.ч. с точки зрения того, как работает утилита и как она выглядит). Неплохо бы модераторам отреагировать.
Далее, постараюсь ответить на другие ваши "варианты":
Такого нет, в минорных релизах не ломается обратная совместимость (а мажорный никогда ещё не увеличивался).
Такого также, к счастью, не наблюдается.
Очевидно это так, ибо с ключами из статьи (несуществующими) утилита просто уйдет в ошибку на старте. Причем такое поведение будет даже на самых старых версиях.
Не ошибаетесь.
По крайней мере, можно автоматизированно определить ОДЗ для параметров "anti-DPI" утилит, а далее (также, автоматизированно) перебрать оставшиеся варианты одновременно тестируя их через dpi-ch — и выбрать наиболее оптимальный.
Термин ТСПУ применим только в РФ (по большей части), репозиторий же рассчитан на международное использование. Напр., есть ещё Китай, Иран и т.д.
В общем смысле мы называем это интернет-цензурой, а актора – цензором. Но для массового пользователя термин DPI является более привычным и удобным, хоть и не совсем точно раскрывает смысл.
См. ответ на это замечание здесь.
На данной площадке затруднительно обсуждать что нам это "даст". Но, напр., понимание ситуации и диагностику средств обхода интернет-цензуры (исключительно в образовательных и/или исследовательских целях).
Да, это один из сценариев использования — автоматизация диагностики.
Гипотетически этого исключать нельзя, пользователи (см. соотв. warning в репозитории) сами несут за это ответственность.
Вероятность этого, на мой взгляд, минимальная. В т.ч., но не ограничиваясь, из-за того, что утилита dpi-ch мимикрирует под работу обычного браузера (использование utls и проч.). Мало того, обычно причины блокировки сервисов не связаны с их анализом пользователями.
Репозиторий рассчитан на международные утилиты и нацелен не только на домашние провайдеры (напр., можно тестировать дата-центр), т.е., в каких-то местах DPI может вовсе не быть. Однако, применительно к РФ — да, вы в целом правы.
Денис, а каким образом k8s, исходя из его предназначения, решает задачу отказоустойчивости точки входа в веб-сервис? Etcd можно использовать и там и там, — тут вы правы. Ну и что?
Роман, важно помнить, что Cloudflare в этот момент работал в штатном режиме ;)
Также речь не только об TextBoxFor, речь о любом контроле, который поддерживается стандартной реализацией HtmlHelper.
Однако, после ваших слов, ухожу на очередную итерацию, направленную на более подходящее название. Спасибо!
Чтобы искомый генератор «знал» о данных правилах, их нужно описать. Описать в формализованном и общем виде. А данная операция, на мой взгляд, едва ли менее трудоемкая, чем сразу написать соответствий DTO вручную (это и будет, в частности, манифест который требуется «на вход» генератору).
Однако, в действительности можно представить, что вы в используемой IDE графически выделяете нужные свойства в модели, нажимаете кнопку генерации и получается соответствующий DTO-класс, тогда неплохо.
С контроллером вообще все сложно (впрочем, CRUD функции можно сгенерировать в некотором общем виде для сущности, и сопутствующие сервисы тоже, тут вы правы).
Уверен, что это в любом случае задача IDE.
Если данный генератор кода будет универсальным в предельно общем смысле, то его настройка будет более сложна, чем механическое написание данного кода.
Это из той же серии (утрированно), что и написание некоторой универсальной системы в принципе.
// Когда-то я с товарищами задумал написать программный комплекс, эмпирически решающий подавляющее большинство типичных задач по ТВиМСу с помощью моделирования на основе входных данных, да так, чтобы любой неподготовленный человек сумел воспользоваться. Однако, на стадии прототипирования стало понятно, что настройка и формирование входных данных на комплекс — задача более трудоемкая, чем «по-быстрому» закодить это на том же Python'e и посмотреть результаты. Это впоследствии послужило большим уроком в аспекте универсальных подходов.
А вот шаблоны, гайдлайны — приветствую, ибо там действительно одно и тоже (и это хорошо!). Соответственно, написать генератор кода по заданным шаблонам — пожалуйста.
// upd: превентивно изменил название, надеюсь, так будет более уместно.
Предлагаемая архитектура позволяет масштабироваться проекту (и, при необходимости, сужаться) при малых затратах благодаря малой связности компонентов системы.
Действительно, это выглядит как оверхед на примере в статье, но ведь контент рассчитан на читателей, которые уже столкнулись с данными проблемами, и была надежда, что сложные примерны ни к чему. Удачного вам остатка дня!
Насколько можно судить, это SHA256.
Сегодня пробовал в метро, вместо телефона теперь хеш:
"msisdn":"f5618b8ef6e2c7cde6f674da5e6d485329aa026607175a624b8aee7b9a0de97e"
В силу того, что расчет набора a,b,c,d… в зависимости от выбора функций находится за разное время (сравните логарифмическую и радикальную формы), то, разумеется, один быстрей, другой медленнее. Поэтому ваше предположение верно.
В конце статьи также приведен графический способ применения (можно также попробовать перенести алгоритм в трехмерное пространство).