Что за программа соап

Simple Object Access Protocol (SOAP) — это протокол на базе языка XML, который определяет правила передачи сообщений по Internet между различными прикладными системами.

Определение

Simple Object Access Protocol (SOAP) — это протокол на базе языка XML, который определяет правила передачи сообщений по Internet между различными прикладными системами. В основном он используется для удаленного вызова процедур. Изначально протокол SOAP разрабатывался с тем расчетом, что он будет функционировать «над» HTTP (дабы упростить интеграцию SOAP в Web-приложения), однако теперь могут быть задействованы и иные транспортные протоколы, например SMTP.

Предположим, что вы создаете в Internet службу доступа к приложениям; потребители взаимодействуют с этой службой, передавая ей информацию. Ваши серверы обрабатывают данные и возвращают результаты потребителям. Как лучше всего поддерживать обмен данными с системой?

Вы могли бы создать настраиваемое клиент-серверное приложение и потребовать, чтобы потребители использовали для доступа к вашей службе специальную клиентскую программу. Но если вы намерены всерьез найти себя в Internet-бизнесе, вам придется создать клиент, работающий на всех возможных клиентских платформах — Windows, Macintosh, Unix, Linux и т. д. Другими словами, потребуется написать множество различных клиентов.

Что происходит, когда мы отправляем SOAP или REST запрос

А как вы отнесетесь к использованию Web? Такое решение, естественно, вполне приемлемо, но жестко завязано на реализации браузера, и вам опять-таки придется создавать инфраструктуру, чтобы посылать и получать входящую и исходящую информацию, а также форматировать и упаковывать данные для подобного обмена. Для реализации сложных приложений можно выбрать Java или ActiveX, но тогда некоторые пользователи откажутся от ваших услуг из-за явно завышенных требований к полосе пропускания и неадекватной защиты.

Все, что требуется, — это простой протокол, который упрощает упаковку данных приложения и передает их по Web, используя адаптируемый к содержанию информации язык XML. Тем самым он гарантирует, что и отправитель и получатель смогут легко интерпретировать содержимое любого сообщения. При этом благодаря использованию в качестве транспорта Web-протокола HTTP можно будет отказаться от необходимости снижать уровень защиты межсетевых экранов.

Достаточно подробно описанный Simple Object Access Protocol (SOAP) представляет собой простой «связующий» протокол, с помощью которого узлы могут удаленно вызывать объекты приложения и возвращать результаты. SOAP предлагает минимальный набор условий, позволяющий приложению передавать сообщения: клиент может посылать сообщение для того, чтобы вызывать программный объект, а сервер может возвращать результаты этого вызова.

SOAP довольно прост: сообщения представляют собой документы XML, содержащие команды SOAP. Хотя теоретически SOAP может быть привязан к любому транспортному протоколу для приложений, как правило, он используется вместе с HTTP.

Кеннард Скрибнер, один из авторов книги Understanding SOAP: The Authoritative Solution (Macmillan USA, 2000), говорит, что SOAP работает за счет преобразования информации, необходимой для вызова метода (например, сюда относятся значения аргументов и идентификаторы транзакций) в формат XML.

Различия REST и SOAP за 4 минуты

Данные инкапсулируются в HTTP или в какой-то другой транспортный протокол и передаются адресату, в качестве которого обычно выступает сервер. Этот сервер выделяет данные SOAP из пакета, выполняет требуемую обработку и возвращает результаты в виде ответа SOAP.

Скрибнер отметил, что SOAP действует как протокол удаленного вызова процедур, во многом так же, как протокол Remote Method Invocation в Java или General Inter-ORB Protocol в CORBA.

По словам Скрибнера, поскольку HTTP и XML используются практически повсюду, SOAP, по-видимому, можно назвать самым масштабируемым из созданных на сегодняшний день протоколов удаленного вызова процедур. SOAP не рассчитан на то, чтобы действовать как полная объектная архитектура.

SOAP не заменяет собой протокол Remote Method Invocation в Java, Distributed Component Object Model и CORBA; он предлагает правила, которые могут использоваться любой из этих моделей. SOAP не является полным решением. Он не поддерживает активацию объектов или защиту. По словам Скрибнера, разработчики SOAP «уверены в том, что пользователи самостоятельно добавят этот код», надстраивая его над SOAP, вместо того чтобы делать его составной частью самого протокола.

