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

Как сказано на самом сайте, Fixie – Conventional Testing for .NET. Т.е. тестирование по соглашению. Под соглашениями здесь понимается то, к чему мы в целом привыкли – все операции выполняются на основе «устного» договора, джентельменского соглашения об именовании. Ближайший пример – scaffolding. Это когда мы договорились, например, что тестовые классы содержат слово Test, или что тестовые классы должны быть публичными и ничего не возвращать.  Тогда такие классы будут распознаны как тестовые. И больше никаких атрибутов и всего такого прочего. Просто классы и методы.

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

Установка и первый тест

По умолчанию, Fixie настроен так, что тестовыми классами является всё, что оканчивается на Tests. Тестовыми методами – всё что внутри этих классов и не возвращает значения. Т.е. теоретически и, на самом деле практически, вот такой код уже будет распознаваться как тест:

public class SuperHeroTests {
    public void NameShouldBeFilled() {
        var superHero = new SuperHero();

        superHero.Name
                 .Should()
                 .NotBeEmpty();
    }
}

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

Команда nuget для установки самого фреймворка. Но на этом всё не заканчивается. Фреймворк не предоставляет встроенного способа для написания проверок данных в тесте. Для их использования вам необходимо воспользоваться одним из сторонних решений:

• FluentAssertions
• Should
• Shouldly
• Что-то другое по этой же теме

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

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

Интеграция

Кстати о запуске тестов. Автор честно признается, что ему надо было запускать тесты из консоли и поэтому он сделал интеграцию со студией в последнюю очередь. Есть плагин для ReSharper, но он для версий от 8.1 до 8.3, т.е. с новой версией вы пролетарий. Ради тестов мне не хотелось откатываться на 8ю версию, поэтому не могу сказать насколько это комфортно.

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

Здесь, на мой взгляд, кроется потенциальное место ошибки. Очепятки. Не так-то сложно опечататься в слове “Tests”, что приведет к пропуску тестов. Визуально они никак не выделяются.  Справедливости ради надо сказать, что такая ситуация редка и маловероятна, если вы будете использовать правильные средства студии и запускать не скопом все тесты, а, например, только те, что раньше не запускались.

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

Чтобы два раза не возвращаться к теме обнаружения тестов и генерирования результатов документация нам сообщает, что Fixie может генерировать отчеты в стиле NUnit и xUnit, что значительно облегчит жизнь тем, у кого нормально построен CI.

Тюнинг

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

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

Все настройки происходят в конструкторе класса, наследованного от Convention.

public class CustomConvention   : Convention {
    public CustomConvention  () {
          
    }
}

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

public class DefaultConvention   : Convention {
    public DefaultConvention  () {
        Classes
            .NameEndsWith("Tests");

        Methods
            .Where(method => method.IsVoid());
    }
}

Код говорит о том, что тестовые классы должны заканчиваться на Tests и тестовым методом будет все что возвращает null. В целом годно.

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

Естественно, что любое правило лишь указывает на направление, а не является догмой.  «A Foolish Consistency is the Hobgoblin of Little Minds» – поэтому всегда надо руководствоваться здравым смыслом.

Глядя на свой список тестов, я вижу, что не все классы заканчиваются на слово Tests или начинаются с When.

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

В таком режиме именования, мне страшновато (да и лень) указывать ключевые слова по которым будут определены тестовые классы. Кроме того, подход When… Then… на практике означает, что есть настроечный метод, который запускается в начале каждого теста и в самом тесте либо проверяются результаты, либо как-то влияем на созданный объект. Т.е. надо явно будет пометить, или указать настроечный метод (SetUp).

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

public class SuperHeroTests {
    public void NameShouldBeFilled() {
        SetUpEnvironment();
        var superHero = new SuperHero();

        superHero.Name
                 .Should()
                 .NotBeEmpty();
    }
}

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

Fixie предлагает решение для этой ситуции. Вот оно:

public class DefaultConvention   : Convention {
    public DefaultConvention  () {
        Classes
            .NameEndsWith("Tests");

        Methods
            .Where(method => method.IsVoid());

        CaseExecution
            .Wrap<HeroUniverseSetup>();
    }
}

public class HeroUniverseSetup : CaseBehavior {
    public void Execute(Case context, Action next) {
        // реализация
    }
}

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

• CaseBehavior = [SetUp] / [TearDown]
• FixtureExecution = [FixtureSetUp] / [FixtureTearDown]

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

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

public class SuperHeroTests {
    public void NameShouldBeFilled() {
        var superHero = new SuperHero();

        superHero.Name
                 .Should()
                 .NotBeEmpty();
    }
}

Ничто не говорит мне, что есть SetUp/TearDown.

МАГИЯ!!! Вообще это интересно, но в данном случае нет. Я бы не хотел себе такую магию на проекте. Это совершенно противоречит тому, что тесты должны быть прозрачными. Даже если я в том же классе напишу расширение для CaseBehavior – это не решение, так как будет не очень очевидно где мне искать класс, в котором это все будет настроено. Заниматься постоянной копи-пастой тоже не выход.

Сравним:

public class DefaultConvention   : Convention {
    public DefaultConvention  () {
        Classes
	     .InTheSameNamespaceAs(typeof(DefaultConvention))
            .NameEndsWith("Tests");

        Methods
            .Where(method => method.IsVoid());

        CaseExecution
            .Wrap<HeroUniverseSetup>();
    }
}

public class HeroUniverseSetup : CaseBehavior {
    public void Execute(Case context, Action next) {
        // реализация
    }
}
public class SuperHeroTests {
    public void NameShouldBeFilled() {
        var superHero = new SuperHero();

        superHero.Name
                 .Should()
                 .NotBeEmpty();
    }
}

Против:

[TestFixture]
public class SuperHeroTests {
    [SetUp]
    public void Init() {
        // реализация
    }
    [Test]
    public void NameShouldBeFilled() {
        var superHero = new SuperHero();

        superHero.Name
                 .Should()
                 .NotBeEmpty();
    }
}

Строчек кода как-то будет поменьше в случае с NUnit, да и SetUp из класса не потеряется в проекте.

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

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

С помощью аттрибутов можно сделать

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

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

public class CustomConvention : Convention
{
    public CustomConvention()
    {
        var desiredCategories = Options["include"].ToArray();
        var shouldRunAll = !desiredCategories.Any();

        Classes
            .InTheSameNamespaceAs(typeof(CustomConvention))
            .NameEndsWith("Tests");

        Methods
            .Where(method => method.IsVoid())
            .Where(method => shouldRunAll || MethodHasAnyDesiredCategory(method, desiredCategories));

        if (!shouldRunAll)
        {
            Console.WriteLine("Categories: " + string.Join(", ", desiredCategories));
            Console.WriteLine();
        }
    }

    static bool MethodHasAnyDesiredCategory(MethodInfo method, string[] desiredCategories)
    {
        return Categories(method).Any(testCategory => desiredCategories.Contains(testCategory.Name));
    }

    static CategoryAttribute[] Categories(MethodInfo method)
    {
        return method.GetCustomAttributes<CategoryAttribute>(true).ToArray();
    }
}

И запуск:

Fixie.Console.exe path/to/your/test/project.dll —include CategoryA

Моё решение

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

Получается, что Fixie это метафреймворк для тестирования. Вы вольны построить какие угодно правила и возможности для тестирования, при этом строятся они достаточно просто, если честно. Вопрос только в целесообразности. А надо ли это всё делать? Немного отпугивает, конечно, отсутствие поддержи R#, и того, что я не вижу что тест – реально тест, и он оказался распознан фреймворком. В продакшене я бы не стал использовать, но для домашнего использования и как перспективное средство – Fixie очень интересен. По крайней мере, я точно вспомню его, если будет какая-то интересная и специфичная задача тестирования, которая будет трудно решаться стандартными средствами NUnit.

Hard’n’Heavy!

Джеф Ходжес в своем прекрасном посте «Заметки о распределенных системах для новичков» рекомендует использовать САР теорему для критики найденных решений. Многие похоже восприняли этот совет слишком близко к сердцу, описывая свои системы как «СР» (согласованность данных, но без постоянной доступности при сетевой распределенности), «АР» (доступность без согласованного состояния при сетевой распределенности), или иногда «СА» (означает «Я всё ещё не читал статью Коды (Coda Hale) почти 5-летней давности»).

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

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

