| # config/deploy.rb | |
| # config valid only for Capistrano 3.1 | |
| lock '3.1.0' | |
| set :application, 'my_app' | |
| set :repo_url, '[email protected]:USER/my_app.git' | |
| # Default deploy_to directory is /var/www/my_app | |
| set :deploy_to, '/var/node/my_app' |
| This assumes you've already set up your instance with node, npm, forever, mongodb, configured ports, and have optionally added a web server like nginx to proxy access to meteor. | |
| Local | |
| 1. Install Ruby | |
| 2. gem install capistrano | |
| 3. cd /your/meteor/project | |
| 4. capify . | |
| 5. edit config/deploy.rb as needed with below | |
| AWS |
| # This deploy script takes a parameter to define the number of instances to deploy (default is 1) | |
| # ex: cap deploy -s instances=3 | |
| set :application, "YOUR_APP_NAME" | |
| set :repository, "git@YOUR_GIT_REPOT.git" | |
| set :scm, :git | |
| set :deploy_via, :remote_cache | |
| set :user, "deploy" | |
| set :deploy_to, "/home/deploy/www/#{application}" |
Unit test: If you are testing one small module of your application, you are writing a unit test. You’ll need to stub and mock other modules that your module usually leverages in order to isolate each test. You’ll typically also need to spy on actions that the module takes to verify that they occur.
Integration test: If you are testing that multiple modules behave properly in concert, you are writing an integration test. Such tests are much more complex and may require running code both on the client and on the server to verify that communication across that divide is working as expected. Typically an integration test will still isolate a part of the entire application and directly verify results in code.
Acceptance test: If you want to write a test that can be run against any running version of your app and verifies at the browser level that the right things happen when you push the right buttons, then you are writing an acceptance test (sometimes called “end to end test”). Such test
Reference and recommand read from http://speakingjs.com/
JavaScript has only six types
Undefined, Null
Boolean, String, Number, and
Object
JavaScript makes a somewhat arbitrary distinction between values:
The primitive values are booleans, numbers, strings, null, and undefined.
All other values are objects.
They say that one of the pros of NodeJS is that you use the same language on the back-end and the front-end, so it's easy to share code between them. This sounds great in theory, but in practice the synchronous dependency handling in NodeJS works completely different than any client-side frameworks (which are asynchronous).
Usually that means that you end up copy-pasting your code between your NodeJS sources and your client-side sources, or you use some tool like Browserify, which is brilliant, but they add an extra step in the build process and most likely will conflict with the dependency handling of the framework of your choice (like AnularJS DI). I couldn't look in the mirror if I would call that code sharing.
Fortunately, with a couple of lines of boilerplate code, you can write a module which works in NodeJS and AngularJS as well without any modification.
No globals in the front-end, and dependencies will work. The isNode and isAngular va
| In root directory type this command: | |
| 1 | |
| 2 | |
| 3 | |
| <b> | |
| mkdir src | |
| </b> | |
| Type this command | |
| 1 | |
| 2 |
| Main Reason | |
| HA - High Availability | |
| Data Safety | |
| General Info | |
| Replication is Async | |
| And Can have ACK | |
| Single Primary (No direct Eventual Consistency) | |
| Has somewhat Statement Based Replication (Not Binary Based) | |
| It creates one statement for document even if your query is single line (But it may affect multiple documents) |