Anadea

Павел Мизонов
April 5, 2016

Введение

С ростом объёма кода и функциональности программного продукта, возникает необходимость управления сложностью приложения. Хорошо продуманная архитектура и правильное разбиение приложения на модули помогают справляться с поставленной задачей. Вариантом реализации архитектуры может быть монолитное приложение, когда вся или большая часть бизнес-задач имеет одну кодовую базу. Альтернативой является построенное на микросервисах приложение, в котором общая бизнес-задача разбита на отдельные части, каждая из которых имеет отдельное приложение (микросервис) со своей кодовой базой. К микросервисам в своих приложениях прибегают такие компании, как Amazon, Netflix, The Guardian. О преимуществах и недостатках подобной архитектуры по сравнению с монолитным приложением, будет рассказано ниже.

Что такое микросервисы?

Это небольшие модули, разделённые по принципу выполнения одной бизнес-задачи или одного класса задач. Основная цель такого разделения - возможность изменения отдельно взятого микросервиса, не меняя при этом связанных с ним компонентов. Бизнес-логика приложения разбивается на отдельные части, каждая из которых представляет собой небольшое приложение, выполняющее одну бизнес-задачу (single responsibility). Число таких приложений ничем не ограничено и между собой они общаются, используя API, построенное, например, на основе HTTP.

Какие преимущества дает использование микросервисов?

1. Избавляемся от высокого зацепления кода, разделяя приложение на микросервисы.

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

2. Легко масштабируем.

Это можно осуществить за счёт размещения микросервисов на разных серверах. Если в приложении есть несколько не очень требовательных к вычислительным ресурсам микросервисов, их можно размещать на одном хосте. Для более требовательных микросервисов - выделить хост мощнее. Микросервисы выполняющие неблокирующие задачи можно ставить в параллель.

3. Разные сервисы могут разрабатывать разные группы разработчиков.

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

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

Например, в web-приложениях для одних микросервисов можно использовать Ruby (Sinatra), а для других - node.js, потому что микросервисы изолированы друг от друга и технология их реализации никак не скажется на поведении приложения в целом.

Сложности использования микросервисов

1. Сложнее реализовать общее поведение для всех микросервисов (авторизация запросов, агрегация данных из разных микросервисов).

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

2. Микросервисы могут добавлять дополнительные издержки при обработке пользовательских запросов.

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

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

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

Список источников информации:

Martin Fowler: Microservices.
Sam Newman. Building Microservices. Designing Fine-Grained Systems. O'Reilly Media, 2015.

Станислав Синицкий, Денис Алтухов
June 17, 2016
 

С чего вы начинаете своё утро? Раньше люди очень любили за завтраком почитать свежую газету, из которой узнавали о последних новостях, событиях в мире, находили объявления, читали анекдоты. Однако, светлое научно-фантастическое будущее уже наступило, и на смену газетам пришли смартфоны и планшеты, а рубрика анекдотов эволюционировала в целое приложение. Из приложений мы узнаём погоду, курс валют, новости, смотрим, где есть пробки, следим за деятельностью любимых артистов, листаем афиши и так далее. Они прочно вошли в жизнь современного человека. И современный человек частенько берётся разрабатывать их. И нередко бывает так, что он и понятия не имеет о том, что бывают нативные приложения, а бывают гибридные и web-приложения, не ведает он, как их отличить, и какой тип лучше подойдёт концепции его проекта.

О нативных и гибридных приложениях мы сегодня поговорим с Денисом Алтуховым - Android-разработчиком в Anadea.

Привет, Денис!
Привет!

Скажи, как профессионал: чем отличаются нативные приложения от гибридных?
Ну смотри: нативные создаются под конкретную платформу, будь то Android, iOS или Windows. Они пишутся на нативных языках - Java в случае Android и Objective C в случае iOS. Скачиваются исключительно из официальных магазинов.

Вроде PlayMarket?
Да, у нас это PlayMarket и AppStore для Apple. Установка и распространение ведётся через эти магазины. Открывается как отдельное приложение, имеет свои окна. Не-нативное, написанное на JavaScript - по сути, это приложение, которое открывается в браузере и там имеется какая-то мобильная вёрстка.

