Вы совершенно верно рассуждаете, рассматриваемый в статье процесс пинга является лишь небольшой частью процесса сканирования и его целью является пропинговать как можно больше хостов за короткое время.
Для каждого из последующих этапов сканирования, доступность хоста определяется по своему собственному алгоритму, при этом первичный результат пинга, говорящий о недоступности хоста, может быть проигнорирован.
К сожалению у нас пока нет возможности полностью перейти на новый стандарт, в связи с большим кол-вом клиентов, некоторые из которых используют старые версии ОС.
Лично сам я ощущаю так же, лучшая инспекция – парное программирование.
По-моему, не все проекты готовы к такой методике и не для всех она подходит.
Парное программирование плохо прижилось, например, при разработке встраиваемых систем. По-моему, потому что там большое кол-во задач, когда нужно читать документацию на какую-то микросхему или прибор и потом писать по документации код. Читают все с разной скоростью, усваивают так же с разной скоростью и в разных объёмах. Да и вообще, часто нужно с железкой что-то попробовать, поэкпериментировать. Тут второму просто делать нечего. Это лично моё субъективное мнение: почему при разработке встраиваемых систем парное программирование не практикуется или практикуется редко.
Хотя для части кода – лучше именно инспекция. Например, вы портируете драйвер сетевой карты, такой код лучше чтобы проинспектировали ещё и опытные коллеги. Они найдут – где я забыл засинхронизировать доступ к ресурсу или увидят возможность рекурсивного вызова того же обработчика прерывания, а я на такую ситуацию с напарником не заложился :)
По школе помню, что лучше «контролку» проверить, прежде чем её сдать, а то пара обеспечена . А ещё лучше, если её проверит мой сосед :) (мы кстати бывало так делали в школе, проверяли работы друг у друга – находили дефекты :)
Так что, по-моему, инспекция дополняет практику парного программирования.
Инспекция позволяет посмотреть на выполненную работу спокойно и отстранённо, проверить её.
Да берите конечно. Не проблема! Не жалко :) Можно без надписей даже, ну или если хотите можно ссыль на сайт вставить www.ptsecurity.ru, но мы и так не обидимся.
По-моему, это как с «техническим долгом»: какой можно принять, чтобы в краткосрочной и долгосрочной перспективе заработать больше, чем без него.
По-существу.
1.1 Да, вы можете создать инспекцию, добавлять туда комиты по мере их появления и просматривать: добавился новый комит в инспекцию, вам пришло уведомление, посмотрели, прокомментировали. После того, как вы описали проблему, вспомнил, что мы так действительно поступали с большими задачами :-)
1.2 Самый лучший способ, который обеспечивал нас хорошими архитектурными решениями – Design Review. Перед началом того, что я хочу сделать, накидывал прототип, определял основные концепции и выкатывал это своим коллегам, которые критиковали и показывали узкие места. Таким образом, до начала реализации в рабочей системе мы тратили ~10% на прототипирование, зато получали отличные качественные архитектурные решения. CodeReview здесь уже помогает лечить проблему, но не причину. Предназначение же Design Review – лечить причину на корню. Думаю, что самый отличный вариант гармонично совмещать Design Review и CodeReview. Уточню, что Design Review проводили для действительно стоящих новых задач/рефакторинга, для «мелочи» этого не делали.
2. Да, может. Для этого настраивается так называемый Automatic Link – по сути это регэксп, найдя который в текстовых полях шапки инспекции, CC подставляет для него шаблон подстановки. Например, вот такой паттерн #(\d+) превращается у нас в ссылку в TestTrack при помощи такого шаблона ttstudio:///MaxPatrol8/dfct?number=$1 (#11001 -> ttstudio:///MaxPatrol8/dfct?number=11001)
С Джирой можно так же – это точно, на предыдущей работе у нас были ссылки в Джиру. Мы именовали инспекции, просто вводя код запроса из Джиры. Очень удобно. Всё равно краткая инфа в списке инспекций мне ничего не даёт, а вот ссылка на Джиру очень даже хороша. Тем более что есть функция сортировки по полю, так любую инспекцию легко найти.
Сейчас хотим добавлять ссылку в запросе bugtracker’а на инспекцию, чтобы было удобней. Пока что программист в запрос TestTrack вручную будет добавлять ссылку на инспекцию в CC.
Думаю, что такая возможность обязательно представится.
Главное — рассказать в таком формате, чтобы это действительно было интересно аудитории Хабра.
А продукты действительно очень любопытные.
Уточню разбираемую мной ситуацию, дабы убедиться, что мы говорим об одном и том же.
Разработчик работает над фичей недельку и каждый день делает commit’ы, дабы не заморачиваться с backup’ами. Допустим, что у него получилось порядка 15 commit’ов в разные файлы и что один файл участвовал во всех 15 commit’ах, причём код в этом файле правился, добавлялся, удалялся, рефакторился.
После того, как разработчик посчитал, что закончил работу над функционалом, и готов представить результаты на инспекцию, он создаёт инспекцию и добавляет все ревизии, которые относятся к этой задаче.
Меня как инспектора интересует diff было-стало. Что там было посередине – для меня не интересно, слишком дорого.
Лично мы своей командой работали в trunk’e, но на каждую задачу создавали свою рабочую копию. Поэтому, когда коммитил изменения по одной задаче и переключался на другую, то всегда обновлял рабочую копию, чтобы все изменения объединились.
Если работая над задачей видел, что какой-то разрабатываемый функционал будет нужен мне в других задачах, то мог его разработку провести отдельной подзадачей. Такое, правда, случалось очень редко, т.к. в большинстве своём задачи в работе (как правило, не больше 3 задач) редко пересекаются кодовой базой. Поэтому мы решили, что такие единичные случаи нам дешевле обработать, проведя разработку общей части в рамках новой подзадачи (прямо в багтрекере разработчик заводил новую задачу, в рамках которой выполнялась разработка общего функционала).
Поэтому, когда я начинал инспекцию, мне было совсем не интересно, как там правил код автор, и пытаться понять, каким образом автор пришёл к конечному решению — слишком дорого, в моём понимании.
Мы проводили инспекцию итогового решения:
1) удовлетворяет ли оно предъявляемым требованиям;
2) достаточно ли use-case’ов покрывают unit-тесты;
3) проверить код на отсутствие логических дефектов (например, конфигурация прибора читается до начала работы с ним);
4) проверить на применение правильных идиом (те же shared_ptr, отсутствие утечки ресурсов и применение RAII);
5) проверить корректную обработку граничных условий и обработку и сигнализацию ошибок (exception/return value).
Резюмируя, не припомню, чтобы комментарии к коммитам как-то помогали мне на инспекциях. Unit-тесты и комментарии к ним – да, doxygen комментарии к функциям/классам – да, комментарии в коммитах – нет.
CC не умеет отслеживать переименование/перемещение файлов в SVN. Запрос на разработку этого функционала висит еще с 2008 года. Разработчики отмазываются ограничениями самого SVN.
Переименование/перемещение файла CC понимает как удаление старого и создание нового. Не совсем удобно.
Хотя такие ситуации возникают достаточно редко. У нас были заведены, например, шаблоны именования файлов.
С другой стороны, если файл разрастается, то в конечном итоге, он подвергается рефакторингу и делению на несколько файлов. Корректность copy-paste’а из старого файла в новый приходится отслеживать вручную.
Извините меня за долгий ответ, был в командировке с четверга.
Более подробно формализации use-case'ов инспекций кода у нас была посвящена предыдущая статья. В ней рассмотрены, в частности, межкомандные инспекции.
Этот пример я взял из личного опыта предыдущего проекта, и мне было просто удобно на нём продемонстрировать интерфейс CC.
На предыдущем проекте у меня часто были задачи поддержки какого-то нового оборудования. Например, нужно поддержать новый контроллер или прибор учёта какого-то производителя (например). В этом случае создавался каталог для этого счётчика и создавались файлы реализации логики конкретно этого прибора, которые потом попадали на инспекцию (мы вели разработку прямо в trunk’e). Мы создали очень хорошую объектную модель(что типа фреймворкa), у которой всё было разнесено по разным уровням абстракции, и для поддержки нового прибора чаще всего нужно было создать реализацию абстракций именно под этот конкретный прибор. Схема очень похожа на модель драйверов в ядре Linux'a. Там есть так называемый bus драйвер, ниже — драйвер контролера, ещё ниже — драйвер конкретной железяки. Добавление достаточно объёмных новых файлов у нас было нормальным явлением.
Заводилась одна большая задача, которая делилась на несколько небольших подзадач, по каждой подзадаче делались commit'ы и на каждую подзадачу создавалась отдельная инспекция. Деление проводилось по разным логическим единицам: поддержка чтения архивов, поддержка чтения журналов, поддержка чтения текущих значений и т.д.
Т.е. разработчик каждый день, когда хотел, коммитил свой код в репозиторий. Затем, когда приходило время инспекции, указывал все нужные ревизии в инспекцию.
Когда я инспектирую вновь добавленные файлы, в которые уже было сделано по несколько commit'ов, то хочу видеть последнее состояние файла без промежуточных изменений, которые для меня не интересны. Вот это как раз позволяет сделать СС автоматически.
Такой живой интерес к посту не может не радовать :-)
К сожалению, всю прошлую пятницу хабр оставался для нас недоступен. Видимо, корпоративный IP был зафильтрован в процессе масштабной борьбы с DDoS-атаками. Сейчас ситуация изменилась, и в ближайшее время предоставим вам автора ;-)
Еще раз, огромное спасибо за вопросы и комментарии!
Думаю, у вас очень дисциплинированная команда, очень похвально.
Напишу именно про себя и свой опыт.
Когда мы использовали схему отслеживания commit’ов, то часть commit’ов оставлась в репозитории не проверенной.
Иногда в «запарке», я откладывал проверку на потом, а там ещё commit’ов накидали и старые уже просто лень смотреть совсем, и этого потом так у меня и не наступало.
Поэтому, дабы дисциплинировать себя самого, мы использовали инструмент, чтобы это «потом» однозначно наступало рано или поздно.
Ещё инструмент позволяет удобно отслеживать всю историю изменений и общения по конкретным блокам кода. В почтовой программе такого удобства, к сожалению, нет.
Инструмент позволяет работать с изменениями наподобие wiki движка: все комментарии видны, удобство обсуждения и хорошо отслеживается история изменений по ходу общения.
1. Мы реализуем новый функционал в отдельных ветках.
2. Каждая большая задача всегда разбивается на подзадачи.
3. Разработчик отдаёт код на инспекцию вменяемыми законченными частями.
4. Приоритет на инспекцию у нас ниже только критических уязвимостей.
ICS-CERT,
NVD,
CVE,
Bugtraq,
OSVDB,
Mitre Oval Repositories,
exploit-db,
Siemens Product CERT.
Сборники эксплойтов:
SAINTexploit,
Metasploit Framework,
Immunity Canvas,
Agora Pack,
Agora SCADA+,
D2 Exploit Pack,
White Phosphorus exploit pack,
VulnDisco Exploit Pack.
линки на каждый из них можно легко нагуглить :)
Для каждого из последующих этапов сканирования, доступность хоста определяется по своему собственному алгоритму, при этом первичный результат пинга, говорящий о недоступности хоста, может быть проигнорирован.
По-моему, не все проекты готовы к такой методике и не для всех она подходит.
Парное программирование плохо прижилось, например, при разработке встраиваемых систем. По-моему, потому что там большое кол-во задач, когда нужно читать документацию на какую-то микросхему или прибор и потом писать по документации код. Читают все с разной скоростью, усваивают так же с разной скоростью и в разных объёмах. Да и вообще, часто нужно с железкой что-то попробовать, поэкпериментировать. Тут второму просто делать нечего. Это лично моё субъективное мнение: почему при разработке встраиваемых систем парное программирование не практикуется или практикуется редко.
Хотя для части кода – лучше именно инспекция. Например, вы портируете драйвер сетевой карты, такой код лучше чтобы проинспектировали ещё и опытные коллеги. Они найдут – где я забыл засинхронизировать доступ к ресурсу или увидят возможность рекурсивного вызова того же обработчика прерывания, а я на такую ситуацию с напарником не заложился :)
По школе помню, что лучше «контролку» проверить, прежде чем её сдать, а то пара обеспечена . А ещё лучше, если её проверит мой сосед :) (мы кстати бывало так делали в школе, проверяли работы друг у друга – находили дефекты :)
Так что, по-моему, инспекция дополняет практику парного программирования.
Инспекция позволяет посмотреть на выполненную работу спокойно и отстранённо, проверить её.
Имхо, конечно всё.
По-моему, это как с «техническим долгом»: какой можно принять, чтобы в краткосрочной и долгосрочной перспективе заработать больше, чем без него.
По-существу.
1.1 Да, вы можете создать инспекцию, добавлять туда комиты по мере их появления и просматривать: добавился новый комит в инспекцию, вам пришло уведомление, посмотрели, прокомментировали. После того, как вы описали проблему, вспомнил, что мы так действительно поступали с большими задачами :-)
1.2 Самый лучший способ, который обеспечивал нас хорошими архитектурными решениями – Design Review. Перед началом того, что я хочу сделать, накидывал прототип, определял основные концепции и выкатывал это своим коллегам, которые критиковали и показывали узкие места. Таким образом, до начала реализации в рабочей системе мы тратили ~10% на прототипирование, зато получали отличные качественные архитектурные решения. CodeReview здесь уже помогает лечить проблему, но не причину. Предназначение же Design Review – лечить причину на корню. Думаю, что самый отличный вариант гармонично совмещать Design Review и CodeReview. Уточню, что Design Review проводили для действительно стоящих новых задач/рефакторинга, для «мелочи» этого не делали.
2. Да, может. Для этого настраивается так называемый Automatic Link – по сути это регэксп, найдя который в текстовых полях шапки инспекции, CC подставляет для него шаблон подстановки. Например, вот такой паттерн #(\d+) превращается у нас в ссылку в TestTrack при помощи такого шаблона ttstudio:///MaxPatrol8/dfct?number=$1 (#11001 -> ttstudio:///MaxPatrol8/dfct?number=11001)
С Джирой можно так же – это точно, на предыдущей работе у нас были ссылки в Джиру. Мы именовали инспекции, просто вводя код запроса из Джиры. Очень удобно. Всё равно краткая инфа в списке инспекций мне ничего не даёт, а вот ссылка на Джиру очень даже хороша. Тем более что есть функция сортировки по полю, так любую инспекцию легко найти.
Сейчас хотим добавлять ссылку в запросе bugtracker’а на инспекцию, чтобы было удобней. Пока что программист в запрос TestTrack вручную будет добавлять ссылку на инспекцию в CC.
Думаю, что такая возможность обязательно представится.
Главное — рассказать в таком формате, чтобы это действительно было интересно аудитории Хабра.
А продукты действительно очень любопытные.
Разработчик работает над фичей недельку и каждый день делает commit’ы, дабы не заморачиваться с backup’ами. Допустим, что у него получилось порядка 15 commit’ов в разные файлы и что один файл участвовал во всех 15 commit’ах, причём код в этом файле правился, добавлялся, удалялся, рефакторился.
После того, как разработчик посчитал, что закончил работу над функционалом, и готов представить результаты на инспекцию, он создаёт инспекцию и добавляет все ревизии, которые относятся к этой задаче.
Меня как инспектора интересует diff было-стало. Что там было посередине – для меня не интересно, слишком дорого.
Лично мы своей командой работали в trunk’e, но на каждую задачу создавали свою рабочую копию. Поэтому, когда коммитил изменения по одной задаче и переключался на другую, то всегда обновлял рабочую копию, чтобы все изменения объединились.
Если работая над задачей видел, что какой-то разрабатываемый функционал будет нужен мне в других задачах, то мог его разработку провести отдельной подзадачей. Такое, правда, случалось очень редко, т.к. в большинстве своём задачи в работе (как правило, не больше 3 задач) редко пересекаются кодовой базой. Поэтому мы решили, что такие единичные случаи нам дешевле обработать, проведя разработку общей части в рамках новой подзадачи (прямо в багтрекере разработчик заводил новую задачу, в рамках которой выполнялась разработка общего функционала).
Поэтому, когда я начинал инспекцию, мне было совсем не интересно, как там правил код автор, и пытаться понять, каким образом автор пришёл к конечному решению — слишком дорого, в моём понимании.
Мы проводили инспекцию итогового решения:
1) удовлетворяет ли оно предъявляемым требованиям;
2) достаточно ли use-case’ов покрывают unit-тесты;
3) проверить код на отсутствие логических дефектов (например, конфигурация прибора читается до начала работы с ним);
4) проверить на применение правильных идиом (те же shared_ptr, отсутствие утечки ресурсов и применение RAII);
5) проверить корректную обработку граничных условий и обработку и сигнализацию ошибок (exception/return value).
Резюмируя, не припомню, чтобы комментарии к коммитам как-то помогали мне на инспекциях. Unit-тесты и комментарии к ним – да, doxygen комментарии к функциям/классам – да, комментарии в коммитах – нет.
Имхо, конечно.
Переименование/перемещение файла CC понимает как удаление старого и создание нового. Не совсем удобно.
Хотя такие ситуации возникают достаточно редко. У нас были заведены, например, шаблоны именования файлов.
С другой стороны, если файл разрастается, то в конечном итоге, он подвергается рефакторингу и делению на несколько файлов. Корректность copy-paste’а из старого файла в новый приходится отслеживать вручную.
Более подробно формализации use-case'ов инспекций кода у нас была посвящена предыдущая статья. В ней рассмотрены, в частности, межкомандные инспекции.
Этот пример я взял из личного опыта предыдущего проекта, и мне было просто удобно на нём продемонстрировать интерфейс CC.
На предыдущем проекте у меня часто были задачи поддержки какого-то нового оборудования. Например, нужно поддержать новый контроллер или прибор учёта какого-то производителя (например). В этом случае создавался каталог для этого счётчика и создавались файлы реализации логики конкретно этого прибора, которые потом попадали на инспекцию (мы вели разработку прямо в trunk’e). Мы создали очень хорошую объектную модель(что типа фреймворкa), у которой всё было разнесено по разным уровням абстракции, и для поддержки нового прибора чаще всего нужно было создать реализацию абстракций именно под этот конкретный прибор. Схема очень похожа на модель драйверов в ядре Linux'a. Там есть так называемый bus драйвер, ниже — драйвер контролера, ещё ниже — драйвер конкретной железяки. Добавление достаточно объёмных новых файлов у нас было нормальным явлением.
Заводилась одна большая задача, которая делилась на несколько небольших подзадач, по каждой подзадаче делались commit'ы и на каждую подзадачу создавалась отдельная инспекция. Деление проводилось по разным логическим единицам: поддержка чтения архивов, поддержка чтения журналов, поддержка чтения текущих значений и т.д.
Т.е. разработчик каждый день, когда хотел, коммитил свой код в репозиторий. Затем, когда приходило время инспекции, указывал все нужные ревизии в инспекцию.
Когда я инспектирую вновь добавленные файлы, в которые уже было сделано по несколько commit'ов, то хочу видеть последнее состояние файла без промежуточных изменений, которые для меня не интересны. Вот это как раз позволяет сделать СС автоматически.
К сожалению, всю прошлую пятницу хабр оставался для нас недоступен. Видимо, корпоративный IP был зафильтрован в процессе масштабной борьбы с DDoS-атаками. Сейчас ситуация изменилась, и в ближайшее время предоставим вам автора ;-)
Еще раз, огромное спасибо за вопросы и комментарии!
Напишу именно про себя и свой опыт.
Когда мы использовали схему отслеживания commit’ов, то часть commit’ов оставлась в репозитории не проверенной.
Иногда в «запарке», я откладывал проверку на потом, а там ещё commit’ов накидали и старые уже просто лень смотреть совсем, и этого потом так у меня и не наступало.
Поэтому, дабы дисциплинировать себя самого, мы использовали инструмент, чтобы это «потом» однозначно наступало рано или поздно.
Ещё инструмент позволяет удобно отслеживать всю историю изменений и общения по конкретным блокам кода. В почтовой программе такого удобства, к сожалению, нет.
Инструмент позволяет работать с изменениями наподобие wiki движка: все комментарии видны, удобство обсуждения и хорошо отслеживается история изменений по ходу общения.
Меня в свою команду вы, видимо бы не взяли :)
1. Мы реализуем новый функционал в отдельных ветках.
2. Каждая большая задача всегда разбивается на подзадачи.
3. Разработчик отдаёт код на инспекцию вменяемыми законченными частями.
4. Приоритет на инспекцию у нас ниже только критических уязвимостей.