Работа блога

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

Давным давно, в одной далекой далекой галактике… На самом деле, кажется что это было очень давно, а на деле не то что бы очень. Почти 3,5 года назад я задумался о том, кем я хочу быть в дальнейшем, что именно из мира программирования мне ближе всего. На тот момент мне хотелось очень круто программировать и рассказывать об этом. Я не думал, что я уйду от активного программирования, от постоянного изучения технологий. На тот момент я подумал, что надо сделать так, чтобы люди тебя знали и сами приглашали на работу, а не самому искать работу и доказывать, что ты что-то знаешь и будешь ценным приобретением для компании. Полностью в соответствии с принципом: сначала ты работаешь на имя, потом имя работает на тебя.

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

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

Подробнее

Создание проектов с NuGet и ReSharper

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

 

Hard’n’Heavy!

 

 

WPF Exception Viewer

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

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

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

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

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

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

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

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

Подробнее

Visual Studio Multi-Project Templates

Идея

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

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

Итак, будем делать мульти-проектовое (проектное?) решение.

Подробнее

PostSharp. Обзор. Часть I

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

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

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

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

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

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

Подробнее

DDD & TDD. Часть III

Итак, у нас есть домен с необходимыми классами и сервисами. В целом можно генерировать и обрабатывать данные в любых количествах согласно написанным сервисам. Но есть проблема, даже проблемы:

  • Как пользователь будет вводить данные;
  • Как данные будут сохраняться/загружаться.

Домен по природе и задумке своей должен быть полностью независимым и работать независимо от того, как построено взаимодействие с пользователем (WPF, WinForms, Web) и как реализован слой данных (MSSQL, MySQL, Oracle и т.д.).

Слоеные пироги

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

  • Домен – слой бизнес-логики. В котором описано КАК работать с данными.
  • Слой данных. В этом слое осуществляется сохранение объектов во внешние ресурсы и восстановление из внешних ресурсов в доменные объекты. Выделением этих операций в отдельный слой мы делаем приложение более гибким, т.к. можно осуществлять работу с несколькими БД, меняя их, а приложение этого даже не заметит.
  • Слой представления. В этом слое мы говорим приложению ЧТО делать с данными, т.е. вызываем в нужном порядке доменные сервисы и отдаем результат вычислений на прорисовку. Таким образом, этот слой связывает Домен и Front End.
  • Пользовательское отображение (Front End). Это пользовательский интерфейс, может быть чем угодно: консолью, win forms, web, да хоть сразу в мозг! =) Этот слой должен быть максимально «тупой», тут недолжно быть никаких изменений данных, никакой логики, как и что показывать. Слой просто делает все что ему скажут без капли самодеятельности.

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

Подробнее

DDD & TDD. Часть II

Диспозиция

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

Доменные сервисы

Допустим, в условиях к программе сказано,  что вам

надо определять количество классов на заданный год обучения (сколько 5ых классов или 9ых) и сколько учеников в параллели.

Подумаем, какие классы и что у нас знают:

  • «Школа» знает сколько всего вообще классов;
  • «Класс» знает сколько в нем учеников.

Кажется больше нам и не надо. Как бы я сделал на заре своего обучения? Я бы в класс School добавил метод

Но это плохой подход по следующим причинам:

  • У класса School увеличивается ответственность что приводит к высокой связности классов;
  • Его становится труднее поддерживать и изменять;
  • Это так же может привести к дальнейшим проблемам тестирования.

Подробнее

DDD & TDD. Часть I

Disclaimer

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

Магические аббревиатуры

DDD – Domain Driven Design, если совсем вкратце, то это способ организации кода приложения. А организуется он таким образом, чтобы в единственной, независимой ни от чего в проекте сборке, лежала сама суть приложения.

TDD – Test Driven Development, проектирование приложения через тесты.

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

По DDD и TDD написано уже куча литературы различных форматов и объемов. Где-то проще, где-то запутаннее.  Исторический экскурс благополучно пропустим, кому интересно, могут погуглить книги Эрика Эванса и посетить сайт Мартина Фаулера.  Я постараюсь донести свое видение этого предмета максимально просто и доступно. Рассказать, как это помогает, работает, сопровождается и развивается.  Надеюсь, у меня все получится. =)

Но это все вкратце, теперь перейдем к более детальному рассмотрению.

Подробнее