NoMachine - The Coolest Thing Since VMware

I finally got around to giving NoMachine a go, and it works great! At the weekend I got around to getting the machine that I was planning on using with NoMachine (and eventually, Xrdp) up and running (I can't remember if I've had that machine sitting around for 1 year, or for 2). I can sit at work and (thanks to some ssh tunnelling) "forget" that the machine I'm actually using is back at the flat. It gives the same sense of "coolness" that VMware gives.

One of the things I've found really useful is session suspend - so that I could connect to the NoMachine server from inside the flat, then suspend the session, go to work and then resume the session, picking up right where I left off.

One thing to note, when using ssh to tunnel the ssh connection that NoMachine will be using (ie, ssh into machine A with a -Llocalport:B:remoteport, so that I can ssh into machine B via machine A) be sure to set "enable SSL encryption of all traffic", otherwise it will try to use ports that aren't being tunnelled and will fall over.

Another thing to note, the "new" machine is running Xubuntu, as it's not a particularly high spec machine (256Mb of RAM and Dual 600MHz P3s), so I use "dbus-launch --exit-with-session xfce4-session" as the custom command to run.

EntityManager Injecting Again

I better write this down, as I'll be needing it again when the app I'm writing gets deployed - from this page, the way to get the EntityManager injected again is to add the following

<context-param>
<param-name>com.sun.faces.injectionProvider</param-name>
<param-value>com.sun.faces.vendor.GlassFishInjectionProvider</param-value>
</context-param>

to the APP_SERVER_HOME/domains/domain1/config.default-web.xml (I put it down at the bottom, just before </webapp>)

Model Driven Development

IBM's System Journal is running an issue on Model Driven Development. There's something that bugs me a bit in the introduction -

Amazing feats can now be accomplished with sophisticated modeling tools. For example, the latest Dassault Aviation commercial jet, the Falcon 7X^®, was designed, simulated, and had its entire bill of materials generated by a CAD/CAM system. It was the first airplane ever designed that flew without any physical models ever being built and discarded. Millions of dollars and significant amounts of time were thus saved. In addition, the completeness of the model makes testing the comfort and safety characteristics of the airplane very simple and quick.

In light of this, the question should be why not model complex software applications

When will people realize that developing software isn't anything at all like building a jet, or a building or any other analogy often used when people are promoting their "improvements" to the software development process? If you must come up with a real world analogy for software development, one good analogy would, oddly enough, be model building.

That's what bugs me about this introduction to MDD - pretty much all software development is in essence the development of a model. So it's hard for me to see how you could make a model of a complex software application that isn't the application itself, unlike with jets and buildings, where the model is far removed from the final product. While MDD operates at fairly high level, from what I've seen of it, you'd be hard pressed to find a MDD tool that doesn't output some form of runnable code. This means you're not really building a model of your complex application separate from your complex application, you're building your complex application. Don't get me wrong - I think there's the potential to get a lot out of using MDD tools - what gets me is the inappropriate analogies to various forms of engineering.

Groovy

I had my first use of Groovy, the Java Scripting Language (no, not JavaScript :-) ). It's basically a version of the Java language that sucks less. It feels like a mixture of Java and Ruby.

The language itself is fine - they ripped the verbosity out of Java, and it can access Java libraries - which is both a benefit and a curse as while it offers access to a large library, a lot of the Java API (like the Java language) is a bit verbose at times. Still, groovy has some syntactic sugar that lets you avoid using the Java API at times (especially with JDBC stuff, which is why I was using Groovy today).

If you know Java and Ruby/Python, you'll be right at home with Groovy.