Difference between revisions of "Эволюция Wiki-Way командной разработки/Презентация"

From Wiki4Intranet
Jump to: navigation, search
 
(2 intermediate revisions by one other user not shown)
Line 1: Line 1:
−
{{:Wiki-Way}}
 
 
<slideshow title="" style="custis" scaled="true" font="Calibri, Segoe Print, cursive" footer="" headingmark="⌘⌘" />
 
<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

Slide Show
Slide Show
Author

Stas Fomin
Subfooter

Stas Fomin, 17:53, 5 April 2012

Эволюция Wiki-Way командной разработки

Виталий Филиппов, Стас Фомин

CUSTIS

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

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

Open-Source
нет жестких ограничений — гибкость и опыт масс в одном флаконе.
Wiki + баг-трекер + система контроля версий
достаточно для всего.
Правильная вики ⇒ MediaWiki
мэйнстрим + расширяемость.

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

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

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

и так далее.

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

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

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

Парадигма проектирования нового

Blueprint.png Инженерная
Джамшут-Лестница.png

Парадигма проектирования нового

Файл:ParaWiki.jpg

Wiki-Way

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

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

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

Выбор систем

Выбор систем

Ящик Вендора
Закрытый, сильносвязанный, платный
Велосипед
Быстро создать, тяжело поддерживать
Футбол Хоттабыча
Кажется идеалом, Не взлетит
«Ящик Вендора»
Закрытые платные системы крупных производителей («вендоров»).
«Велосипед» или «Лунапарк»
Да, то самое, что нестерпимо хочется изобрести самому, и сделать это обязательно с блекджеком и шлюхами ©.
«Жадный интегратор» или «Футбол Хоттабыча»
поставить все что можно (особенно если бесплатные системы) и потом пытаться все это интегрировать, а пользователей учить всем этим пользоваться.

Ящик Вендора

BlackBox.jpg

Interlinked.gif

LockedLock.jpg

Handcuffs.jpg

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

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

Велосипед

Велосипед

Файл:Bicycle.gif

YATUP ⌘⌘

Файл:Yatup.avi.flv

Пользователи: *FACEPALM*

Админы: *FACEPALM*
Программист: (сбежал)

CLOC ⌘⌘

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

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

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

Всё это ☹.

А как ☺?

⇒ MainStream!

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

Wiki + трекер + VCS — cочетание используется всё чаще:

Trac

GitHub, Bitbucket, Google Code, Launchpad

Github.png

Bitbucket.png GoogleCode.jpg

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

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

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

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

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

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

  • Код, тесты
  • Баги, задачи, постановки
  • Документация
  • Новости, обсуждения
  • …
Файл:DevCircles-NoCircles.svg
  1. ↑ Ну вообще-то, эволюция к этому метастабильному состоянию, была примерно такой:
    • 1996: CVS
    • 2001-2002: Bugzilla
    • 2003: MediaWiki

    но при этом мы таки немного комплексовали, перед «профессионалами» с крутыми системами «поддержки полного жизненного цикла разработки», и только в 2007 году, мы вылезли с этой темой на конференцию, где внезапно обнаружили, что мы не одиноки, и почти также живут все, включая (!) самих разработчиков этих самых «крутых систем»

  2. ↑ Например, мы пытались понять, почему непопулярны testmanagement-системы
  3. ↑ Мы случайно сохранили типичную презентацию такого подхода, который пыталась реализовать очень сильная команда разработчиков. Мы предлагаем взглянуть на слегка обфускированную версию, где мы, чтобы не бросить тень на уважаемую нами компанию, убрали упоминания названия этой компании, а также брендов и торговых марок. 256px|right

Файл:Subversion logo.png

На данный момент вершина эволюции CVCS :)

Файл:March-hare-2.jpg

Ещё жив CVS(nt) (March Hare)

* А зря nt

А бешеный заяц на слайде выше — это Мартовский заяц из Диснеевской Алисы в Стране чудес, иллюстрирующий 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 веб-интерфейс вообще в стоке.
  • Тоже чуть докручен Hackwrench.jpg

Трекер и вики

Трекер: Bugzilla*

* при всех недостатках. Самый большой →→→

→ Сложность расширения!

(… кривость объектного движка)
  1. ↑ Более подробно о нем можно почитать или посмотреть наше выступление на конференции.

Epic Win’ы MediaWiki ⌘⌘

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

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

VCS

VCS*

Централизованные и распределённые

CVS, SVN → Git, Mercurial, Bazaar (, Monotone, Darcs)

* известно почти всем

Что такое 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 %.

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

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

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

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

