I’ll be speaking at the Úll conference in Dublin, Ireland sometime during April. Thanks to Paul Campbell and Dermot Daly for the invitation, and thanks to Jim Dalrymple for talking me into it.

I got a chance to meet Paul at a four-hour lunch last week. He’s obviously both considerate and crazy enough to endure me talking for that long. Perhaps you are too.

If you like the content here at this website, my session will be like a really long-ass blog post. Except that you won’t have to read it. I’ll “perform” it live. Whatever the hell that means. Now I just have to finish writing it before I show up next month.

Of course, there are many other fine folks speaking at and joining in the conversation at the conference. I look forward to meeting them all.

See you there.

I meant to write this article a few weeks ago when I was on a roll here. In the meantime, life intruded with several distractions — some serious, like another illness for our 15-year-old Labrador Retriever, Penny. That situation caused me to completely unplug from the Internet for a few weeks to focus on her recovery. Penny is much better now and I’m trying to get back to that original thought.

Like me, many of you probably read Jacqui Cheng’s article on Ars Technica, “Does Apple really assign engineers to ‘fake’ projects as a loyalty test?” Her article was a response — a refutation, really — of a meme that wouldn’t seem to die.

Once you get past the overly dramatic headline, it’s a well-written, thoughtful piece with actual research, sprinkled with quotes from real people who know what they’re talking about, including a tweet from my friend Daniel Jalkut. Props to Ms. Cheng for being an honest-to-God journalist and doing the hard work on this one.

The conclusion to the article is, of course, “no,” Apple doesn’t do that.

And I can also confirm that’s the case. As a manager and then director at Apple for over 10 years, I never once assigned anyone to a fake project. And loyalty tests? I never heard of either practice there.

So, how do silly ideas like this stay alive? It’s because many don’t understand — even at a basic level – how Apple works.

A qualification for that understanding doesn’t require employment at Cupertino. I doubt very seriously if John Gruber, Jim Dalrymple or Horace Dediu — none of whom have ever worked for Apple — fell for that original story.

I picked those three folks as examples because all of them — as far as I’m concerned — have a good track record of discerning Apple’s motives and interpreting the company’s actions. There are certainly other people out there like those three, but sadly it’s a small number compared to the legion employed as media gas bags.

Anyway, here’s a lesson for the gas bag army — not that they’ll really take it.

As I’ve mentioned here before:

… at Apple, we defied business orthodoxy by being a functional rather than divisional organization. Meaning we were organized by product focus like a much smaller company, rather than in discrete business units like some the size of IBM or General Motors. It certainly staved off the complexity of duplication that continues to plague other companies.

This isn’t some insider scoop I gave away with that post. It’s been obvious to people on the outside for years.

Clearly, duplication of effort is not big in Cupertino. Even with two operating systems — iOS and OS X — the idea is to share technologies that make sense and keep those technologies from diverging too much. Otherwise it becomes really complicated to coordinate releases. It’s not perfect, but anyone who’s attended an Apple developer conference knows the company takes reducing even that kind of duplication seriously.

Which makes the idea of fake projects so ludicrous. That’s not even duplicated effort. That’s completely superfluous work. When you have a focus on efficiency like Apple, why would you waste time and resources doing that?

Apple is also known for having very high standards when it comes to hiring. And it’s clear that those candidates who make it through the interview process, are offered a job, and finally accept employment — well, those folks really want to be at Apple.

It’s also common knowledge that Apple keeps what they’re working on a secret until it’s unveiled to the public. There are very explicit rules for employees — told to them on their first day of their employment or later disclosure on a specific project— about what they can say regarding that project and to whom they can say it. And it’s very clear to everyone what happens if those rules are broken. Such a policy is probably not that much different from what other technology companies have these days. This is old news.

Now, if Apple is going to screen candidates so thoroughly and then explain the rules to them so carefully after they’re hired, what is the point of an additional loyalty test?

None. It’s a stupid idea. Not only stupid, it’s insulting to the person you just hired. And basically an excellent way to demotivate the person you invested so much time in finding.

