Armswiper.co.uk

I’ve noticed recently a worrying problem.

Manufacturers have started to get better with their technology, and have started producing cars which do automatic braking.

If you can’t understand me, imagine this. You’re driving your car on a motorway, and are following the car in front. The car in front suddenly pulls an emergency stop. In this situation, a computer can react faster than you can, so an onboard computer applies the brake pedal quicker and stronger than you can, and so slows the car to an immediate stop. For a video showing this in action, check out this Gizmodo page

This technology is currently in development with some manufacturers, but Mercedes Benz have recently released the technology on the new S Class.

Now this sounds all fine and dandy, except something worries me. I’m worried that people will become to used to the technology – that they will rely on the computer to do their work for them, and not on their own senses and intuition. I’m worried people will get into the mentality of “Oh, it’s OK to drive really close to the car in front, the computer will take care of the braking”. I drive a lot everyday (it’s more than a 60 mile round trip to work and back), and I see people do the most stupid things (I’m not saying that I have never done anything stupid myself) just because they weren’t thinking. To relax the brain even more is just asking for trouble.

This worries me because driving is a very analogue, random process. There is no fixed solution for a situation, no simple rules to follow when something occurs. Computers follow rules, humans can deliberately break those rules because, through experience, they know better.

Take for example the new Mercedes S-Class. This takes the braking thing one step further, and can actually follow the car in front. This means it will brake when it needs to, and accelerate when it needs to, and always maintain a safe braking distance. Now this is fine for motorway travel, where you can just put the car in gear and cruise, but imagine what would happen if you came up to a roundabout. The car would follow the car in front, so approaching the roundabout, it would slow as the car in front approached the line. If the car then leaves the line quickly to fit into a space, your car would then follow, and potentially smash into the side of another car.

Not a good plan.

This page has some pretty useful animated pictures of various different types of engines working. It’s certainly helped me clear up a few questions over how precisely a Two-Stroke engine works!

I’ve had my first real experience with an AA man this morning (as in The Automobile Association, rather than Alcoholics Anonymous). It was actually a very pleasent experience. I’ve had to call the RAC out before to get my car towed home for 96 miles from Reading, but that was done by a local garage and a low-loader, rather than an RAC van themselves.

When I was a kid, I remember my Mum calling the AA, but I never really got to speak to the man as I was still sat in the car. This time, it was a little different, seeing as I am at work, and 23, not 10.

The guy came, asked me the problem, fixed my car within 5 minutes by replacing a broken hose, and we both had a little bit of a laugh. I asked him if I needed to fill out any paper work, which I didn’t, and everything was sorted. Cool!

I found a post on one of the MSDN blogs the other day about Hungarian Notation being adopted by some of the Microsoft Development teams, and how they should go about using it.

Where I work, we don’t use Hungarian Notation, and so far we have managed to cope without it. Having said that, the language that we use (Progress 4GL) is meant for database access, and therefore relatively few types actually exist, and more complex types are created by creating database tables. The most that we really stretch to is “vVarName” for a variable, “ipParamName”/”opParamName”/”iopParamName” for input/output/input-output parameters (respectively). Some people do go further and may use “c” for a string, but that is about it. We also call procedures or functions defined in include-files “i_ProcName” to make it easier to identify their location, and sometimes people may name variables inside of procedures located in include files so that they do not run into “Multiple Variable Declaration” problems.. So far, in the extensive project that I work on, it’s not been a problem.

They also link to a page which describes an internal Microsoft layout format for programs/source code. Again, we don’t have a strict set of rules for this. We have rough guide lines (like “Line up all the equal signs”) but quite often these are broken in order to actually improve readability.

What this actually means though, is that (by knowing each person’s individual style), it can be quite easy to pin-point who did a piece of work where it is not already obvious who had done the work.

I doubt that my Project Managers will ever feel the need to develop a more rigorous standard, or enforce rules about layout and style, and for the most part I don’t think that we will need to either.

We’ll just have to see what happens with time…..

Just before Christmas 2004 (the 23rd to be precise) I managed to pick up a nasty puncture on my way to work. Unfortunately I didn’t realise and limped my car home for 7 miles on an alloy rim…..

Anyway, I came across this blog post for somebody who seems to have had the same happen to them. I’m wondering now whether I didn’t have a blow out as well. There didn’t seem to be any kind of hole through the tread of the tyre, and the car was only about 10 weeks old….

Guess I’ll never know.