NGC 2170
Feb 28, 2007 · CommentsКосмос Сегодняшняя картинка на APOD: NGC 2170
На мой взгляд, Trac – одна из лучших, если не самая лучшая, bug tracking система для малых и средних по размеру проектов. Особая прелесть Trac состоит в том, что она органично объединяет вики, интеграцию с Subversion и ведение списка задач/ошибок. Именно то, что нужно команде для ведения проекта. Более того, стандартная функциональность позволяет организовать рецензирование кода, не смотря на то, что никакой специальной поддержки рецензирования в Trac нет.
Read On →Рецензирование кода (перевод подсмотрел у Лебедева) – это на мой взгляд одна из полезнейших и при этом наиболее легко внедряемых практик разработки надёжного кода. Основная идея рецензирования заключается в систематической (пере)проверке кода с целью найти ошибки, допущенные при его написании. И поскольку рецензирование кода относится к ранним этапам разработки, найденные ошибки «ценнее», чем, скажем, ошибки, найденные при формальном тестировании. Я не буду останавливаться на подробном описании процедуры рецензирования. В Интернете можно найти массу материалов по теме. Вот, например, страница из Википедии. Я же просто хочу поделиться своими наблюдениями.
Read On →На этой неделе попробовал поработать в Ubuntu – дистрибутиве Linux, который отпочковался от Debian. До этого на «машине для опытов» стояла Fedora Core (в девичестве - Red Hat Linux). Надо сказать, что впечатления от этого эксперимента довольно забавные. Фактически, Ubuntu и Fedora Core – это одна и та же система. Они используют практически идентичный набор программ - с точки зрения неискушенного пользователя, конечно. Понятно, что на Fedora Core можно поставить KDE вместо Gnome, да и менеджер пакетов у них разный. Всё равно это практически одна и та же система.
Read On →Вчера, укачивая дочку, пришла в голову светлая мысль, что искать баг в программе и успокаивать ребенка – одинаковое шаманство. Посудите сами, в обоих случаях индикация проблемы налицо: ребенок плачет, программа не работает. Однако никаких намеков на то, что именно не так не даётся. Ну и начинаешь пробовать по очереди все известные примочки: подгузник там поменять, взять последнюю версию исходников из репозитория, покачать на руках, подправить конфигурационный файл и т.д. Прямо хоть бубен (погремушку) доставай!
Read On →Когда я пришёл в Microsoft, команда, ответственная за ядро Dynamics AX (тогда ещё Axapta), куда я собственно и попал, как раз работала над повышением безопасности ядра. Сразу после старта мне «повезло» окунуться в этот процесс с головой. Как выяснилось, этот процесс совсем непрост, как могло показаться со стороны. Оказалось, что он отнимает массу времени, сил и вообще может надолго отбить желание писать надёжные программы. Я так думаю, что если бы мне пришлось участвовать в дискуссии про то «как Microsoft выпускает дырявые программы» в тот период, я бы не удержался в рамках приличия. :-)
Read On →Обычно при переносе 32-х разрядного приложения на 64-х битную платформу все исправления касаются только 64-х битного варианта. Однако бывают случаи, когда вполне корректно функционирующий 32-х битный код нуждается в правке только потому, что появился 64-х битный вариант программы.
Read On →Разделяемая память (shared memory) - очень удобный и популярный механизм обмена данными между процессами. Простота использования и скорость - основные причины этой популярности. Простота использования играет роль, когда объем передаваемой информации мал. Например, описатель глобального хука (см. SetWindowsHookEx) обычно передаётся через секцию разделяемой памяти. Скорость важна, когда остальные методы межпроцессового взаимодействия слишком медленны, ненадежны либо вносят большую чем надо задержку. Хороший пример - микшер, смешивающий аудио потоки из разных приложений.
Read On →