Укрощение автопрокрутки

Люблю я Delphi. И нравятся мне в ней такие фичи, как: Ctrl+Shift+Enter (Find Local References), Ctrl+Shift+E (Refactor Rename), и многие другие. Вот окошки озвученных фич у меня расположены как-то так:
image
Мне так удобнее – слева от редактора кода. А когда результаты поиска большие (или список для рефакторинга большой) – то на экране так больше помещается. Есть один минус – при клике в строчку, которая не помещается на экране по ширине – происходит автоматическая прокрутка по горизонтали (на картинке выше такая строчка выделена подчёркиванием). Т.е. дерево уезжает влево и родительские узлы прячутся за прокруткой – меня это сильно отвлекает и раздражает.
Не секрет, что эти деревья реализованы на VirtualTreeView-компоненте, поэтому такое “лечится” в одно действие:

  VTV.TreeOptions.AutoOptions := VTV.TreeOptions.AutoOptions + [toDisableAutoscrollOnFocus];

Добавляем в пакет, устанавливаем – и готово!
Исходники доступны по ссылке.
P.S.: Однажды я писал, как боролся со шрифтом Object Inspector’а Delphi XE7. Чуть позже я доработал тот пакет, чтобы он исправлял шрифт и в остальных окошках/вкладках. Но оно не прижилось – среда время-от времени восстанавливает свой шрифт – получается вообще ерунда – шрифт скачет туда-сюда. Странное поведение. Но оно исчезает, если отключить модную тему оформления, которая установлена как обычный пакет (ModernTheme210.bpl). Отключить можно через реестр:
image
Отключив этот пакет, все иконки вернутся к старому стилю, зато IDE будет работать чуть стабильнее (у меня было несколько ошибок с указанием на ModernTheme210.bpl), и не надо мудрить со шрифтами.

Читать на сайте автора.

Собираем базу Android приложений разработанных с использованием RAD Studio

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

Читать на сайте автора.

Кроссплатформенный квест

Читать на сайте автора.

