В последние годы мы видим, что ведущие поставщики средств разработки ПО (в первую очередь IBM Rational и Borland) от выпуска отдельных инструментов переходят к созданию комплексных платформ управления жизненным циклом приложений (application lifecycle management, ALM). Microsoft пока не форсирует процесс формирования полного спектра ALM-решений для автоматизации различных этапов производства ПО, хотя движется именно в этом направлении (об этом свидетельствуют последние новости с конференции TechEd'2004, см. врезку), и основной акцент делает на средствах проектирования и разработки - Visio, Visual Studio и т. д.
Однако для реализации идеологии ALM на практике необходим не только набор инструментов сам по себе, но и общая методологическая база. Microsoft уже более десяти лет занимается развитием собственной ALM-методологии под названием Microsoft Solutions Framework (MSF). Может показаться неожиданным, но MSF в целом - по сути платформно-независимая методология, детально описывающая отдельные процессы на уровне абстракций. Инструменты самой Microsoft присутствуют в ней в минимальной степени, лишь как примеры реализации тех или иных рекомендаций. Вместе с тем, хотя и неявно, концепция эта четко выражает общую нацеленность средств разработки корпорации (круг задач, для решения которых они предназначены), что очень хорошо видно из анализа динамики ее развития. Так, если десять лет назад MSF была ориентирована на создание локальных клиентских приложений, то сегодня - на разработку и внедрение сложных систем масштаба предприятия.
Структура процессов MSF
Говоря о моделях процессов жизненного цикла проектов разработки ПО, в первую очередь нужно упомянуть о двух основных схемах: водопадной и спиральной (рис. 1), которые отражают два разных подхода к организации этих работ.
Надеюсь, что в прошлый раз, хорошо ли, плохо ли, но ответ на вопрос "в чём суть COM-технологии" был сформулирован. Сегодня мы рассмотрим некоторые хорошие детали COM подробнее. Итак, в прошлый раз утверждалось - COM-объект, это объект, который доступен так же, как и "локальный" объект данного проекта, хотя, фактически, он не располагается в данном проекте, а есть уже готовый двоичный исполняемый ресурс. И в предыдущей же статье утверждалось, что он может располагаться где угодно. Там же говорилось, что это - некая DLL. Суровая правда состоит в том, что объект COM может располагаться действительно где угодно. И DLL - не единственная форма его существования. COM-объект может жить и внутри EXE-модуля, который может исполняться независимо (параллельно!) от модуля, который использует этот объект, и даже - этот самый модуль может исполняться совсем на другом компьютере! Вы где-нибудь видели подобное? И зачем это нужно?
Итак, "технология COM". Аббревиатура COM расшифровывается просто, это - Component Object Model - компонентная объектная модель. Иногда говорят и "модель COM". Сутью данной технологии является то,что программы строятся из компонент, которые состоят из объектов. Само по себе это обстоятельство не является последней новостью в области программостроения - модульная архитектура и объектно-ориентированный подход к построению программ давно являются признанными стандартами de facto. Новостью является то, что является этими компонентами и объектами - ими является непосредственно исполняемый двоичный код. Да-да, не " включаемые исходные тексты " компилируемые совместно с проектом, не " библиотеки стандартных программ ", присоединяемые линкером, а непосредственно исполняемые файлы, которые никак не надо "связывать" со своим проектом - их достаточно зарегистрировать в операционной системе и они будут доступны любой программе исполняющейся на данной машине. Т.е. их использование в своей программе производится " без использования операций сборки модуля ".
Linux: программирование в примерах — М.: КУДИЦ-ОБРАЗ, 2005 / Роббинс А. / 656 страниц
Разумная цена: 211 рублей
Не секрет, что правильный способ научиться программировать — почаще читать хорошо написанные программы. Вот и автор этой книги рассказывает об API системных вызовов Linux на основе реального исходного кода повседневно используемых программ. Ты видишь не только банальный синтаксис Linux API, но и копаешься в реальных проблемах производительности, переносимости и устойчивости, с которыми всегда сталкиваются при написании программного обеспечения. Правда, книга будет понятна только тем, кто разбирается в программировании и знаком с основами С. Ты изучишь базовые API, образующие ядро программирования под Linux: управление памятью, файловый ввод-вывод, метаданные файлов, процессы и сигналы, пользователи и группы, поддержка программирования (сортировка, анализ аргументов и т.д.) и интернационализация. Отдельно рассмотрены средства отладки, доступные под GNU Linux. В качестве иллюстраций — примеры кода из V7 UNIX и GNU.
Эта статья посвящена тестам Тьюринга. Для тех, кто еще не знает, это способ не допустить автоматизации выполнения каких-либо действий, которые должен делать пользователь. Тесты эти бывают графические и звуковые. В первом случае вам предлагается ввести число, слово или набор символов, написанный на картинке, а во втором произнесенный голосом. Генерируются картинки и звуки на сервере автоматически, а разобрать их никакая программа, по замыслу авторов, не может. Тесты Тьюринга нужны для борьбы со спамом на сервисе, где отправитель не платит за отправку сообщения и, таким образом, может осуществлять массовую рассылку, а также для защиты от подбора паролей методом грубой силы. В наше время только ленивый не писал о тестах Тьюринга и о методах их обхода. И многие программеры на практике имели дело с тестами Тьюринга: одни их реализовывали, а другие обходили. Причем результативная работа последних возможна, в основном, из-за некомпетентности первых. Я считаю возможной компьютерную реализацию механизма распознавания образов, сравнимого с человеческим, хотя не встречал ее описания в статьях о прохождении тестов Тьюринга, так что, имхо, все решения не будут гарантированно работать всегда. На некоторых сайтах я встречал абсолютно неграмотные реализации тестов, показывающие полное непонимание проблемы разработчиком и его незнание возможностей существующих методов распознавания образов, основанных на научной теории, существующей уже далеко не первый год. Некоторые реализации обойти можно путем простого сравнения заранее известных областей картинки с эталонами, несмотря на зашумленность и игру с цветами. Эти наблюдения побудили меня написать о тестах Тьюринга, уделив внимание обзору методов генерации тестов и методов их прохождения, т. е. распознавания образов. Поскольку задача написания теста Тьюринга состоит в противодействии существующим методам распознавания изображений или звуков, имхо, начать следует именно с их обзора.
Не для кого не является секретом что так называемые IRC боты вещь полезная во всех отношениях , начиная от поддержания работоспособности канала, до распределенных DoS атак и т.д. Существует куча всевозможных ботов под *nix , которые можно скачать настроить и запустить со спертого у товарища Unix Shell'а . Однако не всегда существует возможность докопаться до Unix Shell'a да и если честно несколько километровый конфигурационный файл от того же EggDrop пугает. Выход из слажившейся есть практически всегда. К примеру если вас все таки не пугает конфигурять EggDrop можете скачать его и в версии под винду. Сейчас же я раскажу свой собственный вариант решения поставленной задачи , может этот вариант и немного посложнее первого , но заодно и Experience повышу. Речь пойдет о написании IRC бота под всеми ненависные форточки (хотя по моему скромному мнению если руки кривые *nix не поможет). Ну программирование это дело второстепенное, каждый пишет как хочет и на чем хочет. Как известно ( может и нет ) для написания какого либо приложения для интернет можно пойти двумя путями:
ФОРМАТ XML, ПОЯВИВШИЙСЯ НА СТЫКЕ ТЫСЯЧЕЛЕТИЙ, ПОСЛУЖИЛ ТОЛЧКОМ ДЛЯ НОВОГО ЭТАПА ЭВОЛЮЦИИ В СФЕРЕ СЕТЕВЫХ ПРИЛОЖЕНИЙ. СЕГОДНЯ ИСПОЛЬЗОВАНИЕ XML — ЭТО НЕ ДАНЬ МОДЕ И НЕ БЕЗДУМНОЕ СЛЕДОВАНИЕ СОВРЕМЕННЫМ ТЕНДЕНЦИЯМ, А ТЩАТЕЛЬНО ПРОДУМАННЫЙ БРАК ПО РАСЧЕТУ
Инструменты XML
Работа с документами XML в языках программирования реализуется с помощью специальных компонентов — парсеров XML. Основная задача парсера — это умение создавать документы и предоставлять клиенту возможность навигации по элементам дерева документа (узлам и атрибутам). Сегодня существует множество парсеров для любого языка программирования, следовательно, XML-документы стали отличным механизмом для реализации обмена формализованными данными, независимого от языка и платформы. Например, для С++ можно вспомнить с десяток различных парсеров.
