В мире дедлайнов правильный выбор технологии играет ключевую роль. Имея многолетний опыт за спиной, мы были вовлечены в разработку на десятках языков, с использованием фреймворков и библиотек. Собрав вместе наши знания, мы решили пролить свет на вопрос: React или Angular? и поделиться своими мыслями с вами. Так что в этой статье мы собираемся преобразовать наш опыт frontend разработки в информацию, которая поможет определить лучшую для вас технологию. Почему Angular 2? Angular JS – это open-source библиотека, предоставляющая всё необходимое для создания клиентской части сайта. Используя Angular 2, вы можете заметить, что вторая версия избавлена от ненужной сложности, которая присутствовала в предыдущей версии. Команда, работавшая над Angular 2, устранила или заменила почти все концепции первой версии. Я говорю о модулях, контроллерах, областях видимости, директивах и так далее. Однако они не остановились только на упрощении фреймворка. Они также добавили новые примечательные фичи и некоторые улучшения. Среди фич мы хотели бы выделить встроенную поддержку приложений и server-side рендеринг. Говоря об улучшениях, мы не можем упустить тот факт, что производительность Angular 2 резко возросла. Как Angular стал популярным? Тот факт, что Angular – создание Google, внушает доверие сам по себе. Фреймворк разработан таким образом, что не травмирует психику разработчиков, которые ранее учили другие технологии и языки. Многие разработчики утверждают, что если код на Angular кажется сложным – тогда ты делаешь что-то не так. Сайты, созданные на Angular JS: YouTube (for PS3), GoodFilms, Freelancer, Upwork. Итак, почему Angular 2 может быть полезным? Давайте рассмотрим его основные плюсы и минусы. Angular pros and cons by Cleveroad Почему ReactJS? В отличие от Angular, ReactJS – это JavaScript-based библиотека с открытым исходным кодом и JSX компилятором. Он в основном сосредоточен на пользовательском интерфейсе и разрешает создавать многоразовые UI рассматриваемые компоненты. Используя React, вы всегда должны помнить, что это не MVC фреймворк, а только библиотека для рендеринга вашего View (V из MVC). Таким образом, React – это интерфейс-ориентированное решение, когда ваши пользователи получают весьма отзывчивый интерфейс с плавной загрузкой. Как React стал популярным? За этим проектом стоит Facebook. ReactJS-решения дружественны с SEO. Производительность и гибкость ReactJS очень высоки. Известные сайты, сделанные с помощью ReactJS: Netflix, Feedly, Airbnb, Walmart Сейчас давайте рассмотрим, почему ReactJS может быть полезным. React pros and cons by Cleveroad Как сделать выбор? Сейчас мы глубже рассмотрим детали и нюансы, которые могут быть достаточно важными при выборе технологии. Лицензия Вы должны быть ознакомлены с видами лицензий фреймворка. Большинство лицензий довольно гибкие в работе, и вы можете использовать их для создания коммерческих приложений без каких-либо проблем. Однако существует целый ряд лицензий, которые не дают вам такой свободы действий. Лучше просто поискать информацию, нежели потом узнать, что вы не имеете права на коммерческое распространение своего продукта, не так ли? Примечание: Одним из преимуществ Angular JS и ReactJS является то, что это open-source фреймворки без каких-либо ограничений в использовании. Стоит отметить, что Angular использует MIT лицензию вместо 3-clause BSD лицензии, которая используется в React. Однако BSD отличается от MIT только присутствием запрета на использование имени владельца прав в рекламных целях. Паттерн MVC Паттерн Model-View-Controller разрешает разделять проекты на три компонента: модель, вид и контроллер. Таким образом, модификацию каждого компонента можно проводить независимо друг от друга, что способствует сжатию кода и повышению качества конечного результата. Помимо шаблонов MVC существуют также Model-View-Presenter (MVP) и Model-View-View-Model (MVVM). Примечание: Среди всех особенностей Angular 2 наличие out-of-the-box MVC паттерна является значительным преимуществом перед React. Из трёх букв акроним MVC имеет только букву «V» – View (в переводе «вид»). Так что если вам нужны буквы «М» и «С», то придётся искать их в другом месте. Размещение шаблонов Говоря о преимуществах Angular 2, стоит упомянуть о простоте написания шаблонов отображения. Имея действительно простой интерфейс, Angular позволяет получить конечный результат с более интуитивным подходом к пользовательскому интерфейсу, который требует меньше кода и кажется «очевидным». React же требует специальные функции для управления отображением данных. В основном это значит, что вам следует определить способ представления данных перед тем, как они будут внесены в DOM. Это может привести к отключению во время попыток определить, как будет отображаться определённый элемент.  Примечание: До 80% того, что вы делаете при создании онлайн-сервиса, основывается на написании пользовательского интерфейса. Так что, лучше взвешивайте подходы этих технологий к шаблонизации, чтобы понять, какой из фреймворков соответствует вашим предпочтениям в написании кода. Привязка данных Angular использует двухстороннюю привязку данных. С её помощью фреймворк может присоединить DOM к данным Model через контроллер. В двух словах: когда пользователь взаимодействует с входными данными и задаёт новое значение вашему приложению, то не только View может быть обновлен, а и Model тоже. Соответственно, вам не нужно писать какой-либо метод отслеживания этих изменений в приложении. Примечание: Подход Angular влияет на производительность из-за того, что создается вотчер (watcher) при каждой привязке данных. React использует одностороннюю привязку, где поток данных направлен только в одном направлении. Благодаря этому, вы всегда будете знать, в каком месте ваши данные меняются. Примечание: Подход React гораздо проще отлаживать, когда речь идёт о больших приложениях. Стоит сказать пару слов о клиентском и серверном рендеринге. Фактически server-side рендеринг использовался в первых версиях Angular и создавал трудности для маркетинга. Поскольку браузер воспринимает рендеринг клиентской стороны, то JavaScript дает отличные возможности для SEO оптимизации. Это является существенным недостатком, ведь большинство цифровых продуктов нуждаются в маркетинговой поддержке, дабы остаться в живых. Кроме того, client-side рендеринг может сильно повлиять на загрузку страниц. Однако начиная со второй версии, разработчики Angular исправили эту проблему, перенеся модель рендеринга на сторону сервера. Производительность Как вы знаете, Angular создает наблюдатель (watcher) для каждой привязки данных, чтобы отслеживать все изменения в DOM. Как только View получает некоторые обновления, Angular начинает сравнивать полученные значения с начальными. Дело в том, что данная технология проверяет не только те значения, которые изменились, но и все остальные тоже. Примечание: Производительность Angular 2 может стать причиной проблем для массивных приложений. Разработчики ReactJS ввели концепцию виртуального DOM, которая позволяет создавать легкое дерево DOM, сохраняя его на сервере. Каждый раз, когда пользователь взаимодействует с сайтом, например, заполняет форму, React создает новый виртуальный DOM для сравнения с предыдущим. После того, как библиотека обнаружит все различия между этими двумя моделями – виртуальный DOM будет перестроен. Весь процесс на сервере выполняется, таким образом снижая нагрузку на браузер. Примечание: Производительность ReactJS возрастает, когда дело доходит до больших объемов данных, поскольку в этом фреймворке нет вотчеров. Взгляните на график, показывающий оценку React и Angular по некоторым критериям. Эти оценки основаны на нашем личном опыте. Cleveroad evaluation of technologies У нас было небольшое собрание, посвященное вопросу «React или Angular?», в ходе которого наши frontend разработчики имели возможность обсудить все плюсы и минусы этих технологий. Они пришли к выводу, что Angular лучше подходит для их предпочтений в написании кода, а также для рабочих задач, с которыми они сталкиваются ежедневно. Для подведения итога всему сказанному выше мы подготовили для вас график. В нём сравниваются Angular 1.X, Angular 2 и React. React vs Angular versions Опыт Cleveroad Из этих двух технологий наши разработчики предпочитают Angular. Имея много наработок, связанных с этим фреймворком, мы способны работать более эффективно, сокращая время, необходимое для реализации проекта. Таким образом наши клиенты экономят на стоимости проекта из-за сокращения часов разработки. Все наши проекты, основанные на этой технологии, имели большое количество frontend-логики в своей структуре, которая часто изменяется. Кроме того, в проектах предусматривался ряд изменений в дизайне. Использование библиотеки React может увеличить время разработки и повысить общую стоимость конечного продукта. Вот некоторые из наших проектов: Age In Days, Count, Lifetile. Все эти веб-сайты основаны на AngularJS в нашей компании. Вы также можете посмотреть наш tech stack, который мы обычно применяем вместе с разработкой на Angular 2. Серверные решения: AWS, DigitalOcean, Hetzner, Microsoft Azure Back-end технологии: Node.js + Typescript 2, Angular 2 Базы данных: MySQL, MongoDB, Redis, PostgreSQL Облачные хранилища: WS S3, Azure storage Платёжные системы: Stripe, Braintree Инфраструктура и управление проектами: Webpack 2, Docker и CI, Jira, Bitbucket / Git Подводя итог Вероятно, проблема выбора между Angular и React в мире frontend может быть сопоставима с выбором между iOS и Android. Обе технологии имеют свои преимущества и недостатки, своих поклонников и ненавистников. Таким образом, у каждого разработчика есть определенные причины использовать ReactJS или другую технологию. В 2017 году все больше веб-проектов будет основано на Angular 2 благодаря фичам, позволяющим упростить жизнь разработчиков. Например, хорошая отладка, шаблон MVC, рендеринг на стороне сервера и т. д. В результате это сократит количество часов, необходимых для разработки, и, соответственно, снизит цены на разработку и обслуживание. Оригинал- https://www.cleveroad.com/blog/react-vs-angular-ultimate-performance-research-2017#.WKMPN5BkZMM.twitter

