Software developers are not generally IO-bound. The speed at which I can type is not the bottleneck in terms of how fast I can produce software. I’m definitely CPU-bound. This means that there is little performance gain to be had from scaling out to 1 or more keyboards per developer. The pipe between my brain and the IDE is fairly idle a lot of the time, with occasional bursty traffic that still comes nowhere near 50% of the available bandwidth, even on a single half-duplex keyboard architecture.

As developers are generally CPU-bound, scalability can be achieved by moving to a multiprocessor configuration, with 2 developers sharing the same IO channel. The instruction pipeline optimization that can take place with a shared memory configuration can result in a better than linear performance increase.

I’ve worked on a few migration / rewrite /port projects in my time. They almost universally had no technical merit in and of themselves. From a developer’s perspective, a rewrite of an existing system basically means taking a stable, tuned application, freezing all new features, and writing it again in a language that’s newer, possibly more buggy, and probably less familiar to many of the team members, and delivering at best exactly the same features as the existing system, while taking several months to do it, with a risk of introducing new bugs along with it.

Migration projects are almost always done for political or cost reasons. Either the company has decided on a strategic plan to ‘go Java’ or ‘go .NET’, or (possibly less high profile, but potentially more significantly), is having a progressively harder time retaining developers with the skill set needed to support the existing system. Technology can also be made a scapegoat – so if a system is delivered that runs too slowly, or crashes a lot, the entire platform it happened to be developed with is proclaimed as ‘slow and unstable’, and the baby is thrown out with the bathwater.

Following a pub conversation with a colleague:

http://www.eecs.harvard.edu/~mdw/proj/seda/

http://foxtrot.sourceforge.net/

http://spin.sourceforge.net/

The Humble Dialog Box

Peelable UI’s

Looking for the price of an XBox on Amazon, I spent several futile minutes trying to find the ‘add to basket button’. In desperation I turned to the help page where I found this gem:

If you can’t see an “Add to Shopping Basket” button, it’s because the item isn’t available from Amazon.co.uk.

Okay. Right. Wonder what else they have listed that they don’t actually sell!! Why stop with XBoxes? Why not advertise trips to Mars, X-ray spectacles and rayguns?

Some very close friends of mine asked me to be the ‘official’ photographer at their wedding this weekend. I reluctantly agreed, against my better judgement, as they weren’t going to have a photographer otherwise. Having lived through the experience, and found surprisingly little useful advice on the internet prior to it, I thought I’d add my bit to the body of knowledge on the subject.

So, some things to remember when asked to photograph someone’s wedding:

• Unless you’re already a professional wedding photographer, don’t. Its an enormous responsibility. If a paid professional screws up a a crucial shot, some form of financial compensation can be negociated, and even if the wedding party end up hating them, they’re highly unlikely to meet them again. The same cannot be said of friends. So you’d better be very, very good friends with the bride and groom, and even if they forgive you for missing a vital shot, you’re still going to feel pretty bad about it.
• The better you know the couple, the higher the chances are that you are supposed to be in some of the photos. Better have a photographically inclined friend around who is not in the same groupings that you are.
• Use a good digital SLR, quality lenses and shoot raw. Unless you really are a professional wedding photographer, steer clear of film. You have to be able to rattle off shots like crazy, and check them in the field. You should expect to take between 200 and 500 shots.
• Have a manic eye for detail. Jackets, ties, buttonholes, pocket hankies, bride’s veil, people’s hair, backgrounds, head heights, positioning and spacing all need to be checked by you. Nobody else will notice at the time – its your responsibility to make sure everyone looks their best.
• You have to be able to impose your will on complete strangers. Get comfortable saying things like, ‘You, madam, in the hat! Is that your husband next to you? Could you at least pretend to like each other and stand a little closer together? Thank you so much,’ with sufficient charm to keep everyone smiling. This is surprisingly hard work – I was exhausted by the end of the day.
• Buy the most powerful flashgun you can find. Churches are usually lit by a combination of daylight, stained glass, tungsten and fluorescent lights, often all at the same time. Your flash needs to be powerful enough to fill a substantial space and overpower the other light sources to avoid colour casts.
• Photograph outdoors if possible. Avoid dodgy backgrounds like gravestones, and use fill flash.
• If photographing indoors use bounced flash whenever possible. Make sure you extend your flashgun’s reflector card if it has one, to form catchlights in people’s eyes. If the ceiling isn’t white or very close to it, use direct flash, and look for sources of daylight.
• Consider finding a high vantage point at the back (some churches have an organ loft or mezzanine) during the service and using a long lens with a wide aperture (f/2), beanbag or tripod and no flash to capture the exchange of vows. The couple will often turn around to be applauded after exchanging vows – be ready to capture this. Make sure you can get rapidly from your vantage point down to the couple if you need to capture the signing of the register, or anything at ground level during the service.
• Practice changing lenses – it should take you 5 seconds or less.
• Don’t use any equipment you’re unfamiliar with, or storage media you’ve never tested.
• Keep spares of everything in your pockets. Batteries for camera and flash, and several memory cards. Don’t keep your full cards/batteries in the same pocket as the used ones.
• Use a proper camera bag that opens up easily. It doesn’t have to be expensive, just easy to put stuff in and out of. Keep everything in the bag or on your person – you may need to grab it to get quickly to the next location.
• Use a zoom lens for the group photos. I took the majority of pics towards the 70 mm end of an 18-70 mm lens.
• Make everyone stand very close together – they need to be inside each other’s personal space to avoid ‘broken up’ looking groupings. People will not generally stand close enough to each other if left to their own devices. Make sure the bride and groom are dominant (in the middle, at the front generally works, with clear space between you and them), and get everyone else to turn towards them by 45 degrees or so. This lets you stand people closer together, and emphasises the wedding couple.
• Heads. Get the bride and groom to embrace and lean their heads towards each other, touching if they’re similar enough in height.
• Take several shots of each group – its very hard to get everyone looking their best at the same time, so you need to give the couple a selection to choose from.
• Crop in close. Sometimes the only difference between a ‘pro’ looking shot and a merely average one is the tightness of the framing.
• Did I mention not doing it?

