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

• 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).

Концепция

Меня во всей этой концепции интересуют именно сайтлеты. В отличии от использования Asp.Net-конструктов (пусть и на F#), сайтлеты – наиболее “трушная” концепция, в которой сгенерированный код будет полностью отвязан от Asp.Net и, впоследствии, от IIS.

Теперь о том как это делается. На самом деле, основной концепцией является конверсия F# в JavaScript/CSS/HTML на этапе компиляции. Делается это за счет аттрибута под названием ReflectedDefinitionAttribute который, имея alias под названием JavaScriptAttribute, используется перед методами, которые нужно сконвертировать в JavaScript.

Что этот аттрибут делает? Он заставляет компилятор F# сохранить логические конструкты метода вместо того чтобы просто его компилировать. А тут включается постпроцессинг WebSharper’а, который берет это “отраженное определение” и, на его основе, формирует некий промежуточный слой JavaScript. Промежуточный слой нужен потому, что мэпить F# на JavaScript не так-то просто.

Простой код который вы напишете вот так

[<JavaScript>]
let rec Fact n =
  match n with
  | n when n < 2 -> 1
  | n -> n * Fact1 (n - 1)

может быть в последствии вызван со страницы напрямую – ведь все остальное, что есть на странице тоже определено через F#, конвертированный в JS и HTML.

Вызовы серверных методов

Мне очень понравилось что механизм вызова методов очень прозрачный. Метод помеченный как [<JavaScript>] вызывается как JS прямо у клиента, в то время как метод помеченный как [<Rpc>] хостится на сервере (как это будет сделано в полноценных сайтлетах – непонятно), и соответственно его вызов со страницы дергает сервер.

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

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

ВебШарпер не отказывается от идеи шаблонов! По крайней мере сайтлеты на текущем этапе предоставляют возможность писать шаблоны в HTML, который потом компилируется… в F#! Что намного более извращенно чем то, что делает Asp.Net MVC, например. Но мы сейчас не об этом.

Дело в том, что сам по себе WebSharper предоставляет возможность формировать HTML путем использования HTML-подобных конструктов в F#. Механизм, с помощью которого организовано создание HTML весьма забавно. В модуле IntelliFactory.Html.Tags есть определения для большого количества тэгов, например H1. Каждый тэг – это функция, которая сама по себе берет список, состоящий из нескольких “нодов”, которые могут формировать как аттрибуты данного тэга, так и его начинку. Например, чтобы сделать заголовок с текстом, мы пишем следующее:

H1 [Text "Title"]

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

Теперь насчет композиции. Композиция – это центральная особенность ВебШарпера, которая очень хорошо выделяет его по сравнению с тем же Asp.Net MVC. В данном случае, для вкладывания HTML-элементов друг в друга, мы можем использовать оператор -<. Например:

Div [Attr.Style "padding: 5px;"] -< [
  P [Text "Hello"]
]

События

Обработка событий в F# делается путем еще одного полезного оператора |>!. Этот оператор делает подписку на событие, и одновременно возвращает созданный элемент, что обязательно в условиях механики работы WebSharper. Вот небольшой пример:

let update () =
  // обработка события
 
let input = Input [Attr.Type "Text"]
Form [
  label "First Name: "
  input |>! OnKeyUp (fun _ _ -> update ())
]

Опять же, интересно тут то, что не важно, где располагается метод update() – на сервере или на клиенте.

Это вам не MVC!

Сейчас устраивать гонения на MVC модно, многие уходят на Rails (в т.ч. всем известный Рой Ошеров), поэтому я решил тоже подлить масла в огонь хотя, по-хорошему, ВебШарпер является частью Asp.Net инфраструктуры. Но это пока сайтлеты полностью не дописаны. Так вот, понятное дело, что в функциональной парадигме, создание сайтов выглядит несколько по-другому.

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

[<JavaScript>]
let BasicInfoForm () : Formlet<BasicInfo> =
  Formlet.Yield (fun name age -> { Name = name; Age = age })
  <*> Input "Name" "Please enter your name"
  <*> InputInt "Age" "Please enter a valid age"

Формлеты можно “обрамлять” (типичный паттерн Декоратор) в различные другие конструкты, функционально добавляя им кнопки Submit/Reset, настройки, и так далее. Формлеты можно инстанциировать у себя в коде, причем с ними можно делать вещи, которые в том же MVC делать очень сложно. Например, допустим у вас сайт где можно разместить резюме, и вы хотите чтобы человек мог внести данные о всех местах где он работал. Для этого, вы делаете формлет, который инкапсулирует все данные о работе (где, когда, итп.) а потом одной строчкой кода говорите “их может быть несколько”. И все! Композиционная структура сделает все сама за себя.

Так вот, о чем мы? После того как мы сделали несколько формлетов, их можно выстроить в цепочку, так что нажав Submit на одном, мы перейдем к другому. Эта “концепция” именуется flowlet’ом (или flowlet’ами). Выражается это следующим образом.

Во-первых, есть некий workflow под названием Flowlet.Do этот вокрфлоу умеет показывать формы в тот момент, когда они учавствуют по правую сторону let!, и сохранять их возвращенные значения (да-да, форма это функция, а ее return value – это то, что пользователь ввел). После этого, путем return! происходит “типа возврат” из этой цепочки, то есть мы можем, например, предоставить фунцию, которая получит результаты formlet’ов и выведет из них полезные значения на экран.

На самом деле, механика всего этого чуть-чуть сложнее. Во-первых, конечным результатом выражения Formlet.Do все равно должен быть Formlet, то есть создав элемент, вам придется его конвертировать. Но это не сложно! А во-вторых, весь этот computational expression должен быть передан в функцию Formlet.Flowlet для того чтобы оркестровать такое феерическое действие.

Formlet.Do {
  let! w = welcomeForm
  let! c = consentForm
  return! Formlet.OfElement (proc w c)
}
|> Formlet.Flowlet

Представление

На данный момент презентация сего фееричного действия организована в терминах Asp.Net’ного WebControl, от которого наследует ВебШарперный контрол, давая нам возможность засунуть в него целиком наш pagelet. Pagelet – это еще одна абстракция в стиле “нечто что может фигурировать на странице”. Логика мне не ясна, но на данный момент pagelet’ом являются текст, Element (это просто элемено HTML) или Flowlet.

Понятное дело, что формирование отдельного WebControl-а не означает создание странички целиком. И вот тут начинаются странности.

Дело в том, что для сайтлетов у нас генерируются 3 проекта, а именно:

• Проект Asp.Net, который содержит некоторые ресурсы (например CSS), но в будущем скорее всего не будет нужен вообще. По крайней мере, сейчас для сайтлетов он служит заглушкой со ссылкой на “настоящий сайт”.
• Проект сожержащий сайтлет.
• Проект с шаблонами.

Проект с шаблонами – это возможность делать, фактически, master-странички со вставками, определеными в F#. Вы уже догадались почему нужно конвертировать HTML в F#? Поясню: в основном проекте, у нас появляется возможность строготипизированно определить, что мы помещаем в различные секции шаблона. Обычно туда помещяется либо наш F#-созданный HTML, либо… наш WebControl, конечно же!

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

Размышления

Для меня, идеальным кажется сайт, который существует целиком на клиенте, а с сервером общается только через REST или более продвинутую парадигму a la NetKernel. Поэтому в случае с ВебШарпером (надеюсь мне авторы простят русификацию названия), то чего хочу видеть я – это полную отвязку от Asp.Net и IIS. Я точно не знаю когда это будет, но коллеги подсказывают мне, что релиз WebSharper 2.0 будет отвязан от Asp.Net, в то время как полноценная поддержка сайтлетов с отвязкой от IIS будет в последующем релизе. Главное, что для перехода на Linux (а это основная цель) не надо будет ничего переписывать. По крайней мере я на это надеюсь.

Теперь что касается юзабельности сего фреймворка. Понятное дело что вкуривать сложную DSL и писать на F# – занятие не для слабонервных, но лично меня технические трудности не очень беспокоят. Композициональность, если так можно выразиться, фреймворка впечатляет, ровно как и его возможность быстро оборачивать такие JS библиотеки как JQueryUI, YUI или даже RxJS! Это означает что в F# можно получить унифицированную, строготипизированную модель, которая будет сама подсказывать как использовать тот или иной фреймворк и упрощать работу с ним.

Анонсы

Коротко о главном. Во-первых, Петербургская Группа Alt.Net планирует провести 3х-часовую встречу посвещенную F#. Максим Моисеев и я будем рассказывать про все, начиная с основных понятий и заканчивая спекуляциями на тему type provider’ов. Встреча пройдет 3го Февраля в офисах Exigen, и в ближайшее время мы вывесим анонс на сайтах Ineta и Spbalt.net.

Во-вторых, на выходных периодически происходят неформальные встречи участников сообщества. Встречи происходят в моем офисе (территориально 3 мин. от м. Автово), так что если вы живете в Питере и у вас есть желание убить выходной копаясь в F# (или еще какой-нть интересной фигне) с единомышленниками, напишите мне и мы обсудим. Писать лучше по скайпу — dmitri.nesteruk.

На этом все. Comments welcome!

F#

Писать на F# демо-программки и делать на нем что-то существенное – это совершенно разные вещи. Когда начинаешь массово плодить код на F#, начинаешь понимать всю упадочность своего понимания мира. Например, я достаточно долго писал member this.Something with get() = ... вместо аналогичного варианта member this.Something = .... Ну и тяга к скобочкам и излишним аннотациям типов (даже там где и ежу понятно что это за тип будет) – это тоже наследие использования C# где все прописывается.

F# поражает скудностью поддержки в студии. На одной из моих машин вылетела поддержка IntelliSense (полностью!), на другой – F# проекты по F5 только компилируются но не запускается отладчик. Очевидно что-то тут не так. Я конечно предпринимаю усилия для того чтобы работать с F# было более гуманно, но пока что нужно делать основные вещи, такие как лексер и парсер. Адаптировать их из сорцов F#-а — дело не для слабонервных.

WebSharper

Я упомянул этот фреймворк в моем первом сольном подкасте, сказав что он позволяет делать сайты, полностью оторваные от Asp.Net и IIS. Не знаю, один ли я страдаю такой неприязнью к IIS, но на данный момент для меня нет антидота: тот релиз Вебшарпера который состоялся недавно еще не поддерживает вторую версию Sitelet’ов, в которой как раз и должна быть поддержка создания полностью независимых сайтов. Что-то мне подсказывает, правда, что Адам Границ и компания планируют вообще сделать чуть ли не свой веб-сервер.

Так или иначе, я продолжаю эксперименты с Web#, а как только появятся новые сайтлеты, я начну тестировать все это дело уже на Linux. Интересно, что хоть технология и F#, нельзя сказать что она как-то связана с .Net или Microsoft.

NetKernel

Во-первых, NK – это Java-стек, но меня это не пугает т.к. ничего страшного там нет. NK – это реализация ресурсно-ориентированной парадигмы, которая сейчас будоражит умы всех кто занимается коммуникационными технологиями, например та же комманда WCF. По сути дела, RoC в представлении NK – это REST’ообразная концепция, которая предоставляет как бы аусторсинг веб-архитектуры, позволяя разработчикам писать компоненты, которые работают через ресурсы, запросы на ресурсы, конверсию различных типов ресурсов, и так далее.

NK это, если хотите, эволюция REST, и является интересной технологией (более живой чем существующие .Net аналоги) которая понравится тем, кто доселе работал с такими вещами как WCF REST.

Семантический Веб

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

Во-первых, это DotNetRdf – собственно библиотека, которая позволяет работать с RDF и поддерживает различные форматы хранилищ. Кстати, недавно нашел в блоге попытку создания semantic triple store на MongoDB.

Еще один аспект моих исследований связан уже с конкретикой, а именно с онтологией Good Relations и ее нынешней поддержкой гуглом (их Rich Snippets). Изначально у меня была идея попробовать подобавляеть поддержку всего этого в R2P чтобы с этим было легче работать, но потом я узнал что модели Xml и Html в моем любимом Решарпере не имеют общего корня, что означает что, по сути дела, все пришлось бы делать дважды. Возможно когда-нибудь у меня дойдут до этого руки.

Так вот, в попытках найти возможность создать .Net объектную модель из OWL-файла, описывающего GR, я набрел на проект ROWLEX, в котором поставляется утилита именно для этого. Интересно, а можно ли как-то автоматически брать данные со страниц, записывать их в эту модель и потом заталкивать все в MongoDB без каких-либо лишних действий? Подозреваю что все несколько сложнее…

MindTouch

Я занимался исследованием MindTouch в двух направлениях – в попытке понять, можно ли использовать эту штуку для документирования API большого программного продукта, а также мне хотелось понять, можно ли использовать его вместо SharePoint для внутренних целей.

По первому вопросу у меня нет ответа. Бесплатная версия MT шикарна, и покрывает 99% того что мне лично нужно. Поэтому в личных целях я начал ее использовать. Что же касается построения на нем портала разработчиков, то тут все неоднозначно. Я не decision maker в данном вопросе, но лично меня никто не убедил отдавать за коммерческий вариант этой штуки большие деньги.

Я рекоммендую всем скачать MindTouch Core (бесплатную версию) и поиграть с ней. Это действительно стоит того! Это по сути дела Wiki/CMS которая хорошо подходит для документации. Чудес в этом мире не бывает, но штука красивая, и я ей доволен.

TidePowerd GPU.NET

Поскольку несколько лет назад я плотно занимался GPGPU и даже сам эксплуатировал pixel shader’ы через Direct3D, наличие .Net библиотеки мне импонирует – давно пора. Тем более что трансляция IL во что-то еще – процесс весьма понятный и реализуемый без особых проблем. Библиотека GPU.Net – это как раз оно и есть. Еще одна абстракция чтобы облегчить нам жизнь.

Признаюсь что я только лишь посмотрел вебинар – я не игрался еще с самой библиотекой т.к. не было времени. Все впереди :)Update: уже успел созвониться с директором Tidepowerd – разговор шел в основном в ключе поддержки конкретно F# в GPU.NET. Заинтересованность определенно есть, так что рано или поздно замутим совместный конференс с Саймом, Границем, и партнерами. Как что состоится – обязательно напишу.

