CustisWiki - Вклад участника [ru]

MediaWiki — Серебряная пуля или швейцарский нож?

2010-04-06T02:25:21Z

Trolzen: /* MediaWiki */ повторно: орфография/пунктуация

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

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

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

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

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

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

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

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

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

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

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

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

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

== Задачи ==

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

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

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

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

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

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

<graph>
digraph G{

rankdir=TB; node [style=filled, fillcolor="lavender", shape="rect" fontname="Segoe Print"]
"Совместная работа"
"Совместная работа"->"«IT»-команды"
"Совместная работа"->"C заказчиком или \n другими «не IT»-участниками"

"«IT»-команды"->"Эффективность"
"Эффективность" [fillcolor=darkolivegreen1]

"C заказчиком или \n другими «не IT»-участниками"->"Простота и доступность"
"Простота и доступность" [fillcolor=cadetblue2]

node[shape="egg"]
"Эффективность"->"Параллелизм"
"Эффективность"->"Скорость"
"Эффективность"->"Гибкость"

edge [constraint=0 style="dashed"]
"C заказчиком или \n другими «не IT»-участниками"->"Эффективность"

edge [arrowtail="vee" arrowhead="vee" color="red" constraint=0 label="несовместимость"]
"Эффективность"->"Простота и доступность"

}
</graph>

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

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

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

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

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

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

=== Knowledge management ===

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

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

<graph>
digraph G{

rankdir=TB;
node [style=filled, fillcolor="lavender", shape="rect" peripheries=1 fontname="PF Libera Pro"];
"KnowledgeBase"->"Фиксация знаний"
"KnowledgeBase"->"Рефакторинг \n знаний"
"KnowledgeBase"->"Извлечение \n знаний"

"Фиксация знаний"->"Легкость дополнений"

"Эффективность" [style=filled, fillcolor="palegreen1", shape="ellipse" peripheries=3]
"Рефакторинг \n знаний"->"Ссылки \n Рубрики \n категории \n ..."
"Рефакторинг \n знаний"->"Эффективность"
"Рефакторинг \n знаний"->"Актуальность"

"Актуальность"->"Простота и доступность"
"Извлечение \n знаний"->"Полнотекстовый поиск"
"Извлечение \n знаний"->"Быстрая \n навигация"
"Быстрая \n навигация"->"Ссылки \n Рубрики \n категории \n ..."
node [fillcolor=yellow]

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

}
</graph>

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

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

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

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

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

<graph>
digraph G{

rankdir=TB; node [style=filled, fillcolor="lavender", shape="rect" fontname="PF Libera Pro Liberissima"];
"Формат документа"->"Бинарный"
"Формат документа"->"Текстовый"

binarybad [label="Совместная работа \n без блокировок \n чрезвычайно затруднена" style=filled shape=egg]
textgood [label="Совместная работа \n без блокировок \n «Изменение-Слияние»" style=filled shape=egg]
"Бинарный"->binarybad
"Текстовый"->textgood

textgood->"Автоматические \n слияния"
textgood->"Построчные \n различия"
textgood->"Эффективное \n хранение версий"
node [fillcolor=yellow]

binarybad [fillcolor="lightpink" ]
textgood [fillcolor="palegreen"]

}
</graph>

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

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

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

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

<graph>
digraph G{

rankdir=LR; node [fontname="sans-serif" style=filled, fillcolor="lavender", shape="rect" fontname=Festus];
edge [color=blue4]
"Для Машины"
"Для Человека"

"Для Машины" ->SGML
"Для Машины" ->"Препроцессоры"

"Препроцессоры"->TeX
"Препроцессоры"->M4

TeX->LateX

SGML->Docbook
SGML->HTML
SGML->XML
node [fillcolor=yellow]

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

}

</graph>

<graph>
digraph G{

rankdir=LR; node [fontname="sans-serif" style=filled, fillcolor="lavender", shape="rect" fontname=Festus];
edge [color=blue4]
"Для Машины"
"Для Человека"

node [fillcolor=cornsilk shape=none]
"Для Человека"->"Plain ASCII"

"Plain ASCII"->"Wiki-markups"
"Plain ASCII"->"BBCode"
"Plain ASCII"->"Комментарии в коде"
"Plain ASCII"->"Textile"
"Plain ASCII"->"Markdown"
"Plain ASCII"->"reStructuredText"
"Plain ASCII"->"txt2tags"
"Wiki-markups" [fillcolor="chartreuse"]
node [fillcolor=yellow]

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

}

</graph>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

===MediaWiki===

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<references/>

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

