Как добавить клиентам радости

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

Что включает в себя комплект поставки бюджетного телефона? Сам телефон, простенькая гарнитура и зарядник, несколько бумажек. Всё. У более дорогих обычно всё тоже самое, может лишь отличие в том, что качество гарнитуры и зарядника чуть выше (да и то не всегда).

Что сделала Digma:

• Положила в комплект симпатичный рыжий бампер, т.е. телефон сразу начинает привлекать внимание, за счёт яркого позитивного цвета, и приносит радость владельцу
• симпатичный USB-зарядник с подсветкой порта. Мелочь, но приятно искать в темноте под столом разъём
• Тряпочка для протирки 
• Защитная плёнка на экран
• При этом транспортировочная плёнка — прозрачная, без надписей. Т.е. можно для начала тестировать телефон не снимая её, не пытаясь прочесть информацию за огромными ненужными буквами

Т.е. компания потратила чуть больше денег, но впечатление от неё у покупателя осталось весьма позитивным, что с учётом толпы псевдопроизводителей телефонов на российском рынке (Keneksi, Highscreen, Texet, Explay, Fly), возможно что-то стоит. 

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

Впечатления от Windows 8.1

До выхода Windows 8.1 всё меньше и меньше времени, и до того момента, как на людей польётся тонна информации об "уникальных" и "удобнейших" нововведениях, хочу поделиться тем, что я увидел в этой системе нового, приятного и удобного:

НИЧЕГО!

Да, именно так. Абсолютно ничего не изменилось. Да, сломался firewall от Comodo и упорно отказывался ставиться. Заменил на другой. Да, тема из 8 Preview сломалась, починил, отвалившуюся спячку почил, неприлично долгую загрузку-как нибудь починю, остальные мелочи несущественны.

И в общем-то всё, передо мной та же самая Windows 8. Конечно, можно посмотреть в свойства системы и узнать, но это очевидно, не за этим делаются изменения.

Можете спросить про кнопку Пуск, она ведь появилась. Да, появилась, но подобное убожество я писал самостоятельно в июле прошлого года. Да, у меня менее красиво вышло, но я ведь и не рассказываю всем окружающим с помпой про мегафичу? В общем, вместо стандартного убожества из Win8.1 и ничего из Win8, у меня сейчас стоит StartIsBack, и я чувствую себя человеком.

Также теперь есть изменения в Metro Modern UI поведении. Теперь приложения при установке не попадают на главный экран. Ну что же, прорвёмся, можно открыть все программы, и найти только что скачанную игрушку. Или не находить, всё равно они скучные.

Есть какие-то копеечные изменения в стандартных Modern'овых приложениях, но это вообще-то должен быть обычный процесс разработки, не привязанный к новой версии винды.

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

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

PS: Надо отдать должное, есть 2 действительно новые фичи в Windows Server 2012 R2, но это не клиентская система, кроме того, про них уже прожужжали все уши интересующимся.

Тема из Windows 8 Release Preview в Windows 8.1

Данный пост является продолжением прошлогоднего: Смена темы в Windows 8 на тему из Release Preview. Как результат, контекст обсуждения и общие моменты по установке смотрите в прошлом посте.

Итак, совсем скоро Microsoft выпустит Windows 8.1, в которой будет 100500 улучшений, всё будет быстрее, лучше и красивее (по секрету скажу, что ничего стоящего не замечено).

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

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

После некоторого времени, потраченного на иследования я выяснил, что тут сложились два фактора:

• Изменился рендеринг текста, стал ещё более простым (те. убрано свечение текста там, где оно не включено специально)
• Тема от Windows 8 RP имеет в качестве цвета заголовка практически (но не полностью!) прозрачную рамку.

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

Собственно, проблема есть, пишу решения:

Решение №1 использовать программу  Aero Glass for Windows 8, которая сама добавит свечение вокруг букв и решит проблему. Единственная проблема: заставить программу работать по-человечески, та ещё задача. 

Решение №2 поправить тему, заменив почти прозрачность на полную прозрачность, а так как мы сломаем оригинальную тему, то сломать дополнительно проверку подписи для тем.