На рисунке приводится пример, взятый из спецификации SOAP 1.1, в котором хост запрашивает у службы котировок стоимость определенной акции. Запрос SOAP встраивается в HTTP POST, а в теле запроса указывается тип запроса и параметр — символ акции. Ответ также предоставляет собой объект XML, инкапсулированный в ответ HTTP с единственным возвращаемым значением (34,5 в данном случае).

Особенности SOAP

С помощью SOAP разработчики могут создавать Web-службы настолько же оперативно, насколько быстро будут написаны сообщения SOAP для вызовов программ для существующих приложений, а затем добавить эти приложения в простые Web-страницы. Но, кроме того, у разработчиков есть возможности использовать вызовы SOAP в выделенных приложениях и создавать приложения, которые можно переносить на Web-страницы других людей, и тем самым избежать трудоемкого и дорогостоящего процесса разработки.

По мнению Марка Стивера, еще одного автора книги Understanding SOAP, именно эту цель преследует Microsoft в своей перспективной платформе .Net. «Здесь SOAP выступает во всем своем блеске. Он дает разработчикам действительно прекрасные возможности для создания приложений, избавляя их от мучений по поводу вероятной несовместимости», — утверждает он.

Пример SOAP

Следующий пример иллюстрирует запрос SOAP, называемый GetLastTradePrice, который позволяет клиенту послать запрос о последних котировках определенных акций.

POST/StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Type: text/xml; charset=»utf-8″
Content-Length: nnnn
SOAPAction: «Some-URI»

В первых пяти строчках (часть заголовка HTTP) указывается тип сообщения (POST), хост, тип и длина информационного наполнения, а заголовок SOAPAction определяет цель запроса SOAP. Само сообщение SOAP представляет собой документ XML, где сначала идет конверт SOAP, затем элемент XML, который указывает пространство имен SOAP и атрибуты, если таковые имеются. Конверт SOAP может включать в себя заголовок (но не в данном случае), за которым следует тело SOAP. В нашем примере в теле содержится запрос GetLastTradePrice и символ акций, для которых запрашиваются последние котировки. Ответ на этот запрос может выглядеть следующим образом.

HTTP/1.1 200 OK
Content-Type: text/xml; charset=»utf-8″
Content-Length: nnnn

И опять-таки первые три строки — это часть заголовка HTTP; само сообщение SOAP состоит из конверта, который содержит ответ на исходный запрос, помеченный GetLastTradePriceResponse, и включает в себя возвращаемое значение, в нашем случае 34,5.

Источник: www.osp.ru

Рельсы веб-интеграции — REST и SOAP

Сервисы веб-интеграции (или веб-сервисы) — это технологии, при помощи которых различные системы передают друг другу данные (двусторонний обмен).

9 из 10 веб-сервисов работают по HTTP или родительскому протоколу.

В упрощенном виде, большинство запросов к таким сервисам — это стандартные ссылки, при помощи которых переходим к нужному ресурсу для обмена с конкретными базами или выполнения определенных действия.

Одним из главных отличий веб-служб от простых HTTP запросов является наличие задокументированной четкой структуры с рядом общих стандартов. Например, если применять SOAP (строгое к правилам решение), то возможно сразу приступать к настройке структур БД и другим функциям, т.к. все начальные моменты учтены и решены.

• XML-RPC (XML Remote Procedure Call) — протокол для удаленного доступа к использованию XML. Предшественник SOAP, прост в применении;
• SOAP (Simple Object Access Protocol) — стандартный протокол версии W3C, который структурирован и весь задокументирован;
• JSON–RPC (JSON Remote Procedure Call) — относительно современный вариант XML — RPC. Главное отличие состоит в том, что сведения передаются только в формате JSON;
• REST (Representational State Transfer) — это архитектурный стиль, основанный на методах HTTP;
• специализированные протоколы под конкретные задачи (GraphQL, OData, Ajax);
• редко встречающийся, но эффективный gRPC — используется для передачи данных в двоичном виде и использует HTTP/2 в качестве транспорта.

Здесь мы поговорим о том, что же такое SOAP и REST.

Что такое SOAP

Простыми словами SOAP (или Simple Object Access Protocol) – это простой протокол доступа к объектам, в котором не только вызов процедур, но и передача БД происходит в формате XML.

