Об авторе Дастин Драйвер – журналист и технический писатель, который съел кошку в газетном бизнесе и web-игровой разработке. Вступление Конечно, console.log может рассказать вам о многом, но все же сказать, что это отладчик, все равно что сказать, что Канада – это США. Для полноценной отладки вам необходимо отдельное специализированное полнофункциональное приложение. Новый отладчик Firefox позволит вам легко писать быстрый, стабильный код. Вот как это работает. В этом примере мы отладим очень простое приложение. Здесь вы можете найти приложение на базе фрейморков с открытым исходным кодом. Откройте его в последней версии Firefox Developer Edition, запустите debugger.html  при помощи Option + Cmd + S на Маке или Shift + Ctrl + S на Винде. Отладчик разделен на три функциональные области: навигация по проекту (Source List Pane), код (Source pane) и панель инструментов (tool pane). Панель инструментов далее разделена на тулбар, средство просмотра выражения, точки остановки, стек вызова и области видимости. Прекратите использовать console.log! Возможно, использование console.log для отладки своего кода для многих кажется привлекательным. Действительно, мы просто пишем вызов функции в нужном месте и получаем значение искомой переменной. Что может быть проще? Конечно, это работает, но, к сожалению, требует множественного переписывания кода и, честно говоря, банально занимает время. В этом примере я буду использовать debugger.html, чтобы найти значение переменной в нужный момент выполнения программы. Мы можем использовать debugger.html, чтобы углубиться в особенности работы нашего приложения при помощи простого добавления точек остановок на нужные линии кода. Точки остановки сигнализируют отладчику о том, что в этот момент времени необходимо остановить выполнение кода, так что вы можете навести курсор на код и увидеть все необходимые значения. Здесь мы добавим точку остановки на 13 строку файла app.js. Теперь давайте добавим задачу в список. Отладчик остановит выполнение всей функции, и мы сможем залезть в код и посмотреть значение выходной функции – и даже больше. Наведите курсор на переменную, и вы увидите всю возможную информацию о ней. Вы также можете исследовать панель областей видимости, чтобы получить то же самое. Теперь, когда скрипт остановлен, мы можем «пройтись» по нему, используя панель инструментов. Клавиши play/pause делают ровно то, что мы ожидаем от них, исходя из названия. Step over переходит на следующую строчку кода, исполняя текущую. Step in – проникает внутрь вызова функции. Ну и step out выполняет текущий скрипт целиком и останавливается на следующей точке, если она существует. Мы также можем использовать панель просмотра выражений, чтобы следить за состоянием переменной. Просто введите выражение в специальное поле и отладчик будет уведомлять вас о состоянии объекта во время всего выполнения кода. В примере вы также можете добавить выражение “title” или “to-do”, и отладчик покажет вам эти значения, если они будут доступными. Это особенно полезно, когда: Вы переходите на следующую строчку и хотите заметить изменение переменной Вы проводите отладку много раз и хотите видеть общие значения Вы пытаетесь понять, почему та чертова кнопка не работает Также вы можете использовать debugger.html, чтобы отладить React/Redux-приложение. Вот как это работает: Переместитесь к компоненте, которую вы хотите отладить Просмотрите данные о компоненте слева Добавьте точки остановки к нужным функциям Остановите выполнение и проверьте состояние нужных переменных Стек вызова упрощен, так что вы можете увидеть код вашего приложения, чередующегося с фрейморком И, наконец-то, debugger.html позволит вам увидеть скрытый и минимизированный код для отлавливания ошибок, что, как правило, может быть полезным, когда мы имеем дело с такими общими фрейморками, как React/Redux. Отладчик осведомлен о компонентах, которые вы рассматриваете, и с радостью покажет все в упрощенном стеке вызовов – свойства и прочее. Здесь вы можете увидеть (английским), как использовать отладчик Firefox на примере такого разработчика, как Amit Zur. Если вы хотите исследовать возможности нового debugger.html, проследуйте в  Mozilla Developer Playground. Мы обладаем целой серией обучающий материалов, которые в полной мере позволят изучить способности отладчика. Инструменты с открытым исходным кодом Debugger.html был запущен около 2 лет назад – вместе с полной переработкой всех инструментов разработчика. Мы хотели перестроить DevTools при помощи современных веб-технологий, чтобы сделать их доступными для разработчиков всего мира. И когда у технологии открытый исходный код, любой, кто только пожелает, может принять участие в ее разработке. JavaScript является обязательным для любого продвинутого веб-приложения, так что появление качественного отладчика было лишь вопросом времени. Мы хотели создать что-то, чтобы это было быстрым, простым в освоении и адаптивным – способным отлаживать любой JS-фреймворк из числа доступных. Потому мы и решили использовать популярные веб-технологии, так как хотели работать сообща с коммьюнити разработчиков. Этот подход также позволит нам улучшить сам отладчик – если мы адаптировали WebPack и начали использовать внутренние инструменты построения и сорс-маппы, мы хотели бы также улучшить и «горячую перезагрузку». Debugger.html встроен также и в React, Redux, Babel. Компоненты React легковесны, они тестируемы и просты в проектировании. Для быстрого создание ui-элементов мы используем React Storybook. Наши компоненты были оттестированы при помощи Jest и Enzyme, что значительно упростило работу с визуальными интерфейсами. Это также упрощает и работу с различными JavaScript – фреймворками (наподобие React). Наш Babel front-end позволяет совершать отображение классов-компонентов и их функции в левой панели отладчика. Также мы можем делать такие классные вещи, как фиксация точек остановки в функциях, так что они не исчезнут при модификации самой функции. Действия Redux представляют из себя чистый API для UI, но также могут быть использованы для построения отдельного CLI JS – отладчика. Redux обладает селекторами для выборки текущих состояний отладчика. Наш юнит-тест позволяет запустить Redux – действия и эмулировать ответы браузера. Наши интеграционные тесты запускают браузер в режиме отладки совместно с Redux. По сути, сама функциональная архитектура разработана для того, чтобы быть тестируемой. Мы полагались и прислушивались к сообществу Mozilla на каждом этапе разработки. Проект был опубликован на GitHub, и наша команда открыла доступ к нему для всех разработчиков по всему миру. Когда мы только начали, автоматические тесты были обязательным компонентов для разработки. Тесты оберегали нас от регрессий. Это и являлось причиной того, почему один из первых этапов разработки требовал создания юнит-тестов для Redux-операций. По факту, общество заверило нас, что наше Flow и Jest-покрытие успешно тестирует каждый файл системы. Как разработчики, мы верим, что чем мощней и эффективней инструмент, тем больше людей привлечено к его разработке. Наша ключевая команда всегда была маленькой (2 человека), тогда как среднее количество контрибуторов достигало 15 за неделю. Сообщество привнесло перспективу в развитие, что помогло нам преодолеть все трудности и создать такие фичи, о которых мы даже не могли и мечтать. Сейчас мы адаптируем стек вызова для 24 отдельных библиотек, о многих из которых мы раньше даже и не слышали. Также мы оказываем поддержку для WebPack и Angular. Мы планируем перенести все инструменты разработчика на GitHub, так что в скором времени они будут доступны для более широкой аудитории. Приглашаем и вас внести свой вклад. Вы сможете найти список инструкций, как запускать отладчик на своей машине и как модифицировать его к тому, что вам по душе. Используйте его для отладки кода везде – в браузерах, терминалах, серверах, телефонах, ботах. И если у вас есть идея, как бы еще его можно было бы улучшить, дайте нам знать на GitHub. Загрузить последнюю версию Firefox вы можете здесь.   Автор перевода: Евгений Лукашук Оригинал статьи

