Twas the night before Hackday, when all through LinkedIn
Not a person was stirring, not even Stegman.
The fridges were stocked with cans of Redbull
The cups were all stacked, the bins were all full.

The hackers were nestled with text editors,
The build was still stable, with normal errors.
iPhones were docked, and Droids were all sleeping,
And MacBooks were purring with power lights breathing.

All of a sudden the InGraphs start flashing,
The NOC is alerted; what is now crashing?
Henke & Kevin were quickly online,
What could be causing this kind of flatline?

Before the team could dive into root cause,
The problems had ended and everyone paused.
Elliot checked, and the metrics were fine
2011 would be over the line.

Suddenly a voice boomed from across the LinkedGym
There was no doubt: the Wizard of In!
He comes every month, for the same simple reason:
Hackday is coming, and it’s coding season

“Forget all your meetings, tell Outlook to shove it.
Hackday’s for coding, just try it, you’ll love it.
Inspire your colleagues, show what you wrote,
Win their applause, and count Twitter votes!”

The Wizard began to run even faster,
and shouting the names of past Hackday Masters,
“Go Crosa, go Ragade, go Efrat & Heuser. Go Gillick, go Jiong, go Blackburn & Brikman.
Go John, go Matthew, go Shoup & Grishaver. Go Peter, Go Sam, Go Shannon & Vikram.”

As he ran by the kitchen, he stopped for a second:
“I need a Coke Freestyle, this thing is just heaven.”
Quick as he came, he ran out the door,
“Happy Hackday to all, you are all h@x0rs”

Most of the engineers who work at LinkedIn have also worked at other great technology companies, and in the past year there has been an incredible swell of feedback from new and old employees alike that LinkedIn Hackdays have become something truly special.  Creating the LinkedIn Hackday has been an iterative, experimental process, so I thought it might be useful to capture some of the details on how LinkedIn Hackdays work, and more importantly, why we run them the way we do.

Origins

It’s funny to think about it now, but the original LinkedIn Hackday had an unlikely catalyst.  On December 14th, 2007 approximately 100+ LinkedIn employees moved into a brand new space on the first floor of 2029 Stierlin Court.  It was the first time that LinkedIn had designed a workspace from the ground-up, and it included a large number of LCD TV’s on the wall.  The goal was to immerse the product and engineering teams in real-time feedback and data from the LinkedIn community, and each of the TV’s was driven by small Mac Mini.

The “Pure Energy” contest kicked off right before Christmas, with a goal of using some of the seasonal downtime to produce cool, internal applications that we could effectively “hang on the wall”.  The prize?  Brand new iPhones for the winning team.  The only rules?  The application had to reflect real usage of LinkedIn, it had to run continuously (so it could be left up 24×7), it had to be designed for display on a 720P monitor (1366×768), and it had to run in either Safari or as a Mac OS X screensaver.

Five projects were submitted, and several became staples of our decoration in 2029 for all of 2008.  (Coincidentally, December 2007 was also the first time we pull the live Twitter search for “LinkedIn” up on the wall for everyone in Product & Engineering to see at all times through the day).  The winner of the “Pure Energy” contest, NewIn, still lives on in an upgraded form, in both the LinkedIn reception lobby as well as on LinkedIn Labs.

Key Ingredients

We’ve learned a lot in the past four years about how to make Hackdays successful at LinkedIn, but at a high level, there are ten key ingredients that make LinkedIn Hackdays work.

