Nov 272007
 

So the other day I mentioned I was planning to buy a copy of Getting Things Done.  I mentioned to my wife that I was going to buy a book on organization and task management, and she said that she had one of those.  It was given to her at work years ago after a seminar the company brought in to help the office staff get organized.

We hunted it down, and lo and behold, it’s a copy of Getting Things Done, autographed by the author.

So I guess I’m good to go there!

My attempts to get better organized are still in their earliest stages, but yesterday I did complete three tasks that had been on my to-do list in some form for as long as six years, so I guess that’s something!

 Posted by at 12:49 PM
Nov 252007
 

As it turns out, I have way more to do than I actually have time for, between the things I want to do, the things I have to do, and the things that are OMFG if I don’t get this done I’m totally screwed.  So I need to learn to prioritize and keep track of all the things I need to do.  This is something I have a long and storied history of failing miserably at, and that needs to change.

Last night, I downloaded a copy of OmniFocus to see if that’s something I can make good use of.  I look at it, though, and I get totally flummoxed.  I’m hoping that spending some time watching the introduction video will help me make heads and tails of how to use it.

On top of that, I’ve about had it with my Treo.  Even though it’s a great device, it’s been two months since I’ve been able to sync it with my Mac, so it’s worthless as a PDA at the moment.  It hasn’t been able to do data connections in even longer than that (although I’ve not gotten off my lazy butt and called Sprint, they’ve failed to respond to any of my emails to tech support either, so I’ll call that an even split on the blame).  And I don’t actually use it for voice calls.

The sync problem is three-fold… it quit syncing properly well before Leopard came out — and even before that, it liked to duplicate data on address book entries (I have entries that have their email address listed 12 times or more). I suspect an issue with the Missing Sync there, rather than the Palm itself.  On top of that, the beta of the Missing Sync that’s supposed to make it work on Leopard still doesn’t sync for me.  Not sure why yet.  My enthusiasm for the Treo has fallen to the point where it’s hard to get up the energy to look into it in a meaningful way.

I’m sorely tempted to ditch it and get a basic cheap phone that’s smaller, and carry it and my iPod touch around instead; the touch’s PDA features are actually easier to use.  I’m increasingly convinced that as soon as an iPhone with 3G wireless comes along, I’ll beg Sarah to let me get one.

In the meantime, I need to find better ways to keep up with the tasks I need to accomplish.  We’ll see how that goes…

 Posted by at 3:52 PM
Nov 232007
 

This week’s Friday 5 is all about photographs:

  1. If a really, really good photographer — the kind who always makes you look good and still look like you — were to take your photo right now, what would be a good title for it?
    Geek inaction.
  2. If that photo were so good it belonged on the cover of a magazine, what would be a good choice, based on where you are and what you’re doing?
    Computer Gamer.
  3. If you took an interesting or aesthetically pleasing photo of something in your view right now, what might it be, and what would its title be?
    Probably my iMac.  The title would be “Beauty and the geek.”
  4. Among people you know, who seems to have a knack for taking great shots of people?
    I don’t know anyone like that.  If I did, there would be a lot more photos of me!
  5. Are you usually happier with candid photos of you, or photos you’ve posed for?
    As a general rule, I’m not very photogenic regardless of the situation, but posed shots are usually better.
 Posted by at 3:09 AM
Nov 202007
 

This blog post caught my eye a few minutes ago.  In it, the author complains that Firefox 3 memory use is vastly higher than Flock 1.0’s, then proceeds to include a screen shot of a utility that he says proves his point.

That utility is called iStat; I use it myself, as it happens.  The screen shot is actually showing not memory usage, but CPU usage.   So basically he’s demonstrating that while Flock is sitting idly in the background, his copy of Firefox is actively using the CPU.  That has nothing really to do with memory use.

Let’s actually compare memory use.  I started up both Firefox 3.0b1 and Flock 1.0.1, and compared their memory usage using the “ps” tool in Terminal:

Firefox 3’s memory usage is 5.1%; this after two hours of heavy usage.

Flock’s is 7.6% after running for less than 10 minutes and viewing less than a dozen pages.

As for CPU usage, both applications wander up and down the scale of how much CPU they use, with one or the other being ahead depending on what it’s doing.  That’s unsurprising.  Here’s a screen shot, for example:

 

