Burning Chrome

Growing pains - for the community

You know, when Mitchell Baker posted her newest missive, talking about Thunderbird making its own nest in the future, I reacted much the way I expected (and now see) others would react: with disappointment. Although this time, I decided I'd wait a little before commenting. The last time I spoke my mind, I regretted it because I'd misunderstood what Mitchell was actually saying.

I think that's happening again. Rather than bash Mitchell again, I'm coming to her defense this time - because I think people are bashing her too hard.

It's difficult for me to articulate my feelings on this. On the one hand, what Mitchell and Brendan are doing make sense. The browser is the priority because that's what people demand the most of. On the other hand, we want mail/news, we want authoring, we want music, we want debugging, we want all kinds of things.

You may notice something about the links I posted above: with the (current) exception of Mozilla Thunderbird, the products under development or currently available to meet these needs don't come from the Mozilla Foundation. I mean, think about it: just how much do you expect Mozilla to do? Would you really want one organization to do everything, or one organization to have you do everything their way? We have enough companies with aspirations to exactly that right now - Microsoft, Google, and Oracle come to mind. (So does FSF.) Maybe this move is actually a good thing.

The simple fact is, software development is a hard task. It takes years to learn how to do it right - and even then, colossal blunders can be made. The active contributors to a project even of Mozilla's size is always changing, but it's never enough. Some people leave, others come aboard, but we're chronically swamped. Plus, in my case and that of many other developers, we go after the bugs that interest us or annoy us the most. In other words, to get me to fix the bugs you care about, often you have to convince me why your bug is more important and more immediate than mine. Which, I have to admit, is pretty hard to do, since I have a lot of things I want to work on. (The exception to this is keeping a roof over my head, which is a separate discussion.)

The best solution might be to guide people towards getting their hands dirty. As I said, we're chronically swamped as developers. We could certainly use a little help - not in telling us what's important (since we hear that all the time), but in actually fixing the important bugs. Perhaps we should promote a new philosophy towards bugs: "How can we help you to fix this?" In other words, empower the community a little more by directly involving them in the process of bug fixing.

The nature of open source says any one person - or organization - can work on anything they choose. By implication, that which no one chooses to work on will not change. The Mozilla Foundation has made its choices, and if you think about the implications of Microsoft-style "we can do everything, better" attitudes, it might be the right decision. Our complaining about it, though, does little to help the situation. The right solution is to work on the problems that confront you, whether technical or not. There's no reason to make this a popular battle and become a lobbyist, begging for others to change their minds.

For the last few days at work, I've been ruefully thinking that I was spoiled by learning how to write C++ code for Mozilla, instead of generic C++ code. Maybe the same is happening here: we've been spoiled by the ideals of what Mozilla (the name) stands for, and relying on that a little too much. The original Mozilla attitude was not standing up to anyone or against anyone, but standing up for yourself and getting things done. We who use these products on a daily basis need to recapture that attitude.

My favorite t-shirt says it best:

hack
this technology could fall into the right hands

Roadshow: Bicyclists just want to know how to trigger left-turn signal

Mr. Roadshow from the San Jose Mercury News

I landed in the newspaper yet again. I don't know how I do it. (It's also my 400th blog entry.)

QAFound: Reducing testcases (follow-up)

I figured out the cause of my major woes tonight: bug 388267. I have a workaround, so I'm back to hacking on Verbosio's trunk.

Also, our good friend Boris Zbarsky lent a hand debugging bug 388254, which is really very noisy in Verbosio. We believe that bug 388255 is a direct result of it, too. As for bug 388264, that is likely a duplicate bug, but no one's checked that yet.

That accounts for all the bugs I filed as a result of my Verbosio snapshot a few days ago. I'm a happy coder.

Though also a bit lazy:

WeirdAl		is not at all excited about hacking layout...
		"you touch it, you own it" and all that, you know
		WeirdAl: the other side is "you don't touch it, it stays broken" :)
		hehe
ajschult	typically prefers not-broken

Verbosio: First Look