1. For Engineers, By Engineers.  This may be obvious, but Hackdays are highly optimized events around engineering culture.  There may be a lot of opinions about what would be considered “fun” or “useful”, but for Hackdays, in the end, is designed for engineers.  This effects everything from the timing, the prizes, the venue and the communication around it.
   
   
2. Spirit of Exploration.  Hackdays have an opinionated culture, and one of those opinions is that with software it is infinitely better to learn by actually doing, rather than reading / talking.  It’s part of why people go into engineering in the first place.  This is one of the reasons that we celebrate hacks that are purely to learn a new language, environment, algorithm, or architecture.  This is not just a fun thing to do – it’s an incredibly effective way to expose talented engineers to new technology, and more importantly, set a tone that we should always be learning.
   
   
3. Independence.  Hackdays are a day of true self-determination.  At LinkedIn, we believe that small, cross-functional teams build the best software.  Teams do a great job looking at product metrics, customer requests, and innovative ideas from the team, and then prioritizing what to work on.  Hackdays are a day to break free, and work on whatever you personally find interesting.  If you have a great idea, this is the day to help make it a reality.
   
   
4. Company-wide Event. Hackdays may be optimized for engineers, but everyone is invited and included.  Some of the best Hackday projects come from an engineer, web developer and product manager working together.  We’ve had entries from almost every function, and from multiple offices.  Most importantly, hackday projects are shared with the entire company on the intranet, and Hackday Judging is an event that everyone is encouraged to attend.  Winners are announced to the whole company.  It’s incredibly important to cement hackdays as a part of company culture, rather than something that lives within the engineering function.
   
   
5. Executive Attention.  Believe it or not, it wasn’t until 2010 that we stumbled upon an obvious truth.  Executive attention matters.  Actions speak louder than words, and when executives make a point to attend, reference, and discuss hackday projects, it makes a huge difference to the entire organization.  At every LinkedIn Hackday Judging event, you’ll now find at least three of LinkedIn’s senior executives on the panel.
   
   
6. It’s a Contest, but Loosely Enforced.  LinkedIn Hackdays are thrown on Fridays, with the submission date for projects due at 9am on the following Monday.  Teams are limited to five people, and projects have to be presented live for Hackday Judging to be considered for prizes.  Having rules for hackdays is a delicate balance – if you are too weak on enforcement, people lose faith in “the system”, and you’ll get discontent from the people who follow them.  However, too tight on the rules, and you break the independent spirit of the event.
   
   
7. Hackday Judging, or Hackday Idol?  Hackday Judging has morphed over the years into an “American Idol” like event.  The hackdays themselves are relatively independent and quiet.  It’s the judging that is the main event.  Teams are given two minutes to demo their hacks.  The panel of celebrity judges is given a minute to asks questions, and then it’s on to the next project.  We serve lots of food & drink, and try to make it a fun event.  (Typically, I fill the role of Ryan Seacrest.  Yes, I know that my mom would be proud.)  There is a lot of laughing, a lot of cheering, and we try to make a good time for everyone.  Most people who attend leave the event incredibly inspired by what their co-workers come up with.  More importantly, once people attend, they tend to come back again (or better yet, enter their own projects.)  We now have everyone in the company help judge by tweeting out their favorite projects with the project name and a #inday hashtag.
   
   
8. Lots of Prizes. We give prizes to every team that present a project at Hackday, typically a reasonably sized Apple gift card.  Winning teams get larger dollar amounts.  We have 5-6 regular categories, so there are always multiple winners.  Some times, we give additional prizes for stand out projects, but that’s up to the judges.  The reason for gift cards is logistics – giving out iPhones, iPods, Flip cameras, etc sounds like a great idea, but too often you get winners who already have one, or who don’t want one.  (The Apple bias bugs some people, but the truth is we’ve experimented with a wide variety of prizes, and people on average seem to really prefer these.  We did notice that our college interns preferred Amazon gift certificates, however…)
   
   
9. Path to Production.  Some hackday projects are so impressive, there is a natural desire to shout “SHIP IT!”  In reality, however, hackday projects can vary significantly in their technical and product appropriateness for a large scale production environment.  At LinkedIn, we’ve now found multiple ways for people to share their hacks.  Some projects live on hosted on internal machines, and are used by employees.  Some of our best internal tools have come from previous hackdays.  Other projects are built over the LinkedIn Platform, and can be launched to end users on LinkedIn Labs.  Some projects are actually extensions of our production codebase, and actually become live site features.  (Example: The 2010 Year In Review email began as a Hackday Winner, as did the inline YouTube expansion in the LinkedIn feed.)
   
   
10. Learn & Iterate.    We are big believers in continuous improvement, and I don’t think there has been a single hackday where we didn’t add some improvements.  We constantly try out new things, and stick with the ones that work, and shed the ones that don’t.  The pace of innovation has dramatically quickened as hackdays became more frequent, and as the company has grown larger.

