Не вижу проблемы слазить в историю. Мы же всегда достоверно знаем, что именно где сейчас стоит и как получить еще одну точно такую же сборку, не правда ли?
Представьте, что вы получаете отчёт об ошибках с вашей системы, находящейся в эксплуатации. Трассировка стека указывает на метод GetProductDetails и типом выброшенного исключения является NullReferenceException. Какой из шести возможных объектов с нулевой ссылкой стал причиной ошибки?
Неужели по номеру строки, с которой вылетело исключение, этого никак нельзя понять?
В аудитории лектор читает лекцию по математике трём студентам. Внезапно встает 5 человек и уходят. Лектор:
— Вот сейчас придут ещё двое, и вообще никого не останется.
Собственно, это те самые пресловутые буква и дух закона. Первое вполне алгоритмизируемо, второе — останется на откуп людей как минимум до изобретения настоящего ИИ.
Можно уточнить, какие именно два слова? Фамилия того самого Монти — «Питонов» (другое их самоназвание — Pythons), это то же самое слово, а не какое-то другое.
Несколько странный подход к тому, что в статье спрятать под спойлер, а что нет. Лично мне куда интереснее было прочитать, как оно устроено, а код я вообще прокрутил, не читая.
Я понимаю, что уязвима свежая ветка. Вопрос состоит в том, успели ли в той версии ognl, которая идет в комплекте с версиями нескольких лет давности добавить те возможности, которые вылились в эту уязвимость.
Все равно не очень. У вас же уже известны индексы, зачем передавать цвета в поиск, если вас интересует максимум среди индексов?
В вашем первом варианте в худшем случае (если чудесным образом не вмешается компилятор) будет четыре сравнения для трех элементов. Достаточно очевидно, что для нахождения максимума из N элементов достаточно N-1 сравнений. Так что да, пока пишете то, что пишете — надо.
Перерисовал, вроде почище стало.
Очень странные у них оценки, на самом деле. На ум приходит подгонка под красивые циферки: 150 и 95 в отрыве, 125 по нулям, кратных пяти гораздо больше, чем остальных. Насколько можно верить таким данным — большой вопрос.
2. Насколько я знаю, Quartz под капотом использует тот же таймер. Так что это вопрос только удобства API.
3. http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/scheduling/quartz/SchedulerFactoryBean.html#setQuartzProperties(java.util.Properties)
Неужели по номеру строки, с которой вылетело исключение, этого никак нельзя понять?
www.youtube.com/watch?v=5IfHm6R5le0
— Вот сейчас придут ещё двое, и вообще никого не останется.
Деньги на содержание подобного проекта откуда-то должны браться, не так ли?
В вашем первом варианте в худшем случае (если чудесным образом не вмешается компилятор) будет четыре сравнения для трех элементов. Достаточно очевидно, что для нахождения максимума из N элементов достаточно N-1 сравнений. Так что да, пока пишете то, что пишете — надо.
Очень странные у них оценки, на самом деле. На ум приходит подгонка под красивые циферки: 150 и 95 в отрыве, 125 по нулям, кратных пяти гораздо больше, чем остальных. Насколько можно верить таким данным — большой вопрос.