Помните, как в ночном дозоре Завулон играет в приставку с помощью сотового телефона? Ну точнее махает мечом путем махания сотовым телефоном... Так вот кто, оказывается, придумал Wii :)
пятница, 30 ноября 2007 г.
Still Alive
Наверное многие уже слышали эту песенку... Если, конечно играли в Portal :) В данном случае можно посмотреть на живое исполнение ;)
Еще хотелось бы сказать, что в Valve всегда делали довольно хорошие игры. Меня конечно немного тошнило во время игры в Portal, но сама история меня зацепила - особенно песенка в конце. Ну и конечно же, интересно было в свое время почитать про то, как создавалась эта игрушка, как внедрялись некоторые забавные элементы игры...
P.S. Хочу пирог... :)
понедельник, 19 ноября 2007 г.
Проектирование по контракту (бинарный поиск)
В свое время много вопросов вызвала дискуссия: надо ли проверять массив на упорядоченность (предусловие) при бинарном поиске. Надо? :)
Поразмышляю на эту тему ;)
Начну с того, что еще раз обращу внимание на то, что в теории никто не говорит о том, что в действительности надо делать с предусловием, постусловием и инвариантами. Они есть и все ;)
Теперь обратимся к разуму :) На сколько мне известно, бинарный поиск имеет сложность Q(log(n)) (по умолчанию у программистов логарифм двоичный ;), а вот проверка массива на упорядоченность, по всей видимости, Q(n) (по крайней мере я не знаю способа сделать это быстрее ;) Т.е. получается, что сама по себе проверка сводит на нет все преимущества бинарного поиска... К тому же, стоит сказать, что выигрыш в бинарном поиске обычно происходит при неоднократном обращении (имеется в виду, что если нам надо найти элемент в не упорядоченном массиве один раз, то лучше просто пройтись по нему, чем отсортировать его, а потом искать в нем бинарным поиском). При рассмотрении проблемы с этого ракурса, кажется логичным не включать проверку массива на упорядоченность в бинарный поиск ;)
Теперь стоит ответить на вопрос - что же тогда делать с наши предусловием? Оно же имеет место быть (по логике вещей). На самом деле, скорее всего это тот класс (имеется в виду не класс в программировании, а... социальный класс ;) предусловий, который может использовать в своей работе разработчик. Т.е. другими словами, у программиста есть метод бинарного поиска, который ему необходимо реализовать, причем при этом ему сказано - "не заморачивайся по поводу не упорядоченности элементов в массиве". Такие предусловия не должны попадать в код в виде непосредственных проверок. В принципе, можно сделать их автоматическое добавление в xml документацию ;)
Ну и напоследок, рассмотрим несколько примеров предусловий для бинарного поиска, которые можно было бы и включить в код.
Итак, начнем с упорядоченности элементов в массиве. Вроде мы можем быть абсолютно уверены в том, что элементы в массиве упорядочены, но не совсем ;) Ведь нам еще важно - в каком направлении они упорядочены :) Так что проверяем, что, первый элемент <= последнему. В принципе, от данной проверки можно отказаться, если написать такой бинарный поиск, который просто анализирует, в каком направлении отсортирован массив. Вторая проверка больше подойдет для Generic коллекций. Если я ничего не путаю, то, скорее всего, в алгоритме бинарного поиска придется что то сравнивать ;) А это означает, что элементы массива должны реализовывать интерфейс IComparable (ну если мы говорим про .NET ;).
Кстати говоря, наверное еще желательно, что бы все элементы были одного типа (точнее говоря приводились к типу, который мы ищем). Но это уже попахивает очередной проверкой всех элементов ;)
Ну вот на этом я, пожалуй, и закончу ;)
Теперь обратимся к разуму :) На сколько мне известно, бинарный поиск имеет сложность Q(log(n)) (по умолчанию у программистов логарифм двоичный ;), а вот проверка массива на упорядоченность, по всей видимости, Q(n) (по крайней мере я не знаю способа сделать это быстрее ;) Т.е. получается, что сама по себе проверка сводит на нет все преимущества бинарного поиска... К тому же, стоит сказать, что выигрыш в бинарном поиске обычно происходит при неоднократном обращении (имеется в виду, что если нам надо найти элемент в не упорядоченном массиве один раз, то лучше просто пройтись по нему, чем отсортировать его, а потом искать в нем бинарным поиском). При рассмотрении проблемы с этого ракурса, кажется логичным не включать проверку массива на упорядоченность в бинарный поиск ;)
Теперь стоит ответить на вопрос - что же тогда делать с наши предусловием? Оно же имеет место быть (по логике вещей). На самом деле, скорее всего это тот класс (имеется в виду не класс в программировании, а... социальный класс ;) предусловий, который может использовать в своей работе разработчик. Т.е. другими словами, у программиста есть метод бинарного поиска, который ему необходимо реализовать, причем при этом ему сказано - "не заморачивайся по поводу не упорядоченности элементов в массиве". Такие предусловия не должны попадать в код в виде непосредственных проверок. В принципе, можно сделать их автоматическое добавление в xml документацию ;)
Ну и напоследок, рассмотрим несколько примеров предусловий для бинарного поиска, которые можно было бы и включить в код.
Итак, начнем с упорядоченности элементов в массиве. Вроде мы можем быть абсолютно уверены в том, что элементы в массиве упорядочены, но не совсем ;) Ведь нам еще важно - в каком направлении они упорядочены :) Так что проверяем, что, первый элемент <= последнему. В принципе, от данной проверки можно отказаться, если написать такой бинарный поиск, который просто анализирует, в каком направлении отсортирован массив. Вторая проверка больше подойдет для Generic коллекций. Если я ничего не путаю, то, скорее всего, в алгоритме бинарного поиска придется что то сравнивать ;) А это означает, что элементы массива должны реализовывать интерфейс IComparable (ну если мы говорим про .NET ;).
Кстати говоря, наверное еще желательно, что бы все элементы были одного типа (точнее говоря приводились к типу, который мы ищем). Но это уже попахивает очередной проверкой всех элементов ;)
Ну вот на этом я, пожалуй, и закончу ;)
воскресенье, 18 ноября 2007 г.
Dot Net Books
Наткнулся тут на один сайт посвященный книжкам по .NET. Наполнение этого сайта меня просто поразило ;)
P.S. Особой внимание обратите на комментарий к первому посту :)
P.S. Особой внимание обратите на комментарий к первому посту :)
Проектирование по контракту - идеальный случай
Попробую написать коротенький такой пост про то, как бы по моему мнению идеально выглядело бы внедрение DBC в язык программирования, так сказать - мечты ;)
Допустим что у нас есть некий проект в котором есть классы с описанными инвариантами, пред и пост условиями. Ну и представим, что их описание довольно легкое, скажем так, нас в первую очередь сейчас должен волновать не способ их описания ;) Что теперь с этим описанием необходимо делать?
Ну можно делать, например, разного рода ворнинги. Например, есть метод у которого в предусловии у первого параметра стоит, что он должен быть больше нуля, а мы передаем туда переменную просто типа int. В таком случае необходимо добавить warning о том, что переменная может быть и меньше нуля. Ну или есть у нас еще некий класс у которого есть свойство для которого задано, что оно больше нуля и именно это свойство мы передаем в метод - в таком случае ворнинга быть не должно быть.
Под категорию таких же проверок может подойти так же, например, вызов метода из другого метода. Есть метод1, который внутри себя где то в середине вызывает метод2, передавая ему расчитанные в методе1 параметры. В зависимости от входных данных метода1 зависит передаваемый параметр в метод2, т.е. в зависимости от ограничений на входные данные метода1 зависит то, какой параметр мы можем передать в метод2. Анализируем ограничения на параметр в методе2 и, быть может, выдаем замечание о том, что ограничение на параметр в методе1 можно и усилить, т.к. при некоторых его значениях вызов метода2 будет некорректен.
Пусть у всех пред пост условий и инвариантов есть приоритет - в таком случае при компиляции можно указывать, какие проверки в итоге можно включать результирующий код, а какие нет. Это так сказать - игра с балансом производительности и безопасности.
Возможность автоматического тестирования на основе все тех же пред пост условий и инвариантах.
В общем говоря, 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. Честно говоря, уже забыл с чего я начал этот пост, и что именно хотел сказать в его начале... Наверное это пока что только начало рассуждений о том, что же на самом деле такое "проектирование по контракту". И, надеюсь, что вы поможете ответить мне на этот вопрос ;)
Начну, наверное издалека, а именно с вопроса - чем меня не удовлетворяют стандартные автоматизированные тесты на основе 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. Честно говоря, уже забыл с чего я начал этот пост, и что именно хотел сказать в его начале... Наверное это пока что только начало рассуждений о том, что же на самом деле такое "проектирование по контракту". И, надеюсь, что вы поможете ответить мне на этот вопрос ;)
суббота, 17 ноября 2007 г.
Проектирование по контракту (часть 1ая)
Now playing on iTunes: Fleur - Сегодня
В настоящее время я занимаюсь попыткой "внедрить" проектирование по контракту в .NET (на примере языка C#). Внедрить я взял в кавычки неспроста, дело в том, что под внедрить понимается не как непосредственное внедрение проектирования по контракту в синтаксис языка (ну или в саму среду .NET), больше имеется в виду внедрение идеи проектирования по контракту в сам процесс написания приложений на .NET. В связи с этим, хотел бы поделится некоторыми идеями и наблюдениями, но о всем по порядку...
В настоящее время я занимаюсь попыткой "внедрить" проектирование по контракту в .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. А пока можете комментировать - ваше мнение мне очень интересно ;)
Для чего вообще используется идея проектирования по контракту? В первую очередь для повышения надежности разрабатываемого продукта (приложения, кода, "черти что и с боку бантик" - для кого что ;). Естественно, что идея проектирования по контракту не на столько нова, а значит и для 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. А пока можете комментировать - ваше мнение мне очень интересно ;)
воскресенье, 11 ноября 2007 г.
На кого из героев „Футурамы“ ты похож?
Прошел от тут один милый тест - любителям Футурамы посвящается;) Что то в моем результате есть противоречивое... но мое, наверное)))))
Результат теста «На кого из героев „Футурамы“ ты похож»:
Если Вы желаете узнать больше о своем характере и о характере героев «Футурамы», то прочитайте статью «Псих-о-рама». | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
пятница, 2 ноября 2007 г.
Stylish
Сегодня я хотел бы поделиться с вами своей очередной находкой. Находка касается очередного расширения для Mozilla Firefox - Stylish.
А все началось с того, что сегодня мне окончательно надоело куча лишних рекламных (и не только) колонок на computerra (в результате сама статья становится до ужаса узкой). Обычные вырезалки нежелательного контента мне не подходили, т.к. они, конечно, что то вырезают, но не факт, что остальной контент после этого встанет на место вырезанного (т.е. займет освободившуюся часть)...
А все началось с того, что сегодня мне окончательно надоело куча лишних рекламных (и не только) колонок на computerra (в результате сама статья становится до ужаса узкой). Обычные вырезалки нежелательного контента мне не подходили, т.к. они, конечно, что то вырезают, но не факт, что остальной контент после этого встанет на место вырезанного (т.е. займет освободившуюся часть)...
Для начала (когда я еще не знал про Stylish) я решил просто проверить, на сколько можно изменить внешний вид computerra подручными средствами. Подручным средством оказался firebug (по моему скоро это расширение станет одним из моих самых любимых). С его помощью я довольно быстро разобрался, что мне надо отключать, какие стили править и т.д. Подытожив я понял что сия махинация возможна, осталось только все это автоматизировать.
Дальше начались долгие поиски. Через некоторое время я уже совсем отчаялся и решил, что изучу наконец - как же пишутся эти самые расширения для Firefox (я же все таки программист как ни как). Но, тем не менее лень меня победила (я же все таки программист как ни как) и закончилось все тем, что я нашел уже готовое расширение для Firefox :D Стоит сказать, что изучение устройства расширений лишним тоже не оказалось;)
Найденным расширением, как несложно догадаться, стало Stylish. После небольшого изучения я приступил к реализации, а именно выбрал создание нового стиля для cumputerra в котором для начала: скрыл верхний баннер, самую правую колонку (это там, где "сегодня в номере" и т.д., в общем, только место зря занимает), третью рекламную колонку а так же начало рекламы от бегуна (пока не придумал как убрать ее конец). В итоге получился следующий код:
Стоит сказать, что 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 он это должен был сделать.
Дальше начались долгие поиски. Через некоторое время я уже совсем отчаялся и решил, что изучу наконец - как же пишутся эти самые расширения для Firefox (я же все таки программист как ни как). Но, тем не менее лень меня победила (я же все таки программист как ни как) и закончилось все тем, что я нашел уже готовое расширение для Firefox :D Стоит сказать, что изучение устройства расширений лишним тоже не оказалось;)
Найденным расширением, как несложно догадаться, стало Stylish. После небольшого изучения я приступил к реализации, а именно выбрал создание нового стиля для cumputerra в котором для начала: скрыл верхний баннер, самую правую колонку (это там, где "сегодня в номере" и т.д., в общем, только место зря занимает), третью рекламную колонку а так же начало рекламы от бегуна (пока не придумал как убрать ее конец). В итоге получился следующий код:
@namespace url(http://www.w3.org/1999/xhtml);Теперь на странице не отображается ничего лишнего (ну лишнего для меня), но, тем не менее остается куча свободного места, которое можно заполнить основным конентом (ради которого я и посещаю этот сайт). А все дело в том, что в коде заданы жесткие размеры - ничего, сейчас поправим;). Для этого ставим ширину шапки и страницы в 100%, а не 770px, как было:
@-moz-document domain("www.computerra.ru") {
#tophban {display: none !important }
#terralab {display: none !important }
#skyright {display: none !important }
#begunRoot {display: none !important }
}
#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 он это должен был сделать.
Подписаться на:
Сообщения (Atom)