>>который улучшит доступность контента на территории России
Позволю себе в очередной раз напомнить, что граждане России (и Украины) до сих пор не имеют возможности использовать Azure. Следовательно, ни о каком «улучшении доступности» речи быть не может.
Кстати, а почему до сих пор «нельзя»? Неужели вы думаете что в России будет столько желающих, что мощностей не хватит? Решили бы этот вопрос, а то получается только дразните.
>>Вы ж не будете после каждой операции делать Math.round(amount * 100.0) / 100.0;
Ну у меня свой простенький тип Amount с хранением в double. Там хранится сумма с округлением до копейки.
Вообще округление нужно только для сравнения — иначе окажется что 1.01 руб не равно 1.0100000001 руб.
>>При суммировании скажем 1000 чисел это может оказаться вполне заметным.
Точность double, если память не изменяет — около 13 десятичных знаков? Если числа большие, то могут возникнуть проблемы, согласен. Но я прикинул — пока точности даже в 10 знаков для моих задач хватит. Если произойдет гипер-инфляция — последую вашему совету и задействую BigDecimal.
1. Позвольте уточнить какая именно информация «не правильная»? То что инстанции Azure крутятся на одной из модификаций Win 2008 R2? Я лично проверял (когда еще был тестовый аккаунт) — ось Win 2008 R2 (возможно модифицированная).
2. А как же без этого. Но это не является чем-то особенным. Если вы расскажите о практических преимуществах в сравнении с конкурентами — тогда послушаем.
3. А где я сказал что плохая репутация? Имхо, у Windows 2008 R2 — хорошая репутация. Но эта ось является объектом атак (она используется многими и есть возможность и смысл экспериментировать). Или вы хотите сказать что модифицированная версия (которую модифицировали для Azure) более защищенная?
Кстати, Amazon S3, EC2 and VPC ISO 27001 certified. Чем Azure лучше? Что нового? В чем фишка?
И сама Windows, если я не ошибаюсь, так-же имеет сертификации подобного уровня. Верно? Все мы понимаем что это маркетинговые фишки, которые, по сути, ничего не гарантируют.
Вас интересует что-то типа ISO/IESIS 27001-2005? Об этом ничего не знаю.
Скажу с практической точки зрения. Azure работает на OS Windows 2008 R2 (одна из модификаций). А эта ОС является объектом атак. Дыры находят довольно быстро, не всегда MS успевает их вовремя залатать.
GAE используют свои разработки, один черт знает что там у них. Ни об одной атаке на Google FrontEnd я не слышал. В этом отношении у них репутация безупречная.
Azure — это вчерашний день. Ничего нового по сравнению с тем же EC2 — нет. Да и кроме EC2 уже появилось немало хостеров с такими же «облачными» возможностями. Ситуацию усугубляет то, что оно еще и не доступно странам третьего мира (EC2 и множество других — давно доступны).
Настоящий облачный сервис — это Google App Engine. И конкурентов у него не так уж много. Я ради него даже Java выучил, уже 3 месяца на ней пишу (кстати, после 7 лет C# — не сложно).
GAE действительно позволяет платить за то, что используешь. А не как ваше Azure — VPS с оплатой за трафик.
Имхо, будущее за GAE и так подобными технологиями. Если MS это поймут — будет и нам, .Net-чикам, счастье. Я готов даже дороже платить чем за GAE. Готов платить в 2 раза больше, но с той же ценовой политикой: оплата за ресурсы, а не за время.
>>числа с плавающей точкой для эого в любому случае не годятся
Вы имеете в виду погрешность и ошибку при сравнении? Я сумму всегда округляю с помощью вот так:
amount = Math.round(amount * 100.0) / 100.0;
, так что погрешность ликвидируется. BigDecimal тяжеловат, имхо. С Java работаю недавно, могу ошибаться. Если в пару словах скажите где меня поджидает опасность — буду благодарен.
Кстати, никто не обратил внимание на обилие OpenSource-проектов в KAV? Интересно, можно ли все эти проекты использовать в закрытом коммерческом проекте?
Эту тонкость мало кто знает. Обычно g равен единице, но иногда (в некоторых реализациях) принимают другое значение. Я когда атаки Винера реализовывал — сначала облажался, т.к. не знал про это g и что оно может быть отличным от единицы.
Обычно формула такая:
d*e = 1 + k*f (f — функция эйлера от n, k — любое число, чтобы получилось целое d)
А в случае с добавлением g, она принимает вид:
d*e*g = g + k*f
Вот с таким добавлением g RSA все равно работает и на практике это g иногда добавляется (в частности, ключ WebMoney Keeper Classic его использует, а вот Windows CSP не использует).
Вы говорите просто — а оказывается не все так просто. Тонкостей, которые не описаны в wiki народ то и не знает — минусы ставит.
По поводу «несложный» отписал ниже. Попробуйте придумать свой уникальный и криптостойкий алгоритм шифрования, пуст даже простой. Поймете, что не все так просто как кажется на первый взгляд.
RSA намного проще, главное вспомнить малую теорему Ферма.
Вообще не припомню не одного сверх-сложного криптографического алгоритма. Когда все подробно распишут — на первый взгляд просто. Но попробуйте придумать что-то аналогичное... Сразу поймете что не так все просто, как кажется на первый взгляд. Даже оценить криптостойкость алгоритма — уже мало кто сможет.
>>Без тестов ваш код был на 99% правильным, с тестами — на 99.99%. Качество выросло всего на 1 процент, а времени потрачено в 2 раза больше.
Совершенно верно. Нужно только решить насколько критичен этот 1% для конкретного проекта. Если 1% ошибок выльется в процент потерянных денег — то весьма критично.
Во много крат. Не в 2 раза, а именно во много крат. Парадокс, да?
Допустим, в моей системе 100 логических действий, каждое из которых может быть написано с ошибкой (человеческий фактор). В среднем я делаю 1 ошибку на 100 действий. Т.е. в этих 100 действиях есть 1 ошибка (возьмем средний случай).
Если добавить тесты, то в них так-же будет 1 ошибка (так-же 100 действий).
Какова вероятность того, что ошибка будет в одном и том-же месте и в тестах и в программе (речь о машинальной ошибке)? Получается 1 из 10000, верно? Другими словами качество кода повысится в 100 раз, хотя времени затратим только в 2 раза больше.
>>Во-первых, а почему вы решили остановиться на двойной?
Потому что есть 2 стороны: наша система (программа) и внешний мир (пользователь или другая система). С помощью тестов мы эмулируем внешний мир. Третьей стороны нет. Была бы третья — можно было бы делать тройную проверку.
Алгоритм «внешнего мира» не является полным аналогом алгоритма системы.
>>Достаточно того, чтобы одна ошибка скрывала другую.
Бывает и такое. Здесь важна вероятность. По вероятности отпишу ниже.
Лично мне тесты помогают при рефакторинге. Хочу улучшить код (привести к ) — а он потом перестает работать правильно (какая-нибудь мелочь). Вот такие мелочи тесты находят быстро.
Позволю себе в очередной раз напомнить, что граждане России (и Украины) до сих пор не имеют возможности использовать Azure. Следовательно, ни о каком «улучшении доступности» речи быть не может.
Кстати, а почему до сих пор «нельзя»? Неужели вы думаете что в России будет столько желающих, что мощностей не хватит? Решили бы этот вопрос, а то получается только дразните.
Ну у меня свой простенький тип Amount с хранением в double. Там хранится сумма с округлением до копейки.
Вообще округление нужно только для сравнения — иначе окажется что 1.01 руб не равно 1.0100000001 руб.
>>При суммировании скажем 1000 чисел это может оказаться вполне заметным.
Точность double, если память не изменяет — около 13 десятичных знаков? Если числа большие, то могут возникнуть проблемы, согласен. Но я прикинул — пока точности даже в 10 знаков для моих задач хватит. Если произойдет гипер-инфляция — последую вашему совету и задействую BigDecimal.
2. А как же без этого. Но это не является чем-то особенным. Если вы расскажите о практических преимуществах в сравнении с конкурентами — тогда послушаем.
3. А где я сказал что плохая репутация? Имхо, у Windows 2008 R2 — хорошая репутация. Но эта ось является объектом атак (она используется многими и есть возможность и смысл экспериментировать). Или вы хотите сказать что модифицированная версия (которую модифицировали для Azure) более защищенная?
И сама Windows, если я не ошибаюсь, так-же имеет сертификации подобного уровня. Верно? Все мы понимаем что это маркетинговые фишки, которые, по сути, ничего не гарантируют.
Скажу с практической точки зрения. Azure работает на OS Windows 2008 R2 (одна из модификаций). А эта ОС является объектом атак. Дыры находят довольно быстро, не всегда MS успевает их вовремя залатать.
GAE используют свои разработки, один черт знает что там у них. Ни об одной атаке на Google FrontEnd я не слышал. В этом отношении у них репутация безупречная.
Настоящий облачный сервис — это Google App Engine. И конкурентов у него не так уж много. Я ради него даже Java выучил, уже 3 месяца на ней пишу (кстати, после 7 лет C# — не сложно).
GAE действительно позволяет платить за то, что используешь. А не как ваше Azure — VPS с оплатой за трафик.
Имхо, будущее за GAE и так подобными технологиями. Если MS это поймут — будет и нам, .Net-чикам, счастье. Я готов даже дороже платить чем за GAE. Готов платить в 2 раза больше, но с той же ценовой политикой: оплата за ресурсы, а не за время.
Вы имеете в виду погрешность и ошибку при сравнении? Я сумму всегда округляю с помощью вот так:
, так что погрешность ликвидируется. BigDecimal тяжеловат, имхо. С Java работаю недавно, могу ошибаться. Если в пару словах скажите где меня поджидает опасность — буду благодарен.
Кстати, проверил — вот такой код не падает:
NumberFormat decimalFormat = DecimalFormat.getInstance(Locale.ROOT); decimalFormat.parse(value.replace(",", ".")).doubleValue()Его я использовал для парсинга.
Нужно будет сайт пофиксить, чтобы вместо суммы операции не вводили это гнустное число. Иначе сайт легко будет в даун отправить.
Эту тонкость мало кто знает. Обычно g равен единице, но иногда (в некоторых реализациях) принимают другое значение. Я когда атаки Винера реализовывал — сначала облажался, т.к. не знал про это g и что оно может быть отличным от единицы.
Обычно формула такая:
d*e = 1 + k*f (f — функция эйлера от n, k — любое число, чтобы получилось целое d)
А в случае с добавлением g, она принимает вид:
d*e*g = g + k*f
Вот с таким добавлением g RSA все равно работает и на практике это g иногда добавляется (в частности, ключ WebMoney Keeper Classic его использует, а вот Windows CSP не использует).
Вы говорите просто — а оказывается не все так просто. Тонкостей, которые не описаны в wiki народ то и не знает — минусы ставит.
Кстати, d может так-же вычисляться по такой формуле
(e*d*g) % ((p-1)*(q-1)) = g
Т.е. добавляется параметр g (обычно менее 10). При таком d RSA продолжает корректно работать.
Вообще не припомню не одного сверх-сложного криптографического алгоритма. Когда все подробно распишут — на первый взгляд просто. Но попробуйте придумать что-то аналогичное... Сразу поймете что не так все просто, как кажется на первый взгляд. Даже оценить криптостойкость алгоритма — уже мало кто сможет.
Совершенно верно. Нужно только решить насколько критичен этот 1% для конкретного проекта. Если 1% ошибок выльется в процент потерянных денег — то весьма критично.
Допустим, в моей системе 100 логических действий, каждое из которых может быть написано с ошибкой (человеческий фактор). В среднем я делаю 1 ошибку на 100 действий. Т.е. в этих 100 действиях есть 1 ошибка (возьмем средний случай).
Если добавить тесты, то в них так-же будет 1 ошибка (так-же 100 действий).
Какова вероятность того, что ошибка будет в одном и том-же месте и в тестах и в программе (речь о машинальной ошибке)? Получается 1 из 10000, верно? Другими словами качество кода повысится в 100 раз, хотя времени затратим только в 2 раза больше.
Поправьте меня, если я ошибся.
Потому что есть 2 стороны: наша система (программа) и внешний мир (пользователь или другая система). С помощью тестов мы эмулируем внешний мир. Третьей стороны нет. Была бы третья — можно было бы делать тройную проверку.
Алгоритм «внешнего мира» не является полным аналогом алгоритма системы.
>>Достаточно того, чтобы одна ошибка скрывала другую.
Бывает и такое. Здесь важна вероятность. По вероятности отпишу ниже.
Лично мне тесты помогают при рефакторинге. Хочу улучшить код (привести к ) — а он потом перестает работать правильно (какая-нибудь мелочь). Вот такие мелочи тесты находят быстро.