Fusion IO

Fusion IO – компания, которая за 3 года получила 300 миллионов долларов инвестиций. Их “фишка” – высокоскоростные хранилища данных, и когда я говорю “хранилище”, подразумевается PCI-карта с SSD-устройствами на ней. Конечно, Fusion IO говорит что их устройства – это не SSD, но на самом деле их отличие в качественном ПО (в плане прошивки их ASIC), а есть ли у них что-то кардинально новое – не знаю. Надо получить образец (надеюсь дадут) и самому посмотреть.

Хотя если по мне, так более интересной фишкой является NVidia Tegra – нам уже 10 лет назад нужно было иметь нормальные SoC-решения. Те же Fusion IO могли бы засунуть на свои карты контроллер и несколько FPGA которые я бы мог “флэшить” и им цены бы не было! Вот интересно – Intel уже начал нервничать или еще нет? Ведь по мне так самое главное это избавиться от ситуации когда я не могу иметь масштабно-инвариантную систему, а должен на каждый процессор закупать еще и материнскую плату, память, жесткий диск, и так далее. Надеюсь скоро эти телодвижения станут пережитками прошлого.

Кстати о Tegra… двухъядерные процессоры в мобильных телефонах это круто или как?

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

Предыстория

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

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

В CodeRush используются только стандартные конструкции. Например, шорткаты для создания класса, метода, свойства. Написав c, создается класс. Написав ms, создается метод, который возвращает строку. А написав, например, pl.s, создается свойство типа List<string>.

