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

В первой части статьи мы говорили, что основным препятствием при использовании микросервисной архитектуры является то, что модели предметной области (domain model), транзакции и запросы удивительно устойчивы к разделению по функциональному признаку. Было показано, что решение заключается в реализации бизнес-логики каждого сервиса в виде набора DDD-агрегатов. Каждая транзакция обновляет или создает один единственный агрегат. События используются для поддержания целостности данных между агрегатами (и сервисами).

Во второй части статьи мы увидим, что ключевой задачей при использовании событий является атомарное изменение состояния агрегата и одновременная публикация события. Посмотрим, как решить эту проблему с помощью Event Sourcing — используя событийно-ориентированный подход к проектированию бизнес-логики и системы сохранения состояния. После этого опишем, как микросервисная архитектура затрудняет реализацию запросов к базе данных, и как подход, называемый Command Query Responsibility Segregation (CQRS), помогает реализовывать масштабируемые и производительные запросы.

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

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

Однако микросервисы являются не таким уж простым и универсальным решением. В частности, модели предметной области, транзакции и запросы удивительно устойчивы к разделению по функциональному признаку. В результате разработка транзакционных бизнес-приложений с использованием микросервисной архитектуры является довольно сложной задачей. В этой статье мы рассмотрим способ разработки микросервисов, при котором эти проблемы решаются с помощью паттерна проектирования на основе предметной области (Domain Driven Design), Event Sourcing и CQRS.

Приглашаем вас на очередную встречу Java-разработчиков ThinkJava #4. Спикеры нашего ThinkJava-сообщества переплыли моря и океаны, чтобы побывать на SpringOne Platform в Лас-Вегасе, и теперь готовы поделиться привезёнными знаниями и своим опытом со всеми гостями ThinkJava #4. Мы посвящаем эту встречу вопросам облачных вычислений.

Друзья, приглашаем вас на очередную встречу PHP-разработчиков ThinkPHP #13. Вас ждут интересные доклады, живое общение с экспертами, сладкие кофе-брейки в компании постоянных участников ивента и новых гостей, и много вдохновения!

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

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

В этом году конференция WordCamp Europe 2016 проходила в Вене и собрала более 2300 гостей. Столица Австрии отлично подходит для проведения подобных мероприятий, здесь есть все условия: удобное расположение, большие конференц-залы, активное WordPress-сообщество. И есть на что посмотреть после конференции. Несколько наших разработчиков побывали на WordCamp Europe 2016. Под катом — их рассказ о наиболее интересных докладах и событиях.

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

Вам приходилось завершать проект одним махом, когда не было нужды снова смотреть в код? Вряд ли. Работая над старыми проектами, вам, вероятно, не хочется тратить время на выяснение, как работает этот код. Если код читабелен, то продукт легко сопровождать, а вы, ваши коллеги или сотрудники — счастливы.

Яркие примеры нечитаемого кода встречаются на соревнованиях JS1k, цель которых заключается в написании лучших JS-приложений, состоящих из 1024 символов или того меньше. То же самое можно сказать и про JSF*ck, крайне своеобразный стиль программирования, использующий только шесть разных символов для написания JS-кода. Глядя на выложенный на этих сайтах код, вы будете ломать голову, пытаясь понять, что здесь происходит. А представьте, каково это: написать подобный код и спустя месяц пытаться исправить баг.

Если вы регулярно сёрфите по сети или создаёте интерфейсы, то, вероятно, знаете, что для заполнения большой формы нужно много времени и терпения, которых хватает не всем пользователям. То же самое можно сказать и о коде. Чем легче его читать, тем приятнее долго работать с ним. Или как минимум не возникнет желания выкинуть компьютер в окно.

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

Оригинал статьи: https://www.sitepoint.com/importance-of-code-that-humans-can-read/

