Thursday, July 20, 2017

Back to the beginning

After a long period of waiting, it has been decided by the powers that be that I have to be returned to the beginning of the DBA process. Obviously I don't have to resit exams, but I do have to submit a research proposal, have it accepted, then submit an intermediate submission etc. I am not very happy about this although I can understand the reasons for this decision. 

As I've already done a fair amount of the work required for the intermediate submission in April, it wasn't too difficult to sit down for a few hours and take what is needed in order to create a research proposal. I went over it very closely a few times today, deleting material which is irrelevant and rearranging what is not. I imagine that I will be assigned a new mentor for the research proposal (my previous mentor is probably sick and tired of me) and then hopefully I can submit the proposal within a few weeks.

One used to be able to see when the research committee meetings are, but the university's website appears to have been redesigned and I can't find that information. It will be my luck to have the proposal in a form ready for submission only to discover that I have to wait another six weeks. Actually, that isn't very likely to happen as the mentor will tell me when the next committee will be.

Just to recap, here is the abstract. Existing literature shows that there are gaps between the standard functionality provided by Enterprise Resource Planning (ERP) systems and the specific functionality required by implementing organisations. These gaps, known as misfits, are closed by means of enhancements – changes enabled in the system beyond the initial implementation configuration. As business is dynamic, the longer a company is in the post-implementation phase, the greater the need for further enhancements which were not envisaged during the initial implementation. These enhancements can vary in complexity from innovative uses of existing functionality through to the addition of complete, bespoke, modules. Each enhancement should produce a benefit which can ultimately be translated into monetary savings. This research is aimed at Small/Medium Enterprises (SMEs) and is restricted to those using the Priority ERP system. This research utilises the case study approach, being based on interviews with managers and users from multiple companies.

Saturday, July 15, 2017

12 string guitar: the basics

In conversation with my family, I realised that they don't know what a 12 string guitar is and what makes it special. On this basis, I imagine that most of my readership doesn't know either, so I have decided to write a few words of explanation.

A regular six string guitar with standard tuning is tuned (from bottom to top) E - A - D - G - B - E. Apart from the G-B gap, all the strings are tuned in fourths. Questions have been asked on the Internet as to why the intervals are fourths, except for one; the explanation seems to be that this tuning was settled on after decades of trials, as it allows for the easy formation of chords. Tuning the top two strings a semitone higher (thus preserving intervals of fourths over the entire guitar) apparently makes for very difficult chord shapes. A bass guitar has only four strings: these are tuned as the same as the bottom four strings on a guitar but an octave lower.

Since the early 1960s, people have experimented with alternative tunings, such as 'DADGAD', dropped D and open G (Keith Richards). Robert Fripp developed a 'new standard tuning' which is fifths. Joni Mitchell rarely played in standard tuning (as a side effect of the polio from which she suffered as a child) and so developed special tunings: almost every one of her songs has a different tuning.

A mandolin has eight strings: two 'courses' of four strings, which are tuned (from bottom to top) G - D - A - E, which are intervals of fifths. Each string is doubled, which gives the mandolin its special sound; frequently the two strings for each note are slightly out of tune, which gives a chorus effect. One of the bazoukis which I was shown in Rodos has six strings, two courses of three, tuned A - D - A.

