Archive for November, 2012

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.