Logo    
Деловая газета CitCity.ru CITKIT.ru - все об Open Source Форумы Все публикации Учебный центр Курилка
CitForum    CITForum на CD    Подписка на новости портала Море(!) аналитической информации! :: CITFORUM.RU
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

25.05.2017

Google
WWW CITForum.ru
С Новым годом!
2001 г

Управление тестированием, разработкой и конфигурацией на основе Rational Change Request Management

Новичков Александр
http://www.interface.ru, http://www.compress.ru, http://www.cmcons.com
технический специалист, преподаватель УЦ Interface Ltd,
опубликовано в КомпьютерПресс 8'2001
опубликовано на сайте www.interface.ru

1.1 Введение

Идея написать данную статью в стиле "Follow Me" пришла в голову после писем, пришедших на мой адрес после публикации двух статей о технологиях Rational (см. КомпьютерПресс № 2'2001 "Средства тестирования" и № 5'2001 "Конфигурационное управление"). Смысл писем сводился к тому, что построить по технологиям Rational базу по тестированию и конфигурации возможно, только вот связать все это воедино непросто, и уж тем более нельзя на основе описанных продуктов говорить о какой бы то ни было управляемости с точки зрения руководства компании. Конечно же, упрек верный, но технологии Rational Software хороши тем, что любой их сегмент можно рассматривать как по отдельности, так и как часть большой мозаики. Сложив такую мозаику, вы получите полностью управляемое производство, на входе которого можно подать идею, а на выходе получить современный программный продукт. Сам процесс разработки при этом будет похож на производственный конвейер, где все течет, работает и подчиняется строго установленным правилам, где каждый участник проекта знает, что ему делать, и задачи от участника к участнику передаются не на словах, а при помощи специальных средств; соответственно, при такой передаче должна создаваться определенная база данных, в которой и будет храниться история проектов, - эдакий репозиторий проекта. Все вышеописанные проблемы может решить Rational Unified Process - RUP - интерактивная энциклопедия по построению качественного процесса выпуска программного обеспечения.

Рассмотрение RUP мы начали со средств тестирования для разработчиков, а продолжили конфигурационным управлением. Сегодня мы вкратце рассмотрим программный продукт, который сможет связать в единую цепочку разработчиков, специалистов по тестированию и их руководителей. Имя данного продукта - Rational ClearQuest.

1.2 Что дадут проекту CRM и ClearQuest?

Как известно, знание - сила. А на сегодня нам известно, что чем больше проект, тем менее он управляем. Как видите, зависимость здесь обратно пропорциональная. Согласитесь, что сотрудник, тестирующий продукт, должен иметь инструмент, который позволит описать любую найденную в продукте ошибку, разработчик должен, используя сведения, полученные от группы тестирования, исправить модуль, где найдена ошибка, а руководитель, в свою очередь, должен знать, во-первых, кто чем в данный момент занят, а во-вторых, какое количество ошибок и какого рода сопровождают ту или иную версию проекта.

Проблема до боли знакомая, и каждая компания решает ее по-своему, изобретая порой то, что уже есть и работает… Давайте посмотрим, что предлагает Rational.

ClearQuest - это средство управления запросами на изменение (Change Request Management - CRM), специально разработанное с учетом динамической и сложной структуры процесса разработки ПО. ClearQuest предназначен для отслеживания и управления любым типом действий, приводящим к изменениям в течение всего жизненного цикла продукта, помогая тем самым создавать качественное ПО более предсказуемым образом.

ClearQuest представляет собой многомодульное приложение, которое собственными средствами создает базу данных проекта и заносит в нее все изменения. Он поддерживает СУБД ведущих производителей, в частности Oracle, Microsoft и Sybase.

Смысл работы продукта прост и прозаичен. Основная информационная единица - дефект - это найденная ошибка в продукте или описание какой-то его особенности. Дефект заносится в систему пользователем, обнаружившим его. У каждого дефекта есть определенный набор состояний, по которым руководство может как отследить историю проекта, так и оценить текущее положение дел.

Состояний у дефектов всего пять. "Подан" (Submitted) - описание дефекта только что внесено; "Назначен" (Assigned) - описание передано определенному сотруднику. Начало работы над запросом переводит его в "Открытое" состояние (Open), и вся команда может видеть, что кто-то обрабатывает запрос. Наконец, когда запрос проверен и закрыт, он проходит соответственно стадии "Проверка" (Verify) и "Закрыт" (Resolved).

