понедельник, 24 декабря 2012 г.

О вреде изменяемых значимых типов. Часть 2

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

понедельник, 17 декабря 2012 г.

DI Паттерны. Constructor Injection

Когда речь заходит о внедрении зависимостей (Dependency Injection), то у большинства разработчиков в голове возникает образ конструктора, через который эта зависимость передается в виде интерфейса или абстрактного класса. Именно об этом виде управления зависимостей писал Боб Мартин в своей статье Dependency Inversion Principle, поэтому не удивительно, что он является самым известным.

Описание

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

понедельник, 3 декабря 2012 г.

Наследование vs Композиция vs Агрегация

Между двумя классами/объектами существует разные типы отношений. Самым базовым типом отношений является ассоциация (association), это означает, что два класса как-то связаны между собой, и мы пока не знаем точно, в чем эта связь выражена и собираемся уточнить ее в будущем. Обычно это отношение используется на ранних этапах дизайна, чтобы показать, что зависимость между классами существует, и двигаться дальше.

image

Рисунок 1. Отношение ассоциации

среда, 21 ноября 2012 г.

Управление зависимостями

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

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

вторник, 13 ноября 2012 г.

[ANN]ounce книг 11’2012

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

Это не список рецензий, а всего лишь перечень книг, которые я сам с удовольствием прочитаю в ближайшее время. Так что мое мнение основано скорее на имени автора и какого-то «средневзвешенного» мнения народа в наших с вами интернетах, и оно вполне может измениться после более близкого знакомство с этими творениями. Тем не менее, все они, как минимум, заслуживают нашего с вами внимания и достойны добавиться в бесконечный список книг на полке “to-read”.

пятница, 26 октября 2012 г.

Фреймворки, библиотеки и зависимости

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

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

И это очень правильное определение. Фреймворк определяет окружение, используя «push» модель взаимодействия с приложением: в большинстве случаев фреймворк сам вызывает код приложения через механизм виртуальных методов, методы обратного вызова и т.п. Пользователю нужно лишь «вклинить» свой собственный код в «слоты», представленные фреймворком (не зря ведь в русскоязычном сообществе для термина “framework” используется «каркас»).

вторник, 16 октября 2012 г.

Немного о сборке мусора и поколениях

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

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

Основная идея поколений заключается в том, что мы собираем «мусор» молодого поколения значительно чаще и значительно быстрее за счет того, что анализируем не все объекты управляемой кучи (которых может быть очень и очень много), а только объекты этого молодого поколения.

четверг, 11 октября 2012 г.

Источники о сборке мусора в .NET

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

Книги

  1. Under the Hood of .NET Memory Management by Chris Farrell and Nick Harrison
    Книга не большая (225 страниц), посвященная сборке мусора на платформе .NET и описанию типовых проблем работы с памятью и советов по их устранению. Очень неплохая книга, с достаточной глубиной изложения, но без особых дебрей и заумностей; основные моменты изложены хорошо, но я бы посоветовал относиться с осторожностью к некоторым советам по оптимизации и не забывать, что к ним нужно приступать только после профилирования.
    Электронная версия книги свободна доступна в Сети.
  2. Advanced .NET Debugging by Mario Heward
    Книга не по сборке мусора непосредственно, но в ней покрыты очень многие низкоуровневые детали, которые можно «пощупать» с помощью отладки. Очень толково написано, хотя иногда бывает перебор с количеством низкоуровневых деталей.
  3. Pro .NET Performance by Sasha Goldstein at al
    Интересная книга по производительности в целом, но и с разделом по сборке мусора. Книга кажется очень интересной, а точное мнение о ней, я надеюсь у меня появится через месяц-другой после ее прочтения.
  4. CLR via C# by Jeffrey Richter
    Классика. Хотя в этом плане здесь не менее полезной будет практически любая хорошая книга по языку C# и платформе .NET. C# 4 Unleashed, например, тоже подойдет для знакомства с этой темой.

понедельник, 24 сентября 2012 г.

Кэширующий декоратор на деревьях выражений

Совсем недавно возникла такая задача. Предположим у нас есть класс, предоставляющий доступ к некоторым удаленным ресурсам. Поскольку эти ресурсы расположены достаточно далеко, то результатами методов провайдера являются задачи (объектами класса Task или Task<T>).

public interface ICustomProvider