По сути, это web-приложение?
Да. И его преимущество в том, что оно кроссплатформенное - пишешь сразу под все платформы, Windows, Android и iPhone или что угодно откроют их. Но здесь накладывается такое ограничение, что ко многим техническим функциям, которые требует заказчик, ты не достучишься. К примеру, он хочет активную работу с камерой - в не-нативном ты этого не сделаешь. Не сделаешь и дизайн по гайдам, которые есть для iOS и Android.

В разных браузерах гибридное приложение может отображаться по-разному?
Оно может "плыть", но глобально всё будет выглядеть одинаково. Но, к примеру, если человек привык использовать Android, то он будет ожидать увидеть некоторые стандартные "андроидовские" штучки. И когда браузерное приложение свёрстано не так, как ты ожидаешь, это уже, говоря откровенно, раздражает.

Все крупные приложения в основном нативные. Почему?
Отсутствие каких бы то ни было ограничений - это основная причина. Ты можешь достучаться до любого функционала, который тебе предоставляет операционная система. Такое приложение более гибкое, намного лучше работает с батареей благодаря правильной архитектуре нативного языка. Сама операционка смотрит на твоё приложение и выстраивает правильную работу с батареей, экраном и так далее. Ту же работу с картами реализовать в гибридном приложении, не используя для этого нативные инструменты от Google и Apple, будет куда сложнее.

Сталкивался с гибридными приложениями в своей практике?
Да. Например, год назад приходил проект, который как раз работал с картами - написан на JavaScript, в особой студии с трудом запускается, сам проект ломаный. Я кое-как смог его запустить лишь на эмуляторе iPhone!

О, Господи!
И это для того, чтобы хоть что-то увидеть! И то, осознать, что там происходит, было довольно трудно. В конце концов, заказчик пришёл к тому, что вместо одного гибридного он заказал два нативных приложения - для iOS и для Android.

То есть, он просто потратил время?
Да. Но его нельзя в этом винить - гибридные приложения разрабатывать и дешевле, и быстрее по времени. Ну и выбор разработчиков куда шире - уже необязателен специалист по мобильным платформам, достаточно обратиться к фронтендеру, который адекватно владеет JavaScript. Зная синтаксис языка, он сможет выполнить заказ, но без глубокого знания платформы многое может упустить и уровень приложения будет низким.

Именно поэтому не-нативные приложения чаще низкого качества?
Да - они "вылетают" или некорректно работают, потому что кто-то пришёл со стороны. Ещё одним проблематичным аспектом "гибридов" является организация нотификаций. Может там эти сервисы как-то и работают, но, к примеру, сейчас мы работаем над социальным приложением для обмена фотографиями, и там в iOS и Android нотификации строятся совсем по-разному. Вот тебе весомое отличие. Как будут выглядеть нотификации в web-приложении на заявленных трёх платформах (iOS, Android, Windows), где у каждой свои индивидуальные особенности… да кто его знает?

А что касается безопасности?
Здесь гибридные тоже проигрывают. Apk-файл ты можешь скачать только из одного места - из магазина. Плюс у тебя есть возможность перед тем как выложить приложение стандартными инструментами всё зашифровать, скрыть реализацию и так далее. Помимо шифрования, используется ещё такая вещь, как proguard - она разбивает ссылки, стирает имена. В не-нативном ничего этого нет, а это значит, что кто угодно сможет его разобрать, украсть твой код, скачать из каких-то других мест.

То есть, сейчас гибридным приложениям до нативных ещё очень и очень далеко?
Разумеется. Смысл в них есть, если ты разрабатываешь что-то очень простенькое, обобщённое, если бюджет невысок и сроки поджимают. Что-то, что не требует всех мощностей устройства, не привязывается к "железу". Если же требуется весь функционал, то в родных операционных системах Google и Apple уже встроена целая гора методов и способов работы с камерой, картами, bluetooth и прочим. И конечно же это будет лучше и качественнее, нежели пере-изобретённый велосипед от каких-то третьих разработчиков.