• Envelope. Обязательный корневой элемент. Непосредственно он определяет сообщения и пространство времен;
• Header. Он же заголовок. Не является обязательным элементом, но содержит необходимые атрибуты для обработки сообщения (информация об идентификаторе, маршрутизации или безопасности);
• Body. Обязательный элемент, в котором содержится основная информация из сообщения;
• Fault. Необязательный, но полезный элемент. В нем содержится информация об ошибках, которые возникают в процессе обработки сообщений.

Преимущества SOAP

Недостатки SOAP

стандартизация по версии W3C

сложно и долго парсить в XML

понятная поддержка с продуктами Microsoft

Что такое REST

Representational State Transfer — примечание — это архитектурный стиль, а не протоколом. Простыми словами REST — это набор правил и условий для программиста. Если специалист придерживается этим условиям, настройка обмена данными его проекта с другими сервисами будет быстрой и безболезненной.

Особенность REST — данные передаются в исходном виде, не требуя конвертации. Это создает нагрузку на сеть, но разгружает веб-сервер.

• GET — получение;
• POST — добавление;
• PUT — изменение;
• DELETE — удаление.

На практике в 9 из 10 случаев используешь лишь 2 — GET, чтобы получить данные и POST для всего остального.

Подсказка бывалого программиста

Преимущества REST

Недостатки REST

прост в программировании

нет больших требований к ресурсам

сложно и долго парсить в XML

нет требований к замысловатым программным надстройкам

нет чётких методов для управления базами

Чем же настроить веб-интеграцию?

Так каким же методом интеграции правильно пользоваться?

Для ответа на этот вопрос важно знать, над каким проектом идет работа.

XML-RPC метод морально и технически устарел — JSON-RPC его заменяет куда более эффективно. При этом сами протоколы RPC применимы только в простейших системах, имеющих небольшое число информации и API-методов.

SOAP популярен для комплексных корпоративных проектов, где применяется сложная замысловатая логика и необходимы единые стандарты, актуальные для продолжительного использования (комплексная автоматизация для больших предприятий создаётся годами).

Но, самым распространенным в Сети является REST. И это объяснимо — когда “твой код” подчиняется правилам CRUD, интеграция с подавляющим большинством современных популярных сервисов запустится быстро. А с развитием спецификации OpenAPI и ряда инструментов Swagger, появилась возможность стандартизированного документирования разрабатываемого API, и даже тестирование взаимодействия с этим API без ожидания полноценной реализации.

Веб-интеграция и Битрикс

О применении и настройках различных интеграций сервисов и ресурсов на Битрикс мы написали отдельную статью с примерами.

Чего там пока нет, но планируем дописать — 1С-Битрикс: Управление сайтом выпустили отдельный готовый модуль для работы с REST API.

Использование REST и SOAP в больших бизнес-проектах

Настройка интеграции различных веб-сервисов между собой — типичная задача для веб-интегратора ИНТЕРВОЛГА. Приведем пример использования SOAP и REST интеграций в рабочем проекте.

Компания ЕВРАЗ — один из лидеров российского и мирового рынка металлопроката и металлоизделий. ИНТЕРВОЛГА уже много лет сотрудничает с этим металлургическим гигантом и создаёт для него инновационные автоматизированные веб-системы, применяя и REST и SOAP-технологии. А теперь перейдем к конкретике.

Разработка Личного кабинета для партнеров ЕВРАЗ Металл Инпром. Учетная система компании выступает веб-клиентом, а сайт сервером. Интеграция и передача необходимых сведений настроена SOAP методом.

Выводы

Все технологии нужны, все методы важны. Главное — определить подходящий для вашего проекта вариант веб-интеграции и правильно его реализовать.

Компания ИНТЕРВОЛГА — компетентный веб-интегратор, в которой собраны опытные программисты, способные подобрать и реализовать необходимые IT-решения для интеграции.

Источник: www.intervolga.ru

Что за программа соап

Не так давно в нашем блоге рассказывалось об освоении тестирования через REST API. Я же хочу поделиться опытом тестирования SOAP, «старшего брата» REST.

