The Battle {For | Against} Complexity

Rod Johnson:

"I probably shouldn’t say this in a Java community website, but I think that the Java community has almost a pathological desire for complexity at times."

Testify, brother! Although I must add that I suspect this is not exclusively a Java-specific syndrome.

I think it's more to do with the average experience level of developers on a given platform. I would expect the typical Rails developer to be more experienced than a Java dev (I have nothing to back this up, but a cursory inspection of the type of questions being asked on Stack Overflow would tend to confirm this). I have observed a distinct correlation between development experience and desire for over-engineered, complex solutions; it looks like this (pardon my ASCII):

D(comp)
|
|               C C C
|             C C C C
|           C C C C C C
|         C C C C C C C C
|       C C C C C C C C C C 
|     C C C C C C C C C C C C
|   C C C C C C C C C C C C C C 
| C C C C C C C C C C C C C C C C C C C C
|------------------------------------------- Exp
0   1   2   3   4   5   6   7   8   9   10            

The initial "I'm so green" fear of complicated stuff quite quickly is replaced by a desire to flex one's "architect" muscles, typically culminating in an extravaganza of ornate (often distributed) designs at the 4-5 year mark. Shortly afterwards, the folly of one's ways is realised. Ornate designs require ornate maintenance, and that doesn't go down too well with anyone, least of all the prima-donna who came up with the design and now is saddled with babysitting it. The enthusiasm for system diagrams with many, many boxes quickly subsides. A pragmatic programmer emerges at the 8-year mark. DRY, YAGNI and anti-NIH are the order of the day.

And that seems to be the difference between the Typical Java Dev, who is probably sitting on top of the above mountain, and the grizzled Typical Rails Dev, who has scaled it and is coasting down the other side :-)

Debian on a NetVista N2200

While Puppy Linux has been a solid base for this web server for quite some time now, before bringing up a second NetVista N2200 unit, I was looking to move OS to something a little more familiar - a Debian-based OS. I'd found myself wishing for the ease of the deb package management and cursing the way the entire Puppy OS was copied into RAM on startup - very clever and fast, but I don't really want my precious 256Mb filled up with unused instances of /usr/bin/xeyes ...*

I wasted an entire weekend hacking PusPus, which claimed to be able get Debian Etch onto the NetVista. This claim was true, but the OS was all but unusable - any attempt to apt-get install some useful components (like ssh), or even running apt-get update was enough for a segmentation fault and complete system halt. Tweaking the PusPus Makefiles to fetch and build a Debian Lenny image resulted in exactly the same problem.

The Single Point of Truth on all things N2200 is, rather bizarrely, the comment thread at the foot of This Guy's Blog Post, but there is some great stuff there. My saviour was the replacement boot loader and OS image by der_odenwaelder (username: NetVista, password N22008363). This guy has done a sterling job in papering over the nastiest deficiencies in the NetVista's quirky hardware.

Finally I have a (relatively) up-to-date Debian build (Lenny) on my new machine, and it goes beautifully. My local APT Cache is really starting to pay dividends now, and will be even more valuable once I migrate this machine to the same platform.

Now that I can run a more "conventional" Linux OS, I'm getting excited again about the server potential of this all-but-forgotten black box. You can pick them up from eBay's Workstations category all the time for a pittance, and with a suitable RAM and CF Card injection, you've got a handy-dandy general-purpose server that you can leave switched on 24/7 while it uses less power than your broadband router.

(*) Just an example - I removed all of the XWindows stuff from the Puppy image as soon as I got it working.

2011H2 Ponderables

What's on the cards and/or on my mind for the second half of 2011?

• Going on holiday to Canada and the States in July. Woohoo!


• The BRAIN (Blatantly Ridiculous Array of Inexpensive Netvistas) - utilising yesterday's ultra-low-power hardware, today!


• Evaluator Chain - continuing my personal, hopefully fortune-making project


• Continuing the epic Ubuntu Build Box story, that somebody, somewhere, may find useful...


• Less Code - enjoying the luxury that in the Java world, it's almost certain that someone has solved your problem and published a good solution


• More Tests - to make sure that what code I have written is absolutely rock solid


• Enjoying Learning about HTML5, CSS3, Ruby, JPA2 and more

On Walkthroughs

