Prague log #3

As we had decided the day before, yesterday we went straight to the Astronomical Clock, arriving there in plenty of time for the 10 o'clock "performance". I used the time to find a good spot, as far away as possible from the clock whilst still being straight in front, and checked camera angles and zoom. When the clock did chime, I was able to see the 12 apostles being displayed by the clock; there was also enough time to zoom to the clock tower and film a close-up of the trumpeter.

From the clock, we walked from the square to a different exit which lead us to Josefov, the Jewish quarter. Maybe it was the road's name, Parizska, which triggered my subconscious, but all morning the roads and the ambience caused me to think that we were in Paris.

From Parizska, we walked to Maiselov and began the 'Jewish tour'. The first stop was the Maiselov Synagogue, which has been turned into a museum. Inside were displayed articles from the Moravian and Bohemian Jewish communities: various religious utensils which were used to adorn the sifrei torah (I don't know what the gentiles would call these), menorot ("candelabra" which we use during the Chanuka festival), kiddush cups, curtains which cover the ark in which are stored the sifrei torah, special prayers written to commemorate events in history (such as the battles against the Swedish invasion of the 30 year war). The earliest articles were dated to the end of the 15th century, with most of them coming from the 19th century. This was a time when those communities thrived and even received special charters from Charles IV (also displayed, although I think that these were facsimiles). Unfortunately, things were to change in the twentieth century....

The hall itself was very crowded with people; this is partially because it is relatively a small space so any number of people within is going to make it seem crowded, but also because it seems that many tour groups cover these sites. I found myself wondering all morning what these people would make of the synagogue and its display; I suppose it's like when I have toured medieval cathedrals; I can admire the various displays without necessarily knowing the emotional baggage.

From there, a short walk lead us to the Pinhas synagogue; this too has been decommissioned, although male visitors were strongly encouraged to cover their heads as the traditional Jewish mark of respect (I saw several males with uncovered heads, one woman with a covered head (a Reform Jewess, as my wife suggested, but I think that it was more out of ignorance but maybe respect) and one youth who placed his kipa on top of his hat). If the Maiselov synagogue was a testament to the golden days of the 18-19th centuries, then the Pinhas synagogue was testament to the defining event of European Jewry in the 20th century: the Holocaust. There were no items on display; the walls were covered - without bare patches - with the names of over 80,000 members of the Jewish communities of Prague, Brno and other Czech towns who were exterminated in the concentration camps of the Nazis.

Tears naturally came to my eyes then, and I am crying (or more accurately, leaking tears) as I write these words now, in the safety of my hotel room. Again, the museum was crowded, and it seemed that German was the dominant language being spoken. I wonder how much those people - some older than me, who would have been babies at the end of the war, and some youngsters still at school - understand and what they feel. Are they detached from the abominable activities of a misguided generation or two? Are they ashamed of their country's modern history?

Upstairs was an exhibit of children's drawings mainly done in the Terezin (Theresienstadt) Concentration Camp (we will be visiting there tomorrow, so I won't write any exposition today). I don't recall ever seeing similar displays in the Holocaust Museum in Jerusalem, although the above article on Terezin suggests otherwise. There is so much to see in Jerusalem - and most of that through tears - that it is not surprising that some things remain hidden from the consiousness.

The path from the synagogue leads directly into the old Jewish cemetery. As in common with all cemeteries, it is very quiet here, with only a whispered commentary from the tour groups breaking the silence. My wife remarked that the stones were placed in such a way that it was impossible to know where each separate grave was; I pointed out that the gravestones had probably been collected and placed in the best way possible. The sanctity of the graves themselves was not the point, but rather the huge collection of stones - dating from the 15th century. As opposed to modern gravestones whose paltry text state the name and dates of the deceased, these stones were covered in writing from top to bottom. We couldn't make out much of the text, but what could be deciphered tended to be religious writings and not personal details.

The graveyard leads into another synagogue converted into a museum, the Klausova. After the emotional stress of the past hour or so, we were content to sit on a bench, look around the crowded room and get our emotions back in order. From there, we found ourselves back in Prague, or should I say, Paris? We crossed a main road and found ourselves in a quiet street with no tour groups, and in fact, few pedestrians. We entered a small tea-room which could have been transported brick by brick from Paris, and enjoyed a quiet cup of tea. The name of the road is Bilkova; from there we walked to Kozi which lead to Dlouha, all the time the roads being more and more populated, but enjoyable all the same. No tour groups, very quiet and very beautiful. Dlouha ends on Revoluchni, a main thoroughfare, which leads of course to Namesti Republiky and our hotel.

We ate lunch at a Chinese restaurant in the Palladium shopping centre, which is where we seem to spend most afternoons. We are girding ourselves to trying sushi but at the moment are sticking to chicken dishes that we know and like. After lunch, we shopped (and shopped and shopped). Unless my calculations regarding the exchange rate are seriously wrong, clothes are incredibly cheap here and my wife was in heaven. I found several jackets which roughly were what I wanted (in the bargain basement of Marks and Spencer, to be accurate), costing 899 CHK. I tried a few on, but they were either not wide enough around the body or else the arms were too long. Enter a saleswoman who may not know English but does know her jackets: 44 short she kept on saying and eventually found a jacket with the correct measurements. 44 chest to cover my barrel-like middle age pouch, and short arms.Yes!

A neighbouring C&A seemed like a bargain basement, selling shirts at give-away prices. My wife snatched a few hoodies for our son, I bough some corduroy jeans and she bought herself some items. I jokingly suggested that we buy items in order to sell them in Israel at twice the price, which still would be less that the comparative Israeli price, thus financing our trip.

Eventually we finished, drank a concluding pot of tea in a coffee bar (again, the tea seems cheap, 50CHK, which I calculate to be less than half the equivalent price in Israel, and this is for a pot of tea, which yields nearly two large cups) and then back to the hotel to unpack, get organised and do Internet research for the days to come. The program seems to be:

Thursday (today) - Karlovy Vary by bus

Friday - Terezin, organised tour

Saturday - flea market in Prague, including journey by Metro

Sunday - to be announced

Monday - flying to Malta

Prague log #2

There isn't much to add to the log for our first day. After getting settled in the hotel, we walked to the nearby Namesti Republicky (Republic Square) which is a huge concourse with several roads leading off it. After a few wrong turns, we found the street that we wanted, which housed a T-mobile shop; here we bought a local Czech SIM card for my wife's mobile phone, thus enabling her to call me, me to call her and the children to call her.

