Всё в этом мире симметрично:
Лучше одна понятная строка, чем 10 строчек говнокода.
Из говнокода в этих примерах — разве что решето Эратосфена, да ещё фильтрация списка в некоторых примерах. И то, большей частью из-за желания написать в одну строку код, которых всё-таки по хорошему занимает несколько строк.
Да ладно, там вроде бы нигде нет грязных хаков. И уж всяко лучше писать doubles = [x*2 for x in range(1,5)]
чем
doubles = []
i = 1
while i<5:
l.append(i*2)
i+=1
Да, во втором как бы более понятен метод работы. Правда, только для тех, кто на питоне не программирует. А если знаешь язык, и не пользуешься его легитимными функциями — это как-то странно.
Меньше кода — меньше ошибок.
Да, но с другой стороны до сих пор нет технических средств, которые позволили бы на 100% контролировать сеть. Белые списки, разве что… Но это явный бред.
Вон Китай хоть и пытается как-то контролировать Сеть у себя, но желающие всегда могут найти обходные пути.
Но государства и дальше будут пытаться наложить лапу на Интернет, это понятно. Мне скорее интересно, как-то повлияет на другие корпорации: Гугл, Майкрософт, Фейсбук, Эппл, и т.д. Ведь очевидно, что (в том или ином виде) дыры есть у всех. Не станут ли такие взломы ещё одним средством конкурентной борьбы? Или средством шантажа?
Всё-таки провал стоимости акций на 30% из-за кучки хакеров — это как-то… пугающе.
1. Рейтинги и статистика должны обнулиться сами. Ровно в тот самый момент, когда игра будет помечена как недействительная.
2. Нет, игру удалять конечно же не нужно. Нужно пометить её как недействительную.
3. Да, если приходиться делать запросы вида «update pref_player set games=games-1, rating=rating-%s where player_id=%s», (rating, player_id)" — значит дизайн базы неправильный. У игрока вообще не должно быть полей rating и games. Ибо эти поля легко вычисляются из истории сыгранных им игр. Если это вдруг очень тяжелые расчеты — можно всегда хранить их в materialized view. Но никак не в виде атрибутов игрока. Ибо это может приводить к потере целостности базы. Что мы и наблюдаем, кстати.
Меняем статус игры, откатываем денормализационные данные со статистикой игроков, инвалидируем оперативные кеши, затрагивающие эти данные, и дело в шляпе.
Есть мнение, что если таким образом отменяются результаты игры — значит что-то в корне неправильно с дизайном базы.
Ибо, например, статистика игрока — всегда должна быть функцией от сыгранных игр. Так же, как и рейтинг игрока. И, соотвественно, должна вычисляться на ходу (через функцию, либо view, либо materialized view, если рассчеты сложные). Тогда никогда не будет нарушена нормализация базы, и не нужно будет делать такие шаманства, как описывал автор. Нужно будет всего-лишь изменить статус игры.
Меняем статус игры, откатываем денормализационные данные со статистикой игроков, инвалидируем оперативные кеши, затрагивающие эти данные, и дело в шляпе.
В том то и дело, что атака появилась в 70, просто ну публиковалась. В той цитате, что я привел — так и написано.
Вот выдержка из русской Википедии:
Дифференциальный криптоанализ применим для взлома алгоритмов с постоянными S-блоками, таких как DES. При этом его эффективность сильно зависит от структуры S-блоков. Оказалось, что S-блоки DES оптимизированы против дифференциального криптоанализа. Предполагается, что создатели DES знали об этом методе. По словам Дона Копперсмита из IBM:
«При проектировании использовались преимущества определенных криптоаналитических методов, особенно метода «дифференциального криптоанализа», который не был опубликован в открытой литературе. После дискуссий с NSA было решено, что раскрытие процесса проектирования раскроет и метод дифференциального криптоанализа, мощь которого может быть использована против многих шифров. Это, в свою очередь, сократило бы преимущество США перед другими странами в области криптографии.»
Не совсем понятно с DESL. Насколько я знаю, S-boxes были подобраны таким образом, что эффективно противостоять дифференциальному криптоанализу:
Some of the suspicions about hidden weaknesses in the S-boxes were allayed in 1990, with the independent discovery and open publication by Eli Biham and Adi Shamir of differential cryptanalysis, a general method for breaking block ciphers. The S-boxes of DES were much more resistant to the attack than if they had been chosen at random, strongly suggesting that IBM knew about the technique in the 1970s.
Соотвественно, использование одного и того же S-box вместо восьми разных должно сделать DESL очень восприимчивым к такой атаке.
Может не стоит решать ресурсоёмкие задачи на C#? Всё-таки старичок C для этого подходит лучше. Особенно, учитывая тот факт, что из C# легко и просто дергать dll-ки написанные на C.
А то вначале создаем себе трудности, а потом героически их решаем.
Это тот же goto, только ещё и нарушающий семантику.
do {} while() — это цикл, у него семантика цикла. Когда я вижу do while я ожидаю увидеть цикл. А вы его используете как goto.
Это намного хуже, чем просто поставить одну несчастную метку «error:».
Лучше одна понятная строка, чем 10 строчек говнокода.
Из говнокода в этих примерах — разве что решето Эратосфена, да ещё фильтрация списка в некоторых примерах. И то, большей частью из-за желания написать в одну строку код, которых всё-таки по хорошему занимает несколько строк.
doubles = [x*2 for x in range(1,5)]чем
Да, во втором как бы более понятен метод работы. Правда, только для тех, кто на питоне не программирует. А если знаешь язык, и не пользуешься его легитимными функциями — это как-то странно.
Меньше кода — меньше ошибок.
Но всё-таки у нас в математике используется именно «кортеж», а не «тьюпл». Да и выговорить его куда проще.
print [x*2 for x in range(1,11)]
Легче читается, чем через лямбды
Вон Китай хоть и пытается как-то контролировать Сеть у себя, но желающие всегда могут найти обходные пути.
Но государства и дальше будут пытаться наложить лапу на Интернет, это понятно. Мне скорее интересно, как-то повлияет на другие корпорации: Гугл, Майкрософт, Фейсбук, Эппл, и т.д. Ведь очевидно, что (в том или ином виде) дыры есть у всех. Не станут ли такие взломы ещё одним средством конкурентной борьбы? Или средством шантажа?
Всё-таки провал стоимости акций на 30% из-за кучки хакеров — это как-то… пугающе.
Интересное время нас ждет.
Интересно, какие это будет иметь последствия в глобальном масштабе?
2. Нет, игру удалять конечно же не нужно. Нужно пометить её как недействительную.
3. Да, если приходиться делать запросы вида «update pref_player set games=games-1, rating=rating-%s where player_id=%s», (rating, player_id)" — значит дизайн базы неправильный. У игрока вообще не должно быть полей rating и games. Ибо эти поля легко вычисляются из истории сыгранных им игр. Если это вдруг очень тяжелые расчеты — можно всегда хранить их в materialized view. Но никак не в виде атрибутов игрока. Ибо это может приводить к потере целостности базы. Что мы и наблюдаем, кстати.
Есть мнение, что если таким образом отменяются результаты игры — значит что-то в корне неправильно с дизайном базы.
Ибо, например, статистика игрока — всегда должна быть функцией от сыгранных игр. Так же, как и рейтинг игрока. И, соотвественно, должна вычисляться на ходу (через функцию, либо view, либо materialized view, если рассчеты сложные). Тогда никогда не будет нарушена нормализация базы, и не нужно будет делать такие шаманства, как описывал автор. Нужно будет всего-лишь изменить статус игры.
Вот выдержка из русской Википедии:
Соотвественно, использование одного и того же S-box вместо восьми разных должно сделать DESL очень восприимчивым к такой атаке.
устроит? :)
Я та понял, у них там есть разные размеры, от маленьких, до вот таких огромных.
Хм, или, как вариант, хранить всё в memcached :)
А то вначале создаем себе трудности, а потом героически их решаем.
do {} while() — это цикл, у него семантика цикла. Когда я вижу do while я ожидаю увидеть цикл. А вы его используете как goto.
Это намного хуже, чем просто поставить одну несчастную метку «error:».