Machine language is powerful. The programmer has absolute control over the machine. Anything that a computer is physically capable of doing, it can be made to do.

Machine language is not powerful. Even simple conceptual operations take many instructions to code. You’re forced to work in the machine’s terms and manually control all the devices, memory and cpu registers.

SQL is powerful. Its possible to write highly complex queries that tell the machine what information you want it to return to you without any knowledge of how it will go about finding it.

SQL is not powerful. It is not possible to tell the machine how do achieve something, only to ask it for information and hope it goes about the task in an effective way.

Java & .NET are powerful. The environment takes care of interacting with the devices, memory and cpu registers. Its easy to model human concepts on these platforms.

Java and .NET are not powerful. If low-level functionality is needed that was considered too dangerous by the system designers, there is no way to access it from within the environment.

Smalltalk is powerful. The environment takes care of interacting with the devices, memory and cpu registers. Its easy to model human concepts on this platform.

Smalltalk is powerful. Low level functionality is implemented in the same language as high level concepts. If access is needed, the code is accessible from within the environment. The virtual machine can be extended by adding custom primitives.

Smalltalk is powerful.

Mmm. Windows on Mac action…

Take two laptops into the shower? Not any more.

Its a sad but true fact that perception is reality for most of us. Unfortunately this means that looks matter. Most Smalltalk UI’s look like hangovers from Windows 3.1 (or in Squeak’s case, Toys R Us). Folks may moan about Swing being complicated, but the complexity and abstractness of the framework gives it incredible flexibility, beyond that of .Net winforms.

I fear Smalltalk will remain marginalised until its possible to build UI’s of the quality and responsiveness of IntelliJ IDEA with it.

I’m waiting for Pollock – the next generation UI framework for VisualWorks. The bar is high. I hope it makes it.

I love it when I’m proven wrong, or make a mistake. It means there’s still something more to learn.

Looks like I opened a can of worms!

Part of the impetus for my investigation into Smalltalk’s threading model was running BottomFeeder on OS X. The UI seems to lock up on my machine when retrieving feeds (or possibly posts – I forget). I don’t see the ‘wristwatch’ that a completely frozen smalltalk UI shows in OS X, but all the scroll bars seemed to stop working, and it appeared to queue up all my mouse clicks so that all manner of crazy things happened when the UI came back 🙂 This may have contributed to my initial impression that any blocking IO would block the whole smalltalk process.

That’s more of an aside (although if anyone knows whether BottomFeeder does indeed have this problem on OS X that would be great!). (Later: James kindly responded – it is a known issue in OS X and should improve)

What interests me more generally is how well smalltalk deals with things like high concurrency. Is it possible to implement non-blocking IO? Is it even necessary – can I just fork off an unlimited number of Process objects? Would it be feasible for example to use smalltalk to build a web server that gracefully survives a slashdotting on a powerful commodity pc?

For example with the latest release of Java you might use the nonblocking IO library and one thread per cpu, keeping all the cpu’s maxed out without thread-switching, so your only bottleneck is available memory (and browser timeouts). Is there an idiomatic smalltalk equivalent?

My usual tactic for maximising throughput is to minimize the number of thread/processes running, and only hand off to another process when you would otherwise have blocked, for example on IO. Nonblocking IO support in java allows me to use just one thread for all an application’s network IO, and keep the rest of the threads as busy as bandwidth allows. I don’t know how to do this in smalltalk, nor even if I’m worrying about the right problem in smalltalk 🙂