холодильник - тоже космос...

Мотивация

2012-02-04T21:54:00.000+02:00

Да, эта статья, именно, о мотивации. Нет, это неочередные «стопицот способовзамотивироваться». И не очередное тыканье пирамидойМаслоу (хотя с неё, наверное, стоило бы начать, ведь именно потребностиявляются основными двигателями). Все мы знаем свои потребности – именно тенедостающие детали мозаики наших поступков, объясняющие всё – и на нихостанавливаться не будем.

Есть цель,определяющаяся потребностями, есть дорога к цели, состоящая, например, изтасков в проекте или материалов к экзамену, и есть мотивация, которая изаставляет нас, двигатель, работать. Но порой двигатель глохнет. Вроде и дорогане ухабистая, вроде и ехать не далеко, а вот не едется. То ли бензинзакончился, то ли бак вообще не заправляли, то ли слил кто-то весь бензин.Бывало? У всех бывало. И не раз. Ведь слабая мотивация занимает третье место вперечне причин, препятствующих росту бизнеса*.

Причины отсутствия мотивации можно перечислять иперечислять. Но меня больше интересует момент, когда мотивации нет из-за цели.Когда цель уже не привлекательна. В какой-то момент непреступные доселе горныевершины превращаются в холмики, на которые уже просто скучно взбираться. Идаже, если на холмике тебя будет ожидать сундук с сокровищами, - всё равноскучно. В книге Э.Йордона «Путькамикадзе» есть хорошая цитат по этому поводу:

«Деньги, выгода, комфорт и тому подобноеявляются факторами «гигиены» – их отсутствие вызывает неудовлетворённость,однако они не могут заставить людей полюбить свою работу и дать им необходимыевнутренние стимулы. Что действительно может дать такие стимулы, так этоощущение значительности достигнутых результатов, гордость за хорошо выполненнуюработу, более высокая ответственность, продвижение по службе и профессиональныйрост – все то, что обогащает работу»

Джоел Спольски в своей книге «Джоэл о программировании» тожезатрагивает эту тему. Обсуждая такой способ мотивации, как поощрительные премиина основе оценок продуктивности, он всячески советует не использовать его. И онполностью прав, т.к. , наверно, каждый разработчик уверен, что работает хорошо,и его код, как минимум, достаточно хорош, если не идеален. И оценка, отличнаяот его самооценки, может вызвать обратный эффект – «зачем стараться, если всёравно меня никто не ценит?». Людей же, неуверенных в себе, плохая оценка вообщеможет убить. «Ну вот, ещё одно подтверждение, что я – никудышный программист»

Как же правильно мотивировать людей? Как правильно ихпоощрять за проделанную работу? Какое самое запоминающееся поощрение вы получали?

Для меня, например, большой наградой стала фраза: «Эй, мывтроем – два разработчика и один менеджер – за два года сделали то, что несмогла сделать команда из 6-ти людей за 2 с половиной года!», сказаннаяневзначай после сдачи проекта, который, казалось, никогда не закончится. Ну, и,конечно же, греют положительные отзывы пользователей J, осознание, что продукт,выпущенный в итоге, востребован, нужен людям, что время, потраченное наразработку окупается с торицей.

P.S. Авот пирамида Маслоу в свете потребностей разработчиков

* Поисследованию «Управление ростом иконкурентоспособностью российских компаний», проведенном Ассоциацией менеджерови консалтинговой компанией Accenture.

* FrederickHerzberg

Чужой код

2012-02-01T10:52:00.003+02:00

Over engineering

2012-01-30T11:09:00.001+02:00

Загадка: "На столе сидело три мухи. Я взял тапок и прибил им одну муху. Сколько мух осталось на столе?"
Официальная отгадка: одна (две других улетели).
Неофициальная отгадка умного человека:
"Если она не прилипла к тапку, то 3;
Если 2 улетели от страха, а одна прилипла к тапку - 0;
Если 2 бесстрашно остались сидеть, и одна не прилипла к тапку - 3;
Если 2 улетели, а одна не прилипла к тапку- 1;
Если 1 прилипла к тапку, а 2 бесстрышно остались сидеть - 2"
Вывод: умные люди даже в простых загадках всегда рассматривают проблему не поверхностно и проводят глубокий анализ ситуации:)"
Дополнение:
Также возможно, что одна муха улетает, другая бесстрашно сидит на столе, а третья прилипает/не прилипает к тапку.
Еще не рассмотрены варианты прилета новых мух, не зарегестрированных на столе в начальный момент времени.
Так же в условии задачи не говорится какую именно муху убили. Может быть случайно мимо пролетавшую, и эти три даже ничего не заметели (а трупик убитой мухи кстати мог упасть на стол).
Так же автор почему-то не рассматривает (что я нахожу крайне странным) возможность встречи стола с антистолом и их анигиляции. В этих условиях поиск решения становится довольно затруднительным.
bash.org.ru

Возвращение блудных шаблонов в VS

2012-01-25T11:41:00.000+02:00

Постигла такая беда: пропали все шаблоны создания новых файлов / проектов в Visual Studio.
Лечится так: в Visual Studio Comand Prompt запускаем команду devenv /installvstemplates.

Рейтинг языков программирования

2012-01-20T15:58:00.000+02:00

По ежегодному рейтингу языков программирования от компании TIOBE C# поднялся аж на три позиции вверх и занял третье место, догоняя Java, которая так же остается на первом месте (хотя, если взглянуть на график рейтингов за последние 10 лет, то видно, что она медленно, но уверено теряет). Интересно, что годовая дельта для Java оказалась отрицательной (-0.29%), несмотря на популярность ОС Android как платформы для мобильных приложений. На втором месте восседает С. Поднялся рейтинг и у Objectiv-C, что вполне естественно с ростом спроса на рынке разработки под айфоны и айпады. PHP сдал аж на две позиции. Но кто меня действительно удивил - так это Delphi/Object Pascal, который умудрился стать более популярным за последний год.

Размышления о качестве

2012-01-18T17:31:00.003+02:00

Читаю Э.Голдрат "Цель. Процесс непрерывного совершенствования". Долго откладывала эту книгу в сторону, но пришло и её время. Действительно, хорошая книга. Хоть и не it-тематики, но точки соприкосновения есть. Почитать эту книгу полезно всем, не только управленцам.

Если вы не производите качественный продукт, всё, что вы имеете в итоге - куча дорогостоящих ошибок.

Это далеко не новость. Но что такое качественный продукт? Первое, что приходит в голову, это программа без ошибок, т.е. тщательно оттестированный функционал, когда пользователь не переживает, что, ткнув не туда, можно завалить программу. Всю качественность функционала может затмить интерфейс, который не позволяет использовать продукт на все 100%. Т.е. интерфейс тоже должен быть качественным, продуманным, позволяя пользователю не тратить много времени на освоение. Это всё? Нет. Бек-сайд продукта - это код. И качественный код != код без багов. Качественный код - это совокупность характеристик, где одно из первых мест занимает качественная архитектура, позволяющая легко и безболезненно развивать продукт. Это тестируемость (testability) кода как подтверждение качества архитектуры.
И, конечно же, качественный продукт в состоянии выпустить только здоровая команда! (Однако обратное выражение не всегда верно) О влиянии отношений внутри команды на продукт была хорошая цитата тут

Здоровые отношения в группе разработки вносят непосредственный вклад в архитектуру системы. Нездоровые отношения и гипертрофированные самомнения порождают нездоровые продукты.

Качество продукта всегда коррелируется временем (сроками) и бюджетом (это внешние факторы) и профессионализмом команды (это внутренние факторы), и эти факторы очень тесно связаны. Бюджет прямо пропорционально влияет на профессионализм команды, а если ужать время, то даже профессионалы не смогут выдать качественный продукт. Тут вспоминается Ф.Брукс и его высказывание "9 женщин не родят ребёнка за 1 месяц" ("Мифический человеко-месяц"). А за то время, что команда новичков будет набираться опыта, продукт успеет устареть или надобность в нём отпадёт.
И напоследок - зачем вобще нужно это качество? Оно является одной из главных составляющих жизнеспособности - т.е. конкурентоспособности продукта, а значит, и успеха проекта.

Utilu IE Collection

2011-12-29T15:36:00.002+02:00

Думаю, что эта штука пригодится многим веб-разработчикам, знакомым со словом "кроссбраузерность": Utilu IE Collection - сборник всех поколений адового броузера Internet Explorer от MS. Сборник содержит версии IE:

Internet Explorer 1.0 (4.40.308)
Internet Explorer 1.5 (0.1.0.10)
Internet Explorer 2.01 (2.01.046)
Internet Explorer 3.0 (3.0.1152)
Internet Explorer 3.01 (3.01.2723)
Internet Explorer 3.03 (3.03.2925)
Internet Explorer 4.01 (4.72.3110.0)
Internet Explorer 5.01 (5.00.3314.2100)
Internet Explorer 5.5 (5.51.4807.2300)
Internet Explorer 6.0 (6.00.2800.1106)
Internet Explorer 6.0 (6.00.2900.2180)
Internet Explorer 7.0 (7.00.5730.13)
Internet Explorer 8.0 (8.00.6001.18702)

На сайте сборника есть даже таблица совместимости ОС и версий броузера. Ссылка для скачивания.

42

2011-12-26T12:59:00.003+02:00

Недавно довелось написать небольшую утилиту на Delphi. Да, это не опечатка :) Опустим события, ставшие причиной данного извращения, но, кажется, на меня снизошло озарение, ответ на вопрос жизни, Вселенной и вобще: почему не стало delphi-программистов? Так вот, они не выдержали психологической давки со стороны кода! Легко ли программировать, когда на тебя пялится код, всячески выражая своё пренебрежение?

Подкасты

2011-12-02T09:29:00.001+02:00

Накопилось еще немного ссылок на интересные подкасты.
http://distributedpodcast.com/ - интересный подкаст о CQRS
http://www.dotband.com - русскоязычный подкаст о дотнете.
http://www.thisdeveloperslife.com/ - англоязычный подкаст о разработчиках и их жизни
http://deepfriedbytes.com/podcast/
http://polymorphicpodcast.com/shows

Хитрый Delete для Sql Server CE

2011-11-23T15:25:00.001+02:00

Маленький хак для Sql Server CE, который компенсирует отсутствие возможности удаления записей из таблицы с помощью такой конструкции

DELETE FROM bookings LEFT OUTER JOIN accounts ON bookings.AccountID = accounts.ID WHERE accounts.AccountNumber="1100"

Вместо этого вы можете использовать конструкцию

DELETE FROM bookings WHERE AccountID NOT IN (SELECT ID FROM accounts WHERE accounts.AccountNumber<>"1100")

Webbrowser. Сохраняем картинку.

2011-11-16T14:48:00.001+02:00

Задача: сохранить из webbrowser генерируемую на лету (на основе данных post-запроса) картинку.
Решение:

Пошагово:
Сначала получаем картинку по её id. Потом получаем Dom-объект страницы и через него создаем HTMLControlRange-объект, который позволит нам выполнять операции над коллекцией объектов, которую он содержит. Объекты добавляются через метод add(), но нам гораздо более интересен метод execCommand(), который выполняет команды на текущем документе (в нашем варианте - объект doc), на выделенной области или на коллекции объектов. В нашем случае, команда будет выполнятся на коллекции объектов IHTMLControlElement, состоящей из одного объекта image.
После копирования нужной картинки в буффер обмена (строка execCommand("Copy", false, null)), извлекаем картинку из буффера и сохраняем на диск. Всё.
Если нужно сохранить все картинки на странице, а не одну, то коллекцию картинок получаем через
HTMLElementCollection imgCollection = web.Document.GetElementsByTagName("img");
и в цикле выполняем код после создания HTMLControlRange-объекта:
Как видите, всё просто. Главное - не забыть подключить сборку Microsoft.mshtml.dll (в Solution Explorer правой кнопкой по узлу References в нужном проекте -> Add reference):

Extensions, Static methods & null

2011-10-23T19:48:00.002+03:00

Методы расширения (extension methods), появившиеся ещё в C# 3.0, - очень полезная штука.

Методы расширения позволяют "добавлять" методы в существующие типы без создания нового производного типа, перекомпиляции или иного изменения исходного типа. Методы расширения являются особым видом статического метода, но они вызываются, как если бы они были методами экземпляра в расширенном типе. (из MSDN)

Т.е. если в классе String нам не хватает какого-нибудь метода, то не нужно создавать еще один класс, наследуясь от String или, чего хуже, делая декоратор, а можно создать метод расширения:

public static class MyExtensions
{
        public static int WordCount(this String str)
        {
            return str.Split(new char[] { ' ', '.', '?' }, 
                             StringSplitOptions.RemoveEmptyEntries).Length;
        }
 }

(пример тоже из MSDN)
Иногда бывает ситуация, когда нужно вызвать метод расширения в статическом методе класса. Но этого нельзя сделать, несмотря на то, что

Методы расширения являются особым видом статического метода, но они вызываются, как если бы они были методами экземпляра в расширенном типе. (из MSDN)

Но, если всё же очень надо, то есть пара приёмчиков :)

Например, у нас есть класс Document, и в статическом методе Open нам очень хотелось бы вызвать метод расширения Spell().

Как можно вызвать Spell()? Для начала можно создать новый документ и вызвать у него метод расширения, но это не спортивно, тем более проще будет вызвать метод ChangeText().
var text = default(IDocument).Spell(data);
что, в принципе, эквивалентно, следующему:
var text = (null as IDocument).Spell(data);
Что тут происходит? default для ссылочных типов данных - это null, а для value-типов - 0. Т.е. мы вызываем метод Spell() не на объекте, а на null? Почему же не случается Null Reference Exception? Чтобы понять, нужно просто взглянуть на реализацию метода расширения:

Объект document, на котором вызывается метод расширения, будет равен null, и пока мы не попытаемся использовать его без проверки на null, ничего страшного, не произойдёт.
Кстати, используя эту фичу, можно написать расширение для проверки объекта на null, чтобы заменить if (obj == null) ....

Пример использования:

Assert.True()

2011-10-21T18:25:00.001+03:00

Отсюда

Рефакторинг

2011-10-20T13:32:00.000+03:00

Сегодня наткнулась на такой вот метод:

Конечно, сразу заинтересовало, что делает VouchersSrv.GetCustomerAdressID():

Что же это получается? В цикле создается DataContext и делается чтение из таблицы _vouchers? Расточительно как минимум. Надо что-то с этим делать.

Во-первых, метод GetCustomerAdressID() будто бы прилеплен сбоку. Надо перенести его в другой класс. Сначала нужно посмотреть, где ещё используется это метод ( Shift-F12 в VisualStudio). Отлично, в одном месте. Теперь, чтобы не создавать датаконтекст каждый раз, нужно метод сделать обычным, а не статичным, и вынести DataContext как закрытый член класса. Получилось вот так:

Очевидна маленькая проблема - контекст создали, а где мы его уничтожим? Конечно, GC подчистит, но на случай форс-мажора лучше реализовать IDisposable:

Ну и вот, что получилось в вызывающем методе:

Ещё чуть-чуть о тестах

2011-10-18T12:36:00.000+03:00

