Pull to refresh
164
0
Роман Дворнов @lahmatiy

Веб-исследователь

Send message

Предполагалось, что так или иначе читатель разберется куда и что положить. В целом, тема не сложная, но в ней много нюансов – не хотелось на них отвлекаться и раздувать статью, потому эти моменты опущены. И все же, спасибо за фидбек. Я надеюсь будет статья по вопросам организации пакета/инструмента, как настраивать разные штуки, та же сборка (штатная в discovery/cli) еще за бортом осталась и тд...


Если же пакет ставится в проект, который исследуется, то этим самым меняется его древо зависимостей

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


Насчёт jora — вроде уже есть jq, чем, как вы считаете, jora лучше?

Если про то, что есть прямо сейчас (то есть без того что в планах), первое что приходит:


  • субъективно проще, ближе к JS
  • работает с JS объектами, то есть пригоден не только для JSON
  • работает в node и браузерах без каких либо хаков с компиляцией (jq написан на си)
  • так как jora написан на JS — в него проще контрибьютить, можно расширять своими методами, то есть использовать их в запросах (планируются либы методов для работы с semver, датами, математикой и тд)
  • jora весит гораздо меньше (jora ~30kb vs. jq сборка в wasm ~1.7Mb)
  • килер фича: саджест при наборе запроса (на самом деле есть API для получения списка значений проходящих через определенные точки запроса, что можно использовать и для других фич типа отладки)
  • более менее работающий толерантный режим (полезно при наборе — меньше выскакивает ошибка, что запрос поломан и помогает делать саджест)

Теоретически, в discovery можно использовать другой движок запросов – для этого многое есть (например, используется фасад даже для самого jora). На практике пока такое не пробовали, но задача решаемая (правда не у всех есть фичи типа саджеста – например, у jq такого нет, как и многого другого, что планируется добавить).

На этот случай делаем песочницу для jora. Проект в начальной фазе: сейчас туда можно загрузить или кинуть файл, и трансформировать его с помощью jora. В перспективе будет возможно вставлять из буфера, хелп и много всего другого.

Мы думали о цветовых схемах, но пока все было на уровне "nice to have", то есть без явного запроса/планов. Будет круто если создадите ишью, чтобы мы начали обсуждение по этому вопросу.

Можете описать ваш кейс? Пока лишь догадки, что именно вы хотите от сервиса...

Можно, но зачем? Какой у вас кейс?

Технически в discoveryjs (на чем построено расширение) заложено возможность использования альтернативных "движков" для запросов. Можно подумать над тем, чтобы была возможность выбора движка в настройках (из списка). Но об этом нужно подумать дважды, так как усложняет и создает определенные проблемы, например с шарингом по ссылке.


Если говорить конкретно про jq, то здесь основная проблема, что он написан на C и сборки для работы в браузере я не нашел (тот же playground шлет запросы к бекенду для выполнения запросов). И у него нет такой полезной вещи как подсказки при составлении запроса. И это не единственная фича, задуманная вокруг написания запросов (но первая реализованная).


кроме того куча сниппетов на очень многие случаи жизни

Есть какой-то общий сборник, или это личное собрание?

На счет альтернативных форматов были мысли, но конкретных планов на это нет. В целом все, что может конвертироваться в или конвертироваться из JSON, потенциально можно добавить на вход/выход.

Как я понял, вы связаны с автором проекта?

Так получилось, что я автор discovery.js и jora :)


Мне видится сомнительным использование (еще одного) языка запросов, можно ли там писать чистый JS?

Увы, нельзя. Я был бы рад не изобретать своего и использовать что-то готовое, но подходящего (по множеству параметров) не нашлось – так появился жора. Изначально его не было и все писалось на JS, но получалось много рутиного кода. Жора заточен под наиболее часты кейсы связанные с выборкой данных, облегчает манипуляции. Например, вам не надо заботиться о существовании всех свойств в пути (то что решит оператор ?. в JS, если его примут), или отобрать только уникальные значения, или сделать рекурсивную выборку и т.д. А за счет определенных ограничений, таких как отсутствие переменных (но есть "константы"), циклов и тд – позволяет делать интересные вещи, например, те же подсказки при вводе запроса. И есть еще несколько интересных идей. Посмотрите readme у Jora

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

