Storing shift patterns

Maybe I have thinking about it all wrong, maybe the database should store all the shift patterns for a year (365(6) * 3). For each shift pattern it could store which drivers are on duty. This information could be search to build up a list of shifts the driver is working. This could also speed up the search for who is available within a particular shift.

Date: 23/04/2008
ShiftNumber: 3
CommaSeparatedListOfDrivers: 24,01,06,22,14,15

Something like that would probably work. Otherwise I guess each driver would need to hold this information separately.

...?

Back to the blog

I am still waiting to hear back from my tutor regarding my first TMA. I have used the time to reflect more on the structure of the program with the realisation that some parts are harder than I expected.

My biggest issue is with regards to the program checking if a booking can be entered or not. My solution involves dividing a day into 3 time slots which correspond to the drivers shift patterns, a driver can work zero, one or two shifts in a day in any combination.

Each shift is then divided into 5 minute slots. A booking needs to consist of a time and length. When a booking is made the program will check

1. Which drivers are working the shift the time slot falls into.
2. For each driver
3. Get the drivers last booking prior to this one, check the length of the booking.
4. Store the start time of this booking as firstSlot.
5. Store the start time of the drivers next available space postSlot.
6. If the driver has an unallocated slot or collection of slots of enough length from firstSlot to store this booking then enter add it to this drivers bookings and end.
7. If no spaces are found for this booking then return firstSlot and postSlot for the user to choose from.

My problem is that the drivers don't work regular hardcoded shift patterns, some shifts are regular and other like every fourth Sunday are irregular. How do I code this and store this information? I still haven't figured this out yet.

A driver may occasionally be away on holiday or for one shift. This can be stored as a list of dates/shifts and this will be checked first before assuming a driver is available for this shift.

On a different subject user logon.

1. The client application will prompt the user for a username and password.
2. This will be Base64 encoded for HTTP transmission to the server.
3. The server will check that the username and password are valid.
4. The server will then respond with the access permission for that client, or username/password wrong.
5. If the permissions are returned then the client will configure itself to the user. If not it will keep prompting for username and password.
6. Optional - the server could respond with a timeout, once this passes the client will log the user out.
7. If the client has successfully authenticated it will keep the username and password handy for future transmissions.
8. Optional - In real application transmission would need to be over https in order to protect the username password combination.

The drivers holiday could be lower priority to implement since the idea is a proof of concept.

Securing a REST application

Due to the fact that this is not an open API for an open web service I need to think about securing the URLs. Each user will have a different level of access, a booker shouldn't be able to delete drivers or account customers. This could be set with regard to the URLs a client application can send. However there is the risk that if the API is accessible over the Internet which it would be for account customers that someone could attempt to access private information. For example a URL of drivers/32 could return the full details of a driver, name address, phone numbers etc. Someone who could guess the URL could type it into a web browser and gain access to information that should not be shared.

This comes back to logging into the system, if a user is not logged in then the server should return a 401 status 'Unauthorized'. If a user is logged in but doesn't have the correct level of status, for example an account customer trying to delete a driver then they should get a 405 status 'Method Not Allowed' and then the list of methods applicable to them GET, HEAD should be returned.

Doh!

Having spent alot of time searching for libraries to help me and finding very little I have spent a fair amount of time writing a basic WebServer in C++ and wxWidgets. The classes I have developed are hopefully generic enough that I can build a REST server with them or in the future develop them into a more full featured web server. The Doh factor comes here.

Having got this far I found Project Zero . This is a very fully featured Java library which would enable building a REST server in Java with the greatest of ease. However at the project outset I turned my back on Java and settled for the speed and familarity of C++. There is a comfort factor in that if I find it hard to progress with building the rest of my server I can fall back on Java and these libraries.

A highlight is that my O'Reilly book RESTful Web Services has arrived, a first glance looks good. I will spend a lot of time reading this and learning.

Mozilla add on

I have just discovered an excellent add on for Mozilla called Poster. It allows me to make http requests via a side bar. I can fill in the URL, the content type and the content, whether it is a GET, POST, HEAD, DELETE or PUT. This should make a helpful addition to testing the server.