И еще одна небольшая заметка о TDD, точнее о том, что такое тест в контексте TDD.
Начинающие тэдэдэшники часто переусердствуют, стараясь тестировать всё и вся, забывая, что тест в TDD - это небольшой метод, проверяющий конкретное бизнес-правило. Акцент тут следует сделать на бизнес-правилах, они специфицируют поведение приложения, именно их нужно тестировать. С помощью TDD мы разрабатываем бизнес-логику. Не следует тестировать работу с БД, с файловой системой, сетевое взаимодействие - это уже совсем другой вид тестирования. Это интеграционные тесты. TDD позволяет нам быстро разрабатывать бизнес-логику, подтверждая работоспособность (или наоборот) кода мгновенным фидбеком. Если приходится специально что-то настраивать, чтобы запустить тест, и настройка занимает больше времени, чем написание самого теста, следует насторожиться. Метод для теста должен быть черным ящиком: известно только, что на входе, нужно удостовериться в правильности того, что на выходе.
В реальной жизни часто бывает так, что нужно взять выборку из БД и подсунуть данные методу для выполнения сложных расчетов. Для тестирования таких методов придумали Mocks, Fackes, Dummies & Stubs. Все эти технологии позволяют абстрагироваться от уровня физического взаимодействия, генерируя методы-заглушки. А методы заглушки возвращают тот набор данных, который им подсовываем. Чтобы было понятнее, вот простенький пример с Mock-библиотекой Moq.
Например, нам нужно взять из БД данные о продажах и посчитать средние значения по дням и неделям. Как мы будем это делать?

[Fact]
public static shouldCalculateAvarageStatistic()
{
    var datasource = new Moq<IDataSource>();
    datasource.Setup(source=>source.GetMonthSales(

              new   Month(Monther.October)).Returns(
                   new List<Product>(){
                        new Product(){Price=12.50},

new Product(){Price=12.50},
new Product(){Price=25.0},

                        new Product(){Price=74}
                    });
     var counter = new Counter(datasource);
     var stats = counter.GetAvarageStats(new Month(Monther.October));
    Assert.Equal( 31.0, stats.ProfitPerWeek);
    Assert.Equal( 4.0, stats.ProfitPerDay);
}

Класс, который получился в итоге:

class Counter

 {
    IDataSource datasource; 
    public Counter(IDataSource _datasource)
    {
          datasource = _datasource;
     }
    public IStatistic GetAvarageStats(Month month)
    {
         var data = datasource.GetMonthSales(month); 
         var avarage_per_day = data.Sum(product=>product.Price) / month.Days;
         var avarage_per_week = data.Sum(product=>product.Price) / month.Weeks;
         return new AvarageStatistics(avarage_per_week, avarage_per_day);
    }
}

to ORM or not to ORM?

2011-10-16T19:16:00.000+03:00

Плюсы и минусы ORM обсуждались не раз. Скорость vs удобство (отсутствие чистого SQL в коде), возможность тонкой настройки запросов для узких мест vs машинная генерация запросов (порой не оптимизированных)... Да и вобще, кому нужны эти лишние прослойки?
Почему стоит отказаться от ORM рассказывает Rob Conery в своём докладе "Kill Your ORM" на NDC 2011 , где, кстати, было очень много интересных докладов.

Максим Цепков. Domain Driven Design - модель вместо требований

2011-10-11T11:11:00.000+03:00

Выступление Максима Цепкова на Летнем Аналитическом Фестивале - 2011. Иваново, 25 июня 2011 года.

Запахи TDD

2011-10-08T15:44:00.000+03:00

Перевод статьи "TDD Process Smells "

Данный список запаховболее сфокусирован на выполнении принципов самого TDD процесса, чем на содержимом тестов. Без сомнения, существует множество подобных запахов; я же выбрал наиболее часто встречающиеся по правилу 7 (+/- 2).

Покрытие кода тестами как цель. Если вы придерживаетесь принципов TDD, то должны получать практически 100% покрытие нового кода тестами даже без использования специальных инструментов для проверки. Существующий код - это другая история. Как получаются системы с низким процентом покрытия тестами? Если начать гнаться за покрытием кода тестами, можно только ухудшить ситуацию: увеличение числа тестов за счет их качества; тесты падают при внесение изменений в систему; часть тестов остаётся поломанными, сводя к нулю смысл самого тестирования.
Отсутствие зелёной полосы в течении ~10 минут. Размер теста - это одно из наиболее общих заблуждений в TDD. Цель теста - двигаясь маленькими шагами вперёд получать мгновенный фидбэк. Если в среднем цикл разработки теста занимает больше 10 минут, то вы не совсем понимаете, что значит итеративное наращивание функционала. Если вы пишите тест уже 10 минут, остановитесь, вернитесь к последней зеленой полоске и начните двигаться вперёд более мелкими шагами.
Создание сразу рабочих тестов. В TDD отрицательный фидбек означает, что ваши предположения верны. Написать рабочий тест - лучший способ потратить время зря. Много раз я сталкивался с тем, что разработчик сразу писал рабочий тест, но его код оставался полон багов.
Недостаточный рефакторинг. Если вы тратите пять минут на написание продакшн-кода, то вы должны потратить еще несколько минут на рефакторинг. Даже если кажется, что всё идеально, посмотрите вокруг - воспользуйтесь шансом отрефакторить код.
Пропуск чего-то слишком лёгкого (или сложного) для тестирования. "Это обычный геттер, ничего страшного" или "Это ну очень сложный алгорит, понятия не имею, как его тестировать, лучше пропустить этот кусок." Простота часто скрывает под собой проблемы: может, это не такой уж и обычный геттер, а ошибка в реализации ленивой инициализации? В сложных участках кода чаще всего и находятся проблемы. Какой смысл тестировать только те вещи, которые легко тестируются? Внесение изменений наиболее дорого обходится в сложных участках системы, тесты же нужны для того, чтобы сделать разрабатываемую систему стабильной и уменьшить затраты на сопровождение.
Тестирование методов, а не поведения. Это распространённая проблема начинающих тэдэдэшников. Они пишут тест testForSomeMethod, внутри которого создают контекст и что-то ассертят. Позже они добавляют в этот же тест вызов someMethod() с разными входными данными и добавят в комментарий новые детали. Кроме того, что это может привести к ненужным зависимостям, такой подход усложняет понимание смысла теста и дальнейшее сопровождение.
Написание тестов после кода! По определению, это уже не TDD. Но начинающие тэдэдэшники по старой привычке часто пишут код без написания неработающего теста. Почитайте "Why TAD Sucks" (TAD = Test-After Development) , чтобы найти для себя несколько причин начинать с написания неработающего теста.

Linq DataContext и Dispose

2011-10-07T14:40:00.001+03:00

Как известно, любой DataContext объект является IDisposable. При использовании конструкции вида
using (CDataContext db = new CDataContext(ConnectionPool.Connection)) {...}
метод Dispose() вызывается автоматически, и все занимаемые ресурсы освобождаются.
Насколько критично вызывать метод Dispose() вручную для такого кода?

CDataContext db = new CDataContext(ConnectionPool.Connection);
 return (from tbl in db._addresses
        where tbl.IsCustomer.Equals(true)
        select tbl).ToList();

Перефразируя вопрос: что плохого случится, если не вызвать Dispose()? Ведь GC всё равно вызовет этот метод, разве что не сразу. DataContext не держит соединение c БД открытым (только, если не открывать его явным способом вроде DataContext.Connection.Open() ) т.е. никаких тяжеловесных ресурсов не занимает, и ничего плохого не происходит. Т.е. совсем не обязательно вручную вызывать Dispose().
Но. Если вы напишите такой код
using(CDataContext db = new CDataContext(ConnectionPool.Connection))

{
   return (from tbl in db._addresses
            where tbl.IsCustomer.Equals(true)
            select tbl);

}
произойдёт исключение "Cannot access a disposed object. Object name: 'DataContext accessed after Dispose.", потому что дерево запроса (возвращаемый тип IQueryable<_address>) попытается выполнится после того, как DataContext будет уничтожен. Произойдёт это потому, что запрос выполнится тогда, когда будет впервые вызвано перечисление элементов (метод ToList<T>(), например). Если же написать такой код

CDataContext db = new CDataContext(ConnectionPool.Connection)
 return (from tbl in db._addresses
        where tbl.IsCustomer.Equals(true)
        select tbl);

то нужно понимать, что DataContext откроет соединение к базе, извлечет элементы и будет уничтожен только в том месте кода, где произойдет IQueryable<_address>.ToIEnumerable<_address>()

Чего нет в SQL Server Compact 4.0

2011-10-04T10:42:00.000+03:00

А нет в 4-ом компакте целой кучи всего:

Репликация данных с SQL Server - ни через Sync Framework, ни через слияние или удаленный доступ к данным.
Нет поддержки службы SQL Server 2008 Integration Services (SSIS)
SQL Server Management Studio для Sql Server Compact 4 тоже не поддерживается
О мобильных платформах (Windows Mobile, Windows Phone или Windows CE) тоже можно забыть.
Не поддерживается LINQ to SQL (чего стоило, но не хотелось, ожидать). Все дружно переходим на Entity Framework.

Но всё это поддерживается в SQL Server Compact 3.5 SP2.
Т.е. для того, чтобы перевести существующий проект (SQL CE 3.5 + Linq2Sql) на использование Sql Server CE 4.0, нужно заодно переехать на Entity Framwork либо другую ORM-прослойку. Стоит ли оно того, вот в чем вопрос.

Выучить С++ за 21 день

2011-09-30T18:30:00.001+03:00

Выучить С++ за 21 день

8 советов

2011-09-30T12:26:00.000+03:00

Сегодня попались мне две статьи о том, как улучшить свой код. В сумме это дало 8 советов.

В первой статье ( One of the Best Bits of Programming Advice I ever Got ) - всего один совет, и звучит он так "Не создавайте объекты, название которых заканчивается на -er"*. Чем же автору не нравятся все Loader'ы, Manager'ы, Builder'ы...? "В классическом (структурном) программировании, - говорит автор, - мы концентрируемся на поведении (глагол), а потом смотрим, какие данные (существительное) нужны для выполнения работы т.е. мы привязываем данные к поведению." В ООП наоборот: мы ставим на первое место данные (существительные), а потом смотрим, как они должны себя вести (добавляем поведение (глагол)).
Что же дает переименование объектов с именами на "-er"? Более инкапсулированная структура, меньше спагетти-кода и более выраженная объекно-ориентированность. Такой простой совет даёт столько бенефитов.
Вторая статья содержит целых семь советов (7 Crazy Tips That Will Help You Become a Better Coder), но их с трудом можно назвать адекватными.
1. Напишите свой фреймворк (читай: изобретите велосипед) - автор говорит, что искусство программирования превратилось в копи-паст, аргументируя это тем, что даже Гугл решил использовать готовый фреймворк JQuery, а не написать свой собственный. Да уж, давайте каждый раз писать новые фреймворки, и как далеко мы удём, каждый раз изучая новую систему для написания какого-нибудь маленького скрипта?
2. Не используйте инструменты разработчиков (читай: вернитесь в каменный век)
3. Не используйте браузер (что-то невнятное)
4. Не используйте кодогенераторы (чем-то перекликается с п.2) - тут есть доля здравого смысла, т.к. код, порождаемый генераторами не оптимален. Но! Пусть попробует вручную создать DataContext mapping БД на 20-30 таблиц, тогда и поговорим :)
5. Примеры из книг печатать, а не копипастить
6. Используйте "ванильный" текстовый редактор (читай: вернитесь в каменный век) - читая такое, кажется, что автор только с html и css работал.
7. Изобретите колесо (no comments) - понятно, что колесо изобретать полезно для понимания принципов его работы (сомнительно).
Все мы учимся на своих и, порой, чужих ошибках. Но советы автора призывают проходить путь от обезьяны до человека, изобретая на ходу тонны велосипедов. Зачем? Может, новичкам и полезно перепечатывать примеры из книг, но для более быстрого продвижения в освоении языка использовать "ванильный" редактор без интелсенс и подсветки синтаксиса - это просто кощунство и пустая трата времени.
____________
*тут речь об отглагольных существительных

Moq: ошибка номер раз

2011-09-29T15:13:00.000+03:00

Дабы не получить ошибку "Invalid setup on a non-virtual (overridable in VB) member" при работе с библиотекой Moq, мокать нужно либо интерфейс класса:

var mock = new Mock<IEventsStorage>(); //этот подход является рекомендуемым

либо мокаемый метод нужно объявлять виртуальным:

var mock = new Mock<EventsStorage>();
mock.Setup(storage => storage.LoadEvents(Monthes.Januar)).Returns(new List<Event>());

...

public class EventsStorage
{
    public virtual List<Event> LoadEvents(Monthes monthNumber) {...}
}

20 аддонов для VS

2011-09-29T10:21:00.001+03:00

Пройдя по ссылке вы сможете найти 20 бесплатных аддонов для Visual Studio, помогающих ускорить разработку и избавить вас от некоторых рутинных действий.
http://msdn.microsoft.com/ru-ru/vstudio/hh162051

Библиотека

2011-08-18T09:42:00.000+03:00

Steve Freeman, Nat Pryce. Growing Object-Oriented Software, Guided by Tests (скачать)
Test-Driven Development (TDD) is now an established technique for delivering better software faster. TDD is based on a simple idea: write tests for your code before you write the code itself. However, this "simple" idea takes skill and judgment to do well. Now there's a practical guide to TDD that takes you beyond the basic concepts. Drawing on a decade of experience building real-world systems, two TDD pioneers show how to let tests guide your development and “grow” software that is coherent, reliable, and maintainable.
Steve Freeman and Nat Pryce describe the processes they use, the design principles they strive to achieve, and some of the tools that help them get the job done. Through an extended worked example, you’ll learn how TDD works at multiple levels, using tests to drive the features and the object-oriented structure of the code, and using Mock Objects to discover and then describe relationships between objects. Along the way, the book systematically addresses challenges that development teams encounter with TDD—from integrating TDD into your processes to testing your most difficult features.

Coverage includes

Implementing TDD effectively: getting started, and maintaining your momentum throughout the project
Creating cleaner, more expressive, more sustainable code
Using tests to stay relentlessly focused on sustaining quality
Understanding how TDD, Mock Objects, and Object-Oriented Design come together in the context of a real software development project
Using Mock Objects to guide object-oriented designs
Succeeding where TDD is difficult: managing complex test data, and testing persistence and concurrency

Библиотека

2011-08-18T09:36:00.000+03:00

Фридман А.Л. - Основы объектно-ориентированной разработки программных систем. (скачать)
Книга написана как учебное пособие для студентов старших курсов. В ней рассматриваются основные понятия объектно-ориентированного программирования, методы анализа задач и проектирования программных систем на его основе. Исследуются современные способы организации процесса создания программного обеспечения и их взаимосвязь с методами анализа проектирования систем, прежде всего на основе подхода "проектирование по образцам".

Тимоти Бадд - Объектно-ориентированное программирование в действии (скачать)
Второе американское издание книги известного специалиста по объектно - ориентированному программированию выпускается на русском языке по лицензии издательства Addison Wesley Longman. В ней рассматриваются теоретические и практические аспекты ООП (как на уровне разработки программ, так и на уровне работы компиляторов), позволяющие с наименьшими затратами получать современные программы со сложной логической структурой. Автор обобщает опыт объектно - ориентированного программирования на примерах таких языков, как Java, C++, Object Pascal и др. Соответствующий круг вопросов весьма актуален, поскольку в практике современного программирования приходится иметь дело со все более сложными логическими и программными объектами. Рассмотрение теоретических вопросов настраницах книги удачно сочетается с многочисленными наглядными примерами. Для понимания материала достаточно владения каким - либо традиционным языком программирования типа С или Pascal, хотя в отдельных случаях (особенно в последней четверти книги) могут оказаться желательны (но не необходимы) и более глубокие знания. Книга будет полезна преподавателям, студентам, разработчикам прикладных программ и всем, кто хочет освоить современные подходы к программированию.

Библиотека

2011-08-18T09:25:00.000+03:00

