Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 13855 сообщений
Cообщения с меткой

разработка - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

Интеграция Apache CloudStack со сторонними системами. Подписка на события с помощью Apache Kafka

Воскресенье, 23 Июля 2017 г. 13:02 (ссылка)



В данной статье рассматривается подход к интеграции Apache CloudStack (ACS) со сторонними системами посредством экспорта событий в брокер очередей сообщений Apache Kafka.



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





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



В разрезе ACS данные функции реализуются следующими возможностями:




  1. Стандартный API — позволяет взаимодействовать с ACS типовым способом.

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

  3. Экспорт событий — позволяет взаимодействовать с внешними системами при возникновении событий внутри ACS, которые требуют действий от внешних систем.



Итак, ACS предоставляет нам все необходимые способы взаимодействия. В рамках статьи освещается третий способ взаимодействия — Экспорт событий. Вариантов, когда такой способ взаимодействия является полезным достаточно много, приведем несколько примеров:




  • уведомление пользователя посредством сторонних средств, например (SMS, IM) о некоторых событиях, например, событии остановки виртуальной машины;

  • уведомление биллинговой системы о выделении или удалении ресурсов (аккаунтинг, учет, списания);

  • уведомление биллинговой системы о новых аккаунтах ACS.



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

ACS позволяет экспортировать события в брокеры очередей сообщений двумя способами — с применением протокола AMPQ в RabbitMQ и по протоколу Apache Kafka в Apache Kafka, соответственно. Мы широко используем в своей практике Apache Kafka, поэтому в данной статье рассмотрим как подключить к серверу ACS экспорт событий в эту систему.



Экспорт событий в брокер очередей сообщений VS явный вызов API сторонней системы



При реализации подобных механизмов разработчики часто выбирают между двумя опциями — экспорт событий в брокеры очередей сообщений или явный вызов API сторонних систем. На наш взгляд, подход с экспортом в брокеры является крайне выгодным, и значительно превосходит по своей гибкости явный вызов API (например, REST с некоторым определенным протоколом). Связано это со следующими свойствами брокеров очередей сообщений:




  1. отказоустойчивость;

  2. высокая производительность и масштабируемость;

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



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




  1. отказ вызываемого кода и неотправка уведомления;

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



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



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



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



Настройка экспорта событий ACS в Apache Kafka



В рамках настоящего руководства не уделяется внимание как настроить Apache Kafka для использования в "боевой" среде. Этому посвящено немало профильных руководств. Мы же уделим основное внимание тому, каким образом подключить Kafka к ACS и протестировать экспорт событий.



Для развертывания Kafka будем использовать Docker-контейнер spotify/kafka, который включает в себя все необходимые компоненты (Apache Zookeeper и Kafka) и поэтому отлично подходит для целей разработки.



Установка Docker (из официального гайда для установки в CentOS 7) выполняется элементарно:



# yum install -y yum-utils device-mapper-persistent-data lvm2
# yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
# yum makecache fast
# yum install docker-ce


Настройка Apache Kafka



Развернем контейнер с Apache Kafka:



# docker run -d -p 2181:2181 -p 9092:9092 --env ADVERTISED_HOST=10.0.0.66 --env ADVERTISED_PORT=9092 spotify/kafka
c660741b512a


Таким образом, Kafka будет доступен по адресу 10.0.0.66:9092, а Apache Zookeeper по адресу 10.0.0.66:2181.

Протестировать Kafka и Zookeeper можно следующим образом:



Создадим и запишем в топик "cs" строку "test":



# docker exec -i -t c660741b512a bash -c "echo 'test' | /opt/kafka_2.11-0.10.1.0/bin/kafka-console-producer.sh --broker-list 10.0.0.66:9092 --topic cs"
[2017-07-23 08:48:11,222] WARN Error while fetching metadata with correlation id 0 : {cs=LEADER_NOT_AVAILABLE} (org.apache.kafka.clients.NetworkClient)


Прочитаем ее же:



# docker exec -i -t c660741b512a /opt/kafka_2.11-0.10.1.0/bin/kafka-console-consumer.sh --bootstrap-server=10.0.0.66:9092 --topic cs --offset=earliest --partition=0
test
^CProcessed a total of 1 messages


Если все произошло так, как отображено на врезках кода выше, значит Kafka исправно функционирует.



Настройка Apache CloudStack



Следующим шагом настроим экспорт событий в ACS (оригинал документации здесь). Создадим файл настроек (/etc/cloudstack/management/kafka.producer.properties) для продюсера Kafka, который использоваться ACS со следующим содержимым:



bootstrap.servers=10.0.0.66:9092
acks=all
topic=cs
retries=1


Детальное описание настроек Kafka можно найти на странице официальной документации.



При использовании реплицируемого кластера Kafka в строке bootstrap.servers необходимо указать все известные серверы.

Создадим каталог для java bean, активирующего экспорт событий в Kafka:



# mkdir -p /etc/cloudstack/management/META-INF/cloudstack/core


И сам файл конфигурации для bean-a (/etc/cloudstack/management/META-INF/cloudstack/core/spring-event-bus-context.xml) со следующим содержимым:









Перезагрузим управляющий сервер ACS:



# systemctl restart cloudstack-management


Экспортируемые события теперь попадают в топик cs, при этом имеют формат JSON, пример событий отображен далее (отформатирован для удобства):



