Денис, а каким образом 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… в зависимости от выбора функций находится за разное время (сравните логарифмическую и радикальную формы), то, разумеется, один быстрей, другой медленнее. Поэтому ваше предположение верно.
В конце статьи также приведен графический способ применения (можно также попробовать перенести алгоритм в трехмерное пространство).
Спасибо, поправил. Причина ошибки кроется в том, что изначально я хотел использовать традиционные для подобных схем имена (Боб и Алиса), но в последствии решение перевесило в сторону более «русских» имен.
Денис, а каким образом k8s, исходя из его предназначения, решает задачу отказоустойчивости точки входа в веб-сервис? Etcd можно использовать и там и там, — тут вы правы. Ну и что?
Роман, важно помнить, что Cloudflare в этот момент работал в штатном режиме ;)
Также речь не только об TextBoxFor, речь о любом контроле, который поддерживается стандартной реализацией HtmlHelper.
Однако, после ваших слов, ухожу на очередную итерацию, направленную на более подходящее название. Спасибо!
Чтобы искомый генератор «знал» о данных правилах, их нужно описать. Описать в формализованном и общем виде. А данная операция, на мой взгляд, едва ли менее трудоемкая, чем сразу написать соответствий DTO вручную (это и будет, в частности, манифест который требуется «на вход» генератору).
Однако, в действительности можно представить, что вы в используемой IDE графически выделяете нужные свойства в модели, нажимаете кнопку генерации и получается соответствующий DTO-класс, тогда неплохо.
С контроллером вообще все сложно (впрочем, CRUD функции можно сгенерировать в некотором общем виде для сущности, и сопутствующие сервисы тоже, тут вы правы).
Уверен, что это в любом случае задача IDE.
Если данный генератор кода будет универсальным в предельно общем смысле, то его настройка будет более сложна, чем механическое написание данного кода.
Это из той же серии (утрированно), что и написание некоторой универсальной системы в принципе.
// Когда-то я с товарищами задумал написать программный комплекс, эмпирически решающий подавляющее большинство типичных задач по ТВиМСу с помощью моделирования на основе входных данных, да так, чтобы любой неподготовленный человек сумел воспользоваться. Однако, на стадии прототипирования стало понятно, что настройка и формирование входных данных на комплекс — задача более трудоемкая, чем «по-быстрому» закодить это на том же Python'e и посмотреть результаты. Это впоследствии послужило большим уроком в аспекте универсальных подходов.
А вот шаблоны, гайдлайны — приветствую, ибо там действительно одно и тоже (и это хорошо!). Соответственно, написать генератор кода по заданным шаблонам — пожалуйста.
// upd: превентивно изменил название, надеюсь, так будет более уместно.
Предлагаемая архитектура позволяет масштабироваться проекту (и, при необходимости, сужаться) при малых затратах благодаря малой связности компонентов системы.
Действительно, это выглядит как оверхед на примере в статье, но ведь контент рассчитан на читателей, которые уже столкнулись с данными проблемами, и была надежда, что сложные примерны ни к чему. Удачного вам остатка дня!
Насколько можно судить, это SHA256.
Сегодня пробовал в метро, вместо телефона теперь хеш:
"msisdn":"f5618b8ef6e2c7cde6f674da5e6d485329aa026607175a624b8aee7b9a0de97e"
В силу того, что расчет набора a,b,c,d… в зависимости от выбора функций находится за разное время (сравните логарифмическую и радикальную формы), то, разумеется, один быстрей, другой медленнее. Поэтому ваше предположение верно.
В конце статьи также приведен графический способ применения (можно также попробовать перенести алгоритм в трехмерное пространство).
Следите за новостями в группе во «ВКонтакте» — vk.com/rmsweeper