Мартин Р. Чистый код. Создание, анализ и рефакторинг (скачать)
Эта книга посвящена хорошему программированию. Она полна реальных примеров кода. Мы будем рассматривать код с различных направлений: сверху вниз, снизу вверх и даже изнутри. Прочитав книгу, вы узнаете много нового о коде. Более того, вы научитесь отличать хороший код от плохого. Вы узнаете, как писать хороший код и как преобразовать плохой код в хороший.
Книга состоит из трех частей. В первой части излагаются принципы, паттерны и приемы написания чистого кода; приводится большой объем примеров кода. Вторая часть состоит из практических сценариев нарастающей сложности. Каждый сценарий представляет собой упражнение по чистке кода или преобразованию проблемного кода в код с меньшим количеством проблем. Третья часть книги — концентрированное выражение ее сути. Она состоит из одной главы с перечнем эвристических правил и «запахов кода», собранных во время анализа. Эта часть представляет собой базу знаний, описывающую наш путь мышления в процессе чтения, написания и чистки кода

Статические методы и методы экземпляра: кто быстрее

2011-08-09T13:18:00.000+03:00

Для некоторых методов класса Microsoft Code Analysis даёт такой совет:

CA1822 : Microsoft.Performance : The 'this' parameter (or 'Me' in Visual Basic) is never used. Mark the member as static (or Shared in Visual Basic) or use 'this'/'Me' in the method body or at least one property accessor, if appropriate.

В MSDN по этому поводу написано:

«Members that do not access instance data or call instance methods can be marked as static (Shared in Visual Basic). After you mark the methods as static, the compiler will emit non-virtual call sites to these members. Emitting non-virtual call sites will prevent a check at runtime for each call that ensures that the current object pointer is non-null. This can result in a measurable performance gain for performance-sensitive code. In some cases, the failure to access the current object instance represents a correctness issue.»

Какие преимущества у static метода перед методом экземпляра? При каждом вызове метода экземпляра происходит проверка указателя на null. Для статических методов такого не делается, что даёт небольшой прирост производительности. Кроме того, согласно MSDN, для всех объектов класса будет существовать только один экземпляр метода, что так же увеличит производительность.

Аспектно-ориентированное программирование

2011-07-13T17:23:00.002+03:00

Что же такое аспектно-ориентированное программирование? Ещё одна модная тенденция в мире разработки? Вики дает такое определение:

Аспе́ктно-ориенти́рованное программи́рование (АОП) — парадигма программирования, основанная на идее разделения функциональности для улучшения разбиения программы на модули.

Как-то знакомо звучит.
Ведь и другие парадигмы программирования поощряют разбиение функционала программы на модули, а также есть методологии, призванные помочь решить данную проблему - инверсия управления, например. Вот тут и проявляются главные отличия. АОП заботится о выделении сквозной функциональности (аспектов). Сквозная функциональность - это раскиданный по коду функционал, который невозможно декомпозировать ни процедурными, ни объектно-оринетированными- средствами, например, логирование, проверка прав доступа., обработка ошибок. ООП позволяет проектировать программы в терминах объектов, каким-то образом связанных друг с другом. Случается так, что между объектами возникает слишком большая связанность (обычно при программировании на конкретные классы, а не на интерфейсы). С одной стороны, тут может иметь дело ошибка проектирования, с другой - программирования. И тут приходит на помощь методология IoC и программирование по контракту (программирование на интерфейс, а не на конкретный класс). IoC призвана уменьшить связанность, разорвать жесткие зависимости между классами, сделав возможным разбиение кода на отдельные модули.

Итак, у нас есть аспекты и объекты. Объекты - это маленькие целостные подсистемы одной большой декомпозированной системы. Например, объект "колесо" в системе "машина" или "выключатель" в системе "лампа". Аспект будет подсистемой, включающей в себя служебный (т.е. не влияющий на поведение объектов) функционал. Например, логирование события, когда была включена/выключена лампа. Такой функционал никаким IoC не локализировать.

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

Почитать:
Аспектно-ориентированное программирование
Использование АОП

C# Finalize/Dispose pattern

2011-07-13T09:58:00.000+03:00

Два интересных обсуждения о Finalize/Dispose в C# на StackOverflow (http://stackoverflow.com/questions/898828/c-finalize-dispose-pattern/898867#898867) и Хабре (http://habrahabr.ru/blogs/net/122639/)

Боян про отладку

2011-07-08T21:54:00.000+03:00

Злободневно с баша

2011-06-15T15:08:00.002+03:00

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

YYY: Причем из этих двух молотков, один был бы самодельной киянкой!

XXX: Точно. А еще кто-нибудь заявил бы, что все ламеры, а вместо гвоздя нужно использовать шуруп.

YYY: И предложил бы свой вариант самореза с правой резьбой под шестигранную отвертку с логотипом Sun…

XXX: А потом кто-нибудь прийдет и скажет, что посадил все на суперклей и вроде стоит.

YYY: А кто то будет причитать про то, что раньше вообще без гвоздей строили и стояло века…

Сравнительное тестирование производительности платформ .Net, Java и Mono

2011-06-08T14:34:00.000+03:00

Статья на хабре о сравнении производительности платформ .Net, Java и Mono
http://habrahabr.ru/blogs/development/120090/

RegexOptions

2011-05-25T13:02:00.003+03:00

Есть файл с содержимым вида


<Book>
      <Page number='1'><![CDATA[line1
                                line2
                                line3]]>
      </Page>
      <Page number='2'><![CDATA[line1]]>

   </Page>
</Book>

Нужно распарсить содержимое через RegExpr. Вроде ничего сложного. Тест для класса PageParser должен срабатывать:


//PageParser
class PagePaerser
{
  public static IList<Page> Parse(string xml)
  {
     IList<Page> pages = new List<Page>();
     string pattern = "<Page number='(?<number>\\d*?)'><\\!\\[CDATA\\[(?<content>.*?)\\]\\]><\\/Page>";
     var matches = Regex.Matches(xml, pattern, RegexOptions.IgnoreCase | RegexOptions.Multiline);
     if (matches.Count>0)
     {                
        foreach(Match match in matches)
        {                    
            pages.Add(new Page()
            {
                    content = match.Groups["content"].Captures[0].Value,
                    number = int.Parse(match.Groups["number"].Captures[0].Value)
           });                    
        }
    }
    return pages;
  }
}


[TestMethod]
public void ParseMethod_ListOfPages_Test()
{
        var parsed_pages = PageParser.Parse(@"

<Book>
        <Page number='1'><![CDATA[line1
                                  line2
                                  line3]]>
         </Page>
        <Page number='2'><![CDATA[line1]]>

      </Page>
   </Book>

");
        Assert.AreEqual(2, parsed_pages.Count);
}

Но тест не срабатывает. Дело в том, что в RegExpr для обработки multiline-строк, нужно вместо флага RegexOptions.Multiline устанавливать RegexOptions.Singleline, который меняет режим символа "." на улавливание совпадений со всеми символами, а не всех символов, кроме новой строки (\n)

Coding drunk

2011-05-24T23:11:00.000+03:00

Объектные NoSql базы для .Net

2011-05-18T21:52:00.000+03:00

Небольшой обзор объектных БД под .Net. В обзор попали Eloquera, STSdb, Siaqodb, Ninja Database Lite.
Ссылка

dotPeek - бесплатный декомпилятор от JetBrains

2011-05-17T13:53:00.000+03:00

На замену .NetReflector, который стал платным, компания JetBrains выпустила свой бесплатный декомпилятор dotPeek, который умеет
- декомпилировать сборки .Net всех версий (1-4) в C#
- делать навигацию по коду (такую же как и в ReSharper) и понимает клавиатурные шорткаты, аналогичные ReSharper’у
- делать подсветку синтаксиса, фолдинг, и в целом предоставлять experience, аналогичный Visual Studio

Детальный обзор dotPeek
Скачать dotPeek

Random numbers generator

2011-04-28T13:00:00.002+03:00

Crack.Net 2.0

2011-04-12T15:12:00.001+03:00

Crack.Net - freeware runtime debugger для .net-приложений. Позволяет анализировать память, просматривать Debug output, интегрирован с Red Gate’s .NET Reflector. и, что самое вкусное, позволяет работать с объектами и событиями с помощью скриптов на IronPython (для этого нужно добавить IronPython.dll и IronMath.dll в GAC). Мощная штука. Работает под .net framework 3.5 + sp1. Сайт проекта - http://joshsmithonwpf.wordpress.com/cracknet/

Конфигурируем Unity 2.0 через xml-файл

2011-04-11T23:57:00.002+03:00

Цель данной заметки - рассмотреть простой случай конфигурации Unity через xml-файл.
Формат конфигурации Unity и более подробная информация касательно каждой секции тут http://msdn.microsoft.com/en-us/library/ff650027.aspx#config_format

И так, если вы не хотите прописывать все зависимости в коде, как это делается, например, тут (http://sly-and-fluffy.blogspot.com/2011/03/setter-injection-with-unity-20.html), то велкам. Сначала рассмотрим простейший случай. У нас есть интерфейс и три класса, его реализующих:


public interface IPosition
    {
        string Position { get; }        
    }

    public class JustEmployee : IPosition
    {
        public string Position { get { return "Just employee"; } }         
    }

    public class Manager : IPosition
    {
        public string Position { get { return "Manager"; } }        
    }

    public class Boss : IPosition
    {
        public string Position { get { return "Boss"; } }        
    }

Теперь конфигурируем Unity таким образом:


var map = new ExeConfigurationFileMap { ExeConfigFilename = "Unity.config" };
var config = ConfigurationManager.OpenMappedExeConfiguration(map, ConfigurationUserLevel.None);
var section = (UnityConfigurationSection)config.GetSection("unity");
var container = new UnityContainer();            
section.Containers.Default.Configure(container);

И код, использующий IPosition:


List<IPosition> positions = new List<IPosition>();
positions.Add( container.Resolve<IPosition>() );
positions.Add(container.Resolve<IPosition>("Manager"));
positions.Add(container.Resolve<IPosition>("Boss"));            
foreach (var position in positions)
{
Console.WriteLine("Position: " + position.Position);
}

И результат:

Что же такого волшебного находится в файле Unity.config? Вот полный текст:


<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<section name="unity" type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection, Microsoft.Practices.Unity.Configuration" />
</configSections>
<unity xmlns="http://schemas.microsoft.com/practices/2010/unity">
<namespace name="UnityTest" />
<assembly name="UnityTest1" />
<alias alias="IPosition" type="UnityTest.IPosition" />
<alias alias="JustEmployee" type="UnityTest.JustEmployee" />
<alias alias ="Manager" type ="UnityTest.Manager"/>
<alias alias ="Boss" type ="UnityTest.Boss"/>
<container>        
<register type="IPosition" mapTo="JustEmployee" />
<register name ="Manager" type ="IPosition" mapTo ="Manager" />
<register name ="Boss" type ="IPosition" mapTo ="Boss" />
</container>    
</unity>
</configuration>

А теперь обо всём по порядку.
В теге "section" указывается название тега, в котором находится весь конфиг. В данном случае это "unity". В теге "unity" мы указываем namespace, assembly и aliasы для типов данных. Вроде очевидные вещи, но обратите внимание, что в namespace указываем пространство имён (UnityTest), а в assembly (UnityTest1) - имя сборки. Если не указывать два этих тега, то в alias для в атрибуте type обязательно нужно указывать имя сборки:


<alias alias="IPosition" type="UnityTest.IPosition, UnityTest1" />

Алиасы нужны для удобства, указывать их тоже не обязательно; если их не указывать, то нужно указывать полное имя типа в тегах "register", которые соответствуют методу Register<TypeTType1, TType2>().
Вот и все для начала. В следующем посте рассмотрим конфигурирование через xml injections.

Велосипедность

2011-04-09T10:01:00.003+03:00

MonoDroid?

2011-04-07T21:08:00.000+03:00

Вышел MonoDroid 1.0. Вещь для тех, кто хочет писать под Андроид, не слазя с .Net. Этот релиз богат следующим:
- разработка на .Net и C# для Android-планшетов и смартфонов
- .NET-биндинги для Android API
- публикация приложений в Android Market
- интеграция с Visual Studio 2010
- Mono 2.10
Удручает не бесплатность MonoDroid.
Больше о релизе - http://tirania.org/blog/archive/2011/Apr-06.html

Setter injection with Unity 2.0

2011-03-25T23:14:00.003+02:00

Пример Setter injection на Unity 2.0 (продолжая тему этого примера)

Имеется интерфей IEmployee и класс Employee, его реализующий:


interface IEmployee
{
int Age { get; set; }
string Name { get; set; }
string Surname { get; set; }
IPosition position { get; set; }
string GetPosition();        
}
class Employee : IEmployee
{        
#region IPerson Members

public int Age

{ get; set; }

 
public string Name

{ get; set; }

 
public string Surname

{ get; set; }

 
public IPosition position { get; set; }

public String GetPosition()
{
  return position.Position;
}
#endregion
}

А так же есть интерфейс IPosition и набор классов, его реализующих:


public interface IPosition
    {
        string Position { get; }        
    }

    public class JustEmployee : IPosition
    {
        public string Position { get { return "Just employee"; } }         
    }

    public class Manager : IPosition
    {
        public string Position { get { return "Manager"; } }        
    }

    public class Boss : IPosition
    {
        public string Position { get { return "Boss"; } }        
    }

Класс Employee имеет поле property, которое мы и будем инжектить:

>
static void Main(string[] args)
{            
IUnityContainer unity = new UnityContainer();
unity.RegisterType<IPosition, JustEmployee>()
.RegisterType<IPosition, Manager>("Manager")
.RegisterType<IPosition, Boss>("Boss")
.RegisterType<IEmployee,Employee>( new InjectionProperty("position",  new ResolvedParameter<IPosition>()))
.RegisterType<IEmployee, Employee>("Boss", new InjectionProperty("position",  new ResolvedParameter<IPosition>("Boss")))
.RegisterType<IEmployee, Employee>("Manager", new InjectionProperty("position",  new ResolvedParameter<IPosition>("Manager")));

List<iemployee> employees = new List<IEmployee>();            
var emp = unity.Resolve<IEmployee>();
emp.Name = "John";
emp.Surname = "Malkovich";
emp.Age = 35;
employees.Add(emp);
var manager = unity.Resolve<IEmployee>("Manager");
manager.Age = 44;
manager.Name = "Peter";
manager.Surname = "Branch";
employees.Add(manager);
var boss = unity.Resolve<IEmployee>("Boss");
boss.Name = "Bill";
boss.Surname = "Millioner";
boss.Age = 99;
employees.Add(boss);                        
foreach(var employee in employees)
{
Console.WriteLine("Person: " + employee.Name + " " + employee.Surname + ", " + employee.Age + ", " + employee.GetPosition());
}
}

Запускаем, смотрим результат:

Пакеры для .NET exe, dll

2011-03-25T18:35:00.001+02:00

Программы, позволяющие сделать из exe и кучи приблудившихся dll один exe модуль:

Стандартная от MS - ILMerge - http://www.microsoft.com/downloads/en/details.aspx?FamilyID=22914587-b4ad-4eae-87cf-b14ae6a939b0&displaylang=en

NETZ - http://madebits.com/netz/index.php

Molebox - http://www.molebox.com/

Nbox - http://nbox.codeplex.com/

Рефакторинг - не панацея

2011-03-25T18:31:00.000+02:00

Недавно мне попалась фраза

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

А так ли это? Попахивает фанатизмом.

Насколько б рефакторинг не был полезной техникой, нужно понимать, что рефакторинг - это не панацея. Сколько не переименовывай названия методов и переменных, если архитектура кода из разряда "а всё, что плохо держится, мы подопрем деревянными распорками" (из байки "Если б программисты строили дома"), то лучше она от этого не станет. Проектирование ПО плюс постоянный рефакторинг при написании кода – это сильная связка. Плохо спроектированную систему будет трудно рефакторить – есть где разгуляться, да понять бы, за что сначала взяться - рефакторинг будет перекраивать ее, и, если браться за это, то явно не перед сдачей проекта проекта – это не то, на что следует тратить время. «Приближение срока окончания работ – единственный случай, когда можно отложить рефакториг, ссылаясь на недостаток времени.» - говорит М. Фаулер («Рефакторинг. Улучшение существующиего кода»).
Но не стоит злоупотреблять этой техникой и в мирные времена, когда срок сдачи еще не близок, а руки чешутся что-нибудь переиначить. Рефакторинг кода к шаблонам может иметь не только положительные стороны, но и отрицательные, например, тотальное усложнение кода. Как и любой техникой, рефакторингом нужно использовать с умом. И вообще, ум нужно использовать, это тоже полезная техника ;)

Constuctor injection with Unity 2.0

2011-03-18T23:05:00.004+02:00

Пример Constructor Injection на Unity 2.0.

Пусть есть интерфейс IEmployee и класс, его реализующий:


interface IEmployee
{       
       int Age { get; set; }
       string Name { get; set; }
        string Surname { get; set; }
        string GetPosition();        
} 
class Employee : IEmployee
    {        
        #region IPerson Members

        public int Age { get ;  set ; }

public string Name { get ; set ; }

         public string Surname   { get; set;  }

        public String GetPosition()
        {
            return position.Position;
        }
        #endregion
        IPosition position;
        public Employee(IPosition _position)
        {
            position = _position;
        }
    }

Опубликовать сообщение

А так же есть интерфейс IPosition и набор классов, его реализующих:


public interface IPosition
    {
        string Position { get; }        
    }

    public class JustEmployee : IPosition
    {
        public string Position { get { return "Just employee"; } }         
    }

    public class Manager : IPosition
    {
        public string Position { get { return "Manager"; } }        
    }

    public class Boss : IPosition
    {
        public string Position { get { return "Boss"; } }        
    }

По названию легко догадаться, что IPosition представляет должность работника. Класс Employee имеет конструктор с параметром IPosition. Пример создания Employee с аргументом(IPosition) нужного типа с помощью Unity:


static void Main(string[] args)
        {            
            IUnityContainer unity = new UnityContainer();
            unity.RegisterType<IPosition, JustEmployee>()
                .RegisterType<IPosition, Manager>("Manager")
                .RegisterType<IPosition, Boss>("Boss")      
                .RegisterType<IEmployee,Employee>(new InjectionConstructor(typeof(IPosition)))
                .RegisterType<IEmployee,Employee>("Boss", new InjectionConstructor(typeof(Boss)))
                .RegisterType<IEmployee,Employee>("Manager", new InjectionConstructor(typeof(Manager)));

            List employees = new List<IEmployee>();            
            var emp = unity.Resolve<IEmployee>();
            emp.Name = "John";
            emp.Surname = "Malkovich";
            emp.Age = 35;
            employees.Add(emp);
            var manager = unity.Resolve<IEmployee>("Manager");
            manager.Age = 44;
            manager.Name = "Peter";
            manager.Surname = "Branch";
            employees.Add(manager);
            var boss = unity.Resolve<IEmployee>("Boss");
            boss.Name = "Bill";
            boss.Surname = "Millioner";
            boss.Age = 99;
            employees.Add(boss);                        
            foreach(var employee in employees)
            {
                Console.WriteLine("Person: " + employee.Name + " " + employee.Surname + ", " + employee.Age + ", " + employee.GetPosition());
            }
        }

Имеем:

Прелести байткода или зачем нужен обфускатор

2011-03-10T01:16:00.010+02:00

Прекрасная идея портируемости приложений, кроссплатформенности родила языки, использующие виртуальные машины, компилирующие промежуточный платформенно-независимый код (байт-код) в платформенно-специфичный код. Яркие примеры таких языков - Java, C#, VB, ActionScript etc. История, которую я хочу рассказать, будет именно о последнем, но общие моменты касаются всех языков, компилирующихся в промежуточный код.

Учеба - такое дело.... Экзамены - не самая любимая часть учебы :) И преподаватель решил устроить тесты. А тесты были хитрые. У него была оболочка на Adobe AIR, а вопросы к тестам брались из шифрованного xml файла ( более 600 вопросов). Для сдачи экзамена выбиралось 30 вопросов, менялись местами варианты ответов, чтобы студенты не могли механически вычислить, где какой правильный ответ. Надо было что-то делать. Удалось раздобыть оболочку. Что ж, здорово. Оказалось, что эйр - это обычный zip-архив. Распаковав его, обнаружилась file.swf, который вызвал дикое желание декомпильнуть его :) Гуглим Выбираем декомпилятор, открываем файл и ... как разработчика меня огорчило увиденное. Как злостного сообщника студентов-лодырей - порадовало. Чистый, ничем не тронутый ActionScript. Логика выбора вопросов из файла, перемешивания вариантов ответов, криптование и декриптование файла вопросов, подсчет реузльтатов... Даже контрольный пример для криптора имелся в коде, что позволило написать тест для декриптора (декриптор на С#):


[Fact]
public static void DectriptString_Test(){
            var k1 = "x73bvs";
            var k2 = "ma";
            var k3 = "qrx9v";            
            var loc1 = new XorDecriptor(
                k1 + k1.Length.ToString() + "XQAWDbsd7%#jsd"
                + k2 + k2.Length.ToString() + "gyVsd34R$sd"
                + k3 + k3.Length.ToString() + "jhJLwNe@$gaSd" 
                + (k1.Length * k2.Length + k3.Length + 23).ToString()
                );
            var loc2 = "4X%5D%06%19%1D%161%22arg%03S%07VUJ%1EE@%0C%0D%12%08%1Fv4%16VU%12PS%26%03%1B%0CX%1F%14%04";
            loc2 = loc1.xor_unescape(loc2);
            Assert.Equal("London is %#a capit6$al of Grea@t Britai!n", loc2);
        }

Обратите внимание, все строки, использующиеся при инициализации декриптора, хранились в коде в открытом виде. Для дешифровки файла с вопросами к тесту используется пароль из трех частей (k1, k2, k3). Правильность пароля проверяется приведенным выше тестом.
Вот такие пироги. Чем мог помочь обфускатор? Обфускация - процесс затруднения анализа исходного кода. Среди методик обфускации есть сокрытие строк, переименование методов, классов и тд - применил бы разработчик хоть что-то из этого и хоть как-то да усложнил и запутал злостных взломщиков. При правильном подходе можно было вобще сделать код нечитабельным. Нужно хоть как-то защищать свой труд.
Как-то при просмотре .net сборки в декомпиляторе попался не менее замечательный кусок кода:


static private string BuildConnectionString(string path)
        {
            return ("Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" + path + ";User Id=Admin;Jet OLEDB:Database Password=securepasswrd1023!");
        }

Не знаю, насколько трудно написать хотя бы так:


static private string BuildConnectionString(string path)
        {
            return ("Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" + path + ";User Id="+Encoding.Default.GetString( Convert.FromBase64String("QWRtaW4=") )+";Jet OLEDB:Database Password=

"+Encoding.Default.GetString( Convert.FromBase64String("c2VjdXJlcGFzc3dyZDEwMjMh")

));
        }

