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 стороны: наша система (программа) и внешний мир (пользователь или другая система). С помощью тестов мы эмулируем внешний мир. Третьей стороны нет. Была бы третья — можно было бы делать тройную проверку.
Алгоритм «внешнего мира» не является полным аналогом алгоритма системы.
>>Достаточно того, чтобы одна ошибка скрывала другую.
Бывает и такое. Здесь важна вероятность. По вероятности отпишу ниже.
Лично мне тесты помогают при рефакторинге. Хочу улучшить код (привести к ) — а он потом перестает работать правильно (какая-нибудь мелочь). Вот такие мелочи тесты находят быстро.
>> в слаборазвитые страны типа Зимбабве, России, Украины, Сомали и т.п. запрещено слать продукты высоких технологий, дабы аборигены не отвлекались от собирания кокосов
Люблю Java именно за этот минимализм. Нет ничего лишнего, но есть все необходимое.
Из C# постепенно «все в одном» делают: и запросы, и динамическая типизация, и ФП, и скрипты… Может кому и нравится — не знаю. Как по мне — так для каждой задачи нужно использовать более подходящую технологию, а не совмещать. Но это холивар, конечно.
>>Я помню, что у классика kwm-файл может быть разного размера, соответственно интересно было бы почитать как в случае с изменяющимся размером получить D и Modulus
Это раньше было, теперь размер все время одинаковый. Раньше его раздували простейшим алгоритмом «для безопасности». Смысл, возможно, был, когда у всех было подключение 32 Кбод. Сейчас убрали.
>>Закрытый RSA-ключ, который будет помечен как неэкспортируемый и поэтому его нельзя будет извлечь? Если да, то в случае с хранилищем win* все можно извлечь, правда нестандартным, но довольно простым способом.
С win-хранилища можно (если на ключ не установлен пароль). А вот с eToken — такой возможности нет в принципе — только вместе с устройством.
Добились — хорошее слово. Будете смеяться, но первая реализация вычисляла произведение точки на число 15 минут.
Там умножение в ОНБ. В принципе, оно длительно выполняется. Скорее всего нужно перевести в полиномиальный базис, тогда будет быстрее. В общем, если вы разбираетесь в вопросе — можете посмотреть исходники.
Настоящий облачный сервис — это 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 стороны: наша система (программа) и внешний мир (пользователь или другая система). С помощью тестов мы эмулируем внешний мир. Третьей стороны нет. Была бы третья — можно было бы делать тройную проверку.
Алгоритм «внешнего мира» не является полным аналогом алгоритма системы.
>>Достаточно того, чтобы одна ошибка скрывала другую.
Бывает и такое. Здесь важна вероятность. По вероятности отпишу ниже.
Лично мне тесты помогают при рефакторинге. Хочу улучшить код (привести к ) — а он потом перестает работать правильно (какая-нибудь мелочь). Вот такие мелочи тесты находят быстро.
Спасибо.
>>Буду рад ответить на ваши вопросы
Вы бы могли привести минимальный JS пример, не содержащий ни одного слова?
Как хорошо сказано! Нужно будет запомнить.
Из C# постепенно «все в одном» делают: и запросы, и динамическая типизация, и ФП, и скрипты… Может кому и нравится — не знаю. Как по мне — так для каждой задачи нужно использовать более подходящую технологию, а не совмещать. Но это холивар, конечно.
Вот здесь исходный код на C# для расшифровки ключа: wm-api.svn.sourceforge.net/svnroot/wm-api/trunk/WebMoney.Cryptography/DecryptedKey.cs В самом верху файла — константы. Они повторяют структуру файла kwm.
>>Я помню, что у классика kwm-файл может быть разного размера, соответственно интересно было бы почитать как в случае с изменяющимся размером получить D и Modulus
Это раньше было, теперь размер все время одинаковый. Раньше его раздували простейшим алгоритмом «для безопасности». Смысл, возможно, был, когда у всех было подключение 32 Кбод. Сейчас убрали.
>>Закрытый RSA-ключ, который будет помечен как неэкспортируемый и поэтому его нельзя будет извлечь? Если да, то в случае с хранилищем win* все можно извлечь, правда нестандартным, но довольно простым способом.
С win-хранилища можно (если на ключ не установлен пароль). А вот с eToken — такой возможности нет в принципе — только вместе с устройством.
Добились — хорошее слово. Будете смеяться, но первая реализация вычисляла произведение точки на число 15 минут.
Там умножение в ОНБ. В принципе, оно длительно выполняется. Скорее всего нужно перевести в полиномиальный базис, тогда будет быстрее. В общем, если вы разбираетесь в вопросе — можете посмотреть исходники.