Все подобные конструкты мы создаем каждый день в нашей работе. Это вещи, которые могут сэкономить массу времени людям которые, например, имея отличные знания C# не очень ориентируются в том как создавать типы на F#. И тут меня осенило. Ведь я, фактически, могу сам создать свой стандартный словарь сокращений для различных .Net-конструктов, выбрав те механизмы и типы, который лично я считаю наиболее удобными. Более того, я могу воспользоваться всей мощью мною любимого Решарпера, дабы иметь доступ к дополнительной, нужной мне информации – например к названию типа, в котором я сейчас нахожусь.

И понеслось…

Стандартный Словарь

Первым делом, мне пришлось выбрать те основные конструкты, которые будут доступны пользователю. Я выбрал следующие:

• class

• static class

• interface

• struct

• enum

• abstract class

• Тестовый класс (с аттрибутом TestFixture и дефолтным методом с аттрибутом Test)

Что касается начинки класса, то мне понравились следующие элементы:

• Private field

• Private static field

• Private readonly field

• Public method

• Test method (то же самое что и public method, но помечен как [Test])

• Auto-property (другие типы свойств делать не захотелось т.к. это уже реализовано в Решарпере через рефакторинги)

• Dependency property (то же самое что propdp в студии, только не надо писать лишний раз имя содержащего класса)