{
"Role":"e767a39b-6b93-11e7-81e3-06565200012c",
"Account":"54d5f55c-5311-48db-bbb8-c44c5175cb2a",
"eventDateTime":"2017-07-23 14:09:08 +0700",
"entityuuid":"54d5f55c-5311-48db-bbb8-c44c5175cb2a",
"description":"Successfully completed creating Account. Account Name: null, Domain Id:1",
"event":"ACCOUNT.CREATE",
"Domain":"8a90b067-6b93-11e7-81e3-06565200012c",
"user":"f484a624-6b93-11e7-81e3-06565200012c",
"account":"f4849ae2-6b93-11e7-81e3-06565200012c",
"entity":"com.cloud.user.Account","status":"Completed"
}

{
"Role":"e767a39b-6b93-11e7-81e3-06565200012c",
"Account":"54d5f55c-5311-48db-bbb8-c44c5175cb2a",
"eventDateTime":"2017-07-23 14:09:08 +0700",
"entityuuid":"4de64270-7bd7-4932-811a-c7ca7916cd2d",
"description":"Successfully completed creating User. Account Name: null, DomainId:1",
"event":"USER.CREATE",
"Domain":"8a90b067-6b93-11e7-81e3-06565200012c",
"user":"f484a624-6b93-11e7-81e3-06565200012c",
"account":"f4849ae2-6b93-11e7-81e3-06565200012c",
"entity":"com.cloud.user.User","status":"Completed"
}

{
"eventDateTime":"2017-07-23 14:14:13 +0700",
"entityuuid":"0f8ffffa-ae04-4d03-902a-d80ef0223b7b",
"description":"Successfully completed creating User. UserName: test2, FirstName :test2, LastName: test2",
"event":"USER.CREATE",
"Domain":"8a90b067-6b93-11e7-81e3-06565200012c",
"user":"f484a624-6b93-11e7-81e3-06565200012c",
"account":"f4849ae2-6b93-11e7-81e3-06565200012c",
"entity":"com.cloud.user.User","status":"Completed"
}


Первое событие — создание аккаунта, остальные два — создание пользователей в рамках аккаунта. Для проверки поступления событий в Kafka легче всего воспользоваться уже известным нам способом:



# docker exec -i -t c660741b512a \
/opt/kafka_2.11-0.10.1.0/bin/kafka-console-consumer.sh --bootstrap-server=10.0.0.66:9092 --topic cs --offset=earliest --partition=0


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



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




  1. Настройка должна быть выполнена для каждого управляющего сервера ACS;

  2. Kafka должен быть настроен в реплицируемом варианте (обычно, 3 сервера и репликация x3);

  3. Apache Zookeeper должен быть настроен в реплицируемом варианте (обычно, 3 сервера);

  4. Настройки /etc/cloudstack/management/kafka.producer.properties должны быть подобраны с учетом требуемого уровня надежности доставки событий.

  5. Не забудьте настроить период удаления старых данных для Kafka (например, 1 месяц).



Вместо заключения



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




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

  2. Проведена проверка работоспособности для самого нового ACS 4.9.2, которая подтверждает, что функциональность исправна в данной версии продукта.

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

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



Надеюсь, что читатели найдут материал интересным и полезным для себя.


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/333928/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

RubyMine 2017.2: Docker Compose, автокоррекции RuboCop в редакторе, улучшенный VCS

Пятница, 21 Июля 2017 г. 18:09 (ссылка)

Здравствуй, Хабр! На днях мы выпустили RubyMine 2017.2, новую версию нашей IDE для Ruby и Rails, и спешим рассказать о новинке.








  • Docker Compose

  • Отладка приложений в Docker Compose

  • Автокоррекции RuboCop

  • “Хлебные крошки” для Ruby

  • Улучшения поддержки JavaScript

  • Новое в VCS

  • Пользовательский интерфейс

  • Другие улучшения



А теперь по порядку:



Docker Compose



В прошлом релизе мы анонсировали поддержку Docker. Однако пользователям значительно не хватало поддержки Docker Compose, которую мы успешно добавили в новую версию. Откройте Docker проект в RubyMine, и в настройках установите Docker Compose в качестве удаленной SDK (Preferences / Settings | Languages & Frameworks | Ruby SDK and Gems | New remote | Docker Compose). Теперь можно работать с приложениями в контейнерах, используя всю функциональность IDE от автодополнения кода до отладки. Подробнее об установке в блоге (англ.)







Отладка приложений в Docker Compose



Отладка заслуживает отдельного анонса, так как ее очень ждали. Отладчик RubyMine отныне можно использовать для приложений в контейнерах через Docker и Docker Compose. Для этого после настройки Docker/Compose в Gemfile нужно добавить гемы ruby-debug-ide и debase и установить их через команду docker-compose build, запускаемую прямо из редактора Gemfile вместо bundle install. Об этом также подробнее в блоге.







Автокоррекции RuboCop



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







Находим код, подсвеченный инспекцией rubocop как ошибка, нажимаем Alt+Enter, и, вуаля, ошибки исправлены во всем файле.



“Хлебные крошки” для Ruby



Мы добавили “хлебные крошки” для Ruby. Небольшая, но довольно полезная деталь. Показывает текущий контекст типа модулей, классов, методов, блоков, а в файлах RSpec — названий групп и примеров.







Кстати, вы также обнаружите “хлебные крошки” и в файлах JavaScript. А для HTML, XML и YAML мы обновили их дизайн.



Улучшения поддержки JavaScript