More REST resources

I have just been reading the article RESTify Day Trader this has a small amount of constructing URI's this is also covered here and in more depth in How_to_create_a_REST_Protocol. The process strikes me as very similar to the one I am undergoing in converting the statement of requirements into a design. By hunting for the nouns and verbs and using these as the basis for creation. These links could also be of interest since I am considering using JSON . In the far future this article on using Etags to avoid transmitting the same information again and again are of interest.

Back on my main topic about implementing REST is this article. Areas I will be looking at is the use of accept to return different formats, this may be necessary or of interest for different clients. Various article mention that REST should be stateless and this is fine since retrieving a booking for a certain time and date should return the same data as long as it hasn't been deleted. Accessing an account customer or an employer would have the same effect. However there seems to be a small variation on ideas regarding logging on. For my system it needs to be implemented since the web interface is not for anyone to use. Certain people will have access to different functions. Other people should be forbidden to access anything. It makes no sense for a person in Australia to book a taxi in England. So there needs to be a log on system to check if the user is permitted to carry out that action.

How should this be implemented. Should the query section of the URI always carry a user reference that can be checked by the server. Should this be included in the URI e.g. Ref34253/Bookings instead of /Bookings? or some other scheme? I still need to do some searching.

http classes

When I started this project I wrote a couple of classes to simplify the parsing of the content of an HTTP request received by a server and to return a request. Looking back I can see that both classes share alot of similar information. I can also see the benefit of creating similar classes for the client side. As a result I am going to sit down and redesign the basic classes. At the top of the heirarchy will be a base class that contains member variables in common to all the classes. This will be inherited by two classes a base reader and a base writer, these will contain setter or getter methods depending on their function. From these I will derive the server and client classes.

REST design

I have found a great article here which covers some of the ideas involved in creating URL's to access parts of the system.

UML Design

I have continued working on the UML design of the system, at the moment it captures mostly the different objects that will be modelled. It doesn't show drivers shift patterns yet or other areas like that. The design looks at present like this

However I now realise that Account Customers can function like Bookers, and so can Dispatchers. I wonder if the roles that people can play should be implemented higher up as a series of flags, an Administrator can then mark which roles a person in the system is allowed to perform.

More literature resources

My search has lead to more sources http://www.xml.com/pub/a/2004/08/11/rest.html and http://www.xml.com/pub/a/2005/03/02/restful.html and http://webservices.xml.com/pub/a/ws/2003/09/30/soa.html I think these are going to give me a simpler view of what I need to implement.

I think that I have a clear idea of what the http methods represent. GET retrieves a resource from the url. PUT creates a resource at the URL. POST creates or updates the resource at the end of the URL. DELETE deletes the resource at the end of the URL.

It seems to be suggested that the URL should take the form of /the rest of the steps to lead to the resource.

UML Software

While looking around at different UML solutions I discovered this Open Source application StarUML . So far it seems very simple to use, I haven't gone very far with it to see what if any features are missing. It also has the option to export as images.

A first attempt at capturing the statement of requirements

I have also tried the export to C++ code which appears to work very nicely indeed.

Literature Search

I have managed to track down Fieldings original dissertation which introduced REST. I found the link in the document A RESTful Approach which I downloaded from the IEEE site. However the link didn't work properly in Adobe Acrobat Reader and only took me to the top of the University of Califonia website. As usual Google helped out and took me here http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm . This looks to be an extremely weighty document and will be a lot of heavy reading. I will attempt this in part, but will most likely look to some of the shorter and more condensed documents I have found.

No sooner said than found. A second document (REST eye for the SOA guy) I was looking at has lead me here http://rest.blueoxen.net/cgi-bin/wiki.pl which is a wiki on how REST has developed and how to implement it.

Breakthrough

Finally today I managed to transmit a message from my trial server back to a web browser running on my wife's computer. It was a simple message in HTML but enough to prove that I am getting the hang of the idea.

It looks like implementing a REST server that accepts HTTP messages and uses the paths and queries to create and format a response is fairly simple. I will need to write a client, but that is fairly simple in comparison and will need to be able accept a response in JSON or XML. A web browser based client also looks very possible now.