Коротко про мене Мене звати Зел, я розробник-фрілансер із Сінгапуру. У вільний від роботи час я люблю розбиратися в коді і принагідно публікувати у своєму блозі ті цікавості, які я виявив чи вивчив. Вступ Швидше за все вам уже доводилося чути про такий термін, як REST API, особливо якщо ви стикалися з необхідністю отримання даних з іншого джерела (такого як Twitter або GitHub). Але що ж все-таки це таке? Що ми можемо робити з цим і як ми можемо це використовувати? У цій статті ви дізнаєтеся все про REST API для того, щоб працювати з ними та читати пов'язану з ними документацію. Що ж таке REST API? Давайте уявимо, що ви намагаєтеся знайти фільми про Бетмена на YouTube. Ви відкриваєте сайт, вбиваєте у форму пошуку слово «Бетмен», тиснете «Окей» і бачите список фільмів про супергероя. Так само працює і WEB API. Ви шукаєте щось і отримуєте список результатів від ресурсу, до якого здійснюєте запит. Дослівно API розшифровується як Application Programming Interface. Це набір правил, що дозволяє програмам спілкуватися одна з одною. Розробник створює API на сервері та дозволяє клієнтам звертатися до нього. REST – це архітектурний підхід, що визначає, як API мають виглядати. Читається як "Representational State Transfer". Цьому набору правил і слідує розробник під час створення свого застосунку. Одне з цих правил каже, що при зверненні до певної адреси ви повинні отримувати певний набір даних (ресурс). Кожна адреса - маршрут, пакет даних - запит, у той час як результуючий ресурс – відповідь. Анатомія запиту Важливо розуміти структуру запиту: Маршрут відправки. Тип методу. Заголовки. Тіло (або дані). Маршрут – це адреса, за якою надсилається ваш запит. Його структура приблизно така: Root-endpoint - це точка прийому запиту на стороні сервера (API). Наприклад, кінцева точка GitHub - https://api.github.com. Шлях визначає ресурс, до якого здійснюється запит. Це щось на кшталт автовідповідача, який просить вас натиснути 1 для одного сервісу, 2 для іншого і так далі. Для розуміння того, які саме шляхи вам доступні, вам слід переглянути документацію. Наприклад, припустимо, ви хочете отримати список репозиторіїв для конкретного користувача на Git. Згідно з документацією, ви можете використати наступний шлях для цього: Вам слід підставити під пропуск ім'я користувача. Наприклад, щоб знайти список моїх репозиторіїв, ви можете використати маршрут: Остання частина маршруту – це параметри запиту. Технічно запити не є частиною REST-архітектури, але на практиці зараз все ґрунтується на них. Тож давайте поговоримо про них детальніше. Параметри запиту дозволяють використовувати у запиті набори пар «ключ-значення». Вони завжди починаються знаком питання. Кожна пара параметрів після чого розділяється амперсандом (щось подібне до цього): Як тільки ви намагаєтеся отримати список репозиторіїв для користувача, ви додаєте ці три опціональні параметри і після чого отримуєте наступний результат: Якщо ж ви бажаєте отримати список моїх недавно запушених репозиторіїв, вам слід ввести наступне: Отже, як же зрозуміти, що маршрути робочі? Що ж, настав час перевірити їх на практиці! Тестування за допомогою Curl Ви можете надіслати запит за допомогою будь-якої мови програмування. JavaScript може використовувати методи на кшталт Fetch API або JQuery`s Ajax Method. Рубі використовує інше. І так далі. У цій статті я використовуватиму таку утилітку, як Curl. Справа в тому, що вона вказана в офіційній документації для веб-сервісів. Якщо ви зрозумієте, як використовувати цю утиліту, ви зрозумієте, як працювати з API. Після чого ви можете робити запити будь-якою зручною для вас мовою. Перед тим, як продовжити, слід переконатися, що Curl встановлений на вашій машині. Якщо ж він не встановлений, саме час встановити. У такому разі ви отримаєте помилку "command not found". Для того щоб використовувати утиліту, необхідно ввести наступне (за прикладом): І як тільки ви підтверджуєте введення, ви отримуєте відповідь (на зразок цього): Щоб отримати список користувацьких репозиторіїв, вам слід змінити запит за тим же принципом, який був обговорений раніше. Наприклад, щоб отримати список моїх репозиторіїв, вам слід ввести наступне: Якщо ж ви бажаєте включити параметри запитів, переконайтеся, що ви їх екрануєте. Справа в тому, що без екранування знаки питання і рівності розцінюються системою як спецсимволи і виконання команди відбудеться з помилкою. Також спробуйте інші команди та зробіть запити! В результаті ви отримуєте схожі відповіді. JSON JSON – JavaScript Object Notation – загальний формат для надсилання та прийому даних за допомогою REST API. Відповідь, що відправляється Github, також міститься у форматі JSON. Зміст об'єкту цього формату приблизно наступний: Повертаємось до анатомії запиту. Ви вивчили, що запит складається із чотирьох частин: Маршрут відправки. Тип методу. Заголовки. Тіло (або дані). Тепер давайте спробуємо розібратися з рештою. Тип методу Метод позначає тип запиту, який здійснюється; де-факто він є специфікацією операції, яку повинен здійснити сервер. Усього існує п'ять типів запитів: GET POST PUT PATCH DELETE GET – використовується для отримання з боку серверу певного ресурсу. Якщо ви здійснюєте цей запит, сервер шукає інформацію та відправляє її вам назад. По суті, він здійснює операцію читання на сервері. Дефолтний тип запитів. POST – необхідний для створення певного ресурсу на сервері. Сервер створює в базі даних нову сутність та сповіщує вас, чи був процес створення успішним. По суті, це операція створення. PUT та PATCH – використовуються для оновлення певної інформації на сервері. У такому разі сервер просто змінює інформацію існуючих сутностей у базі даних та повідомляє про успіх виконання операції. DELETE – як і випливає з назви, видаляє вказану сутність із бази чи сигналізує про помилку, якщо такої сутності в базі не було. Сам же API дозволяє вказати, який метод має бути використаний у певних контекстних ситуаціях. GET запит у цьому випадку необхідний, щоб одержати список всіх репозиторіїв зазначеного користувача. Також можна використовувати curl: Спробуйте надіслати цей запит. Як відповідь ви отримаєте вимогу про аутентифікацію. Заголовки Заголовки використовуються для надання інформації як клієнту, так і серверу. Взагалі, їх можна використовувати для багато чого; наприклад, та сама автентифікація та авторизація. На офіційній сторінці MDN можна знайти список доступних заголовків. Заголовки являють собою пари ключів-значень. Приклад: Також приклад із використанням curl: (Примітка: заголовок Content-Type у випадку Github для роботи не є обов'язковим. Це всього лише приклад використання заголовка в запиті, нічого більше). Для перегляду надісланих заголовком даних можна використовувати наступне: Тут зірочка відноситься до додаткової інформації, наданої за допомогою curl. > відноситься до заголовків запиту, а <, відповідно, - до заголовків відповіді. Щоб надіслати інформацію з curl, використовуйте наступне: Для відправки множинних полів ми можемо використати декілька подібних конструкцій: Також, якщо необхідно, ви можете розбити ваш запит на декілька ліній для забезпечення більшої читабельності: Якщо ви знаєте, як розгорнути сервер, ви можете створити власний API та протестувати свої запити. Якщо ж ні, обов'язково спробуйте. Існує безліч інформації, присвяченої цьому. Якщо ж бажання розгортати свій сервер немає, спробуйте безкоштовну опцію Request bin. Після чого ви отримаєте адресу, яку спокійно зможете тестувати. Переконайтеся, що ви створюєте власний request bin, якщо ви хочете протестувати саме ваш запит. Зважайте на те, що дефолтний час існування request bin – 48 годин. Тому ті приклади адрес, які я тут наводжу, на момент прочитання статті давно застаріли. Тепер спробуйте надіслати деяку інформацію, після чого оновіть свою сторінку. Якщо все пройде успішно, ви побачите наступне: За замовчуванням curl відправляє дані так, ніби вони були відправлені за допомогою полів форм. Якщо ви бажаєте надіслати дані через JSON, ваш Content-Type повинен дорівнювати application\json, внаслідок чого вам необхідно відформатувати дані у вигляді JSON-об'єкту. По суті, це все, що вам необхідно знати про структуру запиту. Тепер давайте згадаємо про аутентифікацію. Що ж це таке і навіщо вона потрібна? Аутентифікація Ви б не дозволили нікому чужому отримати доступ до вашого банківського рахунку без спеціального дозволу, чи не так? За таким же принципом розробники не дозволяють неавторизованим користувачам робити на сервері все, що їм заманеться. Оскільки POST, PUT, PATCH, DELETE запити змінюють базу даних, розробники повинні завжди бути на варті неавторизованого доступу до них. Проте іноді GET запити також вимагають аутентифікації (наприклад, коли ви хочете переглянути стан вашого банківського рахунку). У випадку з вебом існує два способи представитися системі: Через нік і пароль (базова автентифікація) Через секретний токен Секретний токен дозволяє представити вас системі через соцмережі на кшталт Github, Google, Twitter і так далі. Тут же я розгляну лише базову автентифікацію. Для виконання базової аутентифікації ви можете використовувати наступне: Спробуйте залогінитися під свій профіль за запитом, вказаним вище. Як тільки ви успішно увійдете у свій профіль, ви побачите відповідь "problems parsing JSON". Чому? Все просто: системі ви представилися, але - от біда - нічого корисного їй не надали. Усі типи запитів потребують певної інформації. Тепер же давайте поговоримо про статус-коди та можливі помилки. Статус-коди та можливі помилки Деякі з повідомлень, наведених вище, якраз і належать до кодів помилок. Логічно, що вони з'являються лише тоді, коли щось іде не зовсім так, як було заплановано. Що ж до статусу кодів, вони дозволяють вам пізнати успіх (або невдачу) під час виконання певного запиту. Бувають статус-коди від 100 до 500+. Загалом їх можна поділити на такі групи: 200+: запит успішний 300+: запит перенаправлений на інший маршрут 400+: помилка на стороні клієнта 500+: помилка на стороні сервера Ви можете відлагодити статус відповіді за допомогою –v або –verbose. Наприклад, я спробував отримати доступ до певного ресурсу без авторизації. Відповідно, я спіймав помилку: У випадку ж, коли запит невірний через помилку в самій інформації, що передається, ви отримуєте статус-код 400: Версії API Час від часу розробники оновлюють свої API. Іноді оновлення можуть бути такими сильними, що розробник бажає здійснити реліз нової версії. У такому випадку, якщо ваш застосунок ламається, це відбувається через те, що ви писали код з урахуванням старого компонента, тоді як новий дещо відрізняється в плані реалізації. Запросити поточну версію API можна двома шляхами. Через маршурт Через заголовок Наприклад Твіттер використовує перший спосіб. На момент написання версія Twitter API була 1.1. Водночас GitHub використовує інший спосіб: На закінчення У цій статті ми розглянули, що таке REST API і як його можна використовувати спільно з curl. Крім того, ви також вивчили, як залогінитись за допомогою запиту і що таке статус-код. Я щиро сподіваюся, що ця стаття дозволила вам підвищити свій рівень загальних і не дуже знань щодо такого важливого аспекту веб-розробки. Буду радий будь-яким вашим коментарям тут. Автор перекладу: Євген Лукашук Джерело Ще більше матеріалів на цю тему: ASP.NET Core Web API. Практичний курс ASP.NET WEB API 2 REST API в Node.js  JAX-RS Client API. Asynchronous REST Створення API на PHP та JavaScirpt

Давайте разберемся, кто такой Front-end разработчик и какими технологиями он должен владеть, чтобы быть востребованным специалистом. Возможно, Вы когда-нибудь, глядя на ваш любимый веб-сайт, задавались вопросом, насколько это сложно сделать? Веб разработка состоит из 2-х основных больших частей – клиентской и серверной, которыми занимаются – frontend и backend-разработчики. В самом упрощенном виде: если backend создает функционал, то frontend занимается в первую очередь тем, что видит пользователь, зайдя на сайт – все эти красивые страницы, кнопочки, картинки. Но не все так просто… Frontend-разработчики создают те вещи, с которыми будут взаимодействовать люди. Все этапы разработки проходят вместе с frontend-разработчиком. То есть frontend-разработчик должен быть в курсе всего! Строго говоря, Frontend — публичная часть веб-сайтов и веб-приложений, с которой непосредственно контактирует и взаимодействует пользователь. Во Frontend входят отображение пользовательского интерфейса, функционал, выполняющийся на стороне клиента, и обработка пользовательских запросов. Знания и навыки Frontend-разработчика: Frontend-разработчик должен разбираться в дизайне. Если frontend-разработчик не является сам по себе дизайнером, он должен знать, насколько важен дизайн. Он должен иметь хороший вкус. Он должен знать об инструментах, участвующих непосредственно в разработке.   Frontend-разработчик должен разбираться в работе серверной части (backend). Frontend-разработчик должен явно осознавать всю важность серверной части, понимать, с чем взаимодействует backend, что передается на сервер, а что нет, должен уметь объяснить, что должен дать вам backend и что нужно от серверной части frontend-а.   Frontend-разработчик должен разбираться в производительности. Frontend-разработчик знает, что производительность имеет важное место в успехе проекта. Необходимо понимать, насколько быстрым должен быть backend, а также что оставшиеся 80% времени - это загрузка сайта, т.е. это frontend.   Frontend-разработчик должен разбираться в мобильном дизайне. Frontend-разработчик должен понимать, что его сайтом могут пользоваться везде, на его сайт могут зайти с любого устройства, поэтому необходимо позаботиться заранее на этот счет. Большие экраны, маленькие, сенсорные, устаревшие устройства. Frontend-разработчик должен быть готов к неизвестному! Это всего лишь часть того, что должен знать frontend-разработчик. Чем больше, тем лучше. И начинать изучать лучше сразу правильно. Переучиваться – это всегда проблематично! Какие же технологии предстоит изучить frontend-разработчику? HTML и CSS HTML (язык разметки гипертекста) и CSS (каскадные таблицы стилей) являются основными строительными блоками веб-кодирования. Без этих двух вещей вы не можете создать дизайн веб-сайта, и все, что у вас в итоге получится, - это неформатированный простой текст на экране. Вы даже не сможете добавлять изображения на страницу без HTML! Прежде чем приступить к освоению карьеры в Интернете, вам нужно освоить верстку с помощью HTML и CSS.   JavaScript JavaScript позволяет добавить к вашим веб-сайтам больше функциональности. Вы сможете создать множество базовых веб-приложений, используя не что иное, как HTML, CSS и JavaScript. На самом базовом уровне JavaScript позволяет добавлять на ваши сайты множество интерактивных элементов. Это также самый популярный язык программирования в мире, поэтому, независимо от ваших планов карьерного роста, очень желательно иметь хотя бы базовые знания JavaScript.   JQuery jQuery - это библиотека JavaScript: коллекция плагинов и расширений, которая позволяет быстрее и проще разрабатывать JavaScript. Вместо того, чтобы писать все с нуля, jQuery позволяет добавлять готовые элементы к вашим проектам, которые затем можно настроить по мере необходимости. Вы можете использовать jQuery для таких вещей, как таймеры обратного отсчета, автозаполнение формы поиска и даже автоматическое перераспределение и изменение размеров макетов сетки.   JavaScript фреймворки Фреймворки JavaScript (включая Angular, Backbone, Ember и React) дают готовый дизайн вашему JavaScript-коду. Существуют различные типы фреймворков для разных потребностей. Они действительно ускоряют разработку, предоставляя вам быстрый запуск и могут использоваться с такими библиотеками, как jQuery.   Frontend Frameworks CSS и интерфейсные рамки (самая популярная инфраструктура front-end - Bootstrap) делают для CSS то, что JS Framework делают для JavaScript: они дают вам точку перехода для более быстрого кодирования. Так как CSS начинается с точно таких же элементов из проекта в проект, фреймворк, который определяет все это для вас, является очень ценным. Как правило предполагается, что вы будете знакомы с тем, как эти структуры работают и как их использовать.   Работа с препроцессорами CSS Препроцессоры - еще один элемент, который может ускорить кодирование CSS. Препроцессор CSS добавляет дополнительные функциональные возможности для CSS, чтобы поддерживать масштабируемость и удобство работы нашего CSS. Он обрабатывает ваш код, прежде чем публиковать его на своем веб-сайте, и превращает его в хорошо отформатированный и кросс-браузерный CSS. SASS и LESS являются двумя наиболее востребованными препроцессорами.   Практичный и мобильный дизайн Например, когда веб-сайт посещается с настольного компьютера с большим монитором, пользователь получает несколько столбцов, большую графику и взаимодействие, созданные специально для пользователей мыши и клавиатуры. На мобильном устройстве один и тот же сайт будет отображаться как один столбец, оптимизированный для сенсорного взаимодействия, но с использованием тех же базовых файлов. Мобильный дизайн может включать в себя гибкий дизайн, а также создание отдельных мобильных проектов. Иногда то, что пользователь видит на вашем сайте на настольном компьютере, совершенно отличается от того, что вы можете видеть при посещении его со смартфона.   Кросс-браузерная разработка Современные браузеры очень хорошо демонстрируют веб-сайты последовательно, но по-прежнему существуют различия в том, как они интерпретируют код за кулисами. Пока все современные браузеры не будут работать с веб-стандартами, знание того, как заставить каждого из них работать так, как вы хотите, является важным навыком. Это кросс-браузерная разработка.   Системы управления контентом и платформы для электронной коммерции Очень многие веб-сайты построены на системе управления контентом (CMS). (Платформы электронной коммерции - это особый тип CMS.) Наиболее популярной CMS во всем мире является WordPress, которая является закулисной частью миллионов веб ресурсов. Почти 60% сайтов, использующих CMS, построены на WordPress.   Тестирование и отладка Модульное тестирование - это процесс тестирования отдельных блоков исходного кода (инструкции, которые сообщают веб-сайту о том, как он должен работать), а рамки модульного тестирования предоставляют конкретный метод и структуру для этого. Другим распространенным типом тестирования является тестирование пользовательского интерфейса (также называемое приемочным тестированием, тестированием браузера или функциональным тестированием), где вы проверяете, что веб-сайт ведет себя так, как должен, когда пользователь действительно предпринимает действия на сайте. Отладка просто берет все “ошибки”, выявленные этими тестами.   Системы контроля версий Git и Version Системы контроля версий позволяют отслеживать изменения, которые были внесены в код с течением времени. Они также позволяют легко вернуться к более ранней версии, если вы что-то придумаете. Итак, скажем, вы добавляете настроенный плагин jQuery и вдруг половину вашего разрыва кода. Вместо того, чтобы пытаться вручную отменить его и исправить все ошибки, вы можете вернуться к предыдущей версии, а затем повторить попытку с помощью другого решения. Git является наиболее широко используемым из этих систем управления версиями. Знание того, как использовать Git, будет требовать практически любая работа. Это один из тех важных навыков, которые необходимы разработчикам, но об этом мало кто говорит. С чего начать? Если все сказанное выше звучит довольно интересно для вас, вы, вероятно, задаетесь вопросом, с чего начать. Если вы видите себя на работе в качестве Frontend-разработчика, но не знаете, где получить необходимые знания и навыки, вы находитесь в нужном месте. На ITVDN вы найдете полную подборку видео курсов по специальности Frontend разработчик. Начните с HTML и CSS! Смотрите первый урок видео курса HTML5, CSS3 бесплатно. Если Вы сторонник традиционных форм обучения, приглашаем Вас на курс FrontEnd Developer в CyberBionic Systematics.

В свое время я работал и продолжаю работать сейчас разработчиком. Начал в качестве веб-программиста в 2004 году, перешел на полный стек в 2009 году, начал разработку для iOS в 2013. Я начал свой путь программиста с прочтения трех книг: одна была про HTML, другая – про CSS и третья, соответственно, об SQL. Прочие знания я получил из Google, Stack Overflow и блогов. Вообще, Интернет – прекрасная штука. Каждый день я прочитывал по 5 или больше тематических статьей. И, что самое главное, все эти знания были бесплатны. В основном мои знания о программировании были получены из университета и опыта работы. Как-то так. Действительно, получается, что большая часть из того, что вы изучаете о программировании, были получено в основном во время решения определенных практических задач. То, что меня также интересует – это чтение различных специализированных книг. Увы, но размеры списков по типу «Обязательных к прочтению для разработчиков» выходят далеко за рамки адекватных. Ситуация со сжатым списком из этого списка также ненамного лучшая… Каждая из книг хороша по-своему, но и целой жизни будет мало, чтобы прочитать все это. Лично меня это всегда несколько сбивало с толку, так как выбрать первую книгу для изучения становится весьма проблематично. Потому я и решил немного покопаться в списках и создать один «универсальный» список, в котором будут включены книги, общие для всех рассмотренных списков. Конечно, прочтение всех этих книг не сделает из вас профессионального программиста, но использование того, что было выучено из книг на практике – сделает. Лично я для себя решил выработать привычку прочитывать по крайней мере одну книгу в два месяца. Полный список содержит 139 книг. Все книги, которые вы увидите в этом списке, находятся на вершине популярности рассмотренных списков. В этом списке вы не найдете книгу о том, как стать Java-разработчиком, но вы можете увидеть книги, которые используют язык Java для приведения практических примеров, рассматриваемых тем. Вы сможете найти книгу, направленную на один конкретный язык программирования, но которая также пригодится и для разработчиков на других языках. Также я включил здесь книги, не связанные с разработкой непосредственно, но которые в то же время считаются неплохими для развития особого «программного» мышления. Короче говоря, без лишних слов – я рад представить: Список лучшей литературы для разработчиков 7 упоминаний: Паттерны проектирования: Элементы повторного использования программного обеспечения «Классическая книга, прочтение которой ознакомит читателя с различными паттернами программного проектирования, а также раскроет некоторые секреты наиболее популярных из них.» Джон Сонмец «Еще одно произведение классики, содержащее в себе огромную коллекцию различных паттернов программирования.» Лик Бун Код: Скрытый язык аппаратного и программного обеспечения «Должна быть в закладках у каждого, кто так или иначе связан с программной индустрией, не важно при этом – программист ли он али нет.» Вуди Леонхард «После прочтения этой книги вы поймете, что на самом деле выполняет ваш код и как на самом деле этот код исполняет процессор. Это одновременно и весело, и полезно.» Джон Сонмерц 8 появлений: Эффективная работа с правильным кодом «Я обожаю эту книгу, так как рано или поздно в один прекрасный момент программисту придётся заниматься поддержкой и разработкой уже существующих комплексных систем.» Джейсон Роял «Если вы принимаете участие над работой с большим объемным кодом более пяти лет, эта книга, вероятно, станет вашей новой Библией. Прочтите это и примите в свои сердца.» Джон Сонмерц Люди: Продуктивные проекты и команды «Эта книга оказала на меня наибольшее влияние в свое время. Пожалуй, я могу сравнить ее с эффектом от прочтения Манифеста Анти-Дилберта.» Джоел Сполски «Если вы желаете носить гордое звание тим лидера на практике, нежели на словах – эта книга определенно для вас.» Джеф Атвуд 9 упоминаний: Паттерны разработки корпоративных приложений «Книга очень полезна при разработке массивных приложений, так как она предлагает детальное объяснение ситуаций, когда нужно использовать определенный программный паттерн (а когда наоборот - нет). Даже не могу назвать примерное количеств раз, сколько мне приходилось обращается к данной книге.» Род Хилтон «Обеспечивает читателя каталогом качественных проверенных корпоративных паттернов и ситуаций, советует, когда эти самые паттерны стоит использовать.» Иан Джойс 11 упоминаний: Вступление в алгоритмы «Пожалуй, это лучшая книга для понимания и использования алгоритмов (которые де-факто являются основным инструментом разработчика программного обеспечения).» Вуди Леонхард 12 упоминаний: Чистый код: Пособник мастера программного обеспечения «Если вы пожелаете прочитать книгу, связанную с программированием, определенно – вам стоит обратить свое внимание на эту.» Роберт Грайнер «Это еще одна книга, которой удалось полностью изменить стилистику написания моего кода. Я могу ясно разделить свою жизнь на период до прочтения книги и после.» Джон Сонмерц Рефакторинг: Улучшение дизайна существующего кода «Книга, строго рекомендуемая к прочтению для каждого, кто желает улучшить качество кода.» Деепак Карантх «Обязательна к прочтению каждому, кто так или иначе принимает участие в работе с объектно-ориентированными языками программирования.» Дэниель Рид 14 упоминаний: Мифический человеко-месяц, или Как создаются программные системы «Это классика, но недавно исправленная и дополненная. В высшей степени поразительно то, как она тесно связана с разработкой программного обеспечения. Если вы принимаете участие в программировании, определенно эта книга – обязательна к прочтению.» Джейсон Роел «Бесспорно, единственная классика, посвященная программированию. Позор всякому, кто еще не прочитал ее.» Джеффри Атвуд 15. упоминаний: Прагматичный программист: От новичка к мастеру «Насколько революционна эта книга? Пожалуй, достаточно для того, чтобы развернуть целую издательскую кампанию. Если вы все еще не прочитали ее – это, бесспорно, большое упущение с вашей стороны.» Род Хилтон «Эта книга не только изменит ваш код: она изменит вас как программиста. Наполненная практическими советами по улучшению вас и вашего кода, бесспорно, является отличным приобретением для каждого, кто хочет стать лучшим в сфере разработки программного обеспечения.» Деепак Карант 16 упоминаний: Идеальный код: Практическое пособие по программной архитектуре «Сделайте для себя приятное. Пусть это будет первой книгой, которую вы прочитаете – и первой книгой, которую вы посоветуете другим.» Джеффри Атвуд «Эта книга потрясла меня больше всего. Определенно, после ее прочтения то, как я писал код, и то, что я думал о программировании в целом, претерпело серьезные изменения.» Джон Сонмец   Полный список содержит в себе 139 книг. При желании на языке оригинала его можно рассмотреть здесь. Автор перевода: Евгений Лукашук Оригинал статьи

Приветствую, меня зовут Бобровников Дмитрий, я занимаюсь программированием уже более 4-х лет, из которых первые 2 года учил объектно-ориентированный язык программирования C#, а сейчас занимаюсь разработкой игр на Unreal engine 4. Когда я начинал программировать на движке Unreal engine 4, в то время не было толковой информации по программированию на этом движке, приходилось сталкиваться с определенными трудностями, точнее нехваткой информации, чтобы в дальнейшем нормально работать с этим движком. Конечно, сейчас ситуация стала меняться и уже есть русскоязычные уроки и документация, но особой пользой и информативностью они не отличаются. Также прямо сейчас я работаю над большим “Survive” проектом, пишу всю пользовательскую логику, все изображения взяты именно с этого проекта, подробно вы можете увидеть уроки и процесс создания этого проекта, с какими трудностями я сталкиваюсь и как их решаю на моем youtube канале. https://www.youtube.com/channel/UCZSMGDBh87VmNv0apC6VcCQ И сегодня мы с тобой познакомимся с созданием игр на Unreal engine 4. Кто из нас не мечтал о создании собственной игры! Создание игр - это сложный и трудоёмкий процесс, давай поговорим об этом. Весь процесс создания игры, после выбора движка, начинается с идеи “концепта игр”, то есть сначала полностью на бумаге придумывается игра, после этого ты расписываешь все по пунктам, что нужно будет сделать в игре (от того, что нужно создать меню игры и уровень для него, создать персонажа и т.д.) как можно более широко, для того чтобы у тебя было полное представления о том, что ты будешь писать и какая игра в итоге у тебя получится,  после тебе нужно определиться, какой язык программирования ты будешь использовать. Unreal engine 4 предоставляет два языка программирования: это С++ и Blueprint (язык программирования движка, написанный специально для него). Весь процесс мы с тобой будем рассматривать на примере моего нынешнего проекта игры. Языком для этого проекта был выбран Blueprint, так как он почти не уступает плюсам и имеет в себе более наглядное программирование, чем тот же C++, и подойдет людям, которые только начинают изучать движок и знакомиться с программированием, плюс к этому он не позволит наделать ошибок, возможных на языке C++, и он будет гораздо понятнее для новичков. Так что после запуска движка при создании проекта мы выбираем языком программирования “Blueprint” и выбираем одну из заготовок проекта, их достаточно много, можете сами в этом убедиться, вы выберете то, что вам потребуется, я же выбрал проект от третьего лица. Первой моей задачей стало написание игрового меню и настроек игры. Ты можешь видеть, как я это реализовал (не следует сразу бросаться и писать основную логику игры, а начать нужно последовательное выполнения поставленных тобой задач). Само игровое меню поделено на несколько визуальных интерфейсов “Widget”, это условно (Главное меню, Обшей Widget настроек и каждый отдельный Widget настройки управления, графики и т.д.), причем такое меню не требует глубоких знаний в программировании, если ты используешь язык “Blueprint”, так как все настолько упрощено и интуитивно понятно, на этом моменте не возникает трудностей, достаточно знать основы в программировании. Следующим шагом было реализация игрового персонажа. Благо, Unreal engine 4 предоставляет нам заготовку под персонажа, что полезно как профессионалам, так и новичкам, что позволяет не тратить время на начальную настройку персонажа, а просто добавлять в нее изменения так, что мы этим и воспользуемся, впоследствии заменив модель и анимации. Мы идем по пунктам и следующим шагом была реализация интерфейса пользователя ”игрока” (таких как жизненный показатель, голод, здоровье и выносливость, чтобы создать некую сложность для игрока, так как ему придется следить за этими показателями и своевременно их пополнять, это уже геймплейная составляющая игры). После этого можно уже приступать к различным логикам и системам будущей игры. Я начал с системы инвентаря, сначала сделал визуальный интерфейс, а потом написал логику для него, но такие системы довольно сложные и не стоит ставить вопрос, как написать или сделать систему инвентаря, а поставить перед собой другую задачу, например, что будет у каждого предмета (имя, картинка, количество и т.д.), таким образом дела пойдут гораздо быстрее и в итоге можно получить желаемый результат. После проверить на наличие каких-либо ошибок, исправить, если такие имеются, и постараться максимально оптимизировать код, далее ты следуешь своему плану, который ты расписал, и, таким образом, по выполнении всех пунктов твоего плана ты получишь готовую игру.

В рамках сегодняшней статьи я рад представить новый экспериментальный проект от команды ASP.NET под названием Blazor. Что такое Blazor? Blazor – это экспериментальный веб UI – фреймворк на базе C#, Razor и HTML, который работает непосредственно в браузере посредством WebAssembly. Цель эксперимента – в значительной мере упростить задачу построения простых и качественных одностраничных приложений, которые могут быть запущены в рамках любого браузера. Достигается это за счет написания .NET веб-приложений, которые при помощи открытых веб-стандартов могут запускаться на стороне клиента. В случае если вы уже работаете с .NET, подобный подход открывает перед вами следующие перспективы: вы сможете использовать навыки разработки браузерных приложений в дополнение к существующим сценариям серверных, облачных, нативных и игровых приложений. Однако, даже если вы непосредственно с .NET не знакомы, мы надеемся, что Blazor подтолкнет к его изучению. Зачем использовать .NET для браузерных приложений? Хотя веб-разработка за прошедшие годы значительно упростилась, создание современных веб-приложений - задача далеко не всегда тривиальная. Построение же веб-приложений на базе .NET предоставляет уникальную возможность улучшить качество написания подобного рода программ. Среди основных преимуществ стоит выделить: Стабильность и целостность: инструменты стандарта .NET на протяжении многих лет зарекомендовали себя в качестве надежных помощников при разработке приложений. Современные инновационные языки: с использованием C# и F# процесс создания программ, по сути, становится чем-то вроде развлечения, настолько широким спектром возможностей эти языки обладают. Популярная среда разработки: стек IDE Visual Studio обеспечивает максимальное удобство работы с Windows, Linux и macOS. Быстрота вычислений: .NET обладает длинной историей по улучшению производительности, надежности и защиты веб-приложений для серверов. Соответственно, при разработке full-stack .NET приложений все указанные преимущества также ощущаются. Browser + Razor = Blazor! Blazor базируется на существующих веб-технологиях, таких как HTML и CSS, но в этом случае для создания UI-элементов вы используете C# и Razor – синтаксис вместо JavaScript. Однако отметьте, что это не то же самое, что и деплой существующего проекта UWP или Xamarin в браузер. Blazor будет обладать всеми ключевыми особенностями современных веб-фреймворков, включая: Компонентную модель для построения комплексных UI Маршрутизацию Слои Формы и валидацию Внедрение зависимостей Поддержку JavaScript Перезагрузку в браузере во время разработки «вживую» Рендеринг на стороне сервера Полноценную поддержку .NET – отладки (как в браузере, так и в IDE) IntelliSense и прочие различные инструменты Возможность запускать более старые (не WebAssembly) браузеры через asm.js Публикацию и мониторинг размера приложения Изменения WebAssembly Запуск .NET – приложений в браузере стал возможен благодаря WebAssembly, новому веб-стандарту для «портативных, умеренных в размерах и быстрых» веб-приложений. Таким образом, WebAssembly вводит фундаментально новый способ построения веб-приложений, так как код, скомпилированный под WebAssembly, не уступает скорости нативных .NET-приложений. Никаких прочих сторонних зависимостей нам не нужно: вы можете запустить обычные .NET-сборки в браузере с использованием WebAssembly. В августе прошлого года наши друзья из команды Xamarin Microsoft анонсировали планы по созданию Mono .NET специально для браузеров с использованием все той же WebAssembly. По сути, Blazor частично базируется на результатах их работы. Новый эксперимент Сейчас мы восхищаемся возможностями Blazor-технологии, но не стоит забывать, что сейчас это лишь экспериментальная технология, а не официально выпущенная и готовая для полноценной работы. На этой стадии мы можем более глубоко ознакомиться с основными функциональными возможностями представленной технологии, а также выразить свои замечания и пожелания разработчикам. Я хочу попробовать! Найти технологию вы можете в Blazor repo, который сейчас доступен для использования. Это проект с полностью открытым исходным кодом: все текущие изменения и дополнения могут быть отслежены в вышеупомянутом репозитории. Пожалуйста, отметьте, что технология находится в статусе раннего доступа. Здесь еще нет никаких инсталляторов или шаблонов проектов, кроме того, многое из заявленного еще не реализовано. Даже то, что уже сделано, не оптимизировано. Если вам интересно, вы можете загрузить репозиторий, построить его и протестировать, но пытаться на его базе разработать рабочий проект – задумка явно не удачная. Что же касательно предложений и поддержки, вы можете использовать issue tracker репозитория. Через месяц мы планируем выпустить первые черновые версии заготовок веб-проектов и инструментов, сделав технологию более доступной для широкой аудитории. Автор перевода: Евгений Лукашук Источник

Я был свидетелем многих вопросов, связанных с Subject`ами на Stack Overflow. Недавно я увидел одного разработчика, который интересовался, как, собственно говоря, работает AsyncSubject. Вопрос заставил меня написать эту статью, чтобы показать, почему необходимо использовать различные типы Subject`ов и как их использовать.   Когда мы используем Subject`ы? В своей статье Бен Леш утверждал, что: … [мультикастинг] является основной причиной использования Subject`ов в RxJS. Что касательно мультикастинга, мы рассмотрим его более подробно немного позже. Сейчас же нам достаточно знать, что он позволяет принимать оповещения от одной «наблюдаемости» и отправлять их другим «наблюдателям». Подобная связь «наблюдаемости» с «наблюдаемыми» и есть сутью Subject`ов. Причина этого заключается в том, что де-факто Subject`ы являются одновременно «наблюдаемостью» и «наблюдателями».   Как они могут быть использованы? В качестве примера давайте рассмотрим компонент Angular awesome-component. Наш компонент выполняет определенную работу и содержит в себе внутреннюю «наблюдаемость», что производит определенное значение при работе с ней пользователя. Чтобы позволить родительским компонентам получить доступ к «наблюдаемости», awesome-component принимает «наблюдателя», что вводит свойство и что подписывается, в свою очередь, на «наблюдаемость». Это значит, что отныне родитель может соединиться с «наблюдаемостью» при помощи спецификации «наблюдателя» - что-то наподобие этого: Так как теперь «наблюдатель» «обвязан», родитель соединен и получает значения от awesome-component. Впрочем по сути это то же самое, как  если бы awesome-component производил значения через подписанные события. Так почему же мы здесь не используем события? Дело в том, что «наблюдаемостями» проще управлять. К примеру, чтобы добавить фильтры, нам необходимо использовать лишь несколько операторов. Но немаловажный нюанс: родительский компонент имеет «наблюдателя» – не «наблюдаемость», так как в таком случае мы можем применять операторы? Subject`ы - это одновременно и «наблюдаемости», и «наблюдатели», поэтому, когда мы создаем Subject, он может быть использован по отношению к awesome-component в качестве «наблюдателя» или работать с компонентом как с «наблюдаемостью». Что-то наподобие этого: Subject соединяет «наблюдателя» по принципу «делай-все-что-хочешь-со-значением» с «наблюдаемостью» в виде awesome-component. Но здесь применяется набор операторов родителей компонента.   Композиция различных «наблюдаемостей» При помощи Subject`а для композиции «наблюдаемости» awesome-component может быть использован в разных целях разными компонентами. К примеру, другой компонент может быть заинтересован только в последнем сгенерированном значении. Для этого нужно использовать last-оператор: Что интересно, это не единственный способ получения последнего значения: мы просто можем использовать другой Subject. К примеру, при помощи AsyncSubject код будет выглядеть следующим образом, так как он производит только последнее полученное значение: Но, если использование AsyncSubject равнозначно композиции «наблюдаемости» при помощи использования Subject и last-оператора, зачем усложнять RxJS лишним классом? Ну, в основном потому что Subject`ты предназначены для мультикастинга. В данном случае два способа эквивалентны, потому что здесь есть только один подписчик. В ситуации с применением мультикастинга здесь было бы несколько подписчиков и применять оператор last здесь было бы нецелесообразно. Теперь же давайте рассмотрим мультикастинг более детально.   Как Subject`ы используются непосредственно в RxJS? Ядро инфраструктуры мультикастинга RxJS исполняется при помощи оператора multicast. Multicast вообще применяется к ключевым «наблюдаемостям», принимает Subject и возвращает полученную из Subject`а «наблюдаемость». Оператор multicast чем-то похож на awesome-component. Мы можем принимать «наблюдаемость», чье поведение зависит от принимаемого Subject`а. Ситуации, когда базовый Subject передается multicast: Подписчики мультикаст-«наблюдаемости» принимают оповещения типа next, error, complete. «Поздние» подписчики , другими словами, те, которые подписались после оповещений error, complete, – так же в свою очередь принимают эти оповещения. Важно отметить, что пока мультикастинг не передал factory, «поздние» подписчики не работают с другими подписками на источник. Чтоы произвести композицию по отношению к мультикаст-«наблюдаемости», что передает последнее оповещение next ко всем подписчикам, недостаточно просто применить last-оператор к «наблюдаемости», созданной при помощи Subject. «Поздние» подписчики подобной «наблюдаемости» не получат последнее next-оповещение. Они получат только complete. Специально для этого оповещения должны храниться в состоянии Subject`а. Именно это делает класс AsyncSubject и именно для этого мы используем AsyncSubject в подобной ситуации.   Что касательно других классов Subject`ов? Существует двое других вариантов Subject`ов: BehaviorSubject и ReplaySubject. Чтобы понимать BehaviorSubject лучше, давайте рассмотрим пример: Здесь родительский компонент соединяется с awesome-component при помощи Subject и применяет оператор startWith. Этот оператор обеспечивает надежный прием значения “awesome” вместе со значениями, сгенерированными awesome-component – в случае, конечно, если они таки были сгенерированы. Подобно тому, как AsyncSubject используется вместо обычного Subject`а и оператора last, BehaviorSubject может заменить собой оператора startWith и Subject`а – так как его конструктор принимает значение, которое было бы в противном случае направлено к startWith. В случае с использованием BehaviorSubject все подписчики получат начальное значение. Это возможно потому, что BehaviorSubject хранит значение переменной в своем состоянии. По той причине, что концепция «переигрывания» уже полученных оповещений внедрена в мульти-подписку, аналогии с единым подписчиком для ReplaySubject просто не существует. Так же, как и BehaviorSubject, переменные хранятся в состоянии Subject`а.   Итак, как мы используем эти Subject`ы? Мы увидели, какие бывают Subject`ы и для чего они используются. Но как они должны быть использованы? Что ж, как бы это ни было парадоксально, но класс Subject – это тот класс, который вам, вероятно, никогда не придётся использовать. Subject работает прекрасно при связывании «наблюдателя» с «наблюдаемостью». Но для ситуаций с мультикастингом существуют альтернативы. RxJS содержит операторы мультикастинга, которые используют различные Subject – классы, причем точно так же, как я могу использовать генераторы «наблюдаемостей» RxJS (fromEvent) над вызовами Observable.create. Но для ситуаций с мультикастингом я все же предпочитаю использовать следующие операторы: Publish или share могут быть использованы вместо Subject; publishBehavior может быть использован вместо BehaviorSubject; publishLast может быть использован вместо AsyncSubject; publicReplay или shareReplay могут быть использованы вместо ReplaySubject.   Автор перевода: Евгений Лукашук Источник

Добро пожаловать в наш небольшой сборник советов от ведущих разработчиков на платформе 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 – Ваше все! А какую среду автоматического тестирования используете Вы? Что хорошего и что не очень Вы могли бы о ней сказать? Пожалуйста, приобщайтесь к дискуссии в комментариях! 😊 Автор перевода: Евгений Лукашук Оригинал статьи