Среди улучшений для JavaScript стоит выделить следующие:




  • Новый рефакторинг Move symbol позволяет аккуратно перенести классы, глобальные функции и переменные в модулях ES6 из одного файла JavaScript/TypeScript в другой.


  • Автодополнение и навигация в JavaScript-коде теперь учитывают конфигурацию проекта (например, aliases), описанную в webpack.config.js.


  • Код внутри классов в JavaScript- и TypeScript-файлах теперь легко упорядочить с помощью нового действия Rearrange code и настроек Code Style — Arrangement и Blank lines.


  • Если вы используете ESLint для проверки форматирования кода, RubyMine предложит импортировать некоторые правила из .eslintrc в настройки форматирования в IDE и будет применять их автоматически при форматировании.


  • Для селекторов Sass и SCSS, созданных через амперсанд (&), теперь работает автодополнение в файлах HTML и навигация к самому селектору.






Новое в VCS



В Git-логе появилось сразу два новых действия: Revert и Reword.



Revert — имплементация git revert в IDE, позволяющая сделать Revert выбранных комитов.







Reword же просто позволяет переименовать любые коммиты, для которых еще не был сделан Push (не только последние).







Мы доработали настройки диалога Commit и перенесли их в отдельную вкладку Commit Dialog (Preferences / Settings | Version Control | Commit Dialog). Появилась возможность контролировать разделение заголовка и содержимого коммита пустой строкой, а также указывать максимальную длину строки.







Если вы пользуетесь IDE от JetBrains, то знаете о возможности временно откладывать текущие изменения, Shelve. Это полезно, когда, к примеру, нужно срочно переключиться на другую задачу, а текущие изменения положить “на полочку”, чтобы они не мешали выполнению срочной задачи.



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







Пользовательский интерфейс



В прошлый раз мы добавили предварительный просмотр в Find in Path. Теперь там же находится и Gutter — панель слева от редактора, содержащая номера строк, навигационные иконки, и индикаторы внесенных в файл изменений.







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



Другие улучшения




  • Улучшения в инструментах работы с базами данных.

  • Анализ кода и автокоррекции RuboCop в scratch-файлах.

  • Ряд исправлений для повышения производительности IDE.

  • Возможность создавать патчи в буфер обмена.



Скачать новую версию можно со страницы What’s new. Для новых пользователей действует 30-дневный бесплатный пробный период. Для компаний мы также готовы предоставить расширенный пробный период (90 дней).



Делитесь вашими мыслями с нами в комментариях, докладывайте о багах в трекер и присоединяйтесь к нам в Slack!
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/333880/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] MVC на чистом JavaScript

Пятница, 21 Июля 2017 г. 15:00 (ссылка)

Шаблоны проектирования часто встраивают в популярные фреймворки. Например, шаблон MVC (Model-View-Controller, Модель-Представление-Контроллер) можно встретить буквально повсюду. В JavaScript трудно отделить фреймворк от реализованного в нём шаблона проектирования, причём, часто авторы фреймворков интерпретируют MVC по-своему и навязывают программистам своё видение вопроса.







То, как именно будет выглядеть конкретная реализация MVC, полностью зависит от фреймворка. В результате мы получаем массу разных реализаций, что сбивает с толку и ведёт к беспорядку. Особенно это заметно, когда в одном проекте используется несколько фреймворков. Эта ситуация заставила меня задаться вопросом: «А есть ли способ лучше?».



Шаблон MVC хорош для клиентских фреймворков, однако, полагаясь на нечто «современное», нужно помнить о том, что уже завтра появится что-то новое, а то, что современно сегодня, устареет. Это — тоже проблема, и мне хотелось бы исследовать альтернативы фреймворкам и посмотреть, к чему всё это может привести.



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



Реализация MVC — это ещё один фреймворк?



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



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



Фреймворки не привязаны к конкретным шаблонам проектирования. Для того, чтобы отличить фреймворк от шаблона, можно воспользоваться так называемым голливудским принципом: «не звоните нам, мы сами вам позвоним». Если в системе имеется некая зависимость и при этом в определённой ситуации вы вынуждены её использовать — это фреймворк. Схожесть фреймворков с голливудом заключается в том, что разработчики, пользующиеся ими, похожи на актёров, которые вынуждены строго следовать сценариям фильмов. У таких программистов нет права голоса.



Стоит ли избегать клиентских фреймворков? Каждый сам ответит на этот вопрос, однако, вот несколько веских причин от них отказаться:




  • Фреймворки усложняют решения и увеличивают риск сбоев.


  • Проект сильно зависит от фреймворка, что ведёт к появлению трудноподдерживаемого кода.


  • При появлении новых версий фреймворков сложно с переписывать под них существующий код.




Шаблон MVC



Шаблон проектирования MVC родом из 1970-х. Он появился в научно-исследовательском центре Xerox PARC в ходе работы над языком программирования Smalltalk. Шаблон прошёл проверку временем в деле разработки графических пользовательских интерфейсов. Он пришёл в веб-программирование из настольных приложений и доказал свою эффективность в новой сфере применения.



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



Пример реализации MVC



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



При создании приложения пользоваться мы будем шаблоном MVC, строго следуя его принципам. Кроме того, в процессе решения задачи будет задействована методология экстремального программирования, а также модульные тесты. Всё будет сделано на JS, HTML и CSS — никаких фреймворков, ничего лишнего.



