Monday, 28 May 2012

Software development is difficult

Sometimes I find software development a little depressing. It gets me down, so I thought I'd have a bit of a rant about some of the reasons why.

You're never right and nothing is certain

You're doing it wrong. You're never right. Ever. There's no such thing. Just accept it. Everyone has a different take on what is good and bad practice. Everyone has their own ideas on what works and what doesn't. You will find people who agree with you, but you'll find just as many people who don't. There is no black and white, it's all one gigantic grey area. To make matters worse, I have a computer "science" degree but many people will tell you that software development isn't really a science. Much of what we do is based on very little evidence, a few success stories, the spouting of an enthusiastic evangelist or perhaps some misguided beliefs. All of this means that it's almost impossible to be sure that you're doing it "the right way". It does my head in.

How good am I?

How do you know if you're a good programmer? By what yardstick do you decide? Salary? Fame? What you build? Contribution to open source software? How much you blog? Your Stack Overflow reputation? How many books you've written? The size of your team? The super clever, better than everyone else's, framework you've written? How much public speaking you do? The number of followers you have on Twitter? The quality of your code? That's another debate of course. The number of visitors to your site? How much money you've made? 

Is it important? Probably not. Arguably the most important thing is that you enjoy what you do. Some would suggest that you can't be a good software development unless you enjoy it. I certainly believe that. But is that enough?


You can't know everything. You can't even know a little. The breadth of knowledge required for software development is immense, the total amount of things you can learn is ridiculous. But what should you learn? The skills required to do your job obviously. But how about the things you think would be useful, or the latest framework/tool that people are raving about, or maybe just something you're interested in. Don't forget staying up to date with all frameworks/libraries/techniques/tools that you're currently using. They're all being developed at 100mph. 

That's only technical knowledge of course. There are many other skills you need to be a good software developer. Requirements gathering, version control, motivation, writing, teaching, documentation, time management, prioritisation, learning (I consider it a skill), problem solving, testing, typing, to list but a few. My head is going to explode. 

It's not all bad

I'm probably complaining for no good reason. It's not like I have a hugely stressful, mundane or dangerous job. In fact I consider myself lucky to have a job that interests me and that I find challenging. In this industry, provided you have the right attitude and motivation, you never stop learning, growing and progressing. I'm rarely bored, and there's nothing worse than being bored. 

Tuesday, 15 May 2012

Writing my first iPhone app

Since I've just finished writing an iPhone app for the Teesside basketball league I thought it would be a good time to write about some of my experiences of iPhone development.

Update April 2015 - Unfortunately the Teesside basketball league is no more so I have shut down the website and removed the app from the App Store.

A lot to learn

Professionally I'm a .NET developer, so my main language is C# and the IDE I use the most is Visual Studio. Obviously this is on a Windows machine. So from the outset I had a lot to learn. How to use a Mac for starters, then on to Xcode, Objective-C and the iPhone frameworks. It was more than a little bit daunting. 


I've spent a significant amount of time using other very good IDEs such as Eclipse and Visual Studio so Xcode had a lot to live up to. I felt it held up pretty well. Code completion, code analysis, version control integration, iPhone/iPad simulator, all good stuff. Refreshingly it's also very quick. Admittedly the project I'm typically loading isn't very big but Xcode typically loads in a matter of seconds rather than the minutes I wait for Visual Studio to start. 

When downloading Xcode you don't just get the IDE, it's a suite of tools. Interface builder used to be a separate application but as of version 4 it's integrated into Xcode. I like it. It's not quite as simple as dragging and dropping UI elements on to a view as I'd hoped but it's arguably easier than having to understand HTML and CSS. Out of the box you also get various 'instruments' to help analyse your application. The leaks instrument is the only one I've used so far, and it's very useful. Having something like this out of the box for a .NET web application would be great.

It's not all good though. Perhaps I'm a little spoilt by Resharper but the refactoring and code generation features in Xcode are a little lacking. It's hardly a showstopper though. Another negative is that it's quite error prone. I've experienced numerous crashes. So much so I've got into the habit of using the save all shortcut every minute or so. The handling of folders frustrated me a little as well. I like my projects organised in a nice clean folder structure where every file has it's place. As far as I can tell there's no way to create folders within Xcode. You can only create 'groups' which look like folders but only exist within the IDE. The only solution that I could find was to create folders manually and drag them into Xcode. 


Sweet Jesus, its a sea of square brackets! That was my first thought when seeing some Objective-C, which is entirely justified because there are more square brackets that you can shake a stick at. It's fair to say that I found the language quite difficult to get into. There's the aforementioned square brackets confusing my brain, pointers, memory management, strange method names and header files. But, you know what, after a bit of practice it's really not that difficult. The square brackets are used to call methods, or rather send messages, to a class. My fear of pointers was entirely unjustified because in Objective-C is a non issue (in my experience so far anyway). All you need to remember is that object types must be declared as pointers. That's it, there's no pointers to pointers or dereferencing. As of iOS 5 with the introduction of ARC the memory management isn't particularly tricky either. How about the strange method names? Well, they actually make quite a lot of sense when you think about it. So all in all, aside from some syntactical strangeness it's not a bad language to work with.

Was it worth the time?

Someone asked my recently why I was developing a native app rather than a HTML 5 app. Good question. I'm not convinced it's a particularly good reason but web development is my job and I'm pretty sick of trying to create web sites that work in multiple browsers. So the idea of writing a mobile web app that will function reasonably on approximately a gazillion devices, in my own time, makes me feel a little sick. All I want to do is write some code. Partly to try out new techniques and ideas. Partly to learn something new. And partly because I believe building an application, particularly on an unfamiliar platform, is a great way to learn. For this reasons writing a native app was a no brainer for me. 


To learn Xcode and iPhone development I highly recommend Paul Hegarty's Stanford lectures. They really were incredibly useful. In terms of books, I can't recommend any in particular. I bought a couple, one on Objective-C and one on iPhone development. But, due to a combination of a huge amount of free online documentation and the books only covering a small subset of what can be done on the iPhone, I've hardly used either. 

Other than the Stanford lectures a few other resources I found useful were:

Monday, 7 May 2012

Using variables with Seleium IDE

Testing part of the application I work on involves filling out a fairly long registration form. I've been using Selenium IDE to make my life easier but I still have to change a few fields before I can submit the form. I.e. Email and username, because they must be unique. I normally add an ever increasing number to the end of the fields which doesn't take long but it annoys me that I still have manual steps. So I wondered if it is possible to use variables in the test script. Turns out it is. 

The 'store' command saves a variable. Confusingly, for me at least, the 'target' is the variable value and the 'value' is the name of the variable. Once the variable is declared it can be used to populate other fields using the syntax ${variableName}.

The image below shows an example. I've created a variable called testNumber which is used to populate the Email, EmailConfirm and Username fields with unique values.