САР использует слишком узкое определение

Если вы хотите ссылаться на САР как на теорему (а не на расплывчатый концепт в маркетинговых материалах к вашей базе данных), вы должны быть точны. Математика требует точности. Доказательство сохраняется только если вы вкладывается в слова, то же самое значение, что было использовано при доказательстве. И оно опирается на очень точные определения:

• Согласованность (Consistency) в САР на самом деле означает линеаризуемость, что является (и очень сильным) принципом согласованности. В частности, это не имеет ничего общего с «С» из ACID, даже если эта С так же означает «согласованность». Я на пальцах объясню, что такое линеаризуемость чуть позже.
• Доступность (Availability) в САР определено как «каждый запрос, полученный работающим узлом [базой данных] в системе должен приводить к ответу [не содержащему ошибок]». Недостаточно чтобы некоторые узлы могли обработать запрос: любой работающий узел должен быть способен обработать запрос. Множество так называемых «высокодоступных» (high abailability), т.е. с низким уровнем простоя, систем в реальности не отвечают определению доступности.
• Устойчивость к разделению (Partition tolerance) ужасное название – в общих словах означает что вы для связи используете асинхронную сеть, которая может терять или задерживать сообщения. Интернет и все датацентры обладают этим свойством, так что в реальности у вас нет выбора в этом контексте.

Еще хочу заметить, что САР теорема описывает не просто любую старую систему, но систему очень определенной модели:

• Модель системы в пространстве САР это единый узел\счетчик (register) чтения-записи – и всё. Например, ничего не говориться о транзакциях, которые затрагивают несколько объектов. Они просто за пределами условий теоремы, до тех пор, пока вы не ужмете каким-то образом те объекты до единого объекта.
• Единственный тип сбоя о котором упоминает САР теорема – сетевое разделение, т.е. узлы остаются активны, но сеть между некоторыми из них не работает. Такой вид ошибки так или иначе происходит, но это не единственная вещь, которая может пойти не так: узлы могут быть сломаны или в перезагрузке, может закончиться место на диске, можете поймать баг в ПО, и тд и тп. В процессе создания распределенной системы вам надо иметь ввиду гораздо больший спектр возможных ошибок и компромиссов, к которым они ведут. Слишком сильная фокусировка на САР теореме ведет к игнорированию других важных проблем.
• Более того, САР теорема ничего не говорит о латентности, которая беспокоит большинство разработчиков гораздо больше, нежели доступность. Фактически, САР-совместимые системы могут быть сколь угодно медленными и всё равно называться «доступными». Если доводить всё до крайности, я уверен, что ваши пользователи не будут склонны называть вашу систему «доступной», если для получения веб-страницы потребуется минуты 2.

Если ваше определение совпадает с формальным значением терминов в САР теореме, тогда она подходит вам. Но если вы даёте другое определение терминам согласованности и доступности, то нельзя ожидать того, что САР теорема применима к вам. Конечно, это не значит, что путем переопределения значений вы внезапно сможете сделать невозможные вещи! Просто вы не можете руководствоваться САР теоремой и использовать ее для аргументации в поддержку вашей точки зрения.

Линеаризуемость

В случае, если вы не знакомы с линеаризуемостью (в смысле «целостностью» в контексте САР), позвольте мне кратко рассказать об этом. Формальное определение не то чтобы очень понятное, но ключевая идея, если по-простому, такая:

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

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

Диаграмма иллюстрирует следующую ситуацию: Боб и Алиса находятся в одной комнате, оба проверяют свои телефоны, чтобы проверить результаты финальной игры на чемпионате мира по футболу 2014 года. Сразу после того, как счет был объявлен, Алиса обновляет страницу, видит победителя и радостно сообщает об этом Бобу. Он тут же жмет Обновить на своем телефоне, но его запрос попадает на реплицированную базу, которая слегка лагает, поэтому его телефон говорит, что игра всё ещё идет.

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

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

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

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

САР-доступность

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

Допустим у нас есть копии базы данных в двух разных датацентрах. Конкретный метод репликации в данном случае неважен – это может быть  single-leader (master/slave), multi-leader (master/master) или quorum-based репликация (Dynamo-style). Общий смысл репликации в том, чтобы при изменении данных в одном датацентре они отображались в другом. Представим, что клиенты связанны только с одним датацентром и должно быть еще одно соединение между датацентрами для реплицирования данных.

Теперь пусть соединение между ДЦ было прервано – это то, что мы подразумеваем под сетевым разделением. Что тогда случится?

Очевидно, что вы можете выбрать один из двух вариантов:

1. Приложение продолжает работать и позволяет запись в базу данных, оно полностью доступно для обоих датацентров. Но так как связь между ДЦ прервана, все изменения в одном ДЦ не будут доступны в другом. Это нарушает линеаризуемость (в терминах предыдущего примера, Алиса может быть отнесена к ДЦ1, а Боб к ДЦ2).
2. Если вы не хотите терять линеаризуемость, вы должны быть уверены, что вы осуществляете всё чтение и запись в одном датацентре, который вы можете называть ведущим. В другом ДЦ, данные которого не могут быть в актуальном сосотоянии из-за потери соединения, база данных должна прекратить обслуживать клиентов на чтение и запись до восстановления синхронизации. Так как зависимая база данных во втором ДЦ не может обрабатывать запросы, то она не САР-доступна.

Кстати, это по сути доказательство САР теоремы. В примере используются два ДЦ, но все может быть применено и к одному ДЦ, так как сетевые проблемы могут быть внутри тоже. Просто я подумал, что пример с двумя ДЦ более простой и наглядный.

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

Доступность (availability) на практике не то чтобы ссылается на САР-доступность. Доступность вашего приложения скорее всего измеряется в SLA (например, 99,9% правильных запросов должны возвращать результат в течении 1 секунды), но такое соглашение может быть реализовано в системах CAP-доступных и САР-недоступных.

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

Многие системы ни линеаризуемые, ни САР-доступные

Как же создавать системы с учетом строгих определений в САР-теореме для целостности (линеаризованности) и доступности?

Например, возьмите любую БД с репликацией и одним ведущим (single leader), что является стандартной настройкой для большинства реляционных баз данных. В такой конфигурации клиент не может писать в базу, если он отделен от ведущего. Даже если клиент может читать из копий (read-only recplica), тот факт, что он не может писать данные означает что любая настройка с единым ведущим не САР-доступна. И неважно, что такие системы часто позиционируются как «системы с высокой доступностью».

Если репликация с одним ведущим не САР-доступна, то делает ли это её «СР»? Погодите, не так быстро! Если вы разрешите приложению читать с реплик, а реплики асинхронные (по умолчанию для большинства БД), тогда зависимая БД может быть слегка устаревшей во время чтения. В этом случае чтение будет не линеаризованным, т.е. не CAP-согласованным.

Более того, базы данных с уровнем изоляции snapshot/MVCC намеренно нелинеаризованны, потому что требование линеаризации уменьшит количество одновременно выполняющихся операций (concurrency). Например, PostgreSQL SSI дает сериализуемость, но не линеаризуемость, с Оракл такая же ситуация. Только потому что база данных маркирована как ACID не означает, что БД удовлетворяет определению согласованности\непротиворечивости в CAP теореме.

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

А что насчет «NoSQL»? Для примера можно взять MongoDB: она имеет одного ведущего на шард (по крайней мере так предполагается, если это не режим split-brain), так что учитывая все сказанное выше, уже нет САР-доступности. И Кайл (Kyle) недавно показал, что это позволяет делать нелинеаризованное чтение даже при самом высоком уровне настроек согласованности, так что САР-согласованности нет так же.

Производные от Dynamo, такие как Riak, Cassandra и Voldemort, часто зовутся «АР» потому что оптимизированы для высокого уровня доступности? Ну, это зависит от ваших настроек. Если в реплики можно писать и читать данные (R=W=1) – они действительно CAP-available. Однако, если чтение и запись осуществляются кворумом (R+W>N) и у вас разделение по сети, клиенты находящиеся на стороне меньшинства не могут достучаться до кворума, получается что кворум операции так же не САР-доступны (как минимум временно, пока база данных не поднимет дополнительные реплики на стороне меньшинства).