The next step is to transfer the statement of requirements into a design for the software.

At this stage I am thinking of going with JSON, there is a nice addon library to go with the one I am using for the GUI, and after reading up on it it seems ideal for lightweight data which is all I will be transporting.

It may be beyond the realms of this project, but security will no doubt be an issue that would need addressing, by using http which is a well known protocol, there would be a greater risk of hacking, especially if using the default port 80. However it seems that alternative urls can be used to get a web browser to use a different port such as http://www.amazon.co.uk:8045/, for a client application the port is not an issue as long as it uses the same as the server.

I feel a great deal happier about this project as a result of today's work. The issue was using sizeof(message.c_str()) which I wrongly assumed would give the length of the message in bytes. Instead I switched to sizeof(message.length()) which seems to work as expected.

Slow progress

The web server is progressing, but slowly. I have got to a stage where I can receive and parse the http header and possibly content from a web browser. However when I send a response it seems to be created correctly at the server end, but it doesn't seem to parse properly at the browser end. The trouble is I can't see what the browser is receiving. However it is early days and this is at least progress. Once I get this working the server side of the application should be nice and simple.

Progress

I have heard back from my tutor today and so far it seems that my project is running along the right lines. I am working on two main areas at the moment.

1. At present I am attempting to write up the negotiated requirements document ready for the meeting next Saturday.
2. I am also attempting to write a webserver in C++ as a basis of a REST server. This is all new territory to me since I haven't worked with sockets before, let alone write a webserver. So far the intial attempts have worked quite well, I can receive from a web browser, however I haven't managed to send in return yet. The server I plan to build will only work on a subset of the HTTP specification since it doesn't need to be a full web server it just needs to respond correctly to REST messaging. This area of the project is by far the biggest part of the project for me.

Focused Literature Search

I think that I have narrowed down my literature search. I started this project in panic thinking what should I search for and how. Typing Taxi Booking Software wasn't likely to return anything of any real use to me.

The advice to focus on the project and the sub tasks involved certainly helped to provide me with some focus. I became clear that this was to be a distributed project, with one server and several clients. Additionally the clients would be running on different computers and not necessarily on the same network, indeed they might be running over the web.

This lead to me looking into RPC (remote procedure calls), we had previously implemented this using CORBA in Java. However a quick web search indicated that things had moved on. There seemed to be a big debate about SOAP (Simple Object Access Protocol or Service Oriented Architecture Protocol) vs REST (Representational State Transfer). There was also a related debate about XML (eXtensible Markup Language) vs JSON (Javascript Object Notation).

As a result of these debates it seems that REST is considered the simpliest and lightest weight method of implementing client server communication. As a result I am focusing my literature search on REST to better understand it and how to implement it.

The debate about XML vs JSON seems on similar lines, that XML is too heavyweight for simple tasks like data transfers. However it comes into its own for document transfers. I will probably use JSON for data transfer as a result.

The second part of my literature search resulted from the fact that I have little experience in project management, as a result I have reasearched various methodologies, and I am going to focus on looking at AGILE and XP Programming. I realise that neither of these methodologies is going to fit a one man programming outfit exactly, but I hope that there are aspects that I can apply to my project planning and development.

I am going to consider these papers along with my life cycle choices.

SOA articles

REST at IBM
http://www.ibm.com/developerworks/xml/library/x-restfulsoa/index.html?ca=drs-
SUN implementation in JAVA
http://blogs.sun.com/enterprisetechtips/entry/implementing_restful_web_services_in
Others
http://www.xml.com/pub/a/2004/08/11/rest.html?page=2
Rest and The Real World
http://www.xml.com/pub/a/ws/2002/02/20/rest.html?page=1
http://www.xml.com/lpt/a/1459
Reliable Delivery in HTTP
http://www.prescod.net/reliable_http.html

RPC

The more I look at this the more debates I find over the best method, CORBA seems to be considered heavyweight and out of date. SOAP has many followers, but this is also considered by many to be too heavyweight. JSON has it's fans who claim that it is lighter weight than SOAP, but more suited to data carriage than document carriage. Finally I have stumbled upon REST which seems to make a lot of sense, though I haven't looked at it deep enough yet.

