Blue Sky On Mars

I’ve been reading 43 Folders for a while, and I really dig the whole GTD thing. Until today, I was keeping my next action lists in TextMate. But then I read Keith Robinson’s How I learned to stop worrying and love my schedule and it’s companion How I Schedule Actions and Tasks.

Spreadsheets are a great generic tool for keeping track of lists of things, adding stuff up and the like. (I hear there are some potential applications in financial fields as well, but I’ll believe it when I see it.) I’ve been looking for a decent Mac OS X native spreadsheet for a while, and just couldn’t come up with anything short of splurging on Microsoft Office.

Keith’s post highlights a workflow where tasks are kept in OmniOutliner and then scheduled in iCal. What Keith’s posting showed me was that you can have columns in OmniOutliner, and those columns can be tallied. It’s like a hierarchical spreadsheet. I’ve only just gotten started with it, but it’s a beautiful package.

When reading the articles, even though I loved what i saw about OmniOutliner, I could see a problem that I would have with the iCal part of the workflow. Keith alludes to it as well: it’s hard to rearrange big blobs of scheduled stuff if something comes up and forces its way into the middle of your schedule.

My thought: OmniOutliner to the rescue! I put estimates on my tasks the same way that Keith does. Then I create a “Schedule” outline with a top-level entry for each day and drag tasks from my various todo outlines onto each day. Most tasks don’t have to be done at a specific time of the day, so this works well. Just drop the tasks on the day and make sure the total of the tasks doesn’t go over the total time available in the day.

Outliners are naturally very good at selecting many nodes and moving them around to appropriate places. If something squeezes into my schedule, I just use this natural facility of the outliner to move things from one day to the next.

The only thing left is to figure out how to make appointments that do have a fixed time make it into iCal, which does alarms and all that good stuff. Maybe it’s not such a big deal, if I’m always just working off of the outline.

OmniGroup managed to get a bit of extra money out of me today, because OmniOutliner met these organization needs I had and it just happens that I have some diagrams that need making, so the bundle with OmniGraffle, etc. turned out to be a good deal. This is particularly true given that OmniGraffle is about to have a price increase.

Technology

Bert Decker has written 6 Don’ts for the End of Your Presentation. For those of us who only make the occasional presentation, these kinds of tips are a great thing. Little touches can make a big difference.

Random

Since I started using the convenient L10 Hit Counter in June, I’ve been able to very easily see what people are reading here whenever I want. Mysteriously, the #3 URL here, just behind the BSOM front page, since mid-June is my posting about the Flying Spaghetti Monster. Apparently, the Pastafarians are a larger more dedicated lot than I originally expected. The original FSM site has grown quite a bit. 10 million hits (now up to 750k per day), and startling bits of work like Touched By His Noodly Appendage.

Bobby Henderson has finally provided reasons to convert to Flying Spaghetti Monsterism:

• Flimsy moral standards.
• Every friday is a relgious holiday. If your work/school objects to that, demand your religious beliefs are respected and threaten to call the ACLU.
• Our heaven is WAY better. We’ve got a Stripper Factory AND a Beer Volcano.

The big news comes from Boing Boing (from whence all big news comes): there’s $750,000 up for grabs for anyone that can prove that Jesus is not the son of the Flying Spaghetti Monster. Just as the original FSM open letter was a parody of the insanity of suppressing evolution science, this purse is a parody of an offer for $250,000 for proof that evolution occurs (with a big * that broadens the notion of evolution to include the proverbial kitchen sink).

Ahhh… the Net has been touched by his noodly appendage indeed.
Boing Boing: Boing Boing’s $250,000 Intelligent Design challenge (UPDATED: $750K)

Funny

After I first announced Zesty News, I mentioned that it was an RSS reader, and I talked a bit about making it browser-based and cross-platform, while still including reasonable support for things expected on Macs and PCs.

I hadn’t talked about what makes Zesty News special, and that’s just as well since I ended up delaying things a bit. Now that the alpha is out and available to testers, I have put more information about Zesty News up on the Blazing Things site.

The things that are talked about on the Blazing Things site are features right now. They’re not vaporware. There’s a bit more to add before Zesty News Lite 1.0 beta is done.

Blazing Things

Last week, Ian Landsman wrote about leaving features out in order to get a product out the door, and I promised to write about delaying a product to make it stronger.

One thing about writing a blog is that, as long as you’re honest, you give yourself an automatic history. Something you can look back and reflect on. For example, on May 10th, I wrote that the Zesty News alpha was feature complete, and that there was only bug fixing and interface cleanup to go. And that was true, at that instant. Rich Sheridan is fond of saying “last minute change is a competitive advantage”. If change is necessary to succeed, changing at the last minute is better than not changing at all.

So, a funny thing happened on the way to the alpha release: I decided to make some changes. Two things kicked off what I’m calling my Summer of Refactoring (aka, Thank God for Automated Tests): a desire for better perceived performance and an acknowledgement that plugins are more important to Zesty News than I had first thought.

I’ve been actively using Zesty News for months now. One thing that had bothered me a little bit, but not enough to take immediate action, was that the UI would sometimes pause for a second or two if feeds were being updated while I was reading. On one hand, it was a minor niggle… what’s a second or two, right? But, on the other hand, it breaks the flow of reading and lessens the total experience.

So, I started looking at my options. I ended up concluding that the sqlite database was just not the right database for Zesty News. It’s a great database for a large number of desktop applications. But, Zesty News is almost like a multiuser application in that the feed updating happens right alongside the user’s reading. sqlite is very fast, but Zesty News has a fair bit of bookkeeping to do to work its magic.