Вторая проблема решается давно и неплохо (ибо люди любят кастомные темы).

Самый простой способ сломать проверку через UxStyle. Это небольшой сервис, котороый не меняет системные файлы, а проводит изменения в памяти. Как результат, можно подклаывать любую тему с deviantART. Единственная проблема, пока нельзя скачать программу для 8.1, ибо она была выпущена, но из-за какого-то критичного бага убрана. Так что ждём фикса бага и обновления.

Ну а саму тему из Win 8 RP, я уже поправил, и выкладываю здесь, чтобы можно было забрать и пользоваться:

64 бита

А подробности по установке в прошлом посте.

Маленький хинт для программистов

Иногда бывают ситуации, когда вам нужно что-то удалённо сделать с вашим домашним компьютером. Часто что-то стандартное, а под рукой только телефон.

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

1. Поднять web-сайт на своём компьютере (IIS или node.js — не важно, что больше нравится)
2. Выставить его в интернет (Dynamic DNS в помощь)
3. Ограничить к нему доступ авторизацией или сертификатами
4. Для стандартных задач сделать url'ы, выполняющие определённые команды (лучше внешние батники, чтобы их лего можно было менять)
5. Если нужно что-то сложное, то можно уже сделать интерфейс для выбора или ввода команды вручную
6. Открыть с телефона в браузере полученную ссылку

В общем-то и всё. Ключевое, конечно, в данном случае - ограничить доступ, иначе вы открываете огромную дыру себе в компьютер, остальное дело 10 минут. Код, выполяющий определённую команду на ASP.NET выглядит просто и банально:

var runCmd = ConfigurationManager.AppSettings["runCmd"];

var processStartInfo = new ProcessStartInfo

{

FileName = runCmd,

RedirectStandardOutput = true,

RedirectStandardError = true,

UseShellExecute = false

};

var process = Process.Start(processStartInfo);

var output = process.StandardOutput.ReadToEnd();

var error = process.StandardError.ReadToEnd();

process.WaitForExit();

lbOutput.Text = output + error;

При этом я уверен, что есть уже готовые внешние решения и всякие saas'ы, но ведь самому написать интереснее? 

Зачем я написал эту банальность? А дело в том, что практика показывает, что иногда простые и очевидные решения в голову приходят в самый последний момент (даже для программистов), и человек гораздо вероятнее будет гуглить computer management for android, когда у него всего-лишь одна задча: выполнить ping www.ru и поглядеть на получившийся результат. 

Деплой различных по стабильности версий продукта

Сейчас стало довольно модным использовать следующую модель версий продуктов (Google первый начал, остальные подхватили):

• Developer — фактически транк, в котором тестируются новые фичи, стабильность не гарантируется и даже декларируется что её может не быть
• Beta — фичи заморожены, идёт багфиксинг. Стабильность повышается со временем
• Stable — полностью стабильная версия, обновления выходят только в случае обнаружения серьёзных проблем.

Кроме этого, обычно версионирование идёт по +1, т.е. Stable имеет версию n, Beta — n+1, Developer — n+2.

Когда Beta полностью оттестирована, она переходит в Stable и все версии щелкаются на единичку.

В общем, это всё всем понятно и известно. Но хочу поговорить о таком моменте: в любой момент времени свежесть версий должна идти в этом же порядке. Т.е. даже если сейчас идёт подготовка к релизу стабильной версии, в Beta и Developer должно быть по крайней мере тоже самое. Очевидно? Вроде бы да. Но я сейчас вижу перед глазами свежую Оперу, у которой на момент написания поста самая свежая версия это Beta (Next), а Developer, гораздо древнее. Т.е. явное нарушение концепции. Я не знаю точно, почему так происходит, но могу предположить, что у них одна команда, которая сегодня занимается исследованиями, а завтра в поте лица правит баги. Ну и чего они хотели добиться, внедряя технологию, которую сами же и не смогли осилить?

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

Методы и производительность динамического создания конструкторов

