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

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

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

Проблемы структуризации

В .NET есть ряд весьма неприятных «канонов» в плане взаимодействия с кодом. Во-первых, у нас есть негласное правило под названием «one class per file», т.е. идея о том, что в файле может быть только один класс. Я сколько не думал, так и не мог привести вменяемых аргументов в пользу этого правила. Должен признаться, что я уже давно его не придерживаюсь, разве что для конкретных задач (например, динамического прототипирования, где это критично).

Вторая, сопряженная, проблема заключается в том, что нынче не модно делать «композицию», т.е. вложенные классы. Опять же, мне вспоминается пример с машиной и колесами: если у вас в программе колеса есть только у машины, почему не сделать класс Wheel вложенным в класс Car? Потому что не модно. Нынче агрегирование якобы лучше чем композиция.

Аналогичная проблема встречается в алгоритмах, состоящих из нескольких частей. Если все эти части – внешние функции, то у нас получился не перевариваемый API. Хочется сделать функции внутренними? Пожалуйста, только вывод типов тут работать не будет. Да и то, как выглядит функция на 100 строк, где 50 из них – это какой-нибудь Action – не дает никаких особых преимуществ. Как было нечитабельно, так нечитабельно и осталось.

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

Так как описать сложный алгоритм?

С одной стороны, мы не можем отказаться от принципа «разделяй и властвуй», т.е. единственный шанс понять что-то сложное – разбить его на несколько кусочков, потом разбить эти кусочки, и так далее ad nauseam. Проблема лишь в том, как потом заставить эти 1000 кусочков не лезть нам в глаза со строк тысячестрочного файла?

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

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

class MyAlgo
{
  MyAlgoResult Step1()
  {
    Foo foo = new Foo();
    // change foo, then
    if (foo.Baz < 0) return MyAlgoResult.Fubar;
    return Step2(foo);
  }
  MyAlgoResult Step2(Foo foo)
  {
    var bar = foo.DoStuff();
    return MyAlgoResult.Ok;
  }
  enum MyAlgoResult { Ok, Fubar };
}

В качестве визуального примера этого подхода хочу показать диаграмму вызовов, сгенерированную Visual Studio. Диаграмма хоть и неидеальная, но суть подхода показывает:

К сожалению, разбить алгоритм на методы – мало. Обычно нужны не только внутренние методы, но также внутренние классы. Более того, некоторые алгоритмы не делятся ровно. Например, всякие if-ы, switch-и и прочие частично ломают наш подход. Иногда их можно оставить в покое, но иногда их можно эмулировать с помощью различных ООП структур.

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

Столпотворение структур

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

Еще одна структура (а точнее может одна, а может у вас их несколько) – это классы для хранения методов расширения. Методы расширения нужны по ряду причин, и я уже публиковал пост на тему паттернов которые встречаются чаще всего. Методы расширения способны существенно улучшить читаемость. Например, что проще понять – Math.Round(Math.Abs(x)) или x.AbsRound()?

Еще одна полезная практика – это перегружать оператор индексирования [] для всех типов, в которых есть одна основная перечисляемая коллекция. Разница между info.Points[i] и info[i] весьма заметна, особенно если это нужно писать в 10 разных местах.

Что дальше?

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

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

ОК, получился еще один «поток сознания», comments welcome! ■

Ситуация на рынке

Это мне одному кажется что по программированию как-то стало мало всего интересного выходить? Раньше помню все популярные кухни (Apress/O’Reilly/AW) штамповали достаточно интересные книги. Сейчас же, если посмотреть например на то что нового у Apress, то как-то даже ничего и читать не хочется. У меня все еще “греется” на полке их книжка по TPL, которая ну просто супер, с которой я в свое время слизал массу примеров. Так вот, в последнее время ничего аналогичного на рынке не появилось (или появилось, но я не заметил). Зато появилось много книг с названием “C# 2012″ что есть кретинизм в высшей инстанции (ну нет такой версии языка, нету).

С другой стороны, периодически появляется желание написать книгу самому, но мое мнение начинает колебаться где-то между “это экономически необоснованно” и “это слишком легко”. Если экономическую необоснованность книг понимают все (даже авторы бестселлеров NY Times, оказывается, получают весьма скромные деньги), то “слишком легко” еще нужно объяснить. Я вот вижу например сценарий в котором делается книга про Dependency Injection: берем IoC контейнер (к пр. Autofac) и линейно описываем все его возможности, начиная от самых простых и заканчивая экзотикой которая 99% пользователей никогда не понадобится. Просто, предсказуемо, но времени нужно столько что о-го-го. Сам в процессе нарабатываешь невесть-какие навыки которые самому не понадобятся. (Когда-то я написал серию блог-постов про Unity, и эффект был аналогичный.)

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

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

Второй вариант мне определенно ближе. Я например периодически пытаюсь убеждать людей пробовать новые языки, динамическое прототипирование, realtime-программирование, создание собственных DSL-редакторов, и так далее. Результат в принципе предсказуемый: у большинства появляется просто непонимание, как если бы я начал выводить модель Блэка-Шоулза. После демонстраций, конечно, все проясняется чуть-чуть, но тогда вопрос – может стоит демонстрациями и заниматься?

Читабельность, доступность, верстка

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

Во-первых, мне кажется разработчики всяких “читалок” окончательно забили на техническую литературу. Например, в формате MOBI (это который Kindle использует) нельзя толков верстать блоки кода. Вообще. Не говоря уже про подсветку синтаксиса и прочую муть. Я по дурости купил “The D Programming Language” в формате Киндл, и это был фейл – там код как картинки. Из доступных вариантов остаются только читалки крупного размера которые могут отражать PDF. Тогда можно купить PDF (опять же, не у всех, но паблишеры вроде Apress, слава богу, вменяемы) и попытаться прочитать на Kindle DX или аналогичном устройстве.

Тут тоже все непросто. Во-первых, читалка моя не A4 а все-таки поменьше, а следовательно если верстать как это делает Microsoft Press то шрифт после масштабирования получится микроскопический. Впрочем, эта же проблема влияет и на печатные издания: не знаю кто вдруг решил что человек может прочитать 200 символов в одной строке. Э-эх, MS Press.

Во-вторых, и это еще более существенно, некоторые издательства – например O’Reilly – верстают книги таким шрифтом который нечитабелен на электронных читалках за исключением, возможно, нового iPad’а (не знаю, не пробовал). Причина – слишком тонкий шрифт, а следовательно полное отсутствие контраста. На бумаге терпимо, на экране ну просто никак. Особенно если автор сверстал книгу в LaTeX’е и использовал дефолтный шрифт. Что кстати само по себе диагноз, т.к. у нас тут 21й век на дворе, есть LyX и прочие прелести, неужели читателей не жалко?

На самом деле интересно, я проводил исследование на тему того, как писать книжку и потом публиковать ее в разные форматы. Под разными форматами имеются в виду как минимум PDF (на самом деле есть 2 варианта – “простой” и тот который для Adobe Digital Editions), MOBI (это для Kindle), EPUB (очевидно для Nook и других систем про которые я слишком мало знаю). На самом деле, все основные вопросы появляются насчет PDF – то есть с одной стороны хочется публиковать один вариант, но с другой, начинаешь думать что:

• Публиковать “печатный” PDF можно только если он влезает в рамки типичной “большой” читалки вроде KDX, что накладывает порой не очень адекватные ограничения на размеры полей.
• Использовать печатные шрифты для экрана неправильно. Да, девайсы вроде KDX или iPad 3 спокойно отрезолвят, но какой-нибудь iPad 2 например не способен качественно отображать шрифты с засечками. Следовательно, нужно использовать разные шрифты?
• Если в книге у вас есть иллюстрации, то с большой вероятностью верстка будет привязана к размеру страницы. Что, опять же, существенно ограничивает возможность поддержки разных девайсов.

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

Шрифты и иллюстрации

Шрифты – это наркотик. Это как автомобили или Hi-Fi системы или карточки Magic: the Gathering. Это культ, религия, предмет озабоченности. Но про шрифты говорить стоит даже если вы не культист, т.к. один и тот же текст с разным шрифтом может выглядеть читабельно и не очень. Поэтому у нас не получится их не обсуждать. Сорри.

Какие шрифты используются в книгах? Если кто-то из вас предложит варианты вроде Times New Roman, Arial или какой-нибудь другой предустановленный шрифт, типографические снобы косо на вас посмотрят. Если вы предложите Comic Sans, то даже я инстинктивно потянусь за ружьем. На самом же деле, насколько я понял после исследования нескольких PDF-ов, расклад примерно такой:

• В качестве текстового шрифта, каждый издатель использует свой собственный шрифт во всех книгах. Например, Apress использует Utopia. Примечательно то, что для каждой предметной области есть свой набор шрифтов который подходит ей больше всего.
• В качестве заголовочного шрифта используется правильный “спаренный” шрифт, то есть такой, который наиболее гармонирует с текстовым. Опять же, всякие Arial не используются, но может использоваться Helvetica (что, вообщем-то, то же самое что и Arial) или например Myriad.
• Для верстки кода, в большинстве случаев, не используются всякие Consolas, Courier и прочие. На данный момент, самым популярным шрифтом для кода является TheSans Mono.

С другой стороны, все эти извращения хорошы только в печати: на моем киндле, все это скорее вредит. Что нужно для электронных читалок так это простой sans-serif вроде Arial Unicode. Почему именно он? Потому что большой набор символов. Я вот недавно пытался набрать let 森= new List<木>() в LyX и чуть голову себе не сломал. Не говоря уже о том, что выглядеть это все должно консистентно.

На самом деле, со шрифтами еще все более-менее: вы можете в крайнем случае использовать Arial для текста и какой-нибудь Consolas для кода и все должно быть хорошо. А вот с иллюстрациями совсем непонятно. В частности, непонятно их разрешение: стоит ли оставлять их как 600dpi (займет много места) или сократить т.к. все равно никто печатать с файла не будет? С одной стороны, пользователям iPad’а наверное стоит дать картинку почетче. С другой, встроенный процессор Kindle – это такая адская дурь, которая итак страницу по полсекунды рисует, а сложную картинку она еще должна будет уменьшить (наверняка с помощью кубической интерполяции, чтобы помедленнее было) прежде чем показать. Одним словом, опять нет оптимального решения. Разве что если иллюстрации векторные. Тогда проблем тоже нет, хотя опять же, если в картинке тысячи элементов, то Киндл либо будет долго думать либо вообще не отрисует.

Заключение

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

Сценарий

В мои руки попало несколько сот гигабайт данных – если быть конкретным, по 10Гб данных за несколько месяцев. Данные поставляются в формате базы данных SQLite. Данные в основном численные, но есть и некоторые нюансы:

• Некоторые численные значения поставлены не как число, а как строка, например 12345.00000. Эту строку естественно надо «парсить» чтобы получить значение типа double.

• Все даты в файле поставлены как строки в формате 1991.11.11 11:11:11.111.

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

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

Первая попытка

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

Поэтому я решил написать «выдиралку» с использованием только Connection/Command объектов – это как раз тот ADO.NET подход который был популярен во времена .NET 1.1 примерно 8 лет назад.

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

Переход на C++

В связи со всем этим, я решил что лучше написать один раз, но написать качественно и так чтобы быстро работало. Создал новый проект С++, перевел его на компилятор Intel (для тех кто не знает, я – ярый фанат использования Intel Parallel Studio), и начал писать. Сразу оговорюсь, что писал я с уклоном на то, что результирующие бинарные данные все равно будут использовться в .NET.

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

Второй шаг – это конечно подключение библиотеки Boost, которая мне потребовалась для обработки дат. И вот тут уже началось веселье. В частности, библиотека работы с датой и временем — апокалиптична. Неподготовленному человеку в ней не разобраться без нескольких часов читания доков. Не то что System.DateTime! Вот например как происходит конверсия в .NET-совместимую эпоху:

static uint64_t netEpochOffset = 441481536000000000LL;
static ptime netEpoch(date(1400,1,1), time_duration(0,0,0));
static int64_t Util::TimeToTicks(ptime time)
{
  time_duration td = time - netEpoch;
  uint64_t nano = td.total_microseconds() * 10LL;
  return nano + netEpochOffset;
}

И подобная магия тут везде. Вот в .NET у нас тоже один большой long определяет всю дату, но DateTime имеет кучу методов для того чтобы получить кол-во часов, дней, и так далее. Тут все по-другому, тут дата – это сколько вы отсчитали от той или иной эпохи, и чтобы вычитать, например, только время из даты, придется сильно попотеть. Соответственно, для того чтобы определить определенное время дня мне приходилось писать вот такой код:

time_duration _19_00 = time_from_string("1900/01/01 19:00:00.000").time_of_day();

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

Работа с коллекциями

Коллекции в С++ хранятся ‘by value’, поэтому по-хорошему любой ваш список будет иметь тип vector<boost::shared_ptr<MyObject>> и разыменовывание надо будет делать через (*itr)->DoSomething, что само по себе бесит. Более того, даже работая с примитивными структурами, понимаешь что нехватает массы методов. Например, у .NETного Dictionary есть метод ContainsKey() который проверяет наличие записи с таким ключем. А что происходит с С++‘ным map, где такого метода нет? Вот, полюбуйтесь:

