Я работал с .NET-платформой на протяжении 5 лет – как в плане профессиональной необходимости в качестве бек-енд разработчика и архитектора, так и в плане определенных личных задач - таких как открытые и закрытые сторонние проекты. После нескольких лет работы с экосистемой PHP и имея солидный стаж в плане Java, я пришел к выводу, что язык C# для меня представляет, пожалуй, наибольший интерес – благодаря своему удобству и эффективности. Этот язык комплексный, тщательно продуманный и лично для меня в работе с C# лучшую среду программирования, нежели Visual Studio, человечество еще не изобрело. Более того, ASP.NET уже содержит в себе все, что необходимо веб-разработчику, не требуя установки дополнительных фрейморков и библиотек. Единственное, что меня не очень устраивало в плане .NET-системы, это ее «закрытость» и использование преимущественно Microsoft-платформы (хотя и существуют специальные Mono, которые позволяют в качестве альтернативы запускать шарп-проекты и под Linux, но достигается это ценой утраты целого ряда полезных фичей). По этой причине я обратил свое внимание на Node.JS, хотя мои коллеги называли JavaScript бесполезным языком, а Node.JS – хламом. Я был очарован однопоточной каллбэк-системой, я наслаждался, создавая REST API, используя ExpressJS. Но затем Microsoft выпустила кроссплатформенную технологию ASP.NET Core, и я призадумался, что же и когда стоит использовать. После чего я решил собрать как можно больше информации касательно возможностей и реализации тех или иных фичей двух технологий, после чего выбрал для себя, по моему мнению, наиболее удобную технологию, в рамках которой и развернул свой новый проект. Надеюсь, эта публикация вам тоже поможет прийти к определенному решению. Модель обработки запроса Node.JS Node.JS успел зарекомендовать себя как однопоточный обработчик запросов. Что это значит? Это значит, что вместо обработки каждого поступившего http-запроса внутри отдельного потока или процесса (наподобие Apache), обработка производится внутри одного потока. Подобный подход делает обработку запросов однопоточной, тогда как в Apachi\PHP обработка является многопоточной. Однако, что касательно Node.JS, здесь преимущество заключается в асинхронной работе системного ввода-вывода, которое, соответственно, не блокирует требуемый поток. Операция ввода\вывода производится в рамках отдельного потока, в то время как основной продолжает свою работу. Как только вторичный поток завершает свою работу, вызывается callback, который, соответственно, передает в контекст основного потока результат. С одной стороны, использование подобного подхода прекрасно подходит для приложений, интенсивно работающих с вводом\выводом. С другой стороны, появляется вероятность так называемого «ада обратных вызовов», который провялятся в цикличной сложности кода. Будем надеяться, что новая версия введёт в обиход полноценные async\await. Однопоточная модель обработки запросов Node.JS может быть сгруппирована при помощи использования нативной кластеризации, Nginx или PM2. ASP.NET (синхронный) Исторически так сложилось, что обработка запросов ASP.NET MVC (или Web Api) производится подобно Apache / PHP: каждый запрос обрабатывается внутри своего собственного потока пула потоков. И каждая команда ввода-вывода производится синхронно внутри каждого из потоков. В контексте жесткой работы с вводом-выводом подобный подход, конечно, менее удобный, если сравнивать со схемой Node.JS. Хвала Небесам, .NET Framework 4.5 вводит в C# async\await, что также исправляет сложившуюся ситуацию. ASP.NET Core (асинхронный) Паттерн async\await позволяет в полной мере ощутить все прелести асинхронного программирования. Действительно, теперь появилась возможность указать каждый обработчик запросов как асинхронный, благодаря чему работа с системой ввода-вывода будет производиться в контексте своего потока. Это позволит не блокировать основной поток. Подобная модель на базе Task`ов позволяет использовать обратные вызовы, ощутить все прелести асинхронности и прочее. .NET Core часто применяет паттерн async\await при интенсивной работе с системой ввода-вывода.   Async\await Node.JS VS Async\await ASP.NET Core Пример кода Node.JS для асинхронного запроса в базу данных: Пример того же кода на ASP.NET Core (фрагмент класса Startup):   Разница между двумя моделями в том, что ASP.NET Core способен обрабатывать большее количество запросов благодаря своей дефолтной параллельности. В то же время переключение между асинхронными потоками может занимать время в случае использования большого количества общих для многих потоков переменных. В такой ситуации все же Node.JS будет быстрее.   Много современных языков программирования, вроде того же C#, реализуют асинхронный ввод-вывод, который часто недооценен сообществом Node.JS-разработчиков, но который может приводить к приятным неожиданностям. В этом случае Node.JS в значительно меньшей мере технологичный, если сравнивать его с ASP.NET Core. Язык программирования Особенности и безопасность Вращаться в среде C#-разработчиков – значит выслушать множество критики в адрес динамической типизации и удивительных булевых преобразований JavaScript. Впрочем, эта критика является обоснованной, если учитывать, что JavaScript был разработан всего за 10 дней для динамического контента HTML.   С другой стороны, с того времени язык очень даже «вырос», и новая спецификация привносит такие фичи, как: Классы Новые идентификаторы (const, let), повышающие надежность кода Указательные функции Интерполяцию строк Генераторы Элементы рефлексии Впрочем, C# все равно остается намного более мощным языком программирования, ибо все вышеперечисленное – всего лишь небольшая часть того, чем может похвастаться строго-типизированный объектно-ориентированный язык программирования. Мне кажется, что для C# лучшей среды работы, нежели Visual Studio, просто не найти. Однако, если учитывать рост спроса на рынок микросервисов, большинство из особенностей подобных гигантов здесь не найдут свое применение. Изучение Если вы раньше работали с классической MVC-архитектурой, переход на Node.JS \ Express затребует некоторое время, чтобы привыкнуть. Некоторые же вещи могут вообще оказаться в новинку. Также нужно будет время для того, чтобы «переварить» событийно-ориентированную парадигму Node.JS. Что действительно может показаться запутанным впервые при работе со средними или большими приложениями, так это паттерны рефакторинга кода и, собственно говоря, архитектура кода. Так как функциональность Express.js очень гибкая, выбор «правильной» архитектуры и файловой структуры может быть затруднительным. С другой стороны, для создания качественного приложения без этого – никак. Что же касается ASP.NET (Core) MVC / WebApi, то тут уже предоставляется готовая файловая структура. Да, разработчик может применить немного «креативности» при создании бизнес-логики и слоя для работы с базой, но предопределенность архитектуры упрощает разработку. Однако, в случае с маленькими приложениями, JS-платформа более предпочтительна, так как позволяет написать сайт-визитку с использованием одного лишь js-файла и одного лишь package.json. Продуктивность Я обнаружил, что написание простого кода является более быстрым при использовании Node.JS. Причина в том, что простые приложения тут проявляют большую «гибкость». Также возникают вопросы касательно типизации языка, так как в некоторых случаях оказывается, что динамическая типизация является скорее плюсом, чем минусом. С другой стороны, я заметил, что при написании объемного кода, более читабельным он оказывается при работе с C#, чем с JavaScript. Думаю, причина этому – строгие ооп-парадигмы. Что касается отладки и юнит-тестирования, тут C# / Visual Studio также показывают лучшую продуктивность, хотя и сказать, что JavaScript совместно с Visual Studio Code пасет задних, нельзя. Время построения маленьких js-приложений также меньше. Екосистема В этом плане две технологии отличаются больше всего. Node.JS обязана своим развитием в основном сообществу, которое и разработало для неё большее количество существующих популярных библиотек. С одной стороны, вы чувствуете себя очень свободно в выборе модулей для разработки. С другой же, внезапное обновление одного из пакетов, отсутствие надлежащей проверки на ошибки и стабильность, в некоторых случаях могут легко привести к обвалу всего приложения. ASP.NET Core технология разработана проверенной командой профессионалов из Microsoft. И она предоставляет абсолютно все, что необходимо разработчику веб-приложений любых направлений. Кроме того, сторонние библиотеки также качественно выполнены и разработаны другими крупными проверенными компаниями. Один из многочисленных примеров – ORM-инструменты. Entity Framework, официальный инструментарий для работы с базой данных, предоставляет абсолютно все, что необходимо разработчику. Публикация и запуск А вот это та область, где Node.JS, без сомнения, лидирует. Технология является открытой, кросс-платформенной, поддерживает докеризацию. Это значит, что вы запросто сможете запустить свое приложение под такими платформами: На собственном Linux, Windows или Mac-сервере. Все, что для этого нужно – это движок Node.JS и реверсивный прокси-сервер (наиболее популярный – Nginx). Докер-контейнер. Большинство PaaS-провайдеров (AWS, Google App Engine, Azure, Heroku, …) Сервис Now, который позволяет провести запуск Node.JS-приложения в одну строчку без предварительной конфигурации. Также есть много подходящих CI & CD – платформ. Что же в случае ASP.NET-стека, тут все обстоит несколько печальнее. Хотя и ASP.NET Core также кросс-платформенная, количество сервисов для публикации несоизмеримо меньшее. Вот какие хостинги я знаю на данный момент: Собственный Windows-сервер с классическим IIS. Собственный Linux-сервер с реверсивным прокси. Докер-контейнер под Windows. Работает отлично, но занимает много места. Некоторые облачные сервисы PaaS. В основном, Azure, но есть также некоторые неофициальные билды Heroku. Заключение Node.JS обладает асинхронной событийно-ориентированной моделью обработки запросов, которая не очень то и уступает многопоточной async\await модели ASP.NET. Производительность Node.JS – приложений не всегда лучше, чем ASP.NET Core. Можно сказать, она даже хуже. Язык JavaScript не так уж и плох (и становится лучше!). А использование его вместе с Node.JS может дать приятный результат. ASP.NET (Core) лучше всего подходит для объемных приложений и предоставляет все необходимые разработчику инструменты высшего качества. Для микро- или среднеразмерных сервисов Node.JS предоставляет широкие возможности в плане публикации. И, как всегда, не существует одного лучшего инструмента «на все случаи жизни». Попробуйте доступные и подберите для себя тот, который лучше всего отвечает вашим требованиям. Автор перевода: Евгений Лукашук Источник