Теперь что касается типов. На вкус и цвет, как говориться, товарищей нет, поэтому в плане примитивных ValueType все может и понятно, а вот из reference types пришлось выбирать. В результате получилось вот это:

• Примитивные типы: bool, char, float, byte, double, int, string, long, uint, Guid, DateTime

• Более сложные типы: Exception, StringBuilder, List<T>, HashSet<T> (на самом деле не уверен что конкретно этот тип много кто использует), Dictionary<T,U>

Вполне очевидно, что пользователи могут предпочесть другие типы, но я не могу поддержать их все. Один тип, который я решил поддержать отдельно – это IEnumerable<T>. Помните я публиковал небольшой пост о возможных фичах C#5? Так вот, оттуда я вычерпнул идею превратить ~ (тильду) в аналог IEnumerable. На практике, это значит что написав m~s вы получите метод, который возвращает IEnumerable<string>.

Реализация

Первое, что я сделал – это взял типичный шаблон Решарпера и пропустил через XSD.EXE, получив объектное представление. После этого, сделал для каждой концепции массив, и поместил все во вложенные циклы: типы объектов (класс, метод, и т.д.), типы значения, различные вариации вроде массивов или Nullable.

Отдельный код с циклом создал и для дженериков, чтобы был вариант как задать тип руками List<MyType>, так и сделать “шаблоный” тип – например vl.s делает List<string>.

