Damian Brady's Blog

So I finally joined the dark side and I got myself an iPhone.

Now, if you’ve been following this blog for a while, you’ll know that often it’s the little things that interest me.  Small bits of functionality and the tiniest ideas sometimes make the biggest impression.

With that in mind, here are the top things that have impressed me about the iPhone.

1. UI during phone calls

When I’m on a call and I’m holding the phone up to my ear, there’s no need for the screen to be on… so it’s not.  If I take the phone away from my ear, the accelerometers in the phone notice this and I get a useable display again.

A tiny thing, but it shows that Apple is thinking.

2. Music in my car

I connect the iPhone to my car stereo using a standard 3.5mm headphone plug.  Great sound. It works perfectly. Not that impressive.

However when I get out of my car, I pull the cable out.  The music stops.  It could quite easily continue – there are speakers on the phone after all, but it’s smart enough to assume that having unplugged th speakers/headphones/whatever, I probably don’t want to listen to the music any more.

Again, it’s simple but intelligent.

3. Silent switch

My old phone was a Nokia E71 and I loved it.  It did everything I wanted it to, but I’m a sucker for stuff that’s nice to use (usually) so of course I wanted an iPhone.

One very slight annoyance I’ve had with every phone thus far (including the E71) is that to turn the phone to silent, it takes a few steps.  On the E71, you have to unlock it, press the power button at the top, scroll down to Silent, press the OK button, and lock the phone again.

On the iPhone, you flip the switch on the side.

4. Network connection switching

I’ve set up my iPhone with the details of my home wireless network and the network at my parents’ house.  I did each setup a grand total of once.

Now, whenever I’m at home or at Mum and Dad’s, any browsing I do uses those networks.  The phone never asks me, never checks to see whether I might actually want to pay for access, no.  It assumes I’ll want the fastest (and cheapest) connection available.

5. Application Installation

Hands down the cleanest installation for any software I’ve experienced.

Go to the app store and find something you want, touch the price button and then install, and you’re done.  There could be a couple of extra touches here and there and you might have to put a password in so your account gets charged too, but it’s incredibly easy.

It downloads in the background, there are no restarts, and you can immediately see it in your list of apps (“springboard” apparently).  Brilliant.

So that’s it – probably not the same list as anyone else, but like I said, it’s the small attention to detail that impresses me.

So my keyboard at work just broke.  Doesn’t happen often, but one of the keys just stopped y’know… putting it’s letter on the screen.

So I got given a replacement from somewhere.

Here’s the thing – the layout is different.  Any programmer or techie or otherwise-nerd will know what I mean when I say that it’s FREAKING ANNOYING!!

Now, there aren’t any big changes really.  I mean, all the letters are in the same place, and the F-keys are still above the keyboard and the number pad is the same, but there are enough differences to frustrate someone like me.

The Home-End-PgUp-PgDown-etc. chunk of keys is different.

This is what I used to have:

Here’s what I have now:

What that means is that I keep hitting Delete instead of End.  Because it’s right below Home now.

I only have one Windows key

And it’s on the left – the one I don’t go for when I’m locking my computer with Win-L as I stand up to go somewhere.

The F-keys are grouped in threes

Seriously, in threes?  F5 is by far the most common F-key I hit, and now it’s in the middle of a cluster instead of on the left.  I have to look at my keyboard now to hit it.

My right Ctrl key is slightly to the left of where it was

Not a big deal you’d think?  Well truthfully it doesn’t affect me much – I still usually hit it first go, but it’s been moved left to make way for the arrow keys.  So when I don’t hit Ctrl, I hit the left arrow key.  That’s confusing.

So you’re probably thinking, “Oh, you poor little baby! Would you like some cries with your waa-burger?”  And yes, yes I would.

Seriously, it’s frustrating.  I know it’s only temporary – I’ll get a new one soon with a normal key layout.  But my keyboard is by far the most frequently-used tool in my arsenal.  Small things like this slow me down.

Ok, I’m finished complaining now.  You can proceed with your day.

I’m positive I’ve ranted about maintaining legacy code before, but I going to do it again.  At least this time I’m just reading the code so I can understand it and rewrite it rather than having to apply more bandaids.