The meeting went ok tonight and I have a list of 'requirements' along with a few vague and woolly ideas. I'll try to make sense of it all later today.

Other software on the net

I have just done a quick search for other taxi software there is one here http://www.taxi-plus.co.uk/features.html this gives me some idea what other software provides and has set me thinking about providing automatic accounts billing for account customers. And way in the future this site http://www.futurequest.biz/index_pages/fq_main_taxi.html talks about things like GPS tracking of vehicle.

Other links
http://www.navigator-metro.com/sms.php
http://www.navigator-metro.com/book.php

Requirements meeting tonight

Some ideas that I am going to throw into tonights meeting, drivers having vehicle details such as car model, make, colour, registration plate, hacknet carriage number, then customers can request what vehicle they should look out for or track down which driver they had by the car.

A card system has been mentioned whereby drivers get assigned 20 pound jobs and 50 pound jobs in a circular queue system. If a driver is not on duty then the next driver in the queue gets the job and is moved to the back of the queue. If a driver refuses a job then they are moved to the back of the queue?

Account customers allowed web access to make bookings?

Jobs are allocated in time slots. What is the smallest possible time slot? Jobs need to be allocated an alloted time.

If a driver has an accident there needs to be some provision to swap over his bookings to another driver, maybe let the system auto allocate among other drivers empty slots.

Shift allocation, do drivers have regular shifts? or do they vary?

Controller accounts to provide a level of accountablity? If there is a problem then the correct controller can be contacted for more information.

I am sure that many more ideas will arise tonight, there should also be some drivers available to comment on what they would expect from a new system.

I haven't heard from my tutoe yet, I will wait until Moinday and make contact again if I haven't had a response. By then I will be a bit further into the project and I will have more idea what to ask about.

Search possibilities

I have been thinking about the vague structure of the application I am going to design, there is the need for a database to hold details about Controllers, Drivers, Customers and bookings. On top of the database there will need to be a server since more than one controller will be access and storing data at the same time. Then there need to be the client applications. Future expansion of the system might included trusted customers being able to make bookings over the internet via browser based clients.

Obviously there is a need to consider RPC or data exchange between the server and different types of client. I could program the entire application in JAVA and use CORBA, then browser based clients would most likely need to install an applet. I have also heard of SOAP, JSON and other similar methods.

So I guess a literature search on modern methods of solving this problem would be applicable. This search could also incorporate technologies that don't tie me to one particular programming language.

Search Options

The tutorial in Bristol got me thinking about doing a literature for project planning, since this is an area I could do with learning more about, it is also one area which could be cutting edge. I have just read the notes from the Sterling tutorial which seemed to have covered very different aspects to the Bristol one. Alistair's slides covered this very topic which confirms that that will be one direction for my search. I have heard a lot about agile and xp programming http://www.onlamp.com/pub/a/onlamp/2003/07/31/extremeprogramming.html and it might be worth reasearching wether there are aspects in this paradigms which I can apply to my more or less one man programming project. I have also found an interesting paper on Scrum http://jeffsutherland.com/scrum/scrumpapers.pdf though as yet I don't see where this fits into the agile, xp realms. There appears to be much more here http://jeffsutherland.com/scrum/

The other tutor's slides also threw up some interesting ideas with Groovy http://groovy.codehaus.org/ and Grails http://grails.org/, as one possible future extension would be a web based interface may be these additions would be worth looking into.

I was originally thinking of attempting this project in C++ since this is a language that I am more familar with, I haven't used Java since M301 3 years ago, but I use C++ almost daily. Now I am thinking that these ideas might make the pain of using Java worthwhile.

Suddenly this project looks more interesting, but so much larger considering the time limit I have set.

Next Steps

I have emailed my tutor today to alert him to this blog and to check that I am on target so far. I am not going to expect an instant response since I gather the tutors are as busy as us at this stage. Having described the project in the questions yesterday the next series of questions are supposed to help me scope the project. I don't feel ready to answer these fully yet.