В этой статье мы рассмотрим, что вкладывается в понятие «микросервис», в чем состоят преимущества микросервисов в разных сферах деятельности. Business и Project Management Создание микросервиса, который соответствует требованиям в контексте управления бизнесом и проектами, имеет большое значение для большинства разработчиков и ИТ-специалистов – это именно то, что приносит выигрыш. Микросервис представляет собой направленный на решение одной задачи фрагмент кода, который продолжает функционировать и правильно работать, даже если «весь мир остановился». С точки зрения управления проектами, ценность микросервиса заключается в том, что он проходит и продолжает работать без прямых зависимостей от других систем. Например, поскольку у него есть собственное хранилище данных, и он не делает никаких вызовов внешних API, чтобы получить необходимую для работы информацию, для микросервиса не важно, работает ли общая база данных/имеет ли она доступ к API. Это очень сильно сокращает накладные расходы на координацию с другими командами, потому что команда, владеющая сервисом, может намного легче выполнить свои задачи, не будучи заблокированной другими зависимостями. Усилия по обеспечению качества также значительно сокращаются, поскольку полностью автономная служба не может быть нарушена побочными эффектами от другого кода, который, например, обновляет одну и ту же общую базу данных. Если провести аналогию с едой и напитками, то причину создания микросервиса можно описать так: ваша кофеварка будет работать независимо от того, подключен тостер или нет. Для бизнеса корректно реализованная архитектура микросервиса подразумевает лучшие варианты для продукта: Если вы продаете онлайн виджеты и создаете сервис оплаты, можно будет предлагать сервис оплаты за любые другие товары или услуги, а не только за виджеты. Автономные микросервисы гораздо более универсальны при выходе на новые рынки. Ваша микроволновая печь будет полностью независима от посудомоечной машины. Хотя первоначально микроволновка предназначалась для использования в домах, она прекрасно справится с работой на яхтах и космических кораблях, независимо от того, идет ли речь о посудомоечной машине или нет. Computer Science Микросервис - это state machine. Его состояние представляет собой транзакционную границу. Представьте себе светофор: Цвет, который должен появиться, зависит от цвета, который светофор показывает на данный момент. Если «currentColor=green», тогда команда «Switch to next color» может работать правильно только в том случае, если никто другой не переключает свет на следующий цвет, пока обрабатывается ваша команда «Switch to next color». Так что любой «микросервис», который не представляет транзакционную границу, будет подвержен побочным эффектам от других компонентов системы (как на примере светофора). И больше не будет соответствовать бизнес- и управленческому пониманию микросервисов. Software Engineering Любой отдельный фрагмент кода, который можно рассматривать как черный ящик, где единственный способ связи с ним через его API, можно рассматривать как «микросервис». Когда микросервис оценивает бизнес-правила, то для принятия решений использует те источники информации, которые были переданы в предыдущих вызовах API, а также параметры текущего вызова API. Пример работы микросервиса в поиске событий или совместной работы событий на основе архитектуры.  Publish-subscribe – это хорошее решение для координации потока информации между службами, поскольку приводит к более слабой связи, чем в альтернативных вариантах. Известный Bezos memo расшифровывает это как для целых команд, так и для «микросервисов» любого размера. По каким причинам – смотрите выше в “Business и Project Management”. Не нужно читать об установке термостата центрального отопления, чтобы просто отрегулировать температуру морозильника. Networking & Infrastructure Микросервис представляет собой набор компонентов (например, контейнеров, логических или физических баз данных и т. д.), которые обеспечивают определенную часть бизнес-функций. Их можно создавать, уничтожать, масштабировать и контролировать как единое целое. Они продолжают работать правильно, даже если все остальные службы не работают. Хорошим показателем качества внедрения микросервиса и проектирования его инфраструктуры является возможность контроля, оповещения и масштабирования на основе запросов бизнеса, а не технических критериев. Например, «Обработка платежей не работает (... но выполнение заказа продолжает работать нормально)». Что означает «работа в нормальном режиме»? Если обработка платежей не работает, то как все может «работать в нормальном режиме»? Работа в нормальном режиме означает отсутствие ошибок и отсутствие ошибочного принятия решения из-за неправильных данных. Это может быть достигнуто посредством конечной согласованности. Например, выполнение заказа инициируется событием PaymentProcessed. Ни одно из них не может произойти, если обработка платежей не работает, поэтому выполнение будет завершать заказы, обработка платежей которых происходила до отключения, но не последующие. Когда обработка платежей вернется в оперативный режим, служба выполнения начнет получать события PaymentProcessed для пропущенных заказов и будет постепенно догонять. С точки зрения UX, это означает, что у предприятия есть варианты для разработки отказоустойчивых приложений. То есть вместо полного сбоя в работе, функции, которые обрабатываются незатронутыми микросервисами, могут оставаться доступными для пользователей. Вывод «Микросервис» ничем не отличается от многих компонентов, которые составляют сложную технику, окружающую нас каждый день: Минимальная зависимость от других механизмов («Требуется 12В от аккумулятора автомобиля и подключение к антенне») Четко определенный API как единственный способ взаимодействия с микросервисом («Единственный способ отрегулировать громкость – с помощью этой ручки»). Причины, по которым микросервисы работают в более развитых отраслях это: облегчение разделения труда, простое взаимодействие с механизмами и скорость их создания с меньшим количеством ошибок. Источник

В этой записи нашего блога мы хотели бы обсудить некоторые значительные изменения, которые были сделаны в сборщике мусора (GC от англ. garbage collector) .NET 4.6.х. Мы рекомендуем Вам использовать самую последнюю версию, 4.6.2. Наш главный разработчик, Маони Стивенс описала улучшения, которые были реализованы в 4.6.2. фреймворке. Эти изменения были сделаны для того, чтобы улучшить производительность фреймворка и позволить сборщику мусора работать более эффективно. Как сделать закрепление объектов более эффективным В предыдущих версиях .NET Framework, когда объект определялся как прошедший проверку закреплённый объект, мы не могли перемещать этот объект и смежные ему существующие объекты. Поскольку мы оставляем закрепленные объекты в поколениях 0 и 1 (таким образом вы сможете вскоре использовать свободное пространство между ними), это значит, что нам необходимо просматривать их во время выполнения сборки мусора. Если бы многие другие объекты вокруг закрепленных объектов пережили бы процесс сборки мусора, тогда время сбора мусора в 0 и 1 поколениях могло бы быть больше желаемого. Начиная с версии 4.6.2, это ограничение было отменено, так что мы можем собирать смежные существующие объекты вокруг закрепленных объектов. Во время тестирования мы заметили впечатляющие улучшения времени сбора в сценариях, где сборщик мусора искусственным образом закреплял многие объекты. На рисунке Before два не закрепленных объекта собираются, но не закрепленный объект рядом с закрепленным остается в gen0. В 4.6.х, это ограничение было отменено, так что мы можем переносить смежные существующие объекты вокруг закрепленных. Во время тестирования мы заметили впечатляющие улучшения времени сбора в сценариях, где сборщик мусора искусственным образом закреплял многие объекты. На рисунке After мы можем увидеть, что не закрепленный объект, следующий по отношению к закрепленному, переходит в следующее поколение: Если вы закрепляете много объектов, например, при длительных операциях ввода-ввывода, при этом наблюдаете длинные паузы сборщика мусора, вы, скорее всего, извлечете выгоду из этого изменения. Более эффективное использование свободного пространства во втором поколении В предшествующих версиях фреймворка при переносе объектов из поколения 1 в поколение 2 использовалась техника first fit, а это означало, что GC не использовал память, которая не подходила для хранения объекта. Эта техника приводила к потере памяти. На рисунке Before, мы видим, что F0 область освобождена, потому что была слишком мала для того , чтобы сохранить выживший объект S. Мы смогли поместить S в F1 при этом часть F1 остается (для дальнейшего уплотнения памяти при переносе из gen1). Чтобы улучшить этот подход и более эффективно использовать память, мы ввели список, в котором мы размещаем объекты слева направо в свободном пространстве в сегменте, который подходит по размеру. Мы должны очень аккуратно относиться к использованию маленьких сегментов, так как их может быть очень много. Также, мы работали над политиками определения сегмента, который следует попробовать использовать для хранения объекта, так как мі не хотим продлевать сборку мусора в первом поколении поиском свободного подходящего места в памяти. Мы хотим продолжать делать сборку мусора в фоновом режиме где это возможно, чтобы более эффективно использовать свободное пространство. На картинке After F0 остается в свободном списке и может быть использован для уплотнения памяти объектами из gen1. И мы сразу пробуем поместить S в F1. Если вы наблюдаете увеличение памяти gen2, то одной из причин может быть то, что у вас закончились элементы в свободно списке. Следовательно, продвижение оставшихся объектов из gen1 потребует увеличение размера gen2. Для сценариев, которым помогает это изменение, вы увидите, что размер gen2 увеличивается намного медленнее, и мы сможем разместить больше коллекций gen1 для каждой коллекции gen2. Это также означает, что вы будете видеть блокировку gen2 реже, потому что, когда куча становится слишком большой, это приводит к чрезмерной загрузке памяти, мы будем блокировать gen2 и выполнять уплотнение. В наших тестах, мы наблюдали сценарии, в которых соотношение количества сборов в поколениях gen1 и gen2 возросло в 20 к 1 -  более чем 200 сборам для поколения gen1 для каждого сбора в поколении gen2. Резюме Если вы столкнулись с ситуациями, описанными выше, вам обязательно нужно попробовать .NET 4.6.2, чтобы получить преимущества улучшений в сборщике мусора. Источник

