Wednesday
Nov202013

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!

Sunday
Mar182012

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.

Sunday
Feb262012

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!

 

Saturday
Jul302011

Trust

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.