When the directory structure of your Node.js application (not library!) has some depth, you end up with a lot of annoying relative paths in your require calls like:
const Article = require('../../../../app/models/article');Those suck for maintenance and they're ugly.
For this configuration you can use web server you like, i decided, because i work mostly with it to use nginx.
Generally, properly configured nginx can handle up to 400K to 500K requests per second (clustered), most what i saw is 50K to 80K (non-clustered) requests per second and 30% CPU load, course, this was 2 x Intel Xeon with HyperThreading enabled, but it can work without problem on slower machines.
You must understand that this config is used in testing environment and not in production so you will need to find a way to implement most of those features best possible for your servers.
Обычно после написания кода его проверяют. Если речь о какой-то функции, то можно написать простой скрипт, который будет вызывать ее с разными аргументами, и смотреть, что она вернет. Если вы сделали сайт или приложение, то вы открываете его, жмете ссылки и кнопки, проверяете что все отображается верно. Это называется ручное тестирование или QA (Quality Assurance — контроль качества) — человек проверяет работу программы. Если мы попробуем автоматизировать этот процесс, и написать программу, которая проверяет правильность другой программы, то это называется автоматизированное тестирование.
Главный плюс автоматических тестов — то, что они выполняются намного быстрее, чем ручное тестирование, и вам не надо тратить на это свое время (или время тестировщика). Это позволяет запускать их хоть после каждого изменения в коде.
Также, тесты позволяют «защитить» написанный код. Если кто-то в команде (или вы сами) нечаянно «сломал» ваш код, тесты это обнаружат и укажут, что именн
mkdir -p /usr/local/etc/nginx/sites-{enabled,available}
cd /usr/local/etc/nginx/sites-enabled
ln -s ../sites-available/default.conf
ln -s ../sites-available/default-ssl.conf
File locations:
nginx.conf to /usr/local/etc/nginx/default.conf and default-ssl.conf to /usr/local/etc/nginx/sites-availablehomebrew.mxcl.nginx.plist to /Library/LaunchDaemons/
| sub, sup { | |
| /* Specified in % so that the sup/sup is the | |
| right size relative to the surrounding text */ | |
| font-size: 75%; | |
| /* Zero out the line-height so that it doesn't | |
| interfere with the positioning that follows */ | |
| line-height: 0; | |
| /* Where the magic happens: makes all browsers position |
| # post_loc.txt contains the json you want to post | |
| # -p means to POST it | |
| # -H adds an Auth header (could be Basic or Token) | |
| # -T sets the Content-Type | |
| # -c is concurrent clients | |
| # -n is the number of requests to run in the test | |
| ab -p post_loc.txt -T application/json -H 'Authorization: Token abcd1234' -c 10 -n 2000 http://example.com/api/v1/locations/ |
| for (var i=1; i <= 20; i++) | |
| { | |
| if (i % 15 == 0) | |
| console.log("FizzBuzz"); | |
| else if (i % 3 == 0) | |
| console.log("Fizz"); | |
| else if (i % 5 == 0) | |
| console.log("Buzz"); | |
| else | |
| console.log(i); |
Moved to git repository: https://github.com/aliesbelik/load-testing-toolkit
Tools to benchmark & load-test your code or services
CC
https://github.com/djvirgen/virgen-acl Simple and elegant, create your own checks. No middleware?
https://github.com/OptimalBits/node_acl Use as middleware, create your own roles and access. Great choice.
https://github.com/tschaub/authorized Similar to connect roles... but a bit more robust? you can create roles and action, and associate many roles with that action
| /* | |
| This .scss loop will create "margin helpers" and "padding helpers" for use in your web projects. | |
| It will generate several classes such as: | |
| .m-r-10 which gives margin-right 10 pixels. | |
| .m-r-15 gives MARGIN to the RIGHT 15 pixels. | |
| .m-t-15 gives MARGIN to the TOP 15 pixels and so on. | |
| .p-b-5 gives PADDING to the BOTTOM of 5 pixels | |
| .p-l-40 gives PADDING to the LEFT of 40 pixels |