Revision as of 15:12, 25 August 2011 (view source) StasFomin (Talk | contribs) (moved Эволюция Wiki-Way командной разработки/Презентация to Wiki-Way)		Latest revision as of 17:53, 5 April 2012 (view source) VitaliyFilippov (Talk | contribs)
(4 intermediate revisions by one other user not shown)
Line 1:		Line 1:
−	#REDIRECT [[Wiki-Way]]	+	<slideshow title="" style="custis" scaled="true" font="Calibri, Segoe Print, cursive" footer="" headingmark="⌘⌘" />
		+	<slidecss view="true">
		+	big { font-size: 200%; }
		+	</slidecss>
		+	<slides float="right" width="300">
		+	Эволюция Wiki-Way командной разработки
		+
		+	Виталий Филиппов, Стас Фомин
		+
		+	[http://custis.ru/ CUSTIS]
		+	</slides>
		+
		+	Мы хотим кратко рассказать историю развития open-source систем поддержки разработки в нашем корпоративном интранете, которая чудесным образом совпала с мировой тенденцией развития командной разработки.
		+
		+	У нас она начиналась с идей:
		+	;Open-Source: нет жестких ограничений — гибкость и опыт масс в одном флаконе.
		+	;Wiki + баг-трекер + система контроля версий: достаточно для всего.
		+	;Правильная вики &rArr; MediaWiki: мэйнстрим + расширяемость.
		+
		+	Кроме того, мы (в конце 2010г) наконец-то выполнили обещание выйти в Open-Source и теперь существует проект {{!|[http://wiki.4intra.net/ 4intra.net]}} («фор интранет», то есть, «для интранета»), который вы можете попробовать своими руками.
		+
		+	Например, расширяемость превращает MediaWiki не просто в базу знаний или инструмент документирования, а даёт возможность сделать такие нетривиальные «плюшки», как
		+	* система информационных потоков (читай — '''форумов и блогов'''),
		+	* '''презентаций''',
		+	* '''опросов и экзаменов''',
		+	* личный «кэш» '''сетевых закладок'''
		+	и так далее.
		+
		+	Не говоря уже о расширенных медиа-возможностях — вставке изображений и видео, графов и графиков, UML и MindMap’ов, TeX и прочих «фичах».
		+
		+	О том, как мы пришли к своему выбору, почему он всё больше совпадает с мировой практикой, что представляют из себя все эти, а также многие другие вкусности, реализуемые с помощью <tt>[[MediaWiki]]</tt>, <tt>[[Bugzilla]]</tt>, <tt>[[SVN]]</tt>, <tt>[[ViewVC]]</tt>, <tt>[[FeedOnFeeds]]</tt> и так далее, и о том, куда двигаться дальше, и будет доклад.
		+
		+	= Wiki-Way и выбор систем =
		+
		+	<slides float="right" width="300" split="-----">
		+	<h2><big>{{c|#0c0|Парадигма проектирования нового}}</big></h2>
		+
		+	<div style="float: left">{{UnscaleImage|Blueprint.png|400}}
		+
		+	<big>{{c|red|Инженерная}}</big></div>
		+	<div style="float: left">{{UnscaleImage|Джамшут-Лестница.png|300|top}}</div>
		+
		+	-----
		+	<h2><big>{{c|#0c0|Парадигма проектирования нового}}</big></h2>
		+
		+	[[Файл:ParaWiki.jpg]]
		+
		+	<big>{{c|red|Wiki-Way}}</big>
		+	</slides>
		+
		+	При начале разработки дизайн чего-то нового, доселе неизведанного, обычно либо глубоко проектируется в самом начале (''инженерный подход''), либо эволюционирует, начиная с заложенного изначально минимума.
		+
		+	''Wiki-Way'' мы называем именно натуральный эволюционный подход с максимально упрощёнными концепциями. Вообще говоря, кто-то другой мог назвать его ещё как-нибудь — хоть «Web 2.0», хоть «гибкий», хоть «Agile», но мы выбрали термин «{{c|blue|Wiki-Way}}» — Wiki являются его апогеем.
		+
		+	Этот конфликт, между «жестким, заданным априори»
		+	и «гибким, адаптирующимся к меняющимся потребностям пользователя и ограничениям среды»
		+	встречается повсеместно.
		+	В культуре разработке кстати тоже, рекомендуем вам взглянуть на книгу «[[lib:Культуры программных проектов (Энтони Лаудер)]]» — там этот конфликт выражен противоречием между «заводской» и «сервисной» культурой (offtopic: с очень неоднозначным положением культуры «дизайнерской»).
		+
		+	{{----}}
		+
		+	== Выбор систем ==
		+
		+	<slides split="-----" float="right" width="400">
		+	Выбор систем
		+	;Ящик Вендора: {{c|#a00|Закрытый, сильносвязанный, платный}}
		+	;Велосипед: {{c|#f80|Быстро создать}}, {{c|#a00|тяжело поддерживать}}
		+	;Футбол Хоттабыча: {{c|#f80|Кажется идеалом}}, {{c|#a00|Не взлетит}}
		+	</slides>
		+
		+	;«Ящик Вендора»: Закрытые платные системы крупных производителей («вендоров»).
		+	;«Велосипед» или «Лунапарк»: Да, то самое, что нестерпимо хочется изобрести самому, и сделать это обязательно с блекджеком и шлюхами ©.
		+	;«Жадный интегратор» или «Футбол Хоттабыча»: поставить все что можно (особенно если бесплатные системы) и потом пытаться все это интегрировать, а пользователей учить всем этим пользоваться.
		+
		+	<slides split="-----">
		+	Ящик Вендора
		+
		+	{{UnscaleImage|BlackBox.jpg|400}}
		+	{{UnscaleImage|Interlinked.gif|400}}
		+
		+	{{UnscaleImage|LockedLock.jpg|400}}
		+	{{UnscaleImage|Handcuffs.jpg|400}}
		+
		+	</slides>
		+
		+	=== Ящик Вендора: Плюсы? Минусы? ⌘⌘ ===
		+
		+	<div style="float:right">
		+	* Платный, вендорский
		+	** <s>{{c|#0c0|«☺ Наверное, качественный?»}}</s>
		+	** {{c|#a00|☹ Vendor lock-in !}}
		+	** {{c|#a00|☹ Может быть и недёшев !}}
		+	</div>
		+	* Сильносвязанный
		+	** <s style="color: #0c0">«☺ Отлично, всё интегрировано?»</s>
		+	** {{c|#a00|☹ Шаг в сторону — считается побег !}}<br />
		+	** {{c|#a00|☹ Меньше думать может оказаться вредно}}
		+	* Закрытый
		+	** <s>{{c|#0c0|«☺ Кому в нём копаться?»}}</s>
		+	** {{c|#a00|☹ Недостатки не исправить !}}
		+
		+	=== Велосипед ===
		+
		+	<slides>
		+	'''Велосипед'''
		+
		+	[[Файл:Bicycle.gif]]
		+	</slides>
		+
		+	==== YATUP ⌘⌘ ====
		+	[[Файл:Yatup.avi.flv]]
		+	<!--[[Файл:Comics-not-reinvent-a-wheel.svg]]-->
		+
		+	<slides>
		+	Пользователи: *FACEPALM*<br />
		+	Админы: *FACEPALM*<br />
		+	Программист: (сбежал)
		+	</slides>
		+
		+	==== CLOC ⌘⌘ ====
		+
		+	* MediaWiki: {{c|blue|185000}} PHP, {{c|#0c0|577000}} локализация
		+	* Bugzilla 3.6: {{c|blue|72000}} Perl, {{c|#0c0|35000}} TT
		+	** 4.0: {{c|blue|+10000}} Perl, {{c|#0c0|+3000}} TT
		+
		+	И в них ведь ''есть какой-то смысл'' (!)
		+
		+	Может, не стоит писать заново ?
		+
		+	<slides split="-----">
		+	Всё это <span style="color: red; font-size: 200%">☹</span>.
		+
		+	А как <span style="color: #0c0; font-size: 200%">☺</span>?
		+
		+	&rArr; '''MainStream'''!
		+	</slides>
		+
		+	== Сочетание систем ==
		+	<slides float="right" width="400">
		+	<tt>Wiki + трекер + VCS</tt> — cочетание используется всё чаще:
		+
		+	[http://trac.edgewall.net/ Trac]
		+
		+	[https://github.com GitHub], [https://bitbucket.org/ Bitbucket], [https://code.google.com/ Google Code], [https://launchpad.net/ Launchpad]
		+
		+	{{UnscaleImage|Github.png|100}}
		+	{{UnscaleImage|Bitbucket.png|100}}
		+	{{UnscaleImage|GoogleCode.jpg|100}}
		+	</slides>
		+
		+	Идея родилась у нас ещё N (≈ '''8''') лет назад<ref>Ну вообще-то, эволюция к этому метастабильному состоянию, была примерно такой:
		+	* 1996: CVS
		+	* 2001-2002: Bugzilla
		+	* 2003: MediaWiki
		+	но при этом мы таки немного комплексовали, перед «профессионалами» с крутыми системами «поддержки полного  жизненного цикла разработки», и только в 2007 году, мы вылезли с [[lib:Интеграция Open Source-систем для управления разработкой ПО (SECR-2007)|этой темой на конференцию]], где внезапно обнаружили, что мы не одиноки, и почти также живут все, включая (!) самих разработчиков этих самых «крутых систем»
		+	</ref>, а в последнее время, похоже, распространяется всё больше и больше, возьмите хотя бы [http://code.google.com/ Google Code] или любой [https://github.com GitHub] / [https://bitbucket.org/ Bitbucket] / [https://launchpad.net/ Launchpad].
		+
		+	Логика была следующая — почти все объекты, с которыми приходится иметь дело разработчику, можно разделить на три части:
		+	;Ответственность: то, что нужно сделать или исправить, в каком состоянии какие задачи, проблемы и ошибки, кто за них ответственный и т.п.
		+	;Артефакты: всё то, что является результатом разработки. Код, дистрибутивы, отгружаемая документация.
		+	;Знания: то, благодаря чему разработка становится возможна. Аналитика, крупные постановки задач, функциональные и нефункциональные требования, документация (внутренняя и внешняя и т.п.).
		+
		+	В этой троице каждому из типов соответствует (одна!) своя система, что и даёт такое удобство.
		+	Wiki для знаний, VCS для артефактов, issue-трекер для задач и багов.
		+
		+	Частично они могут пересекаться. На самом деле, набор этих систем столь мощный, что можно «отрубить» одну или даже две, и оставшиеся всё равно будут пытаться «покрывать» большую часть процессов.
		+	И при этом они будут конкурировать, и вытеснять более специализированные системы<ref>Например, мы пытались понять, почему [[lib:Управление тестами с Testopia — недостающее звено? (SECR-2009)|непопулярны testmanagement-системы]]</ref>.
		+	Ну и мы знаем несколько неудачных случаев попытки интеграции большего числа более специализированных систем (подобранных по принципу «футбол Хоттабыча» — «для каждого типа объекта в разработке пусть будет самая лучшая специализированная система его учета»)<ref>Мы случайно сохранили типичную презентацию такого подхода, который пыталась реализовать очень сильная команда разработчиков.
		+	Мы предлагаем взглянуть на слегка обфускированную версию, где мы, чтобы не бросить тень на уважаемую нами компанию, убрали упоминания названия этой компании, а также брендов и торговых марок. [[Файл:Some-good-company-tools.pdf|256px|right]]
		+	</ref>
		+
		+	{{----}}
		+
		+	=== С чем имеет дело разработчик? ⌘⌘ ===
		+
		+	* {{c|red|Код}}, тесты
		+	* {{c|#f80|Баги, задачи, постановки}}
		+	* {{c|#0a0|Документация}}
		+	* {{c|#0a0|Новости, обсуждения}}
		+	* …
		+
		+	<slides split="-----" width="300">
		+	[[Файл:DevCircles-NoCircles.svg]]
		+	-----
		+	[[Файл:DevCircles.svg]]
		+	-----
		+	[[Файл:DevCirclesGeneralSystems.svg]]
		+	-----
		+	[[Файл:DevCirclesMwBzSvn.svg]]
		+	-----
		+	[[Файл:Subversion logo.png]]
		+
		+	На данный момент вершина эволюции CVCS :)
		+	-----
		+	[[Файл:March-hare-2.jpg]]
		+
		+	Ещё жив CVS(nt) ({{@|March Hare}})
		+
		+	<small>* А зря nt</small>
		+	</slides>
		+	А бешеный заяц на слайде выше — это Мартовский заяц из Диснеевской Алисы в Стране чудес, иллюстрирующий CVSnt, очень сомнительного качества доработанный CVS, произведённый на свет компанией March Hare Software.
		+
		+	Кстати, в это трудно поверить, но надо признаться, что у нас в компании до сих пор есть проекты использующие CVS.
		+	Использование CVS обусловлено накопленным legacy-опытом (специальные утилиты deploy и testing, завязанные на CVS), плюс legacy-технологии таковы, что переход на SVN или DVCS почти ничего не дает (ветвится вокруг неизменной терабайтной базы бессмысленно, переименования серверных пакетов чрезвычайно редки и т.п.).
		+	В общем, CVS у нас работает, как до сих пор работают паровозы в Китае, и мы рассчитываем, что он отомрет естественно, вместе со сменой legacy-технологий.
		+
		+	=== ViewVC ===
		+	[[ViewVC]]<ref>
		+	Более подробно о нем можно [[lib:Одежка_для_Subversion_-_ViewVC_и_SVNSearcher|почитать]] или [[lib:Одежка для Subversion: ViewVC и SVN-Searcher (SECR-2009)|посмотреть наше выступление на конференции]].
		+	</ref>.
		+
		+	Для нас большой плюс, что он поддерживает и SVN и CVS (см. выше).
		+
		+	==== ViewVC ⌘⌘ ====
		+
		+	[[Файл:Viewvc-logo.png|right]] [http://viewvc.org/ ViewVC] &rarr; web-интерфейс к CVS & SVN
		+
		+	* Его можно считать частью VCS.
		+	** <small>У <tt>git</tt> и <tt>hg</tt> веб-интерфейс вообще в стоке.</small>
		+	* Тоже чуть докручен {{UnscaleImage|Hackwrench.jpg|150}}
		+
		+	=== Трекер и вики ===
		+
		+	<slides split="-----">
		+
		+	Трекер: <big>Bugzilla{{refstar}}</big>
		+
		+	{{refstar}} при всех недостатках. Самый большой &rarr;&rarr;&rarr;
		+
		+	{{c|red|&rarr; Сложность расширения!}}
		+
		+	<small>(… кривость объектного движка)</small>
		+
		+	-----
		+
		+	Wiki: <big>MediaWiki</big>
		+
		+	[[Файл:MediaWiki-notext.svg]]
		+
		+	</slides>
		+
		+	==== {{c|blue|Epic Win’ы}} MediaWiki ⌘⌘ ====
		+
		+	* Расширяемость: <br /><small style="color: blue">1700 расширений и очень легко пишутся</small>
		+	* Отсутствие суррогатных ID: <br /><small>http://lib.custis.ru/Как_прекратить_писать_(Андрей_Аксенов_на_ADD-2010)</small>
		+	* Производительность и кэши: <br /><small style="color: blue">Ну, Wikipedia же ворочается!</small>
		+	* Локализация: <br /><small style="color: blue">352 локали (!)</small>
		+
		+	= Альтернативы =
		+
		+	Далее мы рассмотрим некоторые альтернативы своему выбору - может быть, не до конца оптимальному, но выросшему эволюционно и используемому успешно.
		+
		+	== VCS ==
		+
		+	<slides split="-----" float="right" width="300">
		+	VCS{{refstar}}
		+
		+	{{c|#0a0|Централизованные}} и {{c|blue|распределённые}}
		+
		+	{{c|#0a0|CVS, SVN}} → {{c|blue|Git, Mercurial, Bazaar}} (, Monotone, Darcs)
		+
		+	----
		+	<small>{{refstar}} известно почти всем</small>
		+	</slides>
		+
		+	Что такое VCS (система контроля версий), надеемся, известно всё-таки уже всем<ref>Мы тоже внесли некоторый вклад в «пропаганду VCS», [[lib:Категория:Системы_контроля_версий|сериями статей и переводов]], а также [http://www.slideshare.net/belonesox/cvcsordvcs выступлениями на конференциях]</ref>. Для тех, кто в танке — это система, помогающая хранить не одну версию файлов продукта, а много сразу, в любой момент возвращаться к любой версии, просматривать информацию о версиях и т. п. Первой системой контроля версий был <tt>RCS</tt>, потом из него вырос <tt>CVS</tt>, а после <tt>CVS</tt> появился <tt>Subversion</tt> для «свержения» (англ. ''subversion'') и исправления недостатков <tt>CVS</tt>’а.
		+
		+	'''CVS''' и '''Subversion''' — наиболее распространённые представители '''централизованных''' систем, в который репозиторий (хранилище версий) располагается на одном «центральном» сервере, а на компьютерах разработчиков размещаются только «рабочие копии», соответствующие какой-то одной версии. Модной в последнее время альтернативой этому подходу являются '''распределённые''' системы управления версиями, хранящие весь репозиторий в каждой рабочей копии.
		+
		+	Что важно для удобства, DVCS поддерживают расширенные возможности отслеживания ветвлений и объединения изменений, потому что без этого объединять безумные графы изменений, приходящих от разных разработчиках в OpenSource проектах, было бы невозможно.
		+
		+	Самые известные [[lib:DVCS]] — это [http://git-scm.com Git], [http://mercurial.selenic.com/ Mercurial] (hg) и [http://bazaar.canonical.com/ Bazaar]. Возможно, вы также слышали о [http://darcs.net/ Darcs] и [http://monotone.ca/ Monotone]. Хранение полной истории ревизий в каждой рабочей копии, кроме всего прочего, даёт ещё и «естественное резервное копирование».
		+
		+	DVCS сейчас действительно «в моде», это даже подтверждают данные двух одинаковых опросов от 26 октября 2009 и 2010 годов на [http://habrahabr.ru/ Хабре] — SVN и CVS потеряли <tt>3 %</tt> и <tt>5 %</tt>, а <tt>Git</tt> и <tt>Hg</tt> приобрели те же <tt>5.5 %</tt> и <tt>3 %</tt>.
		+
		+	{{caution}} <tt>Bazaar</tt>, правда, потерял полпроцента (а [[lib:DVCS YAC|я говорил]]! [http://solovyov.net/blog/2011/01/24/bzr-hate-and-hate/ И не только я]).
		+
		+	Так или иначе, производимые ''артефакты'' хранятся в системе контроля версий, этим уже никого не удивишь, запомним это.
		+
		+	=== Статистика ⌘⌘ ===
		+
		+	[[Файл:Habrastat_VCS_2010-10-26.svg]]
		+
		+	=== DVCS в моде ⌘⌘ ===
		+
		+	За год:
		+	* {{c|blue|Git}}, {{c|blue|Hg}} &uarr; {{c|#f80|5.5 %}}, {{c|#f80|3 %}}
		+	* {{c|#0a0|SVN}}, {{c|#0a0|CVS}} &darr; {{c|#f80| 3 %}}, {{c|#f80|5 %}}
		+	* {{c|blue|Bazaar}} &darr; {{c|#f80|0.5 %}} ([http://solovyov.net/blog/2011/01/24/bzr-hate-and-hate/ hate and hate])
		+
		+	=== Недостатки DVCS — текст ===
		+
		+	<slides title="Но есть у них и недостатки" float="right" width="300">
		+	* Размер репозитория растёт: <br /> Собрать Android recovery &rArr; качаем {{c|red|>4.8 Гб :(}}
		+	* [[lib:Version_Control_and_“the_80%25”|80 % и 20 % разработчиков]]: <br /> Синдром кодовой бомбы
		+	* <s style="color: red">Несколько проектов в репозитории</s>
		+	</slides>
		+
		+	Есть у DVCS и некоторые недостатки: например, то, что размер репозитория со временем сильно растёт, не очень удобно. Хороший пример — это исходники [http://android.com/ Андроида], хранящиеся в Git. Чтобы попытаться собрать хотя бы recovery (образ «консоли восстановления» для телефона), нужно выкачать '''4.8 Гб''' исходников! Также, [[lib:Version_Control_and_“the_80%25”|говорят]], бывает, что разработчики начинают много коммитить локально, а потом «сбрасывают кодовые бомбы» на остальных. Как к этому относиться — личное дело каждого, можно считать, что виноваты всё-таки разработчики, а не DVCS (те самые «80 %» разработчиков — наверное, быдлокодеров). Также менеджеры негодуэ, потому что невозможен контроль доступа к частям репозитория. Но если это жмёт, нужно просто разбить репозитории на несколько и немного упростить выдачу прав. Ну, а «корпоративный народ» может отнестись к этим системам, пришедшим из мира Opensource, не очень хорошо. В общем и целом, все недостатки решаемые.
		+
		+	{{----}}
		+
		+	== Bug Tracker ==
		+
		+	<slides split="-----" float="right" width="480">
		+	Учёт задач
		+
		+	[[Файл:Habrastat_tasks.svg]]
		+
		+	Статистика с хабра, сильно неточная, но {{c|#0a0|даёт повод для размышлений}}
		+	</slides>
		+
		+	'''Bug Tracker''' — это система отслеживания задач (а не только '''ошибок'''). Очень часто «баг» рассматривают именно как «ошибку», хотя это вопрос терминологии — в реальности, «багом» можно назвать любую задачу, запрос и т. п. — любое нечто, исходящее от кого-то одного и требующее реакции от кого-то другого. В силу широты формулировки и наличия большого множества задач, большинство баг-трекеров устроено и выглядит монстровато.
		+
		+	Казалось бы, и баг-трекером уже никого не удивишь, но оказывается, и это не так. Часто для разных задач используется всё что угодно, но только не баг-трекер. Причиной для этого может являться чрезмерная «специфичность» используемой системы, когда менеджерским взглядом в неё вкручены диаграммы Ганта и прочие радости (один из разработчиков Luxproject’а использует для разных задач '''всё что угодно, только не Luxproject'''<ref>Пруфлинк, см. [[lib:KISS or my own time-management best practice (Антон Зотин, Stratoplan World, 2011-05-17)]], начиная с 23:00. См. также [[lib:Time Management для программиста (Михаил Гедзберг, ADD-2011)]], где опять-таки менеджер из LuxSофта пользуется исключительно Outlookом.</ref>).
		+
		+
		+	=== Bug Tracker ⌘⌘ ===
		+
		+	* {{c|red|text = «Bug» != «Ошибка» ! ! !}}
		+	* «Bug» = {{c|#0a0|&forall; (любая)}} задача:
		+	** Ошибка, запрос фичи, вопрос поддержке
		+
		+	Хотя различать любят:
		+
		+	<blockquote style="color: blue; font-size: 70%">…I define a bug as behavior in a «Done» story that violates valid expectations…</blockquote>
		+
		+	<slides split="-----">
		+
		+	Примеры
		+
		+	-----
		+
		+	<big>[http://www.graphviz.org/bugs/buglist.html Minimalistic]</big>
		+
		+	{{UnscaleImage|GraphvizBugs1.png|300}}{{UnscaleImage|GraphvizBugs.png|300}}{{UnscaleImage|GraphvizBugs2.png|300}}
		+
		+	(баги в Graphviz) <big>☺</big>
		+
		+	-----
		+
		+	<big>Bugzilla</big>
		+
		+	[[Файл:BugzillaBugForm.png]]
		+
		+	-----
		+
		+	<big>Mantis</big>
		+
		+	[[Файл:MantisBTForm.png]]
		+
		+	-----
		+
		+	<big>Jira</big>
		+
		+	[[Файл:ProjectManagementWithJiraGreenHopper.pdf|page=17|600px]]
		+	{{UnscaleImage|JiraIssueForm.png|600}}
		+
		+	-----
		+
		+	<big>Roundup</big>
		+
		+	[[Файл:RoundupBugForm.png]]
		+
		+	-----
		+
		+	<big>Trac {{refstar}}</big>
		+
		+	[[Файл:TracBugForm.png]]
		+
		+	{{refstar}} Не только Bug Tracker
		+
		+	-----
		+
		+	<big>Баги на Google Code {{refstar}}</big>
		+
		+	[[Файл:GoogleCodeBugForm.png]]
		+
		+	{{refstar}} Посимпатичнее, но и возможностей мало
		+
		+	-----
		+
		+	А так — все {{c|blue|похожи}}, все {{c|#0a0|монстроваты}}
		+
		+	[[File:Note.svg]] Как ни странно, даже Minimalistic
		+
		+	И Jira — хотели переписать багзиллу, а вышло страшнее :)
		+
		+	</slides>
		+
		+	== Wiki ==
		+
		+	<slides float="right" width="400" split="-----" title="Wiki">
		+	* [http://c2.com/cgi-bin/wiki Первая Wiki] — 1995 («WikiWikiWeb»).
		+	* В честь автобусов {{c|blue|«Wiki Wiki Shuttle»}} в аэропорту Гонолулу, вместо «Quick Web»
		+	* Принципы Wiki:
		+	** {{c|#0a0|☺ Быстрая правка}}
		+	** {{c|#0a0|☺ Plaintext разметка}}
		+	** {{c|#0a0|☺ Версионность}}
		+	</slides>
		+
		+	Сейчас на дворе уже третье тысячелетие, через пару лет, то ли конец света будет, то ли Великая Сингулярность, то ли нефть кончится,
		+	и рассказывать что такое вики-системы и чем они хороши, вроде как страшный баян.
		+	И все же, если вдруг будет время, то у нас (опять-таки!), есть статья и выступление на конференции по этой теме<ref>См. [[lib:MediaWiki — Серебряная пуля или швейцарский нож?]] — почему вики-системы стали так популярны, и чем хороша именно MediaWiki.</ref>.
		+
		+	=== Вики-движки ⌘⌘ ===
		+
		+	http://wikimatrix.org/ - вики-движков {{c|blue|> 130!}}
		+
		+	Популярные:
		+	<tab sep="bar" class="wikitable" head="top">
		+	[http://mediawiki.org/ MediaWiki]<br />{{UnscaleImage|MediaWiki-notext.svg|64}}<br /> (Wikipedia) | [http://moinmo.in/ MoinMoin]<br />{{UnscaleImage|Moinmoin.svg|64}} | [http://dokuwiki.org/ DokuWiki]<br />{{UnscaleImage|Dokuwiki-128.png|64}}
		+	</tab>
		+
		+	=== Win / Fail ⌘⌘ ===
		+
		+	{{c|#0a0|Win}}: гипертекст<sup>в&nbsp;абсолюте</sup> ! <span style="font-size: 150%; color: #0a0">☺</span>
		+
		+	{{c|#b00|Fail}}: плохо с атрибутикой <span style="font-size: 150%; color: #b00">☹</span>
		+	* Однако, гипертекст rules, если есть поиск{{refstar}}
		+	* Есть [http://semantic-mediawiki.org/ Semantic MediaWiki]
		+
		+	<small>{{refstar}} Goo… Guess who?</small>
		+
		+	<slides split="-----">
		+
		+	<big>Wikipedia</big>
		+
		+	[[Файл:RupediaMain.png]]
		+
		+	-----
		+
		+	<big>MoinMoin</big>
		+
		+	[[File:DebianWikiMain.png]]
		+
		+	-----
		+
		+	<big>DokuWiki</big>
		+
		+	[[File:DokuwikiMain.png]]
		+
		+	</slides>
		+
		+	= [http://4intra.net/ 4intra.net] и наши доработки =
		+
		+	Однако «дикая» MediaWiki для компании-разработчика не особо хороша,
		+	и конечно при сравнении «в лоб» проигрывает «специально обученным корпоративным вики-системам».
		+
		+	Но если «укротить» и немного обработать напильником, MediaWiki становится фантастически удобной системой для
		+	компании-разработчика, решающая практически все проблемы управления знаниями, требованиями, тестами и т. п., которые могут возникнуть<ref>
		+	Тут мы очень рекомендуем вам взглянуть на наши доклады [[lib:Knowledge Management: От Склада к Потоку (Software People-2010)]], [[lib:Все блюда для интранета из MediaWiki: ВикиБлоги, ВикиПрезентации, ВикиЭкзамены и ВикиЗакладки (Виталий Филиппов на ADD-2010)]] и статью [[lib:Оранжерея знаний с MediaWiki]].</ref>.
		+
		+	Затратив еще немного сил (как обычно, с использованием «напильника и такой-то матери»), можно эффективно «увязать» то небольшое число готовых, вышеупомянутых систем, получив шикарный интранет-разработчика «with Black Jack & Hookers»©<ref>Рекомендуем взглянуть на [[lib:Свободные системы, спасающие разработчиков (РИТ-2010)]]</ref>.
		+
		+	И мы уже прошли этот путь, отобрали самые интересные расширения, доработали и переработали их, написали кучу своих, и даже решали проблемы производительности и разгона<ref>См. [[lib:PHP-разгон: серебряная пуля из автомата Комменца-Вальтера (Commentz-Walter)]]</ref>, управления правами (самое уязвимое место «природной MediaWiki»), научив все веб-системы не только «плеваться почтой», но и смиренно отдавать RSS-feedы, а всех сотрудников — пользоваться RSS-агрегаторами (и даже развернув корпоративный «Google Reader» — [[FeedOnFeeds]].
		+	И все это готовое предлагаем вам совершенно свободно и даром<ref>"Счастье всем, даром, и пусть никто не уйдет обиженным!" ©</ref>.
		+
		+	Нет, это не было изобретением велосипедов, объем доработок по сравнению с объемом trunkа был невелик, сначала это было практически хобби (10 % времени) одного [http://belonesox.moikrug.ru веб-любителя], но теперь этим (хотя и не на 100 %) стал заниматься настоящий [http://yourcmc.ru/wiki/User:VitaliyFilippov веб-профессионал], и нам уже не стыдно выкладывать все это в open-source.
		+
		+	Кроме того, большинство доработок оформлены в виде расширений ''MediaWiki'', и поэтому в будущем не умрут, как это обычно случается с «велосипедами», а останутся рабочими и доступными для сообщества.
		+
		+	=== FeedOnFeeds ⌘⌘ ===
		+	[[Файл:Feed-on-feeds.avi.flv]]
		+
		+	=== [http://wiki.4intra.net/ 4intra.net] ⌘⌘ ===
		+
		+	Opensource с декабря 2010
		+
		+	* [http://wiki.4intra.net/MediaWiki4Intranet MediaWiki4Intranet]
		+	** <small>~60 расширений, ~40 патчей, установка <tt>hg clone</tt></small>
		+	* [http://wiki.4intra.net/Bugzilla4Intranet Bugzilla4Intranet]
		+	** <small>> 100 фич/изменений</small>
		+
		+	=== Mindmap ⌘⌘ ===
		+	[[Файл:Tools-4intranet.mm]]
		+
		+
		+	=== Медиавозможности ⌘⌘ ===
		+
		+	* [[Справка:Формулы|LaTeX]]
		+	* [[Graphviz]], [[Справка:UML|UML]], [[Gnuplot]]
		+	* SVG, PDF, DjVu, TIFF, [[Справка:Изображения|Flash Video]], Mindmap
		+	* [[Справка:Коды|подсветка синтаксиса]]
		+
		+	=== Wiki-плюшки ⌘⌘ ===
		+
		+	{| class="wikitable" border="1"
		+	|
		+	* Презентации
		+	* Блоги/форумы{{refstar}}
		+	* Календарь
		+	* Опросы, экзамены
		+	||
		+	* ВикиЗакладки
		+	* Развесистые права
		+	* Импорт/экспорт
		+	* ...
		+	|}
		+
		+	<small>{{refstar}} что почти одно и то же</small>
		+
		+	<slides split="-----">
		+	Презентации S<sup>5</sup>{{refstar|#0a0}}
		+
		+	<small>HTML+JS, порождаемый из Plaintext</small>
		+
		+	<small>{{refstar|#0a0}} такую вы смотрите сейчас</small>
		+
		+	-----
		+
		+	Блоги/форумы{{refstar}}
		+
		+	<small>{{refstar}} Разница лишь в способе отображения</small>
		+
		+	-----
		+
		+	<big>Календарь</big>
		+
		+	Резервирование переговорки и т.п…
		+
		+	[[Файл:WikiCalendar.png]]
		+
		+	-----
		+
		+	IntraACL ({{c|#f80|Сильно развесистые права}})
		+
		+	[[Файл:IntraACL rights targets.svg]]
		+	[[Файл:IntraACL inherit.svg]]
		+
		+	-----
		+
		+	Примеры фич Bugzilla4Intranet:
		+
		+	<small style="color: #0a0">* При в целом том же внешнем виде</small>
		+
		+	-----
		+
		+	Excel-импорт/экспорт
		+
		+	[[File:BugsXLSImport.png]]
		+
		+	-----
		+
		+	Массовая загрузка вложений
		+
		+	[[File:BugzillaAddMultiple.png]]
		+
		+	-----
		+
		+	«Excuse-me» (ошибка с котёнком)
		+
		+	[[File:KittenErrorNew.jpg]]
		+
		+	<span style="font-size: 200%">☺</span>
		+
		+	-----
		+
		+	Email-управление, поиск с морфологией, HTML-почта, улучшения Custom полей
		+
		+	[http://wiki.4intra.net/Bugzilla4Intranet И так далее]
		+
		+	</slides>
		+
		+
		+	== Интеграция ⌘⌘ ==
		+
		+
		+	[[File:Tracker-to-vcs.avi.flv]]
		+
		+
		+
		+	=== Ещё интеграция ⌘⌘ ===
		+
		+
		+	[[File:Wiki-to-tracker.avi.flv]]
		+
		+
		+	== Куда двигаться дальше? ⌘⌘ ==
		+
		+	* Правильная Bugzilla
		+	** {{c|#f80|???}} а стоит ли?
		+	* Тесты, code review &rarr; {{c|#0a0|Wiki}}
		+	* Semantic Wiki
		+
		+	== Правильная Bugzilla ⌘⌘ ==
		+
		+	* С одной стороны, Bugzilla {{c|red|отстаёт от ''bleeding-edge''}}
		+	** {{c|#f80|Usability}} + {{c|#a00|Refactoring}}
		+	* Зато пока остальные делают {{UnscaleImage|Bicycle.gif|32}}{{UnscaleImage|Bicycle.gif|32}}{{UnscaleImage|Bicycle.gif|32}}{{UnscaleImage|Bicycle.gif|32}}, {{c|blue|она сохраняет HTML-простоту}}
		+	* {{c|#0a0|А потом нагонит на стандартах}}
		+
		+	=== [http://www.linux.org.ru/news/debian/5681284 LOR, Debian vs Ubuntu] ⌘⌘ ===
		+
		+	<blockquote>
		+	''> этих хомячков в сотни раз больше и именно на них ориентируюся производители ОС''
		+
		+	Когда делают операционную систему по dfsg, тогда ориентируются, прежде всего, на dfsg, а не играют в волшебников с голубыми вертолётами «хрен с ней, со свободой, главное игрушки». И благодаря этим неволшебникам, и существует, в том числе и убунта.
		+
		+	Ну будет Debian делать всё, как убунта, получится две убунты и ни одного дебиана, и, как следствие, ни одной убунты.
		+
		+	Не учите отцов, как им делать. Особенно, если вообще ничего не понимаете и ничего не решаете, а просто плывёте в потоке, ведь это единственные, кто думают о вашем завтра, чтобы не оказалось, что завтра вы уже не контролируете ровным счётом ничего.
		+	</blockquote>
		+
		+	=== {{c|#f80|Usability}} ⌘⌘ ===
		+
		+	<div class="floatright">{{UnscaleImage|Rugby_scrum.jpg|200}}</div>
		+	* JS grid
		+	* «Форум-функционал»
		+	* Agile
		+	** (вкрутить разумный минимум)
		+	{{----}}
		+
		+	=== {{c|#a00|Refactoring}} ⌘⌘ ===
		+
		+	* Переделать систему прав{{refstar}}
		+	** <small>{{refstar}} кто-то понимает MANDATORY/SHOWN/DEFAULT/NA ?</small>
		+	* {{UnscaleImage|Pistol-icon.png|32}} убить YAHOO UI {{c|#0a0|&rarr; jQuery}}
		+	* {{UnscaleImage|Pistol-icon.png|32}} копипасту {{c|#0a0|&rarr; прокачать объектный движок}}
		+	* {{UnscaleImage|Pistol-icon.png|32}} CGI.pm {{c|red|(детище 90-х…)}}
		+	* {{UnscaleImage|Pistol-icon.png|32}} Template Toolkit
		+	** или хотя бы {{UnscaleImage|Pistol-icon.png|32}} обратную связь из шаблонов
		+
		+	== Semantic Wiki ⌘⌘ ==
		+
		+	* «Семантическая Wiki»,
		+	* Она же {{c|#0a0|Wiki с атрибутикой}} - http://semantic-mediawiki.org/
		+	* Semantic Tracker
		+	** {{c|red|В пень Custom Fields!}}
		+
		+	= Примечания =
		+	<references/>
		+
		+	{{replicate-from-custiswiki-to-lib}}
		+	{{replicate-from-custiswiki-to-4intranet}}

---

Latest revision as of 17:53, 5 April 2012

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

У нас она начиналась с идей:

Open-Source

нет жестких ограничений — гибкость и опыт масс в одном флаконе.

Wiki + баг-трекер + система контроля версий

достаточно для всего.

Правильная вики ⇒ MediaWiki

мэйнстрим + расширяемость.

Кроме того, мы (в конце 2010г) наконец-то выполнили обещание выйти в Open-Source и теперь существует проект 4intra.net («фор интранет», то есть, «для интранета»), который вы можете попробовать своими руками.

Например, расширяемость превращает MediaWiki не просто в базу знаний или инструмент документирования, а даёт возможность сделать такие нетривиальные «плюшки», как

• система информационных потоков (читай — форумов и блогов),
• презентаций,
• опросов и экзаменов,
• личный «кэш» сетевых закладок

и так далее.

Не говоря уже о расширенных медиа-возможностях — вставке изображений и видео, графов и графиков, UML и MindMap’ов, TeX и прочих «фичах».

О том, как мы пришли к своему выбору, почему он всё больше совпадает с мировой практикой, что представляют из себя все эти, а также многие другие вкусности, реализуемые с помощью MediaWiki, Bugzilla, SVN, ViewVC, FeedOnFeeds и так далее, и о том, куда двигаться дальше, и будет доклад.

Wiki-Way и выбор систем

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

Wiki-Way мы называем именно натуральный эволюционный подход с максимально упрощёнными концепциями. Вообще говоря, кто-то другой мог назвать его ещё как-нибудь — хоть «Web 2.0», хоть «гибкий», хоть «Agile», но мы выбрали термин «Wiki-Way» — Wiki являются его апогеем.

Этот конфликт, между «жестким, заданным априори» и «гибким, адаптирующимся к меняющимся потребностям пользователя и ограничениям среды» встречается повсеместно. В культуре разработке кстати тоже, рекомендуем вам взглянуть на книгу «lib:Культуры программных проектов (Энтони Лаудер)» — там этот конфликт выражен противоречием между «заводской» и «сервисной» культурой (offtopic: с очень неоднозначным положением культуры «дизайнерской»).

Выбор систем

«Ящик Вендора»

Закрытые платные системы крупных производителей («вендоров»).

«Велосипед» или «Лунапарк»

Да, то самое, что нестерпимо хочется изобрести самому, и сделать это обязательно с блекджеком и шлюхами ©.

«Жадный интегратор» или «Футбол Хоттабыча»

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

Ящик Вендора: Плюсы? Минусы? ⌘⌘

• Сильносвязанный
  • «☺ Отлично, всё интегрировано?»
  • ☹ Шаг в сторону — считается побег !
    
  • ☹ Меньше думать может оказаться вредно
• Закрытый
  • «☺ Кому в нём копаться?»
  • ☹ Недостатки не исправить !

Велосипед

YATUP ⌘⌘

Файл:Yatup.avi.flv

CLOC ⌘⌘

• MediaWiki: 185000 PHP, 577000 локализация
• Bugzilla 3.6: 72000 Perl, 35000 TT
  • 4.0: +10000 Perl, +3000 TT

И в них ведь есть какой-то смысл (!)

Может, не стоит писать заново ?

Сочетание систем

Идея родилась у нас ещё N (≈ 8) лет назад^[1], а в последнее время, похоже, распространяется всё больше и больше, возьмите хотя бы Google Code или любой GitHub / Bitbucket / Launchpad.

Логика была следующая — почти все объекты, с которыми приходится иметь дело разработчику, можно разделить на три части:

Ответственность

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

Артефакты

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

Знания

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

В этой троице каждому из типов соответствует (одна!) своя система, что и даёт такое удобство. Wiki для знаний, VCS для артефактов, issue-трекер для задач и багов.

Частично они могут пересекаться. На самом деле, набор этих систем столь мощный, что можно «отрубить» одну или даже две, и оставшиеся всё равно будут пытаться «покрывать» большую часть процессов. И при этом они будут конкурировать, и вытеснять более специализированные системы^[2]. Ну и мы знаем несколько неудачных случаев попытки интеграции большего числа более специализированных систем (подобранных по принципу «футбол Хоттабыча» — «для каждого типа объекта в разработке пусть будет самая лучшая специализированная система его учета»)^[3]

С чем имеет дело разработчик? ⌘⌘

• Код, тесты
• Баги, задачи, постановки
• Документация
• Новости, обсуждения
• …

А бешеный заяц на слайде выше — это Мартовский заяц из Диснеевской Алисы в Стране чудес, иллюстрирующий CVSnt, очень сомнительного качества доработанный CVS, произведённый на свет компанией March Hare Software.

Кстати, в это трудно поверить, но надо признаться, что у нас в компании до сих пор есть проекты использующие CVS. Использование CVS обусловлено накопленным legacy-опытом (специальные утилиты deploy и testing, завязанные на CVS), плюс legacy-технологии таковы, что переход на SVN или DVCS почти ничего не дает (ветвится вокруг неизменной терабайтной базы бессмысленно, переименования серверных пакетов чрезвычайно редки и т.п.). В общем, CVS у нас работает, как до сих пор работают паровозы в Китае, и мы рассчитываем, что он отомрет естественно, вместе со сменой legacy-технологий.

ViewVC

ViewVC^[1].

Для нас большой плюс, что он поддерживает и SVN и CVS (см. выше).

ViewVC ⌘⌘

right ViewVC → web-интерфейс к CVS & SVN

• Его можно считать частью VCS.
  • У git и hg веб-интерфейс вообще в стоке.
• Тоже чуть докручен

Трекер и вики

Epic Win’ы MediaWiki ⌘⌘

• Расширяемость:
  1700 расширений и очень легко пишутся
• Отсутствие суррогатных ID:
  http://lib.custis.ru/Как_прекратить_писать_(Андрей_Аксенов_на_ADD-2010)
• Производительность и кэши:
  Ну, Wikipedia же ворочается!
• Локализация:
  352 локали (!)

Альтернативы

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

VCS

Что такое VCS (система контроля версий), надеемся, известно всё-таки уже всем^[1]. Для тех, кто в танке — это система, помогающая хранить не одну версию файлов продукта, а много сразу, в любой момент возвращаться к любой версии, просматривать информацию о версиях и т. п. Первой системой контроля версий был RCS, потом из него вырос CVS, а после CVS появился Subversion для «свержения» (англ. subversion) и исправления недостатков CVS’а.

CVS и Subversion — наиболее распространённые представители централизованных систем, в который репозиторий (хранилище версий) располагается на одном «центральном» сервере, а на компьютерах разработчиков размещаются только «рабочие копии», соответствующие какой-то одной версии. Модной в последнее время альтернативой этому подходу являются распределённые системы управления версиями, хранящие весь репозиторий в каждой рабочей копии.

Что важно для удобства, DVCS поддерживают расширенные возможности отслеживания ветвлений и объединения изменений, потому что без этого объединять безумные графы изменений, приходящих от разных разработчиках в OpenSource проектах, было бы невозможно.

Самые известные lib:DVCS — это Git, Mercurial (hg) и Bazaar. Возможно, вы также слышали о Darcs и Monotone. Хранение полной истории ревизий в каждой рабочей копии, кроме всего прочего, даёт ещё и «естественное резервное копирование».

DVCS сейчас действительно «в моде», это даже подтверждают данные двух одинаковых опросов от 26 октября 2009 и 2010 годов на Хабре — SVN и CVS потеряли 3 % и 5 %, а Git и Hg приобрели те же 5.5 % и 3 %.

Bazaar, правда, потерял полпроцента (а я говорил! И не только я).

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

Статистика ⌘⌘

Файл:Habrastat_VCS_2010-10-26.svg

DVCS в моде ⌘⌘

За год:

• Git, Hg ↑ 5.5 %, 3 %
• SVN, CVS ↓ 3 %, 5 %
• Bazaar ↓ 0.5 % (hate and hate)

Недостатки DVCS — текст

Есть у DVCS и некоторые недостатки: например, то, что размер репозитория со временем сильно растёт, не очень удобно. Хороший пример — это исходники Андроида, хранящиеся в Git. Чтобы попытаться собрать хотя бы recovery (образ «консоли восстановления» для телефона), нужно выкачать 4.8 Гб исходников! Также, говорят, бывает, что разработчики начинают много коммитить локально, а потом «сбрасывают кодовые бомбы» на остальных. Как к этому относиться — личное дело каждого, можно считать, что виноваты всё-таки разработчики, а не DVCS (те самые «80 %» разработчиков — наверное, быдлокодеров). Также менеджеры негодуэ, потому что невозможен контроль доступа к частям репозитория. Но если это жмёт, нужно просто разбить репозитории на несколько и немного упростить выдачу прав. Ну, а «корпоративный народ» может отнестись к этим системам, пришедшим из мира Opensource, не очень хорошо. В общем и целом, все недостатки решаемые.

Bug Tracker

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

Казалось бы, и баг-трекером уже никого не удивишь, но оказывается, и это не так. Часто для разных задач используется всё что угодно, но только не баг-трекер. Причиной для этого может являться чрезмерная «специфичность» используемой системы, когда менеджерским взглядом в неё вкручены диаграммы Ганта и прочие радости (один из разработчиков Luxproject’а использует для разных задач всё что угодно, только не Luxproject^[1]).

Bug Tracker ⌘⌘

• «Bug» != «Ошибка» ! ! !
• «Bug» = ∀ (любая) задача:
  • Ошибка, запрос фичи, вопрос поддержке

Хотя различать любят:

…I define a bug as behavior in a «Done» story that violates valid expectations…

Wiki

Сейчас на дворе уже третье тысячелетие, через пару лет, то ли конец света будет, то ли Великая Сингулярность, то ли нефть кончится, и рассказывать что такое вики-системы и чем они хороши, вроде как страшный баян. И все же, если вдруг будет время, то у нас (опять-таки!), есть статья и выступление на конференции по этой теме^[1].

Вики-движки ⌘⌘

http://wikimatrix.org/ - вики-движков > 130!

Популярные:

MediaWiki Template:Localimage:MediaWiki-notext.svg" width="64" /> (Wikipedia)	MoinMoin Template:Localimage:Moinmoin.svg" width="64" />	DokuWiki Template:Localimage:Dokuwiki-128.png" width="64" />

Win / Fail ⌘⌘

Win: гипертекст^{в абсолюте} ! ☺

Fail: плохо с атрибутикой ☹

• Однако, гипертекст rules, если есть поиск*
• Есть Semantic MediaWiki

* Goo… Guess who?

4intra.net и наши доработки

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

Но если «укротить» и немного обработать напильником, MediaWiki становится фантастически удобной системой для компании-разработчика, решающая практически все проблемы управления знаниями, требованиями, тестами и т. п., которые могут возникнуть^[1].

Затратив еще немного сил (как обычно, с использованием «напильника и такой-то матери»), можно эффективно «увязать» то небольшое число готовых, вышеупомянутых систем, получив шикарный интранет-разработчика «with Black Jack & Hookers»©^[2].

И мы уже прошли этот путь, отобрали самые интересные расширения, доработали и переработали их, написали кучу своих, и даже решали проблемы производительности и разгона^[3], управления правами (самое уязвимое место «природной MediaWiki»), научив все веб-системы не только «плеваться почтой», но и смиренно отдавать RSS-feedы, а всех сотрудников — пользоваться RSS-агрегаторами (и даже развернув корпоративный «Google Reader» — FeedOnFeeds. И все это готовое предлагаем вам совершенно свободно и даром^[4].

Нет, это не было изобретением велосипедов, объем доработок по сравнению с объемом trunkа был невелик, сначала это было практически хобби (10 % времени) одного веб-любителя, но теперь этим (хотя и не на 100 %) стал заниматься настоящий веб-профессионал, и нам уже не стыдно выкладывать все это в open-source.

Кроме того, большинство доработок оформлены в виде расширений MediaWiki, и поэтому в будущем не умрут, как это обычно случается с «велосипедами», а останутся рабочими и доступными для сообщества.

FeedOnFeeds ⌘⌘

Файл:Feed-on-feeds.avi.flv

4intra.net ⌘⌘

Opensource с декабря 2010

• MediaWiki4Intranet
  • ~60 расширений, ~40 патчей, установка hg clone
• Bugzilla4Intranet
  • > 100 фич/изменений

Mindmap ⌘⌘

Файл:Tools-4intranet.mm

Медиавозможности ⌘⌘

• LaTeX
• Graphviz, UML, Gnuplot
• SVG, PDF, DjVu, TIFF, Flash Video, Mindmap
• подсветка синтаксиса

Wiki-плюшки ⌘⌘

Презентации Блоги/форумы* Календарь Опросы, экзамены

ВикиЗакладки Развесистые права Импорт/экспорт ...

* что почти одно и то же

Интеграция ⌘⌘

Ещё интеграция ⌘⌘

Куда двигаться дальше? ⌘⌘

• Правильная Bugzilla
  • ??? а стоит ли?
• Тесты, code review → Wiki
• Semantic Wiki

Правильная Bugzilla ⌘⌘

• С одной стороны, Bugzilla отстаёт от bleeding-edge
  • Usability + Refactoring
• Зато пока остальные делают , она сохраняет HTML-простоту
• А потом нагонит на стандартах

LOR, Debian vs Ubuntu ⌘⌘

> этих хомячков в сотни раз больше и именно на них ориентируюся производители ОС

Когда делают операционную систему по dfsg, тогда ориентируются, прежде всего, на dfsg, а не играют в волшебников с голубыми вертолётами «хрен с ней, со свободой, главное игрушки». И благодаря этим неволшебникам, и существует, в том числе и убунта.

Ну будет Debian делать всё, как убунта, получится две убунты и ни одного дебиана, и, как следствие, ни одной убунты.

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

Usability ⌘⌘

• JS grid
• «Форум-функционал»
• Agile
  • (вкрутить разумный минимум)

Refactoring ⌘⌘

• Переделать систему прав*
  • * кто-то понимает MANDATORY/SHOWN/DEFAULT/NA ?
• убить YAHOO UI → jQuery
• копипасту → прокачать объектный движок
• CGI.pm (детище 90-х…)
• Template Toolkit
  • или хотя бы обратную связь из шаблонов

Semantic Wiki ⌘⌘

• «Семантическая Wiki»,
• Она же Wiki с атрибутикой - http://semantic-mediawiki.org/
• Semantic Tracker
  • В пень Custom Fields!

Примечания