{

    Task<int> GetNextId();

    Task<string> GetCustomerName(int id);

    Task<Order> GetOrder(int orderId, string customerName);

}

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

среда, 19 сентября 2012 г.

Структуры и конструкторы по умолчанию

Я решил немного развить тему, поднятую в Google+ о том, почему большинство языков программирования для платформы .NET не позволяют объявлять конструкторы по умолчанию для структур (т.е. для значимых типов).

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

Вот простой пример, как вы ответите на следующий вопрос: сколько значимых типов из .NET Framework содержит конструкторы по умолчанию? Интуитивным ответом кажется "все", и будете не правы, поскольку на самом деле, ни один из значимых типов .NET Framework не содержит конструктора по умолчанию.

понедельник, 3 сентября 2012 г.

Moq. Примеры использования

DISCLAIMER. Все приведенные здесь примеры можно найти на github.

Moq – это простой и легковесный изоляционный фреймврк (Isolation Framework), который построен на основе анонимных методов и деревьев выражений. Для создания моков он использует кодогенерацию, поэтому позволяет «мокать» интерфейсы, виртуальные методы (и даже защищенные методы) и не позволяет «мокать» невиртуальные и статические методы.

ПРИМЕЧАНИЕ
На рынке существует лишь два фрейморка, позволяющих «мокать» все, что угодно. Это TypeMockIsolator и Microsoft Fakes, доступные в Visual Studio 2012 (ранее известные под названием Microsoft Moles). Эти фреймворки, в отличие от Moq, используют не кодогенерацию, а CLR Profiling API, что позволяет вклиниться практически в любой метод и создать моки/стабы даже для статических, невиртуальных или закрытых методов.

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

вторник, 28 августа 2012 г.

Параметризованные юнит тесты

DISCLAIMER: все примеры в этой статье написаны с использованием NUnit, однако все их можно применять и с другими тестовыми фреймворками, как xUnit и MbUnit.

Юнит тесты – это отличная штука; они помогают навести порядок в дизайне приложения, являются незаменимым средством при рефакторинге, позволяют делать процесс разработки более управляемым и т.п. Но как и любой другой инструмент юнит тесты тоже можно использовать неправильно. Если с плохо поддерживаемым кодом все мы хоть как-то привыкли бороться, поскольку сталкиваемся с ним постоянно, но когда на каждую строку г#%@&-кода приходится еще пара строк таких же по качеству тестов, то положение становится каким-то совсем уж невеселым.

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

понедельник, 20 августа 2012 г.

Об идиоме RAII и классе ReaderWriterLockSlim

Идиома RAII (Resource Acquisition Is Initialization) берет свое начало в языке С++ и заключается в том, что некоторый ресурс захватывается в конструкторе объекта, и освобождается в его деструкторе. А поскольку деструктор локальных объектов вызывается автоматически при выходе из метода (или просто из области видимости) не зависимо от причины (нормальное завершение метода или при генерации исключения), то использование этой идиомы является самым простым и эффективным способом написания сопровождаемого C++ кода, безопасного с точки зрения исключений.

При переходе к «управляемым» платформам, таким как .NET или Java, эта идиома в некотором роде теряет свою актуальность, поскольку освобождением памяти занимается сборщик мусора, а именно память была самым популярным ресурсом, о котором приходилось заботиться в языке С++. Однако поскольку сборщик мусора занимается лишь памятью и никак не способствует детерминированному освобождению ресурсов (таких как дискрипторы операционной системы), то идиома RAII все еще применяется и в .NET, и в Java, пусть мало кто из разработчиков знает об этом замысловатом названии.

вторник, 14 августа 2012 г.

Интересное из MSDN Magazine 2009-2012

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

Но, несмотря на это, в MSDN Magazine писали и продолжают писать очень интересные авторы и многие статьи заслуживают внимания. Поэтому я решил просмотреть выпуски за последние 4 года и выписать заинтересовавшие меня статьи по разным тематикам. Поскольку облака, веб, WP7 и SQL Server мне лично не слишком интересны, то в этой подборке ссылок информации по этим темам не будет (так что если это интересно вам, то придется проделать подобную же процедуру самостоятельно). В мой же список вошли следующие темы: многопоточное и параллельное программирование, .NET in general, паттерны и практики, распределенные системы, функциональное программирование и некоторые другие темы.

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

