It’s a very simple job that calls a Node.js script to renew a watch I have on one of my Gmail accounts. at exactly 4:00am daily. Now, what is a watch or why I am watching my mailbox are beyond the scope of this little blog post. Basically, I have a nifty little Node.js API that I use as a webhook to get notification updates from Gmail whenever a new mail arrives. It then checks if the new mail has a specific subject and from address, which when true instructs the API to call a custom parser to scan the contents of the new mail and return me important bits of information that I then save in a database. Geeky? Perhaps it is. I plan to do a separate blog post on how you can do the same (not setting up cron, but watching Gmail mailboxes for new mail programmatically).
Back to cron again: it’s not that I didn’t know the concept of automated jobs before (in Linux or otherwise), I guess I never really needed to create a scheduled job before. Creating the job was not as much fun as reading the correct way to do it. I followed this Digital Ocean community tutorial, which is now 6 years old but stays relevant today.
On this topic, in my professional life I’ve literally seen people learning about this ‘cool’ tool and then misusing it for all sorts of software development things that can be (and should be) done using some form of publish-subscribe or message queue design pattern.
Making reactive and real-time web applications is in fashion these days. Among popular real-time programming frameworks are meteor.js, knockout.js and signalr. Both Knockout and SignalR are developed by Microsoft employees, and integrate seamlessly with Microsoft products. Meteor, on the other hand, is though based on the cross-platform node.js, it is more Linux / Mac-centric than it is Windows. In fact, Meteor’s official documentation is also designed with instructions that pertain to Linux. They don’t even have an official Windows installer for their framework, but depend on a certain Tom Wijsman for that.
It’s true that Linux/Apache is still the dominant server stack, but we still have thousands of corporations that rely on Microsoft’s Windows servers and IIS. And deploying a meteor app on a Windows server is a real pain in the butt because the ever so elegant command meteor bundle doesn’t work in Windows. Last I heard from Tom, implementation of meteor bundle in Windows was in the works. But meteor-win won’t support it until at least v0.5.1.
Although there are workarounds like using a Vagrant VM or msysgit for deploying meteor apps on Windows servers, as I found out through my forum thread, all these workarounds are either too cumbersome or don’t work in all cases. During my constant searching on ways to deploy my meteor app on Windows, I stumbled upon an excellent utility called iisnode, which does that in the best and most elegant way possible.
iisnode is basically meant to host node.js applications is IIS, but again as meteor apps themselves are node.js apps only, using iisnode to host them just works. But some setup and configuration is required before your app is fully hosted.