Освоив этот пример, вы узнаете достаточно для того, чтобы интегрировать MVC в собственные проекты. Кроме того, так как ПО, построенное с использованием этого шаблона, отлично поддаётся тестированию, попутно вы ознакомитесь с модульными тестами для нашего учебного проекта. Понятное дело, если надо, их вы тоже сможете взять на вооружение.



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



Итак, приступим.



Общий обзор проекта



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



Вот как это выглядит в виде схемы.





Схема проекта



Контроллер PenguinController занимается обработкой событий и служит посредником между представлением и моделью. Он выясняет, что произошло, когда пользователь выполняет некое действие (например, щёлкает по кнопке или нажимает клавишу на клавиатуре). Логика клиентских приложений может быть реализована в контроллере. В более крупных системах, в которых нужно обрабатывать множество событий, этот элемент можно разбить на несколько модулей. Контроллер является входной точкой для событий и единственным посредником между представлением и данными.



Представление PenguinView взаимодействует с DOM. DOM — это API браузера, с помощью которого работают с HTML. В MVC только представление отвечает за изменения DOM. Представление может выполнять подключение обработчиков событий пользовательского интерфейса, но обработка событий — прерогатива контроллера. Основная задача, решаемая представлением — управлять тем, что пользователь видит на экране. В нашем проекте представление будет выполнять манипуляции с DOM, используя JavaScript.



Модель PenguinModel отвечает за работу с данными. В клиентском JS это означает выполнение Ajax-операций. Одно из преимуществ шаблона MVC заключается в том, что всё взаимодействие с источником данных, например — с сервером, сосредоточено в одном месте. Такой подход помогает программистам, которые не знакомы с проектом, разобраться в нём. Модель в этом шаблоне проектирования занята исключительно работой с JSON или объектами, которые поступают с сервера.



Если при реализации MVC нарушить вышеописанное разделение сфер ответственности компонентов, мы получим один из возможных анти-паттернов MVC. Модель не должна работать с HTML. Представление не должно выполнять Ajax-запросов. Контроллер должен играть роль посредника, не заботясь о деталях реализации других компонентов.



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



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



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





Приложение на CodePen



Рассмотрим этот код.



Контроллер



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



var PenguinController = function PenguinController(penguinView, penguinModel) {
 this.penguinView = penguinView;
 this.penguinModel = penguinModel;
};


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



Затем подключаются события, связанные со взаимодействием с пользователем:



PenguinController.prototype.initialize = function initialize() {
 this.penguinView.onClickGetPenguin = this.onClickGetPenguin.bind(this);
};

PenguinController.prototype.onClickGetPenguin = function onClickGetPenguin(e) {
 var target = e.currentTarget;
 var index = parseInt(target.dataset.penguinIndex, 10);

 this.penguinModel.getPenguin(index, this.showPenguin.bind(this));
};


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



Когда происходит событие, контроллер считывает данные и принимает решения о дальнейших действиях. В данный момент речь идёт о функции обратного вызова this.showPenguin():



PenguinController.prototype.showPenguin = function showPenguin(penguinModelData) {
 var penguinViewModel = {
   name: penguinModelData.name,
   imageUrl: penguinModelData.imageUrl,
   size: penguinModelData.size,
   favoriteFood: penguinModelData.favoriteFood
 };

 penguinViewModel.previousIndex = penguinModelData.index - 1;
 penguinViewModel.nextIndex = penguinModelData.index + 1;

 if (penguinModelData.index === 0) {
   penguinViewModel.previousIndex = penguinModelData.count - 1;
 }

 if (penguinModelData.index === penguinModelData.count - 1) {
   penguinViewModel.nextIndex = 0;
 }

 this.penguinView.render(penguinViewModel);
};


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



Представленные здесь модульные тесты построены по модели AAA (Arrange, Act, Assert — размещение, действие, утверждение). Вот модульный тест для стандартного сценария показа информации о пингвине:



var PenguinViewMock = function PenguinViewMock() {
 this.calledRenderWith = null;
};

PenguinViewMock.prototype.render = function render(penguinViewModel) {
 this.calledRenderWith = penguinViewModel;
};

// Arrange
var penguinViewMock = new PenguinViewMock();

var controller = new PenguinController(penguinViewMock, null);

var penguinModelData = {
 name: 'Chinstrap',
 imageUrl: 'http://chinstrapl.jpg',
 size: '5.0kg (m), 4.8kg (f)',
 favoriteFood: 'krill',
 index: 2,
 count: 5
};

// Act
controller.showPenguin(penguinModelData);

// Assert
assert.strictEqual(penguinViewMock.calledRenderWith.name, 'Chinstrap');
assert.strictEqual(penguinViewMock.calledRenderWith.imageUrl, 'http://chinstrapl.jpg');
assert.strictEqual(penguinViewMock.calledRenderWith.size, '5.0kg (m), 4.8kg (f)');
assert.strictEqual(penguinViewMock.calledRenderWith.favoriteFood, 'krill');
assert.strictEqual(penguinViewMock.calledRenderWith.previousIndex, 1);
assert.strictEqual(penguinViewMock.calledRenderWith.nextIndex, 3);


Объект-заглушка PenguinViewMock реализует тот же контракт, что и реальный модуль представления. Это позволяет писать модульные тесты и проверять, в блоке Assert, всё ли работает так, как нужно.



Объект assert взят из Node.js, но можно воспользоваться аналогичным объектом из библиотеки Chai. Это позволяет писать тесты, которые можно выполнять и на сервере, и в браузере.