Common Issues & Questions

It would be impossible to capture all the common questions about hackdays here, but I thought it was worthwhile to capture a few persistent questions that we’ve debated in our process of creating LinkedIn Hackdays.

• I have a great hackday idea – how do I find engineers to build it?
  This is a really well meaning question, typically from non-technical employees, who are excited about the idea of hackday, but lack the means to implement it themselves.   The most reliable way that people solve this problem is by talking about their idea broadly, and effectively evangelizing the idea of forming a hackday team around it.  In the past, we’ve tried throwing pre-hackday mixers, usually around a technical topic, to help people find teams, but it’s had at best mixed success.
  
  
• I want people to build features for XYZ – how do we get people to do it?
  This question typically comes from a product manager, executive, or business owner who sees hackdays as a massive amount of valuable potential engineering effort for their area.  In this case, the short answer is that hackdays are about independence – the more you try to get people to do what you want, the more energy (and innovation) you sap from the system.  That being said, we’ve seen quite a bit of success where teams sponsor “special prizes” for a specific category on a given hackday.  Example: an iPad 2 for the project voted best “developer tool”.  This approach seems to provide the best balance of independence and incentive to generate the desired result.
  
  
• How do we get all hackday projects live to site?
  This question assumes that the goal of all hackday projects should be to go live to site.  However, given the education and innovation mandate of hackday, there are actually quite a few projects that are not intended to go live to site, and that’s not a bad thing.  The way that we’ve handled this question is by providing both a variety of mechanisms for projects to “go live”, as well as prize categories for projects that are not based on being a “shippable” feature.
  
  
• How can we spare a day from our priorities for a Hackday?
  In some ways, this is the big leap of faith.  For anyone who has attended any of the recent LinkedIn Hackdays, it’s hard to imagine this being considered seriously at this point.  However, at small companies, there are always more things to do than time to do them.  The decision to have hackdays is largely based on the belief that giving people time to learn by doing and to pursue independent ideas will pay off in multiples, not just in the projects themselves, but in the attitude and energy it brings to the company overall.  In some ways, you can view it as an HR benefit that also has a measurable positive impact on culture, internal technology, and product innovation.
  
  
• How do we get people to participate?
  The ten ingredients above reflect the system that we’ve devised, but the truth is it took time for hackdays to build into a culture fixture at LinkedIn.  In 2008, we threw two hackdays, and had about half a dozen teams enter each.  However, as the company celebrated each hackday winner, we saw demand pick up.  We had a major breakthrough in participation when we launched the “Hackday Idol” format for judging in early 2010, and since then we’ve seen incredible growth in the number of participants and projects.
  
  

What’s Next?

I’ve got a few new innovations ready to roll out for the May 20th hackday.  Not to spoil the surprise, but we’ll be rolling out for the first time a new “Hackday Masters” designation and category, for people who have won at least three hackdays.

Hopefully, the Wizard of In will smile down on us, and as always reward those who seek to bend code to their will.

For fun, I volunteered to give a talk based on material that I’ve put together over the years called “Personal Finance for Engineers”

I cover the most obvious two questions up front:

1. Why Personal Finance?  Personal finance is a bit of a passion of mine, and has been for almost twenty years.  It’s both amazing and shocking to me that you can attend some of the finest secondary schools and universities in this country, and still not get a basic grounding in personal finance.  More importantly, it happens to be an area with a huge signal-to-noise problem:  there is far more “bad” advice and content out there than good content.  And lastly, I believe that money matters are deeply important to the long term success and happiness of most people. (Let’s face it, money happens to be one of the top three causes of marital problems)
2. Why Engineers?  The talk isn’t purely for engineers, per se, so this reflects a personal bias (I just empathize more with engineers more than other people).  That being said, engineers tend to make higher incomes earlier in life than most people, and thus face some of these questions earlier.  They also tend to have stock options, a fairly advanced financial instrument, as part of their standard compensation.  Probably most troubling, engineers also consider themselves exceptionally rational, which makes them more prone to human weaknesses when it comes to money.

