All quiet on the blogging front

After the extreme excitement of the last blog, things have quietened down somewhat. 

On Saturday, I continued reading 'Information Technology for Manufacturing' (ITM) only to discover that the remaining chapters weren't quite so pertinent to my needs as the opening three. I only leafed through the book, but it was clear that the subjects chosen weren't what I needed to read. I'm not saying goodbye to my 'new friend', but it's clear that our friendship won't be quite as close as I had originally imagined.

As I wrote last week, "We have the woodwork factory whose production time is measured in days, where it's hard to assign specific tasks to specify people and where it seems that the methods of following production were designed by someone divorced from the way the factory works (or more correctly, divorced from the way the factory works now). As a result, the plant manager has to resort to maintaining an Excel spreadsheet which keeps all the data which are relevant to him."

I  figured out how I could extend our ERP program to maintain some of the data which he keeps in the spreadsheet; the whole idea of time slices suddenly became much easier and simpler. I wrote with some excitement to the woodwork factory manager on Sunday explaining my solution but he was unable to grasp what I was suggesting. So yesterday, I hauled myself up to the north of Israel and sat with him for a few hours. 

I didn't make the sale. My solution was for only part of what his Excel spreadsheet contains; the spreadsheet is heterogenous in that it contains data both about orders and batches (one batch contains one or more orders), and in Priority it is difficult if not impossible to produce heterogenous reports. I suggested a few alternatives, but these require an order to be linked to a batch as soon as possible and for reasons which I don't comprehend, they attach an order to a batch as late as possible.

As I say, I didn't make the sale. We agreed to part as friends.

Another, more promising area for exploration is external optimisation: ERP's work order says to use a certain amount of raw material, but via the use of an external optimiser, the workers are able to produce the same amount of finished product with less than the dictated amount of raw material. This causes problems with stock keeping and creates what Priority calls 'unflushed inventory' (I haven't managed to find any references to this on the Internet). This is definitely an ERP failure and definitely something which I intend to investigate, and hopefully solve. The problem exists (one way or another) in three out of the four business units in my company, so there should be plenty of examples.

It occurs to me that it might be a good idea to try and contact a company who has implemented Priority abroad; I won't be perceived as a competitor, and I can learn what the various terms are called in English.

New friend

It seems that I have a new friend in my life: a hardbound book called 'Information Technology for Manufacturing' by Kevin Ake, John Clemons and Mark Cubine. If indeed it is available for $39.39 from American Amazon then go for it, because I paid nearly the same price in British pounds (from the Book Depository). I am going to call this book 'ITM' and create a tag for it so that in the future it will be easy to find references to this book in the blog.

I've only read the first three chapters of ITM but it seems to be an ideal source of information and ideas on how to improve the use of one's ERP system (the subtitle of the book is 'reducing costs and expanding possibilities').

I bought the book because I am seriously considering studying for a doctorate degree in business administration (DBA) when I finish my MBA degree, and it's good to start as soon as possible in finding ideas which need to be solved. As opposed to the MBA, in which students are taught the material, the DBA allows the student to display his prior knowledge whilst making a contribution of his own to the literature.

At the moment, it looks like my topic will be addressing the failures of 'standard' ERP and showing how these failures can be ameliorated by the use of 'extended' ERP. It occurs to me that I would not be able to do so had not Priority, the ERP system with which I work, not been extensible (it allows the user to define his own tables, data entry screens and reports).

