Convert Epoc time to a real local date in JavaScript.

Posted on December 7th, 2012 in JavaScript | No Comments »

Lots of times, when you use APIs they are using Epoc time to specify a date (which is the number of seconds that have elapsed since midnight (UTC),January 1, 1970). This post isn’t to explain why Epoc is that date, though interesting. Here is some quick JS to convert that to a real human date in your local time zone:

function realDate (epoc){
    var d = new Date();
    d.setTime(epoc * 1000);
    return d;

// returns Fri Dec 07 2012 11:33:37 GMT-0800 (PST)

Securing your SSH on Centos, especially on EC2.

Posted on December 6th, 2012 in AWS, security, ssh | No Comments »

The popular port.

Example brute force attempt on an EC2 server.

By default SSH runs on port 22 on your server. Though I’m not a proponent of security by obscurity, moving your SSHd to a high-number port (like 3293) will reduce the number of brute force attempts on your SSH by nearly 100% (Stats given by reviewing /var/log/secure on servers I have or have had access to for years.) This used to be pretty important but even more so with cloud services like Amazon EC2 where hackers and script kiddies can ping sweep whole subnets of Amazon’s elastic IP ranges. (On a related note, Stackoverflow blocked all EC2 instances from accessing their site using the same approach.)


If for some reason though, you cannot move SSH ports—for example, you’re working in a legacy system where dozens or hundreds of people are already connecting to, the next best thing is to install DenyHosts, a free tool written in Python that reviews and bans IP addresses that make too many failed attempts.

Installing DenyHosts

Centos doesn’t have direct access to installing it. But you can install it by running the following:

sudo rpm -Uvh
sudo yum install denyhosts

After that, add your IP address to /etc/hosts.allow in the format of sshd: so that it will never blacklist your IP, tweak /etc/denyhosts.conf to your liking, and restart denyhosts with sudo service denyhost restart. It started analyzing your /var/log/secure and banning ips pretty instantly as you can see from this screenshot. After a few weeks it can optionally purge them so the ban list doesn’t get super big.

DenyHosts auto blocking IP addresses.

The folks at Digital Ocean have a great entry that can walk you through the rest.

Note: The one downside of switching SSH ports is that you can no longer use git in it’s common syntax since git uses SSH as it’s secure transport. See my article on using git on non-standart ports to solve that easily.

Hardening your /etc/ssh/sshd_config

There are a few adjustments you should make to your SSHd config so that it’s harder for the wrong person to gain access. This includes disabling password-based logins (everyone should be using SSH keys), disabling root user login, and throwing in a welcome message that this SSH session is being logged:

# Disable password based login. Only SSH keys are allowed.
PasswordAuthentication no
# Add a message banner notifying this server is logged.
Banner /etc/ssh.go.txt
# Do not allow root to login
PermitRootLogin no
# Deny root user login
DenyUsers root

Following the above steps should make your SSH more secure. Happy SSHing!

My Emacs Magit workflow.

Posted on November 24th, 2012 in emacs, git | No Comments »

I wrote about Magit, the Emacs mode for Git almost two years ago and still use it near-daily since. I love being able to spend most my day within Emacs and not having to drop down to shell to pull or push files. I explained my Magit workflow to a user on Stackoverflow recently, and think it would be helpful to post it here as well for my dear Emacs readers:

Magit screenshot

My flow goes like this.

  1. I start the day at work. I type git diff in command line just to see if I have any uncommitted changes from the previous day (don’t forget to enabled colors!) The reason I do this in command line as apposed to magit is because I’m not in emacs yet.
  2. I either open the uncomitted files in emacs emacs file1 file2 or I open some files I’m about to work on.
  3. I code until I’ve fixed a bug or finished a new feature.
  4. In emacs I type C-c i to open up the Magit status window.
  5. I scroll down to the Changes section and next to each file press tab to see a diff of each changes. I either press s to stage those changes or u to unstage those changes.
  6. Optionally, I can look through diffs code and do the same s and u to stage and unstage sections of the code. Useful if I had some debug code somewhere and want to kill it.
  7. After I’ve confirmed all my changes look good and are staged I type c to open the magit-edit-log. I type my commit message and then type C-c C-c to commit it. Then P to push it. Done!

Note that this sounds like a lot of steps but it becomes quickly natural and the whole process literally takes 30 seconds for me to diff my entire set of changes, stage them, and commit them with a message. All while staying in Emacs. So much easier than dropping down to command line.

Sometimes an error is returned when I do a push via Magit usually caused by new code in the remote repo that I have to pull before I push. In this case F to pull changes then P again to push. Honestly for some reason, instead of pulling through magit, I generally just Ctrl-z in this situation, drop down to shell, git pull, and git push.

And as previously posted, don’t forget to change Magit’s default diff colors!

Amazon Elastic Load Balancer vs HAProxy

Posted on November 22nd, 2012 in AWS, unix | No Comments »

When it comes time to horizontally scale up your application with multiple server instances on AWS you generally have three choices: DNS round-robin (simply assigning multiple A names to a domain), using Amazon Elastic Load Balancer, or using one or more HAProxy‘s on EC2. The Robin-robin approach, while easiest, is not good since DNS will always forward round-robin to an IP even to a dead or overloaded EC2 instance, hence, a real HTTP load balancer is needed.

Amazon ELB is pretty awesome as it’s inherently fault tolerant and highly available. You never have to worry about scaling it up like regular EC2 instances. It just works, and it’s relatively cheap. But it also has a few drawbacks including lacking complex routing algorithms, no logging outside of Cloudwatch, and can’t gracefully handle great spikes in traffic like a Slashdot or a consumer flash sale without “prewarming” the load balancer (an act that requires a premium support agreement and contact with Amazon ahead of time).

HAProxy, the premiere open-source load-balancer contains a swiss army knife of functionality, including tons of routing algorithms, that addresses many of the limitation of Amazon ELB at the cost of a lot more manual setup, complexity, and cost (since it’s hosted directly on EC2 instance(s). This article is a great discussion on the merits of both and worth a read if you’re like to know which to go with.

But wait there’s more! What if you could have the best of both worlds? The following article discusses pairing both ELC and HAproxy together.

Lastly, if you don’t want to get into the complexity that is HAProxy, you can always try load balancing through Nginx. There’s less fine-grained controls but it’s totally useable as an efficient load balancer.

Getting rid of 300ms click delay on iOS web views.

Posted on October 12th, 2012 in General Web Dev, mobile apps | No Comments »

While this technique shouldn’t be news to anybody that’s been doing mobile web development in some capacity, still I find myself periodically searching for an article (and this is the best one) again as a refresher when recreating a solution for whatever web application I am working on. One can use existing libraries that’s implemented this concept like Fastclick but I find using JavaScript frameworks like Backbone require something more custom:

Creating Fast Buttons for Mobile Web Applications