It was very hard to decide how to condense personal finance into a 60 minute talk (I leave 30 minutes for advanced topics).  I decided to focus on five topics:

• You Are Not Rational (Behavioral Finance)
• Liquidity is Undervalued (Emergency Fund)
• Cash Flow Matters (Spend less than you Earn)
• The Magic of Compounding (Investment Returns & Debt Disasters)
• Good Investing is Boring (Asset Allocation)

The deck is not perfect by any stretch, and I have a number of ideas on how to improve it.  There are some great topics / examples I missed, and there are some points that I could emphasize more.  I spend literally half the time on behavioral finance, which may or may not be the right balance.

The talk went extremely well.  We had well over 100 people attend, and stay through the full 90 minutes.  Surprisingly, I got more thank yous and follow up questions from this talk than any other that I’ve given at LinkedIn.  I’m strongly considering giving it again, perhaps at other venues, depending on the level of interest.

Let me know what you think.

In a rare combination of serendipity, passion, and empowerment, I personally ended up with one of those unspoken roles: the most prodigious producer of LinkedIn t-shirts.

2010 LinkedIn for Breast Cancer Awareness Shirt

At the recent Silicon Valley Comes to the UK trip, I had the chance to have a great conversation with Dave Hornik on why making t-shirts matter to high tech start-ups.   Believe it or not, I felt that this was a subject important enough to capture in a blog post.  (I’ll write a separate blog post on how to make truly great high tech t-shirts, which is a field of expertise unto itself.)

Why T-Shirts Matter

At a high level, understanding the typical culture at a high tech startup can be difficult for those who haven’t worked for one.  The best analogy I can think of is to put yourself back in time, to when you were between 8 – 12 years old.  Now, think carefully about the things that 8 – 12 year old boys like (at least, the geeky ones).  Video games.  Caffeine.  Scooters.  Toys.  Computers. Bean bag chairs.  Junk food.  This should help orient you, and brings you to the right frame of mind about t-shirts.

T-shirts are a part of that culture.  In part, t-shirts represent the ultimate middle finger to those unnamed sources of authority who wanted software engineers to dress like “Thomas Anderson” in the Matrix.  Software engineers want to be Neo, not John Anderson.

This leads us to the reasons why t-shirts matter:

Empowerment.  In some ways, engineers delight in having found a profession where their intellect and passion for technology have enabled them to earn a great living and work at a company where – yes, you guessed it – they can wear t-shirts to work.  Giving out t-shirts tells your employees, implicitly, that you get it.  You hire only the best, and the best can wear whatever they want.  It says you know that you value merit over appearance; a working prototype over an MBA.

Incentives.  Over the past decade, behavioral finance has taught us that people don’t value money rationally – it varies depending on form and context.  You can bring a $20 bottle of wine to your girlfriend’s parents’ house and be thought a gentleman.  Handing her Mom a $20 at the door isn’t looked on the same way.   Let me just tell you, free t-shirts evoke some sort of primal response at a high tech company.  I’ve often said that I would see less interest at a high tech company handing out $100 bills than handing out free t-shirts.  High tech companies are filled with benefits that cost hundreds of thousands of dollars per year, benefit a minority of employees, and are generally under-appreciated financially.  You’d be shocked at what a $200 per person per year budget for t-shirts will do for employee morale comparatively.