boost::shared_ptr<FullBarrel> barrel;
auto candidate = futureBarrels.find(instrument->InstrumentID);
if (candidate != futureBarrels.end())
  barrel = candidate->second;
else {
  barrel = boost::shared_ptr<FullBarrel>(new FullBarrel);
  futureBarrels.insert(candidate, BarrelDictionary::value_type(instrument->InstrumentID, barrel));
}

Следующее, что убивает, это const-корректность – наивный и жалкий механизм, с помощью которого С++ пытается контролировать, какие элементы можно менять а какие нет. Выливается это в то, что например задекларированный вами vector внезапно нельзя менять внутри for_each. Понятное дело, что для «зубров» С++ эти проблемы разруливаются, да и я смог разобраться, но это еще один пример того, как устаревшая парадигма языка не привносит ничего полезного, зато добавляет массу головной боли.

Сериализация

Поскольку все мои данные – численные (в основном либо double либо int64_t), я решил использовать обычную структуру, т.е. struct, для хранения данных. К счастью, С++ умеет сериализовывать эту структуру в файл полностью, считывая из нее всю память:

ofstream ofs(filename, ios::out | ios::binary);
ofs.write((char*)&myStruct, sizeof(MyStructure));
ofs.close();

Единственный сюрприз ждал меня когда я начал читать эти данные в .NET-е. Во-первых, я не угадал сначала какой размер данных у enum-ов (4 байта), а во-вторых, я забыл про упаковку данных.

Упаковка данных (structure packing) – это механизм, который выравнивает структуры на границах байтов. Очень полезно для процессора, но мой .NETный BinaryReader естественно ничего про подобное не знает и пытается читать заглушечные данные в память переменных.

Решение было простое – добавить директиву #pragma pack(1) в С++ чтобы выравнивать по одному байту, т.е. не добавлять промежуточных данных вообще. Внезапно, все заработало в .NET.

Оптимизации

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

double Util::powersOf10[] = { 1.0, 10.0, 100.0, 1000.0, 10000.0, 100000.0, 1000000.0, 10000000.0 };
static double Util::StringToDouble(string& s)
{
  auto dotPos = s.find('.');
  s.erase(s.begin() + dotPos);
  return _atoi64(s.c_str())/powersOf10[s.length() - dotPos] ;
}

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

Заключение

Конечный результат дал примерно 10-кратное увеличение производительности. За счет компактности С++ных structов, данные получилось ужать примерно в 100 раз. С другой стороны, производительность разработчика упала раз в 5 (а может и более). Спасает лишь то, что это единовременная проблема.

Мне кажется что вывод тут может быть один: нужно использовать правильный язык для правильной ситуации. Ведь анализ конечных данных я все равно буду проводить с использованием C#, т.е. работать на языке где нет LINQ – это как-то совсем архаично. Но многие ведь работают, не так ли?

P.S.: для работы с данными использовался SSD — к сожалению не Revo или FusionIO, а обычный Vertex 3. Обработка велась в несколько потоков на одном физическом диске, т.е. одновременно писалось и читалось несколько файлов.

Этот пост – мои заметки о том, что новое в 2011й студии и как мне в ней работается.

Поддержка WinRT – она есть, но не здесь

Как и все, я немного ошеломлен тем, что даже в Бету Студии не попала поддержка WinRT. Microsoft в очередной раз сбила всех с толку, выпустив Visual Studio Express с поддержкой Metro-Style Apps и «полноценную» студию без такой поддержки. Наверняка на это решение повлияли сложные маркетинговые механизмы, но как бы там ни было, поддержки WinRT в основной студии пока нет.

Как вы понимаете поддержка WinRT – это основноая «фича» новой студии. Но добавлять ее в обзор VS11 пока что неуместно — пусть она сначала тут появится.

Upd: как подсказал в комментариях Владимир Юнев, поддержка WinRT/Metro-Style Apps присутствует в VS11, но только в том случае, если вы ставите ее на Windows 8. :)

Black & White

Новая студия, для тех кто еще не видел скриншоты – черно-белая. А точнее монохромная – в ней скорее много оттенков серого, чем чисто черный и белый цвет:

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

Тяжело вот почему: для меня все монохромные иконки размером 16×16px кажутся одинаковыми. Удалив цвет, потерялось целое «информационное измерение». Вот например раньше тип проекта (C#, F#, C++) имел свой уникальный цвет:

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

Solution Explorer

Единственное новшество solution explorer’а, которое я вижу – это возможность раскрывать структуру файлов чтобы смотреть что у них внутри. Работает это даже для С++ проектов:

Что ж, похвально, только польза от этого сомнительная: обычно требуется ответить не на вопрос «что в этом файле?» а на вопрос «в каком файле лежит тип Х?», и вот тут Студия бессильна.

Если взять и кликнуть правой кнопкой на каком-то из представленных выше типов (например Greeks), Студия покажет нам вот такое меню:

Большинство этих пунктов приводят к замене всего контента Solution Explorer’а, и тут-то становится ясно, что Solution Explorer – это некий page navigator (в терминоголии WPF), который может как набор страниц HTML показывать нам различные виды в зависимости от того где ма находимся.

Говоря о примере выше, Scope to This делает текущий элемент корнем дерева, Base Types и Derived Types ищет родителей и наследников этого типа, а вот Is Used By реализует полезную функцию нахождения всех мест где тип используется:

Add References

Add References – это главный #fail Студии всех версий включая 2010. Я с пристрастием смотрел на то, как нам обещали починить адски медленную загрузку ссылок в 2010й студии, но счастья не пришло: сделали еще хуже. В 11й студии правда все вроде получше: у меня окно при первом запуске открывалось 2 секунды, на последующих – моментально. Само по себе окошко теперь выглядит вот так:

В сборки «фреймворка» попали различные сборки System.* и Microsoft.*, в то время как все сторонние сборки попали в «extensions». Что порадовало так это скорость поиска: я написал «WPF» и получил список всех нужных сборок практически моментально. Вообщем, мне кажется что инцедент изчерпан, хотя признаюсь что нынче я использую NuGet намного чаще чем Add Reference. Он кстати, судя по всему, поставляется с 11й студией, и это хорошо, т.к. я до сих пор периодически встречаю людей, которые не знают что это такое.

Quick Launch или «быстрый запуск всего и вся»

Те из вас кто используют Mac’и уже знакомы с этой функцией: вы вбиваете в текстовое поле ориентировочное название того, что вы хотите сделать, и программа показывает вам все возможные варианты действий. Так вот: теперь подобное есть и в Студии. Называется эта функция Quick Launch (быстрый запуск), и находится она в правой верхней части основного приложения:

Я считаю что идея в принципе хорошая, хотя это и является как бы намеком на то, что в Студии слишком много всяких команд которые ни один человек в принципе запомнить не может. Что хорошо в списке выше, так это то что показаны шорткаты (например, для Run All Tests) — это позволить пользователю запомнить его и в следующий раз уже использовать шорткат вместо Quick Launch для запуска всех тестов.

IntelliSense

Автодополнение кода в 11 студии улучшено и даже умудряется работать в С++ с приемлимой скоростью, что особенно радует. Наконец-то дополнение сопоставляет не только начало слова, но идет все символы которые это слово содержат:

Конечно, до полноценной реализации fuzzy string matching Студия все равно не дотягивает, но хоть какой-то прогресс виден. Да, и список дополнения выпадает теперь автоматически, после первого же напечатанного символа.

Графика, GPGPU, C++ AMP

Теперь мы пришли к одной из «основных» фич студии, а именно поддержки отладки программ, работающих на GPU. Ситуация на данный момент такая: Microsoft работает вместе с AMD/ATI и NVIDIA для того чтобы реализовать в поставке 2012й студии библиотеку C++ AMP (Accelerated Massive Parallelism). Эта библиотека чем-то похожа на Thrust — ее цель дать пользователям интерфейс, сравнимый с TBB или PPL, но при этом сделать так, чтобы вычисления можно было производить не на CPU а на GPU.

Для тех кто не в курсе, напомню что на настоящий момент NVIDIA имеет намного более сильную позицию касаетельно вычислений на графических картах. Обусловлено это тем, что NVIDIA удосуживается поставлять качественный драйверы а также прекрасный CUDA SDK, в то время как ATI поставляет постоянно падающие драйверы и какую-то высокоуровневую несуразицу в форме OpenCL. Не удивительно, что на данный момент, большинсто библиотек и решений (Thrust, GPU.NET и так далее) поддерживают именно CUDA. Для ATI, C++ AMP – это наверное последний шанс вернуться в игру, т.к. иначе NVIDIA просто их раздавит.

К сожалению, и в этой бочке есть ложка дегтя: технология C++ AMP это некая спецификация, а реализация Microsoft использует Direct3D, что означает что шансы использовать эту технологию на не-Windows системах примерно равна нулю.

Заключение

На данный момент, помимо поддержки WinRT и C++ AMP, 11я студия не кажется мне чем-то особенным. Единственное что порадовало – это то что она работает чуть-чуть быстрее чем предыдущая, хотя она пока у меня «голая», а когда в ней будет масса плагинов – будет совсем другое дело. Тем не менее, на нетбуке она смотрится хорошо.

На данный момент мне уже ничего не препятствует в адоптации 11й студии за исключением одной вещи: наличия Intel Parallel Studio которая бы поддерживала VS11. Если вас интересует новая студия, советую скачать и начать использовать бету, т.к. «поломок» от беты, по крайней мере на моей системе, пока не наблюдается. И старая студия тоже, тьфу-тьфу, работает без проблем.

В целом же, мне остается только вздохнуть и заметить, что эра революций в нашей любимой IDE уже прошла. Это не значит что пора пересаживаться на Notepad, но мне кажется что сейчас самое время для какого-нибудь смелого игрока выступить с IDE которая нацелена целиком и полностью на разработку приложений для различных систем, а не на узконаправленную поддержку технологического стека Microsoft. По крайней мере, у меня такая мечта. Ведь если бы был редактор, который бы поддерживал, скажем, C# и C++ и функионал аналогичный ReSharper’у, уверен что процентов 60 разработчиков ежесекундно пересели бы на такую IDE.

P.S.: не упомянул MVC 4, но и не особо хотелось. Что, поддержка single-page apps, говорите? Хорошо, только зачем для этого MVC? Более того, зачем для этого IIS? Ни то ни другое не нужно для реализации парадигмы JS+REST.

P.P.S.: а вот еще одна ложка дегтя: Microsoft сделали так, чтобы было невозможно отлаживать на Windows 7, только на Windows 8 (WTF?!?) Хотя, судя по всему, это можно починить, но тот факт что это делается вручную через переименование DLLек… ну спасибо, Microsoft… серьезно, кто-то планирует использовать Windows 8 для разработки? А я-то думал это поделка чисто для Metro UI.

P³S.: примечательно так же, что попытка поставить DirectX SDK (June 2010) окончилась провалом, т.к. оказываается версия C++ слишком свежая. Детали проблемы тут.

Инлайнинг возведения в степень

Если ваша программа реализует как

double f(double a, double b, double c, double x)
{
  return a * std::pow(x, 2.0) + b*x + c;
}

то вы оказываете пользователю медвежью услугу. Для начала, следует помнить, что возведение в целочисленную степень является достаточно бессмысленной операцией, т.к. простое умножение “инлайн” или умножение в цикле всегда будет быстрее. Причина этого проста – функции вроде std::pow() расчитаны на подсчет степени для любых показателей, в т.ч. нецелочисленных. Как только в экспоненту ставится число вроде 2.0, строятся ряды и производительность идет лесом.

Решение этой проблемы весьма простое. Во-первых, для всех простых показателей вроде , и так далее лучше все инлайнить, т.е. писать x*x, x*x*x и т.д. Что касается более крупных степеней то тут тоже все просто – надо чтобы степень была целым числом, т.е. имела тип int. Тогда будет вызвана пегрузка std::pow(), которая в свою очередь вызовет функцию _Pow_int() (по крайней мере в <math.h> от Microsoft), и все будет хорошо.

В .NET все не так ажурно т.к. Math.Pow() берет два параметра типа double. Очень досадное упущение, но это можно устранить самостоятельно:

public static long IntPower(int x, short power)
{
  if (power == 0) return 1;
  if (power == 1) return x;
  int n = 15;
  while ((power <<= 1) >= 0) n--;
  long tmp = x;
  while (--n > 0)
    tmp = tmp * tmp *
         (((power <<= 1) < 0) ? x : 1);
  return tmp;
}

Пример выше – для типа short, т.к. его обычно вполне достаточно. Естественно, следует также понимать что есть некий порог, после которого дешевле использовать канонический pow(double,double) вместо итеративного умножения.

Сокращение количества умножений

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

double f(double a, double b, double c, double x)
{
  return a*x*x + b*x + c;
}

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

double f(double a, double b, double c, double c)
{
  return x*(a*x + b) + c;
}

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

double f(double x, double y)
{
  return (x + y) * (x - y);
}

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

Предварительные вычисления

Понятное дело что выражение превратится во что-то вроде 0.333333333333 * x будучи оптимизированным компилятором. Но если взять выражение вроде , то тут уже все неоднозначно. До какой степени компилятор сможет оптимизировать и “инлайнить” результаты вычислений? Я думаю что в репертуар типичного компилятора не входит глубокий анализ и оптимизация вычислений.

Выделение переменных

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

double f(double x)
{
  return 2.0*pow(cos(x),3.0) - pow(cos(x), 2.0);
}

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

double f(double x)
{
  double u = cos(x);
  return (2*u - 1)*u*u;
}

То, что приведено выше – это так называемая схема Горнера. Примечательно, что эта задача — анализ выражений на поиск общих кусков кода — будучи созданной ускорять код, сама по себе имеет огромную стоимость, т.к. подразумевает поиск любого поддерева с определенной стоимостью в остальных частях дерева и выделения их для последующей замены. В общем случае эта задача не решается. К счастью, при трансляции Excel→С++ ее можно решить хотя бы частично: результаты промежуточных вычислений часто хранятся в отдельных клетках, а детектировать их повторное использование легче т.к. это всего лишь сравнение cell reference’ов.

Заключение

Для создания вменяемых математических моделей недостаточно просто конвертировать код “один в один”. В конце концов, главная цель подобных конверсий из Excel в С++ — получить многократный прирост производительности. А сколько эта конверсия займет времени никого толком не волнует.

ПО, которое удалось зарелизить:

• JetBrains ReSharper SDK, включая онлайн документацию. Также получилось добавить одну фичу непосредственно в ReSharper.

• ActiveMesa R2P — обновления для ReSharper 6.0 и 6.1, также несколько фич по запросам пользователей (что особенно приятно). Появилось много классных вещей, без которых я и сам уже жить не могу. Впрочем, пишется в основном для себя, так что это понятно.

• ActiveMesa MathSharp — нужно иметь много наглости чтобы просить почти 100 долларов за приложение, которое писалось максимум неделю. И покупают ведь! Первое приложение которое я выпускаю по ClickOnce, и не без факапов конечно же, но тем не менее… теперь точно понятно, что пользователи готовы качать 100-мегабайтный инсталлятор .Net 4 и их это не особо напрягает.

Языки и их использование:

• D — открытие года для меня. Уже успел купить и прочитать книжку Александреску а также попробовать пописать на нем. Впечатления крайне позитивные, несмотря на отсутствие 64-битной поддержки а также явную “недопиленность” стандартной библиотеки Phobos. D – это язык на котором хочется писать и шипить ПО, в том числе и кросс-платформенное. Настоятельно рекомендую!

• C# — продолжаю пользоваться, всем в принципе доволен. Обрастаю библиотеками с методами расширений, т.к. в любом проекте одно и то же, снова и снова. Также активно использую монаду Maybe для R2P.

• C++ — продолжаю пользоваться, нововведения меня не очень затронули, в основном использую “хорошо забытое старое” а также типичный стэк – Intel TBB, OpenMP, SIMD.

• F# — пришел к выводу что он очень хорош для определенного круга задач, и не очень хорош для всего что требует серьезного использования ООП. При написании MathSharp, да и вообще парсеров, он очень полезен. Для математики тоже весьма неплох, хотя тут уже его приемущества чисто психологические (т.е. это приемущества для математиков, но не для меня).

• JavaScript — практически не использую напрямую, пишу все на C# и транскомпилирую через SharpKit (см. ниже). За пределами $.getJSON() стараюсь вообще не трогать.

Программы и компоненты, которые продолжают давать ощутимые бенефиты:

• Контролы DevExpress (WinForms) — использую их с 2006 года и в целом доволен, особенно доволен стилизацией, до которой конкурентам далеко. Контролы DX продолжают лидировать в плане красивости UI, а это важно для пользователей.

• Intel Parallel Studio — до черного пояса Intel мне как до луны, но инструментарием я продолжаю пользоваться, причем весьма успешно. Как ни странно, мне намного больше импонирует использование связки C# & IntelCPP чем связки C# & C++/CLI.

• TypograFix продолжает развиваться, улучшаться, и этот пост я пишу, конечно же, на нем. (Через RDC, сидя на Mac’е.)

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

• Innovasys Document!X — теперь это моя стандартная тула для генерирования документации (CHM и Web) как для коммерческих, так и для OSS проектов. Действительно хороший продукт, который стоит своих денег.

• Red Gate SmartAssembly — все любят ругать Red Gate за Reflector, но продукт SmartAssembly они выкупили у другой компании, и продукт это неплохой. SA – это обфускатор, ILMerge и репортилка исключений в одном флаконе. Да, ценник “зашкаливает”, но мне очень нравится функционал и UI. Нет, я не страдаю любовью к обфускаторам т.к. считаю эту затею бессмысленной, но вот красивый exception reporting многого стоит.

• WiX — да-да, бесплатный пакет для создания инсталляторов существует уже давно, но “распробовал” его я только в этом году. Теперь все инсталляторы которые не используют ClickOnce делаются именно на WiX. Единственное, чего не хватает – это фич автообновления. Правда автообновление уже давно перестало быть большой проблемой. Но все равно хочется иметь его “из коробки”.

• ActiPro Syntax Editor (WinForms) — казалось бы, что особенного в контроле-редакторе который показывает подсветку синтаксиса и code completion для C#? А то, что процесс динамического прототипирования можно сделать более “цивильным”. А динамическое прототипирование дает настолько серьезный прирост производительности, что не делать его уже кажется грехом. Впрочем, мне кажется я никогда не смогу объяснить людям все его бенефиты. Что же, это не критично.

• SharpKit — транскомпилятор из C# в JavaScript. Чтобы не писать JS, который есть зло и должен умереть, хотя кто-то и соглашается на нем писать. Тулкит имеет завязки на разные фреймворки вроде jQuery, да и свои байндинги писать на так уж сложно.

Программы, которые я больше не планирую использовать:

• SQL Server и другие RDBMS, а также такие ORM-фреймворки как Telerik OpenAccess. MongoDB хватает “за глаза”, и подход NOSQL идеален для большинства задач. Единственное исключение пока это embeddability, и тут я пожалуй продолжу пользоваться SQL CE (например в том же R2P), т.к. хороших альтернатив мало.

• IIS и ASP.NET MVC — с момента моего перехода на подход JS+REST, эти технологии оказались нерелевантными. Хотя, по правде сказать, я по-прежнему использую IIS 6 для хостинга WCF REST приложений, но по крайней мере клиентскую часть я писать на ASP.NET больше не намерен.

• NDepend — в нем есть полезные фичи, но они запрятаны под слоями академичного анализа который, если честно, не очень-то полезен для анализа моего кода. Гораздо полезнее обычные механизмы статического анализа.

• Typemock Isolator — я на самом деле давно забросил использование такой “тяжелой артиллерии”, но недавно попробовал снова и был разочарован: оказалось что в VS Ultimate Typemock генерит много багов, и умеет работать только при определенно выставленной конфигурации, которая меня не устраивает.

• Telerik MVC поскольку его больше не существует :) не говоря уже о том что я больше не буду писать под ASP.NET.