Недавно мы побывали в Амстердаме на конференции Unite Europe 2016, где получили массу эмоций и интересного опыта. На этой конференции было очень много увлекательных докладов по разным направлениям и различного уровня сложности. Темой одного из выступлений была “Overthrowing the MonoBehaviour tyranny in a glorious ScriptableObject revolution”, на котором Ричард Файн (https://twitter.com/superpig / https://github.com/richard-fine), специалист из Unity Technologies, подробно рассказал о ScriptableObject и на примерах показал, как он может быть применен в проекте.

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

20-21 мая 2016 года в Санкт-Петербурге прошла уже 19-я по счету международная конференция “SQA Days”. Мероприятие проходило в три потока, и за два дня конференции здесь прозвучало 57 докладов на различные темы: сам процесс тестирования, принципы построения команды тестировщиков, профессиональный рост и мотивация QA-специалиста.

Доклады по автоматизации тестирования шли отдельным потоком. Многие выступления были посвящены таким тенденциям, как DevOps, Continuous Delivery. Рассказываем о самых интересных докладах SQA Days-19.

В начале июня в Берлине прошла одна из самых продвинутых конференций по PHP — International PHP Conference 2016. В качестве докладчиков в ней приняли участие такие специалисты, как Себастьян Бергман, Арне Бланкертс, Стефан Прибш и еще более 50 человек, которые вносят свой постоянный вклад в развитие PHP. Конференция проводилась в шикарном 4-х звездочном отеле Маритим Проарте. Доклады читались в несколько параллельных потоков на английском и немецком и затрагивали как непосредственно PHP-разработку, так и околодевелоперские темы: инфраструктуру, серверное ПО, open source-разработку и многое другое. Отдельно хочется отметить ключевые доклады, которые зажигали то искрометным юмором, то глубиной затрагиваемых тем. В этой статье мы собрали свои впечатления от самых крутых докладов, с ссылками на презентации и примеры.

Протокол передачи гипертекста (HTTP) — это простой, ограниченный и невероятно скучный протокол, лежащий в основе Всемирной паутины. По сути, HTTP позволяет считывать данные из подключённых к сети ресурсов, и в течение десятилетий он выступает в роли быстрого, безопасного и качественного “посредника”.
В этой обзорной статье мы расскажем об использовании и преимуществах HTTP/2 для конечных пользователей, разработчиков и организаций, стремящихся использовать современные технологии. Здесь вы найдёте всю необходимую информацию о HTTP/2, от основ до более сложных вопросов.

В данной статье мы поговорим об основных особенностях объектно-ориентированного программирования в JavaScript:

• создание объектов,
• функция-конструктор,
• инкапсуляция через замыкания,
• полиморфизм и ключевые слова call/apply,
• наследование и способы его реализации.

Как следует из названия, в этой статье мы рассмотрим процесс создания средствами React Native приложения под Android. Оно будет простеньким, всего лишь с текстовым полем. Туда нужно будет ввести имя одного из покемонов, а приложение покажет подробную информацию о полученных данных и зачитает её с помощью функции преобразования текста в речь.

Мы не будем касаться установки Android SDK, React Native и создания проекта, или каких-то иных инструментов разработчиков. Будем исходить из того, что это ваш первый опыт создания приложения с помощью React Native, поэтому подробно рассмотрим каждый кусок кода.

В течение последних лет можно было наблюдать использование различных подходов к построению навигации в Android-приложениях. Кто-то использует только активности (Activity), кто-то смешивает их с фрагментами (Fragment) и/или с модифицированными видами (Custom View).

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

В этой статье мы рассмотрим несколько характерных подходов к реализации навигации в Android, а затем поговорим о подходе с использованием фрагментов, сравнив его с другими подходами. Демонстрационное приложение, на примере которого иллюстрирована статья, можно скачать с GitHub.

С момента возникновения концепции Material design одним из самых простых в реализации элементов стала плавающая кнопка действия — FAB, Floating Action Button. Этот элемент быстро обрёл широчайшую популярность среди разработчиков и дизайнеров. В этой публикации мы рассмотрим, как можно анимировать FAB и сделать её интерактивной. Но сначала разберём, как вообще добавить этот элемент в ваш проект.

В 2012 году разработчики C# из компании Microsoft создали язык TypeScript — надмножество JavaScript. Он предназначен для разработки больших приложений, от100 тысяч строк. Давайте на примерах рассмотрим синтаксис TypeScript, его основные достоинства и недостатки, а также разберём способ взаимодействия с популярными библиотеками.

Кому это будет полезно: Web-разработчикам и разработчикам клиентских приложений, интересующимся возможностью практического применения языка TypeScript.

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

Мне нужно было что-то более близкое, понятное.

Мне нужны были миньоны.

В этой статье мы рассмотрим некоторые «отсутствующие» в Java возможности. Но нужно сразу подчеркнуть, что будут умышленно опущены некоторые вещи, которые либо и так активно обсуждаются, либо требуют слишком большого объёма работ на уровне виртуальной машины. Например:

Отсутствуют материализованные дженерики (reified generics). Об этом не писал только ленивый, причём большинство комментариев свидетельствуют о непонимании сути затирания типов. Если Java-разработчик говорит: «Я не люблю затирание типов», то в большинстве случаев это означает «Мне нужен List int». Вопрос примитивной специализации дженериков лишь косвенно связан с затиранием, а польза от дженериков, видимых в ходе исполнения, сильно преувеличена молвой.

Беззнаковые вычисления (unsigned arithmetic) на уровне виртуальной машины. Отсутствие в Java поддержки беззнаковых арифметических типов вызывает недовольство разработчиков уже многие годы. Но это является обдуманным решением создателей языка. Наличие лишь знаковых вычислений существенно упрощает язык. Если сегодня начать внедрять беззнаковые типы, то это повлечёт за собой очень серьёзную переработку Java, что чревато массой больших и маленьких багов, которые будет трудно вылавливать. Заодно сильно возрастает риск дестабилизации всей платформы.

Длинные указатели для массивов. Опять же, внедрение этой функциональности потребует слишком глубокой переработки JVM с возможными неприятными последствиями, причём далеко не только с точки зрения поведения и семантики сборщиков мусора. Хотя нужно отметить, что Oracle ищет пути внедрения подобной функциональности с помощью проекта VarHandles.

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