Корпоративные системы быстро эволюционируют из монолитных хранилищ в распределенные приложения, основанные на сервисах с гибкими схемами использования.  Чтобы идти в ногу со временем, IT организации должны приспосабливать свои старые приложения к изменяющимся бизнес-требованиям почти что в режиме реального времени, и фактически без возможности второго шанса. Сервис-Ориентированная Архитектура (SOA) эволюционировала для поддержки гибкости операций и федеративности бизнес-процессов, подсистем. Авторы статьи Николас Серано (Nicolas Serrano), Хуасин Эрнандес (Josune Hernantes) и Горка Галлардо (Gorka Gallardo) дают обзор текущего состояния технологии SOA и как развиваться в существующем окружении.
                                                                                        Предисловие от Кристофа Эберта (Christof Ebert)

Современный бизнес должен быть способен гибко и быстро приспосабливаться к требованиям рынка, но даже незначительные изменения в процессах могут повлечь переработку множества информационных систем, которые изначально были разработаны как монолитные хранилища. Для сохранения конкурентоспособности, затраты на поддержку должны постоянно снижаться, а системы ­постоянно эволюционировать. SOA делает возможным переход от монолитных систем к сервис-ориентированным. Это содействует гибкости, слабой связанности, выделению абстракций из реальной инфраструктуры. Возможности по обнаружению сервисов и повторному использованию гораздо выше с SOA. Дополнительные возможности и принципы можно узнать из Манифеста SOA. ^[1][2]

Новизна SOA заключается в том, как моделируется инфраструктура архитектурного решения, основанная на сервисах, вместо фокусирования на всём приложении. Сервисы являются маленькими, обособленными элементами ПО, которые решают одну задачу и могут быть повторно использованы во многих приложениях. SOA основывается на принципе слабой связанности, что означает что каждый сервис – это изолированная сущность с ограниченными зависимостями от других общих ресурсов, таких как базы данных, легаси приложения или разные API. Такое архитектурное решение позволяет создать уровень абстракции между потребителями и создателями. Это влечёт за собой свободу в реализации и обновлениях без ущерба для потребителей сервиса. Да, SOA имеет немало плюсов для бизнеса, но это не лучшее решение для всех случаев. Среди плюсов подхода можно обозначить следующие пункты:

29 апреля 2015 года в Москве прошла бесплатная конференция сообщества SkillsWiki о профессиональном развитии.

Что интересного было на конференции? Какие навыки требуются от .NET-разработчика на американском рынке? Вы смогли бы оценить, шагаете ли вы в ногу со временем. Только ли знания и навыки определяют уровень вашей заработной платы, или есть еще важные факторы, которые определяют вашу ценность с точки зрения работодателя? Как говорить с работодателем о вашем росте и повышении заработной платы?

Не смогли принять участие в конференции? Ничего страшного. В этой заметке представлены все материалы конференции. Но в будущем не пропускайте наши конференции и вступайте в сообщество SkillsWiki!

Разработка веб API это нечто большее чем просто URL, HTTP статус-коды, заголовки и содержимое запроса. Процесс проектирования – то, как будет выглядеть и восприниматься ваш API – очень важен и является хорошей инвестицией в успех вашего дела. Эта статья кратко описывает методологию для проектирования API с опорой на преимущества веба и протокола HTTP, в частности. Но не стоит думать, что это применимо только для HTTP. Если по какой-то причине вам необходимо реализовать работу ваших сервисов используя WebSockets, XMPP, MQTT и так далее – применяя большую часть всех рекомендаций вы получите практически тот же API, который будет хорошо работать. К тому же полученный API позволит легче разработать и поддерживать работу поверх нескольких протоколов.

Хороший дизайн затрагивает URL, статус-коды, заголовки и содержимое запроса

Обычно руководства по проектированию Web API фокусируются на общих концепциях: как проектировать URL, как правильно использовать HTTP статус-коды, методы, что передавать в заголовках и как спроектировать дизайн содержимого, которое представлено сериализованными данными или графом объектов. Это всё очень важные детали реализации, но не настолько в смысле общего проектирования API. Проектирование API – это то, как сама суть сервиса будет описана и представлена, то что вносит значительный вклад в успех и удобность использования Web API.

