>> К сожалению, для новых полей я не вижу возможности убрать программирование.
Согласен. Но программировать можно по-разному. Высока вероятность, что программировать придётся не на C# или Java. Надо пригляделся к неявным способам программирования вне этих языков, но в контексте файла docx. Если это возможно, то разработка шаблонов вполне выйдет на новый уровень. И кто первый догадается, то неожиданно может получить большой профит, т.к. всем нужно использовать свои шаблоны, а не те, что может осилить только программист и тем более не хочется вообще зависеть от программиста.
Вот простой пример по аналогии. Тестирование сайта, закрытого аутентификацией. Можно запариться и долго настраивать систему тестирования на прохождение разных видов аутентификации. А можно прогонять все запросы через fiddler, который будет просто подставлять авторизованные куки (три строчки кода в его панели JavaScript).
Статья весьма слабовата, т.к. её нельзя использовать как руководство. Если я уже знаком с сервлетами, то эта статья мне просто освежит память, но как руководство по нему нельзя ничего сделать не только чайнику, но и более опытному программисту, т.к. требуется выбрать и настроить контейнер сервлетов, о чем в статье ни слова. Надо было в привязке к контейнеру написать хотя бы.
Простите, но мне лично контроль даже в хранимых процедурах кажется всё равно не эффективным, но дело не в производительности, а в том, что результат выполнения запросов известен только после их выполнения. Независимо от того, что выполнялось. В этом кроется дилемма безопасности. Если говорить прямо, то сегодня уровень безопасности обеспечивает не саму безопасность, а доступ на выполнение той или иной конструкции запроса. Например, если вы хотите удалить одну запись, а в результате удаляется 100, то вопрос к кому? К системе безопасности или к разработчику выполнимой процедуры? Понятно, что все запросы тестируются до попадания в продакшен, но по факту один разработчик должен доверяться другому и не может сам что-то настроить.
Я бы для себя поставил задачу безопасности по другому. Например:
1. Открыть транзакцию.
2. до выполнения запроса на удаления «выставил» в программе атрибут1=таблица1, процедура=удаление, количество записей=1.
3. Запуск запроса.
4. Проверка, что действительно из таблицы 1 было именно удалена запись в количестве именно 1шт. Если в результате выполнения процедуры произошло удаление больше одной записи или произошли изменения в других таблицах, то выполнить rollback, иначе — commit.
Вот теперь у программиста backend-а есть контроль над разработчиком БД. Класс! Вот такая система безопасности является именно безопасностью, а не системой распределения прав доступа. Вдруг разработчик БД «немного» накосячил и что-то упустил, ну так такая система безопасности не даст ему произвести действия, которые не планировал разработчик backend-а.
Но о такой системе я ещё не слышал )))
Простите за непрошеный совет. Поделюсь опытом, чтобы сократить вам время на изучение. Фреймворки не делают что-то такого, что не умеете делать вы. Просто каждый фреймворк заточен под конкретную задачу или класс задач. Если вы понимаете под что заточен фреймворк, то задайте себе вопрос, а как бы эту задачу решили бы вы? Удивитесь, но с таким подходом через некоторое время вы будете наперёд знать что должно быть во фреймворке и просто искать в нём соответствующие разделы. Конечно, не всегда ваше мнение будет соответствовать мнению разработчика в реализации, но архитектурные части вполне могут совпасть.
Насколько я знаю, Spring достаточно большой фреймворк. Брался одно время за его изучение года 4 назад. И знаете что? Так и не пригодился )))
Да в общем-то какая разница, через сколько лет смотреть? Обычно разработчик с головой выбирает стек в котором живёт, постепенно улучшая его. Невозможно сделать всё на одном языке. В конце концов рулят всем грамотные интерфейсы, нормальная безопасность и живучая архитектура. Любому разработчику через N лет это становится понятным и лучше перестать искать вокруг себя идеальный язык и понять, что программирование происходит в голове, а не на каком-то языке.
но Node даёт универсальную платформу с экосистемой в полмиллиона пакетов
Учитывая то, что JVM это не только для Java, но и для других языков ( https://en.m.wikipedia.org/wiki/List_of_JVM_languages ), например тот же JavaScript, то интеграция многих JavaScript-овых библиотек позволяет использовать JVM вместо node.js достаточно широко. Спасибо node.js за пакеты ))) Хотелось бы увидеть что-то подобное в node.js
Но в этом продолжении нет выхода из map в любой момент времени. Я легко выдумываю условие выхода — если текущее время больше 14:00:00 (часы: мин: сек), то выйти из цикла. Все фильтры летят в мусорную корзину, потому что если в работе обход массива занимает 10 сек и я запущу фильтр в 13:59:45, то в конечный массив попадут все элементы массива. Затем я запускаю перебор в 13:59:59 и получаю полный перебор массива до 14:00:09, хотя он должен был остановиться в 14:00:00 по break.
т.е. в for фильтр был не нужен, теперь в статье предлагается похоронить for и использовать вместо него map, но вот загвоздка — как жить без фильтра, которого в for не было?
Думаю, что вполне можно было бы ограничиться сведениями, в которых map хорош и удобнее, чем for, но в задачах определённого класса, в которых конструкция for достаточно громоздка.
Мне вот не очень понятно, зачем вводить map в стандарт, когда эту функцию можно написать в прототип массива и без всяких стандартов и выглядеть она будет точно так же?
Согласен. Но программировать можно по-разному. Высока вероятность, что программировать придётся не на C# или Java. Надо пригляделся к неявным способам программирования вне этих языков, но в контексте файла docx. Если это возможно, то разработка шаблонов вполне выйдет на новый уровень. И кто первый догадается, то неожиданно может получить большой профит, т.к. всем нужно использовать свои шаблоны, а не те, что может осилить только программист и тем более не хочется вообще зависеть от программиста.
Вот простой пример по аналогии. Тестирование сайта, закрытого аутентификацией. Можно запариться и долго настраивать систему тестирования на прохождение разных видов аутентификации. А можно прогонять все запросы через fiddler, который будет просто подставлять авторизованные куки (три строчки кода в его панели JavaScript).
Я бы для себя поставил задачу безопасности по другому. Например:
1. Открыть транзакцию.
2. до выполнения запроса на удаления «выставил» в программе атрибут1=таблица1, процедура=удаление, количество записей=1.
3. Запуск запроса.
4. Проверка, что действительно из таблицы 1 было именно удалена запись в количестве именно 1шт. Если в результате выполнения процедуры произошло удаление больше одной записи или произошли изменения в других таблицах, то выполнить rollback, иначе — commit.
Вот теперь у программиста backend-а есть контроль над разработчиком БД. Класс! Вот такая система безопасности является именно безопасностью, а не системой распределения прав доступа. Вдруг разработчик БД «немного» накосячил и что-то упустил, ну так такая система безопасности не даст ему произвести действия, которые не планировал разработчик backend-а.
Но о такой системе я ещё не слышал )))
Насколько я знаю, Spring достаточно большой фреймворк. Брался одно время за его изучение года 4 назад. И знаете что? Так и не пригодился )))
Зачем проводить Code Review для сотрировки методом пузырька? И так сойдёт!
Учитывая то, что JVM это не только для Java, но и для других языков ( https://en.m.wikipedia.org/wiki/List_of_JVM_languages ), например тот же JavaScript, то интеграция многих JavaScript-овых библиотек позволяет использовать JVM вместо node.js достаточно широко. Спасибо node.js за пакеты ))) Хотелось бы увидеть что-то подобное в node.js
А ведь есть ещё разработчики.
Думаю, что вполне можно было бы ограничиться сведениями, в которых map хорош и удобнее, чем for, но в задачах определённого класса, в которых конструкция for достаточно громоздка.
Мне вот не очень понятно, зачем вводить map в стандарт, когда эту функцию можно написать в прототип массива и без всяких стандартов и выглядеть она будет точно так же?