Junior 1.1 Теория тестирования. 1.2 AQA      1.2.1 Программирование и Selenium      1.2.2 TestNG/JUnit, Git, CI              1.3 Web              1.4 Mobile              1.5 Практические задания   Middle 2.1 Теория 2.2 AQA      2.2.1 Selenium      2.2.2 Тестовая инфраструктура 2.3 Web 2.4 Mobile 2.5 Практические задания   Senior 3.1 Теория 3.2 Практические задания     Дорогие друзья! Предлагаем вашему вниманию перевод статьи, опубликованной на DOU.ua 12 января 2022 года. Оригинальная версия на украинском языке доступна по ссылке. Эту подборку вопросов, которые ставят кандидатам разных уровней на технических собеседованиях на позицию QA, составили совместными усилиями практики. Список – лишь ориентир. Кандидатам советуем пробежаться по вопросам и отметить неизвестные слова, погуглить и заодно повысить шансы пройти собеседование. Интервьюерам – пополнить свой запас интересных вопросов. Но не переборщите :) Если вы не претендуете на позицию QA, просмотрите переводы подборок вопросов по другим популярным IT-специальностям.   Junior   Теория тестирования 1. Что такое тестирование? 2. Зачем тестировать ПО? 3. Какие существуют этапы тестирования? 4. Какие типы тестирования можете назвать? 5. Какие уровни тестирования знаете? 6. Какие техники тест-дизайна знаете? 7. Что такое техника анализа классов эквивалентности? 8. Что такое техника анализа предельных значений? В чем ценность этой техники? 9. Что такое Regression и Confirmation тестирование, какая между ними разница? 10. Как часто следует проводить регрессионное тестирование продукта? 11. Какие бывают виды интеграционного тестирования? 12. Что такое Configuration Testing? 13. Что такое Exploratory Testing? 14. Какие существуют UI-стандарты? 15. Что такое Black/Grey/White Box Testing? 16. Что такое Performance Testing? 17. Что такое Smoke и Sanity тестирование и какая между ними разница? 18. Что такое Traceability Matrix? 19. Что такое Sanity Testing? 20. Что такое End-to-End тест? 21. Что такое тестирование безопасности? 22. Что такое испытание на основе рисков? 23. Что такое динамическое тестирование? 24. Что такое «парадокс пестицида»? 25. Опишите основные фазы STLC? Дайте определение Entry и Exit Criteria. 26. Что такое Bug, Error, Failure, Fault? 27. Какие есть атрибуты баг-репорта? Какие основные поля для заполнения? 28. Какова разница между приоритетом и серьезностью? 29. Приведите примеры серьезного, но не приоритетного бага. 30. В чем разница между валидацией и верификацией? 31. Зачем нужна тестовая документация? Какие её виды? 32. Что такое тест-план? Какие элементы у него есть? 33. Какую обязательную информацию должен содержать тест-план? Как правильно его использовать, поддерживать и нужен ли он вообще для большинства проектов? 34. Какая разница между чеклистом и тест-кейсами? 35. Приведите пример хорошего тест-кейса.   Ответы на некоторые из этих вопросов вы можете найти в видео курсе QA Стартовый (урок 1, урок 3, урок 4, урок 5), Основы тестирования (урок 6), Основы тестирования ПО (урок 1-5), а также в вебинаре “QA практикум. Техники тест дизайна” (часть 1 и часть 2).   AQA (Automation QA)   Программирование 36. Что такое ООП? Назовите его принципы с примерами? 37. Что такое интерфейс? Что такое абстрактный класс? Чем они отличаются? 38. Что такое SOLID? Приведите примеры. 39. Что такое DRY, KISS, YAGNI? 40. Какие паттерны GOF вам известны? Приведите примеры их использования. 41. Что такое PageObject и PageFactory? 42. Какая иерархия Collections? 43. Какая разница между Thread class и Runnable interface? 44. Какая разница между String, Stringbuffer и Stringbuilder? 45. Разница между final, finally и finalize?   Selenium 46. ​​Что такое Selenium и зачем его используют? 47. Что такое драйвер браузера? 48. Какие виды локаторов страницы существуют? Каковы их преимущества и недостатки? 49. Что такое Selenium Waits? Какие есть и чем отличаются? 50. Какие exceptions может бросить Selenium? Что они означают и как их обрабатывать? 51. Для чего используют JavaScriptExecutor? Приведите примеры. 52. Что такое Selenium Grid? 53. Какие способы click и send keys Selenium? 54. Как вы запускаете параллельное выполнение тестов? Что такое ThreadLocal? 55. Какая разница между Action и Actions? 56. Как написать метод isElementPresent? 57. Как вычитать данные из динамической веб-таблицы? 58. Можете ли вы назвать 10 интерфейсов в Selenium? 59. Назовите два способа, позволяющих автоматизировать капчу. 60. Вспомните типы навигационных команд Selenium. 61. Как найти поврежденные ссылки в Selenium WebDriver? 62. Какую технику следует рассмотреть, используя весь сценарий, если «нет ни frame id, ни frame name»?   Ответы на некоторые из этих вопросов вы можете найти в видео курсах Web Testing Automation on Java (урок 1), Автоматизация тестирования мобильных приложений (урок 5), а также в вебинаре “Selenoid или Selenium Grid — что лучше?”.   TestNG/JUnit 63. Для чего нужны TestNG/JUnit? 64. Какие инструкции используются в TestNG/JUnit? 65. Какие assertions есть в TestNG/JUnit? 66. Как выполнять тесты параллельно TestNG/JUnit?   Ответы на некоторые из этих вопросов вы можете найти в видео курсе Web Testing Automation on Java (урок 4).   Git 67. Для чего используют системы контроля версий? 68. Что такое Git? Каков принцип его работы? 69. Что такое commits, branches в Git? 70. Для чего нужны GitHub, GitLab и другие, базирующиеся на Git, вебхостинги проектов?   Ответы на некоторые из этих вопросов вы можете найти в видео курсе Основы работы с Git.   CI 71. Что такое CI? 72. Как автоматическое тестирование интегрируется в CI? 73. Как настроить Job или Pipeline на знакомом вам CI-инструменте? 74. Какие инструменты для генерации репорта после выполнения автоматических тестов вы знаете? 75. Какую информацию должен содержать отчет о выполнении автоматических тестов?   Ответы на некоторые из этих вопросов вы можете найти в видео курсе Web Testing (урок 4).   Web 76. Что такое клиент-серверная архитектура? 77. Что может выступать в роли клиента? 78. Что такое REST API, SOAP? В чем разница? 79. Какие протоколы передачи данных знаете? 80. Какие способы взаимодействия с API существуют? В чем разница между ними? 81. Как можно протестировать API, что там нужно проверять? 82. Как расшифровывается CRUD? 83. Чем отличается GET от POST? 84. Какие отличия между XML и JSON? 85. Какие знаете форматы передачи данных? 86. Как происходит шифрование? 87. Какие бывают виды баз данных? 88. Охарактеризуйте каждый класс status code (1хх; 2xx; 3xx; 4xx; 5xx). 89. Какие есть HTTP-методы? 90. Какие знаете Web elements? 91. Какие браузеры знаете? В чем их отличие? 92. Для чего необходимы инструменты разработчика в браузере (Chrome DevTools) и как они помогают в тестировании. 93. Что такое кэш? 94. Что такое сессия? 95. Зачем нужны cookies? 96. Что такое фрейм? 97. Что такое HTML/CSS/JavaScript? 98. Какую структуру имеет веб-страница? 99. Зачем чистить кэш? 100. Какие виды тестирования можно применить только к Web? 101. Для чего в веб-страницах используют JavaScript? 102. Что такое REST? 103. Что такое AJAX?   Ответы на некоторые из этих вопросов вы можете найти в видео курсах QA Стартовый (урок 6), Web Testing, SQL Базовый.   Mobile 104. Какие мобильные платформы существуют? 105. Какие версии Android и iOS используются на рынке (минимальные и максимальные)? 106. Какие версии Android нужно тестировать, если заказчик сказал поддерживать с версии 5.0? 107. Назовите типы мобильных приложений. 108. Каков формат файлов сборок приложений для Android и iOS? 109. Что такое ADB? 110. Как снять логи с AOS/IOS? 111. Что нужно проверять при использовании сканера отпечатка/Face ID? 112. Как я могу запускать тесты Android без Appium? 113. Объясните концепцию дизайна Appium.   Ответы на некоторые из этих вопросов вы можете найти в видео курсе Автоматизация тестирования мобильных приложений.   Практические задания 114. Написать чеклист для функционала корзины в интернет-магазине. 115. Написать тестовые наборы данных для поля ввода даты, которое отсеивает пользователей в возрасте до 18 лет. 116. Написать чеклист тестирования формы ввода данных платежной карты. 117. Протестовать «предмет» относительно различных видов тестирования. (Предмет - лифт, карандаш, калькулятор и т. д.) 118. Есть Input поле, принимающее целые значения от 18 до 99 включительно. Надо протестировать с помощью техники тест-дизайна Boundary Values ​​Analysis и Equivalence Partitioning. 119. Есть веб-страница с полями: e-mail, password и кнопкой submit. Необходимо привести примеры отрицательных тест-кейсов, которыми можно проверить эту страницу. 120. Привести примеры тест-кейсов для функционала, находящегося на нескольких страницах проекта (например, поле поиска). 121. Как протестировать процесс оплаты в интернет-магазине? 122. Как протестировать сломанный тостер? 123. Объясните для 7-летнего ребенка, что такое база данных. 124. Определите необходимое количество функциональных тест-кейсов, чтобы проверить Log in форму. 125. Есть форма регистрации в веб-приложении с полями (first name, last name, username, password, repeat password) и кнопкой Register. Какие проверки нужно провести? 126. Поле username должно быть обязательным, но оно не является обязательным. Приведите пример баг-репорта, созданного для этой ошибки. 127. Как бы вы провели smoke-testing для приложения типа Telegram? 133. Как будет выглядеть баг-репорт, если, к примеру, не работает электрический чайник? 128. Есть таблица books с полями: name, price, page_count. Следует выбрать все имена книг, в которых price более 10 единиц и количество страниц от 20 до 100. 129. У вас есть функционал калькулятора, который доступен через веб-браузер по ссылке. Он имеет только функцию делить, так сказать, MVP-версию. Диапазоны для вписывания в числитель и делитель от 0,1 до 99,9. Вывод значения происходит автоматически, потому что front-end реализован на React JS. Как вы будете тестировать этот функционал? Какие виды тестирования примените? Какие техники тест-дизайна используете?     130. Задание на работу с SQL.   извлечь номер телефона и адрес пользователя Muzik. Извлечь данные о пользователях, имеющих сумму заказа более 2000 грн. Подсчитать количество заказов в таблице и общую сумму сделанных заказов.     131. Ваша компания разрабатывает программное обеспечение для медицинских систем, и вы тестируете компонент, управляющий дефибриллятором сердца. Вы заметили, что одно решение в тестовом модуле состоит из 34 независимых атомарных условий. Какой метод тестирования белого ящика следует выбрать для этого и почему? 132. Оздоровительная программа для сотрудников совмещена с оплатой медицинского страхования и имеет следующие правила:   сотрудники, потребляющие 17 единиц или менее алкоголя в неделю, получают $28 скидки на оплату. Для сотрудников, которые заполнят «Оценку риска для здоровья», оплата уменьшается на $23. Сотрудники, участвующие в ежегодном контроле за состоянием здоровья в компании: получат скидку на $50 за то, что имеют индекс массы тела (ИМТ) 25,5 или менее, и $19 скидки при ИМТ ниже 30. Некурящие получают дополнительную скидку на $46. Курильщики, присоединившиеся к курсу отказа от курения, получают скидку в $24. Курильщики, не присоединившиеся к курсу отказа от курения, оплачивают дополнительно $75.   133. Используя технику классов эквивалентности, сколько тестов нужно написать, чтобы покрыть вышеупомянутые условия на 100%? 134. Какое минимальное количество тестов необходимо для покрытия следующих условий автогражданки:   лица до 18 лет не застраховываются. Для мужчин на красном авто прибавляется +15% к стоимости полиса. Для женщин от 18 до 64 лет страховая премия 1000 грн. Для мужчин от 18 до 64 лет страховая премия 1200 грн. Для лиц старше 64 лет страховая премия 1800 грн.   135. Напишите сценарии автоматического тестирования для сортировки по цене и добавлению товара в корзину на сайте. К вашим тестам добавьте документацию с настройками и разместите ваше решение на GitHub.   Middle   Теория 1. Назовите обязанности QA? 2. Что знаете о тестировании нагрузки? В каком случае следует проводить такое тестирование? На каком этапе готовности продукта? 3. Что такое таблица решений/decision table и как её можно использовать? 4. Что может быть критериями запуска и завершения тестирования? 5. Расскажите о вариантах интегрирования тестовой документации в проект, инструментах для работы с ней. 6. Как организовать сквозное тестирование (e2e)? 7. Какие тест-кейсы можно сдать для тестирования баз данных? 8. Приведите примеры подходов для тестирования локализации. 9. Что такое A/B тестирование? 10. Что такое mock/stub? Какие знаете инструменты для работы с ними? 11. Когда нужно использовать технику Pairwise? 12. Что такое fuzz-тестирование и где его используют? 13. Что такое REgexp? 14. Как меняется стоимость дефекта при тестировании программного обеспечения? 15. Каковы пути анализа бизнеса клиента? Как определить целесообразность того или иного функционала? 16. Назовите последовательность выполнения CI/CD процесса на проекте. 17. Какое должно быть процентное соотношение между положительным и отрицательным тестированием на проекте? 18. Какой вид тестирования целесообразнее проводить до релиза? 19. Есть ли разница между bug leakage и bug release? 20. Может ли быть ситуация, когда критерии завершения (exit criteria) не выполнены? Что должно происходить в этом случае? 21. Что мы действительно должны покрывать тест-кейсами, а что считается избыточным расходом времени и денег? Когда нецелесообразно писать тест-кейсы? 22. Для какого функционала труднее всего написать тест-кейсы? 23. Как посчитать Cyclomatic complexity? 24. В чем основная разница между defect detection percentage и defect removal efficiency? 25. Какие модели risk-based testing вы знаете? 26. Что такое тестирование API? Какими инструментами пользуются для его выполнения? 27. Что такое performance testing? Какими инструментами пользуются для его выполнения? 28. Что такое load и stress testing? Какими инструментами пользуются для их выполнения? 29. Что такое contract testing? 30. Какая разница между Scrum и Kanban? 31. Расскажите о ритуалах, ценностях и ролях в Scrum. 32. Как выбор методологии может повлиять на качество разработки? 33. Нулевой спринт в Scrum. Для тестирования есть задание под названием «Настройка среды». Что здесь нужно выполнять?   Ответы на некоторые из этих вопросов вы можете найти в видео курсах Web Testing, QA Стартовый, “Методология управления проектами. Вступление в SCRUM”.   AQA   Selenium 34. Расскажите, как вы будете строить и внедрять стратегию по автоматизации тестирования. 35. Как взаимодействуют клиентская библиотека Selenium, драйвер браузера и сам браузер? 36. Для чего используют browser capabilities, arguments и options? 37. Что такое iframe и как с ним работать в Selenium? 38. Как обрабатывать браузерные сообщения (alerts)? 39. Что такое Appium? 40. Что такое Electron-based applications? Как использовать Selenium и Appium для их тестирования? 41. Как взаимодействовать с запросами, отправляемыми из браузера? 42. Как взаимодействовать с cookies, LocalStorage и SessionStorage?   Ответы на некоторые из этих вопросов вы можете найти в видео курсе Web Testing Automation on Java (урок 1) и Автоматизация тестирования мобильных приложений.   Тестовая инфраструктура 43. Что такое и чем отличаются виртуальная машина, симулятор и эмулятор? 44. Что такое контейнер и чем он отличается от виртуальной машины? 45. Как используют виртуальные машины и контейнеры в автоматизации? 46. ​​Что такое IaaS и PaaS? Приведите примеры. 47. Что такое Configuration Management? 48. Что такое Provisioning? 49. Какие команды Linux Shell вам известны? Как с помощью команд Linux Shell найти лог-файл и строчку с ошибкой в ​​файле? 50. Какие команды Windows CMD вам известны? Как с помощью команд Windows CMD найти IP-адрес машины? 51. Что такое SSH и как им пользоваться? 52. Что такое bash и batch скрипты? Зачем их используют?   Web 53. Какая разница между авторизацией и аутентификацией? 54. Как происходит авторизация на сервере? 55. Какие статус-коды ошибок бывают? Может ли сервер отправить код 400, если проблема на его стороне? 56. Как выполнить Debug страницы в браузере? 57. Как протестировать адаптивную верстку? 58. Что такое WebSocket и как проверить обрыв соединения? 59. Каковы есть основные виды уязвимости веб-приложений? 60. Какие инструменты для тестирования Web performance client-side знаете? 61. Какова разница между методами GET и POST? 62. Какая разница между методами PUT и PATCH? 63. Какие знаете сниферы? 64. Какова разница между DROP и TRUNCATE? 65. Что такое case function? 66. Что такое collation? 67. Что такое схема GraphQL? 68. Объясните разницу между OLTP и OLAP. 69. Вспомните разные типы репликации в SQL Server? 70. Что вы понимаете под Self Join? Приведите примеры. 71. Что такое cursor и как им пользоваться?   Ответы на некоторые из этих вопросов вы можете найти в видео курсах Web Testing Automation on Java, SQL Базовый.   Mobile 72. Что основное нужно проверить при тестировании мобильного приложения? 73. Что такое Manifest.xml в .apk файле и какие данные там указывают? 74. Что такое режим разработчика Do not keep activities? 75. Как происходит перехват трафика http/https для мобильных устройств? 76. В каком виде хранятся данные в мобильных приложениях локально? 77. Как тестировать миграцию локальных данных? 78. Каковы основные компоненты Android-приложений (активити / фрагмент / сервис / интент-фильтр)? 79. Опишите жизненный цикл активити. 80. Что такое утечки памяти? Как найти? 81. Как протестировать билд на Android? 82. Что такое Testflight? Как тестировать с его помощью? 83. Как работает Android? Какая у него архитектура? 84. Как происходит деплой программ IOS/AOS?   Ответы на некоторые из этих вопросов вы можете найти в видео курсе Автоматизация тестирования мобильных приложений.   Практические задания 85. Что делать, если разработчик не соглашается, что указанный баг действительно является багом? А если в требованиях использована неоднозначная формулировка? Если бизнес-аналитик, PM и представитель клиента сейчас недоступны, чтобы подсказать? Как можно предотвратить такую ​​ситуацию? 86. Сложилась ситуация, когда команда тестирования не успевает закончить свою работу в дедлайн. Как правильно действовать в этом случае? А если релиз передвинуть нельзя? А если никакие фичи из релиза забрать нельзя? 87. Что делать, если проект уже начался, а QA-инженер там начал работать только когда начали разрабатываться бизнес-фичи? Какие этапы тестирования теперь нужно наверстать и нужно ли это? Как это сделать максимально грамотно без ущерба для загрузки по тестированию новых фич? Какие риски имеет позднее вовлечение QA-инженера в разработку? 88. Веб-страница с полями e-mail, password и кнопкой submit. Назовите отрицательные тест-кейсы, по которым можно проверить эту страницу. 89. Предположим, что после нажатия кнопки submit страница перезагружается и ранее введенные данные исчезают. Как проверить, что информация отправлена ​​в базу данных? 90. Как проверить, что данные отправились на сервер, если у нас нет доступа к бэкенду? 91. Приведите примеры улучшений для приведенной веб-страницы (любая на выбор). 92. Составить Smoke Test Suite для DOU.ua. 93. Протестовать функционал банкомата с помощью техники State Transition Diagram. 95. Написать предельные значения для ввода в форму оплаты товара на сайте. 96. Есть метод POST, который регистрирует нового пользователя на сайте, есть тело запроса, содержащее данные о почте, телефоне, имени пользователя и адресе проживания. Какие кейсы для проверки можете привести? 97. На что следует акцентировать внимание при автоматизации методов API? Что следует проверять? 98. Вы тестируете логин-форму, вводите логин и пароль, нажимаете кнопку логин и ничего не происходит. Ваши действия? 99. В течение 5 минут найдите и опишите дефекты, которые вы видите:     100. Вам нужно сделать Regression Testing за два дня. Как вы это сделаете, если Regression Run охватывает 1000 тест-кейсов? 101. Вы тестируете интернет-магазин, который продаёт карандаши. В заказе нужно указать количество карандашей (максимум для заказа – 1000 штук). В зависимости от заказанного количества карандашей отличается цена:   1–100 – 10 грн за шт. 101-200 – 9 грн за шт. 201-300 – 8 грн за шт.   С каждой новой сотней цена уменьшается на 1 гривну. Задание: используя тест-дизайн, опишите все необходимые тест-кейсы, которые будут максимально покрывать описанную функциональность.   102. Есть приложение типа мессенджера, пользователь заходит в чат и отсылает файл (видит сообщение Failed to send...) Когда это может быть баг, а когда нет? 103. Есть веб-приложение интернет-магазина (регистрация, логин, поиск товаров, корзина и покупки). Программу поддерживают следующие браузеры: Chrome, Safari, Edge. У нас есть ограниченное время на тестирование. Расскажите, как вы будете проверять приложение? 104. Напишите автоматические тестовые сценарии для проверки API операций создания и просмотра GitHub Gists. Интегрируйте ваш проект с известной вам CI-системой.   Senior   Теория 1. Как вы преодолеете трудности из-за отсутствия надлежащей документации для тестирования? 2. Какой подход является наилучшим для старта QA в проекте? 3. Какие препятствия могут возникнуть в обеспечении качества для Agile Tester? 4. Что такое Definition of Done? 5. Когда можно считать, что тестирование окончено? 6. Что такое RCA в тестировании? Нужно ли его проводить? 7. Какой подход вы используете для Test Cases Review? 8. Какие виды рисков существуют? Что такое Mitigation Plan? 9. На основе чего нужно составлять стратегию для проведения тестирования нагрузки? 10. Как часто следует ревьюировать тестовую документацию? 11. Как можно быстро сделать выборку необходимых проверок для смоук-тестирования? 12. Как запланировать загруженность команды тестировщиков? 13. Какую ценность несет анализ результатов тестирования команде и проекту в целом? 14. Как можно подкорректировать флоу разработки, чтобы получать более чистые результаты на выходе и уменьшить количество багов на проде? 15. Расскажите о метриках качества, которые вы применяли. Зачем они нужны? 16. Как провести эстимейт задачи? Каковы техники оценки объема тестирования существуют? 17. Как можно посчитать покрытие тестами функционала? 18. Какое оптимальное количество шагов в тестовом сценарии? 19. Как избежать появления регрессивных дефектов? 20. Что такое тестирование со смещением влево (Shift left testing)? 21. Как будете тестировать программу, если для продукта нет документации? 22. В чем смысл юнит-тестов? 23. Какие минусы полной автоматизации тестирования? 24. Что такое ROI и как его считать? 25. Что такое CI/CD? Какие плюсы и минусы этого подхода? 26. TOP OWASP: какие знаете уязвимости и методы защиты? 27. Что вы думаете по поводу BDD? Когда следует использовать, а когда будет только хуже? Если все же следует использовать, то для UI или API автоматизированного тестирования? 28. Что такое сокеты и как их тестировать, вручную и автоматизировано? Зачем их используют? 29. Когда следует делать стресс-тестирование на проектах? От чего отталкиваться, когда строите сценарий для такого тестирования? Что учесть при выборе инструмента? 30. Расскажите об алгоритмах шифрования трафика. 31. Что такое NIC? 32. Для чего нужен протокол RTP? 33. Что, по вашему мнению, лучше – SIP или PRI? 34. Что такое NAT?     Практические задания 35. Сформулируйте негативные сценарии для POST-запроса, который создаёт нового пользователя. 36. Как вы регулируете конфликтные ситуации между QA и разработчиками? 37. Есть проект, на котором нет тестовой документации, но проекту уже год. Мануальным QA не хватает времени на тестирование, они очень устали, есть желание уволиться. Какое решение по команде можно принять? 38. Продайте мне тестирование как клиенту, не желающему его покупать. Кратко и структурированно опишите вашу работу на каждом из этапов разработки ПО, используя профессиональные термины (не лить воду). 39. У вас есть онлайн-калькулятор. Вы вводите 1+1 и получаете 3. Расскажите, как вы будете искать причину проблемы. 40. Могут ли быть такие виды архитектур? Чего может быть недостаточно для правильной работы архитектур, приведенных ниже?   Пример 1     Пример 2     Пример 3     Пример 4   Вопросы при выполнении этого задания:   какие запросы выполняются по форме авторизации? Какой запрос выполняется, когда мы сохраняем данные в базе данных? Можно ли авторизоваться с помощью GET-запроса и нормально ли так делать? Какой код ответа мы получаем при падении ошибки на сервере, код при ошибочных credentials на форме авторизации? Можно ли заменить SSL-сертификат шифрованием данных в пакете от клиента к серверу для протокола HTTP или это будет равноценной заменой?   41. Есть веб-страница с полями e-mail, password и кнопкой submit. Предположим, что после нажатия кнопки submit страница перезагружается и ранее введенные данные исчезают. Как проверить, что данные отправлены в базу данных? 42. Какое минимальное количество тест-кейсов необходимо, чтобы убедиться в корректной работе этой веб-страницы? 43. Как проверить безопасность на веб-странице (на выбор)?   Редакция DOU.ua выражает благодарность за вопросы и рецензию: Роману Поботину, Андрею Заблоцкому, Виктору Максименко, Марьяне Батюк, Ирине Литвин, Сергею Могилевскому, Святославу Логину, Роману Маринскому, Олегу Заревичу, Олесе Паславской, Тарасу Лирке, Максиму Богуну, Вадиму Гуличу, Виталию Кашубе, Юрию Суравскому, Светлане Франковой, Владимиру Арутину, Станиславу Жупинасу, Людмиле Федчук, Иванне Черухе, Юлии Левченко, Владиславу Куличенко, Юрию Бояру.

