Chris Mountford

Nice Syntax for Ignoring Exceptions in Groovy

2013-04-23T18:32:00.000+10:00

Save your breath. I don't need to hear how we shouldn't ignore exceptions. I agree with you. We should use exceptions as a part of an API and we should accept exception handling as an important, fundamental design element in our code. Happy?

OK now, sometimes you know you need to ignore an exception. Often it's a narrow exception type, for example, the following exceptions are frequently ignored with good reason (usually the exception cannot happen in practice):

MalformedURLException
NumberFormatException
IllegalAccessException
UnsupportedEncodingException

Groovy inherits Java's exception handling syntax, the try, catch, finally blocks. While writing some code that ignored the exceptions I wondered what a Groovier way to do things would be. The following Config class is a kind of bean containing validated values read from a properties file. The defaults remain if the config file cannot be parsed for the given value.

Notice how the try {...} catch {...} looks like Groovy's closure passing syntax, as if there was a try method which is being passed a block. In fact I think Scala's equivalent is literally this (also, Scala is awesome).

But while it looks that way, it doesn't quite act that way.

But could it?

What I really wanted to have was something like this:

ignore (NumberFormatException) {
threads = Integer.parseInt(config?.threads as String)
}

This would ignore only a NumberFormatException if it was thrown, if something else was thrown, it would be thrown out of the present block.

As I expected this is pretty easy to implement in Groovy and after a brief search I couldn't really find anything in the standard libraries or the blogosphere at large.

Here's my implemenation with some example code:

Run this on the live GroovyConsole yourself.

What do you think?

Activate Remote Disc with Command Line on MAC OSX

2013-01-31T10:14:00.000+11:00

On Macs without a DVD drive (i.e. everything these days) OSX is configured to easily allow use of a "Remote Disc" wherever another machine has enabled DVD/CD sharing.

The trouble is the "Remote Disc" device was not showing up on my old Mac Mini's (broken DVD drive) and although I can usually avoid it I recently wanted to install something from a DVD. This machine has a DVD drive which is presumably why the option did not show up in the Finder preferences under Sidebar.

Fortunately these preferences can be turned on with a command line as follows:

defaults write com.apple.NetworkBrowser ODSSupported -bool true
defaults write com.apple.NetworkBrowser EnableODiskBrowsing -bool true

Enter that in the terminal and then Restart Finder using the Force Quit menu so the settings take effect.

Then you should see the remote disc icon and can mount remotely shared DVDs and CDs. Note that you must also enable DVD/CD sharing on the machine with the disc.

New Stuxnet Virus Beta Version Discovered

2011-10-19T12:30:00.000+11:00

Stuxnet, the most advanced computer virus ever discovered (by a long way), generally believed to be the first sophisticated example of a virus being used as an international military weapon, just got an upgrade. Most likely from its original authors.

At least, according to Symantec's analysis lab where a recently found version has been dissected on the operating table, it looks like the versions found in the wild "in Europe" were targeted test runs of a new version that was partly recompiled from the original source code which has so far remained secret.

The new version carries a different payload to the original Stuxnet which, it is generally believed, was intended to shut down or disrupt Iranian nuclear facilities. In fact the new version's actual payload is pluggable. Modules can be loaded dynamically from a command and control server located in India.

Duqu, as the new version is called, can read and write files, execute programs, capture keyboard input (to collect passwords) and generally open back doors for later use by the unknown attackers.

Check out the great article on this by Read Write Web and for a quick recap on the original Stuxnet, check this nicely produced - if creepy - video by Hungry Beast in Australia:

Why Programming is Hard

2011-10-09T09:01:00.000+11:00

Programming is not hard because computers are fussy. Programming is hard, but not for that reason.

There are plenty of pesky surface details in managing programming projects and programmers regularly find themselves burdened with managing tools and configuration details. More so when using Maven (Zing!).

But this is just work. Annoying repetitive work. It's not what makes programming hard.

In fact, programming is hard because there are so few limits to what you can do.

Certainly there are limits to computability, and there are famous problems and algorithms that define the state of the art in computer science, but for many programmers, knowing about these limits is enough to prevent them from pushing up against the hardness of these limits on a regular basis.

Programming is hard because the only limit is our own mental capability. It's always going to appear to be hard. It doesn't matter how smart you are.

If programming is not hard, then you're doing it wrong. Your brain is not being fully utilised? You are being limited by your tools and you need to replace them.

Any time spent dealing with repetitive details, remembering lots of things or even managing huge amounts of code, this time waste generally can be eliminated with more programming! This assumes you're in a postion to change the system enough and perhaps this is where practical project tradeoffs impose. And perhaps "the business" isn't interested in funding improvements to the open source build tool, or switching from Java to Scala. (Double Zing!) But those are not programming problems.

For me, because software is so soft, the goals can be altered subtly, continuously, destructively. Especially when ill-defined. The hardest thing generally comes down to dealing with the confusion of some form of not being clear what I'm trying to do. Unravelling the "is it this or is it that" trail of mental plans that led to the curent state. When this happens in the large, a software project is almost certain to fail.

But maybe that's just me. Do you think programming is not hard? Do you think it's hard for a different reason?

32 Bit 64 Bit - All up in your Bitness

2011-09-30T10:29:00.001+10:00

Here's one for the logophiles. English usage nerds. I'm coming out as a bit of a language nerd officially, today, so consider yourself warned.

In film they talk of footage. In transport, haulage. Then there are words like passage, patronage and of course cleavage. At school my friends and I would regularly put "-age" after words. "Foodage?" would mean "are you hungry?". "Skateage" was time spent skateboarding.

So what is it when you want to refer to how many bits something is?