вторник, 7 августа 2012 г.

Перегрузка и наследование

Существует определенный набор возможностей в любом языке программирования для понимания которых нужно просто знать, как они реализованы. Вот, например, замыкания; это не сверх сложная концепция, но знание того, как этот зверь устроен позволяет делать определенные выводы относительно поведения замыканий с переменными цикла. Тоже самое касается вызова виртуальных методов в конструкторе базового класса: здесь нет одного правильного решения и нужно просто знать, что именно решили разработчики языка и будет ли вызываться метод наследника (как в Java или C#), или же «полиморфное» поведение в конструкторе не работает и будет вызываться метод базового класса (как в С++).

Еще одним типом проблемы у которой нет идеального решения, является совмещение перегрузки методов (overloading) и переопределения (overriding) метода. Давайте рассмотрим следующий пример. Предположим, у нас есть пара классов, Base и Derived, с виртуальным методом Foo(int) и невиртуальным методом Foo(object) в классе Derived:

среда, 1 августа 2012 г.

Duck typing или “так ли прост старина foreach?”

Я думаю, что многие разработчики знают, что цикл foreach в языке C# не так прост, каким он кажется на первый взгляд. Для начала давайте ответим на вопрос: «А что нужно, чтобы конструкция foreach успешно компилировалась?». Интуитивным ответом на этот вопрос кажется что-то типа: «Реализация классом интерфейса IEnumerable или IEnumerable<T>.». Однако, это не так, ну, или не совсем так.

Полный ответ на этот вопрос такой: «Для того чтобы конструкция foreach успешно компилировалась необходимо, чтобы у объекта был метод GetEnumerator(), который вернет объект с методом MoveNext() и свойством Current, а если такого метода нет, то тогда будем искать интерфейсы IEnumerable и IEnumerable<T>».

Причин у такого «утиного» поведения две.

суббота, 28 июля 2012 г.

О дизайне. Часть 2. Практические примеры

Как мы обсудили в прошлый раз, дизайн штука не простая; постоянно приходится держать в голове кучу всяких вариантов и стараться найти компромисс среди множества разных требований, раздирающих ваше элегантное решение на части. С одной стороны, хочется, чтобы решение было простым в сопровождении, хорошо расширяемым, с высокой производительностью, при этом оно должно быть понятным не только его автору, но еще как минимум одному человеку; хочется, чтобы решение ело мало памяти и не нарушало ни одного из 100 500 принципов ООП, ну и, самое главное, мы хотим его закончить хотя бы в этом году, хотя менеджер постоянно твердит, что оно должно было быть готово еще месяц назад.

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

понедельник, 16 июля 2012 г.

О дизайне

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

Отношение к этапу проектирования (дизайна) может быть самым разным, начиная от подхода, принятого на ранних этапах развития методологии XP, когда считалось, что дизайн и архитектура – это динозавры, которым нет места в динамично развивающемся мире agile разработки. Многие и сейчас не задумываются о дизайне решения, считая, что итеративный процесс разработки + рефакторинг сделают все за нас и хороший дизайн появится сам собой.

Есть и другая крайность, когда команда можем потратить недели в поисках идеального решения (Святого Грааля архитектора), когда дизайн будет способен «расширяться» во всех возможных направлениях, и быть настолько «гибким», что реализовать его не будет никакой возможности.

четверг, 28 июня 2012 г.

Контракты vs Юнит тесты

DISCLAIMER: Эта заметка подразумевает наличие у читателя базовых знаний о юнит тестах, в чем автор этих строк не сомневается, а также базовых знаний о проектирование по контракту, которые можно пополнить отсюда.

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

Итак, давайте вкратце рассмотрим, в каком именно месте находится пересечение контрактов и юнит тестов, и постараемся ответить на вопрос: являются ли постусловия избыточными при наличии юнит тестов?

вторник, 5 июня 2012 г.

Лучшая метрика для определения качества кода

Небезызвестный камрад Боба Мартин в своей книге «Чистый код» использует очень интересную метрику для определения качества кода. В оригинальном издании книги эта метрика определялась количеством WTFs/minute, замеченных во время инспекции кода (code review).

Однако при переводе произошла досадная ошибка и наши локализаторы вместо замечательной метрики, “WTFs/minute”, добавили, можно сказать, свою собственную метрику, чуждую отечественному разработчику: «количество чертей в секунду».

Любой опытный программист, который хотя бы раз в жизни проводил code review (или его замечательный код подвергался этой процедуре), знают, что никакими «чертями» в этом процессе и не пахнет. Во время чтения чужого кода непонимание и восхищение выражается самым разнообразным образом, но если уж адаптировать оригинальный термин к русскоязычной аудитории, то я бы сказал, что наиболее близким вариантом этой метрики является количество «чезанахов» в минуту.

вторник, 29 мая 2012 г.

Фриман и Фриман. Паттерны проектирования

DISCLAIMER: не проматывайте этот пост только из-за того, что обзор книг – это неинтересно. Здесь будет пяток интересных цитат и ряд других полезных мыслей!

Если спросить у десяти разработчиков о паттернах проектирования и о том, какая книга является лучшим источником информации по этой теме, то 9 из 10 назовут знаменитую книгу банды четырех и будут правы. GoF – является классическим каталогом паттернов в том виде, в котором он был описан Кристофером Александером 35 лет назад и все еще остается бесценным справочником для любого программиста.

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

понедельник, 21 мая 2012 г.

C++ 11 FAQ от Бьярна Страуструпа

Примечание переводчика

Данный FAQ переводится на русский язык с любезного разрешения его автора - Бьярне Страуструпа. На данный момент работа над оригиналом этого документа еще не закончена, поэтому по мере изменения или дополнения оригинала, будет изменяться и перевод. Все пожелания/замечания по качеству перевода присылайте по почте, либо через профиль Google.

По просьбам читателей, я выложил сверстанную в pdf версию перевода, а также оригинал перевода в docx формате.

В формате pdf: http://bit.ly/StroustrupFAQRus_pdf
В формате docx: http://bit.ly/StroustrupFAQRus_docx

Благодарности: огромное спасибо Володе Тихонюку за вычитку материала и ценные советы!

Последние изменения в оригинале: 23.02.2012

С++11 – принятый недавно новый ISO стандарт языка С++

Этот документ написан и поддерживается Бьярне Страуструпом (Bjarne Stroustrup). Конструктивные комментарии, поправки, ссылки и предложения всецело поддерживаются. Сейчас я работаю над полнотой материала и приведением в порядок ссылок.

C++11 – это стандарт языка С++ утвержденный Международной организацией по стандартизации (ISO) в 2011-м году. Предыдущие версии стандарта обычно называют C++98 или C++03. Различия между С++98 и С++03 настолько специфические и их настолько мало, что на них можно не обращать внимания.

Доступна последняя версия рабочего документа, и она близка к окончательной версии черновика стандарта, формально принятого единогласным решением (21-0) в августе 2011 года.

До официального утверждения, будущий стандарт называли C++0x. К сожалению, у меня пока что не было времени везде обновить имя стандарта, вы уж простите, и вообще, мне очень нравится название C++ 0x :-). Название “C++ 0x” осталось с тех давних пор, когда мы надеялись, что новый стандарт будет называться C++08 или C++09. Сейчас можно рассматривать “x” в имени, как признак шестнадцатеричного формата (т.е. C++0B == C++11).

