Part 1B Group Projects

Amidst the heap (no pun intended?) of theoretical courses and pedantic worksets, there is no thought more pleasing to a Cambridge CompSci than that of being let loose into the real world to develop games and applications, all the while getting actual class credit for it. Such is the purpose of the second year (1B) group projects. However, as we were informed this week – group projects are also roller-coaster rides of happiness and debugging – often lessons in team-work, crisis management and effective leadership.

Every second year student at Cambridge is assigned to a group (of five or six students) with an industrial mentor. Each group must then spend the term developing a functional application based on their specific project brief (and consequently present it with all the fanfare of PowerPoint and WordArt).

Presented below are short summaries of the various projects Queens’ students undertook this year. Each description is followed by their learnings over the course of the term and a quick piece of advice for future CompScis.

1. Jake

Jake’s team was handed project “Sound Garden”. Their task was to automatically generate “pleasant” music based on the movement of people inside a botanical garden. This music was to follow certain rules decided by the path people followed and be implemented using “regular grammars”. If you find yourself asking the question “What do regular languages have to do with music?” – congratulations, you share at least one thing in common with Jake.

perl_problems

Eventually, the “regular grammar” part of the project was removed so as to allow a greater focus on user-experience. They’re now trying to use low energy Bluetooth sensors and a swanky Android app to calculate proximity to various points in the garden (thus tracking the path a user takes) and generating funky music.

Lessons?

– Focus on pitching to the client – tell a story

– User experience is the key to a successful application

2. Sam and Eduard

This team was to implement the “Transport Game”. In a city like Cambridge, we’re increasingly faced with problems of traffic and pollution, calling for the implementation of a “congestion” charge/tax to motivate citizens to use public transport more and their cars less.

However, what is the actual cost of such a move on my daily journey from Queens’ to the Computer Lab (if I could drive anything more than a bicycle, that is)?

Screen Shot 2014-02-24 at 12.02.56 am

We thus have the idea of a transport game/application. A user can simply open an interactive map and plot his or her daily route. You can then save/edit/delete routes and estimate a total running cost for the journey – fuel, congestion charges, time etc. One can then compare this to the cost of using public transport and voila, you can find the most cost effective way home.

All of this, of course, requires a great front-end (think Google Maps plus displaying custom information on traffic, routes etc) and a very efficient back-end (calculating optimal routes, costs, dealing with loads of requests).

We thus have:

Lessons!

– Split the team so that the back-end and front-end implementations can carry on (almost) in parallel while each solve their own technical/logistical problems.

– If you have expensive computations (routes), break your problem down; for example, they decided to store common travel routes by diving Cambridge into zones.

3. Andi

Some projects seem straightforward at first glance but soon present a whole load of difficulties – Andi’s is one of these.

His project involved a “Recipe Curator” – simply put, as a user, I can upload, download, find, read or edit recipes. “Ha, Easy!”, you say? Well, Andi decided to do all of this along with a “Suggested Recipes” feature. Essentially, the user could type out things like “I want a dish with eggs that cooks in 30 minutes” and the website should immediately pop up the hundred best omelets recipes it finds.

This uses a large amount of NLP (natural language processing) – a really cool branch of Computer Science.

What else did Andi Learn?

Many, Many Lessons

– Andi warns that every member of a team has different sets of skills – learn to use each member effectively. That may include changing your language of choice to include all teammates, or allowing some to do more of the presentation work (very important, mind you) and others to code more.

– Be prepared for the worst; sometimes people have to stop work because of personal emergencies – learn to stay calm and deal with it.

– In the words of Andi “A person who doesn’t work is not one who doesn’t want to work”.

4. Mistral and Jeppe

We now have our final team – dealing with “Abandonment Prediction”. Jeppe and Mistral were faced with the uber-cool task of analysing users on an e-commerce site and determining the probability of a particular user actually buying something. If they were want to exit, this algorithm should be able to predict it, allowing the site to display all sorts of discounts and offers.

But how do you write this kind of oracle?

Well, Jeppe and Mistral decided to build probabilities using historic site data – i.e. given the current path of the user (eg. homepage -> Justin Bieber CD -> Advertisement), find the most similar (“closest”) path from all your data and use that result as the predicted result in this case.

But that again leads us to the question of measuring distances between paths. Their idea was to represent each path in their data by a string of characters (eg. I for index page, P for product) and then compare that to the string of the current path. They further improved this by using weighted averages, caching results etc.

What does all this mean?

Loads of Lessons

– “Good architecture saves you time” – Mistral (who nonetheless doesn’t seem to believe in this himself, using Ruby for everything) soon realized that an SQL database is not fast enough and decided to load the files directly into the Java Servlet.

– Generating a probability makes for great Math but horrible user-experience; you need to pull this math into great JQuery styled windows for the demos/presentations.

– Further Java practicals are useful!

– Sockets are hugely problematic to work with

– Make sure your algorithm works well for on different data sets

Jeppe ended his presentation by boldly claiming that his algorithm predicted correctly in 98 percent of all cases (what he failed to mention, of course, is that 97% of users abandon shopping in the first place).

Advertisements