At about the same time I came to that conclusion, I also looked at the field of competitors at the time and knew that plugins are going to be an important part of what Zesty News can offer. I’ve been planning all along that the difference between Zesty News Lite, the free version, and the full Zesty News would be completely implemented in plugins. That will greatly ease my maintenance burden, and it will also ensure that others who want to make plugins have a powerful facility to do so.

With a decision to change the database engine already there, I decided that I would open my mind to other changes that would make things easier for people who want to write plugins.

The first couple of weeks of June were lost to a false start on the database change. I liked many aspects of the change, but there was a different performance problem introduced there. One that was just not acceptable to me. Once I discovered that the Firebird database was actually a viable option, I was all set and could proceed forward.

The next step was to put in the best pieces for plugin writers, so that I could make writing plugins easier. I changed around a whole bunch of infrastructure parts that I had chosen. The shape of the Zesty News code changed around the edges, and everything was streamlined a bit and became more pleasant to work with.

The Zesty News of today no longer has the concurrency problem that it had on May 10th. The main interface looks much better (thanks, Kirsten!), there is a smattering of new features, and the infrastructure is fun to work with. I’m exceedingly happy to have changed course, because I know that the Zesty News of today is going to be much better for what comes next: real users.

Sounds like a good time to start the alpha for real! And that’s what I’m doing.

Blazing Things, Software Business

Understand up front that I’m not saying that Joel is wrong about how he develops software. Joel’s comment in The Project Aardvark Spec about extreme programming doesn’t seem to fully appreciate what goes on (or is supposed to go on) in an XP project.

As I worked through the screens that would be needed to allow either party to initiate the process, I realized that Aardvark would be just as useful, and radically simpler, if the helper was required to start the whole process. Making this change in the spec took an hour or two. If we had made this change in code, it would have added weeks to the schedule.

Joel is confusing XP with the ad hoc “just dive in and code ’til it’s done” methodology. He uses the statement above to support Big Design Up Front vs. XP. But, this implies that an XP project would have gone and implemented the whole thing before someone finally slapped themselves on the forehead and said “D’oh! We should’ve just made the helper start the process!” Let’s take a look at how a real XP project might have addressed this:

1. There is up front work in the form of story cards. It’s entirely possible that in creating and estimating the story cards at the beginning of the process, “helper initiates process” and “victim initiates process” may have been two separate cards. They may have had to be two separate cards, since a given story can’t be longer than an iteration. Given that, the “victim initiates process” story just might never have been scheduled in the first place.
2. Particularly if there are UI questions, it is not unreasonable in an XP project to put some effort into UI mockups in the first iteration. At this point “victim initiates” may suddenly start looking very clumsy, causing the story to get dropped.
3. Let’s say that the problem was not in the UI, but how the code needs to work in order for the victim to initiate. When going through the story cards at the initial estimation session, one of the programmers might have thought of a potentially tricky aspect of “victim initiates”. If that’s the case, they might get a new card written for a “spike”, which is a brief experiment to test out the potentailly problematic area.
4. Assuming that “victim initiates” made it all the way through the steps above. It gets scheduled and worked on. Odds are good that the programmers would notice that something’s up mid-iteration. It is legal to change things mid-iteration, if new information arises. Worst case scenario: they go the whole iteration (2 weeks, usually) working on that story before it gets ditched at the next planning session.

XP is not dive in and code. The whole point of XP is written on the cover of Kent Beck’s book: “Embrace Change”. At the beginning of Joel’s Project Aardvark spec, he mentions that the spec is not cast in stone. The problem with many Big Design Up Front (BDUF) projects is not that a spec is written… the problem with many projects is that the spec is cast in stone and requires an elaborate “Change Request” procedure to alter the spec.

Before you call me an XP lunatic: I don’t think XP is the be-all and end-all development methodology. Different projects need different processes. To me, the biggest thing to come out of XP is not the XP process, but Test Driven Development, which I consider a good thing regardless of how the project itself is planned and run.

Software Development

Since Jon Udell’s been all over “screencasts” lately, it’s good to know what screen capture tools are available. I’ve just updated my original blog post about screen capture tools from January to include CamStudio. Unlike Wink, CamStudio does audio and video right now. Well worth a look.

Technology

It didn’t take long to hear back from eight people in southeast lower Michigan (with a disproportionate percentage in Ann Arbor), so I have gone ahead and started the Michigan Python Users Group (michipug) mailing list.

People have different agendas for their user groups. Jim Holmes appeared to be seeking World Domination with his .NET user group in Dayton, Ohio. I’m going to toss out an opening volley in what I’d like to see in a user group:

• Semi-regular, face-to-face, semi-structured meetings to meet up with smart people and exchange useful and practical info about software development in Python.
• Exchange of useful local information on the mailing list (relevant job postings, events, etc).
• Occasional sprints, for people interested in writing some code together
• An organized group that can harrass Python dignitaries that happen to come to Michigan into sharing a slice of their knowledge. (Consider yourself warned, visting dignitaries!

This all sounds fairly similar to ChiPy, which doesn’t seem to be a bad thing, because those guys seem to be enjoying themselves.

So, if you’re somewhere in Michigan, use or want to use Python, and have email: sign up now for michipug.

Python

Since Google searches don’t turn up much of value here, I’m curious if there are any folks out there reading this that work with Python and are in the Ann Arbor or Detroit area. I don’t see signs of an established PUG around here.

Update: There are Pythonistas in this area. Rather than replying to this posting, you can now sign up for michipug.

Python

2008 is the first year in which I am eligible to run for President, so naturally I had planned to throw my hat into the ring. But, now that Christopher Walken is running, I know that there’s no point

Still, it seems a little funny to think of Zorin as our President. Or Colonel Angus, for that matter.

Walken’s speeches would be great to listen to and watch, however.

Politics