You know your latest laptop is 64 bits and your last one was 32 bits. You know about the 16 bit retro video games like Sonic the Hedgehog and maybe even the "8 bit era" of the Commodore 64. So what do call that ... bitness?

I've heard it called bitness, and tweeted about it a while ago and got some interesting alternatives:

bitness
bittage
bittitude
bitality
bitosity
bitch

I guess the last one is a little challenging, linguistically. Maybe German?

Of course I had lots of replies to my tweet saying well you're talking about "word length" or "machine architecture" or other term specific to the usage. Well what if I'm talking about sound samples? "Is that a 16 bit sample or a 32 bit one?". Or colour space in digital imagery? Is that 24 bit colour? Ignoring bittitude is just like saying you can't call it footage, you have to call it film length.

We need to agree on a word that covers bitness and I think I'm coming down on the side of bittage.

Of course this is a question of crucial importance to the world (not - but I did warn you).

What do you think?

image credit jeffrey onMr Breakfast

Last Minute Usability

2011-08-24T12:04:00.000+10:00

Usability, like scalability and security cannot be added to a finished product any more than flavour can be added to a finished meal.

delicious photo by Shutter Ferret

This is NOT the 80:20 Rule You Are Looking For

2011-04-19T17:07:00.001+10:00

The 80:20 rule is based on the assumption that there is (often) an 80% (ish) subset of the realised value for a project that only costs 20% of the resources (e.g time) to complete. The rule, actually the Pareto Principle popularised by Richard Koch and others, like all rules of thumb, can be applied incorrectly.

It's not a license for doing things half-arsed.

Automated Testing in Games

2011-04-06T10:19:00.001+10:00

So I clearly upset a few game developers with my last blog post. Sorry about that! I do find it a bit surprising how strong some of the emotions were but I probably deserved the beating I got on reddit.

Second my post was too long and based on my stats, it looks like less that 1.0% of visitors read the article. Unless they can read a couple of thousand words in 20 seconds. Again, that was my fault.

But what was interesting was the responses to my article were pretty clearly divided into two main groups (disagreeing and flaming) and one small group (agreeing):

You are on crack, we do this stuff (automated testing, etc) better than anyone.
Game developers are moar awesome than normal developers and unit testing, agile and whatever else you are pushing doesn't apply to the game industry because of [one of]:

How can you unit test games anyway that doesn't even make sense!
Deadlines. We don't have time.
Games have hundreds of gigs of assets.
Console contracts / monetisation models etc.

I agree that the game industry suffers from some poor tool and process adoption habits.

Those who use these practices I've been talking about - and to keep things specific I think automated testing is an excellent candidate to focus the debate - these people generally didn't seem too upset with me. In fact I know plenty of game developers in this category.

Those who believe that their game studios are backward generally cannot speak publicly about ANYTHING with the only few exceptions being people who have left the industry, like munificent who says:

I worked at EA for eight years. My running joke-that-was-not-a-joke was that we were twenty years behind the times, but I was probably exaggerating. Fifteen is a pretty good estimate.
At EA, I think the problem was that the company culture was built like this:
A bunch of bedroom hackers in their teens started studios and shipped games ten to twenty years ago.

Those games got successful, and the studios scaled up. The founders hired young people under them.

More staff churn. Fresh grads come in, burned out experienced coders go out.

Munificent went on to qualify and contain his own statements as generalisations (as I did with mine).

Tool and process adoption in development teams is of particular interest to me and I have an ongoing conversation with several developers about the barriers to solving problems they have in this area.

As for the middle group, the question boils down to this:

If automated testing is to some degree not suited to the game industry, then why?

If the answers are things like "How could you test Starcraft 1?" or "You can't test for things like game balance" then I'm sorry that's not a convincing reason! How is it obviously impossible to automatically test Starcraft? I'm sure game developers heavily using automated testing (perhaps even Blizzard) will call bullshit and say "yes you can automatically test it".

You Can't Write a Test for X

I've seen so many of these debates and had them myself since the 90s and I've come to believe slowly by being convinced on a case by case basis that you can test the vast majority of what you think you can't test. I've learned this working in a number of different software projects in different industries.

If the answer is the cost benefit trade-offs on this project lead us to conclude it's not worth doing here and there then that's interesting. I'm looking for examples because it may well be a tooling problem.

I'm not saying that everything can be tested automatically, and perhaps the up-front cost of writing the tests is never outweighed by the benefits of having the tests because of game industry specific business features or whatever, but I think many of those things are currently subject to rapid change.

Game Revenue

WOW is a good case study. This is the sort of game that couldn't be funded 15 years ago. It plays similarly to the MUDs of the early 90s with a lot better graphics etc. but the market was too small for such a grand vision then. We were on 14.4k modems (or worse) and the number of internet users was tiny. WOW has recurring revenue. This is a feature unlike traditional games but not unlike traditional and modern non-game software.

With ongoing revenue you can fund ongoing development in a more continuous way. Updates can be done more frequently and codebases are encouraged to have longer lifespans. Longer lifespan codebases mean legacy code. There's nothing to encourage you to invest more in automated testing like having to maintain legacy code!

I think these are important factors, driven by the modern consumer internet and the market forces that come from it. These forces push game code towards a scenario where automated testing has a bigger benefit.

That doesn't address the cost side. You might think that the costs of automated testing, particularly unit testing, are fixed. Well in my experience of unit testing for the past 12+ years, the biggest barrier to automated testing is bad design. Here's what munificent (who has since moved on to Google) had to say about that:

Unit testing would be awesome, but the thing is... you need units for that. A lot of the game codebases I've seen are closer to "giant hairball" than "collection of components", which isn't amenable to unit testing.