Oh yes, and I’ve jumped on the “Top X List!” bandwagon.  It’s cosy up here.  So in no particular order, here are my top 6 things I hate seeing in legacy code:

1. Comments and variable names that didn’t update with the code

Yes, the code changes as you write, I understand that.  But seriously, can you please update the comments to reflect what you’ve done?

It’s very confusing seeing TODO comments for things that have been done, or comments about things that should be considered before the code goes into production.  Or maybe there’s a variable called currentIndex which is now actually a string containing a key because the original programmer changed from an array to a dictionary.

These things sometimes take ages to work out.  For example, I recently spent several hours trying to figure out what was happening in a chunk of code.  Looking at the following line:

It turns out:

1. It was in fact implemented (and was very, very necessary)
2. The failedMessageList variable contained all messages, not just failed ones

So seriously, if you change your code – take a glance at the comments to see if they need changing too.

2. Poorly named files

I had to add this one in. Not because it’s a big problem very often, but because when it occurs, it can be really painful. It’s obviously frustrating when classes and variables are named badly, but if files are named badly it can be even worse.

Let’s say you’re reading through the code and find a line that instantiates a Person class. Unfortunately, there’s no Person.cs (or whatever language) file. After some searching, you find that the Person class definition is in Teacher.cs – a file that wasn’t renamed when the code changed.

Or perhaps you’re looking for the UI for the window titled, “Database Maintenance” and have to work out that it’s actually a class called Restoring which is found in a file called FrmBackRest.vb. Sadly, a true story.

3. Inconsistent ways of doing things

I don’t have a problem if you do something a different way than I do; that’s fine – we all have our preferences. I might prefer to write to the database with parameterized stored procedures that I’ve written myself, while you use an ORM and just call a Save() method on an object you’ve just updated. That’s fine – both work.

What I really don’t like, though, is when someone does both. Like, in one place they’re calling stored procedures, in another they’re building SQL queries on the fly, and in another they’re retrieving DataSets via queries, updating the values, and calling a Save() method.

Nothing screams I-just-hacked-this-together-without-a-plan as much as large inconsistencies like this.

4. Even legacy-er code in legacy code

Sometimes I’ll come across legacy code that makes it clear that the original developer came from an even older background and didn’t quite understand this new technology. As a .Net developer, the most common stuff I see is good old VB6 code in a .Net app.

I came across a Goto statement in a bit of .Net code the other day. Another true story. It was a few lines after “On Error Resume Next”.

5. Error handling that hides errors

This is pretty common, and unfortunately it’s really only something that gets noticed when you have a problem. While things are working perfectly (and you don’t care how it works), there’s no problem. As soon as there’s an error though, you can’t find any details about it because the error handling is crap.

For example:

The end result of this? Here are some examples:

1. The transmitter.SubmitMessage method throws an exception. It gets caught, written to an error log, and thrown again. Ok, that’s not too bad…
2. The result from the SubmitMessage method comes back invalid. We increment our error count, get the details of the problem, and throw an exception. Then, oh no! That exception gets caught immediately, and another incredibly generic “CONNECTION_ERROR” exception gets thrown – completely abandoning the information gathered. But wait, there’s more! That exception then gets caught and logged and the error count gets incremented again! Yay! A “CONNECTION_ERROR” occurred… no more information… and an incorrect error count…

See? Don’t do it. If you can’t test for proper failures (sometimes it’s very hard), at least think about what’s going to happen.

6. Unused tracts of code

This one comes back to updating everything relevant when you have to revisit your code. A lot of the legacy code I’ve seen has codepaths that can’t possibly be used, methods that are never called, and in some cases classes, modules, and even entire libraries that aren’t referenced.

A recent project even had two code files, Connection.cs and Connection2.cs – they had different class names (Connection and Connection2 predictably), but they had the same methods with different implementations. Connection.cs was never used.

If you have to traverse your way through hundreds of lines of poorly-written code, it can get very frustrating when you find that half of it isn’t even used. It’s even more frustrating when you’re trying to match the behaviour you’re seeing with the code you’re reading, only to find out that it’s actually a completely different near-duplicate that’s running instead.

And that’s it – my top 6 annoying legacy code things. Feel free to comment.

My last post talked about how I wasn’t getting anywhere with my project.  Well now I am.

I might have mentioned that I’m using php and while it’s pretty easy to do stuff, I sometimes feel uncomfortable with the looseness of it all.  If you’ve used php in addition to a “real” OO language, you’ll know what I mean.  Lots and lots of globally-accessible functions with no namespaces, duck-typing, all that sort of stuff.

So I’m following some better practices (as suggested by Jon in his comment on the last post).  Nothing is very groundbreaking and I’m sure most newer php projects use the same kind of things.  Anyway, here’s what I’m doing:

I’m using an ORM library to get from my database to my code and vice versa.  Specifically Doctrine.  I’m reasonably familiar how these things work having used NHibernate for .Net (a port of Java’s Hibernate), but I’ve been impressed with how easy it’s been this time.  I got Doctrine working beautifully for my spider-web of a MySql database inside an evening with no experience.  I’ll let you know how it works out in the long run.  And yes, MySql is the database right now but Doctrine allows it to change very easily as expected.

I’m using an MVC pattern so my code doesn’t get too mixed in with my UI.  Now I’m sure there are plenty of libraries and frameworks out there that would help me with this, but I’m rolling my own… if you can call it that.  I’m used to .Net’s code-behind method so I’m really just copying that to an extent.  Each php page will have an include at the top that references the code-behind.  The “code-behind” php file will set up all the data and will provide functions that can be called by the front one.  Simple, but it should be effective.

Finally, I’m using JQuery for UI prettiness.  I had a serious look at a lot of javascript libraries and JQuery came out on top for what I needed.

So that’s it.  That’s what I’m doing.  So far it’s all fitting together quite nicely, but I’ll be sure to post updates if I want to rave about something or if something sends me into a fit of frustration.

As always, comments are welcome.

Damian

So I have this project that I’m doing for my own interest and I constantly find myself getting nowhere with it.  I’ve done plenty of design work and I have my schemas and stories sketched all over the pages of a notebook, but there’s nothing really tangible electronically yet.

The most common excuse I give myself is lack of time, but I don’t think that’s really true.  After all, I have tons of design work done and you’d think that’d be the boring part right?  I think the problem is lining up spare time, motivation, and resources.

Spare time exists in snippets everywhere.  When I’m on the bus, in a particularly boring lecture, at home after work, etc.  Motivation is more fleeting.  Sometimes I’m really keen to get into this project, other times it’s the furthest thing from my mind.  Finally, resources are either available or they’re not.  I haven’t had a laptop for a while, so I intended to develop mainly from home.  I’ve borrowed a laptop, but I don’t want to fill it with all my development tools.  Having said that, I’m doing it in php and I don’t need much of an IDE to cut code.  I could probably get some meaningful stuff done in notepad if need be.  Testing? That’s harder, particularly as I’d need a database running and a php web server.

So you see that even though I’m motivated more often than not, those three things don’t always line up well.  I don’t often have much motivation when I get home from work, even though I have time and resources.  When I’m sitting in a boring lecture, I’ve got plenty of motivation and time, but I don’t have the resources.  You get the picture.

So, how do I change this?  Well you’ll be pleased to know I have a plan:

1. I bought a laptop.  It’ll arrive in about a week.  It’s powerful and I can put whatever the hell I want on that thing so you can rest assured it’ll be running all the dev tools I want.
2. Portable Apps.  I rediscovered these when I was thinking about how I could improve the situation.  If a computer is available, I can spin up a full WAMP stack as well as GIMP, Notepad++, and FileZilla.
3. Target deadlines.  I have them.  And work breakdowns, heirarchical todo lists and all that stuff.  I’m organised.

So when I wrote that post yesterday, to my surprise I found three other draft posts of varying ages.  I know myself well enough to know that I probably won’t go back and revisit them, so here’s what they were about:

Salling Clicker

That’s all that was in this one – just the title.  I know what I was going to say though.  I was going to heap praise on this tiny but personally very useful app.

I have a beautiful (expensive) Sony LCD TV in my living room with a very handy VGA port.  My computer is right nearby so it’s permanently connected.  What Salling Clicker does is provide a way to control my computer from my mobile phone via Bluetooth or Wifi.  This is amazingly useful when watching movies from the couch.

The interface is solid and deployment is very easy.  Best of all, it’s cheap.

Understanding threading is more important than ever

This was a post I was going to write about a now old Ars Technica article.  The article was about the future of processors according to Intel where they suggested there’d be many many cores, not just two or four.  I didn’t get too far on my post:

We were taught threading in the very first programming subject I took at uni.  Initially, it can be difficult to get your head around.  Eventually I got there.  I was convinced though that plenty of people passed that course without any firm idea of how threading worked.

With the announcement from Intel that they’re heading down the track of many, many CPU cores, understanding threading is more important than ever for a budding software developer.

What I was going to get to was that developers will have to start thinking about parallel processing.  If we’re stuck on 3GHz per core and you want to do some crazy-complex stuff, it better be able to be spread across the cores or it will be S.L.O.W.

Will the compiler/OS/processor be able to handle this for you?  Well, yeah, possibly to an extent, but writing your software to take advantage of new processor capabilities will be a necessity for performance.

At the very least, you’ll have to have a detailed knowledge of how threading works.  It’s the future, man.

Religious Coding

The oldest draft of the lot was also the closest to being finished.  Here’s what I wrote, minus the half-written final sentence (seriously, I stopped halfway through a sentence):

I stumbled across this Slashdot post the other day which talks about the potential for mobile phones to generate enough power to run by using piezoelectric materials.  In short, the vibrations you and those around you make when you talk could generate enough electricity to keep your phone going.

Now here’s the point in this post where I really wish I could remember the word I want to use.  You know when you hear about something for the first time in your life, then amazingly you hear about it several times in the next short while?  You wonder how you’re suddenly being bombarded with this new concept when you only just found out about it?  Yeah, there’s a word for that and I’ve forgotten what it is.  That word goes here.

I picked up a Popular Science magazine a few days before I found this Slashdot post and amazingly, there was a whole section in it about “free” energy.  Awesome concept.

There’s a whole host of low-powered devices in common use today, and there’s superfluous energy being expended everywhere.  Surely this energy can be used to power these low-powered devices?

The simplest example in the Popsci magazine was the humble light switch.  When you wire up a house, you have wire for power going to the actual light, as well as wire for control going from the light to the light switch.  When you flick the switch to turn the light on, you’re expending energy.  Not much, granted, put apparently enough to send a wireless signal to the light (or a controller next to it) to tell it to turn on.  With a setup like this, there’s no need for wire to run down the walls to the switches.  Yeah, it’s not much of a power saving and it’s probably not worth the extra initial cost right now, but in the future it could, and combining a few dozen simple ideas like this in every house could surely save some energy.

The fact is, we expend a lot of energy when we do anything.  There’s also ambient energy all over the place – the obvious ones like wind and light, but also vibrations and body heat.  If we could capture a fraction of that energy and put it to use, we’d have much less need for power plants.

There are thousands of options out there.  If you go for a walk, chuck your mobile phone in the little holster on your belt, and as you walk, the up-down motion of your steps can charge it.  Or maybe the energy absorbed when rain lands on your car roof could be enough to power your windscreen wipers.

Perhaps after a time, when it becomes cheap enough, device manufacturers may get into the habit of building these “free” power sources into their devices.  A mobile you didn’t have to plug into a wall or a sound-powered LED light you could just stick onto a ceiling would certainly have a market.

Clearly this stuff interests me.

A mate of mine working in the US sent me a link to a Mozilla Labs tool called Ubiquity.

Essentially, the idea behind it is to let users describe what they want to do with the Internet rather than where they want to go.  The web at the moment is really based around sites that you have to actually visit to be able to use the information.  Their idea is to skip this visiting stuff and let the tool (or commands written for it) do all the work for you, giving you only the information you were after.  They have a really good description on their blog post (linked above), and I can’t really think of a better way to describe it than them (which is probably good), so have a read if you’re interested.

It’s really lightweight and very easy to install, but at the moment it only works for Firefox.  It’s also surprisingly easy to write new commands.  I’ve been a .Net kid for a while now but it only took me a couple of hours to hack up a new command.  Admittedly the Ubiquity language is Javascript so it’s not terribly unfamiliar.  Still, that’s a pretty short learning curve.

Commands have the ability to give you a realtime ajax preview before you actually execute the command.  In most cases, I don’t even use the execute functionality and I suspect that for the small things, most people won’t.

Anyway, when I was trying it, the built-in “define” command wasn’t working for me.  It would look up a word when you pressed enter to execute the command, but it didn’t give me a preview.  So, in order to get a nicer dictionary lookup and at the same time try out this funky little thing, I decided to create my own.  Of course once I’d got mine working, the define command started working properly.  I like mine better – it gives prettier results.  It’s not just because I made it myself… but that’s the main reason.

You can go here to have a look at it.  Subscribe to it if you want to use it or hey, just steal the code or whatever, I don’t care, it’s public license – do what you want.

So in summary, it’s easy to use and I think it has the potential to be something really big.  If you have a look at the examples of what they’re ultimately trying to be able to do, it’s pretty impressive.  Imagine typing “find restaurants near me with reviews over 4 stars” and being given a google map with markers and summarised reviews of each.  Very useful, no?

Hmm, combine that with voice recognition and you’ve got a genuine futuristic computer from the movies!  Rad.

So I haven’t written a post in a while, but no, that’s not the reason for the title.  I’ve just been concentrating on other things and haven’t felt sufficiently motivated to write about anything.

But then I read this post from Steve Yegge on Stevey’s Blog Rants.  His title was “Business Requirements are Bullshit” which, while clearly designed to catch the eye, doesn’t entirely represent what it was about.

Steve’s post was aimed at people developing a new (or better) product to take to market.  He wasn’t talking to consultants or employees who are producing something to meet a specific company’s business needs, but someone who was creating something new to fill a perceived hole in the market.

His point (adapted from Warren Buffet) was that you should build something you already know about; something that actually meets your needs.  If you’re doing that, then you already know what you want.  You know what compromises you can make and what the unspoken and tacit deal-breakers are.  If you’re trying to gather business requirements from a group of people who may or may not want the product while trying to understand what it is you’re actually making, then you’re probably going to fail.

It sounds like great advice, but right now, I’m not in the category of people building something new to take to market.  I’m in the other group.  The stuff I build and maintain (and now I’m going to slip back into software) is supposed to meet an immediate business need for a specific client.  It more than likely won’t be used by me, but I have to build it anyway.

So can Steve’s advice be applied to my situation?  Sure it can, to an extent.

Steve’s main point was that if you’re not investing in something you understand, then you’re walking into very dangerous territory.  As an end-to-end software developer, I’m aware that it’s difficult to know exactly what the customer wants.  Sure, you can grill every potential user for days, you can write a comprehensive list of requirements, you’ll check it and recheck it over and over again to make sure you know single possible piece of functionality that they want and need.  But when it comes to the crunch, no matter how much work you’ve done, you’ll start getting negative feedback about some specific things that you hadn’t thought of and the customer hadn’t mentioned.

That complex report you were asked to include, the one with all the tables and forecasts and things?  It turns out that 10 different people print that 20 times a day.  So even though it’s perfect, it takes 15 minutes to run each time, and they can’t wait that long each time.

So how do you avoid this? In my experience, if you want to write truly useful software, you need to understand why each piece of functionality is being written.  Spend a lot of time with the clients and find out what it’s like to be in their shoes.  If you see how they operate day-to-day you’ll start to get an idea of what they actually want, not what’s written in the requirements doc.

Steve’s advice was that you shouldn’t invest in what you don’t understand.  So if you have to produce something you don’t understand, make a genuine effort to understand it first.  You might not be as enthusiastic about or deeply involved in the business your client is in.  But by honestly trying to see what they’re trying to achieve, you’ll learn what they really want your software to do for them; over and above the list of required functions.

So I discovered that Google Streetview is now available in Australia.

For example, here’s the Queen Street Mall in Brisbane.

I’m fairly blown away by the sheer number of streets that are covered to be honest.  This map gives you an idea, but once you get to the capital cities, you can see just how dense the coverage is.