Обратите внимание на то, что контроллер не заботится о деталях реализации. Он полагается на контракт, который предоставляет представление, вроде this.render(). Именно такого подхода необходимо придерживаться для написания чистого кода. Контроллер, при таком подходе, может доверить компоненту выполнение тех задач, о возможности выполнения которых заявил этот компонент. Это делает структуру проекта прозрачной, что улучшает читаемость кода.



Представление



Представление заботится лишь об элементах DOM и о подключении обработчиков событий. Например:



var PenguinView = function PenguinView(element) {
 this.element = element;

 this.onClickGetPenguin = null;
};


Вот как реализуется в коде воздействие представления на то, что видит пользователь:



PenguinView.prototype.render = function render(viewModel) {
 this.element.innerHTML = '

' + viewModel.name + '

' +
   '' + viewModel.name + '' +
   '

Size: ' + viewModel.size + '

' +
   '

Favorite food: ' + viewModel.favoriteFood + '

' +
   'Previous ' +
   'Next';

 this.previousIndex = viewModel.previousIndex;
 this.nextIndex = viewModel.nextIndex;

 // Подключение обработчиков событий щелчков по кнопкам и передача задачи обработки событий контроллеру
 var previousPenguin = this.element.querySelector('#previousPenguin');
 previousPenguin.addEventListener('click', this.onClickGetPenguin);

 var nextPenguin = this.element.querySelector('#nextPenguin');
 nextPenguin.addEventListener('click', this.onClickGetPenguin);
 nextPenguin.focus();
}


Обратите внимание на то, что основная задача представления заключается в том, чтобы превратить данные, полученные из модели, в HTML, и поменять состояние приложения. Ещё одна задача — подключение обработчиков событий и передача функций их обработки контроллеру Обработчики событий подключаются к DOM после изменения состояния. Этот подход позволяет просто и удобно управлять событиями.



Для того, чтобы всё это протестировать, мы можем проверить обновление элементов и изменение состояния приложения:



var ElementMock = function ElementMock() {
 this.innerHTML = null;
};

// Функции-заглушки, необходимые для того, чтобы провести тестирование
ElementMock.prototype.querySelector = function querySelector() { };
ElementMock.prototype.addEventListener = function addEventListener() { };
ElementMock.prototype.focus = function focus() { };

// Arrange
var elementMock = new ElementMock();

var view = new PenguinView(elementMock);

var viewModel = {
 name: 'Chinstrap',
 imageUrl: 'http://chinstrap1.jpg',
 size: '5.0kg (m), 4.8kg (f)',
 favoriteFood: 'krill',
 previousIndex: 1,
 nextIndex: 2
};

// Act
view.render(viewModel);

// Assert
assert(elementMock.innerHTML.indexOf(viewModel.name) > 0);
assert(elementMock.innerHTML.indexOf(viewModel.imageUrl) > 0);
assert(elementMock.innerHTML.indexOf(viewModel.size) > 0);
assert(elementMock.innerHTML.indexOf(viewModel.favoriteFood) > 0);
assert(elementMock.innerHTML.indexOf(viewModel.previousIndex) > 0);
assert(elementMock.innerHTML.indexOf(viewModel.nextIndex) > 0);


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



Модель



В шаблоне MVC модель занята взаимодействием с источником данных. В нашем случае — с севером. Например:



var PenguinModel = function PenguinModel(XMLHttpRequest) {
 this.XMLHttpRequest = XMLHttpRequest;
};


Обратите внимание на то, что модуль XMLHttpRequest внедрён в конструктор модели. Это, кроме прочего, подсказка для других программистов касательно компонентов, необходимых модели. Если модель нуждается в различных способах работы с данными, в неё можно внедрить и другие модули. Так же, как и в рассмотренных выше случаях, для модели можно подготовить модульные тесты.



Получим данные о пингвине, основываясь на индексе:



PenguinModel.prototype.getPenguin = function getPenguin(index, fn) {
 var oReq = new this.XMLHttpRequest();

 oReq.onload = function onLoad(e) {
   var ajaxResponse = JSON.parse(e.currentTarget.responseText);
   // Индекс должен быть целым числом, иначе это работать не будет
   var penguin = ajaxResponse[index];

   penguin.index = index;
   penguin.count = ajaxResponse.length;

   fn(penguin);
 };

 oReq.open('GET', 'https://codepen.io/beautifulcoder/pen/vmOOLr.js', true);
 oReq.send();
};


Тут осуществляется подключение к серверу и загрузка с него данных. Проверим компонент с помощью модульного теста и условных тестовых данных:



var LIST_OF_PENGUINS = '[{"name":"Emperor","imageUrl":"http://imageUrl",' +
 '"size":"36.7kg (m), 28.4kg (f)","favoriteFood":"fish and squid"}]';

var XMLHttpRequestMock = function XMLHttpRequestMock() {
 // Для целей тестирования нужно это установить, иначе тест не удастся
 this.onload = null;
};

XMLHttpRequestMock.prototype.open = function open(method, url, async) {
 // Внутренние проверки, система должна иметь конечные точки method и url
 assert(method);
 assert(url);
 // Если Ajax не асинхронен, значит наша реализация весьма неудачна :-)
 assert.strictEqual(async, true);
};

XMLHttpRequestMock.prototype.send = function send() {
 // Функция обратного вызова симулирует Ajax-запрос
 this.onload({ currentTarget: { responseText: LIST_OF_PENGUINS } });
};

// Arrange
var penguinModel = new PenguinModel(XMLHttpRequestMock);

