This was my third year attending the Open Source China, Open Source World Summit. The schedule was similar - a day packed of 20 minutes “keynotes” followed by a half-day round table (which I had to miss this year).

Over this weekend I found myself searching for a particular bit of data that I knew I had, well, somewhere. This prompted me to clean up some of my files and do some organizing. Since I always like learning how others solve these sort of problems, I figured I’d share where I put my digital stuff.

Since Kanchoo is getting to be a serious app, it’s time to make rewrite, refactor, and to adopt automated testing. How do you know whether your tests cover all possible cases? That’s hard, but you can at least verify that all your code is covered. Yes, today we’re talking about code coverage.

CoverStory is an awesome application for inspecting GCC’s gcov output. As you would expect from GCC, setting up gcov is easy and obscure. You need to:

• Add “-lgcov” to Other Linker Flags.
• Set GCC_GENERATE_TEST_COVERAGE_FILES to YES.
• Set GCC_INSTRUMENT_PROGRAM_FLOW_ARCS to YES.
• Run your app, then open the “Objects-normal” folder in CoverStory.

Let’s go over these steps in more detail. In Xcode, get info on the target you want to cover. Switch to the Build tab. Double click on the value of the “Other Linker Flags” setting.

Add “-lgcov”. OK. Now add two user-defined settings: GCC_GENERATE_TEST_COVERAGE_FILES and GCC_INSTRUMENT_PROGRAM_FLOW_ARCS. Set the value of both to YES.

Build and run. Now find the Objects-normal folder. The path is something like:

• CoverageExample/build/CoverageExample.build/Debug-iphonesimulator/CoverageExample.build/Objects-normal

Or in general:

• ${PROJECT_DIR}/build/${PRODUCT_NAME}.build/${CONFIGURATION}-${PLATFORM_NAME}/${PRODUCT_NAME}.build/Objects-normal

Open the Objects-normal folder in CoverStory: drag, drop, see the report, a summary showing the percent coverage of each file with a detail view showing the number of hits for each line in the gutter. When the hit count is zero, the line is highlighted in red.

Sometime lines of code were never meant to run: inconceivable, non-feasible. Mark these lines with COV_NF_LINE comments or mark a block with COV_NF_START followed by COV_NF_END. If non-feasible lines do get executed, CoverStory will warn you.

May your code be ever covered and your tests perpetually passing.

The problem with the Ruby on Rails community isn’t simply sexism, unprofessionalism, or ghetto-ism, but that Rails is, at its core, a culture which values individual ego more than community. David and his posse have purposefully encouraged a tradition of edginess, individual expression, one-upmanship, and disregard for such fluffy, fake egalitarian notions as consensus, inclusion and good manners. It is expressed in the take-it-or-leave-it, I-don’t-owe-you-anything objectivism that guides Rails framework development and even many of the businesses built on it. The result is a community which collaborates largely by aggressive competition and fierce meritocracy.

Slashdot just posted an article about using canonical URLs for URL shortening which does a bad job in my opinion of explaining the problem. So here’s a breakdown that I hope helps.

You can now run Sun’s Open Solaris images on EC2 without signing up for their beta program. The newly released “web stack” AMI includes Open Solaris 2008.11, Apache, MySQL and PHP:

Open Solaris 2008.11 + AMP
32-bit AMI: ami-c7cf28ae

The bad news is that there’s still some work to do if you want to run Ruby on Rails. The good news is that the most recent releases of Ruby on Rails (2.3) and Phusion Passenger (2.1.3) include patches that make it much easier to run on Open Solaris. There’s still some work to do and this article aims to give you all the steps needed.

My notes assume you have some experience with EC2, Open Solaris (or at least some Unix/Linux variant) and Rails. Please leave a comment below if anything is unclear.

This article was written using:

• Ruby on Rails 2.3
• Passenger Phusion 2.1.3
• Open Solaris 2008.11

The story we wanted to tell at ApacheCon Europe was the 10th anniversary of the Apache Software Foundation. Last Wednesday night, we had a cake and celebration. Plans are in the works for a similar party in Oakland at ApacheCon US this November. But aside from the official line, I wanted to share some other thoughts now that I’m back mostly over my jetlag.

How is the Apache Software Foundation different from GitHub? Why is it we do what we do?

I’ll be trying to answer those questions tomorrow in my ApacheCon lunch session, “The Apache Way,” which will be streamed live over the internet. My session is free but requires registration. So if you’re not at ApacheCon, checkout the time in your timezone and sign up.

Update: The session will actually start at 1:30 UTC+1 (or in your local timezone)

ApacheCon Europe 2009 is underway. The Hadoop and OSGi sessions have been packed, but I’ve been stuck in foundation meetings and unable to attend. If you’re not at the conference, you can watch the keynotes and selected sessions online for free. In fact, you can watch my session on Friday!

Following my article about twitter and irc, a friend asked me about how I manage my information on various social networks:

I kinda have an all or nothing approach to things. If I’m not going to do social networks, then I don’t want some old neglected pages out there, I want nothing. If I’m going to do this, I want to get on all the main networks, and have a smooth consistent web presence. I hope that can be done without having it turn into a full time job.

From my experience, keeping various social network profiles up to date can take a lot of time. There are generally two strategies:

• Do it yourself, generally by preferring one network or service over others
• Use an aggregator service

There are pros and cons to both approaches.