Jason Derulo

Custom Lyrics Search Engine Launches for Jason Derulo Songs

Jason Derulo Lyrics Engine



Photo courtesy of Jason Derulo Photographs

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.