Остальное все дело техники. Создать XML-файл из готовых кусочков совсем несложно, на самом деле. Правда результат получился немаленький – аж 1Мб (на текущий момент) шаблонов, в количестве где-то 1200 штук. И это, понятное дело, еще не все – ведь будут новые идеи, захочется добавлять полезные фичи. Но это как пойдет.

Дайте Мне Скорее!

Скачать все темплейты можно тут. Чтобы их установить, сначала идем в меню ReSharper→Live Templates, потом в открывшемся окне нажимаем кнопочку Import, выбираем XML-файл. И ждем. Долго. Очень долго. Ведь шаблонов “за тыщу”. Ну а потом собственно пользуемся.

Вообщем, шаблон я выложил, но это work in progress, так что если что — пишите комментарии! Спасибо!

P.S. С Новым 2011м Годом! Я на самом деле не склонен подводить итоги, поэтому скажу кратко – я даже не 2010й год отдельно рассматриваю, а полосу 2008-2010, в которой, увы, было очень мало радостей – а точнее, почти не было. И хоть и хочется сказать что “кризис ушел”, на самом деле это, конечно же не так. Но не знаю как вам, а лично мне остается одно: работать, работать, работать.

Суть задачи

Я пишу плагин для Решарпера. Чтобы заниматься отладкой этого плагина, мне нужно запускать дополнительный инстанс Visual Studio, который занимает нехилое кол-во времени при стартапе. И понятное дело что при каждом изменении с моей стороны нужно запускать этот процесс снова, благо Edit & Continue – это миф, и там реально ничего не работает.

