Comments / Profile of mn3m0n1c

mn3m0n1c_3n3m1 Sep 29 2016 at 07:07

и запись у вас не полная — пути до istanbul и mocha потерялись

В этих путях нет смысла, они добавляются в переменную окружения PATH во-время запуска npm-скриптов.

mn3m0n1c_3n3m1 Sep 28 2016 at 13:35

Действительно очень длинно, такую команду в любом случае стоит упростить. Сделать это можно добавив пару секций в package.json:

{
  "config": {
    "mocha": "--reporter spec test",
    "istanbul": "-x test --dir=./build/coverage --report=lcov --hook-in-context",
  },
  "scripts": {
    "coverage" : "istanbul cover $npm_config_istanbul _mocha -- $npm_config_mocha"
  }
}

После чего скрипт можно запускать с помощью:

redrun coverage

либо

npm run coverage

mn3m0n1c_3n3m1 Sep 5 2016 at 17:12

Redrun разворачивает секцию скриптов, за счет чего увеличивается скорость по сравнению с npm и npm-run-all. Этот частный случай интересует пользователей npm-скриптов, для которых важны: скорость, удобство и совместимость с существующими решениями — то о чем автор думает достаточно часто.

-1

mn3m0n1c_3n3m1 Sep 2 2016 at 10:04

В redrun v5.5.0 добавлена поддержка автодополнения названий скриптов по табу аналогичную той, что используется в npm. Для установки достаточно выполнить:

redrun-completion >> ~/.bashrc
redrun-completion >> ~/.zshrc

mn3m0n1c_3n3m1 Sep 2 2016 at 08:25

Мне даже кажется, что в данном случае make будет лучше, чем redurn, потому что самому make на линуксах ничего устанавливать не надо, он там и так стоит, а рэдран надо.

Make есть на линуксах, но не на Windows.

Просто конфиги свои берёт не из специального файла, а из package.json, который по идее должен быть в node-проектах. Да, умно брать конфиги от туда, эта идея хороша, но не нова.

Не свои конфиги, а конфиги npm. Redrun в этом плане совместим с npm, и ничего нового не привносит.

Я хочу попросить сравнить скорость redrun и make, если не затруднит, сделайте пожалуйста.

У redrun и make разные цели. Redrun разворачивает npm-скрипты, и запускает получившуюся команду. Make автоматизирует процесс преобразования файлов из одной формы в другую, у него свой формат, и возможности гораздо шире, чем у redrun, но в его штатную поставку не входит чтение и исполнение npm-скриптов, скорее он предлагает писать скрипты в Makefile. Этот подход не хуже, он может быть быстрее, но он кардинально отличается от используемого в redrun а именно: использование существующих скриптов, а не написание новых.

Я не владею make и мне не близка его философия, поэтому я не смогу сделать такое сравнение.

-1

mn3m0n1c_3n3m1 Sep 1 2016 at 12:15

Спасибо, поддержка $npm_package_version добавлена в v5.4.0.

mn3m0n1c_3n3m1 Sep 1 2016 at 11:13

Действительно, этого не хватает. Нужно будет подумать об этом.

mn3m0n1c_3n3m1 Sep 1 2016 at 10:15

Дело, в том, что redrun разворачивает лишь те скрипты, которые расписаны в package.json.
Для того, что бы ощутить результат в полной мере, необходимы небольшие изменения:

{
   "test:full:speed": "redrun test:compile test:full:test test:full:cover test:removeTmpDir",
   "test:full:test": "node test-tmp/test/dev/test.js",
   "test:full:cover": "$(npm bin)/istanbul cover $(npm bin)/_mocha -- test-tmp/test/index.spec.js",
   "test:removeTmpDir": "scripts/test-remove-tmp-dir"
}

В моем случае результаты получились немного другие:

coderaiser@cloudcmd:~/javascript-obfuscator$ time npm run test:full

real    3m46.539s
user    0m45.062s
sys     0m50.060s

coderaiser@cloudcmd:~/javascript-obfuscator$ time redrun test:full:speed
> scripts/test-compile && node test-tmp/test/dev/test.js && $(npm bin)/istanbul cover $(npm bin)/_mocha -- test-tmp/test/index.spec.js && scripts/test-remove-tmp-dir

real    3m8.401s
user    0m39.272s
sys     0m44.236s

А с такими скриптами, будет еще быстрее.

{
   "test:full:speed:max": "redrun test:compile test:full:test test:full:cover:speed test:removeTmpDir",
   "test:full:test": "node test-tmp/test/dev/test.js",
   "test:full:cover:speed": "istanbul cover $(npm bin)/_mocha -- test-tmp/test/index.spec.js",
   "test:removeTmpDir": "scripts/test-remove-tmp-dir"
}

coderaiser@cloudcmd:~/javascript-obfuscator$ time redrun test:full:speed:max