Иногда стоит обернуться назад и посмотреть на мир разработки глазами новичка. В компании Progress мы часто используем Angular. Angular — это основная составляющая нашего веб-фреймворка Kendo UI, так же, как и фреймворка для мобильных приложений NativeScript. Поэтому у нас часто спрашивают, что такое Angular и как его использовать. Когда появился Angular? Кем он поддерживается? Почему мы используем Angular? Когда его лучше не использовать? В этой статье мы ответим на эти и некоторые другие вопросы. Мы рассмотрим, что являет собой Angular, как он появился и в каких случаях его лучше всего применять. После этого кратко рассмотрим несколько примеров того, как работают Angular-приложения. Но давайте все по порядку. Как же появился Angular? Angular появился как side project. В 2009 году Miško Hevery и Adam Abrons выпустили проект под названием <аngular />, чтобы помочь разработчикам, а также и дизайнерам создавать веб-приложения, используя простые HTML-теги. Имя “Angular” пошло от угловых скобок или “<>”, которые обрамляли все теги. Например, < div >, < span > и другие.  Miško рассказал о том, как возникла идея создать фреймворк в интервью 2013 года: “Мы хотели понять, можно ли упростить работу веб-дизайнеров, а не только разработчиков. Смогут ли они добавить еще больше HTML в свой код, чтобы превратить обычную статическую форму во что-то более стоящее, что можно отправить по емейлу. Идея заключалась в следующем: будь у вас небольшой бизнес, продающий пиццу или что-либо другое, то вы могли бы добавить простую систему заказа, используя необходимые теги, и они действительно отправляли бы письмо на сервер." Поскольку домен angular.com был занят – собственно, как и сейчас – создатели фреймворка переименовали Angular в GetAngular и выпустили небольшой сайт, на котором можно было узнать о всех фичах фреймворка. Домашняя страница Angular по состоянию на декабрь 2009 года (из Internet Archive).  Скоро Miško начал работать в Google, а в 2010 году занялся проектом Google Feedback. Miško убедил своего менеджера, Brad Green, переписать проект, используя его Angular. Оптимизация сроков и кода, которые показала команда в работе, помогли убедить Google в силе Angular. Brad Green и Miško Hevery показывают, как много времени и сил удалось сэкономить на проекте, используя Angular. Это скриншот презентации на конференции ng-conf 2014 keynote, которую стоит посмотреть, если вы хотите знать всё о происхождении Angular. Вскоре после успеха Google Feedback та же команда переписала open-source библиотеку и в мае 2011 года была выпущена версия Angular 1.0. В течение нескольких лет Angular стремительно набирал популярность, и сегодня Google заявляет, что более 1,5 миллиона разработчиков используют Angular. Что делает Angular? Angular — фреймворк JavaScript, который помогает разработчикам создавать приложения. Библиотека предоставляет множество фич, которые делают простые реализации сложных задач современных приложений, таких как привязка данных, маршрутизация и анимация. Angular также представляет ряд конвенций о подходах к разработке приложений. Это может быть очень полезно для больших команд, которые должны работать вместе на одном проекте. Angular - это одна из немногих библиотек JavaScript, которые обеспечивают обширный style guide с большим количеством наглядных примеров того, как вы можете писать свой код, используя этот фреймворк. Когда использовать Angular? Технически вы можете использовать Angular где угодно, но лучше всего он работает в нестандартных приложениях с данными. Если вы ознакомитесь с различными приложениями Angular, собранными на madewithangular.com, вы увидите реальные приложения, которые собирают данные из форм и работают с ними. Angular работает не только с формами. Разработчики создали множество игр при помощи Angular и такие сумасшедшие вещи, как приложения с дополненной реальностью. Однако, большинство туториалов и документации по Angular все равно содержат информацию о создании некоторых form-based приложений. Например, вы встраиваете документацию Angular в приложение, где вы создали героев и их список через форму. Окончательный результат демо-приложения Tour of Heroes из Angular документации. Angular хорош в form-based приложениях, он подходит для больших и сложных приложений. Angular - не самый простой и не самый маленький фреймворк JavaScript. Следовательно, если вы создаёте нечто небольшое, вам лучше подобрать для работы фреймворк попроще, например, jQuery. Angular хорошо подойдёт для разработчиков приложений в средних и больших командах. Если вы разрабатываете приложение самостоятельно, может показаться, что шаблонного кода и конвенций разработки в Angular намного больше, чем вам нужно. Angular также хорошо подходит для приложений, которые должны работать в нескольких средах разработки. Если приложение должно работать на веб, а также на Windows или Maс, вы можете придерживаться одного из многочисленных туториалов для запуска Angular-приложений с популярным Electron project. Если же у вас приложение, которое нужно запустить на веб, iOS или Android, можете использовать NativeScript для рендеринга вашего приложения в мобильной среде. В некоторых случаях вы даже можете распространять код через эти платформы, экономя ценное время разработки. Кто поддерживает Angular? Angular Core Team состоит из большого количества людей во всем мире и из сообщества Angular. При этом большая часть разработок Angular изо дня в день осуществляется сотрудниками Google. Примерно 20 сотрудников Google входят в Angular Core Team и все ТОП-разработчики проекта Angular являются сотрудниками Google. Следует отметить, что, несмотря на контроль Google над Angular, сам фреймворк по-прежнему много в чём зависит от усилий сообщества. Более двух тысяч человек внесли свой вклад в open-source репозиторий Angular, в общем доступе есть бесчисленные туториалы и guides, многочисленные компании предлагают обучение и набор инструментов для разработчиков. Если контроль над проектом принадлежит одной компании, это неплохо, так как снижает конфликтные вопросы при принятия нестандартных решений. Какую версию Angular мне лучше использовать? На данный момент существует две популярные версии Angular. Версия 1 доступна на https://angularjs.org/  и является обновлённой версией того Angular, что был представлен Miško и его командой в 2011 году. Другая популярная версия теперь называется просто Angular и доступна на https://angular.io/. Современный Angular – это полностью переделанная версия для новых браузеров, рабочих процессов и платформ разработки. Почти во всех случаях вам следует придерживаться последней версии Angular. В ближайшем будущем команда Angular будет стремиться поддерживать Angular 1, но нет никаких оснований полагать, что они будут поддерживать и более старые версии. Более того, Angular 1 не допускает использования библиотеки вне браузера, поэтому вы не можете воспользоваться такими библиотеками, как NativeScript для создания мобильных приложений. Как выглядит Angular-приложение? Теперь, когда вы имеете некоторое представление об Angular, давайте углубимся в код. Начнём с небольшого приложения “hello world”. Все приложения Angular начинаются с НТМL-страницы, которая выглядит следующим образом. В реальном приложении тег < script > внутри тега < head > может быть немного сложным, но в высокоуровневых приложениях он такой же, как и другие веб-приложениях – вы загружаете кусок JavaScript-кода в HTML-документ, и приложение работает.   Есть одна уникальная вещь в выше приведённом примере – элемент < my-app >. Вы не используете этот элемент регулярно в веб-приложении. Цель Angular – постоянно расширять словарь НТМL, позволяя вам определять собственные теги. Такие пользовательские теги называют компонентами, и вы можете определять их поведение в коде. Вот простейшая реализация элемента < my-app >: Есть несколько моментов, которые вам нужно знать, чтобы понять, что происходит в данном фрагменте кода. Первое – это код на TypeScript, а не на JavaScript. TypeScript может показаться вам пугающим, если вы не встречались с ним раньше, но его основы понять нетрудно. TypeScript – надстройка над JavaScript, то есть весь синтаксис JavaScript доступен на TypeScript. Кстати, весь приведённый выше синтаксис – import, export, @Component и остальные – это или нынешние фичи JavaScript, или те, что появятся в ближайшем будущем. Так что, когда вы учите TypeScript, вы изучаете будущее JavaScript. TypeScript, к тому же, отличается превосходной документацией, к которой вы можете обратиться в любое время. TypeScript был создан и поддерживается Microsoft. Он стал очень популярным за последние несколько лет, поэтому можете смело использовать его в разработке своих приложений. Он никуда не денется. Давайте еще раз посмотрим на TypeScript-код, определяющий компонент < my-app >: В Angular вы используете тег @Component, который известен как декоратор, чтобы отметить классы, которые учитывают элементы, которые могут быть использованы в вашей HTML-разметке. У вас есть возможность передавать свойства @Component для описания элемента.  Свойство selector определяет имя тега при вводе в HTML. Использование селектора < my-app > показывает Angular, что делать, когда он видит тег < my-app > в HTML. Свойство template контролирует, что HTML должен делать, когда используется компонент. Пример использования template: "< h1 >Hello World< /h1 >", тут видно, как Angular определяет, какие действия применять при < my-app > и почему это приложение представляет базовый тег < h1 > при предварительном просмотре в браузере.  Отображение базового примера “Hello World” в браузере. Зачем мне использовать Angular? Angular- не самый простой в мире фреймворк, и понадобится время, чтобы понять те концепции, на которых он построен. Но когда вы возьметесь за Angular, то сможете делать действительно крутые приложения, обходясь небольшим количеством кода. Например, вы хотите добавить привязку данных к предыдущему примеру. Для этого используется очень простой синтаксис. Хотите построить форму для запуска приложения? Хотите, чтобы эта форма имела валидацию данных и двустороннюю привязку? Для этого есть простой гайд. Ваше приложение слишком большое и вы хотите структурировать его? И для этого тоже создан гайд. Попали в модульное тестирование и хотите знать, как проверить код? Такая возможность тоже есть. Хотите добавить такие профессиональные виджеты, как диаграммы и графики? Kendo UI и похожие фреймворки упрощают добавление этих высококачественных компонентов пользовательского интерфейса. Пользуясь Angular, не рассчитывайте на простоту фреймворка, но будьте уверены в его невероятной надёжности и хорошей документации. Этот фреймворк прошёл не одно боевое испытание и заслужено используется миллионами разработчиков для написания крутых приложений. Сообщество Angular – огромное, и все хелпы легко найти в Google, Stack Overflow и по всему интернету. Ищите разработчика? Тысячи Angular девелоперов откликнутся на ваш запрос. Есть даже специальные рекрутинговые сайты. Я уже упоминал о том, что Angular – мультиплатформенный? Вернемся к нашему примеру Hello World. У вас уже есть начало для iOS и Android приложения – просто переключите элемент HTML на компонент, который NativeScript может отобразить в мобильной среде, как , например. Вот так примерно будет выглядеть код. А вот как этот код работает в нативных iOS и Android приложениях. Angular делает это и многое другое возможным. От создания потрясающих приложений до расширения мультиплатформенной разработки, Angular может стать отличным решением для вашего следующего проекта.   Если вы ищите больше информации о том, что может предложить Angular, начинайте изучать туториалы по быстрому старту работы с Angular и начинайте кодить. Если вы хотите использовать Angular для разработки мобильных приложений, посмотрите, как использовать его с NativeScript. Вы изучите один из самых популярных фреймворков JavaScript, когда будете знакомиться со столь популярным миром мобильной разработки. Оригинал статьи: http://linkis.com/telerik.com/7vemI

