Enumerator и хранение прав доступа.

В Linux-подобных системах для определения прав доступа, используются паттерны rwx для владельца (owner), группы (group) и всех (all), таким образом получается последовательность вида rwx-rwx-rwx, которая однозначно может быть определена бинарной последовательностью, а в итоге чем-то вроде 777, 555 или 577, что очень легко читается и воспринимается.

Вышеописанная схема натолкнула меня на мысль об использовании подобной схемы в C# с енумераторами (enums) для определения прав доступа к чему-либо. Итак, начнем по порядку. Создадим енумератор:

public enum AccessLevel : int
{
    Read = 1,
    Write = 2,
    Execute = 4
}

Здесь основную роль играет последовательность 1, 2, 4, 8, 16  и т.д., что же она нам дает? А дает нам она следующее: мы можем с легкостью определить любые уникальные комбинации, исходя из суммы этих значений:

Read	001	1
Write	010	2
Execute	100	4

То есть, Read + Execute = 5, Write + Execute = 6 и т.д. В программе это будет выглядеть следующим образом:

int chmod = (int)(AccessLevel.Read | AccessLevel.Execute);

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

if ((chmod & AccessLevel.Read) != 0)
    // true
if ((chmod & AccessLevel.Write) != 0)
    // false
if ((chmod & AccessLevel.Execute) != 0)
    // true

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

Идеология разработки. Выпуск версий.

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

1. Выбирается дата выпуска очередной версии;
2. За неделю до выпуска производится бранчевание (branching) – для будущей версии создается бранч (branch), т.е. создается копия всего кода в отдельную дирректорию;
3. Далее вработа ведется по двум направлениям: фикс багов (коммиты идут в бранч) и добавление функциональности (коммиты идут в основную ветку);
4. В момент выпуска версии, все изменения в бранче переносятся в основную ветку, после чего бранч переносится в тег (tag), сохраняя снэпшот (snapshot) текущего кода под определенной версией;
5. После выпуска работа полностью возвращается в основную ветку.

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

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

Идеология разработки. Версионный контроль.

За последние три года я настолько сжился с простейшей коммандой “svn ci”, что даже трудно представить, что раньше я пытался всеми силами избежать этого, отказывался от использования корпоративного репозитория, а складировал все скрипты (тогда я писал на PHP) архивами по версиям и датам, что-то вроде “kb-1.2.1-12.04.2006.zip”. А чем не версионный контроль? – Думал я. – Зачем все усложнять какими-то странными командами? Так шли дни, недели, месяцы, пока однажды не возникла необходимость слить изменения из трех различных архивов в новую ветку – на эту простую операцию у меня ушло больше дня. Тогда я все-таки поддался на уговоры и все накопившиеся архивы закоммитил в новенький репозиторий. Сейчас в моем рабочем репозитории находится более 70 тысяч строк кода, в личном – более 120.

Итак, даже несмотря на то, что я предпочитаю разработку под Windows, а самой удобной средой считаю VS – для версионирования использую не TFS (стоит уж очень дорого), не Source Safe (уж очень он малофункционален), а Subversion (и даже принимал небольшое участие в его разработке).

Для тех кто предпочитает графические интерфейся, для Subversion есть Tortoise SVN (http://tortoisesvn.tigris.org/), но по мне – так консольный вариант куда удобнее, да и основное общение сведется к простейшим коммандам:

> svn co [repository] [dir]	Создает новую рабочую копию репозитория по указанному пути.
> svn status	Отображает статус текущей рабочей копии.
> svn up	Обновляет текущую копию до последней ревизии.
> svn add [path]	Добавляет путь под версионный контроль.
> svn ci	Коммитит все изменения в текущей рабочей копии в репозиторий.

Вот и все, этих знаний предостаточно что бы иметь версионированный код. А для тех кто хочет знать больше – всегда доступна “Svn Book” (http://svnbook.red-bean.com/).

“Hello World!” на родном языке блога.

using System;
using System.Text;

namespace ConsoleApplication
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine(“Hello World!”);
        }
    }
}