Все официальные документы, связанные со стандартом C++11/C++0x можно найти на официальном веб-сайте комитета по стандартизации. Официальное имя комитета SC22 WG21.

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

понедельник, 7 мая 2012 г.

Инициализаторы объектов в блоке using

UPDATE: наткнулся на объяснение данного поведения Эриком Липпертом (подробности здесь).

Инициализаторы объектов (Object Initializers) – это полезная возможность языка C#, которая позволяет инициализировать необходимые свойства объекта прямо во время его создания. Поскольку синтаксически эта «фича» очень близка к инициализации объекта с передачей параметров через конструктор, многие разработчики начинают забивать на принципы ООП (в частности на понятие инварианта) и использовать ее, где только можно.

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

// position передается извне или настраиватся каким-то образом
long position = -1;
using (var file = new FileStream("d:\\1.txt", FileMode
.Append)
                        {
                           
// Мы точно знаем, что нужные данные расположены
                            // с некоторым сдвигом!
                            Position = position
                        })
{
   
// Делаем чего-то с файлом
}

В данном фрагменте внутри директивы using создается ресурс (файл) и устанавливается одно из его свойств (Position) с помощью инициализатора объекта. При этом самое главное в этом коде то, что setter этого свойства может генерировать исключение.

четверг, 19 апреля 2012 г.

