I've repeatedly found myself trying to visit http://sourceforget.net. Needless to say this doesn't resolve. But I wonder if my fingers aren't smarter than me.

Rather than recount my frustrating experiences with the SourceForge support system, I'll just repost my latest support issue in the hopes that other people might find it and lower their expectations before having it forcibly lowered by the cold, hard hand of SourceForge "justice" (where justice should be replaced by incompetence).

Consider this a complaint. I don't expect any action on this since it's going into the same system I'm complaining about.

I've logged two issues in the past month regarding an SVN import failure (1439808 and 1448954). The first issue was closed after a quick back and forth which didn't resolve anything. The reason for closing it was that it was "determined that my request was covered by the documentation".

I was pointed back to the docs that state "if the import fails, log a support request".

The second one appears to have been closed because I didn't respond within 14 days. This amuses me because I only received a response from your support team after 15 days. I guess you can keep your issue count down by ignoring them for long enough?

In both cases I've had no useful responses, merely the same question (which I've answered repeatedly).

I'm not even asking for something to be fixed. I just want some more info about the failure (more than "FAILED") so I can try to troubleshoot this myself.

Along with the first issue I logged an unrelated issue (1439810) about problems logging in using Firefox. The only (non-automated) response to this issue has been by another user indicating they're seeing the same behaviour. Beyond that I've had no response in the 28 days since I logged the issue.

In terms of support this is a disgrace. I understand that it's free and perhaps you do get what you pay for, but where before I would have considered paid support I'm afraid I've been completely put off ever putting real software into your hands.

It would be nice if I could exchange email with a real person on this issue since this system seems to be breaking down.

Yours in frustration
James Greenfield

The illusion of mastery over your tools is very liberating.

A couple of dozen Drunken Blog Rants later and my language stack is deeper than it's been in a loooong time. So now I find myself with half a dozen or so languages I want to play with and the difficult task of deciding where to start.

Even though I've been using it for a few months I still consider Ruby one of the languages on the list. The difficulty of learning a new language is that it's usually not sufficient to simply ingest a new syntactic ruleset and find equivalents for a bunch of constructs in a familiar language. This works if the language is very similar to a language you already know. Ruby's deceptively similar to Java, Perl and Python in various aspects but there's enough lurking in here that means it's going to take a small investment before I feel like I'm programming idiomatically in it. Ruby has an advantage in that much of what we're currently writing at Amazon is in Ruby, so I'm already using it to solve real problems. Unfortunately, the nature of the work we're doing means coding is a bit stop-start, so progress is slow.