Порой вы можете встречаться с людьми, которые утвержадют что чтение и запись на основе кворума гарантирует линеаризацию, но я думаю это будет не очень умно полагаться на это – хрупкая комбинация фич, таких как sloppy quorums и чтение с восстановлением (read repair) могут привести к хрупкой грани, когда мертвые восстанут удаленные записи восстановятся, или количество реплик упадет меньше оригинально числа писателей (нарушение условий кворума), или количество реплик превысит первоначальное N (опять нарушение условий кворума). Всё это ведет к нелинеаризованному получению данных.

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

Реальный пример: ZooKeeper

Что насчет ZooKeeper? Эта система использует алгоритм соглашений, поэтому многие сходятся во мнении что это чистый пример предпочтения согласованности над доступностью (т.е. «СР система»).

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

Вообще сделать линеаризованное чтение в ZooKeeper возможно используя sync перед командой чтения. Это не поведение по умолчанию, потому что получаем просадку по производительности. Команда sync используется, но не всё время.

Что насчет доступности в ZooKeeper? Что ж, ZK требует решение большинства для достижения соглашения для записи данных. Если у вас есть разделение на большинство и меньшинство нод, то большинство будет функционировать как прежде, однако ноды оставшиеся в меньшинстве не смогут обрабатывать запросы на запись, несмотря на то, что все они исправны. Получается, функция записи в ZK не САР-доступна в разделенном (partition) режиме функционирования (даже с учетом того, что большинство нод может записывать данные).

Чтобы добавить во всё это еще больше веселья, в версии ZooKeeper 3.4.0 добавили режим только для чтения, в котором ноды, оставшиеся в меньшинстве могут продолжать обслуживать запросы чтения – кворум не требуется! Т.е. режим для чтения является САР-доступным. Таким образом, ZK по умолчанию не является ни САР-согласованным («СР»), ни САР-доступным («АР») – это реально просто «Р». Впрочем, вы можете сделать систему «СР» используя метод sync, и только для операции чтения система «AP», если включить верные опции.

Но вот что раздражает: называть ZooKeeper «не согласованной» системой, просто потому что она нелинеаризуемая по умолчанию – действительно ужасная интерпретация фич. ZK на самом деле дает великолепную степень непротиворечивости! Он поддерживает atomic broadcast совместно с гарантированной casual consistency – что более сильное условие, чем read your writes, monotonic reads и consistent prefix reads вместе взятые. Документация говорит, что система дает последовательную непротиворечивость, но это недооценка самих себя, потому что ZooKeeper гарантирует более сильное определение, чем последовательная непротиворечивость.

СР/АР: ложная дихотомия

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

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

• В рамках одно приложения может существовать несколько разных операций с различными характеристиками согласованности данных.
• Множество систем не отвечают определению согласованности и доступности в рамках САР-теоремы. Однако я никогда не слышал, чтобы кто-то называл свою систему просто «Р», наверно потому что это плохо звучит. Но это не плохо – это может быть идеально спланированная архитектура, которая просто не попадает в категории СР/АР.
• Даже если большинство ПО не попадают точно в упомянутые категории, люди все равно стараются втиснуть его в одну из категорий, и получается, что неизбежно меняется смысл «согласованности» или «доступности» к тому, что они хотят под этим понимать. К сожалению, если значение слов меняется – САР теорема больше не может применятся, и разделение на СР/АР не имеет значения.
• Огромное количество нюансов теряется при попытке втиснуть систему в одну из двух категорий. Существует огромное количество аспектов касательно устойчивости к сбоям, латентности, простоты модели программирования, взаимодействия и так далее, что может быть использовано в проектировании распределенных систем. Физически невозможно закодировать все эти нюансы в одном бите информации. Например, даже ZooKeeper поддерживает «AP» в режиме только для чтения, и этот режим дает возможность читать записи в том же самом порядке как они были записаны – это гораздо сильнее, чем «АР» в таких системах как Riak или Cassandra – так что было бы нелепо складывать их в одну кучу.
• Даже Эрик Брюэр (Eric Brewer) признает, что САР вводит в заблуждение и слишком всё упрощает. В 2000 году было важно начать обсуждение компромиссов в распределенных системах, и это сработало. Не было намерения создать какой-то прорывной формальный документ или строгую классификацию схем для хранилищ данных. 15 лет спустя у нас появился гораздо более богатый набор инструментов с разными подходами к обеспечению целостности данных и защитой к ошибкам. САР сделала свою задачу и теперь время двигаться дальше.

Учитесь думать самостоятельно

Если «СР» и «АР» не подходят для описания и критики систем, что следует использовать взамен? Не думаю, что у меня есть единственный правильный ответ. Многие люди провели немало времени напряжено размышляя о проблемах распределенных систем, и предложили терминологию и модели, которые сейчас нам помогают понять проблемы. Чтобы узнать большое об этих идеях вам надо самостоятельно покопаться в литературе:

• Хорошей отправной точкой будет статья Дуга Терри где он разъясняет различия между разными уровнями частичной согласованности используя бейсбол для примера. Очень легко читается и понимается, даже если вы (так же, как и я) не американец и ничего не понимаете в бейсболе.
• Если вы хотите узнать побольше про модели транзакционной изоляции (что не то же самое что и согласованность в распределенных репликах, но близко), мой маленький проект Hermitage может помочь.
• Связь между согласованностью реплик, транзакциями и доступностью исследована Питером Баилисом (Peter Bailis). Документ так же объясняет значение иерархии уровней согласованности которые так любит показывать Кайл Кингсбери (Kyle Kingsbury).
• Когда вы всё это прочитаете, вы будете готовы копнуть глубже. Я перелопатил кучу ссылок и документов для этого поста – почитайте их, эксперты уже отлично описали многие вещи для вас.
• В качестве последнего довода, если вы не можете читать первоисточники, я предлагаю вам взглянуть на мою книгу, которая содержит и суммирует наиболее важные идеи в удобном виде. Видите, я старался очень сильно не сделать из поста рекламную речь.
• Если вас заинтересовала тема ZooKeeper и вы хотите обратить на него более детальный взгляд, то Flavio Junqueira и Benjamin Reed написали хорошую книгу.

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

Оригинал: https://martin.kleppmann.com/2015/05/11/please-stop-calling-databases-cp-or-ap.html

Хороший дизайн затрагивает URL, статус-коды, заголовки и содержимое запроса

Обычно руководства по проектированию Web API фокусируются на общих концепциях: как проектировать URL, как правильно использовать HTTP статус-коды, методы, что передавать в заголовках и как спроектировать дизайн содержимого, которое представлено сериализованными данными или графом объектов. Это всё очень важные детали реализации, но не настолько в смысле общего проектирования API. Проектирование API – это то, как сама суть сервиса будет описана и представлена, то что вносит значительный вклад в успех и удобность использования Web API.

Хороший процесс проектирования или методология предоставляют набор согласованных и воспроизводимых шагов для создания компонентов сервисов, которые будут доступны в виде Web API. Это значит, что такая прозрачная методология может быть использована разработчиками, дизайнерами и архитекторами для координации своих действий по реализации ПО. Использованная методология так же может уточнятся со временем по мере того, как улучшается и автоматизируется процесс без ущерба для деталей методологии. На самом деле, детали реализации могут меняться (например, платформа, ОС, фреймворки и стиль UI) независимо от процесса проектировки, когда эти две активности полностью разделены и задокументированы.

Проектирование API в 7 шагов.

Далее следует краткий обзор методологии описанной в книге «RESTful Web APIs» за авторством Ричардсона и Амундсена (Richardson and Amundsen). Статья не предполагает детального разбора каждого шага, но постарается дать общее понимание что делается на каждом шаге. Также, читатели могут использовать этот обзор как руководство для разработки процесса проектирования Web API, который учитывает специфику ваших знаний и целей бизнеса.

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

