Техно-логи

Еще один software as website

alik — Sun, 13 May 2012 08:34:17 +0000

В новостях Y Combinator проскочило упоминание очередного варианта реализации фреймворка для создания десктопных приложений на HTML5+CSS+JS. Этот проект называется AppJs.

Система строится на основе Node.js. На момент написания поста, проект имеет версию 0.0.2. Базовое открытие окон сделано только для Linux и немного для Windows. Для Mac пока ничего не работает. Исходники на GitHub.

Никакой большой коммерческой организации за проектом не замечено. Лицения MIT.

Слава ReSharper-у!

alik — Mon, 07 May 2012 11:31:32 +0000

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

Но сегодня я внимательно посмотрел на окно ReSharper -> Options -> External Sources. И, о чудо, там есть галочка «Allow downloading from external locations»! Для библиотеки Nancy, с которой я сейчас вожусь, исходники оказались, что мне сильно помогло. Буду надеяться с остальными опен-сорсными либами ситуация будет аналогичная.

И пожелание к JetBrains напоследок – сделайте, пожалуйста, напоминалку про эту фичу при переходе на дизассемблер чужих либов.

Интеграция Atlassian Bamboo и тестов xUnit.net

alik — Fri, 17 Feb 2012 22:51:05 +0000

Система непрерывной интеграции Atlassiat Bamboo включает множество плагинов для работы с тестами, но поддержка xUnit.net в это множество, к сожалению, не входит. Но интеграция все же возможна, о ней и расскажем.

Итак, имеется solution, состоящий из множества проектов. Проекты, которые собираются в assembly, и названия которых заказчиваются на Tests являются комплектами xUnit тестов. Сборка всего решения построена на MSBuild, осуществляется сервером Bamboo. Для управления внешними сбоками используется NuGet.

Шаг 1: Подключение xunit в MSBuild

При установке сборок xUnit в проект через NuGet, сборка задачи xunit для MSBuild уже была закачана. Подключим ее к нашему MSBuild проекту.

Если вы не используете NuGet, вы можете скачать дистрибутив xunit и положить .dll самостоятельно.

Шаг 2: Подготовка преобразования

В составе поставки Bamboo поддержки xUnit нет, но имеется job task под название NUnit parse. А в поставке xunit имеется описание трансформации лога xUnit в формат NUnit. Воспользуемся этим. Для этого надо скопировать файл NUnitXml.xsl из поставки xunit в корень проекта.

Шаг 3: Добавление задач в скрипт сборки

Теперь надо добавить 2 таргета в скрипт сборки:

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

NB! Важно, что файл отчета формата NUnit должен иметь расширение xml, иначе его не найдет NUnit Parse Task.

Шаг 4: Настройка парсинга в Bamboo

После задачи сборки проекта добавляем задачу NUnit Parsing. Примерно так:

До этого интерфейса можно добраться:

выбрав план сборки,
нажав на configure,
потом выбрав job сборки.

Проверка

Запустите план на сборку и убедитесь, в том, что тесты поключились и отчет виден через интерфейс Bamboo.

Правила оформления кода C# v1.0

alik — Tue, 07 Feb 2012 04:11:21 +0000

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

Использование такого стиля позволяет:

Быстро ориентироваться
Не задумываться над оформлением
Применять автоматические инструменты контроля стиля (ReSharper)

Описание рассчитано на использование C# версии 3.5.

Переменные

Использовать значимые имена переменных написанных на правильном английском. Транслитерация названий переменных не допускается.
Хорошо:

private int letters;
private int result;

Плохо:

private int rezultat;
private int oshibka;

Применение венгерской нотации не применяется ни в каких участках кода, ни в GUI, ни в DataAccess, ни в доменной части.
Хорошо:

private int letters;
private string result;

Плохо:

private int iRezultat;
private ComboBox cbItems;

В именах переменных не допускается применение знака подчеркивания. Каждое новое слово пишется с прописной буквы.
Хорошо:

private int lettersToUpdate;
private string lastName;

Плохо:

private int rows_in_table;
private string last_Name;

Переменные не могут начинаться со знака подчеркивания.
Хорошо:

private int lettersToUpdate;
private string lastName;

Плохо:

private int _rows;
private string _lastName;

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

Хорошо:

public static int Letters;
public int Letters;
protected int Letters;
internal int Letters;

Плохо:

public static int letters;
public static int LETTERS;
public static int LeTTeRs;

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

Хорошо:

public static int Letters;

for (var i = 0; i < names.Count; i++) {
...
}

names.Where(s => s.Length > 3).Select(s => s);

Плохо:

private int n;
private List l;

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

Использование var

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

Именование методов

Все методы начинаются с прописной буквы и не содержат в своем названии знака подчеркивания.
Хорошо:

private int GetErrorMessages() {
   …
}

Плохо:

private int get_Error_Messages() {
   …
}

private void save_OnClick(…) {
   …
}

Имена методов должны быть написаны на английском языке. Транслитерация не допускается.
Хорошо:

private int GetStockRates () {
   …
}

Плохо:

private int GetKotirovki () {
   …
}

Первым словом в названии метода должен быть глагол.
Хорошо:

private int LoadStocks() {
   …
}

Плохо:

private int StocksLoad() {
   …
}

Можно использовать универсальные глаголы типа Do или Perform.

Именование методов при возвращении булевого значения не должно формулироваться отрицательно.
Хорошо:

private bool IsValidUser () {
   …
}

Плохо:

private bool IsUserDoNotHaveErrors () {
   …
}

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

Обрамление кода

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

Плохо:

#region public fields

public static int Letters;

#endregion

//======== public fields =========================================

public static int Letters;

//======== end public fields =========================================

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

Плохо:

//        public Foo() {
//            Letters = 2;
//        }

Не стоит комментировать каждую строку и писать очевидные вещи.

Плохо:

/// 
/// Отображение данных
/// 
public interface IDataViewer
{
    /// 
    /// Всегда один
    /// 
    bool IsSingle { get; }

    /// 
    /// Сервер
    /// 
    string HostName { get; set; }

    /// 
    /// База данных
    /// 
    string Database { get; set; }

    /// 
    /// Загрузка данных
    /// 
    /// Результат загрузки
    bool LoadData();
}

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

Оформление блоков кода

Фигурная открывающая скобка всегда стоит на следующей от конструкции языка строке.
Хорошо:

namespace N
{
    internal interface I
    {
        void foo();
    }

    internal class C
    {}
}

Плохо:

namespace N {
    internal interface I {
        void foo();
    }

    internal class C {}
}

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

Свойства

Автосвойства должны быть записаны в одну строку.

Хорошо:

public int Age { get; set; }
public string Login { get; set; }

Плохо:

public int Age {
    get;
    set;
}
public string Login {
    get;
    set;
}

В остальном правила такие же, как и для полей класса.

Логические операции

Длина строки с логическими операциями не должна превышать 80-120 символов. Перенос операций производится с логическим знаком.

Хорошо:

if(boolValue && number >= 0) {
   ...
}

if(string.IsNullOrWhiteSpace(bigCompositeCaption)
   && bigCompositeCaption.StartsWith("x00")
   && bigCompositeCaption.Length > somePositiveNumber) {
     ...
}

Плохо:

if(string.IsNullOrWhiteSpace(bigCompositeCaption) &&
   bigCompositeCaption.StartsWith("x00") &&
   bigCompositeCaption.Length > somePositiveNumber) {
     ...
}

if(string.IsNullOrWhiteSpace(bigCompositeCaption) && bigCompositeCaption.StartsWith("x00") && bigCompositeCaption.Length > somePositiveNumber) {
    ...
}

Форматирование тернарной операции должно быть на несколько строк.

Хорошо:

return boolValue
    ? somePositiveNumber
    : anotherNegativeNumber;

Плохо:

return boolValue ? somePositiveNumber : anotherNegativeNumber;

Исключение может быть сделано только для результатов в 1-3 символа.

Хорошо:

return boolValue ? 1 : -1;

return boolValue ? “Y” : “N”;

Унарная операция ?? так же должна быть с переносом на новую строку, если для записи выражения требуется более ~60 символов.

Хорошо:

return someVeryLongNamedNullable() ?? “N/A”;

return someVeryLongNamedNullable()
    ?? new SomeVeryLongNamedClass();

Плохо:

return someVeryLongNamedNullable() ?? new SomeVeryLongNamedClass();

Строка начинающаяся со знака логической операции показывает, что это все еще идет условие, а не первый оператор при выполнении условия. Сравните:

if(string.IsNullOrWhiteSpace(bigCompositeCaption) &&
   bigCompositeCaption.StartsWith("x00") &&
   bigCompositeCaption.Length > somePositiveNumber)
   bigCompositeCaption.Trim();

if(string.IsNullOrWhiteSpace(bigCompositeCaption)
   && bigCompositeCaption.StartsWith("x00")
   && bigCompositeCaption.Length > somePositiveNumber)
   bigCompositeCaption.Trim();

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

Хочется поблагодарить коллегу violet-tape за его аналогичное состав правил. Множество правил было взято именно у него.

Автоматическая реализация INotifyPropertyChanged на Spring.NET

alik — Sat, 04 Feb 2012 01:34:55 +0000

В статье ранее я писал как сделать автоматическую реализацию INotifyPropertyChanged на основе расширений библиотеки NInject. К сожалению, моя жизнь с этой библиотекой не сложилась, NInject был заменен на Spring.NET. При этом схему автореализации надо было как-то перенести без особенных изменений прикладного кода. Объясню, что именно я сделал.

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

    public interface IAutoNotifyPropertyChanged : INotifyPropertyChanged
    {
        void OnPropertyChanged(string propertyName);
    }

Удобства ради можно использовать базовый класс для всех авто-реализаций:

    public class ViewModelBase : IAutoNotifyPropertyChanged
    {
        public event PropertyChangedEventHandler PropertyChanged;

        public virtual void OnPropertyChanged(string propertyName)
        {
            PropertyChangedEventHandler handler = PropertyChanged;
            if (handler != null)
            {
                handler(this, new PropertyChangedEventArgs(propertyName));
            }
        }
    }

Кроме этого, нам понадобятся атрибуты, которыми мы будет включать/отключать авто-нотификацию:

    [AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, AllowMultiple = false, Inherited = true)]
    public class NotifyOfChangesAttribute : Attribute
    {
    }
    [AttributeUsage(AttributeTargets.Property, AllowMultiple = false, Inherited = true)]
    public class DoNotNotifyOfChangesAttribute : Attribute
    {
    }

Теперь пришла очередь Pointcut, которые будет определять setter-ы целевых свойств:

    public class AutoNotifyPointcut : StaticMethodMatcherPointcut
    {
        public override bool Matches(MethodInfo method, Type targetType)
        {
            if (!typeof(IAutoNotifyPropertyChanged).IsAssignableFrom(targetType))
                return false;

            // non-setters ignored
            if (!method.Name.StartsWith("set_"))
                return false;

            object[] attributes = targetType.GetCustomAttributes(typeof(NotifyOfChangesAttribute), true);
            if (attributes.Length > 0)
            {
                object[] disables = method.GetCustomAttributes(typeof (DoNotNotifyOfChangesAttribute), true);
                if (disables.Length > 0)
                    return false;

                return true;
            }

            attributes = method.GetCustomAttributes(typeof (NotifyOfChangesAttribute), true);
            return attributes.Length > 0;
        }
    }