А еще можно строки, предварительно отконвертированные в Base64, в ресурсы запрятать. А еще... Вариантов много, главное, не хранить в открытом виде такую информацию. Но, к сожалению, и такое встречается.
Полезные ссылки:
Способы защиты Flash-приложений
Статья на хабре про обфускаторы для .net

История одного приложения

2011-03-09T23:56:00.009+02:00

История эта началась давно, в те времена, когда деревья были высокими и трава зеленее, да и макароны назывались правильно ... И была поставлена задача - написать простенькое приложеньице, дополнение к главной программе, состоящее буквально из одной формы.
Задача приложения была в том, чтобы записывать в БД главного приложения следующее: сколько конкретный работник потратил времени на выполнение конкретной задачи с известной стоимостью (цена в час) для определенного клиента. Данные (клиент (Cusotmer), исполнитель (Supplier), сервис (Task), цена) брались из БД главного приложения. Что может быть проще? На форму были накиданы контролы, к контролам привязаны события - вуаля! Работает, готово.
Тут заказчик говорит: "Да, здорово, но еще здоровее будет, если можно будет изменять путь к БД главного приложения!" Да не проблема! Вот еще одна кнопочка, диалог, файл с сеттингами - всё работает! На этом этапе развития приложение состоит из...из... трудно сказать для такого "масштабного" приложения. Одна форма, пара кнопок - зачем заморачиваться и что-то выделять? В коде формы нет sql-кода, и на этом спасибо :) За работу с БД отвечает статический класс DBManager:


static class DBManager{
public static IList<Customers> GetCustomers() {...}
public static IList<supplier> GetSuppliers() {...}
public static IList<Task> GetTasks() {...}
...
}

Разработчик рад - работает, заказчик рад - работает! В данном раунде скорость (лень) победила качество.
Проходит время и ... "Общую стоимость нужно вычислять по-другому! " - говорит заказчик. - "Общая стоимость может включать в себя налог или нет в зависимости от типа компании!" Разработчик открывает код класса Task, добавляет private member companyType, которую инициализирует в конструкторе класса, находит метод GetTotalPrice() и пишет:


if ( CompanyType.Brutto == companyType) { CalculateBruttoPrice();} else {CalculateNettoPrice();}

Но тут на подстанции сгорает трансформатор, и гаснет свет, и весь вышеприведенный код исчезает, не сохранившись на ограниченных просторах жесткого диска.
На следующий день разработчик еще раз прочитал требования заказчика, и выделил интерфейс ITask, создал базовый абстрактный класс BaseTask и конечные классы BruttoTask и NettoTask, различающиеся только механизмом расчета итоговой стоимости и налога:

 interface ITask {
   ...
   double GetTotalPrice();
   double GetTotalTax(); 
}
/*когда стоимость налога включена в цену*/
class BruttoTask : BaseTask, ITask {
public double GetTotalPrice(){
    retrun Amount * Price;
}
public double GetTotalTax(){
   var hundrendPercentsPlusTax = 100 + TaxPercentage;
   return (GetTotalPrice() * TaxPercentage / hundrendPercentsPlusTax);
}
}
/*когда стоимость налога не включена в цену*/
class NettoTask : BaseTask, ITask {
public double GetTotalPrice(){
   return Amount * Price + GetTotalTax(); 
}
public double GetTotalTax(){
   return (Price*Amount * TaxPercentage) / 100;
}

После этого разработчик добавил класс-фабрику TaskFactory, которая будет в зависимости от типа компании создает нужный тип сервиса.


static class TaskFactory{
public ITask CreateTask(){
    if (CurrentSettings.CompanyType ==  CompanyTypes.Brutto) return new BruttoTask();
    if (CurrentSettings.CompanyType ==  CompanyTypes.Netto) return new NettoTask();
}
}

Ура, заказчик доволен, дело сделано! На этом этапе качество начинает побеждать скорость. Приложение стало немного более гибким. Например, если теперь заказчик скажет, что нужно добавить расчеты для компаний, у которых нет налога, то это потребует совсем не много усилий и займет не так уж много времени - всего лишь добавить class WithoutTaxTask : ITask.
Проходит N времени, и заказчику нужно немного расширить возможности приложения. Теперь нужно, чтобы программа умела сохранять, сколько и чего конкретный работник продал. Разработчик добавляет класс Product, но понимает, что уж очень он похож на Task, и поэтому в интерфейс ITask доавляет свойство IsService, которое и будет отличать сервис от продукта. Теперь нужно как-то получать список продуктов из БД и сохранять их туда. Разработчик открывает свой класс DBManager, начинает добавлять новый метод GetProducts(), и опять какие-то неполадки на подстанции уничтожают результаты его труда. На следующий день разработчик получает email от разработчика главной программы, в котором говорится, что было введено несколько служебных типов сервисов и продуктов, которые ни в коем случае отображать пользователю не нужно. Разработчик отрывает проект, ищет DBManager, начинает править GetTasks() и восклицает "Это ужасно!" И быстро начинает писать:

 interface IEntity { int ID {get;set;} }
interface ITask : IEntity {…}
class Customer : IEntity {…}
class Supplier : IEntity { … }
class Service : IEntity {...}

interface IRepository<T> where T : class, IEntity{
   IList<T> Load();
}
class CustomerRepository : IRepository<Customer>{
public IList<Customer> Load() { … }
}
...
public interface ITaskRepository{
   IList<ITask> Load();
   bool Save(ITask task);
}

public class  ServiceTaskRepository : IRepository<ITask>, ITaskRepository{       
public IList<ITask> Load(){...}              
public bool Save(ITask tsk){...}
}

Когда он заканчивает, то имеет Entities (хотя тут можно выделить Customer, Supplier, Service как Value-объекты, т.к. в процессе работы они никак не изменяются) и Repositories для них, счастливо улыбается и удаляет DBManager, который был перегружен обязанностями. Теперь каждый класс выполняет только свои обязанности, all inclusive больше не в моде. Разработчик открывает главную форму, код которой разросся на несколько экранов. "Нужно что-то с этим делать"-думает он и принимается за рефакторинг. По-тихоньку из бревна начал получаться Буратино, если б не сломался тесак. Разработчик со вздохом еще раз окинул взглядом код формы, и полез в свой арсенал выбирать рубанок калибра MVC / MVP / etc, но...
Но тут звонит заказчик, просит добавить в программу возможность просмотра закрытых сервисов и просит все это закончить «до завтра». Разработчик легко добавляет новый class ClosedTaskRepository : IRepository <ITask>, но опять тонет в коде главной формы. Выбравшись из трясины после добавления списка на форму, тестирует, отсылает заказчику и закрывает IDE: "На сегодня хватит. А завтра я разберусь с этими макаронами на главной форме". На следующий день довольный заказчик лукаво спрашивает "А можно сделать так, чтобы ….?" "Конечно, можно" - говорит разработчик, одевая макаронолазный костюм...
Мораль.... Какая тут мораль? Делайте сразу качество, даже если заказчик говорит "два поля одна кнопка", и очень хочется по-быстрому все свалить в одну кучу.

Сравнение IoC-контейнеров

2011-02-10T12:49:00.002+02:00

Небольшой сравнительный анализ IoC-контейнеров (AutoFac, MEF, Ninject, Spring.Net, StructureMap, Unity, Windsor) http://elegantcode.com/2009/01/07/ioc-libraries-compared/
Глубокий сравнительный анализ IoC-контейнеров:
http://blog.ashmind.com/index.php/2008/08/19/comparing-net-di-ioc-frameworks-part-1/
http://blog.ashmind.com/index.php/2008/09/08/comparing-net-di-ioc-frameworks-part-2/
Бенчмарк IoC-контейнеров (Unity, Windsor, StructureMap, Spring.NET):
http://www.codinginstinct.com/2008/04/ioc-container-benchmark-unity-windsor.html
Делайте выводы, решайте сами, иметь или не иметь ;)

Зачем нужен рефакторинг?

2010-10-27T15:26:00.002+03:00

