Command Facade pattern

Several weeks ago, Wolfgang asked after a rename command for Hecl. Pretty simple to do in terms of the Hashtable that maps strings to commands, so I added it. However, there was a problem: in order to save space, I’d been grouping commands together in one class, and dispatching on “argv[0]”. A nearly empty class in Java compiles to something like 500 bytes, so mapping one command to one class is not an acceptable practice when you are working, in some cases, with an upper limit of 64K. Dispatching on argv[0] meant treating it as a string, and doing a compare against the command name, which meant hard coding the command names into the classes implementing commands. Try renaming one of those commands and…oops!

I struggled for a bit trying to find an answer I was happy with, and after talking it over on the mailing list, arrived at doing things like this:

A big class that implements a number of commands, with a dispatch method:

static void dispatch(int cmd, Interp interp, Thing[] argv) throws HeclException {

That method then does a plain old ‘switch’ on the cmd int to go to the correct block of code. The code that calls this is simple, and it has to be, because one gets instantiated for every command, and so it’s imperitive that it doesn’t take up much memory:

class MathCmdFacade implements Command {
    private int cmdtype;

    public MathCmdFacade(int cmd) {
        cmdtype = cmd;
    }

    public void cmdCode(Interp interp, Thing[] argv) throws HeclException {
        MathCmds.dispatch(cmdtype, interp, argv);
    }
}

So far, I’m pretty happy with the results. By making the ‘facade’ (I’m not sure it’s really the facade pattern, but… oh well, the name works for me) small, I don’t waste memory. Plopping all the code in the switch statements is probably loathsome to purists, but it makes the code smaller, something that’s never far from mind when working on Hecl. Things are also a bit faster, because we don’t do the string comparisons to dispatch commands either. All things considered, the code isn’t illegible by any means, either. Furthermore, because the new ‘facade’ commands still just implement the regular old Command interface, which means that Proc still works, and that you can still associate a class implementing Command with a string, so that it remains very easy to implement new Hecl commands in Java, and the interface hasn’t changed.

Faster, smaller, backwards compatible, and ‘rename’ works too… life is good!

Projects vs Business, “Agile Development”

Projects vs Business

I read something via reddit recently that hit a nerve:

In this article: Meeting the founders of reddit

he says that: “Reddit, like many other initiatives is more a “project” than a “company/business”

Like everyone, I get inspired by Paul Graham’s writings, and like the idea of making money doing something cool, but my brain seems to be much better at generating ideas for fun projects/cool hacks, as opposed to businesses. I wonder if it’s possible or worth it to make that change. Sometimes trying to “be what you aren’t” is unpleasant and unsuccessful. On the other hand, perhaps it’s more of an acquired skill that doesn’t really conflict with the ‘hacker’ mentality…

Agile methods for introducing Agile Development?

Something else I found on reddit:

An Agile Approach to a Legacy System (pdf)

seems interesting because it deals with crappy, real world code, rather than some ideal workplace that exists only in fantasyland. I wish that they’d explained a bit more, at the technical level, of how they managed to integrate their new system with the old one, as that is often a difficult task when the code always has to be up and running, and the old system is in production.

I have a Big Ball of Mud to deal with myself, and a development process that is not agile, nor much of anything else really. It’s the kind of situation that is only going to change ‘in small iterations’, rather than trying (and quite possibly failing) to impose a new way of doing things in one fell swoop. So perhaps what I need is an agile methodology for introduction agile development in small iterations?

Hecl, Oregon, OFBiz

Hecl

I released a new snapshot of Hecl this evening, with a few minor fixes. I’m pleased that the project has picked up a regular contributor, Wolfgang Kechel, who seems to be doing some interesting things with it. He’s a bright guy, and it’s good to have feedback and someone to talk things over with. I have been sidetracked with Ruby on Rails (more on that in the future) lately, so I haven’t dedicated as much time to Hecl as I would have liked to.

Oregon

I found this brochure about open source in Oregon. It’s “marketing materials” kind of stuff, but still… I’m proud to see all the interest in open source in my home state. Almost makes me want to go back, but then I talked with my parents on the phone, who told me about the 24 days of rain in a row, which brought me back to my senses.

OFBiz

I had been investigating OFBiz as something to use in the company where I’m working, but apparently that’s not going to happen for now, which is a pity, because it’s well done software, and more importantly, has attracted a bright, diverse group of people to work on it. Indeed, I liked it so much that I’m helping out (I hope!) by acting as a “mentor” for the project as it goes through the process known as incubation at the Apache Software Foundation, which means that it hasn’t officially been accepted as part of the ASF, but has the potential to do so if we get all the i’s dotted and t’s crossed. It’s been an interesting experience, as it’s about as far away as you can get from my Tcl work at Apache!

Maximizers, Satisficers and Programming Languages

Whilst ambling around on the web after seeing a post on reddit.com that piqued my curiousity, I happened on some work discussing “maximizers and satisficers”, which, put crudely, says that there are two kinds of people. Those who, out of a group of options want the best one – maximizers – and those who just want something that will work – satisficers.

Anyone who has been around programming languages more than, say, a week, will instantly recognize the above theme in the endless discussions of “which programming language is best?”, or more generally, which “X” is best? I’d be willing to bet that programmers, and especially open source programmers, tend towards the ‘maximizers’ end of the spectrum – I don’t want just any old X, I want the best one, dammit! Sometimes, this can be a good thing, as it leads us to continuously seek to improve things we come into contact with, or try new approaches, it can also be detrimental if your goal is simply to accomplish some task, rather than spending too much time fretting about finding the perfect tools to accomplish the task with.

This also has ramifications for people designing or dealing with programming languages. One of the papers (the original?) on the subject (here), actually deals with the fact that maximizers, in their search for perfection tend to be less happy. Where satisficers are happy because they’ve got something that works, and they can go on to something else, maximizers have lots of room for “fear, uncertainty, and doubt” about their choices.

In some instances, actually reducing people’s choices makes them happier. Python’s “one good way to do it” makes everyone happy, because both maximizers and satisficers know that they’re doing things right, and don’t have room to worry. Another example that I know well from my involvement in the Tcl community is “object systems for Tcl”. For those who don’t know Tcl well, it’s an extremely flexible, extensible language, both in the language itself and in terms of its C API. So flexible, in fact, that you can write an OO system in Tcl itself, which has been done, or in C, which has also been done several times, leading to a proliferation of OO systems, and a never-ending stream of questions on the newsgroup about which is the best one? Perl’s “there’s more than one way to do it”, despite apparently providing and pushing choice, may actually work well because it encourages people to be satisficers and use whatever works. I’m sure everyone can think of examples where too much choice causes doubts and hesitation.

I think the lesson to be learned is that while it’s important to encourage experimentation in order to explore possible solutions to problems, at a certain point it makes sense to consolidate and provide one or two recommended ways of doing something. That’s not always possible (Linux distributions, for instance), and squashing competing ideas too early might cause friction with people generating innovation, so it can be difficult to accomplish, but I believe it’s an important social aspect of software creation to keep in mind.

Conditional Compilation in Java

We’ve hit something of a stumbling block with Hecl, and it’s proving tricky. Far from being “write once run anywhere”, Java has many versions, when you take into considerations the wide array of devices that run one of several configurations roughly lumped together as “J2ME”. My cell phone’s implementation doesn’t have floats, for instance. This necessitates that the J2ME and J2SE versions contain different code, but Java doesn’t make this easy, because there are no macros or other ways of conditionally compiling code.

The solution we’ve adapted so far is problematic because it’s not very fine grained: we have two separate directories, one for ‘core’ Hecl (sans floats) and another that contains the exact same classes, but with floating point. For instance:

BasicMathCmd.java – no floating point

BasicMathCmd.java – the floating point version.

As you can imagine, this means that code is replicated in two places, and each change has to be done twice, carefully, keeping track of the actual differences between the two files. This can only get worse as the code grows.

I’ve seen some hacky ways of doing macros and things like that, but they don’t look very satisfying. I’m too much of a Java novice to think of anything better than what we’ve got, though.

Update 2006-04-20: we chose to use Antenna

30th Anniversary of “An Open Letter To Hobbyists”

Bill Gates wrote his famous letter thirty years ago, tomorrow:

http://www.blinkenlights.com/classiccmp/gateswhine.html

In the meantime, people are still missappropriating software, the “hobbyists” have returned with a vengeance and have built software that rivals or bests Mr. Gates’, and the economics of the industry still aren’t entirely clear. What economist would have ever predicted the success of Open Source? They’re certainly fascinated by it now that it’s here.

Disaster strikes

Where I’m working, they wanted to try “netoffice”, a PHP collaboration/time tracking/productivity thing. I downloaded the “dwins” version of it, and ran the install script after reading the instructions. Being a bit late, I hit the return key one too many times, and noticed some funny error messages about problems deleting files in /dev. Oh shit…

Turns out the script has the following line:

rm -rf ${INSTALL_DIR}/*

Simply brilliant. Thanks a lot, guys… So at this point I’m sitting there with two shells opened via ssh, no /bin/, no /etc/ and nothing much in /dev. For reasons I won’t discuss here we don’t have backups – suffice it to say that it wasn’t my decision.

Not good. ssh didn’t work any more, either in or out, because it needs files in /etc/ and /dev, and so I couldn’t just copy new stuff in. Luckily, I had a fully stocked /usr/bin, and I did the first thing that came to my head: a small server in Tcl that copied its input into the specified file. Using that and netcat on the other side to send the files, I recreated enough of /bin to get MAKEDEV working in /dev. Phew… a little bit better, but /etc/ was still gone. I brought in a few more bits and pieces like /etc/passwd and /etc/group using my Tcl server, which was enough to get scp working from the machine. At that point, I brought in the rest of /etc. I was starting to think about going home when I ran the fateful script, so at this point it was pretty late, I was starving, so the rest will have to wait for tomorrow.

The biggest problem, I think, is how to restore the files in /etc at least to the pristine installed state required by the packages that own them? The other problem is that the password file uid’s are now out of sync with the file system, which is causing problems here and there. Unless I think of a brilliant way to fix those two issues, I’ll probably consider myself satisfied that I got things running to a point where I can get the important data off the system, set up some temporary services on other machines, and reinstall the whole thing.

This is all on Ubuntu systems, by the way.

Sourceforge and mailing lists

After my last post, exhorting people to use mailing lists for a variety of reason, including the ability to find the messages later via email, it’s frustrating that SourceForge’s mailing list archives are down:

Clicking on any of the messages in the archives

http://sourceforge.net/mailarchive/forum.php?forum_id=42757

gets you a result like this one:

http://sourceforge.net/forum/message.php?msg_id=14419574

Hrmph! I’m also frustrated by the broken CVS stats, that have been broken for more than a year. Just get them off the project pages already!

In any case, Hecl is picking up steam – it’s fun to have people to collaborate with.

Ilenia looking for work

If you’ll pardon the interruption from the topic of “computer stuff”, my wife Ilenia has started to look for work in biotech/related fields – she’s scheduled to finish her doctorate in about a year. Her CV is here:

http://www.dedasys.com/ilenia/

Please post to mailing lists

Unfortunately, this quick note will most likely not reach the people it needs to, but it needs to be said in any case:

When contacting myself or other people who produce free software, please use the mailing list for the project in question unless you have a really good reason to keep the conversation private.

The reasons:

  • Other people can benefit from, and contribute to the conversation. They might also be more interested than I am in the problem at hand, or at least want to hear about how it’s resolved.

  • It gets archived, and therefore people can find it via search engines in the future. This is critical when you want to be able to point people at archives that led to decisions that affect the project.

  • It creates more sense of ‘community’. Most successful open source projects are not the fruit of only one person’s labor. Perhaps they are initially, but at a certain point, everyone is better off if a community grows up around the project, and keeping conversations public helps that process along.

Please pass this along – hopefully people will start to get the idea.