// Act
penguinModel.getPenguin(0, function onPenguinData(penguinData) {

 // Assert
 assert.strictEqual(penguinData.name, 'Emperor');
 assert(penguinData.imageUrl);
 assert.strictEqual(penguinData.size, '36.7kg (m), 28.4kg (f)');
 assert.strictEqual(penguinData.favoriteFood, 'fish and squid');
 assert.strictEqual(penguinData.index, 0);
 assert.strictEqual(penguinData.count, 1);
});


Как видите, модель заботят лишь необработанные данные. Это означает работу с Ajax и с JavaScript-объектами. Если вы не вполне владеете темой Ajax в JavaScript, вот полезный материал об этом.



Модульные тесты



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



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



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



О развитии учебного проекта



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




  • Добавить экран со списком всех пингвинов.


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


  • Добавить SVG-диаграмму для визуализации данных. Например, так можно вывести обобщённые сведения о размерах пингвинов.




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



Итоги



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



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



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



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



Уважаемые читатели! Какие шаблоны проектирования вы применяете в своих JS-проектах?
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/333856/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Superjob PHP-meetup. Прямая трансляция

Четверг, 20 Июля 2017 г. 18:37 (ссылка)

Сегодня в 18:30 по московскому времени в офисе Superjob состоится встреча PHP-разработчиков. Присоединяйтесь к прямой трансляции!











Спикеры и темы:



Алексей Коротин, старший разработчик Superjob, с докладом «Внедрение RESTful в mature проект»



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



— Как мы внедрили чистый и прозрачный REST поверх легаси

— Как нам удалось привести зоопарк технологий к единому виду

— Как отвязались от структуры хранения и перестали писать тонны DTO

— Как распараллелили разработку между командами благодаря единым стандартам

— Как стандарт помог нашим автотестам и документации

— Как сократили время на разработку нового и перестали думать о рутине

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

— Как при всем этом оставили свободу действий программисту



Антон Довгаль, Senior C Developer Badoo, с докладом «Как мы разрабатываем модули в Badoo»



Документация на тему архитектуры языка PHP скудна и разрозненна, несмотря на то что тема интересна многим. В моем докладе я постараюсь заполнить этот пробел и рассказать о модулях PHP: как они работают, зачем и как их пишут. В процессе мы рассмотрим опыт Badoo в этой сфере на примерах двух модулей. И еще напишем очень небольшой собственный модуль.



— Что такое модули PHP, как они работают

— Как начать писать свой модуль PHP

— Скелет модуля — Функции, классы, методы

— Разбор параметров функции

— Сборка модуля

— Подгрузка модуля

— Простой пример модуля из Badoo

— Сложный пример модуля из Badoo



Надежда Рябцова, Senior DevOps Engineer Skyeng, с докладом «Как медиа сервисы Skyeng переехали на Symfony 4»



Я расскажу, как мы приняли решение и внедрили в продакшн новый инструмент для сборки бекенда приложений – Symfony Flex – менее чем за один месяц. О преимуществах и недостатках подхода для сборки бандлов с помощью рецептов. Сейчас нам удалось укротить зоопарк подключаемых бандлов, и оформить схему переезда на Symfony 4 для последователей внутри компании и за ее пределами.



В своем проекте мы реализовали легковесное api для браузерных расширений и сопровождаем его стопроцентным покрытием автотестами. И я расскажу, как вписать Symfony Flex в процессы непрерывной интеграции, схожие с нашими. А также, как развивать и эксплуатировать проект на альфа версии фреймворка в продакшне.



Василий Грудистов, руководитель департамента производства QSOFT, с докладом «Как построить SOA в связке laravel и 1C-Битрикс. Опыт большого проекта»



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

— Как спроектировать сервисно-ориентированную архитектуру (SOA);

— Как создать отказоустойчивую/катастрофоустойчивую платформу;

— Как реализовать совмещение предыдущей разработки на 1С-Битрикс и не потерять взаимосвязь пользователей в SOA;

— Как организовать совместную работу 1С-Битрикс и сервисов на PHP Framework laravel в рамках одного портала, исключив необходимость внесения дублирующего кода;

— Как закэшировать ВСЁ, при этом не потерять динамические функции портала.



Александр Макаров, активный участник OpenSource проектов, один из разработчиков PHP-фреймворка Yii и его представитель в PHP-FIG, с докладом «Yii. Что дальше?»



— Что происходит с PHP: стоит ли с ним работать или пора переходить на другие языки?

— Ошибки 2.0. Что мы сделали не так и почему. Для понимания этого нужно знать историю Yii, так что немного нырнём и в неё.

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

— Планы на 3.0. Если он будет. О том, что мы никому не показываем, но потихоньку пилим.



Официальная группа Superjob IT-meetup в Facebook.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/333804/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Выбранный UI-фреймворк – вред. Архитектурные требования – профит

Четверг, 20 Июля 2017 г. 11:49 (ссылка)





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




  • Войти в метро теперь – не просто кинуть пятачок, а приложить карту Тройка, записанную на телефон и учитывающую пересадку.

  • Позвонить по телефону и посмотреть телевизор – давно уже не провести два провода в квартиру и вносить фиксированную абонентскую плату, а triple play с кучей опций и возможностей.

  • Посмотреть дневник сына – на святое же покусились! – теперь можно с планшета, заодно ответив на комментарий классного руководителя о его неудовлетворительном поведении.



Ну и я уже молчу про всякие Tinkoff, Apple Pay, Google Now, умные дома и многое другое.