Миф 1. Без знания математики дверь в программирование закрыта Миф 2. “Прочту книгу — стану программистом” Миф 3. Чтобы освоить программирование, необходимо быть очень умным Миф 4. Необходимо обладать талантом к написанию кода Миф 5. Программисты — замкнутые и необщительные люди Миф 6. Программирование — скучное занятие Миф 7. Программисты всё пишут с нуля Миф 8. Чтобы устроиться на работу в качестве программиста, необходимо очень долго учиться Миф 9. После курсов у вас сразу высокая ЗП Миф 10. “Выучи язык программирования… за 1 час!” Миф 11. Нельзя освоить программирование самостоятельно Миф 12. Программисты разбираются во всём, что связано с техникой Миф 13. Программирование — мужское занятие Миф 14. Существует самый-самый лучший языка программирования Миф 15. Разработчики компьютерных игр — самые богатые и счастливые люди в IT Миф 16. Начинающим айтишникам устроиться на работу невозможно Миф 17. Пойду в ВУЗ, там меня научат программированию Миф 18. Программирование имеет возрастные ограничения Миф 19. Программист — вымирающая профессия: роботы заменят этих специалистов Итоги   Приветствуем вас, друзья! При своей относительной молодости программирование успело обзавестись приличным количеством мифов. Время, когда писателей кода считали дикими отшельниками, потихоньку уходит. Однако, и по сегодняшний день многие имеют ложные представления о программировании. Некоторые считают, что программист - это человек, который взламывает компьютерные системы, банкоматы и совершает прочие несогласованные с буквой закона действия. Другие уверены: программист и компьютер тебе починит, и Windows переустановит, и ТВ-каналы настроит, и новый Фейсбук за ночь напишет, и покажет, как генерировать содержание документа в Ворде.  Более того, некоторые стереотипы настолько прижились, что стали отпугивать новичков в IT и мешать их профессиональному дебюту в данной сфере. Мы подготовили для вас рейтинг самых главных мифов, которые необходимо развеять в первую очередь. Давайте же приступим к их разрушению.   Миф 1. Без знания математики дверь в программирование закрыта Одно из самых распространенных заблуждений. Как мы уже упоминали в статьях “Нужно ли программисту высшее образование?” и “FAQ начинающего программиста”, важно не столько знание математики напрямую, сколько само математическое мышление. Сейчас мы все объясним. Для того, чтобы начать изучение любого популярного языка программирования (ЯП), с головой хватит знаний школьной алгебры. Согласно опросу Stack Overflow Developer Survey 2020, более 50% разработчиков-респондентов написало свою первую строку кода до 16 лет, а в этом возрасте никто еще не изучает высшую математику. Значит, сделать старт в программировании может любой, кто учился/учится в обыкновенной среднестатистической школе. Это первая ступенька на пути к качественному овладению ЯП. Когда вы начнете более-менее ориентироваться в языке и поднабьете руку на практических задачках, вам необходимо будет изучить смежные с математикой дисциплины: теорию множеств, графов, автоматов, алгоритмов, базовую логику. Это программа первых курсов технических вузов по IT-направлению, однако и самостоятельное ее освоение — вполне подъемная задача. При этом наименее зависимыми от математики являются такие специальности, как верстальщик и FrontEnd разработчик. Хорошие знания в области высшей математики необходимы тем, кто хочет реализовать себя в таких направлениях: научная область, шифрование, машинное и глубокое обучение, Data Science, разработка искусственного интеллекта и все, что связано с большими данными. Именно там находит широкое применение тот мат. аппарат, которым славятся технические вузы. Математика в программировании — это, прежде всего, о математическом и аналитическом мышлениях, которые тесно связаны с критическим мышлением и позволяют абстрагироваться, развязывать задачи с умелым применением логики. Именно правильный взгляд и рациональный подход к решению задач является главным оружием программиста, поскольку программирование — это динамика, в то время, как формулы, теоремы и аксиомы статичны. С развитием мат. мышления вам помогут различные книги, а также практика — кодинг, решение математических задачек и прочие упражнения, которые можно найти на просторах интернета. Кстати, критическое мышление отлично развивают шоу с фокусниками. Посмотрите их, подумайте над тем, как маэстро смог провернуть тот или иной трюк (затем посмотрите соответствующие разоблачения). Также будут полезны детективные игры в стиле “Шерлока Холмса”, где, казалось бы, мистическим событиям находяться вполне логические объяснения. Умение не принимать всю информацию как чистую правду, а смотреть на нее со всех возможных углов — очень полезный навык не только в кодинге, но и в повседневной жизни.   В любом случае, данный миф о математике разрушен, а это означает, что начать программировать вы можете прямо сейчас.   Миф 2. Можно стать программистом, просто прочтя одну или несколько книг (“Прочту книгу — стану программистом”) Программирование — это в большей степени практика. Теория здесь обязательно должна подкрепляться добротным кодингом. Это обеспечит закрепление полученной информации, а также будет гарантировать понимание вами материала и способствовать развитию ваших навыков написания кода. Поэтому чтение книг начинающими программистами должно обязательно сопровождаться соответствующими отработками (практикой), иначе получите ноль пользы от литературы и только зря потратите свое время, не достигнув желаемого.    Миф 3. Чтобы освоить программирование, необходимо быть очень умным Миф, который отпугивает множество потенциальных программистов. Появился он из-за ложного убеждения, мол, программисты — это сверхразумы, которые видят мир, как в “Матрице” — в форме бесконечно бегущих зеленых символов. На самом деле они обыкновенные люди. Просто они горят кодом. Программистам нравится создавать компьютерные программы, веб-сервисы, игры, мобильные приложения. Точно так же экстремалам-байкерам нравится выделывать различные трюки на железном коне, знатокам поварского дела — готовить вкусные и красивые блюда, летчикам — поднимать в воздух многотонные крылатые гиганты, водителям — колесить по бескрайним просторам, психологам — помогать людям понимать себя. Если посмотреть на каждую профессию со стороны, в каждой можно найти свои сложности. И каждое препятствие преодолевается прежде всего большим трудом и упорством. А мозги — это часть организма, которая поддается прокачке, как и мышцы тела. Поэтому если вы чувствуете, что “недостаточно умны” для программирования, начинайте ломать этот барьер, работайте над собой и ни в коем случае не позволяйте каким-либо предубеждениям вставать у вас на пути. Никто этот шаг за вас не предпримет, так что все в ваших руках.       Миф 4. Необходимо обладать талантом к написанию кода Успех программиста как такового обусловлен его заинтересованностью выполняемой задачи, количеством специализированных знаний, степенью владения ЯП и математическим мышлением, а также прилагаемыми усилиями. Таланта или какого-то дара в перечне нет. Так что программирование — это 95% усердной работы. Не ожидайте манны небесной — работайте, трудитесь и тогда вы сможете преуспеть в создании кода.   Миф 5. Программисты — замкнутые и необщительные люди Возможно, в далеком прошлом это и было правдой, однако сейчас все совершенно по-другому. Более того, одними из главных требований к личным качествам программистов сегодня являются коммуникабельность, открытость и умение работать в команде. Время компьютерных гиков-одиночек кануло в Лету. Различные конференции, хакатоны, совместный отдых и развлечения — эти вещи как-то мало совместимы с замкнутостью и необщительностью, вы не находите? Такой спектр коммуникабельности не всегда можно встретить в фирмах, которые специализируются на коммуникациях с клиентами, а тут целые мероприятия, куда разработчики приходят пообщаться, заиметь новые связи, обменяться опытом и просто отдохнуть.    Миф 6. Программирование — скучное занятие На первый взгляд это правдоподобно: человек сидит перед монитором (или несколькими), набирает строчки кода и так целый день напролет. Ну что тут может быть интересного? Даже как-то страшно становится... Однако, это очень урезанный взгляд на то, чем занимается программист. Прежде всего, в рассматриваемой ситуации он может: разрабатывать одну из механик компьютерной/мобильной игры; создавать мобильное приложение; реализовывать привлекательный внешний вид веб-сайта; разрабатывать программу для какого-то “умного” устройства; работать над автоматизацией каких-то рутинных процессов, которые обыватели проделывают чуть ли не каждый день; писать программное обеспечение для космического аппарата, самолета, машины; и многое другое. Поверьте, кто-кто, а программисты не скучают — для них всегда есть работа, которая требует и знаний, и навыков, и творческого подхода к решению. К тому же, у каждого человека свой спектр интересов. Кто-то программирование считает скучным вследствие своего гиперактивного способа жизни, а кто-то просто поддается влиянию когнитивного искажения, прислушиваясь к собственному ложному суждению, обусловленному субъективными предубеждениями и стереотипами, социальными, моральными и эмоциональными причинами, то есть, вырабатывает свое отношение к программированию на основе искаженной информации.   Миф 7. Программисты всё пишут с нуля Современные сложные программы состоят из сотен тысяч строк кода. Если бы программисты писали всё с нуля, то на разработку одной такой программы уходило бы очень много времени, особенно, если говорить про игры — там и вовсе приходилось бы для каждого нового экземпляра и движок свой создавать, и физику свою писать и делать много других лишних движений. А это и время, и деньги, и лишние нервы. Поэтому в среде программистов принято не заниматься разработкой “велосипедов”, а использовать проверенные наработки. Разработчики часто применяют сторонние библиотеки, а также код, который был написан ими самими либо другими кодерами для других проектов. Это существенно упрощает и ускоряет создание проектов любой сложности и любого объема.   Миф 8. Чтобы устроиться на работу в качестве программиста, необходимо очень долго учиться В каждом человеке это утверждение находит различное отображение. Кто-то может освоить ЯП и необходимые технологии за месяц. Кому-то на это потребуется пол года. Некоторые и за год не управятся. Все зависит от вашего желания и стремления изучать ЯП, а также от времени, выделяемого вами на теорию и практику. Поставьте перед собой четкую цель и не сворачивайте с выбранного пути. Максимально быстрого обучения можно достичь, выбрав хорошие курсы, разбавляя их большим количеством самостоятельной практики.    Миф 9. После курсов у вас сразу высокая ЗП Один из самых распространенных мифов, который делает программистов в глазах других, незнакомых с данной сферой занятости людей, буквально миллионерами. Мол, “вот мой знакомый недавно листовки раздавал, потом походил на курсы 2 месяца и теперь деньги лопатой гребет”. На самом деле все не так. Те, кто только окончил курсы по освоению той или иной IT-специальности, по своему уровню знаний и умений могут претендовать на должность разработчика-джуниора (младший разработчик, Junior Developer). Конечно, все зависит от выбранного направления и конкретного места работы, однако джуниоры не срывают куш и первое время имеют довольно невысокую зарплату, которая не всегда доходит до пятизначной отметки (если говорить об украинских гривнах). Приблизительно на третий год работы можно говорить о действительно хорошей заработной плате. Так что запомните: высокая ЗП — даже в IT — результат не курсов, а усердной и ответственной работы.     Миф 10. “Выучи язык программирования… за 1 час!” Миф касается различных видео уроков на YouTube, которые пестрят подобным названием и тем самым обманывают вас. Ни один язык программирования не учится за час. Большое количество опытных программистов утверждают: сколько лет они программируют, столько они изучают ЯП. Языки взаимодействия с электронно-вычислительными устройствами настолько же компактны и многогранны, как и те, которыми мы пользуемся в повседневности. Таким образом, во время изучения ЯП вы осваиваете основной синтаксис языка и то, как с ним работать. Затем во время профессиональной деятельности вы углубляетесь в язык и открываете для себя новые техники кодинга и решения различных задач. Но даже процесс овладения языком (синтаксис + основы работы с ним) — небыстрый процесс. У опытного программиста изучение нового ЯП может занять несколько дней. У новичка могут уйти месяцы — все зависит только от вас. Но на всевозможные “Выучи язык… за 1 час!” и подобные вещи не ведитесь; такие видео ролики создают иллюзию того, что вы знаете ЯП, в то время, как на самом деле вы толком ничего и не умеете.   Миф 11. Нельзя освоить программирование самостоятельно Можно. Просто на это уйдет больше времени, чем на обучение при помощи специализированных курсов. Причины тому очень просты: отсутствие ментора, который бы мог направлять вас в нужное русло, давать советы и отвечать на вопросы; отсутствие предельно четкого понимания о знаниях и умениях, которыми необходимо обладать, чтобы в будущем занять соответствующую должность; отсутствие четкой программы обучения, которая покроет весь необходимый профильный материал; отсутствие стимула и достаточной мотивации, которые обычно присутствуют в коллективной среде (тренер, другие учащиеся, домашние задания и т. д.). Главная проблема самостоятельного обучения в силе воли, которая зачастую быстро испаряется и в итоге изучение ЯП сводится к нулю. А программирование вещь серьезная — на недельку-другую все забросил и вот ты уже ничего не помнишь. Так что самостоятельно обучаться программированию можно, главное — запастись упорством, терпением, силой воли и мощной мотивацией, которая должна постоянно подпитываться.   Миф 12. Программисты разбираются во всём, что связано с техникой Как вы поняли из вступления статьи, это тоже миф, причем один из самых распространенных. Разработчик мобильных приложений специализируется на создании программ под мобильные устройства. Он знает соответствующие ЯП и смежные технологии, которые позволяют ему выполнять свою работу качественно и без лишних затрат времени, однако, с какой стати этот специалист должен уметь чинить телевизоры и устанавливать Windows? Или, например, человек увлекается программированием микроконтроллеров. Почему он должен уметь создавать веб-сайты, если это абсолютно другая отрасль в IT? Вы же не требуете от педиатра вылечить вам зуб, а от стоматолога — избавить вас от кашля? Хотя и тот и тот специалист — врач. Каждый является специалистом в своей области и не следует это забывать. Сюда же относится и миф о хакерах, согласно которому программисты приравниваются к людям этого рода деятельности. Опять-таки, сторонники данной теории слишком плохо знают IT-сферу, поэтому все равняют под одну гребенку. То, что человек разбирается в определенном ЯП и смежных технологиях не делает его хакером. Хакерство — это специфический род деятельности, который предусматривает достаточно глубокие знания компьютерных сетей, операционных систем, социальной инженерии, криптографии и множества других IT-ответвлений. Если хотите узнать больше подробностей, не пожалейте своего времени — совершите поиск по специализированным ресурсам и тогда сможете расставить все точки над “i“ — кто кем является и какой спектр знаний-умений какому IT-специалисту свойственен.     Миф 13. Программирование — мужское занятие Безусловно, мужчин в программировании больше, чем женщин. По данным исследования Stack Overflow Developer Survey 2020, женщин среди разработчиков 8%. В Украине процент женщин в IT в 2020 году достиг уровня 25%, согласно исследованиям DOU.ua. Однако, это связано, скорее, с определенными социальными и психологическими явлениями. Дело в том, что женщины по своей природе более “социальны”, чем представители мужского пола. Соответственно, они чаще выбирают те сферы занятости, которые предусматривают общение и социум. В то же время парни и мужчины увлечены преимущественно техническими науками, поскольку достаточно распространенная среди них интровертивность позволяет посвятить необходимое количество времени цифрам, формулам и вычислениям. Плюс детская любовь к конструкторам, машинам, компьютерным играм и всему, что связано с техникой, с экспериментами. Ну и стереотипы, привитые обществом — куда же без них. Однако, это ни в коем случае не означает, что женщинам путь в программирование заказан. С каждым годом все больше и больше представительниц прекрасного пола покоряют IT в различных его секторах. Не ведитесь на предубеждения — программирование абсолютно открыто для всех полов, народов и возрастов.    Миф 14. Существует самый-самый лучший языка программирования Очень часто в интернете можно наткнутся на неутихающие дискуссии касательно того, какой ЯП лучше. Однако “лучшего” не существует. ЯП подбирается под задачу, а не задачи под ЯП. Если вы хотите максимально быстро развернуть свой сайт, лучше обратить внимание на Python и фреймворк Django. Хотите самостоятельно запрограммировать, допустим, сигнализацию с инфракрасным датчиком? Выбирайте C/C++ либо низкоуровневый Assembler. Те же С/С++ подойдут под разработку тяжеловесных игр, а для более простых идеальным выбором будет среда разработки Unity вместе с языком C#. FrontEnd разработка немыслима без языков верстки HTML & CSS, а также языка программирования JavaScript. Определитесь с тем, какая сфера разработки вам интересна и тогда выбирайте тот язык, который вам по душе.    Миф 15. Разработчики компьютерных игр — самые богатые и счастливые люди в IT Казалось бы: ты посвящаешь себя тому, о чем мечтал, наверное, каждый ребенок девяностых и нулевых — компьютерным играм. Ну что может быть прекраснее этого? Воплощаешь в жизнь все свои детские задумки: создаешь героев, работаешь над их характерами, занимаешься реализацией собственного геймплея, придумываешь уникальные квесты, сюжет не хуже “Игры престолов”, открытый и насыщенный игровой мир… Да вот только одна проблема — это так не работает; на деле все получается совсем иначе. Чтобы стать разработчиком игр, необходимо ими “гореть”, причем “гореть” так, чтобы ни время, ни вода, ни песок, ни отсутствие кислорода не смогли потушить ваше пламя. Во-первых, богатство гейм девелоперов преувеличено. Если игра “выстреливает”, либо вы работаете на плюс-минус солидную студию, то тогда можно говорить о деньгах. Однако, приличное количество разработчиков занимаются инди-играми, то есть, разрабатывают игры без финансирования крупных компаний (в одиночку, либо небольшими группами энтузиастов). Естественно, пока вы работаете над своим продуктом, единственным источником внешних доходов могут быть лишь пожертвования (донаты) от потенциальной аудитории, которая заинтересована в вашем творении. Также, важно знать, что разрабатывать игры и играть в них — две абсолютно разные вещи. Игростроение — сам по себе трудоемкий и комплексный процесс, который сильно отличается от того, что мы себе воображали в детстве.   Подробнее о пути гейм-мейкеров вы можете прочесть в нашей статье “Как стать разработчиком игр”. В ней мы постарались собрать максимальное количество информации с отечественных и зарубежных информационных ресурсов, чтобы подать вам все самое вкусное в одном компактном виде.      Миф 16. Начинающим айтишникам устроится на работу невозможно Действительно, если брать на рассмотрение популярные направления в IT, то конкуренция достаточно большая. И это на фоне растущих с каждым годом требований от работодателей. Однако, это не означает, что IT-отрасль закрыла свои двери перед новичками. Как раз таки наоборот. Сегодня функционирует множество программ стажировок от известных компаний, занимающихся созданием программного обеспечения. Например, EPAM, GlobalLogic, SoftServe и другие открывают вакантные места для тех, кто хорошо знает предметную область, но не имеет опыта работы. Конечно, необходимо будет пройти тестирование и/или собеседование, однако, это уже упрощает процесс внедрения в рабочую среду желанной IT-секции.      Миф 17. Пойду в ВУЗ, там меня научат программированию В ВУЗе не обучают программированию в соответствии с теми требованиями и ожиданиями, которые предъявляют к соискателям IT компании. Хоть вам и будут преподавать алгоритмы и различные ЯП, но нагрузка в вузе будет настолько объемной и пёстрой, что вы физически не сможете нормально научиться программировать. Все равно вы будете вынуждены самостоятельно учить/доучивать тот или иной язык. Если бы вы поступали на факультет, допустим, прикладной математики, вы бы туда шли с сильными знаниями по математике, правда? Так же само и с айтишными факультетами: если вы туда идете, у вас УЖЕ должен быть опыт программирования на любом ЯП. Иначе вам будет очень тяжело и мучительно больно.   Миф 18. Программирование имеет возрастные ограничения Языки программирования, как и любые иностранные языки, вы можете начать изучать в любом возрасте. Возрастные рамки отсутствуют. Самое главное — это ваше желание учиться, развиваться и познавать. Как показывает практика, уже с 8-9 лет дети способны понимать основные концепции ЯП и успешно создавать собственные программы. Если говорить об относительно великовозрастных людях, с ними работает то же правило — никогда не поздно учиться и узнавать нечто новое. Более того, активная мозговая деятельность (как такая, которая происходит в процессе программирования) является отличной профилактикой многих заболеваний мозга, связанных со старением. Так что программирование и юных развивает, и взрослых прокачивает + помогает держать в тонусе свои мысли. Однако, при трудоустройстве возрастные ограничения могут иметь место. Это зависит от политики компании, которая ищет специалиста.   Миф 19. Программист — вымирающая профессия: роботы заменят этих специалистов Очень распространенное мнение, имеющее право на жизнь. С одной стороны, все верно: программ становится все больше и больше, а значит, потребность в программистах должна потихоньку отпадать (ведь скоро будет нечего программировать!); при этом активно развивается искусственный интеллект, способный перенимать определенные функции человека, включая написание кода, на себя. Поговорим о первом тезисе. Вроде бы все логично, но есть одно НО. Рассмотренная выше мысль будет абсолютно верна в том случае, когда мы говорим об информационных технологиях, как об области, которая находится в некоем вакууме, причем вакуум этот ограничен, то есть, имеет свой “потолок”, выше которого не прыгнешь. Наш же мир не является ограниченным, по крайней мере, человечество еще не смогло определить его грани. Да, человеческие возможности упираются в определенные физические ограничения (невозможно поднять руками или ногами самолет, самостоятельно прыгнуть на высоту 5 метров, проглотить целиком кокос и т. д.), однако в нашем мозгу пока что не было замечено четких ограничений. Более того, с его помощью мы научились обходить естественные физические преграды: придумали и реализовали специальный транспорт, который может перевозить тяжелые объекты; изобрели джамперы, джетпаки (реактивные ранцы) для совершения высоких прыжков и полетов в воздух на относительно небольшие высоты; специальные предметы для разделывания экзотических фруктов и т. п. Пока что ученые не смогли выжать максимум из нашего мозга и разглядеть границы нашего сознания. Если сложить вместе безграничность наших мыслей и безграничность мира, можно прийти к выводу, что любая сфера нашей жизни поддается совершенствованию и всегда есть, куда дальше двигаться. Все области нашей жизнедеятельности неразрывно связаны между собой, хотим мы того или нет. Особенно сфера IT — сейчас она находит свое отображение везде: музыка; киноиндустрия; компьютерные игры; банковская сфера; транспортная инфраструктура; сфера безопасности (физическая и кибербезопасность); СМИ; медицина; аграрная отрасль; все, что связано с космическими разработками; научные исследования любых направлений; сфера образования... Так можно продолжать, пока не будут перечислены все отрасли человеческой деятельности. Давайте обратимся к сухим фактам и посмотрим на то, как “умерли” некоторые профессии в результате их совершенствования: человечество уже научилось создавать искусственные фрукты и овощи, но фермеры никуда не пропали; более того — некоторые страны имеют острую нехватку профессионалов в аграрном деле; существуют дистанционно управляемые боевые машины, дроны и другие приспособления для ведения боевых действий, но никто не говорит о роспуске армейских подразделений; набор призывников и добровольцев продолжается и приветствуется во всех странах; в супермаркетах появились терминалы самообслуживания, однако продавцов никто не уволил; посмотрите вакансии на данную должность — их пруд пруди; пассажирские самолеты обустроены очень надежными и серьезными компьютерными системами, которые выполняют много работы за человека и даже имеют функцию автопилота, но никто не спешит увольнять самих пилотов; более того, в мире острая нехватка данных специалистов, а их зарплаты считаются одними из самых высоких в мире; такая же ситуация и с поездами — сегодня не надо кидать уголь в печь и разгонять поезд (как в XIX веке), но водители поездов никуда не испарились; беспилотные автомобили уже разъезжают по улицам некоторых городов, однако водители государственных и коммерческих предприятий тоже никуда не делись, вакансии пестрят предложениями для водителей; множество других примеров. Примерно та же ситуация и у программистов. Правда, сфера IT настолько многогранна, что профессии в результате развития данной области будут просто эволюционировать. Например, веб-мастер двухтысячных стал современным FullStack девелопером, а само направление сайтостроения поделилось на два лагеря — FrontEnd и BackEnd. На границе программирования и системного администрирования образовалась DevOps инженерия. IT-специальности будут попросту перерождаться и образовывать новый виток с новыми должностями. Для осознания системности нашего мира советуем прочесть книгу “Введение в системный анализ” (Ф. И. Перегудов, Ф. П. Тарасенко). Прекрасный труд, который очень хорошо демонстрирует взаимосвязанность всего, что нас окружает. Воспитывает системное мышление и заставляет смотреть на вещи более адекватно и трезво, находить логические связи между всевозможными событиями и процессами в нашем мире.  Поговорим о втором тезисе. Он касается искусственного интеллекта (ИИ). Сюда же добавим системы генерации кода, существующие в наше время. К примеру, взглянем на сервисы, которые позволяют создавать собственные сайты без знания IT технологий. Действительно, сегодня существуют подобные системы, использование которых исключает необходимость владения языками верстки и программирования, однако они предоставляют достаточно шаблонные решения. В них вы не сможете воплотить все свои задумки — это сможет сделать только живой специалист. Системы генерации кода хорошо справляются с типичными задачами, однако в реальных ситуациях, где не всегда всё просто и зачастую необходимо импровизировать, сохраняя при этом код “в чистоте”, они бессильны. Возвращаясь к разработчикам сайтов: верстальщики, FrontEnd и BackEnd разработчики не исчезли и спрос на них является одним из самых высоких среди направлений в IT. ИИ уже давно разрабатывается и ученые демонстрируют потрясающие результаты: системы, которые обыгрывают шахматных гроссмейстеров и легенд покера, робот София, системы по распознаванию образов и т. д. Однако, какого-то обвала рынка программистов не последовало, массовые увольнения специалистов замечены также не были. Все спокойно.  Посетите, например, такие ресурсы по поиску работы, как https://jobs.dou.ua/, grc.ua,  hh.ru — вакансий для сайтостроителей много, равно как и для других айтишных специальностей. Не похоже на упадок эпохи программирования. Несмотря на то, что сфера IT и без того находится на пике популярности, она испытывает дефицит рабочих кадров. Так что вы сможете прекрасно себя реализовывать в IT еще несколько десятилетий как минимум. Главное — следите за тенденциями в IT и ловите попутный ветер.   Итоги Большинство мифов, касающихся IT, рождены обыкновенным незнанием предметной области и изрядной долей ложных предубеждений. Сегодня мы постарались разрушить некоторую часть из них и показать вам, что программирование — не башня из слоновой кости, а вполне реальная и податливая сфера человеческой деятельности, в которой кипит жизнь и которая нуждается в пополнении своих рядов. Не бойтесь делать шаги навстречу программированию. Разрушайте стены незнаний и непониманий. Если вы в чем-то неуверенны,  интересуйтесь у знакомых-программистов, пишите на форумах, спрашивайте на стримах. Все зависит только от вас!   Желаем вам всевозможных успехов и профессиональных свершений! Оставайтесь с ITVDN!