Заначка

 — что-либо прибережённое, припрятанное про запас ◆ Опять же всё расставив по местам, как и было, достал из-за трюмо тёткину заначку — вскрытую пачку «Любительских», — закурил. Андрей Битов, «Сад», 1960–1963 г. (цитата из Национального

http://alexander-bagel.blogspot.com/2014/11/store.html

Общее оформление файла

Эта заметка является продолжением к заметкам Стиль оформления кода. Вместо вступления, Настройки окружения и Регистр букв.

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

Копирайт

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

Следует разделять два уровня доступа к исходным текстам:

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

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

Начало

В зависимости от своего типа, файл начинается с одного из зарезервированных слов: package, program, library или unit. Следом за ним, через один пробел, следует имя файла (без расширения) с точкой с запятой на конце. Например:

unit UnitName;

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

Это требование исходит из соображений: в случае последовательного просмотра файлов из «продвинутых» файловых менеджеров — имя файла всегда находится на одном и том же уровне от начала файла, а в случае отсутствия копирайта переход к имени модуля осуществляется всего в три клавиши: Ctrl+Home, Ctrl+Right.

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

// UnitName.xml

Это удобно для быстрого перехода к редактированию указанного в комментарии файла по сочетанию Ctrl+Enter.

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

// UnitName.hst

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

Далее может следовать многострочный комментарий с описанием предназначения файла и нюансы его использования. Текст комментария обрамляется либо фигурными скобками { и }, либо парой (* и *) и отстоит от левого края на один отступ (см. пример). Однако вместо такого комментария рекомендуется использовать отдельный текстовый файл и его имя размещать в простом комментарии, например:

// UnitName.txt

После всех комментариев следуют директивы компилятора, относящиеся ко всему исходному тексту модуля. См. также: определения условной компиляции.

Секция uses

Зарезервированное слово uses занимает отдельную строку. Объявляемые далее модули группируются по принадлежности, а внутри группы располагаются в порядке использования (см. пример).

В секции implementation слово uses следует располагать после директив, относящихся ко всему разделу реализации модуля (см. пример).

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

Секция interface

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

var
  Form1: TForm1;

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

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

Секция implementation

Это секция реализации модуля. Она может быть пустой, либо содержать только код инициализации и/или финализации — это секции initialization и finalization.

Конец модуля

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

Директивы компилятора

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

Порядок объявления методов

В VCL принято сначала объявлять конструктор класса, затем деструктор, затем все методы в алфавитном порядке. Это удобно, когда реализуемый класс получается большим (содержит большое количество методов) и является законченным и готовым к использованию. Однако алфавитный порядок следования методов неудобен при чтении кода и при его сопровождении. Для удобства рекомендуется подход, описанный ниже.

При объявлении методов (в секции interface) сначала объявляются обработчики методов. Обработчики группируются по принципу их принадлежности — сначала обработчики формы (фрейма), затем обработчики остальных компонентов (Action’ов, кнопок, грида и т.п.). Внутри группы рекомендуется использовать порядок в соответствии порядка использования обработчиков в RunTime, т.е. сначала идут OnCreate, затем OnShow (или OnInit, OnLoadData, OnLoadState), а затем OnClose, OnDestroy (OnSaveState, OnSaveData, OnDone).

«Парные» методы можно располагать рядом, т.е. обработчики OnCreate/OnDestroy, OnShow/OnClose и т.п. Это удобно для контроля парности действий, выполняемых в таких обработчиках.

Для обработчиков событий Action’ов — сначала OnUpdate, затем OnExecute. Это положение вытекает из таких моментов:

  • Action.Execute всегда внутри себя сначала вызывает OnUpdate, а затем OnExecute, следование обработчиков в коде логично сопоставить с порядком вызова обработчиков. (Кстати, это документированная особенность TAction — обработчик OnExecute не будет вызван, если в OnUpdate свойство Action.Enabled сбрасывается в False.)
  • Читая код OnExecute часто приходится на какой-то момент переключаться на код обработчика OnUpdate, для глаз это удобнее делать, когда расстояние между обработчиками (ключевыми словами procedure) фиксированное. Как правило, код обработчика OnUpdate занимает одну-две строки, а код OnExecute может занимать и более 10 строк. Расположение обработчиков в порядке OnUpdate/OnExecute повышает скорость читаемости кода.

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

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

Пример

unit Example;
// Example.hst

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

{$I Common.inc}
{$ALIGN ON}
{$MINENUMSIZE 4}

interface

uses
  // Delphi units
  SysUtils, DateUtils, Windows, Classes, Forms,
  // My units
  MyUnit1, MyUnit2;

type
  TExample = class(TForm)
    procedure FormLocalize(Sender: TObject);
    // OnCreate, OnDestroy, OnShow, OnClose ...
  public
    constructor Create(AOwner: TComponent); override;
    destructor Destroy; override;
  end;

implementation

{$R *.dfm}

uses
  MyUnitA, MyUnitB;

{ TExample }

constructor TExample.Create(AOwner: TComponent);
begin
  inherited;
  // do something
end;

destructor TExample.Destroy;
begin
  // do something
  inherited;
end;

procedure TExample.FormLocalize(Sender: TObject);
begin
  {$include *.mui.inc}
end;

// OnCreate, OnDestroy, OnShow, OnClose ...

end.

Читать на сайте автора.

Регистр букв

Эта заметка является продолжением к заметкам Стиль оформления кода. Вместо вступления и Настройки окружения.

Регистр букв

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

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

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

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

Общее правило для идентификаторов

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

HINT: соглашение об именовании может содержать исключения из этого правила. Например идентификаторы вида: WM_ACTIVATE, DWORD, BITMAPFILEHEADER, some_table_filed и другие.

Если наименование идентификатора

то

Пример

1

состоит из одной буквы

допускается любой регистр

i, j, k: Integer;
s, t, u: string;
C: Cardinal;
D: TDateTime;

2

состоит из одного слова (в том числе аббревиатуры и сокращения)

начинается с заглавной буквы

Count
Value
Next
Rtti
Vcl
Db
Eof
Tmp
Src
Dst
Cnt

3

состоит из нескольких слов

слова пишутся слитно, каждое с заглавной буквы

FirstChar
DoSomethingElse
RttiContext
ItemsCnt

4

начинается с префикса, указывающего на тип идентификатора

префикс пишется строчными буквами

poScreenCenter
fsModal

btnOk
frmMain
acSetup

5

начинается с буквы, указывающей на вид идентификатора

буква пишется в верхнем регистре

SResourceString
EMyException
ISomeInterface
TAnotherType
FClassField
AMethodParameter
LLocalVariable

Директивы компилятора

Выбор регистра букв при написании директив компилятора сводится к простому правилу:

  • все однобуквенные директивы всегда записываются в верхнем регистре;
  • директивы, влияющие на текст компилируемого кода, записываются в нижнем регистре;
  • все остальные директивы — записываются в верхнем регистре.

Параметры всех директив пишутся в соответствии с общим правилом (см. выше).

Включение части кода из другого файла

Для включения (вставки) текста из указанного файла в текущий фрагмент кода при компиляции используется директива {$include} или {$I}.

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

{$I OurCompanyDefinitions.inc}

В противном случае используется полная форма, и записывается в нижнем регистре:

{$include SomeFileWithCode.inc}

Условная компиляция

Директивы условной компиляции кода, такие как {$define SomeSymbol}, {$ifdef SomeSymbol}, {$else}, {$endif} и т.п., пишутся в нижнем регистре.

См. также: определения условной компиляции.

Регионы

Редактор кода Delphi для удобства навигации позволяет сворачивать/разворачивать логические единицы исходного кода.

Для выделения произвольной части кода в сворачиваемую единицу используются регионы. Для этого необходимый текст обрамляется директивами {$region ‘Region Description’} и {$endregion}, которые пишутся в нижнем регистре. Описание региона (‘Region Description’) игнорируется компилятором, поэтому должно быть удобочитаемым и подчиняться правилам естественного языка.

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

Читать на сайте автора.

Настройки окружения

Эта заметка является продолжением к предыдущей.

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

Настройки окружения

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

  • масштабирование текста в ОС Windows должно быть установлено в 100%;
  • тема оформления ОС Windows должна быть классической (с использованием шрифта Tahoma по умолчанию).

Масштабирование текста

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

К сожалению в VCL механизм масштабирования содержит ошибки. Подробно об этом описано здесь.

На уровне BaseForms.pas большая часть проблем исправлена, но новый механизм масштабирования требует, чтобы все dfm-файлы проекта разрабатывались в едином PPI. На текущий момент это значение должно равняться 96.

Это настройка операционной системы, называется «масштабирование текста». Чтобы PPI равнялось 96, масштабирование должно быть установлено в 100%.

Тема оформления

В разных темах оформления используются разные шрифты и разные размеры неклиентских элементов диалоговых окон (строка заголовка, граница окна, полосы прокрутки и другие). Это влияет на внешний вид разрабатываемых в Delphi форм (на разницу между значениями ClientWidth (ClientHeight) и Width (Height) формы, а также на высоту некоторых компонентов типа TEdit и TCombobox, для которых высота определяется по размеру шрифта). Использование разных тем оформления может привести к случайному/лишнему изменению свойств формы и её компонентов.

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

Настройки IDE

Настройки IDE Delphi — главное меню Tools Options. Эту настройку достаточно выполнить один раз, сразу после установки Delphi.

VCL Designer

Environment Options VCL Designer

VCLDesigner

Use designer guidelines необходимо сбросить.

Snap to grid – установить.

Grid size необходимо выставить именно в 4 и все компоненты располагать по сетке (Snap to grid) потому, что в Windows есть масштабирование. К числам, кратным 4, хорошо применяются стандартные масштабы текста – 75%, 125%, 150% и выше.

New forms as text – для того, чтобы новые dfm-файлы сохранялись в виде текстовых файлов; это необходимо при сравнении двух разных версий одного файла.

Auto create forms & data modules – выключено, т.к. формы создаются в Run-Time по мере необходимости.

Embedded designer – установить, настройка преследует две цели: а) избежать лишнего/случайного изменения положения формы (свойства Left и Top) в dfm-файл (когда программист просто подвинул форму, чтобы не мешала); б) вообще не сохранять эти свойства в dfm-файл (реализовано на уровне BaseForms – когда значения равны нулю, они не сохраняются).