Как следствие, в любой компании растут IT-отделы. То, чем раньше занимались несколько десятков сотрудников, сейчас делают команды из тысяч и десятков тысяч человек (кстати, поделитесь в комментариях, как выросли ваши IT-отделы).



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



Технологическое развитие – увеличение скорости, объема и удобства обмена информацией – позволило большим IT-коллективам не собираться в одном здании, а работать распределенной командой. И вот уже у нас огромные open-source проекты, где много команд из различных компаний, стран и континентов работают над одним продуктом.



Совместная разработка большой распределенной командой принесла следующие особенности, которые, в свою очередь, выразились в развитии соответствующих инструментов, фреймворков и передовых практик:




  • Декаплинг. Строгое разделение на back-end и front-end. REST-сервис под каждый отдельный UI.

  • Микросервисы. Каждая команда независимо разрабатывает свою часть, но все эти части должны сложиться в одно работающее приложение.



Эти особенности фактически развязали руки front-end разработчикам и позволили разным командам выбирать front-end технологии в зависимости от бизнес-задач, экспертизы команды, предпочтений и «религии».



Во многом поэтому мы сейчас наблюдаем активный рост и отсутствие явного и безоговорочного лидера в UI-фреймворках: AngularJS, ReactJS, EmberJS, ExtJS и др. При этом, вполне вероятно, надо быть готовым к тому, что завтра появится новая front-end технология, которая будет более эффективной и будет более активно поддерживаться/развиваться сообществом. Именно поэтому считаю неправильным сейчас делать долгосрочный выбор и останавливаться на одной front-end технологии. Более того, вести разработку надо так, чтобы front-end технология была относительно дешево заменяемой, всегда держать это в голове при разработке архитектуры конкретного приложения. Это задача номер один.



Кроме того, при дальнейшем увеличении команды мы будем иметь уже несколько front-end команд, которые разрабатывают одно UI-приложение. Каждая команда независимо разрабатывает свою часть, но все эти части должны сложиться в одно работающее приложение так, чтобы UI одной команды не конфликтовал с UI другой. Это задача номер два.



Для решения этих задач мы, front-end практика в компании Netcracker, разрабатываем архитектурные требования, которые обязательны для всех продуктов.



Немного теории модульного подхода



В основе архитектурных требований лежит подход, который подразумевает независимые JS-блоки и их встраивание друг в друга. У этого подхода есть несколько названий: Scalable JS Apps, Modular JavaScript, JS Portals. Такие фреймворки сравнительно молоды и, можно сказать, сделаны по принципам Николаса Закаса: если можете писать, просто пишите монолит, если нужна интеграция с различными блоками, то придется использовать модульный подход.



Терминология




  • Application (конечное приложение) – набор html/js/css, который отображается пользователю. Конечное приложение может в общем случае не использовать принципы Modular JavaScript и быть написано на любом языке, хоть на flash.

  • Application Controller – JS-объект, реализующий принципы Modular JavaScript, позволяющий модулям общаться и встраиваться рядом и друг с другом.

  • Module – JS-приложение на любом языке, подобном JS.

  • Sandbox – объект, через который Module может общаться с внешним миром.

  • Service – утилитарные объекты, имеющие логику, но не имеющие UI.

  • BroadcastService – сервис, позволяющий модулям общаться.

  • Plugin – встраиваемый в Application Controller модуль. Application Controller может использовать его, чтобы получить новый функционал.







Modular JavaScript. Принципы



Принципы основаны на том, что мы считаем каждый модуль ребенком. Поэтому к ним применимы следующие правила:




  1. Модуль может вызывать только свои методы или методы Sandbox.

  2. Нельзя смотреть на DOM вне своего Sandbox.

  3. Нельзя трогать ненативные глобальные переменные.

  4. Если модулю что-нибудь нужно, это нужно спросить у Sandbox.

  5. Не разбрасывать игрушки (модуль не должен создавать глобальные переменные).

  6. Не разговаривать с незнакомцами (модуль не должен напрямую вызывать другой модуль).



Оригинал можно прочитать здесь.



Эти принципы реализованы Николасом Закасом в ряде проектов, например здесь: http://t3js.org. Однако есть альтернативные реализации: http://openf2.org/ (хотя принципы там те же, о них рассказывается в видео).



Взяв за основу эти принципы, мы начали уточнять и развивать их в наших проектах.



Наша специфика и архитектура



Уточнения и дополнительные принципы, которые диктуются спецификой наших проектов:




  1. сервис не имеет UI;

  2. сервис обычно singleton;

  3. модули могут общаться через сервис общения (это может быть EventBus или publish/subscriber);

  4. есть только один сервис общения, общий для всех модулей;

  5. поскольку мы имеем дело с JS, нужен статический анализатор кода (например, ESLint), который запретит внесение изменений в код в случае нарушения принципов;

  6. реализация Modular JavaScript должна быть JS Agnostic, т. е. модуль может быть написан на любом языке, подобном JS;

  7. необходима поддержка модуля в модуле, так как часто хочется переиспользовать код (например, модуль table может быть отрисован внутри модуля dashboard, который, в свою очередь, рисуется на модуле tab navigation – наподобие панели c вкладками для переключения);

  8. из-за того, что модуль не может выйти за рамки своего элемента, необходим DialogManagerService, который управляет body для показа диалогового окна; модуль, который хочет показать диалоговое окно, использует модуль dialog и передает его в сервис;

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



И вот какая получается архитектура







