Главная » Хабрахабр » Почему строить базу знаний компании на основе mediawiki — недурная затея

Почему строить базу знаний компании на основе mediawiki — недурная затея

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

Само собой, mediawiki подойдет не всем — в ней нет модной интеграции с jira/tfs/etc, перенос документов с картинками из пакета Microsoft Office доставляет кучу неудобств, да и сама она написана на PHP, что в последнее время служит отпугивающим фактором для некоторых айтишников. Не умаляя достоинства этих систем, хотелось бы рассказать о том, какие возможности есть у Mediawiki в роли корпоративной базы знаний. Большая часть интересного функционала кроется именно в расширениях, так что изрядная часть статьи будет именно про них. Тем не менее, платформа живее всех живых и над ее развитием работает изрядное количество людей, коль скоро на ней базируется семейство проектов фонда Викимедиа.
Сама по себе вики довольно скупа на возможности, но для нее написано огромное множество расширений. И да, не могу не отметить, что есть специальная корпоративная версия Mediawiki — BlueSpice, которой я не пользовался, а потому не могу судить об ее адекватности.

Зачем ты в это полез и кто ты такой вообще

Привет. Меня зовут Николай, я QA инженер.

$\textbf$

QA включает в себя не только/не столько тестирование, сколько обеспечение качества в широком смысле. И среди прочих значений этого самого широкого смысла затесалась такая штука, как управление знаниями. По этой теме довольно много абстрактных статей и книг, повествующих о принципах Knowledge management, но на удивление мало конкретных рекомендаций и практически применимых идей, во всяком случае сколько-нибудь свежих. Это заставляет меня думать, что или все пользуются тем, что дают всем известные компании и радуются, или не пользуются ничем и страдают, или пилят свой тайный велосипед, о котором неловко рассказывать в приличной компании. Мне тоже неловко, но я расскажу.

Сперва про фишки самой mediaiwki

Если на вашем счету тысяча правок на википедии, то вряд ли вы узнаете что-то новое из этой части, ее можно смело пропустить. Прежде чем говоритиь о расширениях, стоит упомянуть о том, какие вообще особенности есть у самой mediawiki.

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

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

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

Модули вместе с шаблонами позволяют реализовать многие вещи, даже не обращаясь к написанию своих расширений. В дополнение к шаблонам расширение Scribunto позволяет использовать lua-модули внутри вики.

Навигационная таблица — это, например, вот эта штука, которую обычно можно увидеть внизу страницы:
К примеру, навигационные таблицы построены на базе этого дуэта.

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

Не могу не упомянуть Mediawiki:Common.css и Mediawiki:Common.js файлы, позволяющие добавить небольшую кастомизацию вики — для больших вещей лучше использовать расширения.

Редакторы

Одна из самых важных частей вики — это редактор. Крайне сложно внедрить вики, если в ней нет визуального редактора, потому как учить вики-разметку согласится только очень инициативный человек.

Visual Editor

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

Задача эта оказалась крайне нетривиальной в силу того, что mediawiki синтаксис развивался хаотично и не был строго определен. Появление визуального редактора тесно свзяано с появлением Parsoid — сервиса конвертации между Mediawiki синтаксисом и html. Подробнее можно почитать в прекрасном посте официального блога.

Среди расширений, интегрирующихся с VisualEditor, можно выделить Graph для редактирования графов, Math для редактирования математических формул и SyntaxHighlight для подсветки синтаксиса фрагментов кода.

WikiEditor

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

Конфликиты редактирования

Кто пользовался в прошлом Mediawiki, тот помнит, какой болью становилось каждое разрешение конфликтов редактирования.

В случае возникновения конфликта можно посмотреть на те места, где имеет место конфликт, и выбрать нужную версию спорного фрагмента. TwoColConflict со включенным по умолчанию бета-режимом сильно упрощает решение проблемы. Как-то так это выглядит в деле: Если обе версии не полны, то можно дополнить одну из них.

Можно попробовать самому на тестовой странице.

Формы для добавления однотипного контента

Расширение PageForms позволяет добавлять на вики однотипный контент при помощи форм. В своей пратике я использовал формы для добавления на вики реестровых ключей, таблиц БД и других подобных типовых вещей.

Семантическая медиавики позволяет добавлять на страницу свойства страницы или объекты со своими свойствами. Это расширение раскрывает свою мощь при использовании Semantic Mediawiki или его аналогов. Задаются свойства примерно так (на примере страницы Германия):

[[Имеет столицу::Берлин]]

Эти свойства и объекты после можно получить при помощи запроса ask или через api.

К примеру, в моем случае на основе таблиц, добавленных через формы, строятся простейшие схемы бд. Из полученных свойств можно выводить таблицы, строить графики и делать много других крутых вещей. И в схеме можно отразить помимо очевидных FK/PK связей еще и неявные связи, которые не увидеть стандартными средствами построения диаграмм. При этом схему можно строить не для всего продукта, а для конкретной категории.