There's an old saying in the open-source community: "Release early, release often." I confess now that with Verbosio, my prototype for an extensible XML editor, I've done neither. I have put two years into it, and I have little to show for it - just some nice screenshots.

Until today.

A few days ago, I asked for help reducing testcases. Jesse Ruderman pointed out that I hadn't given anybody a real testcase to reduce. Neil Rashbrook pointed out in response that Verbosio was too big for Bugzilla. In essence, both were right.

So I spent the last two days re-arranging the Verbosio repository, in order to provide a "snapshot" of Verbosio which people could reference in Bugzilla. It goes beyond that, however: it's also a snapshot of the Verbosio code base which anyone with a XULRunner build (1.9a6 or trunk) can experiment with. It's not just for filing bugs against Gecko, in other words.

It's a chance to look inside my head, and see a piece of the vision I've been dreaming up for two years. It's a chance to actually play with Verbosio, and see where it's going.

Right now, it sucks, bad enough for me to say on the installation page:

This "snapshot" is specifically for Mozilla developers in order to debug several problems which the author believes are not the fault of his application (NS_ASSERTION failures, weird XUL deck behaviors, etc.). If you are using Verbosio for any other purpose, be aware that it can do nasty things to edited files, computer performance, and your grandparents. Use this snapshot with extreme caution. You have been warned.

However, I suppose that as software projects go with initial source package releases, I'm in pretty good company. Netscape, I remember hearing, had a really ugly package for their Communicator 5.0 initial source release. Lots of other projects put out code that's nowhere near ready for general use, with lots of incomplete features just waiting to shock users.

