CustisWiki - Новые страницы [ru]

WikiHelp:Перенаправление

2013-01-24T12:07:07Z

AndreyMoiseev:

{{#set: |HelpId=Redirect |HelpOrder=200 |ParentMenuId=CreateArticles |HelpContent=Справка:Перенаправления |HelpDisplay=Перенаправление }}

[Исходная статья]

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

Поскольку имя у статьи есть лишь одно, на страницы с альтернативными названиями ставятся перенаправления. Если пользователь приходит на такую страницу, то CustisWiki автоматически перенаправит его туда, куда указано в исходном тексте страницы.

Для создания на странице перенаправления, напишите в её тексте одну строку:

#REDIRECT [[Название статьи, куда будет перенаправлено]]

Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Репликация: База Знаний «Заказных Информ Систем» → «WikiHelp:Перенаправление»

Внимание! Данная статья выбрана для репликации в SMWiki.

Статья реплицируется в Wiki4IntraNet.

{{#ask: ParentMenuId::Top

?HelpId

?HelpOrder

?ParentMenuId

?HelpDisplay

?HelpContent

?#=Link

sort=HelpOrder

format=template

named args=yes

template=WikiHelp/SideMenu/TopLevel

}}

WikiHelp:Wiki - что,как и почему?

2013-01-24T11:43:39Z

AndreyMoiseev:

{{#set: |HelpId=AboutWiki |HelpOrder=250 |ParentMenuId=StartWith |HelpContent=WikiWiki |HelpDisplay=Wiki - что, как и почему? }}

[Исходная статья]

WikiWiki (Вики) — гипертекстовая интернет-среда, предназначенная для коллективного редактирования, накопления и структуризации текстовой информации.

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

Термин

Название произошло от гавайского слова «wikiwiki» — «как можно быстрее». Концепция Вики отвечает тому, что первоначально задумывал Тим Бернерс-Ли (Tim Berners-Lee), изобретатель Всемирной Сети: доступность информации онлайн и возможность её быстрого изменения. По крайней мере, так он писал в своей книге «Weaving the Web».

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

Wiki (также WikiWiki, WikiWikiWeb или WikiWeb), — это собрание интернет-страниц, которые можно не только читать, но и изменять онлайн. Как и в WWW, отдельные страницы и статьи соединены между собой ссылками. Для реализации вики-среды создаётся (или добывается уже существующее) подходящее для данных целей ПО — движок вики-сети (вики-движок).

Возможность редактировать содержимое вики-сайта любым посетителем, с одной стороны, позволяет без труда накапливать и систематизировать информацию, но, с другой стороны, создаёт обширное поле для вандализма. Из-за последнего все вики-сайты используют технологию CVS, сохраняющую каждую версию документа. Если документ подвергается вандализму, пользователь вики может легко восстановить старую версию. Получается, что портить в Вики сложнее, чем исправлять. Программное обеспечение также позволяет ограничить доступ и права редактирования страниц Вики-среды до определённого круга пользователей.

Таким образом, «Вики» («ВикиВики») это:

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

История

Оригинальная система Wiki была изобретена Вардом Каннингемом. Она была создана для web-узла Pattern Languages Community с целью упростить совместное создание и документирование программных образцов.

Преимущества

Статьи/документы — это плоский текст

Преимущества «плоского» текста (текста, разбитого на строки):

Редактируется в любом текстовом редакторе.
Минимальный «вес» при хранении и пересылке по сети.
Возможно автоматически определять изменения, что дает:
- Параллельное (совместное редактирование);
- Определение авторства каждой строчки;
- Автоматическое разрешение конфликтов;
- Экономная система контроля версий.
- Удобен для автоматической обработки.

Простой язык разметки

Стандартные языки разметки (SGML, HTML, LaTeX):

Сложные для изучения (много элементов, нетривиальный синтаксис);
Возможны трудноуловимые ошибки;
Элементы разметки занимают существенный объем текста (высок «overhead»):
- Долго и трудно набивать текст;
- Текст плохо читаем с экрана.

Плоский текст c простой разметкой:

Быстро пишется;
Легко читается с экрана.

Правка и публикация по месту

Мгновенная публикация:

Для практически всех языков разметки, кроме HTML, нет WYSIWYG-программ просмотра — необходима конвертация в DVI, PostScript, PDF, RTF или тот же HTML, что происходит небыстро.
Публикация по месту позволяет вносить правки в процессе чтения материала (не нужно искать исходные тексты)
Немедленная публикация позволяет сразу же проверить внесенные правки.

Автоматическое построение ссылок

Автоматическая линковка:

Стандартные языки разметки (TeX, LaTeX, SGML) разделяют идентификаторы и названия структурных блоков (секций, глав, разделов), что:
способствует строгой целостности;
Вносит большую «нагрузку» на внесение ссылки
Идентификаторы=Названия=Заголовки
Адаптивная линковка:
- «Опережающие» ссылки на несуществующие статьи;
- Перенаправления ссылок.

Централизованное хранение

При локальной обработке размеченной (HTML, XML, LaTeX, SGML) документации необходимо одновременно знать

файловую структуру проекта (в каком файле что лежит);
Идентификаторы разделов.
Иметь систему синхронизации изменений от различных пользователей

ВикиВики система сама обеспечивает

централизованное хранение всех блоков текста («статей»)
идентификатор хранения=идентификатор ссылки=названию статьи.

Редактировать может каждый

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

Недостатки

Редактировать может каждый

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

Нет стандартной вики-разметки

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

Разметка не «адаптирована к компьютеру»: Мало программных библиотек стандартного разбора (parsing) документов (в отличие от XML/SGML/HTML).

Ограниченное использование возможностей верстки и полиграфии

Шрифты;
Сложные страницы с полями;
Плавающие объекты и т. п.
Оптимальный кернинг и выравнивание пустых пространств.

Размыта ответственность за содержимое;
Допустима ссылочная нецелостность.

Почему это работает?

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

Когда это не работает?

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

Репликация: База Знаний «Заказных Информ Систем» → «WikiHelp:Wiki - что,как и почему?»

{{#ask: ParentMenuId::Top

?HelpId

?HelpOrder

?ParentMenuId

?HelpDisplay

?HelpContent

?#=Link

sort=HelpOrder

format=template

named args=yes

template=WikiHelp/SideMenu/TopLevel

}}

WikiHelpContent:Расширенная разметка

2013-01-23T11:51:45Z

AndreyMoiseev: Новая страница: «См. подразделы.»

См. подразделы.

WikiHelp:Багзилла

2013-01-18T14:57:24Z

AndreyMoiseev:

{{#set: |HelpId=Bugzilla |HelpOrder=200 |ParentMenuId=Integration |HelpContent=Bugzilla |HelpDisplay=Багзилла }}

[Исходная статья]

Логотип Bugzilla

Bugzilla — система отслеживания ошибок, разрабатываемая Mozilla Foundation.

Может также упоминаться (и с некоторыми оговорками использоваться) как:

Система учета заданий
Система ведения дел
Система регистрации инцидентов
Система управления требованиями, идеями, предложениями, заявками и т.п.
Сайт: http://www.bugzilla.org
Распространение: freeware, open source

Введение

Ключевым понятием системы является Bug (баг) — некоторое задание, запрос, рекламация по поводу ошибки в системе или просто сообщение, требующее обратной связи. Баги регистрируют и предоставляют заинтересованным лицам целостную информации о состоянии этого issue, включая интерфейсы редактирования, запроса и поиска, механизмы почтового и RSS-оповещений.

Bugzilla используют многие компании и организации по всему миру. Из наиболее известных: NASA, IBM, Mozilla, Linux Kernel, Gnome, KDE, Apache Project, Open Office.

Анатомия бага

Сущность Bug имеет набор атрибутов, работа с которыми — редактирование и запросы — является основными сценариями использования Bugzilla. Рассмотрим эти атрибуты.

Структурные атрибуты

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

2. Component (Компонент) - дополнительная структурная классификация. В зависимости от выбранного компонента баг может иметь разный набор компонентов.

Атрибуты жизненного цикла

1. Status (Статус) - основной атрибут, определяющий текущее состояние бага. Отражает меру активности бага от начального состояния, когда он еще не подтвержден как баг, до завершения, когда баг исправлен/решен, что подтверждено Службой Качества. Набор состояний зависит от конкретной инсталляции и настроек Bugzilla. Стандартный набор:

UNCONFIRMED (Не подтвержден)

Наличие этого состояния зависит от настроек конкретного Продукта. Например, если считается, что баг-отчеты в Продукт могут составлять неконтролируемое множество пользователей (например, интернет-аудитория), в этом состоянии имеется смысл. Тогда для перехода в следующее состояние (NEW) необходимо решение пользователя системы с правами canconfirm. Если же новые баги ставят только обученные сотрудники, то это состояние скорее всего не нужно;

NEW (Новый)

Баг только что зарегистрирован или проверен (если был зарегистрирован в состоянии UNCONFIRMED);

ASSIGNED (Назначен)

Пользователь в поле Assigned To назначен ответственным за этот баг. Баг может быть назначен на другого сотрудника или переведен в состояние NEW;

REOPENED (Открыт заново)

Баг был решен ранее, однако возникла необходимость вернуться к нему (решение было неверным либо неокончательным).

2. Resolution (Резолюция, Решение) - атрибут имеет смысл только для багов в состояниях RESOLVED, VERIFIED, CLOSED. Набор значений атрибута настраиваемый, стандартный набор:

FIXED (Решено) — стандартная резолюция, означающая, что задание выполнено или баг исправлен;
INVALID (Некорректно) — неправильная или некорректная постановка задачи;
WONTFIX (Проблема есть, но решаться не будет) - такая резолюция может быть в отношении request for enhancement, которые хоть и имеют смысл, являются слишком трудновыполнимыми и не являются обязательными;
DUPLICATE (Дублирует) — описанная проблема уже зарегистрирована в другом баге;
WORKSFORME (А у меня работает…) — не удалось воспроизвести описанную проблему ни эмуляцией сценария, ни анализом кода;
MOVED (Перенесено) - проблема перенесена в иную систему-tracker.

Также можно использовать:

LATER (Позже) - задача зафиксирована, но ее решение откладывается на неопределенный срок. Возможно, для ее решение необходимо некоторое внешнее событие или решение других задач. Если в продукте есть веха «неопределенное будущее», разумно также установить target milestone на эту веху.

3. Диаграмма

Жизненный цикл бага (он же граф переходов состояний, workflow) жестко задан в коде и представлен ниже, на графе.

[svg]

Связанные пользователи

Assigned To (ответственный) - пользователь, ответственный за решение (исправление) бага. Подтверждение ответственности происходит при переводе бага из состояний NEW и REOPENED в ASSIGNED.

Reporter (автор) - пользователь, создавший баг.

QA Contact (проверяющий, тестировщик) - пользователь, ответственный за проверку решения бага.

CC List (список наблюдателей) - список заинтересованных в баге пользователей, оповещаемых об изменениях бага.

Описание бага

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

2. Version - номер версии продукта (компонента продукта), в которых наблюдается описанная проблема.

3. Priority - приоритет бага, указывается Assigned To пользователем на основе собственной оценки. Менять приоритет у чужих багов неправильно. Стандартный набор значений — от P1 (наивысший приоритет) до P5 (наименьший).

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

Blocker - разработка или использования продукта невозможна. Требуется немедленное решение проблемы;
Critical - серьезные проблемы — не работает критичный для использования функционал, наблюдаются серьезные ошибки, связанные с потерей данных и т. п;
Major - проблема связана с важным функционалом продукта;
Minor - проблема связана со второстепенным функционалом продукта или есть легкий обходной путь для решения проблемы;
Trivial - проблема косметического уровня. Например, недоработанный интерфейс - опечатки, не выровненные поля, разнобой цветов и пр.;
Enhancement: Request for enhancement - запрос на усовершенствование.

5. Target (Target Milestone, Веха) - здесь указывается веха (версия, стадия) проекта, к которой баг должен быть решен. Не путать с Version. Например, баг может описывать ошибку, возникшую в версии 1.17, которую было решено исправить к версии 1_21. Веха не обязательно привязана к версии продукта, она может быть привязана к определенному времени. Набор вех — набор единых для каждого продукта событий, которые должны синхронизировать процессы исправления, тестирования и пронесения изменений. Каждый продукт имеет атрибут Milestone URL, содержащий ссылку на документ с именованными и описанными вехами, то есть где будет приведен некоторый Roadmap проекта.

6. Comments - комментарии к багу. Первый — это Description, остальные в форме редактирования бага именуются Additional Comments. Bugzilla рассылает всем связанным с багом пользователям комментарии по почте. В нашей инсталляции Bugzilla есть возможность «Silent» комментариев (checkbox Silent), уведомления о которых не рассылаются по почте. Использовать Silent следует только в том случае, когда информация в комментарии действительно мало интересна — например, worklog-запись о выполненной промежуточной (не решающей баг) работе, или если основная ценность записи - регистрация личных трудозатрат (см. Учет времени (Time tracking)).

Не стоит злоупотреблять комментариями, превращая баг в форум. Для обсуждения постановки задачи, продуктивней завести ассоциированную с багом статью в Wiki-системе, и обсуждать там (см. Интеграция с Wiki).

Зависимости между багами

В Bugzilla регистрируется только один единственный вид зависимостей: «баг X зависит от решения бага Y». Нет разделения структурных зависимостей вида «проблема X подразделяется на проблемы X₁,X₂,X₃» и сетевых зависимостей общего вида, но в целом ничто не мешает представлять структурные зависимости в общем виде («баг X зависит от решения багов X₁,X₂,X₃»).

Зарегистрированные зависимости видны и при просмотре атрибутов отдельно выбранных багов, и могут быть просмотрены в виде ориентированного графа вида:

[svg]

В нашей инсталляции Bugzilla 3 графы зависимостей имеют две дополнительные особенности:

«Важные» баги отображаются более крупными, и их заголовки отображаются прямо на графе. Важными считаются баги, имеющие в трудозатратах или их оценке более 40 часов, либо блокирующие более 4-х багов.
Можно выбрать альтернативный алгоритм построения графов, располагающий баги на поверхности более плотно — twopi - Баг 11407 зависит от решенного 11406 и нерешенного 11405.

Depends on указывает, от решения каких багов зависит данный баг.

В нашей инсталляции Bugzilla показывается также активность по блокирующим багам, а именно:

Процент выполненности блокирующих

Blockers completed ~16%,

Дата последнего изменения блокирующих багов

last changed 2009-02-12 12:57:45

Blocks указывает, решение каких багов зависит от данного бага.

Прочее

URL - ассоциированный с багом URL, указывающий на документ с описанием/постановкой проблемы, если таковой имеется.

В нашей инсталляции Bugzilla можно пользоваться автоматической связью между багом и ассоциированной с каждым Component'ом Wiki-системой, в которой можно делать пристойно отформатированную постановку задачи и даже вести ее обсуждение (См. Интеграция с Wiki).

Whiteboard - текстовая зона свободной формы для задания кратких заметок или тегов к багу.

Keywords - ключевые слова, используемые для пометки и даже для классификации багов.

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

Attachments - прикрепленные к багам файлы (сценарии тестирования, патчи и пр.).

Атрибуты, не используемые в нашей инсталляции Bugzilla:

Platform - вычислительная платформа (железо), на которой наблюдается проблема;

OS - операционная система, на которой наблюдается проблема;

Votes - голоса за баг. Используется в основном для автоматического перевода бага из UNCONFIRMED в NEW.

Поиск багов

Основные атрибуты

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

Хранение запросов

Любой выполненный запрос можно сохранить под выбранным именем (Remember Search As). Ссылка на сохраненный поиск отобразится в линейке Saved Searches, результат запроса можно будет получить за один клик, перейдя по ссылке.

Временные условия

Можно накладывать временные условия на изменение бага, запрашивая только баги, по которым было какое-либо движение (изменение атрибутов, комментарии) в определенном интервале времени — см. группу полей Bug Changes. Интервал времени можно задавать как в абсолютной форме (дата в формате YYYY-MM-DD), так и в форме, относительной текущей дате. Можно сделать хранимый запрос, показывающий только баги, измененные в течение предшествующих 24 часов (или недели, месяца).

Можно использовать слова:

Now — сейчас, разумно использовать для задания верхней границы интервала.
1d — день назад. 2d — два дня назад, 0d — последняя полночь до текущего момента.
1w — то же самое в неделях. 0w — начало недели.
1m — то же в месяцах. 0m — начало месяца.
1y — то же в годах. 0y — начало года.

Можно добавить перед относительными датами знак +, это будет означать, что относительная дата не вычитается из Now, а прибавляется (в будущее).

Полнотекстовый поиск

Начиная с версии 3.0 Bugzilla поддерживает честный полнотекстовый поиск по MySQL FULLTEXT-индексам, а с нашими доработками — и русскоязычную морфологию через стеммер Портера Lingua::Stem::Ru (порт из snowball).

То есть по слову «завтрака» ищется и «завтрак», и «завтраков» и пр.

Искать по словам можно из двух мест: со страницы поиска и из поля Quicksearch в шапке и подвале страниц Bugzilla.

По умолчанию ищутся баги, содержащие в описании и/или комментариях все введённые слова с учётом морфологии. Однако, также действует специальный синтаксис, на самом деле совпадающий с синтаксисом MySQL Fulltext Boolean Search. При встрече во введённом запросе любого элемента этого синтаксиса запрос автоматически переключается в режим поиска любого из введённых слов, если не указано обратное.

Описание синтаксиса:

слово - слово не обязательно должно присутствовать в тексте бага, однако тексты, содержащие данное слово, ранжируются выше других;
+слово - слово обязательно должно присутствовать в тексте бага;
-слово - слово не должно присутствовать в тексте бага. Работает только в сочетании с заданными «положительными» словами — запрос, состоящий из просто «-слова», не вернёт ни один баг;
>слово - повышенная важность слова — больше вклад в ранжирование;
<слово - пониженная важность слова;
+(слово1 слово2) слово3 - группировка выражений скобками. Может быть вложенной;
~слово - ранжировать тексты, содержащие слово ниже других, но не исключать окончательно;
сло* - знак шаблона (wildcard). Такой запрос найдёт и «слона», и «слово»;
"слово, или фраза" - поиск словосочетаний, а не слов. Знаки препинания между словами не учитываются, морфология учитывается.

Слова короче 3 символов в поиске не учитываются.

Boolean Charts

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

[ NOT ]
 ( (Атрибут₁₁ Операция₁₁ Значение₁₁) OR
   (Атрибут₁₂ Операция₁₂ Значение₁₂) OR
   ....)
 [ AND
   (Атрибут₂₁ Операция₂₁ Значение₂₁) OR
   (Атрибут₂₂ Операция₂₂ Значение₂₂) OR
   ....) ]
 [ AND ... ]
 )

Можно накладывать условия по флагам, например: Только баги, содержащие флаги, установленные пользователем user@company.com - «Flag Setter» «is equal to» «user@company.com» Только баги, в которых флаг флаг_утвердить установлен в + - «Flag» «is equal to» «флаг_утвердить+» (аналогично с ?,-)

В Bugzilla 3.0 появилась возможность, ранее имевшаяся только в нашей версии — подзапросы по сохранённым запросам поиска в лице операций matched by saved search (присутствует в списке, возвращаемом запросом таким-то), и not matched by saved search (отсутствует в списке, возвращаемом запросом таким-то).

Например, вы можете сформулировать условие «Блокируется багом из списка, возвращаемого сохранённым запросом поиска My Bugs» — для этого нужно выбрать поле Depends On, операцию matched by saved search и значение My Bugs.

Чуть менее тривиально: можно задавать и запросы вида «найти все мои баги в открытом состоянии, для которых все блокирующие выполнены». Для этого просто нужно создать сохранённый запрос, находящий все выполненные баги, и подменить в запросе из предыдущего абзаца My Bugs этим запросом.

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

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

NOT(Depends On "contains regexp" "[0-9]+" )
NOT(Blocks     "contains regexp" "[0-9]+" )

Списки багов

После выполнения запроса система возвращает выборку — список удовлетворяющих запросу багов. Формат этого списка настраиваемый, по ссылке Change Columns можно настроить набор показываемых в списке атрибутов. Также можно включить настройку Stagger headers — разнесение заголовка таблицы списка на два уровня.

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

Другие полезные возможности вызываются ссылками, расположенными внизу списка:

CSV - выдает список в CSV формате (разделенным запятыми) например, для импорта в программу электронных таблиц;
Buglist feed - выдает список в RSS формате, для чтения через RSS-агрегатор. Список отсортирован по убыванию времени открытия бага, набор полей задан жестко. Может быть полезным для отслеживания поступления новых багов. Для пользователей Mozilla Firefox рекомендуется установить Sage, чтобы использовать Bugzilla-авторизацию, полученную браузером после логина.
Activity feed - показывает RSS-ленту последних комментариев и активности по выбранным в списке багам;
Change Columns - изменение списка атрибутов, показываемых в списке;
Change several bugs at once - если у вас достаточно привилегий, вы можете делать некоторые изменения одновременно над всеми багами в списке — например, сменить ответственного, закрыть группу багов, перенести их в другой Product или Component.
Send Mail to Bug Assignees - отправить письмо всем ответственным по всем багам в списке;
Edit Search - вернуться на страницу запроса для его уточнения;
Remember Search As - присвоить этому запросу имя и сохранить, ссылка на сохраненный запрос отобразится в Saved Searches внизу страницы.

Также есть 3 кнопки:

Long format - показывает несколько багов на одной странице в подробном формате со всеми атрибутами и полными обсуждениями;
XML - даёт возможность выгрузить баги в XML-файл для специальной обработки или импорта в другую Bugzilla;
Time Summary - перенаправляет на страницу просмотра отчётов по трудозатратам по выбранным багам (см. Time Summary).

В нашей инсталляции Bugzilla также есть пункты:

Graph - просмотр выбранного списка багов в виде ориентированного графа;
Summary Report - просмотр табличной агрегации (cм. Отчеты) выбранного списка багов по выбранному срезу (набору атрибутов). Каждая ячейка табличного отчета будет содержать число багов, обладающих соответствующими атрибутами и ссылка на список этих багов. Таким образом, можно легко делать настоящий OLAP drill-down, то есть формулировать "широкий" запрос, переходя от списка к табличному отчету, раскладывать по выбранным измерениям (от одного до трех), и далее получать списки багов по отдельным ячейкам среза, возможно повторяя процедуру раскладки по другим измерениям.

Создание багов

Создание багов вручную

Процедура следующая:

Кликните на ссылке New в нижней или верхней линейке Actions;
Выберите классификацию и продукт;
Заполните поля. Уделите особое внимание атрибутам, идентифицирующим проблему или задание (что, где, насколько срочно) — Component, Version, Severity. Старайтесь дублировать (не обязательно дословно) содержимое Summary в первом комментарии (поле Comments). Атрибут Summary может быть несколько раз отредактирован, что приведет к утере первоначального смысла бага;
Нажмите Commit — это зафиксирует и отправит ваш bug report.

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

Создание бага клонированием другого бага

См. ниже

Импорт из Excel-файла

Bugzilla 3.0 поддерживает массовый импорт багов из Excel-файлов — как бинарных *.xls, так и OOXML *.xlsx.

Система подразумевает, что первая строка Excel-файла содержит заголовки колонок, а последующие — описания багов. Обязательными полями бага являются Product, Component и Summary.

Процедура импорта багов из Excel-файла следующая. Сначала вы выбираете Excel-файл и устанавливаете начальные параметры импорта. Далее система разбирает загруженный файл и отображает его на веб-странице для проверки и изменения каких-либо полей или сопоставления полей колонкам таблицы.

После проверки и нажатия Import selected bugs отображается страница с результатами импорта:

с ошибкой, в этом случае ни один из выбранных багов не импортируется;
с успехом, в этом случае будет присутствовать текст Successfully imported X bugs и список ID созданных багов.

Для запуска Excel-импорта:

Кликните на ссылке New в нижней или верхней линейке Actions;
Внизу страницы, под списком классификаций или продуктов, перейдите по ссылке See also: Mass bug import from Excel file;
Выберите Excel-файл кликом по кнопке Обзор…;
Если ваш Excel-файл содержит несколько листов, а вы хотите импортировать только один из них, введите его название в поле Enter sheet name to process. Если вы хотите импортировать все листы, очистите это поле;
После загрузки файла система автоматически проверяет список на наличие уже импортированных ранее багов по точному совпадению названия и максимальному возрасту бага, указываемому в днях в Maximum bug duplicate age. Поэтому, если вы производите повторный импорт файла (модифицированного), укажите такой максимальный возраст, чтобы баги, импортированные ранее из того же файла, попали в этот возраст;
Если вы хотите установить значение определённых полей по умолчанию для всех импортируемых багов, можно выбрать поле, нажать Add field value for all bugs и заполнить выбранное поле;
Нажмите кнопку Parse File.

После нажатия кнопки Parse File будет показана страница с таблицей так, как её видит система. Если колонки в Excel-файле имели названия, совпадающие с названиями полей в Bugzilla, они автоматически сопоставятся нужным полям бага. Если автоматического сопоставления не произошло, кликом на название колонки можно выбрать нужное поле из выпадающего списка.

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

По результатам автоматической проверки существующих импортированных багов из списка будут установлены флажки слева каждой строки. По нажатию кнопки Import selected bugs будет предпринята попытка импорта только помеченных флажками багов.

После успешно выполненного импорта вы увидите ссылку Import another Excel file — you can bookmark this link as a template. В этой ссылке сохранена информация о сопоставлении полей и значениях полей для всех багов по умолчанию. Поэтому, переходя по ней, вы сможете импортировать другой файл того же формата без лишних усилий. Также вы можете сохранить ссылку в закладки браузера для использования в будущем.

Редактирование багов

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

В основном редактированием основных атрибутов бага занимаются связанные с багом пользователи, указанные в атрибутах Reporter, Assigned To и QA Contact. Регламент работы с багом жестко не определен, любой пользователь, обладающий соответствующими правами, может изменять состояние и атрибуты бага.

Впрочем, обычно:

Reporter ответственен за указание атрибутов, идентифицирующих проблему (что, где, насколько срочно) — Product, Version, Severity;
Assignee определяет Priority, Status, переводя баг по состояниям NEW -> ASSIGNED -> RESOLVED.
QA Contact определяет Status, переводя баг из RESOLVED в VERIFIED или REOPENED.

Если в инсталляции Bugzilla включены функции регистрации времени (например, параметр timetrackinggroup), то можно регистрировать предварительную оценку сложности задачи и с каждым комментарием свои трудозатраты, корректировать оценку оставшийся работы (См. Учет времени (Time tracking)).

В окне редактирования бага можно выяснить различные аспекты решаемой проблемы, зарегистрированные в Bugzilla:

Лента комментариев к багу, отсортированная по времени;
View Bug Activity - история изменения всех атрибутов бага.
Look for Bug in CVS, SVN, Git - ссылка на страницу ViewVC — выполняет поиск в CVS и Subversion - репозитариях ревизий файлов, в комментариях к которым указан номер этого бага. Страница результатов поиска содержит также ссылки на другие действия с файлами. Оставленная до поры, до времени ^+Old — ссылка на аналогичную страницу поиска в Bonsai в будущем будет удалена. См. интеграция с системами контроля версий.
Look for Bug in Wiki - перенаправляет на ассоциированную с багом статью Wiki см. Интеграция с Wiki.

В нашей инсталляции Bugzilla можно воспользоваться ссылкой Preview (например, проверить, правильно ли гиперлинкуются ссылки, см. Автоматические ссылки), и убедившись, что все хорошо, вернуться кнопкой браузера Назад и выполнить Commit.

В стандартной инсталляции для этого можно использовать страничку c адресом вида http://bugs.office.custis.ru/bugs/page.cgi?id=linkify.html

Клонирование бага

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

ссылка clone to other/same/int product на первом комментарии;
ссылка Clone This Bug внизу страницы (аналог clone to other product на первом комментарии).

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

В нашей инсталляции Bugzilla также можно клонировать в баг любой комментарий исходного бага ссылкой clone to other/same/int product на комментарии.

Полезности Bugzilla

Автоматические ссылки

Комментарии в Bugzilla разрешены только plain текстом с использованием некоторых HTML-тегов. Ссылки с помощью <A HREF=""> вставить не получится. Тем не менее, Bugzilla делает гиперссылки для определенного рода комментариев, например распознаются и гиперлинкуются основные типы URL:

«http://»,
«ftp://»,
«mailto:»,
почтовые адреса someone@somewhere.org.

Дополнительно гиперлинкуются ссылки на внутрибагзильные элементы (баги, комменты, вложения):

bug 12345
comment 7
bug 23456, comment 53
attachment 4321

Интеграция с системами контроля версий

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

Наша инсталляция Bugzilla интегрирована с системой ViewVC, в которую оперативно загружается информация о всех правках в CVS- и Subversion-репозиториях Компании. Поэтому, если при работе над багом XXX ведутся правки файлов, находящихся под CVS или Subversion, при фиксации (выполнении commit) не нужно писать длинных комментариев, описывающих суть изменений, а достаточно указать номер бага. Например, выполнить

cvs commit -m "Bug 1234"

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

При соблюдении этого правила для каждого бага можно найти все commit'ы, в комментариях к которым указан номер этого бага, с помощью ссылки Look for Bug in CVS, SVN, Git на странице бага.

Ранее похожую функцию выполнял Bonsai, однако был сделан переход на ViewVC по причине поддержки не только системы контроля версий CVS, но также и Subversion последним. Посему ссылки Look for Bug in CVS, SVN, Git теперь ведут именно в ViewVC.

Интеграция с Wiki

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

В нашей инсталляции Bugzilla дополнительно к возможностям автоматических ссылок можно делать читаемые гипертекстовые ссылки на статьи (разделы статей) в CustisWiki, например:

wiki:Bugzilla#Автоматические_ссылки
wiki:[[Bugzilla#Автоматические ссылки]]

будет ссылаться на Bugzilla#Автоматические_ссылки.

Если при работе над багом требуется сделать документ-постановку задачи и/или провести его обсуждение, можно воспользоваться ссылкой Look for Bug in Wiki на странице бага и перейти к одноименной с багом статье Bug XXX для чтения/редактирования/обсуждения.

Рекомендуется после заведения статьи выполнить ее переименование (закладка move/переименовать) в более понятное название, например «Ошибка ORA-YYY при загрузке каталога (Bug XXX)», copy-paste атрибута Summary.

Таким образом, будет создана статья с смысловым заголовком и статья-перенаправление «Bug XXX».

Однако, стоит помнить, что в CustisWiki не стоит помещать конфиденциальную информацию, так как тут уже не действует система прав Bugzilla.

Учет времени (Time tracking)

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

Ведется учет следующих полей:

Orig. Est. - начальная оценка трудоемкости бага. Разумно использовать как априорную оценку трудоемкости. Хотя ее можно менять, лучше это делать реже, чтобы сохранился смысл априорной оценки, данной разработчиком или руководителем проекта;
Current Est.- текущая оценка трудоемкости бага. Вычислимое поле, является суммой Hours Worked и Hours Left;
Hours Worked- число затраченных часов. Только увеличивается с каждым редактированием;
Hours Left - осталось затраченных часов. Изначально выставляется, как разница Current Est. и Hours Worked, но будучи отредактированным, влияет на Current Est. Например, если считалось, что на баг надо затратить 5 часов, а после некоторой работы выяснилось, что затрачено 3 часа, а осталось еще 7, то текущая оценка меняется на 10 часов.
% Complete - процент завершенности. Вычислимое поле, равно Hours Worked/Current Est.
Gain - Выигрыш. Вычислимое поле, является разностью Orig. Est. и Current Est.
Deadline - крайний срок решения/выполнения бага.

Единица измерения — часы. Можно вводить дробные значения 1.5 = полтора часа.

Time Summary

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

Советы по использованию Bugzilla

В процессе использования Bugzilla было сделано много доработок. О них можно очень кратко прочитать здесь Bugzilla: Список доработок#Доработки 3.x

Поддерживайте целостность:
- Дублируйте содержимое Summary в первом комментарии,
- Указывайте корректные значения в полях или не указывать никаких. Например, не пишите строки «any», «нет», "-" и прочее в URL, если нет конкретного связанного с багом URL.

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

Сделана специальная доработка (Bug:15001 и Bug:53638, которая позволяет присоединить текстовое вложение к багу через буфер обмена, без создания файла, с одновременным добавлением комментария, фиксацией времени и изменением некоторых атрибутов бага. Таким образом, если Вы получили текстовое сообщение об ошибке с большим стеком, то надо не писать комментарий, а добавить вложение, где вставить это сообщение в текстовое окно вложения (переключив radio button на Enter text), а ниже написать комментарий с краткой формулировкой ошибки.

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

Не вкладывайте простые тестовые примеры (например HTML-файл, ссылающийся на CSS и картинку) как архив. Вместо этого загрузите перечисленные файлы в обратном порядке, и отредактируйте вкладываемый HTML-файл, чтобы он ссылался непосредственно на загруженные вложения. Bugzilla хранит и использует Content-Type для каждого вложения (например, text/html). Чтобы выгружать вложение с другим Content-Type (например, application/xhtml+xml), надо добавить CGI-параметр Content-type в URL, то есть &content-type=text/plain.

Комментирование

Если вы изменяете баг, добавляйте комментарий, только если вам действительно есть что сказать или если этого требует Bugzilla (для некоторых типов переходов). В противном случае, вы будете без нужды засыпать письмами связанных с багом пользователей. Например, люди могут настроить свой аккаунт (см. Field/recipient specific options), чтобы не получать извещений при событиях вида «Изменился CC List». Но если доброжелатель добавляя себя, добавит комментарий «Я, типа, себя добавил», это будет уже добавление комментария и обойдет вышеуказанный фильтр.

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

Конфликты

Если вы считаете, что отправленный вами баг некорректно помечен как DUPLICATE of another, задавайте вопросы-комментарии в вашем баге, а не в том, который считается багом-оригиналом. Смело добавляйте в CC List бага человека, который принял такое решение, если его нет.

Флаги

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

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

Чтобы установить флаг, выберите +, или - из выпадающего списка Flags. Значение этих символов зависит от флага? в качестве примера, установление флага review в + может означать, что баг или вложение одобрены, а в - — отклонены. Чтобы сбросить флаг, выберите в выпадающем списке пустое значение.

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

В нашей инсталляции Bugzilla есть доработка, позволяющая не вводить пользователей для запрашиваемых флагов вручную, а выбирать из списка связанных с багом пользователей (Reporter, Assignee, QA Contact, CC List).

Установленный флаг показывается на странице бага и странице edit attachment рядом с аббревиатурой установившего флаг пользователя. Например: Иван: review [ + ]. Аналогично показывается запрошенный флаг, только в скобках показывается имя пользователя, у которого запрошена установка флага, например Иван: review [ ? ] (Бибичев).

Отчеты и графики

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

Отчеты

Отчет представляет собой некий информационный срез о текущем состоянии базы зарегистрированных багов. Можно сделать отчет как обычным, HTML-табличным, так и графическим, с различными видами графиков: линейными, круговыми, гистограммы (line/pie/bar), и переключаться между этими режимами просмотра онлайн.

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

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

Или разработчик может выбрать все свои баги, распределив их по критичности и своей оценке приоритета, получив следующую таблицу, где каждая ячейка (например, (major,P2)=> 2) является гиперссылкой на выборку соответствующих багов (в данном случае, двух багов, у которых в дополнение к условиям общего запроса Severity=major, а Priority=P2):

            Priority
Severity       P2       P3     P4     P5   Total
 major         2        .       1     .     3
 normal        8        1       1     .     10
 minor         .        .       2     2     4
 trivial       .        1       .     .     1
 enhancement   .        .       1     1     2
 Total         10       2       5     3     20

От выборки багов можно снова перейти к таблице и продолжить детализацию далее (см. описание Summary report в списках багов.

После заполнения параметров и вызова Generate Report вы можете переключаться между форматами HTML, CSV, Bar, Line, Pie (формат Pie доступен, если вы определили только одну горизонтальную ось). Остальные интерфейсные элементы интуитивно понятны — можно изменять размер картинки, если текст наползает графику или слишком узкие столбцы гистограмм.

В нашей инсталляции Bugzilla кроме числа багов можно просматривать агрегированные временные параметры бага:

Remaining time;
Estimated time.

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

          Priority
Severity       P2      P3      P4      P5      Total
major          32      .       .       .       32
normal         47.5   184      .       .       231.5
minor          .       .       .       192     192
trivial        .       5       .       .       5
enhancement    .       .       30      3       33
Total          79.5   189      30      195     493.5

Динамические графики (Charts)

Динамические график (chart, чарт) — это просмотр эволюции состояния базы багов во времени.

В данный момент в Bugzilla есть две системы построения таких графиков — Old Charts и New Charts.

Old Charts — это старая, давно используемая система, она отображает только изменения статусов и решений багов для каждого продукта. Она более не поддерживается и не развивается, и будет вскоре исключена из системы. Развиваться будет система New Charts, которая позволяет отрисовывать все, что можно задать поисковым запросом.

Обе системы требуют, чтобы администратор настроил скрипт, собирающий данные.

Каждая отдельная линия в чарте представляется датасетом data set, которые упорядочены в категории и подкатегории. Категории/подкатегории автоматически определяются на основе отношений Продукт/Компонент (для всех продуктов и компонентов), но также можно определять и любые другие категории.

Датасеты могут быть публичными (видимыми для всех) и приватными (доступными только создателю). Сделать датасет публичным могут только администраторы.

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

Создание Динамических графиков

Для создания динамического графика необходимо выбрать в списке требуемые датасеты и нажать Add To List. В списке List Of Data Sets To Plot вы можете задать название для каждого отображаемого датасета, также можно заказать суммирование подмножества выбранных датасетов (то есть просуммировать датасеты? представляющие баги в состоянии RESOLVED, VERIFIED и CLOSED для выбранного продукта, получив полное число исправленных багов). Ошибочно добавленный датасет можно исключить с помощью чекбокса и Remove. Если вы добавили более одного датасета, в списке автоматически появится линия Grand Total. Если она не нужна, ее можно удалить, как и любую другую линию.

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

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

По окончании настроек нажмите Chart This List для получения чарта.

Создание датасетов

Для создания нового датасета следуйте ссылке create a new data set на странице Create Chart. Используя стандартный интерфейс выбора определите нужную выборку, внизу страницы определите категорию, подкатегорию и имя для нового датасета.

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

Настройки пользователя

После того, как вы войдете в систему, вы можете изменить личные настройки Bugzilla по ссылке Preferences.

Настройки расположены на пяти вкладках: General preferences, Email preferences, Saved searches, Name and password, Permissoins. Рассмотрим подробнее каждую из них.

General preferences

Вкладка содержит простые настройки общеинтерфейсного плана.

В нашей инсталляции Bugzilla дополнительно включены настройки:

After changing a bug - по умолчанию, после правки бага Bugzilla перенаправляет на следующий баг в списке, однако большинство людей это смущает, и они путают следующий баг с предыдущим. Для борьбы с этим поведением и служит данная опция. Нужно выбрать Show the updated bug;
Remind me to track worktime for each comment - запрос затраченного времени, если пользователь из timetrackinggroup не заполнил (поставил 0) в Hours Worked при введении комментария;
Remind me to track worktime for new bug - требование введения трудозатрат от пользователя из timetrackinggroup при постановке каждого нового бага;
Remind me about flag requests - при вводе комментария пользователем, на которого поставлены флаги-запросы (флаги в состоянии ?, у которых requestee = этому пользователю) — будет проверять и переспрашивать, не желает ли пользователь изменить состояния флагов (ответил ли он своим комментарием на эти вопросы).

Email preferences

Эти настройки определяют когда и сколько писем будет вам прислать Bugzilla. Если вы хотите получать все письма — нажмите кнопку Enable All Mail, если не хотите получать письма от Bugzilla вообще — нажмите Disable All Mail.

Администратор Bugzilla может заблокировать получение почты пользователем через добавление имени пользователя в файл data/nomail. Такие меры применяются в исключительных случаях — например, для аккаунтов уволившихся сотрудников.

Раздел Global options содержит (пока?) только настройки извещений по флагам):

Email me when someone asks me to set a flag - уведомление о том, что вам адресован запрошенный флаг;
Email me when someone sets a flag I asked for - уведомление о том, что кто-то ответил (установил в + или -) на запрошенный вами флаг.

Раздел Field/recipient specific options содержит настройки для определения случаев, когда вы хотите получать письма от Bugzilla, и в каких отношениях с багом вы должны при этом находиться. Поставьте/уберите галочки в соответствующих клетках.

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

Reporter - вы указаны в поле Reporter;
Assignee - вы указаны в поле Assigned To;
QA Contact - вы указаны в поле QA Contact;
CCed - вы указаны в списке CC List.

Почту также можно фильтровать по различным заголовкам X-Bugzilla-Что-Нибудь, присутствующих во всех письмах от Bugzilla (см. [[#Дополнительные email-заголовки|Дополнительные email-заголовки).

По умолчанию Bugzilla рассылает почту вне зависимости от того, кто был автором изменения бага, и вы будете получать почту, даже если будете единственным лицом, связанным с багом. Если вы не хотите получать письма после своих изменений, поставьте галочки в строке but not when (overrides above): The change was made by me.

Если использовать более-менее вменяемый почтовый клиент, лучше разрешить получать почту и комментарии при своих изменениях, добавив правило «помечать письма содержащие 'xxx@company.com changed:' как прочтенные» (Вместо xxx@company.com разумеется, ваш логин). Установив локальный поисковик и проиндексировав почту, это даст возможность удобного полнотекстового поиска по всем комментариям связанных с вами багов.

Раздел User Watching содержит пользователей, следящих за вашим потоком извещений от Bugzilla.

Если вы введете список (разделенный запятыми) пользовательских аккаунтов (обычно совпадающих с email-адресами) в Users to watch, то будете получать копию всех писем, рассылаемых пользователю Bugzillой (с учетом настроек безопасности).

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

Не злоупотребляйте этой возможностью!

Saved searches

... добавить инфу ...

Name and password

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

Permissoins

Чисто информационная вкладка, описывающая все права пользователя в текущей инсталляции Bugzilla — какие группы продуктов доступны, может ли пользователь редактировать баги и осуществлять административные функции.

Фильтрация писем от Bugzilla

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

Заголовки — это не subject, а внутренние заголовки письма, увидеть которые можно в свойствах письма или выбрав в почтовой программе пункт View Message Headers или подобный.

Список заголовков:

X-Bugzilla-Reason - отношение получателя к упомянутому багу: Assigned To (ответственный), Reporter (создатель бага), QA Contact (тестировщик), CC List (наблюдатель), Voter (голосовал за баг);
X-Bugzilla-Watch-Reason - то же, но каждое значение означает, что получатель наблюдает за пользователем, имеющим соответствующее отношение к упомянутому багу. Плюс есть ещё одно значение — GlobalWatcher, означающее, что пользователь получает всю почту по всем багам;
X-Bugzilla-Type - new (новый баг), changed (изменение) или request (изменение флагов);
X-Bugzilla-Who - логин (то есть, e-mail адрес) изменившего баг;
X-Bugzilla-Changed-Fields - список изменённых полей упомянутого бага;
X-Bugzilla-Added-Comments - количество добавленных комментариев (0 или более).

Также есть набор заголовков, имеющих значением значение соответствующего атрибута бага:

X-Bugzilla-Classification
X-Bugzilla-Product
X-Bugzilla-Component
X-Bugzilla-Status
X-Bugzilla-Priority
X-Bugzilla-Severity
X-Bugzilla-Assigned-To
X-Bugzilla-QA-Contact
X-Bugzilla-Target-Milestone
X-Bugzilla-Keywords

Примеры:

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

Решение: Заголовок X-Bugzilla-Added-Comments равен 0 и заголовок X-Bugzilla-Changed-Fields пуст.

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

Решение: В Outlook создать правило, которое будет перемещать письма, содержащие в заголовке "X-Bugzilla-Reason: Assigned-To" или "X-Bugzilla-Reason: CC Assigned-To" или "X-Bugzilla-Type: request" или "X-Bugzilla-Reason: Reporter", в нужную папку.

Просмотр Патчей

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

Просмотр и ревизия исправлений в Bugzilla часто затруднена из-за недостатка контекста, несоответствующих форматов и других сложностей. Patch Viewer это дополнение Bugzilla, предназначенное для улучшения контекста, интеграции с Bonsai, LXR, CVS.

Patch Viewer позволяет:

Просмотр исправлений с раскраской, в режиме side-by-side, а не интерпретация сырого содержимого исправления;
Просмотр разницы между двумя исправлениями;
Получение контекстной информации об исправлении;
Удобный просмотр исправления с возможностью скрывать/раскрывать разделы;
Ссылки на разделы исправления для обсуждения или ревизии;
Ссылки на Bonsai или LXR для определения ответственности;
Создает исправления в унифицированном diff-формате.

В нашей инсталляции Bugzilla мы не используем PatchViewer, так как есть гораздо более удобная система просмотра версионных репозиториев ViewVC (см. Интеграция с системами контроля версий).

Ссылки

Bugzilla в России; Bugzilla в Википедии; Bug Tracking системы (бесплатные).

Репликация: База Знаний «Заказных Информ Систем» → «WikiHelp:Багзилла»

Статья реплицируется в Wiki4IntraNet.

Внимание! Данная статья выбрана для репликации в SMWiki.

{{#ask: ParentMenuId::Top

?HelpId

?HelpOrder

?ParentMenuId

?HelpDisplay

?HelpContent

?#=Link

sort=HelpOrder

format=template

named args=yes

template=WikiHelp/SideMenu/TopLevel

}}

Непрерывная интеграция

2013-01-15T12:36:56Z

IgorShatalkin:

Репликация: База Знаний «Заказных Информ Систем» → «Непрерывная интеграция»

Рынок ERP: рост в условиях турбулентности

2013-01-15T10:26:09Z

AlexandraVelyaninova:

Максим Михалев, наш директор по маркетингу и продажам, рассказал еженедельнику PC Week/RE о состоянии российского рынка ERP на начало 2012 года и наиболее актуальных задачах, которые решались компаниями с помощью ERP-систем в прошедшем году. Комментарии Максима опубликованы в обзоре «Рынок ERP: рост в условиях турбулентности» на сайте издания.

PC Week: Какой, по вашим оценкам, была в прошедшем году динамика российского рынка ERP в трех сегментах: крупные предприятия, предприятия среднего и малого бизнеса (СМБ) и госсектор? Что в этом отношении можно ожидать от года наступившего?

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

Всем уже очевидно, что выросшее количество каналов коммуникации с клиентом заставляет по-новому выстраивать отношения с ним. Уже невозможно игнорировать многочисленные мобильные платформы, социальные сети, разнообразные интернет-сервисы и т. д. А это, в свою очередь, новый вызов и для бизнеса, и для разработчиков ПО. В ближайшие 3–5 лет эта тенденция будет преобладать и, вполне вероятно, сформирует новые стандарты прикладного корпоративного ПО.

PC Week: Какие наиболее актуальные и востребованные заказчиками задачи решались предприятиями с помощью ERP-систем в прошедшем году? Ваш прогноз на нынешний год?

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

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

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

Летом 2011 года в магазинах торговой сети O’STIN была внедрена система «Розничный магазин Lite», разработанная CUSTIS. Новое ПО позволяет существенно упростить выбор торговых помещений и сократить затраты на автоматизацию сети в целом без ущерба для процессов продаж в магазинах и оперативного учета в центральном офисе. Это решение было запланировано еще в период активной оптимизации расходов и оказалось особенно актуально для розничной сети с большим количеством малоформатных магазинов.

PC Week: Как вы считаете, выйдут ли ERP-решения за пределы частного облака и каковы перспективы разделения ERP-функциональности в гибридных архитектурах между общедоступными и частными облаками?

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

Репликация: База Знаний «Заказных Информ Систем» → «Рынок ERP: рост в условиях турбулентности»

Облачно-ориентированная ИТ-инфраструктура: возможности и проблемы управления сервисами в облаке

2013-01-11T15:53:54Z

AlexandraVelyaninova: /* Рискуем и/или выигрываем? */

В журнале Rational Enterprise Management (№5/2012) опубликована статья ведущего системного инженера Дмитрия Морозова, посвященная созданию облачно-ориентированной ИТ-инфраструктуры. Какие требования предъявляются к ИТ-инфраструктуре со стороны бизнеса? Каковы преимущества и риски перевода ИТ-систем в облака? Когда есть смысл создавать частное облако? Об этом — в статье «Облачно-ориентированная ИТ-инфраструктура: возможности и проблемы управления сервисами в облаке» на сайте и в бумажной версии журнала.

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

Доступ запрещён

2013-01-11T12:43:50Z

127.0.0.1:

MediaWiki:Hacl permission denied

WikiHelp:UML

2013-01-09T09:58:14Z

AndreyMoiseev:

{{#set: |HelpId=UML |HelpOrder=600 |ParentMenuId=AdvancedMarkup |HelpContent=Справка:UML |HelpDisplay=Диаграммы UML }}

[Исходная статья]

Можно автоматически рисовать UML-диаграммы классов по их текстовому описанию, причём с помощью двух расширений:

PlantUML — более удобный, чем UMLGraph, по собственному языку разметки.
UMLGraph — по близкому к описанию классов на языках типа Java/С#.

PlantUML

Полная справка по языку — Media:PlantUML Language Reference Guide.pdf.

Справка по PlantUML

Синтаксис вставки — просто

<uml>
 ...код...
</uml>

Пример графа:

Разметка

<uml>
title Основной цикл — получение агрегированных проводок
 
autonumber "<b>[0]"
 
note left of МСФО: 1.1
activate МСФО
МСФО -> Система: Запрос справочников
deactivate МСФО
 
note right of Система: 2.1
activate Система
Система -> МСФО: Возврат справочников
deactivate Система
note left of МСФО: 1.2
 
activate МСФО
МСФО -> Система: Запрос используемых аналитик
deactivate МСФО
note right of Система: 2.2
activate Система
Система -> МСФО: Возврат используемых аналитик
deactivate Система
note left of МСФО: 1.3
 
activate МСФО
МСФО -> Система: Запрос выгрузки/выгрузок
deactivate МСФО
note right of Система: 2.3
activate Система
Система -> МСФО: Возврат выгрузки/выгрузок
deactivate Система
note left of МСФО: 1.4
 
activate МСФО
МСФО -> Система: Результат выгрузки/выгрузок
deactivate МСФО
activate Система
note right of Система: 2.4
</uml>

UMLGraph

Диаграммы классов

/**
* @opt nodefontcolor "blue"  
*/
class Person {
        String Name;
}
 
class Employee extends Person {}
 
class Client extends Person {}

 
class Tyre {}
class Engine {}
class Body {}
 
/**
* @composed 1 - 4 Tyre
* @composed 1 - 1 Engine
* @composed 1 - 1 Body
*/
class Car {}

/**
 * @opt shape node
 * @note Located in the
 * machine room
 * @note Sun Blade 6048
 * @depend - - - MapLocation
 * @depend - - - DataMine
 */
class Server{}
 
/** @opt shape component */
class MapLocation {}
 
/** @opt shape component */
class DataMine {}
 
/**
 * CPU-munching
 * components that must
 * run on this server
 * @opt shape note
 * @opt commentname
 * @assoc - - - MapLocation
 * @assoc - - - DataMine
 */
class munchComment {}

Большой пример

Generalisation Relationships

Advanced Relationships

Relationships Inference

Schema

Element Visibility

Association Types

Real Example (Catalina Classes)

Class Stereotypes and Tagged Values

Fonts, Colors, Global and Local Options

Еще пример

Ссылки

http://umlgraph.org Automated Drawing of UML Diagrams

Репликация: База Знаний «Заказных Информ Систем» → «WikiHelp:UML»

Статья реплицируется в Wiki4IntraNet.

{{#ask: ParentMenuId::Top

?HelpId

?HelpOrder

?ParentMenuId

?HelpDisplay

?HelpContent

?#=Link

sort=HelpOrder

format=template

named args=yes

template=WikiHelp/SideMenu/TopLevel

}}

WikiHelp:Опросы и голосования

2013-01-09T09:54:36Z

AndreyMoiseev:

{{#set: |HelpId=Polls |HelpOrder=200 |ParentMenuId=Social |HelpContent=Справка:Опросы и голосования |HelpDisplay=Опросы и голосования }}

[Исходная статья]

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

Опросы бывают следующих основных типов:

Режимы

CHECKS

Возможность отметки любого предложенного варианта (по одному разу). Пример:

<poll>
Какие программы и системы, вы используете в повседневной работе:
[[{{SITENAME}}]]
[[Bugzilla]]
[[Bonsai]]
[[TeX]]
[[CVS]]
[[Oracle]]
[[Python]]
Erwin
Open Office
</poll>

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

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

POINTS

«POINTS N» — голосование с определенным (N) количеством голосов, которых можно распределить по предложенным вариантам.

Пример:

<poll>
POINTS 7
Распределите ваши симпатии по фирмам-производителям автомобилей:
TOYOTA 
NISSAN
ALFA-ROMEO
BETA-ROMEO
GAMMA-ROMEO
OPEL
VAZ
</poll>

Распределите ваши симпатии по фирмам-производителям автомобилей:

Вы можете использовать 7 голосов.

TOYOTA
NISSAN
ALFA-ROMEO
BETA-ROMEO
GAMMA-ROMEO
OPEL
VAZ

«Ключевая» строка в этом примере, задающая нужный режим — «POINTS 7».

Можно использовать ключевую строку «ALTERNATIVE» для задания режима «POINTS 1», то есть выбора только одного варианта из предложенных.

Авторизация

Опрос можно сделать авторизованным, то есть запретить голосование анонимным пользователям, которые учитываются по IP-адресам. Для этого используется ключевая строка «AUTHORIZED». Анонимные пользователи увидят только список вариантов и строку «вы должны войти в систему, чтобы участвовать в голосовании». Зарегистрированные пользователи CustisWiki увидят форму голосования и/или результаты.

Есть ещё более жёсткий вариант, полностью скрывающий и голосование, и варианты ответов от анонимных пользователей — «AUTHORIZED_DISPLAY».

<poll>
AUTHORIZED
ALTERNATIVE
Вам нравится работать в нашей компании?
Да
Нет
</poll>

Вам нравится работать в нашей компании?

Да
Нет

Вы должны войти в систему, чтобы участвовать в этом голосовании.

Ограничение по IP-адресам

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

Работа

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

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

Конец опроса

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

Тем не менее, существует опция «END_POLL YYYY-MM-DD», где YYYY-MM-DD — дата (YYYY — год, MM — месяц, DD — день), позволяющая автоматически закончить опрос, начиная с даты YYYY-MM-DD. То есть, начиная с этой даты, все пользователи, вне зависимости от того, голосовали они или нет, увидят только результаты и не увидят формы голосования.

Скрытие результатов

Специально для спецагентов и «секретных» опросов существует опция «HIDE_RESULTS», позволяющая скрывать результаты голосования от рядовых пользователей, по крайней мере, до конца опроса. Проголосовавшие пользователи увидят только сообщение «Вы уже проголосовали, всего проголосовало столько-то человек, а результаты будут (или не будут) доступны после даты YYYY-MM-DD». Результаты не будут показаны никогда, если опрос не имеет конца, то есть, если не указана опция END_POLL. В базе данных они, естественно, будут сохранены, и могут быть извлечены оттуда любым человеком, имеющим прямой доступ к БД.

Разрешение переголосования

Чтобы разрешить отозвать свой голос и проголосовать заново, нужно добавить опцию «REVOTE», она же кому как больше нравится — ALLOW_REVOTE, ALLOW_RECALL. Если добавить эту опцию после создания опроса, могут быть потеряны ранее отданные голоса.

Нецелостный («тупой», «небезопасный») режим

Опция UNSAFE ID=УникальнаяСтрока даёт вашему голосованию идентификатор, равный этой уникальной строке, после чего в голосование можно добавлять/удалять вопросы, менять заголовок и опции. Голосовалка будет вести себя тупо — считать количества по НОМЕРАМ ответов и показывать их всегда для этого голосования. То есть если вы удалите ответ из середины, все голоса за ответы, стоящие ниже него, собьются. Также всегда любой может подсмотреть результаты небезопасного голосования, даже если они скрыты, добавив соответствующую опцию и даже не сохраняя страницу, а делая предпросмотр. В то же время путём указания UNSAFE ID=ID реального (безопасного) голосования подсмотреть его результаты невозможно.

Привязка к названию страницы

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

Открытые голосования

Иногда возникает необходимость делать открытые для всех, неанонимные, голосования — например, в опросах по реализации каких-нибудь фич. Для этого нужно указать опцию OPEN_VOTERS — тогда для тех, кто ещё не проголосовал, будет показано предупреждение о том, что их голос будет показан всем, а те, кто проголосовал, увидят имена/IP всех проголосовавших рядом с каждой опцией.

Также есть опция OPEN_RESULTS, которая совмещает форму голосования с результатами и показывает их всем, даже ещё не проголосовавшим, пользователям.

Email-оповещение

Для голосования можно указать опцию VOTES_TO_EMAIL=N (N — неотрицательное число). Если она указана, то при наборе как минимум N голосов все пользователи, следящие за страницей с голосованием (обычное вики-слежение, или «наблюдение»), будут получать результаты голосования на свои email-адреса (адреса для этого должны быть подтверждены). Смысл такого слежения — асинхронность: забросил голосовалку, следишь за страницей и ждёшь, пока начнёт работать закон больших чисел, то есть результаты голосования начнут что-то значить.

Синтаксис

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

[svg]

Внимание! Данная статья выбрана для репликации в SMWiki.

Репликация: База Знаний «Заказных Информ Систем» → «WikiHelp:Опросы и голосования»

Статья реплицируется в Wiki4IntraNet.

{{#ask: ParentMenuId::Top

?HelpId

?HelpOrder

?ParentMenuId

?HelpDisplay

?HelpContent

?#=Link

sort=HelpOrder

format=template

named args=yes

template=WikiHelp/SideMenu/TopLevel

}}

WikiHelp:RSS

2013-01-09T09:50:53Z

AndreyMoiseev:

{{#set: |HelpId=RSS |HelpOrder=200 |ParentMenuId=AdvancedOther |HelpContent=ListFeed_(расширение_MediaWiki) |HelpDisplay=RSS }}

[Исходная статья]

ListFeed — расширение MediaWiki, позволяющее генерировать простые RSS-ленты из стандартных списков MediaWiki (нумерованных «#» и маркированных «*»).

Инструкции по установке и исходные коды можно увидеть на домашней странице расширения.

С помощью этого расширения практически любой список можно превратить в RSS-ленту.

Расширение добавляет два новых тега — <listfeed> и <endlistfeed />, а также функцию парсера {{#listfeedurl:Feed Name}}, которая возвращает URL RSS-ленты, сгенерированной расширением из списка с заданным именем. Расширение позволяет легко превратить любой маркированный или нумерованный Wiki-список в RSS-ленты, которая автоматически обновляется при обновлении статьи.

Каждый элемент списка становится отдельной записью ленты.

Заголовком записи становится первая строка текста элемента списка.
Текстом записи — всё остальное, если оно присутствует, и просто весь текст элемента списка, если нет.
Дата записи разбирается в соответствии с заданным регулярным выражением (см. ниже) и вырезается из заголовка.
Ссылкой записи становится первая ссылка в тексте, за исключением даты, так как в дате может присутствовать ссылка на автора, например, если используются стандартные подписи (~~~~). Если ссылок в тексте нет, используется ссылка на статью с уникальным якорем (anchor) для идентификации записи.
Автором записи становится первая ссылка в пространство имён [[Участник:]] из текста элемента списка, либо автор последней ревизии статьи.

Ленты идентифицируются по именам (<listfeed name="ИМЯ_ЛЕНТЫ">) и помещаются в один каталог, поэтому в пределах одной Wiki-системы две ленты с одинаковыми именами будут перезаписывать друг друга при каждом обновлении страницы. Описанием ленты служит любой Wiki-код, заключённый в тег <listfeed> — он преобразуется в HTML и включается в RSS-элемент <about>.

Чтобы начать использовать ListFeed, добавьте тег <listfeed> перед вашим списком:

<listfeed name="ИМЯ_ЛЕНТЫ" [ОПЦИИ]>
ОПИСАНИЕ_ЛЕНТЫ
</listfeed>

И тег <endlistfeed> после списка:

<endlistfeed />

Чтобы вставить ссылку на ленту в текст статьи, нужно использовать функцию парсера:

{{#listfeedurl:ИМЯ_ЛЕНТЫ}}

На данный момент доступны две опции, связанные с разбором дат элементов ленты.

Опция date

<listfeed date="ВЫРАЖЕНИЕ">.

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

^(?:[^:]+|<[^<>]*>)*%H:%M(?::%S)?,\s*%d\s+%b\s+%Y(?:\s*\(UTC\))?(?:\s*:?)

ВЫРАЖЕНИЕ похоже на обычные Perl-совместимые регулярные выражения, однако, кроме стандартных инструкций, включаемых в регулярные выражения, оно также может содержать большинство strftime(3)-подобных подстановок (см. ниже полный список поддерживаемых подстановок) и, таким образом, является как бы «обратной функцией» к strftime(3).

На данный момент поддерживаются следующие подстановки strftime:

%Y	год (4 цифры)
%y	год (2 цифры)
%C	век (2 цифры), может использоваться вместе с %y, по умолчанию выбирается текущий век, если выделенный год и текущий год лежат в одной половине века, и предыдущий/следующий, если в разных
%m	месяц (2 цифры, от 01 до 12)
%b / %B	имя месяца — либо полное (Январь, Января, January), либо сокращённое (Янв, Jan)
%d	день месяца (2 цифры)
%e	день месяца (1 или 2 цифры)
%H / %h	часы
%M	минуты
%S	секунды
%s	UNIX время — количество секунд, прошедших с начала Эпохи UNIX (1970-01-01 00:00:00)
%%	символ %

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

Опция headingdate

<listfeed headingdate="ВЫРАЖЕНИЕ">.

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

<listfeed name="News of extension" date="^%b %d:\s*" headingdate="%Y" />
= 2010 news =
* Jan 13: New version of ListFeed.
* Jan 01: Happy New Year!
= 2009 news =
* Dec 17: ...
* ...
<endlistfeed />

В данном случае даты не могут быть взяты целиком из каждого элемента, однако, год каждой даты со всей очевидностью присутствует в заголовке, поэтому и требуется разбирать его тоже. Для приведённого примера, выражение headingdate="%Y" абсолютно корректно.

Пример

<listfeed name="Новости CustisWiki">
Новости CustisWiki - важные статьи, голосования, новости системы
</listfeed>
* [[Участник:EvgeniaUdalova|Евгения Удалова]] 09:00, 5 октября 2009: Опрос ДМС 2009 завершён! Результаты можно посмотреть  [[Опрос_ДМС_2009| здесь]].
* [[Участник:MaksTsepkov|Макс Цепков]] 05:38, 26 сентября 2009 (UTC) Чтобы долго не искать - ссылки на блоги и rss:
*: [[Blog:Володя Рахтеенко]]
*: [[Blog:TechTools/Новости наших Wiki-систем: Блоги, черновики, интеграция с Subversion]] [[FeedOnFeeds]]
*: [[Служебная:Wikilog]] - общая лента блогов и замечание: когда ищите по wiki из панели слева, поиск в блогах отключен, надо включать галочку на результатах поиска.
<endlistfeed />

Репликация: База Знаний «Заказных Информ Систем» → «WikiHelp:RSS»

Статья реплицируется в Wiki4IntraNet.

{{#ask: ParentMenuId::Top

?HelpId

?HelpOrder

?ParentMenuId

?HelpDisplay

?HelpContent

?#=Link

sort=HelpOrder

format=template

named args=yes

template=WikiHelp/SideMenu/TopLevel

}}

WikiHelp:Быстрое создание статей по шаблону

2013-01-09T08:40:23Z

AndreyMoiseev:

{{#set: |HelpId=ArticleByTemplate |HelpOrder=100 |ParentMenuId=Templates |HelpContent=Быстрое создание статей по шаблону |HelpDisplay=Создание статьи по шаблону }}

[Исходная статья]

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

Можно больше — заполнить создаваемую статью не только «инструкцией о категории» но и любым произвольным блоком текста (шаблоном отчета, тест-кейса и т.п.). Для этого, для категории «XXX» нужно завести статью «Шаблон:Категория:XXX», и тогда ее содержимое будет подставляться при действии

«Создать статью в данной категории».

См. например, Категория:Тест-кейсы_(Bugzilla).

Репликация: База Знаний «Заказных Информ Систем» → «WikiHelp:Быстрое создание статей по шаблону»

{{#ask: ParentMenuId::Top

?HelpId

?HelpOrder

?ParentMenuId

?HelpDisplay

?HelpContent

?#=Link

sort=HelpOrder

format=template

named args=yes

template=WikiHelp/SideMenu/TopLevel

}}

WikiHelp:Магические слова

2013-01-09T08:37:49Z

AndreyMoiseev:

{{#set: |HelpId=MagicWords |HelpOrder=1000 |ParentMenuId=AdvancedMarkup |HelpContent=Справка:Магические слова |HelpDisplay=Магические слова }}

[Исходная статья]

Приведет список магических слов, т. е. специальных подстановок, или модификаторов поведения CustisWiki

#redirect

Перенаправление на другую страницу — См. Help:Перенаправления.

NOTOC

Подавляет генерацию «содержания».

FORCETOC

Форсирует генерацию «содержания».

NOEDITSECTION

Скрыть ссылки на редактирование разделов.

START

Ничего не делает.

CURRENTMONTH

Переменная:

CURRENTMONTHNAME

Переменная:

апрель

CURRENTDAY

Переменная:

CURRENTDAYNAME

Переменная:

пятница

CURRENTYEAR

Переменная:

2026

CURRENTTIME

Переменная:

21:40

NUMBEROFARTICLES

Переменная:

1489

CURRENTMONTHNAMEGEN

Переменная:

апреля

PAGENAME

Переменная:

WikiHelp:Магические слова

PAGENAMEE

Переменная:

WikiHelp:%D0%9C%D0%B0%D0%B3%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B5_%D1%81%D0%BB%D0%BE%D0%B2%D0%B0

NAMESPACE

Переменная:

MSG:

Модификатор шаблонных подстановок — переданное имя считается шаблоном, даже, если есть такое же магическое слово. См. также Help:Шаблоны.

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

SUBST:

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

Bug:{{{1}}}

См. также Help:Шаблоны.

MSGNW:

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

{{MSGNW:Bug}}

даст <noinclude> <templatedata> { "params": { "1": { "label": "Номер бага", "required": true, "suggested": true }, "2": { "label": "Заголовок" } }, "description": "Ссылка на баг в Bugzilla" } </templatedata> Использовать так: <pre> {{Bug|Номер бага|(опционально) заголовок}} </pre> ----- См. также: * [[:Template:Attachment|Ссылка на вложение]] * [[:Template:BugInfo|Маленький информер по багу]] * [[:Template:BugInformer|Большой информер по багу]] * [[:Template:BugComment|Ссылка на комментарий в баге в Bugzilla]] * [[:Template:Bz-embed|Встраивание списка багов из Bugzilla (с учётом прав доступа)]] {{replicate-from-custiswiki-to-all}}</noinclude><includeonly>[http://bugs.office.custis.ru/bugs/show_bug.cgi?id={{{1|}}} {{#if:{{{2|}}}|{{{2}}}|Bug:{{{1|}}}}}]</includeonly>

См. также Help:Шаблоны.

END

Включить в текст статьи завершающие ее пустые (состоящие из пробелов или табуляций) строки.

thumbnail

Модификатор картинок — см. Help:Изображения.

right

Модификатор картинок — см. Help:Изображения.

left

Модификатор картинок — см. Help:Изображения.

none

Модификатор картинок — см. Help:Изображения.

27px

Модификатор картинок — см. Help:Изображения.

center

Модификатор картинок — см. Help:Изображения.

framed

Модификатор картинок — см. Help:Изображения.

SITENAME

Переменная:

CustisWiki

NS:

Специальный шаблон: подставляет имя неймспейса по его номеру.

{{NS:1}}
{{NS:4}}
{{NS:8}}

Обсуждение CustisWiki MediaWiki

LOCALURL:

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

{{localurl:Help:Магические слова|section=0}}

дает /index.php?title=%D0%A1%D0%BF%D1%80%D0%B0%D0%B2%D0%BA%D0%B0:%D0%9C%D0%B0%D0%B3%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B5_%D1%81%D0%BB%D0%BE%D0%B2%D0%B0&section=0

LOCALURLE:

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

{{localurl:Help:Магические слова|section=0}}

дает /index.php?title=%D0%A1%D0%BF%D1%80%D0%B0%D0%B2%D0%BA%D0%B0:%D0%9C%D0%B0%D0%B3%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B5_%D1%81%D0%BB%D0%BE%D0%B2%D0%B0&section=0

SERVER

Переменная:

https://lib.custis.ru

CURRENTWEEK

Переменная:

CURRENTDOW

Переменная:

<enableheadshift>

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

Репликация: База Знаний «Заказных Информ Систем» → «WikiHelp:Магические слова»

Внимание! Данная статья выбрана для репликации в SMWiki.

Статья реплицируется в Wiki4IntraNet.

{{#ask: ParentMenuId::Top

?HelpId

?HelpOrder

?ParentMenuId

?HelpDisplay

?HelpContent

?#=Link

sort=HelpOrder

format=template

named args=yes

template=WikiHelp/SideMenu/TopLevel

}}

WikiHelp:Шаблоны

2013-01-09T08:37:00Z

AndreyMoiseev:

{{#set: |HelpId=Templates |HelpOrder=800 |ParentMenuId=AdvancedMarkup |HelpContent=Справка:Шаблоны |HelpDisplay=Шаблоны }}

[Исходная статья]

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

Общая информация

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

Для того, чтобы включить статью «Template:name», нужно использовать следующий синтаксис (так называемый тэг шаблона) {{name}}. Тогда при показе статьи будет подставлено содержимое ссылаемого шаблона. Терминологически, этот процесс можно также называть

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

Если страница «Template:name» еще не существует, то {{name}} будет работать как [[Template:name]], т. е. как ссылка на несуществующую статью, которую можно редактировать. Таким образом, шаблоны также удобно заводить, сначала сделав на него ссылку, а затем проследовав по ней.

Если статья name уже существует в обычном (не шаблонном) пространстве имен, или начинается с двоеточия (что означает ссылку на основное пространство имен), то ссылка не будет автоматически направлятся в шаблонное пространство имен «Template:». Таким образом, любую страницу можно использовать как шаблон. (Примечание: если вызывать так картинку или категорию — то будет подставлена описательная часть картинки и категории соответственно). Таким образом удобно

экспериментировать с шаблонами (не залезая в пространство шаблонов);
«вытаскивать» подписи и описания картинок;
изготавливать специальные составные статьи (например для печати).

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

Возможно также рекурсивное включение.

Переменные шаблона вычисляются после вставки шаблона в «вызывающую» статью, т. е. если в шаблоне содержится подстановка {{PAGENAME}}, то она будет развернута в имя вызывающей статьи, а не имя шаблона.

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

Параметры

Параметры шаблона могут быть поименованные или пронумерованные. Синтаксис использования может быть

{{templatename|parname1=parvalue1|parname2=parvalue2}}, тогда в теле шаблона надо ссылаться на {{{parname}}};
{{templatename|parvalue1|parvalue2}} тогда в теле шаблона нужно использовать {{{1}}}, {{{2}}}.

Лишние (не используемые в теле шаблона) параметры игнорируются. Имена параметров чувствительны к регистру, пробелы, подчеркивание и остальные символы не из набора [a-z\-A-Z0-9] недопустимы.

Обратите внимание на тройные фигурные скобки при использовании параметров!

Т.е. механизм шаблонов выполняет два типа подстановок:

вызов шаблона (двойные фигурные скобки) заменяется содержимым шаблона;
параметры шаблона (тройные фигурные скобки) заменяются параметрами шаблона.

Параметром шаблона может быть ссылка на другую статью. Пусть например у нас есть Шаблон:

   Начало {{{1}}} Конец.

Тогда

   {{Шаблон| [[Main_Page|Главная страница]]}}

будет развернуто в

Начало Главная страница Конец.

Если какой-то параметр «someparameter» не задан, то он остается нераскрытым текстом {{{someparameter}}}, что позволит раскрыть его, если вызвавшая шаблон статья, также включается куда-то, где этот параметр задан.

Заметим, что вызов {{Шаблон||a}} делает первый параметр определенным, но равным пустой строке. Если нужно задать второй параметр, не определяя первый, то нужно использовать вызов {{Шаблон||2=a}}. Этот синтаксис нужно использовать также, когда параметр вызова содержит знак "=", например "a=b", т.е. {{Шаблон|a=b|c}}, не определит параметр "1", зато определит параметр "a", зато {{Шаблон|1=a=b|2=c}} сделает все как надо.

Просмотр содержимого шаблона

Чтобы правильно увидеть содержимое шаблона, нужно смотреть на шаблон в режиме редактирования, т. к. некоторые подстановки, типа {{PAGENAME}}, могут раскрыться.

msgnw

Для показа содержимого шаблона (без wiki-интерпретации) можно использовать кодовый «волшебный» префикс u «msgnw:». Т.е. {{en}} и {{msgnw:en}} будут показаны как Шаблон:En и [[:Шаблон:En]] соответственно.

Ссылка на редактирование шаблона

«Редактирующая» ссылка на каждой странице-статье не позволяет редактировать текст используемого шаблона, а иногда желательно иметь такую ссылку (приглашающую поправить шаблон, например, если шаблон еще не устоялся, или если его содержимое может часто изменяться). Такую ссылку можно «зашить» внутрь самого шаблона, даже более того, сделать шаблоном, который можно использовать внутри других шаблонов. См. template:edit.

Ограничения и возможности

Использование вложенных двойных или тройных фигурных скобок внутри двойных вложенных скобок

Не получиться вызывать шаблоны в зависимости от содержимого других шаблонов. Допустим, у нас есть шаблон «tctc» с содержимым «tc», и шаблон «tc» с содержимым «Ура».

Тогда вызов {{{{tctc}}}} даст текст {{{{tctc}}}}, а не «Ура».

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

Тэг категории в шаблоне. Проблема с кэшированием

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

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

Кэширование

Правка шаблона автоматически сбрасывает кэширование всех статей, напрямую использующих этот шаблон. Однако в случае с косвенными зависимостями (шаблоны зависящие от параметров и т. п.), внутренний кэш системы не сбрасывается и стандартный «Refresh» броузера может не помочь. В таких случаях используйте «action=purge», т. е. вызывайте URL типа https://lib.custis.ru/index.php?title=CustisWiki&action=purge

subst

Используя «subst:» после двойных фигурных скобок заставляет выполнять подстановку текста шаблона или даже переменной в момент сохранения ссылающейся страницы.

Например «timestamp»:

{{subst:CURRENTDAY}} {{subst:CURRENTMONTHNAME}} {{subst:CURRENTYEAR}}, {{subst:CURRENTTIME}} (UTC)

подставится при сохранении, как:

3 March 2005, 16:56 (UTC)

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

Используйте {{..}}, затем, в окне «preview», вытащите результат и замените исходные {{..}}.
Аналогично можно использовать msgnw.

Перенаправления

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

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

Заголовок страницы-результата есть имя исходной страницы, а не включаемой страницы.
Вся функциональность, (редактирование, обсуждение, watch-list, …) относится к включающей странице, и ничего (если не смотреть код) не связывает ее с включаемой страницей.
Включающая страница лежит в тех же категориях, что и включаемая.
Работают «двойные перенаправления» основанные на включении.

Ссылки на шаблон

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

История изменений для страниц содержащих шаблоны

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

Функции парсера

В CustisWiki установлено расширение ParserFunctions, позволяющее выполнить нетривиальное препроцессирование разметки.

Более подробно см. RuPedia:Википедия:Функции парсера.

Ссылки

Наши Шаблоны

<noinclude> и <includeonly>

Текст между <noinclude> и </noinclude> включается только когда шаблон не включен в статью. Наоборот, includeonly работает только когда шаблон включен в другую статью. Применение - категории, распространяющиеся только на шаблон или только на его включение; оглавление и титульный лист, которые должно уйти при включении во композитную статью и т.п.

Репликация: База Знаний «Заказных Информ Систем» → «WikiHelp:Шаблоны»

Статья реплицируется в Wiki4IntraNet.

{{#ask: ParentMenuId::Top

?HelpId

?HelpOrder

?ParentMenuId

?HelpDisplay

?HelpContent

?#=Link

sort=HelpOrder

format=template

named args=yes

template=WikiHelp/SideMenu/TopLevel

}}

WikiHelp:Диаграммы

2013-01-09T08:30:31Z

AndreyMoiseev:

{{#set: |HelpId=BarChart |HelpOrder=700 |ParentMenuId=AdvancedMarkup |HelpContent=Справка:Ленточная диаграмма |HelpDisplay=Ленточные диаграммы }}

[Исходная статья]

Ленточная диаграмма (horizontal bar chart) позволяет отобразить множество дискретных данных вида (категория, число) в виде прямоугольников, ширина которых одинакова, а длина каждого прямоугольника пропорциональна заданному значению для этой категории. Например, таким образом удобно показывать дискретные распределения. В CustisWiki можно легко включать ленточные диаграммы, используя тэг «hbarchart»:

 «Готовы ли Вы приобрести мобильный телефон отечественной сборки?»
 <hbarchart>
 Нет 4873
 Да 1970
 затрудняюсь ответить 1286
 это зависит от того, где его будут собирать 688
 </hbarchart>

«Готовы ли Вы приобрести мобильный телефон отечественной сборки?»

Нет

4,873

55%

Да

1,971

22%

затрудняюсь ответить

1,287

15%

это зависит от того, где его будут собирать

681

Аналогично, можно использовать вертикальный график — столбиковую диаграмму (vertical bar chart). Для этого используется тег «vbarchart»:

«Количество новорожденных в роддоме города N.»

11%

12%

13%

55%

1,523

1,985

2,123

2,345

9,876

2003

2004

2005

2006

2007

Внимание! Данная статья выбрана для репликации в SMWiki.

Репликация: База Знаний «Заказных Информ Систем» → «WikiHelp:Диаграммы»

{{#ask: ParentMenuId::Top

?HelpId

?HelpOrder

?ParentMenuId

?HelpDisplay

?HelpContent

?#=Link

sort=HelpOrder

format=template

named args=yes

template=WikiHelp/SideMenu/TopLevel

}}

WikiHelp:Графики

2013-01-09T08:27:00Z

AndreyMoiseev:

{{#set: |HelpId=Plots |HelpOrder=300 |ParentMenuId=AdvancedMarkup |HelpContent=Gnuplot |HelpDisplay=Графики функций }}

[Исходная статья]

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

Быстрый старт

Для того, чтобы нарисовать график в CustisWiki, достаточно указать набор команд в тэгах <plot>...</plot>. Основные команды состоят из задания области определения функции (для одномерных графиков это переменная «x», для двухмерных «x», «y»), и команды отрисовки одномерной или двухмерной функции, заданной в символьном виде. Синтаксис функции интуитивно понятен, «+», «-», «*», «/» обозначают стандартные арифметические операторы (умножение должно быть явным, никаких математических сокращений типа «3x» и т. п.), «**» означает возведение в степень, скобки "(", «)» используются для задания приоритета.

 <plot>
 set xrange [-5:+5]
 plot 3*x**4 + 4*x - 2/3
 </plot>

gnuplot> set encoding utf8

                     ^
        line 0: expecting one of 'default', 'iso_8859_1', 'iso_8859_2', 'iso_8859_15', 'cp437', 'cp850', 'cp852', 'koi8r' or 'koi8u'

Could not find/open font when opening font Arial, using default

Кроме операторов, есть набор стандартных математических функций:

Тригонометрические функции sin, cos, tan, константа pi, и им обратные asin, acos, atan.
Гиперболические функции sinh, cosh, tanh.
Экспонента exp и натуральный и десятичный логарифмы: log и log10 соответственно.

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

 <plot>
 set xrange [0:+10]
 plot 3*log(x), 5*sin(x)
 </plot>

gnuplot> set encoding utf8

                     ^
        line 0: expecting one of 'default', 'iso_8859_1', 'iso_8859_2', 'iso_8859_15', 'cp437', 'cp850', 'cp852', 'koi8r' or 'koi8u'

Could not find/open font when opening font Arial, using default

Трехмерные графики

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

 <plot>
 set xrange [-10:+10]
 set yrange [-10:+10]
 splot -x**3-y
 </plot>

gnuplot> set encoding utf8

                     ^
        line 0: expecting one of 'default', 'iso_8859_1', 'iso_8859_2', 'iso_8859_15', 'cp437', 'cp850', 'cp852', 'koi8r' or 'koi8u'

Could not find/open font when opening font Arial, using default

Графики дискретных величин

gnuplot> set encoding utf8

                     ^
        line 0: expecting one of 'default', 'iso_8859_1', 'iso_8859_2', 'iso_8859_15', 'cp437', 'cp850', 'cp852', 'koi8r' or 'koi8u'

Could not find/open font when opening font Arial, using default

Продвинутым пользователям

Gnuplot:Краткое введение

Cсылки

«WikiHelp:Графики» в Википедии

Домашная страница проекта: http://www.gnuplot.info/
Введение в Gnuplot (на английском языке): http://www.cs.uni.edu/Help/gnuplot/
Онлайн-документация: http://gnuplot.sourceforge.net/docs/gnuplot.html#plot

Репликация: База Знаний «Заказных Информ Систем» → «WikiHelp:Графики»

{{#ask: ParentMenuId::Top

?HelpId

?HelpOrder

?ParentMenuId

?HelpDisplay

?HelpContent

?#=Link

sort=HelpOrder

format=template

named args=yes

template=WikiHelp/SideMenu/TopLevel

}}

WikiHelp:Графы

2013-01-09T08:25:05Z

AndreyMoiseev:

{{#set: |HelpId=Graphs |HelpOrder=200 |ParentMenuId=AdvancedMarkup |HelpContent=Graphviz |HelpDisplay=Графы }}

[Исходная статья]

Graphviz — это разработанный специалистами лаборатории AT&T пакет утилит по автоматической визуализации графов, заданных в виде текстового описания. Пакет распространяется с открытыми исходными файлами и работает на всех операционных системах, включая Windows, Linux/Unix, Mac OS. Самой интересной программой пакета является «dot», автоматический визуализатор направленных графов, который принимает на вход текстовый файл со структурой графа, а на выходе формирует граф в виде графического, векторного или текстового файла.

Быстрый старт

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

<graph>
 digraph G{ 
  Рождение->Юность->Зрелость->Старость->Смерть;
  Юность->Смерть;
  Зрелость->Смерть;
 }
 </graph>

на выходе будет

[svg]

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

Чтобы использовать «dot»-графы в CustisWiki, используйте следующий синтаксис:

<graph>
digraph G{ 
  Рождение->Юность->Зрелость->Старость->Смерть;
  Юность->Смерть;
  Зрелость->Смерть;
 }
 </graph>

Если у вас узлы поименованы словосочетаниями, заключите их в кавычки, т. е.

<graph>
digraph G{
  "Полет фантазии"->"Расход горючего";
 }
 </graph>

Поздравляем! Теперь вы способны рисовать графы в CustisWiki. Остальной текст будет посвящен некоторым тонкостям использования Graphviz.

Внешний вид графа

«Dot» позволяет изменять внешний вид графа. Например, можно изменять форму фигур (прямоугольники, овалы, круги, параллелограммы, многоугольники), цвет и шрифт текста, цвет фона фигур, стиль стрелок и рамок фигур, подписи стрелок и т. д. Итак, основные объектами являются узлы («node») и ребра («edge»). Для того, чтобы настроить свойства всех узлов или ребер нужно вначале использовать команды

node[свойство1="значение1",свойство2="значение2",...]
edge[свойство1="значение1",свойство2="значение2",...]

Также (в квадратных скобках после описания объекта) можно изменять настройки конкретного узла или ребра. Параметры графа, просто задаются в виде параметр=значение. Полезно запомнить параметр «rankdir», он может быть «TB» (top->bottom, параметр по умолчанию), или «LR» (left->right), и определяет, сверху-вниз, или справа-налево, нужно располагать узлы графа. Вот пестрый пример:

digraph G{
 rankdir=LR;
 node[color="red",fontsize=14];
 edge[color="darkgreen",fontcolor="blue",fontsize=12];
 OPEN[shape="rectangle",style="filled",fillcolor="lightgrey"];
 CLOSED[shape="octagon",label="Финиш"];
 VERIFIED[shape="rectangle",style="rounded"];
 OPEN->RESOLVED->VERIFIED->CLOSED;
 OPEN->CLOSED[style="bold"];
 VERIFIED->OPEN[label="обнаружены ошибки",style="dashed",arrowhead="dot"];
}

на выходе будет

[svg]

Если предполагается, что граф будут не только просматривать через IE, но и печатать, то необходимо установить ширину картинки, иначе при печати картинка будет обрезана. Для этого следует задать внутри описания

size="6.7,15";

Существенна только первая цифра. Число 6.7 подобрано эмпирически, оно обеспечивает печать полной картинки при настройках IE по умолчанию.

Уровни в графах

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

  { rank = same; "элемент уровня"; "элемент для привязки 1"; "элемент для привязки 2"; ..}

Например, при использовании следующей конструкции:

<graph>
 digraph G{
   node[fontsize=9];
   { /* шкала месяцев*/
     node[shape=plaintext]; /* что бы не было видно рамок */
     edge[color=white] /* что бы не было видно стрелок */
     "март" ->  "июнь" -> "сентябрь" -> "декабрь"; 
   }
   { rank = same; "март"; "весна"; "a"; }
   { rank = same; "июнь"; "лето";}
   { rank = same; "сентябрь"; "осень"; "d"; }
   { rank = same; "декабрь"; "зима"; "e"}
   "весна" -> "лето" -> "осень" -> "зима" -> "весна"
   "a" -> "b" -> "c" -> "d" -> "e" ;
 }
 </graph>

на выходе получается: [svg]

Многосекционный узлы

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

Для включения режима многосекционности устанавливается атрибут узла shape.

shape=record;

Секции описываются в атрибуте label узла, с помощью разделителя «|». Для именования секции ее имя указывается в <>. При описание ребра, исходящего или входящего в секцию, секция именуется следующим образом:

элемент:<имя_секции>

Например, из такого описания:

digraph structs {
  rankdir=HR;
  first [shape=record,label="  x1\n all | { x21 | <f0> x22| x23} | x3" ];
  second [shape=record,label=" x22_1 | x22_2 | x22_3"];
  first:<f0> -> second;
}

Получается следующее:

[svg]

Гиперссылки на графах

Можно использовать атрибут «URL», задавая относительные или абсолютные гиперссылки для узлов и ребер. Например

<graph>
 digraph G {
     rankdir=LR;
            SGML [URL="SGML"];
            HTML [URL="HTML"];
            XML [URL="XML"];
            XHTML [URL="http://www.w3schools.com/xhtml/"];
    SGML->HTML;
    SGML->XML;
    HTML->XHTML;
    XML->XHTML;
    SGML->XHTML[color="red",fontcolor="blue",label="ссылка на Google",URL="http://www.google.com"];
 }
 </graph>

[svg]

Кластеры в графах

Программа «Dot» позволяет объединять узлы графов в кластеры для подчеркивания общности.

Кластер описывается следующим синтаксисом:

subgraph имя{
свойство1 = "значение1",свойство2="значение2",...
узел1; 
узел2;
...
}

При этом имя подграфа должно начинаться с префикса cluster, иначе подграф не позволяет себя отобразить на экран(раскраска, контур, подпись, .. ).

Например:

 digraph G {
  rankdir=LR;
  subgraph cluster0 {
       node [style=filled,color=white];
       style=filled;
       color=lightgrey;
       a0;
       a1
       label = "process #1";
  }
  subgraph cluster1 {
       node [style=filled];
       b0;
       label = "process #2";
       color=blue
  }
  start -> a0;
  start -> b0;
  a0 -> a1 -> end;
  b0 -> end;
 }

[svg]

Цвета

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

Набор палитр Brewer-а, что удобно при автоматической генерации схем — задаваемые числовым индексом цвета в более-менее вменяемой палитре.

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

color="#FF0EDD"

и выбирать цвета из палитры, например, на http://www.colorpicker.com/

Цвета и черно-белая печать

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

[svg]

Формы вершин

Перечислим палитру возможных форм вершин (узлов).

[svg]

Окончания ребер

Можно задавать стиль офомления начала («arrowtail») и конца («arrowhead») дуг (ребер):

Чтобы работал arrowtail, для ребра нужно указать свойство dir=both или dir=back.

[svg]

Неориентированные графы

Наряду с рисованием ориентированных графов, есть несколько методов для автоматического рисования неориентированных графов (будем рассматривать их на примере несложной ER-диаграммы).

В отличие от автоматического рисования направленных («directed») графов, основанных на ранговой модели, есть несколько подходов к раскладке ненаправленных графов.

Graph

Ненаправленный граф можно нарисовать с помощью рангового подхода (несмотря на ненаправленность ребер) — будет использоваться программа «dot». Как это будет выглядеть для простой ER-диаграммы, можно увидеть ниже. [svg]

Очевидна неоптимальность такого подхода для неориентированных графов.

Neato

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

[svg]

FDP

Метод «fdp» по сути, близок к методу «neato», и использует другую разновидность «энергетического» («spring») подхода. Также рекомендуется для ненаправленных графов общего типа.

[svg]

Twopi

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

[svg]

CIRCO

Метод «circo» использует «circular layout». Выделяются двусвязные компоненты (каждая вершина имеет по крайней мере два ребра) и вершины этих компонент рисуются на некотором круге. «Дополнительные» ребра рисуются радиально и далее процесс повторяется. Пересечение ребер внутри круга минимизируется максимально возможным выносом ребер с круга за его периметр.

[svg]

Версии для печати

Как известно, трудно добиться хорошего результата одновременно на экране и на принтере, в силу разных разрешений. Картинка экранного разрешения будет плохо (с «зазубринами») выглядеть на принтере, а картинка печатного разрешения, будет очень плохо выглядеть на экране (к сожалению, современные броузеры выполняют очень примитивный ресайзинг картинок при показе), и будет достаточно много «весить». Все соображения о печатных картинках также относятся к случаю, когда вы переносите (например, копируя вебстраницу из броузера через клипборд) содержимое MediaWiki-статьи в MS Word или другой текстовый редактор. Для такого, «печатного» случая (т. е. если у вас не примитивные графы, и вы собираетесь их печатать или переносить в другую систему верстки), мы сделали «печатную версию» всех перечисленных графов, с разрешением около 200 DPI. Для этого надо использовать те же самые тэги с постфиксом «-print», например «graph-print»,«neato-print», и т.п.:

[svg]

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

Ссылки и дополнительная документация

Онлайн-документация, +последние изменения, FAQ и прочее можно найти на домашней странице пакета http://www.graphviz.org/Documentation.php

Репликация: База Знаний «Заказных Информ Систем» → «WikiHelp:Графы»

{{#ask: ParentMenuId::Top

?HelpId

?HelpOrder

?ParentMenuId

?HelpDisplay

?HelpContent

?#=Link

sort=HelpOrder

format=template

named args=yes

template=WikiHelp/SideMenu/TopLevel

}}

WikiHelp:Изображения

2013-01-09T08:16:25Z

AndreyMoiseev:

{{#set: |HelpId=Images |HelpOrder=100 |ParentMenuId=Media |HelpContent=Справка:Изображения |HelpDisplay=Изображения }}

[Исходная статья]

Загрузка файла изображения в CustisWiki

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

Для переименования изображения выберите вкладку «переименовать» вверху страницы.
Для удаления — «удалить».
При загрузке другого изображения (или того же, но более высокого качества) под тем же названием старое изображение не стирается, а сохраняется в «Истории», как и любой файл;
В названии файлов различается написание «ПРОПИСНЫМИ» и «строчными» буквами.
Так как пространство имен для всех изображений одно, желательно давать файлам дескриптивные (пусть и длинные) названия. То есть картинка с названием Image1.jpg не является дескриптивной, и повышает вероятность того, что в результате опечатки будет включена другая картинка и т. п.

Загрузка и удаление файлов отражаются в Special:Newimages. Просмотреть ранее загруженные файлы можно в списке загруженных изображений либо через категории изображений.

Описание изображения

После загрузки файла изображения появится ссылка на страницу описания этого изображения, которую желательно заполнить.

Вставка изображения в статью

Первоначальных размеров

Чтобы вставить загруженное изображение в статью, достаточно указать ссылку на него: [[Image:Файл]] или [[File:Файл]]. Изображение будет воспроизводится слева в полную величину, а текст начинаться ниже его. Если вы хотите дать только ссылку на изображение, не воспроизводя его, поставьте двоеточие перед словом «Image»: [[:Image:Файл]]. Щелчок на такую надпись загружает страницу самого изображения. Вот попробуйте: Image:2004-01-23-twins-computer-01-tmb.jpg.

С альтернативным текстом.

Чтобы в браузерах с отключённой функцией показа графики показывалось пояснение к изображению, его вписывают в конце после вертикальной чёрточки: [[Image: Файл|Альтернативный текст для изображений]]. При наведении курсора мыши на пустующее место эта подпись всплывает.

Пояснительная подпись.

Пояснительная подпись

Чтобы сделать поясняющую подпись, используется атрибут «frame»: [[Image:2004-01-23-twins-computer-01-tmb.jpg|frame|Пояснительная подпись]]
Он заключает изображение в рамку и смещает изображение вправо. В области «Пояснительная подпись» можно применять wiki-разметку.

Уменьшение размеров

Пояснительная подпись

[[Image:2004-01-23-twins-computer-01-tmb.jpg|thumb|Пояснительная подпись]]
Атрибуты «thumb» или «thumbnail», вставленные между именем файла и пояснительной подписью, уменьшают ширину изображения до 180рх (высота изменяется пропорционально), прижимают его вправо и помещают в рамку. Кроме того, справа от пояснительной подписи появляется значок, щёлкнув на который можно перейти на страницу изображения и посмотреть его в натуральную величину. Текст располагается слева от изображения.

Пояснительная подпись

[[Image:2004-01-23-twins-computer-01-tmb.jpg|thumb|100px|Пояснительная подпись]]
Для получения изображения заданной ширины (высота изменяется пропорционально), запишите её в пикселах (рх) за атрибутом «thumb». При этом не забывайте о соотношении изображения с текстом. Если статья небольшая, то можно подобрать высоту изображения так, чтобы текст полностью охватывал его. В длинной статье не стоит делать изображения маленькими, иначе они «утонут» в тексте.

Расположение на странице

Смещение вправо.

Кроме рассмотренных выше атрибутов «frame», «class=rimage», «thumb» и «thumbnail», прижать изображение вправо можно html-атрибутом «right»:

[[Image:2004-01-23-twins-computer-01-tmb.jpg|right|]]

Текст, помещённый ниже, обтекает его слева. Не забудьте поставить вертикальную чёрточку «|» в конце. Это нужно для того, чтобы слово не воспринималось как альтернативный текст для изображения.

Смещение влево.

Чтобы прижать изображение к левому краю страницы, даже при наличии вышеперечисленных атрибутов, используйте html-атрибут «left» или «none».

Расположение по центру.

Для расположения изображения в центре странице используется html-атрибут «center»:

<center>[[Image:2004-01-23-twins-computer-01-tmb.jpg|thumb|Пояснительная подпись]]</center>

Пояснительная подпись

Пример

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

Мои фото
Фото1		Фото2

Исходный текст для этой таблицы такой:

<center>
{| border="1" style="border-collapse:collapse"
!colspan="4"|Мои фото
|-
|Фото1|| [[Image:Stas-fomin.jpg]]
|Фото2|| [[Image:Stas-fomin.jpg]]
|}
</center>

Видео

Совершенно аналогично операциям с картинками (загрузка, включение через [[Image:…]]), можно загружать и видео, в FLV-формате с кодеками FLV видео + MP3 аудио, или в MP4-формате (контейнере) с кодеками H.264 видео + AAC аудио.

FLV — проще (не нужно делать qt-faststart), но MP4 — качественнее, потому что кодек H.264 лучше, чем Flash Video.

Чтобы преобразовать практически любой видеоформат (например, AVI) в FLV или MP4, проще всего воспользоваться программой ffmpeg. Скачайте и установите ее (например, отсюда).

Опции можно не учить, просто заведите bat-файл !avi-to-flv.bat, для FLV состоящий всего из двух строк:

ffmpeg -y -i %1 -vcodec libx264 -pass 1 -vpre fastfirstpass -r 10 -b 579k -f flv %1.flv
ffmpeg -y -i %1 -vcodec libx264 -pass 2 -vpre hq -r 10 -b 579k -f flv %1.flv

и пользуйтесь им.

SVG-графика

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

[[File:Warning icon.svg]]

Отображаются они парой растрового+векторного изображения, так что старые браузеры, не поддерживающие SVG, картинку всё равно отобразят.

Использовать СТАРЫЙ способ вставки SVG прямо в текст статьи через <pic-svg> - НЕ НУЖНО! Это очень некрасиво и неудобно.

С SVG-графикой работают графические редакторы «MS Visio» начиная с версии 2003 и бесплатный редактор Inkscape.

PDF-файлы

С PDF-файлами в вики тоже можно работать, как с изображениями. Очевидный нюанс заключается в том, что в PDF-файле много страниц. Поэтому на странице файла (например, File:Leeward.pdf) отображается поле с выбором страницы, а вставлять отдельные страницы в статью можно так:

[[File:Leeward.pdf|page=5|300px]]

Также можно вставить диапазон страниц или ВСЕ страницы:

Диапазон: [[File:Leeward.pdf|page=4-6|300px]]
Все: [[File:Leeward.pdf|page=-|300px]]

Остальные типы файлов

Можно также загружать «бинарный» контент произвольных форматов — документы Word и LibreOffice, презентации PowerPoint, и т. п.

По тексту офисных документов и презентаций работает поиск.

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

Дать прямую ссылку на скачивание любого файла можно в формате

[[Media:<имя файла>]]

Пример:

[[Media:Leeward.pdf|Лекция на тему «наветренный»/«подветренный»]].

Лекция на тему «наветренный»/«подветренный».

Репликация: База Знаний «Заказных Информ Систем» → «WikiHelp:Изображения»

Внимание! Данная статья выбрана для репликации в SMWiki.

Статья реплицируется в Wiki4IntraNet.

{{#ask: ParentMenuId::Top

?HelpId

?HelpOrder

?ParentMenuId

?HelpDisplay

?HelpContent

?#=Link

sort=HelpOrder

format=template

named args=yes

template=WikiHelp/SideMenu/TopLevel

}}

WikiHelp:Таблицы

2013-01-09T08:12:30Z

AndreyMoiseev:

{{#set: |HelpId=Tables |HelpOrder=800 |ParentMenuId=BasicMarkup |HelpContent=Справка:Таблицы |HelpDisplay=Таблицы }}

[Исходная статья]

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

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

Расширение SimpleTable

Простейший способ с минимумом «шумовых» символов и с соблюдением модели «строка таблицы=строка текста» — это использование расширения SimpleTable и тега «tab».

Этот же способ удобно применять для копипасты простых таблиц из Excel’я и подобных программ — нужно только написать <tab sep=tab>. Если, однако, таблица содержит объединённые ячейки или специфичные стили ячеек, то способ не подходит, и нужно смотреть в сторону #Импорт таблиц из внешних приложений в вики-синтаксис.

Например,

<tab class=wikitable sep=spaces head=top>
Месяцы:            январь февраль март апрель май июнь июль август сентябрь октябрь ноябрь декабрь
Дневная_температура  21     21      22    23  25   27    29    28     26      24      22     20
Ночная_температура   15     15      15    16  17   17    18    17     16      15      15     14
Солнечные_часы/день   6      6       7     8   9    9     9     8      7       7       6      6
Дождливые_дни/месяц   6      4       3     2   2    1     0     0      2       5       6      7
Температура_воды     19     18      18    18  19   20    21     23    20      18      18     18
</tab>

Месяцы:	январь	февраль	март	апрель	май	июнь	июль	август	сентябрь	октябрь	ноябрь	декабрь
Дневная_температура	21	21	22	23	25	27	29	28	26	24	22	20
Ночная_температура	15	15	15	16	17	17	18	17	16	15	15	14
Солнечные_часы/день	6	6	7	8	9	9	9	8	7	7	6	6
Дождливые_дни/месяц	6	4	3	2	2	1	0	0	2	5	6	7
Температура_воды	19	18	18	18	19	20	21	23	20	18	18	18

Атрибуты тега «tab», обрабатываемые самим SimpleTable:

sep

Символ-сепаратор колонок:

tab: символ табуляции
space: пробел
spaces: один или несколько пробелов или символов табуляции
comma: запятая
bar: вертикальная черта «|»
Другие: Есть возможность определить как разделитель любую последовательность символов. Скажем, sep="%%" разобьёт строчку по двойному символу процента.

head

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

top: верхняя запись
left: первая колонка
topleft: и верхняя запись и первая (левая) колонка таблицы.

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

class: Название CSS-стиля таблицы. Стиль применяется к самой таблице, а не к её ячейкам.

Чтобы не видеть убогие стандартные HTML-рамочки, рекомендуется всегда использовать class="wikitable".

Чтобы применить стиль к ячейкам, нужно определить класс .className td. Например, чтобы выровнять все ячейки по левому краю, нужно добавить на страницу следующий текст:

<html><style>.classname td { text-align: right; }</style></html>

border: Толщина границ, попадает в HTML-атрибут таблицы. Подобные границы выглядят убого, лучше используйте класс simpletable.
cellpadding: Ширина поля между значениями ячеек и границами ячеек.

И наконец, добавляя к class слово sortable, можно делать динамически сортируемые таблицы:

EMP_NO	DEPT_NO	PRO_NO	EMP_BDATE	EMP_SAL	EMP_BONUS
2441	1	155	1955	16000.00	14000.00
2442	1	20	1960	14000.00	NULL
2443	1	NULL	1960	16000.00	13000.00
2452	1	155	NULL	15000.00	14000.00
2453	1	234	NULL	17000.00	NULL
2444	2	177	1970	17000.00	16000.00

Таблицы в стандартном синтаксисе MediaWiki

Любая таблица в wiki-стиле начинается с фигурной скобки { с последующей вертикальной чертой | и заканчивается вертикальной чертой | с закрывающей фигурной скобкой }. Каждая ячейка строки начинается вертикальной черточки |, после которой пишется ее содержание.

Пример: Таблица с одной строкой пишется так:

{|
 |Ячейка 1
 |Ячейка 2
 |Ячейка 3
 |}

В CustisWiki это будет выглядеть так:

Ячейка 1

Ячейка 2

Ячейка 3

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

Пример: Таблица в две строки пишется так:

{|
 |Ячейка 1*1
 |Ячейка 2*1
 |Ячейка 3*1
 |-
 |Ячейка 1*2
 |Ячейка 2*2
 |Ячейка 3*2
 |}

В CustisWiki это будет выглядеть так:

Ячейка 1*1	Ячейка 2*1	Ячейка 3*1
Ячейка 1*2	Ячейка 2*2	Ячейка 3*2

Таблица в три строки пишется так:

{|
 |Ячейка 1*1
 |Ячейка 2*1
 |Ячейка 3*1
 |-
 |Ячейка 1*2
 |Ячейка 2*2
 |Ячейка 3*2
 |-
 |Ячейка 1*3
 |Ячейка 2*3
 |Ячейка 3*3
 |}

А в CustisWiki это будет выглядеть так:

Ячейка 1*1	Ячейка 2*1	Ячейка 3*1
Ячейка 1*2	Ячейка 2*2	Ячейка 3*2
Ячейка 1*3	Ячейка 2*3	Ячейка 3*3

И так далее.

Табличные рамки

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

Однако, вместо border=1 рекомендуется опять-таки просто использовать class=wikitable — выглядит куда симпатичнее.

Пример: Для последней таблицы рамку можно создать так:

border=1

class=wikitable

Код

{| border=1
 |Ячейка 1*1
 |Ячейка 2*1
 |Ячейка 3*1
 |-
 |Ячейка 1*2
 |Ячейка 2*2
 |Ячейка 3*2
 |-
 |Ячейка 1*3
 |Ячейка 2*3
 |Ячейка 3*3
 |}

{| class=wikitable
 |Ячейка 1*1
 |Ячейка 2*1
 |Ячейка 3*1
 |-
 |Ячейка 1*2
 |Ячейка 2*2
 |Ячейка 3*2
 |-
 |Ячейка 1*3
 |Ячейка 2*3
 |Ячейка 3*3
 |}

Результат

Ячейка 1*1	Ячейка 2*1	Ячейка 3*1
Ячейка 1*2	Ячейка 2*2	Ячейка 3*2
Ячейка 1*3	Ячейка 2*3	Ячейка 3*3

Ячейка 1*1	Ячейка 2*1	Ячейка 3*1
Ячейка 1*2	Ячейка 2*2	Ячейка 3*2
Ячейка 1*3	Ячейка 2*3	Ячейка 3*3

Заголовки

Чтобы содержание ячейки выделялись жирным шрифтом и отцентрированны, вместо вертикальных чёрточек ставятся восклицательные знаки. Это можно применять для выделения заголовков.

Пример:

Для последней таблицы можно написать так:

{| class=wikitable
 !Первый столбец
 !Второй столбец
 !Третий столбец
 |-
 !Первая строчка
 |Ячейка 2*1
 |Ячейка 3*1
 |-
 !Вторая строчка
 |Ячейка 2*2
 |Ячейка 3*2
 |-
 !Третья строчка
 |Ячейка 2*3
 |Ячейка 3*3
 |}

В CustisWiki это будет выглядеть следующим образом:

Первый столбец	Второй столбец	Третий столбец
Первая строчка	Ячейка 2*1	Ячейка 3*1
Вторая строчка	Ячейка 2*2	Ячейка 3*2
Третья строчка	Ячейка 2*3	Ячейка 3*3

Запись в одну строчку

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

Пример: Для последней таблицы можно написать так:

{| class=wikitable
 !Первый столбец||Второй столбец||Третий столбец
 |-
 |Ячейка 1*1||Ячейка 2*1||Ячейка 3*1
 |-
 |Ячейка 1*2||Ячейка 2*2||Ячейка 3*2
 |-
 |Ячейка 1*3||Ячейка 2*3||Ячейка 3*3
 |}

В CustisWiki это будет выглядеть следующим образом:

Первый столбец	Второй столбец	Третий столбец
Ячейка 1*1	Ячейка 2*1	Ячейка 3*1
Ячейка 1*2	Ячейка 2*2	Ячейка 3*2
Ячейка 1*3	Ячейка 2*3	Ячейка 3*3

Объединённые ячейки

В wiki-стиле, как и в HTML, имеется возможность «растягивать» ячейки как по вертикали, так и по горизонтали.

Для слияния ячеек по вертикали применяется атрибут rowspan=n, где «n» — число ячеек, на которые должна «тянуться» данная ячейка. Этот атрибут вписывается перед содержанием «растягиваемой» ячейки.

Пример: Вертикальное слияние двух ячеек пишется так:

{| class=wikitable
 |Ячейка 1
 |rowspan=2 |Ячейка 2, растянута
 |Ячейка 3
 |-
 |Ячейка 4
 |Ячейка 5
 |}

Выглядеть это будет так:

Ячейка 1	Ячейка 2, растянута	Ячейка 3
Ячейка 4	Ячейка 2, растянута	Ячейка 5

Для горизонтального слияния используется атрибут colspan=n.

Пример:

{| class=wikitable
 |Ячейка 1
 |colspan=2 |Ячейка 2, растянута
 |-
 |Ячейка 3
 |Ячейка 4
 |Ячейка 5
 |}

Выглядит это так:

Ячейка 1	Ячейка 2, растянута
Ячейка 3	Ячейка 4	Ячейка 5

«Раскраска» таблиц

Текст, находящийся в таблице, можно сделать цветным. С этой целью применяются те же тэги, что и в HTML:

для отдельного слова — <font color="#ABCDEF">Teкст</font>;
для длинного текста — <div style="color:#ABCDEF">Текст, текст.</div>,

где «ABCDEF» — индекс цвета в Таблице цветов.

Пример:
Для "раскраски" текста пишут так:
{| class=wikitable
 |Ячейка 1*1
 |Здесь цветное только <font color="#FF00FF">одно</font> слово.
 |Ячейка 3*1
 |-
 |Ячейка 1*2
 |Ячейка 2*2
 |<div style="color:#33CC66">А здесь выделен цветом длинный-длинный абзац.</div>
 |-
 |Ячейка 1*3
 |Ячейка 2*3
 |Ячейка 3*3
 |}

В CustisWiki это будет выглядеть следующим образом:

Ячейка 1*1	Здесь цветное только одно слово.	Ячейка 3*1
Ячейка 1*2	Ячейка 2*2	А здесь выделен цветом длинный-длинный абзац.
Ячейка 1*3	Ячейка 2*3	Ячейка 3*3

Сделать цветную ячейку можно с помощью атрибута «bgcolor=#ABCDEF», где «ABCDEF» обозначает, как вы уже, наверное, догадались, индекс цвета в Таблице цветов.

Пример:
Для "раскраски" одной ячейки пишется так:
{| class=wikitable
 |Ячейка 1*1
 |bgcolor=#FFCC00|Ячейка 2*1
 |Ячейка 3*1
 |-
 |Ячейка 1*2
 |Ячейка 2*2
 |Ячейка 3*2
 |-
 |bgcolor=#CCFF00|Ячейка 1*3
 |Ячейка 2*3
 |Ячейка 3*3
 |}

В CustisWiki это будет выглядеть следующим образом:

Ячейка 1*1	Ячейка 2*1	Ячейка 3*1
Ячейка 1*2	Ячейка 2*2	Ячейка 3*2
Ячейка 1*3	Ячейка 2*3	Ячейка 3*3

Вложенные таблицы

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

Пример:
{| border=1
 |Ячейка 1
 |
 {| border=2
 |Ячейка A
 |-
 |Ячейка B
 |}
 |Ячейка 3
 |}

Выглядеть это будет так:

Ячейка 1

Ячейка A

Ячейка B

Ячейка 3

Название таблицы

Чтобы название таблицы было отцентрировано по ее ширине, нужно после вертикальной чёрточки поставить знак «+». Само название можно форматировать обычными wiki-атрибутами.

Пример:
{| border=1
 |+ Очень длинное-длинное название таблицы.
 |Ячейка 1
 |Ячейка 2
 |-
 |Ячейка 3
 |Ячейка 4
 |}

Выглядеть это будет так:

Очень длинное-длинное название таблицы.
Ячейка 1	Ячейка 2
Ячейка 3	Ячейка 4

Ширина таблицы

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

Пример:
{| border=1 width=75%
 |+Таблица 1
 |Ячейка 1*1 - long - long- long- long- long
 |Ячейка 1*2
 |-
 |Ячейка 1*3
 |Ячейка 1*4
 |}
{| border=1 width=75%
 |+Таблица 2
 |Ячейка 2*1
 |Ячейка 2*2
 |-
 |Ячейка 2*3
 |Ячейка 2*4
 |}

Выглядеть это будет так:

Таблица 1
Ячейка 1*1 - long - long- long- long- long	Ячейка 1*2
Ячейка 1*3	Ячейка 1*4

Таблица 2
Ячейка 2*1	Ячейка 2*2
Ячейка 2*3	Ячейка 2*4

Импорт таблиц из внешних приложений в вики-синтаксис

Иногда возникает задача импорта сложных таблиц из Office-приложений (MS Word, MS Excel, Open Office).

«Сложные» таблицы — это таблицы, имеющие различные стили ячеек и/или объединённые ячейки.

С помощью wikEd — просто, но некрасиво

Используем Firefox, Chrome или Safari.
Включаем wikEd, если оный выключен (кнопочка с карандашом в правом верхнем углу страницы).
Делаем Copy-Paste таблицы в статью.
Нажимаем кнопку [W] — Wikify, выглядит она так: .

Ручками — сложнее, но красивее

Нужно:

добиться сохранения таблицы в HTML-формате (например, скопировать таблицу из MS Excel в MS Word, сохранить в формате «web-page filtered»).
«Почистить» таблицу от лишних тэгов и атрибутов с помощью программы Tidy. Примерный вызов Tidy для HTML таблицы из сохраненной из «MS Word» следующий:

tidy -raw -i -m -wrap 256 -bare --word-2000 yes %1

Вставить полученную (очищенную и отформатированную) HTML-таблицу в статью.

Таблицы в машинописном стиле без форматирования

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

                                       Климатическая таблица

Месяцы:            январь февраль март апрель май июнь июль август сентябрь октябрь ноябрь декабрь
--------------------------------------------------------------------------------------------------
Дневная температура  21     21      22    23  25   27    29    28     26      24      22     20
Ночная температура   15     15      15    16  17   17    18    17     16      15      15     14
Солнечные часы/день   6      6       7     8   9    9     9     8      7       7       6      6
Дождливые дни/месяц   6      4       3     2   2    1     0     0      2       5       6      7
Температура воды     19     18      18    18  19   20    21     23    20      18      18     18

Репликация: База Знаний «Заказных Информ Систем» → «WikiHelp:Таблицы»

Внимание! Данная статья выбрана для репликации в SMWiki.

Статья реплицируется в Wiki4IntraNet.

{{#ask: ParentMenuId::Top

?HelpId

?HelpOrder

?ParentMenuId

?HelpDisplay

?HelpContent

?#=Link

sort=HelpOrder

format=template

named args=yes

template=WikiHelp/SideMenu/TopLevel

}}

WikiHelp:Формулы

2013-01-09T08:09:27Z

AndreyMoiseev:

{{#set: |HelpId=Formulas |HelpOrder=600 |ParentMenuId=BasicMarkup |HelpContent=Справка:Формулы |HelpDisplay=Формулы }}

[Исходная статья]

Исходный текст математической формулы должен находиться между тэгами <m> ... </m>.

Практически, если включен режим генерации изображений, допустимы любые TeX-формулы, и иной TeX-блок. Если вы не знакомы с TeXом, то рассмотрите нижележащие примеры.

Специальные символы

Элемент	Синтаксис	Интерпретация в CisWiki
Стандартные функции (правильно)	\sin x + \ln y +\operatorname{sgn} z
стандартные функции (неправильно)	sin x + ln y + sgn z
арифметический модуль	s_k \equiv 0 \pmod{m}
производные	\nabla \partial dx
логические	p\wedge \bar{q} \rightarrow p\vee \bar{q} \Rightarrow \Leftrightarrow
корни	\sqrt{2}\approx 1.4
корни	\sqrt[n]{x}
операторы сравнения	\sim \simeq \cong \le \ge \equiv \approx \ne
геометрические	\angle \perp \\|
специальные	\oplus \otimes \pm \mp \hbar \dagger \ddagger \star \circ \cdot \bullet \infty \vdash \models
прочие	\forall x\not\in\empty\subseteq A\cap B\cup \exists \{x,y\} \times C

Подстрочные и надстрочные индексы

Элемент	Синтаксис	Интерпретация в Википедии
Надстрочный индекс	a^2
подстрочный индекс	a_2
группировка	a^{2+2}
группировка	a_{i,j}
комбинирование под- и надстрочных индексов	x_2^3
производная (правильно)	x'
производная (неправильно в HTML)	x^\prime
производная (неправильно в PNG)	x\prime
сумма	\sum_{k=1}^N k^2
произведение	\prod_{i=1}^N x_i
предел	\lim_{n \to \infty}x_n
интеграл	\int_{-N}^{N} e^x\, dx
интеграл по контуру	\oint_{C} x^3\, dx + 4y^2\, dy

Дроби, матрицы, многострочные формулы

Элемент

Синтаксис

Интерпретация в Википедии

Дроби

\frac{2}{4} или {2 \over 4}

Биномиальные коэффициенты

{n \choose k}

Матрицы

\begin{pmatrix} x & y \\ z & v \end{pmatrix}

\begin{bmatrix} 0 & \cdots & 0 \\ \vdots &

\ddots & \vdots \\ 0 & \cdots &

0\end{bmatrix}

\begin{Bmatrix} x & y \\ z & v \end{Bmatrix}

\begin{vmatrix} x & y \\ z & v \end{vmatrix}

\begin{Vmatrix} x & y \\ z & v \end{Vmatrix}

\begin{matrix} x & y \\ z & v \end{matrix}

выражения с выбором

f(n)=\left\{\begin{matrix} n/2, & \mbox{if }n\mbox{ is even} \\ 3n+1, & \mbox{if }n\mbox{ is odd} \end{matrix}\right.

многострочные формулы

\begin{matrix}f(n+1)&=& (n+1)^2 \\ \ & =& n^2 + 2n + 1\end{matrix}

альтернативные многострочные формулы (используя таблицы)

<table>
<tr>
<td><math>f(n+1)</math></td>
<td><math>=(n+1)^2</math></td>
</tr><tr><td></td>
<td><math>=n^2 + 2n + 1</math></td>
</tr>
</table>

Шрифты

Элемент	Синтаксис	Интерпретация в Википедии
Греческие буквы	\alpha\ \beta\ \gamma\ \Gamma\ \phi\ \Phi\ \Psi\ \tau\ \Omega
Blackboard bold	x\in\mathbb{R}\sub\mathbb{C}
Жирный шрифт (векторы)	\mathbf{x}\cdot\mathbf{y} = 0
Жирный шрифт (греческий)	\boldsymbol{\alpha}+\boldsymbol{\beta}+\boldsymbol{\gamma}
Fraktur typeface	\mathfrak{a} \mathfrak{A} \mathfrak{B}
Script	\mathcal{ABC}
Hebrew	\aleph \beth \gimel \daleth
non-italicised characters	\mbox{abc}

Скобки для больших выражений

Элемент	Синтаксис	Интерпретация в Википедии
неправильно	( \frac{1}{2} )
правильно	\left( \frac{1}{2} \right)

Возможно использовать различные скобки с \left и \right:

Элемент	Синтаксис	Интерпретация в Википедии
Круглые скобки	\left( A \right)
Квадратные скобки	\left[ A \right]
Фигурные скобки	\left\{ A \right\}
Треугольные скобки	\left\langle A \right\rangle
Вертикальная черта	\left\| A \right\|
Если скобка не должна отображаться, используйте \left . или \right .	\left . {A \over B} \right\} \to X

Разделение элементов

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

Элемент	Синтаксис	Интерпретация в Википедии
восьмикратный пробел	a \qquad b
четырехкратный пробел	a \quad b
текстовый пробел	a\ b
большое расстояние	a\;b
среднее расстояние	a\>b	не поддерживается
маленькое расстояние	a\,b
без расстояние	ab
отрицательное расстояние	a\!b

Русский язык в формулах

Если в формулах нужно использовать строки на русском, используйте макрос «\mbox» следующим образом:

<m>\mbox{Фонд зарплаты}=\sum_{c \in \mbox{Сотрудники}} \mbox{Зарплата}_c</m>

Репликация: База Знаний «Заказных Информ Систем» → «WikiHelp:Формулы»

Внимание! Данная статья выбрана для репликации в SMWiki.

Статья реплицируется в Wiki4IntraNet.

{{#ask: ParentMenuId::Top

?HelpId

?HelpOrder

?ParentMenuId

?HelpDisplay

?HelpContent

?#=Link

sort=HelpOrder

format=template

named args=yes

template=WikiHelp/SideMenu/TopLevel

}}

WikiHelp:Советы

2013-01-09T08:01:44Z

AndreyMoiseev:

{{#set: |HelpId= |HelpOrder= |ParentMenuId= |HelpContent=Справка:Советы |HelpDisplay= }}

[Исходная статья]

Публичность

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

Поместить новую статью в CustisWiki и отредактировать существующую может любой зарегистрированный участник.

Позаботьтесь о читателях Вашей статьи, назвав и оформив ее хорошим образом, структурировав и проверив орфографию. К сожалению, для IE нет средств проверки орфографии, надо или использовать mozilla (смотри #Проверка орфографии), или воспользоваться внешним редактором. Что касается оформления, то лучше применять однородные приемы, особенно при редактировании существующей статьи, чтобы все материалы были выдержаны в едином стиле: это облегчает восприятие.

Броузеры

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

Можно рекомендовать для установки следующие «многозакладочные броузеры»:

Maxthon — это надстройка над стандартным IE. * Mozilla Firefox. Очень удобный броузер, единственное — могут возникнуть проблемы с некоторыми сайтами, криворуко оптимизированными под Internet Explorer.

Также можно посмотреть броузеры MyIE2, Avant.

Адресная строка броузера для русских статей

Броузер IE позволяет вводить русские названия статей непосредственно в строке броузера (можно набрать https://lib.custis.ru/wiki/index.php/Help:Советы ), это возможно и для броузера Mozilla Firefox, если вызвать страницу настроек

about:config

и установить

network.standard-url.encode-utf8 = true

Внешнее редактирование

В большинстве броузеров, стандартные функции редактирования «TextArea»-области очень бедны — нет полноценного «Undo», «Find/Replace», настройки шрифтов и подсветки синтаксиса.

Но для броузера Mozilla Firefox, можно установить плагин TextArea Sputnik, с помощью которого можно использовать внешний редактор, для редактирования статей в CustisWiki.

Переход к статье из адресной строки Firefox

См. Firefox: Сокращения в адресной строке

Шрифт редактирования в TextArea

Если не использовать внешний редактор, то можно хотя бы настроить любимый шрифт для окна редактирования. Наиболее читаемыми с экрана являются шрифты из семейства sans-serif (без засечек), а наиболее удобными для редактирования — из семейства monospace. К сожалению, среди «стандартного» набора шрифтов, шрифтов, принадлежащих обоим семействам, всего два — «Lucida Console» и «FixedSys», и оба имеют достаточные недостатки, чтобы навязывать их общество всем пользователям. Поэтому, вы можете попытаться настроить шрифты в окне редактирования индивидуально.

Обладателям Firefox надо найти в каталоге

C:\Documents and Settings\[имя пользователя]\Application Data\Mozilla\Firefox\Profiles

подкаталог chrome и отредактировать в нем файл

userContent.css

(Если userContent.css там нет — скопировать его из userContent-example.css). Далее можно добавить строчку типа

 textarea {
            font-family: "Lucida Console", monospace, !important;
          }

«!important» — устанавливает приоритет вашего выбора над выбором вебмастера.

Импорт документов из OpenOffice

Импорт документов из OpenOffice (MediaWiki)

Импорт текста из MS Word

Варианты:

Использовать Microsoft Office Word Add-in For MediaWiki

Либо:
1. установить Open Office (всего 100Мб при максимальной инсталляции);
2. открыть Word-документ в Open Office;
3. действовать согласно пункту #Импорт документов из OpenOffice.

Ссылки на локальные файлы

Если в Mozilla Firefox у вас не работают ссылки на локальные файлы (с UNC путями или с файловыми, т. е. ссылки вида file://\\localmachine/fff или file://x:/distr/) то читайте статью, как это можно исправить.

В кратце — для последних (2.x) версий Mozilla Firefox есть два решения.

Установка http://locallink.mozdev.org/, но тогда «клики» на локально-файловых ссылках все равно работать не будут, открывать их можно только через контекстное меню «Open/…»
Найти файл настроек для своего профиля (в обычном Firefoxе это «user.js», в PortableFirefox «prefs.js», в общем .js где лежит куча настроек в виде вызовов процедуры «user_pref». Найти группу опций «capability.policy.» и заменить ее (если этой группы нет — добавить) на:

user_pref("capability.policy.policynames", "localfilelinks");
user_pref("capability.policy.localfilelinks.sites", "http://wiki.office.custis.ru");
user_pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess");

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

user_pref("capability.policy.localfilelinks.sites", "http://wiki.office.custis.ru http://penguin.office.custis.ru");

Проверка орфографии

Для Mozilla Firefox есть возможность установить проверку русской орфографии. Для этого, установите в Firefox дополнение SpellBound и дополнение русский-словарь к нему. Для IE и основанных на нем броузеров пока проверки русской орфографии нет. Была надежда, что удасться уговорить автора ispell включить поддержку нелатинских символов. Не вышло.

Замечания и обсуждения

Уважительно относитесь к труду автора и не злоупотребляйте правом редактирования любых статей. Если какое-то положение кажется Вам спорным или неверным, то лучше вставить замечание, а не исправлять сразу основной текст. Можно предложить альтернативу. Вставляя замечание, обязательно представиться, для чего удобно вставить в текст ~~~~, что при записи будет преобразовано в ссылку на участника обсуждения. Если замечание относится к конкретному месту текста, то его лучше вставить непосредственно в данное место, используя шаблон «remark» и пиктограммы для выделения его из основного текста. Можно также использовать отступы (двоеточиями). Пример:

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

Стас Фомин 16:24, 21 июля 2008 (UTC): Нет, Нормальное распределение реально накладывает аксиоматичный степенной ряд, в итоге приходим к логическому противоречию.

Стас Фомин 16:24, 21 июля 2008 (UTC): С другой стороны, рациональное число, конечно, упорядочивает криволинейный интеграл, что и требовалось доказать. Математический анализ соответствует невероятный предел последовательности, при этом, вместо 13 можно взять любую другую константу.

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

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

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

Пиктограммы

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

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

: «ok»
: «no»
: «question»

могут быть использованы в обсуждениях очевидным образом, а семантика использования остальных пиктограмм соответствует SGML Docbook#Замечания, и будет рассмотрена далее.

caution

Предостережение. Как правило, связанное с действиями техники, чем с действиями людей (для чего предназначен «warning»).

Пример:

{{caution}} Наверняка есть другие источники информации,  
 а также другая  поступающая информация. Так что этот список нуждается в 
 расширении и доработке.

Наверняка есть другие источники информации, а также другая поступающая информация. Так что этот список нуждается в расширении и доработке.

important

Важно!

{{important}} При загрузке все нулевые значения отрезаются и не вводятся!

При загрузке все нулевые значения отрезаются и не вводятся!

note

Замечание, пометка.

{{note}} Этот размер различен для различных операционных систем и определяется для каждой из них отдельно.

Этот размер различен для различных операционных систем и определяется для каждой из них отдельно.

tip

Совет, подсказка.

{{tip}} Каждый вопрос имеет ответ по умолчанию, который принимается 
при нажатии кнопки «Enter»

Каждый вопрос имеет ответ по умолчанию, который принимается при нажатии кнопки «Enter»

warning

Предостережение, скорее относящееся к действиям пользователя (а не к свойствам оборудования или софта — это «caution»).

{{warning}} '''Нельзя''' получать новые версии файлов другим путем, 
  кроме как выполнением команд <tt>update</tt> или <tt>checkout</tt>. 
  Копирование новых версий файлов с другого компьютера 
  может привести к потере данных!

Нельзя получать новые версии файлов другим путем, кроме как выполнением команд update или checkout. Копирование новых версий файлов с другого компьютера может привести к потере данных!

Отдельные рекомендации

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

Чтобы создать статью, вставьте ссылку в то место, откуда на нее предполагается переход, а затем перейдите по этой ссылке.
Ответственно относитесь к названию статьи, так как множество названий в рамках вики — общее.
Укажите категории для статьи с тем, чтобы она попала в классификаторы по категориям.
Если хотите завести статью-"песочницу" для своих личных целей (поиграться, попробовать некоторые возможности, подготовить драфт статьи), то заводите ее в своем «личном» пространстве, используя свой логин, как префикс. Например, Стас Фомин ( [[User:StasFomin]] ) может завести статью User:StasFomin/Песочница1:

[[User:StasFomin/Песочница1]]

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

Не следует дублировать заголовок статьи заголовком первого уровня в ее тексте. Вики считает, что заголовок статьи уже есть, а внутри статьи должны быть только подзаголовки.
У списков вики есть неприятная особенность: их разрывает даже перевод строки. Это особенно печально для нумерованных списков, так как сбивается нумерация. Поэтому не используйте нумерованные списки для фиксации важных положений, подлежащих обсуждению: в них практически невозможно вставить замечания.
Используйте специальные символы — кавычки, тире и так далее для оформления статьи. Для замены символов в тексте можно также использовать викификатор.
Ответственно подходите к флагу малозначимых изменений при записи. Исходите из того, что автор и другие заинтересованные лица наблюдают за статьей и хотят получать уведомления именно о значительных изменениях.
Когда делаете существенное изменение, заполняете его описание, которое сохранится в истории.
Если вы планируете внести в статью много изменений, то ее лучше редактировать целиком, а не по отдельным разделам — чтобы запись об изменениях была одна.
Если по статье идет обсуждение и у нее много наблюдателей, не делайте существенные правки оформления или викификацию статьи: на сравнении версий наблюдатели получат много малозначимых изменений. Или, если решили сделать, оформите их отдельной версией и сохраните описание.

Вот, в целом, и все.

Репликация: База Знаний «Заказных Информ Систем» → «WikiHelp:Советы»

Внимание! Данная статья выбрана для репликации в SMWiki.

Статья реплицируется в Wiki4IntraNet.

{{#ask: ParentMenuId::Top

?HelpId

?HelpOrder

?ParentMenuId

?HelpDisplay

?HelpContent

?#=Link

sort=HelpOrder

format=template

named args=yes

template=WikiHelp/SideMenu/TopLevel

}}

WikiHelp:Специальные символы

2013-01-09T08:00:33Z

AndreyMoiseev:

{{#set: |HelpId=SpecialSymbols |HelpOrder=400 |ParentMenuId=BasicMarkup |HelpContent=Справка:Специальные символы |HelpDisplay=Специальные символы }}

[Исходная статья]

Поскольку CustisWiki использует юникод, то рекомендуется все символы вставлять непосредственно, без использования кодов HTML: α вместо α и т. п.

Знаки пунктуации

¿ ¡	¿ ¡
« » ‹ ›	« » &lsaquo; &rsaquo;
‘ ’ “ ” ‚ „	‘ ’ “ ” &sbquo; &bdquo;
§ ¶	§ ¶
† ‡	&dagger; &Dagger;
•	•
— –	— –
…	…

Математические символы

√ ∫ ∂ ∑ ∏	√ ∫ ∂ ∑ ∏
операторы: − ± × · ∗ ÷	− ± × · &lowast; ÷
векторное умножение: ⨯	⨯
условия: ≅ ≈ ∝ ≡ ≠ ≤ ≥	&cong; ≈ &prop; &equiv; ≠ ≤ ≥
множество: ∈ ∉ ∩ ∪ ⊂ ⊃ ⊆ ⊇ ∅	∈ ∉ ∩ ∪ ⊂ ⊃ &sube; &supe; ∅
логические: ¬ ∧ ∨	¬ &and; &or;
кванторы: ∃ ∀	∃ ∀
двойные стрелки: ⇐ ⇒ ⇑ ⇓ ⇔	⇐ ⇒ &uArr; &dArr; ⇔
одинарные стрелки: ← → ↑ ↓ ↔ ↵	← → ↑ ↓ ↔ &crarr;
верхние индексы: ¹ ² ³	¹ ² ³
дроби: ¼ ½ ¾	¼ ½ ¾
градусы: °	°
минуты, футы: ′	′
секунды, дюймы: ″	″
бесконечность: ∞	∞
промилле: ‰	&permil;
от букв: ∇ ℵ ℑ ℘ ℜ	∇ &alefsym; &image; &weierp; &real;
∴	&there4;

Коммерческие символы

™ © ®	™ © ®
¢ € ¥ £ ¤	¢ € ¥ £ ¤

Другие символы

♠ ♣ ♥ ♦	&spades; &clubs; &hearts; &diams;
⊕ ⊗	&oplus; &otimes;
ª º	ª º
´ ¨ ˜ ‾ ¦ ◊	´ ¨ &tilde; &oline; ¦ &loz;
∠ ⊥ ƒ ⁄ ˆ	&ang; &perp; &fnof; &frasl; &circ;
★ ☭ ☂ ☠ ☛	★ ☭ ☂ ☠ ☛

Греческие буквы

Α Β Γ Δ Ε Ζ α β γ δ ε ζ	Α Β Γ Δ Ε Ζ α β γ δ ε ζ
Η Θ Ι Κ Λ Μ Ν η θ ι κ λ μ ν	Η Θ Ι Κ Λ Μ Ν η θ ι κ λ μ ν
Ξ Ο Π Ρ Σ ξ ο π ρ σ ς	Ξ Ο Π Ρ Σ ξ ο π ρ σ &sigmaf;
Τ Υ Φ Χ Ψ Ω τ υ φ χ ψ ω	Τ Υ Φ Χ Ψ Ω τ υ φ χ ψ ω

Комбинируемые диакритические символы

Ниже показаны диакритические модификаторы букв на примере буквы «а»:

а̀	̀
а́	́
а̂	̂
а̃	̃
ӓ	̈
а̉	̉
а̋	̋
а̌	̌
а⃗	⃗

Фиксированные диакритические символы

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

À Á Â Ã Ä Å Æ Ą à á â ã ä å æ ą	À Á Â Ã Ä Å Æ Ą à á â ã ä å æ ą
Ç Ć Ĉ Č ç ć ĉ č	Ç Ć Ĉ Č ç ć ĉ č
È É Ê Ë Ę Ě è é ê ë ę ě	È É Ê Ë Ę Ě è é ê ë ę ě
Ì Í Î Ï ì í î ï	Ì Í Î Ï ì í î ï
Ð ð	Ð ð
Ñ ñ	Ñ ñ
Ò Ó Ô Œ Õ Ö Ø ò ó ô œ õ ö ø	Ò Ó Ô Õ Ö Ø ò ó ô &oelig; õ ö ø
Ù Ú Û Ü ù ú û ü	Ù Ú Û Ü ù ú û ü
Ý Ÿ ý ÿ	Ý &Yuml; ý ÿ
Þ þ	Þ þ
ß	ß

Репликация: База Знаний «Заказных Информ Систем» → «WikiHelp:Специальные символы»

Внимание! Данная статья выбрана для репликации в SMWiki.

Статья реплицируется в Wiki4IntraNet.

{{#ask: ParentMenuId::Top

?HelpId

?HelpOrder

?ParentMenuId

?HelpDisplay

?HelpContent

?#=Link

sort=HelpOrder

format=template

named args=yes

template=WikiHelp/SideMenu/TopLevel

}}

WikiHelp:Подсветка синтаксиса

2013-01-09T07:57:40Z

AndreyMoiseev:

{{#set: |HelpId=SyntaxHighlighting |HelpOrder=300 |ParentMenuId=BasicMarkup |HelpContent=Справка:Коды |HelpDisplay=Подсветка синтаксиса }}

[Исходная статья]

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

Первый - MarkupBabel, использование:

<code-название_языка>
  ... фрагмент кода
 </code-название_языка>

Второй - SyntaxHighlight_GeSHi, использование:

<source lang="название_языка">
  ... фрагмент кода
 </source>

Поддерживаются следующие языки:

actionscript
ada
apache
asm
bash
c
c_mac
caddcl
cadlisp
cpp
csharp
css
delphi

html4strict: HTML, вставляйте только фрагменты (то что внутри тага «html»)

 <4/element/head.html">head>
  <4/element/meta.html">META http-equiv="Content-Type" content="text/html; charset=windows-1251">
  <4/element/title.html">title>ВК Луч-МГСУ::Каспер</4/element/title.html">title>
  <4/element/link.html">link rel="stylesheet" href="../css/cisweb.css" type="text/css">
 </4/element/head.html">head>
 <4/element/body.html">body>
 <4/element/div.html">div id="cis-main-block">
  <4/element/div.html">div class="cis-article">
   <4/element/div.html">div class="player-info">
    <4/element/div.html">div class="player-info-card">
     <4/element/table.html">table>
     <4/element/tr.html">tr>
     <4/element/td.html">td>
      <4/element/div.html">div class="player-info-photo"><4/element/img.html">img src="../photos/team/casper/foto.jpg" alt="Каспер "></4/element/div.html">div>
      </4/element/td.html">td></4/element/tr.html">tr></4/element/table.html">table></4/element/div.html">div></4/element/div.html">div></4/element/div.html">div></4/element/div.html">div></4/element/body.html">body>

 <head>
  <META http-equiv="Content-Type" content="text/html; charset=windows-1251">
  <title>ВК Луч-МГСУ::Каспер</title>
  <link rel="stylesheet" href="../css/cisweb.css" type="text/css">
 </head>
 <body>
 <div id="cis-main-block">
  <div class="cis-article">
   <div class="player-info">
    <div class="player-info-card">
     <table>
     <tr>
     <td>
      <div class="player-info-photo"><img src="../photos/team/casper/foto.jpg" alt="Каспер "></div>
      </td></tr></table></div></div></div></div></body>

java
javascript
lisp
lua
mpasm
nsis
objc
oobas

oracle8: SQL от Oracle 8i.

 CREATE OR REPLACE VIEW VA_CROSS_SPOT AS
 SELECT dt_op, code_type, code_operation, e_place, val,
        ROW_NUMBER() over (PARTITION BY dt_op, code_type ORDER BY code_operation, e_place nulls last) rn
 FROM va_spot_bytype;

 CREATE OR REPLACE VIEW VA_CROSS_SPOT AS
 SELECT dt_op, code_type, code_operation, e_place, val,
        ROW_NUMBER() over (PARTITION BY dt_op, code_type ORDER BY code_operation, e_place nulls last) rn
 FROM va_spot_bytype;

pascal

perl

#!/usr/bin/perl -w
 
use strict;
use English;
 
my $extref = "PUBLIC \"-//OASIS//DTD DocBook V3.1//EN\"";
my ($line, $topelement);
 
while ($line = <>) {
  last unless $line =~ /^$/;
}

#!/usr/bin/perl -w
 
use strict;
use English;
 
my $extref = "PUBLIC \"-//OASIS//DTD DocBook V3.1//EN\"";
my ($line, $topelement);
 
while ($line = <>) {
  last unless $line =~ /^$/;
}

php, php-brief

python

 # Класс-обработчик сырых jade-индексов.
 class CureRTF:
        def __init__(self):
                pass
 
        def ProcessFile(self):    
                #считываем все строчки из входного файла или 
                #выводит обработанные строчки в стандартный выход.
                for ls_line in fileinput.input():
			ls_line = string.replace(ls_line,' CYR;}',';}');
                        print string.replace(ls_line,'_45_','_'),

 # Класс-обработчик сырых jade-индексов.
 class CureRTF:
        def __init__(self):
                pass
 
        def ProcessFile(self):    
                #считываем все строчки из входного файла или 
                #выводит обработанные строчки в стандартный выход.
                for ls_line in fileinput.input():
			ls_line = string.replace(ls_line,' CYR;}',';}');
                        print string.replace(ls_line,'_45_','_'),

qbasic
smarty
sql

vb: Visual Basic

 Public Sub reject_swap(p_id_deal As Long)
    Dim l_com As ADODB.Command
    '-------------------------------------------
    On Error GoTo reject_swap_error
    '-------------------------------------------
    Set l_com = New ADODB.Command
 
    l_com.ActiveConnection = g_csDB.m_db
    l_com.CommandType = adCmdText

 Public Sub reject_swap(p_id_deal As Long)
    Dim l_com As ADODB.Command
    '-------------------------------------------
    On Error GoTo reject_swap_error
    '-------------------------------------------
    Set l_com = New ADODB.Command
 
    l_com.ActiveConnection = g_csDB.m_db
    l_com.CommandType = adCmdText

vbnet
visualfoxpro

xml

 <?xml version="1.0" encoding="windows-1251" ?>
 <tree>
  <node>
    <name>О компании</name>
    <description>Обзорная информация о компании</description>

 <?xml version="1.0" encoding="windows-1251" ?>
 <tree>
  <node>
    <name>О компании</name>
    <description>Обзорная информация о компании</description>

Репликация: База Знаний «Заказных Информ Систем» → «WikiHelp:Подсветка синтаксиса»

Внимание! Данная статья выбрана для репликации в SMWiki.

Статья реплицируется в Wiki4IntraNet.

{{#ask: ParentMenuId::Top

?HelpId

?HelpOrder

?ParentMenuId

?HelpDisplay

?HelpContent

?#=Link

sort=HelpOrder

format=template

named args=yes

template=WikiHelp/SideMenu/TopLevel

}}

WikiHelp:Разметка

2013-01-09T07:35:42Z

AndreyMoiseev:

{{#set: |HelpId=Markup |HelpOrder=500 |ParentMenuId=Top |HelpContent=Справка:Форматирование |HelpDisplay=Разметка }}

[Исходная статья]

Редактировать вики-страницу очень просто. Щёлкните на ссылку Править, чтобы изменить содержание страницы. На странице правки есть текстовая форма с исходным размеченным текстом страницы.

введите желаемые изменения;
напишите краткое описание сделанных изменений в соответствующей строке;
нажмите [Показать предварительный вариант] для проверки внесённых изменений на возможные ошибки;
нажмите [Записать страницу].

Часто бывает удобно предварительно скопировать текст в текстовый редактор(через буфер обмена), редактировать и проверить на ошибки в нём, а затем скопировать текст в браузер.

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

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

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

Малозначимые изменения

При редактировании страницы пользователь может отметить изменения как «малозначимые», если правка составляет лишь исправление опечаток, мелкое форматирование и небольшое переупорядочение текста.

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

Вики-разметка

Ниже приведена справочная таблица по редактированию в CustisWiki. Прежде, чем применять эти «инструменты» на «живом теле» CustisWiki, поэкспериментируйте, пожалуйста, сначала в «песочнице».

Как это выглядит	Что следует набрать
Полужирное и курсивное начертания используются в следующих случаях: логическое ударение структурное выделение логическое ударение в структурном выделении Это двойные и тройные апострофы, а не кавычки.	''логическое ударение''<br> '''структурное выделение'''<br> '''''логическое ударение в структурном выделении'''''.
Вы также можете писать курсивом и жирным, если вас интересует определенный стиль шрифта, а не логическое выделение, например, в математических формулах: F = ma Тем не менее, разница между этими двумя методами не очень важна для графических браузеров, и многие люди просто игнорируют ее.	Вы также можете писать ''курсивом'' и '''жирным''', если вас интересует определенный стиль шрифта, а не логическое выделение, например, в математических формулах: :'''F''' = ''m'''''a'''
Вы можете вставлять специальные символы	См. WikiHelp:Специальные символы
Сложные формулы: Смотри WikiHelp:Формулы	<m>\sum_{n=0}^\infty \frac{x^n}{n!}</m>
Подавление интерпретации разметки: Link → (''to'') the [[{{SITENAME}}:Справка]] Используется для изображения данных, содержащих символы со специальным значением. Игнорирует всю разметку wiki, включая ту, что выглядит как теги HTML. Не игнорирует символьные последовательности HTML.	<nowiki>Link → (''to'') the [[{{SITENAME}}:Справка]]</nowiki>
Как это выглядит	Что нужно набрать
Начните раздел со строки заголовка: Новый раздел Подраздел Под-подраздел Старайтесь делать сбалансированную структуру разделов и подразделов, например, неправильно, когда есть заголовок уровня один, дублирующий название статьи, а остальные разделы это подразделы. Старайтесь, чтобы если разделы появились, то разделов верхнего уровня было не меньше одного.	== Новый раздел == === Подраздел === ==== Под-подраздел ====
Одиночный перевод строки не влияет на разметку. Его можно использовать, чтобы разделять предложения в одном абзаце. Некоторые редакторы считают, что это облегчает редактирование и улучшает функцию сравнения версий. Но пустая строка начинает новый абзац.	Одиночный перевод строки не влияет на разметку. Его можно использовать, чтобы разделять предложения в одном абзаце. Некоторые редакторы считают, что это облегчает редактирование и улучшает функцию ''сравнения версий''. Но пустая строка начинает новый абзац.
Сделать список очень просто: каждая строка начинается со звездочки; чем больше звездочек — тем глубже уровень.	Сделать список очень просто: * каждая строка начинается со звездочки; ** чем больше звездочек — тем глубже уровень.
Нумерованные списки тоже хороши: очень организованные; лёгкие для восприятия; и с вставкой абзацев без прерывания нумерации.	# Нумерованные списки тоже хороши: ## очень организованные; ## лёгкие для восприятия; ##: и с вставкой абзацев ## без прерывания нумерации.
Можно также делать смешанные списки: и вкладывать их как например:	Можно также делать смешанные списки: # и вкладывать их # как например:
Список определений список определений пункт определение пункта	; Список определений : список определений ; пункт : определение пункта
Двоеточие делает отступ строки или абзаца. Ручной перенос строки начинает новый абзац. Это применяется в основном для отображаемого материала, но также используется для обсуждения на Страницах обсуждения.	: Двоеточие делает отступ строки или абзаца. Ручной перенос строки начинает новый абзац.
ЕСЛИ строка начинается с пробела ТОГДА она будет отформатирована так же, как и набрана; шрифтом с фиксированной шириной; без переноса строк; КОНЕЦЕСЛИ Это можно применять для: * вставки преформатированного текста; * описания алгоритмов; * исходного кода программ * ascii art. ВНИМАНИЕ! Если вы сделаете такую строку длинной, вы сделаете всю страницу широкой и из-за этого менее читабельной. Никогда не начинайте обычные строки с пробела.	ЕСЛИ строка начинается с пробела ТОГДА она будет отформатирована так же, как и набрана; шрифтом с фиксированной шириной; без переноса строк; КОНЕЦЕСЛИ Это можно применять для: * вставки преформатированного текста; * описания алгоритмов; * исходного кода программ * ascii art;
Горизонтальная разделительная линия: вверху и внизу.	Горизонтальная разделительная линия: вверху ---- и внизу.
Сноска ^[1] будет у тэга references. ↑ Это сноска.	Сноска <ref>Это сноска.</ref> будет у тэга references. <references/>

Ссылки, URL

Как это выглядит	Что надо набрать
Мы работаем в проекте КИС Спортмастер. Первая буква точки назначения автоматически делается большой. Внутренние пробелы автоматически представляются как подчеркивания (набор подчеркивания имеет тот же эффект, что и набор пробела, но не рекомендуется). Завершающие пробелы и подчеркивания игнорируются. Таким образом, приведенная выше ссылка ведет на http://penguin.office.custis.ru/wiki/index.php/КИС_Спортмастер, которая является статьей с названием «КИС Спортмастер». Внимание: если падеж ссылающегося слова или словосочетания не совпадает с именительным, или нужно, чтобы ссылка на некоторую статью была с текстом, отличным от названия статьи, то следует в двойных квадратных скобках ставить вертикальную черту и слева от нее писать именительный падеж, а справа — соответствующий грамматике предложения, в которое вставлена ссылка. Пример: Мы собираемся вести обсуждение системы управления версиями "CVS".	Мы работаем в проекте [[КИС Спортмастер]]. Мы собираемся вести обсуждение [[CVS\|системы управления версиями "CVS"]].
Та же ссылка, но с другим именем: справочная информация.	Та же ссылка, но с другим именем: [[wikipedia FAQ\|answers]]
Окончания сливаются со ссылкой: использование CVSа.	Окончания сливаются со ссылкой: использование [[CVS]]а.
Можно ссылаться на подраздел в самой статье, указав его после «решётки»: Использование флагов в Bugzilla.	Можно ссылаться на подраздел в самой статье, указав его после «решётки»: [[Bugzilla#Флаги\|Использование флагов в Bugzilla]].
Перенаправляйте название статьи на другую статью, поместив следующий текст в первую строку. Заметьте, что после этого не должно быть текста, иначе перенаправление может не работать. Смотрите Перенаправления для более подробной информации.	#REDIRECT [[CVS]]
Внешняя ссылка: Nupedia	внешняя ссылка: [http://www.nupedia.com Nupedia]
Или просто укажите URL: http://www.nupedia.com. В URL все символы должны находиться в диапазонах: A-Z a-z 0-9 ._\/~%-+&#?!=()@ \x80-\xFF. Если URL содержит другие символы, их следует преобразовать: например, ^ следует записывать как %5E (чтобы можно было просматривать в ASCII).	Или просто укажите URL: http://www.nupedia.com.
Для того, чтобы включить ссылки на загруженные объекты, не являющиеся изображениями, такие как звуковые файлы, или на изображения, заданные ссылкой, а не отображаемые на странице, используйте «медиа» ссылку. Sound Image of a Tornado	[[media:Sg_mrob.ogg\|Sound]] [[media:Tornado.jpg\|Image of a Tornado]]

Рисование графов

Можно очень легко рисовать графы по текстовому описанию. Читайте описание Graphviz!

Изображения

WikiHelp:Изображения

Таблицы

WikiHelp:Таблицы

HTML-разметка

Можно также свободно использовать HTML-разметку. Например:

Как это выглядит	Что нужно набрать
Разделы, которые не попадают в Содержание Новый раздел Подраздел Под-подраздел	<h2> Новый раздел </h2> <h3> Подраздел </h3> <h4> Под-подраздел </h4>
Можно разрывать строки не начиная новый абзац.	Можно разрывать строки<br> не начиная новый абзац.
Центрированный текст.	<center>Центрированный текст.</center>
Моноширинный шрифт для `технических терминов`.	Моноширинный шрифт для <tt>технических терминов</tt>.
Вы можете использовать маленький текст для заголовков.	Вы можете использовать <small>маленький текст</small> для заголовков.
Вы можете ~~перечеркивать удаленный материал~~ и подчеркивать новый материал.	Вы можете <strike>перечеркивать удаленный материал</strike> и <u>подчеркивать новый материал</u>.
x² ≥ 0 true Для разделения пробелами используйте знак пробела: ` `. Это также предотвращает переносы строк посреди текста, что полезно в формулах.	''x''<sup>2</sup>  ≥  0 true.
Нижний индекс: x₂ Верхний индекс: x² или x² Второй метод не может использоваться в общем случае, но при возможности (например, для единиц измерения) следует использовать именно его, поскольку большинство браузеров при этом лучше форматируют строки: ε₀ = 8.85 × 10⁻¹² C² / J m.	Нижний индекс: x<sub>2</sub> Верхний индекс: x<sup>2</sup> or x² ε<sub>0</sub> = 8.85 × 10<sup>−12</sup> C² / J m.
Комментарий в исходном тексте страницы: не отображается на странице Используется для внесения в исходный текст страницы комментария для последующих редакторов.	<!-- комментарий -->

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

Включение других статей

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

{{:Название статьи}}

мы полностью включим статью «Название статьи» в нашу.

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

Подробнее о механизме шаблонов смотри в WikiHelp:Шаблоны

Можно включать также не всю статью, а только выбранный подраздел

{{:Название статьи#Подраздел}}

Как вернуть предыдущее состояние статьи?

WikiHelp:Возврат к ранней версии

Репликация: База Знаний «Заказных Информ Систем» → «WikiHelp:Разметка»

Статья реплицируется в Wiki4IntraNet.

Внимание! Данная статья выбрана для репликации в SMWiki.

{{#ask: ParentMenuId::Top

?HelpId

?HelpOrder

?ParentMenuId

?HelpDisplay

?HelpContent

?#=Link

sort=HelpOrder

format=template

named args=yes

template=WikiHelp/SideMenu/TopLevel

}}

Процессы: ключевые vs сквозные

2012-12-27T13:41:23Z

AlexandraVelyaninova:

В журнале Intelligent Enterprise (№11/2012) опубликована статья Михаила Заборова, заместителя генерального директора по стратегическим проектам, посвященная сквозным бизнес-процессам и их автоматизации. Почему в компаниях возникают сквозные процессы и к каким последствиям для бизнеса это приводит? Как избежать сквозных ключевых процессов при оргпроектировании? Какие возможности могут предложить современные ИТ для автоматизации ключевых бизнес-процессов? Об этом — в статье «Процессы: ключевые или сквозные?» на сайте и в бумажной версии журнала.

Заказная разработка как услуга

2012-12-26T15:23:41Z

GalinaTsaturyan:

Игорь Беспальчук, руководитель отдела технологического развития, в интервью для PC Week/RE рассказал об особенностях средств и методов заказной разработки, о сервисном подходе и новом уровне аутсорсинга ИТ-услуг.

PC Week: Какие средства и методологии разработки отличают создание заказной прикладной системы от тиражируемой?

Игорь Беспальчук: Если взглянуть на современный процесс разработки, то он эволюционирует, смещая уровень сервиса ближе к потребителю. Поставщик ПО становится все ближе к заказчику и гораздо внимательнее смотрит на то, что тому нужно. Уже недостаточно просто продать программный продукт или разработать систему по спецификации. Нужно, глубоко понимая бизнес заказчика и его динамично меняющиеся потребности, быть готовыми к тому, чтобы действовать оперативно (а иногда и проактивно), при необходимости внося изменения как в ИС, так и в деятельность организации.

В низкоуровневом проектировании, разработке и тестировании для нас нет каких-либо заметных отличий от тиражной разработки. Мы используем вполне обычные и распространенные IDE-среды (Microsoft Visual Studio для систем на базе Microsoft .NET и IntelliJ IDEA для Java), системы контроля версий (Subversion), баг-трекеры (Bugzilla). С другой стороны, иногда сотрудники организации-заказчика имеют непосредственный доступ к нашему трекеру задач, в котором осуществляется и фиксируется довольно интенсивный поток общения на проектные темы. Это позволяет выстроить более оперативное и прозрачное взаимодействие с заказчиком.

PC Week: Достаточно ли заказному разработчику и в частности вашей компании имеющихся на рынке коммерческих инструментальных средств или вам приходится создавать для себя и собственные инструменты?

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

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

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

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

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

Специфические отличия иного рода возникают на более поздних стадиях работы. Тесно взаимодействуя с заказчиками в решении их бизнес-задач, мы нередко берем на себя часть деятельности по внедрению, сопровождению и администрированию разработанных нами программных продуктов — в духе популярной сегодня концепции DevOps. При этом регулярно приходится заниматься масштабными инсталляциями или обновлениями ПО и БД (десятки и сотни серверов и рабочих мест). Выполнять эту работу вручную невозможно, поэтому мы разработали собственный инструмент CUSTIS Patcher, позволяющий централизованно управлять накатом обновлений с контролем ошибок и запретом на работу в некорректных состояниях. Часто этим инструментом пользуются и специалисты заказчика, устанавливая очередные версии нашего ПО самостоятельно. Полноценных аналогов этого инструмента на рынке мы не встречали.

PC Week: В последнее время в ИТ все большую популярность приобретает сервисный подход. Находит ли он применение в разработке ПО, в частности заказного?

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

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

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

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

PC Week: Можно ли называть это передачей разработки ПО на аутсорсинг?

И. Б.: По сути всё, о чем мы говорим, вполне можно назвать аутсорсингом. Но нужно понимать, что большинство проблем и неудач с аутсорсингом связаны именно с неправильно проведенными границами, неверно выстроенными отношениями, низким уровнем ответственности и доверия между заказчиком и подрядчиком. Попытка отдавать на аутсорсинг «только кодирование» приводит к негативному эффекту: контракт включает в себя детально прописанные требования, и в результате заказчик получает то, что было зафиксировано в спецификации, а не то, что ему действительно нужно. Если нашу модель заказной разработки рассматривать как аутсорсинг, то это «аутсорсинг с человеческим лицом».

PC Week: Каковы более отдаленные перспективы развития такого подхода?

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

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

Репликация: База Знаний «Заказных Информ Систем» → «Заказная разработка как услуга»

Рынок средств разработки в эпоху ИТ-перемен

2012-12-26T15:22:54Z

GalinaTsaturyan:

Игорь Беспальчук, руководитель отдела технологического развития, рассказал еженедельнику PC Week/RE о современном рынке средств разработки, тенденциях и ожиданиях, а также о роли разработчиков и бизнес-руководителей в создании новых ИТ-решений. Комментарии Игоря опубликованы в обзоре «Рынок средств разработки в эпоху ИТ-перемен».

PC Week: Что представляет собой сегодня рынок средства разработки и использования этих средств?

Игорь Беспальчук: Сейчас мы переживаем бурный исторический момент в IT-индустрии. За последние годы на рынке открылось несколько новых ниш. Три значимых фактора для этого: стремительное развитие коммуникаций, повышение мобильности и персонализации вычислительных устройств и общий сдвиг к сервисной парадигме. В образовавшееся рыночное пространство хлынули все, от мала до велика. Это движение порождает соответствующий информационный шум — кажется, что вне облаков и мобильных устройств «жизни нет». Это, конечно же, не совсем так, просто в этой области сейчас наибольшая активность и самые быстрые изменения. За пять-десять лет бум утихнет и даже произойдет частичный откат. Уже сейчас многие эксперты (например, Стив Возняк) выражают обеспокоенность чрезмерной увлеченностью облаками и потерей контроля над данными.

PC Week: Какие тенденции тут наблюдаются и что можно ожидать в будущем?

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

В то же время мы наблюдаем очень большую разницу в подходах к разработке клиентских приложений для различных аппаратных платформ. Большую фору в этом вопросе имеют разработчики веб-браузеров и HTML5, но их унификация подхода к разработке дает слишком много ограничений (что недавно подтвердил и Марк Цукерберг). По направлению к единой клиентской платформе для всех устройств идет и Google с инициативой NativeClient, преодолевающей ограничения HTML. Но она пока не получила широкого распространения, поскольку, очевидно, не выгодна производителям HTML-браузеров. Корпорация Microsoft также готова представить единую платформу под лозунгом «One OS to rule them all». Она даже пытается привлечь на свою сторону легионы JavaScript-разработчиков, чем здорово пугает своих традиционных сторонников. Но перспективы Microsoft на мобильном рынке пока довольно призрачны.

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

PC Week: Какова роль разработчиков в создании новых ИТ-решений?

И. Б.: Один из главных сегодняшних трендов в ИТ-индустрии — это смещение уровня сервиса ближе к потребителю. Уже мало кого устраивает просто разработка программного продукта по подготовленным требованиям. Сегодняшний поставщик ИТ-решений должен быть готов предоставить сервис значительно более высокого уровня, включающий более тесное взаимодействие с заказчиком для решения бизнес-задач. Поставщик при этом выступает не как ресурс разработки по спецификациям и не как ресурс специализированной рабочей силы, а как целостный ресурс развития бизнеса. Для достижения синергетического эффекта в таком партнерстве от заказчика требуется высокий уровень доверия к поставщику, а от поставщика — высокий уровень ответственности за качество сервиса в целом, от анализа проблем и разработки ПО до поддержки и эксплуатации. Здесь находит свое место набирающая зрелость концепция DevOps. Команды разработчиков должны понимать новую философию, воплощенную в принципах Agile и DevOps, но большинству компаний в нашей стране еще предстоит культурная ломка, чтобы перейти к новой парадигме.

PC Week: Какова роль бизнес-руководителей в управлении процессом разработки?

И. Б.: Руководители бизнеса должны представлять IT (будь то внутренняя IT-служба компании или внешний подрядчик) как полноправного партнера, от которого с каждым годом все больше и больше зависит течение бизнеса. Необходимо, чтобы стратегическое движение бизнеса формировалось совместно с представителями IT, исходя из общего понимания целей организации и новых возможностей IT-технологий. Кроме общего понимания целей важным является общее представление о качестве сервиса. Необходимо, чтобы именно эти высокоуровневые представления, о целях («Чего мы хотим достичь?») и качестве («Что мы считаем достаточным уровнем качества?») были максимально объективированы и согласованы. Исходной точкой во взаимодействии должно быть именно согласование целей и критериев качества, а не директивное руководство. Естественно, что это возможно только в том случае, когда IT-служба или подрядчик обладает достаточной компетентностью для самостоятельного успешного ведения проектной деятельности и управления процессами.

Репликация: База Знаний «Заказных Информ Систем» → «Рынок средств разработки в эпоху ИТ-перемен»

Портал WikiHelp

2012-12-26T15:05:36Z

AndreyMoiseev:

Регистрация

Создание и редактирование статей

Права доступа

Разметка

Продвинутые темы

Социальные возможности

Регистрация

Создание и редактирование статей

Подписи

Права доступа

Разметка

Выделение текста

Гиперссылки

Подсветка синтаксиса для ЯП

Специальные символы

Пиктограммы

Формулы

Подавление разметки/форматирования

Мультимедиа

Структура документа

Продвинутые возможности

Включение других статей

Рисование графов

Рисование графиков

Векторная графика (SVG)

Быстрое создание статей по шаблону

Магические слова

Продвинутые темы

Интеграция с внешними системами

Интеграция с SVN

Интеграция с Bugzilla

Списки багов из Bugzilla

Массовое редактирование статей

RSS

"Социальные" темы

Блоги

Опросы и голосования

Лайки и рейтинги

введите желаемые изменения;
напишите краткое описание сделанных изменений в соответствующей строке;
нажмите [Показать предварительный вариант] для проверки внесённых изменений на возможные ошибки;
нажмите [Записать страницу].

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

Малозначимые изменения

Вики-разметка

Как это выглядит	Что следует набрать
Полужирное и курсивное начертания используются в следующих случаях: логическое ударение структурное выделение логическое ударение в структурном выделении Это двойные и тройные апострофы, а не кавычки.	''логическое ударение''<br> '''структурное выделение'''<br> '''''логическое ударение в структурном выделении'''''.
Вы также можете писать курсивом и жирным, если вас интересует определенный стиль шрифта, а не логическое выделение, например, в математических формулах: F = ma Тем не менее, разница между этими двумя методами не очень важна для графических браузеров, и многие люди просто игнорируют ее.	Вы также можете писать ''курсивом'' и '''жирным''', если вас интересует определенный стиль шрифта, а не логическое выделение, например, в математических формулах: :'''F''' = ''m'''''a'''
Вы можете вставлять специальные символы	См. WikiHelp:Специальные символы
Сложные формулы: Смотри WikiHelp:Формулы	<m>\sum_{n=0}^\infty \frac{x^n}{n!}</m>
Подавление интерпретации разметки: Link → (''to'') the [[{{SITENAME}}:Справка]] Используется для изображения данных, содержащих символы со специальным значением. Игнорирует всю разметку wiki, включая ту, что выглядит как теги HTML. Не игнорирует символьные последовательности HTML.	<nowiki>Link → (''to'') the [[{{SITENAME}}:Справка]]</nowiki>
Как это выглядит	Что нужно набрать
Начните раздел со строки заголовка: Новый раздел Подраздел Под-подраздел Старайтесь делать сбалансированную структуру разделов и подразделов, например, неправильно, когда есть заголовок уровня один, дублирующий название статьи, а остальные разделы это подразделы. Старайтесь, чтобы если разделы появились, то разделов верхнего уровня было не меньше одного.	== Новый раздел == === Подраздел === ==== Под-подраздел ====
Одиночный перевод строки не влияет на разметку. Его можно использовать, чтобы разделять предложения в одном абзаце. Некоторые редакторы считают, что это облегчает редактирование и улучшает функцию сравнения версий. Но пустая строка начинает новый абзац.	Одиночный перевод строки не влияет на разметку. Его можно использовать, чтобы разделять предложения в одном абзаце. Некоторые редакторы считают, что это облегчает редактирование и улучшает функцию ''сравнения версий''. Но пустая строка начинает новый абзац.
Сделать список очень просто: каждая строка начинается со звездочки; чем больше звездочек — тем глубже уровень.	Сделать список очень просто: * каждая строка начинается со звездочки; ** чем больше звездочек — тем глубже уровень.
Нумерованные списки тоже хороши: очень организованные; лёгкие для восприятия; и с вставкой абзацев без прерывания нумерации.	# Нумерованные списки тоже хороши: ## очень организованные; ## лёгкие для восприятия; ##: и с вставкой абзацев ## без прерывания нумерации.
Можно также делать смешанные списки: и вкладывать их как например:	Можно также делать смешанные списки: # и вкладывать их # как например:
Список определений список определений пункт определение пункта	; Список определений : список определений ; пункт : определение пункта
Двоеточие делает отступ строки или абзаца. Ручной перенос строки начинает новый абзац. Это применяется в основном для отображаемого материала, но также используется для обсуждения на Страницах обсуждения.	: Двоеточие делает отступ строки или абзаца. Ручной перенос строки начинает новый абзац.
ЕСЛИ строка начинается с пробела ТОГДА она будет отформатирована так же, как и набрана; шрифтом с фиксированной шириной; без переноса строк; КОНЕЦЕСЛИ Это можно применять для: * вставки преформатированного текста; * описания алгоритмов; * исходного кода программ * ascii art. ВНИМАНИЕ! Если вы сделаете такую строку длинной, вы сделаете всю страницу широкой и из-за этого менее читабельной. Никогда не начинайте обычные строки с пробела.	ЕСЛИ строка начинается с пробела ТОГДА она будет отформатирована так же, как и набрана; шрифтом с фиксированной шириной; без переноса строк; КОНЕЦЕСЛИ Это можно применять для: * вставки преформатированного текста; * описания алгоритмов; * исходного кода программ * ascii art;
Горизонтальная разделительная линия: вверху и внизу.	Горизонтальная разделительная линия: вверху ---- и внизу.
Сноска ^[1] будет у тэга references. ↑ Это сноска.	Сноска <ref>Это сноска.</ref> будет у тэга references. <references/>

Ссылки, URL

Как это выглядит	Что надо набрать
Мы работаем в проекте КИС Спортмастер. Первая буква точки назначения автоматически делается большой. Внутренние пробелы автоматически представляются как подчеркивания (набор подчеркивания имеет тот же эффект, что и набор пробела, но не рекомендуется). Завершающие пробелы и подчеркивания игнорируются. Таким образом, приведенная выше ссылка ведет на http://penguin.office.custis.ru/wiki/index.php/КИС_Спортмастер, которая является статьей с названием «КИС Спортмастер». Внимание: если падеж ссылающегося слова или словосочетания не совпадает с именительным, или нужно, чтобы ссылка на некоторую статью была с текстом, отличным от названия статьи, то следует в двойных квадратных скобках ставить вертикальную черту и слева от нее писать именительный падеж, а справа — соответствующий грамматике предложения, в которое вставлена ссылка. Пример: Мы собираемся вести обсуждение системы управления версиями "CVS".	Мы работаем в проекте [[КИС Спортмастер]]. Мы собираемся вести обсуждение [[CVS\|системы управления версиями "CVS"]].
Та же ссылка, но с другим именем: справочная информация.	Та же ссылка, но с другим именем: [[wikipedia FAQ\|answers]]
Окончания сливаются со ссылкой: использование CVSа.	Окончания сливаются со ссылкой: использование [[CVS]]а.
Можно ссылаться на подраздел в самой статье, указав его после «решётки»: Использование флагов в Bugzilla.	Можно ссылаться на подраздел в самой статье, указав его после «решётки»: [[Bugzilla#Флаги\|Использование флагов в Bugzilla]].
Перенаправляйте название статьи на другую статью, поместив следующий текст в первую строку. Заметьте, что после этого не должно быть текста, иначе перенаправление может не работать. Смотрите Перенаправления для более подробной информации.	#REDIRECT [[CVS]]
Внешняя ссылка: Nupedia	внешняя ссылка: [http://www.nupedia.com Nupedia]
Или просто укажите URL: http://www.nupedia.com. В URL все символы должны находиться в диапазонах: A-Z a-z 0-9 ._\/~%-+&#?!=()@ \x80-\xFF. Если URL содержит другие символы, их следует преобразовать: например, ^ следует записывать как %5E (чтобы можно было просматривать в ASCII).	Или просто укажите URL: http://www.nupedia.com.
Для того, чтобы включить ссылки на загруженные объекты, не являющиеся изображениями, такие как звуковые файлы, или на изображения, заданные ссылкой, а не отображаемые на странице, используйте «медиа» ссылку. Sound Image of a Tornado	[[media:Sg_mrob.ogg\|Sound]] [[media:Tornado.jpg\|Image of a Tornado]]

Рисование графов

Можно очень легко рисовать графы по текстовому описанию. Читайте описание Graphviz!

Изображения

WikiHelp:Изображения

Таблицы

WikiHelp:Таблицы

HTML-разметка

Можно также свободно использовать HTML-разметку. Например:

Как это выглядит	Что нужно набрать
Разделы, которые не попадают в Содержание Новый раздел Подраздел Под-подраздел	<h2> Новый раздел </h2> <h3> Подраздел </h3> <h4> Под-подраздел </h4>
Можно разрывать строки не начиная новый абзац.	Можно разрывать строки<br> не начиная новый абзац.
Центрированный текст.	<center>Центрированный текст.</center>
Моноширинный шрифт для `технических терминов`.	Моноширинный шрифт для <tt>технических терминов</tt>.
Вы можете использовать маленький текст для заголовков.	Вы можете использовать <small>маленький текст</small> для заголовков.
Вы можете ~~перечеркивать удаленный материал~~ и подчеркивать новый материал.	Вы можете <strike>перечеркивать удаленный материал</strike> и <u>подчеркивать новый материал</u>.
x² ≥ 0 true Для разделения пробелами используйте знак пробела: ` `. Это также предотвращает переносы строк посреди текста, что полезно в формулах.	''x''<sup>2</sup>  ≥  0 true.
Нижний индекс: x₂ Верхний индекс: x² или x² Второй метод не может использоваться в общем случае, но при возможности (например, для единиц измерения) следует использовать именно его, поскольку большинство браузеров при этом лучше форматируют строки: ε₀ = 8.85 × 10⁻¹² C² / J m.	Нижний индекс: x<sub>2</sub> Верхний индекс: x<sup>2</sup> or x² ε<sub>0</sub> = 8.85 × 10<sup>−12</sup> C² / J m.
Комментарий в исходном тексте страницы: не отображается на странице Используется для внесения в исходный текст страницы комментария для последующих редакторов.	<!-- комментарий -->

Включение других статей

{{:Название статьи}}

мы полностью включим статью «Название статьи» в нашу.

Подробнее о механизме шаблонов смотри в WikiHelp:Шаблоны

Можно включать также не всю статью, а только выбранный подраздел

{{:Название статьи#Подраздел}}

Как вернуть предыдущее состояние статьи?

WikiHelp:Возврат к ранней версии

Репликация: База Знаний «Заказных Информ Систем» → «Портал WikiHelp»

Статья реплицируется в Wiki4IntraNet.

Внимание! Данная статья выбрана для репликации в SMWiki.

Разработка мобильных приложений с помощью JavaScript, HTML, CSS и PhoneGap (семинар 2012-10-10)

2012-12-23T15:09:47Z

KirillovaOlga:

Функциональное программирование: мифы и реальность (семинар 2012-10-24)

2012-12-23T15:01:40Z

KirillovaOlga:

Предметно-ориентированные языки (DSL) в проектах на Java (семинар 2012-11-15)

2012-12-10T21:32:16Z

DenisGavrilov:

ИТ-решения должны не только работать здесь и сейчас, но и развиваться вместе с бизнесом

2012-11-29T16:31:45Z

AlexandraVelyaninova:

Максим Михалев, наш директор по маркетингу и продажам, в интервью для информационно-делового портала @ASTERA рассказал о результатах работы нашей компании в 2012 году и планах на следующий год. Также обсуждались препятствия для роста российского рынка ИТ и необходимые условия для успешной работы в этом сегменте. Мы публикуем полный текст беседы с Максимом.

@ASTERA: Как вы оцениваете результаты работы CUSTIS в 2012 году? Как изменился объем бизнеса компании? Результаты работы? Достижения?

Максим Михалев: 2012 год стал для нас периодом интенсивного роста и развития. За этот год мы выросли на 70% по количеству персонала, объем проектной деятельности увеличился почти в полтора раза. Для того чтобы в процессе такого расширения компании не уронить планку качества оказываемых услуг, нами были запущены несколько проектов развития. Их цель — подготовить компанию к работе с проектами большего масштаба, научиться предоставлять клиентам сервис, гарантирующий долгосрочное развитие разрабатываемых информационных систем, выстроить систему управления развитием компании (под развитием мы понимаем, в первую очередь, качественные изменения внутри компании).

Продолжая работать с привычными для нас отраслевыми клиентами (торговыми сетями, финансовыми институтами и предприятиями сферы ЖКХ), мы начали активные переговоры с компаниями энергетического сектора, а также с рядом государственных предприятий. Если говорить о существующих клиентах, то стоит отметить передачу в промышленную эксплуатацию системы «Главная бухгалтерская книга», разработанной для ГПБ (ОАО), и участие в качестве разработчика учетного бэк-офиса в проекте внедрения крупного западного банковского продукта.

@ASTERA: Назовите основные проблемы для роста российского рынка ИТ. Возможно ли их преодоление в ближайшее время?

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

Долгое время продажа и внедрение систем класса ERP от SAP, Oracle и Microsoft, а также небольшого набора узкоспециализированных систем класса CRM, BI и им подобных были хорошим драйвером роста для большого количества ИТ-компаний. А в конечном итоге и для всего рынка. Однако сейчас можно наблюдать ситуацию насыщения рынка — большая часть компаний, желавших внедрить готовое решение, уже сделали это, и значительного количества новых клиентов в ближайшее время не ожидается. Как правило, после внедрения системы ИТ-компании стараются предоставить услуги по сопровождению и эксплуатации. В режиме сопровождения подрядчик получает предсказуемый объем работ, и по этому пути пошли многие игроки. Однако обратной стороной предсказуемости является низкая динамика роста, а зачастую и вовсе стагнация.

Выходом из этой ситуации может быть переход от сопровождения к развитию внедренных систем (то, что на Западе сейчас называется набирающим популярность термином DevOps). У услуги такого типа есть большой потенциал роста, так как она позволяет обеспечить динамичное и менее скачкообразное развитие информационной системы. Но для ее предоставления ИТ-компании должны демонстрировать совсем другой уровень знания системы и организации производства.

@ASTERA: Какие факторы способствуют успешной работе на российском рынке ИТ на сегодняшний день?

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

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

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

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

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

В-третьих, гибкость. Клиентоориентированный подрядчик выстраивает все свои процессы — от сбора требований до внедрения — исходя из потребностей клиента.

В-четвертых, профессионализм. Заказчик хочет быть уверен, что его проектом будут заниматься опытные профессионалы, а результат будет соответствовать всем актуальным в данном ИТ-сегменте стандартам качества.

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

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

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

@ASTERA: Как планируете бороться с высокой конкуренцией на этом рынке?

М. М.: В нише, которую мы занимаем, — проектирование, разработка и внедрение информационных систем на заказ — конкурентное давление существенно ниже, чем в других сегментах рынка ИТ. Причин тому несколько. Во-первых, спрос на заказную разработку пока значительно меньше спроса на «коробочные» и ERP-системы от крупных вендоров. Во-вторых, существующая парадигма российского рынка такова, что большинство компаний решает задачу разработки информационных систем собственными силами — формируя внутреннее ИТ-подразделение (инхаус). В-третьих, существует ряд укоренившихся мифов (и нужно признать, что они не совсем безосновательны), касающихся заказной разработки. К примеру, что заказная разработка — это долго, дорого и не очень качественно. Неудивительно, что чаще всего компании привлекают разработчиков заказного ПО на небольшие проекты по автоматизации процессов, не являющихся критически важными для бизнеса. Поэтому большую долю в сегменте заказной разработки занимают небольшие компании, работающие с короткими проектами от человеко-месяца до человеко-года.

Вопреки сложившемуся на рынке отношению к аутсорсингу разработки ПО, наша компания 16 лет реализует масштабные проекты (в которые вкладываются десятки человеко-лет за 1–1,5 года) по автоматизации ключевых бизнес-процессов крупных государственных и частных компаний. Другими словами, мы работаем там, где просто нет и не может быть готовых решений. Наши основные клиенты — крупнейшие банки, торговые сети, органы государственной власти и инфраструктурные институты.

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

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

Таким образом, если коротко резюмировать все вышесказанное, то основными составляющими нашего конкурентного преимущества являются:

специализация (масштабные проекты, учетные и аналитические задачи);
авторская методология проектирования и собственная платформа разработки — учетные диаграммы и Учетная Машина;
технология «бережного внедрения».

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

@ASTERA: Какие отрасли экономики сейчас наиболее привлекательны для разработчиков ПО? Кто наиболее серьезно сейчас занимается модернизацией ИТ-инфраструктуры?

М. М.: По нашим наблюдениям, традиционно есть спрос на заказное ПО в динамично меняющихся отраслях, которые физически не могут существовать без автоматизации. В первую очередь это относится к банковской сфере, где часто меняется законодательство, что требует быстрой реакции со стороны информационных систем, и к торговым сетям, где традиционно высокая конкуренция и динамика развития. Также заказное ПО востребовано в отраслях, которые находятся в стадии реформирования и претерпевают структурные изменения, как это можно наблюдать в энергетике и ЖКХ.

@ASTERA: Планы по развитию компании на следующий год?

М. М.: В следующем году основные усилия мы планируем сконцентрировать на продвижении разработанной нами в этом году концепции учетно-ориентированной архитектуры (УОА). Она предполагает логическое выделение в существующей ИТ-архитектуре информационного слоя, отвечающего за движение учетных данных. При этом одним из ключевых принципов УОА является сохранение существующего ИТ-ландшафта.

В результате создания учетно-ориентированной архитектуры все бизнес-приложения компании объединяются в единое учетное пространство, что подразумевает централизованное управление и распространение учетных политик на все приложения. Одновременно выполняется контроль соответствия данных учетной политике и их обогащение для последующей трансляции в аналитические и отчетные системы. Кроме того, УОА дает компании возможность создавать и развивать независимый от конкретных вендоров ИТ-ландшафт, внедряя специализированные best-of-breed системы.

Репликация: База Знаний «Заказных Информ Систем» → «ИТ-решения должны не только работать здесь и сейчас, но и развиваться вместе с бизнесом»

Качество отечественных стартапов растет с каждым годом

2012-11-29T12:22:29Z

KseniyaKirillova:

Максим Михалев, наш директор по маркетингу и продажам, рассказал «Российской Газете» о ситуации на российском рынке инновационных проектов и о том, могут ли отечественные IT-стартапы конкурировать с западными разработками. Пояснения Максима опубликованы в статье «Проекты становятся лучше» на сайте издания. Мы предлагаем вашему вниманию полную версию комментария.

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

«Российская Газета»: По вашему мнению, за счет чего растет качество инновационных проектов в РФ? Сыграли свою роль институты развития? Инноваторы учитывают предыдущие ошибки и пр.?

Максим Михалев: Если рассматривать инновации с позиции Шумпетера, то есть как создание чего-то принципиально нового, то в России сейчас есть для этого и желание (спрос), и возможности. Спрос на инновации в области информационных технологий определяется все более зрелым отношением к ним со стороны как государства, так и крупных компаний. Постепенно становится очевидно, что далеко не все можно купить на Западе в виде готового решения, а когда речь заходит о национальной безопасности, то собственные разработки — это единственный выход.

Что касается возможностей, то в России по-прежнему есть сильная база подготовки специалистов в области информационных технологий. Если посмотреть на успешные ИТ-компании, то большая часть их персонала приходит из главных вузов страны — МГУ, МФТИ, МГТУ, МИФИ. Многие компании активно участвуют в учебном процессе, чтобы получать выпускников, более ориентированных на реальные задачи. А большое количество появившихся в последнее время ИТ-стартапов говорит о том, что с идеями у нас тоже все хорошо, потенциал есть.

«Российская газета»: Обладают ли сегодняшние проекты (не конкурсные, вообще по рынку) хорошими рыночными перспективами? Поясните свою точку зрения.

М. Михалев: Скорее да, чем нет. Не секрет, что большая часть ИТ-рынка поделена между крупными корпорациями, что, с одной стороны, означает, что новым небольшим компаниям сложно соревноваться с их рыночной властью, с их бюджетами на НИОКР. С другой стороны, чем крупнее компания, тем больше она стремится не к освоению новых рубежей, а к защите старых. В этой ситуации небольшая компания, будучи гибкой, мобильной и быстрой в принятии решений, может легко найти себе нишу с высоким потенциалом и успешно в ней вырасти. Подобных примеров на рынке много, и тот факт, что корпорации вроде Google, Oracle, Microsoft в последние годы активно ищут и покупают такие компании, лишь подтверждает эту гипотезу.

«Российская газета»: Сегодня в инвестиционном портфеле преобладают предложения в основном от зарубежных компаний (81%), российских государственных и коммерческих структур меньшинство — 19%. Почему складывается такая ситуация? На Западе иссякают разработки? Отечественные компании не верят в своих же разработчиков? Банальный недостаток средств в РФ?

М. Михалев: Я склонен считать, что это связано, прежде всего, со сложившимся за последние 20 лет стереотипом, что качественная ИТ-разработка может быть только на Западе. При этом часто забывают, что многие ныне успешные западные компании основаны выходцами из России. А западные инвесторы это как раз хорошо понимают.

Репликация: База Знаний «Заказных Информ Систем» → «Качество отечественных стартапов растет с каждым годом»

Agile-методологии в действии: теория и практика (семинар 2012-09-26)

2012-11-19T08:11:09Z

DenisGavrilov: Новая страница: «== Аннотация == ;Докладчик: [mailto:dzvonarev@custis.ru Дмитрий Звонарев] менеджер по персоналу, сертиф...»

Разработка web-приложений на платформе ASP.NET MVC (семинар 2012-10-17)

2012-11-13T16:14:14Z

DenisGavrilov:

Автоматизация бизнес-процессов: проектирование архитектуры конкурентных решений (семинар 2012-11-07)

2012-11-13T15:53:42Z

KirillovaOlga:

Роль аналитика в IT-компании (семинар 2012-10-03)

2012-11-13T15:49:36Z

DenisGavrilov:

Введение в разработку многопоточных приложений (семинар 2012-10-31)

2012-11-13T15:36:54Z

DenisGavrilov: Новая страница: «== Аннотация == ;Докладчик: [mailto:dkostikov@custis.ru Дмитрий Костиков] ведущий разработчик C#, сертиф...»

Highload-2012: Отчёт Виталия Филиппова

2012-10-31T17:59:50Z

VitaliyFilippov: /* Tricky SQL. Особые возможности SQL-диалекта PostgreSQL / Иван Фролков */

Highload — «конференция разработчиков высоконагруженных систем» — пожалуй, самая распиаренная из Бунинских конференция. Проходила 22-23 октября 2012 (понедельник и вторник) в конференц-центре гостиницы Radisson Славянская (м. Киевская).

Общие замечания:

Конференция полностью разработческая, число менеджерских тем стремится к нулю.
Что приятно, число виндузятников на конференции также стремится к нулю — на ноутах у всех либо мак, либо линукс, причём соотношение где-то 50 на 50.
Было некоторое количество иностранцев с докладами, но они в основном как-то растекались мыслью по древу. Говорят, Bruce Momjian очень хорошо вещал, но я его, к сожалению, пропустил.
Уровень как докладчиков, так и презентаций, вполне приличный, пусть и не идеальный.
В раздатке дали книжку с частью содержимого хайлоадов за 2010 и 2011 года. Я как раз пропустил то ли обе, то ли только 2011 :) пусть там не всё и вообще непонятно, по какому принципу выбирались доклады, тем не менее — наконец-то что-то полезное в раздатке :)
Кормили неплохо. Жалко, бутербродиков в кофе-брейках не было :)
Билет стоил (!!!) 21000 рублей. Что и говорит о степени распиаренности конференции.
В этом году нагнали совершенно дикое количество народа — например, в первый день в первом зале было совсем всё печально. Сидели разве что не у друга на головах, плюс ещё стояли в проходах, выглядывая друг у друга из-за плеча. Я сидел на полу. Это при том, что первый зал был сам по себе огромный, размером примерно как 2-3 стандартных потоковых аудитории.
В конце Бунин продал с аукциона красные пенопластовые буквы «HL++», стоявшие в виде декораций на полу. За 16500 O_o. Да, поистине чудесное аукцион творит.

Круглый стол по системам контроля версий (ADD-2010)

2012-10-25T12:25:25Z

StasFomin: Новая страница: « == Видео == {{vimeoembed|43624089|800|450}} {{CONFIDENTIAL-BEGIN}} У нас {{UniversityMedia|channels\addconf.ru\2010\314-round-table-vcs-add-2010.av...»

Java vs Csharp (Круглый стол, ADD-2010)

2012-10-23T19:57:57Z

StasFomin:

SQL vs. NOSQL (Круглый стол, ADD-2010)

2012-10-23T19:45:15Z

StasFomin: Новая страница: «== Аннотация == <blockquote> На конференции запланирован круглый стол/дискуссия на актуальную т...»

Проектирование с помощью UML (2012-06-07, для студентов)

2012-10-22T17:51:49Z

StasFomin: /* Видео */

Библиотеки и фреймворки для построения клаудов (Константин Данилов, ADD-2012)

2012-10-16T19:17:23Z

StasFomin: Новая страница: «== Аннотация == ;Докладчик: [https://plus.google.com/106112060048784999686/about Константин Данилов] <blockquote> За посл...»

Автоматизация сборки и тестирования в разрезе эффективного производства (Олег Ладыгин, SQADays-11)

2012-10-16T18:52:26Z

StasFomin: /* Видео */

Практика создания удаленного офиса тестирования (Михаил Мериин, SQADays-11)

2012-10-16T18:07:02Z

StasFomin:

Разработчик и провайдер в одном лице

2012-10-08T13:29:58Z

AlexandraVelyaninova:

Дмитрий Морозов, ведущий системный инженер нашей компании, рассказал журналу Intelligent Enterprise об использовании разделяемых сервисов (Shared Services) в российских реалиях. Почему наибольшей популярностью пользуется модель «Инфраструктура как сервис» (IaaS), а не «ПО как услуга» (SaaS)? Кому может «навредить» стандартизация и как этого избежать? Об этом — в комментарии к статье «Консолидация означает разделение».

В настоящее время на российском рынке наибольшей популярностью пользуется модель «Инфраструктура как сервис» (IaaS). Почему же? Казалось бы, бизнес наиболее ориентирован на использование «ПО как услуги» (SaaS). К примеру, все большее распространение получает перевод корпоративных почтовых систем на Gmail. Основными целями при переводе IT-систем в облачную инфраструктуру, как известно, являются снижение стоимости владения, увеличение стабильности и качества предоставляемых бизнесу информационных сервисов. В то же время существует необходимость сохранения должной степени управляемости IT-систем. Поиск оптимального баланса между стоимостью, качеством и управляемостью является первостепенной задачей при переходе в облака.

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

Модель SaaS глубоко связана с содержанием решаемых бизнес-задач и требует стандартизации менеджмента IT более высокого уровня. С одной стороны, стандартизация позволяет привести систему к наиболее удачным решениям (именно это и является причиной популярности корпоративных почтовых сервисов от Google). Но, с другой стороны, могут быть утеряны уникальные особенности бизнес-процессов. Если для почтовых служб это почти неактуально, то для сильно связанных с бизнес-процессами и слабостандартизируемых систем, например для ERP-решений, данный вопрос является ключевым.

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

Репликация: База Знаний «Заказных Информ Систем» → «Разработчик и провайдер в одном лице»

Золотая середина. Открытые системы поддержки разработки (Стас Фомин, ADD-2010)

2012-09-27T19:19:41Z

StasFomin: /* Видео */

Переходя все границы. Vol 2 (Алексей Баранцев, UTD-2012)

2012-09-27T17:56:34Z

StasFomin: /* Примечания и отзывы */

Автоматизация, как естественный процесс эволюции проекта (Екатерина Несмелова, UTD-2012)

2012-09-27T17:34:09Z

StasFomin: /* Примечания и отзывы */

Exploratory Testing. Что это? (Андрей Дзыня, UTD-2012)

2012-09-27T17:23:44Z

StasFomin: /* Слайды = */