О повторном использовании кода

Сегодня существуют разные мнения по поводу успешности объектной технологии. С одной стороны, большинство современных mainstream языков программирования являются объектно-ориентированными, с другой стороны, нередко можно услышать критику ООП, дескать, объектно-ориентированное программирование «провалилось» и не оправдало тех надежд, которые были возложены на нее индустрией разработки ПО. Все, мол, ожидали наступления вселенского счастья в виде увеличения повторного использования, упрощения сопровождения, да и вообще, обещали, что думать придется кому-то другому, а я за это буду деньги получать.

Причин у подобных разочарований тоже несколько. Во-первых, такое отношение к ООП может быть следствием завышенных ожиданий, а ведь Фред Брукс еще двадцать лет назад писал о том, что не стоит ждать «серебряных пуль», способных на порядок увеличить продуктивность труда программиста. Во-вторых, никто из серьезных сторонников ООП (типа Гради Буча или Бертрана Мейера) не обещали, что все будет просто. ООП – это не волшебная палочка, которая сделает из любого УГ конфетку, даже обертку которой можно будет использовать повторно.

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

понедельник, 9 апреля 2012 г.

Видеоматериалы, блоги и подкасты для .NET разработчика

Видеоматериалы

В одной из своих статей Бьёрн Страуструп (папа С++) признался, что он не признает видео материалы в качестве источника для самообразования. И с ним сложно не согласиться, когда речь касается изучения с нуля языка программирования или технологии. Я правда сомневаюсь, что можно одолеть такого монстра, как С++ или стать гуру WPF лежа на диване и просматривая обучающее видео типа «Узнай все за 24 часа». Но если вы ставите себе цель познакомиться с некоторой технологией или новой возможностью языка программирования, или просто послушать философско-компьютерные размышления умного товарища, то в этом случае веб-касты, записи конференций или другой вид видеоматериалов может быть очень кстати.

Если постараться найти обучающее видео (а не просто интервью или выступления с конференций) для .NET разработчика, то первым и, пожалуй, единственным источником будет Pluralsight.

Pluralsight

Большая часть курсов Pluralsight посвящены технологиям компании Майкрософт: .NET, C#, F#, WCF, SQL Server, Windows Azure, Windows 8 и т.д. Другие же курсы посвящены фундаментальным знаниям и не привязаны к конкретным технологиям: HTTP Fundamentals, NoSQL, Source Control, практики разработки ПО и т.п.; есть даже курсы, посвященные Java, Ruby, разработке под iOS и Android (одним словом, в каталоге можно найти курс практически по всем популярным нынче баззвордам).

четверг, 5 апреля 2012 г.

Что значат для вас юнит-тесты?

С технической точки зрения юнит-тесты – это очень простой инструмент, основанный на паре несложных концепций: (1) тестируемый класс, (2) набор тестовых методов, завернутых в некоторый класс и (3) набор методов, с помощью которых можно удостовериться в том, что состояние тестового класса соответствует (или не соответствует) некоторому значению.

Это очень простая штуковина, которая может кардинальным образом повлиять на процесс разработки в целом. С одной стороны существует TDD (“test-first approach), при котором тесты «драйвят» не только процессом кодирования, но и процессом проектирования (т.е. дизайном системы). С другой стороны существуют разработчики с противоположной точкой зрения, которые считают юнит-тесты пустой тратой времени, потому что они не приносят никакой ценности пользователю.

понедельник, 2 апреля 2012 г.

Замыкание на переменных цикла в C# 5.0

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

Если говорить о языке C#, то его разработчики подходят к вопросам «юзабилити» весьма основательно; они спокойно могут пожертвовать «объектной чистотой» в угоду здравому смыслу и удобству использования. Одним из немногих исключений из этого правила является замыкание на переменной цикла, той самой фичи, которая ведет себя не так, как считают многие разработчики. При этом количество недовольства и недопонимания настолько много, что в 5-й версии языка C# это поведение решили изменить.

понедельник, 19 марта 2012 г.

Бертран Мейер. Объектно-ориентированное конструирование программных систем

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