Затем нам нужен advice, в котором и будет происходить вся работа:

    public class AfterPropertySetAdvice : IMethodInterceptor
    {
        private static readonly Logger logger = LogManager.GetCurrentClassLogger();

        public object Invoke(IMethodInvocation invocation)
        {
            object proxy = invocation.Proxy;
            string name = null;

            IAutoNotifyPropertyChanged model = proxy as IAutoNotifyPropertyChanged;
            if (model == null)
            {
                logger.Error("Advice is called on non-IAutoNotifyPropertyChanged class");
            }
            else
            {
                name = invocation.Method.Name;
                if (!name.StartsWith("set_"))
                {
                    logger.Error("Cannot notify on non-setter");
                }
                name = name.Substring(4);
            }

            object rval = invocation.Proceed();

            if (name != null)
            {
                model.OnPropertyChanged(name);
            }

            return rval;
        }
    }

Тут для вящего удобсва отладки используется NLog. Его использование можно вовсе удалить.

Так, классы созданы, надо как-то их применить к объектам. Сразу скажу, что из-за особенностей Spring AOP для оборачивания класса в advice надо, чтобы экземпляр класса создавался Spring-ом. Код подключения выглядит примерно так:



  
  

  
    
    
  

  
    
    
      
        *Model
      
    
    
      
        notifyInterceptor

Можно заметить, что оборачиванию будут подвергнуты объекты, id которых заканчивается на «Model». Анонимные объекты будет проигнорированы.

Кажется, что ограничение по имени какое-то странное. Также кажется, что использование InheritanceBasedAopConfigurer выглядит странно в контексте наличия тега aop:config в Spring.NET. Поясню, почему именно так.

В рамках Spring.NET существует 3 способо создания proxy объектов для вызова advice:

Aggregation based – для объекта-обертки генерируется DynamicProxy со своим интерфейсом. Такой объект нельзя привести к оригинальному типу target объекта. Реальный объект в этом случае будет аггрегирован внутри proxy. Нам не подходит из-за несовместимого интерфейса.
Inheritance based – объект-прокси будет наследником класса target объекта, при этом обернуты будут только virtual методы и свойства оригинала. Оригинальный объект будет аггрегирован внутри proxy. В нашем случае это дает интересный спец-эффект: поскольку события тоже проксируются, то добавление обработчика события на объект-обертку не влияет на оригинальный объект. Значит, если внутри advice вызвать событие, то вызов будет превращен в вызов объекта-оригинала, а не обертки. А на внутреннем объекте обработчиков как небыло так и нет. Значит, тоже не подходит
InheritanceBasedAopConfigurer – новый способ генерации вызовов, добавленный в Spring 1.2. Идея состоит в изменении кода оригинального объекта. Вот это нам подходит, но дает указанные выше ограничения на создание объектов

Пример создания объекта:

Неопределенное будущее Titanium Desktop

alik — Wed, 01 Feb 2012 01:42:39 +0000

Около полугода я следил на развитием проекта Titanium Desktop. Идея продукта состоит в том, что можно создавать полноценные desktop приложения на HTML+JS. Я подумывал использовать этот фреймворк в одном из своих проектов. Но сегодня, проверяя новости, обнаружил нерадостное – проект снимают с финансирования AppCelerator и передают сообществу разработчиков. Официальный пресс-релиз можно прочитать здесь.

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

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

Таким образом, многоплатформенных технологий для создания desktop приложений на HTML+JS в доступности не видно. Разве что Adobe AIR, но он пугает чем, что Adobe.

Простая реализация INotifyPropertyChanged

alik — Tue, 31 Jan 2012 01:10:34 +0000

При разработке для платформы .NET часто приходится делать так раздражающие всех реализации интерфейса INotifyPropertyChanged на классах-моделях. Типичный пример выглядит так:

class StatisticsRecord: INotifyPropertyChanged
{
    private string name;
    public string Name { get { return name; } set { name = value; NotifyPropertyChanged("Name"); } }	

    private void NotifyPropertyChanged(string name)
    {
        if (PropertyChanged != null)
            PropertyChanged(this, new PropertyChangedEventArgs(name));
    }

    public event PropertyChangedEventHandler PropertyChanged;
}