Tribal Cohesion. There are a lot of reasons why many institutions require employees to wear uniforms.  Common appearance can be a reminder that the person represents the company.  More importantly, common dress signals who is “part of the tribe” and belongs to the corporate family.  Uniforms are incompatible with the “empowerment” aspect of how people want to dress, but t-shirts can represent a form of “voluntary uniform” if produced in sufficient variety and quantity.   This effect can be had at a team level, when a t-shirt is made just to celebrate a new product, or at the company level.  It has a profound effect on new hires, as well, who desperately want “a shirt” so they can fit in.  It may sound subversive, but t-shirts can provide many of the same benefits of camaraderie and tribal cohesion that uniforms did, without the top-down oppression.

Tenure Based Seniority. High tech companies are largely meritocratic, and as they grow they tend to define roles based on skills & experience rather than “time at the company”.  However, there are positive aspects to rewarding those who have “bled for the company” over the years, and put their hearts and souls into building the business.  T-Shirts, in an innocuous way, implicitly do this by almost always becoming “limited editions”.  Want the t-shirt from the 2007 company picnic?  You had to be there to get one.  How about the shirt from the first intern program?   The launch of a game-changing new product?  Even shirts that are given out to the whole company will become rare at a company that’s growing rapidly.  In a socially acceptable way, t-shirts subtlely communicate a form of tenure that is warm, and yet structured.

Branding.  As discussed under “Tribal Cohesion”, people want to wear the brand of their tribe.  They will wear them out everywhere if you let them.  Let them.  While being careful not to interfere with the uniqueness of shirts given to employees, make shirts for your developers, your fans, your early adopters.  Long before they become vocal advocates for your brand, they will gladly showcase it if you let them.  This tends to work best in relatively inter-connected, dense, techy cultures like Silicon Valley, but you’d be surprised how far your reach might be.  Of course, this assumes that you make shirts that don’t suck, but we’ll cover that in the next blog post.

So How Do I Make Great Shirts?

It turns out that this is a lot harder than it appears.  Mario always tells me my blog posts are too long, so I’m going to save this topic for the next post…

Got the graphic from CNET.  They have some details about the event:

Apple distributed invitations Thursday for a March 17 special event in Cupertino, Calif., to discuss the iPhone 3.0 software and a new software development kit.

Next Tuesday’s event will come a little more than a year after Apple unveiled the original SDK at the iPhone 2.0 software event, setting the stage for over 25,000 iPhone applications to make their way onto the App Store. Speculation about a new iPhone had mostly centered on new hardware features, rather than software upgrades, but it seems Apple has something up its sleeve.

Hoping to see OS-level support for some missing basics:

• Clipboard (cut & paste)
• Background processing (some form of mult-tasking where apps can receive updates even when they aren’t front-most)

I’m wondering if we’ll see any significant hardware enhancements or new models announced.  The iPhone currently drives developers to really focus on a single screen size… would be nice to see more robust handling for multiple sizes/shapes to give more flexibility to hardware in the future.  It’s not that you can’t make resolution-independent applications today – you can.   It’s just not encouraged or optimal.

MegaPhone?

while (days > 365) {
    if (IsLeapYear(year)) {
        if (days > 366) {
            days -= 366;
            year += 1;
        }
    } else {
        days -= 365;
        year += 1;
    }
}

For non-programmers out there, this is what we like to call in technical terms “an infinite loop”. This code block will never finish running because on Day 366, the loop keeps checking to see if the day is greater than 365 (it is), and then checks to see if it’s a Leap Year (it is), and then checks to see if it is greater than 366 (it isn’t). So it does nothing, and then starts all over.

Perfect way to lock up your Zune every four years on the last day of the leap year.

Not sure if this is the actual code snippet or not, but a fun exercise. I could actually see this being on an introduction to programming test at some point.

My favorite quote about this fiasco (from the San Jose Mercury News):

“I’ve never heard of a consumer electronic device fail en masse like this,” said Matt Rosoff, an analyst with Directions on Microsoft, a Seattle-based research firm that focuses on the software giant.

Does anyone doubt that “Microsoft Zune” has become the “Ford Pinto” of consumer electronics?

First, special hat tip to Mario Sundar for finding this lead.  Mario is not a coin collector, but he reads my blog often enough to know that I have a special interest in coins.  This one is a beauty, since it combines creative visualization with a unique engineering tale.

