Stuff you learn about when it breaks

Somewhere in my basement I have a copy of Winograd and Flores' Understanding Computers and Cognition, required reading in some late-1990'es HCI course. Just about the only thing I remember from that book is this quote: "The word processor exists as a collection of hardware or programs only when it breaks down." This is in the sense that you don't think about a tool which doesn't get in the way, and only when it fails (or is missing), you notice it and start to analyse it.

Fast forward some 13 years, a few days ago, I finally got around to writing some better UI tests of WTP's "XPath View", using SWTBot as the weapon of choice. Having read the SWTBot getting started docs and some useful blog posts, writing my tests were soon well underway, using the fluent API provided. It is fun to watch the application speeding along like time-lapse film, like magic.

Everything went fine until I wrote code to switch the XPath view's active process from XPath1.0 to XPath2.0, using the view's menu. The API was pretty easy to figure out, but the view menu finder just didn't pick up the menu item I wanted.

There's my breakdown: Why?

Well, it turns out that unlike regular menus and context menus, view menus are collected in a different fashion by SWTBot, by examining the contributions rather than enumerating the SWT objects themselves. Some corners cases are not covered. Not a big deal, really, but it made me look at the source for SWTBot, which is quite a pleasant sight. Now it exists as real code in my mind, as does the Eclipse command framework implementation. And I also now "get" the Hamcrest Matcher framework which I've previously thought to be horribly over-engineered.

With my new knowledge, I can even extend SWTBot. Nice.

Then fast forward two more days, while this blog post was sitting half-finished in my browser, Saturday evening, after historic amounts of rain in the area, my basement was flooded: The sewer couldn't contain the rain, and the system broke down and came very much into existence, as sewage water gushed up from the drains and toilet and my otherwise dry basement became a 20cm deep paddling pool, allover. Getting the water out took hours; getting the smell out will take days, maybe weeks.

Like software, sewage is something most people would rather not have to deal with. It's supposed to be "invisible magic", but in reality it is messy and complicated, and when it doesn't work, it makes for a shitty situation -- yet our society very much depends on it.

The really strange part is the book: I haven't found it yet, not in the "dry" pile, the "slightly damp but fine" pile, the "soggy yet perhaps readable" pile, or the "discard" pile. I know that book must be down there somewhere, and when I find it, it's going back into my reading queue right away.

P.S: My flooded basement was a picnic compared to the flood in Pakistan. Consider donating to your favorite charity!

Autonomy, Mastery, and bug 313989

Dear diary: About a week ago, I took out a full 10 minutes from my day job to watch an interesting video on YouTube about what motivates people, as recommended by David Carver.

The video explains what might motivate people (who typically hold a challenging and rewarding day job) to contribute their efforts, for free, to open source projects, and it really got me thinking (spoiler alert -- go watch it first): The video concentrates on three significant drivers for motivation: Autonomy, Mastery, and a Sense of Purpose. I considered this is terms of my WTP interests:

• "Autonomy" is right on target: Nobody told me to get involved with web tooling in Eclipse, this is purely an itch. For a free-time contributor, I believed I scratched my itch really good.
• "Mastery" is on target too, since nothing teaches you a spec(*) as well as trying to implement it, or filing a bug against said implementation. It's nerdy, but rewarding!
• "A Sense of Purpose" is a bit more difficult... What is the purpose of contributing to an open source project, anyway? Is it ... mastery for the sake of professional/career development? ... just "scratching an itch"? ... to improve the quality of a common resource? ... to earn the respect of my peers? ... to make the lives of users (other developers) easier? I'm not sure I have a clear answer on this one, but it got me thinking.
  

I wouldn't have taken as much notice if my watching this video didn't coincide with the WTP 3.2 RC2 build, which I took for a spin, and found three really annoying defects (bug 313989 being the most trivial of those). These bugs weren't really enough to warrant PMC reviews and all that process, but to me, they felt just like when you notice the first scratch on the paint of your brand new car: Sure, you realise it's probably going to get worse -- but you would have preferred not to know about it.

The point is this: I should have found those bugs earlier! If I hadn't been so busy investigating all kinds of other unrelated, non-WTP stuff (issues in Xalan and Hibernate, besides investigating how face recognition works, just because...) I could have done much better! Boom, there goes my sense of purpose, no matter how I look at it: Lost in unfocused dabbling.

So my conclusion was this: The "sense of purpose" motivating me to work with WTP is to develop the best IDE for working with XML schemas and documents, and to make our XPath2 implementation consumable for the likely adopters.
My open source effort will be concentrated on that (WTP+XML) for the next two years: Make it to the New and Noteworthy. So while I might take other tools for a spin (Xtext rocks!), those other projects shouldn't wait up for patches from me -- for the next two years.

P.S. And dear diary: I promise to write more often.

*: XML, XML Schema 1.0, SOAP 1.1, XML Catalog, XPath 2.0, XSLT 1 & 2, XML Schema 1.1, the list goes on.

Random acts of kindness

With Helios M6 in the mold, now is the time to send a big 'thank you' to the ladies and gentlemen making all this possible, the unsung heroes of the more-or-less-oiled machinery called 'build', the closing-time-panic induced commitathoners, the map-file conflictinators, the cooler of the cool 'hope-the-next-build-will-be-green'-cats, the ... well you know who you are!

Thank you all very much!

For those of you going to EclipseCon this year, I recommend buying a pint for your build-wizard. But don't overdo it in case somebody (could be me) breaks a build somewhere!

