console.time('Node.js ' + process.version + ': mysql query (SELECT NOW()) 100 раз');
for (var i = 0; i < 100; i++) {
// вызов асинронного кода с промисами
}
console.timeEnd('Node.js ' + process.version + ': mysql query (SELECT NOW()) 100 раз');
Этот код запускает 100 запросов к БД параллельно, и завершается, не дождавшись их выполнения.
В этой связи очень странно, что время node-кода больше, чем время php-кода, который все запросы выполнил последовательно. Как так вышло вообще?
На другую БД заменить непросто, используются специфичные вещи типа JSON-функций в MySQL.
выполнение запроса, пост-обработка, слияние с другими источниками и генерация самого отчета будут проверяться раздельно
Да, я специально уточнил, что проверяется только логика построения запроса, который должен вернуть ожидаемые сырые данные (пост-обработка тестируется отдельно, уже без БД). Тогда это юнит-тест?
Мой юз-кейз: Создание отчета по набору фильтров, заданному пользователем.
Существенная часть логики — конструирование сложного SQL-запроса по этому набору фильтров.
Я тестирую эту логику на настоящей (тестовой) базе — берем пустую схему, тестовый метод наполняет его набором данных, проверяем, что сконструированный запрос вернет ожидаемые данные.
Вопросы к знатокам:
Это еще юнит-тест или уже интеграционный? (тут уточню, что создание и выполнение запроса это еще не все, что делает приложение при генерации отчета — там и пост-обработка, и слияние с данными из других источников).
Можно ли (и имеет ли смысл) такой сценарий тестировать без БД? (речь идет о тестирование именно той части, которая делает первичную выборку данных на основе переданных фильтров)
Про оптимизацию как-то непоследовательно получается.
С одной стороны, автор пишет, что не нужно заниматься преждевременной оптимизацией. С другой — предлагает заменять pow(x, 2) на x * x.
Кстати, насчет последнего. Я далек от современного C++, но неужели компилятор сам не разберется с этим довольно простым выражением? Даже с -O3?
Присоединяюсь. Я довольно часто использую только проверку на X-Requested-With — дешево, сердито.
Чем это грозит?
Конечно, потенциально это может поломать работу сайта, если между сайтом и клиентом есть некий прокси, который режет этот заголовок. Но в реальности я пока с такой проблемой не сталкивался.
CORS ограничивает только ajax-запросы, чего явно недостаточно. На сайте bad.com злоумышленник вставит <form action='good.com' method='post'> и инициирует отправку (сабмит) формы — CORS тут не поможет.
У нас в офисе всегда пиво в холодильнике, плюс еще краники с разливным от компании, у которой мы арендуем офис (на краниках провокационная надпись — "drink responsibly" — не, ну они мне еще будут говорить, как мне пить).
Никто особенно не пьет — некогда :)
"Неограниченный отпуск" — и такое было. В среднем, народ использовал меньше отпускных дней, чем при фиксированной длительности отпуска. (наш гендир потом так и говорил, что это такая замануха просто :) ).
Довелось мне посетить офис Гугл. Спортзал, комната для массажа, комната для медитаций, вот это все. Все это было практически пустое — в рабочее время. Может, по вечерам там массово народ зависает, не знаю. Знакомая моя сказала, что всем этим добром она лично практически не пользуется — работы много, а после работы домой к семье, которую и так мало видит.
Лично для меня важный бонус — гибкий график: возможность работы из дома, возможность уйти пораньше, возможность взять выходной в рабочий день (допустим, на поездку), отработав в другой день.
Если вы тестируете осознанно и качественно, можно ожидать покрытия в районе 90%. В то же время, покрытие 100% выглядит подозрительно — выглядит так, будто кто-то специально пишет тесты таким образом, чтобы получить высокий процент покрытия, но не задумываясь о том, что он делает.
(If you are testing thoughtfully and well, I would expect a coverage percentage in the upper 80s or 90s. I would be suspicious of anything like 100% — it would smell of someone writing tests to make the coverage numbers happy, but not thinking about what they are doing.)
Так в чем же ценность анализа покрытия кода тестами? Это просто помогает определить, какие части вашего кода не протестированы.
So what is the value of coverage analysis again? Well it helps you find which bits of your code aren't being tested
Я правильно понимаю, что при изменениях в ветках справа, у вас ребейзится ветка dev, с которой активно работают разработчики?
Как вы решаете вопрос конфликтов с локальными копиями на машинах разрабов?
2) тестирование, маленькие куски выполняют очень мало работы, следовательно покрытие тестами становится весьма тривиальной задачей
Если эти маленькие функции — приватные, то на тестирование это вообще не влияет. (это случай, когда код из длинного публичного метода в классе вынесли в несколько приватных в том же классе).
Использовать radix, который требует дополнительную память, тоже не слишком мотивирует — строки могут быть большими
Насколько я понимаю, при реализации алгоритма дополнительная память будет расходоваться на хранение указателей на строки, а не на хранение дополнительных строковых данных. В этом случае длина строк никак не влияет на дополнительную память — строки могут быть как короткими, так и длинными, без разницы.
У каждого свои потребности. Кто-то скажет, что этого мало. Кому-то более, чем достаточно.
Я привел примерную раскладку на нашу семью из 3 человек.
У холостяка, естественно, все будет иначе (кстати, и налогов больше платить придется — на каждого неработающего члена семьи 4к в год федеральный налоговый вычет, и еще сколько-то калифорнийский).
Я писал про 4к после обязательных расходов типа еды и жилья (по факту даже меньше — всегда какие-то непредвиденные расходы вылезают). Образование, развлечения туда не входят.
Не совсем так. Надо подавать на грин карту, и на какой-то фазе этого процесса (после одобрения I-140) можно будет запросить разрешение на работу для зависимой визы.
Просто так это разрешение не выдают.
Считал на семью, где работает один человек.
Можно и добавить, конечно. Если второй человек — тоже инженер и востребован на местном рынке.
И также помним, что второму человеку надо получать отдельную визу (найти себе работодателя, который будет ее спонсировать) — при рабочей визе H1B члены семьи получают так называемую "зависимую" визу (H4), которая не дает права на работу.
Или ждать грин-карту.
дубль
Это не я вызываю, это код автора статьи. И результаты, приведенные в статье: 9ms на php и 13ms на node.
Этот код запускает 100 запросов к БД параллельно, и завершается, не дождавшись их выполнения.
В этой связи очень странно, что время node-кода больше, чем время php-кода, который все запросы выполнил последовательно. Как так вышло вообще?
Спасибо.
На другую БД заменить непросто, используются специфичные вещи типа JSON-функций в MySQL.
Да, я специально уточнил, что проверяется только логика построения запроса, который должен вернуть ожидаемые сырые данные (пост-обработка тестируется отдельно, уже без БД). Тогда это юнит-тест?
Мой юз-кейз: Создание отчета по набору фильтров, заданному пользователем.
Существенная часть логики — конструирование сложного SQL-запроса по этому набору фильтров.
Я тестирую эту логику на настоящей (тестовой) базе — берем пустую схему, тестовый метод наполняет его набором данных, проверяем, что сконструированный запрос вернет ожидаемые данные.
Вопросы к знатокам:
Про оптимизацию как-то непоследовательно получается.
С одной стороны, автор пишет, что не нужно заниматься преждевременной оптимизацией. С другой — предлагает заменять
pow(x, 2)наx * x.Кстати, насчет последнего. Я далек от современного C++, но неужели компилятор сам не разберется с этим довольно простым выражением? Даже с -O3?
Вы правы, нужно было написать в личку.
Мощность измеряется в кВт. А кВт*ч — это энергия.
Присоединяюсь. Я довольно часто использую только проверку на X-Requested-With — дешево, сердито.
Чем это грозит?
Конечно, потенциально это может поломать работу сайта, если между сайтом и клиентом есть некий прокси, который режет этот заголовок. Но в реальности я пока с такой проблемой не сталкивался.
CORS ограничивает только ajax-запросы, чего явно недостаточно. На сайте bad.com злоумышленник вставит
<form action='good.com' method='post'>и инициирует отправку (сабмит) формы — CORS тут не поможет.У нас в офисе всегда пиво в холодильнике, плюс еще краники с разливным от компании, у которой мы арендуем офис (на краниках провокационная надпись — "drink responsibly" — не, ну они мне еще будут говорить, как мне пить).
Никто особенно не пьет — некогда :)
"Неограниченный отпуск" — и такое было. В среднем, народ использовал меньше отпускных дней, чем при фиксированной длительности отпуска. (наш гендир потом так и говорил, что это такая замануха просто :) ).
Лично для меня важный бонус — гибкий график: возможность работы из дома, возможность уйти пораньше, возможность взять выходной в рабочий день (допустим, на поездку), отработав в другой день.
Фаулер про покрытие тестами: http://martinfowler.com/bliki/TestCoverage.html
(If you are testing thoughtfully and well, I would expect a coverage percentage in the upper 80s or 90s. I would be suspicious of anything like 100% — it would smell of someone writing tests to make the coverage numbers happy, but not thinking about what they are doing.)
So what is the value of coverage analysis again? Well it helps you find which bits of your code aren't being tested
Я правильно понимаю, что при изменениях в ветках справа, у вас ребейзится ветка dev, с которой активно работают разработчики?
Как вы решаете вопрос конфликтов с локальными копиями на машинах разрабов?
Если эти маленькие функции — приватные, то на тестирование это вообще не влияет. (это случай, когда код из длинного публичного метода в классе вынесли в несколько приватных в том же классе).
Насколько я понимаю, при реализации алгоритма дополнительная память будет расходоваться на хранение указателей на строки, а не на хранение дополнительных строковых данных. В этом случае длина строк никак не влияет на дополнительную память — строки могут быть как короткими, так и длинными, без разницы.
Обработка данных сотового оператора по конкретному человеку- это не биг-дата ни разу.
У каждого свои потребности. Кто-то скажет, что этого мало. Кому-то более, чем достаточно.
Я привел примерную раскладку на нашу семью из 3 человек.
У холостяка, естественно, все будет иначе (кстати, и налогов больше платить придется — на каждого неработающего члена семьи 4к в год федеральный налоговый вычет, и еще сколько-то калифорнийский).
Я писал про 4к после обязательных расходов типа еды и жилья (по факту даже меньше — всегда какие-то непредвиденные расходы вылезают). Образование, развлечения туда не входят.
Не совсем так. Надо подавать на грин карту, и на какой-то фазе этого процесса (после одобрения I-140) можно будет запросить разрешение на работу для зависимой визы.
Просто так это разрешение не выдают.
Считал на семью, где работает один человек.
Можно и добавить, конечно. Если второй человек — тоже инженер и востребован на местном рынке.
И также помним, что второму человеку надо получать отдельную визу (найти себе работодателя, который будет ее спонсировать) — при рабочей визе H1B члены семьи получают так называемую "зависимую" визу (H4), которая не дает права на работу.
Или ждать грин-карту.