Атака нахождения второго прообраза фокусируется на том, чтобы найти сообщение, которое даёт тот же хеш, что и уже известное сообщение.
При коллизии же, если как намеренную атаку ее представлять - атакующий пытается найти любые два разных сообщения, которые дают одинаковый хеш, но у него нет конкретного сообщения заранее
Как так, не понимаю почему при том же процессе входа через QR-код нельзя проверять вводимые данные на SQL-инъекции ? Нужно какое-то исследование почему люди допускают такие очевидные ошибки, он же не глупые коль уже стали разработчиками ...
От ваших статей идет приятная и грустная ностальгия, но в моем случае, не в самое сердечко, так как в те самые юные и светлые дни я использовал Symbian, а именно в 2008-2011 года. Если к такой, давно забытой, OC вы вернетесь, и если какое-то ПО для нее будете писать, это вообще нечто будет.
А что вы скажите на счет того подхода к взаимодействию с базой данных, что реализовано библиотекой JOOQ, которая позиционирует себя как то, что избавляет от ORM проблем, а так же избавляет от проблем использования простого SQL. Это, конечно, библиотека из мира Java разработки, но все же это та же некоторая альтернатива "Object-Relational Mapping", хоть и в строго типизированном языке, я понимаю, есть другие проблемы и решения.
Можно поинтересоваться, почему именно так ? Почему не через то же дополнение для генерации кода - DDLDatabase, который я описал выше ? Может в тот момент когда вы столкнулись с этим, еще не было реализовано данное дополнение или вы считаете, что использовать реальную базу, на которую вы накатили самостоятельно скрипты лучше чем просто относительно скриптов ?
Просто есть разные способы генерации кода и один из них это с помощью DDL на основе скриптов миграции, к примеру Flyway или Liquibase, вот тут в документации можете ознакомится. То есть в вашем случае получается вы делаете лишнюю работу тем что поднимаете тест контейнер вместо того что бы сразу, относительно DDL скриптов, генерировать классы. Хотя и ваш способ имеет место быть.
«table first» подразумевается что база данных с таблицами должна существовать на момент генерации классов или вообще в принципе необходима для старта разработки ? Или можете, пожалуйста, конкретнее описать, я отмечу это в следующей статье.
Так же хочется отметить, что я описал проблемы которые встают перед разработчиками когда они активно используют наследование, те же не поддерживаемые методы из реализации `List.of` и тд.
https://habr.com/ru/articles/325478/ В данной статье ознакомился с "Composition over inheritance", в общем смысле понимаю проблему, и к чему нас призывает сам термин, но даже в этой статье упоминается:
Наследуем, если:
Наследник является корректным подтипом (в терминах LSP — прим. пер.) предка
А вы как можете убедится, Шаблонный метод я упомянул вместе с LSP
Спасибо за ваш анализ, приятно было ознакомится. Решил так же прокомментировать некоторые части.
И это приводит к разрастанию очень и очень маленьких классов (буквально по одному методу), а потому становится очень сложно понять, что же происходит
....
И, в целом, идея даже правильная, вот только даже List, приведенный в пример выше, уже нарушает этот принцип. Собственно, если честно следовать этой логики, то у каждого интерфейса должен быть строго один метод, иначе можно быстро найти пример, когда код нарушает правило.
Не могу согласиться потому что, как я понимаю, SPR не требует от нас ограничиваться одним методом, он лишь призывает к тому что бы класс, а именно его состояние и поведение, были ограничены одной зоной ответственности, и о том что бы это выражалось в виде одно метода - речи нет. Думаю DDD тут ближе всех с логической стороны может описать данный принцип.
Если исключить самые-самые простые примеры, это принцип не работает даже в небольших проектах. Несмотря на то, что интерфейс к базе может быть общий, синтаксис запросов будет очень разным (как пример). Несмотря на то, что существует интерфейс List в Java (IList в .Net), в реальной программе всё-таки требуется знать, изменяемый объект или нет, это ArrayList или LinkedList и так далее. Аналогично про интерфейс Map (это может быть и хеш таблица, и дерево).
Может я не правильно понял смысл "реальная программа", но да, нам как программистам важно какой мы реализуем список или мапу для той или иной задачи когда пишем код или закладываем логику, но уже потом когда мы используем те или иные библиотеки или код коллег, они ожидают одинаковой логики от этих абстракций, и в большинстве случаев получают ее.
Не совсем. Если меняются сигнатуры, то это запросто повлечет изменения в куче мест. Более того, тут используется термин "класс родитель", а потому можно предположить, что предлагается делать наследование. Если так, то добавление нового аргумента в конструктор базового класса поменяет вообще все классы наследники.
Тут согласен, сигнатуры это, в некотором роде, Ахиллесова пята.
На самом деле, основной совет должен быть "код должен легко поддерживать изменения в рамках ответственности проекта".
И в итоге хочется отметить, что да, это верно, но слишком размыто, по моему мнению SOLID принципы и подталкивают нас именно к этому. Согласен что и они так же размыты, но не настолько и, главное, они более всех ближе к той границе где за гранью хороших практик и все возможных общих советов уже идет сугубо индивидуальные задачи, с такими же индивидуальными подходами к решению.
Да, точно, спасибо за замечание!
Атака нахождения второго прообраза фокусируется на том, чтобы найти сообщение, которое даёт тот же хеш, что и уже известное сообщение.
При коллизии же, если как намеренную атаку ее представлять - атакующий пытается найти любые два разных сообщения, которые дают одинаковый хеш, но у него нет конкретного сообщения заранее
Как так, не понимаю почему при том же процессе входа через QR-код нельзя проверять вводимые данные на SQL-инъекции ? Нужно какое-то исследование почему люди допускают такие очевидные ошибки, он же не глупые коль уже стали разработчиками ...
Ну мне понравился проект TextToVideo.Bot, не знаю на сколько это уже заезженно, но все равно круто, интересно что там по капотом.
От ваших статей идет приятная и грустная ностальгия, но в моем случае, не в самое сердечко, так как в те самые юные и светлые дни я использовал Symbian, а именно в 2008-2011 года. Если к такой, давно забытой, OC вы вернетесь, и если какое-то ПО для нее будете писать, это вообще нечто будет.
Я один ждал человека с длиной палкой и с злыми намерениями ? Его точно там не хватало....
Как я понял, это все Android и получается вы разрабатывали клиент используя Java ? Среда разработки у вас Android Studio или Eclipse ?
А что вы скажите на счет того подхода к взаимодействию с базой данных, что реализовано библиотекой JOOQ, которая позиционирует себя как то, что избавляет от ORM проблем, а так же избавляет от проблем использования простого SQL. Это, конечно, библиотека из мира Java разработки, но все же это та же некоторая альтернатива "Object-Relational Mapping", хоть и в строго типизированном языке, я понимаю, есть другие проблемы и решения.
решил разузнать о чем это вы - спасибо, сегодняшний день прожит не зря.
Как там говорится: не кладите все яйца в одну корзину…
да, вы правы
Можно поинтересоваться, почему именно так ? Почему не через то же дополнение для генерации кода - DDLDatabase, который я описал выше ? Может в тот момент когда вы столкнулись с этим, еще не было реализовано данное дополнение или вы считаете, что использовать реальную базу, на которую вы накатили самостоятельно скрипты лучше чем просто относительно скриптов ?
Просто есть разные способы генерации кода и один из них это с помощью DDL на основе скриптов миграции, к примеру
FlywayилиLiquibase, вот тут в документации можете ознакомится. То есть в вашем случае получается вы делаете лишнюю работу тем что поднимаете тест контейнер вместо того что бы сразу, относительно DDL скриптов, генерировать классы. Хотя и ваш способ имеет место быть.«table first» подразумевается что база данных с таблицами должна существовать на момент генерации классов или вообще в принципе необходима для старта разработки ? Или можете, пожалуйста, конкретнее описать, я отмечу это в следующей статье.
Какой генератор кода вы используете ? Может есть то что было удобно в JPA и чего нет в JOOQ ?
Так же хочется отметить, что я описал проблемы которые встают перед разработчиками когда они активно используют наследование, те же не поддерживаемые методы из реализации `List.of` и тд.
https://habr.com/ru/articles/325478/
В данной статье ознакомился с "Composition over inheritance", в общем смысле понимаю проблему, и к чему нас призывает сам термин, но даже в этой статье упоминается:
А вы как можете убедится, Шаблонный метод я упомянул вместе с LSP
...
Я с вами отчасти согласен, и я свою статью начал и закончил похожими тейками.
Спасибо за ваш анализ, приятно было ознакомится. Решил так же прокомментировать некоторые части.
....
Не могу согласиться потому что, как я понимаю, SPR не требует от нас ограничиваться одним методом, он лишь призывает к тому что бы класс, а именно его состояние и поведение, были ограничены одной зоной ответственности, и о том что бы это выражалось в виде одно метода - речи нет. Думаю DDD тут ближе всех с логической стороны может описать данный принцип.
Может я не правильно понял смысл "реальная программа", но да, нам как программистам важно какой мы реализуем список или мапу для той или иной задачи когда пишем код или закладываем логику, но уже потом когда мы используем те или иные библиотеки или код коллег, они ожидают одинаковой логики от этих абстракций, и в большинстве случаев получают ее.
Тут согласен, сигнатуры это, в некотором роде, Ахиллесова пята.
И в итоге хочется отметить, что да, это верно, но слишком размыто, по моему мнению SOLID принципы и подталкивают нас именно к этому. Согласен что и они так же размыты, но не настолько и, главное, они более всех ближе к той границе где за гранью хороших практик и все возможных общих советов уже идет сугубо индивидуальные задачи, с такими же индивидуальными подходами к решению.
Спасибо за вашу работу! О таких вещах стоит знать и помнить, пусть и на своей работе мы плотно сидим в mvc.