When I was writing software in the 90s and 80s I never wrote automated tests. I thought testing had to be manual and had to be done when the system was "finished". I don't think that any more. When someone tells me that they have to test that way I ask why and I think I'm right to be suspicious of weak, vague answers.

Are Game Developers 15 Years Behind The Rest of Us?

2011-04-05T09:56:00.001+10:00

Game developers have a reputation, deserved or not, of being a nasty unwashed rabble with no process, no discipline and no skills outside of graphics performance and playing video games. They shoot from the hip, stay up all night and cut corners to hit the ship date, just like all developers, but they commit these sins to a much greater degree than the average developer, or so it goes.

It seems much more common that games developers, as opposed to non-game developers will not have automated unit testing and measure code coverage, adopt agile processes, use proper source code management systems, have proper backups (!), do code reviews, track bugs and do continuous integration.

Obviously, there are going to be game developers who do follow these engineering practices, but a reputation is a form of stereotype.

So I'm wondering how much truth there is in this or if it's a total myth.

Are game developers really less skilled in the big picture of software development? Are they really 15 years behind the rest of the industry on common best practices? Do their knuckles really drag on the ground? And if so, why?

I'm no expert in game development but I've always been very interested in it. My observation of a number of game projects and my contact with several game developers suggests there are a number of factors that could contribute to the possibility that game developers do not follow many of these practices.

Games Projects Are Not Like Other Software?

It seems true that game projects are usually dominated by a media production workflow. Like CG movies, modern AAA megabudget console titles have teams of artists who churn out gigabytes of high quality graphics and other media. The game project's process and its project management is totally dominated by the needs of this media production. Game project managers are quite often called "producers", the companies that make games often call themselves "studios" and, like movies and music, there are "publishers" who handle distribution and marketing. Funding models for many game studios likewise seem to follow the movie industry.

Interestingly, indie developers react strongly against this model of game development and argue that better games are the true goal, not bigger budgets.

By contrast, a multi-million dollar non-game software project will have a team where visual design work, including "UX" (user experience) design, often takes up less than 10% of total resources. By contrast, software developers and possibly business analysts (the equivalent of a game designer) will represent the majority. Obviously there is huge variation here, but the contrast is clear.

The basic idea behind this factor is that the division of labour on the project tips the scales towards a different set of best practices. Ones that are, arguably, better for making the cost-benefit tradeoffs and managing the risks of those projects.

Game Developers Don't Know Better?

I've been told that game developers mostly started in their bedroom and their skills have not expanded very far due to lack of exposure. Nobody convinced them to use unit testing, so they don't do it. Game development tends to be a passion. I know lots of skilled developers outside of game development who started coding all night in their bedroom. But just like they no longer use BASIC or name their variables with expletives, they no longer code games. I'm describing myself too here, I started programming like this.

Another aspect to this is that a lot of self-professed game developers participating in online discussions about this stuff literally are kids in the bedroom!

This factor is not very convincing but it seems that the game development sector is separated from other software development and the rule of passion is enforced in game development companies in both directions. Game developers feel strongly that they would never want to work on other projects and game development companies have a strong policy of only hiring people who have a passion for games. If this were true for Insurance companies, they'd never find candidates. People don't get passionate about insurance. Part of the truth of this factor may be that the segregation of game developers is so strongly self-policing.

With some exceptions, there are still not many game development courses run by universities, whereas the materials in the general software engineering and computer science courses are often specifically tuned to non-game industry problems. Think of the number of examples in programming tutorials about e-commerce or payroll!

This lack of tertiary education might not be such a big deal, except the game developers I've spoken to think that it is. They believe that game development is a speciality that needs special courses. Managing the media pipeline mentioned above is often cited as a part of this. As are the fast-moving hardware technology advances such as GPU architectures and the iPhone-style app-store project publishing aspects of the game industry. Business IT courses are only gradually starting to touch on this.

Games Don't Ship Upgrades?

Traditionally, games are shipped in their final state.

Back in the olden days people bought physical media in a physical retail outlet. I'm only partially joking here, clearly that method is quickly disappearing and luminaries like John Carmack have predicted next-generation consoles to cater predominantly to online distribution. Games that require dozens of gigs of media have seemingly had no alternative but to rely on ever increasing optical media densities to ship their bits.

While most games these days seem to have upgrades that are made available online, these are universally free, contain bug fixes only and are staffed minimally. Games do not generally go through the same lifecycle as, say, Microsoft Office where a new version of the same software is released on a regular basis and customers usually pay to upgrade.

The effect of this is many of the practices in non-game software development that pay off only in the long term don't seem to be worth the trouble in the short term.

While this factor may have been true in the past it is becoming increasingly less convincing across the board. With the rapid growth of gaming segments such as MMOGs, casual games and mobile games on always-online devices like iOS and Android phones and tablets, I expect a greater proportion of games to get their revenue from long-running projects that include multiple upgrades or in-game purchases that fund continued development of the software.

When the software is under continual development, as is most pronounced in SaaS, the payoff for the investment in quality engineering practices becomes more obvious. Games that are developed without such practices, as with non-game projects, will often become bogged in technical debt or suffer disasters that severely impact the businesses behind them.

By contrast, those game development studios that adopt automated unit testing regimes and invest in infrastructure like modern version control systems (e.g. Git, Mercurial) and Continuous Integration (CI) not to mention bug tracking and potentially things like code review, have a potential competitive advantage that can lower the cost of development over time.

Games Can't Be Unit Tested?

I've heard several game developers, state that game development is different in a technical sense such that unit testing (and other related engineering practices) are not suited to game systems. While, when pressed, these people will concede that certain parts of game development are like any other software in their suitedness to unit testing etc. they argue that there is a fundamental mismatch.