My aim at the moment is two-fold: to identify such areas (I've already noted two) and to show how it is possible to handle them.

Why do I write that this book is my new friend? Because it looks like ITM will be accompanying me intimately for a long trip into the future. Because I woke up this morning at 4:30am with an idea which came from the intellectual stimulation caused by my new friend!

As is expounded in the first three chapters of ITM, 'standard' ERP was developed for the corporate staff; it handles accountancy, purchasing, sales, manpower, etc very well, but does not have the level of support necessary for the data collected at the plant level. That's not to say that there is no such support, but rather the existing support is designed and implemented from the corporate point of view (an interesting example of bias).

I woke up so early this morning with an idea which can be summed up in two words: time slices.  ERP offers no standard method of storing time slice data. Whilst writing those words, it occurs to me that in the chair factory, we know every day the status of each order: how many of the chairs in each order have been produced and by whom, by virtue of the fact that the manager of the production line sits down at the end of the day and enters this data into the standard program.

But chairs are discrete objects whose production time is measured in minutes. On the other hand, we have the woodwork factory whose production time is measured in days, where it's hard to assign specific tasks to specify people and where it seems that the methods of following production were designed by someone divorced from the way the factory works (or more correctly, divorced from the way the factory works now). As a result, the plant manager has to resort to maintaining an Excel spreadsheet which keeps all the data which are relevant to him.

The very word 'Excel' acts as a springboard: as I have written before, 'whenever I hear the word Excel, I reach for my gun'. Here, the word Excel means that there is a lacuna in ERP which cannot be solved by traditional methods but can be solved by 'extended' ERP (enter cartoon character ERPman stage left). What we need to do is to convert this spreadsheet into a 'time slice' data table which then can be analysed using all the strong methods and advantages of the SQL database.

The plant manager sent me a copy of his spreadsheet a few months ago but I returned it, saying that there was no way to maintain that kind of data in Priority. That's a true statement if one is working in the blinkered standard ERP but not true when one enters the brave new world of extended ERP. On Sunday morning I shall dig out that spreadsheet and start examining how I can transfer it: what data fields are needed, which will come automatically from the database and which will be entered manually, how to present a suitable input screen to the user, etc.

The ideas are running around my head - which is why I woke up at 4:30am. There's no point in going back to bed as it is now 5:30am which is when I would have woken up anyway.

Size matters

Once upon a time (in fact, until about three months ago), the computer monitors on which my programs run were all the same size. This made it very easy for me when designing screens/forms for my programs: if they looked ok on my monitor, then they would be ok on my client's monitors.

With the advent (and purchase) of different sized monitors with different display ratios and resolutions, this state of affairs is now in the past. The client (OP) has a monitor which is capable of displaying many more pixels than my monitor displays, and she wants to make use of that extra space. So I had to start learning about resizeable forms. As it happens, these work in synergy with MDI child forms - but not with dialog boxes - and a few of my recent programs follow the MDI model, so the possibility of conversion to resizeable forms definitely exists.

The starting point of this discussion will be a simple MDI child form with a database grid and a panel hosting a few buttons. Something like this:

My first attempts at creating a resizeable form included the following steps:

1. Change the form's border style from 'bsSingle' to 'bsSizeable'
2. Add a status bar at the bottom of the form in order to show the 'stretchable' bitmap hint

Whilst the form could be resized, the individual components of the form stayed where they were. The next stage in the learning process was the anchor: both the grid and the panel have their anchors set to akLeft and akTop, or in English, the left and top coordinates remain at a fixed offset from the form's top and left. As resizing is generally to the bottom and to the right, the result is that the components don't resize. The key to this conundrum was to set the akBottom anchor property to true - the bottom of the component will be at a fixed offset from the form's bottom. If the form's height increases, the height of the components will increase as well.

Whilst all was good at the design stage, running the program produced different results when resizing the form, specifically regarding the width of the form. A MDI child form whose border style was 'bsSizeable' was displaying at a different width than the form's defined width and this was annoying. I programmed a work around by forcing the form to be a specific width in the FormShow and FormResize methods, but it was clear that this wasn't the solution.

Looking around on the internet, I came across the SizeGrip component; I think that this component originated here, although I actually found it on a different blog which quoted the original word for word without attribution (very bad practice). The sizegrip component allows a form to be resizeable without the need of a statusbar; for reasons which I don't understand, the form's border style can remain bsSingle yet still resize, thus solving the display width problem.

Along with anchors, one is supposed to use the constraints property which define the minimum size for the form. Once I had allowed a form to resize, it seemed only polite to store the resized height in the registry so that the form could be displayed at the same height the next time it was invoked. As a result, I started adding the following code to units

procedure TDoTables.FormCreate(Sender: TObject);
const
 mywidth = 416;
 myheight = 496;

begin
 height:= reg.ReadInteger (progname, 'dotables', myheight);
 constraints.MinWidth:= mywidth;
 constraints.MinHeight:= myheight;
end;

procedure TDoTables.FormClose(Sender: TObject;
  var Action: TCloseAction);
begin
 reg.WriteInteger (progname, 'dotables', height);
 action:= caFree;
 TrimMemory
end;

'DoTables' is the name of the form; the registry stores the height of each individual form.The 'myheight' and 'mywidth' constants were defined in the design stage - what looks good on my monitor.

But: there is still room for improvement. If I set the grid and panel's anchor.akBottom propery to true and enlarge the form, the form looks as follows

Whilst the panel has resized, the buttons have remained in the same position. Obviously the top button should remain in the same position, but the second and third buttons' position should change. The bottom button's top property can easily be calculated as it will be the panel's new height less the height of the button less 8 (the offset from the bottom of the panel), but what about the middle button? And what happens if there are four buttons on the panel? Basically, what is needed is the equivalent of the alignment palette's space equally vertically command. As I don't know how to access this at runtime, I have to mimic its action.

After a bit of muddling around, I found the following method which sits in the form's FormResize method. First of all, calculate the increment to the panel's height (the original design time height is stored as a constant), then divide this height by the number of buttons less one. The second button's top has to increase by this calculated increment, and the third button's top has to increase by this calculated increment times two. Translated into code, it looks like this:

procedure TDoTables.FormResize(Sender: TObject);
const
 ph = 441;

var
 incr: word;

begin
 closebtn.top:= panel1.Height - closebtn.Height - 8;
 incr:= panel1.height - ph;
 if rankbtn.Visible then  // five buttons on screen
  begin
   incr:= incr div 4;
   editbtn.Top:= 106 + incr;
   contactsbtn.top:= 204 + incr * 2;
   rankbtn.top:= 302 + incr * 3
  end
 else
  begin
   incr:= incr div 3;
   editbtn.Top:= 138 + incr;
   contactsbtn.top:= 269 + incr * 2;
  end;
end;

The above is probably more complicated than need be, but I thought I'd quote the form's code ad verbatim. The complication is caused by the fact that sometimes the form displays five buttons (rankbtn will be visible) and sometimes only four buttons (no rankbtn). Editbtn is the second button on the panel and contactsbtn the third; Closebtn is always the final button on the panel so its top can be calculated without knowing the increment in panel height. The magic numbers in the code (106, 204, 302, 138, 269) are the buttons' tops at design time.

I'm going to let this code sit for a while (like good wine); maybe there is room for further improvement.

The gumption trap

Thomas Edison famously remarked that "invention is 1% inspiration and 99% perspiration". Unfortunately, it's the same regarding debugging.

I bought a wide LED screen for the children's computer and on Sunday connected it up. The screen didn't work. After eventually finding the power switch and turning the screen on, it still didn't work. As it was fairly late and I was very tired, I decided not to continue but to leave the problem for another day.

On Monday evening, I started again with the screen and verified that it wasn't displaying a picture. I then disconnected it from the children's computer and connected it to mine - voila! There is  a picture on screen, so we know that there is not a problem with the screen itself. I moved the screen back to the other computer - no picture. I connected my screen to their computer - no picture. I even swapped the video cable; the new screen's video cable worked fine on my computer whereas my video cable didn't work on their computer.

At this point I did the sensible thing and took the dog for a walk. Getting out of the house - or more importantly, getting away from the problem - helps me see more clearly and theorise what to do. Obviously it's a problem with the computer's video card.

When I got back (and after eating something: food also helps the brain), I opened up the computer and verified that the screen card was sitting properly in its slot. I also managed to cut my thumb on the sharp edges of metal which have been cut to allow a fan to sit on the video card. I connected the video cable to the video card, connected the electricity - and saw a picture on the screen. I then disconnected the electricity and video cables, connected a disconnected wall fan inside the computer, put the side of the computer case back on, connected everything up - and no picture appears on the screen.

The wall fan was making a large amount of noise so I disconnected the computer again, opened it up, disconnected the wall fan - and then I had the epiphany which I should have had much earlier. I had been connecting the video cable to the onboard video connector instead of to the external video card! Once this was noted, I closed the computer up again, reconnected everything properly - including the video cable - and could begin working.

Well, not quite. There was an icon on the screen saying that the network card was disconnected. I checked the connections - wall first, computer second - before the inevitable epiphany occurred again: I had connected the network cable to the internal ethernet socket, which had been disabled, instead of to the external ethernet socket. Easily solved.

Conclusions:

1. Write on the computer case to use the external video and ethernet sockets in the future
2. Take the dog for a walk more frequently

This morning, whilst thinking over this affair, I remember "Zen and the art of motorcycle maintenance" which discusses what I would term 'debugging' and the importance of the 'gumption trap'. When debugging, one often gets into a mental state which leads in one direction whilst ignoring other directions (one of which will be the correct direction). Thus one wastes a great deal of time whilst increasing one's frustration as one goes in the wrong direction.

I am about to order a book which discusses this issue more thoroughly - "How we know what isn't so: fallibility of human reason in everyday life", by Thomas Gilovich. Ignore the price which is going to be displayed by the Amazon link: British Amazon is selling the book for 6.66 GBP but charging something like 8.25 GBP postage, whereas the Book Depository will sell me the book for 10.94 GBP including postage. Why pay 36% more?

Here's the blurb of the book: "When can we trust what we believe - that "teams and players have winning streaks", that "flattery works", or that "the more people who agree, the more likely they are to be right" - and when are such beliefs suspect? Thomas Gilovich offers a guide to the fallacy of the obvious in everyday life. Illustrating his points with examples, and supporting them with the latest research findings, he documents the cognitive, social and motivational processes that distort our thoughts, beliefs, judgements and decisions. In a rapidly changing world, the biases and stereotypes that help us process an overload of complex information inevitably distort what we would like to believe is reality. Awareness of our propensity to make these systematic errors, Gilovich argues, is the first step to more effective analysis and action." 

I look forward to reading this book. 

Frustration in the computer lab

The last two weeks have been very volatile: some good events have happened, countered by some not so good events. I think that things have evened out now, but all those ups and downs have left me very tired.

I choose to write about the problems we have had in updating computer services in the occupational psychologist's office. Until about a month ago, the setup was as follows:

1. a venerable NT server was hosting all data files (mainly word files and pdf), as well as hosting the Firebird server and its associated data files
2. Two "main user" computers for the OP and her secretary, which accessed the files on the server. These computers run XP.
3. Seven "examinee" computers which run the various computerised exams and store their results on the server; five of these computers run XP and one Windows 98.
4. One "helper" computer which runs a program every ten minutes during the day; this program reads the results of the computerised exams, inputs them into Firebird data tables and creates Word files containing the developed results of those exams. This computer runs XP.

Due to various problems (probably speed and clutter), it was decided to buy new computers to replace the two 'main user' computers; these naturally came with Windows 7. After playing with these computers for about two weeks, we discovered that they were having problems saving files on the NT server. So we decided to buy another Win7 machine which would replace the NT server: all it had to do was store files and run Firebird.

This is where the fun begins. It took several frustrating hours before I could even get Firebird (v1.5.5) to run on this new computer and to access the database files locally. I was totally unable to set up the other computers to access the databases, so we decided to scrub Win7 and install XP. Again, it took several hours, but eventually on Saturday night, I had Firebird running on this new computer and the Win7 computers could access the databases.

But the remaining XP computers couldn't access those databases! This means that the 'helper' computer was unable to do its work, and I was considering moving its functions to the new server computer so that it would update its databases locally. But in order to do that, it would need Office installed. Even though the Win7 machines were accessing the databases on Saturday night, they often complained of problems: one program would complain about not having access to temporary files being created on the new server, and another program displayed a timing problem. 

All day Sunday, the OP and her secretary were having problems with the databases. The files created by the people who were examined that day could not be entered into the databases because the helper computer couldn't help. So in the evening, we decided to put everything back almost the way it was. 

The only real difference is that the NT server no longer serves as a file repository - the new computer does this. It still hosts the Firebird server and all the database programs run properly. The helper computer now does its job.

All of the above has taken a large amount of time and frustration (see opening paragraph). As I often say, "computers were invented to teach us the value of patience", a deliberately ironic statement seeing as computers do routine tasks so fast that we (supposedly) don't have to wait.

I bought the NT server in 1998 if I remember correctly, and it's still going strong, which says something about the operating system. One day, though, it's going to stop working, and then we'll have to find a way of migrating the databases successfully to another computer.

Project management exam

Tonight we lit the eighth candle of Chanuka. The reason for lighting eight candles is that, according to the legend, there was only enough oil for a lamp in the Temple to stay alight for one day; despite this, the lamp stayed lit for eight days. This is called the miracle of Chanuka.

I had my own small Chanuka miracle today when the Project Management exam was not too hard. I'm not saying that it was easy, though; I finished the exam after two hours and 40 minutes, whereas previous exams have taken at the most two hours and 20 minutes.

I'm fairly confident that I did well on the exam (let's say 70%), although the more I think about the exam, the more I can think of things which I didn't answer well. The case study was about an oil exploration company, which is a lot simpler than some of the example case studies that I have seen. Drawing the organisational breakdown structure (OBS) wasn't too hard, although it may well be that I misunderstood one of the questions about the contracts involved.

