Gives new meaning to the term “ARMs race”.

Since my last post was a point-form update, I thought I’d follow suite this time around.

• I landed a position at an internet company based in Las Vegas, Nevada (and later Dallas, Texas).
• I jumped over that way for a short period of time to meet, greet, negotiate, etc in Las Vegas.
• I flew back to Australia, sorted out my E3 visa, and then flew back to Dallas with my little family beside me.
• The owner of said company turned out to be a convicted felon! That was unexpected. Company tanked, I can only assume because the investors found this out also.
• Dragged family back to Vegas.
• Found out about a serious illness in the family, which was devastating news when one is 10,000 miles away from said family.
• Got married in San Diego! (without a doubt, the best part of 2011 by a long, long stretch).
• Found out aforementioned illness was serious, but manageable and altogether surmountable. Much relief.
• Found out my wife and I are now expecting our 2nd child! (shares the podium with San Diego in terms of fantastic days in 2011)
• Put family on a plane back to Australia while I co-founded Dropbear IMG in the USA to encompass our future development activities.
• Flew back to Australia to a very welcoming wife and son and family overall.

So! Back on Australian soil after all that (temporarily) to see family, sort out the next opportunity in the USA and get the visa/immigration matters safely squared away. It’s been a… turbulent year to say the least.

While on Aussie shores, I’m carrying on with some existing dev work and a local client who has been supportive enough to offer a full-time gig while my feet are on the ground here.

In terms of what I’ve learned this year… oh boy, that would be a long list. I’ll be frank: what happened was terrible, and the individual(s) in question have blazed a trail of personal, professional and financial destruction through the lives of some very hard-working and talented individuals. I’ve never encountered anyone so bereft of moral fiber and common decency.

However, I’ll exchange bitterness for pragmatism, anger for optimism, and a desire for retribution for a commitment to dust myself off, move forward, and get back to what I was doing. There are some fantastic opportunities out there for someone with my experience, and I plan to make the most of it and make my mark.

To that end, I’m officially saying “goodbye” to the current blog template and starting new, when I manage to find a layout I like! And one thing that’s been indicated to me recently is that while I do spend my days elbow-deep in code, I really should write about it more (the problems and the solutions), something I intend to fully embrace.

Remember folks, sometimes there’s only one direction that matters: forward.

Exciting new developments though… I have an opportunity to dabble in SAP.

I’ve also set up shop in a shiny new office in the Brisbane CBD. It’s taken the better part of 4 weeks to get naked ADSL installed here (cable guy should be arriving….. 8 minutes ago) so it’ll be nice not to run up my 3G bill.

Probably the coolest thing I’ve seen all week is Panic’s status board. Panic make a brilliant FTP client called Transmit… amongst other products that I haven’t explored yet.

Panic status board

Seriously cool.

But is it really necessary?

YES.

A status board like that would make a such a difference in any development environment. Being able to see at a glance who’s doing what, what people are saying, live updates of a product’s uptime/downtime… given the opportunity, you could fill a wall with live data about your products, and it wouldn’t be wasted space.

I’ve seen the classical whiteboard setups, but you always have the problem of people not updating it because they don’t have 5 minutes free to run to the whiteboard, or someone accidentally wiped out an important note or somesuch. The whiteboard has had it’s day.

While flitting around the Panic website, Coda has caught my eye… I might have to look at that.

Don’t look a gift horse in the mouth, as they say.

VICTORY IS MINE!!

In this example…. we’re configuring lighttpd as our forward-facing (port 80) web server, which will use mod_proxy (proxy module) to send any dynamic requests back to apache listening on port 8080, while lighttpd takes care of any and all static content. I won’t go into the details of *installing* lighttpd or apache as this is beyond the scope of this article.

First of all…. ports.

In the Apache config (/etc/apache2/ports.conf if you’re using Debian, or /etc/httpd/conf/httpd.conf if you’re using RedHat or a derivative, these are just the defaul install locations) you want to find the following line:

	Listen 80

And change it to:

	Listen 8080

That’s it for the apache config! By default, lighttpd should already be listening on port 80 so we don’t need to change that.

In lighttpd.conf (wherever your distro of choice chooses to place this file), find the server.modules section, and uncomment (or add, if it’s not there already) the following line:

	"mod_proxy",

Now, scoot down to the bottom of the file, and we’ll set up the proxy:

	$HTTP["url"] !~ "(?i)\.(js|css|gif|jpg|png|ico|txt|swf|mp3|pdf|ps|wav|flv|zip|rar|gz|tar)$" {
		proxy.server = ( "" => (
			( "host" => "your-server-ip-here", "port" => 8080 )
		))
	}

Obviously substitute “your-server-ip-here” with the IP address of your web server. This is very important, because if you use any virtual hosts, they won’t like it if you just set host to 127.0.0.1 (or at least they didn’t in my config).

Which brings me to the next point…. virtual hosts. If you are serving several domains from the same location and use several different virtual hosts, you will need a virtual host definition for each because lighttpd simply needs to know where to look for your static content! This worked for me (for this site):

	$HTTP["host"] =~ "(^|\.)richardwalker\.com\.au$" {
		server.document-root = "/opt/web/richardwalker.com.au"
	}

That’s it….. thats a virtual host definition in lighttpd. There are several more options but for the purposes of this demonstation (and of this site), that worked a treat.

All that’s needed now is to stop both apache and lighttpd, then start them up again.

You might wonder why this approach is beneficial….. it is possible to set up apache to use persistent connections, which means it fetches all the content (the root page, the CSS, the images, etc) all in the one connection. This can be troublesome for sites with huge amounts of traffic, as instead of just dropping off when the job is done, persistent connections hang around for a predetermined length of time. Large amounts of concurrent traffic can quickly turn into a large number of persistent connections.

Alternatively, if you leave persistent connections off, you get a connection made to the web server for each item in the HTML that needs fetching…. the root HTML itself, a CSS file or two, a JS include, all the images……. for each one of those, Apache will fire up a process, load its modules etc, fetch the item, and drop off. This can result in very large chunks from memory being eaten up all at once in bursts, which can slow things down considerably.

There are of course several schools of thought on this sort of thing, and everyone has an opinion about which is better…. for me, the approach outlined above works perfectly. My lighttpd access log has hits for all the static items, and my apache log has only the single hit, the initial GET request for the HTML itself. Which is exactly the way it should be.