Основная сложность при изучении объектно-ориентированного программирования (или любой другой парадигмы программирования) заключается в том, что весьма сложно подобрать формальные критерии, которые бы сказали: «ок, теперь я знаю ООП и стану писать более клевые (читай модульные, реюзабельные и легкие в сопровождении) программы». Например, при изучении языков программирования мы относительно быстро замечаем, опа, level-up, я, кажись, перешел на новый уровень понимания идиом и конструкций языка программирования и могу использовать его более интересным образом, да еще и другим рассказывать, где они не правы.

среда, 14 марта 2012 г.

15 возможностей ReSharper-а для навигации и редактирования

Инструменты – средство усиления вашего таланта. Чем они лучше и чем лучше вы ими владеете, тем больше вы сможете сделать.
Энди Хант и Дейв Томас «Программист-прагматик. Путь от подмастерья к мастеру»

DISCLAIMER: это не заказная и совершенно не проплаченная статья (JetBrains, я ни на что не намекаюJ). Здесь представлены лишь возможности популярного расширения для Visual Studio (а иногда и аналогичные возможности самой студии), которые я лично использую в повседневной деятельности.

Инструменты не являются панацеей от кривых рук и сами по себе не сделают из заурядного специалиста аццкого сатану, способного рвать любую задачу, как известные четвероногий друг тряпку. Они не решают сами ваши задачи, а лишь помогают снять с плеч некоторые рутинные вещи и дают возможность сосредоточиться на главном, не задумываясь о таких мирских вещах, как добавление нужных директив using, проблемах форматирования или навигации по коду. Многие инструменты (в особенности ReSharper) могут помочь в решении и других, не мене важных задач, таких как поиск ошибок в коде, следование стандартам кодирования, запуск юнит-тестов и многих других. И хотя все эти возможности являются мегафичами сами по себе, но сегодня речь в основном пойдет о возможностях навигации и поиска.

Формат описания следующий: названия фичи, а затем в скобках горячие клавиши для схемы Visual Studio, а затем для схемы IDEA.

Например: Go To Type (Ctrl + T, Ctrl + N).

понедельник, 12 марта 2012 г.

Альтернативная проверка предусловий в Code Contracts

При попытке использования библиотеки Code Contracts в реальном проекте может возникнуть небольшая сложность: хотя сам класс Contract с методами проверки предусловий и постусловий, располагается в mscorlib начиная с 4-й версии .NET Framework, но без установки самой библиотеки Code Contracts, они не попадают в результирующую сборку.

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

Однако Code Contracts поддерживает дополнительный «режим совместимости», который позволяет «жестко зашить» проверки предусловий в результирующий код, так что они будут видны всем, не зависимо от того, установлены контракты на машине разработчика или нет.

понедельник, 5 марта 2012 г.

Brainbench: Bench Games has started!

Сайт Brainbench.com, который занимается on-line сертификацией, с сегодняшнего дня запустил Bench Games, что для простых смертных означает возможность сдать на халяву любые тесты (а их там чего-то порядка 600). Да, это не распространяется на бумажные версии сертификатов, так что если захотите свою гениальность получить в персистентном виде, то дать им денег все равно придется.

Bart

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

В общем, let the game begins.

З.Ы. Старовало это добро сегодня и длиться будет до 9-го марта.

UPDATE: я хз, как дать прямую ссылку на все тесты, похоже, чтобы по ней перейти нужно вначале залогиниться на brainbench-е. В общем, вот ссылка на все тесты. Если не получится зайти по ссылке, то логинимся, и потом сюда: Skills Center > Test Center > All Tests.

Наследование интерфейсов и контракты

В библиотеке Code Contracts, которая любезно предоставляет возможности контрактного программирования на платформе .NET, для задания предусловий и постусловий используются вызовы статических методов класса Contract. С одной стороны – это хорошо, поскольку альтернативная реализация на основе атрибутов была бы слишком ограниченной. С другой стороны – это добавляет определенные сложности, когда дело касается контрактов интерфейсов или абстрактных методов, которые, по своей природе, не содержат никакого кода, а значит и вызывать методы просто не откуда.

Решается эта с помощью двух атрибутов: ContractClassAttribute, который вешается на интерфейс или абстрактный класс, и ContractClassForAttribute – который вешается на сам контракт.

вторник, 28 февраля 2012 г.

Принцип замещения Лисков и контракты