SOAP (Simple Object Access Protocol) является стандартизированным протоколом передачи сообщений между клиентом и сервером. Обычно он используется совместно с HTTP(S), но может работать и с другими протоколами прикладного уровня (например, SMTP и FTP).
Тестирование SOAP с точки зрения техник тестирования ничем принципиально не отличается от работы с другими API, но для его проведения требуются предварительная подготовка (в плане теории протокола) и специальные инструменты для тестирования. В данной статье я хотела бы сформулировать небольшой чек-лист необходимых знаний и навыков, который будет одинаково полезен как тестировщику SOAP (зачастую не представляющему, «за что хвататься» после постановки задачи), так и менеджеру, вынужденному оценивать знания тестировщиков и разрабатывать планы по обучению.

Теоретическая база

Тот факт, что SOAP является протоколом, имеет большое значение для тестирования: нужно изучить сам протокол, «первичные» стандарты и протоколы, на которых он базируется, а также (по мере необходимости) существующие расширения.

XML
XML – язык разметки, схожий с HTML. Любое сообщение, отправляемое/получаемое через SOAP, – это XML-документ, в котором данные удобно структурированы и легко читаемы, например:

Более подробно про XML можно узнать на w3schools или codenet (по-русски). Обязательно обратите внимание на описание namespaces (метод разрешения конфликтов при описании элементов в XML) – в SOAP их использование необходимо.

XSD
При работе всегда удобно иметь стандартизированное описание возможных XML-документов и проверять их на корректность заполнения. Для этого существует XML Schema Definition (или сокращенно XSD). Две главные фичи XSD для тестировщика – это описание типов данных и наложение ограничений на возможные значения. Например, элемент из предыдущего примера можно сделать необязательным для заполнения и ограничить его размер 255 символами с помощью XSD:

XSD – это сила и мощь. Чем подробнее описан XSD, тем меньше головной боли доставит вам тестирование сервиса. С помощью выстроенной схемы сервис сам сможет валидировать полученные данные и возвращать пользователю ошибку.

Таким образом, у вас отпадает необходимость тестировать «любимые» классы эквивалентности для форматов заполнения полей (конечно, при условии подробного и корректного описания XSD, а также реализации проверки запроса на соответствие схеме на сервере). Следовательно, первым делом при тестировании SOAP вы должны проверить документацию – XSD. Довольно часто встречаются ошибки в XSD в виде некорректно прописанных ограничений или случайно закравшихся кириллических символов. Подробнее прочитать про XSD можно опять же на w3schools и codenet (по-русски).

WSDL
Web Services Description Language (WSDL) – это язык на основе XML, который используется для описания веб-сервисов. В WSDL-документе содержится информация о местонахождении сервиса и доступных методах (операциях); для каждого метода определяются параметры отправляемого и получаемого сообщения. Обратите внимание на то, что XSD может быть «встроен» внутрь WSDL-документа (например, у Yandex Speller API).

WSDL-документ – это «капелька магии» в мире SOAP. Его можно сгенерировать из классов для сервера, а уже из него можно создать классы для клиента. Главное – не забывать проверять адекватность и доступность WSDL-документа для пользователей.

Протокол SOAP
У «героя» нашей статьи есть две основные версии протокола: 1.1 и 1.2. Для начинающего тестировщика различия между этими версиями не так принципиальны. Важно лишь знать, какую версию использует ваш сервис (в некоторых случаях применяются сразу обе версии, и тогда объем тестирования возрастает). SOAP задает формат сообщений, которыми обмениваются клиент и сервер, в нем же описываются подробности обработки приложениями конкретных фрагментов сообщений. Например, определенные элементы в заголовке позволяют создавать приложения, в которых сообщения сначала проходят через несколько промежуточных «станций», а только потом достигают конечного получателя.

Пример запроса checkText через Yandex Speller API:

И полученный ответ:

Прочитать о формате SOAP сообщений можно на w3schools.

Расширения SOAP
В работе вам также могут встретиться различные «расширения» SOAP – стандарты типа WS-* . Одним из самых распространенных является WS-Security позволяющий работать с шифрованием и электронными подписями. Нередко вместе с ним применяется WS-Policy, с помощью которого можно управлять правами на использование вашего сервиса.

Пример использования WS-Security:

Все эти расширения – достаточно сложные конструкции, используемые далеко не в каждом SOAP-сервисе; их подробное изучение на начальном этапе освоения тестирования SOAP вряд ли будет актуально.

Инструменты