Прошло много времени с момента релиза ASP.NET Core 1.0. Затем появились версии 1.1, 2.0… В общем и целом серверные компоненты и технология оказались достаточно качественными, в них было замечено всего лишь несколько багов. Кроме того, начиная с вышеупомянутой версии 1.1, было добавлено бессчётное множество различных полезных примочек к Entity Framework Core и самой ASP.NET Core. Помимо прочего, стоит также отметить радикальные отличия в структуре проектов, которые могут показаться слегка непривычными, но являются жизненно необходимыми для взаимодействия проектов .Net Core с другими типами проектов. Но ожиданиям качественного инструмента пришел конец. Произошел релиз Visual Studio 2017, и она успела зарекомендовать себя как достаточно стабильная версия. К тому же я без проблем сумел перенести мои проекты на базе project.json в новый формат файлов MSBuild без всяких проблем. Помимо прочего, стоит также отметить целую серию приятных улучшений стандартной среды языка .NET. Мы долго ждали и дождались – наконец-то стандарт .NET Core (вместе с технологией ASP.NET Core) успешно захватывает IT-рынок и обладает целым рядом полезных инструментов для разработки. Если вы из компании, которая от стольких лет ожидания успела натереть себе мозоль – определенно, вам есть чему радоваться. Итак, ASP.NET Core сейчас уже на полках. Так в каких случаях нам стоит забыть про старый добрый ASP.NET и опробовать его кроссплатформенную версию? Позволю себе поделиться мнением. Новые проекты Если вы начинаете разработку нового проекта с использованием MVC-подхода и/или Web API, вам определенно нужно обратить свое внимание на ASP.NET Core. Технология содержит в себе целую серию значительных улучшений, которые заметно отличают ее от предшественницы. Помимо прочего, она также может похвастаться первоклассной системой внедрения зависимостей. ASP.NET Core также обладает специальными tag-helper`ами. Используя сервис TestServer, вы запросто сумеете производить локальные тесты прямо на свое ПК (забудьте про падения через неверную конфигурация фаервола). Web API теперь внедрены в ASP.NET Core MVC, потому теперь нет никакой необходимости использовать сторонние библиотеки с кучей дублирующих компонентов. Также скорость работы значительно выше, плюс, помимо прочего, арсенал может похвастаться значительно большим количеством опций, нежели MVC5/WebAPI2, который в значительной мере привязан к IIS. Но что, если проект имеет среди зависимостей сторонние библиотеки (собственные или чьи-то еще), которые требуют полноценной среды .NET Framework, не включенной в .NET Core? Нет никаких проблем. При желании в ASP.NET Core можно включить полноценный .NET Framework. Желаете использовать ваш Entity Framework 6 или NHibernate для работы с данными? Да ради Бога. Все прекрасно будет работать и в ASP.NET Core. Единственное, что вы от этого утратите – это кроссплатформенность, ибо эти сервисы могут быть запущены только в рамках Windows-сервера. У меня нет времени переучивать команду на ASP.NET Core! На счастье, переход на новую платформу не займет много времени, если ваша команда уже знакома с ASP.NET MVC и/или Web API. Концепция Core – использовать все, что было раньше, но значительно лучше. Контроллеры и представления никуда не делись. Представления все еще используют Razor. Маршрутизация по сути своей осталась прежней – она даже стала немного проще. Фильтры также особо не изменились, а Web API добавили своего удобства в использовании (так как они были интегрированы в MVC). Конечно, отличия все же есть, но это не критично. Несколько новых вещей, вроде того, как запускается приложение или как работает middleware, выучить придется, но в целом опыт работы на предыдущей ASP.NET Core MVC тут будет решать очень многое. Я хочу поместить приложение в контейнер на Linux! Тогда вы можете желать только ASP.NET Core. Вы не сможете использовать библиотеки из среды .NET Framework, но что касательно стандартных компонентов .NET Core – полный вперед. И да, вы также можете помещать свои приложения под Azure на Linux. Судьба приложений на ASP.NET MVC 5 и/или Web API 2 Предугадать тут что-либо конкретное будет несколько затруднительно. Если эти приложения работают и запускаются без проблем, не думаю, что необходимость переходить под ASP.NET Core такая уж  срочная. Однако, несколько причин, по которым  стоит интегрировать подобные программы под ASP.NET Core, все же есть: Сама поддержка. Если вы бы хотели деплоить приложение и его сервер вместе, без привязки к IIS – Core, – это однозначно ваш выбор. Поддержка различных платформ. Порой использование Windows-ориентированных серверов может быть дороже прочих других. Возможно, вы могли слышать об поддержке контейнеров, Докера и так далее. Core все это поддерживает – причем на очень даже приличном уровне. Множественные приложения. Приходилось ли вам запускать несколько экземпляров приложения на одной и той же машине? ASP.NET Core позволит это делать значительно удобнее и эффективнее, нежели традиционный ASP.NET. Тестирование и Domain-Driven Design (DDD). Если ваша команда следует этому подходу, пишет тестируемое программное обеспечение, то ASP.NET Core (и Entity Framework Core) привнесёт целый ряд полезных фич, которые значительно могут упростить жизнь. Программы Web Forms         Если ваше приложение базируется на веб-формах, возможно, вам лучше всего будет оставаться на ASP.NET. Microsoft активно инвестирует в эту технологию. Существует множество способов улучшить качество кода, используя внедрение зависимостей и прочее. Но смена платформы на ASP.NET Core MVC будет такой же «болезненной», как и переход на ASP.NET MVC 5,4,3,2,1. Что хуже, используя MVC 5, вы можете запускать страницы отдельно друг от друга, но проделать подобное с ASP.NET Core не представляется возможным. Лично я могу посоветовать оставаться на веб-формах до тех пор, пока приложение не потребует полноценной замены. В плане нагрузки на данные, потребовалось бы применить стиль SPA-приложений со значительно большим количеством клиентского кода и фрейморков типа Angular 2, или React. Другие размышления Хотя Visual Studio – прекрасный инструмент для разработки приложений, эта среда не бесплатная (за исключением комьнити-версии). Помимо прочего, она Windows-ориентированная (да, есть VS для MacOS, но это совершенно другое приложение). Если же студия для вас по причине цены или размеров неприемлема, .NET Core будет воистину полезным приобретением. Вы можете на MacOS, Linux (и, разумеется, под Windows) работать в Visual Studio Code! Подобным образом, если ваши приложения больше ориентированы на клиентскую часть, ASP.NET Core порадует более облегченными размерами. В то время, как фронтендеры превозносят NodeJS как быструю технологию (и ее возможность исполнять js-код на сервере), ASP.NET Core может также исполнять Node.JS на сервере (и вы также можете работать под JS на сервере, если вам захочется). Используя TechEmpower, ASP.NET Core, развернутый с использованием Kestrel, может обрабатывать до 1 миллиона запросов за секунду на том же ПК и в рамках того же приложения, в то время, как NodeJS обрабатывает всего около 175 тысяч в секунду. Подведем итоги Безусловно, ваш опыт и ваше мнение может сильно отличаться от моего, потому вопрос о том, стоит ли переходить на ASP.NET Core для некоторых может остаться открытым. И, конечно, ASP.NET Core далеко не единственная технология, используя которую вы будете создавать свое следующее веб-приложение. Однако, тема этой статьи как раз-таки ASP.NET Core, с которым мне приходилось долго проработать. К тому же, написано очень много официальной документации на официальном сайте Microsoft. Я не советую переходить на ASP.NET Core лишь потому, что он такой новый и весь из себя красивый. Решение перейти должно быть тщательно взвешенным и подкрепленным весомыми аргументами, которые я постарался привести в своей статье. Что дальше? Разработка ASP.NET Core продолжается. Уверен, версия 2.0 – далеко не последняя! Было бы неплохо взглянуть на обновленный SignalR и новую функциональность разор-страниц. Автор перевода: Евгений Лукашук Оригинал статьи

Добро пожаловать в наш небольшой сборник советов от ведущих разработчиков на платформе Node.JS! Цель сей статьи – обобщить все те знания, которые были в свое время опубликованы в различных обучающих постах или журналах. Автор статьи – Йони Голдберг, независимый разработчик и консультант Node.JS. Итак, начнем! 1) Мониторинг Что это: мониторинг – это такая интересная игра в «найти баг быстрее, чем это сделают твои пользователи». И, помимо прочего, эта игра обладает беспрецедентной важностью. Современный рынок переполнен всеми видами предложений - на любой вкус. Учитывайте: вы должны строго следовать заданной концепции, не переполняя ее различными «доп. фичами». Подберите для себя такое решение, которое удовлетворяет всем требованиям. В противном случае - провал. Разочарованные клиенты. Все просто.   2) «Умное логгирование» - Ваш друг Что это: логи, как правило, очень быстро превращаются в свалку утверждений и записей всех видов и типов. Однако при должном подходе, логи являют собой образец чистоты, легко дающие понять всю необходимую информацию, связанную с программой. Планируйте ведение логов с самого начала: как они будут собираться, храниться и анализироваться. Убедитесь, что желаемая информация (такая, как частота возникновения ошибок и прочее) в любой момент может быть легко извлечена. В противном случае: вы окончите бесконечными копаниями в нечитабельных логах и, в конце концов, потратите уйму времени на «костыли», дабы понять хоть что-то из написанного.   3) Сваливайте все возможные задачи на обратный прокси Что это: увы, но Node.JS ужасен, когда речь заходит о выполнении ресурсоемких задач на центральном процессоре (такие, как g-zip упаковка, SSL-терминация и прочее). Используйте вместо этого промежуточные middleware-сервисы, такие как nginx, HAproxy или облачные. В противном случае: Ваша невинная однопоточная операция займет процессор на длительное время. Как следствие, ваше устройство будет уделять больше времени различным промежуточным задачам, нежели непосредственно Node.JS-приложению. Не буду говорить о производительности.   4) Блокируйте зависимости Что это: код должен быть идентичен для всех сред. Однако, на удивление, можно обнаружить, что NPM творит с зависимостями что-то неимоверное – как только Вы попытаетесь установить пакет в различных средах, программа пытается использовать последнюю версию, характерную для конкретной среды, что, безусловно, вносит свои особенности. Дабы избежать этого, используйте файлы конфигурации. npmrc. Они настраивают NPM таким образом, чтобы тот сохранял текущую версию пакета, не последнюю. Как вариант Вы можете использовать “shrinkwrap”-опцию, так как NPM5 блокирует зависимости по умолчанию. В противном случае: во время тщательного теста QA пропустят версию, которая в продукции будет вести себя неожиданным для разработчика образом. Даже хуже, разные серверы одновременно в том же кластере будут исполнять разный код.   5) Выбирайте правильные инструменты: экономьте время Что это: процесс должен выполняться и перезапускаться в случае ошибок. Возможно, в обычной ситуации в качестве рестартера может сгодиться и что-то наподобие PM2, но в современном мире, где правит балом Докер и его приспешники, все подобные инструменты должны быть подобраны особенно тщательно. В противном случае: использование десятков приложений с сотнями своих инструментов в конце концов приведет к хаосу.   6) Убедитесь, что вы используете только лучшие практики отлавливания багов Что это: как правило, анализ ошибок – наиболее затратная по времени и устрашающая процедура в поддержании стабильности Node.JS-среды. В основном, причина этому – однопоточная модель приложений и отсутствие выработанной стратегии по отношению к ошибкам в многопоточной среде. Быстрых решений не существует, Вы должны в полной мере осознать и приручить это багнутое чудовище.   7) Используйте все ядра процессора Что это: в своей стандартной ипостаси приложения Node.JS используют только одно ядро процессора, в то время как остальные в задаче никакого участия не принимают. Ответственность за утилизацию всех ядер лежит только на Вас. К примеру, для небольших и средних приложений Вы можете использовать Node Cluster или PM2. Для более полновесных программ обратите внимание на репликацию процесса при помощи Docker-кластера (такие, как K8S, ECS) или деплоймент-скрипты на базе инициализации Linux (system – как вариант). В противном случае: Ваше приложение, скорее всего, будет использовать только 25 процентов доступных вычислительных ресурсов (!) или даже меньше. Заметьте, типичный сервер минимум 4-х ядерный, наивный деплой обычного NodeJS использует лишь одно (даже если Вы используете PaaS сервисы наподобие AWS beanstalk)!   8) Разумно планируйте диагностику Что это: работайте с системной информацией как с количеством используемой памяти или REPL и специальных защищенных API. Хотя полагаться на стандартные инструменты и надежней, некоторую ценную информацию и некоторые операции лучше извлекать и производить напрямую в коде. В противном случае: в один прекрасный момент Вы обнаружите, что тратите очень много информации на деплой – поставляя код в продукцию просто затем, чтобы получить некоторую информацию для диагностики.   9) Используйте APM-программы Что это: программы мониторинга вроде APM, чтобы активно оценивать кодовую базу. Посему и их действия могут выходить за рамки действий простых программ мониторинга. К примеру: некоторые APM подсвечивают проблемные транзакции, которые могут вызвать падения производительности на стороне клиента и предполагают причину подобных проблем. В противном случае: Вы можете провести тонны времени на анализ производительности и поиски проблемных мест. Вероятно, Вы так никогда и не будете уверенными, что именно замедляет работу Вашего приложения больше всего и как приложение будет вести себя в «реальном мире».   10) Завершенный код – завершенный продукт Что это: «только идеальный код может быть выпущен в продукцию». Запомните это с самого первого дня разработки. Возможно, это и звучит как что-то из репертуара законченного перфекциониста, но, поверьте, результат того стоит. В противном случае: IT-сообщество вряд ли оценит и сохранит для потомков плохо написанную систему.   11) Обращайте внимание на защиту Что это: Node.JS включает в себя некоторые уникальные защитные механизмы. Понятно и без слов, что более «защищенная» система требует больше времени на ее анализ. В противном случае: что может быть хуже, чем брешь в защите, когда продукт уже в производстве? Просто банальная проблема, которую Вы забыли исправить.   12) Отслеживайте и контролируйте память Что это: Node.JS достаточно неоднозначно работает с памятью: движок v8 обладает ограничением в виде 1.4 ГБ, и были известны случаи, когда код был излишне «памятозатратным». Потому и контроль над использованием памяти – вопрос отнюдь не тривиальный. В небольших приложениях Вы можете настраивать работу с памятью, время от времени используя команды оболочки. Однако в проектах больших масштабов позаботьтесь о выводе состояния памяти в  надежную систему мониторинга. В противном случае: вы обнаружите ежедневную «утечку» памяти в несколько сотен мегабайт, как это произошло с Walmart.   13) Разделяйте клиентскую и серверную часть Что это: для фронт-енд части используйте такие middleware компоненты, как nginx, S3, CDN и прочие. Выполнение подобных задач на Node.JS-сервере очень плохо сказывается на его производительности. Причина этому: обработка великого множества статических файлов в однопотоковой модели. В противном случае: Ваш единственный Node.JS-поток будет занят обработкой сотен html/изображений/angular/react-файлов вместо того, чтобы заняться непосредственно обработкой динамического контента. Или, другими словами, того, для чего и была разработана технология Node.JS.   14) Храните данные вне сервера Что это: сохраняйте любую информацию – будь то пользовательские сессии, кэш, загруженные файлы – на внешнем накопителе. Представляйте, как будто Ваш сервер будет регулярно «падать». Используйте «безсерверную» платформу (например, AWS Lambda). В противном случае: «падение» конкретного сервера в результате приведет не только к утилизации нерабочей машины, но и к падению производительности самого приложения. Более того, зависимость от конкретного сервера значительно уменьшит гибкость всей системы.   15) Используйте инструменты с автоопределением уязвимостей Что это: даже такие проверенные временем зависимости, как Express и другие, имеют бреши, которые время от времени могут ставить всю систему под угрозу. Однако подобное можно легко обойти, если использовать различные бесплатные или коммерческие продукты, которые постоянно проверяются на предмет уязвимостей и могут быть мгновенно исправлены в случае необходимости. В противном случае: держать код в чистоте и без уязвимостей в случае неиспользования соответствующих инструментов затребует постоянного отслеживания новостных сводок и обновлений. Немного напрягает.   16) Присваивайте каждой записи лога свой TransactionId Что это: присваивайте уникальный идентификатор каждой записи в логе. Подобный подход в значительной мере упростит работу и поиск ошибок. К сожалению, из-за асинхронной природы Node.JS реализовать подобное – задача отнюдь не тривиальная. В противном случае: Поиск производственных ошибок будет достаточно длительным. Как следствие, Вы закопаетесь в логе ко всем чертям.   17) NODE_ENV = production Что это: устанавливайте переменной окружения NODE_ENV значение production или development. Это нужно для того, чтобы указать NPM, включить ли оптимизацию или нет – так как многие подобные сервисы обладают опцией автоопределения состояния среды. В противном случае: игнорирование этого нюанса может сильно замедлить производительность. К примеру, если проигнорировать NODE_ENV, используя Express для серверного рендеринга, производительность упадет в три раза!   18) Развертывайте приложение быстро Что это: исследователи отмечают, что команды, которые проводят большее количество Node.JS-размещений, имеют меньший риск столкнуться с целым рядом проблем. Быстрые и автоматизированные размещения, не требующие рискованных ручных этапов и сервисов, в значительной мере ускоряют процесс размещения. Возможно, Вам стоит обратить свое внимание на Docker в комбинации с CI-инструментами. В противном случае: длительное размещение -> падения производительности и человеческие ошибки -> неуверенность команды -> меньшее количество размещений и, как следствие, потенциальных фич.   19) Помещайте NPM-версию в каждое размещение Что это: с каждым новым релизом указывайте в package.json-версию текущего NPM. Это внесет ясность в работе с приложением. Сей фактор важен, так как, к примеру, в среде MicroService некоторые сервисы могут обращать внимание на версию Вашего NPM. Вы можете использовать команду “npm version”, которая укажет версию автоматически. В противном случае: достаточно часто разработчики пытаются исправить баг, часто в конце обнаруживая, что они ищут его не в той версии, в которой стоило бы.   20) Следите за актуальной информацией Традиционное: отслеживайте последние обновления Node.JSб NPM и прочих технологий, с которыми Вы работаете. До новых встреч! Автор перевода: Евгений Лукашук Источник

10 отменных советов как стать лучшим Node.JS разработчиком 2018 года от автора Азата Мардана. Эта статья содержит в себе собранный и тщательно отфильтрованный опыт писателей и спикеров технологии всего Веб-сообщества. Заметка: первоначально заголовком статьи должно было быть «Лучшие практики Node.JS от Гуру Технологии». Эта статья охватывает не «новые» и «лучшие» практики 2017-2018 года, а тщательно выверенные и проверенные временем и практикой паттерны, которые стопроцентно приведут к успеху. И хотя многие из проверенных практик Вам определенно пригодятся в 2018, 2019 и даже более поздних годах, статья не включает в себя такие новшества, как async/await и прочее. Почему? Потому что эти фичи не включены в состав, собственно говоря, кода Node.JS-ядра или кода таких популярных проектов как npm, Express и прочие. Полноценно заниматься разработкой на Node.JS я начал в 2012 году, когда присоединился к Storify. С тех пор я никогда не жалел о принятом решении и не ощущал, как будто я многое потерял, закинув Python, Ruby, Java или PHP – языки, с которыми я работал на протяжении предыдущего десятилетия. Работа в компании Storify для мня оказалась достаточно интенсивной. В отличии от большинства компаний, все приложения Storify работают исключительно на JavaScript. Как вы понимаете, большинство компаний, особенно такие крупные как PayPal, Walmart или Capital One, используют Node.JS только для конкретных определенных задач. Как правило, это gateway API. Однако, с точки зрения программиста, ничего не может быть лучше, чем работа и погружение с головой в одну определенную технологию. Краткая сводка: Избегайте нагромождения – пытайтесь разбивать свой код на столько мелких составных частей, насколько это вообще возможно. И даже больше. Используйте асинхронный подход – избегайте синхронное программирование словно чумы. Избегайте блокировки потоков – помещайте ВСЕ требуемые утверждения в начало файла, ибо они синхронные и, следовательно, будут блокировать программу. Require должен быть закеширован – считайте, это такая фича в Вашем коде. Или баг. Как Вам угодно. Всегда проверяйте свой код – ошибки – это не вышивание, которое можно выбросить в любом момент. Никогда не упускайте обнаруженные ошибки! Используйте try…catch только в синхронном потоке – try…catch бесполезен в асинхронном коде. Кроме того, v8 никогда не оптимизирует try…catch-код. Возвращайте значения или используйте if…else – просто на всякий случай: возвращайте значения что бы остановить выполнение участка кода. Обращайте внимание на события ошибок – почти все Node.JS-классы или объекты реализуют паттерн-наблюдатель и производят события-ошибки. Не стоит пропускать их. Познайте свой npm – устанавливайте модули с ключами –S или –D вместо –save или –save-dev. Используйте текущие версии в package.json – при работе с npm он по-тупому просто добавляет верхнюю скобочку по умолчанию при использовании вместе с ключом –S. Дабы избежать этого, просто вручную блокируйте версии. Никогда не доверяйте semver в своих приложениях, но доверьтесь ему в модулях с открытым исходным кодом. Бонус – используйте разные зависимости. Помещайте то, что требует проект только в процессе разработки в devDependencies. После этого используйте npm i –production. Чем больше ненужных зависимостей используется, тем больше риск возникновения уязвимостей.   Давайте разберем некоторые из этих пунктов поподробнее: Избегайте нагромождения Взгляните на некоторые модули, написанные Исааком З. Шлейтером, создателем npm. К примеру, use-strict включает «строгий» режим написания JavaScript-модульного кода. Включается эта опция всего лишь в три строчки: Но почему-же все-таки стоит избегать нагромождения кода? Одна известная фраза американского воздушного флота гласит: «все должно быть просто до идиотизма». И на это существуют свои причины. Человеческий разум не может держать в памяти больше чем от 5 до 7 вещей одновременно. Это просто как факт. Разбивая код на небольшие составные части, Вы и другие разработчики легко сможете разобраться в нем и понять, для чего он предназначен. Так же упрощается процесс тестирования. Вот пример:   Или еще: Уверен, большинство из Вас отдадут предпочтение второму примеру, когда имена переменных сразу же делают понятной их суть. Конечно, в процессе написания кода Вы можете думать, что Вы понимаете, как он работает и так. Возможно, Вам даже захочется продемонстрировать свою смекалку и сообразительность, объединив несколько методов вместе в одну строку. Пожалуйста, пишите так, как если бы Вы были более неопытны. Как если бы Вы не смотрели в код на протяжении 6 месяцев, или очень устали и, кроме того, еще и выпили. Если Вы пишете код на пике своей ментальной активности, Вам будет труднее понимать его позже, не говоря уже о Ваших коллегах, которые даже не знакомы с ходом Ваших мыслей. Держать все в относительной простоте единственно верный метод – особенно в рамках Node.JS-технологии, где используется асинхронный подход. Другими словами, преимущества от использования подхода малых частей значительно более перевешивают недостатки. Помимо прочего, они позволяют значительно быстрее исправить различные ошибки, которые могут возникнуть по разным причинам в процессе работы с Node.JS-приложением.   Используйте асинхронный подход Синхронный код мало где используется в нынешнем Node.JS. Как правило, он находит свое применение в написании CLI-команд или скриптов, не связанных с веб-приложениями. Что же касательно веб-разработки, Node.JS программисты предпочитают использовать асинхронный подход, так как это позволяет избежать блокировки потоков. К примеру, синхронный код будет приемлем, если мы строит скрипт для работы с базой данных, не системы для обработки параллельных/конкурентных задач: Но, в случае веб-приложения, лучше использовать следующее: Отличительная особенность состоит в том, пишите ли вы долго исполняемый конкурентный код или небольшой скрипт с малым временем жизни. А вообще, лучше запомните одно хорошее правило: всегда пишите асинхронный код в Node.JS.   Избегайте блокировки require S обладает простой системой загрузки модулей, которая использует общий формат CommonJS. Самый простой способ подключить модули, разбросанные по отдельным файлам – использовать встроенную функцию require. В отличии о AMD/requirejs, Node/CommonJS синхронна. По сути, функция работает согласно следующему принципу: Вы импортируете то, что было экспортировано в виде модуля или файла. О чем большинство разработчиков даже не догадывается, так это о том, что require кэшируемая. Потому, до тех пор, пока нет заметных изменений зарезервированного имени файла (и, в случае использования npm-модулей, их нет), код модуля будет выполнен и подгружен в переменную только единожды (для обработки). Подобная методика позитивно сказывается на оптимизации. Однако, даже с кэширование, лучше сначала попробуйте обойтись без require. Попробуйте использовать axios-модули. Путь /connect в свою очередь будет медленнее чем требуется, ибо импорт модулей происходит после генерации запроса: Гораздо лучше будет загрузить модули тогда, когда сервер еще даже не определен, не в маршруте: Require должен быть закэширован Хотя я и упоминал о том, что require может быть закэширован, но что так же интересно, так это то, что мы можем поместить код вне module.exports. К примеру: Зная, что некоторые участки кода могут быть запущены только один раз, подобная реализация окажется более чем полезной.   Всегда проверяйте свой код Node.JS – это Вам не Java. В Java Вы выкидываете исключения потому как в большинстве случаев Ваше Java-приложение не должно продолжать работать в случае ошибки. В Java для этого Вы просто используете try…catch. В случае Node.JS история обстоит несколько по-иному. Так как технология выполняется в асинхронном режиме, контекст ошибки всегда будет отделен от любого перехватчика (такого как try…catch) в случае возникновения самой ошибки. Этот код в Node.JS будет просто-напросто бесполезен: Но! Привычный try…catch все еще может быть использован в синхронном режиме. Вот более действенный рефакторинг предыдущего участка кода: Если мы не можем обернуть request-вызов в блок try…catch, ошибка будет не перехвачена. Однако, это легко решается при помощи callback-аргумента error. Кроме того, Вам нужно всегда вручную отлавливать error в каждом и каждом callback`е. Проверяйте наличие ошибки (и убедитесь, что она не равна null) и затем, или демонстрируйте содержание ошибки пользователю или клиенту и потому логируйте ее, или отправляйте ее обратно в место вызова при помощи error-callback`а. В качестве небольшого фокуса Вы можете использовать библиотеку okay. Применяйте ее как наведено ниже что бы обойти ручной проверки на ошибки: Возвращайте значения или используйте if…else .JS – параллельный. Эта особенность может привести к багам, если не отнестись к ней с должной осторожностью. Что бы обезопасить себя, останавливайте выполнение участка кода при помощи ключевого слова return: Избегайте бессмысленной работы (и ошибок) из-за неостановленного вовремя исполнения: Просто убедитесь, что return всегда будет стоять на страже целесообразности работы Вашего кода.   Обращайте внимание на события ошибок Почти все классы/объекты Node.JS реализую паттерн-наблюдатель, который порождает событие-ошибку. Это прекрасная возможность для разработчика отловить особо подлые ошибки и придушить их до того, как они устроят хаос. В качестве полезной привычки было бы неплохо создавать программы-прослушиватели событий-ошибок при помощи использования .on(): Познайте свой npm Многие Node.JS и front-end событийные разработчики знают, что –save (для npm install) не только установит модуль, но так же и создаст запись в package.json с упоминанием текущей версии модуля. Для аналогичных целей существует и –save-dev, опция для модулей, которые нужны только во время разработки. Но знаете ли Вы, что вместо этого можно спокойно использовать –S и –D? Теперь да. И пока Вы в режиме установки модулей, удаляйте символ ^, который будут порождать команды –S и –D. Эти значки могут быть особенно опасными, так как они позволят npm автоматически обновить модуль к последней незначительной версии (вторая цифра в семантике версирования). К примеру, с версии 6.1.0 до версии 6.2.0. Команда NPM полагается на semver, но Вы не должны. Я хочу сказать, что они используют авто обновления к промежуточным версиям модулей с открытым исходным кодом, так как они полагают, что никаких радикальных изменений в этих самых промежуточных версиях не будет. Мой вам совет: не стоит слишком в это верить. Более того, используйте npm shrinkwrap. Команда создаст новый файл с текущими версиями зависимостей зависимостей. И в заключение В этом посте мы охватили много всего: от работы с callback'ами до работы с асинхронными потоками, проверки на ошибки и снятия блокировки зависимостей. Надеюсь, Вы нашли для себя что-то новое и познавательное здесь. Немного об авторе Азат является техническим консультантом и менеджером в Capital One. JavaScript/Node.js-эксперт, автор различных онлайн-курсов. Издатель более чем 12 книг, посвященных теме, включающие такие хиты продаж как Full Stack JavaScript, React Quickly, Practical Node.JS и Pro Express.js и другие. В свое свободное время Азат читает о технике на Webapplog.com, проводит конференции и работает над продуктами с открытым исходным кодом. До того, как стать экспертом Node.JS, работал в федеральных правительственных агентствах США, принимал участие в небольших старт-апах и больших корпорациях, имея дело с такими технологиями, как Java, SQL, PHP, Ruby и прочие. Азат обожает все, что связано с технологиями и финансами, так же увлекается инновационными способами обучения и просвещения людей. Автор перевода: Евгений Лукашук Источник

Так как 2017 год совсем недавно остался позади, наша команда решила сделать небольшой новогодний подарок в виде разбора лучших сред автоматического тестирования, обладающих, помимо прочего, открытым исходным кодом. 1. Robot Framework Robot Framework – это фреймворк для приемного тестирования (Acceptance Testing) и, помимо прочего, так называемого ATDD (Acceptance Test-Driven Development). Среда написана на языке Python, но также может быть развернута в рамках Jython (Java) и IronPython (.NET). По сей причине считается кроссплатформенной, ибо поддерживает Windows, Linux и MacOS соответственно. Достоинства: Упрощает автоматическое тестирование благодаря использованию подхода keyword-driven тестирования, в значительной мере помогая тестерам в создании читабельных, легко производимых тестов.  Простота в использовании «тестового синтаксиса». Имеет в наличии отменную среду, включающую в себя богатый набор различных инструментов и библиотек, выполненных в виде отдельных проектов. Огромное количество различных API делает систему очень гибкой. Хотя и не в виде встроенной функции, однако Robot Framework позволяет проводить параллельные тесты при использовании библиотеки pabot или Selenium Grid. Недостатки: Трудно настроить структуру html-отчетов. Примечание: эта среда будет очень полезной, если Вы нацеливаетесь на Keyword-Driven тестирование – и обширная база библиотек и расширений вряд ли заставит Вас в этом усомниться. Однако, чтобы добавить новые ключевые слова (RF test library API) базовые познания Java/Python/C программирования обязательны. 2. JUnit JUnit – это среда для проведения юнит-тестов для приложений, написанных на языке Java. Достоинства: Тесты пишутся при помощи чистейшего Java – одного из лидирующих языков программирования современности. Поддерживает TTD. Позволяет создать свой собственный пакет для юнит-тестирования. Прекрасно интегрируется в различные инструменты разработчика (к примеру – Maven) или среды разработки (к примеру, IntelliJ). Благодаря достаточно высокой популярности поиск документации не составляет труда. Недостатки: Если необходимо использовать возможности mock-объектов, пользователь вынужден прибегать к помощи сторонних библиотек (Mockito или другие). Чтение тестов у людей без технического образования может вызвать затруднения, так как, к примеру, имена методов в JUnit ограничены условностями языка Java. Примечание: для тех разработчиков, которые желают писать юнит-тесты для собственных Java-приложений JUnit, пожалуй, лучшее из того, что можно бы пожелать. Однако, в случае если речь идет о функциональном тестировании программ, написанных на других языках, вероятно, Вам стоит выбрать другую среду. 3. Spock Spock – это среда тестирования и спецификации для приложений, написанных на языках Java или Groovy. За основу взята среда JUnit. Достоинства: Позволяет создавать читабельные тесты с поддержкой чисто английских предложений, без необходимости следовать ограничениям языков программирования. Предоставляет информативный контекст возникнувшей проблемы. Плюс, дает легко понять, что необходимо сделать, дабы исправить обнаруженный недостаток. Имеет встроенную поддержку mock и stab объектов. Поддерживает DDT (Data-Driven Tests). Недостатки: Требует базовых знаний языка программирования Groovy. Примечание: идеально подойдет, если Ваше приложение базируется на JVM, плюс, Вы нацеливаетесь на BDD автоматическое тестирование с DSL. 4. NUnit NUnit – среда для юнит-тестирования языков .NET виртуальной машины. Имевшей однажды огромное влияние JUnit, среда NUnit была полностью написана на C#. Помимо прочего, в арсенале так же имеется целый спектр новых возможностей, позволяющих использовать все преимущества языков .NET. Достоинства: Быстрая инициализация и выполнение теста. Использует методы типа Assert с поддержкой аннотаций. Позволяет проводить параллельное тестирование. Поддерживает TDD. Недостатки: Так как использует только языки .NET стандарта, не является кроссплатформенным. Интеграция в среду Visual Studio не представляется возможной. Использование NUnit означает больше расходов на сопровождение проекта. Примечание: прекрасный фреймворк юнит-тестирования для C# с открытым исходным кодом, долгой историей и проверенной репутацией. Однако, в случае, если вы уже активно работаете с .NET языками, обратите свое внимание на MSTest. 5. TestNG TestNG – сервис автоматического тестирования для Java. По сути, это те же JUnit и NUnit, но с улучшениями и новым функционалом (ибо NG читается как «новое поколение» - Next Generation). Среда была разработка для покрытия всех видов тестирования, которые только могут понадобится. А именно: юнит-тестирование, функциональное тестирование, тестирование интеграции и прочее. Достоинства: Прост во внедрении в проект. Позволяет разработчику писать гибкие и всеобъемлющие тесты. Поддерживает DDT. Простые в понимании аннотации. Простота в группировании тестовых кейсов. Позволяет создавать параллельные тесты. Недостатки: Так как поддерживает только Java, Вы должны иметь хотя бы базовые познания этого языка. Установка и калибровка среды тестирования занимает время. Примечание: если вы работаете с Java, ищите инструмент для мульти задачного тестирования и можете уделить некоторое время на установку программы – TestNG определенно для Вас. 6. Jasmine Jasmine – среда для юнит-тестирования JavaScript. Так же известен как Behavior Driven Development (BDD) подход JavaScript тестирования. Идеально подходит для веб-сайтов, проектов Node.js и вообще для всего, где JavaScript может найти свое применение. В основном используется в связке с AngularJS. Достоинства: Кроме JavaScript, так же может быть применен по отношению к Python или Ruby. Чрезвычайно полезен, если Вам нужен один сервис тестирования как для клиентской разработки, так и для серверной. Поддерживается множеством CI (Codeship, Travic и прочее). Имеет встроенный Assert-синтаксис. Недостатки: В большинстве сценариях требует прогонщика тестов (такого как Karma). В случае с асинхронным тестированием возникают трудности. Примечание: Jasmine может оказаться прекрасным решением, если Вы нуждаетесь в унифицированном (клиент-серверном) сервисе юнит-тестирования. 7. Mocha Mocha – это еще один сервис JavaScript юнит-тестирования с занятным для русскоязычного сектора названием и отнюдь не банальным функционалом. Используется на NodeJs, в основном часто применяется в связке с ReactJS. Достоинства: Обладает встроенным тестовым прогонщиком. Поддерживает асинхронное тестирование. Позволяет большую гибкость, так как Вы спокойно можете использовать любую Assert-библиотеку (Chai, expect.js, Must.js прочие), которая будет отвечать Вашим требованиям (как замена стандартной NodeJs функции «assert»). Недостатки: Относительно новый сервис (появился в 2012 году), что означает он в активном развитии и некоторые аспекты технологии могут быть не до конца задокументированными. Предоставляет только базовую структуру тестов, плюс требует дополнительную ручную установку и конфигурацию (для кого-то может быть плюсом). Примечание: если Вы ищите независимую среду юнит-тестирования для JavaScript, Mocha – Ваше все! А какую среду автоматического тестирования используете Вы? Что хорошего и что не очень Вы могли бы о ней сказать? Пожалуйста, приобщайтесь к дискуссии в комментариях! 😊 Автор перевода: Евгений Лукашук Оригинал статьи

Все мы знаем простую формулу: быстрый сайт = счастливые пользователи, высокая оценка 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. Искренне надеемся, что сей гайд будет полезным для работы с запросами. Внешне оптимизация может казаться чем-то устрашающим, но как только Вы попробуете это сделать, Ваши маленькие победы развеют подобные суждения. Автор перевода: Евгений Лукашук Источник

Я работал с .NET Core около года и сейчас могу сказать, что был очень впечатлен. Поскольку наша компания создает приложения для разработчиков, которые базируются на .NET Core, я ощущаю нас причастными к тому, что сейчас происходит. Каждый день мы общаемся с клиентами, которые уже используют .NET Core в своих разработках. .NET Core быстро завоевывает популярность, и я уже предсказываю огромную потребность в разработчиках на C# и .NET Core в 2018 году. Согласно индексу программирования TIOBE, C# уже входит в пятерку наиболее популярных языков программирования. 6 вещей, которые стоит знать о C# и .NET Core Узнайте, почему .NET Core возводит C# в топ списка наиболее популярных языков программирования. 1) Простота в изучении Если вы уже работали с С, Java или даже JavaScript, синтаксис C# покажется Вам довольно знакомым. Сам синтаксис достаточно прост в понимании и чтении. Исходя из индекса TIOBE, приведенного выше, уже сейчас большинство разработчиков могут легко перейти с Java или C. В сети существует много онлайн-ресурсов для изучения C#. Большинство из них – бесплатные, другие же можно использовать за умеренную плату. Pluralsight – Отличный обучающий контент за доступную цену Microsoft Virtual Academy – Бесплатные видео и оценивание Microsoft Getting Started with C# - Бесплатные интерактивные туториалы 2) Современные возможности языка .NET существует на протяжении длительного времени и за последние 15 лет достаточно сильно преобразился и улучшился. На протяжении лет я отмечал такие прекрасные нововведения как MVC, обобщения, LINQ, async/await операторы и многое другое. Как человеку, который лично посвятил себя изучению языка, я рад наблюдать, как он модернизируется. Многое претерпело изменения с появлением .NET Core. Взять тому примером стек технологий ASP.NET. Все эти 15 лет язык C# был с нами, и он продолжает совершенствоваться. Вот некоторые наиболее примечательные особенности: Строгая типизация Качественные библиотеки классов Асинхронное программирование – шаблон async/await Сборка мусора, автоматическое управление памятью LINQ – интегрированный язык запросов Обобщения – примером List<T>, Dictionary<T, T> Управление пакетами Общие бинарные файлы для разных платформ и фреймворков Простота в использовании фреймворков для создания MVC веб-приложений и REST API. 3) Универсальность: веб, мобильные, серверные, настольные приложения Одним из наиболее значимых плюсов C# в частности и .NET в целом, я считаю, является его многогранность. Я могу писать программы для ПК, вести веб-разработку, создавать фоновые сервисы или даже мобильные приложения (спасибо Xamarin!). Кроме того, все, что мне нужно знать, дабы скомпоновать все UI-коды вместе (чего я все же стараюсь избегать), это, кроме C#, всего лишь немного JavaScript’а (+ TypeScript). Шаблоны ASP.NET Core в свою очередь при создании клиентских библиотек даже используют макеты Бутстрапа и npm. Универсальность языка - довольно весомый плюс, так как ваш вклад в его изучение может найти применение в широком спектре возможностей. Ваши навыки очень мультиплатформенные. Если пожелаете, Вы можете легко «перескочить» с разработки веб-приложений на мобильные. Пожалуй, это уникальное отличие от других языков, заточенных только под серверную часть. Не стоит забывать о первоклассной поддержке Microsoft Azure. Нужно задеплоить проект на облако? Нет ничего проще: сия операция осуществляется всего лишь в пару кликов. Поддержка Docker-контейнеров также присутствует, что значительно упрощает деплой приложений на AWS или другие хостинги на Ваше усмотрение. 4) Качественные инструменты разработчика Visual Studio всегда считалась одной из лучших сред разработки. Это прекрасный редактор кода, поддерживающий такие фичи, как компиляцию, отладку, профилирование, git-репозиторий, юнит-тестирование и многое другое. Плюс, за вами всегда остается возможность писать коды для .NET Core в любом текстовом редакторе в виде обычных текстовых файлов. Вы также можете использовать Visual Studio Code на любой ОС в качестве отличного редактора кода. Даже те из нас, кто никогда не желает расставаться с этим Vim или Emacs, могут вести разработку на C#. Можно также установить плагины для Visual Studio и добавлять свои «горячие клавиши». Вся экосистема .NET изобилует прекрасными инструментами. К примеру, вряд ли я смогу представить жизнь без Resharper`а или JetBrains. Существуют десятки классных инструментов, включая смеси открытого кода и коммерческих продуктов. 5) Обобщение навыков .NET обладает очень хорошим набором базовых библиотек. В отличие от Node.js, такие простые строковые функции, как LeftPad(), уже встроены. Подобное разнообразие стандартных библиотек значительно уменьшает потребность в сторонних пакетах. Также благодаря вмешательству Microsoft, мы можем использовать такие технологии, как JSON.NET и прочее. Microsoft обеспечивает качественный набор шаблонов и их реализаций на .NET. К примеру, сервис для работы с данными (Entity Framework) и MVC уже встроены. Большинство разработчиков именно ими и пользуется. Подобный подход значительно упрощает взаимодействие между командами и ускоряет понимание, как проект работает. Благодаря этому, Ваши знания и навыки становятся более универсальными. 6) Код .NET Core в свободном доступе Одним из наиболее значимых событий, которое когда-либо происходило на .NET, является публикация исходного кода. Теперь каждый на GitHub’е может просматривать, вносить правки и дополнять его. Пожалуй, большинство людей даже никогда не думали о том, что подобное может когда-либо произойти. Как разработчику, время от времени Вам необходимо «заглядывать за ширму», дабы понимать, как на самом деле работает код. К примеру, раньше я мог только гадать, закрывает ли вызов метода Dispose() на базе данных соединение или нет. Если же Вы можете заглянуть в исходный код, большинство схожих вопросов отпадает. Даже если Вы не дополняете исходники, так или иначе Вы получаете пользу от тех, кто это делает. Проблемы и возможные улучшения быстро обсуждаются, реализуются и публикуются в свободный доступ. Прошли теперь те дни, когда на ожидание сколь-либо значительных улучшений или незначительных правок уходили годы. Заключение На протяжении лет я читал о программистах-полиглотах и о новых классных языках. В разное время люди писали на Ruby, Python, Scala, Go, Node.js, Swift и прочем. Приятно видеть, что Microsoft, сообщество сделали с .NET Core и как он вознесся в ранг первоклассной платформы. Я даже портировал .NET приложения на Maрc! Проблемой многих существующих языков программирования является то, что они узкоспециализированы. Ruby и PHP прекрасно подходят для веб-приложений. Swift или Objective C лучшего всего использовать для IOS или MacOS. Если нужно написать серверное приложение, можно использовать Python, Java и так далее. Пожалуй, кроме C#, только JavaScript и Java могут считаться языками широкого профиля. Мне бы было трудно применить навыки для решения различных задач, если бы я был вынужден работать со многими языками программирования. Это ограничивает возможности. Мне нравится универсальность C#, нравится то, что его можно использовать для разных типов приложений. Теперь, поскольку .NET Core так же подходит и для MacOS и Linux, больше нет никаких лимитов на его применение. Автор перевода: Евгений Лукашук Источник