So, to get you started in Verbosio (if you're daring enough), try the following steps.

1. Get a XULRunner package (trunk or 1.9a6).
2. Download the gzipped tarball (approx. 1 MB) from Verbosio's installation page. (Note: it may not be on all the mirrors yet - it should be there in less than 24 hours.)
3. Unzip and untar the tarball (after a virus and spyware scan - you don't trust me that much, do you?)
4. Run the application. Use the "default" application, not the "testing" application.
5. When it's running, go to Verbosio -> Open testing verbosio.xul. Watch Verbosio load a copy of itself (from the "testing" subdirectory) into its tabbed editing space. (Note: There's a bug I haven't figured out yet with Verbosio on the Mac platform, involving symlinks, which prevents you from doing this. Sorry.)
6. Play with it to your heart's content. As long as you don't try to edit (opening up is okay) any other XULRunner applications or Firefox/Gecko-based XUL extensions with Verbosio, you should be pretty safe. The "testing" subdirectory application is disposable - you can get a fresh copy from the tarball at any time.

Several of the features:

• WYSIWYG view with partial editing support
• Support for editing DTD entities inside the XML document, and having those entities update in the original DTD
• Source code view
• DOM Inspector-like tree views
• A chrome registry viewer

These are just what's visible to the user. There's a lot of infrastructure too (ECMAScript design by contract, automated tests, support for extensions without conflicts of variable names, virtual files, a markup language for XML templates, DTD and entity management, undo/redo support including DOM operations, base URI mappings for starters).

Finally, the snapshot you see is on a branch (0.1a1pre.0.*), while the trunk is on a different line (0.1a1pre.1.* right now). That way, the branch itself can remain relatively static, and be a good reference for others. Also, the branch will work with any XULRunner build 1.9a6 or later (meaning 1.9a7, 1.9b1, 1.9, 1.9.1, etc.), while the trunk will remain based on a single milestone at a time (1.9a6 currently), so that I can work with an unchanging XR base. (In other words, the stable branch will tie to an evolving XULRunner, and the evolving trunk will tie to a stable XULRunner.)

This tarball and its contents are available under MPL 1.1 / GPL 2.0+ / LGPL 2.1+. Change log in the extended entry.

2007-07-15 23:10  ajvincent

	* verbosio/src/core/content/appOverlay.js: Merge from
	  SNAPSHOT_20070713_BRANCH: The app.* fields in
	  chrome://verbosio/content/app.properties has been removed; update
	  chrome://verbosio/content/appOverlay.js to cope.

2007-07-15 21:56  ajvincent

	* verbosio/www/installation.html: Point users to 0.1a1pre.0.6
	  tarball.

2007-07-15 19:35  ajvincent

	* verbosio/: README,
	  downloads/snapshots/branch_20070713_tag_006.tar.gz: Add
	  SNAPSHOT_20070713_TAG_006 object directory tarball to Verbosio
	  downloads.

2007-07-15 19:33  ajvincent

	* verbosio/src/core/VER_LAST: Bump version for
	  SNAPSHOT_20070713_BRANCH to 0.1a1pre.0.7.

2007-07-15 19:31  ajvincent

	* verbosio/src/core/VER_LAST: Move Verbosio version to 0.1a1pre.0.6
	  for SNAPSHOT_20070713_TAG_006 tag.  Branch will leap ahead to
	  0.1a1pre.0.7.  This will keep future tags in synch with their
	  version numbers.

2007-07-15 19:25  ajvincent

	* verbosio/src/core/content/templateFrame.xul: Simplify
	  templateFrame.xul in order to show deck layout bug more clearly.

2007-07-15 18:20  ajvincent

	* verbosio/README: Fix version numbers inside README for the
	  Verbosio project.

2007-07-15 18:19  ajvincent

	* verbosio/README: Update README file for the Verbosio project to
	  reflect the SNAPSHOT_20070713_TAG_005 tag.

2007-07-15 18:14  ajvincent

	* verbosio/src/core/VER_LAST: Bump version for
	  SNAPSHOT_20070713_BRANCH to 0.1a1pre.0.5.

2007-07-15 18:12  ajvincent

	* verbosio/downloads/snapshots/branch_20070713_tag_005.tar.gz: Add
	  SNAPSHOT_20070713_TAG_005 object directory tarball to Verbosio
	  downloads.

2007-07-15 18:01  ajvincent

	* verbosio/src/core/content/appOverlay.js: The app.* fields in
	  chrome://verbosio/content/app.properties has been removed; update
	  chrome://verbosio/content/appOverlay.js to cope.

2007-07-15 17:28  ajvincent

	* verbosio/src/: make-project.pl, core/components/xeTestEngine.js:
	  Landing from SNAPSHOT_20070713_BRANCH branch:  Remove the need
	  for filesystem-specific directories in
	  chrome://verbosio/content/app.properties bundle.  (Dated Mon Jul
	  16 00:08:26 2007 UTC.)

2007-07-15 17:22  ajvincent

	* verbosio/README: Fix the date on the README file.

2007-07-15 17:19  ajvincent

	* verbosio/README: Update README file for the Verbosio project to
	  reflect the SNAPSHOT_20070713_TAG_004 tag.

2007-07-15 17:16  ajvincent

	* verbosio/downloads/snapshots/branch_20070713_tag_004.tar.gz: Add
	  SNAPSHOT_20070713_TAG_004 object directory tarball to Verbosio
	  downloads.

2007-07-15 17:14  ajvincent

	* verbosio/src/core/VER_LAST: Bump version for
	  SNAPSHOT_20070713_BRANCH to 0.1a1pre.0.4.

2007-07-15 17:08  ajvincent

	* verbosio/src/: make-project.pl, core/components/xeTestEngine.js:
	  Remove the need for filesystem-specific directories in
	  chrome://verbosio/content/app.properties bundle.

2007-07-13 20:50  ajvincent

	* verbosio/www/installation.html: Emphasize in installation page
	  that currently XULRunner is not packaged with the snapshot
	  tarball.

2007-07-13 20:36  ajvincent

	* verbosio/README: Update README file for the Verbosio project to
	  reflect the actual SNAPSHOT_20070713_BRANCH,
	  SNAPSHOT_20070713_TAG_003 tags.

2007-07-13 20:35  ajvincent

	* verbosio/www/installation.html: Post a link to
	  SNAPSHOT_20070713_TAG_003 gzipped tarball on installation page.

2007-07-13 20:25  ajvincent

	* verbosio/src/core/VER_LAST: Bump version for
	  SNAPSHOT_20070713_BRANCH to 0.1a1pre.0.3.

2007-07-13 20:19  ajvincent

	* verbosio/downloads/snapshots/branch_20070713_tag_003.tar.gz: Add
	  SNAPSHOT_20070713_TAG_003 object directory tarball to Verbosio
	  downloads.

2007-07-13 20:06  ajvincent

	* verbosio/src/make-project.pl: Another change to 20070713 snapshot
	  branch:  Remove compileIDL.pl, backport.pl, run_verbosio.sh from
	  the build process.

2007-07-13 19:49  ajvincent

	* verbosio/src/core/VER_LAST: Bump version for
	  SNAPSHOT_20070713_BRANCH to 0.1a1pre.0.2.

2007-07-13 19:40  ajvincent

	* verbosio/src/core/application.ini.in: Bump MaxVersion for
	  applicatio.ini.in to 1.9.*, so that others on trunk XULRunner can
	  examine the branch.

2007-07-13 19:38  ajvincent

	* verbosio/src/core/VER_LAST: Bump VER_LAST for Verbosio
	  application to 0.1a1pre.1.0.

2007-07-13 19:14  ajvincent

	* verbosio/src/core/VER_LAST: Bump version for
	  SNAPSHOT_20070713_BRANCH to 0.1a1pre.0.1.

2007-07-13 18:34  ajvincent

	* verbosio/: README, src/code-languages/css/install.rdf.in,
	  src/code-languages/javascript/install.rdf.in,
	  src/document-packs/xul-application/install.rdf.in,
	  src/generic-viewers/inspector/install.rdf.in,
	  src/generic-viewers/preview-edit/install.rdf.in,
	  src/generic-viewers/source-edit/install.rdf.in,
	  src/markup-languages/xul/install.rdf.in,
	  src/pack-viewers/chrome-contents/install.rdf.in,
	  src/pack-viewers/dir-contents/install.rdf.in,
	  src/xpathgen/install.rdf.in, src/core/VER_LAST: Move Verbosio
	  executable to version 0.1a1pre.0.0, in preparation for snapshot
	  branch.

2007-07-10 07:48  ajvincent

	* verbosio/src/core/application.ini.in: Move Verbosio's required
	  XULRunner to version 1.9a6.

2007-07-10 07:48  ajvincent

	* verbosio/src/core/content/verbosio.js: Fix error with closing
	  Verbosio and not having opened a document pack.

2007-07-10 07:47  ajvincent

	* verbosio/src/core/: components/documentFile.js,
	  components/entityManager.js, components/nodePositionService.js,
	  components/templateXTF.js, components/textDocumentWrapper.js,
	  components/verbosio-utils.js, components/virtualProtocol.js,
	  components/xeBaseURIMap.js, components/xeFileSearch.js,
	  components/xeTestEngine.js, content/templateWizard.js: Gecko
	  1.9a6 prep:  load components from resource://app/modules/,
	  resource://gre/modules/.  Update calls on XPCOMUtils.

2007-07-10 07:43  ajvincent

	* verbosio/src/core/modules/ArrayConverter.jsm: Gecko 1.9a6 prep:
	  Update ArrayConverter.jsm docs to reflect the new world order.

2007-07-10 07:42  ajvincent

	* verbosio/src/core/modules/XPCOMUtils.jsm: Gecko 1.9a6 prep:  Add
	  modification for XPCOMUtils.jsm module, which will wrap a
	  singleton component object for XPCOMUtils.

2007-07-10 07:41  ajvincent

	* verbosio/src/make-project.pl: Gecko 1.9a6 prep:  Stop copying
	  modules into the components directory.

2007-06-17 20:00  ajvincent

	* verbosio/src/core/: content/templateWizard.js,
	  content/templateWizard.xul,
	  locale/en-US/verbosio/templateWizard.dtd: Not part of the build
	  (yet) for template creation wizard.  Add user-interface for
	  disabling text inputs, setting markup:xpath attributes as needed,
	  and keeping everything synchronized.	Note this check-in requires
	  mozilla.org bug 209555 be patched.

2007-06-17 19:52  ajvincent

	* verbosio/src/core/: components/verbosio-utils.js,
	  idl/xeIVerbosioUtilsService.idl: Break up
	  xeIVerbosioUtilsService.getSupportingTemplates() into two
	  functions; the first becomes
	  xeIVerbosioUtilsService.getTemplateDocument().

2007-06-17 19:48  ajvincent

	* verbosio/src/core/: components/templateXTF.js,
	  idl/xeIMarkupLanguage.idl: Add method for 
	  elements to publicly match a UI node to the corresponding output
	  node.

2007-06-17 01:31  ajvincent

	* verbosio/src/core/: content/template.css,
	  content/templateFrame.css, content/templateWizard.js,
	  content/templateWizard.xul, content/bindings/template.xml,
	  locale/en-US/verbosio/templateWizard.dtd,
	  skin/verbosio/templateFrame.css: Check in mockup of template
	  builder wizard UI.  Note this is not yet functional, and not part
	  of the app.  It also needs a lot more comments and a thorough
	  code review.

Raindrops from a brainstorm

Every now and then, I have a really good idea, something that I think would shake up the authoring/editing community and add simple, useful capabilities we've never seen before. Basically, I run into a problem when I'm working on code, and I come up with a solution... but I just don't have the time to prototype it, implement it, and see how it works out. I figured today that I might as well throw a few of these ideas out for the community to chew on.

UPDATE: I forgot to mention - if anyone wants to implement these ideas, go right ahead. :-) I'm posting them because I don't have time to do them myself right now.

