Recently I have switched from running node.js apps on heroku to nodejitsu. The development experience is so so much better. Nodejitsu focuses solely on node.js while heroku provides support for many languages/platforms but is know for great Rails support.
Nodejitsu doesn't have a free tier; however, they do offer a sandbox for a month or two (if you input a credit card). But their least expensive plan starts around $3 a month. I have no issue paying money for this great development experience.
Heroku uses a few different abstractions that relate to app performance such as web and worker dynos. Nodejitsu allows multiple drones to exist which are essentially copies of your app that are behind a load balancer.
How effective are Nodejitsu's drones? Lets find out
There is definitely a linear increase in performance when the number of drones increase at least for the testing parameters. However 1 drone seems to get the job done pretty well. This test is extremely bad and doesn't prove much. More extensive tests would need to be done to form a better answer. The output of the request is {"title":"tempus"} and doesn't do anything with a database or anything.
Today I had a discussion with @rfc2616, Rob Heittman, about mongoDB. We discussed replica sets, write concerns and other web scale concerns. I am trying to figure out if an app I am working on is write intensive.
Rob put it this way; Unless you have a HD telescope streaming a live feed to your app, its probably not write intensive. Typically for smaller business apps, mine is a time tracking app, any human requested data will be hard to match a high bandwidth data stream hitting your app.
We love mongoDB and nosql because we realize its place and that it is not a replacement for RDMS. However we still enjoy nosql memes and the frustrated haters.
You can. Why not? It's just a string.
JSON=`node -e "console.log(JSON.stringify({a:'hi im json',
b:['what','up','yo']}));"`
echo $JSONFor solving Glog config, which is a .json file, I can set a env variable on Heroku to be this config string.
Heroku is an awesome web app platform. Hands down it has one of the best deployment strategies.
git push heroku masterIts that simple. In the past couple of years, Heroku has added support for node. They have done an excellent job by using npm and providing numerous tutorials. I have been deploying node apps on Heroku for a few months and I want to share with you a few caveats I have found.
The typical solution you will hear for #1 is Pingdom. Although it will work, it is pricey. Another factor to consider is why you chose Heroku in the first place. Inexpensive scalable web hosting. The reason why slugs sleep after a certain period of inactivity is so Heroku can keep their costs down, in turn keeping your costs down.
I am leaning towards Iron Worker. You can get Five free hours as the starter plan.
Using Glog on heroku no longer seems to be a problem. At the time this post was written, Glog will not work out of the box on heroku, but with a few adjustments it works great.
So I have been attending more conferences and networking events. I find people say funny things and sometimes they have no idea what they are talking about.
Me: So are you using git?
Him: No, then I would have to make my project open source.
Me: So are you using git?
Him: No, I'm afraid of git. Nor do I trust our IT guy to install it.
Him: Yeah we have just launch our mobile app.
Me: So do you have a REST api the app uses to access your data etc?
Him: Yeah we use REST, but not with the verbs.
yes, guy1 wins.
Here is a snippet of code where I use recursion in a Titanium project. Basically it is a JSON.stringify like function that's terminating condition is the typeof(hash) isnt 'object' ie a primative and ready for me stuff it in a label object.
labels = [];
getObjectProps = function(hash) {
var key, value, _results;
_results = [];
for (key in hash) {
value = hash[key];
if (typeof value === 'object') {
_results.push(getObjectProps(value));
} else {
if (key !== 'type' && key !== 'name' && key !== 'optional') {
_results.push(labels.push(Ti.UI.createLabel({
text: format.cleanBodyText(String(value)),
height: Ti.UI.SIZE,
color: colors.white,
width: Ti.UI.FILL,
touchEnabled: false,
font: {
fontSize: key === 'textRaw' ? '16dp' : '14dp',
fontWeight: key === 'textRaw' ? 'bold' : 'regular'
}
})));
} else {
_results.push(void 0);
}
}
}
return _results;
};
getObjectProps(_this.currentLevel[e.source.key]);Here is the same in coffee
labels = []
getObjectProps = (hash)->
for key,value of hash
if typeof(value) is 'object'
getObjectProps value
else
if key not in ['type', 'name', 'optional']
labels.push Ti.UI.createLabel
text: format.cleanBodyText String value
height:Ti.UI.SIZE
color:colors.white
width:Ti.UI.FILL
touchEnabled:false
font:
fontSize:if key is 'textRaw' then '16dp' else '14dp'
fontWeight:if key is 'textRaw' then 'bold' else 'regular'
getObjectProps @currentLevel[e.source.key]As long as you do not involve any asyncish code everything will be good.
Adding callbacks to recursive is a tricky business because recursion works on the underlying principle of functions waiting for others to return. So this leads me to question why recursion and callback (async) styles would ever mix?
Initial thoughts. Callbacks and recursion would make memoization interesting. In a way, we can "pretend" that returning is nonexistent and pass in a callback function where we would return the finished result.
For saving space, I will show examples in coffee only.
WIP
The odds are against us. No matter how much I crunch the statistics the casino games are not worth playing unless you are truly disciplined in your betting habits.
In video roulette I started with twenty and would bet the minimum until a payout occurred that put me above the original twenty. When this became true I would cash my ticket.
Giving the 00 wheel the odds black or red hit was 47% give or take some 1/10s. So theoretically over the long run I will lose 53% of the time. Thus I wouldn't make money.
Or so I would think. The evil computers inside adjust the winnings to keep the casino's win ratio at a specified percentage. This implies that the ball lands on the position that will keep the casinos win/loss ratio in check.
If we consider an always neutralizing win/loss ratio It would be best to observe a game and wait for someone to lose a lot. Then proceed to put X amount of dollars down on Red/Black, Odd/Even, 1-18/19-36 or any 1 to 1 or 2 to 1 odds bet. If this win/loss ratio was down the machine might be more likely to pay out.
In the end of my mini experiment I lossed because of some greedy bets, but I conclude that the computerized games do act in a fashion concurrent with the statments above. My best bet is to save up for a casino rather than spending my money at one because all in all it is called gambling, not winning.
If you want to redirect traffic to a different subdomain, you can add a rewrite clause into each of your server{} entries in /etc/nginx/sites-avaliable/default or where ever you keep your available sites located.
This setup still allows me to have multiple virtual hosts on the same box behind an nginx reverse proxy.
For this example, I have a DNS A record for examplehost1.com, blog.examplehost1.com and www.examplehost1.com pointing to the same IPv4 address. examplehost2.com and www.examplehost2.com have their own A records pointing to the same IPv4 address.
Nginx will match the incomming server name in the headers of the request. If the server name is examplehost1.com, nginx will send a 301 redirect in the response to www.examplehost1.com. The same applies if the server name in the request is blog.example1.com. When the server name is www.examplehost1.com, nginx passes the request to the specified proxy. The reason I have this is there exists links out in the world with the blog subdomain, but now I want all traffic to end up at www.examplehost1.com.
The examplehost2.com will make sure all of its traffic ends up at www.examplehost2.com.
There are other methods of redirection, but I find this the easiest when you have multiple virtual hosts setup on an nginx reverse proxy.
/etc/nginx/sites-available/default
server{
server_name examplehost1.com;
rewrite ^/(.*) http://www.examplehost1.com permanent;
}
server{
server_name blog.examplehost1.com;
rewrite ^/(.*) http://www.examplehost1.com permanent;
}
server{
server_name www.examplehost1.com;
location / {
proxy_pass http://127.0.0.1:3000;
}
}
server{
server_name www.examplehost2.com;
location / {
proxy_pass http://127.0.0.1:3001;
}
}
server{
server_name examplehost2.com;
rewrite ^/(.*) http://www.examplehost2.com permanent;
}