Да, в сумме, как не проектируй и какие патерны не применяй, количество вызовов методов практически не меняется. Ладно, убеждать вас ни в чем не буду.
И да, что такое legacy системы мне прекрасно знакомо, и как в них внедрять более современные правила проектирования тоже.
Если бы нашел 100400 мест, где используются getAllPayment, прибил бы архитектора. Шутка. Вызовы getAllPayment на 2 млн. entity, скорее всего могут должны использоваться только для задач интеграции, обслуживание БД и т.п. Если такой метод используется в обычных модулях это уже повод понять зачем.
Если есть куча мест где используется getPaymentByQuery(«name = ?»), то это повод выделить его в отдельный метод getPaymentByName, создать индекс по полю name, сделать тест производительности метода на реальной базе и т.д. Также для всех подобных методах, в результате большинство частых запросов можно будет выделить в отдельные методы. А дальше всегда можно использовать профайл и т.п. методики на отдельных методах. Метод getPaymentByQuery имеет смысл именно для действительно уникальных случаев и опять-таки ловится профайлером, логированием времени работы и т.п. методами
Ну, например что будет узнаете ли вы когда нибудь, что у вас используется в 100400 мест запросы вида «Payment.name = ?», но индекс по поля name вы сделать забыли, отчего вся ваша система дико тормозит? Ни один профайлер не сможет собрать такие запросы из 100400 мест, насколько я знаю.
Тут скорее всего имели в виду, если есть супер программа вычисляющая курсы валют для Форбса и значительная часть следует её указаниям, то с большой вероятностью даже совершенно случайные прогнозы будут сбываться.
Теперь нам не нужно искать вообще все Payment'ы, достаточно сделать поиск по getAllPayment и getPaymentByQuery и понять где программисты промахнулись. Крайне редко проблема будут в цикле с getPaymentById.
Но как узнать, где порождается такое большое количество объектов? Искать по коду? Не вариант, придется делать поиск по всей системе, а времени в обрез – заказчик уже весь синеет.
Я конечно извиняюсь, но вроде бы, поднятие общих бизнес сущностей выносят в отдельные классы, тогда и связность системы понизилась бы, поиск с модификацией кода работающего с entity стали куда проще, да и необходимость у программистов сто первый раз писать велосипед, вроде того поднятия entity не было бы. Плюс часто делают свои обертки над классами JPA'а, вроде entityManager'a, чтобы, например, было проще отлаживать и профилировать поднятие entity (на самом деле, так ещё куча других полезных вещей). Тогда не нужно было делать всех этих хаков с конструктором.
Не идеальный продукт, я имел в виду немного другое. Например, делал я как-то я во фрилансе некоторый парсер данных в один интернет магазин, сделал по-правильному, чтобы парсер висел, постоянно проверял обновление и допарсивал новые данные, а оказалось что заказчик вообще-то рассчитывал на одновременный перенос данных, а за доработку парсера, чтобы он мог обновлять данные, хотел заплатить ещё примерно столько же позже. В результате, я получил некий абстрактный плюс в «репутацию», но потерял в деньгах.
В большом бизнесе примерно также, подозреваю, что сделать не ломающиеся и не требующие расходников пылесосы возможно, но производители никогда на это не пойдут.
Да, сталкивался с ситуациями когда куча народа неделю и больше обсуждает и планирует функционал (причем каждый тянет в свою сторону), который за пару дней силами одного разработчика можно сделать, отладить, выкинуть, пару раз переписать и выдать уже готовый и отлаженный продукт, учитывающих косяки, которые никаким планированием не поймать. ИМХО, чрезмерное планирование, такое же зло, как и быдлокодирование без всякого плана.
Иногда, сделав изначально слишком хороший продукт даже за тоже время/деньги, есть риск в бизнесе проиграть. Идеальный продукт не глючит и его не нужно дорабатывать, следовательно заказчику нет смысла платить за сопровождение и доработки, следовательно можно потерять изрядную сумму от этого заказчика (правда получив некий плюс к репутации).
Статья интересная, но на мой взгляд автор все-таки уходит в другую крайность от тяп ляп и в продакт. Вспоминается эпизод в «автостопом по галактике», про разбившийся корабль менеджеров и рекламных агентов, где они бесконечно планировали и проводили совещания вместо того чтобы просто нарубить дров и собрать еду. Перепланирование, так же плохо как и попытка все решить наскоком.
Перефразируя Энштейна «объяснять надо просто настолько это возможно, но не проще», «разрабатывать надо быстро насколько это возможно, но не быстрее», в смысле скорость разработки должна быть максимальной, но только пока она не влияет на качество разработки.
Возникает чувство что все модели предсказывают одинаково плохо (а точнее вообще никак не предсказывают), просто для одной из моделей результаты случайно оказались более близки к реальности. Tbats, на мой взгляд, кстати в целом показывает картину лучше ARIMA, так как Tbats предсказывает падение, а ARIMA стабильность цены и цена на 6 день очень близка с реальностью (важен не столько график скачков, сколько тенденция прогноза). Увы, сложность экстрополяции на коротких промежутках в том что даже просто генерируя абсолютно случайные графики рано или поздно можно найти похожий на реальность, но это ничего не говорит о качестве модели, модель можно будет считать проверенной если она будет близка к реальности хотя в 2-3 разных временных промежутков.
Не сочтите за критику, но можно вопрос: А xlst преобразования в данном случае реально вам необходимы для задачи или просто для тренировки навыков и демонстрации xlst в статье? Просто я не заметил критичной причины, почему нельзя в данной задаче было сразу написать парсер в нужный формат xml, раз вы все равно уже парсер писали (и по сложности написания парсеры не сильно бы на мой взгляд отличались, но возможно я просто не увидел чего-то что нельзя сделать/или сложно сделать только с помощью парсера...). Но если вас интересовала именно тренировка работы с xlst, тогда вопрос снимается.
А смысл? Боты прекрасно умеют менять ип адреса, посылать каждый запрос с нового ип адреса вообще не проблема, учитывая кучу бесплатных прокси и весьма умеренные цены на платные.
Да, но на самом деле, имена пользователей ещё более предсказуемы, чем пароли, на мало-мальски крупном сайте можно гарантировано перебирать самые популярные имена и фамилии (olga, ivanov, petrov, olga1982 и т.д.), а так же основные популярные английские и русские прозвища, типа красава, cat. dog, mad dog и т.п. Плюс погуглив по сайту часто можно получить список пользователей (например, из ников авторов статей и комментариев). В целом, лучше рассчитывать что бот имена пользователей знает, даже если у вас сайт банка и каждего пользователя вы заставляете придумывать имя вроде dujhhj244.
А да, для полноты защиты, можно даже ограничить общее кол-во неправильных вводов пароля даже с капчей и потом требовать или восстановления пароля или ввода какой-то дополнительной информации. Например, если пользователь ввел даже с капчей 50 раз пароль неправильно, предложить ему восстановить пароль по email или ввести дату своего рождения/email/т.п. для дальнейших попыток ввода пароля.
Не уверен что это хорошая идея:
1) Пользователям быстро это надоест, например принудительно менять раз в месяц даже на рабочем компе пароль для меня было весьма утомительно
2) Есть пользователи, которые могут месяцами не логиниться (и соответственно не менять паролей),
Вообще, все украдено для нас. Самый простой и довольно эффективный алгоритм защиты от перебора такой:
1) Все-таки заставлять пользователей не использовать совсем уж легкие пароли,
2) Ограничить кол-во попыток логирования для пользователя и ипишника (отдельно для каждого user'a и отдельно с каждого ip'шника) определенным числом за N минут, например не более 5 неудачных попыток входа за 15 минут, после требовать ввода сложной капчи и давать ещё 5 попыток, если пользователь ввел её успешно (ввод любой капчи это ещё не гарантия что это не бот из-за трудолюбивых китайцев с их сервисами ручных распознаваний капч, но распознавание миллионов капч все-таки весьма дорогое занятие, чтобы оно имело смысл),
3) Ограничить общее время неудачных попыток за все время, то есть если пользователь даже в течении месяца ввел 20 раз пароль неправильно и не ввел ни разу правильный пароль, то при каждом следующем вводе, требовать капчу.
Это позволит ограничить как ботов, перебирающих пароли сразу, так и тех кто перебирает по-немногу. Правда, проблема все равно остается если пользователь заходить часто, а бот перебирает достаточно медленно, тогда есть шанс что пользователь будет успевать вводить правильный пароль чаще чем бот израсходует лимит неправильных. Тут есть несколько вариантов:
1) Анализировать соответствие правильных и неправильных пользователей, если ипшники и юзер агенты и включена ли js или нет, всех кто входит под правильным паролем и под неправильным никогда не совпадает, включаем для пользователя капчу при каждом входе,
2) другой вариант, при входе правильного пользователя выводить предупреждение с каких ип адресов, когда и сколько раз были попытки входить в систему и показывать кнопку «это был не я»
3) придумать что-то свое…
P.S. Если есть желание помучатся, можно порыть в сторону анализа таких вещей как включен ли у пользователя javascript (например, отдавая ему хитрую, сгенеренную каждый раз заново, функцию javascript, устанавливающую хитрые ключи в скрытые поля форм), правильные ли user agent'ы и работа с куками, нет ли следов работы с прокси или ипишников совсем отличных от предыдущих ипишников регистрации и успешных входов и т.п. Соответственно, для подозрительных пользователей, показывать капчу или раньше или вообще сразу при вводе пароля.
Основная проблема только в том что очень тупые боты будут непрерывно перебирать пароли одного пользователя без остановки. Дело в том что в большинство нормальных сервисов после некоторого кол-ва неправильных паролей в течении определенного времени у одного пользователя будет требовать не только пароль, но и вводить сложную капчу (а может вообще заблокировать данную запись и требовать восстановления через почту/телефон). Поэтому боты не перебирают пароли у одного пользователя, а ходят по всей базе данных пользователей (её на форуме или почтовом сервисе, например, можно получить вообще в открытом виде) и подставляют каждому пароль 123. Причем ходят, естественно, под разными ипшниками. На следующий день они пойдут по всем пользователем, но с паролем 1234 (на самом деле это утрировано, они могут случайно выбирать из списка легких паролей и подставлять каждому «свой» пароль и запоминать результат). Через месяц-другой у ботов будут все аккаунты с легкими паролями, причем ни разу они не натолкнуться на лимит по времени или ип адресу сервиса, так все запросы будут очень распределенные по времени и ип.адресам.
Только в теории, так как такой внешний код не сможет нормально работать с сущностями 1С, а даже гипотетически сложно представить ситуацию, когда в 1С потребуется миллиард итераций, работающих только с числами и строками и никак не использующий объекты самого 1С.
Плюс, мерить производительность циклов в высокоуровневых языках в большинстве случаев никакого смысла не имеет, так как один кривой запрос к базе данных или к сети, будет выполняться дольше любого практического числа итераций.
И да, что такое legacy системы мне прекрасно знакомо, и как в них внедрять более современные правила проектирования тоже.
Если есть куча мест где используется getPaymentByQuery(«name = ?»), то это повод выделить его в отдельный метод getPaymentByName, создать индекс по полю name, сделать тест производительности метода на реальной базе и т.д. Также для всех подобных методах, в результате большинство частых запросов можно будет выделить в отдельные методы. А дальше всегда можно использовать профайл и т.п. методики на отдельных методах. Метод getPaymentByQuery имеет смысл именно для действительно уникальных случаев и опять-таки ловится профайлером, логированием времени работы и т.п. методами
Ну, например что будет узнаете ли вы когда нибудь, что у вас используется в 100400 мест запросы вида «Payment.name = ?», но индекс по поля name вы сделать забыли, отчего вся ваша система дико тормозит? Ни один профайлер не сможет собрать такие запросы из 100400 мест, насколько я знаю.
Теперь нам не нужно искать вообще все Payment'ы, достаточно сделать поиск по getAllPayment и getPaymentByQuery и понять где программисты промахнулись. Крайне редко проблема будут в цикле с getPaymentById.
Я конечно извиняюсь, но вроде бы, поднятие общих бизнес сущностей выносят в отдельные классы, тогда и связность системы понизилась бы, поиск с модификацией кода работающего с entity стали куда проще, да и необходимость у программистов сто первый раз писать велосипед, вроде того поднятия entity не было бы. Плюс часто делают свои обертки над классами JPA'а, вроде entityManager'a, чтобы, например, было проще отлаживать и профилировать поднятие entity (на самом деле, так ещё куча других полезных вещей). Тогда не нужно было делать всех этих хаков с конструктором.
В большом бизнесе примерно также, подозреваю, что сделать не ломающиеся и не требующие расходников пылесосы возможно, но производители никогда на это не пойдут.
Перефразируя Энштейна «объяснять надо просто настолько это возможно, но не проще», «разрабатывать надо быстро насколько это возможно, но не быстрее», в смысле скорость разработки должна быть максимальной, но только пока она не влияет на качество разработки.
1) Пользователям быстро это надоест, например принудительно менять раз в месяц даже на рабочем компе пароль для меня было весьма утомительно
2) Есть пользователи, которые могут месяцами не логиниться (и соответственно не менять паролей),
Вообще, все украдено для нас. Самый простой и довольно эффективный алгоритм защиты от перебора такой:
1) Все-таки заставлять пользователей не использовать совсем уж легкие пароли,
2) Ограничить кол-во попыток логирования для пользователя и ипишника (отдельно для каждого user'a и отдельно с каждого ip'шника) определенным числом за N минут, например не более 5 неудачных попыток входа за 15 минут, после требовать ввода сложной капчи и давать ещё 5 попыток, если пользователь ввел её успешно (ввод любой капчи это ещё не гарантия что это не бот из-за трудолюбивых китайцев с их сервисами ручных распознаваний капч, но распознавание миллионов капч все-таки весьма дорогое занятие, чтобы оно имело смысл),
3) Ограничить общее время неудачных попыток за все время, то есть если пользователь даже в течении месяца ввел 20 раз пароль неправильно и не ввел ни разу правильный пароль, то при каждом следующем вводе, требовать капчу.
Это позволит ограничить как ботов, перебирающих пароли сразу, так и тех кто перебирает по-немногу. Правда, проблема все равно остается если пользователь заходить часто, а бот перебирает достаточно медленно, тогда есть шанс что пользователь будет успевать вводить правильный пароль чаще чем бот израсходует лимит неправильных. Тут есть несколько вариантов:
1) Анализировать соответствие правильных и неправильных пользователей, если ипшники и юзер агенты и включена ли js или нет, всех кто входит под правильным паролем и под неправильным никогда не совпадает, включаем для пользователя капчу при каждом входе,
2) другой вариант, при входе правильного пользователя выводить предупреждение с каких ип адресов, когда и сколько раз были попытки входить в систему и показывать кнопку «это был не я»
3) придумать что-то свое…
P.S. Если есть желание помучатся, можно порыть в сторону анализа таких вещей как включен ли у пользователя javascript (например, отдавая ему хитрую, сгенеренную каждый раз заново, функцию javascript, устанавливающую хитрые ключи в скрытые поля форм), правильные ли user agent'ы и работа с куками, нет ли следов работы с прокси или ипишников совсем отличных от предыдущих ипишников регистрации и успешных входов и т.п. Соответственно, для подозрительных пользователей, показывать капчу или раньше или вообще сразу при вводе пароля.
Плюс, мерить производительность циклов в высокоуровневых языках в большинстве случаев никакого смысла не имеет, так как один кривой запрос к базе данных или к сети, будет выполняться дольше любого практического числа итераций.
Скажем, в java, код:
for (MyClass obj: collection)
{
obj.prop = 1;
}
работает прекрасно. В C# тоже, должен работать.