Archives

Archives / 2012 / June
  • Модульное тестирование и контракты

    Tags: tdd, code contracts, unit testing, defensive programming

    Я давно хотел попробовать использовать контракты в дизайне своего кода, но всё как-то руки не доходили. Для целей defensive programming мне было вполне достаточно привычного подхода if-then-throw в начале каждого метода. Однако, руки наконец-то дошли, подвернулся новый несложный проект, и я решил включить эту технику в свой инвентарь. Как минимум это позволит мне писать более безопасный код, так как я буду проверять не только предусловия, но и постусловия и состояние объектов. И сразу же возник вопрос: “как такой код тестировать”. Вроде бы всё просто, заменяй тип ожидаемого исключения в модульных тестах с разнообразных ArgumentException, ArgumentNullException на тип, который используется при нарушении контрактов, но не тут-то было! Действительно контракты выбрасывают, при своём нарушении, исключение типа ContractException, но этот тип объявлен внутренним (internal).

    То есть подобный код просто не будет скомпилирован:

            [TestMethod]
            [ExpectedException(System.Diagnostics.Contracts.ContractException)]
            public void TestMethodName()
            {
                new ClothesStyle(null, 0);
            }
    

    Read more...

  • HTML 5 макет страницы с фиксированной шириной

    Tags: html5, css, макет страницы

    Один из типичных макетов страницы – страница с фиксированной шириной. Как правило, в таком макете должны присутствовать заголовок, область контента и подвал. Высота всего макета, в случае когда контента не хватает, должна равняться высоте окна браузера. Я решил накидать подобный макет для последующего использования. Макет проверен в пяти наиболее распространённых на текущий момент браузерах: Opera, Internet Explorer, Fire Fox, Chrome и Safari.

    Read more...

  • Вопросы для собеседования программистов

    Tags: идея, вопросы на собеседовании

    stackoverflow-logoМеня достали тупые, шаблонные вопросы на собеседованиях! Верхом тупости я считаю вопрос о том, как работает Garbage Collector. Грешен, я его сам задавал и не раз, но никогда не требовал от кандидатов полного отчёта о всех тонкостях его работы, никогда не ставил им в упрёк то, что они не знают с каких объектов GC начинает поиск мёртвых объектов. Работает и ладно. Будут проблемы с утечкой памяти, буду разбираться. Лично я считаю, что все эти энциклопедические знания никому не нужны. Ну, разве что игрокам в “Что, где, когда”. У нас всегда под рукой MSDN (или какая-то другая библиотека с документацией), блоги, и т.д. Так как быть?

    Однако я знаю по себе, как сложно придумать Хорошие вопросы. Сегодня меня осенило. Не надо мучать себя, надо воспользоваться тем, что уже есть. Думаю, всем программистам известен сайт Stack Overflow (есть и другие аналоги), на нём люди задают вопросы, касающиеся разработки программного обеспечения. Суть иди: идёшь на  Stack Overflow и подбираешь вопросы по нужной тематике и уровню, там их море с ответами и без. Да, многие вопросы требуют кодирования, но совсем не обязательно получать от кандидата готовое решение. Достаточно спросить о путях решения, которые он видит. В конце концов важно ведь не то, даст он правильный ответ за несколько секунд. Важно понять, как он ищет решение, как думает, как рассуждает, как ищет информацию. Хорош не тот программист, который знает все классы и методы сотни API, а тот, кто умеет быстро доходить до сути проблемы и знает как собрать нужную информацию для поиска решения, как поставить опыт (тест).

    Пользуйтесь, господа интервьюирующие! Идея бесплатна при условии ссылки на автора. Улыбка

    Read more...

  • CALM-нотация

    call-notation

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

                string cheepCounter = "Use CALM notation!";
                this.cheepCounter++;
    
    

    Так приходится делать, если слепо следовать рекомендациям для C#-кода. Но рекомендации – это лишь рекомендации. Я много раз видел в коде использование префикса для полей-членов. Кто-то ставит подчёркивание, кто-то m, а кто-то и то и другое: m_. Здравое зерно в этом было, и я решил попробовать. Поля вообще желательно использовать как можно реже, заменяя их свойствами. А так сразу видно, что, возможно, стоит пересмотреть дизайн класса. Если так можно пометить поля, почему бы не пометить и другие идентификаторы, где это будет полезно? Мне показалось полезным добавить следующие условные обозначения: a – аргумент метода, l – локальная переменная, c – локальная константа. Я решил дать этой нотации имя CALM: Constant Argument Local Member, что значит: Constant Argument Local Member. Такое именование несёт следующие выгоды:

    • не нужно больше писать конструкцию this.fieldName,
    • если необходимо приведение типов какого-то аргумента, то можно не выдумывать какое-то другое имя: FrameworkElement lSender = (FrameworkElement) aSender;
    • константу легко отличить от переменной только по имени: cYouCanNotChangeMe,
    • строго говоря это даже не нарушает рекомендацию: имена переменных, параметров, полей и локальных констант начинаются с маленькой буквы,

    Хорошо, использовать префиксы не рекомендуется, например, венгерскую нотацию, но тут несколько другое дело. И в конце концов, рекомендованные правила можно нарушать, если есть достаточное основание их нарушить. Я считаю, такой подход имеет право на жизнь. А что думаете вы?

    Read more...

  • Windows Phone + Caliburn.Micro + Autofac

    Tags: windows phone, caliburn.micro, autofac

    Source code

    Недавно я начал экспериментировать с разработкой под Windows Phone. У меня уже есть некоторый опыт разработки под WPF и Silverlight с использованием шаблона MVVM и IoC-контейнера, поэтому эта задача не представляет для меня большой трудности. Как выяснилось, мой любимый MVVM-фреймворк Caliburn.Micro (CM) и любимый IoC-контейнер Autofac поддерживают эту платформу. Я засучил рукава и начал формировать скелет приложения. CM активно использует IoC-контейнер для своей работы. Можно использовать либо встроенный контейнер (SimpleContainer), либо ряд других, для которых существуют адаптеры для CM. Есть такой адаптер и для Autofac – Caliburn.Micro.Autofac, который я уже использовал для WPF-приложений. Это замечательно, однако бочку мёда, как обычно, испортила ложка дёгтя – адаптер Autofac для CM 1.3.1 (текущая версия) под Windows Phone не работает. До недавнего времени он даже не компилировался, но его автор David Buksbaum пару недель назад поправил это недочёт. Однако, так или иначе, приложения с его использованием не работают. Видимо David не разрабатывает сам приложений для Windows Phone и эта версия осталась недоработанной. Отказываться от любимой связки не хотелось и пришлось написать этот адаптер самостоятельно. Сегодня я представляю вашему вниманию эту реализацию.

    Read more...

  • Изучая Autofac. Динамическое создание объектов с помощью контейнера

    Tags: autofac

    Тестовый проект

    Autofac 2 – один из множества IoC-контейнеров для .NET. Я не стану рассказывать о том, что такое IoC-контейнер (Inversion of Control container), IoC (Inversion of Control) и DI (Dependency Injection), предполагая, что вы уже знаете об этом или можете узнать из других источников, например, здесь. Я буду рассказывать об одном из них – Autofac – по мере моего знакомства с ним. До этого я пользовался StructureMap, но по ряду причин он мне больше не подходит. В частности он давно уже не обновлялся, требует полного .NET Framework (в противовес .NET Framework Client Profile), нет версии для Windows Phone, версия для WinRT (Windows 8) не предвидится. Autofac, как я понял, избавлен от этих недостатков. Вряд ли у меня получится излагать материал последовательно, да я к этому и не стремлюсь. Просто буду описывать те возможности, которые меня заинтересовали в данный момент.

    Read more...