Using an automatically installed virtual machine for development is a wonderful way to work, as it’s quick to set up and closely matches your production environment.

But there’s one slight problem: What URL do you type into the web browser to see your application? The popular Vagrant solves this by forwarding a port on your host OS to the virtual machine, so you can just type in http://localhost:8080 and log into your app.

I’m a firm believer that the best conferences introduce new ideas by being for people who do a particular thing, not by being about that particular thing.

Ruby Manor was one of those best conferences. Rather than talking about the Ruby language, Rails, or the latest gems, the presentations were about ideas from outside Ruby, with suggestions on how they might be applicable to Ruby developers.

In fact, there was so little about Ruby itself that the running joke was “this is a wonderful functional programming conference!”

My company’s product, ONEIS, is a complex and sophisticated information management platform. It has metadata handling which far exceeds that of other products, and combines a graph database with easy free text searching.

Yet our “training course”, which enables a user to get the most out of it, is just this:

When you want to find something, click Search and type in what you want.

When you want to add something, click Add, click what kind of thing it is, then fill in the form to describe it.

That’s it. If someone follows those instructions, they will be managing their information well, and they will find what they need when they need it. And, perhaps more importantly, their colleagues will find what they need too.

The key to delivering sophisticated systems which are easy to use is to take a radical approach to simplicity. Assuming that you’re a developer, unfortunately this means you’re going to have to work harder.

Nashorn is the fancy new JVM JavaScript interpreter under development by Oracle. Its aim is to replace the ageing Rhino interpreter, using modern JVM techniques available in the forthcoming Java 8 for much improved performance.

The London Java Community is running a hack day on March 24 to try it out, find any problems, and write up some notes to help others experiment. One of the Nashorn development team, Attila Szegedi, will be there on the day to talk about it and help with questions.

I’m helping organise the day, and preparing all the suggested tasks and instructions for getting going. Even though it’s a work in progress and you have to build it yourself, it’s surprisingly easy and everything works well.

I’ve been running a ployglot app in production for about three years, written in a combination of Ruby, Java and server-side JavaScript, all running in the same JVM.

First thing on the second day of Devoxx, I’ll be explaining why this is a good idea, and share the highs and lows of writing a complex app in several different languages.

Using some carefully crafted flattery, the organisers of Devoxx have persuaded me to tell you all that you can register here, and using the code SPUK13, get 10% off the very reasonable price of £350 for two days of entertainment on March 26 and 27th.

Let’s say you have a web application which deals with “content”, so works much like a web site: one-page per item, and when you click a link, just load the next page. It’s very old fashioned, but it works the way the web works, and works well. Users are encouraged to have more than one page open at a time, and this works well, as it does for web sites.

Just like any other web application, you have some state on the server which is reflected on those pages, for example, which user is logged in, how many tasks they have to complete, how many items in their basket, and so on.

When you have multiple pages open, you can do something which changes that state, but it’s only reflected in the page which is returned in response. All the other windows show the old state. Wouldn’t it be nice to have a lightweight way of broadcasting state changes between the pages so they could update their state too?

Sometimes you throw an idea into the world, and it takes on a life of its own.

BenConf took me by surprise. I made a silly joke by pretending to announce a technical conference for people called Ben. But I also said that I’d make it happen if 12 people wanted to come. One hour later, I had a dozen Bens on my list. So, I booked a pub and set up an Eventbrite page to sell tickets.

Then it went viral. I had tens of thousands of hits on the blog page. My jokes were retweeted all over the place (some were even funny). I’m pretty sure that every Ben on Twitter had been told about BenConf by at least one of their friends.

We already know who would be silly enough to start a conference for technical people called Ben. We’re also compiling a list of those silly enough to attend this conference. But who would be silly enough to sponsor BenConf?

I’ve found that good quality code can only be written by thinking very carefully before you start writing it. I’ve also found that thinking about it afterwards is just as important.

Before typing fossil commit, I make a point of thinking carefully about the code I’ve just written, roughly like a mini code review. It’s a very useful habit to pause for 10 minutes or so, and in doing so, I often correct small issues, reduce the size and complexity of code, and make it easier to read.