WeSay News

Thanks to Cathy, we now have a revamped skin on our wiki. We also have acquired wesay.org so update your bookmarks.

I have been working on two areas of WeSay. The first is our data access layer. Db4o provides a read only IList when queried. In the prototype, I had wrapped that result and provided our own read-write IList that automatically kept the database up to date. With John’s databinding work, we decided to provide a IBindingList interface over db4o. I spent quite a bit of work creating tests for the various interfaces: IBindingList tests, IList tests, ICollection tests, IEnumerable tests. I had an implementation working with tests when we hit performance issues with filters and John found Marek Istvanek’s work on providing a binding list over db4o. I chose to only use his db4oList class and implemented my own Db4oBindingList since we won’t be needing the paging and didn’t want to take on the associated risk. I had to modify the Db4oList class so that it would pass my previous tests.

Another big change to the Db4oList class had to do with unregistering the PropertyChanged event on classes which implement INotifyPropertyChanged. A number of people have blogged about the “lapsed listener” problem which causes objects to remain in memory due to the event source retaining a reference to the listener after the listeners go out of scope.

The solution to this tricky issue is to either use weak delegates or require a call to dispose before the listener goes out of scope. Wesner Moise claims that implementing weak delegates is a difficult proposition with a number of casualties (Joe Duffy and Ian Griffiths) to date. I found three implementations that still purport to be correct: Greg Schechter (he also provides the best overview of the problem space), Xavier Musy, and John Stewien. We finally decided the best way to handle this was to remove the listener from the event source when dispose is called.

The other area is in moving our proof of concept lazy GTK nodestore to production standards. In the process I came across this blog entitled DataBinding an IList as DataSource for the Gtk.TreeView. This obviously peeked my interest. At first, I adapted his code to use an IList but when I tried to load the assembly, I discovered that templated classes cannot contain references to external methods, which makes sense so I’m back to using an IList. This is still a work in progress for me too, but you can check out what I’ve done in our subversion repository.

This past week, Eric and I have been designing and starting to implement the code framework for WeSay. I have rarely had a chance to do this kind of “green fields” architecture before, but I have done it enough to recognize some of the dangers, such as those described by Brook’s “second system effect”:

An architect’s first work is apt to be spare and clean. He knows he doesn’t know what he’s doing, so he does it carefully and with great restraint.

As he designs the first work, frill after frill and embellishment after embellishment occur to him. These get stored away to be used “next time.” Sooner or later the first system is finished, and the architect, with firm confidence and a demonstrated mastery of that class of systems, is ready to build a second system.

This second is the most dangerous system a man ever designs. When he does his third and later ones, his prior experiences will confirm each other as to the general characteristics of such systems, and their differences will identify those parts of his experience that are particular and not generalizable.

The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one. The result, as Ovid says, is a “big pile.”

— Frederick P. Brooks, Jr.
The Mythical Man-Month

Personas

As part of an effort to avoid this affect, one simple thing we have started doing is to use the UI notion of persona and apply it to the developers that might be helping us build WeSay, maintaining it someday, or writing pieces to plug into it. Some folks at Microsoft have blogged about this sort of thing. For example, Eric and I went through an exercise of thinking about the people we know who would be keen to write extensions for WeSay. We boiled down their essential common characteristics:

• Primary motivator is helping individuals they know through a technical related problem.
• Primary job is some kind of computer support of people doing language development. Enjoys programming occasionally for this job.
• Normally does “one-off” projects that help a single person/project.
• Has a background of working in languages that give you a big bang for your buck: VB, Perl, CC.
• Has a long history of directly manipulating text files.
• Has (possibly strong) opinions about file formats.
• Willing to try new things, but is used to being able to purchase a book about the topic.

We are calling him Sam, after the helper-hero in the Lord of the Rings.

Why are we interested in Sam? He represents a huge pool of talent, often untapped, and he will in many cases be the interface to the language development workers who would deploy WeSay. We want him to be able to say to a language-development worker “This thing called WeSay might really help you achieve your goals… I see you have this special need, but I could program up a little extension to solve that.”

We don’t expect Sam to be responsible for maintaining the WeSay code base, so it doesn’t affect the decisions we make there. What we would like him to be programming is extensions to WeSay that make it useful in some particular circumstance. Especially as we bring in paradigm changing “best practices” into our architecture, such as dependency injection and design patterns in general, we are trying to keep a close eye on Sam. Are we forcing him to understand these concepts? How big of a barrier will that be?

We haven’t worked out other programmer personas yet in this kind of detail. It would be nice to have one, for example, for a developer who is a full-time programmer and who could take over maintenance of WeSay from us. And perhaps another one for an open-source volunteer who would add new abilities to WeSay in their spare time. We’ll see how it goes with Sam.

Today we broke ground on “the real thing”. All of the prototype code has been put away (still in the code repository, of course) and we are starting from scratch. The prototype has served us well, helping us to answer many questions.

As a last hurrah for the app, Andy Palmowski over in Calgary reports that he has managed to get it running in a simulated OLPC. Andy found that the prototype plus mono accounted for a mere 16 megs of RAM.

After a few days of preliminary architecture design, Eric and I are coding the new framework. We might not have much to say now for a couple weeks, when we hope to reemerge with another application.