Full stack разработчик, который может создать из прототипа полноценный MVP (минимальный жизнеспособный продукт), часто считается тем, кто берется за все, но ничего толком не умеет, и не без оснований. Чтобы определить современного разработчика как full stack, нам сначала нужно сосредоточиться на том, кем был разработчик full stack. Full Stack разработчики «тогда», раньше Давным-давно, около 2000 года (в интернет-времени 17 лет – это очень давно), full stack разработчиком был тот, кто мог: - создать веб-страницу в некоторых инструментах Adobe, таких как Photoshop или Fireworks - превратить этот дизайн в HTML, CSS и горячие точки на изображениях (помните их?) - написать некоторые базовые сценарии PHP 4.0 (тогда объектно-ориентированного PHP не было и на горизонте) для обработки серверной части логики - хранить все динамические данные в MySQL, возможно, немного оптимизировать - загружать все на сервер по FTP и собирать оплату. Обратите внимание, о каком PHP здесь идет речь: у full stack Flash или Coldfusion разработчика был другой (но не очень отличающийся) рабочий процесс. Это были простые времена, жизнь была хорошей. Агентства, состоящие из одного человека, были весьма распространены, и люди все еще успевали проводить время с семьей после работы. Что же сейчас? Что же должен знать Full Stack разработчик сейчас? В наши дни мы сталкиваемся с такими ситуациями:  Чтобы преуспеть в современном насыщенном рынке, разработчики, которые часто являются перфекционистами, не решаются делегировать процессы и работу и часто живут под девизом «если вы хотите что-то сделать правильно, то сделайте это сами». Это загоняет специалиста в угол, где он обязан и должен знать все. Таким образом, сейчас Full Stack разработчик - это: Server Admin / Devops Разработчик должен знать, как выполнять базовое управление сервером. Это включает, но не ограничивается: - подключение к удаленным серверам через терминал, в среде без GUI - основные сценарии оболочки - управление пользователями и группами на сервере - управление серверными программами, такими как Apache и Nginx для обслуживания приложений - управление брандмауэрами и разрешениями - установка нового программного обеспечения и обновление дистрибутива Помимо этих основ, разработчик должен знать, как создавать хорошие, здоровые, изолированные среды разработки, как в Docker, так и на виртуальных машинах, таких как Vagrant. Также разработчик должен быть хорошо знаком с системами контроля версий, чтобы иметь возможность создавать резервные копии и совместные коллективные коллекции кода, отслеживать изменения во времени. В наши дни не существует современного рабочего процесса разработчиков без использования контроля версий. Облако Помимо реальных управляемых или виртуализированных серверов, разработчик должен знать об облаке – хостинге на таких платформах как Heroku, Google Cloud, Azure, AWS и других. Существует справедливое мнение о платформах и инструментах, которые являются более привлекательными, чем полезными, но знакомство с сервисами, о которых все говорят, может пригодиться в долгосрочной перспективе – клиент может потребовать переключения провайдеров в любой день, и он платит за готовность. Back End Что касается back end, помимо знания выбранного языка – например, PHP и его множества фреймворков и CMS – Full Stack Developer должен быть знаком с: - веб-серверами, такими как Nginx и Apache, которые связаны с Devops (смотрите описание выше) - NodeJS для компиляции JS, CSS и других активов в статически хранимые. Хорошие новости в том, что есть способы избежать NodeJS с помощью PHP - такими инструментами, как Composer для управления пакетами и зависимостями в самом PHP – никакая среда современного разработчика не будет завершенной без него - хорошим дизайном API, поскольку большинство новых веб-сайтов сегодня основаны на API и просто говорят об отдельном интерфейсе (подробнее об этом ниже) - поисковыми систеамиы, такими как ElasticSearch, ведь они действительно важны для производительности - cronjobs и фоновыми заданиями с помощью таких инструментов, как Gearman или библиотек, таких как Crunz - знанием о кешировании с помощью Varnish, Redis и аналогичных мощных инструментов, которые значительно снижают расходы на хостинг, часто создают или разбивают проект. Базы данных Базы данных представляют собой отдельный раздел, потому что, помимо хорошего понимания реляционных баз данных, схема которых не часто изменяется (например, MySQL или PostgreSQL), разработчик должен знать о базах данных noSQL, таких как MongoDB, Redis или Cassandra, не говоря о графовых базах данных, таких как Neo4j. Что еще хуже, все это находится на сервере, под контролем разработчика. Есть также несколько удаленных решений, таких как Mongo-like RestDB или Firebase, принадлежащая Google, и т.д. Front End Здесь вообще полный хаос. Вот довольно исчерпывающий обзор того, что необходимо для здорового рабочего процесса front end: - NodeJS и NPM - Yarn - Препроцессоры и транспиллеры (такие как Babel) для таких вещей как Typescript, ES6, LESS, SCSS, SaSS - Builders and task runners like Grunt и Gulp - Фреймворки как VueJS, React, Angular - Module bundlers, такие как Webpack, Browserify, Rollup Дизайн В дизайне разработчик должен знать, как набросать прототип приложения, прежде чем преобразовать его в пригодный для использования формат, такой как HTML и CSS. Затем может быть добавлен интерактив с ложными JS включениями и только после того, как оболочка приложения будет завершена, а user experience дизайн и дизайн интерфейсов будет готов, начнется настоящая разработка. Это само по себе является огромной стартовой работой и требует специального набора инструментов, таких как: - Photoshop и/или Illustrator или альтернатива с открытым исходным кодом, например Gimp/Inkscape - хороший, быстрый редактор, такой как Atom или Sublime Text - подборщики рисунков, такие как подклассы и подборщики цветов, которые подбирают цвета, подходящие друг другу - сетчатые системы для CSS - все от Front End до имитации JavaScript - способы развертывания прототипа онлайн для клиентов, чтобы они могли увидеть его и дать вам отзывы (например, Ngrok). Логирование Чтобы эффективно следить за здоровьем приложения, разработчик должен иметь возможность отслеживать ошибки, иметь доступ к журналам и извлекать из них ценную информацию. Он должен иметь возможность распознавать и отмечать тенденции, а также уведомлять о всплесках в использовании процессора или ввода-вывода для предотвращения простоев - вовремя. Это немного связано с Devops, но требует своего определенного набора навыков. Разработчик может создавать свой набор инструментов, который поможет получить все необходимое для всех задач ведения журнала. Например, ElasticSearch для поиска журналов, Logstash для их сбора и Kibana для панели, в которой они отображаются для удобного мониторинга. Mobile Наконец, мобильная разработка. Webview как на iOS, так и на Android становится все более и более эффективным, появились PWA (прогрессивные веб-приложения), а нативные приложения уже теряют свое очарование из-за сложного процесса их разработки. Таким образом, разработчик полного стека должен быть знаком с PWA или переходить на что-то вроде React Native или полностью на webview, например, NativeScript, Tabris, Cordova, Phonegap, или другую реализацию, чтобы получить хорошее «клиентское приложение» для своего API (см. back end раздел выше). Так стоит ли становиться Full Stack разработчиком? Итак, после всего, стоит ли стараться? Прежде всего, следует отметить, что очень немногие full stack разработчики являются такими full stack – многие сосредотачиваются только на большинстве из этих технологий и аспектов, а не на всех, просто потому, что нельзя полностью все взять во внимание. Во-вторых, знание хотя бы небольшой части всего не сделает вас мастером определенного ремесла, но позволит вам понять, что входит в проект, и какие из этих технологий действительно нужны проекту. Это бесценный навык при делегировании, открытии агентства или просто перенаправлении существующей команды с утраченного пути на конкретный вектор работы. Возможно, я не JavaScript rockstar, Elasticsearch ninja, гуру MySQL, Devops маньяк или мобильный ретранслятор, но в моем случае full stack позволяет мне расправлять мои крылья, тестировать различные технологии и предлагать альтернативные, необычные решения для моих клиентов на фрилансе. Деньги могут приходить со всех сторон, и я могу заключать контракты от работы на серверной стороне до разработки плагинов WP и всего между ними, потому что я умеренно знаком со всеми этими вещами. Для меня full stack определенно стоит того. Если сравнивать с моими Flash-днями, когда я получал огромное удовольствие от работы (без JavaScript!), то зарплата была ниже, а проекты – гораздо сложнее получить.   Источник: https://www.sitepoint.com/full-stack-developer/

