kill the radio » deployments http://blog.killtheradio.net or die trying Fri, 18 Jun 2010 04:56:10 +0000 en hourly 1 http://wordpress.org/?v=3.0 Javascript minification with JSMin and gzip http://blog.killtheradio.net/technology/javascript-minification-with-jsmin-and-gzip/ http://blog.killtheradio.net/technology/javascript-minification-with-jsmin-and-gzip/#comments Tue, 04 May 2010 00:32:54 +0000 Andrew Lyon http://blog.killtheradio.net/?p=527 Here’s a good tip I just found. Note that this may not be for all cases. In fact, I may have stumbled on a freak coincidence. Here’s the story:

I hate java. I hate having java on a server, but hate it even more if it’s only for running one small script. Forever, beeets.com has used the YUI compressor to shrink its javascript before deployment. Well, YUI won’t run without java, so for the longest time, jre has been installed collecting dust, only to be brushed off and used once in a while during a deployment. This seems like a huge waste of space and resources.

Well, first I tried gcj. Compiling gcj was fairly straightforward, thankfully. After installing, I realized I needed to know a lot more about java in order to compile the YUI compressor with it. I needed knowledge I did not have the long-term need for, nor the will to learn in the first place. I, although revering myself as extremely tenacious, gave up.

I decided to try JSMin. This nifty program is simple, elegant, and it works well. It also has a much worse compression ratio then YUI. However, I trust any site that hosts C code and has no real layout whatsoever. Knowing the compression wasn’t as good, I still wanted to see what kind of difference gzipping the files would have.

I recorded the size of the GZipped JS files that used YUI. I then reconfigured the deployment script to use JSMin instead of YUI. I looked at the JS files with JSMin compression:

YUI:
mootools.js     88.7K (29.6K gz)
beeets.js       61.5K (20.5K gz)

JSMin:
mootools.js    106.1K (29.5K gz)
beeets.js       71.0K (17.7K gz)

Huh? GZip is actually more effective on the JS files using JSMin vs YUI! The end result is LESS download time for users.

I don’t know if this is a special case, but I was able to derive a somewhat complex formula:

YUI > JSMin
YUI + GZip < JSMin + GZip

Who would have thought. See you in hell, java.

]]> http://blog.killtheradio.net/technology/javascript-minification-with-jsmin-and-gzip/feed/ 1 Fix capistrano multi-server deployments (sort of) http://blog.killtheradio.net/tricks-hacks/fix-capistrano-multi-server-deployments-sort-of/ http://blog.killtheradio.net/tricks-hacks/fix-capistrano-multi-server-deployments-sort-of/#comments Mon, 30 Nov 2009 22:14:48 +0000 Andrew Lyon http://blog.killtheradio.net/?p=352 Capistrano is a sexy bitch. At least it was until I spent hours trying to figure out how to deploy to multiple servers. Updated Cap, Ruby, compiled Ruby from source twice, etc etc. Capistrano just kept hanging with pushing code to two or more servers at once. Note that I am in Cygwin, if that makes a difference. Also, when deploying with no password on my ssh key, it works…hmm.

Well I added this:

default_run_options[:max_hosts] = 1

To my deploy.rb, and although it now has to deploy to one server at a time, it works. Note that for two servers this is fine. For 200 it’s not so fine. I’ll worry about that when it comes though.

UPDATE!!!! Something I never thought about until now is that you can use ssh-agent to save your keys in memory pre-deploy. Then you have a password-protected key that works with Capistrano WITHOUT doing the max_hosts hack. This is tested (on cygwin) and working for me.

]]> http://blog.killtheradio.net/tricks-hacks/fix-capistrano-multi-server-deployments-sort-of/feed/ 0