Идеи новых редакторских фич

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

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

• Растеризованные заголовки (пример) – хорошее кстати решение для ресурсов вроде Хабра которым я полностью не доверяю со стилизацией контента. Также прошу заметить что посты со стилизованными заголовками, опубликованные на Хабре, не являются собственностью хабра а лишь даются в аренду пока мне это удобно. Если что, я тупо выдерну все картинки со своего сервера.

• Синтетическая подсветка кода, которая по аналогии с SyntaxHighlighter подсвечивает код через тэги <font>. Не особо современное решение, но сделано оно, опять же, для движков вроде Хабра. В принципе работает, хотя подсветка подсветке рознь. Мне кажется что для стабильного результата легче код растеризовать, хотя это не позволяет делать cut-and-paste.

• Растеризация текста включая различные OpenType фичи а также «синтетическое» применение ClearType. ClearType перестал быть актуален после перехода на DirectWrite (OMG, lightweight COM!!!). Изначально все это дело я писал на WPF, также делал эксперименты на Silverlight, но с переходом на DW у меня получилось даже реализовать свой markup-язык для OpenType-фич. Область применения этого – очень узкая

• Всякие другие микроредакторы, которые применяются редко, но метко.

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

• Поддержка Retina-экранов для всего растеризованного. Обнаружилась эта проблема когда я начал читать блогпосты на new iPad который, как мне кажется, есть у многих технарей. Конечно это подразумевает что блогодвижок поддерживает retina.js или что-то аналогичное, но (имхо) если люди купили устройство с Retina нужно их уважать и делать поддержку таковых устройств по мере возможности.

• К предыдущему поинту, потребуется альтернативное техническое решение для скриншотов. На текущий момент, возможных решения два – во-первых пробовать делать скриншоты на 200% увеличении (прошу заметить что это увеличение не является «штатным» в Windows и как получить его я не знаю). Это правда не всегда возможно т.к. многие программы не поддерживают или плохо поддерживают high DPI. Второй вариант – это просто делать @2x используя nearest neighbor. Это возможно самый безопасный вариант, и я пожалуй скоро его реализую.

• Есть ряд юз-кейсов которые вообще выходят за рамки текстовых редакторов, за исключением возможно редакторов вроде Mathematica. Например, часто хочется сделать что-то подобное:

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

• Очень хочется научиться делать иллюстрации (именно иллюстрации, а не программы) декларативно в стиле Metro Windows 8, с квадратиками и прямоугольниками. Очень часто нужно проиллюстрировать какую-то концепцию, например иерархию наследования классов. Не использовать же мне, в 21-м веке, для этих вещей UML! (UML is dead.)

• И наконец, одна из фишек которые есть (пусть частично) у пользователей Mac-ов – это такие красивые черные overlay-ы на скринкастах. Вы их наверняка видели – они обычно используют Gill Sans и показывают всякие красивые иллюстрации нажатых клавиш, и так далее. Camtasia полноценно такие штуки делать не может, а это значит что их нужно делать отдельно как PNG. Не самая сложная в мире задача, конечно, но для красивых скринкастов грех не сделать.

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

А пока всего!

Методы борьбы со сложностью

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что дальше?

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

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

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

Про книги

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

Короткий опыт использования С++

Хочу поделиться опытом решения задачи, для которой я вместо C# решил использовать C++. История, мне кажется, очень поучительная, т.к. хорошо иллюстрирует все казусы использования этого «древнего» языка.

Сценарий

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оптимизации

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

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

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

Заключение

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

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

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

Небольшой обзор Visual Studio 11 (2012) Beta

Должен признаться, что я пишу на 11й студии (она же VS2012) уже достаточно давно, и делаю эту в силу того, что новая студия имеет неплохую обратную совместимость с 2010й: если открыть обычное решение, то 11я студия оставит .NET проекты в покое, а С++ проекты предложить переконвертировать. От этой конверсии можно отказаться, и все равно все будет работать и компилироваться. Единственное, возможно придется менять использование констант вроде MSC_VER или как там, для того чтобы библиотеки компилировались. Но все будет работать.

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

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

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

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

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

Black & White

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

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

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

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

Solution Explorer

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

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

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

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

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

Add References

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

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

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

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

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

IntelliSense

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

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

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

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

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

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

Заключение

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

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

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

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

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

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

Снова про оптимизацию математических выражений

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

Итоги 2011 года

Сейчас блоггеры усиленно подводят итоги уходящего года, и я тут подумал – а чем я хуже? Мне тоже есть что рассказать! Рассказывать я буду конечно про технические вещи, с которыми успел “поиграться” в 2011 году. Поехали…

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

• 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.: С Новым Годом!!!