C# занимает лидирующие позиции во всех рейтингах языков программирования. Так как рынок труда активно развивается, программисты, которые хорошо знают C# и технологии .NET, являются очень востребованными. На ITVDN вы найдете все необходимое, чтобы выучить C# с нуля до профессионального уровня. Курсы записаны сертифицированными разработчикам и тренерами Microsoft. Мы рекомендуем проходить обучение в такой последовательности:    C# Starter, автор Александр Шевчук Выполнение домашних заданий по C# Starter, автор Константин Черный How to C# Starter, автор Богдан Бондарчук Тренажер по C# Starter Visual Studio Tips & Tricks, автор Дмитрий Охрименко  C# Essential, автор Александр Шевчук Выполнение домашних заданий по C# Essential, автор Константин Черный How to C# Essential, автор Богдан Бондарчук Тренажер по C# Essential C# Универсальные шаблоны, автор Николай Мельничук  Unit Тестирование в C#, автор Дмитрий Охрименко  Асинхронное программирование в C# 5, автор Олег Кулыгин C# для профессионалов, автор Александр Шевчук  How to C# Professional, автор Константин Черный Что нового в C# 6.0-7.0, автор Александр Ткаленко Также вас могут заинтересовать записи вебинаров ITVDN: С# - с чего начать и как идти дальше? Работа с Microsoft Word на C# Если вы планируете свое обучение C# с нуля, тогда наилучшим решением будет приобретение подписки ITVDN сроком на 3 или 6 месяцев.

Настало время для прогнозов по безопасности и новым технологиям на следующий год. Ведь 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