Отмучался с Emit...

В предыдущем посте я описывал свой механизм проектирования по контракту. Никто ничего не откомментировал по его поводу, ну да ладно, не будем сейчас про это. Сегодня я закончил еще один этап своей работы, а именно генерирование прокси класса по определенному интерфейсу, который внутри себя использует класс ContractsManager, который в свое время внутри себя использует класс, который реализует необходимый интерфейс - ужас одним словом ;)

Попутно с этим, мне пришлось немного разобраться с таким пространством имен как System.Reflection.Emit. Страшное, надо сказать пространство имен ;)
С генерированием конструктора, который принимает параметр и запихивает его в специальное поле, проблем не возникло - примеров этого было много :) Ну попутно еще разобрался с тем, как сгенерировать поле.
Дальше началась проблема - необходимо было сделать метод, который реализует метод интерфейса следующим образом: внутри себя вызывает специальный метод у поля. Этому методу надо было передать имя метода и параметры метода. Ну так приблизительно я и сделал... Но прокси класс никак не хотел работать, со словами, что у него там какая то фигня сгенерирована, а не метод интерфейса :) Через некоторое время до меня наконец дошло, что это в C# ключевое слово params позволяет перечислять параметры через запятую... но потом они упаковываются в массив, а следовательно надо передавать не параметры, а массив параметров... И тут встала проблема - как создать локальную переменную в виде массива объектов, заполнить этот массив из параметров и передать куда нибудь... К счастью google помог и в этом :)
В итоге могу сказать - даже если плохо разбираешься в системном программировании .NET (имеется ввиду Emit, да и вообще программирование на чистом MSIL), то google лучший помошник. Хотя информацию приходиться агрегировать из примеров по маленьким кусочкам... Кстати говоря, ни нашел ни одного нормального источника на русском (да и английском), где можно было бы подробно почитать про Emit. Есть что то на intuit, но там на очень конкретном примере, в котором многое опускается...
P.S. А еще наконец то заменил себе старый монитор на новый ;)

Проектирование по контракту - первые попытки

Сегодня я предложу вам один способ использования проектирования по контракту в .NET, точнее очередную библиотеку, автором которой и являюсь ;) Надеюсь, что вы напишите свои впечатления, замечания, пожелания и т.д. и т.п.

На сегодня, наверное, будет только один пример использования. Пример, который используется во многих статьях про проектирование по контракту - класс стек ;)
Сначала приведу код интерфейса - он довольно простой ;)

public interface IStack<T>
{
    int Count { get; }

    bool Empty { get; }

    void Put(T item);

    T Remove();

    T GetItem();
}