Somewhere along the way I stumbled across Scala. It targets the JVM (and I think work is underway to target the CLR) which gives it a bit of a boost since you have access to a wide range of existing libraries and a mature platform. Scala has a bunch of interesting ideas but doesn't depart radically from the Java model. It's statically typed but uses type inference. All types are objects (so there's no distinction between primitive types and objects). It's "functional" in the same sense Ruby is "functional" and it goes some way to elevating functions to being first class members again. It supports traits (interfaces that allow for method bodies, something like Ruby's mixins) and some degree of extensibility (any method that takes a single parameter may be used as an infix operator). But it's syntax is pretty horrible and other bright, shiny toys drifted into my field of vision and displaced it.

OCaml is a far more established language with a bit more pedigree. It has the distinction of producing compiled code that is as fast (and usually faster) than C or C++ code, largely due to it's extremely strict type system. The compiler generally knows a whole lot more about your code than a C (and especially C++) compiler ever will. As a result it can apply optimizations far more aggressively. It also supports type inference but you can include optional type information even though the compiler doesn't require it if it makes code clearer. I've only taken the briefest of looks at OCaml so I can't really comment. Suffice to say it's a language I would like to come back to at some point.

I've already blogged about starting to play with Lisp again (specifically Common Lisp). Tomorrow Practical Common Lisp arrives. Mmmm ... dead tree ... mmmm. Lisp is noteworthy for being one of the most extensible languages ever created. Common Lisp was an attempt to standardize the various Lisp variants floating around and essentially give the world a production ready version of Lisp. Lispers seem to be divided over whether or not CL is a farce or a Good Thing^TM. The jury's still out for me.

Just as I was getting stuck into CL a bright, shiny toy called Erlang caught my eye and derailed me entirely. Erlang was created by Erricson to support their own in-house work developing telecommunications systems. Erlang is pretty ambitious, aiming to include support for highly concurrent applications (thousands and thousands of concurrent processes), fault-tolerance, "continuous" computing (software components can be hot-swapped) and to provide "soft" realtime guarantees. It has a pretty rich set of libraries and a number of implementations (always a good thing) including at least one commercial implementation. Erlang is functional and borrowed bits and pieces from Prolog, Lisp and Parlog. It's Progol roots are pretty obvious when you start looking at actual code.

A brief sidetrack last night brought me to the recently released Fortress specification. This is a research language being developed at Sun, with the intention of replacing Fortran. It reminds me a lot of Scala. It looks pretty ambitious in some respects and Lisp's influence is quite obvious: the spec includes a section on supporting domain specific languages (something Lisp's extensibility gives it naturally) and the spec even mandates tall-call optimization. Not surprising given that Guy Steele's involved. Fortress supports top-level functions (and I would guess that functions are first-class objects but I haven't confirmed that yet), and functions can return multiple values (handy). A more interesting feature of Fortress is something called function contracts. These essentially formalize pre- and post-conditions and invariants. This falls into the same bag as static typing. You get more compile-time safety but usually at the expense of flexibility. And just to mess with your mind Fortress also includes some explicit support for parallelization. For example, iterations in a for loop are executed in parallel by default. That's about as cool as it is scary.

I'm quite enjoying playing with Erlang, and I think it would be a really good exercise to get more familiar with CL. So for the moment those are going to be the focus of my attention (along with Ruby as part of my day to day work).

Erlang in particular is interesting because it was created with the explicit goal of raising the level of abstraction. Erricson had a specific problem domain, which implied a set of requirements. They believed that the only sane way to tackle it was to created a language that included building blocks that directly supported their requirement (concurrency, fault-tolerance, soft realtime responsiveness). Sure, in a straight line it's an order of magnitude slower than C (apparently) but it wins hands down when you have to scale the system up or maintain it. If I had TM to do over Erlang would be a strong contender. I'm a big believer in appropriate abstraction. If you're thinking at the wrong level you're doomed from the get go.

It occurred to me recently that the programmers who are visible to the world are probably actually in the minority. The guys you see and hear making a noise generally fall into two categories.

The first group is a small group who, for a wide range of reasons, tend to be quite vocal. These reasons include a desire to make a difference, ego in spades, an interest in pushing a certain approach, tool, platform or package, and any number of other reasons for putting themselves out there.

The second group, who constitute a majority, tend to be idiots. By and large if someone is posting in a technical forum their contribution can only be measured with an electron microscope. On a brief tangential note, my favourite example of this is a few thousand word long post describing in detail how Oracle stores and manipulates date-time values, followed a post by a very well known (and respected) Oracle developer along the lines of "put that crack pipe away and find a job you're up to". In general the people with the answers do not have time to engage in hour long online tag-you're-it exchanges because, well, gee, they're busy figuring the answers out. Sometimes I think the Internet only has the answers by virture of the sheer volume of stuff (i.e. crap) out there. Monkeys, typewriters, you get the picture.

But I digress. This post is not about the Unhelpfuls that lurk on newsgroups and technical discussion forums. It's about programmers, and it's about programming (the career rather than the technical activity).

If you spend any time reading about jobs in IT and about programmers and programming languages and tools and platforms and ... you get the idea ... then you'd probably come away with the impression that programmers are constantly changing jobs, and languages, and platforms and wow there's so much going on, must ... learn ... it ... all.

I don't think that's an accurate picture. Not even slightly. I think if you could sit down and collect some accurate figures you'd find that the majority of programmers are "lifers". They're the 90% of the iceberg sitting below the waterline. Admittedly, the term lifer is probably not entirely accurate. Gone are the days where people joined a company at 18 and worked until they received a gold-plated watched and a handshake at 65. Actually, even that's not strictly true. Computer programming as a career hasn't really been around long enough for anyone to have traveled that road. But you get the idea. So when I use the term lifer what I really mean is long-term, say 10 or more years.