Если вы только узнали, что это такое и не совсем понимаете, зачем оно нужно, то, скорее всего, после прочтения книги М.Фаулера "Рефакторинг", этот вопрос отпадет сам собой.
Если у вас уже есть опыт применения рефакторинга, но вы всё равно не понимаете, зачем это нужно, и считаете рефакторинг пустой тратой времени, то есть несколько вариантов объяснения:
а) либо вы - босс и считаете, что так программисты "валяют дурака" - вроде что-то и делают, но нового функционала - 0! Цель рефакторинга - не увеличение производительности кода, не сокращение расходуемой памяти, не ускорение алгоритмов вычислений - это все могут быть положительные побочные эффекты. Цель рефакторинга - структуризация и упрощение кода, приведение его в порядок, чтобы другой программист, который будет работать с ним после, не получил психологическую травму :)
б) либо вы применяете рефакторинг не там, где надо - еще раз почитайте М.Фаулера, другие книги (например, Д. Кериевски, С.Макконнелла и др.), разберите внимательно примеры... Вспомните, как часто вы слышите фразу (или сами ее говорите) "Этот код готов. Он не совсем идеален, зато работает!". Эдакий "скорокод"! Он ведь просто кричит "Help me! I wanna be refactored!" Вот тут можете смело оттачивать свои навыки!
в) либо вы считаете, что пишете идеальный код! - спуститесь с небес на землю, такого не бывает! Это была плохая новость. А теперь хорошая: вам есть, куда расти. Я считаю, что программист развивается, растет, когда находит все новые и новые пути оптимизации кода. Это значит, что он научился чему-то, увидел проблему в другом свете, и ее решение, раньше казавшееся сложным, теперь для него - само собой разумеющееся, элементарное. И с этими новыми знаниями программист может существенно улучшить старый код. Оглядываясь назад, думаю , как изящно можно было б решить ту или иную проблему с накопленными знаниями!
Помните, что любой код можно улучшить, главное в этом деле - не переборщить. И не стоит гнаться за принципом "совершенству нет предела", тут немного другая математика :)

VS 2010 Shortcuts Posters for C#, F#, VB, C++

2010-10-26T09:18:00.001+03:00

Появились новые постеры с горячими сочетаниями клавиш для разработки в Visual Studio 2010 под разные языки. Постеры выполнены в двух разных форматах - 8.5”x11”(Letter) и 210x297mm (А4)
Скачать с сайта Microsoft
Зеркало на C# for VS 2010 постеры
C# for VS 2008

Задачка про песочные часы

2010-10-14T12:52:00.000+03:00

Есть 2 песочных часов: первые отсчитывают 4 минуты, вторые - 7. Как, начиная с текущего момента, с помощью этих часов отмерить 9 минут?

Ответ:
Запускаем часы вместе.
Через 4 минуты переворачиваем первые.
Через 7 минут после начала переворачиваем вторые - в первых пройдёт уже 3 минуты.
Через минуту (т.е. через 8 после начала) опять закончатся первые, во вторых отсыпется минута.
Переворачиваем вторые, чтобы отсчитать последнюю минуту.

MS Sql Server CE : какая dll для чего нужна?

2010-10-12T13:59:00.003+03:00

После установки MS SQL Server CE мы получаем целый набор dll-файлов. Для чего нужна какая dll? Что нужно добавлять в проект, а что нет? Сейчас будем разбираться.

Для начала посмотрим на такую замечательную картинку:

На этой картинке хорошо видно, из каких компонент состоит SQL Server CE.
Синим цветом обозначены компоненты ядра (Storage Engine, Query Processor), которые должны быть обязательно для работы с сервером.
Зеленым и фиолетовым выделены опциональные компоненты. Фиолетовые (ADO.NET Provider, Managed Extensions, OLEDB Provider) зависят от выбранной модели доступа к БД. Зеленые компоненты подключаются по желанию - хотите вы работать с LINQ2SQL или нет = подключаете соответствующий компонент или нет.
Теперь определимся, в какой дллке что находится (XX в конце имени dll-файла обозначают версию SQL Server CE. Например, для SQL Server CE 3.5 XX надо заменить на 35, для SQL Server CE 4.0 соответственно на 40) :
Storage Engine - sqlceseXX.dll
Query Processor - sqlceqpXX.dll
OLEDB Provider - sqlceoledbXX.dll
DB Utilities - sqlcecompactXX.dll
Managed Extensions - sqlcemeXX.dll
Merge Replication, Remote Data Access - sqlcecaXX.dll
Sync Services:
         Client Sync Provider - Microsoft.Synchronization.Data.SqlServerCe.dll
         Sync Common - Microsoft.Synchronization.Data.dll
         Server Sync Provider - Microsoft.Synchronization.Data.Server.dll
ADO.NET Provider (ADO.NET v2 Provider) - System.Data.SqlServerCe.dll
LINQ/Entities (ADO.NET v3 Provider), Entity Framework - System.Data.SqlServerCe.Entity.dll
LINQ/SQL не требуется отдельной dll для подключения
Error Messages - sqlceer35en.dll (для локализации меняем EN в названии файла на нужную локаль)
Теперь займемся простой арифметикой, а после посмотрим, когда и что применять :)
1) Core Engine = Storage Engine + Query Processor = sqlceseXX.dll + sqlceqpXX.dll
2) Core Engine Native = Core Engine + OLEDB = sqlceseXX.dll + sqlceqpXX.dll + sqlceoledbXX.dll
3) Core Engine Managed = Core Engine + ADO.NET + Managed Extensions = sqlceseXX.dll + sqlceqpXX.dll + System.Data.SqlServerCe.dll + sqlcemeXX.dll
Вот такая простая арифметика.
А теперь, главный вопрос - что же и когда использовать?
Если приложение использует нативный код и подключается к компакт серверу только локально, без всяких Sync-сервисов, то приложению потребуется только dll-набор для Core Engine Native
Если мы пишем приложение на управляемом коде и , опять же, работаем с Sql Server CE только локально, то нужен dll-набор для Core Engine Managed. При этом в приложении мы можем использовать LinQ/SQL. Но если вдруг мы захотим использовать LINQ/Entities, придется подключить дополнительно System.Data.SqlServerCe.Entity.dll.
Если захотим в приложении сделать возможность репликации, то в зависимости от того, как пишем (native или managed) будет Core Engine Native / Managed + sqlceca35.dll.
И так далее: к ядру (native/managed) плюсуем дополнительные библиотеки в зависимости от потребностей.
Данный пост использует материалы http://blogs.msdn.com/b/laxmi/archive/2009/10/07/sql-ce-binaries-details.aspx

10 заповедей программиста

2010-10-01T13:20:00.002+03:00

1. Программирование - твоя главная страсть. И да не будет у тебя страсти главней.

2. Не сотвори себе кумира из конкретной технологии. Ибо программирование требует постоянного развития, а технологии-кумиры останавливают развитие.

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

4. Работай много и хорошо, но не забывай и про отдых. Ибо нет ничего страшнее, чем код усталого, засыпающего программиста.

5. Уважай учителей и учеников своих. Постоянно учись и учи окружающих, чтобы было тебе всё легче и легче делать всё более и более сложные вещи.

6. Не убий в себе ребенка. Не забывай эмоции от первого запуска первой написанной тобой программы и воспринимай каждую следующую, как ту - первую.

7. Не изменяй программированию. Ибо программист может стать кем угодно, но этот кто угодно обратно программистом уже не станет.

8. Не кради код ближнего своего.

9. Не программируй то, что может принести вред другим. Ибо встав раз на путь дьявола - на нем и останешься.

10. Не завидуй ближнему твоему, если он умеет лучше программировать. Ибо программирование - это божественный дар, но его можно развить. Так что не завидуй, а развивай.

(скопипастено с инета)

TypeMock Video: The Goals of Unit Testing

2010-09-28T13:17:00.002+03:00

О целях юнит-тестирования.

Задачка для страшеклассников

2010-09-28T08:34:00.003+03:00

Маленькая и совсем несложная задачка.

Есть две переменные a и b. Поменять местами их значения, не вводя третью переменную.

Решение:
a = a+b
b = a - b
a = a - b

Еще одна интересная задачка

2010-09-22T00:18:00.004+03:00

Нравятся мне эти задачки, несложные, но хитрые :) Вот еще одна.

Дано целое натуральное число. Без использования циклов и рекурсии поменять значение самого крайнего правого бита, равного 0, на 1.
Например, 0101 -> 0111; 1010 ->1011

Решение:value | (value+1)

Очень сложная задачка

2010-09-14T13:05:00.005+03:00

Не так давно знакомый программист, проходивший собеседование в девелоперской конторе, поделился задачкой, которую получил на собеседовании:

Есть массив из N элементов, в котором находятся значения от 1 до N+1. Одно значение пропущено. Нужно его определить за линейное время. Массив не сортирован.

Вот такая хитрая задачка с ооочень тривиальным решением :)

Решение: искомое значение = sum(i=1; i=N+1) - sum(array[N])

С 256-ым днем в году!

2010-09-13T11:08:00.002+03:00

С нашим днём, уважаемые коллеги!!!
Красивого, чистого кода, и пусть обходят стороной вас баги!

IoC, DI, WTF?

2010-09-10T15:55:00.013+03:00

Давайте разберемся с этими загадочными абревиатурами и разницей между ними.

IoC (Inversion of Control) - инверсия управления, один из принципов S.O.L.I.D., известна так же как Принцип обращения зависимостей (Dependency Inversion Principle, DIP). IoC - очень полезная техника, которая уменьшает связанность и придает гибкость разрабатываемому ПО. Принцип инверсии управления звучит так [wikipedia]:

Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

В своей статье Inversion of Control Containers and the Dependency Injection pattern Мартин Фаулер вводит понятие Dependency Injection (Dependency Injection) - внедрение зависимости - как разновидность IoC. Всего он выделяет три типа DI в зависимости от того, через что осуществляется DI:
1) Interface injection
2) Setter injection (пример)
3) Constructor injection (пример)

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


class TxtDocument
{
private string Path;
public TxtDocument(string path){...}
public void Open() {...}
public Stream GetContent() {...}
public void Save(Stream stream) {...}
public void Close(){...}
}
class DocumentManager
{
private TxtDocument document;
public DocumentManager(string path)
{
document = new TxtDocument(path);
}
public Steam GetDocument()
{
document.Open();
Stream stream = document.GetContent();
document.Close();
}
public void SaveDocument(Stream stream)
{
document.Open();
document.Save(steam);
document.Close();
}
}
....
DocumentManager dm = new DocumentManager(@"C:\test.txt");
Stream stream = dm.GetContent();
...
dm.Save(stream);
....

UML-диаграмма:
Что получилось: жесткая зависимость класса DocumentManager от класса TxtDocument. А теперь представьте, что нам понадобилось работать еще и с rtf, doc, pdf, etc. - документами. Что делать? Срочно, срочно применять IoC (DI: Interface injection)! Для этого введем интерфейс IDocument, который будут реализовывать все классы документов.


interface IDocument
{
void Open() {...}
Stream GetContent() {...}
void Save(Stream stream) {...}
void Close(){...}
}
class TxtDocument : IDocument { .... }
class RtfDocument : IDocument { ... }
class DocDocument : IDocument { ... }
class PdfDocument : IDocument { ... }

Класс DocumentManager изменится следующим образом:


class DocumentManager
{
private IDocument document;
public DocumentManager(IDocument _document)
{
document = _document;
}
public Steam GetDocument()
{
document.Open();
Stream stream = document.GetContent();
document.Close();
}
public void SaveDocument(Stream stream)
{
document.Open();
document.Save(steam);
document.Close();
}
}
....
DocumentManager dm = new DocumentManager(new RtfDocument(@"C:\test.rtf"));
Stream stream = dm.GetContent();
...

UML-диаграмма результата:
В результате применения инверсии управления мы получили гибкое решение, которое с легкостью позволяет нам добавлять классы для работы с новыми форматами файлов.

Для автоматизации инверсии управления существуют IoC-контейнеры. Наиболее популярные для .Net :
Unity Application Block 2.0
Spring.NET
Structuremap
CastleProject
Seasar
Winter.NET
Применение IoC-контейнера на примере рассмотрим в следующей заметке.

UML редактор

2010-09-03T09:12:00.005+03:00

Наткнулась на SourceForge на милый UML-редактор NClass с элементами интерфейса, такими родными и привычными для меня как пользователя Visual Studio.
Простой и интуитивно понятный интерфейс. Поддерживает два типа диаграмм - java, c#, кодогенерацию, экспорт диаграммы в PDF, сохранение в разных графических форматах (png, jpg, etc...). Что еще сказать? Программа бесплатна, написана C#. Из минусов - нет Ctrl+Z, Ctrl+C, Ctrl+V :( Надеюсь, в следующих релизах появится поддержка этих поистине горячих сочетаний клавиш :)

TDD: начало

2010-08-30T22:11:00.011+03:00

Что такое TDD?
Это способ управления страхом в процессе программирования.
Да, мне гораздо спокойней, когда работоспособность моего кода подтверждена и подтверждается постоянно тестами. В любой момент времени я могу запустить тесты и проверить, все ли работает. Особенно актуально это, когда изменения вносятся в код, написанный пару-тройку месяцев назад, а то и ранее. А если этот код еще и чужой, то шансы поломать что-то возрастают многократно. Имея хороший набор тестов можно безбоязненно и безболезненно вносить изменения в код. Говоря "хороший набор тестов" я намеренно не указываю число в процентах, потому что считаю test coverage весьма относительной метрикой. Стопроцентное покрытие - исключительно утопия. И та еще тема для холивара :) Тестов должно быть столько, сколько требуется для уверенности в вашем коде и спокойного сна, если представить, что каждый ваш проект - система обеспечения АЭС ;)
К чему стремится TDD?
К чистому коду, который работает.
Ключевое слово здесь - чистый. Код, который работает, может написать каждый. И зачастую такой код - выходец из семейства "говнокодовых". Думаю, такой код в начале тернистого пути совершенствования навыков программирования писали все. Но есть несколько вещей, которые заставляют двигаться от кода, который работает, в сторону "чистого кода, который работает" - начинаются сложности при поддержке кода, внесении изменений, расширении системы... признаки того, что все катится в сторону антипаттерна Big ball of mud :(
Каковы правила TDD?
Красный - зеленый - рефакторинг

Эти правила просты, как дважды два:
1) Красный - пишем тест. Не факт, что он заработает сразу (или даже скомпилируется). Напротив, это тревожный знак. Ведь тесты мы пишем всегда перед написанием кода. «Тест, написанный после кода, ничего не стоит и является только обузой.»
2) Зеленый - заставляем тест работать, создавая при этом минимум кода. О чистоте и порядке на этом этапе задумываться еще рано. Тест должен работать. И работать быстро. Вот что главное на данном этапе. Минимум усилий. Ничего лишнего. Тут мы создаем код, который работает.
3) Рефакторинг - наводим порядок. Убираем дублирование и остальные запашки. После каждого действия запускаем тесты, проверить, ничего ли не поломалось. Время создавать чистый код, который работает.
И кто это все придумал?
Тестирование имеет довольно длинную историю, уходя вглубь веков. Первые упоминания о тестировании можно найти в 1975 (в "Мифическом человеко-месяце" Брукса). А сама методология Test-Driven Development и ее основные принципы были сформулированы Кент Беком в книге "Extrime Programming Explained", увидевшей свет в 1999 году. С тех пор и понеслось :)
Что нужно, чтобы начать?
Нужно немного - желание, храбрость, терпение и фреймворк для тестирования под платформу, на которой вы программируете. Или можете сами его написать, как это делает Кент Бек. Заодно и попрактикуетесь:)
А еще?
А еще можно (нужно) искать тут:
Кент Бек. "Экстремальное программирование: разработка через тестирование"
Roy Osherove Understanding TDD (видео, en)
Джерард Мессарош «Шаблоны тестирования xUNIT»
Джошуа Кериевски. "Рефакторинг с использованием шаблонов"
М. Фаулер "Рефакторинг. Улучшение существующего кода."

SqlCE 3.5 to 4.0 Converter

2010-08-26T11:47:00.021+03:00