Теперь можно сказать, какие предусловия, постусловия и инварианты можно придумать для данного интерфейса. Инвариантом может послужить условие о том, что количество элементов всегда больше или равно нулю. Предусловием для методов Remove и GetItem будет то, что количество элементов в стеке больше нуля. Постусловием для метода Put будет то, что свойство Count увеличивается на единицу, для Remove - уменьшается на единицу, для GetItem - свойство Count не изменяется.
По схеме, которую хочу предложить вам я, все утверждения записываются в отдельном классе (хотя их может быть и больше). Для каждого метода этого отдельного класса можно указать чем именно он является - предусловием, постусловием или инвариантом. Так же, необходимо произвести что то вроде mapping`а или биндинга параметров этих методов к параметрам проверяемого метода, а так же свойствам и полям. Все это делается через атрибуты.
Приведу пример проверяющего класса:

internal class StackCheck
{
   [Invariant("Количество элементов больше или равно 0")]
   public bool CheckCount(int Count)
   {
        return Count >= 0;
   }

   [Ensure("Количество элементов увеличивается на единицу", "Put")]
   public bool EnsurePut(
       [Old][PropName("Count")] int oldCount,
       [PropName("Count")] int count)
   {
        return count == oldCount + 1;
   }

   [Ensure("Количество элементов уменьшается на единицу", "Remove")]
   public bool EnsureRemove(
       [Old][PropName("Count")] int oldCount,
       [PropName("Count")] int count)
   {
        return count == oldCount - 1;
   }

   [Ensure("Количество элементов не изменяется", "GetItem")]
   public bool EnsureItem(
       [Old][PropName("Count")] int oldCount,
       [PropName("Count")] int count)
   {
        return count == oldCount;
   }

   [Require("Стек не должен быть пустым", "GetItem")]
   [Require("Стек не должен быть пустым", "Remove")]
   public bool RequireNotEmpty([PropName("Count")] int count)
   {
        return count > 0;
   }
}

Несложно заметить, что все проверочные методы должны возвращать bool, в противном случае этот метод будет опущен при проверке.
Атрибут Invariant задает, что метод является инвариантом класса, в данном случае такой метод один - CheckCount. В параметр конструктора атрибута можно передать описание инварианта. В случае, если инвариант не выполнится, то это сообщение будет использоваться в качестве сообщения ошибки, так же этот текст может быть использован для документации (подумываю позже написать что нибудь и для этого ;).
Перед параметром Count этого проверочного метода нет никакого атрибута, в таком случае для метода инварианта этот параметр будет пытаться биндиться к свойству проверяемого класса с соответствующим именем (регистр в данном случае важен), если такого свойства не будет, то к полю с таким названием, если не будет и поля, то сгенерируется исключение. В общем случае перед параметром проверочного метода инварианта можно указать один из двух атрибутов - PropName (биндится к свойству с указанным именем) или FieldName (биндится к полю с указанным именем).
Следующий метод помечен атрибутом Ensure. Этот атрибут принимает два параметра: описание (использование аналогично инварианту), а так же название метода, к которому относится постусловие. Кроме уже имеющихся возможных атрибутов параметров, в постусловиях можно использовать атрибут Old. Он говорит о том, что значение свойства (или чего то другого, в зависимости от второго параметра) должно браться до того, как был вызван проверяемый метод. Так же, кроме атрибутов биндинга к свойству и полю можно использовать атрибут биндинга к параметру метода - PropName. Если никакого атрибута не проставлено, то считается, что стоит атрибут PropName с названием аналогичному названию параметра. Сам метод EnsurePut проверяет, что количество элементов после вызова метода Put в проверочном классе будет увеличено ровно на единицу. Следующий метод - EnsureRemove, практически идентичен предыдущему, только он проверяет, что количество элементов уменьшилось на единицу после вызова метода Remove. Далее идет метод EnsureItem - он проверяет, что после вызова метода GetItem количество элементов не изменится.
Следующий метод помечен атрибутом Require (даже двумя ;) Параметры атрибута Require аналогичны атрибуту Ensure, только он говорит о том, что помеченый им метод является предусловием, а не постусловием. К параметрам метода предусловия могут применены все те же атрибуты, что и к методам Ensure, за исключением Old (он просто опускается и не учитывается). Как видно из кода, здесь проверяется, что перед вызовом методов Remove и GetItem количество элементов больше нуля.
В принципе, логичнее проверять не свойство Count, а свойство Empty. В таком случае код можно переписать так:

[Require("Стек не должен быть пустым", "GetItem")]
[Require("Стек не должен быть пустым", "Remove")]
public bool RequireNotEmpty([PropName("Empty")] bool empty)
{
    return !empty;
}

Как можно заметить, сам класс помечен как internal. По крайней мере для рефлексии это имеет не такое большое значение ;)
Теперь, имея такой класс, мы можем сказать интерфейсу стека, что он должен использовать его в качестве проверочного - для этого служит атрибут ContractsType, которому необходимо передать тип проверяемого класса. Еще одно немаловажное свойство, в связи с этим, проверочный класс (в нашем случае StackCheck) должен иметь пустой публичный конструктор (хотя по поводу публичного - кто знает эту рефлексию ;)

[ContractsType(typeof(StackCheck))]
public interface IStack;
{
    //Описание интерфейса...
}

Наверное теперь у вас возникает вопрос - как все это использовать? А использовать все это можно через специальный класс, который называется ContractsManager - он создается для экземпляра определенного класса. Например можно использовать вот так:

Stack<int> stack = new Stack();
ContractsManager contractsManager = new ContractsManager(stack);
int res = contractsManager.RunMethod<int>("Remove");

В данном примере мы создаем класс "обертку", которая может вызвать метод вместе с проверками. Заметьте, что используется generic метод - для того, что бы указать, результат какого типа вернет метод. Так же, обратите внимание на то, что здесь используется класс Stack - наследник интерфейса IStack - т.е. все проверки наследуются по иерархии.
Т.к. стек создается по умолчанию пустой, то в данном случае сгенерируется исключение - RequireException с текстом сообщения - "Стек не должен быть пустым".
Если необходимо вызвать метод без каких либо проверок, то можно просто вызвать метод у экземпляра класса. Но это еще не все. На самом деле у каждого из атрибутов (Invariant, Require и Ensure) имеется еще один параметр, который можно задать - это приоритет (по умолчанию он равен 0). У класса ContractsManager в свое время так же есть 3 свойства которые задают максимальные приоритеты для инвариантов, предусловий и постусловий (по умолчанию тоже равны 0). Соотвественно эти свойства можно менять во время исполнения программы тем самым "балансируя" производительностью.
Естественно, что все это пока только... бета ;) Уже сейчас есть некоторые проблемы, например с generic - скажем так, пока что я особо не обращаю на них внимание. Так же, есть еще несколько идей относительно того, что можно было бы еще добавить. В общем, жду так же и ваших комментариев ;)
P.S. Да, я очень не хороший мальчик, но библиотеку с кодом всего этого я пока никуда не выложил ;)

Pipes

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

Например можно взять обычную ленту новостей и отфильтровать все ее записи по категориям или еще чему нибудь. Так же можно переименовать часть полей, можно сделать join нескольких лент, ну и всякого рода другие интересные возможности. В общем, советую попробовать хотя бы ради интереса ;)
Из недостатков пока нашел только то, что иногда русский язык отображается неправильно (но скорее всего это связано с неправильным указанием кодировки в самой ленте новостей).
Сам сервис предоставляет yahoo, но самое интересное, что при этом сервис использует некоторые API от google. В общем, идея, конечно интересная, посмотрим что будет дальше.

+++

Помните, как в ночном дозоре Завулон играет в приставку с помощью сотового телефона? Ну точнее махает мечом путем махания сотовым телефоном... Так вот кто, оказывается, придумал Wii :)

Still Alive

Наверное многие уже слышали эту песенку... Если, конечно играли в Portal :) В данном случае можно посмотреть на живое исполнение ;)

Еще хотелось бы сказать, что в Valve всегда делали довольно хорошие игры. Меня конечно немного тошнило во время игры в Portal, но сама история меня зацепила - особенно песенка в конце. Ну и конечно же, интересно было в свое время почитать про то, как создавалась эта игрушка, как внедрялись некоторые забавные элементы игры...

P.S. Хочу пирог... :)

Проектирование по контракту (бинарный поиск)

В свое время много вопросов вызвала дискуссия: надо ли проверять массив на упорядоченность (предусловие) при бинарном поиске. Надо? :)

Поразмышляю на эту тему ;)

Начну с того, что еще раз обращу внимание на то, что в теории никто не говорит о том, что в действительности надо делать с предусловием, постусловием и инвариантами. Они есть и все ;)
Теперь обратимся к разуму :) На сколько мне известно, бинарный поиск имеет сложность Q(log(n)) (по умолчанию у программистов логарифм двоичный ;), а вот проверка массива на упорядоченность, по всей видимости, Q(n) (по крайней мере я не знаю способа сделать это быстрее ;) Т.е. получается, что сама по себе проверка сводит на нет все преимущества бинарного поиска... К тому же, стоит сказать, что выигрыш в бинарном поиске обычно происходит при неоднократном обращении (имеется в виду, что если нам надо найти элемент в не упорядоченном массиве один раз, то лучше просто пройтись по нему, чем отсортировать его, а потом искать в нем бинарным поиском). При рассмотрении проблемы с этого ракурса, кажется логичным не включать проверку массива на упорядоченность в бинарный поиск ;)
Теперь стоит ответить на вопрос - что же тогда делать с наши предусловием? Оно же имеет место быть (по логике вещей). На самом деле, скорее всего это тот класс (имеется в виду не класс в программировании, а... социальный класс ;) предусловий, который может использовать в своей работе разработчик. Т.е. другими словами, у программиста есть метод бинарного поиска, который ему необходимо реализовать, причем при этом ему сказано - "не заморачивайся по поводу не упорядоченности элементов в массиве". Такие предусловия не должны попадать в код в виде непосредственных проверок. В принципе, можно сделать их автоматическое добавление в xml документацию ;)
Ну и напоследок, рассмотрим несколько примеров предусловий для бинарного поиска, которые можно было бы и включить в код.
Итак, начнем с упорядоченности элементов в массиве. Вроде мы можем быть абсолютно уверены в том, что элементы в массиве упорядочены, но не совсем ;) Ведь нам еще важно - в каком направлении они упорядочены :) Так что проверяем, что, первый элемент <= последнему. В принципе, от данной проверки можно отказаться, если написать такой бинарный поиск, который просто анализирует, в каком направлении отсортирован массив. Вторая проверка больше подойдет для Generic коллекций. Если я ничего не путаю, то, скорее всего, в алгоритме бинарного поиска придется что то сравнивать ;) А это означает, что элементы массива должны реализовывать интерфейс IComparable (ну если мы говорим про .NET ;).
Кстати говоря, наверное еще желательно, что бы все элементы были одного типа (точнее говоря приводились к типу, который мы ищем). Но это уже попахивает очередной проверкой всех элементов ;)
Ну вот на этом я, пожалуй, и закончу ;)

Dot Net Books

Наткнулся тут на один сайт посвященный книжкам по .NET. Наполнение этого сайта меня просто поразило ;)
P.S. Особой внимание обратите на комментарий к первому посту :)

Проектирование по контракту - идеальный случай

Попробую написать коротенький такой пост про то, как бы по моему мнению идеально выглядело бы внедрение DBC в язык программирования, так сказать - мечты ;)

Допустим что у нас есть некий проект в котором есть классы с описанными инвариантами, пред и пост условиями. Ну и представим, что их описание довольно легкое, скажем так, нас в первую очередь сейчас должен волновать не способ их описания ;) Что теперь с этим описанием необходимо делать?
Ну можно делать, например, разного рода ворнинги. Например, есть метод у которого в предусловии у первого параметра стоит, что он должен быть больше нуля, а мы передаем туда переменную просто типа int. В таком случае необходимо добавить warning о том, что переменная может быть и меньше нуля. Ну или есть у нас еще некий класс у которого есть свойство для которого задано, что оно больше нуля и именно это свойство мы передаем в метод - в таком случае ворнинга быть не должно быть.
Под категорию таких же проверок может подойти так же, например, вызов метода из другого метода. Есть метод1, который внутри себя где то в середине вызывает метод2, передавая ему расчитанные в методе1 параметры. В зависимости от входных данных метода1 зависит передаваемый параметр в метод2, т.е. в зависимости от ограничений на входные данные метода1 зависит то, какой параметр мы можем передать в метод2. Анализируем ограничения на параметр в методе2 и, быть может, выдаем замечание о том, что ограничение на параметр в методе1 можно и усилить, т.к. при некоторых его значениях вызов метода2 будет некорректен.
Пусть у всех пред пост условий и инвариантов есть приоритет - в таком случае при компиляции можно указывать, какие проверки в итоге можно включать результирующий код, а какие нет. Это так сказать - игра с балансом производительности и безопасности.
Возможность автоматического тестирования на основе все тех же пред пост условий и инвариантах.
В общем говоря, DBC должен открыть возможность дополнительного анализа кода (ведь появилась некая дополнительная мета информация о нем), а не просто добавлять проверки в код ;)

Проектирование по контракту (часть 2ая)

В предыдущем посте я начал рассказывать про проектирование по контракту (DBC). А закончил я рассказ на том, что сделал некий небольшой обзор уже существующих попыток внедрить проектирование по контракту в .NET. Теперь же наступило время продолжить ;)

Стоит сказать, что изначально, идею проектирования по контракту я хотел использовать с целью тестирования кода. Идея была приблизительно следующая: описываются предусловия, постусловия и инварианты с помощью атрибутов, затем запускается некая среда, которая подгружает созданную сборку, на основе атрибутов генерирует некий набор случайных тестов, и запускает их. Тут может возникнуть вопрос - какой именно набор тестов, что значит случайный и что эти тесты проверяют? Да и, вообще, зачем все это нужно? Отвечу на вопросы по порядку.
Начну, наверное издалека, а именно с вопроса - чем меня не удовлетворяют стандартные автоматизированные тесты на основе NUnit? А не удовлетворяют они меня тем, что все тесты приходится придумывать самому. Согласен, что в ряде случаев это правильно, но не всегда. Например, есть у нас метод принимающий целочисленный параметр. Для этого метода известно, что в зависимости от того, в какой диапазон попадет этот параметр, метод может повести себя по разному. Предположим что таких диапазонов 3. В таком случае мы пишем 3 теста, в каждом из которых проверяем метод при подаче в него параметра из соответствующего диапазона (1го, 2го и 3го), ну или пишем один большой тест (что, лично я, делать не советую ;). Вроде все правильно, только вот из каждого диапазона мы проверим только несколько значений. А вдруг, на самом деле существует некий 4ый диапазон для чисел из которого наш метод будет выполняться неправильно? В таком случае наши тесты не найдут этот самый диапазон. И это при том, что проверяемый нами метод полностью покрыт тестами. Естественно, что сейчас найдутся люди, которые скажут, что оттестировать все варианты невозможно, но тем не менее...
Лично мне в данной ситуации более логичным кажется в каждом их трех тестов брать не конкретный параметр из заданного диапазона, а случайно сгенерированный. Естественно, что тогда нельзя будет точно определить выходной параметр метода, но, скорее всего некие ограничения на него наложить будет можно (сумма двух положительных - положительна). При таком методе тестирования, теоретически, может сгенерироваться параметр из нашего 4го диапазона и в таком случае тест может и не пройти (а может и пройти, выходные параметры мы же проверяем не на точное соответствие). Конечно для верности в тесте надо будет сгенерировать несколько входных параметров. В итоге мы получаем некое стохастическое тестирование. А вдруг да и грохнется наш тест на каких то непредвиденными нами входными данными? Причем, в первую очередь, имеется виду не то, что сам метод не выполнится (это уже фуззи тестирование), а то, что выходные параметры не пройдут проверку.
Конечно нельзя сказать, что данный метод тестирования лучше традиционного. Лучше сказать так - они бы прекрасно дополняют друг друга.
Ну вот мое "издалека" и кончилось. Я думаю, что смышленные уже догадались, что три описанных выше теста с легкостью могут быть превращены в три различных контракта для метода. Осталось только автоматизировать процесс автоматической генерации данных, ну а еще придумать удобный способ описания этих самых контрактов (а иначе толку от идеи мало, т.к. легче будет писать такие тесты ручками). В итоге получаем ответы на наши вопросы. Генерируется набор тестов, который проверяет определенный контракт метода генерируя случайным образом входные данные для этого метода.
Теперь, наверное, стоит ответить на вопрос, какое отношение все это имеет к первому моему посту, где я рассказывал про Spec# и eXtensible C#? А отношение следующее - лично по моему сугубо личному мнению, велосипеды получились неудобные, т.к. использоваться проектирование по контракту должно не как велосипед. Поясню. Теория проектирования по контракту вообще говоря, не подразумевает использования пред пост условий и инвариантов для более простой записи проверяющих условий в коде. В первую очередь она служит для того, что бы описать некие логические ограничения классов во время проектирования (именно проектирования, а не кодирования), которые нельзя описать с помощью обычных конструкций языка. Ну, например, нельзя компилятору объяснить, что количество элементов в коллекции должно быть больше нуля, т.к. с точки зрения компилятора int может применять и отрицательное значение. Нет, конечно можно сделать свойство в котором метод set будет все это проверять, но проблема не в этом. Проблема в том, что само по себе условие о том, что свойство Count должно быть больше нуля никак не отражается в описании класса (в описании интерфейса этого класса, так будет лучше) - программист сам понимает, что он должен сделать такое ограничение, ну или проектировщик интерфейсов описывает это дополнительно где нибудь (например в тех. задании на реализацию этого интерфейса, или в remarks к свойству). Существующие же решения просто предлагают краткую форму написания проверок.
Еще пару слов об автоматизированном тестировании, а точнее о TDD. Это очень хорошая методология, правда ;) На самом деле TDD позволяет как раз частично описать те самые ограничения (и не только их). Соотвественно, потом появляется возможность спокойно реализовать код и проверить его с помощью тестов на соответствие этих самых ограничений (а не написать код, а потом писать тесты, которые "подтверждают" что это самый код работает). На самом деле всвязи с этим у TDD прослеживается хорошая связь с DBC. Только вот DBC содержит более "абстрактные" проверки (TDD проверяет конкретный пример - частный случай, а DBC говорит, как должно быть в общем). Но не смотря на связь нельзя сказать, что TDD это частный случай DBC или наоборот... просто здесь есть некие пересечения, есть что то общее, но только в некоторых частях обоих методологий.
Немного отступлю от темы, что бы еще раз разрекламировать TDD. Недавно у меня была следующая проблема: я уезжал из города на неделю, но необходимо было придумать задание, которое бы выполнили в мое отсутствие. Задание заключалось в том, что бы создать DataSet определенной структуры. Можно конечно было просто сказать - сделайте DataSet соответствующий структуре такой то БД, но боюсь, что "реализаторы" не могли в полной мере понять, как же надо соответствовать структуре БД, да и проверять потом сделанную работу просмотром кода не очень то удобно. Соответственно были сделаны тесты, которые просто проверяли, что DataSet содержит внутри себя такое то кол-во таблиц, что таблицы имеют такие то названия, что в таблицах есть такие то столбцы такого то типа, что заданы определенные ключи и определенные связи между таблицами. Другими словами я описал то, что хотел увидеть в результате, но в форме тестов. В итоге люди, особо не понимающие, что, например, столбец должен иметь такой тип данных и именно такое название, зачем нужны связи между таблицами и т.д. смогли реализовать код (хотя конечно не за неделю, но тут уже проблема в другом). Задание же для них было приблизительно следующее: все кружочки должны быть зеленого цвета. Самое главное, что и я был спокоен относительно того, что код был реализован правильно.
Но вернемся к нашей теме. А начну я с того, что брошу еще один камень в парк велосипедов. Камень этот имеет название "постусловия". Что такое постусловия? Это утверждения, которые говорят о корректности выполненого метода. Что же происходит с ними, например, в eXtensible C#? Постусловия превращаются в подобие Assert, которые вызываются перед return метода... Т.е. получается, каждый раз, когда вызывается метод, он проверяет себя - а правильно ли я вообще выполнился? С одной стороны это, может быть и правильно - метод поймет, что сделал какую то глупость во время выполнения приложения... т.е. приложение более устойчиво к своим же ошибкам? Ну это зависит от того, что в такой ситуации сделает метод. Наверное логичнее всего отправить отчет microsoft - пусть разбираются ;) А если честно, то получается, что тесты перетекли в уже готовое приложение и выполняются каждый раз во время выполнения метода (что естественно сказывается на производительности, причем, по моему, это нельзя оправдать большей надежностью).
С предусловиями все таки все не так плохо. Часть из них действительно необходимо включать в результирующий код, например предусловие о том, что какой то параметр метода не должен быть равен null. С другой стороны возникает вопрос, что делать если предусловие не выполняется? Генерировать исключение, просто выходить из метода?
Ну или еще милый пример (это если я, конечно, все таки понимаю проектирование по контракту)... Допустим у нас есть несколько контрактов на метод сложения двух чисел: "если оба числа положительные, то результат положителен", "если оба числа отрицательные, то результат отрицателен". Ведь у обоих контрактов есть предусловие и постусловие.... причем если для конкретного предусловия не выполняется его постусловие, то метод реализован неправильно, но вод вставлять эти пред и пост условия в конечный исполняемый код... извините, но по моему это неправильно. К тому же тут наблюдается следующая ситуация: несоответствие одному из предусловий еще не говорит о том, что входные параметры неверны, ведь они вполне подходят для другого предусловия. В данном примере входные параметры даже могут не удовлетворять обоим предусловиям. В общем случае тут получается ситуация, когда по одному из контрактов метод с данными входными параметрами выполняться не должен, а по другому должен. Что делать? Это зависит от самих контрактов. Например контракт должен быть обязателен к исполнению, или нет. Тут мне, наверное, стоит оговориться - на сколько я помню, в самой теории DBC нет вывода нескольких типов контрактов (а жаль). Кстати, что думаете об этом? Путаю ли я тестирование и проектирование по контракту? :)
Следующий пункт в моем не структурированном высказывании будет посвящен связи проектирования по контракту и аспектному программированию. Связь может быть натянутой, ну или немного искуственной, сейчас объясню почему. Для начала скажу, что связь проектирования по контракту с аспектным программированием появилось только из-за того, как это проектирование по контракту реализовываться. Ведь самым логичным подходом считается следующий: ловим момент вызова метода, проверяем все наши предусловия, если они прошли проверку, то вызываем метод, получаем выходные параметры, проверяем на их основе постусловия, если все хорошо, то возвращает результат дальше. Вот и получается, что у нас что то делается в начале вызова метода и в его конце. Лично мое мнение - это все неправильно. По крайней мере про постусловия я уже говорил выше, да и с предусловиями все не так ясно. Могу лишь согласится, что аспектное программирование логично применять при верификации кода в тестах по контрактам и инвариантам.
Кстати об инвариантах. Как не жаль, но инварианты это единственное, что на данный момент до сих пор осталось только в теории... По хорошему, инварианты нужно проверять и в предусловиях и в постусловиях, в реальности же, необходимость в этом наблюдается не всегда (в принципе отчасти это и логично). Из-за этого, скорее всего, было принято единственное решение - вообще их не использовать, а жаль... Лично я вижу следующее решение данной проблемы: для каждого контракта указывать, какие именно инварианты имеет смысл проверять в данном контракте. Так же, по хорошему, необходимо проверять часть инвариантов, когда происходит изменение свойств и полей. Хотя, учитывая, что свойство - это просто два метода (а на метод можно навесить контракт), то проблема остается актуальной только для обычных полей.
Подводя промежуточные итоги я могу лишь сказать, что или идеи DBC написаны не очень четко (т.е. иногда возникают спорные вопросы относительно того, что же это такое... ну вот как у меня с несколькими контрактами), или везде, где утверждается использование DBC - оно используется только отчасти (а точнее - используется название "проектирование по контракту" для каких либо целей, но никакое это не проектирование по контракту)...
P.S. Честно говоря, уже забыл с чего я начал этот пост, и что именно хотел сказать в его начале... Наверное это пока что только начало рассуждений о том, что же на самом деле такое "проектирование по контракту". И, надеюсь, что вы поможете ответить мне на этот вопрос ;)

Проектирование по контракту (часть 1ая)

Now playing on iTunes: Fleur - Сегодня
В настоящее время я занимаюсь попыткой "внедрить" проектирование по контракту в .NET (на примере языка C#). Внедрить я взял в кавычки неспроста, дело в том, что под внедрить понимается не как непосредственное внедрение проектирования по контракту в синтаксис языка (ну или в саму среду .NET), больше имеется в виду внедрение идеи проектирования по контракту в сам процесс написания приложений на .NET. В связи с этим, хотел бы поделится некоторыми идеями и наблюдениями, но о всем по порядку...

Наверное сначала стоит уточнить, что вообще такое проектирование по контракту (знающие могут пропустить абзац ;). Если совсем кратко, то это описание некоторых утверждений, которые должны выполняться в определенный момент работы программы. Например есть некоторые ограничения на входные параметры метода (предусловия), если они будут выполнены при вызове метода, то гарантируется что и сам метод выполнится успешно, кроме того будут выполнены ограничения наложенные на выходные параметры метода (постусловия), если они конечно есть. Ну например для метода деления одного числа на другого: "второе число не должно быть равно нулю, в таком случае деление произойдет". Или для того же метода деления чисел: "если оба числа положительные, то деление произойдет и результат будет положительным". Ну и т.д. Все это называется контрактом (контракт на метод). Кроме контрактов есть так называемые инварианты класса (вообще говоря, это может быть и интерфейс) - это некие утверждения (как правило затрагивающие поля и свойства), которые должны удовлетворятся на протяжении всей жизни экземпляра этого класса (в теории их проверка обычно происходит перед вызовом метода и после его выполнения, т.е. в пред и пост условиях). Примером инварианта для какой нибудь коллекции может служить такое вот утверждение: "количество элементов в коллекции больше нуля". Ну я, надеюсь, что вкратце ясненько, хотя, быть может и не по научному ;)
Для чего вообще используется идея проектирования по контракту? В первую очередь для повышения надежности разрабатываемого продукта (приложения, кода, "черти что и с боку бантик" - для кого что ;). Естественно, что идея проектирования по контракту не на столько нова, а значит и для C# (а он тоже уже не так нов) уже что то придумано (стоит заметить, что в наше время вообще сложно быть в чем то первым, как правило получается только снова изобрести уже существующий велосипед, но это так - лирическое отступление). Существующими и , в принципе, работоспособными примерами чего то придуманного служат, например, Spec# и eXtensible C#. Расскажу про них совсем немного ;)
Spec# представляет собой некое расширение синтаксиса языка C#. При таком подходе можно написать предусловия, постусловия и инварианты (далее будем называть все это прелестями для краткости ;) прямо в коде - прямо как в теории проектирования по контракту. При этом компилятор дополнительно "что то там" проверяет на этапе компиляции на основе этих самых прелестей, что, естественно позволяет выявить ошибки еще на этапе разработки. Так же компилятор на основе все тех же прелестей добавляет ряд проверок в код, которые будут работать во время исполнения. Ну и, естественно для всего этого есть некая среда разработки в виде расширения Visual Studio, что бы жизнь казалась медом :) Не смотря на все, вроде как, имеющиеся плюсы, есть один минус (который может все перевесить) - Spec# всетаки не C#, т.е. другой язык программирования. Ну так же, по моему, не имеется уже привычного нам всем IntelliSense ;).
Проблему "другого" языка может решить eXtensible C#, который представляет собой немного другой подход к проблеме внедрения проектирования по контракту. Во-первых, это набор атрибутов, с помощью которых (вроде как) можно описать наши прелести. Во-вторых, это некое расширение компилятора, которое на основе соответствующих атрибутов вставляет в код дополнительные проверки. Тут может возникнуть вопрос - в чем же отличие, если eXtensible C# это тоже расширение компилятора? На самом деле в том, что код написанный с применением eXtensible C# можно скомпилировать и обычным компилятором, в таком случае просто атрибуты eXtensible никак не повлияют на скомпилированный код (просто останутся в метаданных).
Тут я сделаю некое лирическое отступление про то, как все это работает. На самом деле с eXtensible C# компиляция проходит в два прохода: сначала проект собирается обычным компилятором, а затем компилятор eXtensible C# загружает созданную сборку, через рефлексию анализирует свои атрибуты, на их основе "подправляет" код (вставляя проверки) и снова все компилирует (ну в случаи неудачи выводит стандартные ошибки компиляции). Соотвественно, за счет этого eXtensible C# легко отключается, ну а за счет атрибутов достигается обратная совместимость со стандартным компилятором (если это можно назвать совместимостью, лучше сказать так - eXtensible C# использует то, что никак не мешает обычному компилятору ;).
Стоит сразу сказать, что в eXtensible C# так же не обошлось без минусов. Во-первых, из-за применения атрибутов нет никаких проверок во время разработки (ошибки вскрываются во время компиляции, ну или после ;). Во-вторых, из-за применения атрибутов, писать утверждения довольно проблематично, точнее сказать - в атрибут они передаются как самая обычная строчка ("count > 0") - наверное, отсюда, кстати и берется первый минус , т.к. во время передачи строчки никак нельзя узнать, правильно ли она написана, только во время компиляции (другими словами забудьте про Intellisense ;). В третьих, никак не используются инварианты классов (кстати, может быть их нет и в Spec#...). В четвертых, eXtensible C# применим (как видно из названия, кстати) только для C# - другими словами, для других языков программирования данные атрибуты являются просто пустышкой.
Есть и немного другие подходы (например кто то советует просто использовать класс System.Diagnostic.Debug с его методом Assert). Подведя итог можно сказать следующее: велосипеды уже есть, но ездить на них не так уж и удобно (еще лучше сказать - ездить конечно можно, но только при явном желании). Вопрос в другом - можно ли изобрести что то лучше? В общем, если кто то найдет ответ - скажите мне ;) А я по старинке буду пока что просто пробовать изобрести очередной велосипед. Кстати, наконец то настало время рассказать про свои замечания... Но уже, наверное, не сегодня ;)
P.S. А пока можете комментировать - ваше мнение мне очень интересно ;)

На кого из героев „Футурамы“ ты похож?

Прошел от тут один милый тест - любителям Футурамы посвящается;) Что то в моем результате есть противоречивое... но мое, наверное)))))

Результат теста «На кого из героев „Футурамы“ ты похож»: Проф. Лила Гермес Бендер Зойдберг Фрай Эми Киф Зепп 6 4 -1 5 3 7 9 6 4 Если Вы желаете узнать больше о своем характере и о характере героев «Футурамы», то прочитайте статью «Псих-о-рама». Пройти тест.

Stylish

Сегодня я хотел бы поделиться с вами своей очередной находкой. Находка касается очередного расширения для Mozilla Firefox - Stylish.
А все началось с того, что сегодня мне окончательно надоело куча лишних рекламных (и не только) колонок на computerra (в результате сама статья становится до ужаса узкой). Обычные вырезалки нежелательного контента мне не подходили, т.к. они, конечно, что то вырезают, но не факт, что остальной контент после этого встанет на место вырезанного (т.е. займет освободившуюся часть)...

Для начала (когда я еще не знал про Stylish) я решил просто проверить, на сколько можно изменить внешний вид computerra подручными средствами. Подручным средством оказался firebug (по моему скоро это расширение станет одним из моих самых любимых). С его помощью я довольно быстро разобрался, что мне надо отключать, какие стили править и т.д. Подытожив я понял что сия махинация возможна, осталось только все это автоматизировать.
Дальше начались долгие поиски. Через некоторое время я уже совсем отчаялся и решил, что изучу наконец - как же пишутся эти самые расширения для Firefox (я же все таки программист как ни как). Но, тем не менее лень меня победила (я же все таки программист как ни как) и закончилось все тем, что я нашел уже готовое расширение для Firefox :D Стоит сказать, что изучение устройства расширений лишним тоже не оказалось;)
Найденным расширением, как несложно догадаться, стало Stylish. После небольшого изучения я приступил к реализации, а именно выбрал создание нового стиля для cumputerra в котором для начала: скрыл верхний баннер, самую правую колонку (это там, где "сегодня в номере" и т.д., в общем, только место зря занимает), третью рекламную колонку а так же начало рекламы от бегуна (пока не придумал как убрать ее конец). В итоге получился следующий код:

@namespace url(http://www.w3.org/1999/xhtml);

@-moz-document domain("www.computerra.ru") {
#tophban {display: none !important }
#terralab {display: none !important }
#skyright {display: none !important }
#begunRoot {display: none !important }
}

Теперь на странице не отображается ничего лишнего (ну лишнего для меня), но, тем не менее остается куча свободного места, которое можно заполнить основным конентом (ради которого я и посещаю этот сайт). А все дело в том, что в коде заданы жесткие размеры - ничего, сейчас поправим;). Для этого ставим ширину шапки и страницы в 100%, а не 770px, как было:

#top {width: 100% !important }
#page {width: 100% !important }

После этого замечаем, что контент всеравно имеет слишком большой отступ от правого края - этот отступ предназначался для размещения в нем рекламы, но ее то у нас уже нет;) так что уменьшаем отступ:

.content {margin-right: 20px !important }

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

p {text-align: justify !important }

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

Стоит сказать, что Stylish еще поддерживает и публикацию ваших стилей в общую базу, а так же поиск стилей других пользователей для данного сайта. Т.е. если вы хотите подставить для сайта свой стиль для чего либо, то, сначала посмотрите, нет ли уже аналогичных стилей других пользователей (зачем изобретать велосипед). Сделать это можно вызвав команду Stylish - "Find Styles for this Page". Для computerra уже был один стиль, но он не делал то, что было нужно мне.
P.S. Кстати, когда выравнивал текст по ширине, обнаружил небольшой баг в firebug (ну или в firefox). Дело в том, что материал находится в div с id="article" и я сначала прописал у него text-align: justify !important; тем не менее тег p внутри него не принял этот атрибут, точнее он не заменил свой text-align: left; (который определен для всех p на странице, но выше по иерархии) не смотря на то, что по мнению firebug он это должен был сделать.

Class Designer

Недавно для себя открыл в полной мере Class Designer в Visual Studio 2005. В полной мере - это значит что теперь я сначала что то в нем рисую, а не делаю классы, а дизайнер использую просто для красивого их отображения (их - это классов);)

Вообще, про то, что Class Designer в VS представляет собой некий аналог диаграмм классов UML, но только для .NET и с моментальным отображением в код и, соотвественно, кода в него (другими словами синхронизация диаграмм и кода), я слышал уже давно. Но до недавнего времени я не уделал этому большое внимание (всетаки раньше я был больше программистом). Недавно же передо мною встала задача спроектировать ряд бизнес объектов. Начал я по старинке, т.е. с написания кода интерфейсов. Через некоторое время меня утомило писать фигурные скобки, геты, сеты и т.п. К тому же при таком подходе небыло видно всей картины в целом (кто от кого наследуется, какие связи существуют между объектами).

Для начала я просто решил воспользоваться Class Designer для того, что бы как раз посмотреть общую картину (точнее показать другим то, что я натворил в красивом виде). Потом я заметил, что изменять название полей, методов, да и добавлять новые гораздо легче с того же самого дизайнера классов (через окно Class Details), к тому же через окно Class Details очень удобно сразу же писать документацию к полям, методам и т.п. Так же довольно просто создать класс, унаследовать его от того, который уже есть на диаграмме, а так же указать что у него должны быть поля вот такого то и такого типа (которые тоже уже есть на диаграмме), одним словом - метод перетягивания "стрелочек" и никакого кода.

Еще один плюс в использовании Class Designer - это то, что видны все связи (ну если отображать некоторые поля как связь), а следовательно гораздо легче принимать некоторые решения. Ну например, был у меня интерфейс "факультет" со своими полями, а так же был интерфейс "кафедра" у которого тоже были свои поля, в том числе ссылка на "факультет", методов ни у одного интерфейса небыло. Увидев же связь, сразу становится понятно, что целесообразно в интерфейс "факультет" добавить метод создания кафедры на этом самом факультете. Может быть это кажется довольно тривиальным примером, но создавал бы я эти интерфейсы ручками в коде, то я бы и не подумал бы про их связь, а так же про то, что у факультета может быть метод создания кафедры на нем - по крайней мере заметил бы это не сразу. Кстати, через дизайнер можно вызвать и часть методов рефакторинга.
Ну, несмотря ни на что, нашлись и некоторые минусы в Class Designer. Например меня огорчил тот факт, что нельзя прямо из дизайнера указать то, что свойство должно быть только на чтение, а не на чтение и запись. Точнее сказать, дизайнер создает для свойства и get и set, а поправить это можно только в коде ручками. Так же довольно сложно указать от каких интерфейсов должен наследоваться конкретный класс (ну или другой интерфейс) - это можно сделать только если интерфейс отображен на самой диаграмме (а вот как добавить стандартный интерфейс на диаграмму? Ну я то на самом деле знаю один способ, но он извращенный).
К тому же, одним из самых больших минусов многие считают отсутствие поддержки Class Designer для C++, говорят она была в бете VS 2005, но ее в итоге исключили из финальной версии, т.к. не успели ее до конца оттестировать (от греха подальше другими словами). Но стоит сказать, что про данный минус я вычитал уже потом, а сам бы его никогда бы не обнаружил, т.к. уже давно полностью продался C# и про C++ вспоминаю только в страшном сне;) Ну и к тому же - в Visual Studio 2008, Class Designer теперь поддерживает и C++.
Так же не стоит забывать, что Visual Studio поддерживает плагины. В том числе мне довольно быстро удалось найти плагин который немного расширяет функциональность дизайнера (в 2005 студии), правда не совсем то, что мне было надо, да и некоторые методы вылетали (судя по трекеру - из-за того, что у меня стоит TestDriven. Странная связь, согласитесь).
Подытожим. Лично по мне, так Class Designer - это очень удобное средство на этапе проектирования, да и не только. Оно позволяет спроектировать систему не прибегая к непосредственному написанию кода. Да, это не вполне UML, но это явно его конкурент, по крайней мере для .NET.
P.S. Кстати говоря, в Visual Studio Team Suit for Architector есть еще ряд дизайнеров, с помощью которых можно конструировать другие схемы чем то аналогичные соответствующим схемам в UML (естесвенно плюс в том, что все это сразу же отражается на коде или еще чем то и синхронизируется с этим чем то), но, к сожалению, про это я пока только мельком читал, так что ничего не могу пока сказать;) Ну и на последок официальный блог Class Designer (жаль что он уже давно не обновляется).

Екатеринбург (фото)

Часть фотографий с последней поездки в Екатеринбург (буквально вот сегодня приехал):

2007_10_28

Лабиринты Ехо

И все таки от поездки в Екатеринбург была польза, по крайне мере для меня;) Теперь я счастливый обладатель всех книжек из серии "Лабиринты Ехо". Так сказать - чтиво на месяц обеспеченно!

А еще - стояли они в Екатеринбурге гораздо дешевле чем у нас (и даже дешевле чем заказывать по интернету)... Вот думаю, когда же у нас будут нормальные цены... да хотя бы нормальные книжные магазины:)

И куда делась романтика?

Дочитал вчера Лукьяненко - "Чистовик"... как то это произведение оставило во мне некоторые грустные отголоски. Наверное потому что я надеялся на другой конец, хотя и этот меня вполне устраивает (в том плане, что я не ждал того, что главный герой устроит всем кузькину мать, не в стиле Лукьяненко). Быть может потому что не получил ответы на вопросы, ну или неудовлетворен ими (а ну все быстро забыли про идею с миром номер ноль, которая мне, как программисту, очень понравилась... тем более теперь мы знаем про мир номер 16), а быть может потому что главный герой так и пробегал всю книжку от функционалов (вся история вообще напомнила чем то серию "Башня" у Стивина Кинга, хотя я читал только ее часть). Ну и самое главное, никакой романтики (а мне быть может ее сейчас очень не хватает...), а ведь сколько было поводов. Лично мне больше всего симпатизировала кузнец из Харькова... такая "могучая" женщина... и со "вторым высшим", и с "трудовой книжкой" (ну это поймут не все...) у нее было все в порядке (по крайней мере в моем представлении). Так нет, совсем наш Кирилл в этом плане неудачник, да и намека даже нет на то, что он помирится со своей бывшей подружкой, что было самой самой последней надеждой. Осталось только , наверное, порадоваться за Котю с Итан.

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

В общем, распрощался я с Кирилом и вернулся я к Максу... Максу Фраю, которого безобразно бросил читать ради "Чистовика" в начале главы "Жертвы обстоятельств". После недолгого возвращения внутри меня загорелась надежда - ну хоть тут у главного героя не все наперекосяк (я был наивен). Свидание наяву, а потом во сне - в этом как раз было что то романтичное:) И вот, только ей стоило появится у него под одеялом... как все тут же испортилось. Ну вот скажите мне, какая разница, что она через сон попала в его кровать, ей же вроде тоже этого хотелось... принуждают ее видете ли... Ну да ладно, остались надежды, помирятся и все такое, читаем дальше. Ага, и вот наш герой попал в "Квартал свиданий" (забавное местечко) и вот ему сама судьба указала на Меламори (вот вечно они так, как что, так сразу надо идти мстить с первым попавшимся... нашего то героя туда случайно занесло)... в общем, была у них веселая ночка (интересно как себя чуствовал в это время арестант), но последняя... суеверия и все такое, в общем после этого идея квартала свиданий мне разонравилась еще больше, а самое главное теперь никаких надежд. Даже не знаю кто больший неудачник, Максим или Кирилл (это который из Чистовика ;)).

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

Прием, прием, кто на связи?

Now playing: Patrick Wolf - Ghost Song

Как докричаться до человека, когда он находится в другой комнате, да еще за компьютером и в наушниках? Моя мама "изобрела" один способ - она просто звонит мне на сотовый, ну а ведь правильно - ножки то у нее болят. Причем если я не отвечаю (а это означает что мой телефон не рядом со мной), то она звонит на свой второй мобильный (который преднамеренно перед этим уже положен на компьютерный стол) - в этом случае я не смотрю на то, кто ей звонит, а просто иду искать в квартире маму (она ведь у меня "громадная" :D), что бы отдать ей телефон, когда же я, наконец то, нахожу ее, то понимаю что звонит она сама себе, лишь бы "вызвать" меня.

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

P.S. Так что, как говорит один мой знакомый, сотовый - это зло. С этой "высокотехнологичной" вещью в нашем современном мире уже не от кого не скрыться, а уж учитывая вечные нововведения сотовых операторов в борьбе за конкуренцию, теперь тебя достанут и при минусовом балансе (а как было раньше хорошо, отключил телефон а потом говоришь всем -ой, а у меня баланс кончился, теперь осталось все списывать только на батарейку). Ну и к тому же эти вечные 6секундные разговоры... из-за которых возникают милые недопонимания, вытекающие потом в большие казусы.

Самара (11 октября)

Давно что то не писал в свой блог, решил начать понемножку исправляться:)

Недавно был в Самаре, в том числе посетил "Дни разработчика 07" о которых, быть может, я расскажу чуть позже;) Пока же хочу просто показать вам некоторые фотографии, которые я успел там наснимать пока "гулял" по городу на следующий день после семинара:

Самара (11 октября)

Книга о смерти

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

Из Шведской национальной библиотеки

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

P.S. И ведь книжка якобы для детишек...

+++

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

Затем сходил ненадолго в больничку, на обратном пути прошелся по некоторым магазинам (у меня снова есть деньги на телефоне, а так же я купил еще какую то заумную книжку по программированию, так что у меня снова есть, что почитать... ну еще можно добавить, что у меня снова нет денег в кошельке ;) ).

Вернулся, наконец то, домой... Что то делал, в том числе включил компьютер, вышел в интернет и даже почитал новости:) Внезапно мне захотелось снова покушать дыню. Я встал, прошел на кухню, открыл холодильник и не обнаружил там дыню... Я точно помнил, что дыня еще оставалась... начались поиски. На столе ее не оказалось, во втором холодильнике тоже... в зале я ее тоже не нашел... в мусорном ведре было только две кожурки от кусочков дыни (отметил для себя, что все таки я ее съел не полностью...)... Думаю, да где же она... куда пропала... Рассказал о "трагедии" своему знакомому в асе, он сказал, что бы я особо не переживал, что скорее всего засунул ее куда нибудь не туда, вот как, например, я обычно делаю с чашкой воды по утрам, когда вместо микроволновки сую ее в холодильник... Стоп! И тут меня осенило, я быстро побежал на кухню, открыл микроволновку... и обнаружил в ней дыню...

P.S. Да, что путал холодильник с микроволновкой - такое было, что бы путал микроволновку с холодильником, такого до сегодняшнего дня еще небыло - все когда нибудь бывает в первый раз:)

Киноляпы в книжках?

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

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

P.S. Ну конечно же, это был всего один такой момент, а в целом... мне все таки понравилось:)

ваш вредный читатель