At my current employer, as part of their flavour of Agile (no two ever the same!) we developers are required to conduct a walkthough of every story we finish. Present must be a tester and a BA. All very well in theory.

But it seemed to us that some walkthroughs were uncovering bugs and/or oversights early, while other stories were breezing through their walkthrough but then exploding once the testers got their mitts on them. What was going on?

It turned out that in many cases, the developer, having spent possibly days neck-deep in the code, had a level of understanding of the problem domain far in excess of the BA and tester he was demoing to. As a result, the developer (consciously or not) would exude a confidence in his solution that would almost intimidate the "spectators" into not objecting to any deviations from the story specification.

A walkthrough conducted in this vein is almost useless, which led me to the formulation of the following rule:

The value of a story walkthrough or other such demonstration is directly proportional to the experience level of the audience

Ultimate Ubuntu Build Server Guide, Part 4

Sync Thine Clocks

Note from future self; Although this setup guide is now superseded by cloud-based tools, certain elements are still useful simply as good practice, such as the "groundwork" in the early stages of this guide. As such, this article has been spared the chop

This is Part 4 of my Ultimate Ubuntu Build Server Guide.

Although it's less critical these days than it was in the bad old days of makefiles, it's still not optional that ALL your machines MUST be NTP-synced to a machine on the local network.

Think about how annoying it is when you login to a remote server to do some logfile-trawling but discover that the server's concept of "wall clock time" is actually 3 minutes, 37.234 seconds behind your local machine's. Ugh. I've noticed this is a particular issue with Virtual Machines - clock drift seems to be a perennial issue there.

Again, getting this stuff working doesn't have to be a big deal and certainly doesn't have to involve A Big Linux Box.

Your common-or-garden DSL router can almost certainly be "pimped" with a more-useful firmware image from one of the many open-source projects. On my NetGear DG834G, I'm using the DGTeam firmware image (unfortunately that project seems to have died, but a very kind soul is mirroring their excellent final versions here).

This offers a fully-working, webpage-configured implementation of OpenNTPD which is the exact same software Big Linux/BSD Servers run anyway.

Owners of DSL routers from other manufacturers (like Cisco/Linksys, D-Link, Buffalo and non-DG- NetGear equipment) can get similar functionality boosts from:

• dd-wrt - I'm personally using this with success on a Linksys wireless AP. Supported device list
• OpenWRT - requires more powerful hardware than dd-wrt but has the potential to act as a full Linux server should you desire...

Ultimate Ubuntu Build Server Guide, Part 3

Groundwork, Phase 3: Calling Names

Note from future self; Although this setup guide is now superseded by cloud-based tools, certain elements are still useful simply as good practice, such as the "groundwork" in the early stages of this guide. As such, this article has been spared the chop

This is Part 3 of my Ultimate Ubuntu Build Server Guide.

A productive network needs a comprehensible naming convention and a reliable mechanism for dishing out and looking up these names.

Naming Thine Boxen

On my first day at my current workplace I asked what the URL of the Wiki was. "wiki" was the reply. That kind of smile-inducing, almost-discoverable name is exactly the kind of server name we are looking for. At the other end of the scale is the completely-unmemorable, partly-implemented corporate server-farm naming scheme that means your build box is psal04-vic-virt06-r2 and your wiki lives on 12dev_x64_v227a. Ugh.

DNS and DHCP

The cornerstone of being able to talk to machines "by name" is of course, DNS. You need your own DNS server somewhere on the network. I know what you're thinking - that means a big, noisy, power-sucking Unix box and bind and resolf.conf and ... argh!.

Not necessarily.

Unless you've been living under a rock for the last 10 years, you'll have noticed that there are now rather a lot of small networked devices around, all running some flavour of Linux. Your DSL router is almost certainly one of them, but while it probably offers DHCP services, it probably won't be able to serve up DNS entries (as aside from proxying DNS entries from upstream). That's OK. There are other small Linux boxen that will do the job.

I speak of NAS devices. I'm personally using a Synology DS209, which is the kind of web-configured, one-box-solution, Linux-powered network überdevice I could have only dreamt about 10 years ago. In addition to storing mountains of media files and seamlessly acting as a Time Capsule for my MacBook, this neat little unit also runs SynDnsMasq, a port of the amazing dnsmasq DHCP/DNS server.