Недавно (в июле этого года) вышла новая версия MS Sql CE, в которой был изменен алгоритм шифрования (стал использоваться SHA-2). Это означает, что для работы sql ce 4 с бд, созданной сервером версии 3.5, ее нужно предварительно переконвертировать. Для это в API предусмотрен специальный метод, поэтому особого труда конвертирование не вызовет.
Давайте напишем конвертер для файлов баз данных в формате slq ce 3.5 в формат slq ce 4.0.
Писать будем на C# в TDD-стиле, использовать VS 2008, тестировать в xUnit (последнюю версию можно скачать с codeplex). Когда вы используете TDD, не нарушая основных принципов ( а их всего три - RGR (красный-зеленый-синий): пишем тест, пишем код, рефакторим) и порядка их следования, то получаете автоматически приятные бонусы в коде.

Warning! Этот пост нужно рассматривать как пример по разработке в стиле TDD для начинающих.

Итак, начнем. Создаем новый Windows Forms Application - проект в VS (у меня он называется "SqlCE3.5_to_4.0"), сразу же добавляем в солюшн еще один проект Class Library, называем его Tests. И, в лучших традициях TDD, начинаем писать наш первый тест.


public class SqlCEVersionConverterTests
{
[Fact]
public void ConvertTest()
{
string file2convert = @"C:\sqlCE35.sdf";
var sqlCEConverter = new SqlCEVersionConverter(file2convert);
Assert.True(sqlCEConverter.Convert());
}
}

Так я представляю себе работу нашего конвертера. Тест, конечно же, не срабатывает - ведь класс SqlCEVersionConverter не реализован. Этим и займемся. Добавим в главный проект новый класс, SqlCEVersionConverter. Пока нам нужно сделать минимум телодвижений, чтобы заставить тест сработать - делаем фейковую реализацию:


public class SqlCEVersionConverter
{       
public SqlCEVersionConverter(string file2convert)
{
}
public bool Convert()
{
var result = true;
return result;
}
}

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


public bool Convert()
{
var result = false;
using (SqlCeEngine sqlCeEngine = new SqlCeEngine(connectionString))
{
try
{
    sqlCeEngine.Upgrade();
    result = true;  
}
catch (Exception e)
{   
    //обработка исключения
}
}
return result;
}

Код не компилируется (F6) - не хватает строки соединения (connectionString). Добавляем новое поле в класс. Теперь код компилируется, но тест не срабатывает - мы используем пустую connectionString, из-за чего и не можем подключиться к БД, чтобы переконвертировать ее. Значит, нам нужен метод, который бы создавал строку подключения. Настало время писать следующий тест.


[Fact]
public void BuildConnectionStringTest()
{
string sqlCEdbFile = @"C:\sqlCE35.sdf";
var converter = new SqlCEVersionConverter(file2convert);
string connectionString = converter.BuildConnectionString(sqlCEdbFile);
Assert.Equal(@"Data Source=C:\sqlCE35.sdf;Mode=Exclusive", connectionString);
}

Код не компилируется, нужно реализовать метод BuildConnectionString():


public string BuildConnectionString(string sqlCEdbPath)
{
SqlCeConnectionStringBuilder builder = new SqlCeConnectionStringBuilder();
builder["Data Source"] = sqlCEdbPath;
builder["Mode"] = "Exclusive";
return builder.ConnectionString;
}

В реализации этого метода мы сразу опробовали новый API slq ce 4 - класс SqlCeConnectionStringBuilder. Ничего так, удобненько :)
Теперь изменим конструктор SqlCEVersionConverter:


public SqlCEVersionConverter(string file2convert)
{
connectionString = BuildConnectionString(file2convert);
}

Запускаем тест - тест проходит. Look nice. Но что-то не то. Дааа, ведь база данных может быть запаролена! Это значит, что нам нужен для конвертирования бд знать еще и пароль! Т.е. нам нужен еще конструктор, принимающий два аргумента (путь к файлу бд и пароль) и метод BuildConnectionString, тоже на два аргумента. Пишем соответствующие тесты (позволю себе пропустить их) и добавляем реализацию в класс SqlCEVersionConverter. Запускаем - тесты срабатывают! Но все равно мне не нравятся эти два метода BuildConnectionString, засоряют они своим присутствием ауру конвертера :) Во-первых, эти методы должны быть явно приватными. Но тогда их не потестишь. Во-вторых, конвертер должен конвертировать, а тут ему еще вписали в обязанности connection strings делать. Не порядок. Это явно противоречит Single Responsible Principle. Я сделаю небольшой рефакторинг - вынесу эти два метода в отдельный класс SqlCEConnectionStringBuilder. Но для этого сначала напишу соответствующие тесты. Ниже тест SqlCEConnectionStringBuilder.BuildConnectionString() на два аргумента:


[Fact]
public void BuildConnectionStringTest()
{
string sqlCEdbFile = @"C:\sqlCE35.sdf";
string password = "somepassword";
var builder = new SqlCEConnectionStringBuilder();
string connectionString = builder.BuildConnectionString(sqlCEdbFile, password);
Assert.Equal(@"Data Source=C:\sqlCE35.sdf;Mode=Exclusive;Password=somepassword", connectionString);
}

Просто копируем тела методов из SqlCEVersionConverter в SqlCEConnectionStringBuilder, запускаем тесты - срабатывают. Теперь изменяем конструкторы SqlCEVersionConverter, таким образом, чтобы использовался класс SqlCEConnectionStringBuilder:


public SqlCEVersionConverter(string file2convert, string password)
{
SqlCEConnectionStringBuilder builder = new SqlCEConnectionStringBuilder();
connectionString = builder.BuildConnectionString(file2convert, password);
}

И после этого удаляем из SqlCEVersionConverter методы BuildConnectionString(). Компилируем - все в порядке. Запускаем еще раз для уверенности тесты - все зеленое :)
Теперь осталось сделать форму и нацепить обработку событий. У меня форма получилась такой:
На форме есть чекбокс - Make backup file before convert. Из-за того, что в sql ce 4 используется SHA-2, sql ce 3.5 или более ранние версии не смогут работать с файлами данных sql ce 4. Поэтому было бы хорошо делать бэкап. А для этого нам нужен SimpleBackuper. Но сначала - тесты! :)


public class SimpleBackuperTests
{
[Fact]
public void BackupBeforConvertTest()
{
string file2backup = @"C:\sqlCE35.sdf";
var backuper = new SimpleBackuper();
backuper.MakeBackup(file2backup);
string backupFilename = @"C:\sqlCE35_backup.sdf";
Assert.True(File.Exists(backupFilename));
}
}

Сильно заморачиваться над методом создания бэкапа я не буду - использую простое переименование и копирование.


public class SimpleBackuper
{
public void MakeBackup(string file2backup)
{
var backupFileName = file2backup.Insert(file2backup.LastIndexOf('.'), "_backup");
File.Copy(file2backup, backupFileName, true);
return;
}
}

Вот теперь осталось совсем немного - написать обработку клика по кнопке Convert. Думаю, это описывать не надо :)
Заметьте, до этого момента мы еще ни разу не запустили программку (F5) - только компилировали (F6)! Время запустить и законвертировать наконец-таки какую-нибудь sql ce 3.5 бд в 4.0! И вот он, сюрприз! База из 3040 Кб - файла превратилась в 676 Кб-файл! Вот это отличная новость четвертого компакта!

Итак, подведем итоги. Мы разработали приложение в стиле TDD. Получили чистый код, который работает :) Как бонус, у нас получилось отличное отделение логики решаемой задачи от графического пользовательского интерфейса. И мы можем совершенно без страха изменить что-либо или добавить новый функционал в программу.

MS Sql CE 4 CTP1

2010-08-26T08:11:00.007+03:00

В июле этого года вышел SQL Server CE 4 CTP1, что, конечно же, является хорошей новостью! Скачать sql ce 4 можно с сайта Microsoft, дистрибутив радует размером - всего 2.5 мб для х64 и 2.0 мб для х32.
Что же нового в четвертом компакте? Много было сделано для использования sql ce в ASP.NET приложениях - теперь компакт выдерживает нагрузку сайтов-стартеров с не большим количеством посещений. Внедрили поддержку SHA 2 - шифрования. Это означает, что для перехода с sql ce 3.5 на 4.0 база данных должна быть предварительно проапгрейдена предусмотренным в API методом SqlCeEngine.Upgrade(). Так же это означает, что slq ce 3.5 не может работать с файлами данных, созданными четвертым компактом.
Компакт теперь умеет беспроблемно работать с ADO.NET Entity Framework 4.0, что тоже радует :)
Важно отметить, что в четвертом компакте изменился Transact-SQL-синтаксис: добавлены ключевые слова OFFSET & FETCH:


SELECT * FROM Employees ORDER BY [Hire Date] OFFSET 10 ROWS;
SELECT * FROM Orders ORDER BY [Shipped Date] OFFSET 2 ROWS FETCH NEXT 1 ROW ONLY;

Так же изменился API:
System.Data.SqlServerCe.SqlCeConnection.GetSchema() - возвращает информацию о базе данных.


SqlCeConnection conn = new SqlCeConnection("DataSource=Northwind.sdf");
       try
       {
           conn.Open();
           DataTable dt = conn.GetSchema();
           dt = conn.GetSchema("Tables");
           dt = conn.GetSchema("Columns");
           dt = conn.GetSchema("Indexes");
           dt = conn.GetSchema("IndexColumns");
           dt = conn.GetSchema("ForeignKeys");
       }
       catch (Exception e)
       {
           //Fail
       }

System.Data.SqlServerCe.SqlCeConnectionStringBuilder - позволяет легко строит connection strings для компакта.


SqlCeConnectionStringBuilder builder =  new SqlCeConnectionStringBuilder();
builder["Data Source"] = sqlCEdbPath;
builder["Mode"] = dbMode;
builder["Password"] = password;
Console.Write( builder.ConnectionString );

Более подробно об этих и других нововведениях можно почитать в блоге Rob Tiffany
А тут можно почитать о тулзе для конвертирования файлов sql ce 3.5 в slq ce 4.0

В чем измеряется качество кода?

2010-08-20T10:00:00.001+03:00

Подкасты для разработчика

2010-08-17T10:54:00.007+03:00

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

http://rpod.ru - кладезь подкастов. На любой вкус и цвет. Тут в следует выделить, во-первых, отличные подкасты Петербургской Группы Alt.Net http://spbaltnet.rpod.ru/ В каждом выпуске подкаста море полезной и интересной информации.
О подкасте:

Петербургская группа Alt.Net создана с целью проведения в Санкт-Петербурге семинаров и технических встреч, связанных с разработкой в среде .NET. Наша цель – помочь друг другу узнать больше о том, как работать в среде .Net, как эффективно использовать различные технологии, методологии и практики в нашей работе.

Дальше - Domain Driven Design Study Group. Тут можно послушать обсуждения книги Эрика Эванса "Domain-Driven Design: Tackling Complexity in the Heart of Software". Всем, кто хочет познакомиться с DDD, стоит обратить внимание на этот подкаст.

Следующий подкаст - Качественный код и методология Agile. Название подкаста говорит само за себя. Выпуски небольшие по длительности, один выпуск - одна конкретная тема.

The Art Of Programming - ориентирован на Java, Flash/Flex, но тоже интересно послушать.

Следующий кладезь подкастов для IT-шника http://www.dotnetrocks.com - The internet radio talk show for .Net developers. В студию приглашаются дотнет разработчики и рассматривается какая-то конкретная тема. Подкаст на английском языке.

http://www.hanselminutes.com - англоязычный еженедельный подкаст для ASP.NET или Windows разработчиков. В студию приглашаются известные разработчики и дают интервью. Например, интервью с Роем Ошро The Art of Unit Testing with Roy Osherove.

Elegant Code Cast и Software Engineering Radio - еще две англоязычные подкаст-ленты, которые я с удовольствием слушаю.

UPD: Spbaltnet переехали. Теперь их нужно искать на podfm.ru http://spbaltnet.podfm.ru

Лето...

2010-07-12T23:34:00.004+03:00