Идея этой заметки навеяна статьей Александра Бындю “Дополнение к LSP” и может рассматриваться, как развернутый комментарий к статье Александра.

Итак, вопрос следующий, предположим, один из членов команды пытается реализовать интерфейс IList of T в классе DoubleList of T таким образом, чтобы при добавлении элемента с помощью метода Add, добавлялся бы не один, а два одинаковых элемента. Поскольку класс List of T всегда добавляет только один элемент, то можно считать, что данное поведение нарушает принцип замещения Лисков (LSP – Liskov Substitution Principle).

понедельник, 13 февраля 2012 г.

Повторное использование знаний

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

Если оглядеться вокруг, то может сложиться впечатление, что отрасль разработки ПО шагает такими громадными шагами, что угнаться за ней нет никакой возможности. И если рассматривать всю отрасль в целом, то действительно это так и есть. Как-то сразу вспоминается старина Брукс со своим «Мифическим человеко-месяцем», когда он в заключении к своей книге пишет о том, как изменилась индустрия ПО в середине 90-х по сравнению с 50-ми годами. В те далекие годы (да, 90-е тоже уже далеки, так что уж говорить за эпоху зарождения индустрии сорока годами ранее) можно было прочитать все журналы (!),компьютерной тематики, которые выходили в свет. Сейчас же ежемесячно появляется десятки книг только по одной из популярных технологий, а количество статей просто не поддается счету.

понедельник, 6 февраля 2012 г.

Attached свойства для ограничения текстового ввода

WPF – это уже далеко не новая технология на рынке, но относительно новая для меня. И, как это часто бывает при изучении чего-то нового, появляется желание/необходимость в изобретении велосипедов с квадратными колесами и литыми дисками для решения некоторых типовых задач.

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

В Windows Forms эта задача решалась довольно легко, а когда в распоряжении был тот же TextBox от DevExpress со встроенной возможностью ограничения ввода с помощью регулярных выражений, то все было вообще просто. Примеров решения этой же задачи в WPF довольно много, большинство из которых сводится к одному из двух вариантов: использование наследника класса TextBox или добавление attached property с нужными ограничениями.

понедельник, 30 января 2012 г.

18 фактов о Джоне Ските

Практически на каждом своем выступлении, будь то семинар или воркшоп, рано или поздно заходит речь об известных представителей .NET community и одним из первых в этом списке идет Джон Скит (Jon Skeet), гуру stackoverflow.com и автор одной из самых интересных книг по языку C# - “C# in Depth”.

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

среда, 18 января 2012 г.

Первый workshop по .NET и архитектуре

Завтра, 19 января мы в Учебном Центре попробуем провести первый workshop по .NET и архитектуре. Правда посвящен он будет не совсем обычной, казалось бы, для такого воркшопа теме, а именно “Приемам функционального программирования на платформе .NET”.

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

среда, 11 января 2012 г.

The Art of Unit Testing

imageЕсть некоторые категории знаний, которые профессиональный разработчик познает в процессе своей работы, не прилагая к этому особенных дополнительных усилий. Вот, например, мало кто из нас читал замечательную книгу по регулярным выражениям Джеффри Фирддла, чтобы познакомиться с одноименной темой. Безусловно, есть масса людей, для которых «регвыры» стали смыслом жизни и без подобных фундаментальных знаний никак не обойтись. Но в большинстве случаев пары мелких статей и справки в соответствующем разделе документации будет достаточно для более или менее комфортной работы с регулярными выражениями (если такое понятие, как «комфортная работа» с регулярными выражениями вообще существуетJ).

Аналогичным образом мы обычно относимся и к изучению юнит тестирования. Ведь юнит-тесты – это же не rocket science; для их изучения не требуется многолетняя подготовка и множество бессонных ночей проведенных за изучением толстенных «талмудов» от гуру юнит-тестирования. Концепцию автоматизированного тестирования кода можно объяснить за 10 минут, а познакомившись с одним из тестовых фреймворков семейства xUnit (еще 15 минут), вы сможете работать с любым другим фреймворком практически сразу же. Затем нужно будет потратить еще 20 минут на изучение какого-нибудь изоляционного фреймворка, типа Rhino Mocks, и, вуаля, у нас есть еще один профессионал в области юнит-тестов.

вторник, 3 января 2012 г.

Ретроспектива 2011

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

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