Here, Flock is the heavy hitter and Firefox 3 isn’t even in the top 5.  It’s all a matter of timing your screenshot.

 Posted by at 4:15 PM
Nov 192007
 

As I remarked previously, we’re looking seriously into switching from MediaWiki to Deki Wiki for MDC.  This has caused quite a run of discussion, so I figured I’d post more thoughts on this.

We will have a development server up soon that people will be able to use to try out Deki and where we’ll be working on the software to make it work the way we need it to work.

Regarding spam

Deki provides a captcha mechanism to help prevent spam bots from signing up for accounts in the first place; this is an improvement over our current MediaWiki setup (although there is a captcha system available for MediaWiki, we’ve not installed one yet).

We’re pretty comfortable that the spam situation will improve with Deki (although to be honest we’ve managed it pretty well with MediaWiki so far, although it’s been a bit of a cat-and-mouse game to keep ahead of the spammers).

Regarding accessibility

I don’t know a ton about accessibility so I’ll be relying heavily on others to gauge the accessibility of Deki Wiki.

Regarding invalid markup

Yes, this is an ongoing problem.  It would be lovely to have perfectly valid markup but to be frank, that’s not really my priority.  My priority as documentation lead is to get the information out there and make it as easy as possible to create and manage that information.  I hope that we can make progress on this front, but I can’t let validity of the markup be an overriding factor in deciding what software to use to create the documentation because when you’re sitting there writing and editing content, that’s just not what matters the most.

As long as the site works in Firefox and other popular browsers, that’s really what means most.  However, that being said, I fully intend to urge the Deki guys to work on this!

Regarding the Deki editor
There’s an edit source mode that allows you to directly edit the XHTML for an article.  I don’t know about per-page CSS, although that would be nice.

There is a nice WYSIWYG table editor, although I’ve had some interesting issues with it acting oddly on certain table configurations (in particular, single-row tables seem to confuse it a bit).

 Posted by at 12:11 PM
Nov 162007
 

After a lot of research, it looks likely that we’ll be moving the Mozilla Developer Center away from MediaWiki, which we’ve been using for some time now, to Deki Wiki.  There are a number of reasons we’re probably going to be making this move:

  • Two words: Syntax highlighting.  You can specify a language for a code snippet and get syntax highlighting with numbered lines; fantastic for doing explanations of what a sample does.
  • Deki uses lucene for searching, and it’s built in, so we don’t have to fight with Nutch.  Searches can even go into attached files, so a search on, say, “nsIDownloadManager” will not only find articles mentioning that interface, but also any downloadable code samples that make use of it.
  • Deki offers a very snazzy WYSIWYG editor which should make it easier for new contributors to get going.
  • You can easily attach downloadable files to articles, and there’s a nice file manager for organizing these. This will make it much easier for contributors to offer sample code.
  • Very nice built-in statistic features.
  • Articles can be keyword tagged.
  • Advanced printing options, including PDF download option.
  • Since all content is stored in XML instead of in a database, we have some interesting possibilities for making portable versions of the wiki that could be downloaded and browsed offline.
  • It looks like it will be easier to customize the appearance and functionality of the site with Deki.

The folks at MindTouch will be writing us a utility to convert our current MediaWiki content into Deki, and will (assuming we do indeed decide to go ahead with this transition) be adding some new features to their software that we’ve requested.  This is a huge plus for us: we can get the software revised to meet our needs by people that know the code inside and out.

We’re still working out exactly what changes they would be making to the code for us, but it’s looking very good, and I think folks will be pleased with the result.

Assuming this transition happens, it will take place sometime early next year.  Hopefully in the first quarter but I wouldn’t be surprised if it slips into Q2, given the huge amount of stuff that needs to be done to make this happen.

I’ll blog further on this as things develop.

 Posted by at 4:26 PM
Nov 162007
 

My wife is coordinating the regional Girl Scout troops’ fall sale, which focuses primarily on nuts and candies.  As I write this, a truck is here offloading a garage full of cases of nuts that will be dispensed to the various troops tomorrow, so that they can turn around and dispense them to the girls for delivery to their customers.

This is nothing compared to the March timeframe, when we will have pallets upon pallets of cookies in the garage!  Hundreds and hundreds of cases (thousands of boxes) of cookies.  Yow!

 Posted by at 12:48 PM
