Jaan Paljasma | Tech Blog

Running node.js application is easy, but how do you close the application gracefully without errors? Typically you run the app in command line while developing, e.g. node app.js - press Ctrl+C or Command+C to stop running process. If you have sent your application into the background, you can execute kill <pid> command; you can get process ID <pid> with ps aux | grep node . This will kill your app, but if you want to end your application and close all the resources, you can use node.js process  events: // Execute commands in clean exit process.on('exit', function () { console.log('Exiting ...'); if (null != db) { db.close(); } // close other resources here console.log('bye'); }); // happens when you press Ctrl+C process.on('SIGINT', function () { console.log( '\nGracefully shutting down from SIGINT (Crtl-C)' ); process.exit(); }); // usually called with kill process.on('SIGTERM', func...

You use node.js and express framework - you have made great choice! By default, express application will run on port 3000, and it is fine. In production environment, you may want to use nginx as a forward proxy (and I will write next post about it) but another way is to run your app in port 80. Assuming that your app.js  already contains following: app.configure(function(){ app.set('port', process.env.PORT || 3000); ... }); In shell, you can type following command: PORT=80 node app.js or if you use forever , then: PORT=80 forever start app.js On your OSX you may get following warning: TypeError: Cannot read property 'getsockname' of undefined The cause for this is general problem - you need to have root privileges in order to run applications in port lower than 1024. To avoid this, you can type sudo PORT=80 node app.js and your application will work normally in port 80. Another common mistake is that you may still have Apache runnin...

Google Hotel Finder There is a newer version of  Google Hotel Finder  HPA partner front-end available. New version allows partners to view their performance across various dimensions such as user location & google site, to manage groups and bids, and to troubleshoot issues. What's new in Hotel Pricing Ads PFE? Group Management The 'Groups' section provides performance information for all properties or for user­defined groups of properties. One of the advantages of creating groups is that you can track performance for the group. Clicking on the group displays performance information for the group. More details on the performance section is found below. Performance The 'overview' tab in the Performance section is a great way to get a high level view of the performance of HPA. At a quick glance, this page displays trends over time, performance by geography and across Google sites. This section allows the user to view overall performance infor...

Amazon Web Services announced this long-time waited update to its OpsWorks by adding support to Elastic Load Balancer . During AWS Summit 2013 New York it was mentioned several times that ELB support will be added soon  - I am glad they kept their word. Until now, developers taking advantage of Amazon OpsWorks were forced to bring up one instance as HAProxy; but you can now add Elastic Load Balancing (ELB) to your OpsWorks application stacks and get all the built-in capabilities ELB is known for, including automatic scaling across availability zones. Combining this feature with Amazon Route53 latency based routing , and you have highly available, redundant, scalable application. Related article: AWS OpsWorks supports t1.micro instances

If you are already using MongoDB Monitoring Service, or MMS, the next logical step here is to sign up for their backup service. MongoDB Backup Service MBS is a cloud-based service provided by 10gen for backing up and restoring MongoDB. Engineered for MongoDB, it features point-in-time recovery and is hosted in reliable, redundant and secure data centers. Update - I got access to MongoDB Backup Service and tried it out! Read more below. MongoDB backup, own way Before MBS was there, I spent some time setting up the backup scripts on one of my secondary servers in replica set, and it works very straight forward once set up: create backup archive and store in S3, and keep only 30 days worth of backups. run mongodump --oplog -u user -p pass mongobackups create backup-YYYYMMMDDHH.tar.bz2 file from mongobackups run /usr/bin/s3put to move file to S3 storage delete mongobackups folder Configure S3 storage lifecycle: Move to Glacier 1 day after creation date Expiration (delete)...