This weekend I spent a bit of time playing with Squeak (as my non-commercial Gemstone/S was missing a valid license key, so the plan to play with that went out the window).

Starting simply, I tried the following, based on some example code:

HTTPSocket httpShowPage: 'http://www.darrenhobbs.com/index.html'

Sure enough, up popped a window with the raw html of my homepage.

Wanting to try out multiple requests, I modified the code to this:

10 timesRepeat:[HTTPSocket httpShowPage: 'http://www.darrenhobbs.com/index.html'].

After a significant pause, 10 windows appeared one after the other. This was probably due to the 10 connections being single threaded and run one at a time. I then tried this:

10 timesRepeat:[[HTTPSocket httpShowPage: 'http://www.darrenhobbs.com/index.html'] fork].

It took about the same amount of time, but the windows started coming back quicker.

Being ambitious, I then tried the following:

100 timesRepeat:[[HTTPSocket httpShowPage: 'http://www.darrenhobbs.com/index.html'] fork].

And all hell broke loose. Major UI corruption. Turns out that HTTPSocket::httpShowPage is not thread safe, and updating the UI from more than one thread is a bad idea. This is fair enough – the method is basically a helper that pops a window with the contents of a url.

The offending line was this one in HTTPSocket::showPage

(StringHolder new contents: doc) openLabel: url.

Wanting a quick way to make it work for me, I went on a hunt for mechanisms to ensure thread safe UI updating and found this method on WorldState:

WorldState addDeferredUIMessage:

Changing the line in httpShowPage like so:

WorldState addDeferredUIMessage:[(StringHolder new contents: doc) openLabel: url].

And all was well. Now the multiple forked requests to httpShowPage would queue up their UI updates and play nicely together.

But thats not quite the end of the story. I now had 100 windows open, all showing the raw html from my homepage, that I had to get rid of. I could have clicked on each one individually, but I’m a developer, and this is Squeak, so after much experimentation, I came up with this:

| holders darrens |
holders := SystemNavigation default allObjectsSelect:[:anObject | anObject class = SystemWindow].
darrens := holders select:[:each | each label = 'http://www.darrenhobbs.com/index.html'].
darrens do: [:each | each delete].

And presto, 100 windows deleted.

The moral being that a system that describes itself and written in itself and is open to change is hugely powerful, and very pleasing to work with.

You’re IT manager/director at a moderate sized, fairly successful company. You have to decide which technology platform to standardise on, because standards are good, and having a unified strategy will save money. Economies of scale and all that. You’re seeing lots of articles about .Net and Java, and how they increase productivity and leverage industry best practice. Looks good. If its industry best practice then most organisations must be doing it, and you wouldn’t want to be at a competitive disadvantage. Not only that but you will have a large pool of developers to recruit from, which is another big plus for risk reduction. You don’t want to select a technology platform that the majority of developers out there don’t have experience with.

You’re a developer looking to maintain your employability and keep your skills current. You keep an eye on the job listings and the technical press. You’re seeing lots of articles about .Net and Java, and how they leverage industry best practice and increase developer productivity. Looks good. If you can increase your productivity then you’ll be more attractive to employers, and less at risk of struggling to find work. Checking the job websites shows a healthy number of positions open in .Net and Java, which is another big plus for risk reduction. You don’t want to learn a technology platform that the majority of employers out there aren’t interested in.

As of January 2005, the Squeak VM is no longer being maintained at SourceForge.

http://minnow.cc.gatech.edu/squeak/407

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.