Для получения качественного кода, мы должны выполнять тестирование во время его написания (если не использовать TDD). Однако, трудно сделать выбор среди такого широкого круга PHP инструментов тестирования. Эта статья посвящена самым широко распространенным инструментам тестирования. В ней собрана обновленная информация по состоянию QA инструментов в 2017 году. PHPUnit PHPUnit  - это фреймворк PHP для тестирования. Он был разработан Себастьяном Бергманом (Sebastian Bergmann) в 2004 и является одним из многих доступных средств тестирования моделей РНР в процессе разработки. Сейчас доступна 6 версия фреймворка, требующая PHP 7. Cucumber Cucumber -  это фреймворк для создания тестирования по спецификациям. Он известен своими описательными сгенерированными текстами, которые очень удобно и просто читать. Официальной реализацией PHP для Cucumber является Behat. Ниже приведен пример из документации, который хорошо отображает выразительность фреймворка. Atoum Atoum – еще один фреймворк для тестирования PHP. Это автономный пакет, который можно установить через GitHub, Composer или исполняемый файл PHAR. Тесты Atoum очень читабельны, имеют выраженные имена методов и взаимосвязи. Selenium Selenium  - это инструмент для автоматического браузерного тестирования (интегрированное и приемочное тестирование). Он преобразует тесты в команды API браузера и утверждает ожидаемые результаты. Selenium поддерживает большинство доступных браузеров. Мы можем использовать Selenium с PHPUnit, используя расширение. Вот простой пример: Dusk Dusk из Laravel – еще один инструмент автоматизации браузера. Он может использоваться автономно (с chromedriver) или с Selenium. Он имеет простой в использовании API и охватывает все возможности тестирования, такие как ожидание элементов, загрузка файлов, управление мышью и т.д. Вот простой пример: Kahlan Kahlan – это полнофункциональная среда тестирования Unit & BDD, которая использует описательный синтаксис. Из приведенного выше синтаксиса видно, что он похож на тесты Behat. Kahlan поддерживает Stub-инг и Mock-инг (stubbing and mocking out of the box) без зависимостей, покрытия кода, отчетности и т.д. php_testability Последний пакет, о котором мы упомянем здесь – PHP Testability. Это инструмент статического анализа, который рассказывает о проблемах с тестируемостью в вашей программе и генерирует подробный отчет. Пакет в настоящее время не имеет помеченного релиза, на который можно полагаться, но вы можете безопасно использовать его в разработке. Вы можете установить его через Composer: Затем запустить его следующим образом: Сервисы непрерывной интеграции (CI) Важная часть в предоставлении кода при работе с командами – это возможность автоматически проверять код до его объединения с официальным репозиторием проекта. Большинство доступных сервисов/инструментов CI предоставляют возможность тестировать код на разных платформах и конфигурациях, чтобы убедиться, что ваш код безопасен для слияния. Существует множество сервисов, которые предлагают доступные цены, но вы также можете использовать инструменты с открытым исходным кодом: • PHPCI: (с открытым исходным кодом) • TravisCI: (бесплатно для проектов с открытым исходным кодом) • SemaphoreCI: (бесплатно для проектов с открытым исходным кодом) • Jenkins   Заключение Принять культуру тестирования кода сложно, но она понемногу развивается с практикой. Если вы заботитесь о своем коде, вы должны его протестировать! Перечисленные в этой статье инструменты и ресурсы помогут вам разобраться и начать работу.   Оригинальная статья на английском языке

Универсальная платформа Windows (UWP) – это специальная платформа для создания приложений на Windows 10. Вы можете разрабатывать приложения для UWP с помощью всего одного набора API, одного пакета приложений и одного магазина для доступа ко всем устройствам Windows 10 – ПК, планшета, телефона, Xbox, HoloLens, Surface Hub и других. Легче поддерживать несколько размеров экрана, а также различные модели взаимодействия, будь то сенсор, мышь и клавиатура, игровой контроллер или ручка. В основе приложений UWP лежит идея, что пользователи хотят, чтобы их работа, их задачи были мобильными через ВСЕ устройства, чтобы можно было использовать любое устройство, наиболее удобное или производительное для конкретной задачи. UWP является гибким: вам не нужно использовать C# и XAML, если вы этого не хотите. Вам нравится развиваться в Unity или MonoGame? Предпочитаете JavaScript? Не проблема, используйте все, что хотите. У вас есть настольное приложение C++, которое вы хотите расширить с помощью функций UWP и продавать в магазине? И тут все будет работать. В итоге вы можете потратить свое время на работу со знакомыми языками программирования, фреймворками и API-интерфейсами, все в одном проекте, и иметь тот же самый код, который работает на огромном диапазоне оборудования Windows из существующих сегодня. После того, как вы написали свое приложение UWP, вы можете опубликовать его в магазине на обозрение всего мира. Итак, что такое UWP-приложение? Что делает приложение UWP особенным? Вот некоторые из характеристик, которые отличают приложения UWP в Windows 10. Существует общая среда API для всех устройств Основа API-интерфейсов универсальной платформы Windows (UWP) одинакова для всех классов устройства Windows. Если ваше приложение использует только основные API-интерфейсы, оно будет запускаться на любом устройстве Windows 10, независимо от того, планируете ли вы использование настольного ПК, гарнитуры Xbox или наушников Mixed Reality. Расширение SDK позволяет вашему приложению делать классные вещи на определенных типах устройств Расширение SDK добавляет специализированные API для каждого класса устройства. Например, если ваше приложение UWP нацелено на HoloLens, вы можете добавить функции HoloLens в дополнение к обычным API-интерфейсам UWP. Если вы используете универсальные API-интерфейсы, ваш пакет приложений может работать на всех устройствах, работающих под управлением Windows 10. Но если вы хотите, чтобы ваше приложение UWP использовало API-интерфейсы устройства тогда, когда оно работает на определенном классе устройства, вы можете проверить, существует ли API до его вызова во время выполнения. Приложения упакованы с использованием формата упаковки .AppX и распространяются из магазина Все приложения UWP распространяются как пакет AppX. Это обеспечивает надежный механизм установки и гарантирует, что ваши приложения могут быть развернуты и обновлены без проблем. Одно хранилище для всех устройств После регистрации в качестве разработчика приложений вы можете отправить свое приложение в магазин и сделать его доступным для всех типов устройств или только тех, какие вы выберете. Вы загружаете и управляете всеми своими приложениями для устройств Windows в одном месте. Приложения поддерживают адаптивные элементы управления и ввода Элементы пользовательского интерфейса используют эффективные пиксели, поэтому они могут отображать макет в зависимости от количества пикселей экрана, доступных на устройстве. И они хорошо работают с несколькими типами ввода, такими как клавиатура, мышь, сенсорный экран, ручка и контроллеры Xbox One. Если вам нужно дополнительно адаптировать свой пользовательский интерфейс к определенному размеру экрана или устройству, новые панели макетов и инструменты помогут вам в этом. Используйте язык, который вы уже знаете Приложения UWP используют Windows Runtime, собственный API, встроенный в операционную систему. Этот API реализован на C++ и поддерживается на C#, Visual Basic, C++ и JavaScript. Некоторые варианты написания приложений в UWP включают: XAML UI и C#, VB или C++ backend DirectX UI и C++ backend JavaScript и HTML Microsoft Visual Studio 2017 предоставляет шаблон приложения UWP для каждого языка, который позволяет вам создать единый проект для всех устройств. Когда ваша работа будет завершена, вы можете создать пакет приложений и отправить его в Windows Store из Visual Studio, чтобы сделать ваше приложение доступным для клиентов на любом устройстве Windows 10. Приложения UWP оживают в Windows В Windows ваше приложение может предоставлять актуальную информацию в режиме реального времени вашим пользователям и заставлять их возвращаться снова. В современной экономике приложений ваше приложение должно участвовать в жизни ваших пользователей. Windows предоставляет вам множество ресурсов, чтобы помочь вашим пользователям вернуться в ваше приложение: Живые фрагменты и экран блокировки отображают контекстно-зависимую и своевременную информацию. Push-уведомления приносят сигналы в реальном времени, отправляя предупреждения вашему пользователю, когда это необходимо. Центр действий – это место, где вы можете организовывать и отображать уведомления и контент, на которые пользователи должны обратить внимание. Background - исполнение и триггеры оживляют ваше приложение, когда пользователю это нужно. В вашем приложении могут использоваться голосовые и Bluetooth-устройства LE, чтобы помочь пользователям взаимодействовать с окружающим миром. Поддержка богатых, цифровых чернил и инновационного набора. Cortana добавляет индивидуальность вашему программному обеспечению. XAML предоставляет вам инструменты для создания плавных анимированных пользовательских интерфейсов. Наконец, вы можете использовать данные о роуминге и Windows Credential Locker, чтобы обеспечить постоянный роуминг на всех экранах Windows, где пользователи запускают ваше приложение. Данные о роуминге дают вам простой способ сохранить пользовательские настройки и настройки в облаке, не создавая собственную инфраструктуру синхронизации. И вы можете хранить учетные данные пользователя в хранилище учетных данных, где безопасность и надежность являются главным приоритетом. Монетизируйте ваше приложение В Windows вы можете выбрать, как вы будете монетизировать свои приложения на телефонах, планшетах, ПК и других устройствах. Вот несколько способов заработать деньги с помощью вашего приложения и услуг, которые оно предоставляет. Все, что вам нужно сделать, это выбрать то, что лучше подходит для вас: Платная загрузка – это самый простой вариант. Просто назовите цену. Система нескольких пробных попыток позволит пользователям оценить ваше приложение перед его покупкой. Это обеспечит более легкую конверсию, чем более традиционные варианты «freemium». Используйте скидки для привлечения внимания к своим приложениям. Также доступны покупки и реклама в приложении. Как начать? Более подробный обзор UWP читайте в официальном Руководстве по приложениям для универсальной платформы Windows. Затем ознакомьтесь с настройкой Get set up, чтобы загрузить инструменты, необходимые для начала создания приложений, и напишите свое первое приложение! Источник. 

Настало время для прогнозов по безопасности и новым технологиям на следующий год. Ведь 2016 год стал еще одним годом, когда киберпреступность достигла новых высот, превысив прошлогодний набор угроз. Увеличение количества хакеров, новых технологий и выделение незначительных бюджетов для безопасности компаний создает идеальный плацдарм для более сложных хакерских механизмов. Одно можно сказать наверняка: вся эта буря, в свою очередь, привела к повышению осведомленности об угрозах кибербезопасности и появлению методов смягчения этих угроз. Компании поняли, что, придерживаясь одинаковых стратегий безопасности, они не могут ожидать разных результатов. Их неспособность влиять на ход киберпреступности внутри организации является явным индикатором потребности в изменениях. В лучшем случае, самые везучие смогли замедлить и даже перенаправить атаки, но не остановить или значительно уменьшить их. Правительства и компании, наконец, признали важность кибербезопасности и начали вкладывать большие деньги в защиту данных. Одно можно сказать наверняка: 2016 год был хорошим годом для признания кибербезопасности, поскольку была признана ее значительность. Руководители отделов кибербезопаснсти, CISOs – Chief Information Security Officer, перешли к более активному подходу в этой сфере и сосредоточились на областях, которые могут контролировать. Главные их инициативы кибербезопасности в 2016 году (в США): Источник: Исследование кибербезопасности Deloitte-NASCIO за 2016 год В общей сложности 29% американских руководителей отделов IT-безопасности концентрируются на идентификации и управлении доступом (IAM), наиболее приоритетной является многофакторная аутентификация – 77%. Угрозы, направленные на сотрудников, такие как фишинг, фарминг, социальная инженерия и ransonware, больше всего беспокоят руководителей IT-безопасности. И хотя задачи IT-безопасности являются первоочередными, CISOs по-прежнему сталкиваются с рядом преград при внедрении решений IAM внутри компании: затраты, законодательство, приоритеты компании и т.д. Источник: Исследование кибербезопасности Deloitte-NASCIO за 2016 год Тенденции аутентификации на 2017 год Gartner определяет «аутентификацию пользователя» как подтверждение в реальном времени заявленной цифровой идентичности человека с подразумеваемым или условным уровнем доверия. Рынок аутентификации пользователей включает в себя несколько типов продуктов и услуг, которые позволяют реализовать множество методов проверки подлинности, которые направлены на сопровождение или удаление полностью классических систем на основе паролей. Существуют 3 основных метода аутентификации: Однофакторная аутентификация Двухфакторная аутентификация Многофакторная аутентификация 1. Однофакторная аутентификация (SFA) Наиболее распространенной формой однофакторной аутентификации является аутентификация на основе пароля. Пароли существуют с первых дней работы компьютеров, около 55 лет. Пароль представляет собой непостоянную последовательность символов, используемых для определения того, что пользователь компьютера, запрашивающий доступ к компьютерной системе, действительно является конкретным пользователем. Естественно, что в такой быстро развивающейся среде, того, что использовалось 55 лет назад, уже недостаточно. Пароли действительно являются самым слабым звеном в цепочке безопасности, и это связано с: Невозможность людей придумать надежный пароль (они склонны недооценивать способность хакеров угадывать их пароли). Склонность пользователей использовать один и тот же пароль для нескольких учетных записей (имея не менее 50 разных учетных записей, никто не может запомнить 50 разных паролей). Способность хакеров взламывать их в считанные секунды. Конечно, есть много менеджеров паролей, но даже эти инструменты иногда оказываются уязвимыми. Интерес к паролям не уменьшается -  в целом поиск Google по слову «пароль» достаточно популярен, а это означает, что они по-прежнему являются основным методом аутентификации для большинства пользователей и систем. Несмотря на последовательный интерес, на пароли охотятся сами создатели WWW, которые также создали консорциум под названием World Wide Consortium. Эта инициатива направлена на замену паролей более безопасными способами входа в веб-сайты, так как: «Сильная аутентификация полезна для любого веб-приложения, которое хочет поддерживать текущие отношения с пользователями». Учитывая все эти факты, мы заключаем: Прогноз 2017: аутентификация на основе пароля будет переживать стагнацию. Общая тенденция: стагнация. Почему это может произойти: - Рост заинтересованности людей в защите их частной жизни приведет к ускорению внедрения альтернативных аутентификационных механизмов. - Пароли неэффективны в защите пользовательских аккаунтов. - Как следствие разработки более сложных и безопасных систем аутентификации. - Традиционный пароль будет ориентирован на более биометрический подход. - Веб-сайты переходят к более безопасным механизмам входа. Почему это может не произойти: - Обычные пользователи в основном имеют базовые компьютерные знания и считают свои текущие пароли достаточно сильными. - Все больше пользователей используют менеджеры паролей, сохраняя таким образом привычки входа с помощью паролей. - Основная масса населения не считает свои данные «стоящими» усилий хакеров. - При создании веб-сайтов используется классический механизм аутентификации пользователь/пароль. 2. Двухфакторная аутентификация (2FA) Двухфакторная аутентификация – это в основном переход на традиционную аутентификацию на основе пароля, в результате которого добавлен дополнительный шаг к процессу входа в систему (второй фактор). Двухфакторная аутентификация (2FA), часто называемая двухэтапной аутентификацией, представляет собой процесс безопасности, в котором пользователь предоставляет два фактора аутентификации, чтобы подтвердить, что он является тем, кем является, в отличие от однофакторной аутентификации (SFA), где пользователь предоставляет только один фактор – обычно пароль. 2FA существует уже довольно давно, но пользователи не выделяют ее как другую, иную систему аутентификации. Интерес к этому типу аутентификации растет довольно резко, поскольку поисковые запросы Google для термина «двухфакторная аутентификация» растут, особенно во второй половине 2016 года. Одной из наиболее распространенных форм двухфакторной аутентификации является форма, основанная на SMS, поскольку она во многом используется большинством финансовых учреждений. Широко распространенная версия 2FA на основе SMS теперь считается небезопасной из-за того, что они отправляются через различные небезопасные системы и существует риск перехвата SMS-сообщений со стороны нежелательных сторон. Национальный институт стандартов и технологий Министерства торговли США опубликовал проект, содержащий новые рекомендуемые стандарты аутентификации. В этом проекте предлагаются другие методы проверки подлинности, кроме основанных на SMS: «OOB с использованием SMS устарел и больше не будет разрешен в будущих версиях этого руководства». Прогноз 2017: использование двухфакторной аутентификации будет возрастать. Общая тенденция: увеличение. Почему это может произойти: - Переход от аутентификации с помощью пароля к двухфакторной аутентификации сравнительно легок, так как это добавляет один проверочный шаг в процесс. - Главные компании, такие как Apple, Google и Facebook, уже внедрили ее, познакомив своих пользователей с этой новой технологией и ускоряя внедрение. - Так как 2FA будет получать большую поддержку во внедрении, уязвимости будут ликвидированы и число компаний, внедряющих эту технологию, будет расти. Почему это может не произойти: - Двухфакторная аутентификация по-прежнему основана на паролях для аутентификации, к которым добавляется дополнительный проверочный шаг. - Так как аутентификация с помощью SMS теряет популярность как небезопасная, это может повлиять на общий рост 2FA. - Пользователи стойки к 2FA системам до их внедрения, что часто заставляет их менять используемые сервисы. Однако, как только система внедрена или становится обязательной, стойкость значительно падает. 3. Многофакторная аутентификация (MFA) Более надежной альтернативой двухфакторному механизму аутентификации является многофакторная аутентификация. Многофакторная аутентификация (MFA) – это система безопасности, которая требует более одного метода аутентификации из независимых учетных данных для проверки личности пользователя при входе или другой транзакции. MFA создает многоуровневую систему защиты, которая усложняет работу хакеров, поскольку им придется взломать все независимые учетные данные: То, что пользователь знает (пароль) То, что у пользователя есть (маркеры безопасности) Что-то от пользователя (биометрическая проверка) В поиске Google термин «многофакторная аутентификация» не имеет резкого увеличения, как в случае с 2FA, но видна устойчивая ритмическая эволюция. В отчете, опубликованном Markets And Markets, показано, что рынок мультифакторной аутентификации по прогнозам превысит 9,6 млрд. долл. США, применяемый в разных областях (путешествия и иммиграция, правительство, банковское дело, оборона, коммерция, безопасность, бытовая электроника, здравоохранение). Источник: MarketsandMarkets Помимо высокого уровня безопасности, многофакторная аутентификация обеспечивает определенную степень гибкости, позволяя компании устанавливать желаемый уровень безопасности в зависимости от профиля пользователей и потребностей. Прогноз 2017: многофакторная аутентификация будет неуклонно расти. Общая тенденция: увеличение. Почему это может произойти: - Так как проблемы безопасности возрастают, компании и правительства будут искать более сложные аутентификационные системы, такие как MFA. - MFA намного безопаснее, чем 2FA, которая до сих пор сильно зависит от паролей для аутентификации. - Учитывая уровень безопасности, который имеет MFA, она превосходит по удобству 2FA. - Законодательство – это важный фактор, который положительно влияет на рост рынка MFA, так как появляются законодательные требования по охране данных. - Правительства выделяют крупные суммы для создания продуктов кибербезопасности. Почему это может не произойти: - Осведомленность о кибербезопасности все еще низкая среди компаний и сотрудников. - Организации имеют ограниченный бюджет, навыки и ресурсы для усиления кибербезопасноти, что замедляет ее внедрение. - Длинные и часто сложные финансовые процессы компаний, ориентированных на кибербезопасность и создающих аутентификационные продукты. Поскольку мир все больше озадачен сохранением конфиденциальности и защиты данных из-за повышения количества взломов, компании и правительства вынуждены придумывать более эффективные инструменты кибербезопасности. На эволюцию рынка этой отрасли влияют несколько факторов: удобство использования, осведомленность о безопасности и спрос на нее, бюджеты и законодательство. Источник: https://www.upwork.com/hiring/for-clients/authentication-trends/

