Today I received my final set of grades for my BSc (Hons) in Computer Science from the University of Hull – This included my two second semester modules, Mobile Devices and Application and Distributed Systems Programming, as well as my Final Year Project.
I achieved a grade of 85% in Mobile Devices and Applications, and 89% in Distributed Systems Programming.
The final year project was worth twice as many credits as each second semester, and so had more of an effect on the final grade. Thankfully I did quite well in the final year project, achieving a grade of 86%.
My overall weighted average for this year, including my first semester modules grades, is 86.5%.
This grade, weighted with my second year grades, means that my final grade for my degree as a whole is 86% – a very high first! I am of course over the moon with this.
I’d like to again say thank you to everyone who has made my time at university not only great for learning, but truly the best three years of my life (so far! :P). Particularly, but not limited to:
Tom “Jeff” Procter
Special mention to “our American foreign exchange students”
Dr Martin Walker
Eur Ing Brian Tompsett
Dr David Parker
Dr Peter Robinson
And of course anyone I spent time with in the labs or any of the many, many nights out in the first two years. Last but by no stretch of the imagination least thanks to my Mum, Dad, Brother and Sister for supporting me throughout the last 3 years.
I’m looking forward to trying to maintain this good score next year at York! Of course I will continue to do this blog throughout my time there too.
On Monday 12th May our Mobile Devices and Applications coursework was due in at 9am and I had to demonstrate mine at 1:30pm, which was a very quick turn-around! At the demonstration I received my grade of 100%, which I was of course very happy with.
The coursework this year was to develop an Android Application called AMULET – “An m-health (mobile health) tool for the valid self-assessment of alcohol-induced impairment” for a real-world research project in the University of Hull’s Social Sciences Department. In this post I will briefly outline the functions of the application.
All users of the service had to sign up to use the AMULET service, which keeps track of all their data. They could do this inside the application itself, and information could be synced with however many devices they decide to use. The interaction with the AMULET web service is via a RESTful JSON API. The user could also manage their account from within the application including deleting it and changing its password.
The main point of the application was for users to be able to self-test various attributes and skills whilst sober, as a calibration, and then compare this score with their current score at the time of intoxication. Users were asked to input details of their current drinking session before taking a test, and shown results afterward.
The Inspection Task measures the users speed of information intake. It does this by showing the user 8 sheep and changing one of them to be a wolf for a small period of time — 100ms — the wolf then changes back to being a sheep and the user has to select the correct sheep. If the user selects the correct sheep then they complete the same task again, this time with less time — it goes down in 10ms increments. When they eventually fail this is their recorded score. A sober person should manage a time around 60ms.
The Sequence Task measures the users ability to locate information. It does this by asking them to tap every number, in order, from highest to lowest. The users score is the number of seconds it takes for the user to complete the task.
Finally, the Pilot Task measures the users ability to split their attention between multiple objects. In this task the user has to drag around the white square and keep it away from the red enemy squares. The recorded score is the amount of time in seconds the user avoids the enemies.
In my implementation each task had 3 different difficulty settings; easy, medium and hard.
In the inspection task on easy mode the sheep would change to a wolf (which was both a different shape and colour), on medium mode the sheep would change to a purple sheep, (which was the same shape but a different colour) and on hard mode the sheep colour would change only slightly.
In the sequence task easy mode makes the user count to 9, medium mode makes the user count to 16 and hard mode makes the user count to 28.
In the pilot task the enemies move faster at the higher difficulty settings, and believe me it gets rather tough. Different calibration scores and results are stored for each setting, meaning users can’t calibrate on hard and then compare that score to an easy result when drunk — because that would be cheating!
Before each task the user was shown the task brief, which allowed them to access instructions for the particular task they were about to start. At the end they were shown the task finished screen, which compared their results to a calibration or prompted them to make one. At any time the user could go to the home screen and tap “task history” to see their results from the past.
Drink Diary & Unit Calculator
As well as keeping track of the users abilities at times of sobriety and intoxication the application also kept track of the users drinking habits through a “drink diary”. This diary allowed users to enter information about a particular brand of drink including the brand name, alcoholic % and portion size, and then store how many they had drank along with a timestamp.
A unit calculator was also included for the users convince. The user could input the number of drinks they had consumed, the class of drink (e.g. Red Wine, White Wine, Average Strength Beer), and the portion size and be given a reasonable estimate of the number of units consumed. This functionality was also called when the user input drinks for the drink diary, to make data entry easier.
RESTful Server Interaction
One of the most interesting parts of the coursework was ensuring we stuck to the standard required by our lecturers server to send and receive data. This server allowed for research to take place on the information submitted by users, backed the data up and allowed users to carry information from one device to another.
All drink diary entries and task results were synced.
Though the design of the application was very “windows phone-eseque” it was somewhat unique and supported many of the android features users have become familiar with; such as landscape and portrait support, different screen resolution support (from 3 inch phones to 12″ tablets and above) and notifications for long running processes such as data upload.
Thoughts on Developing for Android
I thought this coursework was a really nice way to pick up the programming language Java which, until now, I hadn’t needed to use. It’s similar to C# in a lot of ways with a few of its own idiosyncrasies, but a lot of the industry (and The University of York) use it extensively, so its a good thing to have learnt.
It was also interesting to have developed an application which worked across mobile phones, from small 3 inch screen devices, to much larger 12 inch tablets. This made me really think about the best way to develop the user interface, and I think I found a good compromise — it was certainly at least usable on all of these devices.
The main issue a lot of people had, including myself, wasn’t with Android itself, or indeed Java but rather the Eclipse IDE which most android developers use when writing applications. We all know that Visual Studio is in a class of its own, but it was a bit of a culture shock to change to an IDE that didn’t support debugging in quite the same way for example. Having said this I think this ability to switch between development environments is a good skill to have picked up. The other issue was just how slow the default andoird emulator is on a non-intel PC — but this can be solved through the use of Genymotion.
I will be getting my results for the module as a whole, along with my final university grade itself on the 2nd of July. I will of course update the blog then!
Today everyone at the University of Hull got their results for semester 1 of this year, including myself.
Semester 1 this year was almost certainly the most challenging semester I have taken so far at university, as you might expect. This increase in difficulty meant I had to put in even more effort and be even more determined than in previous years — therefore I was both pleasantly surprised, and extremely happy with my results — 90% for “Data Mining and Decision Systems” and 83% for “Languages and Their Compilers”.
These grades, combined with my grades from last year, put me in a very good position to get a first class degree, which of course I’m very happy about.
I will of course keep the blog updated over the rest of this final year.
3 of the more exciting terms in Computer Science, it has to be said — and also three of the integral parts of the Electronics and Interfacing module, which I haven’t spoken about much this year. This is due in part to the fact that I spent a lot more time on the other modules I took this year, and partly due to the fact that the coursework and exam for the module were both at the very end of the year.
Infact my final exam for the module was only yesterday, my last for the whole year, meaning I’m now at the end of my second year of university 🙂 Expect a second year round-up blog post soon.
The coursework we were given for the module was to build, and write the software for, two devices in a team of two. One device, a Robot, would be controlled by another device, a Controller via an Infrared link using a command and control protocol we came up with as a pair. I worked on producing the Controller whilst my partner worked on producing the Robot itself.
Below you can see the LCD Screen I programmed to show Bitmap images (don’t think anyone else did this) which could be touched to control the devices trajectory or to activate the Killswitch — which stopped the robot dead in its tracks. Next to that you can see the potentiometer which could be used to alter the speed of the robot, and finally alongside this you can see a physical button which also activated the Killswitch, for those times when the responsiveness of a touch screen wasn’t enough and you wanted to smack something! 😛
All of these items when used together were used to control Eric, our robot, whom you can see below.
I received a grade of 71.25% for the coursework.
The exam, which I took yesterday, focused more on the electronics portion of the module, and now the terms Ohm, Amp, Volt, Potential Difference, AC, DC, Current and Resistor and burnt into my memory forever. In addition to the questions about electronics there were a few questions on the .NET Micro Framework, Threading and other embedded programming specific tools.
As it was an electronic exam I have already received my grade and am quite happy to say I achieved 84%, though I was hoping to do a little better.
This means overall I achieved a grade of 77.6% for the module, which is my lowest grade of the year and therefore a little disappointing, but still a reasonably high first so I’m content.
A few weeks ago I wrote about our group project for the Systems Analysis, Design and Process Module. I was a bit worried at the time about how it would work out, because I’m always a bit nervous about group projects, however I’m pleased to report it all worked out well in the end. 🙂
My team achieved a baseline grade of 35 out of 40, which is 87.5%. This doesn’t necessarily mean that I have that grade, but my personal grade won’t be far off this mark!
I’m really pleased, if I get a personal mark of 87.5% that will mean I have a grade of 80% overall for the module, a high first class. 🙂
The exam mainly covered the comprehension of specifications, diagrams used in System design (State Transition, Activity, Use Case, Class, Sequence, PERT, etc) and BCS Ethics. All of which were quite interesting. 🙂
I achieved a grade of 72% — which is a first class — so hopefully, along with my Group work I will have a first class grade overall for the module.
Last Wednesday I had an exam for the Advanced Programming module. The exam was about the syntax and use of the C++ Language and the ability to read Assembly Language. I was fairly confident, even though I have personally developed very few C++ applications. As more of an application developer than a real time system or game developer I prefer to ease, reliability and stability of C# or other managed languages such as Java over the pure speed of C++.
Having said that, C++ and Assembly are interesting languages and by studying them I feel I have learnt a lot about programming in general, particularly optimization and how things actually work on the hardware.
The exam wen’t well, and I received a mark of 75% — a first class — which I’m very happy with 🙂
In the upcoming semester there will be a coursework and one more exam for the module. Hopefully I do as well in them as I have in this exam 🙂
Yesterday I got my module results for my First Year in Computer Science at the University of Hull. I got a first class in all 6 modules and 82.3% average grade for the year — I couldn’t be happier. Below is a breakdown of my module grades:
Computer Systems – 72% – First Class
Information Technology and Professional Skills – 77% – First Class
Programming 2 – 95% – First Class
Programming 1 – 94% – First Class
Quantitative Methods for Computing – 74% – First Class
Software Engineering and Human Computer Interaction – 82% – First Class
I’d like to thank my lecturers and fellow students for such a great year! In particular to those whom I learnt and revised with, we tend to learn together in Computer Science at Hull, and its been a great help! I’d also like to congratulate my fellow first years who have done very well on the whole (hull?! :P)
Today I got my result for my Algorithm Analysis Coursework for the Software Engineering and Human Computer Interaction module.
The coursework assignment was to build three C# programs from pseudo-code — an explanation in English of what the algorithm should do — and then analyse them using techniques we had learnt in the module. We then had to come up with a conclusion on the efficiency of each algorithm, and finally we had to say which “Big O” notation an algorithm was, Big O is just a measurement of algorithm efficiency.
I felt I did quite well and it seems I was right because I got a mark of 96% which is pretty good! This means there is less pressure on me for the Software Engineering exam which is in a few weeks time. Wish me luck. 🙂
Today I took a test for the IT and Professional Skills Module based around SQL. SQL stands for Structured Query Language and is the industry standard language for interacting with databases including Creating, reading, updating and deleting data — collectively known as CRUD interactions.
Due to it being an electronic test we got instant feedback and I was pleased to discover I got 88%.
I feel that I’m continuing to do well with my course, and I’m enjoying every moment of uni, so I’m happy! 😀