Абсолютно с тобой согласен. Спасибо, что нашёл время побеседовать!
Всегда пожалуйста.

Подведём итоги нашей беседы с Денисом:

• если вам требуется высокая скорость работы и ваше приложение будет непосредственно использовать "железо" (камера, оперативная память, видеочип, bluetooth, wi-fi, экран и прочее) устройства - разрабатывайте нативное приложение;
• если вас интересует высокий уровень безопасности - разрабатывайте нативное приложение;
• если вы работаете над действительно большим проектом - разрабатывайте нативное приложение;
• если же вам нужно что-то очень простенькое и вышеперечисленные пункты вашему проекту не нужны - тогда можно обойтись и гибридным приложением.

Сергей Волошин
March 30, 2016

За последние несколько лет front-end разработка ушла далеко вперёд. От банальной верстки html-страниц при помощи CSS c минимальной динамикой, задаваемой javascript/jquery, практически не осталось и следа. Если вы не работали хотя бы с одним из сборщиков front-end проектов (grunt, gulp, webpack), не слышали слова "транспайлер" (babel), не знаете, что на front end тоже можно писать тесты (jasmine, mocha, chai), и запускать их автоматически в любом браузере (karma), то вы весьма сильно отстали от жизни. А ведь есть ещё React.js (библиотека для построения интерфейсов), ES6 (новейший стандарт языка javascript, который ещё не поддерживается большинством браузеров, но если очень хочется, то уже можно использовать в production-коде), Node.js (платформа, позволяющая исполнить мечту любого front-end разработчика - писать не только front end, но и back end проекта на любимом javascript) и многое-многое другое.

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

Работая над проектами в Anadea Inc., мы успели испробовать не только все вышеназванные, но и многие другие инструменты front-end разработчиков. Это был длинный и тернистый путь, и теперь мы хотим поделиться полученным опытом, дабы помочь вам приоткрыть дверь в мир современной javascript-разработки.

Поговорим о преимуществах использования передовых front end инструментов.

Pros

• рост скорости решения задач;

Эта одна из основных причин появления всех вышеназванных инструментов. Благодаря им значительно сокращается время, затрачиваемое на рутинную работу. Например, благодаря, karma вы можете запустить тесты в режиме слежения сразу во всех имеющихся браузерах (а также в вашей виртуальной машине и даже на мобильных устройствах, подключенных к той же локальной сети, в которой находится ваш компьютер) и при каждом сохранении изменений в коде тесты будут автоматически перезапускаться.

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

• повышение качества кода;

В последнее время стали популярными линтеры (jslint, jshint, eslint) - инструменты, позволяющие определить стиль кода в вашем приложении и указывать на места, где выбранный стиль не соблюдается. В зависимости от настроек окружения, это может происходить во время push'a изменений в репозиторий, во время deploy'a на сервер, либо в реальном времени прямо внутри вашего текстового редактора/IDE. Линтеры позволяют в значительной степени улучшить состояние вашего кода, избежать простых ошибок. Однако линтеры не являются решением всех проблем - они лишь укажут на места, где ваш код явно "плохо пахнет". Но это не исключает изучение pattern'ов и лучших практик программирования, чтение чужого кода, общение с более опытными коллегами и всё так же придётся рефакторить ранее написанный код. Только так удастся добиться повышения качества кода.

• значительное снижение дублирования кода;

Ещё один полезный момент, который можно извлечь из использования линтеров - это возможность отслеживать дублирование в коде и избавляться от него. Но это не главный инструмент сокращения дублирования кода в мире современной javascript-разработки. К основным можно отнести Node.js, который при правильной архитектуре позволяет использовать один и тот же код и на back end, и на front end. Также снизить дублирование позволяет компонентный подход, применяемый многими библиотеками (например, React.js), и удобная система управления пакетами - npm. Компонентный подход позволяет инкапсулировать логику, стиль и отображение. Npm предоставляет несложный способ распространения (share) таких компонентов.

• возможность программирования в реальном времени;