Мне это не нравится. Я хочу чтобы было лучше.

В частности, я хочу редактировать плагин прямо при исполнении и чтобы “все работало”. Сразу. Без задержек. И тут-то возникают проблемы.

Как это решается сейчас

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

// вот мой класс
class MyItem : BulbItemImpl
{
  ...
}
 
// и вот как я его создаю
var i = new MyItem(...);

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

Вклиниваем контейнер

Следовательно, я делаю небольшой трик: без особого детерминизма я втыкаю Unity как статический класс с соответствующим набором extension методов:

public static class ContainerExtensions
{
  static UnityContainer container;
  
  static ContainerExtensions()
  {
    container = new UnityContainer();
  }
  
  static TBase Get<TBase,TImpl>(this object o, params object [] args)
  {
    return container.Resolve<TBase>(typeof(TImpl).Name, new InjectionConstructor(args));
  }
  
  static void Set<TBase>(this object o, Type implType)
  {
    container.RegisterType(typeof(TBase), implType, typeof(TImpl).Name);
  }
}

Вот такое вот шаманство. Ничего странного не находите? Как насчет typeof(TImpl).Name? Давайте поясню что тут происходит. У нас много классов наследуют от BulbItemImpl, следовательно нам как бы некошерно просто делать container.RegisterType<BulbItemImpl,MyItem> потому что эта регистрация будет 100 раз перекрыта. Поэтому мы делаем именную регистрацию по имени типа конечного результата. Это будет полезно дальше.

Делаем Impl-прослойку

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

public sealed class RequireOrEnsureBulbItem : BulbItemImpl
{
    // Fields
    private readonly string block;
    private readonly IMethodDeclaration method;
    private readonly ICSharpContextActionDataProvider provider;
    private readonly string text;
    // Methods
    public RequireOrEnsureBulbItem(ICSharpContextActionDataProvider provider, IMethodDeclaration method, string text, string block);
    protected override Action<ITextControl> ExecuteTransaction(ISolution solution, IProgressIndicator progress);
    // Properties
    public override string Text { get; }
}

Соответственно, мы берем и переименовываем этот класс, добавляя префикс Impl.

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

private BulbItemImpl impl;

который инициализируется в конструкторе:

public RequireOrEnsureBulbItem(ICSharpContextActionDataProvider provider,
  IMethodDeclaration method, string text, string block)
{
  impl = this.Get<BulbItemImpl,RequireOrEnsureBulbItemImpl>(
    provider, method, text, block);
}

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

public override string Text { get { return impl.Text; } }

Что дальше?

Мы только что разделили один класс на интерфейс, который загружается единожды, и реализацию, которую можно, в принципе, менять в контейнере. Но как? На самом деле – очень просто. Для начала давайте решим как мы будем знать что можно редактировать а что нет. Лучший способ – пометить это типы (это сгенерированные Impl-типы) каким-нибудь аттрибутом вроде [Editable]. Тогда мы будем всегда знать что можно генерировать а что нет.

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