Выступление с докладом по этой теме:
* [http://team.custis.ru/2008/12/mediawiki.html внутренний семинар перед SECR-2008].
* [http://team.custis.ru/2009/06/sef-2009.html скринкаст с SEF-2009].

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

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

MediaWiki — Серебряная пуля или швейцарский нож?

2010-03-27T18:39:11Z

Trolzen: /* MediaWiki */ орфография

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

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

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

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

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

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

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

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

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

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

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

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

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

== Задачи ==

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

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

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

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

<graph>
digraph G{

rankdir=TB; node [style=filled, fillcolor="lavender", shape="rect" fontname="Segoe Print"]
"Совместная работа"
"Совместная работа"->"«IT»-команды"
"Совместная работа"->"C заказчиком или \n другими «не IT»-участниками"

"«IT»-команды"->"Эффективность"
"Эффективность" [fillcolor=darkolivegreen1]

"C заказчиком или \n другими «не IT»-участниками"->"Простота и доступность"
"Простота и доступность" [fillcolor=cadetblue2]

node[shape="egg"]
"Эффективность"->"Параллелизм"
"Эффективность"->"Скорость"
"Эффективность"->"Гибкость"

edge [constraint=0 style="dashed"]
"C заказчиком или \n другими «не IT»-участниками"->"Эффективность"

edge [arrowtail="vee" arrowhead="vee" color="red" constraint=0 label="несовместимость"]
"Эффективность"->"Простота и доступность"

}
</graph>

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

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

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

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

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

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

=== Knowledge management ===

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

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

<graph>
digraph G{

rankdir=TB;
node [style=filled, fillcolor="lavender", shape="rect" peripheries=1 fontname="PF Libera Pro"];
"KnowledgeBase"->"Фиксация знаний"
"KnowledgeBase"->"Рефакторинг \n знаний"
"KnowledgeBase"->"Извлечение \n знаний"

"Фиксация знаний"->"Легкость дополнений"

"Эффективность" [style=filled, fillcolor="palegreen1", shape="ellipse" peripheries=3]
"Рефакторинг \n знаний"->"Ссылки \n Рубрики \n категории \n ..."
"Рефакторинг \n знаний"->"Эффективность"
"Рефакторинг \n знаний"->"Актуальность"

"Актуальность"->"Простота и доступность"
"Извлечение \n знаний"->"Полнотекстовый поиск"
"Извлечение \n знаний"->"Быстрая \n навигация"
"Быстрая \n навигация"->"Ссылки \n Рубрики \n категории \n ..."
node [fillcolor=yellow]

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

}
</graph>

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

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

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

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

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

<graph>
digraph G{

rankdir=TB; node [style=filled, fillcolor="lavender", shape="rect" fontname="PF Libera Pro Liberissima"];
"Формат документа"->"Бинарный"
"Формат документа"->"Текстовый"

binarybad [label="Совместная работа \n без блокировок \n чрезвычайно затруднена" style=filled shape=egg]
textgood [label="Совместная работа \n без блокировок \n «Изменение-Слияние»" style=filled shape=egg]
"Бинарный"->binarybad
"Текстовый"->textgood

textgood->"Автоматические \n слияния"
textgood->"Построчные \n различия"
textgood->"Эффективное \n хранение версий"
node [fillcolor=yellow]

binarybad [fillcolor="lightpink" ]
textgood [fillcolor="palegreen"]

}
</graph>

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

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

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

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

<graph>
digraph G{

rankdir=LR; node [fontname="sans-serif" style=filled, fillcolor="lavender", shape="rect" fontname=Festus];
edge [color=blue4]
"Для Машины"
"Для Человека"

"Для Машины" ->SGML
"Для Машины" ->"Препроцессоры"

"Препроцессоры"->TeX
"Препроцессоры"->M4

TeX->LateX

SGML->Docbook
SGML->HTML
SGML->XML
node [fillcolor=yellow]

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

}

</graph>

<graph>
digraph G{

rankdir=LR; node [fontname="sans-serif" style=filled, fillcolor="lavender", shape="rect" fontname=Festus];
edge [color=blue4]
"Для Машины"
"Для Человека"

node [fillcolor=cornsilk shape=none]
"Для Человека"->"Plain ASCII"

"Plain ASCII"->"Wiki-markups"
"Plain ASCII"->"BBCode"
"Plain ASCII"->"Комментарии в коде"
"Plain ASCII"->"Textile"
"Plain ASCII"->"Markdown"
"Plain ASCII"->"reStructuredText"
"Plain ASCII"->"txt2tags"
"Wiki-markups" [fillcolor="chartreuse"]
node [fillcolor=yellow]

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

}

</graph>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

===MediaWiki===

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<references/>

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

Выступление с докладом по этой теме:
* [http://team.custis.ru/2008/12/mediawiki.html внутренний семинар перед SECR-2008].
* [http://team.custis.ru/2009/06/sef-2009.html скринкаст с SEF-2009].

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

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

Обсуждение участника:StasFomin

2010-02-19T07:23:29Z

Trolzen: /* Не получается создать страницу обсуждения */

Уважаемый Стас Фомин!

Пишут Вам из редакции журнала «Потенциал» -
образовательного научно-популярного журнала для школьников и учителей.
Ссылка на официальный сайт журнала — http://potential.org.ru/bin/view/Home/WebHome
Он также представлен в wikibooks (http://ru.wikibooks.org/wiki/Журнал_"Потенциал")

На данном сайте (http://lib.custis.ru) мы обнаружили много разных хороших статей, которые можно было бы опубликовать в нашем журнале.
Нам бы хотелось связаться с авторами, чтобы узнать у них, не согласятся ли они подготовить ряд статей для журнала на основе имеющихся здесь.
Если с авторами связаться нельзя, то можем ли мы сами воспользоваться имеющимся здесь материалом?

В частности, нам интересна статья про машину Тьюринга
1) Знаете ли вы автора статьи про машину Тьюринга или аналогичного ему человека,который бы согласился переделать эту
статью в журнальном стиле и опубликовать ее в журнале «Потенциал»?
2) Если статью переделать некому или нельзя, каковы условия публикации, возможно, в измененном виде, данной статьи в нашем
журнале?

С уважением, Ольга Бутыгина и Артем Ворожцов. karagota@mail.ru

:[[Участник:StasFomin|Стас Фомин]] 12:38, 10 Apr 2006 (MSD): Статьи по сложности и машинам Тьюринга взяты из лекций (наших, с научным руководителем) по теории алгоритмов (и упрощены, как шпаргалка по основным понятиям) - PDF-файлы, посмотрите, может более интересно:
:* http://discopal.ispras.ru/ru.lectures.htm
:* http://discopal.ispras.ru/ru.lectures-mipt.htm

:Взять наверно можно, только для школьников, в более популярном стиле, есть наверно более подходящие книги и статьи (которых лучше взять за основу), например, на http://www.mccme.ru/free-books/
:* А.Китаев, А.Шень, М.Вялый. «Классические и квантовые вычисления.»
:* Н. К. Верещагин, А.Шень. «Языки и исчисления»
:* Н. К. Верещагин, А.Шень. «Вычислимые функции»

== Лицензия ==

какая лицензия материалов в вики?
можно ли их (частично) перенести в википедию?
:[[Участник:StasFomin|Стас Фомин]] 12:06, 2 May 2006 (MSD): Можно, только ставьте ссылку на оригинал в разделе «Ссылки» (что собственно и было написано в [[{{SITENAME}}]]). Наиболее приличные материалы я и сам в википедию переношу. К сожалению, в [[{{SITENAME}}]] реализовано много расширений, полезных для представления IT- и CS- информации — поддержка [[Graphviz]], [[Tex]], SVG, синтаксическая раскраска кодов и т. п. — без этого (в Википедии) все это выглядит достаточно бедно. Поэтому в википедию обычно переношу энциклопедический обьем, а непосредственно статьи-учебники поддерживаю в актуальности здесь.

== Вопрос по правкам ==

[[Участник:Trolzen|Trolzen]] 17:20, 18 февраля 2010 (UTC): Скажите, почему после моих правок появилось ещё 2 (одна ваша и одна бота), в которых написано, что они добавили столько же символов, хотя, если посмотреть сравнение, то изменений никаких? Вот пример страницы с такими правками: http://lib.custis.ru/index.php?title=Programmer_Insecurity&action=history Здесь что-то вроде системы постмодерации, и она себя так проявляет? Очень интересно, почему так получается, т.к. вижу подобное впервые.
:[[Участник:StasFomin|Стас Фомин]] 19:01, 18 февраля 2010 (UTC): Почти все статьи реплицируются (наша разработка) по ночам из внутренней вики-системы (в частности это защищает от вандализма). Но пользовательские правки я просматриваю, и исправления/добавления проношу во внутреннюю вики. Так что ваши правки не пропали.
::[[Участник:Trolzen|Trolzen]] 07:18, 19 февраля 2010 (UTC): Да, я видел, что они не пропали, просто было интересно, почему так получается. Да, интересно вы придумали. Спасибо за разьяснения.
[[Участник:Trolzen|Trolzen]] 17:20, 18 февраля 2010 (UTC): И ещё вопрос. Почему BenderBot всё время в комментарии пишет: "1 версия"? Это означает "первая версия"? Тогда непонятно, почему всё время первая, хотя страницы изменяются.
:[[Участник:StasFomin|Стас Фомин]] 19:01, 18 февраля 2010 (UTC): Нет, это он показывает, что пронесена одна (а не две или три) новых версии статьи. То, что он реплицирует статьи, хотя они добайтово совпадают (кроме авторства) — это то ли баг, то ли фича, сходу не помню, надо посмотреть.

== Не получается создать страницу обсуждения ==

[[Участник:Trolzen|Trolzen]] 07:23, 19 февраля 2010 (UTC): Например, я не могу создать свою страницу и к ней страницу обсуждения. Ну и ко всем статьям тоже не получается создать обсуждение. Выдаётся ошибка "У вас нет разрешения создавать новые страницы". Почему так было сделано? Если это поведение нельзя изменить, то не могли бы вы создать эти две мои страницы?

Обсуждение участника:StasFomin

2010-02-19T07:22:58Z

Trolzen: /* Не получается создать страницу обсуждения */ Новая тема

Уважаемый Стас Фомин!

Пишут Вам из редакции журнала «Потенциал» -
образовательного научно-популярного журнала для школьников и учителей.
Ссылка на официальный сайт журнала — http://potential.org.ru/bin/view/Home/WebHome
Он также представлен в wikibooks (http://ru.wikibooks.org/wiki/Журнал_"Потенциал")

На данном сайте (http://lib.custis.ru) мы обнаружили много разных хороших статей, которые можно было бы опубликовать в нашем журнале.
Нам бы хотелось связаться с авторами, чтобы узнать у них, не согласятся ли они подготовить ряд статей для журнала на основе имеющихся здесь.
Если с авторами связаться нельзя, то можем ли мы сами воспользоваться имеющимся здесь материалом?

В частности, нам интересна статья про машину Тьюринга
1) Знаете ли вы автора статьи про машину Тьюринга или аналогичного ему человека,который бы согласился переделать эту
статью в журнальном стиле и опубликовать ее в журнале «Потенциал»?
2) Если статью переделать некому или нельзя, каковы условия публикации, возможно, в измененном виде, данной статьи в нашем
журнале?

С уважением, Ольга Бутыгина и Артем Ворожцов. karagota@mail.ru

:[[Участник:StasFomin|Стас Фомин]] 12:38, 10 Apr 2006 (MSD): Статьи по сложности и машинам Тьюринга взяты из лекций (наших, с научным руководителем) по теории алгоритмов (и упрощены, как шпаргалка по основным понятиям) - PDF-файлы, посмотрите, может более интересно:
:* http://discopal.ispras.ru/ru.lectures.htm
:* http://discopal.ispras.ru/ru.lectures-mipt.htm

:Взять наверно можно, только для школьников, в более популярном стиле, есть наверно более подходящие книги и статьи (которых лучше взять за основу), например, на http://www.mccme.ru/free-books/
:* А.Китаев, А.Шень, М.Вялый. «Классические и квантовые вычисления.»
:* Н. К. Верещагин, А.Шень. «Языки и исчисления»
:* Н. К. Верещагин, А.Шень. «Вычислимые функции»

== Лицензия ==

какая лицензия материалов в вики?
можно ли их (частично) перенести в википедию?
:[[Участник:StasFomin|Стас Фомин]] 12:06, 2 May 2006 (MSD): Можно, только ставьте ссылку на оригинал в разделе «Ссылки» (что собственно и было написано в [[{{SITENAME}}]]). Наиболее приличные материалы я и сам в википедию переношу. К сожалению, в [[{{SITENAME}}]] реализовано много расширений, полезных для представления IT- и CS- информации — поддержка [[Graphviz]], [[Tex]], SVG, синтаксическая раскраска кодов и т. п. — без этого (в Википедии) все это выглядит достаточно бедно. Поэтому в википедию обычно переношу энциклопедический обьем, а непосредственно статьи-учебники поддерживаю в актуальности здесь.

== Вопрос по правкам ==

[[Участник:Trolzen|Trolzen]] 17:20, 18 февраля 2010 (UTC): Скажите, почему после моих правок появилось ещё 2 (одна ваша и одна бота), в которых написано, что они добавили столько же символов, хотя, если посмотреть сравнение, то изменений никаких? Вот пример страницы с такими правками: http://lib.custis.ru/index.php?title=Programmer_Insecurity&action=history Здесь что-то вроде системы постмодерации, и она себя так проявляет? Очень интересно, почему так получается, т.к. вижу подобное впервые.
:[[Участник:StasFomin|Стас Фомин]] 19:01, 18 февраля 2010 (UTC): Почти все статьи реплицируются (наша разработка) по ночам из внутренней вики-системы (в частности это защищает от вандализма). Но пользовательские правки я просматриваю, и исправления/добавления проношу во внутреннюю вики. Так что ваши правки не пропали.
::[[Участник:Trolzen|Trolzen]] 07:18, 19 февраля 2010 (UTC): Да, я видел, что они не пропали, просто было интересно, почему так получается. Да, интересно вы придумали. Спасибо за разьяснения.
[[Участник:Trolzen|Trolzen]] 17:20, 18 февраля 2010 (UTC): И ещё вопрос. Почему BenderBot всё время в комментарии пишет: "1 версия"? Это означает "первая версия"? Тогда непонятно, почему всё время первая, хотя страницы изменяются.
:[[Участник:StasFomin|Стас Фомин]] 19:01, 18 февраля 2010 (UTC): Нет, это он показывает, что пронесена одна (а не две или три) новых версии статьи. То, что он реплицирует статьи, хотя они добайтово совпадают (кроме авторства) — это то ли баг, то ли фича, сходу не помню, надо посмотреть.

== Не получается создать страницу обсуждения ==

Например, я не могу создать свою страницу и к ней страницу обсуждения. Ну и ко всем статьям тоже не получается создать обсуждение. Выдаётся ошибка "У вас нет разрешения создавать новые страницы". Почему так было сделано? Если это поведение нельзя изменить, то не могли бы вы создать эти две мои страницы?

Обсуждение участника:StasFomin

2010-02-19T07:18:05Z

Trolzen: /* Вопрос по правкам */

Обсуждение участника:StasFomin

2010-02-18T17:20:40Z

Trolzen: /* Вопрос по правкам */ Новая тема

Уважаемый Стас Фомин!

Пишут Вам из редакции журнала «Потенциал» -
образовательного научно-популярного журнала для школьников и учителей.
Ссылка на официальный сайт журнала — http://potential.org.ru/bin/view/Home/WebHome
Он также представлен в wikibooks (http://ru.wikibooks.org/wiki/Журнал_"Потенциал")

На данном сайте (http://lib.custis.ru) мы обнаружили много разных хороших статей, которые можно было бы опубликовать в нашем журнале.
Нам бы хотелось связаться с авторами, чтобы узнать у них, не согласятся ли они подготовить ряд статей для журнала на основе имеющихся здесь.
Если с авторами связаться нельзя, то можем ли мы сами воспользоваться имеющимся здесь материалом?

В частности, нам интересна статья про машину Тьюринга
1) Знаете ли вы автора статьи про машину Тьюринга или аналогичного ему человека,который бы согласился переделать эту
статью в журнальном стиле и опубликовать ее в журнале «Потенциал»?
2) Если статью переделать некому или нельзя, каковы условия публикации, возможно, в измененном виде, данной статьи в нашем
журнале?

С уважением, Ольга Бутыгина и Артем Ворожцов. karagota@mail.ru

:[[Участник:StasFomin|Стас Фомин]] 12:38, 10 Apr 2006 (MSD): Статьи по сложности и машинам Тьюринга взяты из лекций (наших, с научным руководителем) по теории алгоритмов (и упрощены, как шпаргалка по основным понятиям) - PDF-файлы, посмотрите, может более интересно:
:* http://discopal.ispras.ru/ru.lectures.htm
:* http://discopal.ispras.ru/ru.lectures-mipt.htm

:Взять наверно можно, только для школьников, в более популярном стиле, есть наверно более подходящие книги и статьи (которых лучше взять за основу), например, на http://www.mccme.ru/free-books/
:* А.Китаев, А.Шень, М.Вялый. «Классические и квантовые вычисления.»
:* Н. К. Верещагин, А.Шень. «Языки и исчисления»
:* Н. К. Верещагин, А.Шень. «Вычислимые функции»

== Лицензия ==

какая лицензия материалов в вики?
можно ли их (частично) перенести в википедию?
:[[Участник:StasFomin|Стас Фомин]] 12:06, 2 May 2006 (MSD): Можно, только ставьте ссылку на оригинал в разделе «Ссылки» (что собственно и было написано в [[{{SITENAME}}]]). Наиболее приличные материалы я и сам в википедию переношу. К сожалению, в [[{{SITENAME}}]] реализовано много расширений, полезных для представления IT- и CS- информации — поддержка [[Graphviz]], [[Tex]], SVG, синтаксическая раскраска кодов и т. п. — без этого (в Википедии) все это выглядит достаточно бедно. Поэтому в википедию обычно переношу энциклопедический обьем, а непосредственно статьи-учебники поддерживаю в актуальности здесь.

== Вопрос по правкам ==

Скажите, почему после моих правок появилось ещё 2 (одна ваша и одна бота), в которых написано, что они добавили столько же символов, хотя, если посмотреть сравнение, то изменений никаких? Вот пример страницы с такими правками: http://lib.custis.ru/index.php?title=Programmer_Insecurity&action=history Здесь что-то вроде системы постмодерации, и она себя так проявляет? Очень интересно, почему так получается, т.к. вижу подобное впервые.

И ещё вопрос. Почему BenderBot всё время в комментарии пишет: "1 версия"? Это означает "первая версия"? Тогда непонятно, почему всё время первая, хотя страницы изменяются.

[[Участник:Trolzen|Trolzen]] 17:20, 18 февраля 2010 (UTC)

Programmer Insecurity

2010-02-17T11:37:57Z

Trolzen: орфография/пунктуация

Programmer Insecurity/Комплексы Программиста

<blockquote>
Перевод статьи «Programmer Insecurity/Комплексы Программиста»
<ref>http://blog.red-bean.com/sussman/?p=96</ref>,
выполнен сообществом компании [http://team.custis.ru «Заказные ИнформСистемы»].
</blockquote>

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

Всегда был стереотип, что программисты асоциальны:

Q: How do you know when an engineer is outgoing?
A: He looks at your shoes!

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

Мой приятель Фитц и я долго проповедовали о ''best practices'' в разработке приложений
с открытым исходным кодом — когда человек должен быть открытым и честным с работой другого,
воспринимать разбор своего кода и уметь конструктивно критиковать, и, главное, активно общаться
с коллегами.

Один из антипаттернов, о котором мы говорили — это люди, пишущие «кодовые бомбы».
То есть, что вы делаете, когда кто-либо показывает вам огромную новую фичу в open source проекте, написание которой заняло месяцы?

У кого есть время, чтобы отрецензировать тысячи строк кода?
А что, если там были неправильные архитектурные решения с самого начала?
Есть ли теперь смысл указывать на это?

Сбрасывание такой «кодовой-бомбы» в сообщество, редко когда идет проекту на пользу:
команда либо должна либо полностью отклонить ее, либо принять и иметь дело с
гигантским мутным ''BLOB''-ом, который трудно и понять, и править, и поддерживать.
К тому же, это явно двигает проект в некотором направлении без всяких обсуждений или консенсусных решений.

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

Они хотят работать одни, в пещере, и только потом открыть сообществу
свой «идеальный» код, как будто бы в нем никогда ошибок и не было.

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

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

Оцените несколько историй, которые я собрал:

;Просьбы на конференции «Google I/O»:
Пару недель назад, когда моя команда была на конференции «Google I/O»,
мы поставили демонстрационный стенд, посвященный сервису поддержки проектов с открытыми исходными кодами.
Раз за разом, мы получали просьбы типа:
* «Ребят, вы можете заставить Subversion в Google Code возможность прятать определенные ветки?»
* «Парни, а можно создавать открытые проекты поначалу скрытые от мира, а потом раскрыть их, когда они будут готовы?»

По сути, они говорили одно и то же: «Я не хочу, чтобы люди видели процесс моей работы, пока она не стала идеальной»

;Просьбы в список рассылки Google Code:
* Почистить так или иначе svn-репозиторий на <tt>Google Code</tt>. Встречаются и разумные причины — например, случайный коммит секретных данных, или необходимость загрузить полностью историю из другого SVN-репозитория.
Но в основном, мы получаем некорректные (да, мы их отклоняем) просьбы вроде «Привет, я хочу переписать свой код с самого начала. Вы могли бы уничтожить историю?». Это значит «Я не хочу, чтобы люди увидели мой старый код, мне так за него стыдно!»

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

;Код-ревью воспринимаются как личные нападения:
Фитц рассказал смешной анекдот о своем друге, который перешел из мира open-source в корпоративную разработку.
Перескажу своими словами:

В течение первой недели он начал рассылать дружественные рецензии на исходники
каждого из сослуживцев, получая странные пристальные взляды в ответ.
Наконец начальник вызвал его к себе:
«Знаешь, тебе пока заканчивать с этой негативной энергией. Твои напарники говорят, ты критикуешь все, что они делают».

Мораль: рецензии кода далеки от стандартной практики в корпоративном сообществе, более того,
большинство программистов не способны отделить свои хрупкие «Я» от кода, который они пишут.

Повторяйте за мной: '''ты это не твой код'''!

;Использовать распределенный контоль версий — быть в пещере:

Один мой друг работает над несколькими проектами, в которых используют <tt>git</tt> и <tt>mercurial</tt>.
Недавно он рассказал мне следующую историю.

В основном, он работал с двумя командами над проектом.

Одна команда часто публиковала изменения…
«… в результате у меня была возможность постоянно просматривать их проект
в течении семестра, регулярно предлагая улучшения дизайна и предоставляя
рецензии на код… …В результате этого [их проект] развивается на полном ходу и практически
функционирует.

Другая группа… Я не слышал от нее и писка за последние 5 месяцев.
Несмотря на множество писем и обсуждений в IRC, призывающих их обсудить их
дизайн и регулярно публиковать изменения, мне не дали увидеть ни одной строчки. […]

В прошлое воскресенье один из них зашел ко мне с багом […] и я наконец смог увидеть
код, чтобы помочь отладить его. Это мне не удалось, потому что там были 5000
строк мусорного кода, и просмотр лишь одного файла выявил две или три серьезных
ошибки в проектировании и дюжину сыро реализованных мест.

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

Я не знаю, боялись ли они опубликовать это, или только не заботились об этом.
Но так или иначе, учитывая код, что я видел, практический результат составляет 5 потраченных впустую месяцев.»

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

Но у моего друга есть интересная точка зрения:

''Я думаю, что этот недостаток имеет место по крайней мере частично из-за того,
что DVCS даёт легкий способ обнести себя стеной и забраться в пещеру.
Если бы мы использовали <tt>svn</tt>, я думаю, что «пещерный» барьер был бы слишком
высок, и я сразу бы увидел этот код.
''

Другими словами, да, это было бы в основном социальной проблемой.
Команда запуталась в распределении кода.

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

«Смотрите, мы коммитим изменения в наш репозиторий каждый день … прогресс!»

Если бы они использовали Subversion, то гораздо менее вероятно, что
они сидели бы над патчем из 5000 строк в их рабочей копии в течение 5 месяцев;
они должны были бы показать работу намного раньше.

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

Это было моей главной темой ранее, когда я написал о рисках распределенного управления версиеями.

Хорошо, так, каково заключение? —
Просто очевидно, что люди боятся показывать незаконченную работу.

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

Я рассматриваю это как норму и не могу понять, почему кто-то не хочет этого делать.
Более того, растущая популярность распределенного контроля версий показывает,
насколько сильно люди стремятся спрятать свой код друг от друга.

Вот классическая «рекомендация» для системы вроде git (взято из комментария в блоге):
«Не надо говорить мне, что я должен сотрудничать с другими людьми
в начале и публиковать мои изменения как можно раньше.
Я сотрудничаю с другими людьми, но иногда хочу делать определенную часть работы в одиночку.»

Хм, ладно! Только не работай в одиночку слишком долго!

Немного отступая от основной темы, скажу почему я предпочитаю <tt>Mercurial</tt> <tt>Git</tt>-у,
проделав некоторые исследования и прочитав немного об этих системах.

Git гораздо более склонен к «пещерности», а я этого не люблю.

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

Другой пример: когда приходит время отправки и получения наборов изменений,
поведение по умолчанию для Mercurial состоит в том, чтобы обменяться историей с
удаленным репозитарием, тогда как git в этом случае только отправляет и получает
отдельную ветвь — предположительно ту, которую пользователь счел нужным сделать
общедоступной.

Другими словами, git по умолчанию считает, что вся работа «пещерная», и с радостью
уничтожает историю.
Mercurial же по умолчанию разделяет все, и не может стирать историю.

Я знаю, этот пост получился очень длинным, но дайте мне еще постоять на трибуне из ящика из-под мыла:

* Будьте ясными.
* Постоянно публикуйте свою работу.
* Приветствуйте обратную связь.
* Воспринимайте критику.
* Дайте возможность другим людям найти ваши ошибки.
* Ваш код — это не вы сами.
* Не бойтесь ежедневных ошибок — учитесь на них (Как говорят в Google, «не беги от ошибки — ошибайся часто, быстро, и учись!»).
* Храни всю свою историю, и удачи, и ошибки.

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

Уф-ф! Теперь я чувствую себя лучше.

==Ссылки==
<references/>

[[Категория:Статьи о Subversion]]

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

Version Control and the... Long Gradated Scale

2010-02-17T11:20:55Z

Trolzen: орфография/пунктуация

<blockquote>
Перевод статьи [http://blog.red-bean.com/sussman/?p=82 {{PAGENAME}}] («Контроль версий и далекие перспективы») выполнен сообществом компании [http://www.custis.ru «Заказные ИнформСистемы»].
</blockquote>

Моя предыдущая статья о [[Version Control and “the 80%”|контроле версий и «правиле 80%»]] заслуживает продолжения,
в первую очередь потому, что породило очень шумное обсуждение,
ну а затем из-за того, что мне бы не хотелось чтобы меня считали безграмотным нарциссом.

Многие со мной согласились, но огромное число людей обиделись на мои смелые обобщения.
Я вижу бесконечные комментарии на мой пост
(хотя среди них есть и поддерживающие меня — см. пост [http://www.codinghorror.com/blog/archives/001002.html Джеффа Этвуда]),
где люди или пытаются решить — входят ли они в «80%» или в «20%», или несут пафосный бред, что
все программисты попадают о обе категории одновременно.

Начну с извинений.
Оно конечно приятно, читать эту статью и думать, что смысл в том, что
«80% программеров — это тупые ведущиеся лохи, а другие 20% — клевые, толковые парни, прямо как я».
Очевидно, я в это не верю. :-).

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

Конечно, мир не черно-бел и все программисты уникальны.
Нет каких-либо отдельных интересов, которые бы явно свидетельствовали о вашей «20%»-ности.
С другой стороны нельзя зайти в какую-нибудь контору и указать на команду программеров — «эти парни явно тупое 80%-е стадо».
Нельзя так четко делить, нельзя.

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

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

Иными словами, имеет ли кандидат прирожденную страсть к программированию как к искусству?
Именно это ведет к
* участию в open-source,
* написанию LISP-компиляторов,
* [вставить здесь что-нибудь чумовое].

На этом я и основывал свои сверхсхематичные «80/20» метафоры в той статье, и, надеюсь, последнее определение будет менее скандально.

По моему опыту, большинство людей, пишущих ПО за деньги, не имеют глубокой увлеченности в программировании,
и не занимаются этим ради удовольствия.
Они пользуются инструментами, написанные другими людьми,
причем эти инструменты должны быть очень дружественными к пользователю, чтобы ими воспользовались.
Как тут [http://kylecordes.com/2007/10/16/dvcs-80-percent/ указывали], эти инструменты должны работать прямо «из коробки»,
«с колес», без малейшей «обработки напильником».

Основная мысль, которую я пытался донести, заключалась в том, что распределенные системы контроля версий (DVCS) пока не достигли такого уровня дружественности, да и Subversion только-только начинает достигать этого уровня (спасибо клиентам типа [http://tortoisesvn.tigris.org/ TortoiseSVN]).

Я подписан на [http://www.google.com/alerts Google Alert] в моей области в софтверном мире, т.е. каждый раз, когда Google находит новую веб-страницу, ссылающуюся на Subversion или на контроль версий, я об этом узнаю.
Вы будете просто поражены числу новых постов в блогах, которые я вижу каждый день, по-существу говорящих
«Эй, может наша команда должна начать использовать контроль версий! Subversion кажется достаточно удобной, вы с ней уже работали?»

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

Некоторые обратили внимание на то, что, в то время, когда я взываю к евангелистам DVCS не отбрасывать бездумно такие централизованые системы, как Subversion, сам я занят бездумным игнорированием DVCS (в той статье я жаловался, что большинство DVCS систем не работают под Windows, не имеют простого контроля доступа и не имеют приятных GUI клиентов).
Нет, я действительно сталкивался с Mercurial в разных проектах, просто мои утверждения основывались на несколько устаревшей информации.
[http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Обратившись к википедии], я уверился в том, что был неправ. :-)

[[Category:Статьи о Subversion]]

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

Линус Торвальдс о GIT на Google Talk

2010-02-17T10:52:32Z

Trolzen:

[[Image:Linus-git-googletalk.0-00-04.098.jpg|right]]

<blockquote>
Перевод доклада Линуса Торвальдса о системе контроля версий <tt>git</tt> на «''Google Talk''»
<ref>Оригинальное видео доклада http://www.youtube.com/watch?v=4XpnKHJAok8</ref>,
выполнен сообществом компании [http://team.custis.ru «Заказные ИнформСистемы»].
</blockquote>

<blockquote>
Есть предложение удалить эту статью, т.к. уже есть точно такая же: [[Линус Торвальдс о GIT на Google Talks]].
</blockquote>

[[Image:Linus-git-googletalk.0-00-11.269.jpg|center]]
[[Категория:Системы контроля версий]]

== Представление ==

[[Image:Linus-git-googletalk.0-00-19.731.jpg|framed|right| Эндрю Мортон. Один из ведущих разработчиков ядра Linux. Работник Google]]

'''''Эндрю:'''''
Спасибо всем пришедшим, большинство из вас вероятно уже слышали
о Линусе Торвальдсе, а те, которые не слышали — это люди с Макинтошами на коленях.
Это парень, который прется от издевательств над людьми.
Его последняя выходка — создание СУВ<ref>система управления версиями</ref>, которая явно создана для того,
чтобы вы почувствовали себя менее умными, чем до знакомства с ней.
Спасибо, что снизошли до нас сегодня, Линус.
Последние дни я получал письма от людей, вопрошающих:
«Где Линус? Почему он не берет мою ветку? Он меня больше не любит… =(»


И вот, он пришел в мой офис сегодня днем, и сказал: «а чем ты вообще тут занимаешься?!»
О, спасибо вам, что тратите на нас свое время.
И вот, Линус пришел сегодня, чтобы объяснить нам,
какого …, он написал такие тулы, гм,
что только он тот избранный, кто настолько мудр, чтобы понять, как ими пользоваться.

[[Изображение:linus-git-googletalk.0-00-51.199.jpg|framed|center| тут все апплодируют, апплодируют…]]

== Вводное слово ==
[[Изображение:linus-git-googletalk.0-01-15.165.jpg|framed|left|Линус Торвальдс.]]

'''''Линус:'''''

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

Так вот, я не буду говорить про ''Ядро''<ref>Проект Linux Kernel.</ref>, просто потому, что оно слишком большое,
чтобы рассказать о нем за час, хотя похоже Эндрю сделал это пару дней назад.
Вместо этого я расскажу вам про [[EnPedia:Git_(software)|git]], систему управления версиями,
которую мы используем для Ядра.

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


Я не знаю, как тут у вас, на ''Google talks'', все это происходит,
я скажу просто — меня не стесняйтесь.
А если ваш начальник потом вас пристрелит — это будет уже ваша проблема.

== Credits ==

[[Изображение:Linus-git-googletalk.0-02-21.683.jpg|framed|Потому что Линус любит заставлять людей думать, что он скромный|left]]
Сначала я хочу раздать несколько отзывов и благодарностей.

О [[CVS]] я будут отзываться только в очень-очень отрицательном ключе,
потому что я, когда проектировал <tt>git</tt>, во многих ситуациях
использовал (в контексте СУВ) подход «что бы тут сделал Иисус», а иногда и «что бы тут CVS никогда не сделала».

Я никогда не использовал CVS при разработке ядра.
За последние десять лет для поддержки ядра
мы использовали только тарболы<ref>tarballs — несжатые tar-архивы</ref>
и патчи<ref>patch — файлы изменений</ref>,
которые оказались лучшими СУВ, чем CVS,
но я «покончил с CVS» после семилетнего опыта использования ее
в коммерческой компании, и я страстно ненавижу эту систему.

Когда я сказал, что страстно ненавижу CVS, я должен также сказать, что если в аудитории есть пользователи SVN ([[EnPedia:Subversion (software)|Subversion]]),
то вы, возможно, захотите уйти.
Поскольку моя ненависть к CVS означает, что я считаю Subversion самым
бесцельным проектом, так как основной девиз Subversion некоторое время был
«Сделанный по-уму CVS» или что-то вроде этого.
А если вы начинаете с такого слогана, то вы никуда не сможете прийти.
Это так, потому что CVS невозможно сделать «правильным».

Это была негативная часть.

А вот с благодарностью я упомяну о [[EnPedia:BitKeeper|BitKeeper]],
хотя я понимаю, что по мнению многих, вокруг ''BitKeeper''’а было
много проблем и споров да и «развод» с ним был во многих смыслах неприятен.
Но по-моему, наш развод с BitKeeper-ом был
вполне полюбовный, хотя снаружи это казалось иначе.
И BitKeeper не только стал первой системой контроля версий,
которая показалась мне вполне достойной,
но, более того, показал мне, в чем была его основная идея
и как с ней можно реально работать.
И хотя <tt>git</tt> во многом, в том числе технически, очень-очень сильно отличается от
BitKeeper (это было специально задумано, чтобы убедить всех, что это
не клон BitKeeper), многие процессы используемые нами с <tt>git</tt>,
взяты из BitKeeper.

Кстати, вы используете BitKeeper здесь, в Google? Я сомневаюсь.
Насколько я знаю, BitKeeper — это единственная коммерческая распределенная СУВ,
и поэтому, если вам-таки нужна именно коммерческая система,
то вам стоит использовать BitKeeper.

Я также хотел бы заметить, что я разрабатываю <tt>git</tt> чуть больше двух лет,
но хотя я запустил проект, разработал архитектуру и начальный код,
на протяжении последних полутора лет его поддерживает
гораздо более славный парень, японец ''Junio Hamano'',
и именно он сделал <tt>git</tt> более доступным для простых смертных.
Ранние версии <tt>git</tt> действительно требовали некоторое количество
«ментальных пунктов» мозгосилы.
C тех пор он стал гораздо проще.

В общем, это мой обычный подход —
все остальные делают все возможное, а я сам могу просто сидеть и потягивать
ПинаКоладу<ref>Пинья колада (исп. Piña colada), также ошибочно называемый пинаколада/пиноколада и т. п. — традиционный карибский алкогольный коктейль содержащий ром, кокосовое молоко и ананасовый сок.</ref>,
ну и типа люди то же вроде как-то при деле…

На этом благодарности окончены, всех вышеперечисленных откладываем в сторону.

== Content ==

[[Изображение:linus-git-googletalk.0-06-23.653.jpg|framed|right| Он набросал эту презентацию прошлой ночью, не ждите здесь чуда]]
Вот этому слайду уже один день.
Я вообще не делал презентацию прошлой ночью, потому что прошлой ночью
я пьянствовал, отрывался и ел суши. Вот.

И тем не менее, в презентации
речь пойдет о реализации надежной, высокопроизводительной распределенной
системы управления содержимым, и ключевое слово здесь — «распределенная».
Я сначала попытаюсь объяснить, почему распределенность так важна.
Если мы потом к этой теме не вернемся, я буду действительно счастлив.

И ничего страшного, если мы так и не разберем, как <tt>git</tt> устроен изнутри.
Учить пользоваться <tt>git</tt>’ом я тоже не буду.
Ну есть же у вас такая штука, которую вы делаете, «google.com»,
и в ней есть такое место, куда можно вводить буквы, и если вы введете туда «git»
и нажмете кнопку «Мне повезет!», вы обязательно попадете [http://git-scm.com/ на официальный сайт <tt>git</tt>],
на котором есть и вводные обучающие курсы и руководство пользователя в HTML-формате.
В общем, если вы хотите научиться пользоваться <tt>git</tt>, вам нужно первым делом туда,
а не на этот доклад.

Но, как я уже сказал, ничего страшного, если мы отклонимся в сторону от темы
из-за ваших вопросов.

== Content Advisory ==
[[Изображение:Linus-git-googletalk.0-08-05.443.jpg|framed|left|Линус критичен и к программам и к людям]]

Я вам уже озвучил эти примечания к заголовкам; я использую сокращение [[EnPedia:Source_Code_Management|SCM]] в
значении «''source code management''/управление исходным кодом»,
что то же самое, что контроль версий. Некоторые думают, что SCM означает
«Управление конфигурациями/''software configuration management''»
и включают сюда не только контроль версий, но и управление релизами и все такое;
но я сейчас буду рассказывать не об этом, хотя <tt>git</tt> вполне подходит и для этого.

С [[CVS]] мы уже разобрались. Вы можете не соглашаться со мной сколько хотите, но в течение этого доклада
все, кто не согласен со мной, по определению — тупые уроды.
Помните об этом!
Вы будете вольны делать и думать все что захотите, когда я закончу доклад.
А сейчас я рассказываю свое единственно правильное мнение,
так что пользователи CVS, если вы действительно его так любите,
уйдите с глаз моих долой. Вам надо обратиться в психушку или куда-то еще.

== Background ==
[[Изображение:Linus-git-googletalk.0-09-24.327.jpg|framed|right|от BitKeeper к <tt>git</tt>]]

Теперь, перед тем как начать говорить о самой сути «Распределенности»,
что, по-моему, архиважно, нельзя не упомянуть об истории <tt>git</tt>,
потому что если люди что-то и слышали о <tt>git</tt>,
то это, в первую очередь, историю его возникновения.

Во-первых, я на самом деле вообще не фанат SCM.
Я никогда особо не интересовался системами контроля версий, и думал, что это зло,
пока не наткнулся на ''BitKeeper'', который оценил по достоинству; и,
в некотором смысле, именно поэтому <tt>git</tt> намного лучше всего остального,
ведь мой мозг не страдал долгие годы, думая, что [[CVS]] делает что-либо разумное.

Мне понадобилась замена для BitKeeper.
Причина в том, что BitKeeper — это коммерческий продукт,
но ''BitMover'' и ''Larry McVoy'' разрешили использовать его бесплатно для open-source
продуктов, как вы, возможно, знаете; единственным ограничением было то,
что его нельзя было исследовать (''reverse engineer'') и нельзя пытаться создать конкурирующий продукт.

И я был вполне этим доволен, ведь я делаю свободное ПО,
потому что считаю это единственным правильным способом разработки,
но я также хочу использовать лучшие инструменты для работы,
и BitKeeper был как раз таким.

Но не все были согласны со мной.
Все они тупые уроды, но как бы там ни было,
они подкинули проблем,
и это в результате привело к тому, что мы с ''Larry'' несколько раз
поговорили по телефону и в конце концов договорились прервать сотрудничество,
дабы не ухудшать отношения.

Тогда, примерно 2 года назад, я выпустил релиз <tt>Linux 2.6.12-rc2</tt> и сказал,
что не продолжу разработку Linux, пока у меня не будет замены BitKeeper’у,
для управления исходным кодом.

Одним из способов замены был возврат к tar-архивам и патчам,
но все были категорически против.

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

Если система не распределенная, ее не стоит использовать, это же очевидно.

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

Честно говоря, та малышка [BitKeeper] прекрасно заботилась обо всем.
Полно СУВ которые не гарантируют, что то, что вы из них достаете,
является в точности тем, что в них положили.
Вы можете никогда и не узнать, что у вас повреждена память или жесткий диск.
А заметите это, только когда получите назад поврежденный файл.
Причем сама система контроля версий за этим вообще не следит.
И такое — совсем не редкость.
Да, это встречается очень, очень часто.

Проблема быстродействия: одной из систем, которая мне более-менее понравились,
была система [[EnPedia:Monotone_(software)|Monotone]], о которой, кстати, когда-то вроде был доклад в Google,
хотя может я и ошибаюсь; так вот, в ней было много интересных идей,
но производительность была просто ужасна,
так что попробовав ее один день, я понял, что она мне не подходит.

В результате, я решил, что сам за две недели смогу написать что-то получше,
и не ошибся.

== Distribution ==

[''Показывает слайд «Distribution» с картинкой'']

[[Image:Linus-git-googletalk-slide-distribution.jpg|framed|Это не просто хорошая идея. По-другому просто не будет работать!]]

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

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

[''слушатели поднимают руки'']

Большинство из вас разрабатывают ядро?
Нет?
Хорошо, примерно десять человек подняли руки.

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

Поэтому, например, я Subversion даже
трехметровым багром трогать не буду.
В Subversion большой репозиторий, куда все обязаны складывать свои данные.
А централизованная модель просто не работает,
когда… давайте взглянем на некоторые такие случаи.

[''Показывает слайд «Distribution» с пунктами'']

[[Image:Linus-git-googletalk-slide-distribution2.jpg|frame|Слайд «Distribution» с пунктами]]

Я сказал, что распределенность — это гораздо больше, чем просто работа в оффлайн,
но это, пожалуй, понять проще всего:
вы можете взять по-настоящему распределенную SCM с собой в самолет и,
даже если в нем нет ни wi-fi, ни спутникового интернета,
вы просто продолжаете работать — вы можете посмотреть любые логи,
вы можете фиксировать изменения, вы можете делать все, что вы бы делали,
если бы вы были подключены прямо к магистральному каналу с гигабитным Ethernet.
И это действительно важно.

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

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

И это действительно очень важно и очень сильно отличается от работы в CVS,
где ветвление считается уделом настоящих мастеров.

Кто из вас когда-либо пользовался CVS?

[''Слушатели поднимают руки'']

Понятно, все. А кто когда-нибудь по-настоящему создавал ветку, а потом объединял изменения в CVS?

[''Слушатели поднимают руки'']

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

Ну и кому из вас понравилось осуществлять этот процесс?

[''смех'']

Понятно, все-таки нескольким понравилось.

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

Разве я не прав?
Что-то я не вижу, чтобы многие говорили «Нет, это очень просто, мне нравится это делать».
Это отвратительно!

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

На самом деле, в <tt>git</tt> мы так любим ветки, что многие держат их по 10-15 штук,
потому что когда вы понимаете, что у вас по-любому будет отдельная ветка,
вам уже все равно, сколько их будет, и вы делаете отдельные ветки
для экспериментов и отдельные для поддержки.
Так что ветвление гораздо более свойственно распределенным системам.

Еще одна вещь, которая мне кажется важной, — это то, что распределенная система
в силу своего устройства более надежна.

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

Я очень сомневаюсь, что все так делают.
Но это по-настоящему работает только в распределенных системах.
Если вы пользуетесь CVS, вы не можете так сделать, если вы используете…
кстати, чем вы здесь пользуетесь?

Perforce?… [[EnPedia:Perforce|Perforce]]. Ну да, извините.
Да, он, конечно же, лучше, чем [[CVS]].

[''Слушатели смеются'']

Но все равно это по сути CVS.

Еще одна прикольная вещь, хотя у вас в компании возможно этого и нет,
но это обязательно есть во всех командах, разрабатывающих свободное ПО,
которые используют CVS или Subversion или что-то вроде этого, это то,
что они пользуются понятием «commit access».

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

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

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

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

И потом, если окажется, что вы сделали что-то полезное, вы можете сказать
людям: «''Эй, тут в моей ветви все работает в десять раз быстрее, чем у всех остальных,
так что ня-ня-ня, не хотите взять мой код?''».
И народ берет.

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

Вы избавитесь от кучи проблем.

Одна из них касается коммерческих компаний.
Распределенная модель может также помочь с процессом выпуска релизов.
У вас может быть команда тестировщиков, которая работает в своем дереве.
Они берут код у других, проверяют его и когда проверят, передадут его
команде выпуска.
И они скажут: «Эй, мы тут проверили новую версию» и разработчики могут
продолжать работать головой вместо того, что маяться всякой дурью типа создания
меток, ветвей и всего того, что вы обычно делаете, чтобы разработчики не
конфликтовали друг с другом, потому что это достигается тем, что каждая группа
работает в своем дереве, следит за тем, что она сделала и что хочет сделать.

То есть Распределенность — это на самом деле ключевой момент для любой из
СУВ, которые стоит использовать.

Так что немедленно избавьтесь от Perforce!

[''Апплодисменты'']

Да, может и жалко, но это архиверно!

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

'''Из зала:'''

[[Image:Linus-git-googletalk.0-21-39.872.jpg|frame|right|И как вы собираетесь это делать?]]

{{question}} Вопрос. И как вы собираетесь это делать?
Если у вас есть эта монстрообразная, страшно огромная база кода
и вы хотите использовать ее, не останавливая
другие дела на шесть месяцев, как вы собираетесь это делать?

'''Линус:'''

Не отходите от микрофона, потому что я не совсем понял ваш вопрос.
Он ушел, ну ладно.

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

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

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

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

Да, вам не позволяют делать коммиты.
И это происходит почти в каждой компании.
Я уверен, что это так даже у вас, в Google.
У вас вероятно есть строгий набор тестов и вам нельзя делать коммиты, пока
все тесты не будут пройдены, а это приводит к тому, что на практике люди вносят
изменения по одной строчке и не тестируют, потому что знают, что изменения в
одной строчке скорее всего ничего не сломают.
Да, бывает и так.

Такой подход, конечно — ужас-ужас!
Это означает, что вы делаете коммит огромного числа изменений за раз,
потому что работали над этими изменениями две недели.
И в итоге у вас три человека, которые делают одно и то же, потому
что они не видят изменений от других, пока не сделают коммит своих.
Это часто происходит, это происходит везде, это жуть!

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

Но так как вы думаете, что сможете сделать это за 48 часов, вам очень лень
создавать ветвь, даже в таких системах, в которых это делать удобнее, чем в CVS.
И вы этого не делаете, потому что думаете, что как-нибудь справитесь с этим
и вы возвращаетесь к случаю № 1, но даже если вы решите создать ветвь, то будете
менять содержимого репозитория и для всех остальных,
потому что в централизованной среде ветви глобальны.

То есть вы столь любезны, что вы трахаетесь со всеми остальными,
но при этом не трогаете их ''основной ствол'', так называемую ''головную ветвь''.
Вы добавляете что-то новое в их репозитории, но при этом так,
чтобы они ничего не заметили (по-крайней мере, вы на это надеетесь).
Но общий репозиторий все равно от этого пухнет.

В общем, в любом случае, успеха вы не добьетесь.

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

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

И эта модель гораздо лучше для разработки.

И это модель, которая используется в разработке ядра Linux.
Оказывается, что во многих местах нам не нужна вся эта мощь, даже в ядре.
И люди обычно не обмениваются обновленным кодом внутри одной группы, но иногда
случается, например, что те, кто работает над сетью, иногда сталкиваются с
людьми, которые работают над NFS, и то, что они могут синхронизироваться,
действительно помогает.
То есть это действительно помогает!

У кого-то еще есть вопрос?

[[Image:Linus-git-googletalk.0-27-03.671.jpg|frame|right|Похоже, что все эти правила и ограничения просто переместились или стали неявными.…]]

'''Из зала:'''

{{question}} Похоже, что все эти правила и ограничения просто переместились или стали неявными.
Да, у каждого есть доступ и все играются со своими ветвями в песочнице, но к вечеру
ветви нужно соединять и разрешать все конфликты чтобы не было 80
миллиардов вариантов каждого линуксового ядра.

'''Линус:'''

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

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

Через сеть доверия.

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

В своей работе я не доверяю всем без исключения.

Более того, на самом деле я крайне циничен и недоверчив.

Я думаю, большинство из вас полностью некомпетентны.

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

Мне нужно доверять только 5, 10, ну может 15 людям.
Если у меня есть доверенная сеть, в которую входят эти 5, 10, 15 выдающихся
человек, и я знаю, что они выдающиеся, я могу забирать новый код
у них.
И мне не надо париться на эту тему.

Когда Эндрю присылает мне патчи, он не использует никакого <tt>git</tt>,
это в некотором роде недостаток, ну и что, он очень надежный человек.
Когда он просит меня принять обновленный код, он просто посылает мне
миллион патчей, я просто их применяю.
Иногда я не согласен с какими-то из этих патчей, но с другой стороны,
доверие означает, как это сказать… «доверять — значит прощать»? Я не знаю…
В общем, это означает, что вы должны соглашаться с решениями других людей.

И самое замечательное в доверии — это что оно создает сеть.
Именно здесь и появляется сеть доверия.

Мне нужно лишь несколько человек, которым я буду доверять.
А у них есть другие люди, которых они выбрали, типа — «тот парнишка шарит покруче
меня» — да, это хороший критерий того, от кого вам следует брать исправленный код.
Если у вас есть кто-то еще, кто шарит лучше вас, — вперед.
Это беспроигрышно.

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

[[Image:Linus-git-googletalk.0-30-08.466.jpg|frame|right|Именно так я и работаю…]]

Именно так я и работаю, скорее всего также действуют и мои поручики/заместители
<ref>В оригинале ''lieutenants'', поэтому часто в рунете помощников Линуса зовут «лейтенантами».</ref>.
Я забираю изменения по сетевой теме от одного человека, а он получает их от
множества других людей, с которыми он постоянно работает, и таким образом все
изменения приходят ко всем, и им не нужно собираться всем в одной точке.

Хотя в ядре все приходит в большей степени в одну точку, так, я думаю, сложилось
исторически, и на самом деле я всегда пытался поощрять пожелания людей заводить
больше деревьев, и у нас действительно есть отдельные деревья по производителям оборудования,
у нас есть специальное «-mm»<ref>Экспериментальная ветвь ядра Linux, специализированная на управлении памятью, см. [[EnPedia:Mm_tree]].</ref> дерево, в котором много выделенных «точек», просто так получается, что
моя точка привлекает, быть может, больше внимания, чем должна была бы.

Даже если что-то там не придет к этой одной точке, это значит, что
можно взять тысячи этих ветвей, игнорируя <tt>99.9%</tt> из них.
Зато вам интересно отслеживать, скажем пять ветвей, относящихся к областям, которыми вы интересуетесь.

И все это работает очень естественно.

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

Люди мыслят именно так.

Мы не знаем сотню людей.
У нас есть 5, 7, 10 близких личных друзей, ну ладно, пусть мы асоциальные гики,
поэтому у нас их двое, но это основы человеческого сотрудничества, то
что у нас есть те, кому мы действительно можем доверять,
это семья, это близкие друзья, и все это удобно и привычно, не нужно
держать в голове неестественную модель взаимодействия,
все подключаются естественным образом.
Поэтому работа с этой моделью сетевого доверия дает огромные преимущества.

[[Image:linus-git-googletalk.0-31-51.970.jpg|frame|right|Знаете ли вы о компаниях, которые используют распределенные системы у себя внутри?]]

'''Из зала:'''

{{question}} Знаете ли вы о компаниях, которые используют распределенные системы у себя внутри?
Похоже, тут есть вероятность «сепаратизма» в коде,
так как народ, разбредется по собственным песочницам, и
не будет вкладываться в основной ствол.

'''Линус:'''

Честно говоря, не так уж и много распределенных систем.
Это BitKeeper, очевидно использующийся коммерческими компаниями,
мы должны иметь в аудитории кого-нибудь, кто действительно знает, но что …
[''комментарий из аудитории''], ага,
HP использует такие системы как BitKeeper в проектах разработки принтеров.

Я уверен, что таких компаний немало.
В мире open-source ПО, есть пара распределенных
систем, которых стоит посмотреть прямо сейчас.
Очевидно одна из них — <tt>git</tt>.
И вы, конечно, должны выбрать ее.

Но есть и другая — Mercurial, которая на самом деле очень похожа по архитектуре.
Есть некоторые различия в деталях архитектуры и большие различия в реализации,
но в сухом остатке модели очень похожи.
Только <tt>git</tt> делает это лучше.

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

'''Из зала:'''

{{question}} А какие преимущества у компании, когда все играются в собственных песочницах?

'''Линус:'''

Я думаю, что есть полно компаний, считающих, что такие преимущества есть.

Я знаю это от инсайдеров, и не думаю, что многие компании
осознанно используют <tt>git</tt>, в смысле, чтобы решение по его использованию
было принято на уровне корпоративного стандарта.

Я знаю несколько компаний, которые внутри
используют <tt>git</tt>, не подозревая об этом, потому что они все еще держат
свои главные репозитории в Subversion, но многие разработчики затем
импортируют код в <tt>git</tt>, потому что <tt>git</tt> действительно хорошо выполняет слияния.
Так что вы можете взять дерево веток из Subversion, импортировать в <tt>git</tt>,
позволить <tt>git</tt> сделать слияние,
что было бы основной головной болью в Subversion,
зафиксировать изменения и фактически экспортировать их назад в Subversion,
и никто другой даже не узнает, что вы использовали <tt>git</tt>.
Немного грустно, но я слышал о многих,
работающих в компаниях в точности по этому сценарию.

А вот чтобы постоянно использовать <tt>git</tt> подряд в течении полугода или больше — таких людей пока еще мало.

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

Я думаю, что мы прошли переломный момент.
Git намного проще использовать, чем CVS, правда-правда!

Большинство людей склоняются к … э-мнэ-э, он проще в использовании, чем что-либо еще.
Это всего лишь,… забудьте это.
Вы не обязаны использовать все его мощные возможности,
некоторые из них могут
быть тем, что вы хотели бы объяснить и представить людям только
после того, как они преодолеют начальные трудности
понимания того, что действительно означает распределенность,
но основные вещи делать действительно легко.

[[Image:linus-git-googletalk.0-34-59.000.jpg|frame|right|Как вы сводите к минимуму конфликты слияний?]]

'''Из зала:'''

{{question}} Одна из характеристик централизованных систем — это то, что именно
тот разработчик, который должен коммитить, обязан также
провести слияние. Как с этим в <tt>git</tt>?
И как вы сводите к минимуму конфликты слияний?

'''Линус''':

Спасибо, что спросили меня об этом!
Это не вас ли я просил задать этот вопрос?

Одно из самых приятных свойств <tt>git</tt> это то, что он реально проще
разбирается со слиянием, чем все остальные системы.
Объединение ветвей в CVS происходит крайне мучительно, просто невыносимо.

По моим подсчетам ядро Линукса — это на самом деле один из крупнейших
проектов с открытыми исходниками.
У нас <tt>22 000</tt> файлов.

Мы используем <tt>git</tt> уже два года.
В течение этих двух лет у нас было в среднем <tt>4.5</tt> слияния в день!

Если бы слияние было бы сложным, то точно пользовались чем-то другим.
Так что <tt>git</tt> делает слияния простыми.

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

А другой чел поменял код так сильно и его версия настолько конфликтует с остальными
(такое бывает, правда не очень часто),
что я говорю: «Я мог бы это пофиксить, но мне лень».
В их области я не программирую — это не моя сфера интересов,
это сетевые технологии или что-то в этом духе,
я просто не могу разобраться и оценить этот код, не могу его тестировать,
так что просить меня разобраться с этим слиянием — просто глупо,
так дела не делаются.

Ага, комп с Виндой опять погас.

Итак, помните, что распределенная модель означает, что «особенных» нет.

Поэтому вместо того чтобы самому разбираться со слиянием,
я вытаскиваю первое дерево файлов, в котором не было никаких проблем,
и говорю второму участнику:
«Эй, я пробовал подгрузить твой код, но там была туча конфликтов со слиянием,
совсем не тривиальных, так что я решил, что тебе стоит разобраться с этим самому».

И они разбираются.
Они знают, что делать, потому что это их изменения.

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

Зато они сами объединяют изменения, обновляют свое дерево файлов и говорят мне:
«Эй, теперь можешь забирать рабочий вариант», и я загружаю себе их версию.
Они прекрасно сделали всю работу за меня.

В этом-то и есть вся прелесть: ''они все сделали за меня''.
А мне достаются честь и хвала!
Далее мне просто нужно подсчитать третью составляющую — ''PROFIT!!!''

Все это аспект, естественным образом возникающий в распределенных системах,
это не особенность <tt>git</tt>. Да, <tt>git</tt> справляется со слияниями гораздо проще, чем все остальные,
но это свойство вытекает из самой распределенной модели.

[[Image:linus-git-googletalk.0-38-02.885.jpg |frame|right|…зачем вам так нужно иметь эту распределенную систему?]]

'''Зритель''':

{{question}} Слушай, я не совсем понимаю, зачем вам так нужно
иметь эту распределенную систему…
Ну да, вроде получаешь кучу преимуществ, по крайней мере
для коммерческой разработки, да и для разработки open-source наверно очень полезно,
поскольку каждый может работать сам по себе,
но, когда у тебя централизованная СУВ, общая структура директорий и файлов,
не окажется ли, что централизованная система с дешевыми ветками
даст тот же самый эффект?
Или такое просто невозможно?

'''Линус''':

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

Они не могут работать так же хорошо, как и распределенные системы!

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

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

Эээ… мда, я не могу показать вам демонстрацию,
да и не так уж она интересна,
но это ноутбук 4-5-летней давности.
Что-то типа ''Pentium-M 1.6 GHz''.

Я мог бы показать вам, что полный <tt>diff</tt> проекта Linux Kernel
на этом ноуте займет чуть больше секунды.

На моей основной машине, это уже будет меньше десятой доли секунды.

Это прирост производительности, которого вы никогда не добьетесь,
работая по сети.

Как только вы стали использовать сеть, хоть для пары пакетов,
вы уже впустую потратили производительность.

Так что если у вас децентрализованная система, и вы привыкли
делать <tt>commit</tt> или <tt>diff</tt> всего дерева исходников за 30 секунд,
то, может быть, 30 секунд вам не покажутся злом.

Но поверьте, когда вы привыкли делать это за одну десятую секунды,
30 секунд — это полный отстой.

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

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

У вас будут проблемы с пространством имен.

Как вы назовете свою ветку?
Вы назовете ее «test»?
Ага-ага, уже есть 5000 других веток,
названных «test1», «test2», … «test5000», так что вам теперь придется
выдумывать новые правила именования
ваших веток, потому что у вас централизованная система
с централизованным пространством имен у ветвей,
что совершенно неизбежно при работе с централизованной системой.

Как же это работает в распределенной среде разработки?

Вы называете свою ветку «test», и все!
Ну на самом деле, вам не следовало бы ее так называть, веткам нужно давать имена
согласно их функциональности; называйте их кратко, благозвучно
и конкретно — что эта ветвь делает.

Git дает вам по умолчанию одну ветку под названием «master»:
красиво, коротко и ясно — это ваш основной ствол.

Но вы можете создать ветку под названием
«experimental-feature-x» — и все будет понятно.

Но в централизованной среде вы просто не сможете так сделать.
Вы не можете назвать ветку «experimental-feature-x».
Вы должны придумывать тупые, идиотские названия.

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

И система добавит тег/закладку там, где вы начали разрабатывать эту ветку,
потому что в CVS вам приходится это делать…
Это занимало некоторое время, но работало.

Вы можете так извращаться в централизованных системах, но вам не нужно этого делать!

Ваша система децентрализована, она просто работает.

Именно так все и должно работать.

Итак, я ничего не утверждаю, я не собираюсь вас убеждать переходить
на децентрализованную систему,
я просто констатирую факт: «Вы тупые дебилы»!

Таков расклад.

Как бы то ни было, перейдем к слайду «Performance».

[[Image:linus-git-googletalk.0-43-15.833.jpg|frame|right|…сколько файлов осилит <tt>git</tt>?]]

'''Зритель''':

{{question}} Могу я задать вопрос?

'''Линус''':

Давай.

'''Зритель''':

{{question}} На самом деле, два вопроса.
Первый: сколько файлов осилит <tt>git</tt>?
а второй, представьте, что у вас здоровенная древовидная структура файлов в <tt>git</tt>,
возможно ли извлечь только часть этой структуры?

'''Линус''':

Отличные вопросы.

На самом деле, эти вопросы цепляют совсем другую тему,
хотя они связаны с производительностью.

Одно из особенных свойств <tt>git</tt> — отслеживание изменений всего содержимого,
и это отличает <tt>git</tt> даже от [[EnPedia:Mercurial_(software)|Mercurial]], несмотря на то, что они очень похожи.

Он никогда не отслеживает отдельный файл.
Вы не можете прослеживать изменения файла в <tt>git</tt>.

Ну, вы можете проследить изменения проекта, в котором один единственный файл.
Если в вашем проекте один файл, то у вас все получится,
но если вы отслеживаете изменения в десяти тысячах файлов, то <tt>git</tt> никогда не будет
возиться с ними по отдельности.

Git думает, что все вокруг — это единый проект.
Вся история в <tt>git</tt> основана на истории проекта целиком.

Отсюда — важные следствия для производительности.

Когда вы используете CVS, вполне нормально, хотя и глупо,
иметь один здоровенный репозиторий с миллионом файлов внутри.

Таким образом, в конце дня, поскольку CVS думает о каждом
из миллиона файлов по отдельности,
вы можете попросить CVS обновить только один единственный файл —
все это в рамках CVS-идеологии.
И это верно для множества других моментов.

Точно также работает и BitKeeper, и это является одной из его ошибок.

Проблема мышления в «концепции наблюдения за каждым файлом по отдельности»
возникает очень часто, особенно, если вы разработчик высокого уровня (как я).
У меня 22 тысячи файлов, и мне пофигу, что происходит с одним из них.
Возможно, я буду следить за подмножеством из тысячи файлов,
например, коллекцией файлов по подсистеме USB.
Но я никогда не беспокоюсь о каком-то отдельном файле.

Поэтому <tt>git</tt> следит за всем, как за коллекцией файлов,
и если вы попросите историю конкретного файла,
<tt>git</tt> буквально начнет с глобальной истории и упростит ее.
Это очень эффективная система, вам даже в голову не придет что это так,
но в действительности, когда вы пытаетесь следить за миллионом файлов
в репозитории, а потом просите историю конкретного файла — это очень тормозит систему.
Таким образом, свойства масштабирования у <tt>git</tt> сильно отличаются от других систем,
благодаря этой фундаментальной особенности.

Мы работали с большими репозиториями.
Мы импортировали историю проекта KDE из SVN, может быть, не всего,
но уж <m>\frac34</m> точно.
И KDEнутые … эээ… ''Я не должен так их называть… Я не буду, поверьте, мне нравится KDE.''

Но они засунули все компоненты в один репозиторий!
Не слишком умно.
Получилось так, что тот репозиторий, который, думаю, весил 8 Гб под CVS,
в SVN разбух еще в три раза!
Ну может там было меньше 8 Гб под CVS, но он был действительно огромным.
Точно больше 4 Гб.
Git же сжал это безобразие до где-то 1.3 Гб.

Итак, <tt>git</tt> очень эффективен в обработке этого проекта,
почти все работает отлично, но не все и не всегда.

Система не заработает хорошо, если вы поместите миллион файлов
в один репозиторий при начальном клонировании.
Когда вы его запрашиваете, вы получаете его целиком.
Вы сваливаете все в один репозиторий, <tt>git</tt> думает, что это один обьект.
Не делайте так.

Если у вас есть множество компонентов, размещайте их в отдельные репозитории,
вы можете даже создать суперпроект, в котором содержатся указатели
на другие проекты, при этом что-то теряется в пользовательском интерфейсе,
но вы храните разные проекты по отдельности.
Тогда вы избежите проблемы «получения всего сразу».
Потому что с <tt>git</tt> вам придется получить все и сразу.

'''Из зала''':
{{question}} Как насчет разделяемого кода?

'''Линус''':

Если они все «расшарили» свой код, что вы можете сделать с помощью <tt>git</tt>,
если у вас действительно много «расшаренных» файлов,
то поскольку <tt>git</tt> внутри использует «файловую систему идентифицируемую содержимым»,
то если существуют одинаковые по содержанию файлы,
<tt>git</tt> будет использовать для них в точности один и тот же объект.
И сохранит вам тонны свободного места.

И у вас могут быть эти расшаренные объекты, и в тоже время
они могут храниться у вас как отдельные сущности.
Вы также можете хранить их в раздельных репозиториях,
но лежащих на одной разделяемой файловой системе.
Вы можете это сделать!

Если у вас действительно есть расшаренный код, ну например,
библиотека, которая используется в пяти разных местах,
то если вам стоить использовать поддержку супер-проекта, где у вас есть
один репозиторий <tt>git</tt>, который просто отслеживает остальные репозитории <tt>git</tt>,
(и он тоже может содержать например, разделяемую инфраструктуру сборки),
но при этом индивидуальные части остаются индивидуальными.

Это похоже на модули CVS.
В CVS модули не до конца индивидуальны, но это потому,
что в CVS каталог — это вещь, которая всегда сама по себе,
так что модуль CVS — это комбинация «каталожности» и их отслеживания,
но в целом вы можете думать об этом как о модулях CVS.

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

Возможно, я забыл ответить на какую-то часть вашего вопроса.

[[Image:linus-git-googletalk.0-49-34.467.jpg|frame|right|Можно ли извлечь из репозитория только часть файлов?]]

'''Из зала:'''

{{question}} Можно ли извлечь из репозитория только часть файлов, а не целый репозиторий?

'''Линус:'''

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

Неверно, что <tt>git</tt> не может обрабатывать большие проекты,
просто производительность будет не так хороша,
а вы будете иметь проблемы, которых можно было бы избежать.

Так что я пропускаю этот вопрос и возвращаюсь к теме производительности.

== Performance ==

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

''[показывает слайд «Производительность».]''
[[Image:Linus-git-googletalk.0-51-10.996.jpg|right]]

Производительность — в первую очередь не это.

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

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

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

Например, давайте вернемся к одной из вещей, где,
как мне кажется, разработчики Subversion показали себя полными идиотами.

Жестко сказано, правда?

Наверняка несколько из них сейчас в этой комнате.

Ну вы и тупые!

''[смех]''

Например, Subversion очень шумно хвалится, что
они исправили CVS, сделав ветвления дешевыми.
Это есть на их главной странице, где они вроде говорят,
что ветвление в SVN требует ''O(1)'' операций,
и что можно сделать дешевых ветвей столько, сколько хотите.

Неважно, что ''O(1)'', мне кажется, на самом деле имеет
довольно большое ''O'', но даже если ветвление занимает микросекунду,
кого это волнует?

Вы меряете не то, что нужно.

Ветки полностью бесполезны, если Вы не объединяете их,
а CVS не может объединить вообще ничего.
Вы можете слить изменения однажды,
но тогда CVS забывает то, что вы сделали, и вы никогда не
сможете объединять снова, не получая адские конфликты.
Слияния в Subversion — полная беда.
Разработчики Subversion отчасти признают это, и у них есть некий замысел,
но эти идеи тоже фигня.

Невероятно, насколько эти люди глупы.
Они все время смотрели на проблему неверно.
Проблема-то не в ветвлении, а в слиянии!
А нормальное слияние они так за пять лет и не сделали.
Вот что грустно.

Итак, быстродействие важно, но надо смотреть в корень проблемы.

Затраты на то, чтобы сделать ветку под <tt>git</tt>,
буквально заключаются в создании 41-байтного файла.
Ну насколько это быстро, как думаете?
Не думаю, что вы даже сможете это измерить.
Вы можете, в общем, если вы используете Windows, вероятно
вы можете измерить это, потому что… [''аудитория: смех'']
но как бы то ни было, это так быстро, что реально вы
не сможете это измерить.
И это создает ветку.
Но никого это не волнует, это-то не проблема.

Единственное, что важно, это как быстро вы можете сливать изменения.
В <tt>git</tt> вы можете объединить… я сливаю изменения в 22 тысячах файлов несколько раз в день, и я недоволен,
если объединение занимает более пяти секунд,
и все эти пять секунд загружаются в основном уходят на загрузку ''diffs'', ладно, не ''diffs'',
а дельты между двумя деревьями, а само объединение занимает менее
чем полсекунды.

И я не должен думать об этом.

Вот что длится дольше чем слияние, это то, что после каждого слияния,
по умолчанию <tt>git</tt> сделает <tt>diffstat</tt>
всего, что изменилось в результате объединения, потому что
мне это важно.
Когда я вливаю чьи-то изменения, я им доверяю, но с другой стороны,
вдруг они уже забросили свои лекарства?
Так что я доверяю им, да, но будем говорить начистоту — может
они были в порядке вчера, но сегодня был не их день…
Так что для контроля я делаю <tt>diffstat</tt> и <tt>git</tt> тоже делает <tt>diffstat</tt> по умолчанию,
хотя вы конечно можете для скорости его отключить, но лучше не надо,
<tt>diffstat</tt> по-любому быстр, и обычно занимает…, ну если большое слияние,
обычно занимает секунду-другую.
Поскольку создание ''diff'' и фактически подсчет статистики о том, сколько
строк изменилось — намного более затратная операция,
чем выполнение непосредственно слияния.

Это вид быстродействия, который фактически изменяет ваш стиль работы.
Это не улучшения быстродействия тех же действий, а возможность работать
совершенно по-другому.
Вот что на самом деле означает производительность, и вот почему
вам не стоить смотреть ни на что, кроме <tt>git</tt>.

Hg (Mercurial) довольно хорош, но <tt>git</tt> лучше.

Я думаю, что у меня заканчивается время, мы посмотрим, есть ли еще …,
… о, ОК это все еще интересно.

Мы еще не добрались до части про реализацию,
но не беспокойтесь, я сейчас я много об этом расскажу:
реализация очень проста.

Код и структуры данных очень-очень-очень просты.
Если вы посмотрите на исходный текст и поймете,
что там всего где-то 80000 строк, в основном на Cи,
ну на таком Си, на котором пишу я — большинство его не понимает,
но зато я комментирую код.

Исходный код может порой выглядеть сложным,
потому что мы очень печемся о производительности, особенно я.
Я действительно забочусь об этом, и иногда заставляю вещи работать сильно быстрее,
но при этом приходится использовать более сложные алгоритмы,
чем последовательная проверка файлов по очереди.
Когда вы делаете слияние 22 тысяч файлов, вы не хотите проверять по одному файлу,
вы хотите посмотреть все дерево сразу и сказать:
«А они же одинаковые, я не должен ничего делать».
В общем, <tt>git</tt> делает все такие штуки, и все это несколько раздувает объем кода,
ибо по-уму все это сделать непросто, но основы все же очень и очень просты.

И одна из этих основ, это аспект безопасности и надежности.

''Показывает слайд:''
[[Image:linus-git-googletalk.0-56-39.330.jpg|center]]

Когда <tt>git</tt> отслеживает ваш проект, мы сжимаем каждый блок данных,
вычисляя дельту (различия) по отношению ко всем другим блокам,
кроме того мы вычисляем SHA-1 хеш, который проверяется при
необходимости достать этот блок.

Если у вас побился диск или память, или что-то еще в этом роде — <tt>git</tt> об этом сообщит.
Это даже не вопрос. Это безусловная и безоговорочная гарантия.

У вас могут быть люди, пытающиеся навредить.
У них не выйдет.

Вам нужно точно знать 20 байтов 160-битного SHA-1 хеша от верхушки вашего дерева,
и если вы их знаете, вы сможете доверять вашему дереву сверху донизу,
всей истории целиком.
У вас может быть десять лет истории проекта с сотней тысяч файлов,
миллионами ревизий, но вы сможете доверять любой части любой ревизии.
Потому что <tt>git</tt> такой надежный, и все его основные структуры данных
очень-очень просты.

Да, мы проверяем контрольные суммы.
Но мы не считаем ''слабую'' контрольную сумму, как у некоторых UDP пакетов,
то есть 16-битную сумму всех байтов.
Мы проверяем контрольные суммы, которые считаются криптографически стойкими.

Никто не может взломать SHA-1, но дело в том, что для <tt>git</tt>,
SHA-1 это не функционал информационной безопасности,
а просто проверка целостности.
Безопасность там отдельно.

А то полно народу думают, что раз <tt>git</tt> использует SHA-1,
а SHA-1 используется во всяком криптографическом софте,
то наверно это крутая фича в безопасности.
Так вот, ничего тут нет общего с безопасностью,
это просто самый лучший хеш из имеющихся.

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

Ну то есть, есть тут некоторые основания и с криптографической стороны,
но все это только про гарантии целостности ваших данных.
Я вам гарантирую, что если вы положите ваши данные в <tt>git</tt>,
спустя пять лет, даже если вы сконвертировали их с вашего
винчестера на какой нибудь DVD, или что там будет вместо него,
вы сможете проверить ваши данные и вернуть их назад в том же состоянии,
в котором вы поместили их в систему.
Именно этого вы и должны ждать от любой системы контроля версий.

Одна из причин, по которой я так агитирую за это, состоит в том,
что у нас был случай со взломом одного из сайтов BitKeeper’а,
когда народ пытался испортить репозиторий с исходниками ядра,
а BitKeeper отловил эту попытку.
Но BitKeeper не имеет по настоящему крутого хеша,
думаю, там простейший 16-CRC код, или что-то типа этого.

В принципе, это достаточно, чтобы заметить неуклюжую попытку подмены,
криптографически оно ненадежно, но на практике атаки сделать уже непросто,
так что тогда атака была немедленно пресечена.

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

Нет, ну может ваши проекты и не очень важные, но мои проекты точно важны, и поэтому
я об этом так пекусь.

Это — также одна из причин, … вернемся на секунду к концепции распределенности …,
ну, например, вы делаете ваш проект [[EnPedia:Google Code|Google code]],
где можно держать исходники в ваших репозитариях,
так вот — я бы никогда не доверил Google хранить и поддерживать мои исходники.
Извините, но вы еще не заслужили моего доверия.

Причина, по которой я предпочитаю распределенные системы,
состоит в том, что я могу держать свой исходный текст позади
трех брандмауэров на системе, которая не позволяет даже по <tt>ssh</tt> войти.
Вот здесь я не могу читать свою электронную почту, потому что моя почта
идет на мою машину и единственный путь, как я могу попасть на мою машину
— это когда я физически нахожусь в той сети.

Может я конечно и полностью свихнулся, может только слегка сдвинулся,
и я забочусь о безопасности больше, чем большинство окружающих.
Да и вообще, чтобы я дал эталонную копию репозитария исходников,
о котором я так пекусь, куда-то на сторону?
Абсурд!

Даже Гуглу не дам.
Никогда в жизни, хоть ты меня режь.

Я позволю Google держать копию репозитория, но
хочу чтобы было что-то, про что я знаю точно, что никто это не трогал.

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

20 байтов отследить легче, чем 180 МБ.

И очень маловероятно, что побьются именно эти 20 байтов.

И если у меня есть эти 20 байтов, я могу загрузить <tt>git</tt>-репозитрий даже
из совершенно «левого» источника, и могу гарантировать, что они не сделали с ним ничего плохого.

Ваш проект [Google Code] — хостинг репозитариев для народа — крутое и благое дело,
вот только вы неправильно делаете, если используете для него Subversion.
Из-за вас люди ночами спать спокойно не будут!

Конечно, если вы делаете это для 70 … , сколько там проектов,
75 тысяч?
Большинство из них довольно мелкие и ерундовые, так что все в порядке.
Но если бы вы все сделали правильно, люди бы чувствовали себя получше.

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

== Content Management ==

Я уже немного говорил на тему «Полный целостный проект vs. Отдельные файлы»,
и что <tt>git</tt> отслеживает именно полный проект.

[[Изображение:linus-git-googletalk.1-03-18.642.jpg|framed|right| «Это гораздо больше чем случайный набор файлов»]]

Ну тут на слайде единственный пример с вызовом из командной строки,
''gitk'' — это GUI вьювер истории проекта под <tt>git</tt>,
это скрипт на tcl/tk для просмотра всей той информации, которую <tt>git</tt>
действительно хорошо показывает, а вот это пример командной строки, которую я использую как
«мейнтейнер» высшего уровня.

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

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

Этот функционал <tt>git</tt> по-настоящему уникален!
Больше никто этого не может, а эта функциональность очень важна!
Может быть, она и не так важна для отдельного разработчика,
потому что отдельный разработчик часто думает в терминах отдельных файлов,
но важно для людей, объединяющих версии проекта.
Это важно для таких как я и тех, с кем я непосредственно работаю,
потому что они практически никогда не заботятся об отдельных файлах,
а вот такие вещи для них важны.
Кто-нибудь отправляет отчеты об ошибке, которые не всегда адекватны,
но пусть вам попался довольно вменяемый отчет,
и вы можете сразу засечь — «Ага, это подсистема SCSI».

Вот командная строка (''указывает на слайд'').

Вы не можете указать точно проблемный файл, но можете сказать:
«Удали последние 15 тысяч коммитов, сделанных с прошлой недели, и он откатит
проект до 50 [коммитов]»

Это круто, и никакая другая система так не может, уверяю.

Вот поэтому вы и должны хотеть использовать именно <tt>git</tt>.
Вот к чему это сводится.
Он надежен и так безопасен, что вы можете делать то, что
остальные системы или не делают, или делают очень медленно,
и кроме того, он распределенный.

Итак, продолжим.
Полагаю, мы можем позволить ответить на еще один вопрос.
Что у нас с временем, я как-то без понятия… Ладно, давайте быстро.

[[Image:linus-git-googletalk.1-05-57.109.jpg|framed|right|…будет просто дрейф проблем с масштабируемостью…?]]

'''''Слушатель:'''''

{{question}} Итак, причина ухода с Perforce — на самом деле масштабируемость и эффективность.
Иначе люди просто продолжат ее использовать.
И может, при переходе будет просто дрейф проблем с масштабируемостью и производительностью
из одной области в другую?

'''''Линус:'''''

Ну я уже говорил, что я без понятия, как вы работаете
с Perforce, и какие с ним проблемы, но если вы перейдете на <tt>git</tt>,
вы можете быть в нем уверены, если, конечно,
вы будете использовать его в разумных пределах.
А эти пределы обычно достаточно очевидны.
У вас есть компилятор, основные исходники,
документация, ну может ваша документация разбросана как-то фрагментами,
хотя наверняка у вас есть что-то типа пользовательской документации,
может в Google не так, но во многих компаниях отдельно
идет набор документации для потребителей
и документации, сопровождающей отдельные модули и пакеты.

Так что одним из моментов использования <tt>git</tt>, о котором стоит подумать,
это как организовать разумную структуру проекта.
Git легко поддерживает здоровые проекты, вы можете без проблем держать в нем
десятки тысяч файлов, вот в Ядре, например, их 22 тысячи.
Мы тестировали на ста тысячах — и все было в порядке — <tt>git</tt> быстрей, чем что бы то ни было.

С миллионом файлов, подозреваю, другие системы, могут быть в чем-то и побыстрее.
И не хотелось бы, чтобы вы попали в такую ситуацию.
Но если вы правильно организуете проект и грамотно настроите,
<tt>git</tt> будет и быстрее и лучше, что все остальное.
Я уверен в его исключительной производительности.

Вот одна из вещей, которую мы не очень хорошо делаем,
это «CVS annotate»<ref>Команда, сообщающая по каждой строчке автора, совершившего в этой строчке последнее изменение и последнюю ревизию, в которой эта строчка менялась.</ref>.
Люди часто используют эту команду.
Я говорил, что у Perforce оно тормозит, так что вы,
вероятно, хотя и не уверен, не используете Perforc’ный «annotate».
Но пользователи CVS используют «CVS annotate»,
эту единственную операцию, которую CVS может выполнять быстрее, чем <tt>git</tt>,
потому что CVS работает «пофайлово», а <tt>git</tt> — нет.

У <tt>git</tt> есть «annotate», но фактически это будет поиск,
вы можете узнать об этом, если вы переместите функцию из одного файла в другой,
<tt>git</tt> дословно воспроизведет историю функции, даже несмотря на перемещение.
Внимание, не перемещение файла, а функцию в пределах файла
он пойдет и откопает и скажет:
«Эй! Эти две строки на самом деле пришли из
того файла 5 лет назад».

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

В других проектах у нас есть история и подлинней,
мы делали на них замеры, например, после импорта KDE и других проектов
с еще более длинной историей.
Тут бывают проблемы с производительностью, но все равно даже
с учетом таких проблем <tt>git</tt> на один-два порядка быстрее, так что
в основном беспокоиться не о чем.

И если обнаружите какую-нибудь проблему, то у нас сейчас очень-очень
классное сообщество.
В <tt>git</tt>-овом списке email-рассылок уровень «шума» очень мал,
и хотя писем там изрядное количество, это очень вменяемый мейллист.
Итак, если кто-то заинтересовался, посмотрите исходники,
но начните с просмотра архива рассылки.
У нас есть и свои флеймы, есть и бесцельные споры,
но большинство сообщений там весьма хороши.

OK? Спасибо…

[''апплодисменты'']

== Ссылки ==
<references/>

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