Спасибо за вопросы!
Тема предстоящего эфира несколько про другое, скорее про вокруг обозначенных тем и вопросов. Возможно мы что-то затронем, но без углубления.
Но будут и другие эфиры, один из них как раз про то что Вы спрашиваете, так что сохраним ваши вопросы до такого эфира. Следите за анонсами :)

чем хуже в том же Selenium открывать необходимую страницу и получать HTML-source? Так будет честнее, чем собирать HTML «руками», как мне кажется.

В нашем случае, мы тестируем компоненты и блоки. Нас интересует множество возможных состояний, которых может быть очень много. Например, компонент Checkbox сейчас имеет 39 состояний (если не ошибаюсь) – нам бы хотелось понимать как он выглядит в каждом, что это каждый соответствует дизайну и не имеет дефектов. А так же иметь гарантию, что при последующих изменениях все останется под контролем.


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


Можно загружать компонент/блок в Selenium, но для этого тоже нужно сделать сборку (bundle). А это не меньшее время. Запустить Selenium, открыть в нем страницу, чтобы получить HTML (а ведь нужен еще и CSS), по которому потом делать скриншот – оверхед, дополнительные траты ресурсов и времени. В целом можно, но получится сложнее и вряд ли быстрее.


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

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

это вообще правильно идеалогически тестировать что-то специально сгенерированное? Есть гарантия что это будет 100% то что надо?

100% гарантию сложно получить в чем бы то ни было. Мы стараемся получить максимально похожее на правду. Когда вносятся изменения или создаются новые тесты, то скриншоты проверяются как автором изменений, так и коллегами на code review. Если получаемые скриншоты похожи на "правду", то они становятся эталонными. Иначе исправляем проблему.


Про микросервис тоже странно мне показалось, проблема кросплатформенности и кроссбаузерности безспорно решена, а по-факту это тестирование в одном браузере.

Да, на данном этапе это было достаточно. То есть пока не ставилась задача кроссбраузерного тестирования. Если потребуются другие браузеры, мы их интегрируем в сервис и добавим параметр, для какого браузера необходимо получить скриншот. Для разработчика мало что поменяется: ему не нужно будет устанавливать локально необходимые браузеры, нужно будет лишь добавить параметр(ы) в настройки на стороне исполнения тестов.


сорри может я невнимательно прочитал, но тут был описан процесс обновления новых эталонных скриншотов?

Для обновления эталонный скриншотов используется тот же механизм, что и для обновления снепшотов в Jest (запускается с флагом -u или --updateSnapshot)

Возможно зависит от реализации, которая может не использовать дельты.
Но когда делается клонирование стандартным клиентом, то в выводе можно увидеть упоминание дельт, например:


> git clone ssh://git@host/path/to/repo.git
Cloning into 'repo'...
remote: Counting objects: 138271, done.
remote: Compressing objects: 100% (47402/47402), done.
remote: Total 138271 (delta 95998), reused 129451 (delta 88469)
Receiving objects: 100% (138271/138271), 29.03 MiB | 6.84 MiB/s, done.
Resolving deltas: 100% (95998/95998), done.

В Wikipedia в секции Design отмечено:


Periodic explicit object packing
Git stores each newly created object as a separate file. Although individually compressed, this takes a great deal of space and is inefficient. This is solved by the use of packs that store a large number of objects delta-compressed among themselves in one file (or network byte stream) called a packfile. Packs are compressed using the heuristic that files with the same name are probably similar, but do not depend on it for correctness. A corresponding index file is created for each packfile, telling the offset of each object in the packfile. Newly created objects (with newly added history) are still stored as single objects and periodic repacking is needed to maintain space efficiency. The process of packing the repository can be very computationally costly. By allowing objects to exist in the repository in a loose but quickly generated format, Git allows the costly pack operation to be deferred until later, when time matters less, e.g., the end of a work day. Git does periodic repacking automatically but manual repacking is also possible with the git gc command. ...

В версии статьи на русском можно найти:


В репозитории иногда производится сборка мусора, во время которой устаревшие файлы заменяются на «дельты» между ними и актуальными файлами (именно так! актуальная версия файла хранится не-инкрементально, инкременты используются только для шагания назад), после чего данные «дельты» складываются в один большой файл, к которому строится индекс. Это снижает требования по месту на диске.

В канале HolyJS на youtube доступно больше видео, запись выступления Вячеслава сейчас первая в списке

