Спасибо за ответ, будет интересно поковырять dokuwiki на предмет возможностей.
В моем случае порядка 300-400 юзеров разной степени активности, нагрузка в рабочие часы довольно ощутимая и не все удается решить простым добавлением ресурсов. Не википедия, но и мириться с загрузкой хитрых визуализаций по несколько минут не хочется, приходится выкручиваться.
Системы веток там нет, только линейная история правок. Этого действительно не хватает.
1.
Можно имитировать ветки при помощи подстраниц, но не уверен, насколько это удобно будет. Гранулярный мерж между страницами будет невозможно сделать автоматически, только переносить целиком контент страницы из одной подстраницы в другую.
2.
С викидата я не работал, но базовая идея там та же, что у semantic mediawiki, cargo и иже с ними — дать возможность хранить структурированные и осмысленные данные, чтобы потом с ними можно было работать при помощи апи и вики-запросов.
Неоднократно слышал о нем, но не пробовал в деле. На первый взгляд смутило отсутствие визуального редактора (CKGEdit — это несколько другое). Но перечисленные вами вещи звучат здорово. Судя по тому, что вижу в комментах, много кто пользуется ею.
Кстати, у вас не было опыта работы dokuwiki с большим числом статей, как она ведет себя на условных 5-10 тысячах страниц?
На данный момент у меня порядка 6000 страниц, так что приходится привередничать и смотреть не перфоманс и общую масштабируемость тех или иных решени. Уже неоднократно приходилось отказываться от тех или иных расширений и писать их аналоги из соображений отвратительного быстродействия. Любопытно, как с этим в dokuwiki.
Поддерживаю, мне тоже было бы интересно почитать про автоматизацию выгрузки, буду ждать стати.
Сам, кстати, создал/поддерживаю базу знаний на Mediawiki. У нее есть свои ограничения, но категоризация там гораздо более естественным образом устроена, кмк, чем теги Confluence.
Обычно уточняют, что слово — последовательность конечной, но неограниченной длины (т.е. не берем расчет бесконечные строки, ведь множество бесконечных последовательностей, составленных конечным алфавитом, и правда не счетно). Тогда все просто: Сперва сортируем по алфавиту все слова длины 1, затем все слова длины 2 и т.д. Счетное объединение конечных множеств вполне себе счетно.
Я тоже недавно оформлял себе синюю карту. Нострификация диплома не является необходимым условием для получения синей карты. Можно просто сделать нотариально заверенный перевод (кстати, нотариально заверить бумажки можно и в консульствах, услуга платная).
Стоит ли ради этой пары кейсов напрягаться с этим? Впрочем, может, будут использовать для сугубо информационных дисплеев во всяких душевых кабинках, стеклянных стенках супермаркетов и прочих полупрозрачных поверхностей.
Не очень представляю кейсы использования такого дисплея: он все еще требует мощного и более-менее равномерного источника освещения (на видео видно, как во фрагментах шкафа включается мощное освещение перед тем, как на экране начинают показывать видеоряд.
Тендер определит «точку входа» на 2016-2017 годы. Мол, у кого условия получше, тот и «провайдер». В целом, и по цене и по своей сути нормальный тендер. Тот же Springer обходился в 3.2-3.3 млн евро в год.
В моем случае порядка 300-400 юзеров разной степени активности, нагрузка в рабочие часы довольно ощутимая и не все удается решить простым добавлением ресурсов. Не википедия, но и мириться с загрузкой хитрых визуализаций по несколько минут не хочется, приходится выкручиваться.
Extension:Maps/Displaying_maps
За счет поддержи «под-объектов» и иже с ними в семантической медиавики можно хранить сложные данные.
1.
Можно имитировать ветки при помощи подстраниц, но не уверен, насколько это удобно будет. Гранулярный мерж между страницами будет невозможно сделать автоматически, только переносить целиком контент страницы из одной подстраницы в другую.
2.
С викидата я не работал, но базовая идея там та же, что у semantic mediawiki, cargo и иже с ними — дать возможность хранить структурированные и осмысленные данные, чтобы потом с ними можно было работать при помощи апи и вики-запросов.
Правда, не уверен, подходят ли в вашем случае существующие решения. Если не секрет, какая задача потребовала хранения геоданных?
Кстати, у вас не было опыта работы dokuwiki с большим числом статей, как она ведет себя на условных 5-10 тысячах страниц?
На данный момент у меня порядка 6000 страниц, так что приходится привередничать и смотреть не перфоманс и общую масштабируемость тех или иных решени. Уже неоднократно приходилось отказываться от тех или иных расширений и писать их аналоги из соображений отвратительного быстродействия. Любопытно, как с этим в dokuwiki.
Сам, кстати, создал/поддерживаю базу знаний на Mediawiki. У нее есть свои ограничения, но категоризация там гораздо более естественным образом устроена, кмк, чем теги Confluence.
За пару оснований.
После этой таинственной фразы нет никаких объяснений. Почему им удалось попробовать кофе не сразу?