I'd like to see what the Mozilla community - and the authoring / editing tools community at large - think. The ideas I'm sharing now are in the extended entry.

Interpreted files through a preprocessor

Problem: When working on chrome files or component files, often the object directory file is an exact copy of a source file. In cases like this, the operating system can create a symbolic link, or "symlink", between the two. However, for files that go through a preprocessor, where other files can be included, or sections of the source file dropped, it's not an option. Despite this, the source file and the object file aren't that different. Sections of one match up with sections in the other.

More specifically, when I get a stack trace from a JavaScript file that's been preprocessed, the JS source lines rarely line up to the object source line numbers.

Solution: Create an annotation (either in the files or outside them) which links sections of source files to corresponding sections of object files. I call this concept a "sub-symlink". (I don't know if anyone else has come up with the idea.) A smart editing program can read these sub-symlinks, and when you edit a section of code in the source file, it can update the corresponding section in the object file. Even better, if I want to edit the object directory file (which for XUL, JavaScript, CSS, etc., don't need to be compiled), then the changes can reflect in the source directory file right away, and I don't have to call make on the object directory again. The smart editor becomes responsible for propagating the change, including to multiple object directories based on a single source directory if the user so desires.

Experimental change sets

Problem: Whenever I go into debugging mode, trying to fix an error, I'll try a bunch of different things. Usually, three or four different approaches don't work. Unfortunately for me, I tend to forget when I've tried an approach - so I end up trying it again thirty minutes later. On the other hand, I'll also tend to forget what changes I've made, so if I end up taking a path that can't work, I want to go back to a set of changes which are better than the original state of affairs.

