>Не согласен по поводу С. Помойму нет ничего быстрее его на данный момент
http://java.sun.com/developer/technicalA…
"It is possible for Java code to be faster than C. For example, allocation in the Java language is already much faster than it is in C. Java programming enables optimizations not possible in C because C leaves so many important factors, such as allocation and thread management, to libraries. Ironically, it's the bit-level control over pointers, which most C programmers see as their most powerful weapon, that cripples the C compiler's ability to optimize effectively. By giving up that bit of control, you enable a wealth of optimizations that are not possible in C and the Java compiler knows more about optimization than 99.99 percent of programmers do."
Просто не могу не привести цитаты из известной книги "Защищенный код" ("Writing Secure Code"). Сразу отмечу явно промайскрософтовскую ориентацию авторов - не скажу, что я с ними солидарен... как и того, что несолидарен :)
Итак:
Образование позволяет избавиться от заблуждения, что «лишняя пара глаз — всегда лучше»
Я много раз слышал утверждение, что чем больше глаз изучают код. тем больше
брешей удается найти и тем безопаснее код. Это вопиющее заблуждение! Люди,
анализирующие код, должны знать и понимать, как выглядят уязвимые места.
Приведу аналогию. Написание книги совпало с периодом громких разоблачений
компаний, занимавшихся фальсификацией финансовой отчетности. Представьте
себе, что исполнительный директор одной из таких компаний отвечает в Конгрессе США на вопросы, касающиеся учетной политики:
Представитель конгресса: У нас есть информация, что ваша компания представ-
ляла «липовые» отчеты.
Директор компании: Это неправда.
Представитель конгресса: Как вы можете это доказать?
Директор компании: Более 10 000 человек изучали наши отчеты, и ни один не
нашел даже малейшего недостатка.
Представитель конгресса: Но каков уровень знаний этих «аудиторов» в области финансов? Где они получили бухгалтерское образование и знакомы ли им
особенности учета в вашей отрасли?
Директор компании: Какая разница? Ведь 10 000 человек — это 10 000 пар глаз!
Сколько бы людей ни анализировали спецификации проекта и само приложение, пытаясь обнаружить дыры в защите, это бесполезная трата времени, если
они не профессионалы в области создания безопасных систем и не знают, где и
как нужно искать уязвимые места, Чтобы качественно анализировать программы,
требуется много знать. Преподав сообразительным сотрудникам основы безопасности и объяснив ход мыслей взломщика, вы будете удивлены их достижениями
в области безопасности,
А теперь доказательства!
В 2001 г. я поставил простой эксперимент, желая подтвердить мою теорию о роли
обучения основам безопасности. Я обратился к двум моим знакомым: оба были
технически подкованы и прекрасно разбирались в программировании. Я попросил каждого проанализировать 1000 строк реального, взятого из Интернета открытого кода на С и попытаться обнаружить в нем бреши. Первый "подопытный»
нашел 10 недостатков, второй — 16. Затем я прочитал им часовую лекцию с демонстрацией массы реальных примеров программистских ошибок, которые вылились в дыры в защите, и рекомендациями, как следует относиться к данным,
поступающим в программу. Закончив, я попросил их проанализировать код снова. Вы мне не поверите, но первый испытуемый нашел еще 45, а второй — 41 бреюсь.
Кстати, я сам обнаружил в программе только 54 недостатка. Таким образом, в общем
зачете первый нашел 55 ошибок, т. е. на одну больше, чем я, а второй — 57, то есть
еще две в придачу к нашим!
Если так очевидно, что обучение позволяет разработчикам быстрее и качественнее распознавать недостатки защиты, то почему же люди продолжают верить, что
нетренированные глаза и мозг способны повысить безопасность ПО?
Внимание! Горстка специалистов принесет больше пользы, чем армия неучей. (в книге выделено в отдельную сноску)
К сожалению, Лин-чи потерял лес за деревьями.
А лес в том, что истинной причиной гнева было чувство собственной важности (ЧСВ).
Которое очень остро реагирует на посягательства других Эго ("не может быть двух солнц на небе...").
В ситуации "лодка пуста" второе Эго отсутствует - такой расклад не задевает ЧСВ.
Принимать позицию "эта лодка пуста" в конфликтах с людьми - это просто прятать свое ЧСВ от ударов, т.е. попросту прятать проблему в глубь, устранять симптом, а не причину.
И если в один прекрасный момент вовремя защитить свое заботливо возлелеянное ЧСВ не удастся, то взрыв гнева будет огромен и беспощадно разрушителен.
По мне, так такое решение иначе как грязным хаком не назовешь:
-логика формирования меню разносится по нескольким местам (усложняет поддержку);
-нет никакой гарантии (т.к. логика "формирования строковой переменной" вам попросту неизвестна), что при наличии некоторых факторов исходная строка будет иметь иной вид, чем предполагает ваш regexp;
-понять, где и как формируется переменная - никак не смахивает на свехзадачу - даже в отсутствии комментариев.
Другое дело, что в мире php такие решения - норма...
А по поводу "утро вечера мудренее" и "решения проблем в подсознании" - совершенно согласен.
Самый тривиальный пример - чтение забористых IT-книжек: утром с легкостью понимаю строчки, которые пытался осознать весь вечер :)
И самое удивительное то, что субъективно совершенно незаметно, что "опосля" думается легче - это видно только постфактум (когда понимаешь, то за 5 минут решил задачу, над которой вчера бился весь день).
Но есть реальная проблема у альтернативных способов мышления: нет никакого четкого алгоритма, а следовательно и никаких гарантий что решение будет найдено в указанный срок (или хотя бы доказано, что решения нет).
"И если вы много и беспорядочно кушаете, курите и выпиваете, то работа ночью вам ни по чём :)"
Категорически неверно: уже ослабленному организму работа ночью наносит еще больший вред.
Я имею некоторый печальный опыт (хронический панкреатит развившийся из-за жесточайшего недосыпания + неправильного питания + физических перегрузок) на этот счет и знаю о чем говорю.
Это очевидно: потому что вы, как и большинство офисных работников - всего лишь винтик в сложном и отлаженном механизме. И для полностью слаженной работы механизма этот винтик должен вести себя строго определенным образом.
На примере этот так.
1) Представим, вашему начальству срочно нужен отчет о статусе задачи, порученной вам - а вы попросту отсутствуете на рабочем месте.
2) Любые разговоры с клиентом тоже предполагают вполне определенные временные рамки.
3) И т.п.
Так что реальная причина наших проблем - ОБЩЕСТВО.
Именно оно (а вовсе не время!) не имеет ночью власти над человеком: пока все "агрессоры" спят, можно полноценнее реализовать СВОЕ...
Баги просто прут изо всех дыр.
Вот что обнаружилось за первые 5 минут (!!!) использования:
1) инсталляция модулей проверки орографии невозможна из-за HTTP-ошибки;
2) (мелкий issue) для многих пользователей будет совсем неочевидно, что для icq-аккаунтов поле screen name - на самом деле UIN;
3) (мелкий issue) при добавлении контакта не умеет самостоятельно резолвить его ник - а ведь даже jabber-транспорты это умеют;
4) (!) подтверждение авторайза почему-то не воспринимается этим клиентом;
5) (!) сообщения с русскими буквами, отправленные в оффлайн НЕ подтягиваются ICQ 5.1 (т.е. 99% проблема в самом Pidgin).
Просто невероятно занудный и бесполезный подкаст...
Примитивные обывательско-мещанские рассуджения абсолютно безэмоциональным, усыпляющим тоном.
Ребята, неужели у вас НАСТОЛЬКО скучная жизнь, что вам ТАКОЕ интересно???
Про java/php/C#/C++ то же самое скажет многократно большее количество человек.
См. http://www.habrahabr.ru/blog/translation…
http://java.sun.com/developer/technicalA…
"It is possible for Java code to be faster than C. For example, allocation in the Java language is already much faster than it is in C. Java programming enables optimizations not possible in C because C leaves so many important factors, such as allocation and thread management, to libraries. Ironically, it's the bit-level control over pointers, which most C programmers see as their most powerful weapon, that cripples the C compiler's ability to optimize effectively. By giving up that bit of control, you enable a wealth of optimizations that are not possible in C and the Java compiler knows more about optimization than 99.99 percent of programmers do."
umputun, bobuk - пожалуйста, прокомментируйте.
Взгляд Кирилла действительно уж очень не похож на оной у ведущих Radio-T.
http://blogs.zdnet.com/Google/?p=189 - Google Music: More clues?
Похоже, музыку будут именно продавать: "audio files are said to be downloadable (for a price)".
Итак:
Образование позволяет избавиться от заблуждения, что «лишняя пара глаз — всегда лучше»
Я много раз слышал утверждение, что чем больше глаз изучают код. тем больше
брешей удается найти и тем безопаснее код. Это вопиющее заблуждение! Люди,
анализирующие код, должны знать и понимать, как выглядят уязвимые места.
Приведу аналогию. Написание книги совпало с периодом громких разоблачений
компаний, занимавшихся фальсификацией финансовой отчетности. Представьте
себе, что исполнительный директор одной из таких компаний отвечает в Конгрессе США на вопросы, касающиеся учетной политики:
Представитель конгресса: У нас есть информация, что ваша компания представ-
ляла «липовые» отчеты.
Директор компании: Это неправда.
Представитель конгресса: Как вы можете это доказать?
Директор компании: Более 10 000 человек изучали наши отчеты, и ни один не
нашел даже малейшего недостатка.
Представитель конгресса: Но каков уровень знаний этих «аудиторов» в области финансов? Где они получили бухгалтерское образование и знакомы ли им
особенности учета в вашей отрасли?
Директор компании: Какая разница? Ведь 10 000 человек — это 10 000 пар глаз!
Сколько бы людей ни анализировали спецификации проекта и само приложение, пытаясь обнаружить дыры в защите, это бесполезная трата времени, если
они не профессионалы в области создания безопасных систем и не знают, где и
как нужно искать уязвимые места, Чтобы качественно анализировать программы,
требуется много знать. Преподав сообразительным сотрудникам основы безопасности и объяснив ход мыслей взломщика, вы будете удивлены их достижениями
в области безопасности,
А теперь доказательства!
В 2001 г. я поставил простой эксперимент, желая подтвердить мою теорию о роли
обучения основам безопасности. Я обратился к двум моим знакомым: оба были
технически подкованы и прекрасно разбирались в программировании. Я попросил каждого проанализировать 1000 строк реального, взятого из Интернета открытого кода на С и попытаться обнаружить в нем бреши. Первый "подопытный»
нашел 10 недостатков, второй — 16. Затем я прочитал им часовую лекцию с демонстрацией массы реальных примеров программистских ошибок, которые вылились в дыры в защите, и рекомендациями, как следует относиться к данным,
поступающим в программу. Закончив, я попросил их проанализировать код снова. Вы мне не поверите, но первый испытуемый нашел еще 45, а второй — 41 бреюсь.
Кстати, я сам обнаружил в программе только 54 недостатка. Таким образом, в общем
зачете первый нашел 55 ошибок, т. е. на одну больше, чем я, а второй — 57, то есть
еще две в придачу к нашим!
Если так очевидно, что обучение позволяет разработчикам быстрее и качественнее распознавать недостатки защиты, то почему же люди продолжают верить, что
нетренированные глаза и мозг способны повысить безопасность ПО?
Внимание! Горстка специалистов принесет больше пользы, чем армия неучей. (в книге выделено в отдельную сноску)
А лес в том, что истинной причиной гнева было чувство собственной важности (ЧСВ).
Которое очень остро реагирует на посягательства других Эго ("не может быть двух солнц на небе...").
В ситуации "лодка пуста" второе Эго отсутствует - такой расклад не задевает ЧСВ.
Принимать позицию "эта лодка пуста" в конфликтах с людьми - это просто прятать свое ЧСВ от ударов, т.е. попросту прятать проблему в глубь, устранять симптом, а не причину.
И если в один прекрасный момент вовремя защитить свое заботливо возлелеянное ЧСВ не удастся, то взрыв гнева будет огромен и беспощадно разрушителен.
Выбросите его медленно, с удовольствием..." :)
-логика формирования меню разносится по нескольким местам (усложняет поддержку);
-нет никакой гарантии (т.к. логика "формирования строковой переменной" вам попросту неизвестна), что при наличии некоторых факторов исходная строка будет иметь иной вид, чем предполагает ваш regexp;
-понять, где и как формируется переменная - никак не смахивает на свехзадачу - даже в отсутствии комментариев.
Другое дело, что в мире php такие решения - норма...
А по поводу "утро вечера мудренее" и "решения проблем в подсознании" - совершенно согласен.
Самый тривиальный пример - чтение забористых IT-книжек: утром с легкостью понимаю строчки, которые пытался осознать весь вечер :)
И самое удивительное то, что субъективно совершенно незаметно, что "опосля" думается легче - это видно только постфактум (когда понимаешь, то за 5 минут решил задачу, над которой вчера бился весь день).
Но есть реальная проблема у альтернативных способов мышления: нет никакого четкого алгоритма, а следовательно и никаких гарантий что решение будет найдено в указанный срок (или хотя бы доказано, что решения нет).
А вот платить +350 USD за SD/MMC и камеру - кхм!...
Категорически неверно: уже ослабленному организму работа ночью наносит еще больший вред.
Я имею некоторый печальный опыт (хронический панкреатит развившийся из-за жесточайшего недосыпания + неправильного питания + физических перегрузок) на этот счет и знаю о чем говорю.
На примере этот так.
1) Представим, вашему начальству срочно нужен отчет о статусе задачи, порученной вам - а вы попросту отсутствуете на рабочем месте.
2) Любые разговоры с клиентом тоже предполагают вполне определенные временные рамки.
3) И т.п.
Так что реальная причина наших проблем - ОБЩЕСТВО.
Именно оно (а вовсе не время!) не имеет ночью власти над человеком: пока все "агрессоры" спят, можно полноценнее реализовать СВОЕ...
Вот что обнаружилось за первые 5 минут (!!!) использования:
1) инсталляция модулей проверки орографии невозможна из-за HTTP-ошибки;
2) (мелкий issue) для многих пользователей будет совсем неочевидно, что для icq-аккаунтов поле screen name - на самом деле UIN;
3) (мелкий issue) при добавлении контакта не умеет самостоятельно резолвить его ник - а ведь даже jabber-транспорты это умеют;
4) (!) подтверждение авторайза почему-то не воспринимается этим клиентом;
5) (!) сообщения с русскими буквами, отправленные в оффлайн НЕ подтягиваются ICQ 5.1 (т.е. 99% проблема в самом Pidgin).
Примитивные обывательско-мещанские рассуджения абсолютно безэмоциональным, усыпляющим тоном.
Ребята, неужели у вас НАСТОЛЬКО скучная жизнь, что вам ТАКОЕ интересно???
dirty.ru падает...