As expected, question 2 was a critical path method question with crashing until a certain limit. This question held no problems for me, although there was a twist in one of the subquestions: after the project has been fully crashed, how can it be speeded up even more? I can think of two ways: compromising on quality (which means that each step won't take so long), and fast tracking, in which one activity is started before its predecessor has finished. I may write to the course designer to ask whether there are any other ways of speeding up the project.

The third question, as expected, was about EVA; this too held no problems but it involved a great deal of writing.

The fourth and final question was about risk. Fortunately I had been reading the course book chapter about risk in the morning, so most of the material was fresh in my mind. This question could have been about something else in which case I might not have been able to answer. To quote the opening sentence,

Explain the difference between risk and uncertainty

I'll leave with that sentence hanging in the air.

Rain

It is finally raining here. It is a great shame that this rain - for which we have waited for, longed for, prayed for - could not have fallen a week ago. Had it done so, then the forest on the Carmel mountain would have been wet, or at least hydrated, and so would not have gone up in flames the way that it did. The entire country mourns the trees.

My mind is trying to concentrate on the Project Management exam which will be held in another two days, but it's very difficult, for 

• My wife told me that there will be two funerals held on the kibbutz today  
• I have just discovered that the annual license for my motorbike expired two days ago
• I have been trying to install the Firebird server on a new computer running Windows 7 and am not succeeding
• I have just received the telephone bill for my trip abroad at the end of September and I have exceeded (by far) the amount that my company allows me each month

The icing on the cake is that I have an appointment for the dental hygienist in three hours time. At least the state of my teeth and gums is much improved from what it was a year or two ago.

When things are down, then everything is down. At least there will be an improvement by Thursday.

Chanuka through the years

Last night we lit the first Chanuka candle, so this seems like a good opportunity to exercise my memory by trying to remember Chanuka through the years.

I know that we lit Chanuka candles all the years when I was at school and I know that we never had a Christmas tree, but apart from that, my mind comes up as a complete blank for those years regarding the festival. As opposed to other festivals, not much happens except lighting the candles, eating doughnuts (sufganiyot) and saying certain prayers, so it's not unreasonable to assume that this is all that we did.

In 1973, I was in Israel during Chanuka, but again my mind is completely blank as to what happened then. Considering that this would have been one or two months after the end of the Yom Kippur war, the entire country would have been in a very sad state of mind, and celebrations were kept to a minimum.

My first specific memories about Chanuka would be from 1975. As I recall, that year I (along with others) 'performed' every night of the festival, singing the special festival songs and bringing cheer. One day would have been at the Friern Barnet Old Age Home (or something similar) where the local Habonim group sang for the residents. Another night, we were outside the Russian Embassy, singing the songs and protesting about the Russian government's emigration policy (as if we would have made a difference). Quite possibly we also appeared at other rallies during the week.

In 1976, I decided to start a tradition by inviting about twenty people to a party at the communal house where I lived and cooking for them. I remember cooking pineapple chicken (which was fine) and fried banana (which was ridiculously ambitious for me to cook for so many people). Apart from the cooking, I don't remember anything else, but we must have had a fine time.

I repeated the tradition the following year, although fewer people attended. I don't remember what I cooked but I do remember that I invited a girl from outside our circle to attend. I had met her at university; she was in the first year intake of my course whilst I was in the final year. She was Jewish and lived not too far away (in London terms - near Swiss Cottage, whereas I lived across the road from the Hendon Way). The following day I phoned her to ask how she was, and whether she had enjoyed herself the previous night; we proceeded to have a conversation for about twenty minutes with a much warmer tone that I had expected. I mentioned this to one of my fellow flatmates with a note of surprise; about five minutes afterwards, the girl phoned me - it turns out that she thought that I was someone else whom she knew better, hence the tone. Although we did hang out for a while, this relationship (if it might be called that) didn't go anywhere. [Mind you, I felt that year as if I was living on borrowed time as I knew that I would be emigrating in the summer of 1978. Typically, after a few years of drought, I met some nice Jewish girls that year but was unable to do very much in the romantic direction.]

In 1978, I was living permanently in Israel. I remember going to Tel Aviv one day before Chanuka and buying a chanukia - my first and only. I doubt very much that buying the chanukia was the reason for my trip but nothing else comes to mind. That year, a few of my fellow immigrants and I performed for the kibbutz, singing some chanuka songs in two, three and even four part harmonies which I had arranged. Every now and then, I pull out my recording of that event and marvel at our ability - and again at my ambition for such vocal writing.

The next few years are again a blank, although I can almost picture them. The kibbutz would have held a Chanuka party at which I probably would have performed, but towards the end of the period of my first kibbutz, these affairs almost certainly would have become chillier and less enjoyable.

In 1989, we moved to a different kibbutz. The Chanuka party that year was one of the most enjoyable in my life, and I remember being moved to tears. This was the kind of party of which I had dreamed when I was still in the youth movement, and finally it was happening in front of my eyes. Many people participated in the music (including myself), every family brought their chanukia, and basically it was the Chanuka party to end all Chanuka parties.

The same pattern continued for the next few years, although naturally my enjoyment decreased. There were also Chanuka parties held in the kindergarten in which our children participated; one year I was asked to say the blessings for lighting the candles and to my eternal embarrassment I became confused in the middle and forgot the words.

Once the children entered school, our active participation decreased and decreased. One year I remember well, for the music was provided by the local school big band and my daughter appeared in a dance troupe. The dancing was fine but the writing was on the wall: we don't need you to play the guitar any more.

Since then, I don't think that we've been to a kibbutz Chanuka party. Should my children get married, have children and still live on the kibbutz, then we will attend again, but that's not going to be for some time - and who says that the parties will be in the same format?

So here we are, alone -
our children have grown up and moved away.
living their own lives, they say...
it all seems very strange to me.
         
I don't understand their ways:
our children amaze me all the time
and I often wonder why they make me feel
so sad and suddenly old.
         
Now we're left with an empty home,
from our nest all the birds have flown for foreign skies.
We're discarded, of no further use,
though we gave our kids all our youth and all our lives -
we really tried.
         
Now there's only my wife and me;
we used to have a family - now that's gone
and only memories linger on...
it all seems very wrong to me.

(Peter Hammill, "Autumn") 

It's not quite as bad as that; whilst our children have their own rooms on the kibbutz, they visit us most days to eat, watch television, use the computers and get clean laundry. But last night our daughter was working off the kibbutz and our son was at the Kibbutz party with his friends - and my wife and I were alone. So we phoned our families and blessed them.