В .NET достаточно развитые средства рефлексии, и как результат этим активно пользуются. При этом вариантов и способов использования достаточно много. Эти способы отличаются в зависимости от того что надо: по типу действий (создать объект, вызвать его метод, получить/изменить значение поля), по информации об объекте (мы заранее знаем сигнатуру или не знаем), по типу доступа (публичные/приватные методы), по наличию параметров.

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

Сегодня я рассмотрю достаточно простой способ: вызов конкструктора без параметров и с известными параметрами. Это достаточно часто встречающаяся задача, например, она может использоваться для создания плагинов и модулей. При этом мы знаем, что объект имеет определённый тип (отнаследован от интерфейса, например), так что в дальнейшем мы можем вызывать методы напрямую. Но тем не менее, мы не можем напрямую создать объект, т.к. у нас есть только информация о типе (Type), но изначально мы просто не можем написать new MyObject() — данные придут позднее.

Соответственно есть несколько путей решений:

Activator.CreateInstance

Самый простой и удобный метод создания объекта:

Activator.CreateInstance(myObjectType)

Также можно передать параметры для конструктора. Всё просто и очевидно.

ConstructorInfo.Invoke

"Классический рефлекшен". 

var constructorInfo = myObjectType.GetConstructor(new Type[0]);

constructorInfo.Invoke(new object[0]);

Т.е. мы получаем объект ConstructorInfo и через рефлексию создаём объект. В данном примере нет параметров, но их легко можно передать массивом объектов

Compiled Expression

Ещё один сравнительно новый вариант создания объекта, который заключается в построении Expression'а и дальнейшей компиляции его в делегат (анонимную функцию). Способ создания без параметров выглядит так:

var d = Expression.Lambda<Func<object>>(Expression.New(constructorInfo)).Compile();

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

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

var p1 = Expression.Parameter(typeof(int));

var p2 = Expression.Parameter(typeof(string));

var newExpression = Expression.New(constructorInfo, p1, p2);

var d = Expression.Lambda<Func<int, string, object>>(newExpression, true, p1, p2).Compile();

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

Compiled Expression with Any Parameters

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

var argsExpr = Expression.Parameter(typeof(object[]));
var constructorParams = constructorInfo.GetParameters()
.Select((p, i) => Expression.Convert(Expression.ArrayAccess(argsExpr, Expression.Constant(i)), p.ParameterType));
var newExpr = Expression.New(constructorInfo, constructorParams);
var d = Expression.Lambda<Func<object[], object>>(newExpr, true, argsExpr).Compile();

Т.е. мы передаём массив, в котором находятся аргументы, потом из этого массива достаём параметры для конструктора, конвертируем к нужному типу и вызываем конструктор.

Dynamic Method

Самый сложный метод, который заключается в использовании DynamicMethod и ручной генерации MSIL'а. Поскольку решение в отличие от остальных не совсем тривиальное, детальное описание реализации оставлю для следующей статьи (будет ссылка, когда статья будет написана). Мы его также как и Expression можем сделать специфичным, или обобщённым. У обобщённого основная идея та же, что и в предыдущем методе: мы генерируем делегат, принимающий массив object'ов, внутри приводим аргументы к нужному типу и вызываем конструктор. Только делаем всё это нативно, генерируя MSIL и компилируя его.

Результаты производительности

Мерять тут можно много чего. Но я остановился на следующих условиях:

• Только публичные конкструкторы (приватные значительно дольше, а необходимость в их использовании весьма специфичная)
• Время подготовки нужного объекта не замеряется. Подразумевается, что если уж есть цель оптимизации, то этим временем можно пренебречь. Хотя оно может и вносить ощутимые задержки на первый вызов. Если для вас это будет существенно, наверное стоит провести замеры на ваших условиях и железе.
• Объекты очень простые но не совершенно пустые (сложность этих объектов может сильно повлиять на расстановку сил, нивелировав или максимально усилив различия между методами
• Проверяется Debug и Release режим, чтобы выяснить ускорение, получаемое кодом от оптимизации
• Конкретные цифры я не покажу, ибо это сильно зависит от железа. Только отношение
• Также для сравнения добавлен прямой вызов конструктора 

Вызов конструктора без параметров

По графику можно сделать простой вывод: если скорость не очень критична, используйте Activator, а если объектов нужно создавать очень много, то Expression. И да, Release режим в некоторых случаях рулит. Рефлекшен через ConstructorInfo самый медленный. Если у вас есть желание, можете использовать DynamicMethod, он самый быстрый.

Вызов конструктора с параметрами

Я взял конструктор с двумя параметрами int и string, чтобы было заметно влияние боксинга. Результаты получились следующие:

Те же графики, но без активатора, чтобы был лучше виден масштаб:

В данном случае Activator показал дичайшие тормоза, что очень удивительно, относительно предыдущего варианта. Обобщённый экспрешшен в 2 раза медленнее специализированного (хоть на графике это плохо видно) и в 4-6 раз медленнее прямого вызова (для сравнения скорости). Т.е. вывод тут такой — используйте скомпилированные экспрешшены, по-возможности с явными типами, если нет, то с обобщёнными, потери не очень сильные. При этом обобщённый DynamicMethod быстрее обобщённого Expresssion'а, но медленнее типизированного. Т.е. если хочется максимальной скорости, придётся относительно много писать, чтобы сделать максимально типизированный и производительный DynamicMethod.

Эксепшены в Task'ах

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

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

Одна из фич, это проброс эксепшенов наружу. Примерно так:

var t = new Task(() => { throw new Exception(); });
t.Start();
// do something
try
{
 t.Wait();
}
catch (AggregateException)
{
 Console.WriteLine("Exception occurred");
 throw;
}

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

Но есть маленький нюанс. Эксепшен ведь пробрасывается, когда от таска что-то ждут (результат, или просто завершение). В стандартной терминологии это называется observable. Т.е. таск должен быть наблюдаемым. А что если мы запустили и забыли (или забили)?

new Task(() => { throw new Exception(); }).Start();

Получается, что эксепшен куда-то потеряется? Как бы не так! Доблестные спецы из Microsoft подумали, и придумали бросать исключение в деструкторе. Оцените изящество этого решения: нарушает все вменяемые стандарты кодирования, приводит к падению приложения, и выдаёт ошибки в то время и в том месте, где их отловить невозможно вообще. Супер!

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

Решений данной проблемы в принципе можно придумать несколько (различные врапперы, следить за использованием тасков), одно из достаточно красивых такое:

public static Task IgnoreErrors(this Task t)
{
 t.ContinueWith(x => { var e = x.Exception; }, TaskContinuationOptions.OnlyOnFaulted);
 return t;
}

private static void DoTask()
{
 new Task(() => { throw new Exception(); }).IgnoreErrors().Start();
}

Т.е. мы создаём extension-метод, который прикрепляет к нашей таске продолжение (continuation), в котором мы берём значение свойства Exception (это обязательно надо сделать! именно так таска становится опять наблюдаемой (observable)), и на этом успокаиваем систему.

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

Бонус

Я вначале не зря писал, что в Microsoft вначале сделали, а потом начали думать. А подумав, они поняли, что поведение уж больно идиотское и убивать всё приложение никому не нужно. И в 4.5 изменили логику, так что для 4.5 уже мой пост неактуален.

Но без нюансов у Microsoft не обходится, ибо 4.5 по факту подменяет собой 4.0. Сюрприз! Т.е. установив 4.5, все приложения, написанные под 4.0 начинают по факту работать на 4.5, и слегка по-другому. Например, в данном случае, ошибка уже не появится (попадаются и некоторые другие различия в поведении, но это уж слишком выраженное). Вернуть старое поведение можно конфигом, но кто же заморачивается чтением всяких безумных и бесполезных настроек?

Т.е. вы как разработчик поставили все апдейты, написали приложение, протестировали в хвост и в гриву, а падает оно только у клиента. Ибо у клиента стоит Windows Server 2003, и ваше приложение должно с ним работать, и даже работает, только падает. Иногда. С непонятным стэктрейсом. И вы пытаетесь найти хвосты и поправить всё это безобразие.

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