A Weblog by Ben Goodger

August 14, 2009

My iMac, which 3 years ago was state of the art, now struggles to build Chrome in less than an hour. Sad? No, that’s progress.

What is sad is that the current top of the line iMac is not much better - the best config iMac (3.06GHz/24″/8GB RAM) is still shipping with the archaic Core 2 Duo.

In 2009, now that the Core i7 is out, no one should be selling a high end consumer system powered by the Core 2 Duo - it’s junk fit for the garbage can.  And yet here Apple is charging $3200 for one. Not since the days of PowerPC has Apple been so behind in CPU horsepower.

Well sure you might say, the iMac is consumer grade not pro-grade - not meant for developers compiling software - that’s the realm of the Mac Pro[1]. But why not? When I bought my iMac in late 2006, it was actually the fastest thing you could buy full stop (except maybe for some crazy $1500 Xeons). I was buying something that not only looked good and was space saving, but something I couldn’t complain about when I used it for work. Intel’s kept up its end of the bargain, developing the amazing new Nehalem CPUs, which deliver simply astounding multitasking performance. But despite being available for almost a year now, Apple has yet to ship it in a consumer line system.

Where does this leave me? With a loud, ugly Windows workstation again. I am not happy about it. But it’s fast enough for me to get work done on.

[1] The Mac Pro might be a contender if it wasn’t so brazenly overpriced.  The Windows system I bought can now be had for ~$1500, a system whose Chrome build performance can only be matched by spending about $6000 on an equivalent Mac Pro. Come on Apple, not all developers are zillionaires comfortable with dropping the price of a brand new Nissan Versa (w/Cash For Clunkers) on something that will be a paperweight in a couple of years.

Eh?

PM flexible on anti-smacking law.

“[John Key] says if the law does not work and good parents get criminalised for lightly smacking a child, the law should be changed.

But he says it is hard to put up a case to change the law when no one has yet been prosecuted.”

So wait, some “good parents” need to be unfairly victimized by a law that by his own admission most of the country opposes before it can be repealed? How is that fair?

August 8, 2009

About two and a half years ago, I bought a 1964 ranch house on a hillside in Los Altos Hills, California. Ever since moving in, I’ve been thinking of fixing it. The house was neglected, dark, riddled with spiders and had a series of plumbing problems. Towards the end of 2008, I finally cracked the problem of how to effectively lay out the interior space, and in February I retained an architect to draw up my plans. More recently, I’ve set to work obtaining permits. The required modifications should now be in, and so I hope to get started soon. As premature celebration, I took to the sheetrock in one of the west wing bedrooms with a hammer.

Most recently, I’ve hired an interior designer to help with final finish selections and fixtures. My hope is that once complete this house will sparkle brighter than it ever has, even when it was brand new.

Once construction gets going, I’ll post photos and specs for the changes being made.

I noted with some interest this thread over at mozilla.dev.platform. The Mozilla codebase has historically included a variety of different coding styles, since style for a given file was left up to the person writing the code. The discussion caused me to reflect a little about what we’ve been doing in Chromium, especially since I spent a number of years working in the Mozilla codebase (at times contributing  a few strange experimental styles).

The Chromium project, having had the luxury of a clean start, decided to inherit its coding style guidelines from Google. We tend to use C++ for most of the application code except for the Mac front end, which uses Objective-C, for which Google has another style guide. We prefer not to fork third party components but rather develop improvements to them “upstream” in their respective projects, which retain their own style. The most notable of these is WebKit.

In the beginning, I found several aesthetic aspects of the Google C++ style not to my taste. However in time as the project has grown I found that having a uniform style across the entire codebase to be very soothing. You can go from user interface code to the bowels of the network stack and find the same style. It requires fewer subtle context switches. Because the Google C++ style tends to be very specific about a great many things, the areas where it is silent stand out more when there are variances. We’ve tried to document where as a project we’ve filled in some of these gaps.

One of the interesting things about the Google C++ style guide (the one I am most familiar with) is that in many cases it goes beyond the aesthetic, covering use of language features. Other projects like Mozilla cover this in their portability guidelines, but the Google C++ style guide makes recommendations for other reasons too. For example, multiple inheritance is generally banned, because it is easily misused to create spaghetti object hierarchies that are not easily comprehendable. In fact, more than a few of the style guide sections echo tips from Scott Meyers’ excellent “Effective C++”.

Having as large a style guide as we do, there do tend to be a lot of code review comments about conforming to it. Rather than being nit-picking though that obscures the larger benefit of the work, I actually think it serves that exact purpose - the larger benefit. We are mindful that our ability to rapidly prototype and ship new ideas is key to our relevance, and as such maintaining good hygeine is a key component of that. We want new-comers to get started quickly and old-timers to pursue larger changes efficiently. In the end, in my opinion it feels that the greater good of a uniform style far outweighs the value of an individual developer being able to use their preferred style.

I’ve reactivated my blog, now using WordPress and on a different hosting provider. I’ll use this space for things too large to fit in 140 character invective.