By the time we finished there, we discovered that we were ravenous so we stopped at the first restaurant that we found and had a meal (too much salt). From there, we walked back to the hotel and rested a while. Later on, we went to the huge Palladium shopping centre, which is literally a stone's throw from the hotel; we each drank a pot of tea in order to revive ourselves and then checked out the variety of stores. Most of them seemed to be women's clothing, which means paradise for my wife and boredom for me. We found a big bookshop, but of course all the title are in Czech.... After leaving the shopping centre, we rambled a bit outside (actually getting a little lost, but I have an inertial guiding system in my head so we reached the hotel without difficulty. Even though it was only about 7pm, we went to bed, as the lack of sleep had been getting to both of us.

Day 2

We woke at around 6:30am; I did my daily chores on the computer, and then we had a sumptuous breakfast in the hotel's dining room which was fairly full. When we hit the streets, they were pleasantly empty - there were a few tour groups but they weren't a hindrance. From our central location, we located the Powder Tower (a very imposing - and tall - building) and behind it, Celetna street which would take us to the Old Town Hall and a major square. We walked down the narrow street, mainly admiring the architecture; one has to look more up in Prague than down, as the buildings are tall and the architectural frivolies are outstanding.

In the Old Town square is located the Astronomical Clock; unfortunately we just missed its 9am call.

From there we carried on into the old city (it's like Jerusalem!) until we found the Charles Bridge. We crossed this slowly and made our way into the little 'Venice' section at the other end, which was charming. Part of it also reminded me of a French boulevard. Whilst the bridge had been moderately crowded, this part was fairly empty which added to its charm. After resting a while and drinking an ice cream sundae, we took one of the boat cruises, which started off in the mock canal (which apparently featured in the first 'Mission Impossible' film, masquerading as the real Venice) and then continued onto the Vltava, where we changed onto a bigger boat.

After the boat trip, we checked out the Charles Bridge museum, which although small was interesting, showing how the bridge had been built and how it had been renovated. From there, we saw that we had about ten minutes to get back to the Astronomical Clock before it chimed 3pm, so we fairly ran through the now crowded streets in order to get there in time. Just as we arrived, the clock chimed, a trumpeter (live) blew a fanfare from the tower's top ... and that was it. Maybe we were missing something. I intend to go back again this morning, when there are fewer people and check what is happening, because the Wikipedia page says that there is more to meet the eye.

Returning via Celetna, we stopped in the souvenir stores which we had studiously ignored in the morning, and my wife bought all manner of Czech souvenirs. The most interesting was a little shop which we found buried in a sidestreet, featuring little 'sculptures' of objects made solely of nuts and bolts. We bought a small chicken, mouse and dog (if I remember correctly), but there were much bigger pieces. Imagine trying to get them past customs....

After another rest in the hotel and sorting our possessions out, we went to the shopping centre again,  to eat a passable Pizza. This time we found all the shops selling clothes for men - they're simply on a different floor to the women's shops. We tried to find a linen jacket for me; it took some explaining from me before my wife understood what I wanted. Eventually we found something good - only it was too small and they didn't have anything larger.

From there to gentle (as Robert Fripp tends to write). More days await us.

Prague log #1

It's 10:30 on a sunny Monday morning and we have just arrived in Prague for a week's stay. Our hotel room was ready and waiting, there is an adequate wireless Internet connection, and the signs could not be better.

The trip did not start on the right foot, though. Friday night/Saturday was Yom Kippur, the most holy Jewish day; unfortunately, I woke up at 6am, and although I rested most of the day, and dozed for a few hours, I was unable to get to sleep at night. I eventually fell asleep at about 1:30am, and was up again at 5:30am on Sunday. Our flight was scheduled to leave Tel Aviv airport at 5am on Monday morning, which meant that we had to be there at around 2:30, which meant getting up at around 1:15am. Although I went to lie down at around 9pm, I was too agitated to sleep, so basically I've been awake since yesterday morning. I am quite tired.

Even though we did in fact arrive at the airport at 2:30am, there were crowds at passport control and personal luggage checking, which meant that we didn't clear these sections till about 3:50am. As we had to board at 4:30am, there wasn't much time left for duty free shopping and other activities. I had intended to get out the computer for some work, but it was clear that there would be no free time.

About a month and a half ago, I and my wife were issued American Express credit cards. The way in which we were approached raised my antennae, and for a few hours I thought that we had been victims of a scam, but it all seems to be above board. One of the perks of the card is free entrance to the VIP lounge at Ben Gurion airport, and this trip seemed the ideal opportunity for testing the perk.

As we had so little time, we could only spend about ten minutes in the lounge. By this time, I was almost shaking from low sugar, so I very quickly ate a few biscuits and drank a bottle of fruit juice (all free). My wife had some crackers and tea. It's a shame that we were only there for a short period; next time, we will try to have a longer stay in the lounge. When we leave Prague, we will fly for a few days to Malta before returning home, so we will have the opportunity of testing the equivalent Prague VIP lounge. Although we have a certain amount of 'perk' as regarding the lounge, we also have to pay $27 to gain entrance, and I am not sure that we will get our money's worth.

My wife is unpacking at the moment; afterwards we'll probably have lunch and hit the town.

A twilight health stage

To quote Michael Covington, "The astute reader will surmise that I'm working hard on something other than writing blog entries". I wish this were true about me. I have been suffering from a presumably viral infection that frequently elevates my body temperature (but never to more than 37.5 degrees), makes me cough on and off, and generally leaves me listless without causing any great pain.

It's also the holiday season in Israel. Last week we had four days off from work (wed-thur-fri-sat), although Wednesday was a 'compulsory' day which will be deducted from my holiday allotment. Next week there are two days off and again the week after. This is an ideal time to go somewhere for a holiday, and indeed, next Monday morning we (my wife and I) are flying to Prague for a week, and then continuing to Malta for another four nights. I hope that I feel better before we go.

I'm not exactly busy at work which is just as well as I don't think that I have enough strength to cope should the need for my services heat up. I'm too well to stay at home but not really well enough to be at work: a twilight health stage.

Ian Rankin: "The Complaints"

After Rankin's literary creation DI John Rebus took compulsory retirement, it is now the turn of Inspector Malcolm Fox to star in Rankin's novels. Fox is almost the complete opposite of Rebus: Rebus was in CID, Fox in Complaints and Conduct (specifically the Professional Standards Unit, which investigates 'bent coppers'). Rebus was a hard drinker and smoker, whereas Fox is teetotal and a non-smoker. Rebus is a loner, whereas Fox has a sister and a father whom he visits all the time.

So the stage was set for a different kind of novel, showing police work from a different angle. And indeed, 'The Complaints' starts out completely differently from a Rebus novel. But after four or five chapters, suddenly the style of the novel became familiar. Fox gets suspended but continues investigating; the plot thickens and thickens and only Fox is able to get the insights which lead him to a conclusion. In effect, this is a Rebus novel without Rebus.

That isn't to say that this is a bad novel; on the contrary, it is gripping, intriguing, full of suspense and one is never sure where it is going to lead. Those who enjoy the Rebus novels which enjoy this one as well. But I had expected a different style, and in this Rankin does not deliver. One aspect which did not exist in the Rebus novels is the family: Fox feels responsible for his father who is living in an old age home. The episodes are handled very realistically.

Nitpicking: there is a conversation between Fox and a bouncer. The latter was released from prison just under two years ago, yet he is the father of an eighteen month old child. Assuming that there were no conjugal visits, the age of the child doesn't add up (unless of course the bouncer is not the biological father).

Fox is not a music lover like Rebus. Instead of listening to the Rolling Stones and dropping musical references all over the place, Fox might listen to FM Classical but generally listens to a radio channel called 'Birdsong' which plays ... continuous birdsong. But Rankin still manages to drop in a subtle in-joke: one of Fox's colleagues is called Tony Kaye, which just happens to be the name of the original organist in Yes.

The Swell Season/The Frames

After writing my previous entry, I thought that it would be a good idea to check what Glen Hansard sounded like prior to The Swell Season. I downloaded a few Frames' records (don't worry: they are all deleted now for reasons which will shortly become clear) and listened to them on the way to and from my Friday MBA lecture. The songs varied from the innocuous to the annoying, with only one song - an instrumental - really finding favour (and typically, this instrumental seems to be completely different from everything else, as if it were a different group playing). It was interesting to note that two songs which appear on The Swell Season (ie the eponymous first album) also appear on The Frames' "The Cost" album, "Falling slowly" and "When your mind's made up".

The latter opens with two electric guitars playing similar but not identical arpeggio patterns, which makes for interesting listening via headphones. The arrangement is almost identical to the later versions, although the 'instrumental freak-out' section is over the top here. I would rate this to be at about 80% of the later, clearer, arrangements. I note that the piano arrangement seems to be note for note the same in all the versions.

On the other hand, "Falling slowly" loses all its charm when interpreted by a band and without female harmony vocals. This initial version sounds very basic, and the overly simple tune is exposed mercilessly. This would rate about 25% compared to later versions.

In other words, the standard rock group setup of The Frames (taking into account that they have a violinist) does not excite my ears. Paring down the sound (and especially removing the drums) and adding the string instruments definitely improves the songs.

Please let me know you listen to a group that plays songs with acoustic and chamber like arrangements. Let not the songs be all fey and magical, such as the Incredible String Band.

Updates (mainly The Swell Season)

I reread the first half of 'Bad boy' again earlier in the week. When writing about the book two weeks ago, I mentioned that I didn't find any major mistakes in it. This time around, I noticed a rather subtle mistake concerning Tracy Banks and her mobile phone; the mistake probably arises from a sentence being deleted from the text of the book - it's not a logical mistake as were the others.

Over the past six months, I've been listening very frequently to the Swell Season. The first item of theirs which I bought was the deluxe version of 'Strict Joy', which comes as a three disc set. The first disc is the 'Strict Joy' album itself; the second is a live concert, and the third is a dvd containing interviews along with some of the performances which are on the second disc. I bought this package from amazon.co.uk, which sold it at a very reasonable price, and only slightly more expensive than the one cd version (which is why I bought the deluxe set). Amazon.com is quoting the limited version at almost twice the price of the standard disc, so it's worth shopping around.

There's a very interesting song on 'Strict Joy': 'Love that conquers'. The opening instrumental phrase (which is repeated almost ad nauseam) is in 5/4, which allows one to excuse the lack of harmonic activity. But when Glen begins to sing, suddenly the time signature is 6/4! Is the previous bar lengthened or is it the sung bar? Does it matter. Then it's back to 5/4 for a few more instrumental bars, and then bang! Back to 6/4 for a line. Later on in the song, Glen and Marketa add a few more syllables to the lines which are sung in 7/4. They must have had fun recording this.

About a month ago, I found a copy of their film, 'Once', on the Internet and eagerly downloaded it. I now discover that Amazon (UK) are selling it for a pittance - but either way, the film is without the Hebrew subtitles which are so important for my wife. In fact, most of the Dublin accents are so strong that I miss a fair amount of the dialogue as well. Maybe one day it will be screened here.

The film opens with Glen Hansard in the same position (but ten or more years older) as he was at the end of 'The Commitments' - busking in Grafton Street. The film was enjoyable, but not outstanding; it's more enjoyable for me watching them make music. There is an amusing scene where Marketa Irglova brings her Hoover to be repaired; she drags it around, making it look like she's taking her dog for a walk. Here's an interview which I've just found about the making of the film.

After watching the film, I felt compelled to order the original 'Swell Season' cd. The arrangements of this album are much more 'chamber' style - guitar, piano, violin and cello - and preferable to my ears that the slightly rocked up versions on the 'Strict Joy' live disc. It's the drums that do the damage. I also prefer the sound of their initial disc to the sound of 'Strict Joy'. It's a shame that they didn't use any wind instruments - an oboe, Uilleann pipes or even a flute would have been a welcome addition.

More inbasket

About a month ago, I started measuring access to this blog and also joined the Amazon Associates program. Whilst the number of people reading this blog is hardly astronomical, there are more hits than I had expected (and unfortunately, a certain percentage of those belong to me).

Surprisingly, the most popular page on this blog is the original post about the Inbasket exam. I imagine that most of the people reading the page wanted to know how to pass the exam successfully and presumably hoped to find some hints. If that is the case, then I'm sure that they were disappointed. There isn't really any way to learn how to pass such exams; the key is to practice on existing exams and to have a great deal of common sense. The exam is testing one's ability to deal with happening events in a reasonable order, and that's not something which can be easily taught.

This reminds me of an issue in the MBA organisational behaviour course, when the subject was leadership; the lecturer said that the Americans believe that everything can be taught, whereas the British tend to believe that leadership is a part of one's personality and is composed of several smaller components. The inbasket exam is similar to a leadership exam; either one has it or one doesn't.

Anyway ... this being the most popular post, it only goes to reason that I have actually earned a few cents by someone clicking on the book reference given on that page, and even apparently buying the book.

In the mean time, the Occupational Psychologist has developed a new exam, this time for the manager of a non-residential old age activity centre. I asked her how she managed to develop the exam so quickly and she said that it was a combination of interviewing people who work in such a centre along with adapting existing material. A few people took this new exam, which revealed yet again a few more bugs. The DLL plugin approach to the exam proved itself in quickly allowing us to implement a new exam.

I often read blogs about entrepreneurial enterprises; this blog  is very lucid on the subject:

"To summarize: Anything that can be copied will be copied, including features, marketing copy, and pricing. Anything you read on popular blogs is also read by everyone else. You don't have an 'edge' just because you're passionate, hard-working, or 'lean'. The only real competitive advantage is that which cannot be copied and cannot be bought. Like what?"

The psychological testing clinic (I have to find a better name in English) is not the only one of its kind in Israel, but we are definitely in a niche market. The competitive advantage that we have is the in-house development of the computerised exams. For example, we are considering the use of the Minnesota Multiphasic Personality Inventory (MMPI); this is a standard psychological exam, although intended for more pathological use than we generally need. One can read about the exam on the Internet and even buy books which give the questions (I don't know whether one needs to be a licensed psychologist in order to do, but I imagine not). Our advantage is that we can quickly take the Hebrew version of this exam and computerise it; our even bigger advantage is that we can then generate both standardised and customised reports from the standard data.

But our biggest advantage is that the OP is interested in expanding both the range of our services and their quality (ie new reports, etc). Whilst my contribution is not trivial, I am only shaping/sculpting information which is given to me; the jewels - the psychological knowledge - come from the OP.

Again, the inbasket exam framework is a huge advantage which enables us to move into unexploited territory with little difficulty.

Bad boy

With very little fanfare, the nineteenth book in the DCI Banks series, "Bad boy", was published a week ago. Amazon had been plugging it for only three weeks before its publishing date so the gap between knowing about the book's existence and reading it was fairly short.

Most of Peter Robinson's books tend to start slowly and build up steam as they progress, and this book is no exception to that rule. In fact, this one started so slowly that it took almost half the book before its pace became more than leisurely. Contributing to this is the fact that DCI Banks is on holiday in San Francisco when the story begins and there is a great deal of development before he returns to Eastvale.

In Banks' absence, most of the story (until his return) is told through the eyes of his colleague DI Annie Cabbot. She has been the third party limited narrator in previous books but has always had to 'share the stage' with Banks. Here the first hundred or so pages come from her point of view, and when the book does switch to another character's pov, it is that of Tracy Banks (DCI Banks' daughter, who until now has been a peripheral character - more mentioned than actually present - in most of the books).

This book is not a classical police procedural; there is no murder to be solved, but the book does present much more police procedure than one normally gets in a novel. Judging by the acknowledgments at the end of the book, author Robinson got most of this material directly from the real police. As such, this is not another in the regular Banks series, where Banks has to outwit someone who committed a murder at the beginning of the book. Instead this is a less cerebral and more action focused story - which does not centre around Banks (at least, not until the end).

In my one read through of the book (which probably was taken at a faster pace than I will take in the future), I didn't notice any glaring mistakes. In previous books, I've found a few; the first time I pointed the mistake out to author Robinson, but as he notes on his website,

By the time a book goes to press, it has been read by about twenty people, many of them professionals in the book business, and still mistakes slip through. They always will. It’s human nature. You might think you’re the first person to notice that Banks’s eyes are blue on page 53 and grey on page 314, but you’re probably not. And sometimes these gentle admonishments come at quite the wrong moment. When you’re having a difficult time with the book you’re writing, the last thing you want is some smart Alec telling you there’s something wrong with your last book!

In 'Strange Affair', Annie Cabbott eats meat after having been a strict vegetarian in all the books; in another, Banks leaves a hotel room without turning off the television, but when he returns, he turns it back on (maybe the maid turned it off in his absence). Rereading "Innocent graves" a week ago, I found a very subtle error in which the location of an interview is given wrongly. But as I say, 'Bad boy' doesn't seem to have such an error.

This is similar to continuity problems in films: very rarely is the viewer aware of such problems as she is too caught up in the story to notice, but watching the film at a slower pace will often reveal a multitude of errors.

I assume that Robinson has reached the limit of the traditional police procedural and is now extending his range, utilising the same cast of characters but on solving problems other than murder. As such, his actions are to be applauded - because otherwise it would be very hard to explain the high murder rate of Eastvale, a fictitious setting for what was once a small town and now seems to have grown to alarming proportions.

Unlike other of his novels, this book didn't touch a nerve in context of its background material, for example  "Piece of the heart" or "Close to home" (aka "The summer that never was"). As such, it becomes an exciting read but not a novel from which my life might be enriched, or cause me to think about similar events which might have occurred in my life.

Looking at the other reviews currently at Amazon, they all say that this is Robinson's worst book in the series. Whilst it is far from being the best, it is also different from the others (a fact which I tried to point out two paragraphs earlier) and as such should not necessarily be compared to the others. At least it has a definite storyline with a beginning, a middle and an end, which is more than the previous 'experimental novel', "All the colours of darkness", had.

Back to school

Today was the first day of the autumn semester of my MBA programme. On the drive there, it was as if the car knew where to go, in the same way that superdog knows the route of our twice daily walks (sometimes I change it just to confuse her). On Fridays, the lectures are in two shifts: from 8-11am, and from 11:15-14:15. I prefer to have lectures in the first shift, but this semester mine are in the second shift. As today is the first day of term when the lecture kits are distributed, I turned up early so that I would definitely be on time for the lecture. As it happens, there was no queue for the kits so I had at least half an hour to kill after receiving the kit. I spoke a little with the course director, checking my future plans, and he also disclosed my result in the economics exam (a very respectable 71).

This semester I am taking the project management course, which should be very useful in the day job. Whilst in a sense almost all of my work could be considered to be composed of projects, strictly speaking a project has to involve more than one person. In this case, the column which I wrote two months ago describes what is a project by every definition, and is sorely lacking management. I am tempted to take some of the material which was presented today and apply this to the MTD project, showing where it is failing (although I know full well where the problem lies, without knowing anything about project management).

Ironically this evening I was looking for some material about in-basket exams on the internet and found a series of three blogs on the subject, ironically from a blog which is mainly about project management. I intend to visit this site more frequently.

The in-basket 6

Until now, in discussing the inbasket exam, I've only written about how the exam has been implemented and the various programming techniques necessary. Now it's time to stand back a little and look at the larger issues of the exam. But first a little debugging....

This time last week, the exam underwent its baptism of fire and was used with 'real live' examinees. The person running the lab contacted me as he was unable to get the database version of the exam to run, so I made a remote connection and transferred the new dll version of the exam (which had not been completed debugged).

In the evening,  I remote connected again to the testing lab and downloaded three result files for examination. It immediately became clear that there were several errors in the file structure, some of which were easily correctable and some were somewhat harder. After 'massaging' the text file (and simultaneously correcting the exam program so that it will produce the correct format the next time it will be run), they were in a form which could be read in to the database and could produce reasonable results.

Meeting with the OP the next day, she informed me that four people had undertaken the exam. Where was the fourth person's results? I hadn't seen a fourth text file anywhere, but we found written confirmation that there was a fourth person who had undergone the test (it seemed possible to me that a fourth person was supposed to have undergone the test but did not). When checking on which computer this fourth person had used, I saw that the dll version of the exam had not been installed there; had the person undergone the test using the database version, the results would have gone directly into the database - and I overwrote the database in the morning as its structure had changed slightly. What could we do?

The answer of course is use the backup (which is done every evening to one of two external hard drives). We found the backed up database file and I was able to ascertain that the fourth person's results were indeed stored within the database. I took this file (taking care to rename it) and then wrote a one-off program to extract the results in the required text format.

When this file was read into the (new) database, a few new bugs became apparent, mainly connected with the handling of instant messages. I wondered why the first three files had not surfaced these problems; checking the answers carefully, it became apparent that there were no results for the im's in the result file. I checked the program code and saw that the results should have been written to the file, and even underwent the quick and dirty demo exam in order to confirm that the im's results were written.

It then became clear that the instant messages had not been displayed in the 'real' exam. Via the debugger, I ran the exam with the 'real' inbasket dll and saw that there was a bug in the code which was responsible for finding an instant message to be displayed (the equivalent of an sql query). The bug itself was in the resource file, not in the program code, meaning that the real bug was in the code which outputted the resource file. Like all bugs, hard to find but easy to fix.

So now we have a (hopefully) completely debugged exam. What can we do with it? Unfortunately, most of the analysis of the results would seem to be 'analogue' - text only, analysis by the psychologist, based on what was written, how it was written, to whom it was written, etc. There doesn't seem to be a standard 'key' by which the exam results could be marked. This is in contrast with the accounting exam which I converted; this exam differs from the 'real' exam in that the accounting exam requires the examinee to place several tasks in correct order (there are various constraints which force the order) but require minimal replies, whereas the 'real' exam's value is based on the replies themselves and not on the order in which they were dealt with.

What 'digital' results can I produce from the data? I had considered something like 'average time that message is displayed on screen', as we had noticed that one examinee seemed to take a long time to answer messages whereas another answered very quickly. This idea was discarded because theoretically an examinee could open all the messages in the inbox (thus having several simultaneously open windows) and then decide which to answer first. So the only metric that we currently have is how many times each message has been answered. Most messages should only be answered once, but some might (and some have to) be answered more than once. This metric shows the results in a concise format.

Following on from this, I am considering a metric in which we will see how many times a message was closed without it being answered. I am not convinced of the value of such a metric; just because it will be easy to write does not mean that it has any value. I noticed than one of the examinees was constantly opening and closing messages without answering them, and this metric will give such behaviour a numerical value. I am not qualified to determine whether such a numerical value has any psychological value.

As I wrote earlier, the successful implementation of the inbasket exam (as a framework) allows us to incorporate exams which are suited to different fields, thus allowing the OP and her staff to enter the recruitment field, either as primary recruiters (which might be considered as diluting the consultancy's core business) or as secondary recruiters (supplying evaluations to an outside recruiting company). I am also considering showing the exam to people at work; we no longer have a HR function within the company and people seem to be hired willy-nilly. Use of the test will allow us to winnow out people and concentrate on more successful applicants (not that there are many jobs being offered, if at all).

Tuna mousse

Last week, my wife and I were invited to a party hosted by a couple on the kibbutz. The food was all non-meat and included two fish mousses: one made from tuna and one made from salmon. They both were very tasty and seemed simple to make, so I downloaded a recipe and tried my hand.

Here is the recipe:

1 170g can of tuna, drained

1 small onion, chopped

6 tablespoons of mayonnaise

1 tablespoon of ketchup  (this may well be unnecessary)

1 teaspoon of vinegar

1 sachet of gelatin

150 ml boiling water

150 ml cold water

I mixed the tuna, onion, mayonnaise, ketchup and vinegar together until a smooth consistency was achieved. The recipe recommends doing this in a food processor but I don't have one. I did try in the blender (which I normally use for milk shakes) but everything clogged up due to a lack of liquid, so this wasn't very successful. Maybe I should try blending only the onions and then add the resulting liquid to the other ingredients.

In a separate bowl, I added the gelatin powder to the water and stirred until all the powder had dissolved. Then I added this liquid to the rest of the ingredients and mixed thoroughly.

The next and final stage of the recipe required me to pour the mixture into a mould and then refrigerate. I don't have such a mould in the kitchen, so I looked for something suitable. Eventually I found two cd containers - I buy disks in bulk in a plastic container with a spindle. The outside cover of the container seemed suitable, so I cleaned two of these (thanking my foresightedness in not throwing the empty ones out) and then poured the tuna mix into them. Playing safe, I put the containers into the freezer.

The next morning, I took the containers and put them in the refridgerator, and in the evening they were suitable for spreading. Both my wife and I had tuna mousse on bread for dinner, and the results were encouraging. I thought that there was too much onion but my wife thought otherwise. If I were serving the mousse on a plate, I would probably use an ice cream scoop in order to transfer the mousse to the plate.

A simple dish with no cooking: perfect for the summer.

How things have changed

After writing about 'Nice work', I thought that I would check when I bought the book (or at least, first read it). I looked through some letters from around the right time period (the years following 1989), and found that the first reference to the book was in August 1991.

I had to look through 'hard copies' of letters; even though I was using computers to write letters from 1986 or thereabouts, I never saved them as computer files, preferring to save the printed versions instead. As a result, some of the letters are virtually unreadable as they were printed via ribbons whose final days had come. Considering that in those days, the letters would have been simple text files with negligible overheads, storage space must have been at an extreme premium, so much so not to store even a measly 1K. I remember that it was considered a huge win when I found a program which would add an extra sector to a floppy disc, increasing its storage size from 360KB to 410KB. Eventually, I would move to writing letters by email (and those are stored), but in order to do that, I needed that my correspondent also to have email, and that took some time.

Anyway, back to the books. One has to remember that 1991 was still pre-Internet and that one had to rely on book reviews or book clubs in order to learn about new books. It comes back to me that in those days I used to obtain a copy of 'Penguins in Print', a directory which listed all the books that excellent paperback house Penguin had in print and so were theoretically available. I used to go through that directory diligently and compile a list of ISBNs (ie book identity numbers) which would then be ordered when my parents or I went to Britain.

The books used to be so heavy and voluminous that we wouldn't bring them back in our suitcases. Instead, I would have to make parcels and sent them by post. One year, I sent two such parcels but only one of them arrived. For obvious reasons, I don't recall what was in the missing parcel, but I seem to remember that nothing precious was lost. In those days, of course, many books were bought 'on spec', so losing them did not necessarily mean that any book that I really wanted disappeared.

Today I received an email from Amazon, suggesting books that I might like to read. I clicked on an autobiographical book by musician Rick Wakeman and on a neuroscience book, and should I wish, those books will be with me in another week. The only reason that I didn't order is because I'm having problems activating a new credit card and I don't want payment problems with Amazon. How things have changed over the past twenty years.

Similarly with the emails - or anything computerised - if I want to find some text, I use a 'search' function and thousands of files are searched in a few seconds. No more leafing through old letters and having to read them all in order to find a nugget.

I came across a letter from early 1990 in which I was writing about my daughter: she had just turned two. I read the passage to her now, and it was very nostalgic for a moment.

Nice work

A little judicious work with the blogger search function shows that I have mentioned David Lodge in four different blog entries over the years but have never tagged him. That has now been corrected.

The first novel of Lodge's that I read was 'Changing places', which was recommended by some book club of which I was a member maybe twenty five years ago. The book was amusing but not overly so, and I don't think that I've read it for many a year. The second was the sequel to CP, "Small world", which I liked somewhat less than CP. Despite this, I found both books interesting enough to keep David Lodge on my search list, and this paid in spades when I found his next novel, "Nice work".

I know that CP was actually Lodge's fifth or sixth book to be published, but his first three novels were out of print in the eighties and nineties (I bought all three in new editions in 2002). But for me, it was his first book, and as far as I am concerned, there was a leap made in quality from the books which preceded it to those which came after. A similar thing happened with Peter Robinson (the first book of his which I read was his tenth to be published) and this makes me wonder whether it's the same thing as in music: the first song one hears by someone is always better than anything which they had made beforehand.

'Nice work' was a very suitable novel for me, because it brought together the disparate worlds of industry and academy. I straddle those worlds myself. Whilst the book itself can be read as a complete - and very interesting story - there is also an amusing subtext (or maybe supertext). One of the protagonists of the book, Robyn Penrose, is a University lecturer specialising in the 'industrial novel'; Lodge 'quotes' a lecture which she delivers to a class, and the ideas presented in the lecture form the background structure to the novel.

Indeed, there is a very important sentence uttered in the lecture whose significance I missed for several years. I had always thought that the ending of the book was rather weak; not quite deux ex machina, but very close (and incidentally, other books of Lodge also suffer from this same malady). But during one pass through the book, I noticed that the situation which suddenly arises at the end of the book - in which Robin is offered marriage, a job in America and receives a legacy following her uncle's death - is exactly what was expounded in her lecture.

I quote from page 83 of my edition of the book:

In short, all the Victorian novelist could offer as a solution to the problems of industrial capitalism were: a legacy, a marriage, emigration or death.

Once I noticed this, all sorts of other bits and pieces started to fall into place. In my opinion, 'Nice work' should have received better reviews that it does at Amazon.

My edition (Penguin 1989, bearing the number '10' alone) has on its cover a picture of Vic Wilcox and Robyn Penrose as portrayed in "a riveting BBC television series from the bestselling book". I wouldn't say that I've lusted after this BBC series, but I have always been interesting in finding it. It would seem that it has yet to be transferred to DVD.

Imagine my surprise and pleasure, then, a few weeks ago when I found a torrent of the series at a BBC torrent site. I eagerly downloaded the torrent and waited for it to complete. Over the past week, I have watched all four episodes of the series as well as rereading the book.

I have to give the series a very high mark. The screenplay was written by David Lodge himself and so is naturally very close to the original. Of course, not all of the book has been transferred to the screen (the daughter of Vic Wilcox has been excised, for example) but it is a very faithful translation. What is missing is the literary subtext; one is much less aware of the parallels to the Victorian industrial novel (even though most of Robyn's lecture is preserved), and the entire 'Silk Cut' deconstruction has disappeared. The telling of Robyn and Vic's stay in Dusseldorf is shown as it happened (well, most of it) as opposed to having it described by Robyn to Penny Black (is Lodge a stamp collector? Only now do I realise the significance of this name) in a sauna.

The casting is superb as well; most of the characters (save Robyn herself) look almost exactly as I imagined them. The actress playing Robyn doesn't quite look the part but is very good (and manages to put on an instant Birmingham accent when in Dusseldorf).

I definitely recommend looking out for this book - and if one is exceptionally lucky, the torrent.

The in-basket 5

Until now, I've been concentrating on writing about the exam program which a user will run. This program outputs a text file containing pertinent information about the exam - the user's name, date of birth, date of exam, exam name - as well as the values generated whilst operating the program - opening and closing of messages, message text, etc. Today I'm going to write a little about importing this text file into the database.

But first: I deleted the dll code from one of my computers before I realised that I had not backed up this code. So I had to spend a certain amount of time recreating the changes necessary to enable the exam program to read its data from a dll. Whilst doing so, I noticed that there were still a few little bits and pieces to correct or improve, so I corrected and/or improved. I also religiously backed up.

Adding the import code to the existing results program was fairly simple as I have already done this with five or six other programs. True, the import code has to be tailored to the format of the import file, but most of this is boilerplate code. I discovered that I had to add a new field to the 'exams' table in the database, in which the dll name of the exam is stored, but this was a minor incovenience. Otherwise, writing the import code was straightforward and it worked (almost) correctly the first time. The only thing which needed fixing was reading the final line of the import file, which showed when the user finished the exam.

I will be introducing the new version of the programs into the work environment in the next few days. I understand that a few people are being tested with it today, but hopefully there will be more in the near future. The OP is quite enthusiastic about this exam as it enables her and her staff to widen their horizons regarding their customers, allowing the OP to enter the field of human resource testing and head hunting.

The in-basket 4

After walking around for a few days with my head in sky, playing with AI programs, I thought that it was time to return to Earth and improve the in-basket exam. At the moment, the exam is unique in that it accesses a database in order to find its data, whereas all the other exams which I have written, including the aptitude exam, have their data compiled into a resource file which is attached to the executable exam. Could I do the same with the in-basket?

At first, I thought that this would be not be possible, as there are all kinds of gotchas in this exam - rich text has to be displayed, replies have to be referenced, etc. But after a while, I realised that it definitely would be possible to convert the exam to reference a resource file and not a database. The rich text was actually simple to solve: the 'administrator' program saves each rich text entry in the database as an rtf file, and these are then loaded into the rc (resource source) file. Storing the people referenced in the exam turned out to be very simple: the program adds 10,000 to each person's id (so as not to clash with message ids), and in the stringtable are stored as separate strings the person's name, job and comments. The messages were also fairly easy to store.

Rewriting the exam to use a resource file was tedious but not too problematic. I fixed a few existing minor bugs which became apparent during this process, so this version is actually slightly better than the original. A reply to an email had to be stored in two places: on the one hand, the text of the reply and the reasons had to be stored in the output file (which will eventually be read into the database), whereas on the other hand, the text has to be kept in memory as it has to be rereferenced should the examinee decide to reply to one of his own emails. I solved this by defining a record type (which inherits from TObject) and storing the replies in a TList. Debugging was a bit awkward but eventually I got all the bugs out and even improved the program a little by displaying replies in a different colour.

But I had also lost something: I would need a separate exam program for every exam (ie one exe file runs the demonstration exam, one exe file runs the furniture exam, etc). Whilst this is not too annoying, it is somewhat impractical. The solution is to store each resource file in a dll; the program scans the list of dlls in the current directory and displays them in a combo box (on the form where the user enters her details). The dll chosen is then passed to the 'LoadLibrary' function, and all future resource references are made to the handle of the dll library. Maybe complicated to explain, but this didn't take very long to implement.

This is quite a step forward in Windows programming for me.

Porting the Amateur Reasoner/2

I didn't sleep too well last night, probably because I was very excited. Yesterday evening I was rummaging around old (paper) files which I had stored and I came across program listings for several versions of the Amateur Reasoner. I found the same listing that I downloaded a few days ago, but I also found later versions; the final version was v1.7.1 dated 1 May 1991.

In this version I see that I had addressed some of the problems in earlier versions: there is use of a generic list object (and all the pointer records are now objects), there is use of variable length strings, there is no hash table, tokens are concatenated making longer strings (and so the introduction text is a few strings instead of many tokens), and the tokeniser seems to have been rewritten and improved. I suppose that when I next get a block of free time, I'll make a Delphi port of this version. I found some correspondence regarding the program which stated that, as I had suspected, the program began on the PDP which had fixed length strings.

But wait! There's more: further looking through this file found various attempts at Prolog-like interpreters and query systems, all of which are less important to me today than what they were. YAPI (Yet Another Prolog Interpreter) was very interesting: I had almost all of the parts assembled including the recursive query solver and resolution (matching) although the unification part wasn't quite right. But the program was still missing the final key, which would allow the use of variables in rules.

I found  the complete documentation to an expert system called ESIE, which contained a knowledge base called 'animals' which looked extremely familiar. I obviously used this as the demonstration database for the Amateur Reasoner, although my program used a slightly different syntax, viz

(ESIE) goal is type.animal

legalanswers are yes no *

if backbone is yes then superphylum is backbone

if backbone is no then superphylum is jellyback

question backbone is "Does your animal have a backbone"?

(AR) goal (animal)

if backbone= yes then superphylum = backbone

if backbone = no then superphylum = jellyback

prompt (backbone) = Does your animal have a backbone?

Earlier versions of the AR required the 'legalvalues' (aka legalanswers) keyword, which later turned into 'values' which later became unnecessary as I realised that this information was redundant.

Right at the end of the file, I find a photocopy of an article which appeared in the April 1985 edition of BYTE magazine entitled "Inside an expert system: from index cards to Pascal program" written by Beverly A. Thompson and William A. Thompson - yes, the same authors who wrote the 'Very Tiny Prolog'! This article was accompanied by source code which I must have obtained from the magazine; I also found my port to PDP Pascal. Looking back on things now, this article must have made a very strong impression on me, although the Prolog interpreter would have made an even stronger impression, had I known about it at the time.

And as for the Prolog interpreter, whilst I couldn't find online the original articles referenced by the program, I was able to find the email of Bill Thompson. I wrote to him, saying how pleased I was to find this program, even if it was 25 years after the event (!) and asking whether he could send me an offprint of the two articles. Lo and behold, yesterday I received a reply, including an url where I could download them (thank you!). The first article was more or less an introduction to Prolog, including vague hints about how the language might be implemented in Pascal. This was the kind of material which I had read previously which had left me to fill in the blanks. The second article, though, was the real thing: explanations on how to implement Prolog. Linked lists, parser, solving queries by solving the head and then attaching the rest of the rule to the end of the queue of clauses to be solved, etc. The program also showed the missing link: how to handle variables in rules.

This key sentence actually appears in the first article, when Mr Thompson is writing about solving rules by making copies of them: The copy will be exactly the same as the original rule in the data base but all variables in the rule will be tagged by appending the recursion level to them. Maybe this sentence doesn't make too much sense on its own, but in the context of the article, it is gold.

Apart from the intrinsic values of these programs, it also gives me a clue what I was programming at the turn of the 90s. We moved from one kibbutz to another in September 1989, which is when I started working in the furniture factory. Shortly after, I began rewriting an application which someone had developed there which dealt with an online data collection system from the factory floor. This involved many new ideas and techniques with which I had not dealt before. None of that code survives.

At the time, I was coming to grips with Turbo Pascal 5.5, with its object orientated extensions, and then Turbo Pascal 6 with Turbo Vision - an almost fully fledged GUI for DOS. This latter system was incredibly difficult to grasp, not least for want of proper documentation and example programs, but mastering it made the transition to Windows very easy.

I remember writing a series of quasi database programs, in which the data was stored in a collection; at the beginning of the program, the data would be read via a stream into the collection, and at the end of the program the data would be written via a stream to disk. During the program's invocation, all the data was held in memory, which made accessing it very fast, although a program crash would lose all changes. I remember being very excited about Turbo (or was it Borland?) Pascal 7, which came with a memory manager which allowed DOS programs to use much more memory than before; such a database program could now hold 700+ records whereas previously it could only hold about 250.

Such concepts seem terribly quaint now.

Beef ratatouie

Blogging frequently means that I have too much time on my hands. At home, I'm "on holiday" from my MBA studies and so have at least ten hours free time a week (which I seem to be spending on watching 'Star Trek: The Next Generation' - we're now near the end of the second season), and at work the second half of a month always seems to carry a lighter load than the first half.

Here's a recipe for a dish which I've been cooking very successfully over the past few months. It's another recipe with a good "value for time invested" ratio; there's no beating roast chicken, but this one comes close. Let us say that the value of a roast chicken meal is 10; it takes me maybe fifteen minutes to prepare it, so the ratio would be 0.67 taste units per minute. Fancy cooking leaves me cold and takes a long time so such a ratio would be around 0.1. This casserole dish has a ratio of about 0.4.

Take a large casserole dish suitable for cooking over a flame and heat in it some oil. Dice a large onion and then fry it in the dish until it browns (but not caramelises). Add 500g minced beef; mix, fry and try to make the pieces of fried beef which inevitably result as small as possible. Once all the meat has a grey tinge, add vegetables which have previously been cut into cubes - potatoes, carrots, courgettes. The original recipe calls for a tin of baked beans to be added, but I've been using haricot beans and this variation improves the result. Add tomato paste and enough water to almost cover everything. Stir and heat until boiling, then reduce the heat and cover the dish. Leave to cook for two hours. Turn off the gas/electricity but leave the dish covered. Warm to serve.

Last Saturday I started cooking at around 8:30 by cubing the vegetables; by 9am the casserole dish was covered. I continued heating till about 11am, then turned off the gas. A quick reheat at 12am and then the food was ready.

Porting the Amateur Reasoner

I ported my Amateur Reasoner program, which I mentioned in my previous blog, to Delphi. Apart from a few specific points, this was a fairly simple process, and now that all the display code has been stripped from the program, it's much easier to understand the program source.

Before going any further, I should describe the program and what it does. First, I'll quote a very simple database which is dated 10 Feb 1989:

goal (rate)

if day = saturday then rate = cheap.
if hour = before_8:30 then rate = cheap.
if hour = after_21:00 then rate = cheap.
if day = sun_to_thurs & hour = 8:30_thru_13:00 then rate = expensive.
if day = sun_to_thurs & hour = 13:00_thru_21:00 then rate = middle.
if day = friday & hour = 8:30_thru_13:00 then rate = expensive.
if day = friday & hour = 13:00_thru_21:00 then rate = cheap.

prompt (day) = On which day was the call made?
prompt (hour) = At which hour was the call made?

The goal of the program is to 'calculate' or infer what the rate should be made for a telephone call according to its rules. In order to solve the goal, the program looks at the various rules which define the rate (this program is exceedingly simple, because it has a 'depth' of 1 - all rules directly refer to 'rate'). In order to infer what the rate is, the program has to determine on which day and at which hour the call was made - these are the prompts.

The first design change was to use variable length strings as opposed to fixed length strings. The only reason that I can think of why the original program used fixed length strings if it compiled with Turbo Pascal 5 is that the program must have originated on the PDP, whose Pascal had fixed length strings. Using variable length strings had slightly more consequences than I had considered: the program's parser, in common with all other programming language parsers, has to tokenise the input file, ie split the text into words and punctuation. The tokenisation process changed slightly after I redefined what a token was; this may or may not have been the cause of a bug which I found in the tokeniser procedure, which affected the parsing of a punctuation symbol at the end of a valid token.

In order to save memory, all the tokens were stored in a hash table and the data structures used the hash numbers instead of the actual tokens. The program had used a simple hash function which depended on the first three characters of the token, which is possible if the token has a fixed length but would return variable results if the token had less than three characters. As one keyword is 'if', it was clear that the hash function had to be replaced. Fortunately I discovered that Delphi has a THashedStringList class which solved all of my hashing problems in one go, so I immediately adopted this class.

I tested the parser initially on a 'database' called 'Actuary', which consisted of several rules and questions which would determine a person's life expectancy. The parser always choked on this file and I discovered eventually that it was using a keyword undefined in the parser. I then checked this database on the original program which also got stuck, so I realised that this extra keyword was in fact superfluous. When I removed all the offending statements, I ran the database through the program which worked fine. After thinking about it (and checking the dates on the files), I realised that this database had been intended for an earlier version of the Reasoner, and that later versions were able to establish for themselves the values needed (using the above example, the program is able to establish that valid values for 'day' are saturday, sun_to_thurs and friday).

The only other part of the program which gave me a few problems was where the program had to get input from the user - to establish what the values of 'day' and 'hour' should be. This is the part of the original program which was chock full of display code trying to emulate a GUI in a text only environment. Of course, all this code was irrelevant, but I had to be careful that I didn't 'throw the baby out with the bathwater'. As it happens, I did throw out a little too much code.... The part which determined which tokens to display on the screen (saturday, sun_to_thurs and friday) was straightforward, but what I missed the first time round was the value which would be returned after one of the tokens was chosen. I had passed the values to a radiobox and originally returned the index of the chosen token, which in this case would be 0, 1 or 2. No! The value to be returned should be the hash value of the chosen token. Whilst it occurs to me now that I could have recalculated the hash value, I already knew the hash value of each token as I accessed it when populating the radio group. Here is the Delphi screen

I remembered the little code trick which I presented in a column a few days ago about storing an integer along with a string value in a combobox. Here I used it with a radiogroup -

 ques:= curobj^.legal;   // this is a pointer to the list of values
 while ques <> nil do
  begin
   rg.Items.AddObject (hashstrings[ques^.n], TObject (ques^.n));
   ques:= ques^.next
  end;

 if showmodal = mrOK
  then with rg do
   result:= longint (items.Objects[itemindex]);

One neat thing which I added to the dialog box was the ability to see the program's reasoning. This existed in the original program too, so I wasn't inventing anything, but when I initially planned how to display this dialog, I thought that pressing on the 'do you want to see my reasoning' button would have brought up another dialog. In the end, I decided to extend the current dialog box downwards in order to reveal another memobox. Below is the screenshot of the same dialog box after the user has clicked on the 'do you want to see' button.

Now that I have the program and got it running with Delphi, what am I going to do with it? Probably nothing. The Amateur Reasoner was like Prolog without the variables, mainly because I couldn't figure out then how to implement the variables and attach values during a recursive process. I also note that in the 'flagship program of the Occupational Therapist', I did something similar, using rules stored in an sql database.

It's the 80s all over again

In the 1980s I was very interested in programming languages and artificial intelligence. I had begun programming on a PDP/11 which was situated about 20 km from where I lived at the time; we had a telephone line connecting the computer to a keyboard/printer, and when I wasn't accounting, I was programming. In 1986, if I remember correctly, I was one of the first people I knew to have a PC at home - some kind of IBM clone. This was to be the first of many computers that I would own. I programmed in Turbo Pascal although I as I say, I was interested in other languages and had several programming language diskettes.

It was the August 1985 edition of Byte magazine that captured my attention; this had a picture of a robot arm emerging from an egg on the cover. I began a subscription to the magazine and shortly learned about a fascinating language called Prolog. I bought a book about the language and had to suffice with this as I had no implementation. At the same time, Byte was running a series of articles by someone called Jonathan Amsterdam (again, if I remember correctly) who was writing about implementing a Modula-2 like language.

At the time I didn't know enough to know better and so I thought that I would be able to use some of Amsterdam's code and write an interpreter for Prolog, as the book I had made it seem simple. Little did I know. I never did succeed in writing a real pico-Prolog at the time, although in the early 2000s I found the source code to a pico-Prolog and finally implemented it in Delphi.

I did try my hand, though, at writing other kinds of inference engines and completed something called 'The Amateur Reasoner', which was distributed via a shareware library with whom I had contacts at the time. Someone in America sent me his knowledge base for determining which catalyst to use in which petroleum refining process, and I incorporated it along with the several other knowledge bases that I had cobbled together.

This program might well have been inspired by a book which I owned called 'Writing Expert Systems in Pascal" - or maybe it was in Basic. Another source of inspiration would have been an article in Byte called "Inside an expert system: from index cards to PASCAL program", about which I had completely forgotten until today.

In the last few months, the itch of trying to implement Lisp in Pascal has re-awakened in me; unfortunately I have the time, but I don't know what I intend to do with this even if I do succeed. As a way of relieving the itch, I often scan the Internet looking for suitable programs. Today I persevered more than I normally do and eventually stumbled upon a treasure trove. I immediately went to the AI languages section and found several interesting programs, including the source to a "very tiny Prolog" implementation in Pascal, written by Bill and Bev Thompson. They were the authors of the "Inside an expert system" article to which I referred in the previous paragraph.

The source code states that there was a pair of articles in "AI Expert" magazine which presumably explained how the program worked, but so far I have been unable to locate those magazines which were published 25 years ago. Whilst looking through the treasure trove site, in an attempt to see whether maybe the articles were there in another guise, I came across a program which seemed terribly familiar - yes, it was my Amateur Reasoner program!

I had to download this, primarily to see whether there was anything cringe-worthy there. Apart from a regrettable tendency to mix display code (including inline assembly and a few BIOS tricks) along with the inference engine code, it's actually not bad at all. The code is full of linked lists, which is what we had in the mid-80s, in the absence of anything of a higher order. I don't know whether I would re-implement this today with a series of types based on TObject and put them in lists or rather keep the low level code.

It's fascinating reading the code. I see how I kept the syntax as simple as possible so that I wouldn't need to include a recursive descent parser. I probably knew about such things then but did not necessarily understand them, which is one reason why my Prolog interpreter never got very far.

I accidentally double clicked on the executable file and I'm pleased to note that the program works fine in a DOS box under Windows. Maybe I should re-implement it in Delphi - only 21 years after it was originally written.

Alarm clock mp3 player

About 15 years ago I bought an alarm clock/radio/cd player combination. The idea was that the alarm would wake one with the soothing sound of a cd, and the combo worked very well for several years. Once I even had the machine repaired, replacing the cd drive. But after a few years, the cd drive stopped working again, and the radio never worked very well, so since then it's been on my bedside table, serving as a clock. My wife's mobile phone wakes us every morning.

Looking at the limited room on the surface of the table the other day, I realised that it was time to get rid of this combo: the space it was occupying was far out of proportion to its utility. Then it came to me in a flash: I need an alarm clock which doubles as an mp3 player. Instead of an alarm going off, the clock starts playing music. I looked and I looked, but couldn't find anything aside from two clocks which I found on Amazon: they appeared to fill my needs perfectly, but received terrible reviews - basically, they don't work.

How difficult can it be to build such a machine? Surely there must be a demand for such a gadget. So this is the first serious idea which I've ever had for a start-up company: making alarm clock mp3 players. The time was ripe for doing so ten years ago, so the technology required is hardly cutting edge.

In the mean time, I've settled on a traveler's alarm clock, which might not have mp3 capability but doesn't take up much room.

The in-basket 3 (whole lotta programming)

Another Friday has come and gone, meaning that I'd had another session with the OP regarding the Inbasket exam. I wrote to her during the week saying that the exam was about 80% finished and was in a testable state. Even so, our meeting resulted in requests for several changes: some of these were minor and some were a bit more than minor, but I've finished them all.

We decided that instant messages (IMs) have to be handled "immediately". This means in programming terms that the IMs have to be displayed in a modal dialog box; all the other forms appearing on the screen are non-modal. This wasn't a problem and the program ran fine after the change. I wanted to see what would happen when the clock runs out and there is a modal dialog box still displayed on the screen; the program terminated but a peculiar error message appeared about a query. It took me a while to figure out where this was coming from.

Every second there is a "timer interrupt"; this increments the seconds count and decrements the 'seconds left till the end of the exam' count. Should the seconds count be evenly divisible by 60, then a minute has passed; at this stage, the program checks to see whether there are any emails to be displayed and whether there are any IMs to be displayed. It so happens that my test exam has two IMs; when checking to see what would happen if the user does not handle the IM, I let my program run idly. The first IM popped up on time, the second didn't and when the program finished (the test exam runs only for five minutes - it saves time), there was the error message. Eventually the penny dropped: when the timer interrupt occurred and a minute had passed, then the program tried to display a modal dialog. But if there were a modal dialog already being displayed, there would be a problem as there can't be two simultaneously active modal dialogs in the same program. It became clear that all I needed was a boolean variable to guard the modal part of the timer loop; when the modal dialog begins to execute, the variable is set to true and when the dialog finishes, the variable is set to false. The program checks this guard variable before executing the modal dialog, and of course if the variable is true then the modal dialog is skipped. Now that I think of it, if a modal dialog is skipped, then it will never appear because its time will have passed. Hmmmm.

Once this problem was fixed, I told the OP that she could now test the program. Of course,  she runs 'her' exam and discovers a bug - an IM isn't appearing. I run 'my' exam and the IMs do appear. I check the query which pulls the IM out of the database in order to be displayed on the screen - perfectly fine. In the real exam, the IM appears after five minutes, which I spent idly fiddling about, only to discover that it wasn't appearing. I decided to save my time and so changed the IM's entrance time to one minute; lo and behold, the IM appears. At this stage, the problem became clear: as it happens, in the 'real' exam there is an IM and an ordinary message which are programmed to appear after five minutes. The code necessary to retrieve the ordinary message and display it was taking more than a second, so the IM code (which I thought I had fixed as described in the previous paragraph) wasn't executing. All that was needed was to turn off the timer before displaying the email and turning it on again immediately afterwards.

Both these problems remind me of programming TSRs in the long-forgotten DOS age. A better solution that my ad hoc fixes would be to use two different timers; one measures seconds and will be responsible for updating the 'time left' display whereas the other measures minutes and will be responsible for displaying messages. This will obviate the need for turning the timer off and on. I still have to figure out what to do if a user takes a long time to handle an IM and in the mean time a new IM is supposed to appear. Presumably I will have to store each undisplayed IM's id number in a queue and handle that queue.

I'm sure that this is much more complicated than the OP imagined and maybe it won't be necessary as the user will be interested in handling the IMs instead of ignoring them, because otherwise she won't be able to complete the exam.

I have to note the fact that writing this exam has certainly varied my programming diet and made me face challenges which either I have never faced before or haven't faced for a long time. This is what makes programming so much fun. I mean, when was the last time that  I had to use a queue in a program?

I want to pass on one little tip. In my programs, I often load a listbox with values taken from a database table (let's say the name field) whilst simultaneously storing the value's id field. This can be done as follows:

 with qQuery do

  begin

   open;

   while not eof do

    begin

     n:= lb.items.add (fieldbyname ('name').asstring);

     sendmessage (lb.handle, lb_setitemdata, n, fieldbyname ('id').asinteger);

     next

    end;

   close;

  end;

The id number is then retrieved thus:

 id:= sendmessage (lb.handle, lb_getitemdata, lb.itemindex, 0);

The key to this code is using the pair of Windows message, lb_setitemdata and lb_getitemdata. Despite the similarities between a listbox and a combobox, it transpires that there are no equivalent messages (like cb_setitemdata). So what's a jobbing programmer to do? Until recently I was forced to issue a database query in order to retrieve an id for a given name, but now I've found a much better solution:

comboxbox.items.clear;

 with qQuery do

  begin

   open;

   while not eof do

    begin

     combobox.items.AddObject (fieldbyname ('name').asstring,

                                                       tobject (fieldbyname ('id').asinteger);

     next

   end;

  close

end;

Accessing the id now becomes

with combobox do id:= longint (Items.Objects[Items.IndexOf(text)]);

I think that it should be possible to replace the 'indexof (text)' with 'itemindex'. The 'AddObject' method allows one to attach an object to each element in the 'items' array; a long integer takes up the same amount of storage as an object, so it can be stored by casting the integer as an object, and retrieved by casting the object as a longint.