Coding Super-Complexity

Young, intelligent developers often fail when they become accustomed to the following two things:

• being 10x smarter than everyone around them; and
• fitting all the code in their head 

When they join a team where everyone else is pretty smart - even if not quite as smart - they can still fail hard.

They are like younger, stronger kung-fu warriors that yet cannot best the wizened master!

The problem is that while they may be able to solve problems that are 10x more complex than other developers, this is only true when limited to a practice which requires one to remember and understand everything about the system under development. Note that this is typical experience in hobby projects and many university projects.

I think software engineering, definitively, focuses on solving problems which require software to be built that is generally much larger than anyone can fit in their head. 

In some ways intelligence can be a curse because it delays the lesson that systemic practices and superior tools (languages, architecture, frameworks) are necessary. Here I identify tools and techniques as superior primarily by their ability to massively magnify the effectiveness of our ability to deal with complexity. To tame it. To contain it.

Isolation, abstraction, automation - these things all help pump complexity out of the brain and into the software. It's true these systems can fail. Machines can fail and all software has bugs. But it's also true that we can often rely on them and that refusing to rely on them is a severe limitation and in some people who never learn this, even a personality defect!

Open Source Needs Copyright

Copyright is not very well understood by many people. Open source likewise. Recently a friend of mine asked me to explain my statement that Open Source Software critically relies on copyright. I think there is a sense in the population outside of software development (and perhaps outside intellectual property law) that open source is an alternative or distinction to copyright.

In fact the opposite is true.

Open source software is protected by copyright. If it were not, then any company could co-opt it and make it their own. Depending on the license, “free software” which is a distinction frequently (and some would say tediously) insisted upon by open source leading lights like the inimitable Richard Stallman, this software may impose a restriction on the rules by which reproduction or distribution of the software may be done - including modified versions of the software.

This free software is freedom-enhanced or freedom-protecting. That's free as in speech, not free as in beer.

The famous GPL (GNU Public License) is like this - some say it is “viral”. If you or any company makes a product which is the result of modifying open source code which is licensed under the GPL, then the modifications you have made must not be published without the same affordances, indeed not without the same exact license. Notably this requires you to provide access to the the full source code without preventing anyone from further adding or modifying it.

Copyright law enables this because without such protections, software licenses would not be necessary. Failure to follow the terms of the license make one’s distribution of software a violation of copyright. Many companies have been busted because they have not followed the licenses and these days technology companies are familiar with meeting their obligations on this matter.

You may notice that most consumer electronic devices - computers, TVs etc. contain code (e.g. Linux), the license of which requires the manufacturer to tell you that you have the right to obtain the source code and that the manufacturer cannot deny you this right - nor can you deny anyone else the same rights should you decide to take that Samsung TV firmware and make a better version! Believe it or not, people do this sort of thing. You might get a bundle of open source licenses along with your equally impenetrable operation manual.

There are other licenses which are extremely permissive, such as the MIT license or the BSD license which do not place these viral restrictions on distributions. Some people believe this is more convenient, especially for software that is ideally suited to being incorporated in proprietary products as one of many components. However, just like GPL, whatever provisions the licenses do make - if these are the only terms under which the software is provided then they stick because copyright is an exclusive right to distribute unless it is explicitly assigned.

Lastly, copyright assignment is completely independent of the terms of a license. Typically copyright is held like title deeds and not given to users of the software. Exceptions are if the work is undertaken as "work for hire" where someone pays someone else to develop that software - typically copyright is assigned in exchange for the money - and another common case of copyright assignment is when an individual developer submits a modification to be included in an official open source project. Such open source projects (like Apache) have a foundation that exists to hold the copyright so that the stewardship of the software can be maintained without a messy consultation with hundreds of dispersed pseudonymous bedroom hackers who happened to have made a small contribution.

Show Me Numbers! Automated Browser Performance Testing

Here's my talk from AtlasCamp 2013, Atlassian's annual plugin developer conference held in Amsterdam.

My topic is Automated Browser Performance Testing.

JavaScript developers often talk about performance, always tweaking to make the user experience faster. The good developers carefully and accurately measure this performance in multiple browsers. The great developers automate this measurement.

In this talk I tell the full-stack story of the design and implementation of User Experience (UX) performance tests in JIRA. Learn techniques critical to improve not only actual performance, but also perceived performance - and when they are not the same thing!

Nice Syntax for Ignoring Exceptions in Groovy

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

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

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

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

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

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

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.

Guy Steele Disassembles 40 Year Old Punchcard

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

Next Android OS Codename: Apple Pie

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

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

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"

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

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

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

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

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!