В своём плане вы должны учесть возможную итеративную природу процесса создания сервиса. Например, вы можете проходить через Шаг 2 (Создание диаграмм состояний) и понять, что надо еще кое-чего сделать в Шаге 1 (Перечислить все компоненты). Когда вы будете писать код (Шаг 6), вы можете обнаружить, что пропустили пару моментов в Шаге 5 (Создание семантического профиля), и так далее. Ключевой момент заключается в использовании руководства для обнаружения как можно большего количества деталей и желании возвращаться на шаг-два назад, чтобы описать пропущенные моменты. Итеративность – ключ к построению наиболее полного представления вашего сервиса и видению как он может быть использован клиентскими приложениями.

Шаг 1: Перечислить все компоненты

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

Например, простое приложения типа «Список дел», вы можете найти следующие семантические описания:

• id – уникальный идентификатор для каждой записи в системе
• title – название для каждого «дела»
• dateDue – дата, к которому «дело» должно быть завершено
• complete – «да/нет» флажок, который показывает завершено ли «дело»

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

Шаг 2: Нарисовать диаграмму состояний

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

Пока не стоит беспокоится на счёт определения какой метод используется для каждого перехода. Просто укажите является ли переход безопасным (HTTP GET), небезопасный/не идемпотентный (HTTP POST) или небезопасный/идемпотентный (PUT)

Заметки на полях: Идемпотентные действия – такие, которые можно повторять без неожиданных сайд-эффектов. Например, HTTP PUT является идемпотентным потому что спецификация говорит, что сервер должен использовать значения состояния, полученные от клиента, для замены любых значений в целевом ресурсе. В то время как HTTP POST не идемпотентен, так как спецификация HTTP указывается что значения, переданные с помощью POST должны быть добавлены к существующим ресурсам, а не замещены.

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

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

• read-list
• filter-list
• read-item
• create-item
• mark-complete

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

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

Шаг 3: Согласование магических строк

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

• schema.org
• microformats.org
• Dublin Core
• IANA Link Relation Values

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

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

Для To-Do сервиса из примера, у меня получилось найти приемлемые существующие имена для всех дескрипторов кроме одного – «create-item». В этом случае, я обратился к созданию уникального URI на основе правил из Web-Linking RFC 5988. Во время выбора конвенционных имён для интерфейса вас всегда будут преследовать компромиссы. Редко когда удаётся найти идеальное попадание к внутренним именам и это нормально.

Вот что у меня получилось:

• id ->identifier from Dublin Core 
• title ->name from Schema.org
• dueDate ->scheduledTime from Schema.org
• complete ->status from Schema.org
• read-list ->collection from IANA Link Relation Values
• filter-list ->search from IANA Link Relation Values
• read-item ->item from IANA Link Relation Values
• create-item -> http://mamund.com/rels/create-item using RFC5988
• mark-complete ->edit from IANA Link Relation Values

Итак, вот как стала выглядеть диаграмма после использования согласования имён:

Шаг 4: Выбор типа гипермедиа

Следующим шагом в процессе проектирования вашего API будет выбор типа данных, который будет использоваться для передачи сообщений между сервером и клиентом. Одним из отличительных знаков сети является то, что данные передаются стандартизированными документами через общий интерфейс. Очень важно выбрать такой тип, который поддерживает одинаково дескрипторы данных («identifier», «status») и действий («search», «edit»). Таких форматов достаточно мало.

Вот некоторые из гипермедиа форматов с вершины списка (порядок не имеет значения в этом списке):

• HyperText Markup Language (HTML)
• Hypertext Application Language (HAL)
• Collection+JSON (Cj)
• Siren
• JSON-API
• Uniform Basis for Exchanging Representations (UBER)

На выбор так же должно влиять то, насколько хорошо выбранный формат гипермедиа работает с протоколом передачи данных. Большинство разработчиков предпочитает протокол HTTP для интерфейса сервисов. Однако так же используются и  WebSockets, XMPP, MQTT и CoAP – особенно для высоко-скоростных реализаций, с короткими сообщениями, соединениями точка-точка.

Для нашего примера я буду использовать HTML как протокол сообщений и HTTP как протокол связи. HTML уже имеет поддержку необходимых дескрипторов (<UL> для списков, <LI> для элементов, и <SPAN> для данных). Так же в нем есть адекватная поддержка для дескрипторов действий (<A> для безопасных ссылок, <FORM method=»get»> для безопасных переходов и <FORM method=»post»> для небезопасных переходов).

Заметки на полях: Диаграмма состояний сейчас показывает «редактирование» как идемпотентное (HTTP PUT), но HTML до сих пор не имеет встроенной поддержки для PUT. Однако я могу добавить дополнительное поле чтобы эмулировать идемпотентный HTML POST.

Отлично, теперь я могу «опробовать» интерфейс основываясь на состояниях из диаграммы. Для нашего примера, нам надо описать только две вещи: «To-Do List» и «To-Do Item»:
Коллекция «To-Do List» в HTML представлении

<html>
  <head>
    <!-- for test display only -->
    <title>To Do List</title>
    <style>
      .name, .scheduledTime, .status, .item {display:block}
    </style>
  </head>
  <body>
    <!-- for test display only -->
    <h1>To-Do List</h1>
    <!-- to-do list collection -->
    <ul>
      <li>
        <a href="/list/1" rel="item" class="item">
          <span class="identifier">1</span>
        </a>
        <span class="name">First item in the list</span>
        <span class="scheduledTime">2014-12-01</span>
        <span class="status">pending</span>
      </li>
      <li>
        <a href="/list/2" rel="item" class="item">
          <span class="identifier">2</span>
        </a>
        <span class="name">Second item in the list</span>
        <span class="scheduledTime">2014-12-01</span>
        <span class="status">pending</span>
      </li>
      <li>
        <a href="/list/3" rel="item" class="item">
          <span class="identifier">3</span>
        </a>
        <span class="name">Third item in the list</span>
        <span class="scheduledTime">2014-12-01</span>
        <span class="status">complete</span>
      </li>
    </ul>
    <!-- search transition -->
    <form method="get" action="/list/" class="search">
      <legend>Search</legend>
      <input name="name" class="identifier" />
      <input type="submit" value="Name Search" />
    </form>
    <!-- create-item transition -->
    <form method="post" action="/list/" class=">
      <legend>Create Item</legend>
      <input name="name" class="name" />
      <input name="scheduledTime" class="scheduledTime" />
      <input type="submit" value="Create Item" />
    </form>
  </body>
</html>

Коллекция «To-Do Item» в HTML представлении

<html>
  <head>
    <!-- for test display only -->
    <title>To Do List</title>
    <style>
      .name, .scheduledTime, .status, .item, .collection {display:block}
    </style>
  </head>
  <body>
    <!-- for test display only -->
    <h1>To-Do Item</h1>
    <a href="/list/" rel="collection" class="collection">Back to List</a>
    <!-- to-do list collection -->
    <ul>
      <li>
        <a href="/list/1" rel="item" class="item">
          <span class="identifier">1</span>
        </a>
        <span class="name">First item in the list</span>
        <span class="scheduledTime">2014-12-01</span>
        <span class="status">pending</span>
      </li>
    </ul>
    <!-- edit transition -->
    <form method="post" action="/list/1" class="edit">
      <legend>Update Status</legend>
      <input type="hidden" name="etag" value="q1w2e3r4t5y6" class="etag" />
      <input type="text" name="status" value="pending" class="status" />
      <input type="submit" value="Update" />
    </form>
  </body>
</html>

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

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

Шаг 5: Создание семантического профиля

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

Следует чётко понимать, что это руководство по реализации, а не инструкция по реализации.

Форматы описания сервиса

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

Основные форматы, которые борются за сердца разработчиков:

• Web Service Definition Language (WSDL)
• Atom Service Description (AtomSvc)
• Web Application Description Language (WADL)
• Blueprint
• Swagger
• RESTful Application Modeling Language (RAML)

Форматы для описания профиля

Существует всего несколько форматов для описания профиля на данный момент. И вот те, которые я рекомендую:

• Application-Level Semantic Profiles (ALPS)
• JSON-LD+ Hydra

Оба формата достаточно новые. JSON-LD спецификация получила статус W3C Recommendation в начале 2014. Hydra все ещё в состоянии неофициального драфта (на момент написания статьи), но имеет активное сообщество разработчиков. ALPS так же находится на ранней стадии драфта.

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