So much of what is written about Apple these days is just horseshit meant to draw flies. And it makes me sad that somebody had to clean up after that particular pile.

Today is the one year anniversary of my last day at Apple. It’s Sunday now but it was a Friday back then. And that evening I was given a very warm sendoff by my crew and many others at The Fruit Company.

Several folks on the Safari and WebKit teams produced a video in order to more thoroughly embarrass me. Which didn’t work because I’m beyond embarrassment. But the experience was great. I loved it.

My wife and son joined me for the going-away party. I think it was a shock to my son to see how I was regarded at work. Of course, that didn’t mean he started respecting me at home but, hey, a man can dream.

Seeing all those folks that night — that last week, really — was so bittersweet. I still don’t know how many I’ll ever see again. If there’s one thing I miss most about Apple, it’s the people. They were always the best thing about the place.

Not that Apple was some kind of gulag, mind you. You got the chance to change the world there. And you did. Your work mattered. It was interesting and, as they say, challenging. Certainly no shortage of it either.

It’s Sunday night as I publish this. That means it’s a working night for most managers at Apple. Even more so for Director-level personnel like I was.

Why? Our veeps had to be ready for the big status and planning meeting on Monday morning and we had to be available to help them. Steve always had the meeting then. I assume to set the tone and the pace for the week. Good idea, really. I doubt that’s changed now.

It’s not like other folks there weren’t working nights and weekends too. Many of my engineers worked longer and harder than I did. It was a busy place. By our choice.

But I don’t miss any of the work.

What surprised me after I retired was not missing the control and authority I had, such as it was. My ego remained intact. And I didn’t feel diminished. I woke up February 18 without any minions. Of course, I woke up that morning without any obligations either.

Why did I retire? People often ask me that. When I’m feeling boorish I just say, “Because I could.”

The truth is I was done.

I accomplished far more there than I expected. And I had no dreams of greater power and glory, if such a thing were available to me. When I looked inside myself, I didn’t see ambition or even drive to continue. I’m not sure how that happened. Maybe I was just tired.

And when you’re responsible for so many people, you owe them more than that. Better to step aside and let others have their turn. So I did.

It’s not like I wanted to leave and start my own software business. People always assume I have some massive entrepreneurial spirit. But I’m not like that at all. At my core, I’m just a tinkerer who got very lucky.

I refer to myself here as a “recovering programmer.” That simply means I no longer pursue engineering as a primary activity. And that I’m self aware enough to know that I’ll occasionally fall off the wagon and start coding again.

But if there’s anything I do aspire to, it’s being a writer. So far it’s been hit and miss with maintaining that activity. It turns out writing is even harder than engineering. Who knew?

Even though my first month of floundering around, thick-fingered on this blog got me over a half million page views, I’m not vain enough to think it’s my snappy prose that drew the visitors. It was the subject matter.

No matter how hard I try, I can’t ever really leave Apple.

Some of you inquired online as to whether I continue to exist as a going concern. I can understand your curiosity since I’ve been absent here and mostly absent elsewhere for more than a week. Let me assure you that I do still live, albeit in a rather feverish and mucus-filled fashion.

As near as I can tell, I don’t have influenza. That’s a very serious disease. That last time I caught the flu — the real it-can-kill-your-ass flu — I went to the hospital for several days. Thankfully, I don’t remember much from the whole ordeal. That was back in the 90s.

What I possess now is an uncommon cold. I call it that because a more humble infection just annoys for two or three days. This one knocked me flat for more than twice that and won’t seem to let its foot up off my chest without draining me of strength and will first.

At least it started out as a cold. While not the flu and not life-threatening, it’s certainly moved on to more than just occupying my nasal cavities and now appears to building a summer home in the more southern parts of my body.

So it might as well be the flu. Even if it’s more prosaic.

The worse part of this experience is that not only am I not writing or programming, but I have little desire to even amuse myself with the vast library of movies, television programs and books I long ago prepared for just such a sickness.

So I sleep. And drink water. Lots and lots of water. Whole bottles of water. Which, besides the cold itself, is why I can’t remain sleeping for very long. Sooner, rather than later, I need to return the deposit on those beverages. Which means my record is about three hours of sleep at one time. And the average is half that.

My advice? Don’t get sick this winter. There are some annoying creatures out there besides the flu. One of those jerks is staying with me now.

Last Wednesday I posted this on Twitter and App.net:

It’s taking almost two seconds to completely regenerate all content on donmelton.com using Magneto. I need to speed that up.

As I’ve mentioned before, Magneto is a static site generator. It’s a tool I wrote myself, and what I use to create all the HTML, CSS, JavaScript, etc. that you’re reading now. The entire website is generated from this online source.

Some might think I was humble-bragging about Magneto’s speed, but I only had 42 posts here at the time and just under two seconds to generate that seemed a bit slothful to me.

Of course, I didn’t do anything about it right away — there are days when I make Jeff Lebowski look vigorous — but I did think on the problem for awhile. And then I was distracted by pictures of cats and bacon on Reddit. You know how it is.

But two days later, John Gruber made these two posts on Twitter:

Just fixed a punctuation typo in the first-ever DF Linked List entry, from 25 June 2004: df4.us/73

That was 18,989 items ago.

Stunning — not the typo, everyone makes those — but that he’s made over 18,989 posts to his website. That is truly impressive. Of course, he’s been doing it for over 10 years so you would expect him to have written maybe one or two.

Rather than make the “Finally!” joke like everyone else about him fixing the typo, I replied to John asking, “How long does it take to regenerate the site with Movable Type?” And he responded, “Good question. It’s been years since I’ve done a site-wide rebuild.”

And that… Got. Me. Thinking.

A site-wide rebuild? I do that here every time I make a single change. It’s just easier that way — no dependencies to calculate. And my website is still small so it makes sense, even if it’s taking almost two seconds right now. If Gruber doesn’t want to do a rebuild with Movable Type, maybe this is a bad approach. How long would it take Magneto to generate a website with 18,989 posts? Hmmm, how long?

So, I put down my White Russian, hung up my bathrobe, and got to work figuring that out.

First thing to do was fake up a shitload of posts. My usual approach to problems like this is a single and convoluted line of shell and sed script, typed and executed directly on the command line in Terminal.app. It’s gruesome, but I’m a hack and that gets the job done.

My not-a-real-script started copying my existing posts and then replacing their published timestamps. A minute into the process and I realized my outside loop counter was wrong and I would wind up with more that 20,000 posts. Oh well, it would just be a better test. And Gruber’s total number of posts was probably closer to that anyway.

Then life interrupted. Not just more pictures of cats and bacon this time, but actual family interaction. For several hours, too.

When I managed to get back to my precious iMac, it was late thirty and I was tired. I kicked off Magneto and started it chugging on 20,394 posts, along with all of the other content already included in the website.

And I waited. Five minutes into staring at Terminal.app I remembered there’s no way to tell which post Magneto was processing because everything happens in memory before it writes anything out to disk. This isn’t as stupid, wasteful, and uncommunicative as it sounds. That behavior was, in fact, by design.

I yawned and thought, screw it, this is taking too long. Something’s wrong, but I’ll just let it keep running and check the results in the morning. Off to bed.

Saturday morning.

Made my coffee and started reading the news. Halfway into my usual RSS feeds when the caffeine finally loosened the knot in my frontal lobes — I remembered. Say, what about that test I was running last night?

I switched over to Terminal.app. Magneto was done. Oh, how nice. But how long did that take? I looked at the console spew. Hmmm, 24,415.52 seconds — a lot. Lesse, that’s… trying to do the math in my head… switching to Calculator.app because I can’t count that high… that’s … MOTHER OF GOD?!? That’s 6 hours and 47 minutes! What the hell was Magneto doing?

I thought, there goes my performance bona fides. My reputation on Safari is shot. They’ll ask for my union card back.

So, I set to work figuring out what went wrong.

The first task was to measure. Folks online pointed me at ruby-prof, a great little code profiler for Ruby. I reduced the number of posts in the test to a thousand or so since I couldn’t stand to iterate all weekend on the problem.

And then it was lather, rinse and repeat with ruby-prof, while also adjusting the number of posts in the test.

It turns out, the problem was not with Magneto. I made an even stupider mistake — I trusted the tool to protect me and didn’t pay attention to how I was misusing it.

Now, Magneto is very simple. It’s devoid of features, really. It’s not even “blog aware” like some other systems. It requires you to write a site controller script, plugins and templates to tell it exactly how to generate blog posts, index pages, RSS feeds, etc. And you get to make all the policy — that’s its power.

When I wrote Magneto, I generated a thousand pages with Magneto before I released it just to make sure it didn’t have any glaring performance issues. It scaled well. Of course, I tested other things, too. And it was plenty speedy with a simple site controller script. A. Simple. Script.

However, I was much more cavalier with my own site controller script, plugins and templates that I wrote to use here. And I made the cardinal sin of never measuring the performance implications of that sloppy-ass code.

I was right when I thought almost two seconds was too long to generate 42 posts. That’s about .03 seconds per post. I thought I could do better on my hefty iMac.

But taking 6 hours and 47 minutes to generate 20,394 means it was taking 1.2 seconds per post. That’s not linear — not even close.

Thank god for ruby-prof. It took awhile, but I was able to zero in on the problems. Yes, it was more than one. But they were all the same issue — not caching the unchanging result of a slow subroutine that was repeated in every post.

All these rookie mistakes were in one of my plugins and one of my templates. None of it in Magneto itself. And after some judicious use of static variables and other grotesque hacks, I was able to improve things a tiny, tiny bit.

Now it takes only 5 minutes and 19 seconds to generate 20,394 posts. That’s a much more linear .016 seconds per post. And a 76.576x improvement overall — that’s not a percent improvement, that’s 76.576 times faster.

Yes, I was that stupid.

I’m sure I can find more improvements, but it’s unlikely that I’ll be able to generate over twenty thousand posts in less than 10 seconds without a massive upgrade in hardware. And 10 seconds is about the most I ever want to wait for something like that. Right now, 10 seconds would be about one thousand posts.

No, if I ever approach the proficiency and productivity of John Gruber, then for daily use I’ll need to extend Magneto or my site controller script to only rebuild what’s changed and cache what hasn’t.

In the meantime, I’ll be measuring more up front. Maybe I’ll even write about how I made a similar mistake with Safari and the other lessons we all learned from that.

During the early development of Safari, I didn’t just worry about leaking our secret project through Apple’s IP address or our browser’s user agent string. It also concerned me that curious gawkers on the outside would notice who I was hiring at Apple.

Other than a bit part in a documentary about Netscape that aired on PBS, I wasn’t known to anyone but a few dozen other geeks in The Valley. Of course, several of those folks were aware I was now at Apple and working on some project I wouldn’t say anything about. And it doesn’t take many people in this town to snowball a bit of idle speculation.

I found out later that Andy Hertzfeld, an Apple veteran who I worked with at Eazel, had figured it all out by the time I showed up for my first day to work on the browser on June 25, 2001. Andy was very insightful that way. But thankfully he was also quiet about it at the time.

Hiring Darin Adler, also ex-Apple and ex-Eazel, in the Spring of 2002 was likely visible to others in the industry since he was much more well known than me. But because Darin had never worked on a dedicated Web browser like I had, no one made the connection.

However, when I hired Dave Hyatt in July 2002, then guesses started flying fast.

While at Netscape, Dave built the Chimera (now known as Camino) browser for Mac OS X and co-created the project that would later become Firefox. Both of these applications were based on the Mozilla Gecko layout engine on which Dave also worked. He was a true celebrity in the Web browser world, having his hands in just about every Mozilla project.

So, during the Summer of 2002, several bloggers and tech websites speculated that Dave must be bringing Chimera to the Mac. Except that Chimera was already a Mac application and didn’t need to be ported. So what the hell was Dave doing at Apple? Building another Gecko-based Mac browser? No one knew. And none of this made much sense. Which is probably why the rumors subsided so quickly.

But people would remember all of this when Safari debuted at Macworld in San Francisco on January 7, 2003. And at least one of them would remember it at full volume while Steve Jobs was on stage making that announcement.

