Wednesday, November 18, 2009

Objective-C Object Instantiation

Today we'll go over the syntax to create an instance of a class.

In Java (and C++, to dynamically allocate an instance of a class), you use the new keyword. Objective-C's equivalent is the alloc keyword.
I wish I could say that's the end of the story, but there is a bit more.

As in Java and C++, a constructor, and its superclass' constructor, and the superclass' superclass' constructor, and so on, are called in order from superclass to subclass to its subclass, etc.
In Objective-C, constructors are called initializers, and you can consider the init: method to be equivalent to a default initializer; i.e. one that takes no arguments and is supplied by the compiler unless you specify one yourself.

What if you wanted to create initializers that take arguments? By convention, it's recommended to:
  1. begin the initializer name with init
  2. name the initializer to include the word "with"
An example might be on a Person class: initWithGivenName: (NSString*) name
Another convention is that the initializer initializes only the attributes that need to be initialized, and any other values can be set w/setter methods or through other means.

Return type
A"gotcha" compared to C++ and Java: the return type on these initializers have a return type of (id), not the name of the current class.

Designated initializers
Objective-C has the concept of a designated initializer. This is defined as the one that guarantees that all instance variables are initialized. While your subclass does not necessarily have to invoke a designated initializer on its class, it eventually must call a superclass' designated initializer. NSObject, the superclass of all classes, which is similar to Object in Java, contains a designated initializer called simply, init:.

What to return in an initalizer
An initializer either returns "self" which is like "this" in Java and C++, upon successful initialization, or nil if a failure occured.

Ok, so how do I put this all together?
Although you could make two separate calls and "throw away" the value of alloc, it's not recommended. The convention is to chain the calls together on one line like this:

SomeClass *pointerToSomeClass = [[ SomeClass alloc] init];

Saturday, September 19, 2009

Agile 2009 summary

I guess it's better late than never, but here's some of the highlights from Agile 2009.

Clean Code Craftsmanship by "Uncle Bob" Martin
This was an excellent talk about software craftsmanship; some of the points that I particularly enjoyed:
  • Plans are useless, but planning is indispensable.
  • In software, cost of change is low, so the later you think about them, the better.
  • No grand redesigns.
  • The only way to go fast... is to go well. Basically, you have to put in quality, which contrary to popular opinion, does not slow you down but in fact allows you to go faster. Code doesn't rot; we make it that way and it's our responsibility to keep the code clean.
  • Green band: Uncle Bob wears a green wristband to remind him to always keep the code clean, and you can get one here.
  • TDD: By following the three laws of TDD, you can always have clean, simple, testable code.
  • Most attendees had short iterations of either one week or 2 weeks. Uncle Bob said that perhaps when he asks again next time, iterations may be even shorter!
Debugging Pair Programming by Matt Wynne
Although I couldn't stay for the entire session, since I had to leave to prepare for another day of Programming with the Stars, I thought the session started out okay by identifying the benefits of pair programming.
  • High truck number: I've never heard of this phrase before this session. Basically it means that when you pair, you are spreading the knowledge so that it's not just one person who's the expert as in most traditional projects. So if that expert were to get hit (god forbid) by a truck, the team would still be okay. So you can have more people hit by trucks, and the team can still function.
  • Free training
  • Instant code reviews
  • Team building: cheaper than going out for paintball, and less painful.
Each table had a large sheet of paper, some sticky notes, markers, and a persona. This persona was basically someone that may or may not have heard of pair programming, and listed their reasons for not adopting it. Our goal was to list the reasons why they may be afraid to adopt pair programming.

My first table was fine since everyone took a sticky and shared their thoughts. Then we were asked to keep one person at the table, and everyone else move to another table. The person remaining was to explain what we talked about and then discuss how to overcome those barriers.

So, at the second table, I think because there were no moderators, each discussion ended up turning into arguments. Also, some participants' views were not being recorded since the sticky notes weren't being used and it seemed like the guy at the table was filtering out comments. It may have been unintentional but it would have been good to get everyone's input.

Originally, I had recorded the audio on my iPhone, and I was going to listen to the whole thing and write down the key points but I think it's unnecessary now since I'd be repeating what everyone else has already written.

To sum it up in a few sentences: basically with integration tests, you end up with a lot of duplication. The tests become slow and brittle, and as we all know, slow tests end up not being run. We want to make sure that in our unit tests that communicate with collaborators, that we are:
  1. mocking out the collaborators
  2. making sure we are sending messages (parameters) that they can actually handle
  3. ensuring that they respond the way we think they do
This is done with collaboration and contract tests.

This is not to say acceptance tests are useless, because they test the entire system from end-to-end. It's that with the right collaboration and contract tests, you do not need to write any integration tests, and therefore, keep your tests DRY.

I was lucky enough to be selected as a participant in Programming with the Stars 2009, and the star I was paired with was James Grenning, the creator of planning poker and an expert at TDD in C and C++, especially in embedded software.

First day
The first day, we were tasked with refactoring existing code. I hadn't programmed in C and C++ in over 5 years, so I had a lot of catching up to do. Thanks to James, I was able to get up to speed in running unit tests, refactoring, etc in Eclipse. We were given only 3 minutes to perform. When you're up there pair programming in front of a live audience, the time really flies!

Day 2
We made it to day 2, where our task was TDD from scratch. It was another exciting day, but both James and I performed on an empty stomach since the competition was far away from lunch. We were given 5 minutes this time.

Day 3
Somehow, we survived day 2 and made it to day 3, where our task was a 6-minute SDD performance. We used FitNesse and CSlim to show the development of a home automation user story. I was amazed at how FitNesse could integrate with so many languages.
It was a close call this day, as we were in the bottom two pairs, but thanks to the audience, we were saved.

Final Day
The final day's assignment was a 6-minute freestyle performance. There was a coin toss to see which team would go second since throughout the competition, it seemed like going first was a disadvantage.

So it would be the team of Gerard Meszaros and Ola Ellnestam, or Grenning/Chien. The non-star partners were called up to call heads or tails. Ola called tails, but during the coin toss, it hit the podium and I called "interference." :)

James and I decided to recap what we did throughout the whole week. Some of the judges liked the idea; others didn't. It was okay; we were only down by 2 points. After the scoring,the audience was asked to vote by writing down their score, from 1 to 10 for each of the pairs. While that was going on, the bonus round was announced: write "Hello Programming with the Stars" to the console using any language, but with the following conditions:
  1. Leave the computer in its current state
  2. Disable the mouse
  3. The star can only type with his left hand, typing only the keys that the left hand normally types. The other partner has to type with his right hand, typing only the letters/keys that the right hand normally types.
While Meszaros/Ellnestam were performing, the audience's votes, averaged and multiplied by three gave Meszaros/Ellnestam an additional lead of three more points.
James and I were thinking of what language to use and decided on C. I had already typed it up and executed it on my personal laptop, using vi and the terminal.

However, when we went up there, I was confused since we wrote it in Eclipse. Although we finally figured out how to run the program, we were a little too late. The other team finished in 1:28; we finished in 2:49.

Although we ended up with second place, I thought the entire competition was a lot of fun. It was great working with James Grenning, and meeting the other stars and competitors, as well the hosts and judges. I learned a lot, and it was an experience that I'll never forget.

Overall summary of Agile 2009
This was my first time attending an Agile conference, and I really enjoyed it. I made a lot of friends, learned a lot of new things, and I'd definitely recommend going to this conference if you've never gone. Hope to see you next year at Agile 2010!

Friday, June 12, 2009

We're back!

Geekyninja is back, after a long hiatus! I'll be blogging both here and at Critical Phase. Check out my new entry regarding Spring MVC 2.5 and all that annotated controller goodness: Fun with Spring MVC 2.5 Annotations.