Someone once told me that the average length of time a programmer spends in a given job is 18 months. Or it might have been 30 months. Either way not very long. At the time I thought it was backed by cold hard facts (well, no, what I actually thought was something like "hold crap Batman, I'd better get a move on!"). I no longer believe that's the case.

There's definitely a large subset of programmers who move on to new opportunities reasonably quickly. But I think the vast majority tend to stick around for much longer. It certainly explains the number of interview candidates that seem to have focused on one language/platform to the exclusion of all others. On the face of it it makes sense. If you're in one place doing one thing then to get ahead you'd better do it well. Better than anyone else if possible. It scares me to think that I might end up on the kind of uni-directional track but I'm quite prepared to accept that I'm just one kind of person who views it as stagnation and that one man's stagnation is another man's perfection of a craft. I'm not here to preach that all programmer's should play with a new language, or tool, or platform as often as they can (even though I believe they should). I'm just sharing an observation (or perhaps perception is more accurate).

I suspect that most programmers spend 10 or more years focused on one job. As part of this they tend to be pretty single-minded about the tools they use. This is a perfectly acceptable way to conduct a career. It's a pragmatic approach to programming as a career. And if you're more interested in solving practical problems then it may not interest you to get bogged down in a better way to do things, or whether or not the platform, language, tools or even approach you're using are the best.

Personally I believe the real advances are made when things are challenged and people start asking meta-questions. These people are on the other end of the spectrum and I can understand why they'd tend to "job-hop". It's the career equivalent of the guy who solves the meaty core of a problem but has little or no interest in tying up the loose ends that differentiate a prototype from a complete solution. I'm a little that way and sometimes I have to force myself to sit down and polish off the rough edges.

And as in all things these are but extremes on either end of a continuum. Nothing is ever absolute. I suspect I sit closer to the latter end of the spectrum (the end overrun by job-hoppers) than the former, but I tend to approach things more pragmatically than most people I would put down that end so if you ran it as a scale from 1 (lifer) to 10 (job-hopper) I'd probably peg myself somewhere between 6.5 and 7.5. And it would fluctuate. Daily. Wildly. Just to keep you on your toes.

I think it's important to realise that this continuum exists. At the very least you need to recognize that you need to be looking for a "like-mindedness" before you can, well, start looking for it. It goes some way to explaining why one pair of programmers will get on so well while another pair find they have nothing in common.

Black Velvet has been playing in my head for about a week now. On repeat. Repeatedly.

Who knows why? So I finally gave in and ... er ... no nevermind, piracy is bad! Stay in school! Don't do drugs!

Phew. Dodged a bullet.

Just a handful of changes. Most work for this release has focused on the SAX unmarshaller and the internal XML parser (both courtesy of Roland). Get it here.

  - Various fixes to the SAX based unmarshaller when dealing with nested
    structs that must be mapped onto user-defined classes.
  - Corrected a logic error in the SAX unmarshaller that broke XML-RPC
    fault handling.
  - Some improvements to the SAX unmarshaller when handling messages
    that span buffers.
  - Corrected an error when handling an empty value within the SAX
    unmarshaller.
  - Fixed a buffer refill error in our internal XML parser.
  - Added logic to avoid reporting a ClosedSelectorException unnecessarily.
  - NullLog no longer logs errors to standard error by default. I'm still
    thinking about how best to handle this.

Not much to report. Home alone, Mosaic, er I mean S1, having pulled the usual off-you-go-at-short-notice stunt. So at the moment Claire's in London shortly to hop over to Poland to present vaporwa ... er I mean conceptware to a potential customer.

So I'm figuring out new and marvelous things like which nobs make the top of the big white box in the food-room hot and how to open those metallic cylinders that contain edibles (I think they grow on trees).