this.Set<BulbItemImpl>(GeneratedType);

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

Заключение

То что я описал выше – это и есть “горячая подмена” функционала. С помощью нее я могу редактировать плагин прямо в момент исполнения, проверять API, тестировать новые идеи и при этом не напрягаться с перезапуском отладчика. Понятное дело что отладка динамически сгенерированных сборок у меня не работает (не напрягаюсь я на тему PDB), но это не так критично как получить ответ на простой вопрос “работает оно или нет?”.

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

Нехватка данных

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

Одна вполне вменяемая альтернатива – это когда автор сайта сам “подсказывает” системе какие данные как воспринимать. Например, Google любит данные в форматах Google Rich Snippets. Наличие данных в этих форматах позволяет Гуглу, например, показывать на поисковой странице рейтинг товара или его цену.

А зачем?

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

И тут возникает проблема: магазины эти не публикуют свои прайс-листы в каком-то универсальном формате. Порой, цены вообще вывешены в табличках, а скачивать все это дело через WebRequest, парсить и интегрировать в BizTalk мне лень – нет, я могу это сделать, и это кстати является моей “продуктовой специализацией”, если так можно выразиться, но это болезненно.

Поэтому, я предпочитаю данные которые реализуют известную онтологию (т.е. схему описания данных), такую например как Good Relations. Эта онтология позволяет продавцам публиковать универсальный набор данных по своим продуктам. Данные, которые потом распарсит Google а я, как пользователь, смогу получить из них выписку.

Что интересней, так это то, что при таком раскладе дел, мне Google вообще-то не нужен – мне нужен свой “паук” или агент который сам будет шастать по интернету в поисках магазинов с нужной продукцией.

Механизмы

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

<div xmlns:dc="http://purl.org/dc/elements/1.1/">
   <h2 property="dc:title">The trouble with Bob</h2>
   <h3 property="dc:creator">Alice</h3>
   ...
</div>

Для тех, кому RDFa в новость, у W3C есть неплохой вводный документ, описывающий технологию более детально. Хотя сама по себе идея, конечно же, примитивна.

На этом этапе вам уже должно быть понятно, что нам просто нужен удобный инструмент, который позволит людям вносить в существующие структуры данных семантическую информацию (semantic annotation). Один из инструментов, который позволит делать это на клиентской стороне – это редактор Aloha. Проект сам по себе интересный, но возможность семантических аннотаций – это очень полезно для встраивания в CMS которую можно например поставлять бизнесу для самостоятельного введения данных по продуктам.

Счастье на сервере

Что касается клиенской части все понятно – нам нужно аннотировать XHTML. А что насчет серверной? Тут опять же есть варианты, один из которых предоставят (я надеюсь) авторы WebSharper. Для тех кто не знает, поясню что WebSharper – это аналог GWT на F#. Иначе говоря, идея в том что F# транслируется в HTML+JavaScript+CSS+сторонние библиотеки вроде JQuery. Сейчас WebSharper еще не достиг коммерческого состояния, но у него уже есть две плюшки, которые хочется получить “чем скорее тем лучше”. Во-первых, это возможность полной отвязки от серверной части, т.е. перевод сайта в чистый JS-driven клиент который может работать на Mono и тем самым освободить нас от обслуживания IIS. Вторая интересная фича – это возможность создания “плагинов”, т.е. встраивания кастомных компонент которые изменяют процесс трансформации F# в JavaScript.

Почему это актуально? Элементарно, Ватсон — нам нужен этот механизм чтобы мы могли создавать решения, которые позволяли бы делать семантические аннотации путем описания всего этого счастья в F#, с дальнейшей эмиссией “кошерного” HTML. Ведь это всяко лучше чем копаться прямо в HTML, не так ли?

Заключение

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

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

Ждите скорых обновлений!