To be frank I find this argument to be just as weak as it is in non-game development projects. I'm not saying there is nothing that can't be unit tested because that's not even the question. The question is whether the effort spent on unit testing is outweighed by benefits derived. The trouble is that the vast majority of "things that can't be unit tested" that I have been shown over the years are really just design problems in the code that only become apparent when a unit test is attempted. Making a small change to the production code fixes this problem. For those developers (both inside and outside game development) who have never gained the benefit of a good regression test suite, the idea of changing the production code to make it easier to test sounds like pure madness.

Of course it's not pure madness, it's just the scientific method.

Game Projects Are Too Hardcore For That Crap

I've heard this one from game developers who, let's just say, do their bit to perpetuate the stereotype of the macho code-all-night-eating-pizza-guzzling-caffeine-optimising-the-engine dude. All nighters are not generally seen as sustainable by most enlightened teams I've worked with and whenever it's done it's seen as fail. Fail happens. Heroic efforts are sometimes necessary. And if you feel that the burn out that results is a badge of honour then it can be kind of fun. It's like the pride an extreme sports junkie has of their broken limbs and sick x-rays. We all know this is true because most of us have been there.

Like a "breakdancing battle" I remember many schoolyard bragging sessions about how many sprites I could animate on screen at once. My friends challenged me to make more impressive graphics than them and I relished the challenge. I believed in my ultimate mental power over the machine. I felt invincible and omnipotent in my coding. And when I look back on the code I wrote then I can barely read it.

Perhaps it's optimal and can't be improved. Only half of that is certain. It can't be changed at all. I'd rather disassemble a binary than read my own teenage source code.

But while it may or may not be fun, it's not sustainable or profitable, except in very narrow windows of opportunity.

To some game developers, game development is like going to war. You have to be tough like a soldier and all the props and niceties of civilian life (unit testing, source control) are luxuries you don't get on the battlefield of a game project. There's no time. There's too much chaos and that goes with the territory. Game projects necessarily have grueling schedules because they must to survive. It's a tough market and if you're not prepared to wade through the swamp in combat boots and 30kg packs then you're not cut out for game development and you should go back to the unicorn and rainbow world of civilian development because you are soft.

I think these guys (invariably this is a guy thing) are delusional. They're living in their own game world.

This sort of attitude will convince starry-eyed coder kids of who has the most chest hair, but it seems to blind some game developers to the simple fact that games are made of the same material as all software: source code. Software practices are solutions to a common problem: a faster stream of features with an acceptable level of performance and an acceptable defect density, not to mention making the right direction and priority decisions.

In the past I would have been more convinced by arguments about the absolute need in games for hyper-performant code and crazy schedules but these days I think those things are less true. As with non-game development before it, the necessity of maximal performance is becoming a marginal one, suited to fewer projects less of the time. Games used to win success on technology and now this happens less than ever.

The online games markets, especially so-called "casual games" have grown phenomenally in recent years such that established games companies are taking notice of new generation companies that understand the importance of community, longevity, and viral distribution channels like facebook.

I think we'll see more legacy game code.

All of this suggests that the majority of game companies are less and less like the mega hit tech-driven games of the past few decades and a larger part of the growing gaming market is in projects that could easily benefit from decent software development practices. Maintainable code, automated test coverage etc.

Small Projects?

There are a lot of small software projects in the games industry. Small iPhone projects probably don't have enough bugs to warrant industrial strength bug tracking, especially when the whole team is sitting around one table and the duration of the project is less than 6 weeks.

Several of the engineering practices I've mentioned seem to better suit larger teams and projects, releasing versions on a regular basis. Small projects that aren't like this arguably find benefits of these practices are reduced.

Absolutely I consider this to be a relevant factor for code review and sophisticated bug tracking, but I think more of the reason for small game projects not having source control or unit testing are questionable.

Flash, for example, very popular for online games, strikes me as one of the worst platforms to integrate source control and unit testing into. I've done some flash programming and I just gave up and went with the flow. No unit tests and no source control.

I survived.

However if I was going to write games in Flash on an ongoing basis, I would find the flashunit framework I'm sure exists, and if it doesn't I would build it. I'm vaguely aware of methods in Flash and ActionScript to solve source control issues like merging and you can bet that I would prioritise getting that stuff working. If I had a team working on a MMOG in Flash, I would make sure I put in a Continuous Integration engine, probably Bamboo and not just because I work for Atlassian. After saving my arse several times I'm convinced these tools and practices are worth the trouble to set up. Hopefully my fellow game developer team mates would not be resistant.

What Do You Think?

I'm not presenting this stuff about game developers as fact, and I'm making a lot of generalisations, a lot of assumptions. I'm not trying to insult any game developers, in fact I'm interested in learning more about game development, especially on the tooling, process and architecture side.

Am I being unfair? Am I out of date? Am I wrong?

Feedback, flames and factual corrections are most welcome.

Guy Steele Disassembles 40 Year Old Punchcard

2010-12-07T15:01:00.000+11:00

Just a quick note to let all of you know who are not currently at the YOW! 2010 conference, some of the fun that you're missing out on.

Firstly it must be said that this is a world-class conference. The calibre of speakers is amazing. Dave Thomas and his team have done an incredible job of drawing this talent to Australia for this meeting of minds. I'll be posting more about this stuff later, but for now, here's a teaser photo from one of my favourite sessions, Guy Steele's "How to Think about Parallel Programming--Not!

In this photo, Guy is disassembling his own 40 year old self-modifing code, starting with a punch card and an old manual (which he admitted to still owning). He demonstrates his deserved bare-metal hacker street cred. Then half-way through the talk he shifts gears into real parallel programming in Fortress. I was quite exhausted after that one!