И самый "горячий" плюс в современной front-end разработке это - hot reload - возможность делать изменения в коде и видеть их на экране браузера без перезагрузки страницы и без потери текущего состояния данных. Эта feature доступна на данный момент только тем, кто использует в качестве builder'a проекта webpack. Если вам интересно как это выглядит, можете посмотреть пример с React.js.

Но как уже было сказано выше, современный front end имеет и обратную сторону медали. Давайте посмотрим на недостатки, которые нам удалось выявить в процессе работы с новейшими инструментами javascript.

Cons

• высокий порог вхождения в окружение;

Как бы ни было, за всем разнообразием front-end инструментов скрываются три технологии: javascript, html, css. Но чтобы вывести банальный "Hello, world!" на экран своего монитора современным способом, вам придётся ознакомиться не меньше чем с десятком документаций, написать несколько не самых очевидных файлов конфигурации и запустить череду команд в терминале. Всё это отпугивает как новичков, так порой и опытных программистов, не желающих познавать новое. Настройка окружения действительно важный этап в современном мире front end'a. Хорошая новость в том, что это необходимо будет сделать "практически" один раз. Плохая - если вы постараетесь проскочить этот этап, бездумно скопировав чьи-то решения, то он постоянно будет возвращаться к вам часами серфинга просторов интернета в поисках решения банальных проблем.

• "усталость от javascript инструментов";

В javascript-community всё чаще стал звучать термин "javascript fatigue", под которым подразумевается усталость от разнообразия инструментов и их бесконечных версий. Некоторые авторы называют 2016 "годом борьбы" с побочным эффектом роста числа инструментов и предполагают, что в этом году усилия javascript-сообщества будут направлены на решение этой проблемы.

Суть javascript fatigue сводится к тому, что если вы не следите за числом модулей, подключенных в проект, управление зависимостями превращается в сущий ад. Из-за обновления одного инструмента до новой версии вам придётся обновить ещё три, которые в свою очередь тоже имеют свои зависимости - и так до бесконечности. Если у вас несколько проектов, то приходится держать в голове не только специфику связей между модулями, но и специфику связей между версиями этих модулей, которая в мажорных версиях зачастую меняется кардинально.

• большой выбор способа конфигурации модулей;

Мы долго сомневались, к достоинствам или недостаткам относить этот пункт, но так как статья рассчитана на новичков, то чаша весов всё-таки склонилась к недостаткам. И вот почему.

Практически каждая большая зависимость (webpack, karma, gulp, eslint и т.п.) в вашем проекте будет предоставлять более одного способа конфигурации: с помощью своего конфигурационного файла; через конфигурационный файл родительского модуля; с помощью флагов в shell-скриптах и т.д. Казалось бы, дополнительная гибкость - что плохого? А то, что на начальных этапах вы обязательно столкнётесь с ситуациями, когда настроив один инструмент, захотите добавить второй, расширяющий функциональность первого, и поймёте, что новый инструмент не работает. Виной тому часто становится банальная недосказанность в документациях инструментов о том, как они должны взаимодействовать и неосознанность возможных способов конфигурации этого взаимодействия.

• нехватка ресурсов для поиска ответов;

Из-за неимоверного количества инструментов в мире современного front end'a пытаться удержать в голове знания о каждом становится практически невозможно. Для решения данной задачи программисты часто прибегают к помощи ресурсов для поиска ответов проверенных временем (stackoverflow.com, experts-exchange.com, superuser.com, github.com и др.). Но в нашем случае проблема в том, что инструменты и их новые версии появляются настолько быстро, что мы фактически являемся их бета-тестерами и сталкиваемся с проблемами, нигде ранее не описанными, отчего не можем даже понять, возможно ли их решить или же это баг библиотеки, которую мы решили использовать.

Как избежать проблем

Недостатков мира современного javascript достаточно легко избежать, придерживаясь простых правил.

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

npm install brilliant-module-that-will-solve-my-problem-by-one-string

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

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

Заключение

