Собеседование на ручного тестировщика (Middle QA) | Выпуск 11

ruticker 05.03.2025 11:07:43

Текст распознан YouScriptor с канала Quality Academy | Создаем тестировщиков с нуля

распознано с видео на ютубе сервисом YouScriptor.com, читайте дальше по ссылке Собеседование на ручного тестировщика (Middle QA) | Выпуск 11

Всем привет! Меня зовут Артём, я автор и преподаватель в школе Quality Academy. Сегодня у нас очередное, уже второе, кстати, публичное собеседование с Амиром. Вот к нам пришёл сегодня Амир. В прошлый раз мы с ним говорили на тему, ну, по большей части на тему фронта. Он хорошо себя показал. Сегодня мы решили поговорить на тему бэкенда, в сторону бэкенда. Поэтому думаю, будет интересно. Небольшая ремарка, ребят: те, кто смотрит, если проходят собеседования и если вдруг есть необходимость, скажем так, качественной подготовки, то на базе Academy можно будет подготовиться с нуля. Также у нас есть вариант трудоустройства: берём внешних учеников и помогаем подготовиться выйти на рынок. И пока что у нас процент трудоустройства 100%. Да, пока что у нас такие показатели, поэтому приходите, я думаю, не пожалеете. Окей, Ар, привет! Привет! Ну что, давай приступим, с корабля на бал. Давай сразу перейдём к такой, пока что небольшой теории. Давай поговорим про клиент-серверную архитектуру. Что за такой зверь? В чём особенность этого зверя, плюсы и минусы? Угу, клиент-серверная архитектура — довольно-таки популярная архитектура, которая сейчас очень часто используется. То есть это архитектура, которая подразумевает, как правило, либо двухуровневую, либо трёхуровневую. То есть это клиент, грубо говоря, компьютер, на котором стоит веб-приложение или нативное приложение, делает запрос. А запрос идёт на сервер, сервер его обрабатывает и возвращает ответ. То есть вот в таком самом обычном случае двухуровневая клиент-серверная архитектура выглядит. Угу, хорошо. А в чём преимущество такой архитектуры по сравнению с, может быть, безсерверной? Да, на самом деле, преимущество точно в том, что сервер — это всё-таки удалённый источник, и у клиента нет возможности на сервере проводить какие-то инъекции, изменения, повреждать какие-то данные. То есть, как правило, у клиента есть определённая оболочка, которая даёт тебе ряд определённых полномочий, но ты, например, не имеешь полномочий админа. И, соответственно, пользуясь как клиент, ты не можешь испортить, грубо говоря, сервер, поломать его и так далее. В этом однозначное преимущество — безопасность. Да, да, да. Хорошо. Ещё давай что-нибудь, ну или, может, недостатки сможешь сказать, от них уже к преимуществам перейти. Угу, недостатки клиент-серверной архитектуры. Угу, угу. А, нет, ну вот если мы посмотрим на эту историю... Так что давай вот смотри: раньше у нас игры в основном продавались на дисках. Угу, да. То есть тебе, чтобы поиграть в игру, нужно купить диск с конкретной версией этой игры и на компьютер установить. То есть это десктопная история, безсерверная. Вот сейчас большинство игр онлайн. Да, и вот дальше рассуждай, в чём плюсы, в чём минусы. Не обязательно полностью онлайн, может быть, да, то есть, но у неё есть... Я понял, я понял. Всё преимущественно общение по сети. То есть то, что идёт общение по сети, это можно обновлять данные. И чтобы, например, получить какое-то обновление или исправление какой-то ошибки, тебе не нужно устанавливать какой-то специальный патч. То есть можно проводить онлайн-обновление, даже можно, как сказать, бесшовное. То есть в этом плюс. Да, согласен. Но в том числе, отталкиваясь от этого же, есть минусы клиент-серверной архитектуры в том, что есть зависимость сети. То есть если ты работаешь как клиент, и любое твоё действие посылает тот или иной запрос на сервер, то, соответственно, без устойчивого соединения или вообще какого-либо соединения ты не можешь пользоваться полноценно этой клиент-серверной архитектурой. Согласен, согласен. То есть зависимость от сервера есть такое. Окей, ещё знаешь, сейчас есть такие сервисы, которые позволяют удалённо, ну, подключаться к компьютеру. Да, и на нём играть. Зачем? Ну тут используется, я не помню, как именно технология называется, но, например, если твой компьютер не имеет достаточных мощностей в плане железа, там, видеокарта, процессор и так далее, то, запустив удалённый клиент, который просто включается удалённо к определённой машине, ты можешь, через который, в данном случае, на твоём компьютере просто выглядит как клиент, и передача трафика идёт, ты можешь запускать более мощные приложения и, в данном случае, использовать там необходимое ПО или играть в интересующие игры, при этом имея необходимых мощностей на твоём физическом клиенте. Да, то есть вот один из плюсов — это как раз мы выносим нагрузку на сервер, который выступает неким "мега-мозгом". Да, и практически любого клиента можно выполнять мощные всякие операции. Да, да, да. Окей, окей. Ну из недостатков можно ещё отметить, скажем так, зависимость. Мы сказали, что безопасность мы как бы обеспечим безопасность за счёт того, что данные хранятся, скажем так, профессионально, да, то есть на Linux-серверах, всё такое, безопасность, уровни доступа, вот эта вся история. Но с другой стороны, это некая централизованность данных. Как бы мы их не разбивали на разные сервера, всё равно эта централизованность есть, или у нас сливаются данные сразу, ну, какого-то большого объёма. Да, нежели если это отдельный персональный комп, взломали какой-нибудь клиент. Окей, окей. А слышал про понятие "тонкий" и "толстый" клиент? Да, да, да. А-а, я его слышал только на практике, когда мы работали, ну, на своей прошлой работе, поэтому не уверен, что я смогу правильно дать определение. Но отличие тонкого и толстого клиента заключается в том, что в отличие от тонкого клиента на толстом клиенте всё-таки есть часть ресурсов, необходимых там для работы. И этим отличается толстый клиент от тонкого, что толстый может хранить в себе часть информации, там, выполнять часть операций на своей стороне, не взаимодействуя с каким-то удалённым сервером. В отличие от тонкого клиента, который, грубо говоря, просто является оболочкой, и все вычисления, все мощности заимствуют сервера там через сеть. А пример можешь привести тонкого клиента? Да, ну та же самая какая-нибудь веб-форма на странице. То есть ты открываешь какой-нибудь, казалось бы, просто URL, но это выполняет функции какого-то веб-приложения. И любые вычисления, которые ты производишь там, например, приложение инвестиций для банка. То есть ты строишь графики, строишь модели, он даёт тебе какое-то процентное соотношение. В данном случае веб-приложение, страница, на которой ты выполняешь все необходимые действия, она выполняет функцию тонкого клиента. В отличие, например, от толстого клиента. То есть это какое-то комбинированное ПО, по-моему, приложение называется. Вот есть нативный, есть веб, а есть комбинированный, если я не ошибаюсь в терминологии. Гибридный? Да, есть. Да, гибридные. Вот, то есть какой это клиент, который там через EXE-шник ты ставишь себе, он часть функций, там, каких-то, например, выполняет на своей стороне, а уже какую-то онлайн-информацию, там, или актуальную информацию, необходимые данные подтягивает из сети по запросу. Да, есть такое. Да, абсолютно согласен. То есть типичный тонкий клиент — это браузер сам по себе, ну и, соответственно, всё, что в нём, это тоже является его частью. Само, ну, нет связи с сервером, либо может быть связь с сервером, например. То есть у нас тут возникают вариации. Да, некие есть вот тонкий клиент, который сам вообще ничего не делает, ну, практически, там, уберём там-то базовые вещи на JS, только отображает. Толстый клиент и вычисляет, и может, и хранить, и отображать. И есть какие-то промежуточные, да, которые могут, например, только вычислять и отображать, а хранят отдельно на сервере, на удалённом. Да, вот комбинация возникает. Хорошо, окей, окей. Давай перейдём к практике тогда. Сейчас тебе отправлю первую задачку. Получится же пошарить? Эж, вторая. Ну, в принципе, они писать пока что. Угу, вот отправил в чатик. Да, сейчас. Ну, браузер видно нормально? Видно? Да, угу, грузится. Отлично, отлично. Вот давай я зачитаю. То есть называется "Интеграция двух систем". Есть интеграция двух систем. В системе номер один через интерфейс создаётся клиент, клиент-сущность. В виде Линта это Лин по инжен. Вме номе отобразится в интерфейсе этой системы, но в результате создания клиент почему-то не отображается в интерфейсе системы номер два. Твои действия по поиску ошибки. Ты можешь рассуждать, варианты предлагать, то вот как бы ты действовал, куда бы смотрел, что использовал? Я могу просто для себя взять ручку, листочек, повально, как удобно. В системе создаётся клиент через интерфейс. Угу, интеграции должен передаваться системе 2 и отобразиться в интерфейсе. То есть у второй системы тоже есть интерфейс, условно говоря, клиент один — это условно, у нас есть форма создания клиента или создания заказа, а второе — это, например, допустим, какая-нибудь сушка, которая имеет визуальную часть и нет. Представь это так: смотри, например, у нас есть, ну, пускай будет маркет, этот Wild, интегрирован с некой системой, которая позволяет удобно пользоваться заказами, там, смотреть какие-то отчётности, да, то есть некая API, то что нету. И когда мы создаём заказ, этот заказ должен отобразиться в этой системе. Тоже отображается, не отображается. Первым делом, конечно, мы будем смотреть под капот, когда мы инициируем, будь то клиент какой-нибудь или приложение. То есть мы смотрим, например, на ашку. Я бы посмотрел на запрос. То есть идёт ли инициация запроса, приме, условно, методом POST? Идёт ли передача данных? А что значит посмотреть на ашку? Куда смотреть? Что это? Ну, я, например, открою вкладку Network в DevTools и посмотрю, идёт ли запрос после нажатия кнопки, например, там, "Создать заказ" или "Создать клиента". То есть во вкладке Network увижу ли я отправку соответствующего POST-запроса? Ну, хорошо, давай так: ты там запроса не находишь. Я запроса не нахожу. Это плохо. Значит, у нас форма не работает. И тогда нужно проверить вообще наличие соединения, интернет-соединения. Если запрос не отправляется, значит, возможная проблема. То есть кнопка не кликабельна или форма не работает полноценно. Может быть такое? Согласен, да. Если она кликабельна, но при этом не идёт отправка запроса, то нужно посмотреть, вообще идёт ли передача трафика. Я, например, это мне в голову приходит, какой-нибудь тот же самый DevTools. То есть проверить, вообще, просто передачу информации. Ещё можно Char использовать, Fiddler. То есть есть ли вообще интеграция. Ну давай так, что трафик есть, интернет работает. Какие здесь могут быть проблемы с фронтом? Давай даже не так. Какие могут быть проблемы не только с фронтом вообще вот в этой ситуации, когда запрос не уходит? Угу, угу, запрос не уходит. Ну, первое, мы уже назвали, что кнопка не работает. Потом есть мысль, что передача нет. Если он не уходит вообще, то то, что запрос сам передаётся неправильно, тут не подходит. Какие-то ошибки можем найти где-то в логе, может быть, в логе, да, да, да, да. А, ну у нас же есть в самом DevTools, например, тот же самый вкладка логирования. Угу, да, абсолютно. Я просто, я могу сейчас, могу ли я во время выполнения задания открыть DevTools и попробовать найти эти логи? Можешь, но я думаю, что особо смысла нет. На самом деле долго не остановимся. Первый кейс, то есть проблема с фронтом. Что можно ещё исключить, чтобы точно знать, что проблема с фронтом? Что может быть с запросом? Это редко для POST-запроса, но всё-таки нам это нужно исключить. Можно ещё раз повторить вопрос? А как исключить? Ну, как бы другой кейс, связанный с отправкой запроса, да, то есть вдруг не на фронте проблема, не с формой проблема. Угу, а какой ещё кейс может быть? Э, речь не про идемпотентность POSTа или... Ну, а что ты имеешь в виду? Ну, допустим, у нас уже до этого был создан заказ точно такой же, например, а другим клиентом, аналогичным кем-то ранее, и мы нажимаем отправку запроса, мы и он не происходит, потому что, допустим, есть зашита какая-то проверка на дублирование данных на стороне клиента или... Ну, на стороне клиента. Ну, давай так, это может быть, может быть такое. Да, почему нет? Типа как это бывает, там, какие-то одинаковые сущности создаёшь, и типа... Угу, нельзя создать, нам не может. А кэш нам не может помешать в этом случае? Вот, да, именно. Именно по этому кейсу, как бы с проверкой дубликатов обычно реализовано на сервере, потому что нам нужно доступ к данным каким-то, да, то есть... Ну, ага, это на клиенте тоже может быть, но непонятно, с чем сравнивать, с какими данными. Если мы данные где-то запишем, типа, стод, но нам нужно их постоянно будет обновлять, чтобы сравнивать. Ну, короче, неудобно будет на клиенте делать валидацию такую. Вот, а вот зашивать практически POST можно, правильно? Да, то есть он по дефолту не кешируется у нас, да, то есть исключаем кэш. А как исключаем? Либо почистить страницу, либо, по-моему, у нас в настройках есть тоже не кешировать данные. То есть ты выбираешь определённые настройки в браузере, что кешируется, что нет. Но да, да, да. Обычно, как всегда, тех, особенно, вот обычным юзерам помогает это просто постить, сбрасываешь и перезагружаешь страницу и выполняешь тот же запрос. Хорошо, хорошо. Окей, давай дальше двигаться. То есть всё-таки этот кейс оставим. Запрос уходит. Варианты дальше. Запрос уходит, на втором клиенте. Запрос уходит неправильным способом. Есть проблемы, ошибки в теле. То есть неправильно идёт передача данных. А возможно, API настроена таким образом, что, например, мы отправляем POST, а он может обновлять данные только PATCH-ом или PUT-ом. А, то есть неправильно. Угу, идёт передача данных. Либо в теле неправильная информация. То есть, а мы каким-то образом на клиенте можем в той или иной форме ввести больше символов, чем это заложено в системе. То есть происходит ошибка обработки. Как это поймём? Как мы это поймём? Что именно такое случай? Э, документация, то есть... Нет, у нас же есть документация. Пока что. Ну давай так, нет документации. Она может быть, но как бы, как ты это поймёшь? Доступа тебе же нужно за что-то зацепиться, чтобы у тебя такие мысли возникли. За что ты будешь цепляться? Куда смотреть будешь? Угу, может быть, те поможет. Как я могу сейчас? Только открыть его и попробовать найти, но так сразу с ходу. А, просто не открывай его. Я ответа не дам, к сожалению. Открывай сейчас, я открою его в отдельной вкладке. Нужна помощь? Я не знаю, грузит? Повтори, пожалуйста, у тебя погрузила? У меня просто нет, что прогрузилась. Вот страничка, вот сейчас появилась. Она? Давай, давай порассуждаем, пока у нас время ещё есть немножко. Вот у нас две системы. Да, буду такими наводящими. Смотри, у нас есть, по сути, одна система, у которой есть фронт, угу, который есть фронт, вероятно, есть, наверное, БД. Ну, мы можем предположить, есть БД, есть сервер. И у второй системы есть фронт, есть сервер, есть БД. А как эти обычные системы взаимодействуют между собой? API, API. Да, какая самая популярная API? Ну, подход HTTP. Да, да, да, HTTP — это протокол, пишка. Да, да, да. Вот эти две системы взаимодействуют между собой. Соответственно, когда у нас системы взаимодействуют, да, это как две дощечки, мы как бы крепим, да, и проблема всегда интеграции возникает в вот этих узлах, это сные швы конструкции. То есть где мы свариваем, там могут быть проблемы. В принципе, ну, проблемы тоже могут быть. Но, скажем так, уже интеграция её с другой системой, например, вот как мы сейчас говорили, фронт, он же как бы тоже типа интегрирует, по сути своей, да, типа логика фронта интегрирована тоже с оболочкой браузера, с редиректом и чему-то проб. Сражения. Вот давай вот на эти узлы посмотрим. Могут ли там какие-то проблемы быть? Как они данными обмениваются? Мы про брокер сообщений говорим, например, может быть такое? Это уже усложняли. Тебе проще будет. Давай так, порассуждаем. Есть БК, допустим. Ну, мне просто вот ко очень часто используются брокеры сообщений, такие как Kafka. В данном случае, то есть в Kafka это организовано там очередями, и с самим брокером сообщений может быть возникнуть проблема, что там при обработке запроса со стороны клиента он просто не публикует этот запрос в очередь, который там потом N2 схватит. А, ну, второй, второй, как система номер два. Но это вот, э, если ты говоришь, что усложняет, значит, можно и без брокера сообщений рассмотреть этот вопрос узла. Да, брокер у нас хорош. Ну, даже не то что хорош, он необходим, когда у нас микросервисы. Да, мы с тобой можем рассмотреть микросервисы как с брокером, так и без брокера. Но мы с тобой начали с интеграцией разных систем, это отдельные сервисы. Ну давай так, вот ты открыл, ты открыл вкладку, запрос ушёл. Что ты там можешь увидеть? Ну, статус можешь увидеть. Он что-то может дать понять статус. Ну да, самое банальное. То есть... А неужели в этом вопрос был? То есть что по статус-коду мы определяем, грубо говоря, что если двухсотка там какая-нибудь, то всё нормально. Неужели всё настолько просто было? Ну смотри, не совсем. Не совсем. Это как бы одна часть. Но смотри, у нас-то проблема-то есть, у нас же клиента не отображается во второй системе. Ну да, да, да. Я понял, я понял. Просто я хотел тебя услышать разные кейсы, разные случаи. Вот если такой там статус-код, вот значит, вот здесь проблема. Если вот такое, то вот надо дальше там смотреть. Я понял, я понял, я совсем не туда ушёл, честно. Я потому что, ну, статус-коды, знаешь, как будто это пря самое банальное, и я подумал, даже как-то не рассмотрел этот вопрос, честно. Вообще признаюсь, ужасно стыдно. А, ну раз уж мы заговорили про статус-коды и изучение, а статус-коды бывают как бы от нуля до пятёрки. То есть там сотые, двухсотые, трёхсотые, четырёхсотые, пятисотые. Если двухсотка, то значит, всё нормально, запрос отправился и обработал. Давайте в контексте нашего случая всё-таки у нас уже всё ненормально, но двухсотка тоже может быть, и трёхсот может быть, и четырёхсот может быть. О'Кей, О'Кей, О'Кей. А в нашем контексте вот мы смотрим, что запрос отправился, всё нормально, но не появился на клиенте 2. Угу. Ну, он отправился, в смысле, и вот это всё нормально. Дальше всё может быть ненормально. То есть... Ну давай, давай, первый случай. Ты открываешь, тебе приходит статус-код 400. Да, ошибка на стороне клиента. Лозу в чём может быть проблема? Ошибка на стороне клиента, то есть клиент неправильно передал данные. Нам тот же самый, а 403 — forbid, например, за... Да, давай пока смотрим 400. 400, Окей, 400. Ага, 400. Окей, клиент неправильно передал информацию. То есть запрос, отправленный клиентом, некорректен. Значит, нужно проверить, как раз вот локализация будет в том, что мы смотрим в тело. То есть в теле переда переда запроса какой-то из значений был передан с некорректным ключом, например, тип данных неправильно был передан, вместо числа передали строку. Или, например, в строке, где разрешено 10 символов, передали 12. Согласен, согласен. То есть будем смотреть на тело. Зажим ситуации, что мы смотрим на тело запроса, там всё корректно, смотрим документацию, сравниваем, всё корректно. Такое может быть, да, может быть. А в чём тогда проблема? Ну, момент того, что клиенту просто не разрешено, тут не подходит. Да, ему разрешено 100%. Угу, при этом данные. Всё передал правильно. Ну, нельзя. Ну, тоже, э, возможно, такой. Клиент уже присутствует, данные, которые мы передали в теле. Хорошо, давай допустим, что нет такого клиента. Нет такого клиента, всё равно 400 приходит. Ну, 400 — это ошибка, чья принадлежность? Ошибка клиента. Да, на роне клиента. Ну смотри, тут не совсем согласен. Есть это клиентская ошибка, но во или нет? Или только на клиенте причина может быть? Клиент у меня до сегодняшнего дня в моей картине мира 400 — это всегда ошибка только на стороне клиента. Смотри, это клиентская ошибка. Она так и называется, то есть, лиева за своей, и сервер отвечает такой ошибкой, когда он видит некорректный запрос со стороны клиента, да. Но в нашем случае мы смотрим на документацию, запрос правильный, корректный, всё О'кей. Но мы уже можем допустить такую ситуацию, что энд разработчик не успел обновить свою часть кода, и он ждёт старые какие-то данные. Допустим, у нас требования поменялись, мы делаем обновление системы, он ждёт от клиента там два поля, а сейчас уходит, возвращает логично 4. Типа, зачем ты мне присылаешь? Ой, ты, я жду от тебя д. Хотя просто нужно завести на сказать ему: "Слушай, тут надо подправить на сервере". Окей, если пятая ошибка у нас в рке, ошибка на стороне сервера, сервер недоступен, например. То есть отворилась какая-то соединение, отвалилось вообще соединение с сервером. Мы ему что-то шлём, а он нам присылает, что не получается, нету доступа. То есть соединение может быть иметься вообще в целом, но из-за нестабильности там запрос не передаётся должным образом. Что ещё ошибка на сервере? Хорошо, давай, давай остановимся на вот здесь. Ошибка на сервере, логично. Давай теперь в контексте нашей задачи. То есть в чём может быть проблема? Нам же нужно понять, почему же не отображаются данные там. Да, откуда могут ноги расти, по сути своей. Давай так, то что сервер недоступен, это уже понятно. Значит, мы это не рассматриваем. Ну, это вот первый вариант. То есть он упал. Да, да, он упал. Как локализовать теперь? Точнее, то есть мы точно знаем, всё, там внутренняя какая-то ошибка, он лежит, дружок. Как будешь локализовать? Куда будешь смотреть? Ну, а мы говорим сейчас про ровно 500 ошибку, да, то есть не там 503 или... Окей, окей, окей. Как я буду локализовать, если сервер доступен? Ну, тебе, например, нужно барер завести. Угу, угу. Вообще, обычно как раз на этом-то моя локализация заканчивалась, но я постараюсь сейчас так. Ну, давай так, какие инструменты будешь использовать? Что можно использовать в данном случае? Что посмотреть можно? Логи. Окей, хорошо. А где? Какие? Ну, на самом сервере тоже, как правило, настрое есть. Можешь подключиться к удалённому серверу, то есть там, если у тебя есть данные учётной записи, и там в отдельной папочке или просто отдельным файлом лежит файл с названием, и ты можешь открыть его и посмотреть по времени, локализовать ошибку, то есть какая именно ошибка возникла в момент, как раз передачи и отправки соответствующего ответа в момент отправки ответа, какую ошибку сервер зафиксировал на своей стороне. Ну да, да. То есть можно напрямую смотреть, либо есть удобные системы, да, такие как Sentry, там, ну, разного рода, которые позволяют логировать, ну, внутренне работу сервера, по сути, посмотреть, какие там функции вызываются, да. Ну тут, конечно, я всё об этом знаю только в теории. То есть я про это слышал и на практике не применял. Соответственно, если развивать тему, мы открываем логи и смотрим, какая там ошибка. А там уже в зависимости от конкретного случая, ну да, там можем как минимум посмотреть. Тут уже будет зависеть от знания системы, там, вот понимание кода, там и так далее. Вот, ну главное, что было понимание, где это смотреть. Хорошо, ну давай рассмотрим следующий вариант: 200, а, но почему-то всё равно в интерфейсе, ну или там 201, не принципиально сейчас нам, но вот у нас проблема осталась. Отметаем проблему того, что нар ошибка и при этом имеет соединение или не, нет 201. И смотришь в нетворкинге: клиент создан, и при этом не появился. Да, я знаю, что есть проблема с кэшем, но не уверен, что она применима в данном случае, когда мы отправляем один и тот же запрос. Если у нас включено кэширование, то следующие запросы могут хранить только часть информации в отличие от первоочередного запроса. Например, у нас есть такая функция. Но пока я не понимаю, что... Прости, у нас по запросу, да? Да, да. Хорошо, давай, у нас осталось с тобой ещё 11 минут. Я хотел, чтобы мы с тобой порешали, поэтому вкратце скажу: ребят, тоже уже порассуждайте. Кто хочет узнать подробный ответ, приходите ко мне, расскажу. А так у нас есть узлы. Если мы видим, что наш сервер отвечает, что на самом деле он ничего не записал в БД, например, да? Ну, например, да, и отдал 20. Это первый кейс, например, да. Пойти в БД, посмотреть, вообще создана ли такая сущность, создался ли он действительно клиент. Смотрим, например, он там есть. Если его там нет, всё понятно. Например, он там есть, но во второй системе всё равно он не отображается. Уже возникает вопрос: они подают во вторую систему? Оставляем здесь вторую, сюда. Как они отсюда попадают сюда? То есть теперь нужно работать с этой штукой и интеграцией её с этой, да? То есть она делает запрос или отсюда уходит запрос. Потому что если у нас это хуки, не знаю, слушал нет, да, то у нас там POST-запрос просто уходит от одного сервиса к другому. А может быть такое, что система сама зашивает, пишет запрос и получает ответ. Но в любом случае нам уже нужно будет тогда работать с этой системой, да? То есть мы можем посмотреть в случае вебхуков, что система отправляет, а мы ей по логам, по тем же, да, и действительно уточним, что та система ждёт именно это. Потому что если она ждёт не это, то, ну, понятно, что будет проблема. И тогда нам нужно будет подправить этот сервис, чтобы он отправил правильные корректные данные, и тогда там всё отобразится. Если же эта система шлёт всё корректно, то вопрос уже тогда к этой системе. Уже смотрим её логи, опять смотрим клиент этой системы, открываем тот же DevTools. Может быть, там проблема какая-нибудь с отображением. Может быть, там на фронте просто проблема, то есть она как бы всё дошло, и на самом последнем этапе просто фронтендер забыл вообще отобразить банальную ошибку, допустим. То есть, короче, тут есть варианты. Порассуждай ещё, подумай, как они интегрируются, да? То есть если мы добавим, как там, будет куча нюансов. Но, как говорится, такое и спрашивают на собеседованиях, и в целом понимание, что-то рассуждал. Да, но, конечно, стоит ещё поразмыслить с интеграцией, с вариантами, да. То есть тут можно уточняющие вопросики задать, каким способом интегрированы. Угу, вот. Окей, давай поговорим на SQL тему теории. Не буду спрашивать. Ты как вообще? Нормально? Ну, я уверен, что да. До сегодняшнего дня был уверен. До сегодняшнего дня, да, ты останешься уверенным. Я тебе отправляю задачки. Ага. Они устные, ничего писать не надо будет, то есть если запросы сегодня писать не будем, но порассуждать можно будет. Я помню, смотрел одно из твоих тестовых интервью, и, казалось бы, такая простая вещь, но несколько раз сталкивался с тем, что никогда с таким на практике не сталкивался и действительно обдумывал по 20-30 минут, как бы я написал запрос. Там в таблице были значения, ну, там, допустим, какое-то число, потом в следующей ячейке null, а в следующей пусто. И вот как отобразить? Я такой: а действительно, как бывает же просто либо-либо что-то есть, либо нет. Ну, да, долго я потратил на это время, но в итоге, не без помощи нейронки, всё-таки немножко сдался и нашёл ответ. Поэтому, конечно, так. У нас пока ничего не видно. Вижу интеграцию двух систем. Да, он почему-то... Я скопировал, но почему-то ему плохо. Либо что? Давай попробуем. Возможно, у меня уже мой MacBook умирает, и когда идёт трансляция, ему прям плохо. Я сейчас попробую другой браузер, возможно, просто в этом проблема, но сильно сомневаюсь. Давай просто с хромом. Бывает такое, что он на самом деле много оперативки жрёт, прям очень много. И вот как будто... Как будто сейчас... А, я понял, у меня идёт загрузка. Всё, это проблема, и туда ресурсы тратит. Подожди, а это же у нас сейчас в России не работает? Я думал, им пользоваться нельзя. Бесплатные аккаунты должны работать. Я протестировал, в моём случае, мы с тобой это ещё после первой встречи обсуждали. Слава Богу, мой аккаунт не заблокировали. Не уда, с умом. В моём случае он работает, даже вот бесплатная. Моя версия только с... Это, конечно, немножко режет скорость, и мы это можем сейчас видеть, но хотя бы он начал грузить. Мы пока стато Яндекса. Вот теперь видно, надеюсь, нет. Э, ещё. А я открыл его в Safari, поэтому я сейчас переключу на полный шаринг, и тогда всё запоёт. Давай так, остановить показ, сейчас весь экран, поделиться. Давай, теперь посмотрим. Я думаю, что видно. Супер, супер. Ну вот, давай. То есть есть у нас запросы разные. В чём разница? Ну, первое самое банальное, то есть звёздочка — это получается, он все колонки будет отображать. А тут мы отображаем выборочные, то что нас интересует. Тельные имена не будут повторяться из продуктов, где цена больше 100. Вот в этом отличие, в этом нте. То есть без повторения. Да, select из... Мы группируем. Ну, тут по убыванию, по возрастанию. Desc, Asc есть у возраста. Так, тут мы агрегирующие среднее значение зарплаты из таблицы, а тут суммарную. И делим это на count X. Вот count X — это прямо отдельная история. Там, м, тоже он подсчитывает сумму всех полей. Тут они, а смысл как не суть один. То есть как будто мы тут просто суммируем все суммы, а потом делим на количество строк. Ну, а тут получается, мы просто берём агрегирующие. То же самое происходит. Мы просто написали разными способами. И давай, мне просто нужно будет отключаться, поэтому мы с тобой сейчас на пятом задании закончим. Вот. Ага, все остальные. Вот, поэтому давай пятое добьём. Пятое, пятое задание. Последнее. Итак, где Эр и зарплата между... Измени sales и больше либо равно и меньше либо равно. Ну, тут мы просто вот эти границы берём. То есть в первом случае сами границы 50.000 и 100.000 не берутся, а внизу они берутся, учитываются. Уверен, то есть это одно и то же. Значит, одно и то же. Хорошо, там пять задачек будет интересно, посмотришь. Вот в целом, как говорится, какие-то выводы сделаешь. Вот и что. Желаю тебе успешной работы, успешных собеседований, если они у тебя будут скоро. Вот, готовься. Если нужна будет помощь, то контакты есть. Да, да. Ну, надеюсь, было интересно. Это точно, 100% было. Спасибо. Да, давай, пока-пока, удачи!

Назад

Залогинтесь, что бы оставить свой комментарий