Flatiron School Week 4 Mistakes and Lessons

Topics: Cocoapods, Core Data

Symptom: The search functionality works most of the time but in a small set of users, the search results are empty.

Mistake: Sending an API call in the prepareForSegue method.

Let’s say that we have a view controller that searches Foursquare for restaurants. If I press submit on my search view controller, I’m pushed to a table view controller with the results. I can put the API call to fetch the data from Foursquare in the prepareForSegue call.

99.5% of the the time, it works, but the other 0.5% of the time, the previous view controller can be removed before our API call has come back with the results and we’ll be left with a table view controller with no results.

This is called a race condition and it’s a very annoying problem to fix because it’s hard to detect and I would have to have millions of users like Facebook to have this problem.

With search view controllers, pass the query to the results view controller and send the API call from there.

Lesson: Avoid race conditions always.


Symptom: I was trying to test a tableViewController to make sure that it worked with Core Data by adding 3 test objects: @”Test”, @”Test Test”, and @”Test Test Test”. I was only seeing one of the three items repeated three times.

Mistake: Messing up basics when moving on to more advanced topics.

I wasted a couple hours last week when I messed up the cellForRowAtIndexRow by writing

cell.textlabel.text = self.store.pirates[[self.tableview indexPathForSelectedRow].row];

instead of

cell.textlabel.text = self.store.pirates[indexPath.row];

Lesson: Watch for simple mistakes, when something is not working as expected.

Week 3 Mistakes and Lessons

Topics this week: TableViewControllers

Symptom: When I see an empty table view controller, this is usually the culprit. 

Mistake: Forgetting to initializing the array in a table view controller.

Lesson: always initialize the array.


Symptom: The dreaded Apple Mach-O Linker Error. Linker command failed with exit code 1. This error is super intimidating because it’s so cryptic. (What the heck does that mean anyway?)

Mistake: Turned out that I had imported a KIF test file “TableViewControllerSpec.m” into another TableViewControllerSpec.m and it was giving the errors:

duplicate symbol _OBJC_METACLASS_$_TableViewControllerSpec ...
duplicate symbol _OBJC_CLASS_$_TableViewControllerSpec ...

Lesson: Don’t quit when you hit error messages. Read the logs, it usually gets you close to the problem.


Symptom: Realizing that the full solution to a problem is not worth implementing and not having the previous version. 

Mistake: Deleting code when it’s a partial solution to go for a full solution.

Lesson: Commit code before trying an experimental solution.


Symptom: Tests fail sometimes but not all the time.

Mistake: Not resetting the test conditions after each or before each tests. Test do not go on in order in KIF.

Lesson: Check the starting condition each time before a test is run. Resetting the tester is cool.

Week 1 Mistakes and Lessons

Topics: Git/Github, Environment Setup, Objective-C basics (loops, methods), unit testing, NSArray, NSDictionary

Mistakes and Lessons

1. Mistake: Going directly into Xcode with a half-baked plan leads to a lot of spinning my wheels and rabbit holes.

What happens here is that I think I know what I want to do in my head, sort of, but I don’t have the steps explicitly worked out yet and so as I write, I concentrate on one part of the program and forget details that I hadn’t accounted for in the other parts. Any thing that I find myself doing is just spamming different code and praying for it to work. I’m using the computer to validate for me instead of having a plan and running code that I think will work.

Lesson: Know how to do a task without a computer before trying to tell a computer to do it.


2. Mistake: not paying enough attention to spelling.

Spot what’s wrong with this for loop:

for (NSinteger fiboCounter = 1; fiboCounter < numberInFiboSequence; fiboCounter++)
{
    NSNumber *currentFiboNumber = fiboNumbers[fiboCounter];
    NSNumber *previousFiboNumber = fiboNumbers[fiboCounter - 1];
    NSInteger nextFiboNumber =  [currentFiboNumber integerValue] + [previousFiboNumber integerValue];
    fiboNumbers[fiboCounter+1] = [NSNumber numberWithInteger:nextFiboNumber];
}

Yeah, that’s right. It’s the NSinteger in the first line. It should be NSInteger.   I was getting missing identifier errors for the fiboCounter, which totally didn’t make sense, because I had already initialized it (I thought).

Lesson:  Misspelling sucks, listen to Xcode.


3. Mistake: thinking that doing everything by myself is more original and superior to copying other people’s way of doing things.

First of all, pretty much nothing is completely original.

Everything is a remix of previous things made. Why would you want to ignore how other people are doing it anyway?

“If I have seen further, it is by standing on the shoulders of giants.” 

-Isaac Newton

Even this quote proves my point. Newton was a smart guy, probably on of the few that actually did make significant advances in science. Despite that, the idea of “shoulders of giants” wasn’t original to Isaac Newton. He was preceded 500 years earlier by Bernard of Chartres.

When I first approach a problem, multiple ways of solving the problem will appear in my mind. If I was working alone, I might implement one and then try another one. The benefit of having a class of people who are working on the same problems means that I can crowdsource other solutions from them. They can teach me smart methods that I didn’t even know existed and I can learn 19 new methods in the time it would take to learn one.

Pair programming is another great way to learn from classmates. I might have my way of doing it, but pairing means that I must contemplate another person’s way as I am still solving the problem and can follow it all the way through. An additional benefit is providing motivation to finish and having someone to celebrate with when we’re done.

Lesson: Solve the problem one way and then rely on my classmates to give me other ideas for solving the same problem. Even better, pair with another person to program it, especially late at night.