arstechnica.com/tech-policy/2012/05/dvds-and-blu-rays-will-now-carry-two-unskippable-government-warnings/

A quick google suggests that it should be possible. For example, Pete’s comment here suggests that pressing shift should work.

What version of Ubuntu are you running as a guest. For early versions, you press Escape, not Shift.

I can’t seem to get the Left Shift to trigger the recovery menu (my Host OS is Mac OS X 10.7.3), does anyone know what key will send the equivalent key stroke?

• Everyone thinks that they are one.
• People tend to concentrate on comparing one driver to another, without considering how a driver’s ability varies over time.

Yes, on a good day, I think I’m a good driver. But if I’m tired, or angry, or distracted, or… then I can be just as poor a driver as the next guy (if not worse).

Code metrics aren’t there for the bad programmers, to be thrown away once everyone on the team is awesome – they’re there for the bad days, when you’ve got a stinking cold, or your daughter woke you up at 4am and refused to go back to sleep. Those are the days when you want your automated tests and metrics to say “whoa, no unit tests?” or “hang on, what about all these checkstyle errors?”.

Yes, there’s a balance; teams should aim for a simple, automated set of metrics that are both easy to apply and easy to understand. If (collectively) you don’t think that its appropriate to mandate a certain level of code coverage then fine, don’t use emma (or rather, don’t let emma fail your build).

It’s wrong to approach this from the angle of “code analysis tools are cool, let’s grab as many as possible and apply them to our build”. The drive needs to come from a code-quality perspective first – What problems are we having (with maintenance, deployment, testing, security etc)? What coding mistakes are causing these problems? Can we detect these errors and highlight them, whilst keeping false-positives low?

It’s likely that as part of such a code quality improvement drive, you’ll try out some tools and see what they find – espeically if your concerns are security-related. But you should always try to distill it back to the simpliest set of tools possible, which give you the quick feedback you need to keep you code on-track.

Programming is hard. To write something that’s extensible and maintainable, that fulfils the customers requirements (which almost certainly won’t be what they asked for) whilst being readable and intuitive is no easy task. Tools can’t tell you if you’re doing to right thing, any more than the compiler can – they can only tell you if you’re wrong, or doing something that is likely to fail. But I’d still rather have them as part of my process.

It started off encouraging people to check their code before committing it (so they gained points rather than losing them when the build broke). Some people who did the bigger, chunkier refactoring of the builds lost points. People then realised if they did things like “fixing” stuff like Checkstyle errors (by “fixing” in quotes I mean not necessarily doing a proper job) they could get loads of points and it all started to get a bit silly.

If people can use the game as a bit of a fun way to focus them on producing stable, tested code before they check in then it can work well.

Basically:

double lon = -2.595;
double lat = 51.450;
int zoom = 16;

LonLat lonLat = new LonLat(lon, lat);
lonLat.transform(“EPSG:4326″, “EPSG:900913″);
mapWidget.getMap().setCenter(lonLat, zoom);

That URL is just GWT running in “hosted mode” (which I think is also referred to as “dev mode”). Basically, that’s me testing it; once you deploy the webapp, that disappears.