Современная front-end разработка находится уже далеко за пределами чистых js/html/css. Число инструментов, призванных помочь разработчикам, растёт в геометрической прогрессии. Но это ведёт не только к позитивным последствиям. Чем больше инструментов, тем сложнее рассмотреть среди них действительно стоящие - те, которые отслужат верой и правдой на протяжении всей жизни проекта и не подведут в ответственный момент. Именно такие инструменты мы попробуем помочь вам выбрать в следующей статье.

Алексей Кудряшов
May 10, 2016
 

"Ruby предназначен для того, чтобы сделать программистов счастливыми."
~ Yukihiro Matsumoto

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

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

Разработчики используют Ruby во множестве областей: в администрировании, прототипировании, научных исследованиях, разработке игр и различных приложений, в написании скриптов и т.д. Cisco, NASA, HP и многие другие компании используют этот язык. Ruby прекрасно себя проявляет на nginx, Apache, а также имеет несколько web-серверов, написанных на самом Ruby.

Ruby – хорошо сбалансированный язык. Он был создан в 1995 году Yukihiro Matsumoto, путём объединения частей разных языков программирования, таких как Perl, Lisp, Smalltalk для формирования нового языка, который был бы естественным, но не простым языком. Этот высокоуровневый объектноориентированый язык программирования, который ещё и полноценно интерпретируем. Интерпретируемый - значит, что код программы хранится в виде обычного текста, который передаётся исполняющему его интерпретатору.

Чистоту и красоту Ruby получает благодаря тому, что программисты стараются следовать нескольким принципам:

Don't repeat yourself. Единожды написав код и положив его в нужное место мы защищаем себя от повторений кода и от ненужной работы.
Conventions over Configuration. Очень многие методы уже написаны и их следует использовать, а в крайних случаях, если умолчания нас не устраивают, мы просто переписываем их под себя. Всё для чистоты и лаконичности кода, и при этом минимум усилий.

В Ruby всё – объект. Для каждой частицы информации или кода могут быть определены собственные свойства и действия. В объектно-ориентированном программировании свойства называются переменными объекта, а действия – методами. Ruby легко может продемонстрировать объектно-ориентированный подход строкой кода, в которой производится действие над числом.

10.256.round # получим округленное число 10

Во многих языках числа и другие примитивные типы данных не являются объектами. Ruby под влиянием языка Smalltalk позволяет задать методы и переменные объекта всем типам данных. Это упрощает использование Ruby, так как правила применимые к объектам, применимы ко всему Ruby.

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

Ruby намеренно предоставляет лишь одиночное наследование, в отличие от многих объектно-ориентированных языков. Этот язык даёт нам концепцию модулей (примеси - в Scala, категории - в Objective-C). Модули - это коллекции методов. Классы могут свободно вмешивать модуль и получать все его методы. Например, любой класс, реализующий метод each, может подмешать модуль Enumerable, который добавит много методов использующих each для создания циклов.

class Collection

include Enumerable

end

Ruby был разработан большей частью на GNU/Linux, но обладает высокой переносимостью: есть возможность работать на многих типах UNIX, Mac OS X, Windows/XP/7 и так далее. Ещё один плюс -  Ruby/Rails сейчас дают реализацию практически всех успешных технологий и подходов к программированию, таких как работа с базами данных через ORM (ActiveRecord), шаблоны проектирования (Design Patterns), разработка через тестирование (TDD), полноценная модель реализации концепции MVC, использование JavaScript-framework'а jQuery.

Открытость сообщества является одной из самых важных частей Ruby. Нашёл решение проблемы, написал полезный модуль -  выложи в открытый доступ, помоги другим. На данный момент, благодаря многим людям, у нас есть доступ к тысячам готовых решений разнообразнейших задач. Сейчас не нужно ломать голову над стандартными инструментами share-кнопок в социальных сетях, почтовых рассылок, составления тестовых данных, систем авторизации и аутентификации, комментирования и т.п. -  это создано, протестировано, и прекрасно работает. Даже если вас не устраивает часть библиотеки —  допишите и предложите это сообществу, может быть именно ваша идея так необходима сейчас.

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

Мне нравится Ruby.