Rants About Software

Petter Released for the iPhone!

Errornix — Sat, 29 Aug 2009 16:55:08 +0000

My first iPhone App, Petter, is now available on the App Store!

It took a bit longer to get out there than I had anticipated (about 2 months longer), but it's finally out and it's been quite a learning experience.

Developing Petter

I built Petter for the learning experience more than anything. I currently have more exciting apps in the works (and even more exciting ones in my brain). But I wanted to really nail down the basics of iPhone development before getting into the bigger projects. So I picked up a copy of Beginning iPhone Development and got to work!

Although Petter is a fairly simple app, there are actually a lot of different aspects of iPhone development that went into it. To build Petter I had to learn/employ...

Objective-C and the Xcode Environment - Before starting iPhone development, I had never coded in Objective-C, nor had I ever used Xcode. Although Xcode was fairly intuitive, there were some aspects of Objective-C that just work differently from the other languages that I'm used to. (Tying my code in with the Interface Builder was particularly awkward.)

SQLite - Petter uses SQLite to store your pet's information. Although I was already familiar with SQL syntax, I had never previously used SQLite and I certainly didn't know how to integrate it into my app.

File System - Petter uses the file system to store your pet's images. This means that you can delete your pet's image from your photo library, and the image in Petter will be unaffected. Not being able to browse the iPhone's file system made this somewhat difficult to debug.

GUI - Petter uses a combination of a TableView and multiple UIViews. The TableView also has custom designed cells. To pull this off, I had to design screens in the Interface Builder, tie the GUI controls in with my code, allow the screens to be able to pass data to each other, and override default functionality of the provided controls. Yeah, it was a lot more work than you would think.

Accelerometer and Touch Screen -Although not used extensively, I had to learn how to capture touch events as well as retrieve accelerometer data in order to trigger the sound effects.

Future Apps

I realize Petter isn't the most exciting thing in the App Store, but like I said, I did it mainly for the learning experience. Now that I have a much better understanding of iPhone development, I'll hopefully be able to produce some much more exciting apps in the near future, so be sure to check back for that!

Check out Petter on iTunes!

Pass-By-Reference Error Handling?

Errornix — Sat, 08 Aug 2009 12:39:00 +0000

I'm going to try something new here. Normally when I write a post, I think through everything that I want to say before I start writing. But I think I'm going to just shoot from the hip on this one and see what happens. Since I'm just writing this as I'm thinking about it, the end result may be brilliant or it may be senseless drivel that will make you dumber by reading it - Proceed with caution.

I was just reading Joel Spolsky's argument against programming with exceptions, and I'm inclined to agree with him.

A better alternative is to have your functions return error values when things go wrong, and to deal with these explicitly, no matter how verbose it might be. It is true that what should be a simple 3 line program often blossoms to 48 lines when you put in good error checking, but that's life, and papering it over with exceptions does not make your program more robust. I think the reason programmers in C/C++/Java style languages have been attracted to exceptions is simply because the syntax does not have a concise way to call a function that returns multiple values, so it's hard to write a function that either produces a return value or returns an error.

While I completely agree with this, I think one could argue that we do have a way of returning multiple values: Pass-By-Reference.

The Idea

For every function that you define, add an extra parameter that will be passed by reference. Do NOT try to use the return value of the function to return any error values, only use it to return "real" values. Any error values should be assigned to the new parameter. Essentially, this will allow you to return any error values independent of the function's actual return value. This will make things somewhat easier when trying to handle any errors from within the calling procedure. For this to work, I believe it's imperative that the programmer follows these guidelines for EVERY function in the project. If you only use this occasionally, your code will be a mess.

(This is an example of Programming INTO a Language, as discussed in Code Complete.)

Now we're still faced with the problem of having a bunch of error handling code mixed in with our logic. So what if we did this... Create an ErrorHandler class. This class could basically serve as a "bank" of error handling methods. Each method could correspond to a different error code. These error codes are what get assigned to our passed-by-reference parameters.

Is it getting complicated yet?

Every class within the project could contain a private instance of the ErrorHandler. After each function call, a private ErrorHandler "consumes" the variable that was passed in by reference and runs whatever local methods the error code is meant to trigger. This would add an extra line of code for every function call, but it will also allow you to keep your error handling code separate from your logic.

Yeah, it's definitely getting complicated.

I should probably cut this off before I get into creating a makeshift table of error codes and using function pointers for the error-handling methods.

A methodology such as this would probably be a bad idea for large projects, as it can easily spiral out of control. However, for smaller projects, I think that it could be a viable alternative to exceptions. Of course that's just what I'm thinking at the moment. It's entirely possible that I'll sleep on it and ultimately come to the conclusion that this whole idea is asinine.

Domain Name Change

Errornix — Fri, 17 Jul 2009 14:14:24 +0000

A little bit of site news: I've decided to change the domain name of this site from errornix.com to rantsaboutsoftware.com. Rants About Software has pretty much always been the title. I just finally decided to make the domain name match. As usual, I registered the domain through Bihira (They're the greatest!)

This is mainly just a cosmetic change, the site itself isn't changing. Also, errornix.com still works; it just redirects you to rantsaboutsoftware.com.

Highlight the Author's Comments in Squarespace

Errornix — Wed, 01 Jul 2009 02:17:00 +0000

Here's another Squarespace tutorial for you. This one's a bit shorter than the last one. In this tutorial, I'll show you how to highlight comments that are written by the author, so that they stand out amongst regular user comments. This image should give you an idea of what I mean.

This is a short and simple little trick, but I'm sure you can easily see how effective it can be. By default, Squarespace doesn't really provide much of an indicator that a comment has been left by the author (other than the username, but nobody pays much attention to that anyway).

To do this, start off by setting the style of the regular user comments. Just do this using the Font, Colors & Sizes tool when in Style Editing mode. Chances are, you already have this style set the way you want it. Once you've done that, go to Custom CSS and add the following

.authored-by-yournamehere .comment { /* style here */ }

Obviously you need to replace "yournamehere" with your actual username. Then just apply whatever style/colors you want. To give you an example, here's what I did...

.authored-by-errornix .comment {background-color: #BFFFF0; border-color: #E6E6E6;}

If you want, you could easily change other things, such as font settings, or add images. But im my opinion, this would just look weird. By only adjusting the color settings, you'll inherit all of your other style settings, and your comments will just appear to be highlighted rather than appearing to be a completely different style.

Like I said, this was a short and simple one. But if you have any questions, let me know!

Status Update

Errornix — Sat, 13 Jun 2009 13:23:00 +0000

I figured I'd just take a minute to update everyone on what's been going on with my current projects.

Projects

Memories of Hyrule - The majority of the MoH engine has been finished for quite a while, but there's one important piece that I've yet to finish. I've never implemented a system that will allow the game world to maintain it's state. What I mean is that when you defeat the enemies on a screen, then leave and come back, the enemies will already be back. Naturally, I would want them to eventually return, but not immediately after leaving and entering the same screen!

I've been unsure of how to solve this problem for a while now, but I think it suddenly dawned on me. I'll probably have a full post on it in the future, but I have an idea for an ADT that will be able to maintain the current state of the world in the player's immediate surroundings.

So it's still a ways off, but Memories of Hyrule is still moving forward, and will be released once it's been "perfected".

Project X - I know I've been pretty tight-lipped about this one. I'm still not really going to reveal any details, but I figured I'd at least give you a small idea of what it is... It's a game portal - mostly Flash, but there will be some other stuff in there too.

iPhone - I should be ready to roll out my first couple of iPhone apps soon. Just to warn you, the first app isn't too exciting, but I've got a couple of other things coming down the pipe. So check back for more updates on that soon!

Note: In case you're wondering, I put "perfected" in quotes when referring to software, because software can only be theoretically perfected. We can't even prove that a piece of code is bug-free, let alone perfectly crafted... but we still try to get as close as we can.

Google FAIL!

Errornix — Sat, 02 May 2009 13:53:00 +0000

Wow, I never would have thought that I would write a title like THAT on this site. But low and behold, I did experience a brief Google FAIL.

I was checking my Gmail from within my iGoogle page, and for some reason the search bar/header appeared both at the top and where my inbox should have been. At first, I thought maybe this was some kind of refresh problem, but both search boxes were fully-functional. Weird. I'm not sure what happened, but a simple refresh fixed it - end of fail.

Note: In case you're wondering, I'm using the PHP Coder iGoogle theme.

The Default Case Dilemma

Errornix — Mon, 20 Apr 2009 23:14:00 +0000

I have to confess something. In my last post, I talked a lot about good coding practices. Well, it seems I have a tendency to break one of my own rules. I was looking through some of my Memories of Hyrule code and I realized that I have a tendency to leave the default cases, in my switch statements, blank.

Here is an example of what I'm talking about.

case BLUE_POTION: imgBluePotion->draw(3, 2); break; case RED_POTION: imgRedPotion->draw(3, 2); break; case MAGIC_WAND: imgMagicWand->draw(4, 2); break; default: //Something terrible has happened. break;

This is the tail-end of a method that draws the player's current inventory items on the screen. There is a different case for each item that is available in the game. So in the end, I'm left with a blank default case. I want to say that this isn't a big deal because I'm sure that the default case with never be reached. But can I really be 100% certain of that? No, of course not. So what can I do to fix this?

I've seen other programmers simply use their last case as their default case. I can see the logic in doing this, but I really don't like it. I think that if I'm going to draw something on the screen, it's going to be because it absolutely belongs there, not because nothing else belongs there.

My next thought was to handle this like any other error or exception. But I don't want to do that, because getting into that default case isn't necessarily something that would be fatal to the application or even something that would disturb the player. So I don't want to turn it into something that will.

I'll be honest. I'm a little stumped with this one. For the time being, it's still just a comment (although it's a little better than the one displayed above), but I still feel like it should be doing something. Perhaps this is a scenario where an empty control block really is the best way to go?

A Passion for Programming

Errornix — Sat, 11 Apr 2009 12:09:00 +0000

There exists programmers who do not love what they do... I know, I can't believe it either.

To many, software development is just an everyday 9-5 job. But to others (such as myself), programming is practically a way of life! But I suppose not everyone can have the same love for code that I do. Not everyone can really admire the elegance of a well-formed recursive function. Not everyone can read a piece of code and appreciate it in the same way that others might appreciate a song, film, or book. But the problem is not that there are people who don't love software. The problem is that there are people who don't love software despite the fact that they CHOSE a career in which they write it every day.

But how do I know? How do I know that the people writing software don't love it the same way that I do? How do I know that people chose to go all the way through school in order to start a career in a field that they don't love?

I know because I read their code.

Aesthetics Matter!

I look at ugly code ALL the time! I look at code with incorrectly indented code blocks. I see code with inconsistent variable naming conventions - that's if they even have conventions. I see poorly designed class interfaces, inefficient nested for-loops, execution paths that are never reached, vague documentation, the list goes on.

If you love what you do, then you should WANT to write clean code. It's not enough to just get the program working. Aesthetics matter!

You should always follow some form of coding guidelines - not because your boss says you have to, but because you WANT to. You should care about the readability and integrity of your code. Here are some sample coding guidelines from the C# Coding Standard that should help.

Methods with return values should have a name describing the value returned, such as GetObjectState().
Prefix private member variables with m_. Use Pascal casing for the rest of a member variable name following the m_.
Avoid putting a using statement inside a namespace.
Always check a delegate for null before invoking it.
Avoid putting multiple classes in a single file.

Again, I'm not telling anyone to follow these exact coding guidelines. I'm just saying that you should HAVE guidelines, and more importantly, you should WANT to follow them!

Refactor Your Code!

All too often, programmers will get a piece of code working and then they'll abandon it and move on to the next task. Like I said before, it's not enough to just get your code working. You need to go back and refactor your code!

How often do you create temporary variables while debugging? Go back and get rid of them! Make sure there aren't any control paths that can't be reached. Improve the efficiency of your implementation by removing redundant code.

The end result should be a tight, concise, and clean implementation of your solution.

Make Your Code Communicate

This one can be a little tricky. For the sake of future programmers, who may someday be maintaining what you've written, you need to try to communicate your thought process to them through your code. So just how exactly do you do that?

Well the first, and most obvious, answer is comments. But having well-commented code is no reason to write bad code. First, you should program as if comments don't even exist. Use descriptive names, refactor your code, and get rid of the bloat. Make your code straightforward and easy to understand, and THEN comment it.

Of course comments can be used to communicate to other programmers, but how do you make your actual CODE communicate? Show them that you've thought of "everything"...

When creating a C++ class, you should always overload the assignment operator. However, this is not always necessary for the functionality of the program at hand. I don't care. Write it anyway. This will show them that you've at least thought about it. The same goes for default constructors and destructors.

When checking for user input, assume anything and everything may be entered, and handle it accordingly. Don't leave it up to the maintenance programmer to think of every scenario. He has enough on his mind with just trying to figure out your code and implement his change.

Consider all control paths. Are there any obscure/unlikely paths that you may not be handling very well. Perhaps these should actually be exceptions. If so, catch them accordingly, rather than having someone else spend hours tracing through your code with a debugger.

Improving our code shouldn't be a chore! It should just be a part of what we all do. We do it because we love it - because we care about the product, both inside and out.

Side Note: I hope Jeff doesn't mind, but I stole the above image from codinghorror.com.