Here is the coin design:

Here is a brief description, from the Dutch Mint website, on the coin design:

A new 5 euro commemorative coin pays tribute to the history of Dutch architecture. Both our historical architecture as well as our innovative conceptual architecture and modern design are popular across the globe.

The Architecture five-euro coin was designed by artist Stani Michiels (b. 1973). The design on the obverse of the coin pays tribute to the history of Dutch architecture, with the portrait of Queen Beatrix being distinctively constructed using the names of important architects from Dutch history. The artist used the internet as a popularity-meter to determine the names’ order of appearance.

The reverse of the Architecture five-euro coin draws attention to the striking fact that many Dutch architects have also included publishing books on architecture in their professional activities. To illustrate this phenomenon, recent books on architecture rise up from the sides of the coin like buildings. Through their careful placement they combine to outline the Netherlands, while birds’ silhouettes suggest the capitals of all the provinces.

This blog post, however, from the designer, is where the real beauty lies.  It’s too long to reproduce here, but it goes into significant depth about the design inspiration, concepts, and visualization at work.  If you have a background in design, you will appreciate it.

Here is the summary from the post, and I think you’ll see why this contest winner gets substantial geek cred, as he goes into detail about the technology used in the coin design:

The whole design was done for 100% with free software. The biggest part consists of custom software in Python, of course within the SPE editor. For the visual power I used PIL and pyCairo. From time to time also Gimp, Inkscape and Phatch helped quite a bit. All the developing and processing was done on GNU/Linux machines which were running Ubuntu/Debian. In the end I had to collaborate closely on location together with the technicians of the Royal Dutch Mint (coin factory). So all the last bits were done on my Asus Eee PC. (I am still wondering why Asus doesn’t offer Ubuntu on its netbooks.) The Eee laptop took a bit longer (30 seconds instead of 3 seconds to generate a whole coin), but did the job just fine. For looking up the number of hits on the internet, I rediscovered Yahoo, which provides a much better api for automatic querying than its competitors. Of course the jury judged only the design and not the software used as others used Maya, Illustrator, …

And the winner is…
I am proud to announce that I won the competition! So soon 350.000 Dutch people will use the fruits of free software. I would have loved to release the coin under the GPL, which could maybe solve the financial crisis. However for obvious reasons I was not allowed to do that. There will be also special editions for collectors which can be bought world wide: a massive silver edition for € 30,95 and a massive gold edition for € 194,95. They will be probably sold out quickly as these are real collectors items. The coin is released in all Dutch post offices to the public the same day as the Intrepid Ibex: 30th October 2008.

You can purchase the coin here at the Royal Dutch Mint.  They seem to still have the gold version available, but no sign of the silver version.  Maybe it sold out?  If you find it, please comment here with a link.

Great news and timing for the CS 193P class at Stanford, as this means that forums are likely to emerge quickly for students to engage with, learn from, and help each other.

Here is some text from the Apple Announcement:

We have decided to drop the non-disclosure agreement (NDA) for released iPhone software.

We put the NDA in place because the iPhone OS includes many Apple inventions and innovations that we would like to protect, so that others don’t steal our work. It has happened before. While we have filed for hundreds of patents on iPhone technology, the NDA added yet another level of protection. We put it in place as one more way to help protect the iPhone from being ripped off by others.

However, the NDA has created too much of a burden on developers, authors and others interested in helping further the iPhone’s success, so we are dropping it for released software. Developers will receive a new agreement without an NDA covering released software within a week or so. Please note that unreleased software and features will remain under NDA until they are released.

It’s interesting to note the phrase I bolded above… given Apple’s history with the Mac & Quicktime, it always seemed possible that the iPhone NDA was a reaction to those bitter lessons.

The San Jose Mercury has a funny write up here.  Ars Technica has a more verbose post up as well.

I think we’ll see a measurable increase in the number of applications and the relative quality and pace of innovation from this change.  It was shocking how much this simple legal protection was stifling the growth and development of developers new to the platform.