Editor Options

Editor Options Display

Display

Right margin = 120 – значение 80 использовалось на старых мониторах; сейчас подавляющее большинство мониторов – широкоформатные, значение 120 является наиболее оптимальным как для чтения кода, так и по использованию экранного пространства. Именно это значение используется как максимально допустимая ширина строки в данном документе.

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

Formatter Options

Formatter Delphi Indentation

FmtIndentation

Formatter Delphi Spaces

FmtSpaces

Formatter Delphi Line breaks

FmtLineBreaks

Formatter Delphi Capitalization

FmtCapitalization

Formatter Delphi Align

FmtAlign

 

DDevExtensions

DDevExtensions – это расширение для IDE Delphi, скачивается и устанавливается отдельно со страницы: http://andy.jgknet.de/blog/ide-tools/ddevextensions/.

После установки необходимо выполнить настройку: IDE Delphi — главное меню Tools DDevExtensions Options.

Extended IDE Settings:

  • Disable alpha-sort class completion
    Эту настройку необходимо включить, т.к. данный документ вместо автоматического расположения методов в алфавитном порядке обязует это делать осмысленно — см. Порядок объявления методов

Form Designer:

  • Active
    Включить
  • Set TLabel.Margins.Bottom to zero
    Включить
  • Do not store the Explicit* properties into the DFM
    Включить

