In mid March – after a weekend working on a project, I set the alarm for 6am so I could be one of the first to register for WWDC.  Of course that is not a requirement these days with Apple providing a lottery system for tickets to their conference.  However the buzz of repeatedly pressing refresh, checking Twitter, and making sure my credit card was ready did add to the excitement.

 

Less than a week later I got the email.  I was going to my first WWDC.  I was a little suspicious as it was April Fools Day, but I checked the next morning and I’m pretty sure that I’m all registered.  And certainly my credit card got hit with the registration fee as expected.

 

The first challenge was flights and accommodation.  From New Zealand to San Jose is a little challenge.  Two flights, but one of those is about 13 hours. To ensure I didn’t miss out I booked the flights and hotel as soon as the dates and location were announced.  All booking could be changed if I didn’t win the lottery, so a little more expensive, but I had those two important aspects all sorted.  As it happens I am very relieved – my hotel is just a couple of minutes walk away from the conference centre, so very convenient. 

Ok, enough of the mechanics of tickets and travel.  What do I expect from WWDC 2017?  Actually I have no real expectations.  I am prepared to be surprised, informed, educated, and entertained.  But there is no wishlist that I have for features, tools, products, or hardware that I am expecting to be announced.  There is a lot of noise out there about new hardware and hopes for new features.  But a lot of it is just guesswork.  

 

And, also, it is all part of the journey that Apple provide their users.  The software in WWDC supports the hardware released later in the year which is enhanced by the software released in the next WWDC and so on.  There have been quite a few times where a Swift feature or framework is released that doesn’t quite make sense until the new iPhone is release later in the year.  At least with software Apple have more control over leaks than they do over hardware.

 

So, next up will be a summary of WWDC.  Watch this space.

As I noted previously I am working through the Big Nerd Ranch books on Objective-C and iOS development.  One of the good things is that all of the  iOS programs used as exercises are started as empty applications.  This means they are built up from nothing but an Application delegate – no storyboard, no XIB file.

It’s taking a bit longer than I had planned so I have ended up having the Xcode development environment being updated to Xcode 6.  The next time I started one of the Big Nerd Ranch exercises I was a little lost – no more ‘empty application’.  The closest option had storyboard and a launch screen XIB, lots of things that were not needed – well, at least in terms of the exercise.

Fortunately other people have had the same problem so thanks to Team Tree House who had a post on their forum reporting the same issue and the kind person who posted a comment there which pointed to Code From Above who clearly detailed how to remove the ‘offending’ additional components from the Single View Application.

All back on track for more learning.

How do you learn a new programming language?  How to you learn anything new for that matter?

I usually start by reading and researching – web sites, books, manuals.  Anything I can get my hands on.  But there comes a point when you need to get your hands dirty.  Doing is a great way of learning.  And when it comes to learning a programming language the only complaint you will get is from the compiler reporting a syntax error.  No real harm there.

So what I was after was a series of exercises that would take me through developing a program in Objective-C and iOS.  And I found an easy winner fairly quickly.

The Big Nerd Ranch books are an excellent choice.  I have lost count of the number of times I have created a new empty iOS application and then created the first UIVIewController and so on.  Almost always hand coding from scratch, though they cover the Interface Builder as well.  Repetition is a great way to learn.  I have both the Objective-C book and the iOS book.  I have been working through both of them in parallel.

I have yet to find an error nor any explanation or instruction that was hard to understand.  A few times I have repeated the exercise to make sure I understood what they were suggested.  I have also eschewed their instruction of always using BNR as the class prefix to save confusion (or compilation/build errors).  I have a fair idea where and when I need to change BNR to my own prefix – and it keeps me on my toes.

So far I have about half way through both books.  Its taken a while, life has got in the way this year.  But small steps in progress regularly has certainly paid off.  I am confident that if I ever had to write a loan amortisation program, I would be able to do a better job …

I have had a few mobile phones in my life – from one that had an aerial that always protruded and weighed my jacket down (UNIDEN, as I recall); through to a small, silver, Alcatel, with a very cute alarm tone; and now the iPhone.  Of all of them the iPhone is the only one where I had the opportunity to program it.  That was never really a consideration when I decided on the iPhone.  I just wanted a phone that worked, and had these new-fangled ‘apps’.

My inspiration was when I downloaded an app for working out mortgage repayment figures.  It was the sort of thing I was calculating regularly when I was studying so to have an ‘app that did that’ sounded a great idea.  The app was disappointing, if you played nice it would work out the right figures.  But it usually had a random number of digits after the decimal point.  And any suggestions invalid data resulted in “NaN” or a weird error on the screen.  Fortunately the app was free.  It was removed from my phone shortly after.  (No, I won’t name the application).

So now I want to develop some apps.

This blog will details how I am learning, what I am learning and some useful links I have found.  It will, eventually, describe the apps I have developed.  My approach to software development in general is to break problems down into small manageable chunks and to solve those problems before putting things together.

There was a post (via Reddit) entitled “Software Dev Without Estimates, Specs or Other Lies” which resonated with my experience of committing to an estimate based on a vague notion of the solution.  Unfortunately the link is now dead and I am sure that software estimation is worthy of a blog post of its own.

So for now, lets say that the time required to develop my ‘apps’ is not important.

Next time, I’ll detail my approach to learning.