Здравствуйте,  дорогие читатели. В этом уроке мы: Установим менеджер установки пакетов “Brew”; Научимся пользоваться базой данных “Mongo DB” и изучим библиотеку “Mongoose”; Установим и сконфигурируем базу данных “Mongo DB”; Научимся запускать демон (службу) “Mongod” и подключаться к ней; Научимся просматривать документы базы данных “Mongo DB” с помощью приложения “Robomongo”; Создадим REST сервисы для товаров и пользователей с использованием “NodeJS”; Научимся тестировать REST сервисы с помощью расширения “Chrome” браузера “Postman”; Итак, вы скорее всего задались вопросом, почему же я выбрал именно такие технологии для написания REST сервисов. Почему не выбрал то, что уже давно у всех на слуху, такие технологии как Web API + Entity Framework. Ответ прост, я выбрал ровно те технологии, которые явно подходят платформе, на которой мы ведем разработку macOS. Да, можно было установить Xamarin Community Edition, в нем создать ASP.NET проект и сделать сервисы на Mono.NET. Еще был вариант сделать сервисы на виндовс платформе, развернутой на виртуальной машине в веб сервере IIS с сетевым адаптером мост. Это для того, чтобы веб сайт и сервисы были доступны на хостовой машине macOS в браузере. Возможно, в одном из моих будущих видео курсов по разработке iOS приложений я буду использовать именно платформу Windows и Visual Studio для разработки REST сервисов. Но в этом уроке  мы будем делать сервисы на NodeJS,  и вы сами убедитесь в том, насколько это просто и как мало кода надо для этого написать :) В качестве среды разработки я буду использовать WebStorm, он довольно хорошо себя оправдал как один из продуктов JetBrains. В этом уроке мы не будем работать с приложением “Warehouse” под iOS, поскольку мы должны приступить к изучению библиотеки “Alamofire”. А для нее необходимы REST сервисы, которых у нас сейчас нет. Показывать работу на всяких httpbin, parse и других сервисах тестирования я не буду, этого полно в сети интернет, вы и сами будете видеть это в поиске нужной вам информации. “Alamofire” -  это асинхронная сетевая библиотека для работы с REST сервисами. В большинстве туториалов  не рассказывается, как сделать REST сервисы и клиент к ним на разных платформах. Мне хотелось бы нарушить этот стереотип и предоставить вам учебные примеры по созданию полнофункционального REST сервиса и полнофункционального iOS клиента в составе приложения “Warehouse” к нему. Проще говоря, дать готовое решение  для быстрого понимания, что и как делается. Это то, чего обычно не хватает новичкам и то, чего обычно нигде не выкладывают. Приходится самостоятельно разбираться и искать нужную информацию. Откройте “WebStorm”. Выберите в меню “File -> New Project”. Выделите тип проекта “Node.js Express App”. В поле “Location”  укажите название проекта “Warehouse” и путь, по которому вы будете сохранять данный проект. В поле “Template”  выберите “EJS”. Нажмите кнопку “Create”. Вы увидите диалоговое окно с предложением, откуда взять библиотеку “NodeJS”. Оставьте пункт по умолчанию “Download from the Internet” и нажмите кнопку “Configure”. Будет загружен из сети интернет “NodeJS”, “Express” и другие библиотеки. Панель навигации будет выглядеть у вас так: Рассмотрим, что создал нам данный шаблон. В папке “bin”  хранится файл “www”, в нем находится настройка сервера “NodeJS”, с этого файла происходит запуск нашего сервера. В папке “node_modules”  находятся библиотеки, которые были автоматически загружены  шаблоном проекта NodeJS. В папке “public”  находятся ресурсы, используемые нашим сервером (картинки, CSS стили, скрипты). В папке “routes”  находятся скрипты, которые должны содержать маршрутизацию относительно текущего URL,  введенного пользователем. Например,  файл с именем “users.js”  вызывется, когда пользователь введет в браузере URL: “http://localhost:{port}/users”. Файл “index.js”  вызывется, когда пользователь введет URL: “http://localhost:{port}”. Если сравнивать с паттерном MVC (Model View Controller), то в папке “routes”  находятся “контроллеры”. В папке “views”  находятся представления. Расширение “*.ejs”  говорит о том, что содержимое данного файла будет транслироваться через библиотеку “Express JS”. Данная библиотека создана в помощь, чтобы можно было проще создавать маршрутизацию в NodeJS  и проще создавать пользовательский интерфейс. Внутри этих файлов “*.ejs”  содержится обычная “HTML” разметка. Файл маршрутизации и файл представления должны называться одинаково, если они будут связаны. В текущем проекте связаны только “index.js” и “index.ejs”. Маршрут “users.js”  не имеет явного представления, для него преставление  генерируется средствами “NodeJS”. Наша задача создать только REST сервисы, поэтому работу с “EJS”  мы не будем рассматривать в данном уроке. Рассмотрим содержимое файла “www” в папке “bin”. На 7 строке  через библиотеку “Require JS”  мы подключаем содержимое модуля “app.js”  в текущий исполняемый модуль “www” и запускаем это содержимое на исполнение. В файле “app.js”  содержатся настройки для работы нашего сервера. На 8 строке  мы задаем режим отладки для нашего сервера. На 9 строке  мы подключаем модуль “http”  для работы с HTTP запросами. На 15 строке  задается порт “3000”, на этом порту сервер будет принимать входящие запросы к нему. На 16 строке  устанавливает этот порт для свойства “port” сервера. На 22 строке  создается сервер на основе настроек экземпляра “app”. На 28 строке  сервер запускается и начинает прослушивание на порту “3000”. На 29 строке  привязывается функция “onError”, вызываемый при возникновении ошибок. На 30 строке  привязывается функция “onListening”, вызываемая  при начале прослушивания запросов сервером. Остальной код в данном модуле не представляет для нас интереса. Чтобы запустить приложение, выполните в меню “Run -> Run bin/www”, сервер запустится. Затем откройте браузер и введите URL: “http://localhost:3000”, вы увидите приветствие. Чтобы остановить сервер, выполните в меню “Run -> Stop”. Теперь необходимо установить базу данных “Mongo DB”. Подробнее об установке  вы можете прочитать тут. Проще всего устанавливать базу данных  через менеджер пакетов “Brew”. Давайте установим его. Перейдите в браузере по адресу, на сайте будет предложено скопировать строку “/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)” в терминал. Откройте терминал и скопируйте в него строку установки “Brew”. После установки  вы увидите следующее: Теперь необходимо установить базу данных “Mongo DB”. Установка базы данных через “Brew”  проще тем, что “Brew”  сам заполняет нужные переменные среды окружения и вам не надо этого делать вручную  в случае с установкой базы данных вручную. Перейдите в “WebStorm”, откройте внутри него терминал. И введите команду “brew install mongodb && mongod”, данная команда скачает и установит “Mongo DB”, а также выполнит настройки по умолчанию для демона “mongod”. Выполните в терминале команду “sudo mkdir -p /data/db”. Введите свой пароль и нажмите кнопку “Enter”. Данная команда создаст папку “data” и в ней папку “db”, эта папка используется по умолчанию для добавления базы данных “Mongo DB”. Команда “sudo”  используется, чтобы выполнить остальную часть команды от имени администратора.       Теперь необходимо установить в наш проект библиотеку “Mongoose”  для осуществления возможности работы с базой данных их кода приложения сервера . Выполните в терминале команду “npm install mongoose”. Документацию по этой библиотеке можно почитать тут:  Данную команду мы выполняли через  встроенный в NodeJS  менеджер пакетов, так как устанавливаем данную библиотеку исключительно для нашего проекта, а не глобально. Откройте терминал, введите команду “mongod”. Данная команда запускает сервер базы данных “Mongo DB”, который принимает входящие подключения на порту “27017”. На картинке выше  вы можете в этом убедиться “waiting for connections on port 27017”. Демон запустили, теперь перейдите в “WebStorm”, в терминале внутри введите команду “mongod –version”, вы увидите версию базы данных “Mongo DB”, которая была установлена на ваш компьютер. Теперь необходим клиент с GUI  для работы с базой данных. Откройте браузер, перейдите по адресу, нажмите кнопку “Download”, скачайте и установите приложение. После установки приложения  откройте его. Нажмите на иконку: Откроется приложение “Robomongo”. Нажмите кнопку “Connect to local or remote Mongo DB instance”. Откроется диалоговое окно подключения к базе данных. Нажмите кнопку “Create”. Откройте диалоговое окно настройки подключения к базе данных. Заполните настройки, как показано на картинке выше и только на вкладке “Connection”, нажмите кнопку “Save”. После этого в окне “Mongo DB connections”  у вас появится добавленное подключение. Выделите его и нажмите кнопку “Connect”. Нажмите правой кнопкой в панели навигации по “Warehouse” и в контекстном меню выберите пункт “Create Database”. В поле “Database Name”  введите “warehouse”, нажмите кнопку “Create”. На картинке выше  видно, что база данных “warehouse”  была успешно добавлена. Супер :) Теперь надо добавить в проект модель и схему базы данных, они создаются с помощью библиотеки “Mongoose”. Перейдите в “WebStorm”. В панели навигации, нажмите правой кнопкой по “Warehouse”, в контекстном меню выберите “New -> Directory”. Создайте папку с именем “models”. Создайте в папке “models”  модули “Product.js” и “User.js”. А в папке “routes” создайте модули “auth.js”, “products.js”. Откройте модуль “Product.js”, заполните его, как показано на картинке ниже: На 1 строке  мы подключаем библиотеку “mongoose” и создаем ее экземпляр с именем “mongoose”. На 2 строке  мы правым операндом создаем схему таблицы товаров и присваиваем ее левому операнду с именем “ProductSchema”. Таблица товаров содержит поля: скрытое поле “_id”, типа “String”, в этом поле содержится уникальный идентификатор строки. скрытое поле “__v”, типа “Number”, в этом поле содержится версия API  по умолчанию 0. Версия API  нужна для того, чтобы можно было менять реализацию сервисов и иметь несколько версий  для обратной совместимости. поле “productImage”, типа “String”, тут будет храниться название картинок из нашего проекта под iOS, названия от “tool001” до “tool012”. поле “productName”, типа “String”, тут будет храниться название товара. поле “productDescription”, типа “String”, тут будет храниться описание товара. На 7 строке  мы правым операндом создаем экземпляр модели с именем “Product” и указываем создать экземпляр на основе схемы, описанной в экземпляре “ProductSchema”.      Библиотека “mongoose”  создает данный экземпляр и присваивает его левому операнду. Свойство “exports”  содержит экземпляры объектов, которые  будут доступны из модуля  при подключении его через библиотеку “Require JS”. Откройте модуль “User.js”, заполните его, как показано на картинке ниже: На 1 строке  мы подключаем библиотеку “mongoose” и создаем ее экземпляр с именем “mongoose”. На 2 строке  мы правым операндом создаем схему таблицы товаров и присваиваем ее левому операнду с именем “UserSchema”. Таблица пользователей содержит поля: скрытое поле “_id”, типа “String”, в этом поле содержится уникальный идентификатор строки. скрытое поле “__v”, типа “Number”, в этом поле содержится версия API  по умолчанию 0. Версия API  нужна для того, чтобы можно было менять реализацию сервисов и иметь несколько версий для обратной совместимости. поле “userName”, типа “String”, тут будет храниться логин пользователя. поле “userPwd”, типа “String”, тут будет храниться пароль пользователя. поле “userDesc”, типа “String”, тут будет храниться описание пользователя. На 7 строке  мы правым операндом создаем экземпляр модели с именем “User” и указываем создать экземпляр на основе схемы, описанной в экземпляре “UserSchema”. Затем присваем созданный экземпляр свойству “exports” данного модуля. Откройте модуль “auth.js”, заполните его в соответствии с содержимым ниже: На 1 строке  подключаем модуль “express” и создаем его экземпляр с именем “express”. На 2 строке  создаем экземпляр маршрутизатора запросов с именем “router”. На 3 строке  подключаем модуль “User.js” и создаем его экземпляр с именем “User”. На 4 строке  строим маршрут типа “http://localhost:3000/auth/”. На экземпляре “router”  вызываем функцию “post”. Вызов данной функции говорит, что созданный с помощью него маршрут будет доступен только через HTTP глагол POST.       Первым аргументом задаем маршрут, вторым аргументом задаем функцию обработчик, который будет вызван при переходе по данному маршруту с учетом заданного HTTP глагола. Т.е. когда пользователь отправит POST запрос по адресу. Функция обработчик принимает три аргумента. Первый аргумент “request”  содержит экземпляр запроса по данному маршруту.     Второй аргумент “response”  содержит экземпляр ответа по запросу по данному маршруту. В этот экземпляр можно добавлять любой ответ, который вы хотите, чтобы пользователь получил. Третий аргумент “next”  содержит текущий итератор в стеке запросов по маршрутизации. Данный экземпляр необходим, чтобы была возможность перейти на следующую итерацию в стеке маршрутизации. Сам по себе сервер NodeJS  работает асинхронно и никогда никого и ничего не ждет, это нужно учитывать при работе с ним. На 5 строке мы выводим сообщение на консоль. На 6 строке мы на экземпляре “User” вызываем функцию “find”, в которую единственным аргументом передаем специальную функцию обработчик, в которой будет содержаться результат данной операции. Функция “find”  получает все записи из таблицы “User” и присваивает их в JSON формате  второму аргументу функции обработчика с именем “data”. Для  примера, в “data” может содержаться такой JSON: “[{_id:'789787sdfsd78sdfsd7', __v:0, userName: “Test1”,...},{_id:'4444447sdfsd78sdfsd7', __v:0, userName: “Test2”,...}]”. Где квадратные скобки - это массив, а в фигурных скобках - это экземпляр JSON. В аргументе “err”  содержится экземпляр ошибки, если произошла ошибка при выполнении данной функции “find”. На 7 строке мы создаем экземпляр объекта с именем “res”, данный объект содержит свойство “Error”, которое инициализировано значением по умолчанию “Authorization Error”. Как вы уже поняли, это текст ошибки, который вернется на клиент в случае ошибки авторизации клиента. На 8 строке мы проверяем, если при получении данных через функцию “find” произошла ошибка и аргумент “err” не содержит значение “undefined”, мы обращаемся к экземпляру “next” и говорим серверу выполнить следующую итерацию маршрутизации и вернуть ошибку на клиент. На клиент средствами NodeJS  будет возвращена “Stack Trace” ошибки. На 9 строке, если ошибки не было, мы выполняем цикл foreach по массиву JSON объектов “data”. В функцию “forEach”  передается специальная функция, которая содержит три аргумента. Первый аргумент “item”  содержит текущий итерируемый экземпляр JSON. Второй аргумент “i” содержит позицию итератора и имеет тип Number. Третий аргумент “data”  содержит исходный массив объектов JSON, по которым проводится итерация. На 10 строке  мы задаем условие поиска пользователя по его имени и паролю в списке всех пользователей полученной функцией “find”. В условии сравниваются имя и пароль, которые пришли в POST запросе на сервер, с именем и паролем, полученным от функции “find”. На 12 строке, если пользователь был найден, мы присваиваем экземляру “res”  JSON объект найденного пользователя. На 15 строке  мы обращаемся к экземпляру ответа “response”, вызываем на нем функцию “json”, которая принимает данные и возвращает ответ на клиент в JSON формате. В аргумент данного метода мы передаем или экземпляр найденного пользователя, или экземпляр ошибки, что пользователь не найден и авторизация не удалась. На 18 строке  мы экспортируем из модуля экземпляр маршрутизации “router”. Откройте модуль “index.js”. Заполните его в соответствии с содержимым ниже: На 1 строке  подключаем модуль “express” и создаем его экземпляр с именем “express”. На 2 строке  создаем экземпляр маршрутизатора запросов с именем “router”. На 3 строке  строим маршрут типа “http://localhost:3000/index/”, доступный через HTTP глагол GET. На 4 строке, на экземпляр ответа вызываем функцию “render”. Данная функция возьмет представление, указанное в первом аргументе функции и вернет его на сторону клиента. Вторым аргументом задается словарь, в который можно добавить свойства со значениями, к которым можно будет обращаться со стороны представления. На 6 строке  мы экспортируем из модуля экземпляр маршрутизации “router”. Откройте модуль “index.ejs”. Заполните его в соответствии с содержимым ниже: Библиотека Express JS позволяет нам обращаться к свойствам, которые мы указали во втором аргументе метода “render”  путем добавления следующей конструкции “<%= Название_Свойства %>”. На этапе отрисовки страницы данные конструкции будут заменены на значение указанного свойства. Откройте модуль “products.js”, заполните его в соответствии с содержимым ниже: На 1 строке  подключаем модуль “express” и создаем его экземпляр с именем “express”. На 2 строке  создаем экземпляр маршрутизатора запросов с именем “router”. На 3 строке  подключаем модуль “Product.js” и создаем его экземпляр с именем “Product”. На 4 строке  строим маршрут типа “http://localhost:3000/products/”. Данный маршрут будет доступен по HTTP глаголу GET. На 5 строке  мы вызываем на экземпляре “Product”  функцию “find”. Внутри функции мы проверяем, были ли ошибки, и возвращаем в ответе JSON массив со списком всех товаров. На 10 строке  строим маршрут типа “http://localhost:3000/products/”. Данный маршрут будет доступен по HTTP глаголу POST. На 11 строке  мы вызываем на экземпляре “Product”  функцию “create”. Внутри функции мы проверяем, были ли ошибки, и возвращаем в ответе JSON объект успешно созданного товара. На 16 строке  строим маршрут типа “http://localhost:3000/products/{_id}” (например, “http://localhost:3000/products/789w66s2322kks4676s” ). Данный маршрут будет доступен по HTTP глаголу GET. На 17 строке  мы вызываем на экземпляре “Product”  функцию “findById”. Из названия функции ясно, что функция выполняет поиск по идентификатору товара. Для поиска используется скрытое поле “_id” в модели “Product”, объявленной в модуле “Product.js”. Внутри функции мы проверяем, были ли ошибки, и возвращаем в ответе JSON объект успешно найденного товара. На 23 строке  строим маршрут типа “http://localhost:3000/products/{_id}” (например, “http://localhost:3000/products/789w66s2322kks4676s” ). Данный маршрут будет доступен по HTTP глаголу PUT. На 24 строке  мы вызываем на экземпляре “Product”  функцию “findByIdAndUpdate”. Из названия функции ясно, что выполняется поиск товара по его идентификатору “_id”, затем, в случае если найден, обновляются все его поля, кроме скрытых полей. В ответе возвращается JSON объект успешно обновленного товара. На 30 строке  строим маршрут типа “http://localhost:3000/products/{_id}” (например, “http://localhost:3000/products/789w66s2322kks4676s” ). Данный маршрут будет доступен по HTTP глаголу DELETE. На 31 строке  мы вызываем на экземпляре “Product”  функцию “findByIdAndRemove”. Из названия функции ясно, что выполняется поиск товара по его идентификатору “_id”, затем, в случае если найден, товар удаляется. В ответе возвращается удаленный JSON объект. Откройте модуль “users.js”, заполните его в соответствии с содержимым ниже: В модуле “users.js”  я не вижу смысла расписывать подробно, что происходит, поскольку тут все то же самое, что и происходило в модуле “products.js”, рассмотренном выше. Разница только в том, что мы используем другую модель данных “User”. Опишу только доступные маршруты. На 4 строке  строим маршрут типа “http://localhost:3000/users/”. Данный маршрут будет доступен по HTTP глаголу GET. На 10 строке  строим маршрут типа “http://localhost:3000/users/”. Данный маршрут будет доступен по HTTP глаголу POST. На 16 строке  строим маршрут типа “http://localhost:3000/users/{_id}” (например, “http://localhost:3000/users/789w66s2322kks4676s” ). Данный маршрут будет доступен по HTTP глаголу GET. На 23 строке  строим маршрут типа “http://localhost:3000/users/{_id}” (например, “http://localhost:3000/users/789w66s2322kks4676s” ). Данный маршрут будет доступен по HTTP глаголу PUT. На 30 строке  строим маршрут типа “http://localhost:3000/users/{_id}” (например, “http://localhost:3000/users/789w66s2322kks4676s” ). Данный маршрут будет доступен по HTTP глаголу DELETE. Откройте модуль “app.js”, обновите его в соответствии с содержимым ниже: Конкретно в модуль “app.js”  были внесены следующие изменения. С 8 по 11 строку  были подключены модули “index.js”, “users.js”, “products.js”, “auth.js”. На 13 строке  был подключен модуль “mongoose”. На 14 строке  мы задаем свойство “Promise” в значение “global.Promise”, чтобы начать обмениваться сообщениями с базой данной “Mongo DB”. На 15 строке  мы подключаемся к базе данных “Mongo DB” c названием “warehouse”, мы ее ранее создавали в приложении “Robomongo”. Источник данных “mongodb://localhost/warehouse” можно разбить так: “mongodb://” протокол взаимодействия (аналоги “http://”, “tcp://”, “file://”). “localhost” - это адрес машины, на которой хостится база данных. “warehouse” - имя базы данных. На 16 строке  метод “then”  вызывается в случае успешного подключения к базе данных. На 17 строке  метод “catch”  вызывается в случае сбоя подключения к базе данных. С 33 по 36 строку мы задаем доступные глобальные маршруты, которые будет обрабатывать сервер. Надеюсь, все помнят разницу между сервером и сервисами, это не одно и то же. Сервер - это просто приложение, которое внутри себя способно содержать различные ресурсы. Сервер может запускать внутри себя различные потоки для обработки данных. Сервис - это функционал, который как раз запускается в отдельном потоке внутри сервера. Сам по себе сервис без наличия приложения ,в котором его можно разместить, работать не будет. В случае с WebAPI сервером является Microsoft IIS или отдельно стоящее исполняемое приложение с функцией self  хостинга. Мы закончили написание сервера. Запустите демон “mongod” в терминале. Запустите сервер. Вы увидите обновленное приветствие. Я бы рекомендовал вам прослушать курс “Angular JS”, автор Дмитрий Охрименко. Это один из лучших курсов, которые я когда-либо слушал. После данного курса вы без особых проблем сможете сделать клиентскую часть для сервера на “Angular JS”. Теперь давайте научимся тестировать наши REST сервисы. Тестировать сервисы можно и через Fiddler, но на macOS  у него есть проблемы с отрисовкой и работой. Поэтому откройте браузер и перейдите по адресу. “Postman” - это аналог “Fiddler”, доступный в качестве расширения для браузера “Google Chrome”. После установки расширения “Postman” откройте его. Выполним первый запрос к сервису “users” по HTTP глаголу GET. Заполните поле адрес, выберите глагол “GET”, нажмите кнопку “Send”. Результат придет - пусто. Обратите внимание, что в терминале “WebStorm” тоже пишется логирование вызовов при обращения к сервисам. Откройте приложение “Robomongo”, подключитесь к базе данных. Разверните папку “Collections” базы данных “warehouse”, выполните щелчок правой кнопкой мыши по таблице “users”, в контекстном меню выберите “View Documents”. В “Mongo DB” нет колонок, там есть всего одна колонка, в которой хранится JSON объект. Строки называются документами. Причем, в каждую строку одной таблицы можно класть абсолютно разный по структуре JSON объект. База данных позволяет такую операцию. Видим, что данных нет, это не удивительно, ведь мы еще ничего не добавляли. Давайте добавим. Перейдите в “Postman”, выберите глагол “POST”. Выберите “Content-Type” - “x-www-form-urlencoded”. Внимание, через другие типы “form-data”  “raw” работать не будет. Заданные свойства “userName”, “userPwd”, “userDesc” будут отправлены в запросе как JSON объект “{ userName: 'admin', userPwd: 'abc123!', userDesc: 'Administrator' }”. Нажмите кнопку “Send”. Придет ответ: В ответе мы видим JSON объект модели “User”, созданной на сервере. Перейдите в приложение “Robomongo”, выполните пункт контекстного меню “View Documents” на таблице “users”. Отлично, у нас появился первый пользователь :) Перейдите в “Postman”, выберите HTTP глагол “GET”. Нажмите кнопку “Send”. Вы увидите такой результат. Обратите внимание на квадратные скобки, в ответе пришел массив JSON объектов, а не один объект. Теперь давайте изменим пароль пользователю “admin”, на “12345678”. Нам понадобится идентификатор пользователя, выделите и скопируйте значение свойства “_id”. Выберите HTTP глагол “PUT”. Обновите данные так, как показано ниже. Обратите внимание на добавление идентификатора пользователя после основного маршрута “../users/”. Нажмите кнопку “Send”. В ответе получим старый JSON объект до внесения изменений. Теперь для того, чтобы посмотреть измененный объект, воспользуемся сервисом , который возвращает пользователя по его идентификатору “_id”. Выберите HTTP глагол “GET”, обновите адрес, добавьте в конец адреса идентификатор пользователя. Нажмите кнопку “Send”. Получим такой результат. Видим, что пароль пользователя был успешно обновлен и мы получили в ответе один JSON объект, а не массив пользователей. Теперь попробуем удалить пользователя. Адрес оставьте тот же. Выберите HTTP глагол “DELETE”  и нажмите кнопку “Send”. Видим, что в ответе содержится JSON объект удаленного пользователя.             Теперь проверим, доступен ли пользователь после удаления. Адрес оставьте тот же. Выберите HTTP глагол “GET”, нажмите кнопку “Send”. Видим, что пользователь действительно был удален. Также можете проверить это в приложении “Robomongo”.             Теперь приступим к тестированию сервиса “products”.             Получим список товаров. Товаров нет. Добавим первый товар. Обновим описание товара. Получим обновленный товар по его идентификатору. Удалим товар. На этом мы завершаем урок. К данной статье прикреплен архив с готовым сервером на NodeJS , в помощь  учащимся :) На следующем уроке мы: выполним рефакторинг проекта “Warehouse” под “iOS”; научимся пользоваться CollectionViewController; научимся пользоваться библиотекой “Alamofire”, в конце урока будут доступны исходники полноценного рабочего приложения; научимся сохранять объекты в настройки телефона и извлекать их; реализуем функциональность для работы со всеми сервисами, созданными в данном уроке; добавим представление регистрации; добавим представление редактирования пользователей. Материалы к статье тут.