Как вы уже поняли, SOAP – дело серьезное, для работы с ним нужно знать теорию и многочисленные стандарты. На практике такая сложность привела бы к весьма ощутимым трудозатратам (например, нужно было бы каждый раз смотреть схему в блокнотике и слать запросы curl-ом). Поэтому были созданы инструменты, облегчающие работу с SOAP.

Редакторы XML / XSD
Хороший тестировщик начинает тестирование еще на стадии написания документации, поэтому для проверки схем удобно использовать специальные редакторы. Два самых известных – Oxygen (кроссплатформенный) и Altova (только для Windows); оба они являются платными. Это очень мощные программы, которыми активно пользуются аналитики при описании сервисов.

В моей практике полезными оказались три фичи редакторов: визуализация XSD, генерация XML на основе XSD и валидация XML по XSD.

1. Визуализация XSD нужна для наглядного представления схемы, позволяющего быстро вычленить обязательные элементы и атрибуты, а также существующие ограничения. Например, для запроса CheckTextRequest обязательным является элемент text, а необязательными – все три атрибута (при этом у атрибута options установлено значение по умолчанию – ноль).

Визуализация необходима в том случае, когда типов и ограничений в схеме много. Если вам нужна только она, и вы не хотите платить за специальные редакторы, то можно рассмотреть бесплатные альтернативы (например, JDeveloper).

2. Генерация XML на основе XSD полезна тогда, когда вы хотите увидеть корректный пример сообщения. Я пользуюсь ей для того, чтобы быстро поэкспериментировать с возможным заполнением сообщения и проверить нюансы работы ограничений.

3. После использования фичи из пункта 2 полезно провести валидацию XML по XSD – то есть проверить сообщение на корректность. Вместе фичи 2 и 3 позволяют отлавливать хитрые дефекты в XSD еще тогда, когда сам сервис находится в разработке.

Инструмент тестирования – SoapUI

Тестирование SOAP практически всегда подразумевает использование SoapUI. Прочитать про использование этого инструмента можно в разных источниках (источник 1, источник 2), но эффективнее всего будет ознакомиться с официальной документацией. Я выделяю 8 условных уровней владения SoapUI:

Уровень 1 – умею отправлять запросы
Научитесь создавать проект на основе WSDL. SoapUI может сгенерировать все необходимые запросы для вас; вам останется лишь проверить правильность их заполнения и нажать кнопочку «Send». После выработки навыков создания корректных запросов вы должны овладеть искусством формирования некорректных запросов, вызывающих появление ошибок.

Уровень 2 – умею делать Test Suites и Test Cases
Начните делать мини-автотесты. Тест-комплекты и тест-кейсы позволяют создавать сценарии тестирования API, подготавливать данные для запросов и автоматически проверять полученный ответ на соответствие ожидаемому. На первых порах их можно использовать просто как коллекции запросов. Например, если вы завели дефект и хотите быстро проверить его после фикса, можно выделить отдельный тест-комплект конкретно под запросы-дефекты.

Уровень 3 – умею писать Assertions
После освоения тест-кейсов вам будет полезно научиться делать их автоматически проверяемыми. После этого вам уже не нужно будет искать «глазами» информацию об ответе: при наличии автоматической проверки кейсы будут помечаться зеленым (если проверка пройдена) или красным (если не пройдена). SoapUI предоставляет большой набор возможных проверок (assertions), но самые удобные и простые – это Contains и Not Contains. С их помощью можно проверить факт наличия конкретного текста в полученном ответе. Эти проверки также поддерживают поиск с помощью регулярных выражений.

Уровень 4 – использую XPath и/или XQuery в Assertions
Для тех, кто немного знаком с автоматизацией тестирования UI с помощью Selenium, язык XPath – знакомая вещь. Грубо говоря, XPath позволяет искать элементы в XML-документе. XQuery – похожая технология, которая может использовать XPath внутри себя; этот язык гораздо мощнее, он напоминает SQL. Оба эти языка можно использовать в Assertions. Проверки с их помощью получаются более прицельными и стабильными, поэтому ваши кейсы будут пользоваться большим доверием.

Уровень 5 – умею писать сложные тесты с помощью специальных шагов

В тест-кейсах может содержаться не только один запрос, но и несколько (к примеру, когда вы хотите эмулировать стандартный сценарий работы пользователя «создать сущность» → «экспортировать сущность»). Между запросами могут находиться другие специальные шаги, например:

• Properties и Property Transfer (помогают переиспользовать данные и передавать их между запросами);
• JDBC Request (используется для получения данных из базы данных);
• Conditional Goto (позволяет сделать разветвления или циклы в тест-кейсе);
• Run TestCase (помогает вынести какие-то типовые запросы в отдельные тест-кейсы и вызывать их там, где нужно).

Уровень 6 – использую скрипты на Groovy

SoapUI позволяет писать скрипты на Groovy в различных местах. Простейший случай – это генерация данных в самом запросе с помощью вставок $. Я постоянно пользуюсь такими вставками:

• $ – для вставки текущей даты и времени в необходимом формате;
• $ – для вставки корректно сформированного случайного GUID.

Полноценные скрипты можно использовать в качестве шагов в кейсах и проверках. В какой-то момент вы обнаружите, что сразу несколько специальных шагов из пятого уровня можно заменить одним скриптом.

Уровень 7 – использую MockServices
SoapUI на основе WSDL может генерировать Mock-объекты. Mock-объект – это простейшая симуляция сервиса. С помощью «моков» можно начать писать и отлаживать тест-кейсы еще до того, как сервис реально будет доступен для тестирования. Также их можно использовать в качестве «заглушек» для временно недоступных сервисов.

Уровень 8 – бог SoapUI
Вы знаете разницу между платной и бесплатной версиями SoapUI и используете SoapUI API в коде. Вы используете плагины и запускаете выполнение кейсов через командную строку и/или CI. Ваши тест-кейсы просты и легко поддерживаются. В общем, вы «съели собаку» на этом инструменте. Я бы с радостью пообщалась с тем, кто освоил SoapUI на таком уровне.

Если вы являетесь таковым – отпишитесь в комментариях!

Тестирование с помощью языков программирования

В какой-то момент у вас может возникнуть мысль, что проще писать тесты не в SoapUI, а просто на языках программирования. Это нормально. Будучи UI-инструментом, SoapUI имеет свои недостатки, которые в лучшем случае решаются приобретением платной версии, а в худшем – «костылями» и большими затратами времени на поддержку тестов. Для работы с протоколом SOAP в языках программирования существуют специальные библиотеки. Так, в Java можно использовать Axis2 (подробные примеры доступны в серии статей на IBM developerWorks), в Python – библиотеки suds либо zeep, в Groovy – библиотеку groovy-wslite.

Приведу пример того, как выглядит запрос к YandexSpeller API, выполненный с помощью groovy-wslite:

Насколько я знаю, высокоуровневых фреймворков (по типу Rest-assured) для тестирования SOAP пока не существует, но недавно появился интересный инструмент – karate. С его помощью можно описывать кейсы для тестирования SOAP и REST в виде сценариев по типу Cucumber / Gherkin. Для многих тестировщиков обращение к karate будет идеальным решением, ведь такие сценарии по сложности написания и поддержки кейсов будут лежать где-то посередине между использованием SoapUI и написанием собственного фреймворка для тестирования SOAP.

Вряд ли вам когда-либо захочется тестировать SOAP просто так, для себя (как могло бы получиться с REST-ом). Это тяжеловесный протокол, который используется в серьезных корпоративных решениях. Но его тяжеловесность одновременно является подарком тестировщику: все используемые технологии стандартизированы, имеются качественные инструменты для работы. От тестировщика требуется лишь желание их изучить и использовать.

Давайте соберем воедино тот самый чек-лист необходимых навыков для тестировщика. Итак, если вы только начинаете тестировать SOAP сервисы, вам нужно знать и уметь использовать:

• XML.
• XSD.
• WSDL.
• SOAP.
• Редакторы XML / XSD (на уровне визуализации XSD).
• SoapUI на уровне 1.

Как видите, основной упор приходится на изучение стандартов, в SoapUI достаточно просто уметь выполнять запросы. По мере погружения в тестирование SOAP перед вам будут возникать задачи, которые потребуют уже более серьезных навыков и знаний, но не стоит пытаться изучить всё и сразу. Гораздо важнее последовательность в повышении уровня сложности выполняемых задач. Следуя этой рекомендации, в один прекрасный момент вы поймете, что стали хорошим специалистом в этой области!

Источник: quality-lab.ru