1. What am I going to design and deliver as an end-product? At present this seems to mimic the last question in the previous section. I guess a fuller answer would be an attempt to fully capture the clients requirements, a design of how those requirements will be implemented, and a prototype system for the clients evaluation.
2. How am I going to identify the (basic) requirements? I am hoping that my client is going to do the basic foot work here, by giving me a list of what they would like to see which we can use as a basis for discussion with me being able to say what is overly ambitious at this stage, suggest features they haven't considere. From there we can hammer out a reasonable modified list of requirements.
3. How will I implement it: Through iteration? Incrementation? Both of these? Or some other strategy? I need to look again at the project life cycles document to choose the best or mix of best strategies. I know that a straight forward waterfall method will be of no use since the clients requirements and expectations are likely to change as they are refined.
4. How will I evaluate it? I think here that my clients response will have a major impact on my evaluation, are they happy with the end product? has it turned out as they expected? At the same time am I happy with the end product? Were there any major obstacles that I did not expect? Did the tasks match the measure of difficulty that I expected them to?

What do I need to do now?

• Compare and evaluate the life cycle models that have been presented to me in light of my chosen project.
• Elicit a basic list of requirements from my client as a starting point. I will be meeting with my contact Saturday evening and will be able to spend a deal of time chewing over requirements. At my next meeting I will have written up a list of what we have come up with so far and see if they have thought of anything to add.
• I also need to identify the major and minor sub tasks for the project.
• I also need to consider the resources that I need access to, these will include the language I intend to use and why, making sure that I have regular access to my clients representive as often as possible. At present this is arranged for each Saturday evening and so shouldn't present a problem (however people do get ill or change jobs!).
• Practical activity I need to source some relevent academic articles, so I need to start thinking about what areas I need to research. I will have begun to elicit requirements, I will also start on modelling the problem possibly in UML.

At present this is as far as I can go.

Project start

This is more or less day one for my project. I have managed to wade through all the project materials and have a basic overview of what the course requires of me. I have also attended a tutorial in Bristol over the weekend and feel a little more relieved.

Now I have to start whipping my project into shape at this point I have a very vague outline of what I want to achieve and little to no idea how to achieve it. To help me to get a more concrete base to work from I am going to answer the questions the first TMA sets out for me.

First I need a working title. I suppose that for now TAXI BOOKING SOFTWARE will do.

1. What is the problem? As I see it the problem is that at present the taxi office is run on an old fashioned paper based booking service. This was fine when the business was smaller and there was only one taxi controller on at a time. Now only one controller has access to the booking sheets, yet all controllers can take bookings.
2. Why is it considered a problem? This way of working means that there is the possiblity of the same time slot being double booked. Also the secondary controllers must take bookings on booking slips and pass these to the primary controller to enter in the sheets. This means the same booking is being written down twice. Also when it is busy booking slips can go astray in the pile of slips.
3. What might be the benefits of solving it? Less work load for the primary controller who doesn't need to write up other controllers bookings, as well as, their own. Less risk of bookings going astray upsetting customers and risking losing business. Reduced risk of booking clients in time slots that are already full.
4. What might the solution look like? I guess that the solution will consist of a central server that is attached to a database. The database will hold details of existing bookings and how many drivers are available at a set time. There will then be one or more clients which can query the server for available time slots, if there is not one available then it can request what is the nearest pre or post time slot that is available. The clients should be able to lock the time slot they are woking on.
5. What specifically, will I deliver by way of an end-product? Since this project is proof of concept to show the owners how a computer based system can solve some of the present paper based systems problems I don't need to produce an entire working system. I can write the server software with a dummy database backend and then create a basic client to carry out the previously mentioned tasks. This will provide the basic proof of concept that can be further enhanced in the future if the owners give the go ahead.

At the end of this I feel I have a clearer feel for my project and what I aim to achieve. This will probably not be a groundbreaking project or one that is too big to deliver. The full list of owners requirements would overwhelm me in the time I have, but by limiting the scope to a basic prototype I have something I can deliver in the time and something to show the owners and see if they wish to go ahead with the project.