Пара комментариев

Первые два скриншота сделаны в Delphi 2010. От использования Delphi 7 мы отказались.

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

Насчёт масштабирования – на самом деле не важно, какое оно выставлено в системе. Важно, чтобы у всех членов команды оно было одинаковым (два момента: визуальное наследование и случайное/лишнее обновление dfm-файла). Есть ещё такой момент: определив его равным 100% я себе облегчаю задачу при описании правил создания пользовательских интерфейсов (grid size, размеры компонентов и расстояния между ними).

Читать на сайте автора.

сенсорных

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

http://alexander-bagel.blogspot.com/2014/10/multitouch-gestures-xe4.html

Работа с MapWindow GIS. Убираем ошибку floating point division by zero в 4.9.2

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

Мне уже задавали этот вопрос, а именно, что когда устанавливают компонент TMap на свою форму, а затем просто при компиляции проекта появляется ошибка: floating point division by zero. Если честно, то я не знаю, в какой момент она возникает. Может это связано с системой координат, либо еще что-то, но решается она очень и очень просто, по крайней мере, я так ее решил. Эту ошибку я наблюдал в Delphi 7, что касается других версий Delphi, я сказать ничего не могу, поэтому ее может просто и не быть.

Поэтому, если после обновления MapWindow GIS до версии 4.9.1 или 4.9.2 у Вас появляется подобная ошибка, то ниже будет описано, как ее можно решить. Мы просто отключим исключения, которые возникают с использованием чисел с плавающей точкой.

Для начала нам нужно объявить константу:

const MCW_EM = DWord($133f);

А затем на событие OnCreate формы, либо можно OnShow пишем следующий код:

Set8087CW(MCW_EM);

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

Гомельский государственный университет им. Франциска Скорины

Читать на сайте автора.

Стиль оформления кода. Вместо вступления

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

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

Неделю назад (17.10.2014) я попросил сообщество проголосовать. Голосование продолжается, но уже очевидно, что вопрос о стиле оформления кода в Delphi остаётся актуальным.

Немножко лирики

Если Вы утверждаете, что Вам всё равно, как оформлен код, то выделяйте пожалуйста, Вам ещё всё равно, или уже всё равно. И вот почему.

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

Затем, набивая раз за разом себе шишки о собственный же код, рано или поздно многие программисты “прозревают”, и по-тихоньку приходят к неким стилевым правилам самостоятельно. И это хорошо. Назовём такое прозрение первой ступенью.

Одно плохо. Чувство стиля – оно сугубо субъективно. При постоянном кодировании оно имеет тенденцию к развитию. И чем сильнее это чувство развито, тем больнее воспринимается “плохой” код. Назовём это второй ступенью, когда при чтении кода, оформленного в “другом” стиле вызываются негативные эмоции вплоть до не понимания кода.

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

И на нулевой ступени и на третьей – нам всё равно. Но между ними лежит огромная пропасть.

 

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

Проблема

Не существует общепринятых правил. Даже справка в самой Delphi пестрит разнообразием стилей (мол смотрите, вы можете написать и таК, и ТаК и ТАк, а мы это откомпилируем). Ну и конечно наследие: когда-то давно мониторы были маленькими, текста на экране помещалось мало, не было подсветки синтаксиса и т.п. А времена меняются, язык расширяется, среда IDE Delphi обзаводится всякими вкусностями… Мне вот становится очевидным, что должен быть официальный, поддерживаемый (обновляемый) документ с набором рекомендаций от Embarcadero. А придерживаться этого документа, или нет – конечно дело каждого. Но для фрилансеров (которые отдают свой код заказчику), бибилотеко/компонентописателей (которые публикуют свой код) и для программистских отделов/компаний (где работает более одного программиста) такой документ был бы крайне полезен. Мм.. преподавателей забыл упомянуть – это тоже важно.

Но чего нет – так нет. А когда самодисциплины не хватает – приходится самостоятельно составлять некую инструкцию и принимать её внутри компании. Конечно есть вещи, которые нельзя вынести за пределы компании, но я надеюсь получить документ, который можно будет опубликовать. (Т.е. в  итоге, наверное, будет два документа – общие требования и внутренние.)

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

С чего начать

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

А также:

 

Если у Вас есть полезные ссылки – добавляйте в комментарии. Если у Вас есть свой набор правил или свои инструкции – пишите, можно на e-mail (есть в профиле) или g+. Я постараюсь принять к сведению, может быть получится что-то обобщить.

 

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

Читать на сайте автора.