Computer Science Is All About Windows 7 For Dummies

2010-08-24T10:51:00.000+10:00

Next Android OS Codename: Apple Pie

2010-08-23T11:48:00.000+10:00

cc photo by http://www.flickr.com/photos/mattmendoza

OMG Google has to do this.

With the Android OS versions getting code names like cupcake, éclair and froyo (which is, evidently, a word), the dessert namespace provides an opportunity too good to miss. Apple Pie. OM NOM NOM.

Of course the logo should be a white stylised piece of apple pie with one bite out of it. Or perhaps a rainbow version?

People, Google fanboys and Apple haters mostly, desperately want Android to DUHSHTROY iPhone in the market. Personally I don't think this is very likely. I know there are a lot of Android devices out now - more than iPhone I hear - but the fragmentation is really starting to happen. Just like MSX.

The code name of Apple Pie would trump the Eclipse Foundation's latest IDE version naming stunt, Helios, Ancient Greek for Sun, aka their competitor recently bought by Oracle who is now suing.. Google. Keeping up?

Why Bookshops Always Put Computer Books With Business

2010-08-20T15:06:00.001+10:00

It's near-universal. Especially for those bookshops with large self-help or mysticism and occult sections and no science section. Computer books are put (and often intermingled with) business books.

Why?

To me it's like always putting cycling with business. Or painting.

Yes computers are used heavily in business, but they're used just as heavily in music or movies or writing.

When I look for programming books, sometimes I'm interested in the topics that combine businesses (or the needs of an organisation) with programming - generally topics like how to translate the needs of project sponsors into deliverable systems. But way more often than that I'm interested in topics that concern the creation of software using specific techniques, paradigms, or languages and frameworks.

I like programming. I would do it more on the weekends if I had time. I don't think it has anything in common with business but it seems that many non-technically minded people assume that the only reason someone would want to do programming is for business purposes.

Well plenty of people do it for fun. Just like cycling or painting.

Posted via email from chris mountford

Apple: I Was Wrong, Here's Your $200 Back

2010-07-05T21:03:00.000+10:00

Previously on Chris Mountford's blog...

Genius: "Oh um ya that battery that split open like a stepped-on-banana.. that's expected behaviour"
Me: "You're kidding me? Should I expecting all other Apple products to do this?

The latest is, thanks to Mr Anonymous, Paul M and legion others like them, is that I have been refunded my $200 because, as a reasonable person would assume, the extended warranty DOES cover such explosive situations.

Exploding Macbook Pro Battery = "Expected Behaviour"

2010-06-28T21:30:00.000+10:00

After booking my appointment with a Genius at the Genius Bar in Sydney's city Apple Store, waiting in line dutifully holding my AppleCare extended warranty stuff, packing what I thought would be an iron-clad case of Exploding Battery Obviously Defective Here's A New One Sir, I was rudely awoken by the facts.

Apple's official position, according to the lips of two courteous Genii, is that exploding is "expected behaviour". The battery was bought with the computer in June 2008 (exactly 2 years ago) and it had been sitting for a couple of months looking like this before I got around to taking it in:

Well it's not behaviour I ever expected. And I say this with some experience with batteries, even lithium ion rechargeable batteries, that ranges roughly two fashionable Genius lifespans or near enough, judging by their fresh-faced appearance. I've never had anything like this.

I think the elephant in the room is that while the fine print may say that the extended warranty doesn't cover batteries, this is a major manufacturing defect and Apple know it. I was virtually told as much as I was assured my 1 year old Macbook Pro with the built-in battery would not suffer the same fate since it is a non-nickel based lithium polymer construction. I was invited to attend the Apple battery page: http://www.apple.com/batteries/ which keen observers will note contains nothing of Apple's expectation of explosions.

Looking further the Apple battery replacement page says:

However the AppleCare Protection Plan for notebook computers does not cover batteries that have failed or are exhibiting diminished capacity except when the failure or diminished capacity is the result of a manufacturing defect.

Right so, who says this is not a manufacturing defect? Shouldn't a manufacturer's expectations about common failure cases be published on thier main information page? If it really is not a manufacturing defect where is the information about this expected behaviour on their written material?

The battery still holds a charge as demonstrated by the indicator lights on the battery. Also, although it doesn't properly fit the case due to it's unsightly bulge, it was powering the laptop fine until I took it out. In fact the reason I did so was because the bulge was pushing the back of the mouse button, preventing it from clicking. None of this stuff appeared to be news to the Geniuses. Just another exploding battery.

So $199 later, I purchase a new battery which, I carefully confirmed, would be expected to explode in roughly 300 power cycles (which I assured the young Genius my existing battery had not experienced).

Has anyone else had luck in getting their battery replaced as a part of Apple extended warranty? I see plenty of talk to this end:

http://www.appledefects.com/?cat=27
http://discussions.apple.com/thread.jspa?threadID=909217
http://www.tuaw.com/2006/12/25/battle-of-the-battery-bulge/

Aussie Censorship Error

2010-03-16T16:23:00.003+11:00

As a father of three young kids the thought of child porn disgusts me.

If only an Internet filter imposed by the government would be effective against it.

As a professional software engineer I can't help but acknowledge that the proposed filter will be 100% ineffective at stopping child pornography and that hundreds of millions of dollars could be better spent elsewhere.

The proposed censorship by senator Steven Conroy does not propose to stop most material that is unsuitable for children and it does not propose to stop the most common channels of illegal content on the Internet (bit torrents).

Finally any VPN will effectively go straight through the filter so anyone who wishes to can circumvent it using current technology.

Titanium Reinforced Self

2010-03-15T22:33:00.003+11:00

