Составление и навигация в диаграммах

В видео ниже я делюсь своими соображениями по поводу составления диаграмм и навигации в них для удобного изучения схем.

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

Hard’n’Heavy!

Тихое обновление с ClickOnce Video

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

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

 

Hard’n’Heavy!

 

 

Тихое обновление с ClickOnce

Сложность 200

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

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

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

Подробнее

Покрытие кода

В связи с последними постами на тему тестирования и использования Mighty Moose, хотелось бы так же затронуть тему покрытия кода, которую менеджеры часто используют для оценки качества кода. Некоторые разработчики, неискушенные в вопросах тестирования могут так же думать, что покрытие кода одно из ключевых свойств отображающих насколько качественно написаны тесты. К авторам MightyMoose так же выдвигались требования и просьбы включить покрытие кода в продукт, но Грег яростно отпирается от этого, так как само по себе покрытие кода не говорить ни о чем совершенно.

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

Значение покрытия не дает ничего. НИЧЕГО.

Предлагаю рассмотреть несколько сценариев, когда покрытие кода не дает желаемого результата.

Подробнее

Mighty Moose Risk Analysis

В видео ниже я рассказываю о том, как Mighty Moose проводит анализ рисков в вашем проекте, и как пользоваться этим инструментов. Что означают знаки в Mighty Moose, в общем все что может пригодиться для того, чтобы качественно покрыть приложение тестами.

 

Hard’n’Heavy!

Обзор работы с Mighty Moose

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

В этой ситуации на помощь приходит Mighty Moose с подходом continuous testing (непрерывное тестирование). Мне логичным появление такой системы, с учетом того, что до этого набрали популярность и оправдали свое существование техники непрерывной интеграции и непрерывной доставки. Mighty Moose действительно оправдывает инсталляцию и занимаемую оперативную память.

В видео подкатом я в обзорном режиме показываю как работать с Mighty Moose.

 

Hard’n’Heavy!

 

 

Непрерывное тестирование с Mighty Moose

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

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

В этой ситуации на помощь приходит Mighty Moose с подходом continuous testing (непрерывное тестирование). Мне логичным появление такой системы, с учетом того, что до этого набрали популярность и оправдали свое существование техники непрерывной интеграции и непрерывной доставки. Mighty Moose действительно оправдывает инсталляцию и занимаемую оперативную память.

Подробнее

WPF Exception Viewer

Сложность 100-200

Достаточно давно я писал о том, как работать (обрабатывать) с исключениями при использовании класса Task из Task Parallel Library (TPL), все описанные способы действительно работают и проверены на практике уже много раз и отлично меня спасают и упорядочивают работу с потоками, особенно с получением исключений. Однако тогда я упустил важный момент как еще централизованно можно получать исключения и никак не был освещен вопрос удобства работы с исключениями: отображение и коммуникация от пользователя. Сегодня собираюсь наверстать упущенное тем более под руку подвернулся удобный и простой набросок от MarkLTX с CodeProject.

Как оно бывает обычно

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

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

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

Так же пользователи не знаю, что текст можно копировать нажав Ctrl+C и высылают FullHD скриншот с ошибкой. Конечно весело порой посмотреть на чужие рабочие столы, но это быстро надоедает.

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

Подробнее