Просмотр исходного текста страницы MediaWiki — Серебряная пуля или швейцарский нож?

;[[:Категория:Стас Фомин (Статьи)|Стас Фомин]]: Заместитель директора по информационным технологиям / stas@custis.ru

* «Mediawiki: Серебряная пуля или швейцарский нож?»<ref>Статья написана в июле 2008, к конференции SECR-2008, опубликована с сокращениями в [http://www.osp.ru/os/2009/03/8162918 «Открытые системы», апрель 2009]</ref>

== Аннотация ==

В последние годы наблюдается бурный рост использования ''Wiki''-систем, причем не только для агрегации знаний открытыми сообществами, для чего они были предназначены изначально, но и для процессов документирования и управления знаниями внутри компаний-разработчиков ПО. При этом, вики-системы зачастую заменяют «классические» системы документооборота и технологии генерации документации. Здесь мы выделим и проанализируем причины, по которым это происходит, и обозначим границы применимости — покажем минусы вики-систем, из-за которых они так и не стали «серебряной пулей», и выявим области, где использование вики-систем не только модно, но и действительно эффективно.

Далее, мы перейдем к вопросу выбора вики-системы для задачи построения внутрифирменной базы знаний, ведения документации и коммуникации с потребителями. На наш взгляд, в большинстве случаев оптимальным выбором будет MediaWiki. У этой вики-системы огромное количество пользователей и разработчиков, накоплен опыт использования и объем текстов. Открытая архитектура системы позволяет легко расширять возможности инструментами-расширениями и «срезать» неудобные углы в использовании.

И наконец, мы рассмотрим наиболее острые проблемы, встающие перед пользователями вики-систем и предложим свои решения.

Ключевые слова: документирование, коммуникация, управление знаниями, вики-системы, MediaWiki.

----
Mediawiki: silver bullet or swiss-army knife?

General-purpose Wiki systems are successfully used in last years for documenting and knowledge management in software companies. These systems were designed to aggregate knowledge in open communities. But now Wiki systems often replace «stereotype» document management systems and software documenting technologies.

We will discuss some reasons for this situation and point out some problems that limit application scope of Wikis. Wiki is not a «silver bullet» but we can outline application domains where Wiki may be effectively used. Then, we will consider how to choose Wiki system in order to build an internal corporate knowledge base, keep and maintain documentation and communicate with customers.

MediaWiki is an optimal choice for this purpose in our opinion, since it has a vast community of users and developers and a wealth of experience. Open architecture makes it possible to extend easily any functionality of MediaWiki and to «downsize» possible inconveniencies.

Finally, we will offer solutions for the most acute problems of «corporate wikiing».

'''Keywords''''''': authoring, documenting, knowledge management, Wiki systems, MediaWiki.

== Задачи ==

Рассмотрим по очереди задачи, возникающие в любой компании-разработчике ПО:

* эффективное документирование и взаимодействие с заказчиком или потребителем;
* построение внутренней информационной базы знаний.

=== Документирование и взаимодействие ===

Ранее было принято, что технической документацией занимается небольшая группа технических экспертов (технических писателей), владеющих технологиями верстки, публикации и групповой работы. 

http://netanyachess.com/dilbertru.20100405.png

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

<graph>
digraph G{
  
     rankdir=TB; node [style=filled, fillcolor="lavender", shape="rect" fontname="Segoe Print"]
     "Совместная работа"
     "Совместная работа"->"«IT»-команды"
     "Совместная работа"->"C заказчиком или \n другими «не IT»-участниками"
  
    "«IT»-команды"->"Эффективность"
      "Эффективность" [fillcolor=darkolivegreen1]
  
    "C заказчиком или \n другими «не IT»-участниками"->"Простота и доступность"
      "Простота и доступность" [fillcolor=cadetblue2]
  
    node[shape="egg"]
    "Эффективность"->"Параллелизм"  
    "Эффективность"->"Скорость" 
    "Эффективность"->"Гибкость" 
  
    edge [constraint=0 style="dashed"]
    "C заказчиком или \n другими «не IT»-участниками"->"Эффективность"
  
    edge [arrowtail="vee" arrowhead="vee" color="red" constraint=0 label="несовместимость"]
     "Эффективность"->"Простота и доступность"
    
}
</graph>


То есть важно, чтобы используемая технология обеспечивала возможность совместной работы, но для различных групп участников важными являются разные и конфликтующие между собой аспекты. Так, например, для основных или стержневых производителей документации, обозначенных на рисунке как «IT-команда», ключевым является фактор ''эффективности'', выражающийся в следующих аспектах:

;Параллелизм: возможность асинхронной работы с минимумом блокировок и других узких мест, что дает возможность масштабировать команду. Правильными практиками для этого аспекта являются использование систем контроля версий с ''неблокирующей'' моделью «Копирование-Изменение-Слияние», допускающей параллельную правку одного артефакта несколькими участниками. Отрицательными примерами могут служить схемы «согласование по email», «файлы на файл-сервере с блокировкой», «Word-документ на всех».

;Скорость: аспект технологии, ответственный за минимизацию затрат (человеко-часов, килокалорий, меганейронов) на условную единицу документации. Позитивные примеры — «написал несколько коротких строчек — диаграммы сами нарисовались, текст сам красиво отформатировался». Отрицательные — «выравнивать мышью маловажные диаграммы», «мучительно и монотонно переформатировать текст».
;Гибкость: цена внесения изменений должна быть ограничена и не более чем пропорциональна объему изменений. Хорошо, когда используются различные составные документы, шаблоны, автоматическое построение документации по программному коду (''literate programming'') или по схеме базы данных. Плохо, когда изменения надо проносить вручную и во множество различных документов.

С другой стороны, кроме «стержневых» участников процесса, обеспечивающих основной объем документации, не менее важна роль и остальных — представителей заказчика, бизнес-аналитиков, разово привлекаемых экспертов-рецензентов. ''Можно привести смелую метафору с «вытягиванием репки» — несмотря на то, что основную тяговую силу составляет стержневая команда «деда и бабки», без участия «кошки и жучки» уже не обойтись, а минутное участие «мышки» может спасти проект от тупика.''  А для них в первую очередь важна не эффективность построения документации, а простота ее правки-рецензирования и доступность для чтения и изменений. ''Простота'' означает крутость «кривой обучения» — то есть включиться в работу с допустимым качеством можно практически «не приходя в сознание», посмотрев пару примеров, и ориентируясь на интуицию. Как пример, можно сравнить программирование на Basic против программирования ядра операционных систем, или использование текстовых процессоров в сравнении с системами верстки типа TeX.

''Доступность'' же означает, что к процессу можно «подключиться» откуда угодно, нет никаких ограничений и требований к рабочему месту, не требуется сложных инсталляций набора ПО. В идеале должна использоваться модель «тонкого» клиента, под которым в данный момент обычно подразумевают браузер.

Как обычно, аспекты «эффективность» и «простота и доступность» плохо между собой совместимы, и решения выигрышные для одной стороны, обычно совершенно недопустимы для другой. Но компромисс необходим — иначе одна из сторон («core» или «не-core») неизбежно выйдет из игры.

=== Knowledge management ===

Теперь рассмотрим задачу построения корпоративной базы знаний. Условно можно выделить следующие направления:

# Фиксация новых знаний;
# Рефакторинг знаний — поддержание актуальности, классификация, установление семантических связей и т. п.;
# Извлечение знаний.

<graph>
digraph G{
  
      rankdir=TB;
      node [style=filled, fillcolor="lavender", shape="rect" peripheries=1 fontname="PF Libera Pro"];
      "KnowledgeBase"->"Фиксация знаний"
      "KnowledgeBase"->"Рефакторинг \n знаний"
      "KnowledgeBase"->"Извлечение \n знаний"
  
  "Фиксация знаний"->"Легкость дополнений"
  
  "Эффективность" [style=filled, fillcolor="palegreen1", shape="ellipse" peripheries=3]
  "Рефакторинг \n знаний"->"Ссылки \n Рубрики \n категории \n ..."
  "Рефакторинг \n знаний"->"Эффективность"
  "Рефакторинг \n знаний"->"Актуальность"
  
  "Актуальность"->"Простота и доступность"
  "Извлечение \n знаний"->"Полнотекстовый поиск"
  "Извлечение \n знаний"->"Быстрая \n навигация"
  "Быстрая \n навигация"->"Ссылки \n Рубрики \n категории \n ..."
  node [fillcolor=yellow] 

  "Простота и доступность" [style=filled, fillcolor="palegreen1", shape="ellipse" peripheries=3]
  "Легкость дополнений"->"Простота и доступность"
  "Легкость дополнений"->"Эффективность"
    
}
</graph>


Оказывается, первые два пункта нуждаются в том же, что рассмотрено в предыдущем разделе, ибо с одной стороны требуется «простота и доступность» технологии для широкой аудитории — от  программистов и системных администраторов, до HR и административно-хозяйственных служб, то есть включая персонал, не сильно «разбирающийся в IT». С другой — эффективность, как добавления знаний, так и рефакторинга, причем с учетом совместной работы.

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

Таким образом, видно, что задачи ''Knowledge management'''а и документирования во взаимодействии с заказчиком весьма схожи, и для них  разумно ожидать единого решения. Отложив вопрос, а существует ли такая «серебряная пуля», попробуем понять, каких свойств можно ждать от такого решения.

== Ожидаемое решение ==

=== Формат документа   ===

<graph>
digraph G{
  
     rankdir=TB; node [style=filled, fillcolor="lavender", shape="rect" fontname="PF Libera Pro Liberissima"];
     "Формат документа"->"Бинарный"
     "Формат документа"->"Текстовый"
  
   binarybad [label="Совместная работа \n без блокировок \n чрезвычайно затруднена" style=filled shape=egg]
   textgood [label="Совместная работа \n без блокировок \n «Изменение-Слияние»" style=filled shape=egg]
  "Бинарный"->binarybad 
  "Текстовый"->textgood 
  
  textgood->"Автоматические \n слияния"
  textgood->"Построчные \n различия"
  textgood->"Эффективное \n хранение версий"
  node [fillcolor=yellow] 

   binarybad [fillcolor="lightpink" ]
   textgood [fillcolor="palegreen"]
    
}
</graph>

Сначала придется определиться с форматом информационных артефактов — статей и иных блоков документации. Оказывается, с учетом необходимости эффективной совместной работы, нужно отказаться от (или по крайней мере минимизировать) использование артефактов в бинарных форматах.

Действительно, только для плоского, разбитого на ограниченные строки текста существуют эффективные алгоритмы вычисления различий и автоматического слияния различных версий. Этот момент уже известен с появления в 1970х первых систем управления версиями. И в эффективном документировании давно было принято использовать различные ''языки разметки'', хранить документацию в текстовом виде под системой контроля версий, а бинарные форматы использовать только в неизбежных случаях, для редко меняющихся артефактов, например фотографий или растровых иллюстраций.

=== Языки разметки ===

Выбрав текстовый формат документа, какой же язык разметки выбрать? Мы возьмем на себя смелость предложить некоторую классификацию существующих языков (''markup languages'') разметки документов.

<graph>
  digraph G{ 
    
     rankdir=LR; node [fontname="sans-serif" style=filled, fillcolor="lavender", shape="rect" fontname=Festus];
     edge [color=blue4]
     "Для Машины"
     "Для Человека"
  
     "Для Машины"  ->SGML
     "Для Машины"  ->"Препроцессоры"
  
   "Препроцессоры"->TeX
   "Препроцессоры"->M4
  
   TeX->LateX
  
   SGML->Docbook
   SGML->HTML
   SGML->XML
  node [fillcolor=yellow] 

   XML->Семантический
   XML->"Технический"
   Семантический->XHTML
   Семантический->"XML Docbook"
   Семантический->"DITA"
   Семантический->"MathML"
   "Технический"->"MS XML (OOXML,ODF)"
   "Технический"->SVG;
    
  }

</graph>

<graph>
  digraph G{ 
    
     rankdir=LR; node [fontname="sans-serif" style=filled, fillcolor="lavender", shape="rect" fontname=Festus];
     edge [color=blue4]
     "Для Машины"
     "Для Человека"
  
  node [fillcolor=cornsilk shape=none]
  "Для Человека"->"Plain ASCII"
  
  "Plain ASCII"->"Wiki-markups"
  "Plain ASCII"->"BBCode"
  "Plain ASCII"->"Комментарии в коде"
  "Plain ASCII"->"Textile"
  "Plain ASCII"->"Markdown"
  "Plain ASCII"->"reStructuredText"
  "Plain ASCII"->"txt2tags"
  "Wiki-markups" [fillcolor="chartreuse"]
  node [fillcolor=yellow] 

  "Комментарии в коде"->docstrings
  "Комментарии в коде"->"Plain Old Documentation"
  "Комментарии в коде"->"Ruby Document format"
    
  }

</graph>

Не вдаваясь в историю и тонкости, отметим, что ветви языков разметки, основанных как на использовании препроцессора (<tt>TeX</tt>, <tt>LaTeX</tt>), так и на использовании жестких <tt>SGML</tt>-спецификаций (<tt>HTML</tt>, <tt>DocBook</tt>) обладают особенностями, делающими их неподходящими для решения задачи «простота для не-гиков». Элементы разметки, будь то теги или макросы, занимают много места, разметка документа ориентируется не на удобство автора, а на удобство машинного представления, для обработки препроцессором (TeX/LaTeX) или стандартизированным компилятором (<tt>SGML</tt>/<tt>XML</tt>/…). В результате, надо быть готовым к трудноуловимым и даже необъяснимым ошибкам при работе с TeX, или держать в голове иерархию вложенности сотен тегов при использовании структурной SGML/XML-разметки (<tt>DocBook</tt>, <tt>XHTML</tt>). Конечно, сильная команда легко сможет обуздать любое из этих средств, и сможет эффективно порождать документацию на любом языке разметки, используя системы последовательных преобразований (''tool chains''), управляемые системой сборки (<tt>make</tt>, <tt>Ant</tt>, <tt>Scons</tt>). При этом можно достичь и гибкости, за счет использования препроцессирования, шаблонов и составных документов, и параллелизма, используя систему контроля версий (<tt>SVN</tt>, или хотя бы <tt>CVS</tt>).

Но «простоты» при этом уже не будет, ибо приучить «непродвинутого» человека этим пользоваться совершенно нереально — проверено более чем десятилетним опытом автора статьи, регулярно ставившего подобные эксперименты. Плюс необходимость развертывания системы сборки на каждом рабочем месте существенно подрывает «доступность».

Однако в те же 1970-80ые года, когда зародились поколения <tt>SGML</tt> и <tt>TeX</tt>-разметок, появились и так называемые плоские (''plain text'') разметки, основной смысл которых заключался в форматировании документа с помощью пустых строк, пробелов-отступов, и использования десятка символов пунктуации так, что текст оставался вполне читаемым и без обработки.

Получается, что «при всем богатстве выбора другой альтернативы нет» — наша «серебряная пуля» должна использовать текстовый формат документа и понятную ''plain text''-разметку. При этом мы уже не достигнем качества верстки <tt>LaTeX</tt>-текстов, или удобства манипуляции XML-документами, но для поставленных задач — база знаний или техническая документация этого будет достаточно.

=== Другие желания ===

Что же еще разумно пожелать от «серебряной пули»? ''Доступность'' — просмотр гипертекста в любимом браузере, правка и редактирование там же. Да, ходить по ссылкам сможет и ребенок, но надо сделать, чтобы и ссылаться можно было легко и понятно. Чтобы было лекарство от страха — управление версиями. Чтобы обеспечивалось reusability: составные документы, шаблоны, препроцессор. В идеале, возможность подключения и использования любых простых предметно-ориентированных языков (''Domain Specific La''''n''''guages'') для увеличения продуктивности. Например, построение графов и даже UML-диаграмм по краткому текстовому описанию, понимание математических формул в общепринятой разметке <tt>TeX</tt>/<tt>LaTeX</tt>, автоматическое форматирование и синтаксическая раскраска для фрагментов кода и т. п. Ну и конечно средства поиска и навигации — категории (онтологии, таксономии) и полнотекстовый поиск.

== Вики-системы ==

Хотя «шум» вокруг вики-систем усилился в последние лет пять, на самом деле идея и первоначальная реализация появилась еще в 1995 году. Тогда разработчик общедоступной базы знаний по паттернам программирования, решил заложить простоту, общедоступность и эффективность в основу своей CMS-системы. Более того, он назвал ее в честь понравившихся ему гавайских автобусов, которые, несмотря на некоторую неказистость, дешево и эффективно перевозили пассажиров между аэропортами. Некоторое время вики-системы не были особенно заметны на фоне огромного множества других CMS-систем, растущих, как грибы после дождя. Но уже в 2001 году на вики-системе стартовала «Википедия»— теперь уже всемирно известная многоязычная энциклопедия, а в 2007 году слово «Wiki» получило официальную прописку в Oxford English Dictionary. Теперь практически базы знаний сообществ сделаны на вики-системах, на «виках» ведут официальные сайты проектов, «вики» попадают и в интранет, где вытесняют «классические» CMS и системы документооборота, в них же ведут техническую документацию к программным продуктам. Почему это происходит? Видимо, потому, что множество вышеперечисленных «хотелок» прекрасно покрывают базовые принципы вики-систем:

# Простой язык разметки;
# Совместное редактирование;
# Правка и публикация по месту;
# Централизованное хранение и версионность;
# Упрощенное построение ссылок.

Поясним пункты с третьего по пятый. Публикация по месту позволяет вносить правки в процессе чтения материала. То есть из режима «чтение» можно немедленно перейти в режим «писатель/корректор», и не нужно искать исходные тексты. Немедленная публикация позволяет сразу же проверить внесенные правки.

Также поясним, что при работе с файлами в «стандартных» языках разметки (<tt>TeX</tt>, <tt>LaTeX</tt>, <tt>SGML Docbook</tt>, <tt>HTML</tt>), нужно помнить нетривиальные соответствия между идентификаторами и названиями структурных блоков — секций, глав, разделов. Плюс еще помнить, в каком файле что лежит. Это конечно способствует целостности, но вносит огромную нагрузку на внесение ссылки. Не говоря уж, что для грамотной работы с файлами обязательно нужна система контроля версий — и все это минусы к «простоте и доступности». В виках же реализовано централизованное хранение всех блоков текста (документов, статей), и для них эквивалентны понятия идентификаторов, названий, и заголовков. Дополнительная дружелюбная к пользователю «денормализация» состоит в перенаправлениях ссылок и даже «опережающих» ссылках на несуществующие статьи.

Отлично подходят для компаний и социальные свойства «вик»:

* Никто не знает всего, но возможно собрать знания «с миру по нитке»;
* Никто не застрахован от ошибки, но любой, заметив ошибку, может легко ее исправить;
* Легче поддерживать актуальность — правка ошибки очень проста, и можно не бояться сломать — есть контроль версий;
* Совместное редактирование влечет совместную ответственность, вырабатывает культуру обсуждений и поиска правильного решения;
* Эффект «взбивания сливок» — легкость совместного редактирования ведет к многократным итерациям и улучшает качество;
* Легкость порождения статей способствует фиксации больших объемов знаний («главное — начать»).

Более того, очень многие проблемы открытых вики-систем, внутри компании перестают быть таковыми. «Спам и вандализм?» — поможет служба кадров. «Толпа невежд лоббируют ерунду?» — Поздравляем, обнаружена серьезная проблема компании, обязательно требующая социального решения. «Неразрешимые флеймы?» — Немедленно перейти к устным переговорам до компромисса. «Расстраивает потеря авторства?» — Похоже, кто-то не любит работать в команде…

Да, есть и технические проблемы, ограничивающие область применимости «вик», о чем надо помнить. Например, если вам нужна книга с высококачественной версткой или полиграфией (шрифты, сложные страницы с полями, плавающие объекты, оптимальный кернинг и выравнивание пустых пространств) — то я бы рекомендовал использовать LaTeX. Если заказчик требует сдавать документацию по древнему ГОСТу, с обязательной проверкой форматирования «службой нормоконтроля» — в таких случаях мы используем SGML DocBook. Но вообще тенденция такова, что ценность бумажной техдокументации уже упала почти до нуля, и продолжает падать дальше. Правда есть еще область электронных документов, в которых требуется качественная верстка по «листу/экрану» — это презентации. Здесь я бы рекомендовал LaTeX/beamer, и использовать все возможности автогенерации текста, диаграмм, картинок, и автоматизировать все это системой сборки типа SCons. Но в целом, пока кажется что эта пуля, если и не тянет на «серебряную», то «посеребренной» называться вполне может. И самое главное, кроме словесных аргументов есть убедительная проверка этого подхода практикой. Почти все знают «Википедию», но далеко не все знают, что ее прародителем был проект «Nupedia», основанный на «серьезных и глубоко продуманных подходах». Например, процесс помещения статей в энциклопедию состоял из семи этапов (проверка независимыми экспертами, вычитка редакторами и т. п.). Результат за 4 года работы — 23 завершенных статьи, 68 «in progress». А с момента перехода проекта на первый вики-движок, начался настоящий «взлет ракетой»:

;2004: ≈ <tt>300 000</tt> статей («en»-раздел);

;2005: ≈ <tt>500 000</tt> статей («en»-раздел);

;2007: ≈ <tt>2 млн</tt> статей («en»-раздел).

В момент написания этой статьи (30 июля 2008 г.) в англоязычном разделе было <tt>2,478,333</tt> статей, а в русскоязычном <tt>303,462</tt>. Для сравнения — последняя (<tt>v15</tt>) версия энциклопедии «Британника» содержала 120 тыс. статей, а последняя (v3) версия БСЭ состояла из <tt>95 тыс.</tt> статей.

=== Обратная сторона луны или проблемы выбора ===

Итак, так как большинство читателей к этому моменту воскликнут «Убедили! Дайте две!», пора рассказать об обратной стороне, серьезно затрудняющей выбор. Дело в том, что вики-систем, даже только тех, которых сравнивают на ''wikimatrix.org'', уже больше сотни, и их число продолжает расти. Почти у всех из них свой собственный язык разметки и интерфейс. Да, наступило время веб-технологий и сменился парк изобретаемых программистами «велосипедов» — с текстовых редакторов и языков программирования, на вики-системы и языки разметки. Выбрать же очень непросто — дискуссии по выбору оптимальной вики-системы, судя по нашему опыту, чудовищно жаркие — сравнивается функционал, эстетика, архитектура, в ход идут религиозные доводы («hate Perl!», «hate PHP», «болд обозначать астерисками!»…). И ошибка в выборе может надолго, если не навсегда, отпугнуть компанию от использования вики-систем: «Вики? Даже не предлагайте! Мы тут пробовали — кошмар, убогая, неудобная, падает, помойка, ничего найти нельзя, никто ее не знает, вообще потом сломалась и мы все потеряли». Ситуация, как в анекдоте — «Карузо? Полная ерунда, мне вчера сосед напел…».

Чтобы этого не случилось, мы предлагаем в первую очередь ориентироваться на комплексную характеристику функционала системы — популярность и распространенность. Да, «миллионы леммингов не могут ошибаться»<ref>Если кто не в курсе, популярный миф про леммингов, тупо следующих друг за другом на пути к суициду — всего лишь мем, запущенный постановочной сценой фильма «Белая пустошь» (1958), где леммингов сбрасывали в реку метлой.</ref>.

Как же объективно измерить популярность?

[[Image:Вики-системы — логарифм от гугл-известности.svg|center]]

Мы провели некоторое оригинальное исследование, подсчитав количество страниц в «глобальном интернете», то есть индексе Google, упоминающих ту или иную систему. Диапазон полученных значений был настолько велик (от <tt>101</tt> до <tt>295,000,000</tt> страниц), что на графике и в последующем сравнении мы приводим десятичный логарифм от этого количества.

Видно, что популярность уже далеко не одинакова, и чтобы выбрать более-менее известную систему, желательно сразу ограничить «шорт-лист», верхней десяткой кандидатов, чтобы не оказаться в незавидной роли «лабораторных животных» — первых пользователей системы, самостоятельно занимающихся «разминированием» сложных моментов. Еще мы анализировали популярность, используя ''Google Pagerank'', — известный индекс интернет-цитируемости. К нашему некоторому удивлению, «top10» согласно нашему исходному критерию и критерию, основанному на Google Pagerank, совпали! Из-за экономии места мы не приводим некоторые другие метрики популярности, например Google Trends и т. п. — заинтересовавшийся читатель вполне сможет получить их самостоятельно.

{| border="0"
|-
| [[Image:wikis-prdata.svg]] || [[Image:wikis-topdata.svg]]
|}


В целом, основная наша рекомендация — ограничить выбор первой вики-системы одной из популярных перечисленных. У каждой из них есть уникальные конкурентные преимущества, положительные и отрицательные особенности. Например, <tt>Confluence</tt> очень хорошо интегрируется с популярным баг-трекером <tt>Jira</tt>, но является платной. <tt>TWiki</tt> бесплатна и поддерживает управление правами на статьи, но написана на Perl. <tt>MoinMoin</tt> понравится любителям Python’а. А <tt>JotSpot</tt> уже понравился Google, и его превратили в <tt>Google Sites</tt>.

===MediaWiki===

Мы же продолжим аргументировать за наш выбор — ''MediaWiki''. Количество контента, размещенного в MediaWik’ах, количество пользователей и разработчиков на порядки больше, чем у любой другой системы. Знание разметки <tt>MediaWiki</tt> уже не менее полезно, чем знание <tt>HTML</tt> — хотя бы потому, что дает возможность копировать или публиковать материалы в Википедии. Открытая архитектура имеет сотни возможных точек расширения (''Hooks'', ''Extensions''), куда можно подключать свои модули, легко реализуя собственные предметно-ориентированные языки, дополнительные интерфейсы редактирования и публикации, поиска и навигации. Причем API-интерфейсы достаточно стабильны — то есть реализовав расширение, можно спокойно обновлять <tt>MediaWiki</tt>, бесплатно получая новый функционал, без боязни потерять свои наработки. Более того, уже есть больше ''тысячи'' готовых расширений, которые легко может установить даже эникейщик (скопировать файлы в каталог <tt>/extensions</tt>). Остается лишь проблема выбора, но, как знают те, кому за тридцать, она гораздо приятней проблемы дефицита и отсутствия. По сути, именно система расширений превращает MediaWiki в многофункциональный швейцарский нож, причем в который вы легко можете добавить свои собственные инструменты. Перечислим несколько наших основных «штопоров», «напильников» и «пассатижей» из ''swiss-army knife ''«MediaWiki»:

;Автоматическое построение графов: строит направленные и неориентированные графы по краткому текстовому описанию. Успешно используют даже самые далекие от компьютеров сотрудники компании и заказчиков. Подходят для всего — для рисования графов информационных и материальных потоков, диаграмм состояний или иерархии счетов, схем проводок или каких-либо классификаций. Кстати, все графы в этой статье построены именно по этой технологии.

;UML-диаграммы по текстовому описанию: аналогично, автоматическое построение некоторых типов UML-диаграмм, но сформулированных на специальном текстовом языке ''UMLGraph'', напоминающем описание классов на языке <tt>Java</tt>. Кстати, это совсем не профанация — ''UMLGraph'' рекомендовал к использованию Мартин Фаулер (''Martin Fowler''), один из самых известных популяризаторов UML.

;Графики по тексту: двух- и трехмерные графики и диаграммы по записанным формулам или наборам данных. Да, редко кому в Software Engineering нужно рисовать функции Бесселя, но вот быстро опубликовать или обновить «''Scrum Burndown Chart''» бывает очень полезно.

;Синтаксическая раскраска: для фрагментов кода или языков разметки. Быстро придает нарядный вид скучным фрагментам технической документации.

;LaTeX: вставка формул и даже целых фрагментов LaTeX-документов.

;Mindmaps: публикация так называемых «карт концепций», сделанных в популярной программе <tt>Freemind</tt>. По сути, это неограниченные иерархий понятий с взаимосвязями: планы действий, иерархии рисков, конспекты описаний предметных областей и т. п.

;Экспорт в CHM: экспорт содержимого вики-системы для последующей компиляции в статический CHM-файл. Также есть экспорт в <tt>MS Word</tt> и <tt>OpenOffice</tt>.

;MediawikiQuizzer: система тестов с выдачей электронных «дипломов», превращающих вики-систему в систему дистанционного обучения, ибо MediaWiki сама по себе уже подходит для публикации обучающего материала.

;Полнотекстовый поиск с морфологией: используется отличный поисковик <tt>Sphinx</tt> (''sphinxsearch.com''), поддерживающий русскую морфологию. Кстати, для <tt>MediaWiki</tt> на <tt>PostgreSQL</tt>, скоро можно будет воспользоваться полнотекстовым поиском с русской морфологией, встроенным в ядро этой СУБД.

;WikEd: встроенный в браузер <tt>JavaScript</tt>-редактор MediaWiki-разметки. Поддерживает синтаксическую подсветку и форматирование, поиск-замену, импорт из HTML или форматов офисных документов и т. п. Дает возможность начать работу без изучения вики-разметки, причем практически не чувствовать ограничений редактирования в браузере. Действительно, современные браузеры поддерживают и проверку орфографии, и закладки, и практически заменяют собой ранее популярные файловые навигаторы с многофункциональным редактором.

;Викификатор: автоматический эвристический обработчик, улучшающий форматирование и типографику текста. Например, заменяет обычные «кавычки», то есть знаки дюйма, на типографские кавычки-лапки, знак «минус» — на длинное тире, правильно расставляет пробелы около знаков пунктуации и т. п.

''Впрочем, перечислять можно еще очень долго, поэтому для тех, кто заинтересовался, на конференции SEC(R)-2008 мы планируем раздавать переносимую версию MediaWiki с нашим набором расширений и демонстрационным набором статей, описывающих ее возможности. Любой желающий сможет простым копированием запустить вики-систему на своем рабочем компьютере или даже ноутбуке, продемонстрировать и попробовать систему в действии вместе со своими коллегами, и если всем понравится — перенести на сервер. Возможно, полезным будет и личная инсталляция MediaWiki на ноутбуке, как персональная CMS или база знаний. Да, мы раздаем переносную систему под Windows, но те, у кого-то стоит Linux, мы уверены, самостоятельно справятся с инсталляцией.

И даже если MediaWiki вам не подойдет — вы сможете это быстро понять. Но знайте, что система быстро развивается, и лучше не заниматься бесплодными поисками «такого же, только без крыльев», а взять стандартное решение и подождать, пока некритичный функционал кто-нибудь сделает.''

== FAQ или наши ответы на часто задаваемые вопросы о «виках» ==

Здесь будут ответы на некоторые актуальные вопросы, о которых нас спрашивали в личном общении или на интернет-форумах.

Сразу скажем, что для внедрения и поддержания «вик» очень полезно, чтобы в компании был один или несколько энтузиастов, получающих удовольствие от «борьбы за качество». Поищите их среди технических писателей или тестировщиков. Отлично, если у них будет терпимый уровень грамотности и элементарные понятия о типографике. Поощряйте их участие в «модерации-викификации»! Вики — это не помойка, требующая регулярной уборки, это скорее сад, где регулярные усилия садовника направляют и придают растениям правильную форму.

{{question}} ''Статьи в вики — это как «письмо из Простоквашино»? Нагромождение разных идей, стилей, «кто в лес, кто по дрова»?''

А вот мы наоборот, читали, что у большинства статей даже в Википедии один или два выделенных автора, а остальные участники вносят пренебрежимо малые правки. В корпоративных виках все будет еще более авторским. Тогда зачем вики, где тут «синергия»?''

Нет, ситуация «письма из Простоквашино» редка, почти у каждой статьи есть основные авторы, реализующие основной объем, а роль остальных сводится к правкам, дополнениям, замечаниям. И эта ситуация совершенно нормальна — вспомним приведенную метафору «Сказки о репке».

{{question}} ''Есть у нас вики, только уже через год мы ничего в ней найти не можем. Полная помойка в ней образовалась, так как никто ничего не модерировал''.

Обязательно сделайте возможность полнотекстового поиска, желательно с русской морфологией. Это более-менее спасает даже такую помойку, как интернет. Технически, если внутренний поиск в вашей вике плох, самое простое решение — установить ''OmniFind Yahoo! Edition'' (корпоративный бесплатный поисковик с русской морфологией). Чуть более сложно, то есть требует некоторого понимания и доработки, подключение к вашей вике Sphinx (''sphinxsearch.com''). Не надо забывать об автоматических функциях Mediawiki по борьбе с нецелостностью и неактуальностью статей. Дополнительно мы используем LinkChecker (''linkchecker.sourceforge.net'').

{{question}}  ''Мы завели вику, но никто из сотрудников туда не пишет. Что мы делаем не так?''

Надо выяснить, могут ли писать что-то сотрудники вообще. Может они ведут активную переписку с заказчиком и между собой по email, или даже, не дай бог, по ICQ. Покажите преимущества накопления знаний, по сравнению с использованием компьютера как телеграфа. Найдите тех, кому вики будет наиболее полезна, и помогите им начать, а остальные подтянутся. Может, сотрудники стесняются (например, из-за низкой грамотности) писать в общую вику — мотивируйте их не бояться и фиксировать любые полезные знания. Попробуйте и кнут — например, включить в ''Definition of Done'' по задачам, требующим отчета, отчет именно в вики-системе.

{{question}} ''При обсуждении статей в MediaWiki сотрудники пишут комментарии не на вкладку «Обсуждение», а непосредственно в тело статьи. Как нам отучить их от этого, или получить «очищенный» от замечаний вариант?''

Да, действительно контекстное замечание удобней вставить непосредственно в текст статьи. Так оно больше привлечет внимание, ведь если на выходе должен быть «чистый» текст, значит нужно рано или поздно учесть это замечание и удалить его. Оформляйте замечания в виде специальных шаблонов, которые с одной стороны будут привлекать внимание цветом или пиктограммами, с другой — не будут включаться в композитную статью. Используйте теги «noinclude».

{{question}} ''Мы используем вики, но версии ведутся только для текстовых документов. Как хранить все версии и для бинарных объектов, например, картинок, чтобы использовать их также в вики.''

Установите <tt>Subversion</tt> и храните бинарные объекты в нем. В любом случае для работы с нетекстовыми объектами вам понадобится специальные программы, вики обычно для этого не приспособлена (хотя есть некоторые расширения по редактированию картинок в браузере). Настройте доступ к SVN-репозитарию через <tt>Apache</tt>, и вы прекрасно сможете использовать картинки, и другие бинарные артефакты, ссылаясь на них из вики-системы. Кстати, вы также сможете ссылаться на любой программный код, документы в бинарных форматах, автогенеримую по коду документацию и т. п.

{{question}} ''Хотелось бы иметь возможность продолжать работу без онлайн-доступа, в местах без интернета, например, в командировке в регионы.''

Заведите персональную инсталляцию MediaWiki (это легко и под Linux, и под Windows), перенесите экспортом набор статей и работайте над ними. Еще сейчас проходит обкатку реализация протоколов ''WebDav''/''DeltaV'' для доступа к MediaWiki, что даст возможность использовать стандартный Subversion-клиент (например, <tt>TortoiseSVN</tt>), для экспорта статей, как набора файлов, редактирования их в файловом виде, с возможностью массовых правок, и последующем ''commit''’е их в MediaWiki, как в SVN-репозитарий.

{{question}} ''Мы перепробовали все, но вики-системы не приживаются. Что нам делать?''

Радуйтесь! Значит они вам и не нужны! А если вы чувствуете, что они вам таки нужны, то есть есть нерешенные проблемы в управлении знаниями или гибком документировании при взаимодействии с заказчиком — то проблема явно в другом. В людях и в их мотивации, в задачах компании и ее приоритетах. Да и вряд ли другой волшебный инструмент сможет помочь в этом случае.

== Примечания ==

<references/>

== Дополнения == 

Выступление с докладом по этой теме:
* [[Блог:Team/2008-12-30_MediaWiki:_серебряная_пуля_или_швейцарский_нож?|внутренний семинар перед SECR-2008]].
* [[Блог:Team/2009-06-20_SEF-2009:_наши_доклады|скринкаст с SEF-2009]].

[[Категория:Стас Фомин (Статьи)]]
[[Категория:2009 год (Статьи)]]
[[Категория:Технологии разработки ПО (Статьи)]]
[[Категория:Открытые системы (Публикации)]]

{{replicate-from-custiswiki-to-lib}}