Управление API и SOA

Для Сервис-ориентированной Архитектуры (Service Oriented Architecture, SOA) достижение начального успеха определяется:

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

Множество команд разработчиков разрабатывают и используют сервисы, но до сих пор идет мучительный подбор архитектуры, при которой сервисы будут широко использованы, с потенциалом для повторного использования внутренними командами разработки. Вместо создания согласованной сервисной архитектуры и демонстрации множественного использования одних и тех же сервисов, разработчики вновь и вновь не нарочно создают «Просто Набор Веб Сервисов» (Just a Bunch of Web Services (JBOWS)) или «Просто Набор REST Сервисов» (Just a Bunch of REST Services (JBORS)).

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

Управление SOA, API, и приложением может стать мостом между этими концепциями и улучшить архитектурную согласованность всего решения.

Сервисы, API и архитектура

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

Подробнее

WPF живее всех живых

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

Так почему же мы, команда GoSharp конференции (да, да, это о C#), решили сделать акцент на десктопной разработке в разрезе WPF? Далее я хочу показать какие светлые и темные моменты есть в существующем положении фреймворка и почему все же стоит в него вкладывать силы и время.

Существует мнение, что развитие десктопной разработки остановилось в своем развитии и для этого есть несколько предпосылок. Одна из них – остановка, или даже лучше сказать стагнация, в самой базе, в визуальном фреймворке WPF. Значительных обновлений для него не было вот уже лет 5, как может показаться. Официальный тулкит давно не обновлялся, точнее с февраля 2010 года, т.е. вот как раз те самые 5 лет. При этом компании, специализирующиеся на кастом-компонентах, как например DevExpress и Telerik успешно выпускают обновления и составляют планы на будущее относительно WPF. Даже если вы ориентированы на новинки, то компоненты для WinRT все равно используют концепции и общую структуру XAML, который никуда не уходит.
Далее мы хотим представить причины, по которым WPF некоторые считают неактуальным, и опровержение этих причин.

 

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

Причин для беспокойства можно выделить с дюжину. Но не все они реально так страшны и существенны. Пройдемся кратко по основным.

Блог команды WPF давно не обновлялся.

Так же, как и у любой другой команды, у команды WPF есть свой блог, в котором по идее должны быть описаны планы и достижения команды. К сожалению, в блоге давно нет новой информации. Это может натолкнуть на мысли, что всех разогнали или что писать не о чем. Однако, это не так и блог стал обновляться 4 месяца назад и последняя запись появилась 20 дней назад. Более того, появился генеральный план развития фреймворка, а также краткие описания новых фич доступных с последними CTP.

Подробнее

Patterns on the Road – Russia 2015

Коллеги по .Net разработке,

Разрешите представить вам тур Гаэля Фрэтё (Gael Fraiteur) Patterns On The Road, который состоится с 12 по 17 марта в Москве и Санкт-Петербурге. Главной идеей этого тура является представление и продвижение идеи разработки приложений с помощью шаблонов проектирования. Не просто прорабатывать дизайн с помощью шаблонов проектирования, которые были представлены Бандой Четырех, но также думать и писать код с помощью шаблонов. Гаэль хочет показать, как шаблоны могут быть вынесены на новый уровень абстракции. Эту идею он продемонстрирует в применении к убийственной задаче: потокобезопасность. Для тех, кто желает глубже узнать о PostSharp, мы подготовили бесплатный однодневный курс в обоих городах.

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

Вечерний семинар: Taking Design Patterns to the Next Level

Шаблоны проектирования доказали свою полезность и сейчас воспринимаются как базовое знание многими разработчиками. Со времени Банды Четырех шаблоны значительно облегчили и улучшили процесс дизайна структуры ПО. Однако со времен публикации практически не изменились способы того, как мы применяем их. Гаэль постарается раскрыть и показать на примерах новый путь применения шаблонов для всего цикла разработки. Его примеры бросают вызов сложившимся догмам касательно применения шаблонов и показывают новые аспекты применения гибких методологий. Беседа будет строится не вокруг абстрактных понятий, а на примере популярной и волнующей темы: многопоточности.

Тренинг: Advanced PostSharp From the Horse’s Mouth

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

Тренинг откроет небольшой экскурс в историю языков программирования и шаблонов проектирования ПО, после чего будет рассмотрен фундаментальный вопрос: почему мы думаем в терминах шаблонов, создаем дизайн ПО руководствуясь шаблонами, но по сути отметаем эти принципы во время непосредственного написания кода? Расписания дня в общих чертах можно описать как: потокобезопасность, undo/redo, АОП вообще и архитектурная валидация кода. Все примеры будут работать на новой Visual Studio 2015.

Количество мест ограничено. При достижении лимита, мы выберем участников рандомно.

Если у вас возникли какие-то вопросы, пишите по адресу my@violet-tape.net — Гордиенков Андрей.

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

Наконец-то появилась запись с выступления 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!

Object Explorer в MS SQL Server, как он должен быть

Давно собирался написать эту статью, о том каким должен быть Object Explorer в SQL Server.

В движок системы добавляются все новые и новые фишки, улучшается поддержка администрирования, скорость работы и так далее. Даже появляются сниппеты кода, а так же автодополнение в базовой версии, казалось бы, чего волноваться? Однако при постоянной работе с SQL Server, и когда хоткеи ReSharper’a уже хочется привнести в каждую программу, замечаешь насколько неудобная работа с объектами базы.

Все хорошо и красиво, когда в базе находится наверно не более 20 таблиц, которые можно объять одним взглядом, однако если таблиц от 50 и больше, а так же требуется работать с несколькими окружениями – работа превращается в ад. Очень легко выполнить не тот код, работая не с тем соединением. Да и просто поиск таблиц вызывает затруднения, так как обычно помнишь примерное название, а не дословное. Впрочем подобная проблема касается любых объектов в SQL Server.

Например глядя на такую картину, что вы можете сказать?

01

Что это за база? Какой это сервер? Сколько тут еще таблиц?

Подробнее

Культ Карго

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

Культ карго или карго-культ (англ. cargo cult — поклонение грузу), также религия самолётопоклонников или культ Даров небесных — термин, которым называют группу религиозных движений в Меланезии. В культах карго верят, что западные товары (карго, англ. груз) созданы духами предков и предназначены для меланезийского народа. Считается, что белые люди нечестным путём получили контроль над этими предметами. В культах карго проводятся ритуалы, похожие на действия белых людей, чтобы этих предметов стало больше. Культ карго является проявлением «магического мышления».

Можно с легкостью это переложить на сферу ИТ, когда команды просто повторяют разные внешние проявления той или иной практики не задумываясь, что должно являться результатом. Что-то резко вспомнились огромные фанерные «антикрылья» на копейках и 4 трубы – это тоже яркий пример культа карго.

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

Подробнее

Работа блога

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

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

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

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

Подробнее

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

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

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

Подробнее

Could not find required file ‘setup.bin’

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

Совсем недавно, при разборе проблемы с применением PostSharp при сборке на билд-сервере, столкнулся с проблемой, что на чистой машине, где стоит только сам билд-сервер TFS, новый фреймворк с SDK не собирается проект. Полностью сообщение об ошибке выглядело следующим образом:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets (4486): Could not find required file ‘setup.bin’

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

Ручным решением проблемы может быть следующее:

1. Необходимо скопировать с машины разработчиков всю папку c:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A

2. Далее в регистре прописать\создать ключ HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\GenericBootstrapper\11.0 со значением C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\Bootstrapper\

После чего все заработает.

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

Но по прежнему не стоит ставить на билд-сервер инструменты вроде DevExpress, Telerik и так далее, потому что только на машине пользователя вы обнаружите, что не хватает какой либо библиотеки для отображения супер-таблицы или иных красивостей.

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

 

Hard’n’Heavy!