My first cron job

Posted on Leave a comment

That’s right. Believe it or not. I created my first cron job TODAY! This is what it looks like:

0 4 * * * cd /var/www/mysite/ && node gmailscripts/watch.js my-email-id@gmail.com

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.

Sencha Touch: Accessing a remote API that is under Basic Authentication

Posted on 2 Comments

ST makes it pretty straightforward to access webservices or APIs through its various data proxies and Ext.Ajax. But consuming an API protected under basic authentication can be tricky. Both data proxies and Ext.Ajax provide setUsername() and setPassword() methods, and they work fine on most browsers. But in my experience using these methods, I had big time face-palm moments in case of Safari, iOS, and some Android versions. When these methods are used, an ST app sets the Authorization header AND makes all API requests through URLs formed such as this:

http://user:passwd@www.server.com/api/user/2627

I’m not sure why this is such a big deal for some browsers, but they seem to get confused due to the presence of these two things — Authorization header and user:passwd URL.

The trick to solving the issue is to NOT use setUsername() and setPassword(), and instead set the HTTP headers yourself.

Data Proxies have a headers config.

someModel.getProxy().setHeaders({
	'Authorization': 'Basic ' + btoa(username + ':' + password)
});

Ext.Ajax has a defaultHeaders config.

Ext.Ajax.setDefaultHeaders({
	'Authorization': 'Basic ' + btoa(username + ':' + password)
});