Лето.... Время отпусков, жары и комаров :) Время лежать на золотом песке под солнышком и ни о чем не думать... Ленивое время, вобщем...
На улице жара, делать ничего не хочется, мысли бессвязно и очень вяло ползают в голове... Работа не идет, вспоминается поговорка "Если хочешь поработать – ляг, поспи и все пройдет". Даже кофе не помогает!
Надо как-то себя мотивировать, а ни один способ мотивации не срабатывает...
Нет, один срабатывает, но эффективность все равно не та: через силу начинаю делать и по чуть-чуть увлекаюсь, и пошел процесс.... Последнее, что пришлось делать через принуждение - переписывать код за коллегой... Сначала задание было "чуток дописать", но, увидев "чудеса чудесные, прелести прелестные" пришлось переписать добротный кусок кода, а занятие это не из приятнейших... Само по себе редактирование, правка чужого кода - та еще задача. А если код написан из рук вон плохо, с огромным количеством "code smells" ;( ... Ничего, бывает, пережили...
Главное, что до пятницы осталось совсем немного - еще пятьдесят три минуты рабочего времени понедельника и три дня!

Пример рефакторинга кода на C#

2010-06-26T12:50:00.068+03:00

Что такое рефакторинг? М. Фаулер дает следующее определение рефакторинга ("Рефакторинг: улучшение существующего кода"):

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

Давайте рассмотрим на примере.

Задача:
В файл ODBC.INI добавить настройки принтера для устанавливаемой программы. Если настройки для данной программы уже имеются, то заменить их.
Имеется решение:


void InstallDriver(string drive)
{
    string PathToODBCINI = Environment.GetEnvironmentVariable("windir",  EnvironmentVariableTarget.Machine) + @"\ODBC.INI";
    if (!File.Exists(PathToODBCINI))
    {
       try
       {
          File.Create(PathToODBCINI).Close();
       }
       catch (Exception e)
       {
          MessageBox.Show(e.Message);
       }
    }
    StreamReader sr = new StreamReader(PathToODBCINI,    System.Text.ASCIIEncoding.Default);
    string content = sr.ReadToEnd();
    sr.Close();
    int index = content.IndexOf("[ODBC Data Sources]");
    if (index >= 0)
    {
       int lastIndex = content.IndexOf("QEWSD=34751", index) + 11;
       try
       {
           content = content.Remove(index, lastIndex - index);
       }
       catch
       {
           MessageBox.Show(ERROR_WRONG_PREVIOUS_INSTALLATION);
       }
    };
    string path_to_driver = Helpers.AppExecFolder + "files\\driver.txt";
    if (File.Exists(path_to_driver))
    {
        sr = new StreamReader(path_to_driver);
        string driver_text = sr.ReadToEnd();
        driver_text = driver_text.Replace("{1}", drive);
        sr.Close();
        try
        {
            StreamWriter sw = new StreamWriter(File.OpenWrite(PathToODBCINI), System.Text.ASCIIEncoding.Default);
            string config = String.Format("{0}{1}", driver_text, content);
            sw.Write(config);
            sw.Close();
            MessageBox.Show("Installation completed");
        }
        catch
        {
            MessageBox.Show(e1.Message);
        }
     }
     else
     {
        MessageBox.Show(String.Format("Cannot find file {0}", path_to_driver));
     }
}

Один метод делает всё... Хороший пример того, как не надо писать код. Сколько разных запахов тут смешалось воедино...
Давайте рассмотрим, что делает этот код, в виде последовательности действий:
0. Находит (или создает, если файл не существует) ODBC.INI
1. Получает содержимое ODBC.INI
2. Проверяет наличие настроек для программы и удаляет их
3. Формирует новые настройки
4. Записывает новые настройки в ODBC.INI
Давайте для начала разобъём этот метод на 5 отдельных методов в соответствии с выделенными действиями. Что получается:


string GetODBCINIPath()
{
    string _PathToODBCINI = Environment.GetEnvironmentVariable("windir", EnvironmentVariableTarget.Machine) + @"\ODBC.INI";
    if (!File.Exists(_PathToODBCINI))
    {
        File.Create(_PathToODBCINI).Close();
    }
    return _PathToODBCINI;
}
string GetODBCINIContent(string PathToODBCINI)
{
    using (StreamReader sr = new StreamReader(PathToODBCINI, System.Text.ASCIIEncoding.Default))
    {
        string content = sr.ReadToEnd();
        return content;
    }
}
string GetClearDriverSettings(string commonSettings)
{
    string clearSettings = commonSettings;
    int index = commonSettings.IndexOf("[ODBC Data Sources]");
    if (index >= 0)
    {
        int lastIndex = commonSettings.IndexOf("QEWSD=34751", index) + 11;
        clearSettings = commonSettings.Remove(index, lastIndex - index);
    };
    return clearSettings;
}
string MakeNewSettings(string drive, string oldSettings)
{
    string driver_text = String.Empty;
    string path_to_driver = Path.Combine(Helpers.AppExecFolder, "files\\driver.txt");
    if (File.Exists(path_to_driver))
    {
       using(StreamReader sr = new StreamReader(path_to_driver))

{

          string driver_text = sr.ReadToEnd();
          driver_text = driver_text.Replace("{1}", drive);
       }
    }
    string newSettings = String.Concat(driver_text, oldSettings);
    return newSettings;
}
bool SetNewDriverSettings(string new_settings, string PathToODBCINI)
{
    bool result = true;

    using (StreamWriter sw = new StreamWriter(File.OpenWrite(PathToODBCINI), System.Text.ASCIIEncoding.Default))
    {
       try
       {
           sw.Write(new_settings);
       }
       catch
       {
           result = false;
       }
    }
    return result;
}
void InstallDriver(string drive)
{
    string PathToODBCINI = GetODBCINIPath();
    string commonSettings = GetODBCINIContent(PathToODBCINI);
    string clearSettings = GetClearDriverSettings(commonSettings);
    string newSettings = MakeNewSettings(drive, clearSettings);
    if (SetNewDriverSettings(newSettings, PathToODBCINI))
    {
        MessageBox.Show("Installation completed");
    }
    else
    {
        MessageBox.Show("Error");
    }
}

Теперь это выглядит немного лучше, но всё еще плохо. В глаза бросается PathToODBCINI, который используется в нескольких методах. Если присмотреться к этим методам, то мы увидим, что всех их объединяет работа с ODBC.INI, то есть логичнее будет выделить эти методы в отдельный класс. Заодно перенесем туда и назойливый PathToODBCINI. Получим:


class OdbcIniProvider
{
    private string PathToODBCINI;

    public OdbcIniProvider()
    {
        PathToODBCINI = GetODBCINIPath();
    }

    private string GetODBCINIPath()
    {
        string _PathToODBCINI = Environment.GetEnvironmentVariable("windir", EnvironmentVariableTarget.Machine) + @"\ODBC.INI";
        if (!File.Exists(_PathToODBCINI))
        {
            File.Create(_PathToODBCINI).Close();
        }
        return _PathToODBCINI;
    }

    public string GetODBCINIContent()
    {
       using (StreamReader sr = new StreamReader(PathToODBCINI, System.Text.ASCIIEncoding.Default))
       {

return

 sr.ReadToEnd();
       }
    }

    public bool SetNewDriverSettings(string new_settings)
    {
       bool result = true;

       using (StreamWriter sw = new StreamWriter(File.OpenWrite(PathToODBCINI), System.Text.ASCIIEncoding.Default))
       {
           try
           {
               sw.Write(new_settings);
           }
           catch
           {
               result = false;
           }
       }
       return result;
    }
}
...
void InstallDriver(string drive)
{
   OdbcIniProvider odbcIniProvider = new OdbcIniProvider();
   string commonSettings = odbcIniProvider.GetODBCINIContent();
   string clearSettings = GetClearDriverSettings(commonSettings);
   string newSettings = MakeNewSettings(drive, clearSettings);
   if (odbcIniProvider.SetNewDriverSettings(newSettings))
   {
      MessageBox.Show("Installation completed");
   }
   else
   {
      MessageBox.Show("Error");
   }
}

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


class SettingsManager
{
    public SettingsManager(){}

    public string GetClearDriverSettings(string commonSettings)
    {
        string clearSettings = commonSettings;
        int index = commonSettings.IndexOf("[ODBC Data Sources]");
        if (index >= 0)
        {
           int lastIndex = commonSettings.IndexOf("QEWSD=34751", index) + 11;
           clearSettings = commonSettings.Remove(index, lastIndex - index);
        };
        return clearSettings;
    }
    public string MakeNewSettings(string drive, string oldSettings)
    {
        string driver_text = String.Empty;
        string path_to_driver = Path.Combine(Helpers.AppExecFolder, "files\\driver.txt");
        if (File.Exists(path_to_driver))
        {
           using(StreamReader sr = new StreamReader(path_to_driver))

{

              string driver_text = sr.ReadToEnd();
              driver_text = driver_text.Replace("{1}", drive);
           }
        }
        string newSettings = String.Concat(driver_text, oldSettings);
        return newSettings;
    }
}

Коренным образом ситуация не улучшилась. Мне совершенно не нравится, как взаимодействуют OdbcIniProvider и SettingsManager. Кроме того, SettingsManager имеет слишком много открытых методов, о которых вызывающему коду совершенно не обязательно знать. По сути, вызывающему коду достаточно одного метода SetNewSettings(string drive), т.е. :


class SettingsManager
{
   ...
   public bool SetNewSettings(string drive)
   {
      OdbcIniProvider odbcIniProvider = new OdbcIniProvider();
      string commonSettings = odbcIniProvider.GetODBCINIContent();
      string clearSettings = GetClearDriverSettings(commonSettings);
      string newSettings = MakeNewSettings(drive, clearSettings);
      return odbcIniProvider.SetNewDriverSettings(newSettings);
   }
}
...
void InstallDriver(string drive)
{  
    SettingsManager settingsManager = new SettingsManager();

    if (settingsManager.SetNewSettings(drive))
    {
       MessageBox.Show("Installation completed");
    }
    else
    {
       MessageBox.Show("Error");
    }
}

Уже лучше, но такой подход тоже имеет свои недостатки. Например, что, если придется менять настройки не в файле, а в реестре? Придется переписывать SettingsManager, добавляя в него новый метод либо еще что-то в таком же духе... Давайте избавимся от такого рода зависимости сразу же. Для этого выделим интерфейс ISettingsProvider для классов, которые будут отвечать за конкретные способы получения и установки настроек:


interface ISettingsProvider
{
    string GetSettings();
    bool SetSettings(string new_settings);
}

И сразу же перепишем наш OdbcIniProvider под этот интерфейс:


class OdbcIniProvider : ISettingsProvider
{
    public string GetSettings() {...}
    public bool SetSettings(string new_settings) {...}
}

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


class SettingsManager
{
    private ISettingsProvider settingsProvider;
    public void SetSettingsProvider(ISettingsProvider _settingsProvider)
    {
       settingsProvider = _settingsProvider;
    }
...
}

В итоге, получилось следующее:


class SettingsManager
{...
    public bool SetNewSettings(string drive)
    {     
       string commonSettings = settingsProvider.GetSettings();
       string clearSettings = GetClearDriverSettings(commonSettings);
       string newSettings = MakeNewSettings(drive, clearSettings);
       return settingsProvider.SetSettings(newSettings);
    }
}
...
void InstallDriver(string drive)
{     
    SettingsManager settingsManager = new SettingsManager();
    settingsManager.SetSettingsProvider(new OdbcIniProvider());
    if (settingsManager.SetNewSettings(drive))
    {
        MessageBox.Show("Installation completed");
    }
    else
    {
       MessageBox.Show("Error");
    }
}

Теперь выглядит лучше, но... а что, если форматирование настроек будет различаться? Просится, просится класс SettingsFormatter, реализующий интерфейс ISettingsFormatter... Пусть это будет домашним заданием ;)

10 поговорок, которые должен знать каждый программист

2010-06-16T12:27:00.033+03:00

Перевод поста "10 Programming Proverbs Every Developer Should Know" Кевина Панга. Оригинал тут

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

1. Нет дыма без огня

Расслабьтесь, это, скорее всего, очередные учения у пожарников :)

Плохо спроектированный код, как правило, имеет некоторые общие признаки:
1) Гигантские классы и/или методы
2) Большие блоки закомментированного кода
3) Дублирование логики
4) Глубоко вложенные if/else блоки
Разработчики часто называют это как "код с душком" (code smells), но я считаю, что термин "коптящий код " или "дымящийся код " больше выражает уровень опасности, которой обладает данный код. Если вы не исправите проблему, лежащую в основе, позже она вернется, чтобы сжечь вас.

2. Унция профилактики стоит фунта лечения

Хорошо, уговорили :)

Автомобильная компания Toyota в 1980-х прославилась эффективностью благодаря революционному подходу к борьбе с браком. Каждый работник получил возможность остановить производство, если заметит проблему в своем секторе. Идея заключалась в том, что лучше остановить производство и исправить проблему как можно раньше, чем продолжать производство бракованных деталей, замена / починка / аннулирование которых позже обойдется гораздо дороже.
Программисты часто делают неверное предположение, что продуктивность = быстрое производство кода. Многие программисты принимаются кодировать без предварительного обдумывания дизайна. К сожалению, подход Leeroy Jenkins к разработке программного обеспечения приводит к неряшливому и хрупкому коду, который требует постоянного контроля и патчей - даже, если требуется заменить всего одну строчку. Таким образом, производительность должна измеряться не только временем, которое затраченным на написание кода, но и временем, затраченным на его отладку. Быстрый выигрыш может обернуться дорогостоящими потерями, если не быть осторожным.

3. Не кладите все яйца в одну корзину

Bus factor для команд разработчиков определяется как "общее количество ключевых программистов, недееспособность которых (например, если попадут под автобус) повергнет проект в такой хаос, что его дальнейшее развитие станет невозможным."
Иначе говоря, что произойдет, если вы потеряете главного разработчика команды? Будут ли дела идти как обычно дальше или всё остановится?
К сожалению, большинство команд разработчиков ожидает второй вариант. Такие команды превращают своих программистов в доменных экспертов, которые занимаются только теми вопросами, которые попадают в область их компетенции. На первый взгляд, это довольно разумный подход. Если такое работает в автомобилестроении, почему бы и не для команд разработчиков? В конце концов, неразумно ожидать, что каждый член команды будет разбираться во всех нюансах, имеющихся в приложении, да?
Проблема в том, что разработчика нельзя просто взять и заменить. Этот метод хорошо работает до тех пор, пока все члены команды вместе, но сразу же перестает работать, как только доменный эксперт выбывает из команды из-за перехода в другое место, болезни или если его вдруг собьет автобус. Крайне необходимо, чтобы команда имела резерв. Ревизии кода, парное программирование, общее владение - благодаря этим практикам каждый член команды хотя бы поверхностно будет знаком с другими частями разрабатываемой системы, а не только с той частью, разработкой которой он занимается.

4. Что посеешь, то и пожнешь

"Программист-прагматик" о теории разбитых окон:

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

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

5. Поспешишь - людей насмешишь

Менеджеры, клиенты и программисты становятся более нервными с каждым днем. Все должно быть сделано, и сделано должно быть сейчас. Из-за этого все труднее бороться с соблазном использовать хаки и быстрые решения.
Нет времени для тщательного юнит-тестирования новой фичи? Ладно, это работает для одного написанного теста. Мы всегда сможем вернуться к этому позже.
Загадочная ошибка при обращении к свойству Y объекта? Обернем этот кусок кода в try/catch. Мы должны ловить рыбу побольше!
Знакомо? Все мы иногда делаем так. В некоторых случаях это простительно. В конце концов, у нас есть сроки и менеджеры с клиентами, которых надо удовлетворить. Но если начать злоупотреблять этим, то очень скоро вы погрязнете в ненадежном коде, полном хотфиксов, дублирующейся логики, непротестированных решений и оберточной обработки ошибок. Вы должны найти золотую середину межды "сделано" и "правильно сделано".

6. Семь раз отмерь, один раз отрежь

Термин "Гибкая разработка" слишком часто используется и злоупотребляется программистами как оправдания для пропуска фазы планирования /проектирования разработки программного обеспечения. Мы творцы, и поэтому мы получаем удовольствие, видя реальный прогресс в конечном продукте. Удивительно, что UML-диаграммы и case-средства не могу удовлетворить это желание. Поэтому мы, разработчики, зачастую начинаем кодировать без малейшего понятия, что мы делаем и куда мы движемся. Это как пойти обедать, когда еще не решил, куда хочешь пойти. Ты голоден и хочешь как можно скорее найти ресторан и заказать столик. Вместо этого, ты садишься в свою машину и думаешь, что по дороге что-нибудь решишь. В итоге, получается дольше, потому что ты ездишь зигзагами и остановишься в ресторане, в котором будут долго готовить. В конце концов, ты, вероятно, получишь свою еду :) , но, скорее всего, мясо будет не таким, как ты хотел, и все это займет больше времени, чем, если бы ты предварительно позвонил и заказал столик в ресторане, в который бы хотел пойти.

7. Когда твой инструмент - молоток, то все похоже на гвозди

А ведь я говорил, что для этого проекта нужен Active Record!

Программисты имеют склонность быть ограниченными в выборе инструментов. Если однажды что-то сработало для одного проекта, то мы будем настаивать в использовании этого же во всех последующих проектах. Изучить что-либо новое может быть трудно и, порой, безрезультатно. Мы думаем "Это будет проще, если я все сделаю, как в прошлый раз." Немного таких мыслей, и мы просто будем использовать то, что есть, даже если это не совсем подходит в данном случае.
Легко использовать то, чем умеешь пользоваться, но в долгосрочной перспективе лучше выбирать более подходящие инструменты. Иначе вы будете забивать квадратные колышки в круглые отверстия до конца вашей карьеры.

8. Молчание - знак согласия

I see nothing. Nuh-thing.

Это связано и с теорией разбитых окон, и инертностью программирования, только в большем масштабе. Сообщество программистов именно сообщество. Профессия отражается на каждом. Чем больше плохого кода "на свободе", тем больше он преобретает статус кво. Если вы не пытаетесь хороший, чистый, отвещающий требованиям SOLID код, вам придется работать с ним день за днем сначала.
Кроме того, если вы увидели плохо спроектированный код, вы должны попытаться исправить это вместе с автором кода. Хочу отметить, в такой ситуации нужно использовать чувство такта. В общем, программисты признают, что не знают всего о разработке программного обеспечения, и оценят ваш жест. Мы все получаем пользу, когда помогаем друг другу. Закрывая глаза на проблемы, мы только усугубляем их.

9. Лучше синица в руке, чем журавль в небе

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

10. С властью приходит и ответственность

Программное обеспечение, бесспорно, стало неотъемлемой и важной частью нашей жизни. Поэтому практика разработки хорошего программного обеспечения важна как никогда. Одно дело, когда имеется ошибка в игре Пинг-пог, и совсем другое, если ошибка в системе навигации космических кораблей или в системе управления воздушными полетами. Slashdot недавно опубликовал статью, в которой рассказывается, как из-за незначительных сбоев в Google News акционеры потеряли $1.14 биллиона. Случаи, наподобие этого, показывают, какой властью мы наделены. Немного страшно представить, что код, который вы пишете сегодня, хотите вы того или нет, однажды может быть повторно использован в критически важной системе. Пишите соответственно.

Топ 10 вещей, которые бесят программистов

2010-06-15T18:38:00.016+03:00

