…это возможность распараллелить код инициализации подсистем по разным процессорам. Учитывая скорость распространения многоядерных процессоров это становиться актуальной задачей. Вынести большую часть кода из DllMain и конструкторов статических объектов не сложно. Достаточно оформить доступ ко всем подсистемам через singleton-подобный интерфейс, защищённый критической секцией. Сложнее – выстроить зависимости между подсистемами так, чтобы инициализация выполнялась как можно позже, когда все рабочие потоки созданы и готовы к работе.
Не менее важно и не перестараться с отложенной инициализацией. 30 секундное шуршание головками винчестера в ответ на безобидный щелчок мышью может вывести из себя даже спокойного пользователя. Или ещё хуже, удаленное приложение может оборвать соединение, так и не дождавшись ответа.
Posted at 4:40 pm •
Вот код, которым я пользуюсь для написания стресс тестов и фаззеров в своих проектах. Класс EntropyGenerator – обертка вокруг генератора случайных чисел.
(more…)
Posted at 10:02 pm •
Точка входа в DLL, так же как и точка входа в программу, - это очень специальное место. Зона. В Зоне действуют свои правила касательно того, что можно делать, а что делать нельзя. В Зоне можно инициализировать локальные данные DLL, можно создавать критические секции. В Зоне нельзя динамически загружать другие Модули или создавать потоки. Любой Сталкер знает и следует правилам Зоны. Все остальные рано или поздно нарушают правила и расплачиваются за это.
(more…)
Posted at 9:01 pm •
… почему программисты, уже озаботившиеся ведением подробного журнала о том, что, где и когда случилось, никак не позаботились о том, чтобы фатальные ошибки находились сразу, простым текстовым поиском? Нет ну серьезно, уровни важности сообщений – есть. Вывод сообщения на каждый чих – есть. Ключевые слова (trace, info, warning & error) – есть! Но найти что именно сломалось в этом многомегабайтном монстре никак не получается. Сообщений об ошибках либо нет, либо их очень много и не по делу. Или еще хуже – финальное сообщение «Ой! Тут что-то поломалось!» есть, а чем оно вызвано – нет. Или есть, но пару десятков тысяч строк текста тому назад…
P.S. Agrhh!
Upd: Нашел что падало. Банальный Access Violation. В логах - ничего. От отладчика его тоже спрятали. Ууу! Сатрапы!
Posted at 10:28 am •
Структура репозитория исходников типичного проекта обычно представляет собой дерево:
Основная ветка, от которой отходят ветки подразделений, команд и отдельных подпроектов. Новый код или исправления старого производятся в самых нижних ветках. Затем накопленные изменения перебрасываются в ветку, находящуюся выше по иерархии. При этом код проходит различные проверки, начиная от банальной «проверки временем», до прогона через формальный набор тестов различной сложности. Сложность и скрупулёзность проверок, как правило, растет при приближении к основной ветке. По мере надобности, от основной ветки отпочковываются ветки выпускаемых версий. Именно в них вносятся последние исправления и собирается финальная сборка продукта.
(more…)
Posted at 5:30 pm •
А не подскажет ли кто хорошего курса уроков/лекций по Java или C#, подходящий для человека, далёкого от программирования? Рассказывающий об основах, безо всяких, лишних поначалу, подробностей и деталей. Можно по-русски, можно по-английски. Нам без разницы.
Posted at 10:29 pm •
Юнит тесты, в отличие от многих других видов тестирования, обладают одной замечательной особенностью. Они обеспечивают практически 100% (a в теории - так точно 100%) повторяемость результатов. Грубо говоря, после успешного прогона тестов можно с уверенностью говорить, что покрываемые тестами сценарии работают. Гарантированная повторяемость важна для обнаружения быстрого регрессий, рефакторинга кода и множества других вещей. Как обычно, окунание в реальность сильно портит эту радужную картину.
(more…)
Posted at 3:03 pm •
