Start here

Recently we had an issue with one of our postgraduate students who was disappointed with the grade he received for his research report. He had been under the impression from his supervisor that his work was of a high standard, but it was assessed as being very poor. It struck me that this unfortunate circumstance may well have been a simple matter of miscommunication rather than anything  else. It reminded me of a document, of uncertain provenance, that claims to be an ‘Anglo-EU translation guide’ and appears on many sites across the web. It consists of a table with the following columns: ‘what the British say’,  ‘what the British mean’ and ‘what others understand’. With acknowledgements to the originators, I have put together my own version, which attempts to  provide a ‘supervisor- research student translation guide’.

What the research supervisor says What the research supervisor means What the research student thinks has been said
You have chosen an interesting topic The project is both boring and impossible I am a genius
You may have missed one or two references You have not read or understood anything My literature review is almost complete
You may need to sharpen the focus of your conclusions Your work has made no contribution whatsoever My conclusions are important
I hear what you say I disagree entirely and do not expect to see this in the thesis I must put this in the thesis
With the greatest respect… I think you are an idiot They are listening to me
That’s not bad That’s good That’s poor
That is a very brave proposal You are insane They think I have courage
Quite good A bit disappointing Quite good
I would suggest… Do it or you will fail Think about the idea, but do what you like
Oh, incidentally/ by the way The primary purpose of our discussion is… That is not very important
I was a bit disappointed that I am annoyed that It really doesn’t matter
Very interesting That is clearly nonsense They are impressed
I’ll bear it in mind I’ve forgotten it already They will probably do it
I may have misunderstood, but… You have completely missed the point They have misunderstood
Perhaps you should write this up as a paper If you won’t listen to me, perhaps a rejection will wake you up They think my work is publishable
I almost agree I don’t agree at all They agree
I only have a few minor comments Please re-write completely They have found a few typos
Could we consider some other options? I don’t like your idea They have not yet decided
Correct me if I’m wrong I’m right, don’t contradict me They are wrong and need correcting
Up to a point Not in the slightest Partially
It’s time to start nominating your examiners Damn, we’re running out of time I am nearly finished
The examiners have suggested a few changes You deserved to fail but they have generously given you six months to try to salvage the thesis I have a doctorate, I will start applying for jobs

Faking your location – how and why

One of the many interesting types of app you can download on your phone is one that will fake your GPS location. There are quite a few of these on the app stores, but they all work in much the same way. If you turn off the network based location services on your phone, but leave the GPS service on, these apps can fool any other app that uses your GPS location into thinking you are somewhere else (and there are plenty of these – think of all those permissions you say ‘yes’ to without reading them every time you install a new app.) When you run a fake GPS app, all you have to do is click on a map of where you want to pretend to be and hey presto, your boss thinks you’re at a client, your partner thinks you’re working late, your accounts department thinks you’re staying in a cheap hotel and your friends think you’re on holiday in the Cayman Islands.

Well, those seem to be the kind of use cases that people suggest on the Web. I had a rather more humdrum requirement. I was updating a mobile learning game that we have been developing for a long time, and converting it to use the most recent version of the Google Maps API. Unfortunately this renders it impossible to test map based apps in desktop device emulators without some rather nasty hacks, which are technically illegal. The only sensible option is to test your apps on a device, but how do I test a location based app when I’m sitting in the office with the phone connected to the laptop through a cable?

The answer is. of course, to fake your GPS location with one of the aforementioned apps. I used ‘Fake GPS Fake Location’ by Andev, but there are plenty of others (with very similar names). First, I ran the app, then just moved the red dot to where I wanted to pretend to be. In this case, I wanted to generate some screen captures of the game being used at Hanyang University in Seoul, Korea, where we had been testing the game, so I positioned the dot there. Here’s what the screen looks like in the Fake Location app.

Image

Next, I ran my own app, and it was fooled into thinking I was in Seoul. Here’s my app, running on the device in Auckland, reading the GPS as normal, but getting fooled.

  Image

Faking your GPS location may have all kinds of strange and sneaky uses, but from the perspective of testing location based mobile apps it’s a great tool.

 

Validating Hofstede? Some reflections on cultural differences

This semester, for the second year running, I tried out a small experiment with one of my classes to see if the students cultural profile matched Hofstede’s results for New Zealand:

http://geert-hofstede.com/new-zealand.html

I asked the students to fill in the VSM94 questionnaire, then put their results (anonymously) into a shared Google doc that calculated the results according to the algorithms outlined in the VSM94 manual. The sample size was only 30, so take the results with a pinch of salt, but the outcome was very interesting, and replicated the results from last year. Despite the fact that the majority of my students were not born in New Zealand, the results of our survey correlated quite closely with Hofstede’s figures, apart from masculinity:

Cultural Measure Hofstede Result Student Result
Power Distance 22 20
Individualism 79 72
Masculinity 58 33
Uncertainty Avoidance 49 58

Certainly wider New Zealand society has masculine traits with a strong emphasis on competing in sport, aggressive outdoor activities and terrible driving, but perhaps students have a different subculture? However it is the similarities that interest me more than the differences, suggesting that we absorb the culture around us  quite quickly, given the short time that some of my students have been in New Zealand.

Ignatia Webs blog post – the future of mobile learning

Ignatia Webs blog post – the future of mobile learning

I was very pleased to see this positive blog post review of a chapter I recently published in an open access book on mobile learning, which the blogger, Inge De Ward, also tweeted. Inge’s blog and Twitter feed must be quite popular, judging by the large number re-tweets that ensued. Please take a look at the blog post, and also the article (the blog contains a link to it)

Strong passwords, stronger extortionists

I’ve posted before about passwords, specifically about the large number of extremely weak passwords revealed by the Adobe hackers. I recently saw a story on the BBC web site about a password that the security forces couldn’t crack. Here’s the article:

Man jailed for refusing to give police USB stick password

The password was $ur4ht4ub4h8, apparently a play on words relating to a chapter of the Koran. Next time some piece of software insists your password must include a mix of upper and lower case letters you can tell it to go take a hike.

If the password was so uncrackable, you may wonder, how come it’s in the article? Well as usual the security of your password is only part of the story, the authorities have many ways of extorting your passwords out of you, as this article describes:

David Miranda feels ‘invaded’ after password disclosure

The moral of the story, if there is one, might be that however secure your data is, you yourself are more easily hacked.

Testing, Testing…

I’ve recently been interested to see a couple of examples where the concepts of test driven development and regression testing were clearly not applied, or at least not applied as they should have been.

The first example was FaceTime on my old iPod Touch. Having worked perfectly happily for years, communicating with an identical device in the UK, it suddenly started failing, and for a while I was reduced to using the much flakier Skype. As you do, I stared surfing the web for answers to the problem. I soon found a growing number of people interacting on various on-line forums complaining about a similar issue. Clearly, the common denominator seemed to be a regression caused by a recent upgrade to the iOS operating system on iPod Touch 4th generation. Interestingly, the response from Apple, if the experiences of those on the forums were anything to go by, seemed to be one of total disinterest. However, a few weeks later, Apple quietly released the following fix for a problem that had affected ‘some users’ (i.e. many):

http://support.apple.com/kb/DL1701

Now I know, from painful experience, how hard it is to test for this type of fault, but Apple should have had regression tests in place for changes that might affect popular standard apps like FaceTime.

The other interesting example was this one, about LG televisions sending personal data back to the company, even when a privacy setting had been turned on:

http://doctorbeet.blogspot.co.uk/2013/11/lg-smart-tvs-logging-usb-filenames-and.html

Now you would expect, if this software had been test driven, that a test would have been written that ensured that activating the privacy setting meant that data could not be sent. Instead, data was still sent, along with an indication that the privacy setting was turned on. Either that wasn’t tested at all, or it was driven by a stupid test. The alternative interpretation, that LG wants your data whether you like it or not is, I’m sure, not the case.

These two examples are instructive because they emphasize how important it is to (a) drive your designs with unit tests and (b) avoid the entropy of your software with regression tests.

 

 

Global Day of Coderetreat

gdcr_ad_textGlobal Day of Coderetreat

Last weekend I participated in the 2013 Global Day of Coderetreat, joining the session running at the Xero offices in Wellington, New Zealand. Along with 2,000+ other software developers across 165 locations on all continents, I spent the day honing my software craftsmanship, pair programming with other developers, using test driven development (TDD), and working within a range of changing and challenging design constraints. A coderetreat is an opportunity to look at the same programming problem (typically Conway’s Game of Life) from multiple perspectives, without the pressure to create a finished product but using the opportunity to reflect on how we build software. I would recommend that all software developers, at whatever level of skill and experience, take a look at the coderetreat.org web site and keep a look out for upcoming coderetreats in their local area. If you can’t find one, why not run one yourself? All the information you need is on the web site. The only people who won’t gain anything from it are those who just want to show other people how great they (think they) are. Fortunately, these people are a tiny minority of the software development community. Most of us will embrace the opportunity to challenge themselves and learn from others, in a day of coding that is surprisingly enjoyable.

Follow

Get every new post delivered to your Inbox.