Angular – технология с полным набором инструментов и к тому же с лучшими вариантами подхода к решению. Кому-то он подходит, а кому-то – нет. С другой стороны, React – небольшая технология, которая необходима вам только при создании какого-то приложения.  Обе технологии имеют свои достоинства и недостатки. Какая из них подойдёт вам больше? Попытаемся выяснить в этой статье. Технологии Вот основные технологии, о которых я буду говорить: Angular React Vue Кривая обучения Допустим, вы знаете JavaScript + ES2015 достаточно хорошо. Какую следующую технологию будет проще выучить? Vue – наилучший выбор, если вы ищите легкости в процессе изучения технологии. React – менее абстрактный, тем не менее, вам понадобится больше времени, чтобы изучить best practices, так как есть много вариантов написать одно и то же или ошибиться. А вот после изучения Angular вы также будете знать всё, что связанно с ним (typescript, MVC…). Angular - большая технология и учить придётся долго.   Масштабируемость Angular - легко масштабируемый благодаря своему дизайну, который так же хорош, как и мощная командная строка. React требует больше проверок и поэтому более масштабируемый, чем Vue и, я думаю, что частично это правда. Vue идёт сразу после React. Он хорош, однако ему не хватает лучших практик масштабируемости, из-за чего вы получаете очень запутанный код. Совместимость с другими технологиями React. Несмотря на то, что он не работает с DOM-деревом, он основан на чистой JavaScript логикe и популярeн настолько, что содeржит в сeбe альтeрнативы библиотeкам, работающим с DOM. Vue прекрасно работает как с ДОМ-деревом, так и с JavaScript. Второе место занимает лишь потому, что у него меньше библиотек, которые могли бы быть действительно полезны для обоих (как для ДОМ, так и для JavaScript). Angular мог бы быть лучше, если бы не typescript, который требует строгой типизации.   Инструменты React, Angular and Vue. Все перечисленные технологии имеют отличные CLI и работают с любым инструментом по типу webpack. Пользователи и популярность React точно стал наиболее популярным в 2016, когда его стали использовать англоговорящие frontend и full stack разработчики. React – хороший выбор для мобильных и даже десктопных приложений на JavaScript. Vue и Angular. Vue – потому что он очень быстро развивается. Angular – потому что он создан Google, а его предшественник Angular 1 был когда-то очень популярен. Востребованность React и Angular. В зависимости от того, где вы находитесь, зависит, какая технология будет доминировать. Angular больше используют в Азии, особенно в Индии, а React – в англоязычных странах, таких как US и UK. Vue менее популярен и не поддерживается большими компаниями, поэтому остальные отдают предпочтение Angular и React. Производительность По этому параметру не ставлю ранги, так как все они сопоставимы. Возможно, React станет немного быстрее, когда полностью будет поддерживать Fiber, но сейчас существует только бета-версия. Перспективы для компаний Angular имеет open source лицензию. Он поддерживается Google, что, возможно, делает его лучшим выбором для компании, и разница между проектами Angular невелика.    React был бы очень хорошим выбором, если бы не лицензия с патентом. Однако, существуют бесплатные альтернативы, которые работают также, как и React. Например, Infernojs или мой любимый rax. Vue – не дитя большой компании, это очень успешный сторонний проект одного человека. Компании часто игнорируют его, хотя, возможно, и не стоило бы. Вне сети Рендеринг –  как раз то, о чем можно много говорить. Все технологии способны осуществлять его, но некоторые справляются лучше, чем другие. React – лучший выбор благодаря react native, alibaba rax, reactWindows и next.js. Vue подойдёт vue-разработчикам, которые предпочитают разработку под мобильные устройства. Спасибо за это alibaba weex. У Angular есть ionic 2 и nativescript, но эти технологии не позволяют достичь производительности react native. Простота и длина кода Vue имеет предварительно встроенные привязки данных и MVC модель, его легче настроить, нежели Angular и React. React пугающе прост для понимания, но нужно реально много времени, чтобы настроить react project. Angular совсем непростой. Эта сложность вызывает много путаницы 3rd party libraries и синтаксиса. Время разработки Vue, безусловно, лёгок в установке и не требует много изменений или синтаксиса, за что его и любят. Он был создан для борьбы с утомительной работой. React настраивается дольше, но после начала работы над приложением будет легко добавлять новые фичи. Angular хоть и является весьма конкурентоспособным, но количество ненужного синтаксиса, который он требует для работы простых вещей, отбрасывает его на последнее место. Размер Vue - наименьший и много в себе содержит. Вы можете подумать, что это не имеет значения, но если речь пойдёт о дешёвом Android 3G смартфоне, то вы уже не будете так уверены. React - больше чем Vue, но все же меньше, чем Angular. Angular - больше всех предыдущих, что вызывает увеличение времени загрузки и проблемы производительности на мобильных устройствах. Будущее Вот лично мои прогнозы для этих технологий на 2017 год: Vue будет приобретать популярность и всё большее количество разработчиков переключится на него. Вполне вероятно, что это может заставить крупные компании продвигать и поощрять Vue. Команда React представит Fiber  и сделает React быстрее, чем Vue и Angular. Создатели Angular попытаются привлечь больше людей, но, скорее всего, им это не удастся. Так что же лучше для вас? Подводя итог, можно сказать, что нет идеального решения, и никогда не будет. Тем не менее, вот полезные советы, которые помогут вам сделать выбор: Если вы разработчик «до мозга костей», тогда попробуйте все и выбирайте между Vue или React, доверяйте своему чувству. Если вы новичок в разработке, выбирайте или Vue, или React. Angular подойдёт компаниям с большими командами. Google -> Angular. Если любите простоту, тогда выбирайте Vue. Если нравится использовать шаблоны, тогда выбор стоит между Vue или Angular. Если предпочитаете JavaScript и JSX, попробуйте поработать с каждой технологией. Если вы работаете с Typescript, используйте Angular или Vue. Выбирайте подходящую технологию поскорее, не стоит пребывать в неопределённости. Я сомневался несколько месяцев, и это было невесело. Я решил пожертвовать популярностью и выбрал то, что считал для себя наилучшим вариантом – Vue. Ютубер funfunfunction сказал лучшее, что я когда-либо слышал про JS framework fatigue: «Существует точка в вашей карьере программиста, когда вы понимаете, что это не лучший инструмент». Здесь нет правильного или неправильного выбора, его просто необходимо сделать. Так что, продолжайте учиться и исследовать. Все будет учить Вас чему-то новому. Оригинал статьи на английском языке. 

Мир технологий стремительно проникает во все сферы нашей жизни. Big data и  достижения в области вычислительной техники постоянно повышаются и, соответственно, повышают уровень повседневной жизни, предоставляя больше доступных возможностей в решении проблем и предлагая больше средств для повышения наших знаний. Виртуальная реальность  стала последним достижением популярных технологий. Идея создания VR находилась в разработке в течение многих лет и совсем недавно стала реальностью, которая способна изменить нашу жизнь, и особенно нашу рабочую среду. Простой интернет-запрос выдаст, что устройства, поддерживающие VR, уже можно приобрести для личного пользования. Они особенно популярны в игровой индустрии в таких компаниях, как PlayStation, Facebook и Xbox, которые предлагают механизмы виртуальной симуляции для усиления интерактивного опыта и создания связей по всему земному шару. Однако виртуальная реальность стала чем-то большим, нежели просто геймерской фишкой. Она предлагает бесконечные возможности в различных отраслях и уже используется для улучшения работы как в нефтегазовой промышленности, так и в автомобильной индустрии. Передовая технология оказывает значимое влияние на обучение и образование, где её преимущества огромны. Возьмём медицину, например. Недавно врачи смогли провести операцию на открытом сердце, используя загруженные файлы компьютерных сканирований и VR-технологию. Будучи в состоянии визуализировать опыт и моделировать среду, виртуальная реальность даёт возможность практиковать и развивать навыки совершенно революционным путём. Так же, как и моделирование медицинских процедур, компании имеют возможность демонстрировать повышенную подготовку к торговым показам для сотрудников или даже для клиентов, чтобы они испытали продукт или услугу за счёт использования виртуальной реальности. Возможности, предоставленные технологиями VR,  наряду с повышением навыков и психологической подготовкой, станут большим достижением в мире деловых отношений. То же самое относится и к строительству, маркетингу, e-commerce, туризму и в значительной степени к индустрии развлечений. TechNet IT и Melody VR совершают огромный прогресс в мире музыки благодаря живым концертам и использованию технологий виртуальной реальности. Наушники VR позволят фанатам не только слушать музыку или смотреть клипы, но и окунуться в  атмосферу живого шоу, ощутить эффект присутствия. Этот тип интерактивной VR открывает широкие возможности благодаря  доступности, устраняя такие препятствия, как время и деньги. Для преуспевания компании в условиях постоянной конкуренции виртуальная реальность обеспечивает неограниченную способность к расширению границ, преодолению барьеров и максимизации производительности. Всего лишь имея доступ к развитию навыков обучения на работе и запуску новых продуктов, компании смогут привлечь больше клиентов и сотрудников, что, вероятнее всего, приведет бизнес к росту по всем показателям. В конечном итоге, VR может полностью трансформировать наше восприятие вещей, и даже есть вероятность того, что это плохо скажется на нашем взаимодействии друг с другом, работе, учёбе, коммуникации и общении с другими людьми. Это создает совершенно новый способ получения опыта в жизни, и VR может стать важной частью нашей деятельности до такой степени, что мы не будем знать, как мы жили без этой технологии раньше. А что вы думаете о виртуальной реальности?

Интернет, а соответственно и сфера веб разработки, быстро и постоянно изменяется. Если ты front-end разработчик, тогда скорее всего, ты знаешь, что нужно быть в курсе новостей (уж поверь!), уметь работать с новыми инструментами, тенденциями и бизнес-процессами. Все самое важное ты сможешь найти в Интернете, но будь осторожен, поскольку в сети много ненужного мусора. Какие же блоги по front-end технологиям наилучшие? Ежедневно публикуются сотни постов и статей. Все они беспорядочны и можно сойти с ума, пытаясь поспеть за всем. Прочитать их все просто невозможно. Более того, не нужно читать все в подряд.  Именно поэтому я попросил людей из компании Merixstudio выделить лучшие технические блоги по front-end разработке, которые стоит читать, и они собрали лучшие ресурсы новостей и тенденций в мире веб разработки. Ранее я уже публиковал статью о самых влиятельных блогах, ориентированных на технологии и веб разработку в целом. На этот раз буду подробно рассказывать о лучших front-end ресурсах (порядок сайтов случайный). Speckyboy Сайт позиционирует себя как журнал веб дизайна, но Paul Andrew – основатель Speckyboy – концентрируется не только на дизайн-ресурсах, но также предоставляет полезную информацию о новейших веб технологиях. Блог, безусловно, является отличным источником информации для ежедневного использования front-end разработчиком – блог предлагает отличные посты, справочники, разные источники информации и мотивирующий контент со всего мира. • #11,771 по рейтингу Alexa Rank* • 54,143 подписчиков на Facebook • 75,150 подписчиков на Twitter CSS-Tricks Если ты хочешь улучшить свои навыки в области веб дизайна и веб разработки, тебе стоит подписаться на CSS-Tricks, который ведет интернет-гуру Chris Coyier. Это кладезь знаний по веб разработке, который непременно повысит уровень представляемого тобой веб контента. CSS-Tricks в основном фокусируется на темах, связанных с CSS. Блог предоставляет фрагменты кода, «прорывные» статьи, видео, учебные курсы, подкасты и многое другое. • #1,253 по рейтингу Alexa Rank* • 67,776 подписчиков на Facebook • 298,126 подписчиков на Twitter Codrops Codrops можно назвать одним из самых новых и быстро растущих сайтов с документацией в сфере информационных технологий. Каждый front-end разработчик и веб дизайнер может найти много полезных материалов и фрагментов кода на Сodrops. Он также охватывает  общие темы веб-разработки и веб-дизайна. Блог ведется всего лишь двумя дизайнерами – фанатами своего дела – Manoela Ilic и Pedro Botelho. Ко всем преимуществам блога можно добавить красивое оформление сайта. Этот блог стоит посещать, чтобы обучаться новым хитростям и тенденциям в индустрии. • #3,197 по рейтингу Alexa Rank* • 89,619 подписчиков на Facebook • 164,845 подписчиков на Twitter Todd Motto’s blog Todd работает на позиции Developer Advocate в компании Telerik. Todd – основатель Ultimate Angular, а также Developer Expert в Google, спикер на конференциях и сторонник проектов с открытым кодом. В целом, он пишет на Angular и JavaScript. Его самоуверенный гид по командному стилю работы с AngularJS приобрел очень большую популярность на Reddit и Hacker News. Его блог отличный ресурс для подпитки собственных знаний, особенно, если ты заинтересован именно в таких технологиях, как Angular и JavaScript. • #44,788 по рейтингу Alexa Rank* • 1140 подписчиков на Facebook • 30,396 подписчиков на Twitter Очень важно, чтобы ты нашел свой собственный, уникальный способ отслеживать нужную тебе информацию. Так что, читай книги, журналы, отслеживай в Twitter людей, которые создают новые тенденции, смотри видеоматериалы, посещай конференции, общайся с единомышленниками и создавай новое! *Alexa Rank – глобальный рейтинг трафика, учитывающий, как число посетителей, так и число просмотров страниц. Предоставляется компанией Alexa Internet. Оригинал: www.merixstudio.com.