Блок T3-NC-powered представляет собой Application Controller. У Application Controller есть набор базовых плагинов (треугольники), которые дополняют его функциональность. Плагины не имеют доступ к Application Controller. Наиболее важным является плагин, позволяющий общаться с сервером для «ленивой» загрузки модулей.



Сервисы могут обмениваться данными с Application Controller. Наиболее важным является сервис для обмена сообщениями между модулями. Также сервисы могут использовать плагины. Сервисы не имеют UI, так как предоставляют JS-функции.



При старте модуля по его имени создается Sandbox, который ограничивает модуль. Основной API – дает возможность получить сервис и DOM element, в который модулю нужно встроиться. Если необходимо запустить два модуля с одинаковым именем, то Application Controller создаст два экземпляра модулей, внутренние id которых будут разными.



Заключение



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



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



Если вы интересуетесь модульным подходом или уже вовсю используете его, пишите в комментариях – давайте делиться опытом. Мы в свою очередь готовы дать больше технических деталей, если у сообщества будет интерес.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/333734/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Локализацию можно автоматизировать: опыт использования Lokalise в боевых условиях

Среда, 19 Июля 2017 г. 20:17 (ссылка)

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



image



После редактирования и перевода вы можете скачать файлы через веб-интерфейс или интегрировать с помощью мобильных SDK, API или утилиты CLI. В случае веба возможна вставка, например, html-ключей, которые будут «подтягивать» локализованный текст в ваш проект. Платформа удобна для команд, которые не готовы постоянно влезать в проекты «на живую» ради правок в локализации, видоизменяя лишь конкретные метки (их ещё называют ключами) на стороне Lokalise.



В этой статье мы расскажем о применении Lokalise для локализации и перевода проектов компанией-разработчиком блокчейн-продуктов Ambisafe. Опытом использования Lokalise с нами поделился Алексей Матиасевич – менеджер проектов Ambisafe.



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


Изначально команда использовала ручную локализацию, идя по пути наименьшего сопротивления. «Да, мы использовали ручную локализацию», — говорит Алексей, «многие веб-разработчики до сих пор так делают, и будут делать еще долгое время». Но каждый, кто сталкивался с вопросами локализации, понимает, насколько нестройным и трудоемким является этот процесс, выполняемый вручную. В какой-то момент команда Ambisafe перешла на использование Lokalise, причем настолько давно, что по утверждению Алексея «хвостов уже не найти».



Для многих проектов достаточно трех-четырех основных языков, например, связки английский-немецкий-французский, если проект ориентирован на рынок ЕС, плюс русский. Либо же английский-французский-испанский-португальский, если ЦА проекта находится в Америке. Вариаций множество, но по утверждению проект-менеджера Ambisafe, их команда редко использовала больше четырех языков для локализации продукта.



Однако в портфолио команды есть и проекты, которые они локализовали на десяток языков. Среди них Polybius — проект по созданию регулируемого банка для цифрового поколения, который в рамках ICO собрал эквивалент $31 млн в различных фиатных и криптовалютах. В общей сложности проект был локализован на десять основных языков.



Сильные стороны Lokalise



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





Скриншот системы управления переводчиками



Но не обходится и без подводных камней. Так, использование Lokalise требует определенной сноровки и опыта от Front-end разработчиков.



«Для перевода нескольких абзацев нужно либо разбивать тексты на блоки и переводить их отдельно, либо использовать специальное форматирование текста для перевода — вставки html-тегов», — приводит пример из практики Алексей. «Опять же, далеко не у всех Front-end разработчиков с первого раза получается работать с сайтами, локализованными через этот сервис, так как в коде используются специальные конструкции для определения «ключей». Как показывает наш опыт, в некоторых случаях код просто ломают, и восстанавливать корректную работу переводов приходится более опытным коллегам».



Процесс, о котором говорит Алексей, и есть создание файлов локализации. При в­­­­ёрстке простых веб-страниц разработчики действительно могут хардкодить тексты, и для дальнейшей интеграции с любой платформой их будет необходимо сегментировать. А вот для сложных веб-страниц и веб-приложений использование файлов локализации изначально — это единственный грамотный подход. Надо сказать, что Ambisafe не единственная компания, которая борется с захардкоденными текстами, поэтому сейчас мы отлаживаем наш новый инструмент для автоматического «заворачивания» текста в метки (ключи).





Панель управления блоками для вставки фронт-эндерами



При этом платформа сэкономила команде достаточное количество ресурсов для того, чтобы сложности с внедрением и обучением новых членов команды Front-end разработки и не самые низкие цены на перевод — не стали весомыми аргументами против использования сервиса.



«Этот сервис, прежде всего, экономит время на самом процессе перевода и прикручивания их к сайту. Нужно сказать, что стоимость переводов на сервисе не самая демократичная (около половины команд переводят сами или приглашают своих переводчиков, а остальные заказывают у нас — прим. Lokalise), однако это компенсируется экономией на параллельных активностях», — утверждает менеджер Ambisafe. Например, экономия возникает на поддержке сайта — нет необходимости делать несколько версток для отдельных языков, контент меняется централизованно, проще управлять изменениями, так как переводы централизованы.



Выбирайте сервис под свои задачи



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



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

Что дальше



В ближайших статьях мы расскажем о теории и практике локализации iOS- и Android- приложений, где мультиплатформенность, универсальные маркеры вставки и мобильные Lokalise SDК творят небольшие чудеса.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/333744/

Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<разработка - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda