Все мы знаем простую формулу: быстрый сайт = счастливые пользователи, высокая оценка Google-статистики и увеличение количества переходов. Возможно, Вам и кажется, что Ваш сайт работает настолько быстро, насколько ему позволяет быть быстрым WordPress – Вы же видели те списки лучших практик настройки сервера, улучшения производительности кода и так далее – но всё же, разве это предел? Используя динамические базы данных сервисов типа WordPress, в конечном итоге перед Вами предстанет проблема: запросы к базе замедляют работу сайта. В рамках этого поста я постараюсь научить Вас определять проблемные места, понимать их причину и предложу некоторые быстрые решения и другие программные подходы для ускорения работы. В качестве примера мы будем использовать действующие примеры работы с базой, замеченные на одном из сайтов.   Идентификация Первый шаг на пути повышения производительности - это обнаружение проблемных SQL-запросов. И на сцену выходит Query Monitor – по-настоящему незаменимый плагин для мониторинга работы запросов. Особенность его в том, что плагин показывает детальную информацию о каждом запросе, позволяя к тому же отфильтровать их, исходя из порождающего участка кода (включается подсветка дублированных запросов). Если же по какой-то причине Вы не желаете устанавливать отладочный плагин, вы можете в качестве опции включить MySQL Slow Query Log, логирующий все запросы, требующее длительное время для выполнения. К тому же конфигурация и настройка места логирования относительно проста. Так как это серверное дополнение, падение производительности будет заметно в меньшей мере, чем если бы вместе с отладочным плагином непосредственно на сайте. Однако по мере отсутствия необходимости, MySQL Slow Query Log стоит отключать.   Понимание Как только вы находите затратный по времени запрос, который было бы неплохо улучшить, встает следующий вопрос: почему он работает медленно? К примеру, во время разработки одного сайта был обнаружен запрос, работающий целых 8 секунд! Для поддержки магазина плагинов мы использовали WooCommerce и кастомизированную версию WooCommerce Software Subscriptions плагина. Задача приведенного выше запроса была получить все подписки пользователя, оперируя его идентификационным номером. WooCommerce обладает своеобразной комплексной моделью данных, при использовании которой наблюдалось следующее: хотя  запрос и хранится как пользовательские пост-типы, идентификатор пользователя хранится в пост-мета данных, а не в post_author, как должно было бы быть. Также было найдено несколько связок с пользовательскими таблицами, созданными плагином. Итак, как же нам уберечь себя от подобных ошибок?   MySQL – Ваш друг MySQL обладает весьма полезным выражением DESCRIBE, которое используется для вывода информации о структуре таблицы (такой, как столбцы, типы данных, дефолты). К примеру, если Вы выполните команду DESCRIBE wp_postmeta, Вы увидите следующий результат: Это, конечно, хорошо, но, возможно, Вы уже знали об этом. Но знали ли Вы, что DESCRIBE также может быть использован в качестве префикса для SELECT, INSERT, UPDATE, REPLACE и DELETE? Широкой общественности это так же известно, как синоним EXPLAIN, который дает нам детальную информацию, как именно та или иная команда будет выполнена. Вот результат для нашего проблемного запроса: На первый взгляд, понять это не слишком-то просто. Однако при более детальной расшифровке задача упрощается. Наиболее важной колонкой считается type, так как она описывает связь между таблицами. Если вы замечаете слово ALL, это значит, что MySQL читает всю таблицу с диска, нагружая центральный процессор. Сие также известно под термином «полное сканирование таблицы» - позже мы вернемся к этому. Колонка row также хороший индикатор того, что нужно, собственно говоря, MySQL сделать. Эта колонка наглядно демонстрирует, сколько рядов было прочитано, дабы найти результат. Ключевое слово EXPLAIN также дает более полную информацию, полезную для дальнейшей оптимизации запросов. К примеру, таблица pm2 (wp_postmeta) говорит нам о том, что мы используем Using filesort, так как нам нужно отсортировать результаты по возрастанию (ORDER BY).   Визуальное изучение Здесь стоит упомянуть о таком полезном инструменте, как MySQL Workbench. Так как для баз данных, работающих на версии MySQL 5.6 и выше, результаты EXPLAIN формируются в виде JSON, MySQL Workbench конвертирует JSON в визуальное представление. Утилита автоматически обращает Ваше внимание на проблемные запросы. На картинке мы ясно можем видеть, что wp_woocommerce_software_licences вызывает негодование.   Решение Упомянутая часть запроса проводит полное сканирование таблицы, чего Вам, собственно говоря, по мере возможности стоит избегать. К тому же тут используется неиндексированная колонка order_id в качестве ссылки между таблицами wp_woocommerce_software_licences и wp_posts. Подобная ситуация – общая причина большинства «медленных» запросов. Которая, однако, решается просто.   Индексы Order-id - достаточно важная часть идентификационной информации. Потому, если мы строим запрос подобным образом, мы должны иметь при себе индекс колонки. В противном случае MySQL в буквальном смысле просканирует ВСЕ рядки таблицы, пока не найдет нужный. Давайте добавим индекс и проверим, что из этого получится:   Невероятно, но нам удалось урезать порядка 5 секунд выполнения запроса!   Знайте свой запрос Проверяйте запрос – команда за командой, подзапрос за подзапросом. Не делает ли он того, чего нам не нужно? Можем ли мы что-то оптимизировать? В этом случае, ограничивая пост-типы shop_order, мы связываем таблицы лицензий с таблицами постов при помощи order_id. Повышая интеграцию данных, подобным образом мы убеждаемся, что используются только корректные порядки записей. Однако на самом деле это только внешняя часть запроса. Довольно опасно иметь строку software license в таблице, владеющей связанным с порядком WooCommerce order_id в пост-таблицах. Причина этому – связка с PHP-кодом плагина. Давайте удалим зависимость и посмотрим на результат: Конечно, это не очень много, но теперь запрос работает до 3 секунд вместо 8!   Кэшируйте все, что только можно! Если на Вашем сервере не установлен MySQL query caching, тогда пора установить его. Это позволит MySQL вести запись всех исполняемых команд – совместно с их результатом. Кэш же, в свою очередь, не «устаревает», так как MySQL обновляет кэш при изменении таблиц. Query Monitor обнаруживает, что наш запрос запускается 4 раза на одной странице. И, хотя query caching – полезная штука, дублирующие запросы должны быть удалены. Статическое кэширование в PHP – это достаточно простое и эффективное решение проблемы. По сути, Вы просто перехватываете результат чтения из базы и заносите его в статическое свойство класса. Когда будет вызван определенный подзапрос, вы просто используете уже загруженную информацию из статического свойства: Кэш имеет такое понятие, как время жизни запроса. Если же Вам необходимо иметь постоянную информацию из кэша, тогда, возможно, Вам стоит воспользоваться постоянным Object Cache`ом. Однако в этом случае Ваш код должен сам описывать работу с кэшем.   Отказывайтесь от шаблонного мышления! Помимо этих, существует великое множество других техник по улучшению производительности запросов, которые потребуют операции посложнее, чем просто правка запроса или дописывание индекса. Одна из наиболее медленных операций нашего запроса – это необходимость связывать покупателя с таблицей товаров, причем для каждого покупателя. А что, если просто один раз связать все, что нам нужно, и не заморачиваться этим в дальнейшем, просто загружая из таблицы всю информацию, связанную с покупателем? Мы можем создать таблицу, которая будет содержать в себе информацию о лицензии, вместе с идентификаторами пользователей и товаров для всех лицензий. При необходимости нам нужно будет только дать запрос для одного пользователя. Для этого Вам предстоит пересобрать таблицу при помощи MySQL triggers на базе INSERT/UPDATE/DELETE. Однако подобная операция заметно увеличит производительность системы в целом. Подобным образом, в случае если количество связей замедляет выполнение запросов, возможно, Вам стоит разбить запрос в два или больше предложений и исполнять их раздельно при помощи PHP. После чего просто собрать и отфильтровать полученную информацию внутри кода. Что-то подобное реализовано в Laravel при помощи eager loading в Eloquent. WordPress иногда может замедлять запросы на wp_posts таблице, в случае если у Вас хранится много информации и разных пользовательских пост-типов. Если Вы считаете, что пост-типы замедляют запросы, возможно, Вам стоит задуматься об использовании кастомных таблиц.   Подведем итоги При помощи подобных нехитрых приемов оптимизации запросов нам удалось снизить время работы запроса с 8 до примерно 2 секунд. К тому же было снижено количество вызовов запрос с 4 до 1. Искренне надеемся, что сей гайд будет полезным для работы с запросами. Внешне оптимизация может казаться чем-то устрашающим, но как только Вы попробуете это сделать, Ваши маленькие победы развеют подобные суждения. Автор перевода: Евгений Лукашук Источник

Что нового в Angular 4? Наконец, когда обновленная технология предстала перед нами, мы можем приступить к ее изучению! То, что новый представитель семейства Angular приобрел новый номер, свидетельствует об инновационных изменениях. Но все же встает вопрос: почему Angular 4, а не 3? Все достаточно просто: так как пакет маршрутизатора был уже представлен в версии 3.x, вместо того, чтобы вносить все нововведения в версию 3.0, а маршрутизатор перенести в 4.0, разработчик решил объединить все в версии 4.0. Не стоит волноваться касательно обновления Ваших приложений к новой версии Angular: так как тех самых инновационных изменений в принципе оказалось не слишком много, процесс установки не занял больше нескольких минут. Ничего особо страшного. Среди дополнительных требований стоит упомянуть версию TypeScript 2.1 или выше (раньше требовалась только 1.8+). К тому же некоторые элементы интерфейса были изменены или вовсе упрощены (редко используемые OpaqueTolen или SimpleChange). Плюс, TypeScript 2.1 и 2.2 приобрел целый ряд прекрасных особенностей, которые теперь поддерживаются в Angular 4. К примеру, в скором времени Вы сможете использовать TypeScript-опцию stringNullChecks. Итак, что именно позволяет нам новая версия Angular? Давайте углубимся!   Ahead of Time (AoT) компиляция: обновленный движок представлений Пожалуй, это наиболее значимое изменение, пусть даже Вы, как разработчик, не ощутите разницы. Как Вы, наверно, знаете, в режиме AoT Angular компилирует Ваши шаблоны во время сборки, после чего генерирует JavaScript код (в отличие от режима Just in Time, когда компиляция происходит во время выполнения приложения). Режим AoT обладает целым рядом преимуществ, например, в случае неправильного построения шаблона ошибка возникнет во время сборки, а не во время работы приложения, как раньше. Эта методика позволяет ускорить запуск приложения, так как генерация JS-кода уже произведена. Также Вам не нужно отправлять Angular-компиляторы пользователям, что в теории должно уменьшить размер пакетов. Почему в теории? Потому что, как правило, обратная сторона медали в том, что сгенерированный JavaScript-код обычно больше, чем нескомпилированные HTML-шаблоны. Таким образом, в большинстве приложений с использованием AoT размер пакета де-факто увеличивается. Разработчики Angular хорошо поработали над новым движком представлений, что позволило производить меньше кода при использовании Ahead of Time компиляции. Эффект на больших приложениях не заставил себя ждать. Без падений производительности. Ежели говорить в цифрах, размер пакета стал: С 499 КБ до 187 КБ (или с 68 КБ до 34 КБ после gzip) С 192 КБ до 82 КБ (или с 27 КБ до 16 КБ после gzip) Достаточно большая разница! Интересно отметить, что в своих дизайн-документах команда Angular сравнивает производительность (как в контексте времени выполнения, так и в контексте нагрузки на память) с базовой имплементацией (лучшим «дефолтным» кодом JS, который они только могут написать) Angular 2.x и InfernoJS (быстрая React-подобная имплементация). Универсальность Масса работы была проделана над универсальным проектом, позволяющим производить серверный рендеринг. Когда раньше этот тип проекта поддерживался в основном силами сообщества, теперь, начиная с Angular 4, поддержка приобрела официальный характер. Анимации Анимации теперь обзавелись собственным пакетом @angular/platform-browser/animations (одна из вещей, которая может быть изменена в процессе обновления). Что это значит? Это значит, что Вам больше не нужно нагружать пакеты ненужным кодом, если вы не используете анимации. Шаблоны ng-template вместо template Тэг template устарел. Вместо него используйте ng-template. Хотя и первый вариант все еще работает. Вообще, было немного странно использовать template, так как это реально существующий HTML-тэг. Теперь же Angular обзавелась собственным ng-template. В случае, если вы используете устаревший template, будет выдано соответствующее предупреждение: это в значительной мере упростит обнаружение подобного кода в проектах. Else С новой версией Angular 4 появилась возможность использовать оператор else: <div *ngIf="races.length > 0; else empty"><h2>Races</h2></div> <ng-template #empty><h2>No races.</h2></ng-template> As Еще одно синтаксическое нововведение. Ключевое слово as позволяет упростить синтаксис let. As позволяет хранить результат переменной шаблона для дальнейшего использование в элементе. К примеру, сия особенность может быть достаточно полезной для хранения коллекции: <div *ngFor="let pony of ponies | slice:0:2 as total; index as i">   {{i+1}}/{{total.length}}: {{pony.name}} </div> Или даже более полезной, если один раз использовать pipe с async. Вместо плохого и некрасивого: <div>   <h2>{{ (race | async)?.name }}</h2>   <small>{{ (race | async)?.date }}</small> </div> Вы можете использовать: <div *ngIf="race | async as raceModel">   <h2>{{ raceModel.name }}</h2>   <small>{{ raceModel.date }}</small> </div> Различные виды pipe Titlecase Angular 4 презентует новый pipe: titlecase. Он позволяет переводить первую букву каждого слова в верхний регистр: <p>{{ 'ninja squad' | titlecase }}</p> <!-- will display 'Ninja Squad' --> Http Задание параметров поиска Http-запроса было упрощено: http.get(`${baseUrl}/api/races`, { params: { sort: 'ascending' } }); Раньше вам необходимо было произвести следующее: const params= new URLSearchParams(); params.append('sort', 'ascending'); http.get(`${baseUrl}/api/races`, { search: params }); Test Переопределение шаблона во время теста также было упрощено: TestBed.overrideTemplate(RaceComponent, '<h2>{{race.name}}</h2>'); До этого мы обычно писали так: TestBed.overrideComponent(RaceComponent, {   set: { template: '<h2>{{race.name}}</h2>' } }); Сервисы Meta Для получения содержимого или обновления meta-тэгов был введен новый сервис: @Component({   selector: 'ponyracer-app',   template: `<h1>PonyRacer</h1>` }) export class PonyRacerAppComponent { constructor(meta: Meta) {     meta.addTag({ name: 'author', content: 'Ninja Squad' });   } } Формы Валидаторы Новый валидатор позволит объединить существующие required, minLength, maxLength, и pattern. email позволит провести валидацию e-mail адреса (если Вы планируете просто обойтись подходящими регулярными выражениями – удачи в поисках). Сравнение выбранных опций Для сравнения выбранных опций была добавлена новая директива: compareWith: <select [compareWith]="byId" [(ngModel)]="selectedPony">    <option *ngFor="let pony of race.ponies" [ngValue]="pony">{{pony.name}}</option> </select> byId(p1: PonyModel, p2: PonyModel) {    return p1.id === p2.id; } Маршрутизатор ParamMap Для представления параметров URL был введен новый интерфейс: ParamMap. Вместо использования params или queryParams, отныне Вам стоит использовать paramMap или queryParamMap, так как они позволяют выбрать между get() для получения значения или getAll() для получения всех значений (так как параметры запросов могут иметь несколько значений, к примеру). const id = this.route.snapshot.paramMap.get('ponyId'); this.ponyService.get(id).subscribe(pony => this.pony = pony); Или как здесь:   .map((params: ParamMap) => params.get('ponyId'))   .switchMap(id => this.ponyService.get(id))   .subscribe(pony => this.pony = pony); CanDeactivate Интерфейс CanDeactivate теперь обзавелся дополнительным опциональным параметром, содержащим следующее состояние (то, куда Вы собираетесь перейти). Теперь можно реализовать «умную логику», когда пользователь может покинуть текущий компонент в зависимости от того, куда он или она направляется. I18n Интернационализация также медленно, но верно улучшается. К примеру, ngPlural теперь упрощен: <div [ngPlural]="value">   <ng-template ngPluralCase="0">there is nothing</ng-template>   <ng-template ngPluralCase="1">there is one</ng-template> </div> А теперь давайте сравним с тем, что было раньше: <div [ngPlural]="value">   <ng-template ngPluralCase="=0">there is nothing</ng-template>   <ng-template ngPluralCase="=1">there is one</ng-template> </div> Только что мы добавили целую главу к нашей электронной книге, включая несколько юз-кейсов и прочее! Подведем итоги Релиз Angular 4 привносит множество улучшений и действительно востребованных инноваций в сферы размера генерируемого кода, сохраняя в целом концепцию предыдущей версии Angular. Благодаря этому обновление технологии не должно вызвать затруднений. Автор перевода: Евгений Лукашук Оригинал статьи

SQL Server 2017 – это огромный шаг вперед на пути к платформе, универсальной для многих языков, типов данных, онпремисного софта и облачных хранилищ, доступной как для Linux и Linux Docker-контейнеров, так и для традиционной Windows. В этой статье мы расскажем о ключевых особенностях обновленной технологии и поделимся полезными ссылками на дополнительные материалы. Загрузить новинку вы можете здесь.   Обратите внимание! Помимо приведенных ниже изменений, также были выпущены кумулятивные патчи, которые привносят свои улучшения.   Обновленный движок Движок SQL Server 2017 включает множество новых возможностей, улучшений и оптимизационных алгоритмов. CLR сборки, в качестве аналога функции clr strict security, описанной в CTP 2.0, теперь могут быть спокойно добавлены в вайт-лист. Кроме того, такие Transact-SQL сборки, как sp_add_trusted_assembly, sp_drop_trusted_assembly и sys.trusted_assemblies (RC1), больше не вызывают конфликтов с безопасностью. Восстановление построения индекса возобновляет процесс построения индекса с места предыдущего сбоя (к примеру, по причине недостаточного места на диске и т.д.) или приостанавливает работу и возобновляет ее через определенное время (ALTER INDEX). IDENTITY_CACHE – отличная новинка для ALTER DATABASE SCOPED CONFIGURATION, которая позволяет избежать пропусков между значениями колонок идентификации на случай, если сервер внезапно перезагрузится или произойдет сбой в работе с вторичным сервером. Новое поколение улучшений в механизме обработки запросов, адаптирующих оптимизационные стратегии к вашему приложению прямо во время выполнения (run-time режиме). Первая версия семейства адаптивной обработки запросов содержит три значимых новшества: batch mode, adaptive joins и batch mode memory grant feedback. Кроме того, не стоит также  забывать про последовательное выполнение многооператорных табличных функций. Автоматическая калибровка базы данных позволяет предотвратить вероятные падения производительности запросов, предлагает решения и, помимо прочего, может автоматически исправить обнаруженные неполадки. Новые возможности графов для моделирования множественных связей включают обновленный синтаксис CREATE TABLE, предназначенный для генерации таблиц ячеек и граней. Также в комплекте поставляется новое ключевое слово MATCH для запросов. С целью обеспечения безопасности CLR сборок опция sp_configure под названием clr strict security теперь включена по умолчанию. Появилась возможность устанавливать максимальный размер временных файлов tempdb до 256 ГБ (262,144 МБ) на один файл. Однако если размер превысит 1 ГБ (без IFI), будет выдано соответствующее предупреждение. Колонка modified_extent_page_count в sys.dm_db_file_space_usage отслеживает изменения в каждом файле базы данных, позволяя применять возможности «умного бэк-ап’а».  «Умный бэк-ап» в свою очередь проводит частичный или полный бэк-ап страниц, исходя из процента внесенных изменений. Поддержка возможности кросс-транзакции между базами данных с Always On Availability Group – даже внутри одного и того же представления. Синтаксис T-SQL SELECT INTO теперь поддерживает загрузку страницы прямо в FileGroup при помощи специального слова – ON. Обновленный функционал Availability Groups включает в себя безкластерную поддержку, настройки Minimum Replica Commit Availability Groups и Windows-Linux кроссплатформенные миграции и тестирование. Новые возможности динамического управления: sys.dm_db_log_stats демонстрирует общие уровневые атрибуты и содержимое файлов транзакции, необходимое для мониторинга состояния транзакционного лога. sys.dm_tran_version_store_space_usage отслеживает использование места на диске отдельно для каждой базы данных, что, безусловно, помогает предугадать возможный размер временных файлов. sys.dm_db_log_info позволяет мониторить, оповещать и предотвращать потенциальные ошибки транзакции благодаря обработке VLF-информации. sys.dm_db_stats_histogram - новая опция мониторинга для анализа статистики. sys.dm_os_host_info предоставляет оперативную системную информацию Windows и Linux. Database Tuning Advisor (DTA) – или «советник по калибровке базы данных» – получил целый спектр дополнительных настроек и улучшений производительности. Оптимизация работы с памятью включает в себя поддержку вычисленных колонок в оптимизированных таблицах, полную поддержку JSON-функций и CROSS APPLY оператор. STRING_AGG функция обзавелась таким полезным опционалом, как CONCAT_WS, TRANSLATE, TRIM и WITHIN GROUP. Новые опции bulk-доступа (вроде BULK INSERT и OPENPOWSET(BULK…)) для CVS и блоб-файлов Azure. Оптимизация объектов: внедрение sp_spaceused, отказ от 8-индексных ограничений оптимизированных таблиц, sp_rename для оптимизированных таблиц и органически внедренные T-SQL модули. Помимо прочего стоит указать CASE и TOP (N) WITH TIES для упомянутых выше T-SQL модулей. Теперь хранение, бэк-ап и заливка оптимизированных таблиц на Azure не составит труда. DATABASE SCOPED CREDENTIAL - это новый класс защищенных, поддерживающих CONTROL, ALTER, REFERENCES, TAKE OWNERSHIP и VIEW DEFINITION разрешений. Работа с операциями bulk-администрирования может происходить прямо из sys.fn_builtin_permissions. Добавлен уровень совместимости 140.   Службы интеграции (SSIS) Новая особенность Scale Out может похвалиться следующими инновациями: Scale Out Master теперь стал более доступным для использования. Благодаря усовершенствованию Scale Out Workers подверглась изменению система ведения логов на случай отказа работы сервера. Параметр runincluster процедуры [catalog].[create_execution] для большей совместимости и читабельности был переименован на runinscaleout. Для поддержки выполнения SSIS-пакетов в стандартном режиме SSIS-Каталог обзавелся соответствующими глобальными свойствами. Благодаря новой особенности Scale Out для SSIS, Вы можете легко использовать Use32BitRuntime во время работы приложения. Сервисы интеграции SQL Server 2017 теперь поддерживают SQL Server и для Linux. Новый программный пакет позволит Вам работать с SSIS прямо из командной строки. Помимо прочего, Scale Out for SSIS значительно упрощает запуск SSIS-пакетов на нескольких машинах. Отдельно стоит упомянуть об OData Source и OData Connection Manager, обеспечивающих подключение к Microsoft Dynamics AX Online and Microsoft Dynamics CRM Online.   Обновление служб Master Data Значительное улучшение и повышение производительности в сравнении с предыдущими версиями. Хотите просмотреть список сборок, коллекций и иерархий веб-приложения? Что может быть проще! Новая страница Explorer легко позволит Вам это. Благодаря использованию специальных процедур хранения данных внесение записей стало значительно более оптимизированным. Улучшение производительности во время развертывания папки Entities в Manage Groups, так как страница Manage Groups перемещена в секцию Security.   Обновленные службы анализа (SSAS) Сервисы анализа (в дальнейшем – SSAS) SQL Server 2017 представляют множество новых возможностей и улучшений для табличных моделей. А именно: Табличный режим в качестве опции по умолчанию. Объектная защита метадаты табличных моделей. Взаимозависимость данных для упрощения создания зависимостей полей. Внедрение нового ресурса Get Data и поддержка М-запросов для существующего DirectQuery. DAX Editor для SSDT. Кодировка подсказок для оптимизации обновления данных таблиц в памяти. Поддержка таблицами уровня совместимости 1400. Если Вы желаете создать новые или обновить существующие таблицы к уровню совместимости 1400, загрузите и установите SQL Server Data Tools (SSDT) 17.0 RC2. Поддержка Get Data нового уровня совместимости 1400, упомянутого выше. Новое свойство Hide Members позволит Вам скрыть пустые сущности поврежденных иерархий. Новые действия – Detail Rows и Show Details – для совокупной информации. Внедрение функций SELECTCOLUMNS и DETAILROWS для создания Detail Rows – выражений. Оператор DAX IN для задания множественных значений.   Обновленные службы отчетности В новой версии SQL Server 2017 службы отчетности не поставляются по умолчанию. Загрузить их Вы можете здесь. Для повышения уровня читабельности кода и упрощения командной разработки была внедрена поддержка комментариев. Также Вы можете прикреплять к ним дополнительные файлы. Используя последнюю версию Report Builder и SQL Server Data Tools, Вы можете создавать нативные DAX-запросы – в противовес таблицам служб анализа. Все, что Вам для этого нужно – лишь переместить желаемые поля в дизайнер запросов. Благодаря поддержке интуитивного RESTful API, используя последнюю версию SQL-инструментария, Вы без труда сможете разрабатывать современные приложения и проводить их последующую кастомизацию.   Машинное обучение В новой версии приложения R-службы сменили название на Службы Машинного Обучения SQL Server (SQL Server Machine Learning Services), что подчеркивает поддержку как языка R, так и набирающего популярность Python. Благодаря этому работа с такими языками не составит труда. Впрочем, можно обойтись и без SQL Server: упомянутые Службы Машинного Обучения не требуют его наличия на ПК. С этими значительными новшествами разработчики SQL получили колоссальное преимущество в виде отменных библиотек Python ML и AI, которые, помимо прочего, могут похвастаться открытым исходным кодом. Итак, что же мы имеем? Revoscalepy – Python`овский эквивалент RevoScaleR. Включает в себя параллельные алгоритмы линейных и логистических регрессий, дерево решений, усиленные деревья и рандомные леса. Также стоит упомянуть богатый набор API, крайне полезных при обработке и манипуляции данными, удаленными вычислениями и информационными ресурсами. Microsoftml – воистину настоящее произведение искусства в сфере алгоритмов машинного обучения. Включает в себя проработанные нейронные сети, быстрые деревья решений и леса и, конечно же, оптимизированные алгоритмы линейных и логистических регрессий. В Вашем распоряжении также оказываются заготовки на базе моделей ResNet, весьма удобные, когда речь заходит об извлечении картинок или их анализа. Взаимодействие Python с T-SQL – что может быть проще? Все, что Вам нужно – это лишь задеплоить Python-код при помощи процедуры sp_execute_external_script! Ощутите настоящую скорость передачи данных между SQL и Python-процессами. Свободно используйте MPI кольцевую параллелизацию. Нативное оценивание – даже если язык R не установлен, благодаря функции Predict Transact-SQL можно легко провести оценивание в любой сущности SQL Server 2017. Все, что Вам необходимо, – это настроить модель, используя один из алгоритмов RevoScaleR или revoscalepy, сохранив модель в новом компактном бинарном формате. Управление пакетами – обновленный T-SQL обладает поддержкой команды CREATE EXTERNAL LIBRARY, что упрощает работу с R-пакетами. Контролируйте приватность пакетов, устанавливайте доступ, сохраняйте их и делитесь с другими пользователями. Улучшения производительности – благодаря оптимизации процедуры sp_execute_external_script была включена поддержка batch-режима для информации в столбцах. Автор перевода: Евгений Лукашук Источник