After that lengthy introduction, we can now turn to the twelve string guitar. Like the mandolin and the bazouki, this guitar has its strings doubled (that's why there are twelve strings and not six). But instead of tuning the strings in unison (mandolin and bazouki), the bottom four strings are tuned in octaves (the top two are in unison). This is what gives the twelve string its characteristic sound, and is why I wrote yesterday that I will have to learn how to play single note parts on the lower strings.

Where can the twelve string be heard? As a child of the 60s, I instinctively think of the "A Hard Day's Night" album, where George Harrison can be heard clearly playing a twelve string. The nascent Byrds saw the film and heard the music; they turned the twelve string into the dominant sound of their earlier songs. The first line up of Genesis used acoustic twelve strings. Apparently Tom Petty uses a twelve string guitar but I am not familiar with his work. Fairport used a twelve string occasionally, played by Simon Nicol: the opening riff on "Come all ye" and "Run, Johnny, Run" spring to mind.

Friday, July 14, 2017

The deed is done (12 string guitar)

The deed is done, the purchase has been made. After a few months of dreaming and a few weeks of planning, the stars aligned, allowing us to drive to the guitar shop near Modi'in (about half an hour away) and purchase the Fender CD-160SE 12-String V-2 which we saw at the end of May. 

As opposed to last time, I played the guitar for quite some time, and discovered that this guitar requires a different technique from what I am used to. Whilst the guitar is very comfortable, it's hard on the left hand, pressing on all the strings. My right hand technique also has to change: I would like to finger-pick, but that doesn't work too well; it's easier with a plectrum. The problem is to pick the first string of each pair, which is the octave string; this way, one achieves the characteristic sound of the 12 string. And finally: for solo note playing (lead guitar), it is better to concentrate on the lower four strings (which have the octaves) as opposed to the top two strings (which are in unison).

I have been reading and listening about the 12 string over the past few weeks, getting prepared - which is why the first thing that I played was the riff to the Byrds' version of 'Mr Tambourine Man'. Apparently McGuinn's 12-string was recorded with compression (there's also a story about Steven Still's guitar being compressed for the CS&N record) so I was interested in hearing what this actually sounds like. To be honest, there didn't seem to be much of a difference, except for a strange sounding attack, so I decided not to buy a compression pedal.

I took along my Dia violin bass as this requires repair work. The shop salesman (Adam) took the bass and played happily for several minutes: as opposed to my previous attempts, the electrics worked, although at the end we discovered that there is indeed a loose wire inside which causes the pickups to disconnect intermittently. Adam was very taken with the bass - especially the dampener - and said that he was prepared to buy it; my wife refused politely. As I may have written before, part of the binding is missing and so the back of the bass is separating from the body. Although I had been told that the shop takes repair work, it transpires that they handle only goods which have been purchased from the shop. I was given the address of a luthier in Tel Aviv; I will try and send him pictures via email or WhatsApp before going there, as it may well be that the cost of repair is more than the guitar is worth.

It turns out that the owner of the shop knew us: he spent time on our previous kibbutz in the mid-80s as part of his army service. He also knows the person who gave me the bass during that time. His knowing us (or having known us) may have suggested to him to discount the price - or throw in a freebee.

I took the opportunity to try out a few other, iconic, guitars which were in easy reach of where I was sitting. Behind me on a stand was a stratocaster (barely visible in the photograph on the right hand side); I found this quite difficult to play, although of course I am an acoustic guitarist who plays primarily rhythm. I also tried out the telecaster (just above my right elbow in the picture): I have always belittled this guitar, partially because of its look and partially because everyone seems to play it (in other words, non-professional reasons). When I picked it up, I was surprised at its light weight, and as opposed to the strat, it was very comfortable to play. I can now understand its ubiquity. 

I also picked up the Gibson SG (directly above my head in the picture) and showed it to my wife, asking if it looked familiar. She recognised that I have a copy of this guitar in the music room, and asked how it could be that guitar makers can produce a blatant copy of an expensive guitar. I don't know whether the penny has dropped about the bass guitar and Paul McCartney's iconic Hofner violin bass, but then, she isn't interested in guitars.

The bottom line of these last two paragraphs is that most electric guitars don't feel comfortable in my hands - although I wouldn't refuse the tele - and so I don't have any intentions of buying any more guitars. Just as well as there is no free wall space!

Thursday, July 13, 2017

Room hiring service design

Giving a small glance into one facet of the work which I perform, I was approached to design a database for a room hiring service, to be implemented in Priority. At first glance, this appears to be the same as a hotel management system: there are rooms which are booked from date until date, each room with its own price. This is fairly standard, although the date handling can be tricky. But what makes this system stand out is the fact that whilst some rooms are 'private', other rooms are 'communal' - a big room could hold fifty workstations, where someone can hire a workstation for a few days. Thus an order for such a workstation would leave the room 'vacant', and other people can hire a workstation in the same room for the same dates. A field will need to be added to the 'parts' table to represent this (1 would indicate 'private', whereas any other value would indicate the number of workstations in the room).

Based on the constraint that the implementation will be in Priority (which simplifies certain things but forces one to work within the framework of Priority), my first decision is that 'each room is a part'. This allows us to use the standard 'orders' screen in Priority, along with the 'order items' screen. Let's see what functionality exists, what has to be added, and where there are problems.

Assuming that there is a part with catalogue number 'ROOM01', a customer can hire this room, stating the period during which the room is to be hired. The 'orderitems' table has a field called duedate, which can represent the date the room is to be vacated, but a field has to be added to represent the starting date (it's definitely not equal to the date the order is opened!). Checking whether the room is vacant during this period is not as easy as it sounds. One approach would be to check whether there exists a record in the orderitems table for this room which straddles the starting date - if there is such a record, then the room cannot be hired. If the starting date is free, then the vacating date has to be checked in the same manner. Unfortunately this check would ignore the possibility that the room has been ordered for a smaller period, falling between the start and end date of this request. I'll leave this aside for the moment.

The room has its default price, so the total price for this line would be this default price times the number of days, which would be 1 + (the leaving date less the arrival date). The number of days would be stored in the quantity field, allowing the total price to be calculated automatically. This last statement implies that the quantity field should be read-only, which is not the case of the standard order items screen.

Priority does not allow fields to be set as read-only at run time, dependent on other fields. While the status of this field could be set in advance, it will be problematic if the user wants to use this screen to insert customer orders for items which are not rooms. As this standard capability should be left as it is, I am tending to suggest that a customised order items screen be used for room ordering, which implies that the order should have a specific type: an error message will be displayed if the user tries to enter the standard order items screen when the order type is 'Rooms', and vice versa.

The owners want to have a daily price, a weekly price and a monthly price. Priority allows multiple prices for the same part, based on a minimum quantity, so three rows can be entered for each part, with prices for quantity 1 (e.g. $50), 8 ($45) and 29 ($40). The appropriate price will appear automatically in the order line dependent on the number of days. Whilst this seems very good, there are two overwhelming problems with it, one internal and one external. The external problem can be phrased as 'what about weekends?' - how many days is it if one orders a room for two weeks? Is this from Monday 17 July 2017 until Friday 28 July 2017? What about the weekend 22-23 July? Is a week seven days or five days? Maybe some people work on Saturdays but not on Sundays. I call this an external problem because its solution is not dependent on Priority per se, but rather a management issue. Weekends can be handled by a series of flags, which will reduce the number of days, but this is messy.

The internal problem is that all the above relates to a room as if it is a whole, and not a room with workstations which can be hired separately. This relates to the quantity: how would a order show that the customer wants to rent 2 workstations for 5 days? The first solution appears to be separating the number of days from the quantity: if the room is defined as 'single hire' (and this has to be added somehow to the parts table), then the quantity will be 1, whereas if the room is defined as 'multiple hire', then the quantity will be however many workstations are required. The mechanism which calculates the total price will have to be amended (it's good that a customised screen will be used!) to calculate 'number of workstations' times 'number of days' times 'default price'. Unfortunately, this means that the multiple prices entered into the price list will not work, as the quantity is the number of workstations and not days.

I think that it would be better not to use the standard price list mechanism, but instead use a discounting system, which would state provide a discount per number of hiring days, for example 5% discount for a minimum hire of 8 days and 10% for a minimum hire of 29 days. This system can be implemented at three different levels: on a global basis (all rooms have the same discount policy); on a 'room type' basis (all rooms of a given type have the same policy), or each room has its own policy. The discount - by whatever means it is calculated - would be inserted into the discount field of the order line. So now the total price for a given room would be: 'number of workstations' times 'number of days' times 'room price' times (100 less discount) times 0.01. Management will have to decide at which level the discounting system will work - probably all three!

Although theoretically a check should be made whilst booking a workstation that there is a free workstation within the room during the given period, I have been told to ignore this possibility. Management is happy to rent 120 workstations a day in a room which holds only 100 workstations. Fortunately, in the first paragraph of this blog, I mentioned the need to add a field to the 'parts' table which allows differentiation between 'single' and 'multiple' hires, so this field would be checked prior to the complicated vacancy check, which is to follow.

Here is the vacancy check problem: someone wants to book ROOM01 for the period 17 - 28 July (this room is a 'single' hire). As it happens, someone has already booked this room for the period 19 - 25 July. How does the program 'see' that the room is unavailable and that the request has to be denied? A naive way of doing this is as follows: after a room has been successfully booked, a series of entries is made into a 'booked room' table, where each row has a room and a date. Thus given the above, this table would have the following entries

Room numberDate
Room0119/07/17
Room0120/07/17
Room0121/07/17
Room0122/07/17
Room0123/07/17
Room0124/07/17
Room0125/07/17

The check would start from the day before the first required date (16 July) in a loop as follows (the flag has to be set initially to 'failure'):
  1. increment date
  2. if there is an entry for this date and room in the 'booked room' table, then go to label 99
  3. loop until the current date is the same as the vacating date (28 July)
  4. set flag to 'success'
  5. label 99
Whilst this solution would work, it requires inserting values into a table, which is going to grow indefinitely. This table is not really needed, as the dates already exist in the order items table, which looks as follows

Room numberFrom dateTill date
Room0119/07/1725/07/17

The only difference between the code needed for these data as opposed to the earlier data is the second step, which would have to check whether the current date is in any given range. There is no particular advantage in this checking code, but the requirement to build the 'booked room' table has been obviated: a very big saving!