Welcome
Friday, October 10, 2008
10/10 Finished Report!
End parts taken out of report:
10/10 Where to from Here
1 Where to From Here
1.1 Application Improvements
1.1.1 Interface
Because the system is only a proof on concept and there were time constraints, there are many improvements that could be made to the application. Grid views were used with one basic data source, this results in a basic data set such as a job record showing only the user id instead of the user name. A better way of doing this would have been to manually loop through and display all of the records with the data needed into a table.
The design and look of the interface was done in a hurry and could have been improved, however this was not part of the core functionality so very little time was spent on this. If more time was given this could have been re-visited and improved, or more time could be spent on other ideas.
1.1.2 Mapping
The mapping works by marking jobs in this design, if the user just wanted to map out only client locations instead of jobs, they cannot do this. Another page could be added just for mapping out clients.
Routing in the proof of concept only shows the street name and the directions (shown in Figure 7.1.1). This is because only the basic function of getting a route is used. It is possible customize the format of the data by looping through the returned route and displaying it. This would allow the job information to be shown under each stop as well as displaying the actual street number.
1.1.3 Searching
The searching of records was one of the original features of the system. By the end of implementation there wasn’t enough time to implement the searching, and a line needed to be drawn for the end of the implementation milestone. Searching was low on the list of important features for functionality. If more time was spent on this application the searching features would be added as it is something that increases the ease of use immensely.
1.2.1 Sorting of Clients and Jobs
The algorithm programmed for sorting the clients (the whole process is explained in section 6.2) is not the most efficient or reliable way of completing the sorting of clients. This is mainly because of the lack of experience on the author’s behalf as well as time constraints not allowing the re-assessment of how the process works. If this were to be improved there would be performance benefits as well as the mapping being more reliable.
Because the mapping is done by using straight line distances it is not very accurate, however the other option was to use Google maps which wasn’t very good for performance and resources. If there was a way of calculating the driving distance quicker and more efficient than using Google, the routing would be more precise.
1.2.2 Mapping Services
At the moment the main functions online mapping services provide are basic mapping. Some of the mapping services provide different features such as 3D views of cities, round routes, small amounts of traffic reports etc. But none provide high detailed traffic reports for around the world. Ideally, for the best route, details about traffic jams, crashes, road works etc would be needed. Because the application implemented only provides mapping of jobs, not on route GPS directions, the traffic details would only be given when the route is made. In future the routes may be used with a GPS at run time so the information would need to be constantly updated.
There is much more potential with mapping services for the future such as routes could be shown in 3D in 360 degree views or the traffic information could be changed and shown minutes after a crash happens.
10/10 Conclusion
Mapping services offer many advantages for all types of mapping in an application. Using Google Maps with the job tracking system allowed the author to easily integrate mapping into the system only by using a few lines of code, without doing this the project scope would have been to large, and a much harder task. The Application Programming Interface provided by Google for mapping was straight forward and provided all of the features needed. Because the JavaScript needed for the mapping is very small it is easy to integrate Microsoft Live Search Maps or Yahoo! Maps by changing the application key and actual map code.
Because the Google Maps API has been around for a few years now there are vast amounts of documentation. This made the research, eventual implementation and problem solving much easier as most problems have been faced by another developer and posted in the forums.
Google Maps provides all of the features needed for this proof of concept application, however there is much potential for the future with better routing and run time traffic conditions, 3D mapping, faster loading times and more detailed satellite imagery.
Because the proof of concept application was implemented using the back end as a web service, there is a lot of room for future expansion on alternative devices using different platforms and languages.
With more development time the job tracking application could be vastly improved by adding a more efficient algorithm for sorting locations, giving the user more detailed routing information, adding traffic details to a route, designing a more appealing interface, showing more detailed information in the grid views and adding search features for better usability.
There are many improvements that could be made, however the main functionality is provided to make this application a proof of concept. The original goal was to provide:
“A system based on job tracking that incorporates mapping to enhance the usability and ease of finding client/job locations. Not only will the user be able to map out one client/job location, they will also be able to combine a list of jobs for the day and get back a map with the most efficient route to take which will cut down travel time.”
This goal was achieved, and the project a success. As well as the success of the implementation, the personal goals were achieved by the author. Programming skills were increased, experience was gained, management skills were improved, time management skills were improved and a new programming language was learnt.
10/10 Problems
1 Reflections on Learning (no figures shown)
All significant problems or issues will be discussed in this section. Problems and reflections are categorised by technical, personal and project management.
1.1 Technical
1.1.1 C Sharp & Programming
Because the authors programming skills were at a very low level when the project was started the C Sharp learning curve was quite high. The first step was taking what was known about a familiar language (specifically Visual Basic.NET) and learning how to do the same in C Sharp.
After the basics were known and the application started, a few problems came up with using lists, static variables and global classes. The normal lists were implemented but it was discovered that each user would be using a different set of data. The author talked to a more experienced C Sharp programmer and got answers to all of the confusing aspects of C Sharp and the problems faced. After understanding how to implement the features needed properly implementation carried on.
1.1.2 Web Service
Once the back end service structure was implemented and fake data inserted into the database it was time to create the web service methods. The adding, deleting and editing methods were easy to implemented and worked straight away. However once the author needed to pass a set of data to the interface a wall was hit. It was realised that the author was using the wrong container for storing data temporarily. A dictionary was being used, when a generic list should have been used. Once the dictionaries were changed to lists the .toArray method could be used to pass the list to the interface. The code for sending and retrieving and looping through the array is shown in section 6.1.1.
After the data was getting to the interface the author had to find a way to read the data out into the classes. After researching and getting nowhere an example of how to do this was provided by a technical supervisor of how they read the data out of the array. This was as simple as just grabbing the data from the array and creating a new instance of the wanted class and passing in each record.
1.1.3 Virtual Machine
Originally the virtual machine being used was given 10 Gigabytes space. This quickly filled up to a point where the author was trying to delete unnecessary data; however this couldn’t be done forever. Eventually when no files would save due to lack of space this issue needed to be dealt with properly. This majorly halted development as nothing could be saved and the author wanted to avoid loosing data. After researching the many ways to extend a virtual machines space it was decided to use an application provided by VMware that converts virtual machines and increases their size. So the virtual machine was copied to a new location with 5 more Gigabytes of hard drive space.
1.1.4 Logging In
At one stage logging in did not work any more. Originally the login authentication was based on active directory, but later on it was decided to use the from the internet option. This is safer to choose at this time because it is easy to create and manage users and roles without the complexity of using active directory. After changing the authentication type logging in still did not work. A long error was given, so one part was researched: "[HttpException]: Failed to start monitoring changes to C:\Inetpub\wwwroot because access is denied". After researching similar problems using the internet and trying many fixes, one for this error worked. This was by changing the IIS ASPNET settings to framework 2.0, a very simple error but an easy setting to forget.
1.1.5 JavaScript
The first mapping done was in the client address forms, which the Subgurim control was used for. Using the control made mapping very easy because the JavaScript was created dynamically behind the scenes. Once the author realised that the Subgurim control did not do the type of routing needed, an alternative way of mapping needed to be used. After asking around, and researching the internet on what other people have done with JavaScript and ASP.NET as well as Google Maps and ASP.NET, the Page.ClientScript.RegisterStartupScript method was used (more on this in section 6.2.6).
Once the method of using JavaScript was selected, the difficulty of making it run came up. At first this method was tried using a button which would trigger the JavaScript, however it still needed to be run straight after all of the other logic so that a list of latitude longitude points could be passed to Google. It was soon realised that the easiest way to run the JavaScript where it was needed was to insert the code for the registerstartupscript exactly where it needed to be inserted. So this was placed after the latitude longitude string is completed allowing the correct data to be passed to Google.
1.1.6 Job Paging
If there are enough jobs to be multiple pages it becomes a problem for checking items on multiple pages, as the state of the previous page is not kept (grid view shown in figure 8.1.1) (not shown here). Due to time constraints the easiest option was to extend the amount of records before paging started. In future however, this would be changed to keep the records selected checked.
1.1.7 Database Constraint
Deleting a client address is more complex than deleting a client or user because of the relationship between that database tables. Because the job table has a relationship with the client ID as well as the client address ID, the address ID can’t cascade delete a job when it is deleted because of an error:
“Introducing FOREIGN KEY constraint 'FK_job_clientAddress' on table 'job' may cause cycles or multiple cascade paths.”
Figure 8.1.
Due to time constraints this was not resolved, but would be fixed if the system were to move on from a proof of concept. The tables concerned are shown in Figure 8.1.2. (not shown here)
1.2 Project management
1.2.1 Travelling Salesman
The travelling salesman problem occurs when the most optimised and efficient route is needed between a very large number of locations. The algorithm needed for this calculation would become slower the larger the locations. There are a few algorithms to deal with this problem, however with current technology it is just not possible to quickly calculate on a large scale.
The author had to face the problem of how the routing was going to be done, and how efficient it was going to be. A small amount of time went into looking at this problem, however for this proof of concept a basic brute force algorithm was chosen for simplicity. This was by looping through each location and finding the nearest position until there are no locations left.
1.2.2 Task Management
Due to lack of experience in many of the fields of this project it was very hard to estimate exactly how long any particular task was going to take. It was decided to assign time limits based on how important a task was, for example the implementation stage was given the highest amount of time because of the author’s lack of confidence in programming. At some points the time given was not enough, but not far out enough to cause a panic. If a task couldn’t be completed by the milestone date a detailed summary of what still needed to be completed was put together and tackled straight away during the next milestone.
1.3 Personal
The only personal problem that majorly impacted this project was time management. This is the authors first long term project so it took some time to get used to consecutively putting time into one thing. The amount of hours needed to spend on the project per week was 30-40, which is a lot compared to the assignments previously completed. This problem was never fully resolved, however by spending time putting together time tables, task lists and recording hours spent per week or on a daily basis this skill was vastly improved.
10/10 Self Evaluation
When I put together the project proposal I had no idea what I was in for, but I did want a challenge, particularly on the programming side of things. Once the proposal was handed in and accepted the research and design begun. After designing the system and starting on some implementation, particularly programming object oriented in C Shap.NET, I realised how much of a challenge the programming was going to be. After getting some syntax help from a friend however my pace of progress picked up.
After I gained confidence in programming the project went smoothly until it was time to create the mapping algorithm. This held me up for a while, but once I found an algorithm for calculating distances and a simple bubble sort all that was left was the sorting of client locations. This in itself took a long time, as well as a lot of trouble shooting and testing.
These two main challenges have left me with much more confidence in my problem solving skills and programming skill, which is what I had hoped for.
I have never before done anything with online mapping, or using an API to integrate maps. I found this area fascinating, especially the potential of what can be done in the future with traffic information. Using a mapping service and implementing an interface with a web service backend really gave me an idea of how you can re-use code and functionality across platforms and benefit from it.
The project as a whole took much longer than planned. I believe that this is because I underestimated how long the majority of tasks would take, and how hard certain tasks would be. This was particularly true with the mapping part which ended up being much more complex than originally thought. The extra time spent ensuring that this process was as good as I could make it was worth it, and in the end works just how I want it to. I learnt that even if you make a project scope right at the beginning and make time frames for tasks a project can take much longer than planned
There are many more improvements that I would make to the system if I had a larger amount of time, but I am perfectly happy just how it is now as a proof of concept as it does what got done what I set out to do.