Автор статьи: Влад Кобылянский, архитектор программного обеспечения, разработчик и консультант по технологиям малого бизнеса (Майами, Флорида).   Вопрос: Что сегодня происходит с PHP фреймворками? В феврале 2017 года я так ответил на этот вопрос: «В основном все крутится вокруг двух PHP фреймворков -  Laravel и Symfony. Особой нужны в использовании CakePHP, Zend, CodeIgniter, Yii и т. д. нет, если вы начинаете новый проект. Только если вы уже знаете эти фрэймворки или у вас в команде есть разработчики которые привыкли работать с ними, тогда причины их использования обоснованы. Когда начинается реальная разработка, вы должны иметь возможность находить инструменты, плагины, ответы на общие проблемы. С сообществами Laravel и Symfony, с постоянным развитием новых «модулей» или функций, не будет ощущения, что вы остались «в стороне». Одни Laracast (даже если вы не работаете в Laravel) чего стоят! Они просто фантастичны. Когда заходит речь об интеграции с iron.io или другими SaaS сервисами, поддержке широкого спектра источников данных или о среде разработки – Laravel и Symfony и их расширения намного более продвинуты. Еще одним достоинством  Lumen, является быстрая разработка и прототипирование API для Laravel. При этом это никак не ограниченно для построения больших приложений.Вообще говоря, сегодня мы определенно видим переход к контейнерной архитектуре, где MVC играет гораздо меньшую роль. Все это касается микросервисов, оркестровки и создания приложений как «функций» (AWS Lambda и подобных сервисов). Возможно, пришло время освежить наши навыки Node/JS и GoLang?»   Хотя я в целом доволен этим ответом, сейчас я думаю, что некоторые моменты пришло время пересмотреть. Прежде чем перейти к таким странным темам, как GoLang, давайте взглянем на тенденции PHP MVC фреймворков. Я бы сказал, что тенденции, которые мы наблюдали в прошлом, остаются. Laravel продвигается вперед, в то время как большинство остальных фреймворков отстает. В популярности Symfony наблюдается небольшой всплеск, вероятно, из-за долгожданного выпуска Symfony 3. Я попробовал более конкретные поиски для сравнения, такие как «CakePHP 3» или «ZF2», однако они не привели к статистически значимым тенденциям. На этот раз я добавил CodeIgniter, потому что он оказалася очень популярным. Я получил ряд вопросов о CodeIgniter. Если коротко, CI сейчас не в конкуренции, потому что это не 100% фреймворк MVC. Иначе, чем организованной коллекцией POPO, я это не назову. Для наглядности представляю вам цитату из руководства CodeIgniter: «CodeIgniter имеет довольно свободный подход к MVC, поскольку не требуются Models. Если вам не нужно дополнительное разделение или вы обнаружите, что поддерживающие Models требуют большей сложности, чем вы хотите, вы можете их проигнорировать и создать свое приложение с помощью Controllers и Views.» Когда дело доходит до построения структуры, я просто не согласен с таким подходом. Возможно, это достойный шаблон (отсюда и популярность CodeIgniter), однако должна быть какая-то дисциплина, навязанная фреймворком, иначе конечный продукт в итоге превращается в беспорядочный спагетти-код, завернутый в какой-то «шаблон». Далее, Symfony 3 привнес некоторые достойные улучшения в разработку и целый ряд новых «фич». Как и многие аналоги PHP, теперь он предлагает микро-фреймворк. ZF3, к примеру, добавил ряд улучшений, таких как поддержка PHP7 (наконец!) и даже стал микро-фреймворком... но, в их руководстве так и говорится: «Для пользователей Zend Framework 2 MVC, различия с ZF3 незначительны...» Я действительно надеялся, что они скажут, что различия есть, что было замечательное архитектурное усовершенствование, замечательные новые модули, которые помогают вам разрабатывать все по-современному. Но, увы, по большей части ZF3 по-прежнему похож на ZF2. Long Story Short Вот как я вижу мир PHP фреймворков сегодня: Symfony или Laravel (выбор зависит от того, какую задачу вам нужно решить) Все остальное Laravel на первом месте. Объем доступной информации, Laracasts, таланты разработчиков во всем мире, простые реализации шаблонов, интегрированные наборы инструментов тестирования, активная реализация записей в форме Eloquent, облегченная версия в Lumen, развитие Homestead (Vagrant) – все перечисленное способствует фреймворку действительно выделяться и для новых, и для опытных разработчиков. Однако модели Eloquent могут стать непослушными и довольно большими по размеру, а сервисов Laravel (не путать с микросервисами) можно создать очень много, и вот тут люди начинают думать о реализации Repository, которому здесь не место. Так родился Monolith. Если вам не нравится активный шаблон записи и вам нужна дополнительная гибкость в репозиториях, или, возможно, вы видите слишком много независимых анонимных функций, тогда используйте Symfony + Doctrine. Рассматриваю ли я Symfony как шлюз для монолитных приложений? В какой-то степени, да. В целом, я бы не назвал это резким изменением с прошлого года. Тем не менее, нам нужно взглянуть на общую картину: правильно разработанное приложение выходит за рамки чистого MVC; речь идет об инфраструктуре, конвейере развертывания, разъединённой архитектуре. Все это может быть достигнуто в стеке MVC, но нужно быть внимательным, чтобы избежать Monolith. Приход микросервисов Раньше я упоминал о распространенности микросервисов и необходимости улучшать навыки GoLang или Node. А в статье о PHP MVC было бы глупо не упомянуть о явно растущем движении к микросервис-ориентированной архитектуре (MOA); и это движение набирает обороты, поверите вы или нет. Хотя эти два понятия не являются взаимоисключающими, не нужно находить параллели между ними, ведь они действительно представляют собой разные философии. В качестве примера, размещение вашего приложения MVC в одном контейнере и MySQL в другом, а затем объединение их вместе, не обязательно представляет собой надлежащую MOA. Это, безусловно, лучший подход, чем пытаться установить MAMP, XAMPP или что-либо еще, чтобы заставить ваш компьютер работать с приложением. Кроме того, это может решить некоторые проблемы, такие как простота запуска локальной среды на разных платформах и, возможно, в некоторых случаях стратегии развертывания, но вы застрянете с монолитным MVC в вашем приложении/контейнере. Уничтожение Monolith Микросервисы – это как раз о «разрушении». В то время как MVC обращается к вашей структуре кода и организации, обеспечивая надежный подход к разделению проблем, эта концепция еще больше расширяется контейнерами/сервисами/MOA. Вместо того, чтобы просто отделять виды (Views) от моделей (Models), вы теперь разделяете каждый «кусок» или логическую единицу вашего приложения на индивидуальную службу, предназначенную для правильной работы с собственными обязанностями. Если у вашего MVC-приложения есть контроллер «Поиск», действия и соответствующие методы модели, то у нас уже есть пример монолитного приложения. Напротив, используя подход MOA, у нас будет сервис для каждого из этих процессов. В качестве примера: Router сервис Request сервис Query сервис DataSource сервис Response сервис Но не все эти «сервисы» являются частью стека MVC? Конечно нет. Они являются строительными блоками нашего Monolith. С MOA каждый сервис работает в рамках собственной среды, а мы, как архитекторы, можем разработать лучший подход к решению конкретного запроса. В качестве примера, если я должен был бы написать службу обработки изображений в среде Laravel, я использовал бы что-то вроде расширения PHP-GD2, что может быть не самым эффективным способом обработки изображений. Служба C++, которая обрабатывает мои запросы в обработке изображений, может быть намного быстрее и определенно более надежной при масштабировании. И мы могли бы сделать вывод службы обработки изображений и отправить ее в службу DataStore, службу CloudStorage и службу Queue Email. Решение этой же задачи с кучей скрытых заданий и, возможно, нескольких отдельных приложений MVC и пользовательских сценариев – это то, как разработчики делали это раньше (2 года назад). Время двигаться вперед. Масштабируемость Здесь возникают проблемы (или заканчиваются, в зависимости от того, куда вы держите курс). С одной стороны, очень сложно масштабировать Monolith: если вы создадите все больше и больше логики в одном и том же наборе MVC, вы застрянете с хорошо структурированным приложением ужасной сложности. С другой стороны, если вы построите тысячу микросервисов на разных языках, как вы будете управлять этим беспорядком? Существуют различные инструменты компоновки контейнеров (например, Kubernetes, Swarm, Mesos), услуги по развертыванию контейнеров (GKE и AWS ECS), однако лишь немногие предприятия используют архитектуру Docker. Есть удачные истории в построении инфраструктуры с использованием Docker или других контейнерных технологий (т. е. GKE). Большинство из этих историй исходят от компаний, которые могут позволить себе тратить ресурсы на архитекторов, дефолтов, администраторов баз данных и инженеров. Тем не менее, сейчас идут бесчисленные дискуссии о том, как развернуть хорошо организованный и элегантный MOA. В любом случае, вы не решите эту проблему самостоятельно, и пока вы не достигнете относительно большого масштаба, эта проблема действительно нуждается в решении. Может быть, сейчас не самое время усердствовать. Золотая середина на сегодняшний день (даже для тех, кто занимается приложениями меньшей сложности или не такими требованиями к трафику) заключается в том, чтобы разгрузить многие типичные сервисы сторонним провайдерам. Почти все доступно сейчас как сервис. Фоновые задания, обработка изображений, аутентификация, аналитика данных, ведение журнала, отправка электронной почты, системы очереди не обязательно должны строиться в одном стеке MVC, а архитектор должен подумать о том, что может быть выгружено в систему SaaS за небольшую ежемесячную стоимость (т.е. поиск Algolia) или, возможно, специально созданную докерную службу, работающую в облачном пространстве, которая выполняет эту обработку изображений. Я думаю, важно, чтобы вы не начали перепроектировать весь проект с начала, не сбрасывать все, что у вас уже есть, а выпускать докеры, где это можно сделать. Существуют способы постепенного развертывания вашего проекта/продукта путем разъединения, изучения узких мест в системе (и т.д.) и последующим применением разделения проблем в этих проблемных областях. Вывод 2017 год принес нам много дискуссий и производственных развертываний, основанных на контейнерах и MOA. Мои размышления о Docker, используя GoLang или Node, не означают, что PHP «умирает» или что-то в этом роде ... Я считаю, что разработчикам нужно оставаться в тренде. Если микросервисы и дальше будут развиваться в том же русле, в котором это происходит сейчас, то почему бы не изучить GoLang? Он идеально подходит (из-за низкой занимаемой площади, скорости и параллельной обработки) для разработки небольших контейнерных приложений. Node и GoLang позволяют создавать небольшие сервисы, которые являются частью более крупного проекта, связывают созданные сервисы и выпускают их как контейнеры Docker, если это необходимо в вашей работе. Тем не менее, все эти передовые решения и языки не уменьшают значимость и востребованность языка PHP. Разработчикам еще нужны будут стеки MVC и работа с  API. MOA пока не помогает решить архитектурные проблемы на стороне frontend, UI или Views, хотя при этом контейнеры помогают нам избежать работы с Monolith на backend. Мы можем создать чрезвычайно надежное backend-приложение, но оно среагирует на JSON, который каким-то образом должен быть представлен в клиентском приложении. Имеет ли значение, если результирующий объект ответа поступает из РНР кода, URL или от модулей принятия решений и обработки, разделенных интерфейсом обмена сообщениями? Это зависит от Ваших потребностей и требований к вашему приложению. Мой совет: в этом году учите Laravel, следите за Docker, GoLang и фокусируйтесь на конвейере развертывания. Продвижение от локального небольшого проекта к продакшену должно быть достаточно плавным, особенно при создании приложений MVC.   Оригинал статьи

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   Заключение Принять культуру тестирования кода сложно, но она понемногу развивается с практикой. Если вы заботитесь о своем коде, вы должны его протестировать! Перечисленные в этой статье инструменты и ресурсы помогут вам разобраться и начать работу.   Оригинальная статья на английском языке