Хороший процесс проектирования или методология предоставляют набор согласованных и воспроизводимых шагов для создания компонентов сервисов, которые будут доступны в виде Web API. Это значит, что такая прозрачная методология может быть использована разработчиками, дизайнерами и архитекторами для координации своих действий по реализации ПО. Использованная методология так же может уточнятся со временем по мере того, как улучшается и автоматизируется процесс без ущерба для деталей методологии. На самом деле, детали реализации могут меняться (например, платформа, ОС, фреймворки и стиль UI) независимо от процесса проектировки, когда эти две активности полностью разделены и задокументированы.

Гугл открыла исходный код своего проекта Jsonnet, языка для конфигурации, который заменяет стандартный JSON и добавляет новые возможности без нарушения обратной совместимости. Среди таких возможностей: комментарии, ссылки, арифметические и условные операторы, массивы и работа с объектами, импорт, функции, локальные переменные. Программы на Jsonnet транслируются в совместимый с JSON формат данных.

Комментарии. Jsonnet принимает комментарии в стиле С ( /* … */ ) и С++ ( // )

Ссылки. Ключевое слово self может быть использовано для ссылки на текущий объект. Оператор $ позволяет использовать корневой объект.

Арифметические и условные операторы. Оператор + может складывать числа, строки, массивы и объекты. Операторы == и != возвращают true или false. Оператор if работает как тернарный оператор ?: в С. Далее несколько примеров с операторами языка и результат. Примеры взяты со страницы проекта.

// bar_menu.3.jsonnet
{
    foo: 3,     
    bar: 2 * self.foo,  // Multiplication.
    baz: "The value " + self.bar + " is "
         + (if self.bar > 5 then "large" else "small") + ".",
    array: [1, 2, 3] + [4],
    obj: {a: 1, b: 2} + {b: 3, c: 4},
    equality: 1 == "1",
}

Всем привет!



Вниманию хабрасообщества хочу представить интересную презентацию Стефана Тилькова, со основателя и главного консультанта в innoQ. Стефан рассказывает об идее разделения больших систем на небольшие приложения, которые отвечают за разные аспекты системы. Сама идея не нова, но автор упирает на то, что основной причиной такого разделения должна быть изоляция. Благодаря границам приложений полученных таким образом, сложнее получить связанные модули, которые на самом деле должны быть независимыми. Тут еще можно вспомнить подход «domains boundary», для разделения доменных сущностей по областям применения, вместо того, чтобы создавать единую модель данных на всю большую организацию/процесс.

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

Совсем скоро 29.04.2015 в офисе B2B-Center пройдет бесплатная конференция сообщества SkillsWiki о профессиональном развитии.

Программа докладов:

1. «Навыки .NET-разработчика глазами американских и российских работодателей» — Алексей Воронин, NVision Software Solutions.
2. «За что вам платят деньги на работе?» — Алексей Косарчук, Positive Technologies.

Что интересного вас ждет на конференции? Вы узнаете, какие навыки требуются от .NET-разработчика на американском рынке. Вы сможете оценить, шагаете ли вы в ногу со временем. Только ли знания и навыки определяют уровень вашей заработной платы, или есть еще важные факторы, которые определяют вашу ценность с точки зрения работодателя? Как говорить с работодателем о вашем росте и повышении заработной платы.

Регистрация на бесплатную конференцию SkillsWiki: http://skillswiki.timepad.ru/event/193115.

Достижение начального успеха для Сервис-ориентированной Архитектуры (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 вместе будут укладываться в общую архитектурную картину.

На недавно прошедшей онлайн конференции dotNetConf организованной Microsoft, рассказывалось множество интересных вещей. И коль скоро было большое количество обсуждений по поводу WPF, что он живее всех живых, то хочется сделать краткий обзор доклада программных менеджеров WPF, что нового нас ждет в релизе, что уже можно посмотреть и к чему все идет. Действительно все так плохо и будет ли аналог нового движка для WPF, как например Razor для ASP.NET.

12 ноября 2014 года блог WPF ожил (сейчас активен тоже) и был представлен генеральный план развития фреймворка.


Здесь и далее, скриншоты с видео, так что качество не очень, но разглядеть все можно.

В начале выступления, ведущие Уни Равиндранатан (Unni Ravindranathan) и Харикришна Менон (Harikrishna Menon) обмолвились, что есть вещи, которые еще находятся в разработке, и они не имеют права о них рассказывать, NDA и все такое. Но то что они могут показать, внушает оптимизм и видно, что работа идет. Забегая вперед, скажу, что прежде всего разработчики подумали о быстродействии, например, как сократить визуальное дерево для конкретной целевой платформы.

Мы решили поделиться материалами прошедших трех конференций и напомнить, что совсем скоро, 11 апреля, состоится конференция Go# Desktop UI & Business Applications. Все презентации доступны на SlideShare. Просто нажимайте на ссылки с названиями докладов в этом посте.

Всем привет!

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



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

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

Всем привет!

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

Ни для кого не секрет, что основной целью наших конференций является дать возможность людям познакомиться на почве профессиональных интересов. Доклады являются пищей для размышления и вводной частью к последующим дискуссиям различной степени детальности. На наш взгляд, такое общение способствует осознанию собственных убеждений в более глубокой мере, так как вы сталкиваетесь с другими, порой диаметрально противоположными мнениями. Так что же приготовлено для конференции Desktop UI & Business Application?



Сначала представим темы, которые относятся к бэкенду, к серверной части, которая будет интересна всем разработчикам, занятым в сфере энтерпрайз разработки. Т.е. это и WPF, и WinForm, и ASP.NET.

История представления реальных данных и процессов в мире программ имеет богатую и долгую историю. Можно сказать, что все началось с транзакционных скриптов, и процедурного программирования. Когда доменную модель пытались полностью представить в виде набора процедур и данных, которые хранятся в базе данных. По сути, все крутилось вокруг таблиц. Шагом вперед, вместе с ООП разработкой стала модель табличных данных, которые уже были представлены набором данных в памяти программы. Теперь таблицы стали отправной точкой в представлении доменной логики. Процедуры уже не объявлялись в глобальном пространстве имен, а были «пристегнуты» к определенной таблице, в зависимости от своих функций. Дальнейшее удешевление и распространение компьютеров привело к тому, что все более широкое применение находило компьютерное моделирование. В то же время сложные реальные доменные модели надо было отображать как можно более проще для поддержки и расширения. Так Мартин Фаулер предложил, а Эрик Эванс развил идею Domain Driven Design, которой большинство сейчас придерживается, в той или иной степени.

Привет, коллеги!

Совсем недавно мы анонсировали конференцию, посвященную Desktop UI & Business Application. В поддержку, чтобы посмотреть на настроения публики, была опубликована статья «WPF живее всех живых», которая оказалась дискуссионной и заставила нас в несколько другом свете взглянуть, на то, что и как мы хотим донести до широкой публики.

Как показали комментарии, не WPF единым живет десктоп разработка. Есть порты Qt для .NET, есть WinRT, если в эпсилон окрестности от дефолт-сити есть спецы по этим технологиям, которые хотят высказаться – у нас есть трибуна! Для этого все и задумано, чтобы показать различные варианты для ваших проектов.



Буквально вчера закончилась онлайн конференция dotNetConf 2015, которую, исходя из сообщений, Microsoft скорее возродила, нежели придумала заново. Конференция, судя по содержанию старается покрыть все основные области использования языка, это мультиплатформенность, веб, десктоп, доставка приложений, интеграция с Xamarin, будущее .NET, .NET Core, Roslyn Analyzer и другие темы. На мой взгляд, это генеральная репетиция перед конференцией //build, которая состоится в конце апреля-начале мая.

Про золотые молотки

Кроме WPF для энтерпрайз разработчиков есть еще много тем, на которое можно поговорить, и львиная доля разговоров всегда упирается в бэкенд. Различных дизайн-шаблонов для корпоративных приложений очень много, и большая их часть посвящена бэкенду. Мартин Фаулер посвятил этому книгу, которая, насколько я смог увидеть за время тренингов, является настольной для многих разработчиков и тим-лидов. Из шаблонов, описанных там, вырастают конкретные инструменты, которые позволяют решать задачи наиболее эффективным способом.

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

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



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

Привет, коллеги!

Совсем недавно мы провели конференцию, посвященную ASP.NET технологиям и всему что с ними связанно. Она имела успех, о чем можно судить по полному залу и звонкам с вопросами: «Может еще билетик будет все же?». Более подробно мы расскажем позже, но можно посмотреть фотоотчет, а сейчас хочется рассказать о двух новых конференциях, которые мы планируем провести в апреле.

Прежде всего хотим сказать, что быть вегетарианской конференцией мы не планировали, поэтому (но не только) мы сменили площадку и меню теперь будет с мясом!



Первая конференция UI Desktop & Business Application (11 апреля) посвящается «невидимым» с облаков разработчикам настольных корпоративных приложений и в целом всем, кто занимается разработкой и поддержкой бэкенда или разработкой сложного корпоративного интерфейса.

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

Тематика докладов:

• разработка системы обновлений
• системы плагинов — MEF
• интересные бизнес-кейсы связанные со стационарной разработкой
• фреймворки для UI, тестирование UI
• встраивание в систему
• особенности или какие-то интересные возможности связанные с EF
• и так далее, все что специфично для Windows программ

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

Меньше двух недель осталось до Дня ASP.NET 28 февраля. Наша команда уже проверяет звук и печатает бейджики. Наши спикеры дорисовывают свои презентации и оттачивают формулировки. А я расскажу о том, как мы будем способствовать обретению сверхчеловеческих программистских способностей у наших участников.

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

Как нам удалось эти бенефиты включить в корзину для участника — читайте под катом.

Друзья, разработчики C# и веб-программисты ASP.NET!

28 февраля 2015 года пройдет конференция, уникальная по концентрации специализированной информации для ASP.NET разработчиков.

Это конференция Go# Moscow – День ASP.NET. Все спикеры обладают серьезным опытом в разработке веб-приложений на платформе .NET, а некоторые являются обладателями статуса Microsoft MVP и Microsoft Regional Director.

8 докладов охватят темы:

• будущего ASP.NET
• ASP.NET Internals
• мониторинга производительности веб-приложений
• архитектуры ASP.NET приложений
• client-side'а

День ASP.NET – это прекрасная возможность повысить свой профессиональный уровень, пообщаться с коллегами по цеху, а также со спикерами из ведущих технологических компаний.

Добрый день, читатели Хабра!

Сразу скажу, что целевая аудитория поста и события: руководители в разработке на C#/.Net, в том числе тимлидеры и менеджеры проектов. И те, кто планирует переходить на руководящую позицию.

Я поделюсь логикой формирования программы второго дня конференции Go#.
Мы взяли темы, которыми должен владеть человек на руководящей позиции в разработке. При этом конкретная имплементация этих знаний должна быть специфична для экосистемы C#/.Net.

Для мероприятия с одним треком программа получилась концентрированной. Расписание включает 10 докладов по 15-30 минут, обед в кафе и кофе брейки – и все это с 10.00 до 17.00.

Темы: от архитектуры .Net приложений до механики решений по формированию команд и распределению задач. И, конечно же, управление проектом и исходным кодом. Докладчики представят две полярные парадигмы – классическую Application Lifecycle Management на базе TFS и альтернативные подходы с применением Git и DevOps инструментов.

Наши спикеры начинали как C#/.Net разработчики, но многие имеют опыт руководства коллективами и проектами с десятками и даже сотнями разработчиков.

Сайт тимлидерского дня конференции Go# – www.gosharp.ru/TLD2014

Я сам разработчик C# и делал конференцию впервые. Расскажу, как я набил шишек и получил много удовольствия.

Это конференция GoSharpMoscow «День личной эффективности разработчика C#».
Она прошла в субботу 15 ноября. Это был мой «первый блин комом» или, как говорят за рубежом, MVP (Minimum Viable Product). Отчитываюсь, что удалось сделать:

• заполнить зал на 100+%
• сделать конференцию полезной для 95% участников
• оправдать ожидания 70% участников.

Но самое ценное, что я получил от конференции – это обратная связь. Практически, это был TDD с экспериментами по формату и нетворкингу. Теперь наша команда знает, что нравится участникам, и каковы узкие места в организации конференции.