Работаю с Blazor уже некоторое время. Пишем backend на asp.NET MVC, Core. На frontend используем jQuery, React.js, Vue.js. Могу всем кто пишет backend на asp.NET рекомендовать ознакомление с Blazor. Это совсем другой подход и поначалу кажется фантастикой.
>> Типа, если вы будете изучать технологии А, Б, В, то никогда не изучите технологию А также глубоко, как человек, который изучает только технологию А.
Вот с этим абсолютно согласен. Уверен, что множество разработчиков в принципе никогда не станут Senior разработчиками даже если будут изучать хоть всю жизнь одну технологию.
Любите вы поспорить. :)
При решении любой задачи можно использовать различные подходы. Можно использовать решение проверенное временем от профессионалов (например, реализация триггеров Oracle Database), а можно взять и реализовать их самостоятельно. Можно и Web-серверы и СУБД реализовывать самостоятельно.
Грамотней означает, что для каждой задачи нужно применять тот инструмент, который для нее наиболее подходит, а не пытаться писать свой велосипед для любой задачи.
>> Любой триггер можно реализовать программно вне СУБД. Естественно будут потери.
Насколько я понял статья именно об этом. Что люди которые считают себя всемогущими FullStack разработчиками в большинстве случаев просто не знают, что данную задачу (например, триггер) грамотнее реализовать при помощи СУБД, а не «программно» наступая на все грабли. Или я неправильно понял суть статьи?
В таком случае нужно понимать что такое FullStack разработчик. В моем понимании это разработчик, который способен написать приложение от и до без посторонней помощи. А не так, что если нужны триггеры, то я уже не FullStack разработчик.
Мало чего принципиально нового. В статье указан интерфейс Сбербанка, но уже несколько лет, как он обновлен и теперь он много лучше. Например, вот вам принципиально новая идея: клиент с телефона выбирает банкомат и выбирает действие (например, снять 1500 рублей банкнотами по 500 + 10 * 100) вставляет карту в банкомат и тот уже знает чего он хочет и сразу ему предлагает это сделать.
В языках программирования var нужен не столько для того, чтобы просто укоротить запись, а скорее для ситуаций когда невозможно (на этапе написания кода) определить какого типа будет результирующий объект.
Например, при использовании LINQ на языке C#: int[] arr = new int[] { 1, 2, 3, 4, 5 };
var result = arr.Select(x => new { x, mod2 = x % 2 }).ToArray();
Так как при проецирование используется анонимный класс, то на момент написания кода нет возможности определить какого типа вернется объект. Это будет массив классов, но имена этим классам будут присвоены лишь на момент компиляции.
>> можно было бы наносить разметку краской, отражающей радиоволны.
Можно. Но также легко представить себе недовольного своей жизнью школьника, который по ночам будет вам такую разметку рисовать. Посмотрите на стены, которые изрисованы граффити. Мы не в идеальном обществе живем.
>> Что если пользователь ошибется в одном символе, и зайдет под другой учеткой?
Я так понимаю, что автор идеи надеется, что сознательный пользователь выйдет и больше так делать не будет. ;)
Криптографическая стойкость при этом пострадает. Любое упрощение аутентификации не должно приводить к дырам в безопасности. Если вы уж решили ограничиться только паролем, то хотя бы его надо хранить грамотно.
>> И для хеша это простейший запрос к бд, разве что строка для проверки длиннее.
Это не так. Если пароли хранятся стандартно т. е. в хеше и с солью различной для каждой строки, то каким запросом вы проверите, что нового пароля еще нет в БД? Вам придется сгенерировать хеши для всех строк и выполнить сравнение с новой строкой. Это совсем другая сложность.
>> пароль генерируем сами, уникальным
Вам за это не один пользователь спасибо не скажет. Например, видели какие сейчас имена электронных адресов автоматически предлагают Яндекс, Google? А мы тут вроде как про удобство.
>> водит свой пароль, берем от него хеш (с солью)
Вот тут то и проблема. Соль то у каждого своя. Вам придется сгенерировать столько хешей, сколько пользователей на вашем ресурсе. И хорошо если их 2, а если их 10 000… А это уже практически готовая атака на ваш ресурс.
>> если они настолько просты, что совпадают
Вопрос скорее в том, как вы будете проверять, что пароли у всех пользователей различны? Для логина, который хранится в открытом виде это простейший запрос к БД, а вот для паролей, которые принято хранить хешем с солью это задача резко усложняется.
>> мы рассчитываем и фиксируем стоимость поездки сразу
За это вам конечно спасибо. Но обычные таксисты фиксировали стоимость до поездки всегда т.е. тут вы их мало чем превзошли.
>> рассчитана с повышающим коэффициентом — он срабатывает в те моменты,
И как раз вот эти коэффициенты спрогнозировать практически невозможно т. е. нельзя знать стоимость заказа хотя бы за полчаса.
Вот с этим абсолютно согласен. Уверен, что множество разработчиков в принципе никогда не станут Senior разработчиками даже если будут изучать хоть всю жизнь одну технологию.
При решении любой задачи можно использовать различные подходы. Можно использовать решение проверенное временем от профессионалов (например, реализация триггеров Oracle Database), а можно взять и реализовать их самостоятельно. Можно и Web-серверы и СУБД реализовывать самостоятельно.
Насколько я понял статья именно об этом. Что люди которые считают себя всемогущими FullStack разработчиками в большинстве случаев просто не знают, что данную задачу (например, триггер) грамотнее реализовать при помощи СУБД, а не «программно» наступая на все грабли. Или я неправильно понял суть статьи?
Например, при использовании LINQ на языке C#:
int[] arr = new int[] { 1, 2, 3, 4, 5 };var result = arr.Select(x => new { x, mod2 = x % 2 }).ToArray();
Так как при проецирование используется анонимный класс, то на момент написания кода нет возможности определить какого типа вернется объект. Это будет массив классов, но имена этим классам будут присвоены лишь на момент компиляции.
Можно. Но также легко представить себе недовольного своей жизнью школьника, который по ночам будет вам такую разметку рисовать. Посмотрите на стены, которые изрисованы граффити. Мы не в идеальном обществе живем.
Я так понимаю, что автор идеи надеется, что сознательный пользователь выйдет и больше так делать не будет. ;)
Вы совсем не любите своих пользователей.
Это не так. Если пароли хранятся стандартно т. е. в хеше и с солью различной для каждой строки, то каким запросом вы проверите, что нового пароля еще нет в БД? Вам придется сгенерировать хеши для всех строк и выполнить сравнение с новой строкой. Это совсем другая сложность.
Вам за это не один пользователь спасибо не скажет. Например, видели какие сейчас имена электронных адресов автоматически предлагают Яндекс, Google? А мы тут вроде как про удобство.
Вот тут то и проблема. Соль то у каждого своя. Вам придется сгенерировать столько хешей, сколько пользователей на вашем ресурсе. И хорошо если их 2, а если их 10 000… А это уже практически готовая атака на ваш ресурс.
Вопрос скорее в том, как вы будете проверять, что пароли у всех пользователей различны? Для логина, который хранится в открытом виде это простейший запрос к БД, а вот для паролей, которые принято хранить хешем с солью это задача резко усложняется.
За это вам конечно спасибо. Но обычные таксисты фиксировали стоимость до поездки всегда т.е. тут вы их мало чем превзошли.
>> рассчитана с повышающим коэффициентом — он срабатывает в те моменты,
И как раз вот эти коэффициенты спрогнозировать практически невозможно т. е. нельзя знать стоимость заказа хотя бы за полчаса.