Технологии, которые удивили или порадовали:

• Kindle DX — пожалуй лучшее мое приобретение года. Вопрос о покупке iPad’а даже не стоял, а KDX я прикупил после долгих раздумий и не сожалею – уже прочитал на нем уйму книг. Глаза он щадит, размер вменяемый для чтения “почти А4”. Есть конечно фейлы – бесплатный 3G не работает в России и Латвии (в Скандинавии – на ура), браузер допотопный, WiFi нету, и книжки которые продает Amazon (типа ‘Kindle Edition’) покупать нельзя т.к. все листинги кода в них – битмапы, оптимизированные под “маленький” киндл. Что просто чудовищно. PDF FTW.

• Windows Phone 7 — честно скажу: я ожидал увидеть очередное мертворожденное детище. А получилась операционка с уникальным, красивым user experience. Ведь могут когда захотят! Теперь остается ждать планшетов, хотя скажу сразу: если iPad 3 будет выпущен с Retina Display, куплю не задумываясь, ибо хочется, наконец-то, вменяемого разрешения. Если оно будет, можно будет и PDFы попробовать читать, и travel guides всякие, комиксы, и так далее…

• Qt Creator — не совсем “моё”, конечно, но Qt Creator порадовал тем что он, во-первых, работает, а во-вторых даже более-менее понятен. В принципе, если приложение действительно нужно сделать кросс-платформенным, то я бы скорее смотрел на Qt чем на Java или AIR. И все это в очередной раз подчеркивает, что если хочешь чтобы твой алгоритм был кросс-платформенным, пиши его на С++. Ну или на С, это тоже сработает.

Что технологического я ожидаю в 2012 году:

• Запуск Visual Studio 2012, в комплекте с поддержкой Metro-style apps, AMP и отладкой на GPU, C#5 и так далее. Запуск новой Студии в Петербурге буду проводить лично, если только Microsoft не передумает и не снимет снова Прибалтийскую для эвента на 500 человек как на запуск 2010й. Впрочем, я не против, так и так.

• Разработческая конференция на пароме, курсирующем по скандинавии. С последующими туристическими ответвлениями. Будет весело.

• Смерть и/или перерождение RIM. Серьезно, что же с ними будет? Кто-нибудь может себе представить WP7 на Blackberry?

Ну и наконец:

• В 2012м я окончательно уеду из России (куда – пока секрет, скажу лишь что это не Англия и не Швеция). Впрочем, произойдет это небыстро – переезд это дело мутное, нужно сделать 1000 дел, все проверить-перепроверить, совершить несколько плановых полетов. Главное что это произойдет – понимание этого уже радует.

P.S.: С Новым Годом!!!

Да, сразу подчеркну – лайфхак этот не очень-то зависит от языка, хотя конечно я его использую в C#.

Строка как магический псевдоконструктор

Первое наблюдение – это то что многие объекты поддерживают метод Parse() – не только int или decimal, но такие объекты как DateTime, TimeSpan, XElement и так далее. Это значит что написав строку, отдаленно похожую на дату, я могу сконвертировать ее в правильный вызов конструктора DateTime:

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

Строка как неживая часть кода

Языки можно мешать – например HTML и C# в MVCшных вьюшках. И если вы не боитесь временно – примерно на долю секунду которая нужна чтобы выполнить контекстное действие – потерять контроль над кодом, то кто мешает вам, например, делать string splicing в PHP-стиле, но в коде C#?

Вот что я имею ввиду:

В примере выше, мы вставили идентификаторы C# прямо в строку, а потом вызвали контекстное действие, которое заменило всю строку на правильный вызов String.Format().

Строка как мимолетно существующий DSL

В погоне за оператором ?. (цепочная процерка на null), многие сели на Roslyn и аналогичные вещи. Но ведь проблема цепочной проверки может очень просто решиться если вместо введения оператора мы дороворимся, что любое выражение в форме a.b.c может быть написано как строковый литерал и, мановением волшебной палочки превратиться в

a == null ? null : (a.b == null ? null : a.b.c)

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

Внимательные читатели заметят, что то же самое можно извлечь и из вполне валидного идентификатора. Что ж, не спорю. Мне просто лень по нему гулять – для меня сделать string.Split() намного проще :)

Подобных встроенных DSLов можно сделать море. Например, можно взять нотацию HTML Zen и из этого строкового литерала создать декларацию XLinq которая соответсвует исходному коду. Возможности безграничны.

Как это работает

Сразу скажу – реализовать подобное тривиально. Для Решарпера, нужно просто контекстное действие, которое говорит вам что вы «на строке», создает новый кусок кода, и делает обмен:

[ContextAction(Group = "C#", Name = "Hide string value",
  Description = "Ensures the string is not human-readable in code.",
  Priority = 15)]
public class StringHideRealValueCA : IContextAction
{
  private readonly IList<IBulbItem> items = new List<IBulbItem>();
  private readonly ICSharpContextActionDataProvider provider;
  public StringHideRealValueCA(ICSharpContextActionDataProvider provider)
  {
    this.provider = provider;
  }
  public bool IsAvailable(IUserDataHolder cache)
  {
    var e = provider.GetSelectedElement<ICSharpLiteralExpression>(true, true);
    if (e != null && e.IsConstantValue())
    {
      if (e.ConstantValue.IsString())
      {
        var s = (string)e.ConstantValue.Value;
        if (!string.IsNullOrEmpty(s))
          items.Add(new StringHideRealValueImpl(provider, e));
      }
    }
    return items.Count > 0;
  }
  public IBulbItem[] Items
  {
    get { return items.ToArray(); }
  }
}

В коде выше, StringHideRealValueProvider прячет естественную строку, подменяя ее Base64-закодированной строкой. Вот, собственно, реализация:

private class StringHideRealValueImpl
{
  // очевидные методы опущены
      protected override Action<ITextControl> ExecutePsiTransaction(ISolution solution, IProgressIndicator progress)
  {
    CSharpElementFactory factory = CSharpElementFactory.GetInstance(provider.PsiModule, true);
    var value = literal.ConstantValue.Value as string;
    if (value != null)
    {
      string encoded = Convert.ToBase64String(Encoding.Unicode.GetBytes(value));
      ICSharpExpression ex = factory.CreateExpressionAsIs(
        string.Format("System.Text.Encoding.Unicode.GetString(System.Convert.FromBase64String(\"{0}\"))", encoded));
      literal.ReplaceBy(ex);
    }
    return
      tc => provider.PsiFile.OptimizeImportsAndRefs(
        provider.Document.DocumentRange.CreateRangeMarker(provider.Document), false, true, progress);
  }
}

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

Заключение

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

Тем не менее, мы должны признать, что по крайней мере в свете анонсов касательно WinRT, язык программирования С++ снова становится более актуальным чем ранее. Да и не только сам С++. Ведь фактически то, что нас ждет, это некая реинкарнация COM, правда с другими терминами и, возможно, меньшим количеством проблем. (Ведь неслучайно PIA – Primary Interop Assembly – расшифровывается также как Pain In the Ass;)

Если быть честно-откровенными, то тот С++ который предлагает нам Microsoft – это совсем не «стандартные» плюсы. Хотя, точно так же как и в случае с C++/CLI, остается возможность использования «труъ» кода, который был написан ранее. Но вот уже в 3й раз нам предлагают некую магию.