Состояния способны указать только на статус того или иного дефекта, а вот дотошно описать его помогут лишь специализированные поля. Любой дефект содержит определенное количество описательных полей, причем если использовать ClearQuest совместно со средствами тестирования, то при обнаружении ошибки данные продукты сами заполняют все необходимые поля. Чтобы вы не посчитали автозаполнение недостатком системы, скажу, что наряду с автозаполнением в ClearQuest предусмотрено и ручное внесение описания дефектов в систему, при котором вся ответственность за поданную информацию лежит на операторе.

Итак, дефект получает идентификационный номер и набор описательных данных. Вот краткий список того, что можно передать в качестве описания к дефекту.

    State - текущий статус дефекта (закрыт, открыт, в работе...).

    ID - идентификационный код дефекта. Воздействовать на это значение пользователь не может, поскольку система присваивает номер автоматически.

    Headline - комментарий к дефекту. В случае ручного ввода дается пользователем самостоятельно. При автоматической интеграции заполняется автоматически программой, обнаружившей дефект.

    RA - ассоциация с проектом (репозитарием). Необходима для ассоциации дефекта с требованием к системе.

    Priority - приоритет исправления дефекта. Этот параметр можно изменять по ходу проекта.

    Severity - критичность дефекта. То есть на первом этапе дефект можно определить как некритичный и исправить в последнюю очередь либо в последующей версии. Этот параметр также можно изменять по ходу проекта.

    Owner - владелец дефекта. Здесь следует отметить такую особенность: ClearQuest имеет два контрольных поля - Submitter и Owner. Причем первое поле содержит имя пользователя, который активизировал ошибку, а второе - имя пользователя, который должен эту ошибку исправить.

    Keyword - набор ключевых слов для данного дефекта. Специальный механизм, позволяющий конкретной компании вводить в обиход свой набор ошибок и приводить их в состояние ассоциативной связи с ошибкой в ClearQuest.

    Symptoms - признак дефекта (Cosmetic Flaw, Data Corruption, Data Loss, Slow Performance... и т.д.). Заранее предопределенные типы.

    Description - описание проблемы, комментарий.

    Resolution - способ разрешения проблемы (fixed/nofixed).

    Attachment - сюда можно присоединить любой документ (скажем, код программы).

    History - история внесения изменений в дефекте.

    TestData - определенный набор сопроводительных документов. Заполняется либо вручную, либо автоматически средствами тестирования.

    Environment - среда сопровождения. Здесь можно определить тип операционной системы, тип процессора, при которых проявляется дефект.

    Requirements - здесь можно задать связь дефекта с требованием из RequisitePro.

    ClearCase - связь дефекта с конкретной версией файла. Данный модуль появляется только при правильной настройке ClearQuest и ClearCase (см. ниже).

Рисунок 1. Внесение нового дефекта

На рис. 1 показано диалоговое окно, возникающее при вводе или изменении дефекта. Как видите, окно включает большое число закладок, подавляющее большинство которых уже описано выше.

Итак, посмотрим, что даст ClearQuest каждому участнику проекта:

  • тестировщику - механизм внесения найденных ошибок, причем достаточно разветвленный, поскольку ClearQuest имеет возможность вносить описания ошибок удаленно, например непосредственно через Интернет либо посредством e-mail-нотификации;
  • разработчику - возможность видеть все ошибки, найденные тестировщиками, и исправлять их, а результат документировать при закрытии диалога;
  • руководителю - возможность контролировать ход проекта и получать отчеты установленного образца.

1.3 Начинаем работать с ClearQuest

Здесь мы опишем механизм, при помощи которого можно "заставить" работать ClearQuest. Естественно, что подробное описание выходит за рамки данной статьи, но попробуем сделать это кратко. Итак, наиболее простой способ подготовить проектную основу и сконфигурировать ее - использовать Rational Administartor, позволяющий посредством нескольких шагов мастера полностью подготовить проект. Здесь воедино связываются метаданные для тестирования, а также требования к системе, по которым потом тестировщики создадут низкоуровневый план тестирования, сгенерируют скрипт тестирования, базу ClearQuest и присоединят модель из Rational Rose.