For those of you I know personally, you've probably already seen my impressive X-rays, but for the rest of you I'm announcing that I have recently had cause to become hyper human.

Not content with collar bones constructed of mere bone matter, which I ably demonstrated can break with the aid of a single mountain bike and a spot of bad luck, I opted for hyper human augmentation.

I can wholeheartedly recommend the procedure should you be advised that it's necessary for adequate bone knitting. It completely stopped the disconcerting clunk that occurred in my shoulder on certain movements for the 36 hours prior to surgery.

The only down side was, apart from the usual recovery and healing process, I discovered much to my surprise, morphine is quite disgusting. It certainly blankets almost all pain but at the expense of almost all cognitive ability.

Further, morphine causes the sensation of hanging upside down in a vat of warm butter after having skulled a salmon milkshake. With an automated IV drip, that feeling was only a button press away should I become convinced that it was better than post op pain.

Now I'm back on the bike but my shoulder does not have 100% strength or mobility and my muscles feel wasted and weak all over. So if you happen to pass me on a hill, this is going to be my standing excuse.

More Cowbell in One Line of Groovy

2010-03-09T14:12:00.003+11:00

Sometimes you just need more cowbell.

It is for those times that I wrote this:

groovy -e 's=javax.sound.midi.MidiSystem.synthesizer;s.open();c=s.channels[9];c.noteOn 56,99;Thread.sleep 99;c.noteOff 96;s.close()'

I do often find myself needing more cowbell, such as when invoking a maven comannd which inevitably downloads the internet, like mvn clean. So get this puppy on your PATH and you can do this:

mvn clean && cowbell

...for an audio cue that tells you the internet has been successfully downloaded with a modicum of funk.

Ali G Joins Github Team

2010-02-20T20:11:00.003+11:00

I was browsing a Github hosted project, Mangos recently and attempted to check out the network graph visualisation of the clones of this open source World of Warcraft server.

Moments later I learned that there are too many branches on the graph for the flash visualisation to render. The following error message is shown:

Sorry, this repository's graph is currently too logical awesome to display. We're working on optimizing it. Check back soon.

Which leaves one wondering just how much is the right amount of logical awesome.

Clearly the only conclusion is that the Github team has been joined by a celebrity error message writer, Ali G:

Booyakasha!

A Tale of Three Buzzes

2010-02-11T11:47:00.004+11:00

Google's Buzz is causing a stink. It's the third social network which is called "Buzz" to come out recently. All have the Twitter model of microblogging (or multicast chat) with an asymmetric social graph (people decide who they follow but not who follows them).

Yahoo Buzz has been out for at least a year on buzz.yahoo.com and predicatably, Yahoo and their new overlords Microsoft are going batshit insane about this.

Oh really Microsoft? You've got a product and a bigger competitor comes along and uses your idea? And they use the generic term to name it? That must be annoying. The worm has turned.

And the drones at AT&T launched buzz.com about 6 months ago. Less said about that the better. In fact you can probably safely forget them right now.

So now we'll all be looking forward to the shakedown. There are too many players.

I think the winner will be the service that provides enough features (not necessarily the most, Facebook) with the best integration with everything else. Twitter so far has been successful at crowdsourcing the integration work with the massive proliferation of Twitter clients and "tweet this" buttons like Tweetmeme. Can Yahoo/Microsoft get this traction?

Google already has a great integration story. When the hundreds of millions of monthly GMail users hit their inbox now, they will be able to thread together lots of their google software that produces socialisable events. Now the google suite can buzz.

Perhaps it's just me but the one image I have about Buzz is those hotted up cars with the ultra-loud stereo systems and the monsterous bass frequencies causing every bolt in the chassis to loosen and the number plate to buzz.

China Hackers Update: Arrests and Details

2010-02-09T22:47:00.006+11:00

It is inevitable after the Google hacks, as they are known, that China responds by showing its international business partners that they do not condone hacking.

China Daily reports that the biggest hacker training site has been shut down. via RWW

"I could download trojan programs from the site which allowed me to control other people's computers. I did this just for fun but I also know that many other members could make a fortune by attacking other people's accounts," said a 23-year-old member of Black Hawk Safety Net in Nanjing of East China's Jiangsu province, who asked to remain anonymous.

and

They seized nine Web servers, five computers and one car, and shut down all the sites involved in the case, according to the provincial public security department.

So there you go Google - nothing to worry about. The "provincial public security department" got the baddies. Carry on.

Of course there's no reported link with what is now clearly a much larger and more sophisticated program of industrial espionage than previously thought as reported in detail by wired magazine.

The salient points of the wired article are:

The hacks have compromised thousands of companies, not just 37 as previously reported.
Most of the compromises are currently still active and law enforcement has been contacting companies to let them know they have been compromised.
The exploit was an IE 6 security flaw that was first reported to Microsoft by an Israeli researcher in September 2009 but which remained unpatched for months. ("0-day")
The attack profile include multiple-year-long occupation of companies' computer systems and typically involved hidden siphoning of large amounts of private data including email, documents, etc. This is in contrast to the smash and grab techniques more common in the past.
Existing security software (like antivirus software) is not able to detect this attack profile or the malware used to initiate it.
The full extent of data theft will never be known.
The goal of the attacks appears to be coroporate and national espionage.
The hackers have levelled up.
The trail goes dead in Taiwan where the data was siphoned to and China where the spear phishing attacks were initiated from.

Now it really feels like we're living in a Neal Stephenson novel.

Build to Flip vs Organic Growth

2009-12-10T20:36:00.004+11:00

In this world of GFC hell (is it over yet?) the biz buzz is "Organic Growth". That is to say business owners who are looking forward to the challenge of entrepreneurship in a downturn are standing as proud adovocates for a refreshing change to the mentality of the bubble and the zero profit, high valuation world of two point oh dot coms.