Solution: Use a revision control system instead of the ordinary file system for storing changes - and when saving a file, export from the VCS to the file system. By this, I don't mean "check changes into the remote repository and see if they work" - rather "check changes into a local repository, which has its own version tracking separate from the remote repository. Then see if the local changes work."

This also has the benefit of permitting comments for each change set, so that I can annotate what I'm trying to do. You could also store all kinds of metadata (including annotations for sub-symlinks!) in the repository. Additionally, undo/redo takes on a whole new meaning - tree-based instead of linear. Just creating the user-interface for that should be interesting.

Subversion could work for this (especially if the editor has access to svnadmin and is very careful about how it interacts with Subversion). However, a distributed revision control system such as Mercurial would work even better, since you have a local copy of the full repository already, and full rights to commit to your local repository without affecting the primary one.

(I didn't understand this at all - what a distributed RCS does better than a centralized RCS, until I read this sentence from the unofficial Mercurial book: "What distributed tools do with respect to forking is they make forking the only way to develop a project." To track a series of change sets while keeping those change sets from reaching the central repository, you essentially have to create a forked copy of the repository - even if it only lives for a few hours. So, a local repository can hold unstable, not-ready-for-bug-attachment changes - and the editor can interact with the local repository.)

The downside is that your project then becomes beholden to the license of the revision control system. This can present real problems, when you want other neat capabilities from open-source projects with incompatible licenses. This is one of those cases where the LGPL is more useful than the GPL...

Distributed editing and reviewing

Problem: For all the strengths Bugzilla has, it's really hard to make a change to a patch. What happens is the reviewer says "Do this instead of what you're doing here. r+ with that change." Then the original patch author makes the change locally, submits a new patch to Bugzilla, and checks it in.

Solution: Review approvals are really about agreeing to sections of a patch, and more specifically about disagreeing to sections of a patch, suggesting improvements. (I am ignoring r- issues for "this patch is not even close to being ready".) Here, distributed RCS's may offer us a new working model:

1. Alice makes changes A, B, and C to a file.
2. Alice then submits it to Bugzilla as an attachment.
3. Bugzilla makes a copy of the central repository for that bug and applies the patch. If the patch doesn't apply cleanly, Bugzilla rejects the patch and tells Alice.
4. A week later, Bob tells Bugzilla "I want to review this patch." Bugzilla updates the bug's repository from the central repository and finds a conflict. Bugzilla says to Bob, "Sorry, there's a conflict, don't waste your time." Bugzilla then e-mails Alice, "Hey, your patch has bit-rotted. Clean it up, please." Alice works with the bug's repository (possibly her own first) to resolve the conflict.
5. Bob, reviewing the patch, doesn't like a few lines of change B. He knows what he wants, though, and modifies change B in the Bugzilla repository for that bug. We'll call this change B₁.The remaining sections he marks as r+.
6. Alice sees B₁ applied to the bug's repository and agrees that's better. Alice then marks r+ on B₁. Bugzilla reminds Alice the patch has r+ for all sections. Alice then requests super-review.
7. Catherine, doing super-review, objects to a part of change C, and submits an alternative, C₁, to the bug's repository. She marks A and B₁ as sr+.
8. Alice disagrees with Catherine's change, and amends it again, offering C₂.
9. Catherine likes it and marks C₂ as sr+. Bugzilla tells Catherine that the patch has r+ and sr+ for all sections directly, and e-mails a notice to Alice.
10. Alice checks it into the central repository.
11. The Firefox tinderbox goes orange. :-) Alice fixes the bustage, posts a note to the bug, and everyone's happy.

