SoftLab.NET 2014

20 Декабря была веб-конференция SoftLab.NET 2014 компании Luxoft на которой я рассказывал про Threading Pattern Library из комплекта поставки PostSharp. Эта библиотека шаблонов действительно упрощает работу с многопоточностью. В следующем году я хочу подробно про это написать, так как там много нюансов обнаруживается, но сейчас краткий обзор доступен в презентации.

Hard’n’Heavy!

Принцип наименьшего удивления

Наконец-то появилась запись с выступления SECR-2013. Может она появилась и не на днях, но заметил я ее не так давно. Так что делюсь и оставляю себе, чтобы не забыть.

20131025-27-Принципы наименьшего удивления в разработке API приложения from Stas Fomin on Vimeo.

What I’ve learned about DDD since the book

Не далее как на прошлых выходных побывал на тренинге Patterns and Practices of Effective Domain Modeling, который вел Dino Esposito. Тренинг понравился, хотя я и не узнал фактически ничего нового. Ну это я сам виноват, так как давно копаю эту тему и много уже всякого переслушал и перечитал. Так вот, на этом тренинге на одном из слайдов была ссылка на выступление Эрика Эванса (Eric Evanse), где тот рассуждал на тему, как бы он переписал книгу «Domain Driven Design. Tackling complexity in the heart of software». Я посмотрел это выступление и оно в целом очень интересное. Вообще мне нравятся темы, когда инициаторы каких-то идей, через несколько лет пишут или говорят о том, как они бы сейчас изменили свою книгу\концепцию. Это наверно наталкивает на мысли, что же наиболее важно оказалось. Второстепенные вещи редко поддаются сильным изменениям.

В общем, советую посмотреть тоже выступление What I’ve learned about DDD since the book

На сегодня это все =)

Hard’n’heavy!

ReSharper и Roslyn: Q&A

Как уже все знают, MS предлагает «компилятор как сервис» в виде платформы Roslyn. Может быть некоторые из вас ее уже попробовали и составили какое-то первое мнение. После того, как почитаешь внимательнее возможности Roslyn и рассмотрев примеры работы с ним, возникает закономерный вопрос:

Как это будет работать с ReSharper и будет ли он переписан? Когда будет новый решарпер для новой студии?

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

 

После анонса и выпуска Roslyn платформы на последней конференции BUILD, мы в JetBrains немедленно оказались погребены под вопросами о судьбе ReSharper, в смысле будет ли он использовать Roslyn для анализа кода и как они могут вместе сосуществовать. Поток вопросов не иссякнет, пока не будет использоваться единый шаблон для ответов на них:

resharper

Подробнее

Поведение при подписке на события

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

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

sample

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

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

Код в реальности выглядит вот так. Т.е. это то, как вы его напишите с первого раза. Собственно я написал так же.

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

Итак, что вы ожидаете от такого кода? Посмотрите внимательно на названия методов, событий – решите для себя, что вы ожидаете.

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

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

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

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

На мой взгляд надо сделать два события:

  • ArrowNavigationCommandReceived – нет возможность использовать IsHandled для прерывания цепочки обработки.
  • ArrowNavigationCommandReceiving – есть возможность использовать IsHandled.

Ближайшая аналогия прослеживается с событиями Closed и Closing для окон (WinForm, WPF).

Что вы думаете по этому поводу? Комментарии как всегда приветствуются.

UPD: голосование пока что запилить не могу.

[poll id=»2″]

Hard’n’Heavy!

Начинающие и опытные разработчики

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

Как вы думаете в чем же разница?

Подробнее

Логика на INotifyProperyChanged

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

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

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

Я уже не раз писал и говорил насколько мне не нравится явная реализация INPC при реализации MVVM для WPF, но недавнее открытие в проекте коллег не смогло меня оставить равнодушным. Честно сказать, я не представлял, что таким образом можно построить логику приложения, но что есть, то есть. Итак, не будем более затягивать вступление и обратим взор на код.

Подробнее

Domain, Context, Integration. Как увидеть динамику в статике кода.

Доклад с конференции, вы не поверите, «Java сегодня и завтра. Просто о сложном».

Большинство из нас, если не все, для разработки больших приложений, для бизнес-приложений по большому счету, используют Domain Driven Design подход описанные Эриком Эвансом в 2004 году. Это способ проектирования, который фокусируется прежде всего на предметной области, на объектах реального мира, их поведении и взаимодействии, то есть фокусируется на модели и бизнес-логике. Однако реальные связи в таком коде чаще всего строятся и можно увидеть только в режиме run-time. Данный доклад ставит своей целью не столько показать конкретный код, сколько направить мысль разработчика на новую тему.

 

Hard’n’Heavy!

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

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

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

Hard’n’Heavy!

Конвейер (Pipeline) — IV

Ближе к жизни

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

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

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

Подробнее