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

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.

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

Репликация: База Знаний «Заказных Информ Систем» → «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: /* Слайды = */

Agile Testing - What is this anyways? (Markus Gärtner, UTD-2012)

2012-09-27T17:14:18Z

StasFomin: /* Примечания и отзывы */

Да перестаньте уже автоматизировать! (Алексей Лупан, UTD-2012)

2012-09-27T16:37:50Z

StasFomin: /* Примечания и отзывы */

Да перестаньте уже автоматизировать! (Алексей Лупан, UTD-2012)

UTD-2012

2012-09-27T16:01:02Z

StasFomin: Новая страница: «Записи первого трека конференции [http://uatestingdays.com/ Ukrainian Testing Days] [[Категория:Конференции (...»

Записи первого трека конференции Ukrainian Testing Days

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

Подбор топ-менеджера — процедура ювелирная

2012-09-27T14:30:44Z

AlexandraVelyaninova: переименовал Подбор топ-менеджера - процедура ювелирная в Подбор топ-менеджера — процедура ювелирная

Евгения Удалова: Руководитель службы персонала CUSTIS

Интервью опубликовано в журнале «Служба кадров и персонал», № 10-2011.

СК: Не секрет, что хороший топ на дороге не валяется. Есть ли дефицит топов вообще — в каких отраслях, в каких направлениях? В вашей компании — в частности?

Е.У.: Не берусь сказать, в каких отраслях или направлениях наблюдается дефицит топов. Мои обобщения скорее базируются на опыте работы в конкретной компании — CUSTIS, которая специализируется на заказной разработке и внедрении масштабных учетно-аналитических систем. Дефицит есть, при этом мы понимаем, что он обусловлен сложностью подбора и привлечения таких специалистов в компанию. То есть речь идет не о том, что таких специалистов мало на рынке, а о том, что мало таких, которые нужны именно вам и которые хотят работать у вас. Причина лежит на пересечении интересов двух сторон: требования и ожидания компании и привлекательность компании для топа.

Прокомментирую подробнее.

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

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

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

Привлекательность компании для топа, как правило, зависит от:

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

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

СК: Как ваша компания закрывает подобные вакансии?

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

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

Растить своих топов, с одной стороны, благородно и правильно, а с другой — сложно и хлопотно.

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

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

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

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

СК: Особенности интервью с топом: он, как правило, человек занятой и знает себе цену. Как с ним вести беседу, как долго, о чем спрашивать (и не спрашивать!), на что обращать внимание, как распознать «золотой самородок», а как — болтуна-госаппаратчика?

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

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

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

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

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

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

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

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

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

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

При подборе топ-менеджеров для структуризации ощущений и впечатлений мы используем код РАEI, предложенный И. Адизесом (P — Производитель, A — Администратор, E — Предприниматель и I — Интегратор). Это позволяет классифицировать и сравнивать разных соискателей друг с другом. В зависимости от контекста и задач, которые будут стоять перед топом, нужные комбинации кода могут быть разными, определение требуемой комбинации помогает нам принять решение.

СК:Чем можно заинтересовать искушенного топа — дополнительными бонусами, долей в бизнесе — лишь бы заполучить его?!

Е.У.: Если топ заинтересован исключительно в компенсации (краткосрочной или долго-срочной) — это плачевный вариант, на мой взгляд. Да, его можно «заманить», предложив дополнительный бонус или долю в бизнесе, но поможет ли это решению ваших стратегических задач по развитию компании? Останется ли он с вами в сложную пору перемен, если его интересует только бонус? Мне кажется, что если ему не интересно получение нового опыта в вашей компании и его не вдохновляют сложные задачи, требующие высокого профессионализма, то нет смысла «заманивать» его бонусами.

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

СК: Какими методами потом оцениваете эффективность топа и эффективность работы по его подбору (эйчара, агентства и т.д.)?

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

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

Первый — 3-5 месяцев работы в компании. Руководитель должен:

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

Второй — 1-1,5 года работы в компании. Должны быть достигнуты какие-то конкретные, согласованные с первым лицом, цели.

Третий — работа в компании более 1,5 года. Правильно оценивать эффективность работы топа по двум основным критериям: результаты по текущим обязательствам вверенного ему подразделения и его вклад в развитие компании в целом.

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

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

Продвижение HR-бренда в соцсетях

2012-09-26T14:02:22Z

AlexandraVelyaninova:

Евгения Удалова, руководитель службы персонала, рассказала порталу «Планета HR» об использовании социальных сетей для продвижения бренда работодателя. О чем стоит рассказывать аудитории соцсетей? Как поставить генерацию интересного контента «на поток»? Для чего нужно вовлекать в эту деятельность IT-специалистов? Обо всем этом — в материале «Вызывайте эмоции — и молодежь к вам потянется» на крупнейшем портале о кадровом рынке.

«Планета HR»: IT-компания 5G начала продвижение своего HR-бренда в социальных сетях, т. к. заинтересована в привлечении большого числа студентов и выпускников. За контент и коммуникации отвечают сотрудники отдела подбора персонала. Однако, написав несколько публикаций о возможностях стажировок в компании и днях открытых дверей, они обнаружили, что испытывают трудности с поиском новых интересных тем. Как бы вы предложили решить задачу регулярной генерации интересного контента?

Евгения Удалова: На мой взгляд, поставленную задачу нужно разделить на две части:

определить круг тем, интересных и студентам, и компании;

организовать процесс генерации контента.

Вначале стоит набросать «карту» контента:

перечислить темы, которые компания готова освещать;

выделить те из них, которые могут быть интересны студентам;

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

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

О чем можно писать в контексте взаимодействия со студентами:

публиковать анонсы мероприятий, которые компания собирается проводить в ближайшее время, и отчеты по прошедшим событиям (например, «как у нас прошел день открытых дверей» с фотографиями и впечатлениями участников);

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

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

Кроме того, можно (и нужно!) поддерживать свой HR-бренд и писать о жизни компании в целом:

рассказывать, как устроен офис и рабочие места, показывать фотографии;

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

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

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

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

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

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

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

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

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

Важно следить за качеством материала и его соответствием общей стилистике — здесь неоценимую помощь может оказать PR-менеджер.

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

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

Внутреннее обучение: слагаемые успеха

2012-09-18T15:08:19Z

AlexandraVelyaninova:

На портале «Планета HR» опубликован комментарий руководителя службы персонала Евгении Удаловой о том, как следует подходить к внутреннему обучению. С чего начать, запуская программу обучения новых сотрудников? Каким вопросам стоит уделить особое внимание? Почему так важно заручиться реальной поддержкой руководителей? Об этом — в материале на крупнейшем портале, посвященном Human Resources. Мы публикуем полную версию комментария Евгении.

«Планета HR»: Розничная сеть QQ активно расширяется и открывает новые торговые точки. На позицию продавец планируется набор молодых людей без опыта работы в торговле, которым предлагается в течение месяца пройти программу адаптации и обучения (первая неделя чисто учебная, далее — на рабочем месте). Каковы, на ваш взгляд, необходимые составляющие успешной программы вводного обучения?

Евгения Удалова: Можно выделить несколько слагаемых успеха:

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

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

Итак, на данном этапе организаторы программы должны четко понимать:

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

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

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

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

Есть и минимальные, «гигиенические» требования, без которых проект компании QQ вряд ли будет успешным:

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

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

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

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

Системы, которых должен знать каждый QA (Стас Фомин на встрече MSTC 2012-12-16)

2012-08-30T12:31:07Z

StasFomin:

Докладчик: Стас Фомин.

Краткая выжимка

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

репозиториев исходного кода (вотчина программистов),

хранилищ документации и требований (город серьезных аналитиков, архитекторов, юзабилистов),

систем планирования и управления задачами (зона менеджеров).

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

Можно примерять различные модели командной работы и типологии личности (модели Адизеса, Белбина, Юнга), и во всех случаях, тестировщики («Администраторы» по Адизесу, и «Контроллеры» по Юнгу), равнозначно комплиментарны программистам («Производителям» и «Предпринимателям» по Адизесу, «Анализаторам» и «Моторам» по Юнгу). Если программисты ориентированы на прорыв, риски и глобальные выигрыши (иначе это слабые, негодные программисты), на поиск наиболее экономичных стратегий реализации, то именно QA должны ограничивать эти процессы, страхуясь от рисков потери временных ресурсов (waste времени, кода) и потери потребителя (срыв сроков, нарушение требований, неудовлетворенность пользователя). ---
И в ситуации, когда тестировщики не имеют иерархических преимуществ («менеджер проекта=QA»), самый эффективный из конструктивных и неконфликтных путей системного контроля качества разработки, это создание и управление инфраструктурой разработки, такой, что не сильно затруднит, и даже поможет работе программиста, и при этом даст возможность QA-специалистам держать контроль над процессом — страхуясь от различных программистких рисков («потеря кода», «сброс кодовых бомб», «неизлечимо завшивевший багами код» …).
Это выглядит нескольно нонсенсом — разве не система контроля версий является инструментом программистов и только их самих? Увы, нет — предоставленные сами себе, программисты вполне могут разменять перечисленные риски на дополнительные проценты личной эффективности, и например, вместо централизованной VCS с защищенным системой непрерывной интеграции^[1] основным стволом разработки, будут пользоваться партизанскими распределенными репозиториями на своих ноутбуках. Также не в их интересах учет трудозатрат, задач, трекинг ошибок. Так что вполне вероятен вариант, что в новой команде (или сильно запущенной старой), будут отсутствовать ключевые системы поддержки грамотной разработки, и если вы QA — то мягко и эволюционно внедрить их — это ваш цивилизационный долг, бремя белого человека. К тому же, сейчас опять-таки, часто нет границы по навыкам между программистом, и продвинутым тестировщиком-автоматизатором, — последний вполне может быть «круче» первого в программировании, и вся инфраструктура поддержки разработки нужна и тестировщику напрямую.
Далее, в современной разработке все чаще стираются границы между аналитиками и тестировщиками (ну и сонмом смежных профессий — техническими писателями, внедренцами, техподдержкой). Соответственно, продвинутый тестировщик также должен владеть технологиями эффективной коллаборативной работы над требованиями и пользовательской документацией (границы между требованиями, пользовательской документацией и тестовыми сценариями — весьма и весьма условна). Значит, он также должен знать и разбираться групповых инструментах и для этих задач, также, как и в случая с программистами, борясь с рисками потери требований и прочих знаний.
Конечно, раньше, выбор инфраструктуры был прерогативной менеджмента, но часто это приводило к жутко неоптимальному выбору («Корпоративный стандарт управления версиями = СистемаМонстр™»), демотивирующему программистов, и современный менеджер скорее коммуникатор/психолог, а технические вопросы оставляет на выбор команде.
Таким образом, тестировщикам совершенно необходимо знать некий минимум эффективных систем групповой работы, которых они смогут эффективно внедрить в компании, в случае обнаружения «функциональных дыр», и при этом не прибегая к насилию. Причем минимальность и легковесность решения очень важна — ведь сложное, перегруженное лишним функционалом решение будет встречено в штыки, и сможет быть внедрено только сверху, властью менеджмента.
Таких решений (платных и бесплатных) можно придумать множество, мы же расскажем о нашем — наверняка не самом худшем, проверенным многолетним опытом и основанном на бесплатных и свободно доступных системах с открытым исходным кодом. Мы познакомимся с несколькими системами групповой работы, покрывающими весь спектр современной разработки, а именно, системами:

Issue-трекинга

(в нашем случае Bugzilla + Testopia) — учет задач, заданий, ошибок, проблем и отвественности любого рода, в частности, тест-планов, тест-прогонов и т.п.

Вики-системой

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

Системой управления версиями

у нас Subversion — известнейшая централизованная система управления исходным кодом, а также смежными с ней системами SVNSearcher и ViewVC.

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

Видео

Доклады на эту тему, в общих чертах уже были и ранее, причем доступны для самостоятельного просмотра ([1], [2], [3], [4]), однако, видео с конференций смотрят мало, а лично и тем более редко кто ходит, так что ни для кого в зале это не было баяном от К.О.

↑ Continuous Integration, — концепция непрерывного тестирования по малейшему изменению в хранилище кода.

Репликация: База Знаний «Заказных Информ Систем» → «Системы, которых должен знать каждый QA (Стас Фомин на встрече MSTC 2012-12-16)»

Запад и Япония: два взгляда на бизнес-процессы

2012-08-23T13:28:48Z

AlexandraVelyaninova:

На сайте Software People опубликована статья «Запад и Япония: два взгляда на бизнес-процессы» нашего главного архитектора Максима Цепкова. Максим делится с читателями блога конференции своими мыслями о различиях европейского и японского подходов к моделированию бизнес-процессов.

Эта статья обязана своим появлением двум людям. Первый — Susumu Sasabe, который делал доклад в Киеве на конференции SQA Days, а на следующий день более трех часов отвечал на вопросы вместе с другими участниками. Слушая его и сравнивая его описания различных процессов в самых разных областях — IT, индустрии, образовании — с представлениями, которые просматривались в вопросах и ответах других участников, я смог сформулировать для себя, чем японский взгляд на процессы как таковые отличается от западного.

Второй вдохновитель — Paul Terner, из доклада которого на конференции Analyst Days в Минске я почерпнул хорошую визуальную метафору, отражающую эти различия.

Итак, начнем.

Американцы и европейцы, когда говорят о бизнес-процессах, представляют некую исходную картину as is. Чтобы внести изменения, они проектируют желаемую картину to be, разрабатывают roadmap изменений и следуют ему. Обе картины — as is и to be — статичны во времени, то есть неявно предполагается, что бизнес-процессам присуще сохранение и воспроизведение текущего состояния, а для их изменения необходима направленная деятельность менеджера. Это, конечно, большое упрощение: всем известно, что менеджеры должны еще и поддерживать бизнес-процессы, которые, вопреки теории, не склонны оставаться в статичном состоянии. Однако, теория предполагает, что механизмы поддержки встроены в хороший бизнес-процесс, работа менеджера протекает в условиях статичных процессов, а его задачей является их изменение — перевод из одного статичного состояния в другое.

Европейский подход к моделированию бизнес-процессов

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

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

Японский взгляд на изменение бизнес-процессов

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

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

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

Теперь перейдем к визуальной метафоре.

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

Метафора европейского пути к желаемому результату

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

Метафора японского пути к цели

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

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

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

Какой способ представления более адекватен для конкретных процессов, естественно, зависит от их изменчивости и предсказуемости. Но, если говорить о глобальных тенденциях, современный мир динамичен, и его турбулентность склонна увеличиваться. Это делает время принятия решений критичным, а японский подход — предпочтительным. Особенно в IT, поскольку наша отрасль развивается быстрее других. Думаю, именно этим объясняется популярность в ней японских методов.

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

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

Системы Управления Версиями (семинар 2012-07-03)

2012-07-31T16:40:39Z

StasFomin: /* Видео */

Вчерашние выпускники — сегодняшние специалисты

2012-07-16T12:19:03Z

KseniyaKirillova:

Ведущие специалисты отдела персонала Дмитрий Звонарев и Евгения Лопатина поделились с порталом E-xecutive.ru своим опытом работы с молодыми специалистами. Какие они, вчерашние выпускники вузов? Готовы ли они к участию в коммерческих проектах и чем рискует компания, приглашая на работу недавнего студента? Зачем современным компаниям «молодая кровь»? Мнения HR-специалистов разных компаний — в материале «Свежая кровь: наглядное пособие для кадрового вампира». Мы публикуем полную версию комментария Дмитрия и Евгении.

Многопоточные приложения (.Net, Windows) (часть вторая) (семинар 2012-06-19)

2012-07-12T17:36:54Z

StasFomin:

Ведущий: Дутиков Михаил
Дата: 19 июня 2012

Как выстроить разработку сервиса под несколько мобильных платформ (Виктор Кузьмин, ADD-2012)

2012-06-26T19:06:23Z

StasFomin: /* Видео */

Microsoft + Node.js = LOVE! (Владимир Юнев, ADD-2012)

2012-06-26T13:58:30Z

StasFomin: /* Видео */

Высокая кухня клиентоориентированности

2012-06-26T10:11:58Z

AlexandraVelyaninova:

В журнале Intelligent Enterprise (№5/2012) опубликована статья заместителя генерального директора по стратегическим проектам Михаила Заборова и директора по маркетингу и продажам Максима Михалева, посвященная клиентоориентированной автоматизации. Как сделать процесс оказания сложной услуги по созданию (или серьезной кастомизации) масштабного ИТ-решения класса ERP максимально прозрачным и «приятным» для клиента и добиться при этом качественного результата? Как найти профессионального и ответственного подрядчика, который будет ориентироваться на интересы заказчика и доведет проект до результативного внедрения? Эти вопросы чрезвычайно остро стоят перед поставщиками и заказчиками крупных ИТ-решений, и наши специалисты предлагают свое видение проблемы и путей ее решения.

Если угождаешь, угождай каждому по-своему.
(Филип Дормер Стенхоп Честерфилд)

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

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