Про глобального агрегатора it-событий не знаю, а вот новости вокруг фронтенда, в том числе про события, можно узнавать из ленты Веб-стандарты, например в твитере https://twitter.com/webstandards_ru (та же лента есть в vk, facebook, телеграмм etc)

!isNaN(Infinity) // => true – ожидалось что-то иное?
Как вообще тогда определять числа? Проверить их конечность!

Почему не !isNaN(value)?


В таком хэше отсутствуют наследуемые ключи — только собственные (гипотетическая экономия памяти).

Никакой экономии, так как у объекта по прежнему есть свойство на прототип, только оно равно null. То есть объект занимает столько же памяти.
А если используя Object.key() или аналог, то под хранение ключей создается массив строк, который требует памяти, а после попадает в GC как мусор.


Казалось бы, вот он идеальный способ. Но, Internet Explorer.

Про это был большой разнос http://webreflection.blogspot.ru/2014/04/all-ie-objects-are-broken.html


arguments = Array.prototype.slice.call(arguments, 0); // Превращение в массив

В strict mode будет исключение – нельзя переопределять arguments.


а вот ...rest — массив

Все верно, происходит destructuring, то есть неявно итерируется arguments с получением массива в качестве результата.


В анонимных функциях указатель this ссылается на глобальный объект.

Совсем не факт. Но в комментариях уже писали, что наиболее правильный способ это new Function('return this')().

Напишите по существу, что не так с изложенным в интервью?

Бандлы у нас есть, обираются r.js и это долго

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

Для этого нужно узнать, а как запустить? Или у вас под рукой только доступ к gitlab/github, что делать? Дублировать доку?

Я вот тоже думаю, что должно быть наоборот command -h > README.md. Но эта дискуссия навела на мысль, что в command -h можно добавлять ссылку на подробное описание команд/флагов...


в dev не используются бандлы и холодный старт не такой быстрый

В dev-сервер'е basis.js для решения проблемы делается динамический бандл. По сути это просто JSON файл, где ключ – это имя файла, значение – его контент. Сервер внедряет этот скрипт (который сохраняет объект в некоторую глобальную переменную) в каждую отдаваемую html-страницу. Когда модульная система делает запрос к серверу за файлом (через xhr), она добавляет спец-заголовок. По этому заголовку сервер понимает, что это ресурс приложения и добавляет в бандл + начинает watch'ить этот файл, и при изменениях обновляет контент в бандле. При следующем обращении к бандлу, если в нем были изменения делается 'window.globalVar = ' + JSON.stringify(bundle). Модульная система инициализирует свой кэш бандлом (если есть). И если запрашиваемый ресурс есть в кэше, то берет оттуда или делает запрос к серверу. Так же есть коннект к серверу через ws, через который прилетают обновления по ресурсам, которые обновляют кэш модульной системы (если ресурс еще не инициализировался) или уже используемый, если его можно апдейтить. Первая загрузка страницы после старта сервера получается так же медленно (но не так медленно, как если собирать все приложение, так как запрашивается только необходимое), но последующие загрузки происходят почти так же быстро, как если бы это было собранно. Еще к серверу могут подключится клиенты, которые уже используют определенные файлы – тогда клиент присылает список файлов, а сервер их прогревает и наполняет бандл ресурсов, но это уже лирика…
Когда начинал писать думал, что все гораздо проще – просто уже давно работает, и об этом не задумываешься :)


не верю, что можно добиться такой восстанавливаемости

Я вот тоже не верю. И более того, даже если добиться этого на "сферических конях", то получится настолько сложное решение (и сложно поддерживаемое), что лучше его будет не использовать.

Спасибо, Костя :)
Для других библиотек нужно встраивать поддержку. Пробовал с knoсkout'ом подружить https://github.com/lahmatiy/knockout-data-flow
Думаю в ближайшие пару месяцев станет возможно сделать этот визуализатор более независимым, как потребитель json. То есть вы или ваша библиотека должны сгенерировать описание графа в JSON (постороение специфично для библиотеки/фреймворки), а он его построит. Собственно он уже так работает, но пока в составе последнего basis.js. А делалось это в рамках новых remote tools https://www.youtube.com/watch?v=j6q3gsWOpgM
Скоро по такому же принципу будет работать Component Inspector. А вот визуализатор потоков данных пока нет планов выносить, по крайней мере до тех пор пока не будут реализованы основные запланированные фичи для него.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity