A variety of influences tonight pointed me towards my earliest published article, for MacTech, in 1999 or so:

MascBug Revisited

I was really just a kid. But I had learned an awful lot about debugging, thanks to my awesome job in the Apple system integration team. I guess that made me feel pretty confident about writing an article – for a real magazine, even. So what if hundreds or thousands of other developers knew more than I did about software development, I knew a lot about debugging! I had spent a few years testing and then developing the Mac OS system file (and system enabler), and was confident that few would be as up-to-date with MacsBug as I was.

Debugging is a skill I have kept throughout my professional career. If you’ve got a bug, chances are I can help you get to the bottom of it. I’m effing good at that. The fact that I can write code is somewhat incidental, because my primary skill is as a debugger.

This is especially handy when I’m debugging my own code, because I’ve got the bug writer and the bug buster within easy reach :)

The MacTech article is antiquated – depressingly so – but many of the concepts still apply to OS X debugging. If you’re at a loss for how to approach buggy code in your project, my old 20-something article might actually be of some use to you.

When it comes to debugging, some things never change.

This Sunday will mark the two year anniversary of Red Sweater Blog. I find it hard to believe it’s been such a long time, and yet such a short time, since I started writing here. With over 360 posts so far, I guess I’m averaging about one every two days. Not bad, for a busy programmer!

This run would not have been possible without MarsEdit, the application that makes writing for the web palatable to Mac users. Little did I know a year ago that the application I love so much would be my product a year later. To paraphrase the Remington shaver guy, “I liked it so much, I bought the source code!”

The past year has also been exciting outside of my programmer life. I got married! We’re almost 2 months into our fabulous marriage, now.

In January I responded to what seemed to be a bunk software acquisition deal by challenging developers to sell me their product. I had an amazing response when over 30 people made me separate offers. The application I ended up buying is now marketed as Black Ink, and is the premier desktop crossword-solving application. (Note: MarsEdit didn’t happen until a bit later, and was unrelated to that original challenge.)

Late last year I was engrossed by the sad story of James Kim, who died in the Oregon wilderness after the rest of his family was rescued. His memory is a recurring reminder to value family and friends while we have the pleasure of their company.

The sad news was offset somewhat by the uplifting charitable software sales I took part in. Mike Zornek’s Child’s Play Day helped raise over $10,000 for a charity that helps kids in hospitals have a bit of fun. Jason Harris followed-up with a Holiday Cocoa Duel, which raised over $2300 for a variety of charities, chosen by the participants.

October marked the first iteration of C4, where I met dozens of amazing developers for the first time. I also had the pleasure of meeting John Gruber, whose HIG Is Dead talk had such an immediate impression on me, that I went straight home from the conference and redesigned FlexTime.

That redesign of FlexTime came only a few short months after it was first released. An idea that started brewing while I was developing complex AppleScripts to cue my yoga practice, I worked on it off-and-on for a couple years before finally releasing it in August, 2006. The application was met with a mixture of applause and confusion, which I think is a fairly good omen for an unusual new application. I’m looking forward to getting a chance to refocus my efforts on expanding its functionality over the next year.

Incidentally, this marks the end of my first “real year” of trying to be an indie software developer. That is, producing and selling software directly to the public. I had been selling shareware for several years, but never focusing so intently on it. Shortly before the release of FlexTime I gave myself permission to cut back on consulting and pursue a full-time career in developing my own products. I’ve taken an unusual path to get here, but I’m glad I took the chances I did. I wrote quite a bit about this last year in The Road Less Traveled, written in concert with Paul Kafasis of Rogue Amoeba.

This summary of the past year’s posts is only the tip of the iceberg. If you like what you read here on the blog, but are a fairly new subscriber, you might find some interesting stuff digging through the archives.

As always, thanks for reading! This would be extremely boring and ungratifying if I were writing these words to myself, only to be pondered in the lonely solitude of my office. Your comments and feedback (often more inspired than my own writing) make all the difference.

Dude! Want to make a bunch of developers your best friend? Then write an online payment processing framework, allowing new developers to easily harness the power of PayPal or Google Checkout.

That’s what Andy Kim of The Potion Factory just did. This is definitely one of those “wish I could run Rails” moments. Still, a move worth applauding. Thanks, Andy!

(Via Gus Mueller)

The WebKit team is picking up on Steve Jobs’s “one more thing” habit, announcing yesterday a new HTML element inspector, built into the latest WebKit nightly downloads.

Play around with it for just a few minutes and your jaw will drop. It’s especially fun to click around the DOM hierarchy and watch as WebKit obscures everything except what you’re inspecting. It makes it dead-simple to cruise around and get the lay of the land on any web page. You can start inspecting at any element on the page by right-clicking and selecting “Inspect Element.”

The inspector’s functionality doesn’t stop at merely poking around the DOM. Click the disclosure button in the lower-left corner to reveal two other nifty tools: Console and Network. Console gives you a nifty little JavaScript interface to the targeted page, which is a lot handier than typing all of your test commands into the URL box with “javascript:” URLs. And the Network tool is sort of a mini-Shark performance tool for the web. It shows you how long it took to load every element on the page, and in what order they were loaded. It even offers advice for performance tuning!

But what’s extra especially shocking and impressive is that this beautiful (no more HUD display!) UI is itself implemented entirely in HTML/CSS. To prove it, just right-click on any item in the inspector window itself, and inspect it!

You can use the inspector to see how the inspector pulls off some pretty impressive tricks to make the plain HTML/CSS look and feel more or less like a desktop app. While I don’t envy anybody trying to replicate the feel of Cocoa in HTML, I am quite impressed with the overall polish and usability of this interface.

Major congratulations are in order to the WebKit team for this amazing update in functionality. The one thing that screams out at me as missing, however, is the ability to edit the CSS for inspected elements directly from the inspector. I’m sure this is a feature many web developers would love to see. It’s something that keeps me running FireFox from time to time, just to accelerate that part of the web design process.

I propose that if some up-and-coming developer was to implement editable CSS for the WebKit element inspector, they would have heaped upon them the praise of many, many Mac developers and web designers. Not to mention the WebKit team itself.

Maybe this is your chance to break into the spotlight?