real    2m58.866s
user    0m37.000s
sys     0m42.692s

Чем больше npm-скриптов — тем выше скорость.

Имплементация coroutine в NodeJS

mn3m0n1c_3n3m1 Mar 19 2015 at 07:55

Пожалуй вы правы, в версии 1.3.0 учтены ваши замечения.

Имплементация coroutine в NodeJS

mn3m0n1c_3n3m1 Mar 18 2015 at 09:18

Что плохого в том, что эта имплементация не использует EventEmitter?

Имплементация coroutine в NodeJS

mn3m0n1c_3n3m1 Mar 18 2015 at 07:54

Библиотека для coroutine ruff делает то же, что и Co. Только проще: без промисов, но с ивентами.
А еще она работает в браузере без необходимости использовать browserify.

Облачные IDE для веб-программистов

mn3m0n1c_3n3m1 Jan 4 2015 at 21:22

Интересная разработка, хотелось бы по-тестировать и, возможно, поучаствовать в разработке.
Сам уже какое-то время пишу файловый менеджер, в котором раньше использовался CodeMirror,
а сейчас — Ace, для редактирования кода.
К облачным IDE отношусь положительно, слежу за Koding, Cloud9 и ShiftEdit уже несколько лет.
Использую Cloud Commander для всех разработок.
Хотелось бы узнать под какой лицензией будет выходить mr. Gefest?
Будет ли какая-нибудь его часть выложена в Open Source?
По-поводу auto-complete, в Ace есть его базовая версия, для JavaScript, например. Включается по Ctrl + Space.
Так же, для подобных вещей, а так же для переименования и прочего могут быть использованы парсеры Esprima или Acorn.

mn3m0n1c_3n3m1 Jun 20 2014 at 06:57

> Кстати, забыл спросить: а какой набор браузеров официально поддерживается?
Все последние версии браузеров: Chrome, Firefox, Opera и IE (начиная с версии, которая поддерживает addEventListener, это, кажеться, 9).

В целях упрощения кода, было решено отказаться от всех условных комментариев и хаков для старых версий IE, поэтому те, которые не смогут обработать JavaScript и загрузить необходимые модули, будут работать без него (то есть, код будет генерироваться на сервере).

Если браузер что-то не поддерживает, подгружается файл с основными полифилами.

mn3m0n1c_3n3m1 Jun 20 2014 at 06:29

В принципе в localStorage вполне достаточно места для таких нужд. С indexedDB проблема в том, что она поддерживается не всеми браузерами, то есть, в идеале, стоит смотреть, что браузер поддерживает, и то использовать. Мне понравился проект localForage, который использует то, что доступно, предоставляя при этом унифицированный интерфейс. Но в процесе его использования, у меня возникла проблема с тем, что в режиме Инкогнито firefox, который поддерживает IndexedDB, выкидывает ошибку на открытие БД. Возможно сейчас этот баг пофиксили и всё должно работать хорошо. В целом, IndexedDB быстрее, поэтому её, конечно, лучше использовать.

Взаимодействие с localStorage в Cloud Commander'е происходит в файле storage.js. Пул реквесты приветствуются.

mn3m0n1c_3n3m1 Jun 17 2014 at 11:33

В принципе да, если рассматривать вариант подключения по ftp, то вполне можно такое сделать.
Это можно сделать даже сейчас, если конвертировать посылаемые http-запросы серверу Cloud Commander в ftp-команды по TCP, тоже самое с приходящим ответом.

mn3m0n1c_3n3m1 Jun 17 2014 at 06:25

Думаю, совсем без сервера не-получится обойтись, поскольку основной нюанс не в том, каким способом обмениваться данными с сервером (сейчас, всё происходит по HTTP), а в том, как работать с файловой системой. К тому же, клиент-серверная архитектура даёт множество преимуществ: возможность удаленной работы, например.

mn3m0n1c_3n3m1 Jun 17 2014 at 06:17

В принципе, в будущем такое вполне возможно, по-поводу ограничения прав — тут немного сложнее, а вот middleware, думаю, это правильное направление.

mn3m0n1c_3n3m1 Jun 17 2014 at 06:15

Git запускает в целях получения последней версии, конечно, если Cloud Commander установлен через npm, в этом смысла нет. Я подумаю об этом, спасибо.

mn3m0n1c_3n3m1 Jun 16 2014 at 12:41

Вы имеете ввиду вот этот?

Скриншот

Выглядит очень неплохо, интересно было бы посмотреть что внутри. Он с закрытым кодом?

mn3m0n1c_3n3m1 Jun 16 2014 at 12:28

Подобных фич пока нету, но в будущем вполне возможно,
что Cloud Commander можно будет использовать как connect middleware, это было бы очень удобно.

Используемый функционал плавно переходит в независимые модули, таким образом появились:
— Menu
— Minify
— Util-io
— Pipe-io