<html>
<alps version="1.0">
  <doc>
    ALPS profile for InfoQ article on "API Design Methodology"
  </doc>
  <!-- data descriptors -->
  <descriptor id="identifier" type="semantic" ref=" />
  <descriptor id="name" type="semantic" ref=" />
  <descriptor id="scheduledTime" type="semantic" ref=" />
  <descriptor id="status" type="semantic" ref=" />
  <!-- action descriptors -->
  <descriptor id="collection" type="safe" ref=" />
  <descriptor id="item" type="safe" ref=">
    <descriptor href="#identifier" />
  </descriptor>
  <descriptor id="search" type="safe" ref=">
    <descriptor href="#name" />
  </descriptor>
  <descriptor id="create-item" type="unsafe" ref=">
    <descriptor href="#name" />
    <descriptor href="scheduledTime" />
  </descriptor>
  <descriptor id="edit" type="idempotent" ref=">
    <descriptor href="#identifier" />
    <descriptor href="#status" />
  </descriptor>
</alps>

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

Это так же замечательный формат для:

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

Но это тема для другой статьи.

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

Шаг 6: Написать немного кода

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

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

После того, как вы написали и стабилизировали ваш код, остаётся последний шаг из списка: Публикация.

Шаг 7: Публикация вашего API

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

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

В заключении

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

Ещё раз 7 шагов:

1. Перечислите все части
   Укажите все типы данных, которые необходимы клиенту для общения с сервисом.
2. Нарисуйте диаграмму состояний
   Задокументируйте все действия (переходы между состояниями), которые доступны для сервиса
3. Согласуйте магические переменные
   Приведите имена в вашем публичном интерфейсе к принятым стандартам
4. Выберите тип гипермедиа
   Выберите формат сообщений, который наиболее полно отображает переходы в сервисе с учётом выбранного протокола.
5. Создание семантического профиля
   Напишите документ, который будет содержать и определять все дескрипторы, используемые в сервисе
6. Напишите реализацию
   Распространите семантический профиль и диаграмму состояний среди разработчиков серверной и клиентской частей, чтобы они могли писать код в соответствии с рекомендациями и править профиль/диаграмму по мере необходимости.
7. Опубликуйте ваш API
   Опубликуйте «billboard URL» и семантический профиль, чтобы другие могли использовать их для создания новых сервисов и/или клиентские приложения.

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

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

Надеюсь эта статья дала вам пищу для размышления как построить оптимальную методологию по созданию API в вашей организации или команде.

Статья написана Майком Амундсеном, ведущим архитектором API в Layer 7 Technologies. Он так же известен как автор книг и спикер, консультант путешествующий по США и Европе.

http://www.infoq.com/articles/web-api-design-methodology

Комментарии. Jsonnet принимает комментарии в стиле С ( /* … */ ) и С++ (//)

Ссылки. Ключевое слово self может быть использовано для ссылки на текущий объект. Оператор $ позволяет использовать корневой объект.

Арифметические и условные операторы. Оператор + может складывать числа, строки, массивы и объекты. Операторы == и != возвращают true или false. Оператор if работает как тернарный оператор ?: в С. Далее несколько примером с операторами языка и результат. Примеры взяты со страницы проекта.

// bar_menu.3.jsonnet
{
    foo: 3,     
    bar: 2 * self.foo,  // Multiplication.
    baz: "The value " + self.bar + " is "
         + (if self.bar > 5 then "large" else "small") + ".",
    array: [1, 2, 3] + [4],
    obj: {a: 1, b: 2} + {b: 3, c: 4},
    equality: 1 == "1",
}

Результат:

{
   "foo": 3,
   "bar": 6,
   "baz": "The value 6 is large.",
   "array": [1, 2, 3, 4],
   "obj": {a: 1, b: 3, c: 4},
   "equality": false
}

Создание массивов и объектов. Для создания массивов и объектов используется конструкция с оператором for, как показано в примере ниже:

{
    foo: [1, 2, 3],
    bar: [x * x for x in self.foo if x >= 2],
    baz: { ["field" + x]: x for x in self.foo },
    obj: { ["foo" + "bar"]: 3 },
}

Результат:

{
   "foo": [ 1, 2, 3 ],
   "bar": [ 4, 9 ],
   "baz": {
      "field1": 1,
      "field2": 2,
      "field3": 3
   },
   "obj": { "foobar": 3 }
}

Модульность. Код написанный на Jsonnet может быть разбит на несколько файлов и затем объединятся с помощью оператора import. Внутренняя механика заключается в простом склеивании файлов.

Функции. Jsonnet значения могут содержать функции. Они помечаются как скрытые поля и не транслируются в JSON. Пример такой функции представлен ниже:

// bar_menu_utils.jsonnet
{
    equal_parts(size, ingredients)::
        if std.length(ingredients) == 0 then
            error "No ingredients specified."
        else [
            { kind: i, qty: size/std.length(ingredients) }
            for i in ingredients
        ],
    id:: function(x) x,
}

Jsonnet также включает в себя локальные переменные, способ для наследования объектов путём импортирования, вычисляемые и опциональные поля.

Движок языка написан на С++11 с предоставлением обёртки API в стиле С для более лёгкого портирования на другие языки. Команда разработчиков сразу может предоставить библиотеки для С и Питона. Реализация для С++ может быть скомпилирована в JS с Emscripten. Еще доступен неофициальный пакет для nodejs.

Полные спецификации можно посмотреть на странице спецификации.

Некоторое сравнение с другими языками

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

YAML. Так же является некоторым расширением JSON, который позволяет генерировать правильный JSON. Синтаксис языка очень компактный и файлы на YAML гораздо, короче чем они потом выходят в JSON формате. Несмотря на то, что язык создан в тех же целях, что и Jsonnet, создание, трансляция и уточнение данных проигрывает Jsonnet. В частности, YAML и Jsonnet имеют различные точки зрения на то, что должно означать «1+1». YAML говорит, что это строка «1+1», тогда как Jsonnet считает, что результат должен быть 2.

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

Сравнение с другими инструментами и языками, такими как Haskel, Nix, Coil, Pystachio и другими можно в деталях прочитать в руководстве к Jsonnet.

Вопросы и ответы

В оригинальном топике появились интересные вопросы и ответы от ведущего разработчика проекта Дэвида Каннингэма (David Cunningham).

Вопрос: Почему бы не воспользоваться уже существующим открытым стандартом EDN? На мой взгляд в нем есть все те же самые фичи и уже есть порты под разные языки.

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

Когда мы создавали Jsonnet, мы думали о том, что нам надо следовать общим стандартам. Мы выбрали JSON из-за его популярности, но мы так же пытались следовать существующим моделям программирования (главным образом js и python) так близко, как только возможно.

Хочу также заметить, что можно интегрировать Jsonnet в системы, которые работают с EDN, потому что возможно генерировать EDN с помощью нашей системы. Необходимо только написать специальную функцию «manifest». Такая работа проделана для INI файлов, конфигурационных файлов Lua и Python.

Наконец, Jsonnet доступна для 3х языков (С, Python, Javascript) и для любого языка, который может работать с С интерфейсом. Порты на другие языки запланированы, возможно с помощью портирования на Haxe.

Вопрос. Мне очень нравится проект, но разработчики должны были использовать стандартные JavaScript функции, а не изобретать из в stdlib. Базовые функции пропущены и добавление новых не простая задача, так что это своего рода ограничитель и я, к сожалению, вернулся на старый предпроцессор JSON.

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

В целом есть возможность расширить stdlib самостоятельно и написать свою собственную библиотеку для Jsonnet. Пример ниже сначала использует маленький трюк для добавления метода add2 в stdlib:

local std2 = std { // Temporarily define std2 to avoid self-reference.
   add2(x):: x + 2,
};
local std = std2; // Bind std2 over std.

// Rest of Jsonnet file below:
{
   foo: std.add2(10), // Expands to 12.
}

В общем случае, может быть невозможно скопировать функции из поддерживаемых языков, так как семантика может не иметь смысла в Jsonnet. Однако мы понимаем, что иметь необоснованные различия никому не поможет. И это является основной причиной, почему stdlib функции отвечающие за форматирование текста в точности совпадают с оператором % в Python.

На основе материалов:

• http://www.infoq.com/news/2015/04/jsonnet
• http://google.github.io/jsonnet/doc/

Сегодня хочу представить интересную презентацию Стефана Тилькова, со основателя и главного консультанта в innoQ. Стефан рассказывает об идее разделения больших систем на небольшие приложения, которые отвечают за разные аспекты системы. Сама идея не нова, но автор упирает на то, что основной причиной такого разделения должна быть изоляция. Благодаря границам приложений полученных таким образом, сложнее получить связанные модули, которые на самом деле должны быть независимыми. Тут еще можно вспомнить подход «domains boundary», для разделения доменных сущностей по областям применения, вместо того, чтобы создавать единую модель данных на всю большую организацию/процесс.

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

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

Рассматривая способ построения логических систем из малых частей, Тильков описывает три стиля:

• Микросервисы – маленькие программы, каждая из которых работает сама по себе. Используют простые механизмы для общения и строятся вокруг нужд бизнеса.
• Приложения – небольшие, отдельные, исполняемые программы, использующие модель «share nothing». Имеют много общего с микросервисами.
• Самодостаточные системы – это крупные автономные программы, которые содержат и данные и логику. Контролируются одной командой. Не используют синхронные удаленные вызовы, могут предоставлять API.

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

Наиболее интересным параметром для Тилькова является количество модулей в системе, потому что это показывает степень декомпозиции большой системы.  Большие системы в этом плане проигрывают, но микросервисы сложнее в поддержке и оркестровке, тем самым увеличивая уровень сложности системы. В общем, нет какого-то одного правильного решения, «серебряной пули» и мы на конференции API & Backend хотели бы поднять дискуссию на эту тему. Если у вас есть интересные случаи из практики касающиеся типичных проблем для той или иной модели, пути решения этих проблем – мы ждем ваших историй.

Hard’n’Heavy!

Для Сервис-ориентированной Архитектуры (Service Oriented Architecture, SOA) достижение начального успеха определяется:

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

Множество команд разработчиков разрабатывают и используют сервисы, но до сих пор идет мучительный подбор архитектуры, при которой сервисы будут широко использованы, с потенциалом для повторного использования внутренними командами разработки. Вместо создания согласованной сервисной архитектуры и демонстрации множественного использования одних и тех же сервисов, разработчики вновь и вновь не нарочно создают «Просто Набор Веб Сервисов» (Just a Bunch of Web Services (JBOWS)) или «Просто Набор REST Сервисов» (Just a Bunch of REST Services (JBORS)).

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

Управление SOA, API, и приложением может стать мостом между этими концепциями и улучшить архитектурную согласованность всего решения.

Сервисы, API и архитектура

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

Внешне, набор RESTful API просто специализированные версии веб-сервисов и предоставляют схожие технические возможности. Дизайн и REST API, и SOA сервисов предполагает раскрытие атомарной функциональности с помощью четко определенных интерфейсов. Публичный контракт (API) оконечной точки и сервисная оконечная точка служат базовыми единицами для построения ядра систем, и разработчики представляют свои решения путем управления доступа, агрегации, композиции и оркестровки взаимодействия оконечных точек. Успешное и расширяемое решение как для API, так и для SOA требует решить вопросы касающиеся:

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

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

Управляемые API это:

• Имеющие активную модель оповещений и дающие возможность подписки.
• Поставляющиеся с соглашением о доступности (service-level agreement (SLA)).
• Надежные, с авторизацией и аутентификацией, защищенные.
• С возможностью мониторинга и монетизацией аналитики.

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

Объединение управления для SOA и API может позволить командам продуктивно использовать плюсы как SOA сервисов (повторное использование и эволюционная реализация), так и API (расширенная область действия и расцепленные интерфейсы)

SOA управление

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

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

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

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

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

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

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

Портфолио сервисов это «А» в SOA

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

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

Управление API

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

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

Экономика API должна включать в себя замеры по полноте использования и нагрузке. Управление API в этом смысле включает в себя отслеживание API по использованию (по версии, по типу API) и нагрузке (по версии, по типу API), а также другие замеры и предписания. Через понимание использования и нагрузке на API – владельцы бизнеса и архитекторы API могут осознанно инвестировать в развитие, расширение инфраструктуры, оптимизировать структуру и полноту сервисов.

Лучшие практики по управлению

Для эффективного и продуктивного предоставления IT решений, команда разработчиков должна синхронизировать действия по управлению API и сервисов. Управление API включает в себя очевидный набор стадий развития (создание, публикация, сокращение, завершение поддержки, блокировка), каждый шаг которых может быть переопределен. Журналирование управления облегчает управление метаданными сервиса, дизайн, разработку, тестирование и оперативное вмешательство. Скриншот ниже показывает пересечение между двумя процессами управления:

Обобщенное описание требований

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

Лучшие практики REST начинают оказывать влияние на дизайн и описание систем. При создании RESTful API и SOA сервисов, следует обращать внимание на следующие моменты:

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

Документация по API и метаданных сервисов

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

• Общее представление (например, имя, описание)
• Атрибуты жизненного цикла (версия, зависимости от версий других сервисов, статус разработки/поддержки)
• Классификация (базовый сервис, составной, инфраструктурный, бизнес)
• Атрибуты оконечной точки (протокол, адрес, WS-* спецификации)
• Модель данных (схема JSON, RAML, XML, WSDL, версия, семантика, проверки)
• Требования и предписания на уровне сервиса (доступность, отзывчивость, безопасность, пропускная способность, емкость)
• Диспетчеризация (перенаправление, очередность, кэширование, трансформации)
• Зависимости (API, сервисы, базы данных, расположение, фреймворки)
• Физические зависимости (платформа для приложения, безопасность, управление)
• Модель бизнес-процессов (UML диаграммы, бизнес классификации)
• Информация о взаимодействии (потребители, поставщики, утилизация)
• Статистика используемости (количество пользователей, доступность, пропускная способность, пики по времени)
• Бухгалтерия и методы стимуляции (плата за показы, подписка, размеры возвратов)

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

Баланс в управлении

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

• Недостаточного образования, знаний, и поддержки со стороны знающих людей
• Недоверие или недостаток общения внутри организации
• Противоречивые стимулы
• Плохой дизайн самих по себе SOA/API
• Недостаток метрик
• Недостаток управления

Руководство является необходимым, но, если процессы управления являются обременительными, они будут вызывать недовольство и сопротивление. Процессы должны выглядеть натурально или автоматизированы при любом удобном случае. Например, соответствие каким-то правилам может проверяться автоматически при чекине или во время регистрации сервиса в системе. Ищите инструменты, которые могут органично встроится в рабочий процесс разработчиков, чтобы они могли легко и просто получать информацию от системы, что какая-то часть результата их работы не соответствует предписаниям и необходимо исправление. Системы управления контрактами (Contract management systems) могут иметь неоценимое значение в управлении потребления ресурсов, запросов на улучшение сервиса, в процессе управления жизненным циклом разработки, и версионировании API.

Дальнейшие шаги по организации управления API

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

• Организация централизованного ревью дизайна системы
• Усилить контроль за информационными моделями и способами их реализации
• Реализация контроля за соблюдением предписаний
• Создание общего соглашения об использовании сервисов
• Инвентаризация возможностей приложений и интеграционных возможностей
• Реализовать процесс пересмотра управления API для своевременного отражения изменений в каталоге возможностей ПО и сервисов.
• Расширить управление жизненным циклом ПО для сохранения сервис-ориентированности.

источник http://www.infoq.com/articles/converging-api-soa-governance

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

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

Hard’n’Heavy

12 ноября 2014 года блог WPF ожил (сейчас активен тоже) и был представлен генеральный план развития фреймворка.

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

В начале выступления, ведущие Уни Равиндранатан (Unni Ravindranathan) и Харикришна Менон (Harikrishna Menon) обмолвились, что есть вещи, которые еще находятся в разработке, и они не имеют права о них рассказывать, NDA и все такое. Но то что они могут показать, внушает оптимизм и видно, что работа идет. Забегая вперед, скажу, что прежде всего разработчики подумали о быстродействии, например, как сократить визуальное дерево для конкретной целевой платформы.

Ключевые области разработки показаны на скриншоте ниже:

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

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

Ближайшие планы по улучшению WPF

На портале Connect были пересмотрены и переоткрыты все баги, которые имели больше 10 голосов. И сейчас все еще есть возможность повлиять на то, какие фичи\баги будут разрабатываться.

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

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

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

Для использования прозрачных дочерних окон вам требуется Windows 8 и выше, а также .NET 4.5.2.

Ну и еще одна деталь, в app.manifest надо указать что эта фича поддерживается ОС. Т.е. в разделе application написать следующее:

<application>
<!— Windows 8—>
<supportedOS Id=»{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}»/>
</application>

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

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

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

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

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

Кроме этого очень много внимания уделяется обратной совместимости. Так как WPF системная вещь, то поддержка DX12 или построение части компонентов на основе DX12 может повлиять на некоторое количество уже выпущенных программ. Мы не можем кинуть их на произвол судьбы и обязаны найти какое-то решение, для обеспечения обратной совместимости. Это конечно большая проблема. Если касаться вопросов быстродействия, то изменения должны почувствовать максимальное количество пользователей.

AppLocal

Абсолютно новая вещь, которая до момента конференции не упоминалась нигде – это AppLocal. Наверно это самое большое изменение сейчас. Оно заключается в том, что WPF как платформа может быть доставлена с помощью пакета NuGet нужной версии. Т.е. каждая версия приложения поставляется со своей уникальной версией WPF. Разработчики гарантируют, что вы получите лучшее или такое же быстродействие по сравнению со встроенной версией. Чаще все же будет улучшение производительности.

Такая версия WPF будет совместима со встроенной, но в то же время, можно построить версии WPF поверх NetCore.

В качестве демонстрации работы новой версии WPF приводится демо с таким вот оформлением.

Для начала приложение загружается со сборками 4.5.2. Видно, что ссылки идут на старую версию при разработке и будет обращение к GAC в runtime.

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

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

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

После этого можно сделать сравнение с версией 4.5.2, на сколько сильно/слабо будет сокращено дерево элементов для графической интерфейса приложения. Итак, для достаточно простого интерфейса на версии .net 4.5.2 был создан 281 элемент.

После применения NuGet пакета с локальной версией WPF получилось 230.

Улучшение быстродействия

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

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

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

В этом контексте становится еще интереснее узнать, что же будет с WPF и Universal Application. Стоит ли мигрировать, сложно ли это и вообще в каких случаях стоит мигрировать, а в каких нет. Конечно, основные навыки по работе с WPF остаются востребованы и актуальны для Universal App, но отчего тогда столько шума? На эти вопросы ответит Костя Кичинский, эксперт по технологиям разработки программного обеспечения, Microsoft, на конференции Desktop UI & Business Application, которая состоится 11 апреля.

Доклад освящает основные вопросы касающиеся Universal App и WPF:

• Развитие WPF и появление WinRT
• Унификация Windows-платформы и UAP
• Инвестиции в WPF
• Как WPF стыкуется с UAP + матрица миграции (когда и как стоит мигрировать, а когда нет)

Приходите, будет интересно!

До этого были рассмотрены шаблоны, которые в той или иной степени получают профит от использования Аспектно-Ориентированного программирования. Однако есть один, который не получит никакой пользы от АОП. Сама суть шаблона «Фасад» заключается в том, чтобы выделить отдельный интерфейс для облегчения доступа к некоторой сложной подсистеме.

Википедия дает следующее определение:

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

С помощью аспектов не выделить отдельный класс для такого функционала.

По сути, исследователи признали, что только «Фасад» никоим образом из классических 23 шаблонов не может быть хотя бы частично реализован с помощью АОП.

Вот такой короткий рассказ.

Hard’n’Heavy!

Мы анонсировали конференцию, посвященную Desktop UI & Business Application. В поддержку, чтобы посмотреть на настроения публики, была опубликована статья «WPF живее всех живых», которая оказалась дискуссионной и заставила нас в несколько другом свете взглянуть, на то, что и как мы хотим донести до широкой публики.

Как показали комментарии, не WPF единым живет десктоп разработка. Есть порты Qt для .NET, есть WinRT, если в эпсилон окрестности от дефолт-сити есть спецы по этим технологиям, которые хотят высказаться – у нас есть трибуна! Для этого все и задумано, чтобы показать различные варианты для ваших проектов.

Буквально вчера закончилась онлайн конференция dotNetConf 2015, которую, исходя из сообщений, Microsoft скорее возродила, нежели придумала заново. Конференция, судя по содержанию старается покрыть все основные области использования языка, это мультиплатформенность, веб, десктоп, доставка приложений, интеграция с Xamarin, будущее .NET, .NET Core, Roslyn Analyzer и другие темы. На мой взгляд, это генеральная репетиция перед конференцией //build, которая состоится в конце апреля-начале мая.

Про золотые молотки

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

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

Это высказывание как нельзя лучше подходит ко многим областям разработки программного обеспечения. За примерами далеко ходить не надо. Как мне кажется, самая популярная тема относительно бэкенда: «Как лучше получить и записать данные в базу?» После этого часто дискуссия скатывается к одной из дисциплин Специальной олимпиады. Например, сейчас очень популярен EntityFramework, который уверенно теснит, или может быть уже потеснил NHibernate – старожила и монстра корпоративной разработки. Ничего не имею против NHibernate и EF, но когда все нужды проекта сводятся к чтению пары таблиц и вызову пары-тройки процедур, использование этих инструментов вызывает недоумение. Ведь есть Link2db (ex. BLToolkit), Dapper и куча других Micro ORM, которые могут быть легче в настройке и использовании, каждый может найти себе нужный инструмент. Даже базовые средства .NET Framework не стоит списывать со счетов.

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

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

На конференции Desktop UI & Business Application Андрей Колчанов, технический эксперт Flexberry platform, как раз расскажет об альтернативной ORM и сравнит использование и быстродействие в основных сценариях использования.

Кривая обучения

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

Когда долго работаешь над одним проектом, или используя один и тот же набор инструментов, то количество не обязательно переходит в качество. Можно производить одни и те же операции изо дня в день, набивать тупой код для клонирования объектов вручную и многие другие вещи, которые приводят к экономическому результату. В итоге приложение все же будет написано и возможно даже без сильного срыва сроков, потому что программисты будут печатать вслепую как лучшие стенографистки. Но это экстенсивный рост навыков, без глубины, без наполнения качеством. Почему-то даже луддиты вспоминаются. Наверно потому, что я опять вспоминаю тренерскую практику, когда у каждого установлен ReSharper, но никто, например, не использует Alt+Insert для создания шаблонных файлов, а также другие возможности. Но опыт использования может быть более 2х лет. Отчего же такое происходит?

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

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

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

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

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

Так почему же мы, команда GoSharp конференции (да, да, это о C#), решили сделать акцент на десктопной разработке в разрезе WPF? Далее я хочу показать какие светлые и темные моменты есть в существующем положении фреймворка и почему все же стоит в него вкладывать силы и время.

Существует мнение, что развитие десктопной разработки остановилось в своем развитии и для этого есть несколько предпосылок. Одна из них – остановка, или даже лучше сказать стагнация, в самой базе, в визуальном фреймворке WPF. Значительных обновлений для него не было вот уже лет 5, как может показаться. Официальный тулкит давно не обновлялся, точнее с февраля 2010 года, т.е. вот как раз те самые 5 лет. При этом компании, специализирующиеся на кастом-компонентах, как например DevExpress и Telerik успешно выпускают обновления и составляют планы на будущее относительно WPF. Даже если вы ориентированы на новинки, то компоненты для WinRT все равно используют концепции и общую структуру XAML, который никуда не уходит.
Далее мы хотим представить причины, по которым WPF некоторые считают неактуальным, и опровержение этих причин.

Причины для беспокойства

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

Блог команды WPF давно не обновлялся.

Так же, как и у любой другой команды, у команды WPF есть свой блог, в котором по идее должны быть описаны планы и достижения команды. К сожалению, в блоге давно нет новой информации. Это может натолкнуть на мысли, что всех разогнали или что писать не о чем. Однако, это не так и блог стал обновляться 4 месяца назад и последняя запись появилась 20 дней назад. Более того, появился генеральный план развития фреймворка, а также краткие описания новых фич доступных с последними CTP.

Официальный WPF тулкит давно не обновлялся

Официальная страница WPF Toolkit на CodePlex не обновлялась с 2010 года. А это ведь когда-то была площадка для обкатки новых компонентов, которые открыто допиливались и в случае успеха вливались в основные релизы фреймворка. Такое положение дел так же может внушать подозрения о том, что ничего нового нам ждать не приходится и останется только закупать компоненты у больших компаний или что-то делать на коленке, долго и мучительно, если это не профильное направление вашей деятельности. Но неофициальный тулкит Extended WPF Toolkit живее всех живых и последний релиз пришелся на 13 февраля 2015 года. Т.е. вот на прошлой неделе был. Этот тулкит поддерживает Xceed, но вложения идут в опенсорс проект, а значит они видят будущее за ним. Титульный баннер однозначно выражает оптимизм по этому счету.

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

Сертификация по WPF

В интернетах можно найти слухи и сообщения о том, что основная сертификация по WPF 70-511 заканчивается в 2015 году и не будет продлеваться. Это не является правдой, в чем вы можете убедиться лично, пройдя по ссылке.

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

Нет интеграции с Win8+

Во время релиза WPF4, значительная часть улучшений была посвящена интеграции с Windows 7, однако этого не наблюдается с новыми операционными системами. Уже на носу Windows 10, а никаких новых фич связанных с возможностями ОС в WPF не наблюдается.

Новая стратегия Microsoft

В феврале 2014 года новым СЕО стал Сатья Надела, который пришел из «облачного» департамента, что может намекать. Сатья заменил Балмера, который как-то не стремился развиваться в сторону мобильного рынка и облачных технологий. Возможно в этом кроется причина такого резкого рывка Microsoft в сторону мобильной разработки и такого продвижения Azure. Сейчас компания движется под лозунгом «сначала облака и мобильность», что ведет к отходу от традиционной модели настольных приложений и активного использования WPF.

Windows Store

Публикация WPF приложений в Windows Store невозможна. Можно сделать приложение визитку, которое загрузит и установит полновесное приложение, но это выглядит как обходной путь. Однако Microsoft пытается сформировать некоторый условный рефлекс, как у Apple и Android пользователей, что все приложения устанавливаются только через Store. Это так же является некоторым звоночком не в пользу WPF.

Мобильный рынок

Это сумеречная зона для WPF, так как он никогда не задумывался как средство для мобильной разработки. Эту роль прочили Silverlight for Windows Phone, однако всем известна судьба этой затеи. Реалии мира же сейчас таковы, что все большее количество контента мы потребляем с помощью мобильных устройств и многие разрабатывают мобильные версии для основных программ. Если это ваш случай, то скорее всего вы будете использовать отличный от WPF стэк технологий.

Кроссплатформенность

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

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

Позитивные моменты для будущего WPF

Активная команда WPF

Команда WPF действительно проснулась и их блог стал обновляться.

Есть потенциал для разработки

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

Новые инструменты

Популярный инструмент Prism, набор инструментов и лучших практик разработки на WPF,  обновился до версии 5. Далее, активно развивается неофициальный расширенный набор инструментов для WPF Extended WPF Toolkit, который обновился буквально пару дней назад. В разработке новых инструментов не уступают и флагманы типа DevExpress.

Два наиболее популярный MVVM фреймворка: MVVM Light Toolkit и Caliburn.Micro так же проявляют активность. Для первого последний чекин датируется 21 февраля 2015 года, для второго – 16 марта 2015 года. И это не единичные чекины раз в полгода, а регулярная работа.

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

Изменения в управлении

В конце 2012 года Стивен Синофски покинул пост President of the Windows Division и Microsoft вообще. Почему это хороший знак для WPF? Потому что он был известен как знатный ненавистник .NET и плохо ладил с другими командами. Возможно это и есть основная причина его отставки.

Это так же частично может объяснять, наряду с техническими причинами, почему .Net не был использован как основной технологический стек для новый операционных систем Windows, тогда как по факту это один из лучших продуктов Microsoft. Снаружи конечно же сложно оценить верность слухов и сплетен вокруг Стивена и его влияния на то, как получились системы Windows 8 и старше.

Инертность рынка ОС

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

Для компаний миграция на новую ОС это всегда головная боль и проблемы. Необходимо убедиться в совместимости всех сервисов, всех своих наработок. Убедиться что вендоры могут предоставить соответствующих экспертов и поддержку, подготовить свой персонал. Вообще переход на новую ОС может составлять 2 года и более. На этом фоне выглядит несколько странным и интригующим заявление о том, что каждые 2 года Microsoft будет выпускать новые версии своих продуктов, включая ОС. За примером далеко ходить не надо, многие компании не переходят с семерки на 8 и 8.1 ожидая, вполне закономерно как дела будут с новой версией и не стоит ли перейти сразу на нее.

На текущий момент распределение ОС от Microsoft выглядит примерно так:

• Windows 8 + 8.1 : ~15%
• Windows 7 : ~55%
• Windows Vista : ~5%
• Windows XP : ~25%

Т.е. более чем на 80% машин не доступны функции WinRT и остается только одна опция – WPF. Принимая во внимание, что цикл обновления ОС и приложений составляет около 5 лет, сейчас WPF является единственным выбором, если вы решаете сделать приложение не за выходные и на ближайшие полгода.

Инертность ALM

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

И это только малая часть всего процесса, но и его хватает, чтобы понять, что приложений на только что появившихся технологиях еще долго не будет. Поддержка WPF со стороны бизнеса будет сильна, потому что это уже стабильная технология для которой есть специалисты и на этом можно строить свои процессы. Кстати, до сих пор порой требуются спецы по Delphi5 или Fortran для поддержки приложений и они стоят сейчас очень дорого. Хотя в целом так далеко ходить не надо, до сих пор актуальны огромное количество приложений написанных с использованием WinForms, так что списывать со счетов WPF было бы слишком преждевременно.

WPF зрелая технология

Для многих разработчиков очевидно, что первая версия приложения отнимает наибольшее количество времени и сил. В таком ключе можно рассматривать выпуск WPF 3.0 и WPF 3.5. После победы над детскими болячками, приложения на WPF 4 уже стали «полными», разработчики стали уделять внимание быстродействию, что намекает на стабильность основной технологической базы. Наконец в версии 4.5 разработчики добавили еще украшательств и еще больше повысили производительность.

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

Line of Business (LOB) Application

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

Во-первых, потому что накоплен огромный опыт в разработке приложений на WPF и их развертывании в системе. Потому что это .Net платформа, которая сама по себе уже зрелый продукт. Если компании имеют достаточно приложений на .net, то нет никаких причин останавливаться и переходить на другой стек. Гораздо легче использовать существующих программистов для покрытия всех бизнес-потребностей. К тому же интеграция приложений на одной платформе будет существенно легче.

Еще одной причиной, почему WinRT пока не может прийти на смену WPF – это то, что нет такого же инструментария. Например, таких вещей как ORM в духе NHibernate или EntityFramework, которые необходимы любому in-house приложению.

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

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

За более чем 10 лет компании создали огромное количество приложений на WinForms и переделать их в один момент по другие технологии не представляется возможным. Огроным плюсом в этом случае является взаимная между WinForms и WPF возможность использовать компоненты друг друга и внедрять друг в друга. Таким образом миграция с одной технологии на другую может проходить постепенно и относительно безболезненно.

Насколько я знаю, пока что WinRT никак не может внедряться в WinForms компоненты, формы.

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

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

Если более конкретно, то мы обсудим темы:

• История пользовательских интерфейсов и как сделать UI\UX удобным для корпоративного пользователя. Через окна в облака.
• Не создавайте медлительных зомби-приложений. Используйте Rx! На реальном примере. А также что вы недооценили в TPL?
• EF-ом ли единым живы большие приложения?
• Прототипирование приложений
• Как написать толковые UT на пользовательский интерфейс. Реальный опыт разработки.
• Холивар на тему полного и анемичного домена
• И другие захватывающие истории!

Регистрируйтесь! До 23 марта действует специальная цена.