Work is heating up what with us screaming towards an Optimistic Deadline^TM. And in all likelihood I'll be off to Seattle at some point in the immediate future (so immediate that there's a possibility I'll be off before Claire's back). This will afford me yet another opportunity to explain to other programmers how I think they should do their jobs. Ho ho ho, ain't Life a barrel of laughs.

On the personal growth and spiritual front I'm attempting to master Emacs. Master is a strong way of putting it. Perhaps attempting to not be mastered while using it is more correct. In case that turns out to be too easy I've also decided to take the Lisp plunge. I was going to say revisit Lisp but frankly, "everyone's" used Lisp at some point but the kind of tinkering you do at varsity really doesn't count. I'm taking the "pragmatic" route by playing with Common Lisp (as opposed to the "purist" route and writing deaf, dumb blind code completely shut off from the outside world). For the first time in a long while I'm really interested in a new language. I'm just not as blown away by Ruby as the rest of the world. Sure I can see some of the elegance people talk about (although not in the syntax, frankly I think it's pretty awful in many respects) but it just hasn't blown my skirt up. I don't feel a driving need to play with it the way I do Lisp. I think ultimately what made my mind up about Lisp was a comment about how Lisp really is one of the few languages that isn't derived from Algol. And it's because Algol was designed to drive a von Neumann machine whereas Lisp was derived from the Lambda calculus. So their roots are completely different which means a language like Lisp is a really good place to expect to find completely different ideas and ways of approaching problems. In some sense the former are too focused on the hardware of computation while the latter is much more centered on the software.

Which brings me to self-improvement activity number three which is to dust off my old maths textbooks and go through them again. Blow out some cobwebs, get some of the old vacuum tubes glowing again. Maybe even get into some areas I've never spent time in. We'll see. All of these are likely to be long term. I think if I push it too hard then I'll just get fed up and back off entirely. So baby steps.

On the Rox front, 0.6 is pending and work on Rox is likely to slow down a bit while I spend some time on a private project (as yet undecided) using Common Lisp. Of course the fact that we're actually using Rox at work will drive it forwards some (I suspect that's one of the reasons it's come so far) but beyond bug fixes and one or two minor features we're likely to need I don't see a whole lot more immediate work. I don't think it's by any means come to an end, it's just been niceed down a little.

So as I said in the beginning. Not a whole lot to report.

Recently someone forwarded me a copy of something posted in the knowledge base wiki of my previous employer.

It struck a nerve and my immediate prediction was that it would be removed (or requested that it be removed) shortly. Sure enough, a day later someone has taken offence and as a result it has been removed.

The problem is, the wrong people took offence. And they took offence for the wrong reasons. So perhaps I should attempt to explain (and you should bear in mind that this is my own view on these things).

First and foremost I believe that a company that can't poke fun at itself can't hope to be a company people want to work for. Want in this case means people work there for reasons other than money. Hell, if Microsoft can do it anyone can.

Secondly, what is this "tea" that is being barometerized (apologies to the OED for that)? My former employer started a tradition of Friday teas very early on. The basic idea was to get everyone together once a week to chat over snacks provided by the company. New people got a chance to mingle and no-so-new people got a chance to look up from their keyboards (or whatever other people do their jobs with) to run a pattern recognition algorithm over faces that didn't garner an immediate hit.

Over time teas grew in size and quality but inevitably something triggered a company-wide financial review and one of the first casualties tended to be Friday teas. Looking back over the past few years FTs seem to have followed a predictable cyclical pattern. Over time FT would wax gibbous before peaking, only to suffer a "financial adjustment" and be reset (back to "bread and water" level) before starting the cycle over again.

The people who took offence in this instance took offence because they thought this poked fun at the quality of "Friday Tea" and they put a lot of effort into it (something I'm not sure many people realised). On the surface it does but I'd wager (again, based on personal experience) that that's not the true target here (or at least not the root cause of this posting). The problem comes down to what I'd label "consistency" and not quality. Ultimately the problem is a company that doesn't realise that it's the little things that count. That spending a few extra hundred bucks on something as silly as tea wins you back a whole bunch. Or to put it more bluntly, counting pennies instead of counting people.

I'll admit that very few companies seem to get this right. But this crowd got it right for a long time. I think one of the difficulties of growing is figuring out how to deal with this. Throw in a large (listed) American company and things get even tougher, especially if they're not making money and you are.

Perhaps this should be the first of James' Drunken Blog Rants.

It seems we're having a few issues with our dyndns provider. I'm working on resolving the problem but until it's sorted out this site (which includes flat502.com, flytek.co.za, fairymoon.co.za and nexinc.net) is likely to come and go like the wind in an alpine forest.

Apologies for that.

While we were out however, Rox 0.5 was released (followed promptly by two serious bugs turning up, so look out for 0.6 shortly). This includes "official" publication of the NIO tutorial and a brand spanking new JUnit test report.

In addition, I've gone over to the dark (light?) side and am playing with both emacs and lisp. So much has been said about these in all my reading over the past few years that I finally figured it was time to stretch the old mental muscles and see what they were like. I'll report back once I've had a bit more of a chance to play.

Actually, it's been "done" for well over 48 hours.

My immediate family has swelled by a factor of 3 (point something). My left hand is decorated with something that I keep mistaking for a band-aid. And I have entered the hallowed halls of the kept man (although, as I've been telling people all weekend, this really just formalized the existing state of affairs).

Ben asked me if they're still hanging between my legs. I'll shower in the morning and check.

It's been a great week. I really enjoy the Henning clan, and assembled together they're as crazy, funny, caring and sometimes psychotic a bunch of people as you're likely to meet.

Friday (henceforth known as The Day) was superb. The teeny-tiniest possible ceremony we could manage followed by a great lunch and much wine and revelry in a beautiful setting (The Vineyard Hotel in Claremont, highly recommended).

And I've been disconnected since then. I avoided plugging in again for as long as possible today, in a vain attempt to try to hang onto the holiday mood I felt slipping away. But alas, eventually the siren call of the Interweb hauled me back into the cold harsh light of, er, night?

I suppose the people who frequent this page are expecting deep insights into this Marriage thing. Well, I'm afraid I'm not sure I'm going to be able to avoid disappointing you. Perhaps they will come in time. The best I can do at this point is recount a moment on Friday where I realised that all these wonderful people now had absolutely no excuse in the world for disappearing into the void.

As promised today was indeed a scorcher. "Blast furnace" was a phrase I heard tossed about at one point.

It was so warm that I ended up in the sea. Yes, the ocean. Water. You heard right. Me. Wet. Beach. Sun. All that stuff.

But I hid myself during the hottest part of the day, beneath the shade cast by my laptop, and finished writing up this NIO tutorial based on my experience getting Rox working using the NIO libraries.

Hopefully it saves someone else some time. I'm happy if all it does is demystify one of the more complex APIs Sun has churned out.

Enjoy.

The forecast maximum temperature today is 40 degrees (celsius), with a discomfort index of 47. 47!

It was 32 degrees at 8am.

Throw in scheduled power outages and we're in for a day of excitement. Break out the ice packs. Oh wait, they all melted when the fridge went off.

Three good (technical) reads:

• On polymorphism and its failures
• A Java rant
• On languages (and specifically languages at Amazon)

There's some contentious stuff in here but I really recommend you read and, most importantly, think about what's being said. Even if at the end of the day you disagree hopefully you'll have a better understanding of why you disagree.

And once again I am tempted to give emacs a whirl.

In between power failures (thankfully I get a decent run out of this laptop's battery) I've been pouring over profiler output.

It turns out the Apache implementation was an order of magnitude faster than Rox in a "straight line" (one client in a tight loop making synchronous calls). This shouldn't have bugged me as much as it did. Rox was never designed for that kind of throughput. It's intention has always been ease of use and scalability.

But it did. A week later, the late nights have paid dividends. A combination of careful tuning and Roland's SAX unmarshaller (for simplicity Rox was built around a DOM parser) and we're less than 5% away from the Apache implementation.

Given that the overhead of a NIO selector is pegged at somewhere between 5% and 30% I'm prepared to step back and call it a day.

Now I just have to get this unmarshaller passing all my unit tests :-)