Code Organization in Xcode Projects

Xcode does not impose any structure to your source code tree. This is both cool and useful to quickly throw a couple of lines for a prototype, but in my experience, this approach does not scale. More often than not, without any hygiene, your project can become a mess. Just using Xcode defaults, after a while your resources will sit beside your .xcodeproj file, all the project classes will be thrown together in the Classes folder, and if you have a relatively large project, this approach makes finding individual files painful.

Of course, Xcode provides “Groups” to organize your source code, but the idea is to be able to quickly identify the different kind of files that make up your Xcode project, either for Mac or for the iPhone, without having to open the Xcode project file. This means having both a folder structure, and an internal source code file structure. All of this will help you maintain your project in the future, which means cheaper costs, and less time spent looking for bugs.

All of this is also particularly useful when browsing projects via Google Code, Github or any other kind of file view of source code repositories. If your code is organized in a nice folder structure, it is easier to explore than if all the files sit in the same folder.

In this post I will enumerate some best practices that I use in all of my projects. Continue reading

Objective-C Compiler Warnings

A recent comment by Joe D’Andrea in a previous post reminded me about the importance of removing compiler warnings in Xcode projects. Most importantly, it reminded me of a conversation with a fellow developer a couple of weeks ago, in which he told me that he was surprised to see that my projects compiled all the time without warnings. Not a single one. Nada. And that I took the time to remove them before checking code into source control.

He actually didn’t know you could remove all compiler warnings; he thought Objective-C was the land of compiler warnings. This situation, I think, is far from exceptional, and due mostly to cultural and technical reasons.

It is my opinion, that removing compiler warnings is basic project hygiene, like writing unit tests, or using the Clang Static Analyzer. I will explain in this post some techniques I use to remove warnings in my Objective-C code.

warnings2 Continue reading

Myself on the Swiss Press

This is something that does not happen that often to me, so it deserves a blog post of its own: here’s two appearances of yours truly in the Swiss press last week. The first one is an article in the Tages Anzeiger of last Wednesday (full text available online), and the second one is an article (with photo) on the SonntagsZeitung last Sunday. Since the SonntagsZeitung article is not available online, here’s the scan of the article.

Yay! :)

WWDC 2009: a message for Scott Forstall

I won’t go into details into all the stuff shown during the keynote; this is just a single comment for Scott Forstall: STOP THE BLOODY DEMOS. Last year it was pretty unbearable, yet this year you managed to make it even worse.

Thankfully I am not the only one who thinks that the interminable series of demos is just a waste of our time, when all we want is to see new stuff in the SDK. We’re developers, not marketing people.

Quotes

A small compilation of quotes I’ve put below the header of this blog during the past few years:

  • No vemos las cosas como son. Las vemos como somos. (Hilario Ascasubi) – We don’t see things as they are; we see them as we are.
  • Don’t be afraid to try something new. An amateur built the ark. Professionals built the Titanic. (unknown)
  • Compatibility means deliberately repeating other people’s mistakes. (David Wheeler)
  • Cuando uno se compromete con lo que piensa, y encima piensa cosas que cuestionan lo incuestionable, es de esperar que haya alguna dificultad. (hernún) – When you stick to your ideas, and on top of that you think about questioning what’s out of question, it’s likely there’d be some problems.
  • The definition of insanity is doing the same thing over and over and expecting different results. (Benjamin Franklin)
  • Most people are fools, most authority is malignant, God does not exist, and everything is wrong. (Ted Nelson)
  • sin incertidumbre no hay novedad, sin novedad posible no hay más que repetición y, por lo tanto, negación del otro como un ser libre: el ser libre es un ser incierto. (adrian mancuso) – without uncertainty there’s no novelty, without novelty there’s only repetition and, therefore, negation of the other as a free being: being free is being unpredictable.
  • Software is like entropy. It is difficult to grasp, weighs nothing, and obeys the second law of thermodynamics; i.e. it always increases (Norman R. Augustine)

Going Github

This is something I’ve been looking forward to do for some time. After praising git back in 2007, now I’m moving many of my personal projects to Github, which has an absolutely brilliant service! For the moment I’m using the free account, but I will most probably switch to a paid account soon. The only thing it lacks, in my opinion, is a bug & issue tracker as you have in Google Code repositories, but other than that, it’s simply perfect.

So feel free to check out the projects I’ve moved there, and of course, to fork them and enjoy the code as you see fit.

Best books of 2008

You might remember my beloved mantras: learning a new programming language and reading at least 6 relevant books every year. Following the 2007 edition, here’s the list of the 8 books I have enjoyed most in 2008, ordered by a purely subjective and absolutely irrational decreasing preference. I strongly recommend all of them!

Winner: Geekonomics: The Real Cost of Insecure Software by David Rice

Runner-up: The No Asshole Rule: Building a Civilized Workplace and Surviving One That Isn’t by Robert I. Sutton, PhD

And 6 more:

Continue reading

Dangers of Prototyping

Frederick P. Brooks Jr. has written about prototypes, saying that they are not only useful but strictly fundamental pieces of the overall software process, as in many other engineering activities. He gives the example of a pilot chemical plant, prepared to process 10’000 units per day instead of the 2 million units a day that the final plant would have to handle, in order to demonstrate the feasibility and uncover some unforeseen problems.

He summarizes his opinion in the famous phrase “plan to throw one away” (Brooks, 1995, page 116), underlining the problem of change management: managing change, right from the beginning of the project, instead of ignoring or avoiding it, is particularly important in software projects, since it presents a solid mindset for all stakeholders in order to avoid scope creep, schedule and staffing problems. Continue reading