The Web Client Platform

With Firefox (and presumably others) getting fancy scene graphs with video on all three platforms out today (in beta form), and with JavaScript JIT support coming in the near future to multiple browsers, where does that leave client-side Java?

If someone makes serious (and open source) dev tools for JavaScript, I'd probably move on. JS has flaws, but so does Java.

There are nicer languages out there than either one, but I always feel drawn back to the main language for the platform. But that's also part of why I'd rather see good JS tools than use GWT. I just haven't seen them yet. Still, JS is the metal in browsers.

I'd also be curious to see a server-side JS framework get traction. Hasn't happened yet despite many attempts. Nothing is yet (and perhaps never will be) "the metal" on the server.

JBullet in jME Physics

Just noticed today that JBullet support is in svn for jME (jMonkeyEngine) Physics. I tried out the ragdoll demo, and it seems like things aren't quite ready yet. But still cool to see the development.

Anonymous Classroom Feedback

I was just imagining today the idea of people in the classroom, with notebook computers or cell phones or whatnot, being able to raise red flags anonymously when they aren't following. The number of red flags from different students could control a general classroom "temperature" visible on your own projected screen.

If the temperature gets too high, it's time to slow down. Also could allow full anonymous questions to be sent up.

The goal here being to let people give anonymous feedback if they are afraid of looking like dummies in front of the crowd.

Could be cool, or maybe old-fashioned watching faces and asking for questions is better.

Other Apps as Automated Tests

I remember hearing about how Microsoft has rooms full of automated tests of running other people's programs on Windows. I've also heard about browsers using web sites as tests. I guess beta testing in general is about this kind of thing, just involving people in the loop.

Seems like to test your own library, if licensing allows it, you could actually include 3rd-party applications using the library as part of your own automated test suite, including their own unit tests. Might not be so bad in some cases.

Mixins and Spreadsheets

It just occurred to me that mixins (such as seen in Scala, Fan, Ruby, or many other languages) and everyday spreadsheets have a lot in common. I tend to prefer C#-style static extension methods. Keeps things cleaner and leaner in my opinion, but it doesn't give you the chance to have tons of default-implemented-yet-still-customizable behavior.

Mixins do provide that. And it occurred to me that's a lot like spreadsheets. You can have a lot of cells that "inherit" functionality via the drag operation, but you can customize individual cells on the fly. Not each one has to be just like the other.

Not a perfect analogy, but I think there's some value in considering the relationship.

Random Testing

So, I had a need the other day to test various permutations of some numbers (and ignoring what this is or why for the moment). Being too lazy to think about coding the permutations, I just used Collections#shuffle(List<?>). In my case, it got the job done:

import static java.lang.Math.*;
import static org.junit.Assert.*;

import java.util.*;

import org.junit.*;

public class Whatever {

    private int secondGreatest(int a, int b, int c, int d) {
        return min(max(a, b), max(c, d));
    }

    @Test
    public void testSecondGreatest() {
        List numbers = Arrays.asList(1, 2, 3, 4);
        for (int i = 0; i < 20; i++) {
            Collections.shuffle(numbers);
            assertEquals(
                "for list " + numbers,
                3,
                secondGreatest(
                    numbers.get(0),
                    numbers.get(1),
                    numbers.get(2),
                    numbers.get(3)
                )
            );
        }
    }

}

It fails, for instance, with text like "java.lang.AssertionError: for list [4, 3, 2, 1] expected:<3> but was:<2>", but it's the not the same failure every time, and there's a probability (which I haven't calculated) that it might pass even though it shouldn't.

So, what's the big picture question? Lots of test data might be a bother to produce in advance or even impossible if the domain is huge. Even an algorithm to test every possibility might take too long. Or I might just be lazy like in this case. Or, in messier contexts, it might be impossible to guarantee the results perfectly, so the results themselves (not just the test cases) might be random. So you have to deal with that in some fashion.

Summary, seems like random (or "stochastic" if I want to sound academic?) testing can be either convenient or necessary in some circumstances, but it doesn't necessarily prove that the program works as expected. Might beat no testing in many cases.

Unit Testing and Automatic Grading of Programming Assignments

I've found before and still that one of my least favorite things as a teaching assistant is grading. It takes time to do well, and it's hard to be consistent.

I remember once as an undergrad that I had a class with automatic grading. It ran the input and output automatically and popped out a grade.

There are pros and cons to automated grading, but I've thought of a way to make it also useful for teaching other good principles. Basically, teach unit testing by providing unit tests that their program has to pass. And use that as a way to do part of the grading automatically. There still ought to be a human involved if possible for part of assessment, but I think that giving out unit tests in advance might not be too bad of an idea in some cases.

Using Opera on Linux

The latest Firefox requires newer GTK than what I've got on the computers I have access to these days. And the latest Opera is ahead of old Firefox, for sure. So I'm experimenting with Opera these days.

Quick review: I want incremental search. Putting downloads ("transfers" in Opera) in a tab out of the way rather than an annoying downloads window is great. I've used Download Statusbar on Firefox, and that works too, but it's nice to have a non-annoying way built in.

And an update to my original post: Just be careful about random incompatibilities. Some sites I need (or want) to use Opera, others old Firefox. Sort of annoying.

jMonkeyEngine 2 and jME Physics 2

Turns out that jME 2 is under active development. Just no releases planned at the moment, so I pulled from svn (though I wouldn't do that with Spring for a production system). And I also pulled jME Physics 2 from svn (though it seems less active).

I had to toy around with things for a while, but I got it all happy in Eclipse and building jars with Ant (some hints, though I didn't follow instructions exactly). I also got the rag doll demo running in a separate project referencing the built jars (and native libs). Just 2 relatively readable files. Much simpler than the JBullet rag doll demo and number of classes I had to copy over there.

So, I think jME looks like a nice way to go, if I continue working on a simulated world environment. (And yes, I know about Player and Gazebo. I'll probably end up using that some, too, though perhaps for different purposes such as simulating more common robot systems.)

Some effort has gone in to supporting JBullet under jME Physics, but it's definitely not under active, public development. I haven't even looked to see if the project is from the same person as in the forum. Still, it could be a start if I care enough. The ODE wrapper seems to work for now, and LWJGL is native anyway.

OSGi for Robot Middleware

Seems like "middleware" is the term in robotics for the platform that lets the different components (usually system processes) communicate with each other. I'd previously thought about whether OSGi might be a good fit for that.

I searched a bit and found a Tobias Wegner that seems to be doing something like that, but I haven't found any papers from him at Google Scholar. Maybe I should try contacting him sometime to see about the status of his thesis.