На мой взгляд, с этим кодом есть 2 проблемы:

Очень много повторений и кода вызванного необходимостью вызвать NotifyPropertyChanged. Увеличивается количество «тупой» работы.
Использование строковой константы Name в качестве аргумента. Рефакторинг может привести к разрушению биндинга к такому свойству.

По счастью разработчики симпатичного фреймворка NInject сделали расширение Ninject.Extensions.Interception, которое позволяет решить описанные выше проблемы за счет использования динамического AOP. Используется это так:

Подключаем к проекту библиотеки NInject, Ninject.Extensions.Interception, Castle.Core, Ninject.Extensions.Interception.DynamicProxy

Создаем класс-реализацию интерфейса IAutoNotifyPropertyChanged, например так:

public class ViewModelBase : IAutoNotifyPropertyChanged
{
     public event PropertyChangedEventHandler PropertyChanged;

     public void OnPropertyChanged(string propertyName)
     {
         PropertyChangedEventHandler handler = PropertyChanged;
         if (handler != null)
         {
             handler(this, new PropertyChangedEventArgs(propertyName));
         }
     }
}

Используем этот класс в нашем классе модели. Например:
```
[NotifyOfChanges]
class StatisticsRecord: INotifyPropertyChanged
{
    public virtual string Name { get; set; }

    [DoNotNotifyOfChanges]
    public virtual string NonNotifyableProperty { get; set; }
}
```
NB! Важно, чтобы getter-ы и setter-ы были виртуальными, поскольку мы используем DynamicProxy для добавления нотификаций
Подключаем «перехватчик» при конфигурации ядра NInject:
```
...
kernel.Components.Add();
...
```

Код стал короче и понятнее напорядок.

PS. Детали того, как именно это все устроено смотрите тут:

System.BadImageFormatException при загрузке тестов в ReSharper

alik — Mon, 23 Jan 2012 22:31:01 +0000

В начале создания авто-тестов в одном проекте на C# начал возникать System.BadImageFormatException при попытке запуска тестов из ReSharper. Выяснение показало, что проблема была в том, что сборка с тестами имела Any CPU. А тестируемые классы были в EXE, который был собран в x86. При этом Windows используется 64х битный, следовательно Any CPU = x64.

Решение просто – указать в тестовой сборке целевую платформу x86. Это делается в закладке Build свойств проекта тестовой сборки.

Названия обработчиков событий в VS2010

alik — Mon, 09 Jan 2012 15:05:36 +0000

После установки ReSharper на Visual Studio 2010 (всем разработчикам на C# рекоммендую, кста) наиболее активно разражает подсвечивание названий методов, который автоматически генерируются Visual Designer для обработки событий, поскольку название типа «Form1_Load» никак не соответствует идеям начинать название с глагола и не использовать «_». Но это можно исправить.

Есть 2 способа исправления проблемы.

1. Изменить способ генерации названий методов
Предпочтительный

Установить плагин EventHandler Naming, который позволяет менять политику именования методов-обработчиков. Устанавливать можно прямо из Extension manager. Даже настройки не требует, по умолчанию настроен как On${SiteName}${EventName}, например, OnForm1Load. Если надо, настраивается.

2. Настроить ReSharper, чтобы он не ругался

Идем в меню ReSharper | Options | Languages | C# | C# Naming Style
Переключаем на «Advanced settings…»
Меняем значение «Event subscriptions on fields» с умолчального $object$_On$event$ на $object$_$event$

Поучимся?

alik — Mon, 26 Sep 2011 12:06:08 +0000

Я считаю, без каких-то новых знаний жить не особо интересно. Поэтому стараюсь учиться. А тут Стэнфорд предлагает уникальную возможность бесплатно поучиться computer science.

Предлагаемые курсы:

Все классы бесплатные, будут домашние задания. Стартуют примерно 10 октября. Язык преподавания – английский.

Я сам записался на машинное обучению и искусственному интеллекту.