WeSay Development Progress

I got some more great questions this morning:

“Couldn’t we just put a WeSay front-end onto FLEx (FieldWorks Language Explorer)? It uses the same underlying stuff, doesn’t it?”

Nothing is currently shared. WeSay is designed for really cheap, tough, low-wattage computers.

“Okay, it’s set up for one person to type into, but what if we want 10 people all typing into the same database–would it work for that?”

Ok, let’s back up. FLEx does allow you to very cleanly keep one database and share it over a LAN. However, while it does support export and import, no attempt is made at automatic merging or to guarantee round-trip-ability. So what do I do if we’re NOT all on a local network? FLEx will eventually support the (far more common) disconnected scenario (I will probably write the merge code needed for the basics).

WeSay has the reverse priority. We claim that if you can work disconnected, then you can always merge. And since these are both conceptually-modeled systems (not just ones that guess at backslash codes), merging isn’t hard. Our internal database system (db4o) actually does allow multi-user, networking access, but we think we should get the more flexible system (disconnected) going first.

So, for example, if FLEx were part of the project, then you’d merge the words collected with WeSay into the master FLEx db, using LIFT interchange files. I did a proof-of-concept with that earlier; it will need more work. From there, you could save the merged lexicon as LIFT or Standard Format, if you wanted to.

Not using FLEx? Someone is also going to write LIFT merger, and of course LIFT-to-Toolbox conversion should become commonplace. So if you wanted to stay in Toolbox land, you’d do this: merge the LIFT files from each WeSay user, then use a tool to convert that to Standard Format.

To summarize: our near term goal is to use LIFT interchange files to go to/from FLEx, and, through a converter, to/from Toolbox. Sound wrong-headed? Leave a comment and tell us so.

Technorati Tags: flex, lift, Wedding Party Favor, sexy lingerie, edox watches, gambling online, herbal health supplements

We’ve received the second request for a mac version:

How hard would it be to compile on the Mac? Seems like it couldn’t be that hard, could it, since your aim is cross-platform? At the worst, it could run in X Windows, where GTK+ supposedly works. GTK+ is not native on the Mac yet, but there are folks working on it.

WeSay has layers, roughly: UI, Model, and Persistence (database). All layers but the UI one will run on Mac, since it uses Mono. Our current UI layer uses Windows.Forms (not GTK), which runs on Linux but I don’t think on mac.  Cocoa# is a native MacOSX toolkit that is part of Mono.

It won’t be a big deal for people to make alternative UIs, whether to go to a different platform or to serve a very different persona. This is real Open Source; if the mac community wants it, they’ll find a programmer we can work with. In the meantime, mac users can run Linux on a virtual machine; remember WeSay is designed to run on REALLY slow machines, so it’s plenty fast in a VM.

WeSay has never claimed (or intended) to do “Extreme Programming“. While we are into the goals of Agile processes, we know that one size doesn’t fit all. For example, we are doing a fair bit of Test-Driven development, but we rarely pair and unfortunately don’t have an on-site customer. We often design with CRC Cards, but we value high-level documentation to help developers understand the system.

I’ve started reading XP Refactored: The case against XP and though there isn’t much new in there, it has inspired me to get some diagrams of our design “out there”.

Alas, I haven’t been able to find any free UML tools that I’m remotely happy with. I tried the free “community editions” from MagicDraw and Visual Paradigm, but these are so limited even a UML beginner like me can’t get far. I think I could live without the automatic “reverse engineering” of the free/cheap versions, though that’d be nice to have, if they had such basic things as XMI import/export.

Surprisingly, Visio 2007 beta 2 does a scandalous job of handling c#’s properties. It puts them in the operations section of the class diagram, and displays them as methods, complete with parentheses! Worse, it does not appear to have an XMI export option, so it feels like I’m being locked in to a non-free, proprietary format.

I tried using the build-in diagram feature in Visual Studio 2005, but it is tied to the actual code. But I want diagrams which convey what someone needs to know; if they want the actual facts and details, I expect them to read the code. For example, if I have a Lexicon which has a collection of, say, LexEntries, I want the diagram to show a composition line from Lexicon to LexEntry. I don’t want one from Lexicon to the actual collection class, such as List<LexEntry>.

Ah well, enough whining. For now, here’s the result of my playing around with Visual Paradigm. I’ve trimmed down the diagram to what I think someone wondering what we’re doing would want to know.

Here’s the Lexical Model (click to get it full size):

And here’s the view from the project:

Some major pieces that I haven’t diagrammed are our data and UI layers. Does seeing these help anyone following this project? Please write and help us learn how much documentation is enough.