Очень интересная штука. Решил попробовать на своих модулях.
В некоторых модулях у меня 100% coverage, в некоторых 90+% а дальше лень.
Результаты для меня.
Полезные
1. Индексы. Мутация arr[idx + 1] в arr[idx — 1] увидела, что нет теста с 2 элементов.
2. Неиспользуемые опции. opt = {use_a:true} заменило на opt = {use_a:false} и поведение не поменялось. Хотя use_a не выбросило бы как warning т.к. переменная использовалась, но не в тех случаях которые в тестах.
Бесполезные
1. coffee компилирует for hki in [0… max_hki] в что-то такого вида (пример выжившей мутации):
Ну, можно поставить by 1, но идеологически ошибки нету, а в мутации есть и это не дает никакой пользы.
2. Я нигде не проверял текст exception'а. Потому все мутации в формировании имени exception'а выжили.
Ну серьезно. Мне не важно с какой ошибкой оно падает, главное, что падает. Т.е. ок, я поправлю тесты, внесу туда текст exception'а, но это не улучшит проект.
С чем я столкнулся при работе.
Проблема 1. Не поддерживается coffee.
Решение. Скоприровать и пройтись iced -c по всем файлам, а coffee удалить
Проблема 2. Оно очень плохо работает с асинхронными тестами с коробки
Решение. timeoutFactor: 3 иногда timeoutFactor: 10
Проблема 3. Некоторые мутации опасны для host машины.
Пример. Для тестов нужно записать в fs а мутация меняет папку.
Пример. Для тестов нужно очистить какую-то директорию через rm -rf.
Пример. Мутация вызывает бесконечный цикл меняя условие if (can_be true){break} на if (false){break} в while(true)
Решение отсекаем по timeout
Пример. Мутация вызывает бесконечное выделение памяти. После чего падает child у runner'а, после чего падает основной runner не выдавая отчёта.
Решение отсекаем по небольшому timeout дабы не успело выделить всю память.
Некоторые проблемы требуют взаимоисключающих решений. В одном случае увеличить timeoutFactor в другом наоборот оставить как есть, а иногда и уменьшить.
Проблема 4. Если тесты больше 30 сек.
Проблема 5. Если количество мутантов больше 1000.
Решение. Берём большой сервак на много ядер.
Но в пределе оно не умеет масштабироваться на несколько серверов.
С другой стороны запускать stryker на каждом чихе CI не самая лучшая идея. Это больше как еженедельная профилактика. Как статический анализатор.
Проблема 6. Была реальная ошибка, которая заключалась в том, что не передали последний параметр в функцию. Такого мутатора по умолчанию нет. Coverage не увидел.
Решение 1. Typescript. Но не поможет если параметр опциональный.
Решение 2. Написать мутатор самому. Еще не написал.
Проблема 7. Оно требует mocha^2.3.3, а уже есть 4-я.
Я забил.
Проблема 8. Кажется глобальный stryker и в node_modules ведут себя по-разному. Глобальный игнорирует опции в stryker.conf.js.
Но это неточно. И надо разбираться. Потому issue не постил.
Вердикт. Интересно, попробовал, все-равно интересно. Пока есть некоторая хрупкость. Выделю сбойные случаи — напишу им issue.
Мало мутаторов. Плохо работает в случае серъезных сбоев. Не запускать с проектами которые работают с fs на машинке с полезными данными или подключёнными сетевыми шарами!!!
Буду ли я использовать его для своих проектов? Пока нет. Только как профилактику раз в месяц.
Вот такая команда
cd /tmp/data && ls -la && unzip data.zip && rm data.zip
Не выполняется на проде т.к. /tmp подмонтирован почему-то как read.
Передаю привет docker-compose
Исправил комментарий т.к. во втором случае действительно взял не оттуда.
3% это не так уж что бы и ничто…
Это в идеальном случае prefetch'а процессором.
Как только вылетите за кэш процессора или возьмете коллекцию, которая не умещается в памяти несколько раз, то… как вы думаете что происходит
(если я взял правильные столбики) "collections.chain.JavaFor.benchmark","avgt",1,5,1220522.342690,762881.441383,"ns/op",1000
"collections.chain.JavaStreams.benchmark","avgt",1,5,1159477.123056,779167.349278,"ns/op",1000
(762881.441383-779167.349278)/762881.441383
-0.021347888428739102
for i in [1 .. 100]
if i % 3 == 0 and i % 5 == 0
console.log "MissKiss"
else if i % 3 == 0
console.log "Miss"
else if i % 5 == 0
console.log "Kiss"
else
console.log i
await setTimeout defer(), 50
А самое бесящее всех программистов на чистом JS
Вот это всё можно было сделать еще задолго до ES6.
Простое правило дабы на такое не натыкаться. Все функции работы с сетью/файлами/прочим по умолчанию выдают строку (не самое лучшее решение, но так получилось). Бинарные данные должны быть в буфере т.к. javascript не может их нормально представлять в строке (много срача, гуглится). Потому первым делом, если нужно получить бинарные данные, то сразу лезть в доку и смотреть какой педалью это включается.
Некоторые библиотеки идут дальше и выдают буфер сразу (и иногда даже не имеют опции кодировки), который нужно еще преобразовать в строку через toString. Это чуть более интуитивно, но менее производительно т.к. больше памяти и лишнее копирование. Но да, так проще программисту. Ты сначала выстреливаешь себе в ногу (если хочешь строку), и сразу фиксишь, не лазя в документацию.
API node.js сделано всё-таки с упором на производительность, потому вот так.
Посмотрел демки, посмотрел исходники. Нарисовал вам 4 issue в github. Одно спасибо, что учли 0.5px для отключения anti-aliasing'а, но хардкодить это в коде для всех ИМХО не очень, не всем нужна эта фича, хотелось бы это отключаемой опцией. Есть translate(0.5,0.5), хотя мне он не нравится.
Как-то непоследовательно подошли с ">> 0". В некоторых случаях он есть, в некоторых нету
Хотелось бы услышать обоснование такого решения
Также в скомпилированном виде https://keepdraw.github.io/KeepDraw.js я вижу странные отступы. Кодогенерация? Если да, то хотелось бы увидеть 0.5px как опцию. Не в приоритете, я все-равно буду делать свой велосипед. BTW. Кодогенератора в репозитории не увидел, надеюсь, что он есть, т.к. если всё это делалось ручками, то у многих возникнут замечания к стилю кодирования
Пример вырвиглазного отступа
draw: function(arg) {
var crush = !1;
if (arg.fill) {
arg.ctx.fillStyle = arg.fill.grd || arg.fill;
arg.ctx.fillRect(0, 0, arg.width, arg.height);
}
else arg.ctx.clearRect(0, 0, arg.width, arg.height);
for (var i = 0; i < arg.childs.length; i++) {
if (arg.childs[i]) arg.childs[i].draw(arg.childs[i]);
else crush = !0;
}
Тоже немного в недоумении по поводу объемов https://bitmakler.com/birzha
ну ок. Топ 3 биржи это Китай, это свой полузакрытый рынок.
Где poloniex?
Где вечно неумирающий btc-e?
Добавлю свои 5 копеек против vuejs. Это просто мое мнение, как человека потратившего ~2 месяца на работу с фреймворком.
tldr Мне не нравится как оно выглядит под капотом (по состоянию когда я с этим работал (лето 2016)), мне не понравилось общение с автором.
Немного про плюсы. Конечно, vue хорош: структура(vue-component, способ импорта компонентов и многое другое), производительность, документация, поддержка sublime, свой плагин в chrome (удобно смотреть состояние), template проекта есть замечательный (см https://github.com/vuejs-templates я использовал webpack). В принципе для среднего разработчика предусмотрено многое. Я бы остался с vue, если бы не некоторые мелочи.
Я сделал простой hook на hotreload. 1 строчка, которая не мешает никому, но решает реальную бизнес-проблему. После всего срача с автором фреймворка я принял решение, что не хочу поддерживать свою ветку vuejs (пусть даже с одним патчем в 1 строку, которую так просто добавить), потому что потом автор поменяет реализацию и оно все-равно сломается, уже была практика с другими проектами.
Про vue-component. ( https://github.com/vuejs/vue-loader/pull/198/files#diff-3fab227e34d65fe9bb2d6ea53eec41cf Прим. Это уже поправили. Но тогда это была веская причина) Реализация мягко говоря мне не нравится, но работает и не трогай. Вместо честного парсинга XML как в mxml (привет adobe Flex) через CDATA, автор… просто применяет ко всему, что ему не нужно комментарии.
Еще веселая переписка по поводу поддержки вложенности компонентов A > B > A https://github.com/vuejs/vue-loader/issues/292
«Отличный» ответ. А главное, не понятно что мне делать, не показано как надо.
В некоторых модулях у меня 100% coverage, в некоторых 90+% а дальше лень.
Результаты для меня.
Полезные
1. Индексы. Мутация arr[idx + 1] в arr[idx — 1] увидела, что нет теста с 2 элементов.
2. Неиспользуемые опции. opt = {use_a:true} заменило на opt = {use_a:false} и поведение не поменялось. Хотя use_a не выбросило бы как warning т.к. переменная использовалась, но не в тех случаях которые в тестах.
Бесполезные
1. coffee компилирует for hki in [0… max_hki] в что-то такого вида (пример выжившей мутации):
Ну, можно поставить by 1, но идеологически ошибки нету, а в мутации есть и это не дает никакой пользы.
2. Я нигде не проверял текст exception'а. Потому все мутации в формировании имени exception'а выжили.
Ну серьезно. Мне не важно с какой ошибкой оно падает, главное, что падает. Т.е. ок, я поправлю тесты, внесу туда текст exception'а, но это не улучшит проект.
С чем я столкнулся при работе.
Проблема 1. Не поддерживается coffee.
Решение. Скоприровать и пройтись iced -c по всем файлам, а coffee удалить
Проблема 2. Оно очень плохо работает с асинхронными тестами с коробки
Решение. timeoutFactor: 3 иногда timeoutFactor: 10
Проблема 3. Некоторые мутации опасны для host машины.
Пример. Для тестов нужно записать в fs а мутация меняет папку.
Пример. Для тестов нужно очистить какую-то директорию через rm -rf.
Пример. Мутация вызывает бесконечный цикл меняя условие if (can_be true){break} на if (false){break} в while(true)
Решение отсекаем по timeout
Пример. Мутация вызывает бесконечное выделение памяти. После чего падает child у runner'а, после чего падает основной runner не выдавая отчёта.
Решение отсекаем по небольшому timeout дабы не успело выделить всю память.
Некоторые проблемы требуют взаимоисключающих решений. В одном случае увеличить timeoutFactor в другом наоборот оставить как есть, а иногда и уменьшить.
Проблема 4. Если тесты больше 30 сек.
Проблема 5. Если количество мутантов больше 1000.
Решение. Берём большой сервак на много ядер.
Но в пределе оно не умеет масштабироваться на несколько серверов.
С другой стороны запускать stryker на каждом чихе CI не самая лучшая идея. Это больше как еженедельная профилактика. Как статический анализатор.
Проблема 6. Была реальная ошибка, которая заключалась в том, что не передали последний параметр в функцию. Такого мутатора по умолчанию нет. Coverage не увидел.
Решение 1. Typescript. Но не поможет если параметр опциональный.
Решение 2. Написать мутатор самому. Еще не написал.
Проблема 7. Оно требует mocha^2.3.3, а уже есть 4-я.
Я забил.
Проблема 8. Кажется глобальный stryker и в node_modules ведут себя по-разному. Глобальный игнорирует опции в stryker.conf.js.
Но это неточно. И надо разбираться. Потому issue не постил.
Вердикт. Интересно, попробовал, все-равно интересно. Пока есть некоторая хрупкость. Выделю сбойные случаи — напишу им issue.
Мало мутаторов. Плохо работает в случае серъезных сбоев. Не запускать с проектами которые работают с fs на машинке с полезными данными или подключёнными сетевыми шарами!!!
Буду ли я использовать его для своих проектов? Пока нет. Только как профилактику раз в месяц.
cd /tmp/data && ls -la && unzip data.zip && rm data.zip
Не выполняется на проде т.к. /tmp подмонтирован почему-то как read.
Передаю привет docker-compose
3% это не так уж что бы и ничто…
Это в идеальном случае prefetch'а процессором.
Как только вылетите за кэш процессора или возьмете коллекцию, которая не умещается в памяти несколько раз, то… как вы думаете что происходит
"collections.chain.JavaFor.benchmark","avgt",1,5,1220522.342690,762881.441383,"ns/op",1000
"collections.chain.JavaStreams.benchmark","avgt",1,5,1159477.123056,779167.349278,"ns/op",1000
(762881.441383-779167.349278)/762881.441383
-0.021347888428739102
"collections.chain.JavaFor.benchmark","avgt",1,5,10819.745871,3922.925920,"ns/op",10
"collections.chain.JavaStreams.benchmark","avgt",1,5,10495.110603,5289.096391,"ns/op",10
(10495.110603-10819.745871)/10495.110603
-0.030932048291821133
1. Visual Basic 6
2. VBA
3. CoffeeScript
Некоторые библиотеки идут дальше и выдают буфер сразу (и иногда даже не имеют опции кодировки), который нужно еще преобразовать в строку через toString. Это чуть более интуитивно, но менее производительно т.к. больше памяти и лишнее копирование. Но да, так проще программисту. Ты сначала выстреливаешь себе в ногу (если хочешь строку), и сразу фиксишь, не лазя в документацию.
API node.js сделано всё-таки с упором на производительность, потому вот так.
Есть. Игральный кубик.
Как-то непоследовательно подошли с ">> 0". В некоторых случаях он есть, в некоторых нету
Также в скомпилированном виде https://keepdraw.github.io/KeepDraw.js я вижу странные отступы. Кодогенерация? Если да, то хотелось бы увидеть 0.5px как опцию. Не в приоритете, я все-равно буду делать свой велосипед. BTW. Кодогенератора в репозитории не увидел, надеюсь, что он есть, т.к. если всё это делалось ручками, то у многих возникнут замечания к стилю кодирования
https://bitmakler.com/birzha
ну ок. Топ 3 биржи это Китай, это свой полузакрытый рынок.
Где poloniex?
Где вечно неумирающий btc-e?
Это к вопросу переписывания на PHP.
tldr Мне не нравится как оно выглядит под капотом (по состоянию когда я с этим работал (лето 2016)), мне не понравилось общение с автором.
Немного про плюсы. Конечно, vue хорош: структура(vue-component, способ импорта компонентов и многое другое), производительность, документация, поддержка sublime, свой плагин в chrome (удобно смотреть состояние), template проекта есть замечательный (см https://github.com/vuejs-templates я использовал webpack). В принципе для среднего разработчика предусмотрено многое. Я бы остался с vue, если бы не некоторые мелочи.
Ключевой причиной почему я ушёл с vuejs стала плохая поддержка hot reload + canvas/proxy textarea (пропадал фокус после hot reload'а).
Обсуждение с автором:
https://github.com/vuejs/vue/pull/3227
https://github.com/vuejs/vue-loader/issues/275
Может, я плохо объясняю, но автор вообще не понял в чем проблема его модели hot reload.
Я сделал простой hook на hotreload. 1 строчка, которая не мешает никому, но решает реальную бизнес-проблему. После всего срача с автором фреймворка я принял решение, что не хочу поддерживать свою ветку vuejs (пусть даже с одним патчем в 1 строку, которую так просто добавить), потому что потом автор поменяет реализацию и оно все-равно сломается, уже была практика с другими проектами.
Про vue-component. ( https://github.com/vuejs/vue-loader/pull/198/files#diff-3fab227e34d65fe9bb2d6ea53eec41cf Прим. Это уже поправили. Но тогда это была веская причина) Реализация мягко говоря мне не нравится, но работает и не трогай. Вместо честного парсинга XML как в mxml (привет adobe Flex) через CDATA, автор… просто применяет ко всему, что ему не нужно комментарии.
Еще веселая переписка по поводу поддержки вложенности компонентов A > B > A
https://github.com/vuejs/vue-loader/issues/292
«Отличный» ответ. А главное, не понятно что мне делать, не показано как надо.
Также до сих пор не починили https://github.com/vuejs/vue-syntax-highlight/issues/41 Конечно, это не проблема vue, но добавляет негатива при работе с ним.
P.s. закончилось всё тем, что я перешёл на самописный велосипед для pet проектов и react для остального.