Почему в 3й? Ну, 1м разом я считаю все те изменения языка, которые не были стандартизованы. С Java/Visual J++ такое не прошло т.к. там правила ныне отошедшая на покой компания Sun, в случае же с С++ не нашлось стороны, которая единолично планировала бы получать доходы с этого языка. Поэтому Microsoft могла сделать все, что угодно – добавить поддержку свойств (да-да, свойств в стиле C#) с помощью __declspec(property), замутить поддержку COM с помощью #import, ну и так далее. Вторым вмешательством в С++ можно считать MC++ и с последствии С++/CLI, который добавил массу ненужных ключевых слов, а также эти ненавистные шляпки (^) для классов. Ну и так далее.

Впрочем, создание C++/CLI было вынужденным. Я это начал понимать только тогда, когда начал встречать кросс-платформенные (!) библиотеки на С++ которые компилировались, помимо обычного С++, еще и с «управляемой прослойкой» для .Net языков. Идея в принципе оказалась правильной – дать .Net разработчикам всю мощь С++ библиотек без особого напряжения в виде P/Invoke или надобности обращать С++ библиотеки в COM.

Ну и наконец, шаг 3й – это полностью узаконить любые новшества в С++ сделав его одним из официальных языков разработки для Windows. Это на самом деле лицемерие – ведь для Windows итак можно писать на «плюсах» используя MFC или даже WTL. Но уверен что мало кто этим занимается. Потери от этого больше, чем потери от требования наличия .Net Framework Client Profile на компьютере. Кстати – недавно в процессе тестирования лицезрел что происходит если поставить ClickOnce-программу которая использует .Net 4 на Windows XP. Инсталлятор сам скачивает и устанавливает framework. Это конечно нехилый download, но большинство людей 100-мегабайтные файлы уже практически не пугают.

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

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

Давайте определимся с тем, что же дает нам С++ чего не может дать тот же C#.

Ручное управление памятью. У меня в голове иногда случаются страшные баталии, связанные с тем, нужно ли делать объект структурой или классом. В принципе, в .Net нам пытаются навязать ограничение, связанное с размером объекта – дескать, если маленький то можно и структуру, а иначе ни-ни. Но это подразумевает что мы, разработчики, наивно делаем pass by value и тем самым поедаем память. Что не всегда так.

Доступ к высокопроизводительным инструкциям процессора. Возьмем например SIMD. Думаю можно с большой степенью уверенности сказать, что JIT-компилятор не оптимизирует и никогда не будет оптимизировать код под SIMD. Соответственно, мы с Microsoft.Net начинаем проигрывать даже Mono, где есть соответствующий пакет.

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

О да, я же забыл упомянуть о самом важном – Microsoft ныне разрабатывает свои библиотеки для С++. Примером такой библиотеки может быть вышеупомянутая Parallel Patterns Library (PPL), которая с одной стороны может считаться «неуправляемым» аналогом .Net’ного TPL, а с другой – конкурентом Intel Threading Building Blocks (TBB). Но на этом все не останавливается – Microsoft работает еще на одной библиотекой под названием C++ Accelerated Massive Parallelism (AMP), которая будет заниматься поддержкой вычислений как на CPU так и на GPU.

Программирование для GPU заслуживает отдельную заметку. На данный момент, графические процессоры можно программировать с помощью OpenCL (вариации языка С++ для различных устройств), CUDA C (подобия С++ для чипов NVidia, кстати с прекрасным тулсетом для Visual Studio). Существуют также решения на .Net, такие как исследовательский проект Microsoft Accelerator (который, насколько я знаю, также работает с FPGA) или коммерческое решение GPU.NET.

Недостатки С++

С++ архаичен. Использовать его для ООП – делать себе плохо. Даже со всеми новшествами C++ 2011 является динозавром, пусть и динозавром который пока не думает вымирать. С другой стороны, С++ прекрасно подходит для производительных алгоритмов.

Приведу пример. Мне в TypograFix нужно обрабатывать Bitmap’ы. Если использовать .Net, то единственная возможность получить более-менее вменяемую скорость по обработке картинок – это использовать unsafe. Что как бы само по себе не очень эффективно, но даже если у вас получится, вы не сможете эффективно настроить параллелизацию unsafe кода. (Автор пробовал использовать TPL и unsafe, с весьма мутными результатами.)

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

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

AMP

У инициативы AMP есть одно существенное приемущество – над этой технологией работают AMD и NVidia, две компании которые держат рынок графических карт (лично я тяготею к AMD потому что у них есть Eyefinity). Работают они над ней, конечно, с Microsoft, т.к. у всех трех компаний есть уклон в сторону различных процессоров. Кстати, в случае с Microsoft, это конечно же ARM, о котором вы все уже наверняка наслышаны. Соответственно идея, как мне кажется, в том, чтобы иметь код (возможно даже код низкого уровня – драйвера, кодеки, и т.п.) который мог бы выжать максимум возможностей из любого процессора.

С другой стороны, по крайней мере для GPU, поддержка идет по наименьшему знаменателю, и этот знаменатель называется DirectCompute. Поэтому неизвестно, будет ли AMP настолько эффективен как например CUDA C или кросскомпиляция, скажем, C# в NVidia PTX (именно это делает GPU.NET). Также непонятно, придется ли писать fallback-код для CPU в случае отсутствия девайса с поддержкой DirectCompute – если это придется делать, то часть шарма данного подхода пропадет, т.к. это точно не «write once, run everywhere».

Intel C++

Microsoft не является единственной компанией, которая выпускает компилятор С++. Intel тоже делает компилятор, в большей степени заточенный на свои процессоры, с неплохой интеграцией в Visual Studio. Важен не только сам компилятор (а он хорош), но и тулсет – отладчик, профилировщик, библиотеки. Все это на высоте. Библиотеки, например, работают более резво на процессорах AMD чем библиотеки самой AMD.

На сегодняшний день я готов работать только с компилятором Intel. Я не использую C++/CLI, мне хватает P/Invoke. На самом деле, технология P/Invoke – настолько простая и понятная, что я не чувствую особого стеснения когда пишу часть проекта на C# а часть на С++. Что P/Invoke не поддерживает так это, конечно же, ООП и возможность передавать туда-сюда классы, но тут я скажу вот что: если вы используете С++ именно для ООП (или для взаимодействия с .Net) – вы делаете что-то не так. На С++ нужно писать производительные алгоритмы, или использовать уже существующие библиотеки (например, Intel TBB, MKL или IPP). Потреблять ООП-структуры там бесполезно, но с другой стороны, не возбраняется потреблять оттуда COM. Например, когда только вышли библиотеки Direct2D/DirectWrite, я захотел ими воспользоваться в WPF-проекте и просто написал C++ DLL’ку, которая рисовала в «залоченый» System.Drawing.Bitmap. Никаких проблем.

OpenMP

OpenMP – это поддержка декларативной параллелизации на С++. Это может показаться шуткой, но на самом деле это старая, проверенная временем технология, которая работает. Для большинства случаев data-level параллелизации в стиле parallel_for() подходит именно OpenMP. Я много где использую именно OpenMP, оставляя Intel TBB для более сложных задач, где автоматический подход не сработает.

Конечно, в .Net есть некий аналог – использование TPL и надежда на то, что JIT-компилятор магическим способом оптимизирует и «векторизует» сгенерированный код. Но это достаточно наивно. Пока вы проверяете индекс элемента доступа к массиву, вы теряете в производительности. Как только вы это отключите, у вас начнутся уже другие проблемы.

Если честно, я не большой фанат TPL. Для простеньких случаев в которые не хочется вникать, я просто пишу Parallel.Invoke или вставляю AsParallel() в цепочку LINQ-запроса и надеюсь на лучшее. Но если мне нужно почитать дистанцию Левенштейна на огромном наборе данных, то я даже напрягаться не буду – отошлю все данные в неуправляемый код, а там уж сделаю все «правильно».

Заключение

Я надеюсь, что повышенное внимание к С++ приведет к улучшению редактора. Правильный IntelliSense уже будет достижением. А что еще надо – ах да, возможно какой-нибудь генератор P/Invoke оберток и соответствующей документации для того чтобы упростить процесс.

К слову скажу, что недавно пытался найти нормальный блог по С++ путем вбивания “с++ блог” в гугле. Гугл выдал какой-то мусор. Если кто-то знает интересные блоги на русском, дайте ссылочку в комментариях. Спасибо.

С++ устарел. Программы на С++, как бы красиво они не выглядели, не соответствуют современным реалиям. Попытки пропатчить C++ под 0x/2011 выглядят трезвыми только на фоне того, что в “плюсах” появились лямбда-выражения, а в Java 7 у Oracle нехватило силенок их сделать.

Вообще, мне по большому счету все равно. Все равно насчет Java-стека т.к. на Java я не пишу, на Scala меня не тянет (синтаксис F# на порядок лучше, имхо). С другой стороны, у меня есть небольшие “вкрапления” С++ в проекты, поэтому о них наверное стоит рассказать.

Зачем нужен С++?

Конкретно мне С++ нужен для параллелизации. Нет, поймите меня правильно, я ни в коей случае не против TPL и всяких прелестей вроде Parallel.For или AsParallel(). Более того, все что я сейчас делаю с коллекциями обычно содержит использование TPL т.к. это достаточно безопасный способ ускорить программу.

Но есть ряд областей где .Net-а мало. Возьмем например обработку изображений – даже если вы напишете обработку Bitmap’а в unsafe режиме на C#, это все равно будет существенно медленнее чем использование C++. Особенно если учесть, что в плюсах есть доступ к SSE (__mm_mul_ps и все такое). И самое главное, что манипуляций-то никаких особо не нужно, т.к. класс System.Drawing.Bitmap может выдать указатель на фиксированный блок памяти, который в последствии можно через P/Invoke передать в тело метода на C++. А дальше можно использовать все прелести OpenMP, Threading Building Blocks, а также мощный инструментарий.

Кстати о… думаю стоит пояснить, что я религиозно использую стек Intel, т.е. Intel Parallel Studio со всеми прелестями. Это важно потому что инструментарий этот достаточно хороший и много чего умеет, компилятор С++ от Microsoft в былые годы (до Intel) был ооочень слабоват – в те времена, чтобы заработали примеры из Generative Programming, нужно было использовать KAI C++, Metrowerks или еще какой-то сторонний компилятор. Мне правда повезло – на шаблонное метапрограммирование я так и не подсел, хотя идея конечно заманчива.

Итак, если прорезюмировать то, зачем мне С++ нужен, должен сказать, что нужен он для производительности в параллелизуемых алгоритмах. Для нативных библиотек С++ не критичен, т.к. всегда можно написать P/Invoke обертку или скачать уже готовую, а вот для новых, свежих алгоритмов – при условии что они не требуют качественного библиотечного окружения – С++ очень даже подходит.

А причем тут D?

Я уже давно хотел попробовать D, но все нехаватало времени. Теперь же у меня получилось истратить день на изучение особенностей языка и выборочное читание частей The D Programming Language Александреску. Книга, кстати, классная – объем информации большой, написано с долей весьма своеобразного юмора.

Собственно использование D под Windows требует от вас две вещи.

Во-первых, нужно скачать компилятор. Инсталлятор (MSI) все делает сам, напрягаться толком не нужно.

Во-вторых, хоть это и опционально, можно скачать IDE или пакет поддержки уже существующей IDE. Я конечно же скачал Visual D – пакет для Visual Studio. Особенности пакета:

• Позволяет создавать проекты на языке D и конфигурировать их

• Весьма слабо поддерживает IntelliSense – можно сказать что поддержки практически нет

• Есть отладка (YMMV, конечно же)

• Все это, увы, 32-bit

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

D vs. C++

В чем же приемущества D? Попробую перечислить то, что бросилось в глаза:

• Нет этого бреда с заголовочными файлами, #pragma once и т.п. Порядок файлов в проекте тоже не важен (F#, я смотрю на тебя). Пишешь module foo в одном файле и import foo в другом.

• Строки… строки вменяемы, почти как в C#. Почти потому что остались извраты с UTF-16 и UTF-32 для тех кто знает в этом толк. Да, естественно что до .Net в плане глобализации не дотянуть – но цель не в этом.

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

• Свойства! Java и С++ могут убить себя об стену, __declspec(property) идет лесом. Свойства, имхо, должны быть в любом современном языке программирования. И тут они есть, и ими приятно пользоваться.

• Piece de resistance: ключевое слово mixin. Самый вменяемый подход к метапрограммированию, который просто ставит в угол Boo, Nemerle и иже с ними.

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

Mixin

Как работает метапрограммирование в языках вроде Boo? Там с помощью цитирования создается объектная модель кода – например [| x + y |] превращается в BinaryExpression. Вставки из реального мира делаются с помощью splice-оператора $. Тем самым, чтобы хоть что-то сгенерировать, нужно уметь создавать объектную модель нужного кода.

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

В языке D, инструкция mixin просто принимает строку. Напишите mixin("string Name;") и вы добавили в класс поле Name. Тривиально. Естественно что строки можно не только передавать напрямую, но и создавать отдельные функции, которые исполняются на этапе компиляции. Это решает проблему метапрограммирования в большинстве случаев.

Недостатки

Куда же без них. Вот то, что я успел заметить:

• Дебаггер порой идет совсем не туда куда нужно. Вложенные функции и делегаты дебажатся “с грехом пополам”.

• Конкретно под Windows, D компилируется только в 32-bit.

• Стандартные библиотеки конечно не дотягивают до какой-нть STL но они намного более вменяемы. Так что это палка о двух концах.

• Стандартных библиотек на самом деле две – Phobos и Tango. Какую использовать – непонятно. В Phobos я уже столкнулся с недопиленностью – например std.xml сейчас переписывается.

• Никто пока не воспринимает D серьезно. Даже у F# больше exposure чем у D, что собственно понятно – ведь F# продвигает Microsoft и этот язык активно используется в quant finance.

• IntelliSense не работает в Visual D. Надо будет еще глянуть на D-IDE которая, кстати, написана под .Net 4 :)

Впечатления

Мне D очень понравился. Это язык с максимальным уровнем вменяемости и достаточно низким уровнем шума. Если вам не нужно завязок на 100 библиотек, D позволит вам быстро разрабатывать и компилировать ваш код. При этом вы не теряете в выразительности – тут и делегаты, и события, и вложенные функции, функциональные литералы (= лямбда-выражения), не говоря уже о совсем продвинутых вещах вроде вариадичных шаблонов.

Резюмируя, должен сказать что D меня очаровал, и в ближайшее время я планирую его использовать к некритичных, non-production проектах дабы прочувствовать все его возможности. А они, судя по первичным наблюдениям, весьма обширны.

Знакомьтесь – квонты

Квонт, он же quant (quantitative analyst – численный, так сказать, аналитик) — это человек, который занимается применением математики в финансах, часто – для создания торговых систем, т.е. программ, которые занимаются автоматизированной торговлей на бирже. Эти люди – чаще всего магистры или PhD в области физики (да-да) или математики (в частности, с дипломами вроде MFE – Masters in Financial Engineering), в некоторых случаях, с дипломом CQF (один из очень небольшого кол-ва “неакадемических” дипломов) или даже с MBA Finance или а ля.

Квонты (я бы называл их квантами) программируют в очень узком ключе – их в большинстве случаев не волнуют новые тренды в Asp.Net или новых языках вроде Scala или D. Они живут в совершенно другой реальности, где доминантным маст-хэв языком был, есть и будет С++. Конечно, есть варинты (например, вспомним Jane Street и их любовь к OCaml), но суть остается одна – эти разработчики привыкли работать с достаточно ограниченным tool support, и не особо от этого страдают. Ведь согласитесь, для того чтобы эффективно выполнять математические рассчеты нужно лишь чтобы у вас худо-бедно работал intellisense, и то, это не так критично если нужно вызвать что-то вроде std::min().

Соответственно, текущее положение вещей наводит на мысль, что людям которые используют в основном C++ (а также MATLAB, VBS, R, ну и другие языки на вкус) tool support как бы не очень нужен.

И все же…

Приведу конкретный пример. На многих графических устройствах, операция a*x+b оптимизирована и проходит быстрее, чем умножение и сложение отдельно. Соответственно, когда я работаю с GPU.NET, у меня есть в R2P контекстное действие, которое превращает все, что похоже на “умножение-в-сложении” на вызов вроде DeviceMath.MultiplyAdd(a, x, b). Мелочь, а приятно, и программу ускоряет.

И это далеко не частный случай. Вот еще пример – допустим что вы попросили студента за еду реализовать вам ряд формул в коде, и студент в качестве реализации написал что-то вроде y = a * Math.Pow(x, 2.0) + b * x. Бред, не так ли?

И тут снова можно включить “электронный мозг” статического анализатора и начать помогать несчастному разработчику. Для начала ему нужно объяснить, что считать ряды Тэйлора в подобном случае раз, эээ, в 50 медленнее чем сделать x*x. Но даже объяснив это, вы получите вот такой результат:

y = a * x * x + b * x;

Это тоже не очень-то эффективно. Ведь тут целых 3 умножения, хотя можно обойтись двумя:

y = x * (a * x + b);

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

А это имеет смысл?

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

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

int [] elems = new int[] { ⋮ };
int sum = 0;
foreach (var e in elems) sum += e;

то почему бы нам не дать ему возможность отрефакторить этот цикл в параллельный:

Parallel.ForEach(elems, () => 0, 
                 (n, loopState, localSum) => 
                 {
                   localSum += n;
                   return localSum;
                 },
                 localSum => Interlocked.Add(ref sum, localSum));

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

Другие языки?

Я привел пример поддержки C#, т.к. не знаю доступной инфраструктуры для написания рефакторингов для С++ или (это было бы еще интересней) для CUDA C. Было бы интересно услышать мнение читателей насчет применимости всех этих идей.

Для начала, я создаю класс DisposableCollection который умеет вызывать Dispose() на каждом элементе коллекции:

public sealed class DisposableCollection : Collection<IDisposable>, IDisposable
{
  public void Dispose()
  {
    foreach (var obj in this)
      obj.SafeDispose();
  }
}

SafeDispose() в коде выше – это всего лишь Dispose() с проверкой на null. Метод также возвращает «флаг успешности», что порой бывает полезно.

public static bool SafeDispose(this IDisposable thіs)
{
  if (thіs != null)
  {
    thіs.Dispose();
    return true;
  }
  return false;
}

Еще один extension method — это инверсия потока управления для добавления элементов в коллекцию:

public static T AddTo<T>(this T thіs, Collection<T> coll)
{
  coll.Add(thіs);
  return thіs;
}

А теперь всем этим можно пользоваться. Для подписок используем ReactiveExtensions.

public sealed class XmppConnectionManager : IResetable
{
  private XmppClient client;
  private DisposableCollection subscriptions;
  private void InitializeEvents()
  {
    // wire up events
    Observable.FromEventPattern<ExceptionEventArgs>(x => client.OnError += x, x => client.OnError -= x)
      .Subscribe(x => OnError(x.EventArgs))
      .AddTo(subscriptions);
    Observable.FromEventPattern<EventArgs>(x => client.OnLogin += x, x => client.OnLogin -= x)
      .Subscribe(x => OnLogin(x.EventArgs))
      .AddTo(subscriptions);
    ...
  }
}

Соответственно, если нужно вдруг отписаться от всех подписок, это делается очень быстро:

subscriptions.SafeDispose();

А теперь загадка: почему методы расширения, приведенные выше, компилируются несмотря на название параметра thіs? Дам намек: как ключевое слово имя параметра не подсветилось.

public void y(double a, double b, double c, double x)
{
  return x*(a*x + b) + c;
}

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

Код выше легко генерить, и созданное AST позволит вам создать код на любом языке, будь то на C#, F# или C++. Но зачем останавливаться на этом?

Недавно, я начал работать с GPU.NET. Несмотря на наблюдения автора одной не особо хорошо отрецензированной статьи на RSDN, библиотека работает, и подход мне нравится. А поэтому, мне пришла в голову (гениальная?) мысль — MathSharp может оптимизировать код не только для CPU но и для GPU! В результате, наша функция выше может выглядеть вот так:

public void y(double a, double b, double c, double x)
{
  return DeviceMath.MultiplyAndAdd(DeviceMath.MultiplyAndAdd(a, x, b), x, c);
}

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

Кстати, MathSharp — это такой небольшой пруф того, что приложение может быть написано на F#, использовать функциональные фишки (алгебраические типы, рекурсивный частичный паттерн-матчинг) и при этом жить, продаваться, развиваться. Правда если хотите tool support то вам скорее сюда — увы, я решил что делать из FSharper коммерческий продукт – слишком сложно. Основная причина – что F# не “тянет” чтобы парсить сам себя. По скорости не тянет. На GPU может и можно, но это нужно исследовать.

Ну и напоследок – кто-нибудь может посоветовать workflow engine для коротких операций? Не workflow foundation со всем его багажом, а что-нибудь легковесное, чтобы можно было “самодокументировать” алгоритмы через какой-нть fluent interface или dsl. Заранее спасибо.

С чего все начиналось

Когда я обитал в сфере финансового программирования (было же такое), одна из задач была в том, чтобы “сливать” воедино финансовые показатели из различных источников. Начиналось все достаточно просто – берем какую-то котировку, делаем для нее квантизацию (это когда нужно подсчитать агрегированные значения за последнюю минуту/час/день и т.п.) а потом начинаем считать всякие показатели (к пр. движимое среднее). Сейчас такие задачи делаются с помощью Reactive Extensions, под которым, должен сказать, аггрегаторы и квантизаторы выглядят не лучшим образом. Тогда же это делалось более примитивными методами. Но не суть…

Так вот, в те времена подход GPGPU был не ахти какой популярный, и соответственно все утыкалось в слабый перформанс моего одноядерного процессора. И, естественным путем, я набрел на то, что по-хорошему нужно использовать несколько машин чтобы все эффективно считать. Механизмы общения между компьютерами в те времены были ни ахти какие, соответственно использовались такие извращения как NServiceBus/MSMQ которые, конечно, имеют свои приемущества, но все же “не айс”.

Самым прикольным было написать консоль, которая показывала бы как моя сеть в realtime обсчитывала те или иные показатели. Более того, в те времена я также использовал нейронные сети (MLPs w/backpropagation) и у меня даже остался код, которые по объектным моделям сетей генерировал диаграммы в PowerPoint. Забавное было зрелище.

Сети – это же так соблазнительно!

Качество работы на среднестатистической “винде” прогрессивно снижается. Когда я начинал программировать на Visual Studio 97, в моем компьютере было 16Мб (мегабайт!!!) RAM, но при этом все работало. Сейчас такой experience можно получить разве что скачав EVC++ 4 (завидую эмбедщикам!). У нас же в плане разработки все плохо – сплошные тормоза. Вон только вчера коллега рассказал, что получил удовольствие от использования Visual Studio 2008 для части ReSharper SDK. Когда я его спросил что у него за машина, оказалось что и 16Gb RAM и SSD у него присутствуют. Так что делаем выводы…

Все это наводит на достаточно печальные мысли. Компьютеры будут становиться быстрее, но “затыки” в производительности будут, и со временем они будут все больше и больше. А нам нужно разрабатывать, а не ждать 15 минут пока полсотни референсов в проект добавятся (таргет-файлы рулят!).

Поэтому единственная вменяемая стратегия, к которой я на данный момент пришел сводится к следующим вещам.

Во-первых, я ратую за экологичное программирование, т.е. если вы используете машину для разработки, не стоит на ней ставить доменный контроллер, IIS, AppFabric и еще 100500 различных сервисных примочек. Ни в коем случае не стоит ставить серверные технологии которые используют SQL Server т.к. эта штука сама по себе съест 1-2Gb оперативки, так она еще и будет диск дергать даже когда никто к ней не обращается. А потом, в один прекрасный день, вы увидите что вместо того чтобы разрабатывать, вы думаете как бы засунуть SQL Server’ный кэш в RAM. Или что-то в этом духе.

Во-вторых, я за распределенную разработку. Писать код можно и на одном компьютере. Но держите свои затраты к минимуму. Ставьте десктопную ось (да-да, сейчас модно ставить 2008R2 везде где не попадя, я тоже на это попался в свое время). Если можете себе это позволить – ставьте XP. Windows, VS и ReSharper/dotTrace/dotCover/TortoiseXxx – плагины, естественно по вкусу. Остальное – в топку! А точнее на другой компьютер.

Что это дает?

Я уже слышу крики в стиле “мне всего и так хватает!”. Что же, если вам итак хорошо, рад за вас. Это как извечная дискуссия про мониторы – каждому свое. Но если говорить о приемуществах такого подхода, то их масса.

Главное приемущество – это моментальный фидбэк. Представьте, что у вас есть солюшн который собирается, скажем, две минуты. Две минуты – это вечность. Особенно если билд провалился с какой-то дурацкой ошибкой которую не отловил статический анализатор. Да, мы говорим не про простенькие проектики, мы говорим например про системы где смешан С++ (адски медленная компиляция), C# и Java (да-да, Java – она примешана тут осознанно). Если учесть сложность cross-VM конфигов, все это дело работает не так быстро как хотелось бы.

Так вот, представьте себе систему, где фидбэк по сборке, тестам, и даже покрытию (хотя с покрытием сложнее) получается моментально. Причем он никак не затрагивает ваш разработческий комп, т.к. мы договорились держать его стерильным. Моментальный фидбэк стоит многого! Особенно это затрагивает такую проблему как тестирование на staging-серверах. На Хабре был пост про то, надо ли стабить репозитарии. Так вот что я думаю – если вы можете себе это позволить, тестируйте на staging-базах! Главное чтобы эти тесты не вызывали затыков. А если вызывает затыки – просто добавьте воды машин!

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

Компиляция

Разработчики С++ уже давно поняли что сборка проектов должна быть распределенной, и на рынке есть для этого соответствующие решения. Но если вы думаете, что в .Net все лучше, то вы правы только отчасти. Да, .Net собирается быстрее, хотя я уверен что новый C#5 компилятор будет намного медленнее в силу своей managed структуры. Опять же, еще один аргумент в том, что де нынче MSBuild поддерживает параллелизацию напрямую, и тем самым грамотное использование MSBuild вместе с правильной, loosely coupled архитектурой, как бы избавляет нас от проблем с медленной компиляцией.

А вот и нет!

На практике все сводится к следующим моментам. Во-первых, стоимость компиляции связана не только с созданием сборок – компиляция как таковая включает в себя массы различных процессов, таких как кастомные task-и которые вы используете. Например, процесс XSLT-трансформации путем какого-нть community task‘а может стоить намного больше чем компиляция.

Во-вторых, этот аргумент не применим на mixed-mode проектах. С++ играет по своим правилам, особенно если вы делаете что-то сложное. Да, ваша сборка может скомпилироваться параллельно с другими. Но это не покрывает изначальную проблему – она скомпилируется медленно. Это, кстати, влияет не только на С++ — даже тот же F# компилируется медленнее (что понятно), не говоря уже про языки вроде Scala (reminder: Scala компилируется в 10 раз медленнее Java).

В третьих, все как-то забыли что некоторым проектам нужно собирать несколько конфигураций. В этом случае параллелизация на уровне конфигураций имеет смысл – тут мы билдим staging, а тут – production. Естественно, никто не мешает настроить разные конфигурации на разных build-системах. Действительно, на практике многие разработчики используют TeamCity для параллелизации подобных задач. Одна из самых популярных – параллелизация тестирования. Кстати о нем…

Тестирование

Тестирование бывает разным. Одно дело когда вы нажали F5 на проекте, который открывает VS в дебаг-режиме. Если у вас комп с 4Gb RAM и Раптором – вы попали. Можете смело идти за кофе/чаем/печеньками. Отладочный экспириенс будет адским. Да – и не думайте что удаленная отладка вам поможет. Во-первых, вы замахаетесь ее настраивать (у меня на это полдня ушло), но даже настроив, вы сразу поймете, что игра не стоит свеч – идея неплохая, но скорость – улиточная. Snail speed. Если действительно хочется делать отладку на другой машине, более вменяемым решением мне лично кажется использование VMWare Workstation. Но так или иначе, тормоза будут.

Но я сейчас немного не про это, а скорее про банальное unit/integration-тестирование. Сейчас в этой сфере ведется работы по разным направлениям – например работы связанные с автопрогоном только тех тестов, которые были затронуты изменениями в коде. Примеры таких программ – NCrunch и Mighty Moose. А теперь угадайте, какой основной смысл этих программ? Правильно – экономия ресурсов. Вызывать только те тесты которые были затронуты. А не все подряд.

На самом деле, это очень сложная задача. В чем проблема вызова абсолютно всех тестов? Правильно, в том, что эти тесты могут задевать сотню различных систем. Да-да, я не только про юнит-тесты говорю, но и про интеграционные тесты – включая те, которые например дергают реальные базы или устройства. Их-то тоже хочется тестировать, причем опять же вопрос ставится так: если мы можем тестировать постоянно – почему бы не делать это? Лично я – ярый сторонник непрервыного тестирования. И не только по комиту – а например по любому компилу. Сделал тестовую сборку – она сразу же ушла в тестирование. Если что упало – результаты сразу же возвращаются к разработчику.

Так что там про FreeSpace?

FreeSpace – это мое новое детище. FreeSpace – это Windows-сервис который можно устанавливать на любые машины где угодно. Фактически, этот сервис объединяет машины в ботнет, который умеет заниматься распределенной компиляцией, тестированием, развертыванием, и так далее. FreeSpace работает как на реальных так и на виртуальных машинах, неприхотлив (дружит с ХР) и требует минимальное кол-во конфигурирования.

FreeSpace использует XMPP (в частности – библиотеку MatriX) и механизмы облачной синхронизации файлов. XMPP гарантирует что машины могут беспрепятственно коммуницировать между собой, при условии что у вас стоит XMPP-сервер (поставить какой-нть ejabberd занимает полминуты). А механизмы облачной синхронизации позволяют гарантировать, что на всех инстансах одни и те же файлы. Поскольку сервис работает через MEF, файлы можно обновлять динамически.

Основная цель FreeSpace – балансировка нагрузки, т.е. составление сбалансированных планов исполнения. Собственно выполнение задач на себя берут уже готовые тулзы. Для компиляции, например, это может быть MSBuild, для тестирования – Gallio. Суть в том, что имея информацию о всех нодах в сети, а также агентах на этих нодах (на одной ноде можно бегать более одного агента), можно сформировать сбалансированный план компиляции или тестирования, который оптимально использует все доступные ресурсы и при этом уважает предпочтения самого нода, т.е. знает что нельзя перегружать нод, который уже занят или имеет какие-то другие обязанности.

Одно из приемуществ FreeSpace – системе полностью плевать на домены. Синхронизация через XMPP способна игнорировать все firewall’ы и протаскивать трафик через порт 80, если это надо (ну, это теоретически… это нужно тестировать). При этом трафик можно шифровать, так что идея о том что де кто-то украдет контрольные данные в транзите или подменит их тоже отпадает. А сами файлы синхронизуются с помощью изначально безопасной системы (так по крайней мере нам говорят), поэтому кроме как на нодах к ним не достучаться. И даже достучавшись, система-то распределенная, так что всей картины все равно не получите – хотя конечно подразумевается, что нодам вы доверяете.

Более сложные задачи

Есть более сложные задачи, которые пока не решить ну никак. Во-первых, было бы здорово вынести за пределы компьютера разработчика весь статический анализ и сделать некий ‘FxCop/R#/whatever as a service’. Если это сделать, и если это хоть как-то параллелизуемо (есть подозрение что не очень), это позволит делать намного более глубокий/затратный анализ и тем самым получать намного более умные эвристические подсказки.

Покрытие – запредельно затратная операция, поэтому вынести его наружу тоже хотелось бы. Это, правда, менее приоритетная задача, т.к. я не большой фанат покрытия. Но с другой стороны, имея уже готовый механизм для измерения покрытия (к пр., dotCover), я не вижу никаких причин не применять измерение покрытия, скажем, к разным тестовым фиксчам на разных машинах. Главное чтобы можно было слить все результаты воедино и как-то их продемонстрировать. (Прошу заметить, что в отличии от результатов тестирования, результаты покрытия таки требуют наличие локальной Visual Studio для подсветки и навигации. То же отчасти верно и для обычного юнит-тестирования, хотя там и не нужно вклиниваться в редактор.)

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

Вместо заключения

FreeSpace разрабатывается в первую очередь не как коммерческий продукт, а как система, которая сможет, при наличии достаточного количества машин, существенно сэкономить количество времени, требуемое для работы с крупными проектами. Соответственно, пишу я ее в основном для себя, с уклоном в те проблемы (например, тестирование в виртуальной среде – VMM/HyperV) которые являются для меня наиболее насущными.

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

А пока всё! Comments welcome! ■

Примечательно то, что простенькая задача сохранить в словарике несколько пресетов и потом записать все это в Properties.Settings превратилась в непростую затею.

Первая попытка

Сначала я сделал все правильно: создал Dictionary<string, ConversionOptions>, то есть мэп названий пресетов на их значения, и тупо попробовал записать все это в настройки. Ничего не получилось. Оказывается, большое количество классов в WPF (такие как Color или Thickness) не сериализуются! Это значит, что по сути дела чтобы сериализовать тип мне нужно их выкинуть!

Следующей проблемой оказалось то, что .Net бросал исключение при попытке сериализовать событие PropertyChanged. Это правда очень быстро релилось прописыванием [field: NonSerialized], но толком делу не помогло.

Вторая попытка

Проблема в том, что несмотря на то, что все работало, настройки отказались записывать Dictionary<>. Никаких исключений не было, тип просто не сохранялся в Properties.Settings и воответственно при попытке считать, возвращался null.

Самое простое в этом случае (точно так же как и в случае с несериализуемыми типами) – это сконвертировать структуру не в XML а в… JSON! (Формат выбран произвольно.) Соответственно, я скачал ServiceStack.Text и заменил тип свойств в Settings на string. В результате, сериализация происходит вот так:

Settings.Default["OptionPresets"] =
  JsonSerializer.SerializeToString(OptionPresets, typeof (Dictionary<string, ConversionOptions>));

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

Бесшумый источник питания

До поры до времени, источники питания без вентиляторов были мусором “по показателям”, и приходилось терпеть[2]. Это время прошло. Теперь качественные и тихие PSU доступны всем и каждому. Конечно, основная их польза – при построении HTPC, но для офиса они тоже идеально подходят (а вот для геймеров – нет, ибо максимум 400W).

Безвентиляторные (fanless) PSU предсказуемо используют радиатор. Лучший по моему субъективному ощущению (после прочтения обзоров) – Silverstone Nightjar.

Полный обзор, если кто сомневается, можно почитать тут. Стоимость – около $180. В России, естественно, не продается.

Бесшумный кулер

Я сам не очень верил в то что можно иметь беззвучное неводяное охлаждение. Оказывается можно. Порыскав на Frosty’s я увидел в лидерах по уровню шума кулер Scythe Orochi. Пошел, купил, установил и доволен.

С кулером поставляется 14-сантиметровый вентилятор но мне он не нужен (да и в корпус не поместится). Обзор сего чуда можно почитать тут. Стоимость – около $60. В России было очень сложно найти. Сейчас его в России не найти, да и на Западе тоже – он discontinued и его заменят обновленной моделью. Ждем-с.

Бесшумное все остальное

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

Это nVidia Quadro NVS 450. Такая карта тянет 4 монитора и не жужжит.[3] (Да, 4 монитора, если надо больше, можно добавить Quadro NVS 295 – почти пруфлинк.) Карточка стоит $550.[4] В России… да, что там говорить, берите на Амазоне.[5]

Насчет жестких дисков тут все понятно. Либо вы берете SSD и проблема отпадает, либо ставите диск на 5200RPM и проблема тоже отпадает (только работать становится намного сложнее). Главное не баловаться дешевыми неопробованными дисками (у меня тут есть Hitachi на 1Gb – такой слона разбудит) и не пытаться думать что какой-нибудь Raptor (даже под RAID) – хорошее решение.[6]

Диск выше – Intel X25-M на 160Gb – стоит $430 на Амазоне. В России, впрочем, найти его тоже не проблема.

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

Заключение

Вот собственно и всё. Я надеюсь что мне удалось показать то, как “малой кровью” сделать компьютер бесшумным. Конечно, сделать это не так-то просто хотя бы потому что в “этой стране” компьютерное оборудование а) в основном ширпотреб; и b) с неприличной наценкой, но по крайней мере, предложенное мною решение может масштабироваться и не требует огромных временных затрат.

Заметки

1. ↑ Поправка: рано или поздно я буду строить систему с водяным охлаждением – только для того чтобы разобраться как это работает и насколько это сложно. Но это хобби и к делу не относится.
2. ↑ На самом деле – не совсем. Я недавно выкинул систему 5-летней давности которая была фактически бесшумной поскольку использовала внешний адаптер вместо полноценного PSU и была построена на базе Pentium M (да-да, десктоп на ноутбучной платформе). К сожалению, когда я еще был идиотом и не обвешал все бесперебойниками, один перепад напряжения спалил мне трансформатор в этом компьютере, и с тех пор этот комп жил в кладовке с воткнутым в него убогим 350W PSU. Недавно я набрался смелости и снес этот “проваленный эксперимент” на помойку.
3. ↑ Я тут сильно лукавлю: сам работаю на 3-х мониторах (4-й стоит в сторонке и пока ничего не делает). Более того, не все мои экраны подключены к одному компьютеру, хотя и управляются одной с одной пары мышь-клавиатура. Но это уже тянет на отдельный пост :)
4. ↑ Такая сумма за графическую карточку – это дороговато, особенно если учесть что Eyefinity 6 поддерживает сразу 6 мониторов а карточки стоят где-то $500 на Амазоне. Тем не менее, такие монстрообразные карты откровенно шумят, что как бы портит всю идею этого поста.
5. ↑ Товарищ Суворов и его коллеги, которые работают на 3-х мониторах (за одно это респект), исповедуют другой подход: основной графической карточкой поддерживают 2 экрана, а третий—с помошью подпиленной x16 карточки, воткнутой в x4 слот. Да-да, это реально, хотя судя по всему не везде работает.
6. ↑ Рапторы – имеется ввиду Western Digital VelociRaptor – производительные 10kRPM диски которые, тем не менее, адски жужжат и тем самым меня бесят.

Релиз MathSharp

Давным-давно я попал на проект, где при разработке программ нужно было переводить математические формулы в код. Тогда я только и думал о том, как все это автоматизировать дабы конвертировать формулы в код автоматически. И вот спустя несколько лет, я создал проект ActiveMesa MathSharp. MathSharp – это программа, которая умеет переводить контент из формата MathML (который можно получить из Microsoft Word 2007/2010, MathType, Maple и других систем) в код на языках C# или F#.

Вот небольшой видеоролик, в котором показано как работает MathSharp:

Если коротко – вы пишете

а оно переводит это в

p = rho*R*T + (B_0*R*T-A_0-((C_0) / (T*T))+((E_0) / (Math.Pow(T, 4))))*rho*rho +
    (b*R*T-a-((d) / (T)))*Math.Pow(rho, 3) +
    alpha*(a+((d) / (t)))*Math.Pow(rho, 6) +
    ((c*Math.Pow(rho, 3)) / (T*T))*(1+gamma*rho*rho)*Math.Exp(-gamma*rho*rho);

Если вам понравилась идея, само приложение можно найти тут: http://activemesa.com/mathsharp. Стоит оно $95 – дешевле чем один инженерный час, так что если оно кому-то сэкономит хоть час работы, значит выгода уже есть.

P.S.: этот релиз позволил мне получить следующие "ачивменты":

• Зарелизил проект написанный на F# (есть соблазн накатать статейку для fprog.ru)
• Зарелизил самообновляемое приложение

Возобновление встреч Spbalt.net

После небольшого перерыва мы возобновляем наши встречи – уже в другом месте, в помещении которое любезно предоставляет нам компания DataArt. Первые мои семинары проводились именно в DataArt под флагом их DataArt Way. Собственно там все и началось. Так что я доволен что мы сможем снова там встречаться.

Следующая встреча пройдет в четверг 21го. Будет рассказ про создание back-end’а для MMO RPG. Подробности тут: http://spbalt.net/home/meetings/27

Новый проект

После релиза MathSharp нужно чем-то снова заняться, поэтому я решил написать что-то посложнее. Сейчас я в стадии R&D экспериментирую с идеей code provider’ов (по аналогии с type provider’ами). Идея в том, чтобы иметь распределенные сервисы, которые могли бы заниматься не столько анализом сколько порождением нового кода на основе декларативных моделей.

Для тех из вас кому интересно что стало с FSharper’ом, могу сказать что на данный момент проект приостановлен – в основном потому, что надо было делать MathSharp – но возможно я и вернусь к нему. “Ничего обещать не буду.”

Очевидно, нужно искать возможность как-то улучшить user experience. Не имея возможности просто сделать ILMerge на все сборки, у нас тем не менее есть возможность сделать нечто не менее эффективное – а именно создать прокси-сборку для всех типов внутри сборок, и воспользоваться фичей под названием type forwarding, для того чтобы вызывались именно конечные сборки нашего SDK.

Как работает type forwarding?

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

Вот как это работает. Есть у меня сборка FirstAssembly, а в ней тип С:

// FirstAssembly.dll
public class С {}

Далее, другой пользователь пишет свой код, ссылаясь на FirstAssembly.dll:

С с = new С();

Все хорошо, но вдруг я решил передвинуть мой тип C в сборку SecondAssembly.dll, при этом не меняя пространства имен и имени самого типа. Тогда я делаю следующее:

• Удаляю реализацию класса С в FirstAssembly.dll и переношу его в SecondAssembly.dll
• Добавляю ссылку на SecondAssembly.dll в FirstAssembly.dll
• Иду в FirstAssembly, открываю там AssemblyInfo.cs и в нем пишу магическую строчку
  

  [assembly: TypeForwardedTo(SomeNamespace.C)]
  

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

Атрибут сборки на момент компиляции FirstAssembly.dll превращается в следующую директиву:

.class extern forwarder SomeNamespace.C
{
  .assembly extern SecondAssembly
}

Иначе говоря, все, что у нас получается – это лишняя директива которая подсказывает, что если клиент ищет в нашей сборке тип Somenamespace.C но не находит его, имеет смысл поискать этот тип в сборке SecondAssembly.dll.

Обсуждение

Во-первых, следует заметить что какой-то особой поддержки type forwarding со стороны Visual Studio не существует – в лучшем случае, при попытке сослаться на тип из сборки который «переехал», помимо обычной ошибки Visual Studio намекнет вам, что тип «мигрировал» и что для успешной компиляции вам стоит добавить ссылку на SecondAssembly.dll.

В контексте SDK, следует заметить, что

• Вы не можете просто поставлять набор из огромного количества директив TypeForwardedTo и компилировать код. В момент компиляции нужны ссылки на реальные сборки или же на некие прокси, которые в точности повторяют структуру тех сборок, на которые нужно ссылаться.
• В момент исполнения, мы не можем «выкинуть» прослойку, т.к. тогда непонятно откуда брать информацию о местоположении реальных сборок.
• Фактически, требуются две прокси-сборки. Одна – это прокси для компиляции, вторая – с набором директив type forwarding для исполнения.

Теперь я пытаюсь понять, правильный ли это подход, и если да – как заставить Mono.Cecil делать из «реальных» сборок прокси с пустышками вместо методов. ▪

Мотивация

Почему REST? Все очень просто – мне нынче импонируют идеи сайтов, которые находятся полностью на клиенте и работают с серверами именно через REST а не через WS-* или какие-то кастомные RPC-байндинги. REST – это тривиальная парадигма и, казалось бы, любой более менее продвинутый фреймворк должен позволять быстро и эффективно создавать REST-сервисы.

Поэтому я решил испробовать простенький сценарий – взять мой диалоговый фреймворк написанный на WebSharper и перетащить все данные на сервер, осуществив взаимодействие через REST.

Сущности

Первое что я обычно делаю в проекте который хранит данные – это конечно Install-Package norm дабы добавить драйвер NoRM для MongoDB. Коллега Суворов конечно рекоммендует якобы официальный драйвер от 10gen, но у меня итак все работает, в т.ч. Linq, поэтому зачем напрягаться?

Как вы помните, NoRM немного замусоривает наш объект, но он все еще остается “почти POCO”. WCF же в долгу не остается, и “домусоривает” объект еще больше, прописывая свои аттрибуты. В результате получаем классы подобные этому:

[DataContract]
public class ConversationItem
{
  public ConversationItem()
  {
    Id = ObjectId.NewObjectId();
  }
  [DataMember, MongoIdentifier] public string Id { get; set; }
  [DataMember] public string PartyId { get; set; }
  [DataMember] public string Speech { get; set; }
  [DataMember] public List<string> EnableList { get; set; }
  [DataMember] public List<string> DisableList { get; set; }
}

Начинаем писать сервис

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

• OperationContract для того чтобы пометить что это часть сервиса.
• WebGet дабы прописать шаблон вызова а также форматы запроса и ответа.
• JSONPBehavior, но он из коробки не поставляется, и мы о нем поговорим попозже.

Вот пример декорированного метода:

[OperationContract]
[WebGet(UriTemplate = "/c/{id}", RequestFormat = WebMessageFormat.Json, ResponseFormat = WebMessageFormat.Json)]
[JSONPBehavior(callback = "callback")]
public Conversation GetInitialConversationItems(string id)
{
  ...
}

Итак, “из коробки” мы получаем достаточно простой метод, но не хватает двух вещей – обработки ошибок и поддержки JSONP, без которой вы ничего кроссдоменно не вызовете.

Обработка ошибок

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

using (var db = GetDB())
{
  var conversation = db.Query<Conversation>().FirstOrDefault();  
  if (conversation == null)
  {
    var resp = WebOperationContext.Current.OutgoingResponse;
    resp.StatusCode = HttpStatusCode.NotFound;
    resp.StatusDescription = "Could not find conversation with id='{0}'.".ƒ(id);
    return null;
  } 
  else
  {
    return conversation;
  }
}

JSONP

Феноменально, но факт – WCF не поставляется с поддержкой JSONP. К счастью, Microsoft дает такую поддержку в примерах, и то как она выглядит является хорошей демонстрацией того, как гибок WCF в плане расширения.

Всего для поддержки JSONP нужно добавить 5 классов. Детально я описывать их не буду, опишу только вкратце.

1. Во-первых, нужна реализация аттрибута JSONPBehavior который я уже описывал. Фактически, этот аттрибут навешивает на операцию объект типа IParameterInspector, который перед вызовом прописывает в свойства исходящего сообщение свойство типа IMessageProperty для JSON.
2. Класс JSONMessageProperty – это всего лишь обертка для лишнего кусочка метаданных который поставляются поведением. Применим этот довесок только для callback-параметра. Для тех кто забыл, callback-параметр это то с помошью чего данные data возвражаются через запрос http://somewhere.com/x?callback=y как y(data), прописываются в <script> и исполняются.
3. Далее формируется фабрика JSONPEncoderFactory, которая производит энкодеры типа JSONPEncoder. Сам энкодер, казалось бы, тривиален – все, что он должен сделать так это обернуть вызов в название callback’а и вернуть его. Но поскольку его метод WriteMessage() перегружен, его приходится вызывать в нескольких местах.

Для того чтобы получить всю поддержку JSONP полностью, нужно скачать набор примеров по WCF c MSDN.

Web.config

Несмотря на то, что все, в принципе можно сделать в коде, на практике приходится достаточно сильно шаманить с Web.config ом дабы все заработало. В частности, нужно прописать новый binding:

<bindings>
  <customBinding>
    <binding name="jsonpBinding">
      <jsonpMessageEncoding/>
      <httpTransport manualAddressing="true"/>
    </binding>
  </customBinding>
</bindings>

А также добавить расширение для кодировки JSONP:

<extensions>
  <bindingElementExtensions>
    <add name="jsonpMessageEncoding"
    type="ConversationServer.JsonpSupport.JsonpBindingExtension, ConversationServer"/>
  </bindingElementExtensions>
</extensions>

Удаление .svc

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

public class RestModule : IHttpModule
{
  public void Init(HttpApplication context)
  {
    context.BeginRequest += (sender, args) =>
    {
      var ctx = HttpContext.Current;
      var path = ctx.Request.AppRelativeCurrentExecutionFilePath;
      int i = path.IndexOf('/', 2);
      if (i > 0)
      {
        var svc = path.Substring(0, i) + ".svc";
        var rest = path.Substring(i, path.Length - i);
        var qs = ctx.Request.QueryString.ToString();
        ctx.RewritePath(svc, rest, qs, false);
      }
    };
  }
  public void Dispose()
  {
  }
}

А далее просто прописываем его в секцию system.web в Web.config:

<system.web>
  <compilation debug="true" targetFramework="4.0" />
  <customErrors mode="Off"/>
  <httpModules>
    <add name="NoMoreSVC" type="ConversationServer.RestModule, ConversationServer"/>
  </httpModules>
</system.web>

Вот собственно и все.

Заключение

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

Давайте попробуем реализовать базовые конструкты HTML Zen. Для этого мы воспользуемся языком F#, библиотекой тестирования FSunit. Будем писать программу в стиле TDD. Я пожалуй назову ее FSharpZen, так интересней.

Исходный код можно найти тут: https://bitbucket.org/nesteruk/fsharpzen

Базовые случаи

Весь HTML Zen – это набор трансформаций. Например, на входе a, а на выходе <a href="|"></a>, где | обозначает финальное положение каретки. Следовательно, можно как минимум написать следующий тест:

[<TestFixture>]
type ``Basic transformation tests`` ()=
  [<Test>] member test.
    ``Empty input should yield empty output`` () =
      Zen.html "" |> should equal "|"

Это счастье совсем не компилируется, поэтому нам придется как минимум предоставить хоть какую-то реализацию, например:

module FSharpZen.Zen
let html input = ""

В результате, конечно, получим “красный” тест:

Expected string length 1 but was 0. Strings differ at index 0.
Expected: "|"
But was:  <string.Empty>
-----------^

Ну а дальше мы “жульничаем” и наш тест проходит. Не забываем сказать спасибо Решарперу, который поддерживает F#-тесты out-of-the-box.

Пустые тэги

Дефолтное поведение HTML Zen такое, что при написании, скажем, буквы z разворачивается шаблон <z>|</z>. С другой стороны, hr определенно превращается в <hr/>|, а img – в <img src="|"></img>.

[<Test>] member test.
  ``Simple entity should be in a closed tag`` () =
    Zen.html "c" |> should equal "<c>|</c>"