It's a few more steps, and Bugzilla has to do a bit more work (needing a bigger hard drive), but it allows for interactive editing of a patch. Less work on the part of Alice, and Bob's and Catherine's suggested changes go right in.

QAWanted: Reducing testcases

I've gotten myself in a real pickle now. In writing this XULRunner app, Verbosio, I've ignored assertions, worked around oddities, but now I'm essentially blocked due to an obscure layout bug.

Essentially, I have a XUL deck, and what that deck is reporting as its selected panel is in fact not what the user sees.

Obviously, I should report it to Bugzilla. Except that I have no idea how to produce a testcase that will show the same results in Firefox 3.0 alpha 6 (the equivalent milestone). A bug that cannot be reproduced by a separate person is essentially INVALID, WONTFIX, and INCOMPLETE.

There are exceptions, but they require an exceptionally dedicated hacker (thanks, bz!!!).

So I am putting out a call for help. I need a few people who are willing to spend volunteer hours taking a look at these weird behaviors and trying to reduce them to manageable testcases which can be reproduced in Firefox 3 or XULRunner, either trunk or alpha 6. Once you've got such a testcase, please file a bug on it and cc me. If the bug is in Verbosio's code, use Mozdev's Bugzilla - otherwise, use mozilla.org's Bugzilla. (You may find that both are doing something wrong in the same area, which wouldn't surprise me.) I'm available weeknights and weekends, Pacific time zone.

If you are willing to do so, please leave a comment on this blog entry. I'll gladly walk you through the process of reproducing these bugs in Verbosio (including building and running Verbosio). You'll need a XULRunner build, 1.9a6 or trunk, probably a debug build - and that means compiling your own. You'll also be getting your hands dirty with delta debugging in XUL.

I think the only reward you'll get for reducing the testcases and filing the bugs is an "attaboy" from various people in the Mozilla community. That, and having your testcase added to Mozilla's regression test harnesses, probably as a reftest. (For those near San Jose, California, it'll probably also mean a free meal.)

UPDATE: I'm going to work tonight on putting out a "snapshot" nightly so that no one will have to run Verbosio's make process. Then all you'll need is a XULRunner debug build. News at eleven.

UPDATE 2: I've posted a gzipped tarball snapshot to Verbosio's downloads directory. It'll take a few hours for the tarball to propagate to the mirrors, but the instructions for grabbing it are here.

Do you know someone in San Jose with a wood shop?

I know this is totally off-topic for Mozilla, but I find myself wanting to take up a new hobby, carpentry. To spare people who don't care, the rest of this entry is in the extended entry.

For the last couple of years, I've had a desire in the back of my head to do a little bit of woodwork. I can't put my finger on why, but when I was a little kid, my dad gave me a bookcase that he himself had built when he was many years younger. Last year, I asked him if he and I could just spend some time building something, but we never found the time to start.

Today, I wandered into four different furniture stores, looking for a new computer desk to handle my four computers. When I looked through the catalogs, though, not one of them really impressed me enough for me to say "I'll take that - here's a check." Walking away from the second of those stores, I found myself thinking about the kind of desk I wanted: one where I could slide my chair into the center, and swivel in the chair from workstation to workstation. A circular desk, in other words.

Not many people make circular desks, though, for the general public. Even Google turned up only one manufacturer in the first 100 search results for the phrase "circular desk". Of course, I can custom-order it, but that's going to cost a pretty penny.

Instead, if it's at all feasible, I'd like to simply build it myself, under the guidance of a craftsman. It'd be a spare-time project, and I'd certainly take it more to heart now than I did in eighth-grade shop class.

There's also the consideration rumbling in the back of my head that I may not be able to do computer work forever. Don't get me wrong, I still love programming and designing applications - but twenty, thirty years from now, who knows what software engineering will be like? Will I even be able to do it then, or will my skill sets be totally mismatched to the industry in that time frame?

An even better question to ask is "Will I want to do it anymore?" A colleague of mine and friend (whose name many Mozillians would recognize instantly) has decided to get out of software engineering entirely. (No, I'm not talking about Jamie Zawinski and the DNA Lounge. This is much more recent.) Right now, I can't see why he made that decision, probably because I can't see why I'd make that decision. I love it too much to even think about leaving right now. But twenty years from now...

The thought of me not doing software engineering actually scares me. For over twenty five years now, messing with computers and seeing how to make them more useful as tools has been an overriding theme in my life. I've even managed to build a career (for the moment) out of it, without spending a day in college. That's no mean feat in the 21st century, but there may come a day when I can't - or even worse, don't want to - do it anymore. If I don't have another way to support myself, I'll sink -- and I don't mean just financially.

Oh, I love writing, and a few other things, but none of them really leap out at me as anything that I can currently support a family on. As good as things are now, I really don't like not having a fallback plan, some other set of useful skills. But to be perfectly and bluntly honest, I don't have any other trades.

So: Carpentry. I think I could learn that. It might even be fun. Certainly I love the smell of fresh wood.