Для реестровых ключей из тех же свойств вытаскивается ключевая информация для того, чтобы на ее основе можно было бы генерировать .reg файл с заданным значением.

Дерево категорий

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

С другой стороны, когда у нас уже есть разложенные по категориям статьи, их можно отобразить на любой странице в виде дерева:

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

LDAP/AD авторизация

Расширение Ldap Authentication поддерживает авторизацию через домен, ограничение доступа для определнных групп и маппинг групп юзеров mediawiki на группы ldap. Можно настроить сразу несколько доменов. Довольно утомительная вопросах настройки, но, к счастью, в интернетах есть очень даже неплохие инструкции.

Гранулярные права доступа

Вот тут все плохо. Если задача стоит в том, чтобы ограничить доступ неавторизованным пользователям, то это просто. Если среди этих пользователей нужно выделить отдельные группы с особыми правами доступа, то это сложно.

Для поддержки прав доступ придется патчить код Mediawiki, маниакально добавляя
Есть много разных расширений, но они не решают фундаментальную проблему: mediawiki не была создана как CMS.

$title->userCan('read')

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

К счастью, мне не был нужен продвинутый ACL, хватило и примитивных проверок для нескольких групп. Для себя я решил проблему самодельным расширением, построенном на идее из PermissionACL и пачки патчей для разных расширений и самой mediawiki.

А последний использует стример файлов от mediawiki, который не умеет отдавать partial content (на момент mediawiki 1. Для поддержки того же самого для изображений придется завернуть обращения к файлам в Img_auth.php. 31), так что для поддержки воспроизведения видео придется приделывать другой стример файлов.

Поддержка видео

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

Поиск

Одна из раздражающих меня лично вещей в Confluence — это поиск. Стандартный поиск Mediawiki еще хуже, но к счастью есть сторонние расширения. Из поисковых расширений самые популярные — это CirrusSearch и SphinxSearch. Последним я никогда не пользовался, но с первым мне довелось познакомиться очень плотно, он же, кстати, используется и в проектах фонда викимедиа

CirrusSearch работает на базе elasticsearch, для работы расширения придется еще поставить промежуточный интерфейс — расширение Elastica.

Например, меня очень порадовало, что в ветке 1. CirrusSearch поддерживает безумное число параметров и довольно активно развивается. 32 заработал поиск по CamelCase.

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

Расширение не поддерживает добавление синонимов на уровне конфига LocalSettings, но это несложно решить правкой кода расширения — см AnalysisConfigBuilder.php и инструкцию по настройке синонимов elasticsearch.

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

Кстати, AdvancedSearch поможет привести в порядок вид страницы поиска, с ним она не будет выглядет как жертва любителя чекбоксов.

Аналитика

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

Соответствующее расширение для интеграции — MatomoAnalytics. Для интранета есть крайне достойное расширение Matomo (ex Piwik).

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

Прочее

Помимо перечисленного есть немало расширений, которые просто облегчают жизнь. Например, GuidedTour для обучения новичков основам работы с интерфейсами, Popups для предпросмотра статей по наведении на ссылку, MultimediaViewer для более кофмортного просмотра полноразмерных изображений и многое-многое другое.

Что в итоге?

Перечисленный джентельменский набор расширений покрывает значительную часть потребностей при создании базы знаний, но не все. Mediawiki не годится в качестве универсальной единой базы знаний. Но в качестве универсальной системы также плохо справляются и все остальные — sharepoint, confluence, олдскульные папочки outlook, поиск по которым занимает полчаса и т.д. Mediawiki же на их фоне отличается своими возможностями кастомизации и отличной масштабируемостью.

Но если это не пугает и если вы согласны разделять работу с офисными документами и работу с вики статьями по разным платформам, mediawiki в качестве базы знаний может оказаться весьма недурной затеей. В противовес всем перечисленным плюсам mediawiki постоянно требует допиливания напильником функционала под нужды конкретной компании, так что ее администратору стоит быть морально готовым разбираться в php, js и lua коде.


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Профессиональная IoT-конференция InoThings++ — что было и что будет

Привет, Хабр! Практически ровно год назад — в конце января 2018-го — мы попробовали провести первую профессиональную конференцию для разработчиков устройств, систем и проектов «Интернета вещей» InoThings++ 2018. Помимо того, что она была первой для нас — если не считать ...

[Перевод] Изучаем Python: модуль argparse

Если вы занимаетесь обработкой и анализом данных с использованием Python, то вам, рано или поздно, придётся выйти за пределы Jupyter Notebook, преобразовав свой код в скрипты, которые можно запускать средствами командной строки. Здесь вам и пригодится модуль argparse. Для новичков, ...