[<Test>] member test.
  ``Self-closing entity should yield a self-closing tag`` () =
    Zen.html "br" |> should equal "<br/>|"
[<Test>] member test.
  ``Entity should have appropriate attributes generated and placeholder set accordingly`` () =
    Zen.html "a" |> should equal "<a href=\"|\" title=\"\"></a>"

Теперь у нас есть 3 use-case’а: просто тэги, тэги которые не нуждаются в закрывающем тэге, и тэги которые имеют сложную начинку. Второй и третий случай – специальные, поэтому мы можем попробовать их выделить…

let singularEntities = ["hr"; "br"; "img"]
let neededAttributes = [
                         "a", ["href", "title"];
                         "img", ["src", "alt"]
                       ]

TDD по наивности своей рекоммендует “самое простое работающее решение” которое в нашем случае выглядит примерно вот так:

let html input =
  if input |> String.IsNullOrEmpty then "|"
  else
    let sb = StringBuilder()
    sb.Append ("<" + input) |> ignore
    for a in neededAttributes do
      match a with
      | i, attributes when i = input ->
        let firstAtt = List.head attributes
        sb.Append(" " + firstAtt + "=\"|\"") |> ignore
        attributes |> List.tail 
                   |> List.iter (fun f -> sb.Append(" " + f + "=\"\"") |> ignore)
      | _ -> ()
    // see if this is a self-closing tag
    let isSelfClosing = List.exists (fun f -> f = input) singularEntities
    let pipe = if sb.ToString().Contains("|") then "" else "|"
    sb.Append(if isSelfClosing then "/>" + pipe else ">" + pipe + "</" + input + ">") |> ignore
    sb.ToString()

До элегантности тут как до Китая. Вывода напрашивается два:

• Нужны какие-то структуры для того чтобы отражать структуру тэгов, особенно когда будут вложенные, с аттрибутами, и т.д.
• Нужно учиться лучше парсить строки. То, что мы делаем выше – “не по паттернам”.

FsLex и FsYacc

Лучший способ парсить – это взять что-то уже готовое (хотя до меня это иногда туго доходит). Поэтому для парсинга наших магических строк мы возьмем F# Power Pack, и скачаем через VS Extension Manager шаблон проекта под названием F# Parser Language Starter. Это позволит нам получить пример, в котором есть три важных файла, а именно:

• Ast.fs — определение синтактического дерева. В нашем случае оно достаточно простое.
• Lexer.fsl — определение “лексем”, т.е. различных кусков строки, которые формируют выражение HTML Zen.
• Parser.fsy — собственно парсер, который определяет то, как лексемы становятся чем-то осмысленным.

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

AST

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

• Идентификаторы, такие как div, href и так далее. Они парсятся “как есть”.
• Классы, т.е. при при написании a.b мы получаем <a href="|" class="b"></a>.
• Идентификаторы, т.е. a#b ставовится <a id="b" href="|"></a>.
• Множители, т.е. hr*2 дает нам <hr/><hr/>. Между тэгами, между прочим, фигурирует \n – это вынужденная мера для таких ситуаций как ol>li*2.
• Вложенные тэги – например, ol+li становится <ol><li>|</li></ol>, с соответствующими переносами и отступами.

Теперь попробуем перевисти все эти идеи на структуры F#. У меня получилось примерно следующее:

type ZenExpression =
  | ZenExpression of Expression list
and Expression =
  | Expression of Identifier * Qualifier list
and Identifier =
  | Identifier of string
and Qualifier =
  | ClassQualifier of string
  | IdentityQualifier of string
  | CardinalityQualifier of int

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

Лексер

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

let digit = ['0'-'9']
let letter = ['a'-'z'] | ['A'-'Z']
let letterOrDigit = letter | digit
let whitespace = [' ' '\t' ]
let newline = ('\n' | '\r' '\n')

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

• Строки (возможно с числами) для идентификаторов и квалификаторов.
• Операторы для разделения квалификаторов (., #, + и *)
• Числа для квалификатора размерности

Следовательно, получаем следующее определение:

rule tokenize = parse
| whitespace	   { tokenize lexbuf }
| newline        { tokenize lexbuf }
| letterOrDigit+ { STRING(lexeme lexbuf) }
| digit+         { INT32(Int32.Parse(lexeme lexbuf)) }
// Operators
| "+"            { PLUS }
| "#"            { HASH }
| "*"            { TIMES }
| "."            { DOT }
// EOF
| eof   { EOF }

Парсер

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

start: exprs { ZenExpression($1) }
exprs:
  | exp PLUS exprs EOF { Expression($1) :: $3 }
  | exp EOF { [Expression($1)] }
exp:
  | STRING quals { (Identifier($1), $2) }
  | STRING { (Identifier($1), []) }
quals:
  | qual quals { $1 :: $2 }
  | qual { [$1] }
qual:
  | DOT STRING  { ClassQualifier($2) }
  | HASH STRING { IdentityQualifier($2) }
  | TIMES INT32 { CardinalityQualifier($2) }

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

Принтер

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

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

let rec private getId qualifierList =
  match qualifierList with
  | IdentityQualifier(id) :: t -> Some(id)
  | h :: t -> getId t
  | [] -> None

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

type CodeBuilder() =
  let sb = StringBuilder()
  let mutable indent = 0;
  member this.GetIndent() =
    System.String.Empty.PadRight(indent * 2)
  member this.AppendWithIndent (text:string) = 
    sb.Append(this.GetIndent()).Append(text) |> ignore
  member this.Append (text:string) = 
    sb.Append(text) |> ignore
  member this.NewLine() = sb.AppendLine() |> ignore
  member this.Indent() = indent <- indent + 1
  member this.Unindent() = indent <- indent - 1
  override this.ToString() = sb.ToString()

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

let rec private print expressions (builder:CodeBuilder) =
  match expressions with
  | h :: t ->
    builder.AppendWithIndent "<"
    match h with
    | Expression(name, qual) ->
      builder.Append name
      // id it if has any
      match getId qual with
      | Some(id) -> builder.Append(" id=\"" + id + "\"")
      | _ -> ()
      // needed attributes
      let needed = getNeededAttributes name
      needed |> List.iter(fun n -> builder.Append(" " + n + "=\"|\""))
      // classes
      let classes = getClasses qual
      if classes <> List.empty then
        builder.Append(" class=\"")
        builder.Append(System.String.Join(" ", classes))
        builder.Append("\"")
      // if self-closing, then close it
      let selfClosing = singularEntities |> List.exists(fun f -> f = name)
      if selfClosing then builder.Append "/>|"
      else builder.Append ">"
      // if there's more stuff in there, add it
      if t <> List.empty then
        builder.Indent()
        builder.NewLine()
        print t builder
        builder.NewLine()
        builder.Unindent()
        
      if not selfClosing then
        builder.Append("|</" + name + ">")
  | _ -> 
    builder.Append "|"

А вот собственно как все запускается:

let html input = 
  let lexbuf = LexBuffer<char>.FromString(input)
  let parsed = Parser.start Lexer.tokenize lexbuf
  let builder = new CodeBuilder()
  match parsed with
  | ZenExpression(items) -> print items builder
  let pre = builder.ToString() |> Seq.toList
  let rec clean input metBar =
    match input with
    | '|' :: t when not metBar -> '|' :: clean t true
    | '|' :: t when metBar -> clean t true
    | h :: t -> h :: clean t metBar
    | [] -> []
  let lst = clean pre false
  System.String(lst |> List.toArray)

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

Заключение

В очередной раз у меня сомнения. Количество телодвижений для того чтобы реализовать парсер примерно в 10 раз больше чем когда я все это писал “в лоб” на C#. FxLex и FsYacc обладают практически нулевой диагностичностью, никакого IntelliSense нет, такое впечатление что блуждаешь в потемках. Что касается принтера, опять же, структура на которую все было “замэплено” очень неудобна; намного быстрее было бы использовать ООП. Плюшки FP вроде паттерн-матчинга и прочего тут совсем не амортизировались.

Заметки

1. ↑ Кстати, пример кривой – попробуйте например ввести 2-2 и у вас парсер моментально накроется – а все из-за попытки взять минус перед 2кой как префикс-оператор. :)
2. ↑ Тут я немного отклонился от “кошерного” HTML Zen который, на мой взгляд, достаточно избыточен. В частности, я заменил > на + а “оригинальный” + попросту проигнорировал.

Квадратное уравнение

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

Сразу можно сделать несколько сравнений C# и F# для этого примера:

• Возвращаются 2 значения, а следовательно F# выигрывает за счет того что не надо писать Tuple.Create, а тому кто эти значения получит не надо использовать абсолютно ничего не значащие свойства Item1 и Item2
• Математические binding’и у F# намного «ближе» чем у C#, а следовательно в этом случае (да и в общем), ваш код на F# не будет испачкан явным вызовом статических функций вроде Math.Sqrt. Меня всегда это бесило в C# т.к. сложные вычисления становится еще сложнее читать.
• Ни C# ни F# не умеют работать с оператором ±. Но если в C# нам придется тупо вызывать вычисления дважды, в F# мы можем просто определить функцию конечного вычисления, а потом передать в нее операторы (+) и (-).

В результате получим следующее сравнение:

C#

public Tuple<double,double> SolveQuadraticEquation(double a, double b, double c)
{
  double discRoot = Math.Sqrt(b*b-4.0*a*c);
  double x1 = (-b + discRoot) / (2 * a);
  double x2 = (-b - discRoot) / (2 * a);
  return Tuple.Create(x1, x2);
}

F#

let solveQuadratic a b c =
  let disc = b * b - 4.0 * a *c
  let calc op = (op (-b) (sqrt disc)) / (2.0*a)
  (calc (+), calc(-))

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

C#

public Tuple<double, double> SolveQuadraticEquation(double a, double b, double c)
{
  double q = -0.5 * (b + Math.Sign(b) * Math.Sqrt(b * b - 4 * a * c));
  return Tuple.Create(q / a, c / q);
}

F#

let solveQuadraticEquation a b c =
  let q = -0.5 * (b + (sign b |> float) * sqrt(b * b - 4.0 * a * c))
  (q / a, c / q) //           ^^^^^^^^ WTF?!?

Пример на F# должен вызвать у вас возмущение – с какой это радости результат (sign b) должен быть приведен к типу float?¹ А дело все в непродуманности API, согласно которому sign(x) – это всегда int (могли бы сделать тем же типом что и аргумент), а также крайне жесткой системе типов в которой float + int * float не воспринимается и никак не вычисляется.

Такое странное поведение F# унаследовано из OCaml и требуется для правильного вывода типов. Если вам действительно интересны причины – можно почитать тут. Мне же это лишь палки в колеса. Да, и я знаю что можно было бы написать sign(float b) или что-то в этом роде. Тут как бы без разницы, все равно «не очень».

Комплексные решения

Ну да ладно, а вот вопрос – что будет если дискриминанта (Δ) меньше нуля? С одной стороны, и C# и F# поддерживает комплексные типы данных (см. System.Numerics). Если сделать вид что мы все будем передавать как комплексные числа (так проще?), то получим вот такой вот код:

C#

public Tuple<Complex, Complex> SolveQuadraticEquation3(double a, double b, double c)
{
  double det = b * b - 4 * a * c;
  double absRoot = Math.Sqrt(Math.Abs(det));
  Complex root = det < 0 ? new Complex(0, absRoot) : new Complex(absRoot, 0);
  Complex q = -0.5 * (b + Math.Sign(b) * root);
  return Tuple.Create(q / a, c / q);
}

F#

let solveQuadratic3 a b c =
  let complex v = Complex(v, 0.0)
  let det = b * b - 4.0 * a * c
  let absRoot = sqrt(det |> abs)
  let root = if det < 0.0 then Complex(0.0, absRoot)
                          else Complex(absRoot, 0.0)
  let q = -(complex 0.5) * ((complex b) + (sign b |> float |> complex) * root)
  (q / complex(a), complex(c) / q)

Эээ, ну что я могу сказать? F# определенно превносит массу головной боли. Проблема тут как раз в том, что в C# нам доступны операторы автоконверсии вроде float→Complex, но в F# они попросту не работают! Поэтому вы можете либо определить их как функции (благо у них есть имя op_Implicit), либо же просто вызвать конструктор как делаю я.²

Заключение

То ли я чего-то недопонимаю, то ли F# действительно неудобен для работы с математикой? Ведь если нужно каждый int кастовать во float, а каждый float в Complex, и так далее, то это же сколько лишнего, никому не нужного и мешающего восприятию кода надо написать?

Критика welcome! А то может я что не так написал?

Заметки

1. ↑ Напоминаю, что float в F# – это double в C#. А C#-ный float в F# называется float32.
2. ↑ Тут еще хочется заметить что if который выбирает какой Complex создавать как бы не нужно — можно было вместо этого написать Complex.Sqrt(new Complex(b*b-4*a*c, 0.0)). Проблема только в том что в результате этого вычисления Real-значение будет чуточку отличаться от нуля. Например sqrt(Complex(-4.0, 0.0)) равен (1.22460635382238E-16, 2).