So, I promised some updates on BlueJ development plans. Let’s see whether I can keep my good intentions at least for a day, and tell you something about what’s going on.
The most interesting new bit of functionality that we are working on for BlueJ is team work support. When this is done, student teams should be able to cooperate easily by using BlueJ.
The support for team work is the only large bit of functionality that is currently planned for release in the near future.
The team work support is based on CVS (with subversion support planned for some time in the future). BlueJ will integrate a simplified interface to CVS, so that some of CVS’s nastier sides are hidden.
The BlueJ team functionality will concentrate on the file sharing aspect of CVS, and ignore other functionality (such as version rollback). As with other BlueJ tools, the aim is to have an interface that is easy to understand, and gives you the 90% most used functionality.
BlueJ will support setting up projects as “shared projects” (by creating a repository on a CVS server) and the usual commit/update functions. Files that are added or deleted will be automatically included in the commit/update, and the BlueJ diagram layout can optionally be included as well.
The team work support was first investigated by Kasper Fisker as part of his Masters degree, and the implementation is now being finished by Bruce and Davin, our Australian branch of the BlueJ team. So expect the CVS commands to come across with an Australian accent.
We are planning to release a beta version of the teamwork support first (in a couple of weeks) and then have a full version available some time later.
When I first saw this posting I was really excited, hoping that this would be a much hoped for synchronous pairs programming extension. Alas! It is not. Although this is a worthy extension, I’d really like to see something that permitted geographically separated students to do pairs programming. I’d asked Ian U. about this at SIGCSE 2005, but he indicated that it wasn’t really possible. However, there is a Java version of the VNC client. If BlueJ could implement the VNC server protocol, I don’t see why this wouldn’t be possible. Thoughts?
As an update to my previous comment, it appears that there is a SourceForge project called LGPL VNCj that implements the VNC server protocol in Java. Any Swing-based application can be wrapped in it to make it remotable. With the VNC client in Java freely available, it seems like this would be reasonably doable. VNCj is at http://sourceforge.net/projects/vncjlgpl and a JavaWorld article on it is available at http://www.javaworld.com/javaworld/jw-07-2002/jw-0712-remote.html
Todd,
While this is an interesting sounding idea, I’m not convinced that the potential user group for such a feature is large enough to warrant the effort to add this feature. It seems to me that most pair programming by far is done in the traditional way – in front of the same screen – and that your case is an unusual one.
In that case, I’d rather suggest falling back to standard solutions (such as full screen VNC systems) rather than adapting separate applications.
Including third party libraries always carries a high workload in maintainance over a long time, and we don’t have a large amount of capacity to spare…
Michael
The beauty of BlueJ is its educational simplicity and robustness for first time users. Adding spatial pair programming is neither simple nor robust (fire walls, tunnelling ssh key generation etc, vnc setup) or a natural way of teaching pair programming.
If you want to spatially pair program, just use vnc and then view BlueJ running on one machine, why complicate things any more or suck new programmers into the trap that the tool does it ALL for me?
Regarding CVS, EXCELLENT news! Although a little concerned about implementation details… is it going to use pserver, ext (via ssh?) or local, will it work on all platforms? Please keep it simple!