При работе с задачами из пространства имен Microsoft.Phone.Tasks существуют две стандартные ошибки: разработчики не думают о том, что на время, когда запущена задача, ваше приложение может перейти в tombstone mode. Проще говоря – это когда ваше приложение убьют, и сохранят только State страницы и State приложения, которые вам нужно будет потом восстановить. Вторая стандартная ошибка скрывается в том, что при вызове метода Show у задач, если данная страница уже не активна, то есть, например, происходит навигация, то метод бросит исключение InvalidOperationException, который убьёт ваше приложение (если вы не перехватываете исключение), и при возврате из задачи – вы попадете на главный экран самой операционной системы.

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

А код такой:

Итак, сколько проблем вы здесь видите?

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

До работы над Visual Studio я не так часто сидел в отладчике, так как проекты не были такими большими, мой код не так сильно зависел от кода соседних команд, и все что мне нужно я быстро мог понять из тестов/кода, и только, когда уже ничего не помогало, я шел отлаживать приложение. Основная причина для этого была одна – так для меня было намного быстрее и легче работать, так я быстрее находил проблемы.

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

Вчера первый раз в руках держал свою собственную копию бумажного варианта MSDN журнала. Новость, понятное дело, не эпическая, но хочу сказать, что именно бумажная копия журнала мотивирует на чтение MSDN статей, до этого ни разу я не читал столько статей из одного выпуска. В общем, на одной из первых страниц, в статье A Few of My Favorite Things... in the Entity Framework 4.2 DbContext я увидел следующий код:

var objectContext = (myDbContextInstance as IObjectContextAdapter).ObjectContext

Что плохого в этом коде? Я просто не понимаю смысла использования оператора as в этой строке. Почему бы просто не использовать обычное приведение типов:

var objectContext = ((IObjectContextAdapter)myDbContextInstance).ObjectContext

Чем этот вариант лучше предыдущего? А что если myDbContextInstance все-таки каким-то образом нельзя будет привести к типу интерфейса IObjectContextAdapter? Что будет в этом случае? В первом вариант мы получим всеми нами любимый NullReferenceException, так как оператор as вернет null в случае, если у него не удастся это приведение из типа DbContext в IObjectContextAdapter. Во втором случае мы честно получим тот самый InvalidCastException, который сразу же может дать нам понять, где именно, и в чем ошибка.

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

Сейчас по работе очень активно приходится вспоминать как писать batch скрипты, а так же много работать в command line. Кто писал когда-нибудь скрипты на batch знает, как там все непросто, и как там сильно не хватает многих вещей. Поэтому я решил так же познакомиться немного с Windows PowerShell, так как из этой оболочки уже без проблем можно обращаться к классам .NET, а это уже наше хорошо знакомое поле. Так вот, все знают, что в командной строке cmd можно добраться до предыдущей выполненной команды при помощи клавиши Up, ну и собственно можно просмотреть так историю выполненных команд. Сколько же времени тратится на поиск нужной команды из истории при помощи клавиши Up. А оказывается можно, воспользовавшись клавишами F7/F8/F9, намного быстрее выполнить команду из истории. F7 – самая простая из них просто показывают всю историю в таблице. Увидел я их, при чтении книги по PowerShell, а потом чисто ради любопытства решил попробовать в cmd. В общем, отправляю вас читать документацию на TechNet, если вам тоже приходится много работать с cmd: Windows PowerShell Shortcut Keys (они все работают в cmd).

Зачем, кстати, разработчику использовать Command Line? Ну, чтобы запускать msbuild на нескольких процессорах/ядрах (хотя это конечно можно настроить и в студии), написать скрипты, которые бы очень быстро обновляли тестовую систему…. Да, на самом деле, много для чего… Главное – это попробовать ;)

Термины Behaviors и Interactions ввели две библиотеки, поставляемые вместе с продуктом Expression Blend. Эти библиотеки еще известны со времен Silverlight и WPF, и предполагаю, что большинство разработчиков про них знает. Найти эти библиотеки можно в директории “c:\Program Files (x86)\Microsoft SDKs\Expression\Blend\” (если Windows 32 битный, то без (x86)), если Expression Blend был установлен. В этой папке вы сможете найти  библиотеки для WPF/Silverlight/WindowsPhone. Зачем они нужны и как их правильно использовать вы можете узнать, пройдя по ссылки на MSDN Expression Blend SDK for Windows Phone. Если кратко: это способ расширят функциональность контролов, да еще и так, чтобы поддерживался паттерн MVVM (байндинги и т.п.). 

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

Около месяца назад приобрел себе мобильный телефон под управлением Windows Phone 7 (7.1 Mango который). Мобильный телефон взял Samsung Focus S у мобильного оператора ATT. Честно, устройство очень радует. Сама система WP7 тоже доставляет только одни удовольствия. И, конечно же, сразу же захотелось что-нибудь написать под платформу. Тем более, что все на знакомом Silverlight. В общем, ближайшие, не знаю пока сколько, постов в моем блоге будут о Windows Phone 7, а точнее о разработке под него, а точнее о разработке Silverlight приложений под него. Начать же хочу с впечатлений о платформе и процессе разработки.

Продолжаю рассказывать про наш небольшой опыт проживания и работы в Канаде (Часть 1, Часть 2). Надеюсь, что получиться уложиться и остановиться на этой статье, так как уже в голове крутятся темы статьей по профильному направлению блога – программирование. Поэтому, если есть какие-то вопросы, я отвечу на комментарии в этой статье. Если есть какие-то персональные вопросы о том, как там живется – можно писать на email – отвечу без проблем.

Прочитав недавнюю статью на хабрахабр Кодоребус или паттерн «стратегия» на .Net 4.0 у меня всплыла мысль о том, какие задачи нужно давать на собеседовании. Всплыла она потому, что в последнем абзаце, а именно в PS, было

P.S. Обсуждение приведенного кодоребуса может быть хорошей темой для беседы с кандидатом на должность .Net разработчика

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

Еще один отличный пример достаточно распространенной задачи на собеседованиях – это задача с использованием оператора new для переопределения методов, полей базового класса (new Modifier). Я ни разу в жизни не использовал этот подход, так как он очевидно плох для архитектуры приложения. И я бы не хотел иметь дело с кодом, в котором он бы использовался. Но, на собеседованиях любят давать задачу на эту тему, и что же ожидают услышать от кандидата? По мне так хороший ответ был бы “И что, у вас так делают? Зачем вы меня спрашиваете об этом?”. По мне так - это 100% верный ответ. Второй по верности ответ был бы “Я, честно говоря, не помню, чтобы оператор new можно было бы применять для методов, поэтому, если это, действительно, возможно, я попробую решить ее интуитивно и опираясь на какие-то домыслы, которые я вам приведу.”, и не важно какое будет потом решение. И уже следующим для меня “правильным решением” будет просто правильное решение.

В общем, подводя итог: нельзя давать на собеседованиях задачи, основанные на вашем говнокоде.

Хотелось бы продолжить рассказ о нашем небольшом опыте проживания в Ванкувере. В сумме мы прожили в Канаде около 2,5 месяцев. Опыта мы набрали, конечно же, не так много, но до сих пор есть чем поделиться. Ванкувер оставляет незабываемые впечатления, действительно очень красивый и интересный город: парки, пляжи, ночные клубы. Кому что.