Гугл предлагает усилить JSON с помощью Jsonnet

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

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

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

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

Результат:

 

Подробнее

Характеристики микросервисов, приложений и систем

Всем привет!

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

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

В презентации Стефан также рассказывает о том, что традиционные предположения о том, каким образом строить программные системы подвергаются сегодня тотальному пересмотру. Одно из таких предположений, что большая система должна иметь единое окружение, часто с однозначным соответствием между функциональными требованиями проекта и реализацией, что выливается в формулу «1 проект = 1 система». Хотя такое решение не всегда самое лучшее, оно получается очень жестким.

Рассматривая способ построения логических систем из малых частей, Тильков описывает три стиля:

  • Микросервисы – маленькие программы, каждая из которых работает сама по себе. Используют простые механизмы для общения и строятся вокруг нужд бизнеса.
  • Приложения – небольшие, отдельные, исполняемые программы, использующие модель «share nothing». Имеют много общего с микросервисами.
  • Самодостаточные системы – это крупные автономные программы, которые содержат и данные и логику. Контролируются одной командой. Не используют синхронные удаленные вызовы, могут предоставлять API.

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

Screenshot

Наиболее интересным параметром для Тилькова является количество модулей в системе, потому что это показывает степень декомпозиции большой системы.  Большие системы в этом плане проигрывают, но микросервисы сложнее в поддержке и оркестровке, тем самым увеличивая уровень сложности системы. В общем, нет какого-то одного правильного решения, «серебряной пули» и мы на конференции API & Backend хотели бы поднять дискуссию на эту тему. Если у вас есть интересные случаи из практики касающиеся типичных проблем для той или иной модели, пути решения этих проблем – мы ждем ваших историй.

 

Hard’n’Heavy!

Управление 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 4.6 и дальнейшие планы

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

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


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

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

Подробнее

Façade and AOP

Давненько я не писал по теме шаблонов и аспектов. И этот пост будет для разогрева темы снова.

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

facade_aop

Википедия дает следующее определение:

Шаблон фасад (англ. Facade) — структурный шаблон проектирования, позволяющий скрыть сложность системы путем сведения всех возможных внешних вызовов к одному объекту, делегирующему их соответствующим объектам системы.

С помощью аспектов не выделить отдельный класс для такого функционала.

По сути, исследователи признали, что только «Фасад» никоим образом из классических 23 шаблонов не может быть хотя бы частично реализован с помощью АОП.

Вот такой короткий рассказ.

 

Hard’n’Heavy!