CS 193P: iPhone Application Programming

The class website is still a work in progress, but it will come along.  The course is open to Stanford undergrad and graduate students, as well as through the Stanford Center for Professional Development (SCPD) on video.  Enrollment is limited, and my guess is that it will be oversubscribed.

A wonderful opportunity for me to dust off the old Objective-C skills, and help give back to the Stanford community.  Launching new courses is always exciting, and I feel very lucky to be involved with this one in particular.

It might sound crazy to take this on in addition to the full load at both work and at home, but I’m excited to get back involved with teaching, and that’s worth the potential sleep deprivation for the quarter.

There is coverage on Boing Boing:

 SimCity has just been released as free software under the GPL version 3 license (though the name has been changed to Micropolis for trademark reasons; it was the original working title). This was precipitated by the inclusion of SimCity on the One Laptop Per Child XO machines, but no reason the kids should have all the fun. Can’t wait to see the SimCity hacks that emerge now:

The “MicropolisCore” project includes the latest Micropolis (SimCity) source code, cleaned up and recast into C++ classes, integrated into Python, using the wonderful SWIG interface generator tool. It also includes a Cairo based TileEngine, and a cellular automata machine CellEngine, which are independent but can be plugged together, so the tile engine can display cellular automata cells as well as SimCity tiles, or any other application’s tiles.

There is more detailed coverage about the open source release on this blog.

Back in college, I spent a good chunk of my junior year coding up a fast sprite library for the Mac called “Pixie” which had hand-tuned blitters, layering, and other goodies that seem shockingly dated now in a world of graphics cards, modern rendering pipelines, and modern gaming engines.  Back then, getting 30 frame-per-second animation for about fifty 32×32 animated sprites was considered real bragging rights for a 68K-based Mac.  I can’t tell you how excited back then I would have been to download and play with this.

Check it out, if you are so inclined.

Spent two hours after the boys went to bed.  Managed to get swizzling working.  I have now completed a Mail plug-in that when installed…

… drumroll, please …

logs out to console the name & email address of the sender of every email you view in Mail.app.

… let it sink in …

OK, it may not sound significant, but that was 1 of the 7 things I have to get working to have a demo of my new Mail plug-in up and running.  I now have a renewed burst of confidence that this plug-in will indeed get done.
Many thanks to Adam Tow, who responded to my previous blog post, sharing not only tips & sample code, but also a pointer to a regular, weekly coffee night for Cocoa developers in Campbell.  I had forgotten how supportive the Mac development community was… this event looks pretty neat.  Maybe when I get to the really tough stuff, I’ll go.

Method Swizzling in Cocoa

Basically, it’s the missing piece you need to effectively “hijack” an existing function in an existing piece of Mac OS X software.

To do this, you follow a few key steps:

1. You identify a method of an existing class in an existing piece of software that you want to hijack, let’s call it “foo”
2. You then write your own implementation of that method in that class, let’s call it “myFoo”
3. You do what ever you want in myFoo, but then you include a call to myFoo. It looks like infinite recursion, but it’s not.
4. You do the MethodSwizzle trick, which basically tells the Objective-C runtime to replace all calls to “foo” with “myFoo”, and vice-versa.

End result, every existing call to “foo” now calls “myFoo”, and “myFoo” is no longer infinitely recursive because it’s call to “myFoo” now calls “foo”.

It turns out this type of trickery is essential if you want to write a plug-in for an existing application, like Apple Mail, where there is no pre-defined API, and you want to take over pre-existing actions and add some functionality to them.

My work on an Apple Mail plug-in is painfully slow, but I’m at least a little further along now.

Nothing fancy, but I’ve decided to see if I can’t write some useful plug-ins for Mac OS X.  In particular, I’m going to see if I can’t improve:

• Apple Address Book
• Apple Mail

I tend to joke with friends that when I went to business school, part of the admissions process was officially “turning in” my compiler.  To show you how dated I am, the last serious Mac OS development I did was in Metrowerks Codewarrior.