В течение последних нескольких лет JavaScript изменялся. И вот 12 новых фичей, которые вы можете начать использовать уже сегодня! 1.    История JavaScript Новые дополнения к языку называются ECMAScript 6. Они также упоминаются как ES6 или ES2015+. Начиная с концепции 1995 года, JavaScript развивался медленно. Новые дополнения выходили раз в несколько лет. ECMAScript появился в 1997 году, чтобы указать путь JavaScript. Были выпущены такие его версии: ES3, ES5, ES6 и другие.   Как вы заметили, между ES3, ES5 и ES6 существуют промежутки в 10 и 6 лет. Новая стратегия состоит в том, чтобы делать небольшие постепенные изменения каждый год. Вместо того, чтобы делать большие изменения сразу, как это случилось с ES6. 2.    Поддержка браузеров Все современные браузеры и среды программирования уже поддерживают ES6!   Chrome, MS Edge, Firefox, Safari, Node и многие другие уже имеют встроенную поддержку большинства функций JavaScript ES6. Таким образом, всё, что вы собираетесь изучить в этом туториале, вы можете начать использовать прямо сейчас. Давайте начнем с ECMAScript 6! 3.    Основные функции ES6 Вы можете проверить все эти фрагменты кода на консоли своего браузера.   Так что не верьте мне на слово и тестируйте каждый пример ES5 и ES6. 3.1. Блочная область видимости переменных В ES6 мы перешли от объявления переменных с var на использование let/const. Что не так с var? Проблема var – это утечка переменной в другой блок кода, например, в циклы for или if-блоки.   Для test(false) вы ожидаете возвращения outer, но нет, вы получаете undefined. Почему? Потому что даже при том, что if-блок не выполняется, выражение var x в строке 4 «поднимается». Поднятие переменных: var является переменной области видимости. Она доступна во всей функции даже до того, как её объявят. Выражения «поднимаются». Так что вы сможете использовать переменные до их объявления. Инициализация НЕ поднимется. Если вы используете var, ВСЕГДА объявляйте ваши переменные наверху. После применения правил подъема, мы можем лучше понять, что же случилось.   ECMAScript 2015 идёт на помощь:   Изменение var на let приводит к тому, что всё работает так, как и ожидалось. Если блок if не вызывается, переменная x не поднимается из блока. Взглянём на поднятие и «временные мёртвые зоны»: В ES6 let будет поднимать переменную наверх блока (НЕ наверх функции, как это происходит в ES5). Однако ссылка на переменную в блоке перед объявлением этой переменной приводит к ReferenceError. let – переменная области видимости. Вы не можете использовать её, пока она не будет объявлена. «Временные мёртвые зоны» – это зоны в начале блока и до того места, где объявляется переменная. IIFE (Immediately-Invoked Function Expression) Перед объяснением IIFE взгляните на пример:   Как вы видите, появляется private. Для того, чтобы удержать его, вам необходимо использовать IIFE (немедленно-вызываемое выражение функции):   Если вы посмотрите на jQuery/lodash или другие open source проекты, то заметите, что они используют IIFE во избежание загрязнения глобальной  среды и определения только глобального, например _,$ или jQuery. ES6 гораздо проще, нам больше не нужно использовать IIFE, когда мы просто можем применить блоки и let:   Const Вы также можете использовать const, если не хотите, чтобы переменная изменялась вообще.   3.2. Литералы шаблонов Нам больше не нужно встраивать конкатенации, когда у нас есть литералы шаблонов. Взгляните: Сейчас вы можете использовать кавычку (`) и строковую интерполяцию ${}:   3.3. Многострочные строки Нам больше не нужно конкатенации строк + \n по типу:   В ES6 мы снова можем использовать кавычку для решения такого примера:   Оба фрагмента кода будут иметь точно такой же результат. 3.4. Назначение деструктуризации Деструктуризация в ES6 очень полезная и точная. Получение элементов с массива   То же самое:   Обмен значений   Так же:   Деструктуризация для нескольких возвращаемых значений   В строке 3 вы также можете вернуть ее в массив подобный тому, что на примере (и сохранить некоторые, набрав код):   Но потом необходимо подумать о порядке возврата данных.   В ES6 вызывающий выбирает только те данные, которые ему нужны (строка 6):   Обратите внимание: В строке 3 есть некоторые другие функции ES6. Мы можем сжать { left: left} только до { left}.Посмотрите, насколько это компактнее по сравнению с версией ES5. Разве не круто? Деструктуризация для параметров согласования   Так же, но короче:   Deep Matching   Так же, но короче:   Это также называют деструктуризацией объектов. Как видите, деструктуризация весьма полезна и способствует хорошему стилю программирования. Практический опыт: Используйте деструктуризацию массива для получения элементов или замены переменных. Это избавит вас от создания временных ссылок. Не используйте деструктуризацию массива для нескольких возвращаемых значений, вместо этого примените деструктуризацию объекта. 3.5. Классы и Объекты С ECMAScript 6 мы перешли от «функции-конструктора» к «классам». В JavaScript каждый отдельный объект имеет прототип, который является другим объектом. Все объекты JavaScript наследуют свои методы и свойства от своего прототипа. В ES5 мы использовали объектно-ориентированное программирование (ООП), применяя функцию- конструктор для создания объектов, следующим образом:   В ES6 имеется некий синтаксический сахар. Мы можем делать то же самое менее шаблонно и с новыми ключевыми словами, такими как class и constructor. Также обратите внимание на то, как мы определяем методы constructor.prototype.speak = function () vs speak():   Как видим, оба стиля (ES5/6) дают одинаковые результаты и используются одинаково. Практический опыт: Всегда используйте синтаксис класса и избегайте прямого манипулирования прототипом. Почему? Потому что это делает код более кратким и понятным. Избегайте наличия пустого конструктора. Классы имеют конструктор по умолчанию, если он не указан. 3.6. Наследование Опираемся на предыдущий класс Animal. Предположим, мы хотим расширить его и определить класс Lion. В ES5 это большей частью связано с прототипическим наследованием.   Я не буду описывать все детали, но заметьте: В строке 3 мы явно вызываем конструктор Animal с параметрами. В строках 7-8 мы назначили прототип Lion прототипу Animal. В строке 11 мы вызываем метод speak из родительского класса Animal. В ES6 у нас есть новые ключевые слова extends и super.   Посмотрите, насколько разборчиво выглядит этот код ES6 по сравнению с ES5, и они работают одинаково! Практический опыт: Используйте встроенный способ наследования с extends. 3.7. Native Promises Мы перешли от callback hell к promises.   У нас есть одна функция, которая при done получает обратный вызов для выполнения. Мы должны выполнить этот вызов дважды один за другим. Вот почему во второй раз мы вызываем printAfterTimeout. Правда, это может пойти наперекосяк, если вам нужен третий или четвёртый обратный вызов. Давайте посмотрим, как мы можем сделать это с промисами:   Как видите, мы с промисами мы можем использовать then, чтобы сделать что-либо после выполнения другой функции. Больше не нужно хранить вложенные функции. 3.8. Стрелочные функции ES6 не удалил выражения функций, но добавил новые функции – стрелочные. В ES5 были некоторые проблемы с this:   Вам нужно использовать временное this для ссылки внутри функции или использовать bind. В ES6 вы можете использовать стрелочную функцию.   3.9. For…of Мы перешли от for к forEach, и потом к for…of:   В ES6 for...of также позволяет нам делать итерации.   3.10.  Параметры по умолчанию Мы перешли от проверки того, была ли переменная определена, к присвоению значения параметрам по умолчанию (default parameters). Вы делали что-то подобное раньше?   Вероятно, это обычный шаблон для проверки того, имеет ли переменная значение или присваивает значение по умолчанию. Однако заметьте, что здесь есть некоторые спорные вопросы: В строке 8 мы задали 0, 0  и получили 0, -1 В строке 9 мы задали false, но получили true. Если в качестве параметра по умолчанию задано значение boolean или это значение равно нулю, то оно не будет работать. Знаете почему? Все расскажем после примера ES6. С ES6 вы можете писать код лучше и короче! Обратите внимание на строки 5 и 6 – мы получаем ожидаемые результаты. Пример ES5 не работает. Сначала мы должны проверить undefined, поскольку false, null, undefined и 0 являются фальшивыми значениями. Мы можем выбраться с такими цифрами:   Сейчас всё работает так, как и должно, когда мы проверяем undefined. 3.11. Rest-параметры Мы перешли от аргументов к rest-параметрам и spread-оператору. Получать произвольное количество аргументов на ES5 довольно неудобно:   Мы можем сделать то же, используя rest-оператор . . . .   3.12. Spread-оператор  Мы пришли от apply() до spread-оператора. Опять на помощь приходит . . .: Напоминание: мы используем apply () для преобразования массива в список аргументов. Например, Math.max () принимает список параметров, но, если у нас есть массив, мы можем использовать apply, чтобы заставить его работать.   Как мы видели ранее, мы можем использовать apply для передачи массивов в виде списка аргументов:   В ES6 вы можете использовать spread-оператор:   Кроме того, мы пришли от использования массивов contact к использованию spread-оператора:   В ES6 вы можете сглаживать вложенные массивы, используя оператор spread:   4.    Заключение JavaScript прошёл через множество изменений. В этой статье описываются основные функции, которые должен знать каждый разработчик JavaScript. Кроме того, в статье есть примеры из практического опыта, которые помогут сделать ваш код более кратким и простым для понимания. Материал подготовлен на основе статьи из блога Adrian Mejia

Настройка разработчиком любого сайта для успешного SEO – довольно несложный процесс. Но что делать, если вам этого недостаточно? Что вы делаете, если уже есть sitemap и robots.txt, если вы оптимизировали URL и метатеги, оптимизировали сайт под мобильные устройства, но трафика по-прежнему нет? Мы собрали четыре быстрых и простых хака для разработчиков для того, чтобы ваш SEO взлетел и сайт продвинулся в результатах поиска. AMP для мобильных устройств Много важного было сделано для мобильного поискового трафика и того, чтобы оптимизировать сайты для пользователей мобильных устройств. Мера оптимизации мобильной рекламы в Интернете еще известна как «мобильное удобство». Мобильное удобство состоит из двух основных компонентов: Пользовательский интерфейс – насколько легко пользователям перемещаться по сайту и совершать действия? Он предназначен для сенсорных экранов?  Скорость – как важная составляющая общего удобства сайта, скорость экспоненциально важнее для мобильного SEO. Мобильные пользователи ожидают, что загрузка займет всего несколько секунд. Конечно, есть способ улучшить дружелюбие вашего сайта к мобильным устройствам: Accelerated Mobile Pages. Проект AMP от Google представляет собой набор спецификаций, предназначенных для создания страниц для мобильных устройств, которые просты в использовании и навигации, плавно отображаются и загружаются практически мгновенно. AMP состоит из трех частей, которые работают вместе: HTML: В основном обычный HTML с пользовательскими свойствами для изображений, видео и фреймов; а также ограниченные технические функции, определенные спецификациями открытых источников. AMP JavaScript библиотека: AMP JS библиотека управляет загрузкой ресурса для страницы, гарантируя, что любые сторонние ресурсы не блокируют рендеринг страницы. Google AMP Cache: Специальная сеть доставки контента, которая извлекает, хранит и обслуживает действительные страницы AMP и ресурсы из одного источника. Использование спецификации ускоренных мобильных страниц все равно, что создание ярлыка для мобильного удобства. Весь проект призван помочь сделать страницы дружественными для мобильных устройств: Пользовательский интерфейс: поскольку AMP JS загружает элементы страницы асинхронно, это гарантирует, что вышеописанное содержимое появляется перед чем-либо еще. Кроме того, AMP JS требует, чтобы соотношения были предопределены, поэтому браузер знает, как будет выглядеть страница, прежде чем начнется рендеринг. Пользователи больше не подвержены неравномерным страницам с контентом, который перескакивает при загрузке. Скорость страницы: есть причина, по которой AMP имеет право на звание «ускоренных». Согласно Google, время загрузки страниц AMP на 85% ниже, чем на других страницах. Оптимизация поисковой сущности В течение последних нескольких лет Google внедрял семантическую веб-технологию в свои результаты поиска. Эти семантические технологии строятся на так называемых «сущностях». Сущности, как вы, вероятно, догадываетесь, -  люди, места и вещи. Как базовые существительные помогут вам улучшить SEO вашего сайта? Благодаря красоте семантической сети и графу знаний Google, вот как. Один из наиболее очевидных примеров семантического поиска Google, Графа знаний – это поисковая оптимизация сущности в действии. Используя структурированную разметку данных, такую как JSON-LD, RDF / XML или другие RDF-форматы, вы можете оптимизировать сущность своего бренда, чтобы максимально использовать его в Графе знаний. Используйте инструмент, например, WooRank’s Metadata Tool, чтобы указать Google на ваши профили и блоги в социальных сетях. Просто введите URL-адреса ваших профилей в инструменте, а затем скопируйте разметку на свой сайт. Оптимизация сущностей также жизненно важна для местных предприятий или крупных предприятий с локальными филиалами. Семантическая сеть действительно важна для местных предприятий, поэтому вам необходимо использовать ее возможности. Это означает добавление оптимизации ваших объектов для структурирования важных данных в результатах локального пакета Google: Используйте семантическую разметку, такую как LocalBusiness schema, чтобы добавить важные данные к информации о вашей компании: Время работы Адрес Телефонный номер Принимаемые платежи Ценовой диапазон Рейтинги Не отчаивайтесь, если вы не видите немедленного повышения трафика на ваш сайт. Как это часто бывает в случае с семантическим SEO, оптимизация сущностей – это способ наиболее быстрого получения самой важной информации о вас пользователями. Даже если они не посещают ваш сайт, мы знаем, что локальный SEO улучшает посещения магазина и увеличивает количество покупок даже без увеличения трафика веб-сайта. Переход на HTTPS Обеспечение безопасности вашего сайта – отличная идея для вас и ваших пользователей, так что это действительно хорошая идея получить сертификат SSL. Кроме того, отказ от использования HTTPS приводит к тому, что ваш сайт теряет позиции в результатах поиска. Переход на HTTPS URL-адреса – это относительно простой способ улучшить SEO вашего сайта. Даже если вы недавно приобрели SSL-сертификат и перенесли его на HTTPS, у вас все еще есть некоторые прорехи в безопасности. Даже если ваш домен размещен на защищенном URL-адресе, но на странице есть ресурсы, которые размещены на незащищенных адресах, Google это не понравится. Первым шагом будет сканирование вашего сайта, чтобы найти все ваши URL-адреса, как безопасные, так и нет. Вы можете использовать традиционный поисковый робот, например, Screaming Frog, который скомпилирует список всех URL-адресов и позволит вам найти все ресурсы без HTTPS. Или используйте инструмент Woorank Site Crawl, чтобы найти каждый экземпляр HTTPS-страниц, размещающих ресурсы на HTTP URL-адресах. Эти активы включают: Изображения CSS файлы Видео Скрипты Фрэймы После того, как вы зафиксировали HTTPS-страницы с помощью HTTP-активов, вам нужно еще кое-что проверить: Robots.txt. Поскольку Google видит URL-адреса HTTP и HTTPS как отдельные сайты, использование небезопасных URL-адресов в файле robots.txt приведет к тому, что ваш файл robots.txt будет не таким эффективным. Sitemap. Использование URL-адресов, отличных от HTTPS, в вашем файле sitemap может привести к тому, что Google будет сканировать и индексировать незащищенные URL-адреса, что противоположно тому, чего вы хотите. Канонические метки. Использование неправильной формы URL-адреса для вашего канонического тега почти полностью отменяет назначение канонического тега. После того, как вы обновили файл sitemap и файл robots.txt, повторите сканирование своего сайта с помощью Site Crawl. Все ваши канонические теги без URL-адресов HTTPS будут отображаться в разделе Canonical как канонические несоответствия. Оптимизируйте ваши изображения Размер изображений Использовать изображения и видеоролики на вашем веб-сайте – это замечательное решение, которое значительно улучшает пользовательский интерфейс, разбивая текст и делая контент более потребляемым. Вы также можете использовать их для улучшения SEO вашего сайта. Первый SEO-хак, который нужно изучить, - это оптимизация ваших изображений, которая состоит в оптимизации размера изображения. Большие изображения – одна из основных причин низкой скорости страниц и длительного времени ожидания. И не секрет, что и люди, и Google ненавидят медленные страницы. При редактировании изображений уменьшите их до минимального размера. Многие редакторы изображений, такие как Adobe Photoshop, имеют опцию «Save for the Web», которая автоматически уменьшает размер файла при сохранении качества изображения. Если у вас нет Photoshop, есть несколько онлайн инструментов, которые вы можете использовать, чтобы избавиться от дополнительных данных, таких как EXIF: ImageOptim JPEGmini PunyPNG Вы также можете использовать консоль браузера или Google’s PageSpeed Insights для того, чтобы найти неоптимизированные изображения, которые замедляют загрузку ваших страниц. Название файлов и альтернативный текст Большая проблема при использовании изображений для SEO – это сообщить поисковым системам, что находится на изображении и как это относится к странице. Но все изображения можно оптимизировать по ключевым словам: Имя файла: имена файлов относятся к изображениям, подобно URL-адресам для веб-страниц. И они должны быть оптимизированы во многом таким же образом. Большинство хостеров изображений будут использовать имя файла изображения при создании его URL, так что такая оптимизация окупится еще больше. При создании имен файлов будьте описательными и краткими и не используйте подчеркивания. Избегайте использования имен файлов по умолчанию, например, «DSC673829.jpg» или «image_01.jpg», кроме случаев, когда это невозможно. Альтернативный текст: альтернативный текст вместе с именем файла является одной из наиболее важных частей изображения для SEO. Это представляет собой машиночитаемый «контент» изображения, так что это ваша возможность добавить ваше ключевое слово. Как и имена файлов, альтернативный текст должен быть кратким, но, если сделать его слишком коротким, это отрицательно скажется на его преимуществах. Хороший alt text для этого изображения: Выглядел бы так: img src="audit-alt-text-criteria.jpg” alt=”Alt text criteria in the WooRank SEO audit’/ Держите ключевые слова релевантными для фактического изображения, а не обязательно для страницы. Попытка использовать альтернативный текст типа “Alt text in SEO audit as SEO hack for developers” может оказаться похожим на спам-ключевик. Это нехорошо. Подведение итогов Конечно, есть вероятность, что ваши проблемы с трафиком Google могут выходить за рамки четырех хаков, перечисленных выше. Если ваш трафик все еще низкий, выясните, как диагностировать и лечить возникшую проблему. Если вы хотите начать развивать свою аудиторию, проведите один или два SEO-эксперимента. Узнайте, что работает именно для вас. Источник

В этой статье мы расскажем о нововведениях в языке C# 7.0, которые были представлены в марте 2017 года как часть релиза Visual Studio 2017. В C# 7.0 появился целый ряд нововведений и основное внимание уделяется использованию данных, упрощению кода и улучшению производительности. Возможно, самой главной особенностью являются кортежи, которые упрощают получение различных результатов, и сопоставление с шаблоном, что упрощает код, который зависит от формы данных. Существует также множество других нововведений, как значительных, так и не очень. Надеемся, что в совокупности они сделают ваш код более эффективным и точным, а вы при этом будете работать продуктивнее и останетесь довольны результатом. Если вас интересует процесс разработки, который привел к этому набору функций, вы можете найти заметки, предложения и множество обсуждений на эту тему на сайте C# language design GitHub. Если данная информация кажется вам знакомой, это только потому, что релиз предварительной версии состоялся в августе прошлого года. В окончательной версии C# 7.0 изменились некоторые детали, некоторые из них - из-за отличных отзывов на указанную ранее статью. Получайте удовольствие от C# 7.0 и удачного хакинга! Out переменные В более ранних версиях C# использование out параметров является не таким легким, как нам хотелось бы. Прежде чем вызвать метод с out параметрами, сначала необходимо объявить переменные, чтобы перейти к нему. Поскольку вы обычно не инициализируете эти переменные (они все равно будут перезаписаны методом), вы также не можете использовать ключевое слово var, но вам нужно указать полный тип: public void PrintCoordinates(Point p) { int x, y; // have to "predeclare" p.GetCoordinates(out x, out y); WriteLine($"({x}, {y})"); } В C# 7.0 мы добавили out переменные, что позволяет объявлять переменную прямо в точке, где она передается как out аргумент: public void PrintCoordinates(Point p) { p.GetCoordinates(out int x, out int y); WriteLine($"({x}, {y})"); }  Обратите внимание, что переменные находятся в области видимости в окружающем блоке, поэтому последующая строка может их использовать. Многие виды утверждений не устанавливают свою собственную область действия, поэтому out переменные, объявленные в них, часто вводятся в область видимости. Поскольку out переменные объявляются непосредственно в качестве аргументов для out параметров, компилятор может обычно указывать, каков должен быть их тип (если только не существует конфликтующих перегрузок), поэтому вместо типа можно использовать ключевое слово var: p.GetCoordinates(out var x, out var y);  Общим использованием out параметров является шаблон Try..., где логическое возвращаемое значение указывает на успех, а out параметры переносят полученные результаты: public void PrintStars(string s) { if (int.TryParse(s, out var i)) { WriteLine(new string('*', i)); } else { WriteLine("Cloudy - no stars tonight!"); } }  Мы также допускаем «сбрасывание» в качестве out параметров в виде «_», что позволит вам проигнорировать параметры, которые вам не нужны: p.GetCoordinates(out var x, out _); // I only care about x Соответствие с шаблоном В C# 7.0 вводится понятие шаблонов, которые являются синтаксическими элементами, позволяющими проверить соответствие значения определенной «форме» и извлечь информацию из значения, если такое соответствие имеется. Примеры шаблонов в C# 7.0: • Константные шаблоны c (где c – константное выражение в C#), которые проверяют, равняется ли переменная этой константе. • Шаблоны типа T x (где T – тип и x – идентификатор), которые проверяют, имеет ли переменная тип T, и если да, то извлекают значение в новую переменную x типа T. • Var шаблоны var x (где x – идентификатор), которые всегда совпадают и просто помещают значение ввода в новую переменную x с тем же типом. Это только начало; шаблоны являются новым типом элемента языка C#, и в будущем мы обязательно добавим новые шаблоны в C#. В C# 7.0 мы улучшаем две существующие языковые конструкции с шаблонами: • is теперь может использоваться не только с типом, но и с шаблоном; • case в операторе switch теперь может использовать шаблоны, а не только константы. В будущих версиях C#, вероятно, мы добавим больше мест, где можно использовать шаблоны. Шаблоны с is Рассмотрим пример использования is с константным шаблоном и шаблоном типа: public void PrintStars(object o) { if (o is null) return; // constant pattern "null" if (!(o is int i)) return; // type pattern "int i" WriteLine(new string('*', i)); } Как видно из примера, переменные шаблона, представленные шаблоном, аналогичны out переменным, описанным ранее, поэтому могут быть объявлены в середине выражения и использоваться в ближайшей окружающей области. Также как out переменные, переменные шаблона изменяемы. Мы часто ссылаемся на out переменные и переменные шаблона совместно как «переменные выражения». Шаблоны и Try-методы часто используются вместе: if (o is int i || (o is string s && int.TryParse(s, out i)) { /* use i */ } Шаблоны с выражениями switch Мы обобщаем варианты использования switch: • Вы можете использовать любой тип (не только простые типы). • Шаблоны могут использоваться в выражениях case. • Вы можете добавлять дополнительные условия к выражениям case. Вот простой пример: switch(shape) { case Circle c: WriteLine($"circle with radius {c.Radius}"); break; case Rectangle s when (s.Length == s.Height): WriteLine($"{s.Length} x {s.Height} square"); break; case Rectangle r: WriteLine($"{r.Length} x {r.Height} rectangle"); break; default: WriteLine(""); break; case null: throw new ArgumentNullException(nameof(shape)); } Существует несколько особенностей, которые следует отметить в этом новом расширенном выражении switch: • Порядок выражений case теперь имеет значение: как и в случае с выражениями catch, у выражений case выбирается первое по порядку выражение, удовлетворяющее условию. Поэтому важно, чтобы условие квадрата было перед условием прямоугольника. Кроме того, как и в случае с выражениями catch, компилятор поможет вам пометить явные недостижимые условия. До этого вы не могли определить порядок выполнения, так что это не является нарушением существующего поведения. • Условие по умолчанию (default) всегда вычисляется последним: несмотря на то, что после него идет условие null, условие default будет проверено после него. Это сделано для совместимости с существующей семантикой. Однако, как правило, вы помещаете условие default  в конце. • Условие null в конце достижимо, потому что шаблоны типов следуют примеру текущего is  и не срабатывают для null. Это гарантирует, что null значения не будут случайно сопоставлены с первым шаблоном типа; вы должны явно указать, как им управлять (или оставить логику для условия default). Переменные шаблона, объявленные ключевым словом case..., находятся в области видимости только в соответствующем разделе switch. Кортежи Обычно хочется вернуть несколько значений из метода. Все доступные варианты в существующих версиях C# являются менее оптимальными: • Out параметры: использование является неэффективным (даже при использовании рассмотренных нововведений) и они не работают с асинхронными методами. • System.Tuple <...>: выглядит многословным для использования и требует выделения кортежного объекта. • Специальный вид переноса для каждого метода: слишком много кода для типа, единственной целью которого служит временная группировка нескольких значений. • Анонимные типы, возвращаемые через тип возврата dynamic: потери в производительности и отсутствие проверки статического типа. Для упрощения этой задачи в C# 7.0 были добавлены кортежи и литералы кортежей: (string, string, string) LookupName(long id) // tuple return type { ... // retrieve first, middle and last from data storage return (first, middle, last); // tuple literal }  Теперь метод эффективно возвращает три строки, объединенные как элементы кортежа. Вызывающий код метода получит кортеж и может индивидуально иметь доступ к элементам: var names = LookupName(id); WriteLine($"found {names.Item1} {names.Item3}."); Имена полей Item1 и т. д. являются именами по умолчанию для элементов кортежа и могут использоваться всегда. Но они не очень наглядны, поэтому вы можете добавить лучшие имена: (string first, string middle, string last) LookupName(long id) // tuple elements have names Теперь получатель этого кортежа имеет более описательные имена для дальнейшей работы: var names = LookupName(id); WriteLine($"found {names.first} {names.last}."); Вы также можете указать имена элементов непосредственно в литералах кортежей: return (first: first, middle: middle, last: last); // named tuple elements in a literal Как правило, вы можете назначать типы кортежей друг для друга, независимо от их имен: при условии, что отдельные элементы будут присваиваемыми, типы кортежей могут свободно преобразовываться в другие типы кортежей. Кортежи – это типы значений, а их элементы – общедоступные изменяемые поля. Они имеют значение равенства, а это значит, что два кортежа являются равными (и имеют одинаковый хэш-код), если все их элементы попарно равны (и имеют одинаковый хэш-код). Это делает кортежи полезными для различных ситуаций, а не только для возвращения нескольких значений из метода. Например, если вам нужен словарь с составным ключом, используйте кортеж в качестве ключа, и все будет работать правильно. Если вам нужен список с несколькими значениями в каждой позиции, также используйте кортеж для корректной работы. Кортежи полагаются на базовые структурные типы, которые называются ValueTuple <...>. Если вы выявите модель, что еще не включает эти типы, вы можете вместо этого выбрать их с помощью NuGet: • Щелкните правой кнопкой мыши проект в обозревателе решений и выберите «Manage NuGet Packages…». • Выберите вкладку «Browse» и выберите «nuget.org» в качестве «Package source». • Найдите «System.ValueTuple» и установите его. Распаковка кортежей Еще один способ использования кортежа – это его распаковка. Объявление распаковки является синтаксисом для разделения кортежа (или другого значения) на его части и назначения этих частей по отдельности новым переменным: (string first, string middle, string last) = LookupName(id1); // deconstructing declaration WriteLine($"found {first} {last}."); В объявлении распаковки можно использовать ключевое слово var для отдельных переменных: (var first, var middle, var last) = LookupName(id1); // var inside Или даже поместить var перед скобками как аббревиатуру: var (first, middle, last) = LookupName(id1); // var outside Вы также можете распаковать в уже существующие переменные с помощью присвоения распаковки: (first, middle, last) = LookupName(id2); // deconstructing assignment Распаковка выполняется не только для кортежей. Любой тип может быть распакован, если у него есть метод распаковки (образец или расширение): public void Deconstruct(out T1 x1, ..., out Tn xn) { ... } Out параметры соответствуют значениям, которые будут присвоены в результате распаковки. (Почему используются out параметры, а не кортежи? Чтобы можно было иметь несколько перегрузок метода с разным количеством параметров). class Point { public int X { get; } public int Y { get; } public Point(int x, int y) { X = x; Y = y; } public void Deconstruct(out int x, out int y) { x = X; y = Y; } } (var myX, var myY) = GetPoint(); // calls Deconstruct(out myX, out myY); Это будет обычный шаблон для создания «симметричных» конструкторов и методов распаковки таким способом. Так же, как и для out переменных, мы разрешаем «сбрасывать» в распаковке параметры, которые вам не нужны: (var myX, _) = GetPoint(); // I only care about myX Локальные функции Иногда вспомогательная функция имеет смысл только внутри одного метода, в котором вызывается. Теперь вы можете объявить такие функции внутри других функций как локальную функцию: public int Fibonacci(int x) { if (x < 0) throw new ArgumentException("Less negativity please!", nameof(x)); return Fib(x).current; (int current, int previous) Fib(int i) { if (i == 0) return (1, 0); var (p, pp) = Fib(i - 1); return (p + pp, p); } } Параметры и локальные переменные из области видимости доступны для локальной функции так же, как и для лямбда-выражений. В качестве примера рассмотрим методы, реализованные как итераторы, что обычно нуждаются в неитераторном методе-оболочке для точной проверки аргументов в момент их вызова (так как сам итератор не запускается, пока не будет вызван MoveNext). Локальные функции идеально подходят для этого сценария: public IEnumerable Filter(IEnumerable source, Func filter) { if (source == null) throw new ArgumentNullException(nameof(source)); if (filter == null) throw new ArgumentNullException(nameof(filter)); return Iterator(); IEnumerable Iterator() { foreach (var element in source) { if (filter(element)) { yield return element; } } } } Если бы Iterator был приватным методом рядом с Filter, то мог быть доступен для других членов в использовании напрямую (без проверки аргументов). Кроме того, необходимо было бы передавать все те же аргументы, что и Filter, вместо того, чтобы иметь их только в области видимости. Улучшения литералов В C# 7.0 появилась возможность добавлять «_» в качестве разделителя в числовые литералы: var d = 123_456; var x = 0xAB_CD_EF;  Вы можете поместить разделитель в любом месте между цифрами, чтобы улучшить читабельность. Они не влияют на значение. Кроме того, C# 7.0 представляет бинарные литералы, так что вы можете указывать битовые шаблоны непосредственно вместо того, чтобы знать шестнадцатеричную систему наизусть. var b = 0b1010_1011_1100_1101_1110_1111;  Локальные переменные и возвращаемые значения по ссылке Теперь можно не только передать параметры в метод по ссылке в  С# (с помощью ключевого слова ref), но и возвратить данные из метода по ссылке, а также сохранить в локальной переменной тоже по ссылке. public ref int Find(int number, int[] numbers) { for (int i = 0; i < numbers.Length; i++) { if (numbers[i] == number) { return ref numbers[i]; // return the storage location, not the value } } throw new IndexOutOfRangeException($"{nameof(number)} not found"); } int[] array = { 1, 15, -39, 0, 7, 14, -12 }; ref int place = ref Find(7, array); // aliases 7's place in the array place = 9; // replaces 7 with 9 in the array WriteLine(array[4]); // prints 9 Очень удобно передавать ссылки на определенные места в больших структурах данных. Например, в игре информация содержится в большом заранее выделенном массиве структур (во избежание пауз на сбор мусора). Теперь методы могут вернуть ссылку непосредственно на одну из таких структур, с помощью которой вызывающий код может читать и изменять эту структуру. Существуют некоторые ограничения для обеспечения безопасности: • Можно возвращать только ссылки, которые возвращать безопасно: ссылки, переданные в метод и ссылки на поля объектов. • Локальные переменные инициализируются определенной ячейкой памяти и в будущем не меняются. Обобщенные типы асинхронных возвратов До сегодняшнего дня асинхронные методы могли возвращать только void, Task или Task. В C# 7.0 позволяется создавать типы, которые также могут быть возвращены асинхронным методом. Например, можно создать структуру ValueTask, которая поможет избежать создания объекта Task в случае, когда результат асинхронной операции уже доступен в ожидаемое время. Для многих асинхронных сценариев, например, где используется буферизация, такой подход может значительно уменьшить число выделений памяти и таким образом значительно повысить производительность. Конечно, можно придумать и другие ситуации, в которых task-подобные объекты будут полезны. Правильное создание таких типов не будет простой задачей, поэтому мы не ожидаем, что большое количество разработчиков будут создавать их. Однако мы полагаем, что они будут появляться в различных моделях и прикладных интерфейсах, и вызывающий код сможет просто использовать await, как сейчас для Task. Больше членов в виде выражений Методы и свойства в виде выражений используются в C# 6.0, но не все типы членов можно было так объявлять. В C# 7.0 к списку членов в виде выражений добавилась поддержка аксессоров, конструкторов и финализаторов: class Person { private static ConcurrentDictionary names = new ConcurrentDictionary(); private int id = GetId(); public Person(string name) => names.TryAdd(id, name); // constructors ~Person() => names.TryRemove(id, out _); // finalizers public string Name { get => names[id]; // getters set => names[id] = value; // setters } } Это пример функции, которая была предоставлена сообществом, а не командой компилятора Microsoft C#. Ура, открытый код! Throw выражения Выбросить исключение в середине выражения очень легко: достаточно вызвать метод, который это сделает! Но в C# 7 теперь можно использовать throw как часть выражения в определенном месте: class Person { public string Name { get; } public Person(string name) => Name = name ?? throw new ArgumentNullException(nameof(name)); public string GetFirstName() { var parts = Name.Split(" "); return (parts.Length > 0) ? parts[0] : throw new InvalidOperationException("No name!"); } public string GetLastName() => throw new NotImplementedException(); } Источник

Необходимо ли вам знать об уязвимостях в .NET? Возможно, вы по-новому взглянете на код, а может, и на свою жизнь. А вдруг вам захочется сменить квалификацию и уйти в research новых видов атак? Кто знает. Но если вы задались вопросом об уязвимости, то вы наверняка интересуетесь тем, как разрабатывать надёжные и защищённые приложения. Итак, давайте поговорим об уязвимостях, которые находят в .NET Framework.  DoS (Denial of service) – атака на ASP .NET MVC приложение. Эта атака способна серьезно нарушить работу вашего сайта, например, замедлить его, а в отдельных случаях и вовсе его заблокировать.  Как работает На сервер производятся запросы, которые он не может обработать, в результате чего сервер не успевает обрабатывать запросы обычных посетителей и выглядит для них как неработающий. Как исправлять Упростить регулярное выражение Заменить регулярное выражение на custom алгоритм Задать timeout для обработки любого регулярного выражения, используя конструктор, или для всех регулярных выражений, используя AppDomain.   Это отличные примитивные меры, когда вам не очень хочется разбираться в том, какие у вас регулярные выражения и насколько они сложные. Тем более, что такие решения вам ничего не стоят, но дают результат. Атака повышения привилегий (ЕоР) на SQL-сервер. В данном случае это luring атака, которая может скомпрометировать все данные на сервере. Атака повышения привилегий (ЕоР) в ASP .NET Core 1.0. Эта уязвимость была зафиксирована как ошибка бизнес-логики, но позже выяснилось, что она может привести к раскрытию данных и повышению привилегий пользователя. Как работает Атакующий «заманивает» более привилегированный компонент, чтобы что-то сделать от его имени. Самый простой способ осуществить такую атаку – убедить цель запустить код атакующего в более привилегированном контексте безопасности. Как исправлять Единого сюжета, как избежать этих уязвимостей, к сожалению, нет. Можно дать лишь общие рекомендации. Например: Зарегистрировать request-сервис в контексте синглтона Дважды проверять любой код, работающий с security sensitive, c sandboxing и с модификацией данных Runtime check – ещё один хороший способ защиты от подобных вещей Минимум привилегий везде Раскрытие информации ХХЕ -  это уязвимость к XML-инъекциям, которая приводит к чтению произвольных файлов на атакуемом сервере. Как работает Чтобы понять суть ХХЕ, давайте сначала разберёмся с ХМL форматом. ХМL формат может содержать описание своей структуры в теге DOCTYPE. В этом же теге могут содержаться и некоторые Entity. Если говорить по-простому, то это аналог константы, который дальше может использоваться в ХМL коде и, при парсинге этого кода, будет автоматически раскрываться. Уже это обстоятельство может привести к DoS атаке, если вы добавите Entity, которые рекурсивно раскрываются, и не зададите timeout. Парсер начнёт их раскрывать бесконечно долго. Классическая ХХЕ атака проходит следующим образом. Атакующий отправляет скомпрометированный ХМL файл на сервер, где этот файл парсится, после чего из сервера возвращается ответ. Ответ может быть совершенно любого типа, хотя существует вероятность, что злоумышленник получит именно тот локальный файл, который ему нужен. Как исправлять Запретить использование DTD файлов и External Entity Занулить resolver Ввести ограничение на размер и установку timeout Одной из причин появления уязвимостей может быть десериализация бинарных данных. Десериализация данных – это обратный процесс сериализации. То есть если при сериализации мы переводим какую-либо структуру данных в последовательность битов, то при десериализации мы восстанавливаем начальное состояние этой структуры. Как при этом процессе может возникнуть уязвимость? Допустим, у вас есть класс, реализующий команду, который запускает какой-то конвертор. Вы через конструктор передаете ему параметры этого конвертора и они валидируются в конструкторе. При этом использовать можно не каждый, а только ваш локальный конструктор. В чём же проблема? А проблема состоит в том, что при десериализации данных конструктор не будет запущен. То есть ваши данные будут десериализованы так, как они есть, включая приватные поля. Как исправлять Использовать кастомный сериализатор Использовать минимум привилегий в процессе десериализации О возможных способах десериализации вы можете узнать больше в статье Джеймса Форшав «Are you my Type? Breaking .NET Trough Serialization». Вывод К всеобщему сожалению, сейчас не существует ни одного полностью защищённого  веб-приложения. Поэтому проблема уязвимостей остаётся актуальной. Злоумышленники находят всё новые и новые способы взлома серверов и нанесения всяческого вреда компаниям или обычным людям. Следовательно, для гарантии безопасности вашего приложения вам необходимо знать, как устранять уязвимости и препятствовать их появлению. Материал подготовлен на основе выступления Михаила Щербакова, Independent Consultant, на конференции по .NET-технологиям DotNext 2016 Moscow.

Недавно у меня была действительно интересная дискуссия с участником команды, который является экспертом по системам типов в .NET. В ходе беседы он указал на интересный аспект упаковки типа значений в .NET при использовании ограничений. Заинтригованный этой дискуссией, я решил рассмотреть вопрос подробнее. Основы Прежде чем углубиться в подробности, давайте рассмотрим некоторые основы и посмотрим, какую роль может играть упаковка при вызове методов типа значение. Предположим, у нас есть следующий код: Здесь нет ничего особенного. Foo - это структура, которая имеет целочисленное поле value. Она приватно реализует метод интерфейса, который пытается изменить значение этого поля, а также обычный метод, который делает то же самое. Теперь, если у нас есть следующий код: Какое правильное значение после вызова AddValue и после вызова Add? Если вы знакомы с языком, это, пожалуй, вовсе не удивит вас. Но давайте немного углубимся и посмотрим, как JIT это делает: Давайте сначала посмотрим на вызов AddValue. Обратите внимание, что я показываю код сборки x64, который гораздо проще понять. Первые 4 аргумента всегда передаются в регистре rcx, edx, r8, r9 (остаток передается через стек), а возвращаемое значение возвращается в rax. Все это 64-разрядные регистры. В приведенном выше коде JIT передает указатель «this» в rcx (указывает на часть стека, начиная с rbp-18h, и целое число 10 (0x0a) в rdx / edx (edx - это просто нижняя 32-битная часть rdx). Теперь, если вы посмотрите на фактический код Foo.AddValue: Не стесняйтесь игнорировать некоторые из отладочной тарабарщины (clr! JIT_DbgIsJustMyCode). Если вы следите за моими комментариями в сборке (начиная с ;), вы можете увидеть, что 10 добавляется в первую 4-байтовую ячейку памяти в 'this', что и должно делать value + = val. И вы получите следующее: Вызов интерфейса в методе экземпляра типа значения. Теперь давайте взглянем на вызов интерфейса - он немного усложняется: Опять-таки, я поставил комментарии по правой стороне кода сборки. Он в основном создает упакованную Foo, копирует значение во вновь созданную упакованную Foo. Обратите внимание, что смещение 8 для указателя MethodTable в начале объекта  имеют только те объекты и упакованные типы значений, которые являются объектами, разумеется. У обычных типов значений его нет. На данный момент проигнорируйте весь код отправки интерфейса (это не относится к нашему обсуждению), в конце концов вы придете к некоторым интересным инструкциям ниже: Этот код, на самом деле, мало что делает. Но он  дает нам  понимание того, как система работает в целом. Глядя на старый код, который мы показали ранее для метода AddValue, ожидаемо, что он укажет на первое поле. Однако все объекты для поддержки операций типа (таких как рефлексия, кастинг и т. д.) имеют свое первое поле размера указателя в качестве указателя типа, который в языке CLR называется MethodTable. Таким образом, CLR необходимо сгенерировать unboxing-заглушку, которая распаковывает запакованное значение и вызывает базовый JIT-метод, который предполагает работу с распакованным указателем this. Обратите внимание, что распаковка не включает копирование, она просто добавляет к ней смещение. Это фактически означает, что операция + = вступит в силу в упакованной копии. Однако поскольку упакованная Foo известна только компилятору, обновленное значение всегда теряется. И именно поэтому вы увидите: В случае наличия обобщений Теперь давайте добавим некоторые обобщения в микс: Несмотря на то, что это фантастический универсальный метод, сам вызов и лежащий в его основе код не имеет ничего удивительного. Как вы могли ожидать, несмотря на то, что вызывающий элемент передает Foo по ссылке, Add_WithoutConstraint создает его копию, прежде чем вызывает в IAdd, и модификация снова навсегда потеряна. Добавление ограничений Теперь интересный случай, о котором я хотел поговорить ранее в этой статье (спасибо, что остались со мной до сих пор!). Давайте создадим обобщенный метод с общим ограничением, где T является интерфейсом IAdd: Возможно, это не совсем очевидно для всех, foo.Add (val) - это вызов интерфейса с помощью инструкции callvirt: callvirt instance void IAdd :: Add (int32), потому что это единственный способ, который знает компилятор для вызова интерфейса. Интересной частью является то, что, когда мы вызываем Add_WithConstraints, вызов происходит точно таким же образом, за исключением того, что код, который мы вызываем, радикально отличается: Как вы видите, код удивительно прост. Без упаковки, без трансляции интерфейса и прямого вызова метода Foo.IAdd.Add. Никакое значение не теряется. И вы можете наблюдать побочный эффект: Причина в том, что компилятор теперь имеет достаточно информации, чтобы понять, что код для Foo и вызов интерфейса попадет именно на Foo.IAdd.Add, поэтому он пропускает формальности и вызывает функцию напрямую. Это как оптимизация производительности, но также с заметным побочным эффектом. Вывод Когда вы работаете с интерфейсом по типам значений, обратите внимание на потенциальные затраты производительности на упаковку и проблему корректности отсутствия видимых изменений. Если вы хотите избежать этого, вы можете использовать общие ограничения для ограничения вызова интерфейса, чтобы компилятор мог полностью оптимизировать вызов упаковки и интерфейса, и сразу перейти к правильной функции. Вы найдёте полный код в этом сообщении. Источник

В мире дедлайнов правильный выбор технологии играет ключевую роль. Имея многолетний опыт за спиной, мы были вовлечены в разработку на десятках языков, с использованием фреймворков и библиотек. Собрав вместе наши знания, мы решили пролить свет на вопрос: 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