Pull to refresh
17
0

User

Send message
В данный момент spy-js умеет трейсить Node.js код только если сам запускает его и соответственно имеет возможность этот код инструментировать. Поэтому трейсить уже выполняемый где-то серверный код через spy-js пока невозможно, но можно например отлаживать через Node.js Remote Debug Run Configuration.

Еще, насколько я понял, вопрос скорее всего о трассировке серверной части кода? Потому что если речь все же о браузерном коде (который хостится web приложением на Node.js на линукс VM), то его конечно же можно трейсить из WebStorm на Windows просто открыв страницу в браузере при запущенном spy-js.

Кстати, если разработка идет на Windows, и весь код доступен, то может просто установить Node.js и запускать тот же код локально (через spy-js Run Configuration)? Тем более что на dev машине Node.js скорее всего и так уже установлен для других целей (таких как запуск grunt, gulp, тестов?)
На тему устаревания — да уж, специфика книжной индустрии в IT сфере.

p.s. Насколько я знаю, в оригинальной версии упомянут мой open source проект расширения для Unity (Unity Auto Registration), с релиза которого прошло почти, страшно подумать, 4 года. За это время я успел сменить несколько работ и направление деятельности. Было бы интересно узнать упомянут ли проект в русскоязычной версии.
Цель развить успешный бизнес есть. Конкретных планов будет это осуществляться с открытыми или закрытыми исходниками пока нет. Если это будет путь crowd-funding-а или платной поддержки, то исходники вполне могут быть открыты, если продажа лицензий, то открывать исходники невыгодно. Я рассматриваю варианты, на данный момент интересно понять потребность и объемы аудитории. Пока склоняюсь к идее продаже лицензий, но только потому что это выглядит проще и более менее обкатаный путь.
Перенос строки я добавил чтобы было более понятно, что именно оборачивание в блок for-in statement-а влечет за собой проблему, а не оборачивание всего куска кода.

Поясню проблему подробнее. Моя ошибка заключалась (как и было сказано в статье) в неверном предположении, что оборачивание *любого* for, for-in, while, do-while statement-а в блок не является деструктивным.

Проблема заключается в том, что в случае если for, for-in, while. do-while statement-а является частью тела labeled statement и в цикле использутся continue lableName, его нельзя просто взять и обернуть в блок, так как это изменение повлечет за собой ошибку выполнения.

То есть
loop: 
for (i = 0; i < 3; i++) {
  if (i == 1) {
    continue loop;
  }
  console.log(i);
}

работать будет, а
loop: 
{ for (i = 0; i < 3; i++) {
  if (i == 1) {
    continue loop;
  }
  console.log(i);
}}

не найдет label loop при выполнении цикла.

При всем при этом этом
loop: 
{ for (i = 0; i < 3; i++) {
  if (i == 1) {
    break loop;
  }
  console.log(i);
}}

или
lbl1: {{
    console.log('will be displayed');
    break lbl1;
    console.log('will not be displayed');
}}

будет работать.

Из-за описанных особенностей я назвал labels капризными, но вы правы, так можно назвать капризными любые особенности, которых не ожидаешь. Пусть будет не капризные, а неожиданные.
Я использую istanbul следующим образом:
В проекте используется grunt с помощью которого помимо всего прочего запускаются клиентские тесты.
Клиентские тесты написаны на Jasmine. Если вы используете другой тествовый framework (qunit или mocha например) то нужно его поискать в списке расширений и использовать. У меня из расширений grunt установлены grunt-contrib-jasmine и grunt-template-jasmine-istanbul.

Gruntfile.js выглядит примерно так:

//...
grunt.initConfig({
   //...
   jasmine: {
      dev: {
        specRoot: 'test/',
        src: '*.js',
        options: {
          vendor: [
            'libs/jquery-1.9.1.min.js',
            'libs/*.js'
          ],
          specs: 'test/*Spec.js',
          template: require('grunt-template-jasmine-istanbul'),
          templateOptions: {
            coverage: 'bin/client-coverage-dev/coverage.json',
            report: 'bin/client-coverage-dev',
            thresholds: {
              lines: 80,
              statements: 80,
              branches: 80,
              functions: 80
            }
          }
        }
      }
   }
   //...
});
//...
grunt.loadNpmTasks('grunt-contrib-jasmine');
//...
grunt.registerTask('testclient', ['jasmine:dev']);
//...


Соответственно команда 'grunt testclient' запускает тесты ('test/*Spec.js) в phantomjs и создает отчеты в bin/client-coverage-dev.
в блоки оборачивались statements, которым был For Statement
{ l1: { for (var x in y) { continue l1; } } }
Некоторые работы по поддержке node.js велись и ведутся (пока все на этапе прототипирования, но прогресс есть). Если удобно, плюсуйте за фичу на github, также подписывайтесь на твиттер, я обязательно буду сообщать о прогрессе этой и других фич.
Спасибо за отзыв и комментарии по использованию.

В примере конфигурационного файла описано как можно фильтровать события. Запрос на фичу по поиску создал на github, посмотрите пожалуйста это ли имелось ввиду под поиском в событиях?

Насчет консольных вызовов, посмотрел — они трейсятся, но неверно записываются в последнее событие и еще портят время выполнения события (завел баг). Пока как workaround можно просто еще раз нажать на последнее событие и консольны вызов будет в конце.

Насчет появления в планах той или иной вещи — у меня есть конкретное видение и большой список того, что еще я бы хотел добавить. Список этот я опубликую постепенно создавая issues в репозитории проекта на github и в roadmap. Пожелания пользователей естественно обладают повышенным приоритетом, поэтому пожалуйста плюсуйте/создавайте запросы на фичи на github (позже подключу что-нибудь более специализированное, вроде uservoice или tenderapp).

Можете пояснить что подразумевается под cpu статистикой функций?
Версия для node в планах есть, «фича» немаленькая, зависит от того сколько людей захочет такую возможность.
Документацию пополняю почти ежедневно, так что скоро с подробностями будет лучше.
Спасибо за отзыв и замечание. Завел issue, будет в следующем релизе. Создавайте новые issue на github если удобно.
Что может быть не совсем быстрым — это начальная инструментация больших js файлов (таких как большие библиотеки). Но, один раз инструментированный ресурс кэшируется и последующие разы все работает быстрее. В примере конфигурационного файла указано как можно не инструментировать (и соответственно не трейсить) файлы, которые неинтересны в данный момент (например библиотеки, утилиты и прочее). Так и шума меньше и работает шустрее.
Я подумываю написать более подробную техническую статью с описанием технологии. Пока можете просто нажать F12 в браузере с профилируемой страницей и посмотреть каким образом ваш код модифицирован. Похожим образом работают всевозможные открытые code coverage библиотки для javascript (istanbul, jscover и другие).
Код проекта не является открытым (то есть это, как минимум в настоящий момент, бесплатный, но не open source проект), но так как это JavaScript, то закрыть/защитить его сложно чем-то большим, чем указанием в коде:

* Using/copying/sharing/distributing the code in any way
* (different from licensed product usage described in EULA)
* is not allowed without owner's written permission.

Если есть интерес, могу написать более подробную статью, с примерами не минифицированного кода с нормальными именами переменными.
Спасибо за отзыв,

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

Information

Rating
Does not participate
Registered
Activity