Category Archives: Computing

Are you being Agile and should you care?

Agile Software Development is not a new thing. As an exact “thing” it has been around since 2001, making it more a surly teenager than a brilliant new idea. Just like some teenagers, it has not always turned out quite as well as the ideals its creators had for it when it was just a babe…

The agile manifesto was set out by some pretty cluey people – people who were quite competent at thinking for themselves. Unfortunately, some people look at the manifesto and think that it means “rules” rather than “policies and aims”. Sometimes people want to have rules to follow and the manifesto simply does not provide enough rigidity for their needs.

The most obvious example I can think of is when I have heard people misquote: “Working software over comprehensive documentation” as a reason not to write any documentation! (When misquoted, the word “comprehensive” goes missing) The fact that the manifesto is quoted as though it is law should be the first warning sign that you’re doing it wrong! The Agile Manifesto is not a development methodology and shouldn’t be treated as though it were one. As the scrum methodology website states:
“The Agile Manifesto doesn’t provide concrete steps.”

At the bottom of the Agile principles there is this gem:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

I like to think of it as: “Remember the aims of the manifesto and do what works for your team”. If you claim to work in an Agile Software Development team – but you have worked the same way for as long as you can remember, then it might be time to shake things up a little.

At the heart of the problem is that not everyone is passionate about their job. Sometimes, even the passionate ones can be at a point where external events mean that they are not focusing this passion on their work. That’s okay! It happens! But when it does, expecting these people to work in an agile manner is not being realistic.

The Agile Manifesto and the Principles behind it are worthy goals to strive for in software development. Lean, hungry successful startups seem to naturally gravitate towards most of the principles outlined. For them, I imagine, spelling it out is just common sense. (Although the principles also talk about working at a sustainable pace. – That doesn’t seem to align with the stories you hear about successful startups!)

If you are working in a Software development company that claims to abide by the Agile Software Development Manifesto, it is worth going over these principles and the manifesto itself periodically. Make sure you are on the band-wagon, not just claiming to be! If you read them and decide that they do not suit your team at all, maybe it is time you claim to be something else!

Dealing with the Apple Push Notification Service

I have recently been working on sending Push Notifications for an iPhone app. The Ray Wenderlich web site has a (dated but still) great post to get you started with this and includes some PHP code for transmitting the messages to the Apple Push Notification Server (APNS).  I won’t rehash what Ali Hafizji went over in his post, rather just suggest you have a read yourself.

There are free and “nearly free” services that offer customers a service that communicates with APNS, but they just leave you communicating with their servers, rather than directly with Apple’s. At the risk of sounding like “not invented here syndrome” I wrote my own application.

Apple document the comms format used. It’s a binary message format. “Back in the day” I did more than my fair share of binary comms . Like a lot of my peers I had my share of writing Point of sales software. Most peripherals in those days used differing binary formats over RS232 to communicate. Apple’s format differs from how I remember binary protocols from working, so I wanted to share some potential pitfalls that I noted. (One of which I fell in, others I skilfully / luckily? avoided)

Numbers are stored big-endian.

If you are writing your application on a Windows machine, then your numbers will be stored little-endian. In my case, I was using C#. The BitConverter class provides methods to get the byte array representing the number, as well as a property that you can check to see if you need to reverse the array. I guess with Mono, there’s a chance that your C# code will end up running on an O/S that is big-endian – so it probably pays to check first, before reversing the byte array!

The frame data is not simply a in-memory version of the third table

This is the trap I fell in – and in retrospect it was a silly mistake caused by misinterpreting the sentence:

The frame data is made up of a series of items. Each item is made up of the following, in order.

Each item contains an item identifier, an item data length field, and the item data itself. Unlike previous binary comms that I have done, this means that length fields appear throughout a transmission. This is not exactly necessary, as there is only one variable length field. While I consider it “not exactly necessary” it does lend itself to forward compatibility that would otherwise not be possible.

The APNS servers only respond with errors – sometimes

When I was struggling with malformed frame data I would often not get an error message response from the APNS. I don’t know why this would be the case. In my experience, if your iDevice does not receive your notification within thirty seconds, you have probably done something wrong! My experience was most were received within three or four seconds…

Not every item-type needs to be in your frame data

Out of interest, I started experimenting with leaving out frame-data items. It appears safe to leave out the “expiration-date” if you wish. I would guess that leaving it out, is the same as specifying zero. That is, if the message cannot be delivered straight away, the APNS will not attempt any delayed delivery.

You do not have to reinvent the wheel!

Late in the piece, I came across the PushSharp open source library. Chances are, I will switch over the code I wrote to use this project instead. It supports all major mobile platforms, not just Apple.

Still, I wanted to rattle off what I learnt in building this app, in the hope that it may help someone avoid a gotcha!

Good luck and happy coding!

Mmmm… floor pie….

I bought a Raspberry Pi. I know there are faster, more powerful “System on a chip” computers, but the wealth of knowledge and information on the pi made it an obvious choice. I bought the “Model-B”, that features an Ethernet network port and lashed out and got a clear plastic case for it. I like to think it gives it a mini-Orac look…

I’m planning on using it to write basic web services to suit my needs. The first one, is going to be as the “back-end” (or “cloud” if you will!) for an Android app I have been thinking of.

Any app-store with half a million apps or so in it, is bound to have already covered the ideas I am likely to come up with. So, it is strictly a case of “done for the fun” combined with “not-invented-here” syndrome. Ultimately, I am planning on learning something away from what I do and know from work.

Like all true home projects, it runs the risks of being abandoned half-way through. However it goes, I’ll endeavour to blog about it as I go…

I swear it’s true!

Blogging is not journalism.  Sometimes blogs are well researched articles absolutely worthy of a status of journalism and sometimes news articles are not. Other times blogs are little more than opinion pieces, the author’s own soap-box on the web.  Either way, writing allows for some extra degree of thought and contemplation not necessarily afforded to verbal communication.

I swear when I talk.  Maybe not as often as some, but more often than I intend to.  I think of swearing as an admission of failure.  I have some emotional reaction to something that causes an outburst, and my lack of eloquence prevents me from expressing myself without resorting to being a potty-mouth.  The only effective means I have of curtailing swear words is to pretend there are children present.  Introducing children to the common use of bad language somehow seems quite unacceptable.  I put this down to both my parents being school teachers, from a generation where bad language would at least receive the threat of having one’s mouth washed out with soap, even if I never saw the punishment executed.

As writing affords the author some degree of contemplation prior to putting pen to paper (text to screen?) I simply find it unacceptable to see swear words in blog text. Adding swear words can absolutely ruin a good post. If this is the only way you know to get your point across, then yours is not a point I need to know!

Revision Control System Ettiquette

Develop software for any length of time, and you will reach the conclusion that being able to track changes you make to source code is "a good thing". Put a show-stopping or embarrassing bug in the last round of code changes you made? Being able to revert to an older version of the source code, may be the fastest way out of your problem! If it isn't, it may at least help you to understand what you did wrong – by comparing different versions of the source. This isn't rocket science – software development teams have had Revision Control Systems (RCS) to help them do just this for a long time.

If you work as a programmer and you have never heard of RCS, then I suggest you see this thoroughly excellent visual explanation of what one is. Then explain to your boss, that you need one. Those of you who are more in the know, will realise that the introduction I linked to is a few years old, and doesn't attempt to explain what a Distributed Revision Control System is, but for the purpose of this article, it is satisfactory.

Working collaboratively on a project more-or-less makes using some sort of RCS mandatory. Sure – you can survive without it, but it simply makes no sense to do so. One of the highlights of using an RCS is the ability to show how source code evolves. Being able to diff the revisions of the code can be useful to help fellow team members understand how the code came to be the way that it is.

Just because you can see what differences there are in two versions of the file, doesn't mean you will understand what the differences are! It is easily possible to change code sufficiently to make following your changes close to impossible. Even if you are developing in isolation, you should be using an RCS and acting as though someone else will be the next person to work on your code. This is especially important, just in case you are the next person to work on your code! :)

Here are some simple guidelines to try and follow when checking in code changes:

  • Only attempt one change per check-in. If you have several bugs to fix that all relate to the one piece of code, it is tempting to fix them all at the same time. This is discourteous to anyone attempting to understand your changes at a later date.
  • Explain what you are doing. When committing a change to the RCS, you get the opportunity to submit a "check-in comment". In much the same manner as commenting code, these are best used to describe the intent of your revision. Normally, people use the comment field to provide a reference back to a bug-tracking number. This is worthwhile, but it falls short of being a great check-in comment. I am sure that the vast majority of coders can type quickly enough that expanding their check-in comments won't take them too long!
  • Code styling / formatting gets its own check-in. So, you didn't like the order someone put the class methods. Or, they didn't put spaces between function parameters the way it is meant to be. You feel moved enough to change it yourself. Well, just check it in separately. Again, this goes back to being courteous to someone who may be trying to follow your changes at a later date. Logic changes can easily be buried / hidden by moving the function they occur in. The diff output will show that a function was removed from a certain point in the file and inserted somewhere else. Subtle changes in the function can easily be lost

All of the above recommendations are aimed at improving the accountability of the code changes you are making. This becomes more apparent when you are working on a team that uses code reviews as part of their development methodology. The relative-worth of code reviews can receive fairly heated debate, but that is a story for another time.

When Worlds Collide

I watched in abject horror as Dani Pedrosa weaved violently from side to side of the track, at the rear of the field as the rest of the competitors disappeared from his view. Pedrosa was travelling dangerously fast for the next corner and way off the racing line. The bike slowed imperceptibly as though the brakes had air in the lines. In an act of pure desperation, he pitched the bike over on its right side in a vain attempt to make the corner. That the bike would run wide and off the track was a given. What wasn’t so expected was the fact that with in excess of fifty degrees of lean angle and still heavily on the front brakes the bike didn’t “wash-out”. Rather, it merely acted as though the grass was covered in sticky glue, retarding the bikes momentum far more effectively than the brakes had.

Of course, I was Dani Pedrosa and this was the demo version of the game “MotoGP 10/11”. I must admit I enjoy a good racing simulator and as a motorcyclist was desperate to like this game. You can’t expect an X-Box controller to map accurately to the controls of a motorbike, so “realism” in such a game is always going to be a subjective term. The demo version of the game starts with all the usual assists you can expect in a modern racing simulator, including a “racing line” indicator that both indicates where you should be and how fast you should be travelling by its colour.

If you were to paint a line on a racetrack and ask me to travel at whatever speed I felt was appropriate but to stay close to the line, I reckon I could do a reasonable job. Asking me to do so in the game proved close to impossible! I think the largest problem with motorcycle games and a controller is judging a lean angle via the thumb-stick. Maybe I am just a n00b, but it seems difficult to use the thumb-stick and push it to an exact angle that is not at its extremity. Minor corrections are an impossibility as the only steering mechanism you have acts as a giant inverted pendulum. Dani gradually leans from one side to the other, meaning all direction changes need to be planned well in advance.

If I was allowed to call the shots for future development of the game, I would love to have a custom controller that mimicked handlebars and utilise the Kinect sensor to allow for body positioning on the bike. That way, body movements could provide minor line corrections, similar to what happens in real life. A less ambitious idea would be to use the second thumb-stick to provide this line-correcting behaviour. This presumably would have the advantage of being easier to port to the other game platforms.

On the positive side, the game is gorgeous to look at. The visuals are stylised rather than attempting and failing at photo-realism. The result is stunning. Screen shots look like an oil painting. Playing it makes it look like err… a moving oil painting! I don’t think it’s a coincidence that the demo only allows access to what must be the most picturesque circuit on the current MotoGP circuit – Mugello. Although it is even more absurdly difficult to play in “first-person” view, this really does bring out an excellent feeling of realism as your view is buffeted about by the wind rushing past you.

Strangely enough, you don’t hear the wind though. Mind you, this is not a bad deviation from reality, as you are missing out on 90+ dB of white noise blaring out of your television… The noise the bikes make is probably a fair approximation of a MotoGP bike. It certainly is not awful enough to be detracting from the game.

As for an overall verdict based on the demo version, well the jury is still out. I enjoy a challenge in a game and if I had “won” the very first race I attempted, it would not have been a game that appealed to me. However, there comes a point where wobbling around behind the rest of the field loses its appeal. Do I have the persistence to keep playing until I reach the point where I can challenge Alvaro Bautista and Mika Kallio for fifteenth and sixteenth place? I can tell you that unless that happens soon, I might have to just consign this game to the “too-hard” basket and wait for a revolutionary Kinect enhanced version of a motorcycle racing simulation.

Making an exception

I don’t normally blog about code. I don’t often make my blog entries into the lists that are so popular on the Code Project. Plenty of people do plenty of that already. Today, I am making an exception to these rules, to talk about exceptions… Nothing I am going to present is rocket-science. This article, is closer to introductory reading for a junior programmer, or to assist someone mentoring one. Although my examples will be in C#, they should apply for any object-oriented language.

Tip 1: Only trap exceptions you are prepared to handle

Here is a bad example that doesn’t do this:

try
{
    DoSomeFunkyMaths();
    DisplayResultsOfFunkyMaths();
}
catch
{
    // We know we may get a div by 0, so ignore exceptions.
    DisplayOurFunkyMathsFailed();
}

Instead, you should write your code as if you are expecting a particular exception.

try
{
    DoSomeFunkyMaths();
    DisplayResultsOfFunkyMaths();
}
catch (DivideByZeroException)
{
    // We know we may get a div by 0, so ignore that exception.
    DisplayOurFunkyMathsFailed();
}

Essentially, this boils down to “Don’t provide a general exception trap because something *might* happen. Trap explicit exceptions that we know the program can handle.
If you are thinking: “But wait! Our program could still fail and we’re not doing anything about it!” you would be right. It is better to fail early and know why you failed, than to fail later without a clue. When you “bury” exceptions in a generalised exception trap, you leave yourself open to a “clueless failure”. Imagine that DoSomeFunkyMaths() includes some writing of data to file. Now it is possible for I/O exceptions to occur as well as the division by zero. With a general exception trap, you will not know that this has failed and when the code subsequently attempts to use the data from the file, you will get unexpected issues.

Tip 2: If you are going to raise your own exceptions, make your own exception type.

Again, here is not what to do:

if (ErrorHasOccurred())
    throw new Exception("Something has gone terribly wrong");

The only way to catch this exception, is to catch all exceptions. If you haven’t figured out what is wrong with this, reread Tip 1 until it sinks in… While I am at it, try and make your messages a little more helpful than “Something has gone terribly wrong”.
In C#, it isn’t hard to make your own exception class. If you cannot be bothered putting much effort in, here’s a simple example.

public class FunkyMathsException : Exception
{
    public FunkyMathsException(String Message)
        : base(String Message)
    { }
}

This is a perfectly acceptable start for your own exception class. Now, code you write that throws exceptions, will use this, instead of the base exception class.

if (ErrorHasOccurred())
    throw new FunkyMathsException("Something has gone terribly wrong");

I still haven’t learnt to put a more meaningful message in. But, at least I can now catch a FunkyMathsException, where I want to, and leave other exceptions well alone.

Tip 3: A generalised exception trap does have one perfectly acceptable use.

I am not an expert on all languages, but normally, an unhandled exception will cause a program to terminate. Depending on the circumstances, this may or may not be acceptable.
Acceptable: Your program is some sort of stateless service that will be restarted via a script or operating system should it stop.
Unacceptable: Your program is a word processor and the user has not saved their document for the last 30 minutes because they are too busy typing away furiously on their “best-seller”
If your program falls into the “unacceptable to unexpectedly stop” category, a global exception handler is the way to go. Save / report the error / do what you have to do… Just be careful to try and not raise an exception. This is serious “infinite loop” / “stack overflow” territory and your program is already on rocky ground.

Tip 4: Exceptions do not cross process boundaries.

I do not know how general this tip is. YMMV. From what I have seen, calling code in a separate library via COM, exceptions do not cross boundaries. The calling code will throw some sort of exception, but most of the specifics to the exception will be lost. It is just best to use other means to relay failure messages back from the library code.

Tip 5: Do not raise a new exception in response to an exception

There may be times when you wish to perform some operation when an exception occurs, but not actually deal with the exception. For instance, the calling code may be better placed to deal with a particular exception but you wish to perform some logging action at the time. If you raise a new exception, you will have lost potentially useful debugging information, such as the call-stack of where the original exception has occurred. Fortunately, most languages provide the ability to “re throw” the exception, simply by using the “throw” keyword by itself.

try
{
    PerformSomeFunkyMaths();
    DisplayResultsOfFunkyMaths();
}
catch (DivideByZeroException)
{
    LogDivByZeroError();
    throw;
}

Tip 6: Exceptions are for exceptions

There is a balancing act between raising / trapping exceptions, or testing conditions with an if statement and acting accordingly. Using if statements increases code complexity and will take some processing time, every time the statement is evaluated. Using / trapping exceptions may simplify the code, but where an exception is raised, they tend to be far more expensive (time-wise). Therefore, using exceptions should be something that is done for the odd occasion where things haven’t gone according to plan. This point is a rather grey area and open to interpretation.

Gee! Thanks for the compliments!

The complimentary spam-bots are winning. A university lecturer once described computers as being high-speed idiots. It is an accurate assessment: they are many orders of magnitude faster than humans and yet lack basic intelligence. As such, it should come as no surprise that spam generators are quite pervasive in pushing out their content. WordPress blogs seem to be a favourite target.

In terms of blog content and readership, I fully appreciate that I’m just a tiny drop in a large sea of opinionated writers. Some of my posts attract attention on forums, but seldom do people find the need to comment on the post itself. This is frustrating, as I want a blog post to promote discussion and attract opposing opinions. I write to stimulate a conversation that I hope to learn from. Still, I am happy that people have taken the time to read any post I have written.

I moderate the comments that appear on the posts I write. I will not filter any comment – as long as it adds something to the discussion. Being a “tiny-drop” blogger means I can afford the luxury of moderating comments – I don’t have 100,000 readers all vying to make their viewpoint known. Spam-bots are now taking a “complimentary” approach to getting their content published. I have lost track of the number of comments along the lines of “Nice post – I really enjoy your content”. Yeah – good try… If you have a WordPress blog and you get comments like this, I’ve got news for you, and I will tell you slowly: They… are… spam! Try a search for the exact comment and see how many hits you get.

So the signal to noise ratio is appallingly bad. Less than 1% of all the comments this blog has received are genuine and thought provoked. The only worthwhile function these spam comments serve is to alert me to articles that have been linked from external sites. There is a definite trend that externally linked articles attract more spam.

Now that I have finished whinging, I’ll get to the point of the article… If anyone knows of a good WordPress plug-in, or code that reduces the likelihood of spam comments, please feel free to leave me a comment!

Smart-phones

It was more or less inevitable.  I bought myself a new smart-phone and it wasn’t an iPhone.  There were many reasons I didn’t buy one.  Most of which are purely subjective.  Some of which I list here:

  1. I do not like iTunes.  There has always been something about iTunes that has not sat well with me.  For reasons I cannot put my finger on, I just don’t like the way it does things!  If it were not for the consumer lock in of iPods and iPhones and iWhatevers, I am convinced it would not be as prevalent as it is.
  2. I  have an objection to DRM in music.  I consider myself to be pretty honest.  I buy music I want to listen to, but I will not pick a format that restricts how I want to listen to it.  I also could not be bothered trying to work out how to circumvent DRM.  Music is just something I want to listen to.  I do not want to fight it / worry about it / manipulate the format it appears in / lose it because I upgrade computers too often etc.  I can appreciate that some people will pirate music and that DRM probably prevents some people from doing so, but that does not change my opinion on the matter.
  3. I wanted the potential to develop applications for a smart phone.  I know – I could jail-break the iPhone, but that falls into the same category of circumventing DRM.  I can’t be bothered!  There is a learning curve to starting development of smart-phone applications, and I do not need to introduce extra hurdles.

While these reasons are all true and valid for me, if I am completely honest…  There is something deep in my personality that makes me despise following the crowd.  As such, an iPhone was never going to cut it.  From what I read, iPhone market penetration in the US is not all pervasive.  In Australia, consumer gadget of choice, is an iPhone.  I am not sure what will happen when the oversized-novelty-iPhone (the iPad) is released here next week.  I am sure it will sell well, but not convinced it will be quite as ubiquitous.   Everytime I  catch public transport, I swear iPhones outnumber passengers.  :-)  Everywhere you look, iPhones abound.  I am writing this post on a plane, next to some guy listening to songs on his iPhone…  That this happened was not a surprise to me…

So, if “second place” is the first of the losers, I have fallen into that category.  My recent purchase was that of the HTC Desire.  From the little I have “played” with friend’s iPhones, the user experience is different.  With more buttons to press, I would not expect for Android devices to win converts from the Apple buyers out there.  Simply, there is a mental adjustment to make if you go from one system to the other.
Initial impressions are that it takes  a few days until you are comfortable with using the “menu” button to get to features in Applications.  The screen on the Desire absolutely beats the iPhone hands down.  I have no doubt that iPhone v4 will probably reverse this trend, but as it stands now, there is no contest.  Even though it has extra hardware buttons and I appreciate minimalism in design, I think the Desire is a better looking device.  I haven’t bothered putting a DRM free music library on the device as of yet, so won’t pass comment on the media player.  If I am to believe what I have read, this issue divides opinions like few others.

Regardless of brand loyalty etc, last night I had my first “I ♥ my smart-phone moment”.  I will not claim that this sequence could not be replicated on other types of smart-phones, but the whole technology came together in an almost magical way for me.

I have been in Melbourne travelling for work. I lived in Melbourne for years and know it reasonably well, but still enjoy exploring when I go back there.  I picked a suburb I could get to on the nearest tram and decided to go there for dinner…

  • I used “Google Voice” and spoke: “Places to eat, South Melbourne”
  • From the search results, I found a restaurant review website and picked a place I liked the sound of.
  • I cut-n-paste the address into Google maps, so I knew how to get there.
  • While I waited for the tram, I spotted a “star” close to the moon and pointed my phone running “Google Sky Map” at it to determine that it was actually Mars.
  • On board the tram, I used the GPS to show me when I was close to the restaurant so I didn’t have to walk far.
  • While waiting for my meal, (eating alone is a hazard of traveling for work) I caught up on some Geek news via the Engadget RSS feed.

It was simply brilliant!  I now know why people love these gadgets!