Over my vacation in August, I went through Cocoa in a Nutshell from the O’Reilly series, just to refresh my memory.  Even when I was on the WebObjects team at Apple, I primarily wrote framework code in Java, not Objective-C, so basically I’ve got to come up to speed again on:

• Objective-C
• XCode 2.4
• Five versions of Mac OS X (the version I worked on became 10.0)
• Documented methods of extending Apple Address Book
• Undocumented methods of extending Apple Mail

I managed this weekend to get a sample plug-in for Apple Address Book working.  This wasn’t a huge feat, really, since XCode includes a sample project for this as a default install, and it’s fairly trivial to customize the three Objective-C messages that define the functionality.

If you are looking for the documentation on extending Apple’s Mac OS X Address Book, check out:

• Apple’s Address Book Programming Guide
• Apple’s Address Book Object-C Framework Reference

Pretty basic really, although adding a contextual menu command for certain fields is hardly the best interface.  I’ve been playing with Plaxo Toolbar for Mac, and trying to figure out how they inserted their drawer into the GUI.

Creating plug-ins for Apple Mail is much trickier, because it’s completely not supported or documented.  Well, I shouldn’t say not supported… it’s not supported officially.  However, Apple Mail does implement a plug-in architecture, and with a few quick setting changes, you can install a wide range of third party plug-ins.

Here are some cool links if you are interested:

• Demystifying Mail App Plugins.  This blog post covers some high level tips and source code, in Python, to write a quick Mail.app plugin.  Thanks to this post, I re-discovered class-dump, which lets you inspect the classes and methods for any Mac OS X application (very cool).
• Mail Plugin Template 1.0. Aaron Harnly, you are my hero.  Aaron has posted an excellent XCode project template, with class-dump headers, for building your own Apple Mail plug-ins and installer scripts.  He even answered a simple project question for me over email.  Very cool.
• CocoaDev.  This is a wiki site dedicated to Cocoa development.  Aaron’s code pointed me here, since it features “Method Swizzling”.  It’s a very sneaky feature of the Objective-C runtime, where you can effectively not only over-ride an method for an object you don’t own, but you can even replace the parent class method in applications that you don’t control!  Read this for specifics (very cool if you’re into programming).
• Apple Mail Plug-Ins and Tools.  A whole directory site of Apple Mail plug-ins.
• Apple Mail Plug-In Roundup.  This post on The Unofficial Apple Weblog covered a lot of cool Mail.app plugins.
• Mail Act-On.  Very cool Mail.app plug-in that lets you map individual rules to keyboard commands.  My favorite Eudora feature, now on Mail.app

So far, I have an Apple Mail plug-in that compiles and loads correctly in Mail.app and logs data into the console.  But I’m going to put that in the “W” column for this weekend, given my incredible level of rust around the gears.

I’m going to be flying to Omaha this week to visit the LinkedIn customer service team… I’m going to try and use the flight time to get a little bit more working.

My biggest question now is how far can I go in terms of influencing the Mail.app UI.  I already know how to:

• Create a plug-in
• Insert menu commands and menus into the main application
• Create my own preferences panel & preferences file
• Create my own window

However, if I really want to integrate,  I need to figure out how to:

• Add commands to existing contextual menus (I can’t find them in the NIB files anywhere)
• Add views/panes to the existing windows (ala a toolbar)

I haven’t found sample code that does either of the above yet, but I’m still looking.

All in all, it’s fun to be compiling again.

Jonathan Coulton releases his songs under the Creative Commons license, allowing third parties (like Michael Booth) the ability to create things like these videos with them. These videos themselves are spliced together from World of Warcraft.

Lyrics are available here.

Some key lines:

Code Monkey think maybe manager want to write god damned login page himself
Code Monkey not say it out loud
Code Monkey not crazy, just proud

Code Monkey like Fritos
Code Monkey like Tab and Mountain Dew
Code Monkey very simple man
With big warm fuzzy secret heart:
Code Monkey like you

Very funny, and very cool.