DVCS в моде ⌘⌘

За год:

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

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

Но есть у них и недостатки

  • Размер репозитория растёт:
    Собрать Android recovery ⇒ качаем >4.8 Гб :(
  • 80 % и 20 % разработчиков:
    Синдром кодовой бомбы
  • Несколько проектов в репозитории
  • ↑ Мы тоже внесли некоторый вклад в «пропаганду VCS», сериями статей и переводов, а также выступлениями на конференциях

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

    Bug Tracker

    Учёт задач

    Файл:Habrastat_tasks.svg

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

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

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


    Bug Tracker ⌘⌘

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

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

    …I define a bug as behavior in a «Done» story that violates valid expectations…
    Примеры
    1. ↑ Пруфлинк, см. lib:KISS or my own time-management best practice (Антон Зотин, Stratoplan World, 2011-05-17), начиная с 23:00. См. также lib:Time Management для программиста (Михаил Гедзберг, ADD-2011), где опять-таки менеджер из LuxSофта пользуется исключительно Outlookом.

    Minimalistic

    GraphvizBugs1.pngGraphvizBugs.pngGraphvizBugs2.png

    (баги в Graphviz) ☺

    Trac *

    Файл:TracBugForm.png

    * Не только Bug Tracker

    Баги на Google Code *

    Файл:GoogleCodeBugForm.png

    * Посимпатичнее, но и возможностей мало

    А так — все похожи, все монстроваты

    Note.svg Как ни странно, даже Minimalistic

    И Jira — хотели переписать багзиллу, а вышло страшнее :)

    Wiki

    Wiki

    • Первая Wiki — 1995 («WikiWikiWeb»).
    • В честь автобусов «Wiki Wiki Shuttle» в аэропорту Гонолулу, вместо «Quick Web»
    • Принципы Wiki:
      • ☺ Быстрая правка
      • ☺ Plaintext разметка
      • ☺ Версионность

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

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

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

    Популярные:

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

    Win / Fail ⌘⌘

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

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

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

    * Goo… Guess who?

    Wikipedia

    Файл:RupediaMain.png
    1. ↑ См. lib:MediaWiki — Серебряная пуля или швейцарский нож? — почему вики-системы стали так популярны, и чем хороша именно MediaWiki.

    MoinMoin

    DebianWikiMain.png

    DokuWiki

    DokuwikiMain.png

    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

    Mindmap ⌘⌘

    Файл:Tools-4intranet.mm


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

    Wiki-плюшки ⌘⌘

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

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

    Презентации S5*

    HTML+JS, порождаемый из Plaintext

    * такую вы смотрите сейчас
    1. ↑ Тут мы очень рекомендуем вам взглянуть на наши доклады lib:Knowledge Management: От Склада к Потоку (Software People-2010), lib:Все блюда для интранета из MediaWiki: ВикиБлоги, ВикиПрезентации, ВикиЭкзамены и ВикиЗакладки (Виталий Филиппов на ADD-2010) и статью lib:Оранжерея знаний с MediaWiki.
    2. ↑ Рекомендуем взглянуть на lib:Свободные системы, спасающие разработчиков (РИТ-2010)
    3. ↑ См. lib:PHP-разгон: серебряная пуля из автомата Комменца-Вальтера (Commentz-Walter)
    4. ↑ "Счастье всем, даром, и пусть никто не уйдет обиженным!" ©

    Блоги/форумы*

    * Разница лишь в способе отображения

    Календарь

    Резервирование переговорки и т.п…

    Файл:WikiCalendar.png

    IntraACL (Сильно развесистые права)

    Файл:IntraACL rights targets.svg

    Файл:IntraACL inherit.svg

    Примеры фич Bugzilla4Intranet:

    * При в целом том же внешнем виде

    Excel-импорт/экспорт

    BugsXLSImport.png

    Массовая загрузка вложений

    BugzillaAddMultiple.png

    «Excuse-me» (ошибка с котёнком)

    KittenErrorNew.jpg

    ☺

    Email-управление, поиск с морфологией, HTML-почта, улучшения Custom полей

    И так далее


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


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


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

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

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

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

    LOR, Debian vs Ubuntu ⌘⌘

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

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

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

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

    Usability ⌘⌘

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

    Refactoring ⌘⌘

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

    Semantic Wiki ⌘⌘

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

    Примечания


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

    Статья реплицируется в Wiki4IntraNet.
    Retrieved from "https://wiki.4intra.net/index.php?title=Эволюция_Wiki-Way_командной_разработки/Презентация&oldid=5039"