iSpot & EML project blog

Richard G. and I are going to meet soon to consolidate our list of  ‘to-do’ tasks and discuss and prioritise these tasks in relation to the site redesign.

We are going to make use of the new issue tracker system in IET to log these items. The issue tracker will most likely be available to the project team to be able to update.

The next major phase of work is the site redesign which is due to begin very soon. We have discussed batching up a couple of the functionality changes (e.g. next/previous functionality, image upload functionality) to be released with the site redesign so that it feels as though it is more of a new, improved iSpot that has been released rather than just a change to the look and feel of the site.

Development on the new location features is also on going.

I have been working on new functionality to allow users to navigate through observations using ‘Next’ and ‘Previous’ links. This work has been fairly involved and complex in places. We decided that it would be nice to try and make the next and previous links contextual in relation to where the user has come from, for example:

• if the user comes from the home page the next/previous links will scroll through the latest observations
• if the user has come from a group home page (e.g. birds) the next/previous links scroll through the observations from that group
• if the user comes from ‘My Spot’ the next/previous links will scroll through the user’s unread observations or the user’s own observations depending on which tab they have come from.

It has proved a little tricky keeping track of the various places that the user has come to the observation page from and to recreate the list of observations from the original page to then construct the next/previous links however this work is now complete and going through some final testing.

A new presentation of S159 Neighbourhood Nature is due to begin soon, so the new batch of students has been imported to iSpot. There will be a final list of students to import sent through soon. There are currently 98 students registered on the new presentation.

Richard G. has been working on new functionality to remove the Flash image upload facility and replace it with a standard HTML form field for uploading a file/image. The reason that we decided to make this change is that although the Flash upload facility is useful by allowing users to upload multiple images in one batch, it is a barrier to usability as not everybody has Flash enabled. The largest usability barrier is for users of browsers on mobile devices many of which do not have the ability to use Flash. Implementing this change to use a standard HTML form will now allow users of mobile (and ‘standard’  computers) without the ability to use Flash to upload images and observations to iSpot. Each time an image is uploaded a new file/image upload form field is presented to the user to enable them to upload another image.

The changes Richard has been making have been quite involved and Richard has also been looking at the EXIF data that accompanies the uploaded images. This will be used to help pre-populate the ‘Add an Observation’ form where possible and also to make use of GPS data if it accompanies an uploaded image.

This work is almost complete now and is going through some final testing and tweaking.

The recently configured back-up architecture and plan were given a chance to be tested over the past couple of weeks with a live swap over for iSpot and the Evolution Megalab. This was brought about by a disk failure on the live web server. The switch over included moving from the live web and database/file server to two completely different back-up web and database/file servers which then assumed the role of live servers whilst maintenance was performed on the original live web server.

The switch to the back up servers went fairly smoothly and with only a minimal amount of  downtime of the live websites. With the exception of the quiz on Megalab (which is something that needs to be looked at), both sites continued to function as normal on the back up architecture.

The disc failure problem on the live web server was rectified after about two weeks which then allowed the site to revert to the original live web server and database/file server set up. A procedure to do these switches had been documented and followed. We had originally believed that the the swap back to the live set-up had gone very smoothly, and generally speaking in terms of the technical tasks performed it had gone smoothly. However there were a couple of issues which resulted in some significant down time of the live sites:

1. When the live site files were copied back to the live web servers from the ‘backup live’ servers the websites were put in to maintenance mode so that the public could not access them and no data was written to the databases. A flag is set in the database to put the sites in to maintenance mode. After the files and databases had been copied back on to the live servers, the DNS records were changed so that requests to iSpot and the Megalab were then directed to the original live servers. The flag on the databases on the live servers were set to be online so that as the DNS changes propagated to the DNS servers of various ISPs, users trying to access the live sites would then be able to access them on the live servers (this can generally take between 24 and 72 hours or so and is out of our hands). The oversight on our part that caused a problem was that there is a scheduled task (as part of the original back up routine) to back up the live database and save/overwrite the copy on the back up server. This task performed its duty and overwrote the database on the back up server from live but now with the offline/online flag set to online. This happened within an hour of switching back to the live set up and before the DNS propagation had taken effect so that requests for iSpot were generally still pointing to the back up server which had now (inadvertently) been set to online, so users began posting observations and we believed that we were seeing the site appearing on the live servers. Then at hourly intervals the database on the back up server (which was being updated with user observations etc) was over-written with the database from the live site – which was effectively old data. The issue was picked up when a new news feature item dissappeared from the home page. The scheduled task was then stopped and the flag was set to make the sites offline again on the back up servers. Once the propagation of the DNS records started to take effect, users were successfully directed to using the sites on the live servers again.
2. The second problem was that we had requested internally that the external hosting company be notified to update the DNS settings of iSpot and the Megalab and our request was not fulfilled. When we chased up about the request we were told that it was the responsibility of a different person so we then had to chase up the request with a different person to get it actioned. We weren’t given any notice that it wasn’t the responsibility of the person that we logged the request with.

Lessons learnt

• Apart from the obvious frustrastion of a period of a couple of hours where data was lost, we were generally very pleased with how the back up architecture performed and how smoothly the transition from each system went.
• We have updated our documentation to reflect any changes to the procedure to make sure that data isn’t lost in the future.
• During the switch back to live it came to light that there may be an alternative and more efficient way of switching between servers that will result in less downtime of the site for users. Instead of asking the external hosting company to switch the destination of the request to iSpot and the Megalab on their DNS servers and waiting for these changes to propagate, there is a tool that we can use that can internally (internal to our network) control the routing to various servers/IP addresses for given requests. This would effectively mimic a change to an external DNS record but as there would be no external propagation required the switch between servers would be almost instantaneous which should therefore result in only a minimal amount of down time for the live servers.