Перевод поста "Top 10 Things That Annoy Programmers" Кевина Панга. Оригинал тут

10. Комментарии, которые объясняют "как", а не "почему"

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


r = n / 2; // Set r to n divided by 2
// Loop while r - (n/r) is greater than t
while ( abs( r - (n/r) ) > t ) {
r = 0.5 * ( r + (n/r) ); // Set r to half of r + (n/r)
}

Вы поняли, что делает этот код? Я - нет. Проблема в том, что все комментарии объясняют что код делает, а не зачем он это делает.
Давайте рассмотрим этот же код, откомментированный по другой методологии:


// square root of n with Newton-Raphson approximation
r = n / 2;

while ( abs( r - (n/r) ) > t ) {
r = 0.5 * ( r + (n/r) );
}

Теперь намного лучше! Мы до сих пор не понимаем, что тут происходит, но у нас хотя бы есть точка отсчета.
Предназначение комментариев - помочь человеку, читающему код, понять код, а не синтаксис. Вполне можно предположить, что человек, читающий код, имеет базовое представление о том, как работают циклю, и комментарии типа “// iterate over a list of customers” ни к чему. С чем читатель точно не знаком, так это почему ваш код работает и почему вы выбрали именно это решение, а не другое.

9. Когда программиста отвлекают

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

8. Ползучий фичуризм (Scope creep)

Из Википедии:

Scope creep (also called focus creep, requirement creep, feature creep, and sometimes kitchen sink syndrome) in project management refers to uncontrolled changes in a project’s scope. This phenomenon can occur when the scope of a project is not properly defined, documented, or controlled. It is generally considered a negative occurrence that is to be avoided.

Ползучий фичуризм превращает относительно простые вещи в ужасно сложные и требующие много времени. Всего лишь несколько невинных нажатий кнопок на клавиатуре для ребят, составляющих требования, и фичи поползли:
1. Версия 1. Показывать карту локации
2. Версия 2. Показывать 3D карту локации
3. Версия 3. Показывать 3D карту локации и чтоб пользователь просматривать карту с эффектом полета через карту

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

7. Менеджеры ничего не смыслят в программировании

Менеджмент - нелегкое дело. Люди изматывают - все мы такие хрупкие, непостоянные и каждый из нас должен быть на первом месте. Поддерживать в большой группе людей дух удовлетворения и сплоченности - тяжелая задача. Но это вовсе не означает, что менеджеры имеют привелегию не разбираться в том, что их подчиненные делают. Когда менеджер не понимает базовых концепций нашей (программистов) работы, появляются scope creep'ы, нереалистичные сроки и взаимное разочарование. Это довольно распространенная жалоба среди программистов и источник беспокойства.

6. Документирование собственных приложений

Заранее хочу сказать, что я знаю о существовании большого количества приложений для генерации документации, но по собственному опыту могу сказать, что они хороши только для документирования API. Если вы разрабатываете приложение, которое пользователи будут использовать ежедневно, то вам придется создать документацию, понятную для неспециалиста (т.е. как работает приложение, устранение проблем и тд).
Нетрудно заметить, что это наводит страх на программистов. Взгляните на open-source проекты. В чем все они дружно просят помочь? В составлении документации.
Думаю, что с уверенностью могу сказать, что говорю за всех программистов во всем мире, когда произношу фразу "Это может сделать кто-нибудь другой?"

5. Приложения без документации

Я никогда не говорил, что мы не лицемеры :) Программисты постоянно просят включить в проект библиотеки сторонних разработчиков. Для того, чтобы это сделать, нужна документация. К сожалению, как отмечалось в пункте 6, программисты не любят писать документацию. Да, ирония не обошла нас стороной.
Нет ничего более ужасного, чем пытаться воспользоваться сторонней библиотекой, не имея никаких предположений о том, что делает половина функций из API. Какая разница между poorlyNamedFunctionA() и poorlyButSimilarlyNamedFunctionB()? Нужно ли выполнять проверку на NULL перед доступом к полю PropertyX? Думаю, что все это придется выяснить методом проб и ошибок. Эх :(

4. Hardware

Любой программист, которого хоть однажды вызывали разобраться в непонятном сбое на сервере баз данных или выяснить, почему RAID-драйвер работает неправильно, знает, что такое аппаратные проблемы. Существует всеобщее заблуждение, что раз программист работает за компьютером, то он знает, как его чинить. Конечно, это может быть справедливо для некоторых программистов, но я думаю, подавляющее большинство из нас не волнует, что происходит после того, как код оттранслирован в сборку. Мы просто хотим, чтобы вещи работали так, как это задумано, чтобы мочь сосредоточиться на более высокоуровневых задачах.

3. Неопределенность

"Этот веб-сайт не работает". "Фича Х работает неправильно". Это ужасно, когда приходится иметь дело с такими запросами. Меня всегда удивляло раздражение пользователей, когда их просят воспроизвести проблему для программистов. Судя по всему, они не понимают, что описание "оно поломалось, почините это!" дает недостаточно информации для возможности исправить баг.
Программное обеспечение (в большей своей части) предсказуемо. Мы любим его таким. Помогите нам выяснить, где находится ошибка, вместо того, чтобы просто говорить "почините это".

2. Другие программисты

Программисты не всегда находят общий языка с другими программистами. Шокирует, но это правда. Тут можно составить отдельный топ-10 причин, поэтому я перечислю некоторые общие черты программистов, которые раздражают своих товарищей, а более детально расскажу об этом в отдельном посте:

Чрезмерная раздражительность
Неспособность понять, что есть время для обсуждения архитектуры системы, а есть время для ее реализации
Неспособность эффективного общения и запутанная терминология
Преувеличение собственного значения
Безразличие к коду и проекту

И последнее, но самое важное, номер один в списке вещей, раздражающих программистов...

1. Наш собственный код 6 месяцев спустя

Смотрели ли вы с ужасом на ваш старый код? Как глупы вы были! И как вообще вы, знающий столько всего, могли написать ЭТО?! Сжечь его, пока никто не видел! :)
Но вы не один.
Мир программирования постоянно меняется. То, что мы считаем лучшими практиками сегодня, завтра уже может устареть. Невозможно написать идеальный код, потому что стандарты оценки кода меняются каждый день. Трудно принять тот факт, что ваша работа, такая прекрасная сегодня, может быть высмеяна завтра. Раздражает ощущение, что мы мало чего достигли, несмотря на изучение новых тулз, моделей, фреймворков и лучших практик. Меня это раздражает больше всего. Слабое место того, чем мы занимаемся, в необходимости внесения изменений, поэтому я не могу избавиться от ощущения, что я один из монахов, рисующих песком.

Ну, вот и все. Топ 10 вещей, которые бесят программистов. Если вы чувствуете, что я упустил что-либо, напишите об этом в комментариях!

Библиотека

2010-05-31T09:04:00.003+03:00

Д. Нильссон. Применение DDD и шаблонов проектирования (скачать)
Книга о разработке корпоративных программных приложений в среде .NET с применением шаблонов проектирования. В ней описаны: как строится четкая и удобная, с точки зрения сохраняемости, модель предметной области (Domain Model), рассматриваются вопросы проектирования, ориентированного на предметную область (DDD, или Domain-Driven Design), разработки посредством тестирования (TDD, или Test-Driven Development), объектно-реляционное преобразование, т.е. методы, которые относятся к ключевым технологиям разработки программного обеспечения. По мере развития и усложнения технологии все большее значение приобретают вопросы правильного применения методов проектирования, которые налаживают взаимосвязь между пользователями и разработчиками, предметной областью и программным обеспечением, логикой и хранением информации, проектировщиками баз данных и программистами.
Большинство примеров кода, в книге, представлено на языке C#, но материал окажется полезным и пользователей платформы Java.
Книга адресована опытным разработчикам архитектуры и прикладного программного обеспечения уровня предприятий, в том числе и в среде .NET.
Р. Мартин, Д. Ньюкирк. Быстрая (гибкая) разработка программ: принципы, шаблоны, практика (скачать)
Книга рассказывает о различных методиках быстрого (и даже экстремального) программирования. Изложение начинается с обзора основных понятий экстремального программирования и завершается готовыми программами, применяемыми на практике. В каждой главе приведены примеры кода на языках программирования Java и C++. Книга будет полезной руководителям групп программистов, нацеленных на быструю разработку коммерческих программных проектов, характеризующихся высоким уровнем качества и минимальной себестоимостью.

Комментарии в коде

2010-05-30T22:58:00.012+03:00

Все мы не раз слышали, что код нужно комментировать, чтобы в нём потом можно было разобраться. Неопытные программисты часто возражают : "Это мой код, и я знаю, что он делает, и не забуду даже через полгода, что значит переменная k в выражении empS += k*arr[i] + bon[i]!" И при этом совершенно не учитывается, что кроме них, этот код могут править другие программисты - те бедолаги, которым придется сопровождать этот код. Но, опять же, комментарии, написанные, лишь бы написать, чтоб не цеплялись, - это еще хуже, чем отсутствие комментариев.

При плохом выполнении комментирование является пустой тратой времени и иногда причиняет вред.
С.Макконнелл

Например, в следующем коде комментарии совершенно бесполезны, потому что совершенно ничего не говорят:


int k = getKoeff(m); /*инициализируем переменную k значением, возвращаемым методом getKoeff */
double empS = 0.0; //инициализируем переменную empS нулем
for(int i=0; i<getWNub(m); i++)
{
empS +=k*arr[i] + bon[i]; //вычисляем сумму в цикле
}

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

Хороший код сам является самой лучшей документацией. Если код настолько плох, что требует объемных комментариев, попытайтесь сначала улучшить его.
С.Макконнелл

Я не призываю отказаться от комментариев в коде, я призываю к написанию ясного кода, который легко понять и модифицировать даже по прошествии длительного периода времени.
Что в моем понимании "ясный код"? Это, конечно же, самодокументирующийся код. Например, предыдущий кусок кода можно переписать так:


int koefficient = getSalaryKoefficient(monthNumber);
double employeeSalary = 0.0;
int workingDaysInCurrentMonth = getWorkingDaysNumber(monthNumber);
for(int dayNubmer=0; dayNumber<workingDaysInCurrentMonth; dayNubmer++)
{
employeeSalary +=koefficient*workingHours[dayNubmer] + dayBonus[dayNubmer];
}

Что изменилось в коде? Всего лишь имена переменных и методов, но этот код, в отличие от первого его варианта, понятен без комментариев. Имена переменных и методов говорят сами за себя, им не нужны никакие комментарии. Такими же должны делать имена классов, интерфейсов, констант, перечислений, элементов перечислений и т.д. О том, насколько важно правильно выбирать имена и как это делать, можно почитать в книге "Совершенный код" С. Макконнелла.

Почувствовав потребность написать комментарий, попробуйте сначала изменить структуру кода так, чтобы любые комментарии стали излишними...
М.Фаулер

Как менять структуру кода и когда это нужно делать, можно почитать в книге Мартина Фаулера "Рефакторинг. Улучшение существующего кода". Но, конечно же, есть несколько случаев, когда следовать вышеприведенной цитате не нужно. Во-первых, когда код делает не очевидные вещи, например (пример взят из книги "Совершенный код" С.Макконелла):


for(element = 0; element<elementCount; element++)
{
/*Для деления на 2 используется операция сдвига вправо. Это сокращает время выполнения цикла на 75% */
elementList[element] = elementList[element] >>1;
}

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


//Цвет фона по умолчанию - белый
itemBgColor = Color.FromAGB(255,255,255);

Этот код лучше будет даже переписать следующим образом:


const Color DEFAULT_BG_COLOR = Color.FromAGB(255,255,255);
...
itemBgColor = DEFAULT_BG_COLOR;

Кроме того, следует комментировать использование недокументированных возможностей или исправление обнаруженных ошибок - ведь в следующих версиях системы этих возможностей может и не быть, а ошибки могут быть исправлены :)
Полезным может оказаться документирование ограничений, если они не заданы константами с говорящими именами, а используются в коде как есть - в виде чисел. Но с таким настоятельно советую бороться :)
В своей практике кроме всего выше перечисленного я предпочитаю давать краткое описание методу перед началом его кодирования, при этом использую очень замечательную возможность документирования кода в Visual Studio. Это выглядит так:


/// <summary>
/// Возвращает следующий по номеру ваучер по отношению к номеру текущего ваучера
/// </summary>
/// <returns>VoucherItem</returns>
public VoucherItem GetNextVoucherItem()
{ 
return VoucherRepository.GetNextVoucher(this.VoucherNumber);
}

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

Пишите код, исходя из того, что все программисты, которые будут сопровождать вашу программу, - склонные к насилию психопаты, знающие, где вы живёте.
С.Макконнелл

Регулярные выражения

2010-05-29T10:10:00.003+03:00

Для облегчения работы с регулярными выражениями я использую бесплатную утилиту от Rad Software - Regular Expression Designer.

Среди фич можно выделить следующие:

Удобное отображение результата выполнения выражения - строится многоуровневое дерево для Matches, Groups и Captures. При клике на ветку дерева в исходном тексте выделяется фрагмент, соответствующий результату.

Очень удобно сделано окно "Language Element" - справочник по регулярным выражения всегда под рукой. Но для не владеющих английским (о_О) он может оказаться не очень полезным.

Найти более подробное описание программы и скачать ее можно на сайте разработчика - http://www.radsoftware.com.au/regexdesigner/

Mpress VS Avira

2010-05-10T11:15:00.003+03:00

Недавно к своему сожалению обнаружила, что некоторые антивирусы, в особенности Avira, распознают exe-файлы, запакованные с помощью пакера Mpress, о котором упоминалось ранее в этом блоге, как вирус.

О колбасе :)

2010-05-02T10:58:00.004+03:00

Понравился анекдот о колбасе и яйцах :)

Жена посылает мужа-программиста в магазин:
- Дорогой, купи, пожалуйста, палку колбасы, и если будут яйца, то купи десяток.
Через полчаса программист возвращается с десятью палками колбасы.
Жена:
- Что это?! Зачем ты купил столько колбасы?
Программист:
- Ну так яйца-то были...

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

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

Из-за чего получаются такие ошибки? Как они закрадываются в спецификации? Есть несколько ответов на эти вопросы: от банального не доглядели до несогласованности требований. Всем известно, что требования в процессе разработки меняются, и после каждого изменения или дополнения нужно проверять, не получилось ли так, что часть новых требований не согласуется со старыми. Так же есть такие факторы, как взаимонепонимание и "требования по умолчанию". Разработчики, которые не являются специалистами в предметной области разрабатываемого продукта, могут не знать некоторых деталей, а для заказчика (или эксперта, учавствующего в разработке спецификации) данные детали являются делом обыденным, само собой разумеющимся. "Требования по умолчанию" - это опасные требования. Их даже может и не быть в спецификации, потому что это "само собой разумеющиеся" вещи, о них просто забывают. А для разработчиков эти вещи далеко не очевидны, так же как и для обычного человека не очевидно то, что для разработчика ясно как 0 и 1.

Как бороться с ошибками в спецификации? Существует множество способов проверки корректности спецификации. Главное, задействовать эти способы вовремя, после выработки требований и перед началом проектирования или после очередного внесения изменений в спецификации.

Вебкаст "Технический обзор LINQ"

2010-04-16T09:57:00.003+03:00

Отличный вебкаст Романа Здебского "Технический обзор LINQ".
Доклад с конференции «Платформа – 2009». В докладе раскрывается принципиально новый подход к построению запросов и трансформации данных (объекты, реляционные структуры, XML) в .NET-языках программирования. Основной темой обсуждения служит использование преимуществ работы с проекциями данных в стиле реляционных движков в полностью типизированном окружении с контролем ошибок на этапе компиляции кода.