На этапе создания базы необходимо указать тип формата базы данных и местоположение генерируемого файла (для примеров я использовал MS Access), а также тип схемы, по которой она будет строиться. Число доступных схем - примерно 7-8, но может варьироваться вместе с новыми версиями продукта. Из основных схем хочется отметить Enterprise и DefectTracing. Первая предусматривает набор правил, по которым схема будет работать со всеми продуктами, так или иначе описанными в RUP. Вторая предназначена только для использования возможностей документирования дефектов. Мы выбираем схему Enterprise, задаем логическое имя базы. На последнем шаге создаем пользователей и группы, а также описываем права доступа.

Теперь необходимо запустить ClearQuest и провести еще ряд действий, создать запрос Query (правила создания запросов одинаковы для всех баз данных, и здесь мы их не рассматриваем) и наконец, попытаться зарегистрировать дефект.

Мы выполнили только основные шаги по получению базы данных. Но их достаточно, чтобы создать работающий CRM.

1.4 ClearQuest и средства тестирования

Как говорилось в одной из моих предыдущих статей (см. КомпьютерПресс № 2'2001 "Средства тестирования"), Rational имеет два типа средств тестирования: для разработчиков и тестировщиков. Хотя зависимость здесь не жесткая, да и роли участников конкретного проекта могут варьироваться.

Со всеми средствами ClearQuest начинает работать, как только создана база данных. Различия от продукта к продукту заключаются только в способе заполнения полей. ClearQuest вызывается автоматически, при нажатии правой клавиши на описании той или иной ошибки.

Здесь хочется обратить ваше внимание вот на что: ClearQuest не может сам в автоматическом режиме занести все ошибки, обнаруженные средствами тестирования, - этим должен заниматься человек. Иными словами, разработчик может вносить, а может и не вносить описание дефекта. Обычно предполагается, что разработчик должен только исправлять ошибки и неточности, на которые ему указывают тестировщики. Естественно, с этим можно поспорить, но продукт позволит применить любой подход. За вами - выбор, соответствующий традициям, сложившимся в вашей компании.

Как уже говорилось выше, средства тестирования сами способны заполнить сопроводительные поля. Если такое средство, как Rational Purify, способно дать лишь заголовок ошибки, то Rational Robot может уже заполнять поля согласно тому, какой скрипт в какой версии нашел ту или иную ошибку. Тестировщику для получения полной картины тестирования останется только задокументировать тип процессора, тип системы и описать, с какими из сторонних программных средств проводилось совместное тестирование. Само собой разумеется, что все проблемы по хранению таких данных возьмет на себя ClearQuest.

Построить же график по ошибкам или сделать выборку по определенным операционным системам способен любой, кто хоть раз работал с базами данных.

Итак, тестировщики получают инструмент архивации сведений обо всех дефектах, способный провести анализ информации по заданным критериям.

1.5 ClearCase и ClearQuest

Данный набор продуктов позволяет разработчикам не просто исправлять определенные версии файлов, выводя их для этого в состояние Check-out, но и ассоциировать то или иное исправление в соответствии с теми дефектами, которые описаны в системе. Кажущийся сам по себе простым, данный механизм поможет извлечь из проекта всю информацию по ошибкам и изменениям, приведшим к их исправлению либо к порождению новых. Всю информацию можно извлечь подобно поднятию виноградной грозди за верхушку, рассматривая ее с разных сторон!

Здесь скрывается первый подводный камень - Rational предлагает для решения проблем с "change set" две методики: UCM (Unified Code Management) и ClearCase Base. О достоинствах каждой из них мы поговорим в одной из следующих статей, а сейчас остановимся только вот на чем: UCM предлагает универсальный подход и содержит в себе правила быстрого построения проектов установленного образца. UCM уже предопределил все роли и действия, а также осуществил интеграцию ClеarCase с ClearQuest. UCM - это попытка Rational осуществить унифицированный подход к тестированию. Но в погоне за универсальностью UCM потерял ряд важных черт, главная из которых - гибкая настройка под конкретный процесс. Тем не менее UCM развивается, улучшается, но для больших компаний со сложной инфраструктурой пока не совсем пригоден. Поэтому мы рассмотрим вариант интеграции ClearCase Base с уже сконфигурированной базой в ClearQuest.

Сначала проведем интеграцию, а потом поговорим о концепции.

"Внедрение" продуктов друг в друга - процесс двусторонний. Сначала ClearCase настраивается с помощью модуля ClearCase ClearQuest Integration. В появившемся окне необходимо указать, с каким VOB будет проведена интеграция и какие операции будут попадать в базу. Например, можно сделать так, что в базу будут попадать только действия check-out, связанные с ветвью DEBUG, и так далее (рис. 2).

Рисунок 2. Диалог интеграции ClearCase. Слева изображен список вобов, а в центре типы запросов. Здесь можно отметить, что интеграция со стороны ClearCase проходит на уровне инсталляции в VOB триггеров, вызывающих ClearQuest

То есть здесь мы настраиваем реакцию ClearCase на то или иное событие. Соответствующим образом для каждого события будет вызываться список дефектов из ClearQuest, с которыми нужно проводить ассоциацию.

Но этой настройки мало. Теперь схему ClearQuest необходимо "научить понимать" события ClearCase. Делается это следующим образом.

  1. Запускается ClearQuest Designer.
  2. Загружается схема, по которой была сгенерирована база данных.
  3. Через меню Package подключается интеграция с ClearCase.
  4. Схема сохраняется.
  5. Делается обновление базы.

Теперь, как только пользователь даст команду CheckOUT, ClearCase не только попросит прокомментировать действия, но и предложит указать ассоциацию с определенным дефектом в базе ClearQuest. Значит, можно узнать, какие версии в ClearCase были порождены той или иной ошибкой.

Ассоциативные связи могут быть двух типов:

  1. Один файл, несколько проассоциированных дефектов.
  2. Несколько дефектов на основе одного файла.

Диалоговое окно, содержащее ассоциации, отображено на рис. 3.

Итак, мы получаем следующий алгоритм разработки программного обеспечения:

  1. Разработчик создает работающий код.
  2. Тестировщик (или разработчик) обнаруживает ошибку:
    1. заносит описание ошибки (defect) в базу данных;
    2. вносит тип ошибки и ее критичность;
    3. назначает ответственного.
  3. Разработчик исправляет ошибку:
    1. отыскивает в базе модуль и дефект;
    2. выводит соответствующий файл в состояние CheckOut и ассоциирует его с одним или несколькими дефектами;
    3. исправляет ошибку и помечает ее как исправленную (fixed).
  4. Руководитель проекта получает полную статистику о наличии ошибок в проекте, степени их локализации и критичности.

1.6 Заключение

Итак, при создании крупных проектов иметь в своем распоряжении только инструменты тестирования и конфигурационного управления в нынешних условиях разработки программного обеспечения уже недостаточно. Необходимо использовать не только индивидуальные средства разработки, но и средства и технологии коллективной работы.

Контролировать проект и объединять между собой тестировщиков и разработчиков поможет именно Rational ClearQuest.

Рисунок 3. Данное окно вызывается каждый раз при возникновении указанного в СС события. Здесь пользователь ассоциирует порождение новой версии с существующим дефектом, либо создает новый

 

Размещение рекламы — тел. +7 495 4119920, ICQ 232284597

Подписка на новости IT-портала CITForum.ru
(библиотека, CITKIT.ru, CitCity)

Новые публикации:

24 декабря

CITKIT.ru:

  • Новогодние поздравления
  • Сергей Кузнецов. Цикл Операционные системы: Ностальгия по будущему:

  • Алексей Федорчук. OpenSolaris 2008.11 Release

  • Сергей Голубев:

  • Евгений Чайкин aka StraNNik (Блогометки):

    17 декабря

  • С.Д.Кузнецов. Базы данных. Вводный курс

    10 декабря

    CITKIT.ru:

  • OpenSolaris 2008.11 Release

  • Альтернативные ОС: две грустные истории (С.Кузнецов)
  • Nokia N810 — доведение до ума
  • CitCity:

  • Платформа 2009: заоблачные перспективы Microsoft

    4 декабря

  • Лекция С.Д.Кузнецова Понятие модели данных. Обзор разновидностей моделей данных

    CITKIT.ru:

  • OpenSolaris 2008.11 Release. Первые впечатления

  • Linux vs FreeBSD: продолжим "Священные войны"?

  • Nokia N810 as is

  • Индульгенция для FOSS

  • Друзья СПО'2008

    26 ноября

  • Нечеткое сравнение коллекций: семантический и алгоритмический аспекты

    CitCity:

    CITKIT.ru:

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • 19 ноября

  • Проблемы экономики производства крупных программных продуктов

  • Язык модификации данных формата XML функциональными методами

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Заметки к книге:

  • FreeBSD: монтирование сменных устройств и механизм HAL
  • Текстовый редактор ee

    12 ноября

  • Правило пяти минут двадцать лет спустя, и как флэш-память изменяет правила (Гоц Грейф, перевод: Сергей Кузнецов)

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:
  • OSS в России: взгляд правоведа (В.Житомирский)

  • Новая статья из цикла С.Голубева "Железный марш":

    29 октября

  • О некоторых задачах обратной инженерии

  • Веб-сервисы и Ruby

  • Тестирование web-приложений с помощью Ruby

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

  • PuppyRus Linux - беседа с разработчиком (С.Голубев)

  • Сергей Кузнецов. Заметка не про Linux

    22 октября

  • Обзор методов описания встраиваемой аппаратуры и построения инструментария кросс-разработки

    CITKIT.ru:

  • Сергей Кузнецов. Почему я равнодушен к Linux

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • Что надо иметь
    3. Базовые познания

    CitCity:

  • Управление IT-инфраструктурой на основе продуктов Microsoft

    15 октября

  • Методы бикластеризации для анализа интернет-данных

    CitCity:

  • Разъемы на ноутбуках: что они дают и зачем их так много?
  • AMD Puma и Intel Centrino 2: кто лучше?

    CITKIT.ru:

  • Новый цикл статей С.Голубева
    Железный марш:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    8 октября

  • Автоматизация тестирования web-приложений, основанных на скриптовых языках
  • Опыт применения технологии Azov для тестирования библиотеки Qt3

    Обзоры журнала Computer:

  • SOA с гарантией качества
  • Пикоджоуль ватт бережет
  • ICT и всемирное развитие

    CitCity:

  • Пиррова победа корпорации Microsoft

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Статья из архива:

  • Я живу в FreeBSD (Вадим Колонцов)

    Новые Блогометки:

  • Перекройка шаблона Blogger или N шагов к настоящему
  • Blogger. Comment style
  • Screenie или глянцевый снимок экрана

    2 октября

    CITKIT.ru:

  • Сага о FreeBSD (А. Федорчук)

    Zenwalk: пакет недели

  • Банинг — интеллектуальное развлечение (С.Голубев)

    CitCity:

    25 сентября

  • Клермонтский отчет об исследованиях в области баз данных

    CITKIT.ru:

  • Пользователям просьба не беспокоиться... (В.Попов)

  • Снова про ZFS: диск хорошо, а два лучше
  • Командная оболочка tcsh (А.Федорчук)

    Zenwalk: пакет недели

    17 сентября

  • T2C: технология автоматизированной разработки тестов базовой функциональности программных интерфейсов
  • Технология Azov автоматизации массового создания тестов работоспособности

    CITKIT.ru:

  • FreeBSD: ZFS vs UFS, и обе-две — против всех (А.Федорчук)

    Zenwalk: пакет недели

  • Дачнет — практика без теории (С.Голубев)

    10 сентября

  • За чем следить и чем управлять при работе приложений с Oracle
  • Планировщик заданий в Oracle
    (В.Пржиялковский)

    CITKIT.ru:

  • Microsoft: ответный "боян" (С.Голубев)

  • Причуды симбиоза, или снова "сделай сам" (В.Попов)

  • Файловые системы современного Linux'а: последнее тестирование
  • Zsh. Введение и обзор возможностей
    (А.Федорчук)

    Описания пакетов Zenwalk: Zsh, Thunar, Thunar-bulk-rename, Xfce4-places-plugin, Xfce4-fsguard-plugin

    Блогометки:

  • Google Chrome
  • Лончер для ASUS Eee PC 701

    3 сентября

    CITKIT.ru:

  • Заметки о ядре (А.Федорчук):

    Добавлены описания пакетов Zenwalk: Galculator, Screenshot, Gnumeric, Pidgin

    В дискуссинном клубе:

  • И еще о Википедии и Google Knol

  • Лекция для начинающего линуксоида (С.Голубев)

    26 августа

  • Транзакционная память (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Открыт новый проект Zenwalk: пакет недели

  • Статья Текстовые процессоры и их быстродействие: конец еще одной легенды?

    21 августа

    CITKIT.ru:

  • Почему школам следует использовать только свободные программы (Ричард Столлман)
  • Беседа Сергея Голубева с учителем В.В.Михайловым

  • Википедия или Гуглезнание? Приглашение к обсуждению (Алексей Федорчук)
  • Народная энциклопедия от Google (StraNNik)

  • Обзор Mandriva 2009.0 Beta 1 Thornicrofti
  • Новичок в Линукс: Оптимизируем Mandriva 2008.1

  • Книга Zenwalk. Приобщение к Linux:

    13 августа

    CitCity:

  • Мирный Atom на службе человеку. Обзор платы Intel D945GCLF с интегрированным процессором
  • Обзор процессоров Intel Atom 230 на ядре Diamondville

  • iPhone - год спустя. Скоро и в России?

    CITKIT.ru:

  • Интермедия 3.4. GRUB: установка и настройка (из книги Zenwalk. Приобщение к Linux)

    6 августа

  • СУБД с хранением данных по столбцами и по строкам: насколько они отличаются в действительности? (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Интермедия 2.2. Что неплохо знать для начала (из книги Zenwalk. Приобщение к Linux)

  • И снова про шрифты в Иксах (А.Федорчук)

  • 20 самых быстрых и простых оконных менеджеров для Linux

  • Дело о трех миллиардах (С.Голубев)

    30 июля

  • OLTP в Зазеркалье (Пересказ: С. Кузнецов)

    CitCity:

  • Будущее BI в облаках?
  • Тиражные приложения и заказная разработка. Преимущества для заказчика
  • Дискуссия со сторонниками заказной разработки

    CITKIT.ru:

  • Новые главы книги Zenwalk. Приобщение к Linux:
  • Глава 8. Пакеты: средства установки, системы управления, системы построения
  • Глава 9. Zenwalk: репозитории, пакеты, методы установки

    23 июля

    CITKIT.ru:

  • Все против всех. 64 vs 32, Intel vs AMD, tmpfs vs ext3
  • Две головы от Intel

  • Zenwalk: обзор штатных приложений (глава из книги "Zenwalk. Приобщение к Linux")

  • Нормально, Григорий...

    16 июля

    Обзоры журнала Computer:

  • Перспективы и проблемы программной инженерии в XXI веке
  • Большие хлопоты с большими объемами данных
  • Перспективы наноэлектроники

    CITKIT.ru:

  • Интермедия о лицензиях (А.Федорчук. "Zenwalk. Приобщение к Linux")

  • Есть ли будущее у KDE?

  • Linux в школе: альтернативный вариант в задачах

  • Шифр (приключения агента Никодима)

    10 июля

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия вступительная. Linux или GNU/Linux? Как вас теперь называть?
  • Глава 5. Среда Xfce
  • Глава 6. Xfce: приложения и плагины

  • ZUR (Zenwalk User Repository) FAQ

    2 июля

  • Персистентность данных в объектно-ориентированных приложениях (С. Кузнецов)

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия 1.2. Дорога к Zenwalk'у. Период бури и натиска
  • Интермедия 3.3. Немного о Linux'е и "железе"
  • Глава 4. Настройка: инструментами и руками
  • Интермедия 4.1. Zenpanel и конфиги: поиски корреляции

  • Интервью с Жан-Филиппом Гийоменом, создателем дистрибутива Zenwalk

  • Linux в школе: первые итоги (С. Голубев)

    25 июня

    CITKIT.ru:

  • Zenwalk. Приобщение к Linux (А. Федорчук)

  • Логика и риторика (С.Голубев)

  • Технология Tru64 AdvFS

  • Ханс Райзер предлагает отвести полицейских к телу Нины

    18 июня

  • Проекты по управлению данными в Google (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • ОС и поддержка "железа": мифы и реальность (А. Федорчук)

  • Linux в школе: другие дистрибутивы

  • Пинок (С. Голубев)

    4 июня

  • Ландшафт области управления данными: аналитический обзор (С. Кузнецов)

    CITKIT.ru:

  • Linux в школе: слово заинтересованным лицам

  • SlackBuild: пакеты своими руками

  • Linux от компании Novell. Установка и обзор openSUSE Linux

    Все публикации >>>




  • IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

    Информация для рекламодателей PR-акции, размещение рекламы — тел. +7 495 4119920, ICQ 232284597 Пресс-релизы — pr@citcity.ru
    Послать комментарий
    Информация для авторов
    Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
    Copyright © 1997-2000 CIT, © 2001-2007 CIT Forum
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...