Верстальщик сайтов – это специалист, который занимается созданием веб-страниц. Его работа заключается в том, чтобы при помощи различных элементов языка разметки веб-страницы перевести графические элементы дизайна (рисунки, шрифты, таблицы и т.д.) в понятный для браузера формат, то есть сверстать сайт. Работа верстальщика не очень сложная, но требует определенного уровня подготовки и большого внимания к деталям. На хороших специалистов практически постоянно существует большой спрос. На ITVDN все, кто заинтересован в изучении технологий для верстки веб-страницы, найдут необходимые видео уроки и материалы. А также курсы для «прокачки» практических навыков верстки сайта и Тренажер для навыков написания кода. Курсы записаны сертифицированными разработчикам и тренерами Microsoft. ITVDN рекомендует проходить обучение в такой последовательности:    HTML & CSS, автор Александр Петрик How to HTML & CSS, автор Сергей Раздобудько Photoshop. Базовый курс для web-разработчика, автор Сергей Воропаев JavaScript Essential, автор Дмитрий Охрименко How to JavaScript, автор Валерия Прокопенко Основы использования Git, автор Александр Пономаренко Twitter Bootstrap 3, автор Сергей Швайцер Создание адаптивного сайта с Bootstrap 3, автор Александр Пономаренко WordPress Starter, автор Артем Кондранин Практический курс по верстке лендинга, автор Сергей Рубец HTML5 & CSS3, автор Дмитрий Охрименко Также вас могут заинтересовать записи вебинаров ITVDN (все в свободном доступе): Верстаем сайт правильно Photoshop: зачем он нужен веб-разработчику? WordPress: создаем блог за час Скоростная верстка, или как упростить себе жизнь с Bootstrap 3 Интеграция верстки лендинга на CMS WordPress Адаптивный веб-дизайн: типы адаптивных макетов Семантика HTML5, создаем змейку, используя canvas Что надо знать для веб разработки. (реальная разработка + обзор вакансий) Создание веб-приложения с Angular 1.5, Firebase и Gulp Как решить проблемы верстки с помощью HTML5 Web Components Если вы планируете свое обучение с нуля, тогда наилучшим решением будет приобретение подписки ITVDN сроком от 3 месяцев. Это оптимальный срок, за который вы сможете научиться создавать красивые сайты, мастерски владея современным инструментарием  верстальщика.

Универсальная платформа 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