Рассмотрена связка CMS Drupal с инструментарием разработки контента на основе единого исходника (источника) - single source - программы AuthorIT. Показаны преимущества применения связки CMS Drupal + AuthorIT (для сайтов с большим числом страниц) по сравнению с традиционным созданием контента с помощью CMS Drupal + CKeditor. Редакция от 12.06.2016.
Создан 13.12.2010 16:54:51
Клиента не волнует то, чтО и как ты умеешь делать,
Клиента волнует лишь то, чтО он может с этого поиметь...
© Мудрый PRаст
Статья ориентирована на пользователей Drupal, не имеющих представления об инструментариях на основе single source, в частности, о программе AuthorIT. Детали применения Drupal не рассматриваются, сведения о single source и AuthorIT изложены кратко: ссылки на материалы про AuthorIT имеются, любой желающий может по ним пройтись.
Именно поэтому повествование начнется с голословного перечисления преимуществ связки CMS Drupal + AuthorIT по сравнению с CMS Drupal + CKeditor, а затем эти преимущества будут обоснованы. Но сначала вкратце о single source и AuthorIT, а также о реализации CMS Drupal + AuthorIT.
Вкратце о single source и AuthorIT
Не обнаружив в сети узаконенное определение single source, автор попытался самостоятельно раскрыть это понятие. Итак, single source есть технология разработки документов. Суть технологии single source заключается в многократном повторном использовании всевозможных объектов - текста, графики, ActiveX, гиперссылок, файлов (и еще много чего) в любом количестве в различных документах (в любом их количестве).
Многократное повторное использование - это самое главное. Но оно как бы скрыто под единым источником, предполагающим всего лишь возможность публикации в электронные документы различных форматов, см. рисунок внизу подраздела.
AuthorIT - одна из программных реализаций технологии single source (есть еще Serna, DocBook и прочие бесплатные, но менее удобные программы). Визуально интерфейс AuthorIT напоминает интерфейс обычного текстового процессора типа ворда или OpenOffice, см. рисунок ниже.
Верхняя часть скриншота - окошко программы AuthorIT, с помощью которой и подготовлена настоящая статья. В нижней части - эта же статья, опубликованная из AuthorIT в файл ворда. На первый взгляд каких-либо существенных различий не видно. Как и суслика. Но суслик есть!
- в ворде можно просматривать документ с помощью линейки вертикальной прокрутки и щелчками мыши по структуре документа;
- в AuthorIT такой фокус не пройдет. Прокрутка работает только в пределах одного элемента структуры документа, в данном случае - в объекте с заголовком Вкратце о single source и AuthorIT. Переключаться между объектами можно только двойным щелчком по элементам структуры документа;
- ворд является тривиальным текстовым процессором, работающим с отдельным файлом (или их множеством);
- AuthorIT является программной оболочкой - системой управления базой данных формата Jet. По своей сути AuthorIT - тот же Drupal, только структура его базы данных скрыта от посторонних глаз.
Таким образом, любой документ AuthorIT (в терминологии программы - book, книга) НЕ ЯВЛЯЕТСЯ СПЛОШНЫМ ТЕКСТОМ, А СОСТОИТ КАК БЫ ИЗ ОТДЕЛЬНЫХ КИРПИЧИКОВ - объектов (topic - топиков в терминологии программы). При публикации из AuthorIT получается некий связный (или не очень) текст наподобие приведенного выше. Форматы, в которые AuthorIT умеет публиковать свои книги, приведены на рисунке ниже.
Немного о терминологии AuthorIT:
- базовым элементом AuthorIT является библиотека - файл формата *.adl - которая включает в себя книги;
- книга -
- а книг может быть множество, их можно вкладывать одну в другую, образуя иерархию - содержит топики; - топики -
, 
- текстовый топик, изображение и другие - образуют иерархическую структуру книг; - при этом - ВАЖНО! - каждый элемент библиотеки имеет уникальный код объекта (Object Code), который не изменяется ни при каких обстоятельствах - код присваивается каждому элементу библиотеки автоматически, раз и навсегда, на все время существования библиотеки (см. жизненный цикл продукции).
После публикации книги в любой формат (кроме help) книжка превращается в отдельный файл (статью в терминологии Drupal).
Теперь о самом главном.
Single source и AuthorIT: о самом главном
- Ваш идеал женщины?
- 90-60-90, тонкие пальцы на руках, пятки в пределах обуви...
Из одного интервью
Технология single source обеспечивает возможность МНОГОКРАТНОГО ПОВТОРНОГО ИСПОЛЬЗОВАНИЯ одних и тех же топиков в разных книгах, находящихся в пределах одной библиотеки (как пятки в пределах обуви) 
. Если все сказанное пояснить словами, то с помощью программы AuthorIT можно внедрять топики любого типа в разные книги, см. рисунок ниже.
На рисунке топик + (3) отсутствие четкого понимания предмета разработки внедрен сразу в три книги: «Исследования компании «Техническая документация»», «Изучение объекта документирования» и «Что такое...». Пройдясь по ссылкам, можно увидеть, как выглядят после публикации три соответствующие книгам статьи на сайте. Если содержимое внедренных топиков по той или иной причине изменяется, то во всех книгах, содержащих данные топики, после их (книг) публикации также изменится содержимое.
И несколько слов о реализации связки CMS Drupal + AuthorIT.
Несколько слов о реализации связки CMS Drupal + AuthorIT
Небольшое отступление: AuthorIT сам по себе является системой управления контентом, с его помощью можно строить громадные и информативные сайты, но есть существенный недостаток - AuthorIT публикует html-контент в страницы с frame, что давно уже не модно, не популярно, да и отношения поисковых систем к сайтам с фреймами сомнительное...
Связка CMS Drupal + AuthorIT реализуется в четыре этапа (при ПЕРВИЧНОЙ подготовке контента):
- на 1-м этапе с помощью программы AuthorIT подготавливается ПЕРВИЧНЫЙ контент сайта в виде книг. В книгах может быть множество внедрений текстов, графики, внешних и внутренних гиперссылок. Все перечисленные объекты, как было показано выше, обладают собственным уникальным кодом объекта - Object Code. Если в настройках html-публикации AuthorIT имя публикации не указывается в явном виде, то имя файла опубликованной статьи будет иметь вид <Object Code>.htm;
- на 2-м этапе готовый ПЕРВИЧНЫЙ контент (книги) публикуется программой AuthorIT в формат HTML Pages. Можно публиковать книги как по отдельности, так и в пакетном режиме, отметив флажками публикуемые книги и форматы их публикации, см. рисунок ниже;
- на 3-м этапе опубликованные статьи в виде набора html-файлов пакетно обрабатываются: из каждого файла удаляется все до тэга <body> включительно, а также все после тэга </body> (включительно). Очищенные html-файлы также пакетно сжимаются и заливаются по FTP в соответствующий каталог CMS Drupal;
- на 4-м этапе создаются статьи (страницы подшивки) в CMS Drupal, см. рисунок ниже. Название статьи тупо копируется из названия топика в AuthorIT и вставляется в поле Название, уникальный Object Code анонса статьи вставляется вместо ХХХХ в конструкцию <?php include ('html/XXXX.htm'); ?>, точно так же вставляется и уникальный Object Code самой статьи. Затем указывается формат ввода PHP code и прочая известная пользователям Drupal атрибутика страницы подшивки. Обязательно заполняется поле Настройка адресов - вводом цифр из поля Object Code. Четвертый этап повторяется для всех ВПЕРВЫЕ опубликованных статей, а потом - для каждой ВНОВЬ публикуемой на сайте статьи.
Вот и все, собственно... Теперь маленький, но важный нюанс: поскольку значение поля Object Code уникально, книжке с кодом 6740 соответствует html-файл 6740.htm и статья с адресом http://root/6740, поэтому ссылку на статью AuthorIT «знает» заранее: статья, допустим, еще даже не создана в Drupal, но адрес ссылки на нее уже известен. root в строке адреса заменяется адресом сайта в ходе пакетной обработки html, поэтому, при желании, можно любую статью разместить на любом из сайтов, созданных на Drupal, Joomla! и иных движках, поддерживающих вставку конструкции <?php include (...); ?>. Можно вместо root вставить переменную $HTTP_HOST, любой из перечисленных выше сайтовых движков будет «подхватывать» статью автоматически.
Чуть-чуть о ссылках. Ссылки AuthorIT находит поиском по выделенному фрагменту текста, что очень удобно при их вставке в тексты статей.
Теперь о ВТОРИЧНОМ контенте. Иногда появляется желание «перелопатить» тексты ранее опубликованных статей, что-то подправить, что-то изменить. Допустим, в нескольких статьях фигурирует гиперссылка, оказавшаяся битой. Ссылку, разумеется, необходимо скорректировать, а затем повторно опубликовать с помощью AuthorIT статьи, в которые включена данная ссылка. Далее производится чистка html-контента и оправка его по FTP в структуру каталогов сайта на Drupal'е. В самом Drupal'е уже ничего делать не нужно, поскольку вся атрибутика его статей давно уже сохранена в соответствующих таблицах базы данных MySQL.
Про реализацию все.
Преимущества применения связки CMS Drupal + AuthorIT по сравнению с Drupal + CKeditor
Предъявите Ваши доказательства!
© Красная жара
Все познается в сравнении
© Классик марксизма-ленинизма
Преимущества применения связки CMS Drupal + AuthorIT по сравнению с CMS Drupal + CKeditor:
- Разрабатывать (и сопровождать) содержимое сайта связкой CMS Drupal + AuthorIT лучше, чем с помощью CMS Drupal + CKeditor, если речь идет о сайтах с большим количеством страниц;
- Хранить (и восстанавливать) контент сайта в базе данных AuthorIT лучше, чем в базе данных CMS Drupal;
- Разрабатывать мультиязычные сайты связкой CMS Drupal + AuthorIT лучше, чем с помощью CMS Drupal + CKeditor;
- Поисковым системам контент сайтов, разработанных связкой CMS Drupal + AuthorIT, кажется «вкуснее», чем контент сайтов, разработанных с помощью CMS Drupal + CKeditor;
- Организовывать мультисайтинг с помощью CMS Drupal + AuthorIT лучше, чем с помощью CMS Drupal + CKeditor;
- Какие-нибудь еще преимущества...
Разработка контента с помощью CMS Drupal + CKeditor и CMS Drupal + AuthorIT. Внедрение ссылок на объекты в объекты
Контент портала, построенного с применением CMS Drupal, часто разрабатывается при помощи «визивигового» редактора CKeditor. Модуль CKeditor хорошо известен пользователям CMS Drupal, поэтому подробно останавливаться на нем не имеет смысла. Имеет смысл указать лишь одну особенность - автор данной статьи не обнаружил среди функционала CKeditor возможности внедрения в тело любой отдельно взятой страницы подшивки (статьи) текста любой другой отдельно взятой страницы (или ее фрагмента). Речь идет, разумеется, о модуле, скачанном с сайта разработчика.
В то же время программа AuthorIT обеспечивает такую возможность. Почему же акцент делается именно на возможности внедрения?
Все просто. Открываем произвольно выбранную страницу сайта, например «Как писать техническое задание?!» Автору, разумеется, известно, что на указанную статью существует масса ссылок из иных статей, размещенных на сайте. Возможно, глубокие знатоки Drupal смогут легко вычислить количество статей, ссылающихся на данную. Но автор - простой пользователь Drupal, стремящийся использовать типовые настройки готовых программных модулей без какого-либо их тюнинга. По роду деятельности у него нет ни возможности, ни особого желания вникать во все тонкости Drupal, потому он пойдет другим путем...
Открываем AuthorIT, отыскиваем одноименную ссылку на статью, шлепаем по ней правой кнопкой мыши, в меню выбираем пункт Show Relationships..., результат - на рисунке ниже.
Ссылка на статью «Как писать техническое задание?!» внедрена в восемь (!) текстовых фрагментов (топиков), а также на статью ссылается одна картинка. Предположим, адрес ссылки на статью по каким-то причинам был изменен. Спрашивается вопрос: как с применением CKeditor внести изменения во все девять объектов? Ответ очевиден:
- Отыскать все статьи (объекты), содержащие указанную ссылку;
- Поочередно открывая объекты в CKeditor, вручную исправить адрес ссылки в каждом из объектов.
Теперь посмотрим, как это делается в AuthorIT:
- Открывается собственно объект-ссылка, см. рисунок ниже;
- Вместо 1349 вводится новое значение адреса ссылки;
- Изменения сохраняются нажатием кнопки Ок;
- После чего все девять объектов пакетно публикуются и сливаются по FTP в файловую систему сайта.
Что в итоге:
- в первом случае мы теряем время на поиск статей (объектов), на открытие их в CKeditor, изменение адреса ссылки и сохранение всех девяти объектов;
- во втором случае мы открываем ссылку, единожды правим ее и спокойно курим, пока контент автоматически публикуется, чистится и сливается на сайт.
Казалось бы, особой выгоды нет. Но! Открываем страницу http://tdocs.su/tracker, см. рисунок ниже.
Простым перемножением 41 (число страниц) на 25 (число статей на странице) выясняем, что на tdocs.su всего имеет место быть 1025 статей-страниц подшивок. Неплохо, да?
Теперь дадим волю фантазии. А что, если в каждой из 1025 статей придется изменить адрес ссылки? 
С помощью AuthorIT, как было показано выше, все делается в один прием, легким движением руки. А в CKeditor?
Пример из практики - не так давно Форум проектировщиков и разработчиков технической документации переехал с домена authorit.ru на домен author-it.ru. Пришлось, разумеется, изменить ссылку на форум в контактной форме tdocs.su, внедренной в огромное количество статей, см. рисунок ниже.
Стоит обратить внимание на положение ползунка вертикальной линейки прокрутки - статей значительно больше, чем уместилось в скриншоте. Как разрулить ситуацию в AuthorIT, уже, наверное, и младенцу понятно... А вот как это сделать в CKeditor?
Разработка контента с помощью CMS Drupal + CKeditor и CMS Drupal + AuthorIT. Внедрение объектов в объекты
Внедрение объектов в объекты - тема мощная и весьма актуальная. AuthorIT обеспечивает возможность внедрения объектов в объекты как минимум двумя изящными способами. Возможно ли такое в CKeditor - автору доподлинно неизвестно.
По-научному такое внедрение называется многократным повторным использованием. Внедрение объектов в объекты с применением AuthorIT возможно:
- внедрением объекта в структуру другого объекта, см. рисунок ниже;
- внедрением объекта непосредственно в объект, см. рисунок ниже.
В первом случае объект - текстовый топик с названием + (5) п. 5.1 ГОСТ 34.003-90 с картинками внедрен в структуру книги «Оценка качества технической документации» и в структуры еще четырех книг. Книги после публикации становятся соответствующими статьями на сайте. Как видно в окошке Show Relationships, указанный текстовый топик входит в состав пяти статей, размещенных на tdocs.su.
Снова дадим волю фантазии - представим, что в этой стране все снова встанет с головы на ноги, Ростехрегулирование (бывший Госстандарт) займется модернизацией 34-го комплекса ГОСТов, и в указанный выше пункт ГОСТа будут внесены изменения. Задача автора - внести руками изменения в текст топика и опубликовать все пять статей, в структуры которых топик внедрен. И вся любовь.
Во втором случае текст одного объекта внедрен непосредственно в текст другого объекта - внедренный текст автоматически выделяется серым цветом.
Возможен вопрос: а для чего все эти внедрения? Ответ: а для того, чтобы избавить себя от рутинной работы. При изменении содержимого любого топика, внедренного тем или иным способом в несколько статей (книг), содержание этих книг после их публикации автоматически изменяется согласно изменениям в топике. Один топик используется многократно и повторно. Но самое главное состоит в том, что из отдельных объектов-топиков можно СОБИРАТЬ статьи, как домик из отдельных кирпичиков - быстро и просто.
Рассмотрим, к примеру, структуру статьи «Что такое автоматизированная система. Часть I - состав в картинках» - статья практически полностью СОБРАНА из отдельных топиков - пунктов ГОСТ 34.003-90. С минимумом писанины.
Отсюда вывод: разрабатывать (и сопровождать) контент сайта связкой CMS Drupal + AuthorIT лучше, чем с помощью CMS Drupal + CKeditor, если речь идет о сайтах с большим количеством страниц.
Хранение и восстановление контента сайта в базах данных CMS Drupal и AuthorIT
Не стоит держать все яйца в одной корзине...
Мудрая латинская поговорка
Страницы сайта, создаваемые с помощью CMS Drupal + CKeditor, ПОЛНОСТЬЮ хранятся в базе данных Drupal. Страницы сайта, создаваемые с помощью CMS Drupal + AuthorIT, хранятся раздельно: атрибутика страниц - в БД CMS Drupal, подсасываемый оператором include html-контент - в файловой системе, дубль этого контента - в БД AuthorIT на локальном компьютере. Что лучше?
Можно, конечно, тряхнуть стариной и сделать расчет надежности хранения, но в данном случае очевидно, что второй способ куда лучше. Ведь базы данных MySQL, как и любые другие, иногда очень ловко «падают». Хостинг-провайдеры могут сколь угодно долго утверждать, что все БД пользователей денно и нощно резервно копируются, но так ли это? Из личного опыта: однажды tdocs.su, размещенный тогда еще на нтхост.ру, рухнул из-за сбоя (или отказа) MySQL. В результате семидневной войны с техподдержкой тамошние админы восстановили-таки сайт из резервной копии БД недельной (!!!) давности. Автор потерял тогда атрибутику порядка трехсот статей-страниц подшивок.
Далее. Устав от войн с нтхост.ру, на котором tdocs.su либо перманентно лежал из-за недостатка оперативной памяти (всего 64 Мб выделялось), либо генерировал страницы в течение 8-10 с, автор бежал на it-patrol. БД были экспортированы с нтхост и закачаны на it-patrol. В результате экспорта БД Drupal была восстановлена нормально, а вот БД форума на phpBB импортировалась некорректно, в результате чего Форум проектировщиков и разработчиков технической документации лишился всех своих сообщений за 2010 год...
В апреле 2014 года пришлось сбежать и с it-patrol'а. На евробайт. Практика показала, что стабильная и шустрая работа последнего (используются SSD) значительно приятнее ласковой и внимательной техподдержки первого. Да и стоимость хостинга вполне разумная, а на патруле она была сопоставима со стоимостью коммунальных услуг московской квартиры, включая телефон, интернет, электроэнергию и т.д.
Таким образом, при хранении контента только в базе данных Drupal можно одним махом потерять все, а при хранении частей контента в разных базах и в файловой системе подобное невозможно принципиально. Резервно скопировать (восстановить) базу данных AuthorIT на внешний носитель (с внешнего носителя) - как два пальца об асфальт, опубликовать и заново залить контент в файловую систему - дело 10 - 15 минут. Иными словами, последствия отказа менее катастрофичны, а время восстановления минимально.
Подведем черту: в первом случае страницы пришлось бы восстанавливать полностью, а при применении AuthorIT потребовалось всего лишь восстановить значение поля Название, а в поле Содержание добавить соответствующие инклуды html-файлов, генерируемых AuthorIT и хранящихся в файловой системе Drupal в каталоге html.
Отсюда вывод: хранить контент в базе (или восстанавливать из базы) данных AuthorIT лучше, чем хранить в базе (или восстанавливать из базы) данных CMS Drupal.
Разработка мультиязычных сайтов связкой CMS Drupal + AuthorIT
При разработке мультиязычных сайтов с помощью CMS Drupal + CKeditor иногда получаются непонятки, особенно если включен модуль pathauto. Пришлось повозиться.
Путь к русскоязычной странице - http://author-it.ru/content/strashnaya-pravda-o-yuzabiliti-chast-i, к англоязычной - http://author-it.ru/en/content/terrible-truth-about-usability-part-i. Вроде бы все здорово, в итоге образовались человекопонятные URL, но вся деятельность по их настройке напомнила танец с бубнами. А если изменить хотя бы одну буковку в названии статьи, что станет с ЧПУ? Правильно, ссылки автоматически изменятся, но они не изменятся в других статьях сайта, которые ссылаются на первые две...
Для автора предпочтителен иной вариант: ссылка http://author-it.ru/1234 автоматически преобразуется при добавлении перевода в http://author-it.ru/en/1234. Так показалось проще. Поскольку AuthorIT изначально генерирует ссылки с цифрами вида <Object Code>.htm, то нечего было и заморачиваться. Кстати, AuthorIT имеет модуль локализации, потому все переводы русскоязычных текстов могут легко храниться в различных версиях топиков с одним и тем же Object Code.
Отсюда вывод: автору видится, что разрабатывать мультиязычные сайты связкой CMS Drupal + AuthorIT лучше, чем с помощью CMS Drupal + CKeditor, тем не менее вопрос требует дополнительной проработки.
Вопросы поисковой оптимизации
Вопросами поисковой оптимизации сайта tdocs.su автор целенаправленно не занимался. Вернее, занимался, но без особого фанатизма, прекрасно понимая, что ключевой момент в поисковой оптимизации - это качество самого контента сайта. Для начала приведем исходные данные, а затем покажем статистику от Google Analytics.
Доменное имя было зарегистрировано в январе 2010 г., см. рисунок ниже.
О дальнейшей грустной судьбе сайта: сначала он был припаркован к хостеру нтхост.ру. В течение двух месяцев были попытки установить Drupal, но, ввиду «неправильности» хостера, постоянных смен им настроек php.ini (без какого-либо уведомления клиента), малого количества выделяемой оперативной памяти сайт больше лежал, чем работал. Любая страница (при включенном-то кэшировании!) открывалась в течение 8-10 с, как уже упоминалось выше... В мае ситуация более-менее стабилизировалась, но потом пришло лето и автор сбежал к браткам-белорусам - спасаться от жары и смога... Интернет там есть, но до ближайшей сотовой вышки около 8 км, связь медленная и крайне неустойчивая, поэтому заниматься сайтом было попросту невозможно. Хорошо еще, если сообщения с пиджина уходили...
Реально заняться сайтом вплотную получилось только в августе, поэтому и приводится соответствующая статистика. График хостов (с характерными провалами в выходные дни и в моменты падений) приведен на рисунке ниже.
02 августа (Слава ВДВ!) число хостов составило 251 единицу, 09 декабря - 797. Более чем втрое за три месяца с небольшим. Характерно, что резкий рост числа хостов пошел 18 октября (а 15 октября был совершен побег с нтхоста на it-patrol). Судя по всему, сработал кумулятивный эффект: поисковики проиндексировали контент, а время генерации страницы значительно сократилось. Ниже - информация по источникам трафика (хосты за прошедшую неделю).
Неплохо, когда более половины трафика исходит от поисковых систем. Здесь все очевидно. Сложнее с сайтами-источниками переходов: индекс цитируемости застрял на десятке, реально ссылок с различных сайтов гораздо больше, но, судя по всему, в настройках этих сайтов ссылки вовне просто не индексируются. Прямой же трафик - это постоянные посетители ресурса.
Было бы здорово, если бы кто-нибудь из пользователей Drupal подсказал, как добыть информацию Search engine referers из сислога, тогда можно было бы похвастаться хорошими позициями сайта в поисковых системах по ключевым словосочетаниям.
Теперь о некоторых особенностях tdocs.su: сайт узкоспециализированный, заточен под разработку технической документации, изрядная часть статей является аутентичными текстами пунктов различных ГОСТов с указанием первоисточников (это и есть ключевые словосочетания - термины и определения). Все статьи многократно ссылаются друг на друга, но, судя по всему, поисковые системы это не раздражает. В итоге получился сайт, устраивающий как посетителей, так и поисковые системы. Наверное, качественный в плане контента. Утверждать ничего нельзя, поскольку само определение качества контента сайта не имеет места быть 
Отсюда вывод: на основании показанной выше положительной динамики можно судить о том (но не утверждать), что поисковым системам контент сайта, разработанного связкой CMS Drupal + AuthorIT, кажется «вкусным».
Организация мультисайтинга с помощью CMS Drupal + AuthorIT
Организация мультисайтинга с помощью CMS Drupal + AuthorIT - тема отдельной статьи. Вкратце же можно сказать, что с помощью CMS Drupal + AuthorIT легко получилось настроить мультисайтинг с перечисленными ниже характеристиками:
- с единой базой с разными префиксами таблиц для объединения посетителей ресурсов;
- с общими модулями, темами, библиотеками;
- с общим (целиком или выборочно) контентом - при этом таблицы, содержащие контент, не расшаривались на два сайта, т.е. нет общих таблиц БД, содержащих контент. Вопросы общего контента были решены с помощью AuthorIT.
Итоги и ссылки
На текущий момент автором были обоснованы три из четырех преимуществ применения связки CMS Drupal + AuthorIT по сравнению с Drupal + CKeditor при создании и сопровождении контента сайтов. Если всплывет что-то еще, то настоящая статья будет скорректирована с учетом мнений читателей. А теперь ссылки:
- Автоматизация разработки ТД с применением инструментария на основе single source;
- Автоматизация разработки технической документации. Часть I;
- Автоматизация разработки технической документации. Часть II. Практика;
- Автоматизация разработки технической документации с применением AuthorIT. Учебное пособие.
Те читатели, кому, несмотря на «много буккф», удалось дойти до края, могут отдохнуть и расслабиться, послушав великолепную песню на стихи Николая Рубцова...