Составляем ТЗ на английском О важности правильно составленного и правильно понятого технического задания в работе любой IT-команды говорить не стоит. Вопрос в том, как правильно написать его на английском. А если вы работаете в международной команде, это потребуется обязательно. Без паники! EnglishDom расскажет, как написать ТЗ на английском и не наделать ошибок. Итак, обо всех важных моментах - по порядку. SRS structure. Структура ТЗ В техзадании обязательно присутствуют следующие разделы: introduction - вступление, overall description - общее описание, specific requirements - специфические требования, а также возможны и appendices - приложения. Поговорим о каждом разделе отдельно. В introduction, помимо purpose - цели, может быть включен еще и scope - объем работ, definitions - термины, специфичные и принятые для этого ТЗ, и раздел overview, который дает общее представление о наполнении и структуре будущего проекта - identify the product, describe the content and the structure. Overall description - это раздел, который включает многое: product perspective - функционал будущего продукта, который описывает все внешние интерфейсы - describes all external interfaces, functions - главные функции продукта (summary of major functions), constraints, or anything that limits our options - возможные ограничения, use cases - сценарии использования. specific requirements - все, что можно назвать требованиями, идет в этот раздел. Собственно, это и есть его основной частью - body of the document. Итак, структура ТЗ в общем виде должна выглядеть так: Introduction: purpose / scope / definitions Overall description: product perspective / functions  / constraints / use cases  Specific requirements: all the possible requirements = body of the document Useful phrases: identify / limit options, content, structure, product, external interfaces Overview is a section that identifies the product and describes the content and the structure. - Общее представление - это раздел, который определяет проект и описывает наполнение и структуру. Anything that limits our options is described in the constraints. - Все, что как-либо лимитирует варианты действий, указано в разделе “ограничения”. All the possible requirements usually identify the body of the document. - Все возможные требования определяют главную часть документа. Характеристики  ТЗ Есть несколько ключевых характеристик ТЗ. Первое - оно должно быть correct - правильным, то есть up to the required standards for the quality, database integrity and so on - соответствовать требуемым стандартам по качеству, целостности базы данных и т.д. Второе - unambiguous and complete  - недвусмысленным и полным, чтобы четко описать проект и его функционал - describe what is the future project created for. Третье - consistent and detailed - последовательным и детальным, подробно описывающее, каким будет взаимодействие с людьми, оборудованием и другими внешними интерфейсами - how it interacts with people, hardware and other external interfaces. Четвертое - modifiable and traceable - поддающееся изменениям и их отслеживанию, то есть the one you can edit and control. Ряд фраз, которые вам пригодятся: imposed on an implementation - обязательный к внедрению, main considerations - ключевые факторы, operation environment - рабочая среда. Итак, ТЗ должно быть: Correct: up to the required standards for the quality / database integrity Unambiguous and complete: describe what is the future project created for Consistent and detailed: how it interacts with people, hardware and other external interfaces Modifiable and traceable: the one you can edit and control Полезные фразы: imposed on an implementation / main considerations / operation environment. SRS typical mistakes. Как не испортить ТЗ Столько деталей и нюансов, подпунктов, что сложно не ошибиться. Мы расскажем, чего стоит избегать. Первое: ambiguity - неясность. don’t give too much or too little information that may not be verified - не стоит давать чересчур много или мало информации, которую, к тому же, еще и проверить нельзя. Второе: requirements on users - требования к пользователям. Запомните, you can only assume what user will do - нельзя заставить пользователя, можно только предположить, что он будет делать. Третье: unnecessary or invented terms - термины, которые не нужны или выдуманы. Avoid any extra terms if you can say it simple - избегайте лишней терминологии, если все можно сказать проще. Бесполезные и ненужные в ТЗ вещи: forward reference - ссылка наперед, contradiction - противоречие, noise - лишняя информация, silence - недостаточное описание. В общем, придерживайтесь структуры, избегайте лишней информации, используйте ключевые фразы - и ваше ТЗ будет идеальным! Если же вы сомневаетесь в своем знании английского - в EnglishDom есть специальный курс “Английский для IT”, где вы сможете подтянуть все важные для it-шника темы. Научитесь писать резюме и CV, проходимть собеседования, обсуждать проекты и проводить переговоры, переписываться в чате, писать ТЗ и деловые письма, понимать носителей языка и читать зарубежные блоги.

Взято с настоящего поля битвы: работы Спустя практически 10 лет работы на Javascript мне захотелось поделиться своими ежедневными секретами написания кода. Многие советы были позаимствованы у моих коллег, из книг или видео. Такие приёмы не должны оставаться в тайне, поэтому я ими и хочу поделиться!   1. Меньше кода = меньше багов Это может прозвучать тривиально, но всегда держите это в уме. Любую часть можно убрать, даже не сомневайтесь! Просто удалите. Неработающий код, неиспользуемые переменные, лишние скобки: каждый малейший знак учитывается. 2. Развивайте читабельность кода Это дополнение к пункту 1. Если хочется сократить код, всегда нужно помнить о том, что рано или поздно код будет прочитан другими людьми. Может, кто-то другой, может, через несколько месяцев, но будет очень неприятно, если придется потратить больше времени на разбор кода, чем было потрачено на его написание. Запомните: код всегда важнее, чем комментарии или документация. Следите за переменными и именами функций, они должны быть достаточно наглядными, чтобы потом не объяснять их в комментариях. 3. Не пугайтесь функций, возвращающих функции Когда я начал кодить на javascript, мне не нравился метод написания кода с использованием функций, возвращающих функции, потому что, казалось, этому сложно следовать в процессе выполнения. Но этот шаблон, довольно мощный и часто используемый, называется замыканием. Это действительно полезная функция и, как только вы используете её, она значительно облегчает структуру кода. И это первый шаг для погружения в функциональное программирование. 4. Извлекание частей Функция становится слишком большой? Сделайте из нескольких частей отдельные функции! Не совсем понятно? Выделите их в переменную и дайте ей понятное имя. Такой метод, конечно, схож со вторым пунктом, но это сделает ваш код более читабельным. А знаете ли Вы, что Ваша среда разработки может помочь? Ctrl + alt + v выражение извлекается в Webstorm и потом выделяется в переменную. Ctrl + alt + m сделает из него функцию. 5. Переверните мышление Это первый шаг перед TDD. Скорее всего, вы всегда знаете, чего хотите достичь. Так начните с конца, напишите ожидаемый результат и пишите код в обратном порядке, чтобы получить то, что хотите. Если будете писать в прямом порядке, вероятней всего, Вы начнете писать и проверять, работает ли оно. Поменяйте, проверьте, напишите что-то другое, проверьте и…. Возможно, это даже не особо полезно для достижения Вашей цели. Но такое мышление поможет сфокусироваться и потратить меньше времени. 6. Исключите условные операторы Если для функции у вас на уме принцип единственной ответственности, условным операторам тут не место. Они создают ветвления в потоке выполнения. И один маленький if позволит другим разработчикам добавить всё больше логики в него. Я считаю, что условные операторы if вообще не должны использоваться без else, а их размещение внутри другого условного оператора нужно полностью запретить! Опять же, такой подход делает код более сложным, и часто оказывается, что функция выполняет больше, чем нужно. Как же от этого избавиться? Смотрите следующий пункт. 7. Используйте lodash_.get вместо проверки null/undefined Очень часто, анализируя код, я вижу использование ifs для проверки null или undefined значений. Но без использования else! То есть идёт работа только с одним путём, а другой путь остаётся местом загадок (и багов!). Тут на помощь приходит Lodash (лучшее, написанное когда-либо на javascript) с его замечательной функцией get. Её первым аргументом является объект, над которым вы работаете, вторым – путь к дочерним атрибутам, которые вы хотите получить, и третьим является значение по умолчанию в случае с undefined. Два преимущества использования всего одной функции! 8. Используйте тернарные операторы Кто-то может поспорить насчёт их читабельности, но если правильно извлекать функции, они станут превосходным инструментом. Они также заставят Вас сотрудничать с else case. Плюс, они не позволяют содержать в себе больше кода. Чем меньше ваш код похож на смертельную пирамиду, тем лучше. 9. Никаких больше for loops, только map, reduce и filter Мы, наконец-то, подошли тут к теме функционального программирования, так как эти методы являются основой этого стиля. Хоть названия или теории не особо известны, они действительно помогут избежать тяжело читаемого императивного стиля для выражений for. Эти методы сейчас уже встроены в большинство браузеров, так что используйте их! Но если вам всё же нужна совместимость, можно использовать lodash аналоги. Итак, когда их использовать? Выражение for, имеющее дело со всеми точками входа – это map for + if , вероятно, filter sum или accumulation -  это просто reduce  С помощью сочетания этих методов вы можете сделать много работы в хорошей и краткой форме. 10. Читайте исходники Если документации недостаточно - читайте исходники! Это поможет Вам узнать, как их использовать и даст неплохое представление об их качестве. Плюс, некоторые библиотеки имеют исходники, встроенные в их документацию. Так с ними даже быстрее можно ознакомиться. С нашей IDE можно часто обращаться к источнику с помощью ctrl + clic на имя метода. Это отличный способ убрать магию и набраться вдохновения для собственного кода!   В заключение хотелось бы сказать, что это те принципы, которые помогают лично мне. Жаль, что я не знал их раньше, например, в школе… Зато ты знаешь их сейчас. И ими можно пользоваться практически в любом контексте. Некоторые из них распространяются не только на javascript, так что пользуйтесь ими где угодно :) Также хотелось бы обратить ваше внимание на великого Uncle Bob и его сайт . Вам определённо стоит посмотреть эти видео, даже несмотря на то, что они по большей части касаются Java, идеи применимы и в Javascript. Переведено с источника.