dnsmasq

A simple, elegant and functional tool that runs off one superbly-commented configuration file, dnsmasq will make your local network much more navigable thanks to local DNS addresses - ssh user@buildbox is much better than ssh user@10.12.14.16, don't you think?

Having full control of your DHCP server (as opposed to the primitive on/off on most domestic routers) also allows you to set up effectively-permanent address allocations based on MAC addresses. This gives you all of the advantages of static IP addresses for servers, but allows you to have a centralised repository of who-is-who, and even change things on the fly, if a server goes offline for example.

By running this software on my NAS, I get all of these features, plus I save scads of power as it's a low-power unit AND it switches itself on and off according to a Power Schedule so it's not burning any juice while I'm asleep. I've configured the DHCP server to actually tell clients about two DNS servers - the primary being the NAS itself, the secondary being my ADSL router. That way, if I start using a client at 10.55pm, I can keep surfing the web after the NAS goes to sleep at 11pm - the client will just "fail over" to the main gateway.

Name Your Poison

The actual names you use for servers and clients are of course a very personal choice. One of the best schemes I've used was based on animals, with increasing levels of maturity and/or decreasing domesticity based on their function. A table's worth a thousand words here I think!

Function	Species	Dev	Test	Prod
App Server	Canine	Puppy	Dog	Wolf
Web Server	Equine	Foal	Horse	Zebra
Database Server	Capra	Kid	Goat	Ibex

While this caused much hilarity amongst non-technical people ("Horse will be down until we bounce the Goat" is not something you hear in many offices!), it actually worked very well.

The scheme I'm using at home is a simple "big cat" scheme - lion, tiger, cheetah, leopard etc - but I've taken the opportunity to "overload" the names in my dnsmasq configuration - so buildbox currently resolves to the same machine as cheetah - but of course should that duty ever change, it's just a one-line change on the NAS to fix it.

Ultimate Ubuntu Build Server Guide, Part 2

Groundwork, Phase 2: Sensible IP Addresses

Note from future self; Although this setup guide is now superseded by cloud-based tools, certain elements are still useful simply as good practice, such as the "groundwork" in the early stages of this guide. As such, this article has been spared the chop

This is Part 2 of my Ultimate Ubuntu Build Server Guide.

First things first. If you're running a development network on a 192.168.x.y network, you're going to want to change that, stat. Why? Because you simply don't (or won't) have enough numbers to go around.

Yes, you're going to hit your very own IPv4 address exhaustion crisis. Maybe not today, maybe not tomorrow, but consider the proliferation of WiFi-enabled devices and virtualised machines in the last few years. If you've only got 250-odd addresses, minus servers (real and virtualised), minus workstations (real and virtualised), minus bits of networking equipment, and each developer has at least one WiFi device in her pocket, you're probably going to have to start getting pretty creative to fit everyone in. And I haven't even mentioned the possibility of being a mobile shop and having a cupboard full of test devices!

To me, it makes much more sense to move to the wide open spaces of the 10.a.b.c local network range. Then not only will you have practically-unlimited room for expansion, but you can also start encoding useful information into machine addresses. Allow me to demonstrate with a possible use of the bits in the a digit:

 7 6 5 4 3 2 1 0
 | | | |
 | | | \- "static IP"
 | | \--- "wired"
 | \----- "local resource access OK"
 \------- "firewalled from internet"

Which leads to addresses like:

Address	Meaning	Example Machine Type
10.240.b.c	fully-trusted, wired, static-IP	Dev Servers
10.224.b.c	fully-trusted, wired, DHCP	Dev Workstations
10.192.b.c	fully-trusted, WiFi, DHCP	Known Wireless Devices
10.128.b.c	partly trusted WiFi DHCP	Visitor Laptops etc
10.48.b.c	untrusted wired static-IP	DMZ

You've still got scads of room to create further subdivisions (dev/test/staging for example in the servers group) and access-control is as simple as applying a suitable netmask.

In the above case, sensitive resources could require a /10 (trusted, firewalled) IP address. Really private stuff might require access from a wired network - i.e. a /11. Basically, the more secure the resource, the more bits you need in your a octet.

It might be a bit painful switching over from your old /24 network but I think in the long term it'll be well worth it.

Next time, we'll look at how to name all these machines.