Writing a small Beatrix application of my own. Just a small demo, but should help others see how things work. It also helps me see how things work, and how to improve my documentation. Some errors are just silly. Some require a bit more detective work, and that shouldn't be necessary for this kind of application. It means there are some gaps in my documentation. So all in all a good exercise.
Spent some time filling in the gaps in the Beatrix documentation, which appear to be large. The information is all there, but sometimes you need to be a bit of a detective to piece it all together. CryoBob suggested a kind of Q&A table, mapping "What do you want to do?" to "How to do it". That's a good idea and can act as a good reference. What you want to do (in human terms) doesn't always map to single class or interface. It's usually split up over several. So having a handy reference is a very good idea.
Among other things, yesterday I spoke to Jim, our CTO, about a very small class he has in mind to help make legacy systems available as Jtrix services. It's quite simple and very elegant. It involves setting a few fields in one class which then gives you a warrant for someone to access the service. The class then starts an HTTP server listening for a service bind request. This will come when you give the warrant to someone and they use it in a netlet. At this point your legacy application can talk to the netlet. Very simple. Requires a little bit of work, but should open up Jtrix even more.
More javadoc, which really is not fantastically exciting, but it does mean there's going to be a lot fewer people scratching their heads over our storage system thinking "Eh? That's dumb". Andy really does have a fetish for inner classes. Which are all very good in their place, but it can get silly at times. I cannot see the point of most inner interfaces. I pine for the simple things in life. I remember BBC Basic. Now *that* was a programming language...
Phew, long day continuing Javadoc, and tidying up some interfaces. At least I think it's tidying up... we'll see what happens when real programmers get to them. This is for Storix, our distributed transactional file system. Actually, it's probably a good thing for several people to run over the code. It provides a sanity check.
Spoke to CyroBob at the end of the day regarding Beatrix and his understanding of it. Looks like there are lots of gaps in my documentation. Not all that surprising since that's the least roadtested.
Spent the morning making a few corrections to How to write netlets after CryoBob went through it on Friday. It was good to see that his comments were thoughtful and well-directed, as that means he has a good understanding of the issues. Or at least as far as the document allows.
Today he's looking at Beatrix, our application framework. Some comments have already come my way, and it's certainly more complicated. Mind you, it allows you to do much more. We'll see.
Will spend the rest of today making sure our javadoc compiles without problems. A painful, but I think helpful, business.
Observed that experienced people try fiddle around with things to learn them better. CryoBob did this: "I tried to change X just to see what happened, and it broke. And I figured I think I know why...".
Site experienced a small surge after posting a "developers wanted" ad on sourceforge, for our redundant file system, Storix. Meanwhile still looking to fill our full time Java job here in the London office.
Trundling on with documenting the latest changes to the Beatrix framework, which makes it easy to write large-scale services. This is more important now because we have a design for our redundant storage system, Storix, which will be built in this framework, and developers will need decent documentation.
Also on the agenda is continuing the design of the One Node Wonder (is there a better name?). This is a simplified version of the Jtrix node, optimised for a one-user PC rather than a server cluster. Current problems include how to represent resources (disk, sockets, etc) which appear in multiple locations (i.e. multiple PCs).
Much fun today as the Jtrix FAQ on JGuru spawns a minor argument. My apparently simple answer to "How does Jtrix differ from Jini" raised some shortcomings of Jini to which one reader took deep exception. Four of us sat round trying to understand the reader's objections until we realised that perhaps he had the wrong end of the stick. Anyway, posted a polite point-by-point rebuttal which will hopefully make him happy. I'd actually like him to mail back and say "Oh I get it", but more likely is that he'll stop, or come back with more objections. Well, we'll see.
Our recruitment drive continues, and the best avenue, as always, seems to be word of mouth. I've always thought the most interesting part of working in this industry (or any other) is the people.
Our Jtrix forum on the JGuru site spawned an interesting question: How will Jtrix gain mindshare? We're hoping for grassroots take-up which will be slower but more cost effective (we're not a large corporation) and more solid. The open source nature of our work is intended to build trust among developers.
One thing I didn't mention in my reply there was that we could spend time building a really pretty Jtrix app to attract attention, but this would take away from our core activities (producing dull-but-useful things like storage systems and bugfixing the main platform) and may not end up attracting the right people. It's a difficult call. I guess this one will run and run.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!