Здравствуйте, дорогие читатели. В этом уроке мы: выполним рефакторинг проекта “Warehouse” под “iOS”. Создадим удобную структуру расположения модулей в проекте. научимся пользоваться библиотекой “Alamofire”. научимся сохранять объекты в настройки телефона и извлекать их. реализуем функциональность для работы со всеми сервисами, созданными в данном уроке. Откройте проект “Warehouse” под iOS, который мы делали на протяжении всех уроков. Запросы на сервер можно отправлять синхронно и асинхронно. Основное требование Apple, чтобы приложение не зависало и большие операции выполнялись в фоновом режиме. Представим ситуацию: у нас мобильный интернет “GPRS EDGE”, скорость соединения около 54 кб/сек. Если отправлять запрос на получение данных на сервер синхронно, мы блокируем работу приложения и пользователь вынужден ждать. Наша задача - дать пользователю выбор, ждать или нет. Поэтому лучше всего отправлять такой запрос асинхронно. На сегодняшний день существует такая библиотека “Alamofire”, где собраны лучшие практики асинхронного программирования и все оптимизировано за нас. Откройте браузер и перейдите по адресу: “https://github.com/Alamofire/Alamofire”. На сайте нажмите кнопку “Clone of download” и в появившемся окне нажмите “Download Zip”. Когда скачается архив, распакуйте его. Выделите файл “Alamofire.xcodeproj” и папку “Source” и скопируйте их в папку проекта “Warehouse”. Перейдите в проект “Warehouse”. В панели навигации выполните контекстное меню по папке “Warehouse” и в контекстном меню выберите “Add files to 'Warehouse'...”. В открывшемся диалоговом окне выбора файлов  выберите файл “Alamofire.xcodeproj”. Выполните в меню “Product -> Build”, чтобы собрать проект. Затем выделите в панели навигации папку “Warehouse”, в области содержимого откроются свойства проекта. Откройте вкладку “General”, пролистайте область содержимого в самый низ. Установите свойство “Embedded binaries”, нажмите плюсик. В появившемся диалоговом окне, выберите “Alamofire.Framework.iOS” и нажмите кнопку “Add”. Результат должен получиться таким. Выполните в меню “Product -> Build”, чтобы собрать проект. Итак, что мы только что сделали. Мы подключили исходники библиотеки “Alamofire” в проект “Warehouse”. Можно было это сделать и отдельным проектом, но так проще для восприятия. Затем мы подключили сборку “Alamofire.framework.iOS” в приложение “Warehouse”  для возможности обращения к классам данной библиотеки из нашего проекта. Теперь нам надо создать модели данных, в которые мы будем сохранять JSON объекты, полученные с сервера. Также необходимо предусмотреть удобство сохранения и извлечения данных, поскольку запросы будут асинхронными и просто вернуть нужный экземпляр из метода будет проблематично. Именно поэтому мы поступим следующим образом. Отправляем запрос на сервер асинхронно. В метод отправки  добавляем callback метод, который вызовется  после того, как модель была успешно сохранена в настройки телефона. Ждем ответа. Когда ответ пришел, десериализуем объект JSON в нужную модель данных, объявленную в приложении. Сохраняем заполненную модель в настройки телефона. В контроллере, из которого был отправлен запрос, в callback методе  извлекаем модель из настроек телефона и инициализируем данными элементы управления. Создайте следующую структуру папок в панели навигации. В папку “Warehouse”  были добавлены папки “Controllers”, “Protocols”, “Models”, “Services”. В папку “Controllers”  были добавлены папки “Users”, “Registration”, “Authorization”, “Supplies”. В папке “Controllers”  будут храниться модули контроллеров. В папке “Protocols”  будут храниться модули протоколов. В папке “Models”  будут храниться модули моделей данных. В папке “Services”  будут храниться модули обращения к REST сервисам. Сейчас нам необходимо провести некоторую подготовку, перед тем как начать реализовывать приложение. Пока, давайте,  добавим нужные модули. Сам по себе добавленный модуль ничего не делает. Перетащите в папку “Controllers / Supplies”  модули “SuppliesViewController.swift”, “ProductViewController.swift”. Перетащите в папку “Controllers / Authorization”  модуль “ViewController.swift”. Добавьте в папку “Controllers / Registration”  модуль “RegistrationViewController.swift”. Добавьте в папку “Controllers / Supplies”  модуль “ImageCollectionViewController.swift”. Добавьте в папку “Controllers / Users”  модули “UsersViewController.swift”, “UserItemViewController.swift”. Добавьте в папку “Protocols”  модуль “SelectedImageProtocol.swift”. Добавьте в папку “Models”  модули “ProductModel.swift”, “UserModel.swift”. Добавьте в папку “Services”  модули “UserData.swift”, “ProductData.swift”, “Services.swift”, “AuthorizationService.swift”, “ProductService.swift”, “UserService.swift”. У вас должна получиться следующая структура. Как видите, проект стал больше. Он станет еще больше, как только мы заполним добавленные модули. Откройте модуль “Models / UserModel.swift”. Заполните его, как показано ниже. В этом модуле мы создаем модель пользователя, в которую будем десериализовывать JSON объект пользователя,  полученный от сервера. В классе “UserModel”  мы добавляем поля модели “_id”, “userName”, “userPwd”, “userDesc”, которые декларировали при объявлении схемы базы данных “Mongo DB” на сервере. На 9 строке  мы подключаем пространство имен “Foundation”. На 11 строке  мы объявляем класс с именем “UserModel”, который наследует класс “NSObject”, являющийся базовым классом для всех классов в iOS платформе. Наследуемся от протокола “NSCoding”, данный протокол необходимо реализовать, чтобы объект можно было сохранять в настройках телефона и извлекать оттуда. Рассмотрим протокол “NSCoding”. Протокол содержит метод “encode” и инициализатор. Экземпляр класса “NSCoder”  позволяет кодировать и раскодировать свойства класса, значения которых могут сохраняться в хранилище настроек телефона. В методе “encode”  данные извлекаются из свойств и кодируются в формат, нужный для сохранения в настройки телефона. В инициализаторе  данные извлекаются и раскодируются из настроек телефона, затем сохраняются в нужные свойства класса. Вот так это работает. Теперь вернемся и рассмотрим дальше модуль “UserModel.swift”. На 12 строке  мы объявляем поле “_id” типа “String” и инициализируем его значением по умолчанию, пустая строка. На 13 строке  мы объявляем поле “userName” типа “String” и инициализируем его значением по умолчанию, пустая строка. На 14 строке  мы объявляем поле “userPwd” типа “String” и инициализируем его значением по умолчанию, пустая строка. На 15 строке  мы объявляем поле “userDesc” типа “String” и инициализируем его значением по умолчанию, пустая строка. На 17 строке  мы переопределяем инициализатор по умолчанию для класса “NSObject”, тем самым мы говорим, что создание объекта без передачи аргументов в инициализатор будет возможно. На 18 строке  мы вызываем базовый инициализатор из класса “NSObject”. На 21 строке  мы объявляем параметризированный инициализатор. Данный инициализатор  инициализирует поля класса “_id”, “userName”, “userPwd”, “userDesc” значениями, переданными в аргументы инициализатора. На 31 строке  мы реализуем конструктор протокола “NSCoding”. Ключевое слово “required”  обозначает, что вызов этого инициализатора обязателен в первую очередь.   Ключевое слово “convenience”  гарантирует то, что после вызова этого инициализатора  будут вызваны остальные инициализаторы классов, связанных с этим классом по цепочке вверх. На 32 строке  мы раскодируем из настроек телефона  значение свойства “_id”  путем вызова на экземпляре “aDecoder” типа “NSCoder”  метода “decodeObject”, аргумент “forKey”  которого принимает название поля/свойства, которое было сохранено в настройки телефона. Этот метод возвращает значение “Any?”, т.е. неопределенный тип (аналог в C#  - это Object, в Visual Basic - это Variant). Нам необходимо это значение вручную привести к нужному типу поля. В настройках телефона содержится большой файл, который имеет древовидную  структуру словаря ключ и значение. Чтобы привести к нужному значению, мы используем конструкцию приведения к типу “as”. Причем, мы можем управлять этой конструкцией. Например, нам надо привести тип “Any?” к типу “String”. Для этого мы используем конструкцию “as!”. Если же нам надо привести к типу “String?” (nullable тип), тогда мы используем конструкцию “as?”. Зачем мы это делаем. Настройки телефона  разбиваются на разные файлы, для каждого приложения используется свой файл с настройками. Когда приложения устанавливаются на macOS или iOS платформу, они устанавливаются в виде папки и имеют тип “Bundle”. Apple довольно кардинально подошла к этому вопросу, она сделала так, что все настройки для каждого приложения хранятся внутри “Bundle” данного приложения. И когда приложение удаляется, удаляется “Bundle” со всеми настройками с диска операционной системы и не остается никаких следов после удаления. Чего не скажешь о таких платформах, как Windows и Android, которые засоряют все пространство на диске операционной системы вокруг папки, в которую было установлено приложение, и выше. И когда приложение удаляешь, есть риск, что после этого будет необходимо еще и переустановить операционную систему. Отчасти именно из-за этого подхода техника Apple  пользуется такой популярностью и их устройства выигрывают по отказоустойчивости программного обеспечения по сравнению с конкурентами. Если приложение обновляется, то файл настроек остается старый. Чтобы обновить его, надо выполнить запись в него, тогда старые конструкции удалятся, а новые добавятся.   Представим себе ситуацию, сейчас в нашей модели “UserModel”  всего 4 поля. Мы сохранили эту модель в файл настроек телефона. Отправили в магазин, пользователи скачали, установили приложение. Вышла новая версия приложения, в которой мы добавили новое поле в эту модель с именем “userRole” типа “String”. Разумеется, первая операция, которая будет выполнена как обычно - это запрос данных из настроек телефона, но для поля “userRole”  установлено значение “nil” (аналог в C# null) и произойдет ошибка и креш приложения, так как мы не обработали эту ситуацию, а пытаемся через метод “decodeObject” получить значение этого поля и еще и явно привести его к типу “String”  через, например, оператор “as!”. Но в поле “userRole” - значение “nil” и оно не приведется к типу “String” через конструкцию “as!”, но может привестись без ошибок к типу “String?”  через “as?”. Надеюсь, я прояснил понятно, зачем нужна данная проверка. Продолжим. На 32 строке мы проверяем, доступно ли нам значение поля “_id”. Чтобы проверить, равно ли возвращаемое значение “nil”, можно было бы использовать такую конструкцию: “aDecoder.decodeObject(..) == nil”, но такая конструкция не слишком информативна. Поэтому мы используем конструкцию “(aDecoder.decodeObject(..) as? String) == nil”.       Далее, если данная конструкция возвращает значение “true”, тогда мы через тернарный оператор  присваиваем  константе “_id” значение по умолчанию пустая строка, иначе присваиваем реальное значение  поля “_id” из настроек телефона. С 33 по 35 строку  мы выполняем те же операции проверок для полей “userName”, “userPwd”, “userDesc”. На 36 строке  мы вызываем параметризированный конструктор и инициализируем его аргументы объявленными ранее константами. На 47 строке  объявлен вспомогательный метод “Populate”, который переносит данные из экземпляра “dictionary” типа “NSDictionary”  в поля класса “UserModel”. Этот метод мы будем использовать, когда будем создавать запросы к серверу и получать ответы.   В ответе содержится словарь типа “NSDictionary”, в котором находятся свойства с теми же именами, что и поля нашего класса. С 48 по 51 строку мы инициализируем поля класса “UserModel”  значениями из экземпляра “dictionary” c теми же проверками, что мы рассматривали выше. На 53 строке объявлен вспомогательный метод “PopulateArray”, который переносит данные из экземпляра “array” типа “NSArray” в массив объектов типа “UserModel”. Этот метод мы будем использовать, когда в ответе от сервера  придет массив JSON объектов типа “User”, чтобы сконвертировать массив типа “[NSDictionary]” в массив типа “[UserModel]”. На 55 строке  мы объявляем пустой массив типа “[UserModel]” c именем “result”. На 56 строке  мы выполняем цикл “foreach” по элементам массива “array”. На 58 строке  мы создаем новый экземпляр типа “UserModel” с именем “newItem”. На 59 строке  мы проверяем, содержит ли элемент массива  значение “nil”. На 60 строке  мы вызываем на экземпляре “newItem”  метод “Populate”, который перенесет данные из словаря типа “NSDictionary”  в поля экземпляра “newItem”. На 62 строке  мы обращаемся к экземпляру “result” и вызываем у него метод “append”, чтобы добавить новый элемент в массив, и добавляем проинициализированный выше экземпляр “newItem”. На 64 строке  мы возвращаем сконвертированный массив типа “[UserModel]” из метода “PopulateArray”. Откройте модуль “Models / ProductModel.swift”, заполните его в соответствии с содержимым ниже. В этом модуле мы создаем модель пользователя, в которую будем десериализовывать JSON объект пользователя,  полученный от сервера. В классе “UserModel”  мы добавляем поля модели “_id”, “userName”, “userPwd”, “userDesc”, которые декларировали при объявлении схемы базы данных “Mongo DB” на сервере. На 9 строке  мы подключаем пространство имен “Foundation”. На 11 строке  мы объявляем класс с именем “UserModel”, который наследует класс “NSObject”, являющийся базовым классом для всех классов в iOS платформе. Наследуемся от протокола “NSCoding”, данный протокол необходимо реализовать, чтобы объект можно было сохранять в настройках телефона и извлекать оттуда. Рассмотрим протокол “NSCoding”. Данный модуль не нуждается в объяснении, поскольку он по образу и подобию такой же, как и модуль “UserModel.swift”, с разницей лишь в том, что он построен на модели “Product” и содержит соответствующие поля.       Итак, модели данных мы создали, теперь мы сможем с уверенностью сохранять результаты ответа от сервера в нормальном виде и потом использовать их при инициализации элементов управления в соответствующих представлениях :) Теперь приступаем к реализации классов для отправки запросов на сервер и сохранения/загрузки полученных данных в настройки телефона. Откройте модуль “Services / Services.swift”, заполните его в соответствии с содержимым ниже. На 11 строке  объявлен класс с именем “Services”. Данный класс будет содержать вспомогательные свойства и методы, которые мы будем часто использовать при работе с ответом от сервера. На 12 строке  объявлено статическое свойство “host” типа “String” и мы ограничили его функциональность только одним аксессором доступа “get”. Т.е. значение свойства получить можно, но изменить нельзя. В данном свойстве содержится адрес, по которому доступен сервер. В прошлом уроке, когда мы делали сервер, мы использовали адрес “http://localhost:3000” , внутри приложения клиента имеется свой “localhost”, именно поэтому мы используем явный IP адрес “127.0.0.1”, чтобы запрос шел именно на сервер, а не внутрь приложения. На 18 строке  объявлен статический метод “ejectJsonArray”, который принимает аргумент “data” типа “NSData?” и возвращает массив типа “NSArray?”. Данный метод конвертирует экземпляр класса “NSData” в экземпляр класса “NSArray”. В экземпляре “data” будет содержаться массив JSON объектов, полученных от сервера. На 19 строке  объявлена переменная “json” типа “NSArray?” и инициализировано значение по умолчанию “nil”. На 20 строке  мы используем конструкцию “do .. try .. catch” (аналог в C# - “try .. catch”). Символ “_” в блоке “catch” на месте аргумента используется потому, что мы не будем использовать этот аргумент в блоке “catch”. В случае возникновения исключения мы не будем завершать аварийно приложение, а просто вернем значение “nil” по умолчанию, которое будет говорить о том, что конвертация не удалась, поскольку в NSData  не содержится JSON объект. Аналог JSON объекта в Swift - это класс “NSDictionary”. На 21 строке  мы правым операндом обращаемся к классу “JSONSerialization” и вызываем от его экземпляра статический метод “jsonObject”, который первым аргументом принимает данные типа “Data” для конвертации, вторым аргументом принимает опции конвертации. Метод “jsonObject” возвращает экземпляр типа “Any”. Далее мы приводим это значение к нужному нам типу “NSArray?”, если приведение было проведено не успешно, будет возвращено значение “nil”. Результат конвертации присваивается объявленной выше переменной “json”. Обратите внимание на ключевое слово “try” перед конструкцией “JSONSerialization.jsonObject(..)”, использование этого ключевого слова является обязательным, так как метод “jsonObject” имеет в своей сигнатуре ключевое слово “throws”, это означает, что данный метод может генерировать исключения и их необходимо обрабатывать. На 23 строке в случае исключения вызванного методом “jsonObject”  возвращается значение “nil”. На 25 строке в случае успеха операции  возвращается экземпляр типа “NSArray?”. На 28 строке  объвлен метод “ejectJsonDictionary” с той же сигнатурой, что и метод “ejectJsonArray”, но с разницей в возвращаемом значении. В этом методе возвращается экземпляр типа “NSDictionary?”. Метод подразумевает, что в экземпляре “data” типа “NSData?” содержится единичный JSON объект и пытается его  сконвертировать в тип “NSDictionary” , являющийся аналогом JSON объектов в Swift.       Реализацию метода смысла описывать не вижу, она такая же, как и в методе “ejectJsonArray”. Реализуем сохранение моделей данных “UserModel” и “ProductModel” в настройки телефона. Откройте модуль “Services / UserData.swift”, заполните его в соответствии с содержимым ниже. Модуль большой, поэтому будем разбирать его, разбив на две части по функциональности. В первой его части  будут описаны методы сохранения / извлечения единичного экземпляра типа “UserModel” и экземпляра типа массив “[UserModel]”. Во второй его части  будут описаны вспомогательные методы  для обработчиков ошибок ответа от сервера и сохранения данных в настройки телефона. Данные методы были созданы для того, чтобы не копипастить один и тот же код много раз, а стандартизировать и сделать его повторно используемым. На 9 строке  подключено пространство имен “UIKit”, необходимое для классов “UserDefaults”, “NSKeyedArchiver”, “NSKeyedUnarchiver”. В пространстве имен уже содержится подключенное пространство имен “Foundation”, поэтому нет смысла его тоже  подключать для классов “NSArray”, “NSDictionary”, “NSData”. На 10 строке  подключено пространство имен “Alamofire”, необходимое для класса “DataResponse”. На 12 строке  объявлен класс с именем “UserData”. На 13 строке  объявлен метод “saveUserModel”, который принимает аргумент “userModel” типа “UserModel”. Метод будет сохранять поля модели “UserModel” в настройки телефона. На 14 строке  правым операндом мы обращаемся от экземпляра “UserDefaults” к его статическому свойству “standard”, это свойство является источником данных по отношению к файлу настроек телефона и содержит необходимые методы для сохранения / извлечения данных. На 15 строке  правым операндом мы обращаемся к экземпляру “NSKeyedArchiver” и вызываем статический метод “archivedData”. Этот метод принимает один аргумент “withRootObject” типа “Any” и возвращает экземпляр типа “Data”. Метод упаковывает экземпляр типа “UserModel” в экземпляр типа “Data” (аналог NSData) и возвращает его. На 16 строке  мы от экземпляра “userDefaults” вызываем метод “set”, который принимает два аргумента.  Первый аргумент “_” типа “Any?” принимает экземпляр, который необходимо сохранить в настройках телефона. Второй аргумент “forKey” типа “String” необходим, чтобы задать название ключа в словаре настроек  телефона. По этому ключу будет произведено сохранение экземпляра “UserModel”. На 17 строке  мы обращаемся к экземпляру “userDefaults”, вызываем от него метод “synchronize”. Данный метод выполняет сохранение экземпляра модели “UserModel” в настройки телефона (аналог в C#, например,  'using(StreamWriter sw = File.CreateText(“test.txt”)) { sw.Write(“some text”); sw.Flush(); }', из этого примера метод “Write” аналогичен методу “set”, а метод “Flush” аналогичен методу “synchronize”). На 20 строке  мы объявили статический метод “getUserModel”, который не принимает аргументов и возвращает экземпляр типа “UserModel”. В этом методе мы излекаем модель “UserModel” из файла настроек телефона по ключу, указанному в предыдущем методе при сохранении этой модели. На 21 строке  мы получаем экземпляр источника данных настроек телефона. На 22 строке  мы проверяем, если модель “UserModel” ранее не сохранялась в настройки телефона, тогда необходимо создать пустую модель по умолчанию. Вызываем на экземпляре “userDefaults” метод “object”, который принимает аргумент “forKey” типа “String” и возвращает значение типа “Any?”. В качестве аргумента мы передаем ключ, под которым сохраняется данная модель в настройках телефона. Если значение было найдено в словаре, будет возвращен экземпля , который надо будет привести у нужному типу. Если значение не было найдено, будет возвращено значение “nil”. На 23 строке  мы создаем пустой экземпляр типа “UserModel”. На 24 строке  мы возвращаем этот экземпляр из метода. На 26 строке  код будет выполнен при наличии записи по ключу в словаре. Правым операндом мы обращаемся к экземпляру “userDefaults”, вызываем метод “object” и передаем в аргумент “forKey”  ключ, по которому надо извлечь значение. Полученное значение приводим к типу “NSData”. На 27 строке  мы обращаемся к экземпляру “NSKeyedUnarchiver” и вызываем от него статический метод “unarchiveObject”, который принимает аргумент “with” типа “Data” и возвращает значение типа “Any”. Метод конвертирует экземпляр типа “Data” в экземпляр типа “Any”. Возращаемое значение метода мы явно приводим к типу “UserModel”. На 28 строке  мы возвращаем из метода полученный из словаря экземпляр типа “UserModel”. На 31 строке  объявлен метод “saveListOfUsersModel”, который принимает аргумент “listOfUsersModel” типа “[UserModel]” и ничего не возвращает. Метод сохраняет массив “[UserModel]” в файл настроек телефона. Описывать данный метод не имеет смысла, его работа аналогична методу “saveUserModel”. На 38 строке  объявлен метод “getListOfUsersModel”, который не принимает аргументов и возвращает экземпляр типа массив “[UserModel]”. Метод извлекает из настроек телефона массив типа “[UserModel]” по ключу, указанному в методе “saveListOfUsersModel”. Описывать данный метод не имеет смысла, его работа аналогична методу “getUserModel”. Откройте модуль “ProductData.swift”, заполните его в соответствии с содержимым ниже. В первой части описано сохранение / извлечение моделей типа “ProductModel”, “[ProductModel]” в настройки телефона. Описывать код не имеет смысла, его работа точно такая же, как и в модуле “UserData.swift”. Во второй части описаны вспомогательные методы для обработки запросов от сервера и сохранения данных. Описывать код не имеет смысла, его работа точно такая же, как и в модуле “UserData.swift”. Теперь, наконец то, мы можем реализовать первый класс для работы с сервисом авторизации пользователя и разобрать работу с библиотекой “Alamofire”. Откройте модуль “Services / AuthorizationService.swift”, заполните его в соответствии с содержимым ниже. На 12 строке  объявлен класс с именем “AuthorizationService”.             На 13 строке  объявлен метод “login”, который принимает три аргумента и ничего не возвращает.             Первый аргумент “userName” типа “String” -  это имя пользователя (логин).             Второй аргумент “userPwd” типа “String” -  это пароль пользователя.             Третий аргумент - это “callback” метод, который принимает аргумент типа “Bool” и ничего не возвращает.             Метод с такой сигнатурой, переданный в третий аргумент, будет вызван по завершению обработки ответа от сервера. В случае наличия ошибок  в аргумент этого метода будет передано значение “false”. В случае успешно проведенной операции - значение “true”.             Да, можно было сделать этот аргумент другим типом, например, отдельным классом ошибок, в который можно было сохранять подробно, что за ошибка произошла.             Но это учебный пример, он итак очень большой. Я решил не усложнять этим жизнь  ни себе, ни вам :)             На 14 строке  правым операндом мы вызываем метод “request” из библиотеки “Alamofire”.             Метод принимает 5 аргументов и возвращает значение типа “DataRequest”.             Данный метод используется для отправки HTTP/HTTPS запросов на сервер.             Первый аргумент “_” типа “URLConvertible” принимает адрес, по которому необходимо отправить запрос. Мы его инициализируем значением “\(Services.host)/auth”, которое после подстановки свойства “host”  будет выглядеть вот так: “http://127.0.0.1:3000/auth”.             Второй аргумент “method” типа “HTTPMethod” принимает HTTP глагол. Тип “HTTPMethod”  является перечислением и может принимать следующие значения. Мы инициализируем данный аргумент значением “.post” (это сокращенная запись, полная запись “HTTPMethod.post”)             Третий аргумент “parameters” типа “Parameters?”. Принимает словарь, ключ - значение, мы его заполняем теми же данными, что отправляли в прошлом уроке через утилиту “Postman”. Конкретно, мы передаем значение имени пользователя и его пароль.             Четвертый аргумент “encoding” типа “ParameterEncoding”. Этим параметром задается заголовок запроса “Content-Type”, т.е. указывается тип данных, который будет отправлен на сервер, сами данные задаются в третьем аргументе “parameters”. Мы инициализируем аргумент значением “JSONEncoding.default”, что аналогично записи “application/json”. Тип “ParameterEncoding” является протоколом и имеет следующие реализации себя в классах “URLEncoding”, “JSONEncoding”, “PropertyListEncoding”. Про эти классы вы можете почитать в официальной документации на сайте “Alamofire”.             Пятый аргумент “headers” типа “HTTPHeaders?” имеет значение по умолчанию “nil”, в нашем вызове метода он не используется. Данный аргумент задается, если вы желаете отправить в заголовках запроса на сервер какую- либо информацию, например, “cookie”. Если у вас сервер написан на Web API и вы используете для авторизации OWin , с настройкой надо использовать “cookie” как ключ авторизации пользователя. Тогда при отправке запросов вам будет необходимо заполнять этот аргумент. Пример его заполнения может выглядеть вот так: Этот пример взят из моего приложения “Smart Payment”,  написанного на Swift 2.2 c минимальной версией iOS 8.3  библиотекой “Alamofire” версии 2. Чтобы этот пример работал на Swift 3, надо заменить значение параметра “encoding” на “JSONEncoding.default”. Этот пример не относится к нашему приложению и его переписывать не нужно.             На 16 строке  мы вызываем от экземпляра “r” типа “DataRequest”  метод “responseJSON”. Этот метод выполняет запрос на сервер и содержит три аргумента.             Первый аргумент “queue” типа “DispatchQueue?”  по умолчанию содержит значение “nil”. Используется при переопределении потока выполнения запроса.             Второй аргумент “options” типа “JSONSerialization.ReadingOptions” по умолчанию содержит значение “.allowFragments”. Используется для задания опция отправки запроса.    Тип “ReadingOptions” является структурой и имеет такое объявление. Третий аргумент “completionHandler” типа делегат “@escaping (DataResponse) -> Void”. Данная сигнатура принимает один аргумент типа “DataResponse” и ничего не возвращает. В этом аргументе содержится ответ от сервера. Сам метод вызывается после запроса, когда сервер отправил ответ на клиент.             Обратите внимание, на 16 строке, когда мы вызываем метод “responseJSON”, у нас нет круглых скобок после метода, а идут сразу фигурные скобки, это называется “closure” подход. В фигурных скобках мы объявляем лямбда метод с сигнатурой, соответствующей третьему аргументу метода “responseJSON”.             Запись “response in” означает следующее: “response” - это аргумент лямбда метода, а само тело метода начинается после ключевого слова “in”. Аргумент “response” имеет тип “DataResponse”.             На 17 строке  мы проверяем, если ответ пришел с ошибкой, то это означает, что данных нет и пришло пустое значение типа “nil”. Мы обращаемся к экземпляру “response” и вызываем свойство “result” типа “Result” и от свойства “result” вызываем свойство “value” типа “Value?”. Если в свойстве “value” пришло пустое значение, значит запрос не был выполнен, возможно, по причине недоступности сервера или отсутствия подключения к интернету.             На 18 строке  мы вызываем “callback” метод “completion” со значением “false”.             На 21 строке, в случае если проблем с подключением к серверу не возникло, мы правым операндом вызываем от экземпляра “Services” метод “ejectJsonDictionary”, который ранее уже подробно рассматривали. В аргумент “data” мы передаем значение свойства “data”, вызванного от экземпляра “response”. Свойство “data” имеет тип “Data?”. Левому операнду “json” присваивается экземпляр “NSDictionary”, в котором содержится JSON объект пользователя, прошедшего авторизацию, который был отправлен сервером на клиент.             На 22 строке  мы проверяем, если пришел JSON объект с ошибкой, тогда возвращаем нужный флаг в “callback” методе “completion”. Помним, что в предыдущем уроке мы создавали JSON объект с ошибкой на сервере, в случае если пользователь ввел неверные данные авторизации,  JSON выглядел вот так '{ “Error”: “Authorization error”}'.             У словаря “json” есть возможность получить все ключи, для этого надо вызвать свойство “allKeys”, которое имеет тип “[Any]”. Но,  поскольку выполнить поиск строки в массиве объектов нельзя, мы оборачиваем массив объектов в массив типа “Array” и явно приводим его к нужному нам типу массива “[String]”. Мы это делаем, поскольку знаем наверняка, что ключи JSON объекта имеют тип “String”. Затем от полученного экземпляра типа “[String]”  мы вызываем метод “contains”, в аргумент которого передает название свойства JSON объекта ошибки, значение “Error”. Если такой JSON объект пришел в ответе, значит пользователь ввел неправильные логин или пароль, или ввел несуществующего пользователя.             На 23 строке  мы вызываем “callback” метод “completion” с аргументом “false”.             На 25 строке  мы создаем пустой экземпляр “userModel” типа “UserModel”.             На 26 строке  мы вызываем на экземпляре “userModel”  метод “Populate”  в аргумент “dictionary”, передаем экземпляр “json”. Метод “Populate”  перенесет данные из экземпляра “json” типа “NSDictionary” в поля экземпляра “userModel”.             На 27 строке  мы обращаемся к экземпляру “UserData” и вызываем статический метод “saveUserModel”, чтобы сохранить данные экземпляра “userModel” в настройки телефона. В аргумент “userModel”  мы передаем экземпляр “userModel”.             На 28 строке  мы вызываем “callback” метод “completion” и передаем в него результат операции “true”.             Позже в контроллере, где мы будем вызывать метод “login”, будет передан “callback” метод “completion”, объявленный в этом контроллере. Тем самым решается проблема ожидания ответа от сервера в контроллере, так как есть “callback” метод. Внутри этого метода мы проверим результат операции и затем обратимся к экземпляру “UserData” и вызовем метод “getUserModel”, который вернет нам экземпляр “UserModel”, с которым мы сможем работать на стороне контроллера.             Откройте модуль “Services / UserService.swift”, заполните его, как показано  ниже. На 12 строке  объявлен класс “UserService”.             На 13 строке  объявлен метод “get”, который принимает два аргумента и ничего не возвращает.             Первый аргумент “id” типа “String?”  принимает идентификатор пользователя “_id”. Если передать в аргумент значение “nil”, будет возвращен весь список пользователей, если передать конкретный идентификатор, будет возвращен конкретный пользователь.             Второй аргумент “completion” типа делегат “(Bool) -> Void”  используется для получения сигнала, что ответ был получен и основные операции были выполнены.             На 29 строке  объявлен метод “create”, который принимает 4 аргумента и ничего не возвращает. Метод отправляет запрос на создание пользователя на сервер.             Первые три аргумента “userName”, “userPwd”, “userDesc” имеют тип “String” и содержат данные пользователя. Идентификатор пользователя в операции создания не нужен. Так как идентификатор пользователю присваивается на стороне сервера и данный метод выполняет как раз эту операцию.             Четвертый аргумент “completion” типа делегат “(Bool) -> Void”  используется для получения сигнала, что ответ был получен и основные операции были выполнены.             На 37 строке  объявлен метод “update”, который принимает 5 аргументов и ничего не возвращает. Данный метод отправляет запрос на обновление данных пользователя на сервер.             Первые 4 аргумента “id”, “userName”, “userPwd”, “userDesc” имеют тип “String” и содержат данные пользователя.             Пятый аргумент “completion” типа делегат “(Bool) -> Void”  используется для получения сигнала, что ответ был получен и основные операции были выполнены.             На 45 строке  мы объявляем метод “delete”, который принимает два аргумента. Этот метод отправляет запрос на удаление пользователя на сервер.             Первый аргумент “id” типа “String?”  принимает идентификатор пользователя “_id”.             Второй аргумент “completion” типа делегат “(Bool) -> Void”, используется для получения сигнала, что ответ был получен и основные операции были выполнены.               Откройте модуль “Services / ProductService.swift”, заполните его, как показано ниже На 12 строке  объявлен класс “ProductService”.             На 13 строке  объявлен метод “get”, который принимает два аргумента и ничего не возвращает.             Первый аргумент “id” типа “String?”  принимает идентификатор товара “_id”. Если передать в аргумент значение “nil”, будет возвращен весь список товаров, если передать конкретный идентификатор, будет возвращен конкретный товар.             Второй аргумент “completion” типа делегат “(Bool) -> Void”  используется для получения сигнала, что ответ был получен и основные операции были выполнены.             На 29 строке  объявлен метод “create”, который принимает 4 аргумента и ничего не возвращает. Метод отправляет запрос на создание товара на сервер.             Первые три аргумента “productImage”, “productName”, “productDescription” имеют тип “String” и содержат данные товара. Идентификатор товара в операции создания не нужен. Так как идентификатор товару присваивается на стороне сервера и данный метод выполняет как раз эту операцию.             Четвертый аргумент “completion” типа делегат “(Bool) -> Void”  используется для получения сигнала, что ответ был получен и основные операции были выполнены.             На 37 строке  объявлен метод “update”, который принимает 5 аргументов и ничего не возвращает. Данный метод отправляет запрос на обновление данных товара на сервер.             Первые 4 аргумента “id”, “productImage”, “productName”, “productDescription” имеют тип “String” и содержат данные пользователя.             Пятый аргумент “completion” типа делегат “(Bool) -> Void”  используется для получения сигнала, что ответ был получен и основные операции были выполнены.             На 45 строке  мы объявляем метод “delete”, который принимает два аргумента. Этот метод отправляет запрос на удаление товара на сервер.             Первый аргумент “id” типа “String?”  принимает идентификатор товара “_id”.             Второй аргумент “completion” типа делегат “(Bool) -> Void”  используется для получения сигнала, что ответ был получен и основные операции были выполнены.             Заметьте, адреса запросов, используемых нами при отправке на сервер, совпадают с теми, что мы использовали в прошлом уроке в утилите “Postman”.             На этом урок завершен.             На следующем уроке мы продолжим разработку клиента, создадим контроллеры и представления для редактирования пользователей, подключим работу сервисов к странице входа в систему, создадим форму регистрации пользователя.