---

Until I watched that video I found and posted of the Macworld keynote, I had completely forgotten what else was announced that day. Which is pretty sad considering I saw Steve rehearse the whole thing at least four times.

But you have to realize I was totally focused on Safari. And Scott Forstall, my boss, wanted me at those rehearsals in case something went wrong with it.

There’s nothing that can fill your underwear faster than seeing your product fail during a Steve Jobs demo.

One of my concerns at the time was network reliability. So, I brought Ken Kocienda, the first Safari engineer, with me to troubleshoot since he wrote so much of our networking code. If necessary, Ken could also diagnose and duct tape any other part of Safari too. He coined one of our team aphorisms, “If it doesn’t fit, you’re not shoving hard enough.”

Ken and I started at Apple on the same day so, technically, he’s the only original Safari team member I didn’t hire. But because we both worked at Eazel together, I knew that Ken was a world-class propellor-head and insisted Forstall assign him to my team — essentially a requirement for me taking the job.

Most of the time during those rehearsals, Ken and I had nothing to do except sit in the then empty audience and watch The Master Presenter at work — crafting his keynote. What a privilege to be a spectator during that process. At Apple, we were actually all students, not just spectators. When I see other companies clumsily announce products these days, I realize again how much the rest of the world lost now that Steve is gone.

At one rehearsal, Safari hung during Steve’s demo — unable to load any content. Before my pants could load any of its own, Ken discovered the entire network connection had failed. Nothing we could do. The IT folks fixed the problem quickly and set up a redundant system. But I still worried that it might happen again when it really mattered.

---

On the day of actual keynote, only a few of us from the Safari team were in the audience. Employee passes are always limited at these events for obvious reasons. But we did have great seats, just a few rows from the front — you didn’t want to be too close in case something really went wrong.

Steve started the Safari presentation with, “So, buckle up.” And that’s what I wished I could do then — seatbelt myself down. Then he defined one of our product goals as, “Speed. Speed.” So, I tensed up. Not that I didn’t agree, of course. I just knew what was coming soon:

Demo time.

And for the entire six minutes and 32 seconds that Steve used Safari on stage, I don’t remember taking a single breath. I was thinking about that network failure during rehearsal and screaming inside my head, “Stay online, stay online!” We only had one chance to make a first impression.

Of course, Steve, Safari and the network performed flawlessly. I shouldn’t have worried.

Then it was back to slides and Steve talking about how we built it. “We based Safari on an HTML rendering engine that is open source.” And right then is when everybody else remembered all those rumors from the Summer about Dave Hyatt bringing Chimera to Apple.

But I chose the engine we used — with my team’s and my management chain’s support, of course — a year before Dave joined the project. Dave thought it was a great decision too, once he arrived. But that engine wasn’t Gecko, the code inside Chimera.

It was KHTML. Specifically KHTML and KJS — the code inside KDE’s Konqueror Web browser on Linux. After the keynote was over, I sent this email to the KDE team to thank them and introduce ourselves. I did it right from where I was sitting too, once they turned the WiFi back on.

You can argue whether KHTML was the right decision — go ahead, after 10 years it doesn’t faze me anymore. I’ll detail my reasons in a later post. Spoiler alert: I don’t hate Gecko.

But back to Steve’s presentation.

Everyone was clapping that Apple embraced open source. Happy, happy, happy. And they were just certain what was coming next. Then Steve moved a new slide onto the screen. With only one word, “KHTML” — six-foot-high white letters on a blue background.

If you listen to that video I posted, notice that no one applauds here. Why? I’m guessing confusion and complete lack of recognition.

What you also can’t hear on the video is someone about 15 to 20 rows behind where we were sitting — obviously expecting the word “Gecko” up there — shout at what seemed like the top of his lungs:

“WHAT THE FUCK!?”

KHTML may have been a bigger surprise than Apple doing a browser at all. And that moment was glorious. We had punk’d the entire crowd.

At 4:08 this afternoon, the Google Reader RSS feed aggregator decided to insert a bogus entry into their version of my RSS feed. My apologies, but I have no idea why they did this.