Nov 152007
 

This week’s Friday 5 is about sliding.

  1. Where is the nearest playground slide?
    About a mile and a half away, if you mean a real playground.  But we have one in our backyard for our daughter to use, too.
  2. What’s something you recently let slide?
    I let important things slide every day because I’m among the world’s worst procrastinators.  Most notably is my 350+ “unread” messages in my email inbox.  Although I’ve actually opened and looked at nearly all of them, they all involve in some way something I need to do or think about. Yikes!
  3. Who recently let slide something you did?
    My wife.  She has to do this frustratingly often.
  4. Where is the nearest water slide?
    Wow, I’m not sure.  My guess is Pigeon Forge or Gatlinburg, Tennessee.
  5. When did you last slide down a pole, a rope, or an embankment?
    Hum.  Probably at least 15-20 years ago.
 Posted by at 8:21 PM
Nov 132007
 

Aeraj has been working hard on Places reference documentation.  While it’s still a work in progress, it’s coming along very nicely, and I’m quite pleased with his work so far.  Please feel free to give it a look and do edits if you see anything that’s busted.

Places is one of those technologies that sounds like something that won’t make any difference in your life at all — until you actually start using it and realize that it really is better than the way things used to be.  I’m really enjoying the changes to how bookmarks (and the super-cool URL bar) work.

 Posted by at 3:23 PM
Nov 092007
 

One thing that’s interesting about writing developer documentation is that it’s totally possible to write about something you don’t understand at all.  I’ve done this in the past; I once wrote a 450-page “chapter” that was widely received as being quite good even though I literally couldn’t actually figure out how to write code to do the things it was explaining how to do.  No exaggeration.

This amuses me.

I think that means that expectations of documentation are often rather low.  Documentation is obviously much better if the writer actually understands the material.  This is why I prefer to be able to write about things that I have the time to write sample code for.  Not just because sample code is useful (you can often crib sample code out of the product itself), but because the best way to learn how to do something is to do it yourself.

My best documentation always revolves around stuff I actually had time to write code for.  This is pretty much a universal rule.

The trick is that some things it’s really hard to write code for.  Things that are really deeply internal to Firefox do not necessarily lend themselves well to writing code to try out, for example.

Microformats

I’m actively working on the documentation for the Microformats API; you can see the work in progress, which is rooted in the article “Using microformats.”  This stuff is still in draft form, and a work in progress, so be gentle.

I’m finding microformats to be a more interesting topic than I’d expected, even though it’s a little harder to document than I’d expected.  I’m going to need to write some code to be more sure of myself in terms of how they work.   The problem is that I’m not exactly sure how really to do this.  I need to write a microformat handler, but I don’t know enough about how microformats work on the Web to actually do it yet.  I probably need to find a microformat that’s defined already but not implemented by Firefox and write code for it as an experiment; if anyone has a suggestion, please let me know.  The simpler the microformat, the better!

Places

Places already has a lot of conceptual documentation, courtesy of the engineers who actually did quite a good job of writing it up (woohoo).  I’ve asked a student at Seneca to work on putting together initial reference documentation for it; hopefully that work will start in the next few days.

I’ll also need to write an example or two for Places.  There are a lot of very interesting things you can do with Places’ API.  This will actually likely be a fun example set to write — I just need to find and/or make the time.

Firefox 3 Beta

We’re almost to the beta; last I heard, it’s scheduled to roll in mid-November.  The vast majority of the substantial documentation work to be done for Firefox 3 will be done by beta, although not all of it.  I’m  pleased with that.  If over the next week or two we can get Places reference material in place as well as a little more work on the microformats API documentation, I’ll be quite satisfied with the place Firefox 3 documentation is in, despite the relatively short list of things that aren’t done yet.

We’re on a great path to have complete Firefox 3 developer documentation in time for the final release.  Something that would really help make sure we get there is if the subject matter experts on the various topics related to Firefox could do a quick search on the dev-doc-needed keyword and make sure that the bugs that crop up that are related to their areas of interest have a comment in them that makes it clear what needs to be documented.  Many of these bugs are tagged as requiring documentation changes but don’t make it clear at all what needs to be done.  By adding a quick note explaining what needs to be written up, you can turn what could be an all-day or multi-day research project into a quick document edit.

 Posted by at 12:26 PM