It's refreshing because the business press is usually obsessed with the crazy valuations. A sale price with more zeros means more heroes. Examples abound. Twitter's recent funding round reportedly topped $100,000,000. That would be nine zeros. Profit is currently just zero. You'd think by now they could afford to give us more than 140 characters.

Clearly people building businesses the traditional way, you know, charging a price (stay with me) for a product or service and growing revenues slowly over years, those people feel some justification in presenting themselves as a sane alternative to a world gone mad. Atlassian CEO Mike Cannon-Brookes has ranted exactly this in the past.

With financial systems in the toilet due to excessive valuation of flaky assets, this can seem justified as much as ever. Indeed my own aspirations for a new business incorporate this sane model of organic growth. I know it could take longer.

It seems that the venture capital (VC) funded model of startups popular in silicon valley are stuck in railway thinking. VCs think that if it isn't something they can put many millions in and get hundreds of millions out, it's "not interesting". And of course more is always more.

As a tech guy, I think the prospect of growing a business up from nothing seems plenty interesting. But if I had taken millions of someone else's money to start the company, well the reality is I'd have already sold the company. A chunk of it. I'd have borrowed money and would need to pay it back. How would I pay back the millions with extra zeroes on the end? I would have to sell out big. This is the railway. Once you get on it you don't get to choose where to go. You only get to choose when to get off, assuming you don't run out of steam. And VCs don't want you crawling down the track. They are looking ahead to their exit impatiently. They want their money to fuel the train as fast as possible. Destination "liquidity event".

On the other hand, is it really a problem if people want to start a business with someone else's money and sell it in a couple of years? What's wrong with build to flip?

I think the real problem here is cultural. If kids these days aspire to be like Kevin Rose, founder of Digg, or want to build the next Facebook or Twitter or even Mint (just bought by competitor Quicken for $170M), they may well be building with a mind to sell out in the short term. I don't think this short term thinking will build the next generation of great companies. It wasn't the kind of thinking that built Apple or Microsoft or even Google. These companies have really made their mark and changed the world, hopefully for better, but they're clearly more than an expensive flash in the pan. Even Bill Gates has become quite the philanthropist.

The parallels of build to flip with the the Underpants Gnomes are too stark to ignore. Can't remember step two.. never you mind about step two. Step three is profit. I suspect it's only this pesky string of recent bank collapses that has put a dampener on the craze of Underpants Gnomes business models. If the GFC hadn't happened first I think the startup upstarts might well all have bubble gum on their faces by now.

Jason Fried on Less is More

2009-11-17T11:28:00.003+11:00

I'm a fan of Jason Fried, the 37 Signals founder who sticks to his guns and stands up for simplicity in software design. I like how he's a dissenting voice and clearly has the courage of his convictions. I like how he promotes what VCs disparagingly call "lifestyle businesses". I'm happy that he's been featured on INC, a major US business magazine, even though I'm not enough of a fan to care what kind of tea he drinks and all that.

I'm a fan of Less is More. This year I have been exploring the surprising depth and complexity of this oft-quoted pithy aphorism. Jason Fried is a Less is More poster boy. Except he doesn't like the phrase. I've read it from him elsewhere, but the INC magazine feature reminded me.

If he didn't like less is more because it was overused and therefore overlooked, I would completely understand. But that's not his objection. He says that he doesn't like Less is More because it implies that More is better. Ridiculous!

Actually I worked with a guy who straight-out didn't understand the phrase. In one of his customary rants about inconsequential stuff he confided that he thought Less is More was vacuous and clearly irrational. "More is more and less is less!" he said.

First of all, I think it's obvious why it has a deliberate and prominent paradox. The semantic collision is a key feature of its beauty. Less is More works so well because it identifies the conflict of competing values in a compact and humourous way.

Less [of one thing] is more [of another].

There is an unspoken contex shift in the middle.

So to object to the phrase because it implies that More is better is to misunderstand it on the most flimsy semantic level. Less is better because it is "more good". To advocate Less you must refer to its superiority. Inherent in every word to describe "better" is the notion of "more". It's just words!

So to properly appreciate how well Less is More applies to Jason Fried's own philosophy of software design, you see that (arguably) less features enables something. Something is gained in their place. There is more of something.

Understanding what the two sides of the see-saw are is the critical (dare I say pivotal?) task of applying the less is more wisdom to a given situation. What exactly is the tradeoff being made? This is how I use Less is More in my software development and also in my life.

The opportune moments for the wisdom of Less is More are more specific than just identifying competing goals. It represents minimalism. It's not just less pizza is more beer. It advocates a fresh look at what is essential and rejects overconsumption, overburdening, hoarding and powermongering. It represents a philosophy of happiness and a wholistic goal rather than the pointless pursuit of intermediate tokens that we first world people frequently use as proxies for real goals.

Less is more is a tool for escaping from the distraction of things that are merely a means to an end and resets attention on the end itself.

There are usually hidden tradeoffs in software design and the business of programming. The 80/20 rule (the Pareto Principle) is essentially a variant of this where the see-saw becomes a lever and therefore provides (hold your nose) leverage.

Complexity is befuddling. Complexity in software actually prevents people from getting their work done and often inhibits progress towards their goal. For all it's enabling potential, complex software has an opportunity cost. When I was a kid, I had the justified belief that I could learn any application in one sitting. Those days are long gone. There's a great power to that. Jason Fried seems to be a voice in support of this idea.

I'd like to write more on Less is More. I think the irony is stopping me for now.

Smart Programmers Who Don't Get Patterns

2009-10-06T22:32:00.004+11:00

I've been recently struck by the relatively large amount of ignorance about software design patterns amongst the pundits and seemingly intelligent "thought leaders" of the sofware development blogosphere. Actually it's not all that recent.

Sure, I expect newbies and unscreened job applicants to fail to understand the point of design patterns, but to me they've always been one of the things all good developers should understand.

First, I don't think the problem is the definition. I'm not squabbling about this. People get this mostly right. A design pattern is a form of solution to a known problem. They originate from Christopher Alexander's work in Architecture where examples include the "Ante Room" or "Roof Garden". The idea is that a pattern describes a general solution to an open range of problems. Architects might consider adding a "Roof Garden" when they are faced with forces and constraints in a design project where the Roof Garden can help achieve the design goals.

Thanks to the work of many OO pioneers, but most famously the Gang of Four via their seminal book, Design Patterns, the software world has adopted design patterns as a technique for storing and disseminating software design wisdom.

But why?

This is where many otherwise well-trained and intelligent software developers fall down. They think that the point of design patterns is component reuse. They think that, like building blocks, design patterns are prefab parts you can stick together, thereby doing less work or using less attention. And once this mistake is made, their rejection of this dumbing down of attentive design in place of convenience is understandable.

But they have missed the point.

The whole point of design patterns is to enable communication about design. Design patterns are an attempt to standardise a vocabulary for solutions. Design is frequently a collaborative effort, and even when it's not, a design concept often needs to be communicated either verbally or in written form. Learning about system design also relies on a standardised language.

So a design pattern usually has a kind of specification which includes a stable name and possible aliases, description and suitable use situations. Developers who have used this pattern can then use the name instead of some long-winded boxes-and-lines session at the whiteboard.

Now for some examples of seemingly intelligent and experienced software developers speaking out against design patterns.

Some years ago Paul Graham and others argued that Design Patterns suggested a violation of the DRY principle and that they always indicated a smell that the program required refactoring to remove duplication or that the language was not powerful enough to factor out the duplication. While this could in theory be true, only Lisp developers are in danger of suggesting that their language is perfect, so for the rest of us (statistically speaking, everyone), perhaps there is enough complexity and subtlety in our domain that we find ourselves able to recognise solution forms that we can name and talk about, and yet not implement generically.

I take his point, but I think for most people it's a principled rather than a very practical one. The reality is that we live with imperfections in everything, so even if design patterns only exist to cope with this imperfection, then they will still have a seemingly permanent role.

The point that different languages have different patterns, some more than others, is well documented, and really orthogonal to the issue at hand - namely that design patterns are useful primarily for collaboration and communication. Even programming language designers use design patterns. All (impefect) programming languages, like all software, are knowingly designed to contain a subset of all possible features. Don't forget simplicity is a very valuable feature. Apparently Ralph Johnson, one of the Gang of Four, pointing this out did little to calm the hysteria on an argument that design patterns formed a list of language features that should be implemented.

Zed Shaw, Ruby on Rails agitator and apparent chronic self-congratulator warns developers in his keynote entitled "Why Keynotes Suck" which was (with what one must assume is deliberate irony) literally read off an irc channel:

"Stop using patterns. No really, quit using patterns, they aren't helping. I have evidence on that by the way, which is later"

I didn't catch the evidence but later he did say:

"Adapter, Bridge and Connector are the same"

And then

"Patterns suck, use algorithms."

The idea of patterns "not helping" conjures images of these dead zones in the code where there is a pattern just taking up space and not actually providing functionality. Should I go and delete all the patterns from my code? What would pattern-free code look like? Do they just suck because there are aliases? Plenty of algorithms have multiple names. What makes algorithms ok? Is Zed just trying to sound old school?

To be fair, during this talk his main point was to encourage individual thinking and not to follow advice blindly (including his own) but I do get the impression that his idea of patterns has come from the blind cookie-cutter adoption of patterns with small amounts of bad glue code holding the "architecture" together. We've all seen it.

A recent example is from a video interview with Stuart Halloway author of "Programming Clojure" and a series of articles about post-java jvm languages. When explaining the advantages of macros, Stuart basically repeats Paul Graham, saying,

"Languages that have macros don't really have design patterns".

Perhaps because he thinks a design pattern is when:

"I couldn't really figure out how to solve this in a resuable way, so whenever I hit this problem I copy and paste from somewhere else and tweak. So it's amazing that design patterns has put a positive spin on this copy and paste reuse of these blocks of code".

I'm not an expert on functional languages with macros, but Peter Norvig is. Even this mighty Lisp and AI guru identifies design patterns in such languages though he does say that 16 of 23 patterns are either invisible or simpler due to language features like macros, first class functions and multimethods. Stuart may be overstating it - I think what he is talking about is a more populist use of the canonical GOF design patterns and similar OO patterns.

The dread curse of this misunderstanding about patterns seems to have arisen from the usual cause of all technology's ills: marketing. I distinctly recall a Compuware salesman give a bone dry presentation to a local Java user group in about 2000 demonstrating how you could avoid programming almost completely by dragging and dropping patterns from a palette onto a ... thing on the screen. Clearly not targeted to a group of programmers so geeky that they want to get together after hours and talk about the joys of programming. Similarly books about something called "pattern oriented architecture" began to appear and patterns was something to put on the resume.

What these people need to understand is that design patterns will continue to be useful and to have a role because they are one level of abstraction above implementation. They are needed to explain solutions in terms of a programming language but they cannot be replaced by the language. They are softer than software.

My Code Sux!

2009-08-27T10:12:00.002+10:00

I don't know about you, but when I look at code I wrote three years ago, I always seem to think it sux.

And that's a good thing.

If the code you wrote three years ago doesn't suck then you're not learning.