The bogus entry has the same title as one of my previous posts, but it doesn’t have any content.

If you don’t subscribe to my RSS feed using Google, then this problem doesn’t affect you.

My entire website, including the RSS feed, is static. That means all the HTML, XML, CSS, etc. here is just simple text files. I’ve verified that the RSS feed file on my ISP’s Web server does not contain this bogus entry.

I’m actually writing this in hope that a new post on my website and an new entry in my RSS feed will somehow reset Google’s whacky-ass view of the universe — at least that part of the universe where my feed is located.

Please let me know if you see this problem again.

For much of the time we spent developing Safari — long before it was called by that name — it pretended to be Microsoft Internet Explorer. Specifically, Internet Explorer for Mac, which Apple had provided with the OS since 1998. Less than six months before Safari debuted, it started pretending to be a Mozilla browser.

Why did we do this? And how did we make Safari pretend to be these browsers when its code and behavior were so different?

Not only was I tasked by Scott Forstall with building a browser and building a team to build that browser, I had to keep the whole damn project a secret. Which, by the way, really complicated the shit out of hiring most of the original team since I couldn’t tell them what they were working on until they took the job. Talk about your management challenges. But that’s another story.

So, secrecy. We weren’t under physical lockdown like Jony Ive’s design group was then, or like the iPhone team would be years later. But unless you knew who to look for, you were never going to find us on campus. And if you did, it’s unlikely you could tell what we were doing unless you caught one of us actually running Safari — something we usually did with our office doors closed.

I wasn’t worried about talk either. Forstall certainly trusted me – that’s one of the many things that made him a great boss. And I trusted my team — otherwise I wouldn’t have hired them. None of us nor any of the internal beta testers at Apple were going to snitch. There were too damn few beta testers, but they were above reproach.

Twitter and Facebook didn’t exist then. Nobody at Apple was stupid enough to blog about work, so what was I worried about?

Server logs. They scared the hell out of me.

When a Web browser fetches a page from a Web server, the browser identifies itself to that server with a user agent string — basically its name, version, platform, etc. The browser also gives the server an IP address so the server knows where to return the page. This exchange not only makes the Web work, it also allows the server to tell who is using what browser and where they’re using it.

You can see where this is going, right? But wait, there’s more…

Back around 1990, some forward-thinking IT person secured for Apple an entire Class A network of IP addresses. That’s right, Apple has 16,777,216 static IP addresses. And because all of these addresses belong together — in what’s now called a “/8 block” — every one of them starts with the same number. In Apple’s case, the number is 17.

IP address 17.149.160.49? That’s Apple. 17.1.2.3? Yes, Apple. 17.18.19.20? Also, Apple. 17.253.254.255? Apple, dammit!

I was so screwed.

Even though we operated the project like some CIA black op — with loyalty oaths and all — we couldn’t let Safari be “Safari” when we used it on the Apple campus network. Otherwise, some Web server administrator somewhere might be scanning their log files and notice the connection between user agent string and IP address origin. Then the big surprise Steve Jobs wanted to unveil at Macworld on January 7, 2003, would be shot. And, likely, so would I.

So we hid my cleverly designed Safari user agent string whenever we were at Apple. And I say “my” because that’s actually one of the few pieces of code in Safari and WebKit that 1) I can claim to have designed and 2) is still actually in the source. Thank God my engineering team removed or refactored all my other hacks. I hired good people.

Whenever we were off the Apple campus network, e.g. in our homes, we modified Safari to enable its real user agent string. And we had to do this for compatibility testing. That allowed me to tweak the string for maximum compatibility with the websites of that time. Which explains why the Safari user agent string has so much extra information in it, e.g. KHTML, like Gecko — the names of other browser engines.

We couldn’t ship with the real Safari user agent string disabled, but we came up with the next best thing — automatically enabling it after a certain date. Just about this time 10 years ago, days before it was to debut, Safari went from hiding its light under a bushel to being proud of who it really was.

And I spent the days before that debut nervous and losing sleep as I combed the Internet for server logs.