New Year, New Project

In order to get my Swift skills leveled up, I decided to start a new project called LifeList. I'm a birding enthusiast, and any serious birder will have a Life List of all the birds they've seen over their lifetime. I thought that creating an app to help me with that goal was something that was achievable and would keep me motivated.

I also wanted to apply the Apple suite of testing tools to see how they've progressed and how well they all work together. I started writing a few unit tests, all went well there. I also wrote a single UI test after finding a crash. It was nice to recreate the crash in a test, just to make sure it didn't happen again! It also led to extracting out some common code and wrapping it in a unit test.

I turned on Code Coverage for my app's scheme. That was a nice addition! Now I could see where I could/should be focusing my testing efforts.

However, I'm kind of a lazy programmer. I got tired of re-running all the tests all the time. But I know running all the tests at some point is valuable, I still wanted feedback if I broke something. I just didn't necessarily want to take the time to do it!

So I ended up installing Server on my laptop and setup an Xcode Bot to 

  1. Clean up old build artifacts
  2. Build the app
  3. Run a static analysis
  4. Run the tests
  5. Consolidate the results (including code coverage) in a nice report

Its nice to be able to push code changes and within a few minutes know that I haven't affected the health of the app. What's better is that all that information is just a click or two away in Xcode!

On the surface its kind of strange to setup Xcode Server and do all this continuous integration and testing for a one man team. However, in another way it might be even more vital. I don't have anyone else around to do any of this work for me, and I want to spend most of my time actually writing code! We'll see how this setup goes as the project progresses.


CocoaConf Boston

I recently had the pleasure of attending CocoaConf Boston.  I've been to other iOS/OSX conferences before and the technical lessons I've learned were valuable, but they were very sterile.  What stood out at CocoaConf was the sense of community.  

Daniel Jalkut's keynote lead things off with a call to improve your attitude and to be more social, and I think that really set the tone for the conference as a whole.  That night Guy English made a roomful of developers laugh as he recounted his frustrations with the PSP, but he reminded us that we all need to recharge our own internal batteries once in a while.  Afterwords, James Dempsey and the Breakpoints sang about MVC and leaking memory.

Daniel Steinberg made us all cry the next morning with a story that you'll have to hear from him sometime if he is willing to tell it.  Neven Mrgan actually admitted that its OK for engineers to do design work sometimes.  And I guess that means I have to allow designers the freedom to do some engineering every now and then!  Daniel Pasco talked about his journey in starting and overseing the development of Black Pixel.  Each of these sessions really let you tap into the experiences of the presenter and get to know them as real people.

There were roughly 100 developers that attended.  Over lunches, dinners, drinks, etc I felt like I got to hear a majority of their stories as well.  In my current organization, I am the only iOS developer so it was nice to talk with people who have shared some of the same technical and professional experiences.  Plus it was nice to crack a few Android jokes every now and then.  I even ran into a friend of mine from college who is trying to get into iOS development full time.

My one piece of advice for the CocoaConf team is to keep each event small!  That for me was one of the biggest differentiators as opposed to WWDC, Apple's Tech Talks, etc where you feel like just one developer in a giant sea of people.  Do whatever else you have to, but try to keep that sense of community.

I encourage you to check out their website and see if one of their events is coming to your area soon!


Use Storyboards for Your Next iOS Application

A Sample Storyboard  XCode, Apple's tool for developing iOS applications, recently added a great new feature called Storyboards.  Storyboards are analogous to their counterparts in the movie making industry.  They are made up of two major pieces: scenes and segues.  Each scene represents what the user sees on screen, while segues represent transitions between those scenes.

  In this very simple example, there are three scenes and two segues.  The scene on the far left represents a Navigation Controller.  Its job is to manage the other scenes in the application.  If you've ever used an app with a title at the top of the screen and information sliding in and out of view from left to right, you've used a Navigation Controller.  The small arrow pointing at the Navigation Controller indicates that this is the first scene that will be displayed when the application is loaded.

  A segue connects the Navigation Controller to the next scene in the Storyboard, which happens to be a Table View Controller.  Table Views are the name given to the scrolling lists of items that are found in just about every iOS application.  This segue indicates that the Table View Controller is the scene that the Navigation Controller should automatically load after it is created.  Another segue connects the Table View Controller to a generic View Controller that might display details on an item from the list on the previous scene.

  A typical iOS application will have many more scenes and segues than this simple example.  Also, each scene will have much more content and stylistic elements applied to it.  However, no matter how many scenes and segue an application has, they are all contained within a single Storyboard.  Managing all these scenes and segues in one place really helps to manage complexity from a developer's point of view, but that's not the only benefit to Storyboards.

  • Less Code - As a developer, the most reliable and bug-free line of code you can possibly write is the line you never write at all.  Through segues, Storyboards eliminate much of the code needed to create and transition between scenes.
  • Instant Design Documentation - Its not unusual for a developer to be required to document the design of the application that they are creating.  A screenshot of a Storyboard is a great starting point for such a document.  The Storyboard is also very useful as a talking point when talking about UI design decisions during the development process.
  • Reduced Development Cost - Both of the previous benefits ultimately reduce the time needed for development and maintenance.  Since a bulk of the cost of a software project is typically labor, using Storyboarding can reduce the cost of developing and maintaining your software.

 For more information on Storyboards, see this example from Apple.


Never Stop Learning

I've always believed that learning is a lifetime pursuit, and no industry brings that to the forfront more than technology.  About 2 years ago, I got started with the iOS platform.  I had some experience building mobile applications for other platforms, but I had never developed for OS X or written a single line of Objective-C code.

I dug into the tools (XCode and Interface Builder) and the documentation and essentially taught myself to be an iOS developer.  I used training tools and videos from Apple and attended a Tech Talk in Toronto, but reliable learning aides were few and far between.  The platform was less than two years old and the APIs to build native applications were less than a year old.  At times the process was slow and frustrating, but most of the time the exhiliration of learning something new and 'cutting edge' kept me going.

Recently, I started working through iPad and iPhone App Development on iTunes U.  You can read all the documentation you want, but there is still nothing like having the material presented to you by someone who knows what they're doing.  The instructor for the course, Paul Hegarty, has a rare combination of technical skill and teaching ability that really makes the lectures engaging.

 It's a great course and it has really improved my skills as an iOS developer.  Thank you to Paul for leading a great course and to Stanford for providing this and many other courses available through iTunes U!




Stephen Covey wrote an excellent book entitled The Speed of Trust which argues that the proper level of trust can be a key contributor to success in the business world and in life in general.  I highly recommend it.  It also got me thinking about how trust might apply to the process of software development.

In any software project, there is a developer (me) and a customer (maybe you!).  In order to make the project a success,  I have to trust that you know what needs to be done and you have to trust that I know how to get it done.  We document what needs to be done as requirements and I take care of the how part during the design, implementation and test phases.

However, how do we establish trust early on in the project?  In a traditional approach to development, the process begins with a long and drawn out phase of requirements gathering and estimation.

I've honestly always found this phase to be very nerve wracking and scary.  I know the least amount about the project at this point, but yet we want to often come up with an entire schedule and cost for the entire project.  That's hard.  As a customer, I can imagine that this is also a very scary time because you want to convey all the details of the project (which is much harder than it sounds) and you have little to no idea if I can really make good on my estimates.

This is where short development cycles (iterations) can really help.  We don't need to know every single detail about the project up front.  We just need enough knowledge to get started and a vision (nothing detailed) of where we want to eventually end up.  Short iterations also allow me to show you something of value within a few weeks.  This should give you more confidence that I can get things done.  It also allows you to take the product before a set of early adopter/alpha/internal customers and get feedback.  This really helps everyone know whether or not we're headed in the right direction or not.

So, do short iterations really lead to more successful projects?  I think they do, but until you try it you'll just have to trust me.