Red Clown-Nose Game

I love games, I really do. Just the other day, I found out I was in a game I didn't even know about. It's called the The Continuous Integration Game, and it's played on the Hudson instance on build.eclipse.org. And guess what, because I keep breaking the psychopath (XPath2) build, I'm placed almost at the bottom (that earns me -10 points), and dcarver who keeps fixing the build afterwards, is almost at the top (since a successful build gives +1 point and adding a test suite gives +1 per test. And who added the 8000+ tests from the W3C suite?)

I certainly have room for improvement - let the games begin!

Know your project's "hangarounds"

(This post actually started as a comment to Dougs post about too few Eclipse hands but I think it merits a note of its own.)

It's only human to want more, and sometimes we want more for less.

As an occasional contributor, my impression is that there's just not enough people to review bugs and patches and keep ownership of the various components. In the projects I've contributed to, this has been a steady decline over the years. So, I agree with Doug, more cooks!

However: As a former (individual) committer who just wasn't active enough (life happens), I wish there was more time! I think there's an untapped potential in the project "hangarounds". People who have been following the project or component for a while, are power-users but also know the design codebase, but do not have the time to be a committer with all that entails. The hangaround.
By that, I mean a person who keeps up to date with the project or component, and is willing to assist the committers in a number of areas:

• Bug triage
• Spreading the good word about the project (superuser/ambassador)
  
• Fixing bugs
  
• Reviewing and testing patches, etc. from the contrbutors at large.
• Pushing initiatives like Bug Friday
• Extend test coverage
  
• Keeping [helpwanted] markers on bugs relevant and realistic
• Review and write documentation
• Participate on mailing list and/or newsgroup

Who wouldn't want those guys/gals around? The key point here is to encourage participation of a following, by acknowledging that these tasks are important and that these project hangarounds are valuable to the project. By acknowledging that hangarounds earn their "props" (proper respect) from the committers by providing good patches and thus proving their worth over a longer period. Or perhaps sqeeze a "contributor's day" in between Mother's day and Fathers' day somehow - flowers are optional.

Often full-time Eclipse member committers are indeed colleagues working together on significant areas of new functionality, and they often optimize their communication by keeping it to themselves. This is unavoidable and mostly OK. Hangarounds wouldn't be "in the loop" for that kind of development, but their knowledge of the project or component make them valuable reviewers -- keep in mind that a large share of the Eclipse user audience are software developers, and should be accustomed to such tasks and hopefully welcome them.

While I don't know every project in the Eclipse ecosystem, I'm sure project hangarounds already exist, in practise anyway, and that their contributions are valued. However, I think it should be encouraged lots more, also so that the committers had a better feeling of which contributors to turn to for help.

I know, I know, code is the true measure of most things Eclipse, but even if you can't code Eclipse all day, you can still contribute. Let's not forget that.

Surprise: Eclipse is me, too!

My last word on the whole e4 thing will not be about e4 at all (since I'm following going through the instructions for the demo, letting the code speak for itself), rather it will be restating what's been said so many times before: Eclipse is me.

Now, I'm not the most active Eclipse committer/contributor (Dave and Doug are doing all the actual work in the XSLT tooling in the WTP incubator), nor am I a prolific, insightful blogger by any standard. Yet, my posting regarding e4 did not go unnoticed within the community. I think that's a sign of good health, and I was pleased to see Mike M following up on it.

What befuddled me a bit however, was finding out Reg Developer linking to the post, essentially using it as a news source, as an exponent of a general sentiment. That was just ... unnerving, out of proportion, and misunderstood. Planet Eclipse is a great medium for following what's going on, but is does not fairly represent the minds of all ~1000 Eclipse committers and the many members doing the hard work. The planet should always be read with that in mind.

Eclipse is you, but take care to express how.

P.S: For a laugh, read the Reg Developer comments, and try not to think of XKCD.

My EclipseCon un-schedule: Day 1

This year, I am also not at EclipseCon.
Rather than four days of Eclipse tutorials, talks, BOFs, and high quality chit-chat, I'm getting what should have been springtime in Denmark. Well, it isn't.
My un-schedule for today went like this:

• 07:00: Why is everybody up now? I'm not running anywhere! Oh, breakfast.
• 08:00: Traffic Ballroom Z: "Model driving gets kids to daycare" 101, and more.
• 10:00: Coffee - I get that.
• 10:30: Managing my small company's general ledger with a cool RCP based ERP (no, that was OOo Calc)
• 12:00: Lunch and Eclipse smalltalk. Minus Eclipse smalltalk.
• 13:00: Improvised BOF meeting with other Eclipse contributors people stuck in line in the hardware store.
• 13:30: Heave 13 sacks (450 kg) of shredded bark mulch into family car. Prepare for contribution as foundation for the coming platform.
• 15:15: Daily General Meeting with kids being picked up from daycare.
  
• 15:30: Check Planet Eclipse for postings on EclipseCon.
• 16:00: "Introduction to PDE/Build", or make that finally updating my XSL workspace for M5. Noticing how "Project > Cleanup..." is still required for combinations of target, project, and CVS changes.
• 16:20: Fight against the snow build-up. It's not supposed to snow now that spring was here.
  
• 16:30: Check Planet Eclipse again. Hmmm.
  
• 18:00: ...

I hope you get the idea... Please enjoy EclipseCon!