Dangerous Questions

Last week I had to ring up PayPal to liberate some funds that they were clinging on to rather more than they should. The call went smoothly and we sorted everything out. And I've since had two emails from PayPal giving me the "Opportunity to share my feedback." Or, as I put it, do their quality control for them.

I'm a helpful soul, but I'm not sure about all this. It seems that everything I do now results in a friendly request to engage in a dialogue to discuss how well it went. Even my un-solicited calls from EE about upgrading my phone were followed by a text asking what I thought. Fortunately for them I demurred on that occasion. 

I've got two worries about this kind of thing. One is there really should be more driving good customer service than the fear that someone might get a bad review. And the other is more scary. It is all to do with what my feedback tells the company about me.

As a generally easy-going soul who has no great love of upsetting folks I tend to rate my experiences in a positive way. Since my ratings can be data-mined in the context of what other people will have said about the same operatives I could therefore be placed in an "easy going" category that might change the experiences and offers that I might get if I ring up with a genuine problem some time in the future. I've been looking fairly carefully at the disclaimers and I've not found anything that rules out this possibility. 

Perhaps I should leave a really stinking review. Just in case. 

Computer Science Course in "Actually Useful Shock Horror"

James came to see us today, which was rather nice. We got to talking and the subject turned to the gulf between studies and real life, and how to narrow it.

One of the things that we try to do in Hull is to tell people useful stuff that will they can use to get by in life as a developer. A problem that we have is that people think that the only use for the stuff that we are telling them is in exams and assignments to get a good mark.  This is a good thing as far as it goes. And of course you should do this. We have to do the grading thing to ensure that the learning outcomes for our courses have been met.

But we really, really want people to carry those skills into the next (and indeed every) thing that they do going forwards. We're trying to start you building skills that will carry you through your professional career. I don't think you can ever say you've learnt something like programming because, if you do it properly, you are continuously learning. And you should never stop. 

The good news for me is that we do get a few folks who go out into the big wide world, and come back and say "You know, that stuff you taught us turned out to be quite useful".

Who'd have thought?

Anyhoo, James is very keen to come back and do some Rather Useful Seminars on what you can do as a student to build on what you're taught, which is great.  Stay tuned. 

Jupiter and Static Class Members

I put some of my lectures up on YouTube last week and it was great to get a comment on one of them. Kostas was wondering why I spend so much time explaining how static works, and even dragging the Planet Jupiter into the explanation, when a memory diagram would do the job much more efficiently. 

Well, yes and no.

The problem with diagrams like these is that people think that they just have to learn the diagram to pass the exam and therefore pass the course. But I don't want them to do that. I want them to know what "static" means, and when to use it in a program.

I use Jupiter as a context because it might stick in the memory. It turns out that the planet puts out a lot of radio static and that static on the radio is kind of like an echo of the big bang. So it has always been here. Just like static members of a class. They don't need instances to exist. As long as the class exists, the static members exist. So you can use static methods to perform tasks without needing to make an instance (for example data validation) and you can use static properties to hold values that need to be stored once only for the class. 

My idea is that folks can go from Jupiter, to static, to always here, to methods and properties and they'll have a handle on what it all means and how to use it. Which I think is better than a diagram.

Final Year Project Interim Demonstrations

The department is trying something new this year. Each of our Final Year project students is being asked to give an interim demonstration of their project to their second supervisor at around the project mid-point. The students see a lot of their first supervisor, but they don't usually see the second supervisor until later in the project, when they are involved in the final viva and the assessment.

This year I'm getting to see all the projects for which I'm second supervisor. I wasn't convinced at the start, what with the nightmare of fitting a whole new bunch of meetings into an already crowded diary, but I must admit it has been really useful. I've seen some really great work, and some that could be made great by a strong focus on the important elements.

When considering things like this I'm much more impressed by an "end to end" demonstration of a working system with "n" features than a half-way demonstration of a system with "n*2" features. If you are making a game, it should be playable all the way to the end, with a high score table and a chance to play again. If you are making a product you should be able to  run through an entire scenario of whatever transactional behaviours the product provides. If you are performing research you should have the theory, the things you are going to do to prove/disprove the theory and some outcomes to look at which drive the conclusions. And it is worth trimming the scope so that you can achieve this.  

Writers have this thing where they talk about "killing your favourite children" which means that they have to discard a great piece of text out because it doesn't actually add anything to the work. The text might be funny, or poignant or interesting - but if it doesn't fit the context it has to go.

During the meetings we were encouraging students to take a look at their projects and do something similar. This isn't to say that they should not get credit for work that doesn't end up in the finished deliverable. My advice is to write these up in the report and then document the process by which you decide to leave them out in order to focus on the core of the work. In fact, I reckon that getting a handle on your project and dropping features that will make you fail is actually strong evidence of real professional ability. And in real life you can always save these for version 2.0 anyway. 

The Magic of CallerMemberName

Oh my goodness. The things you find when you are searching for something else. While I was looking up some stuff on Model View View Model I came across a C# feature I've not seen before. It's called [CallerMemberName] and it is awesome. It has some  useful siblings too, which I'll get to in a moment. I'm dashing off a quick blog post about it now so that I can tell everyone, and also so I can remind myself how it works in the future.

CallerMemberName lives in the System.Runtime.CompilerServices namespace and it has one simple behaviour. It lets a method know the method or property it was called from. You use it as a parameter to the method, like so:

void Demo([CallerMemberName] string name = "")
{
    Console.WriteLine(name);
}

The method Demo has a single parameter which is called name. All it does is print the name out. The parameter has a default value of "" and the strange [CallerMemberName] attribute thingy in front of it. When the method runs it prints the contents of  name. So, if we make a call to Demo from within another method - like this:

public void DoSomething()
{
    Demo();
}

- the program would print "DoSomething", because that is the name of the method that called Demo. It gets better. I can also do things like this:

private int aProperty = 0;

public int AProperty
{
    get
    {
        return aProperty;
    }
    set
    {
        Demo();
        aProperty = value;
    }
}

This time I'm calling Demo from within AProperty. And it prints "AProperty".  So far, so good.  Might be fun for code instrumentation. But why do I like it so much?

Answer, if you've not figured it out already, is that one of the more painful things about creating ViewModel classes for your applications is that when you set a property you have to call a method to tell the system that the value of that particular property has changed. And you have to give the method call the name of the property that has changed. As a string. If you get the name wrong (it has been known) a whole heap of nothing happens and your display is not updated properly. If you've done any MVVM in C# you'll be nodding around now.

If we use [CallerMemberName] we can get the name of the property being updated straight from the property itself, which means that we can make a generic notifier method that works for all the properties in the ViewModel class. No more errors caused by mistyping. There's a nice description of that part here. 

There are a couple of other "Caller" features you can use that work in exactly the same way, and might be fun to play with:

[CallerFilePath]
[CallerLineNumber]

They are fairly self-explanatory. 

Great fun. 

Making Useful Software is Hard

Turns out that making useful software is surprisingly tricky. Take "Magic Marker", the program that we used last week to help out with the marking of the first year coursework. It was simple enough to write, it just finds the coursework from a archive downloaded from the university learning environment, sets up a spreadsheet for the marking process and then puts all the comments back into the correct format for upload. I made it last year and it worked fine. For me. 

This year I built it out a bit for use by five markers working in parallel. My plan was to slightly extend the program to merge back all the marked work. This turned out to be surprisingly tricky. Not because of the difficultly of the task, I had the code working in double quick time. The thing that caused the grief was that if you introduce more moving parts into a system the number of ways it can fail goes up exponentially.

This is something I've experienced before. It takes you ten minutes to code up the bit that does the work, and a day to cope with all the fiddly ways in which the program can go wrong. For example, at one point in the assessment process you have to copy the mark from the spreadsheet into the marking took. Of course I forgot to do this for a couple of folks and so my program got upset as a result. So I had to figure out how to mitigate this and then build it into the workflow. 

The good news is that having lots of students provides a great way to shake down the solution, and I now have a solution that will be useful going forwards. But this took a bit more coding than I expected. Remember, when you are writing code that the "Happy Path" will probably take you around 10-20% of the development time.  

When you are designing the workflow for a system you need to identify all the ways that it can go wrong and then specify what should happen in each. This is something that I tell everyone on the Systems Analysis course, and perhaps I should have followed my own advice a bit more at the start of this job. 

What is Assessment For?

At this time of year we do a lot of assessment of our students. This week I'm going to be spending the best part of four days in the lab with a bunch of my colleagues, pointing at bits of code written by students and asking "What does this do?". Great fun.

You might think that we do the assessment so that we can give the students grades. True enough, but to me the assessment is more important than that. We also want to have a framework in which we can talk to each student about the programs they have written, and how to make them better. The marking scheme provides lots of hooks we can use to hang discussions about good program design, documentation and testing. 

By the end of each marking session the student will have a number and hopefully they'll have learnt a bit more about software development. Which is kind of the plan. 

What you need to know before you leave university...

I've written a tiny article for the Microsoft UK Developer's Blog about stuff you should know before you leave uni. You can find it here. 

What makes a Bad Programmer?

I've been spending quite a bit of time with the First Year students this week. They're presently grappling with the "Space Cheese Mining" coursework which is a silly board game loosely based on Snakes and Ladders but with a few twists. And some cheese. 

Anyhoo, I was telling one student that I didn't allow First Years to tell me they were bad programmers. "That's my job" I said. The point I was going for is that one of the problems people have when learning to program is that they lack confidence in the code that they write. Sometimes they worry that they might not have found the "best" solution.

It turns out that some things are just hard to deal with, and require fiddly bits of code no matter how you approach them. So your code ends up looking a mess, and that's just the way it is. Snag is, when you are learning to program you don't necessarily get this, and you might worry that your program looks messy because you can't actually write code. So I always say that I'll be the judge of bad and good code, 'cos I've been writing programs for some time. 

We talked it through a while and then the student asked a really tough question "So, what makes a bad programmer then?" Ugh. Wasn't expecting that one. I didn't really have a ready answer. I muttered about bad coding style, not testing code, etc etc and that was that. 

Having thought about it some more though, I reckon I was wrong. I now think  a bad programmer is someone you don't want to work with.  They might write code that nobody can understand. They might refuse to test their solutions. They might refuse to believe that there is a problem with something they have written. They might not buy their round in the pub. They might get into fights with the customer. And they might enjoy telling you about bugs in your code rather too much.

Technical ability will get you so far in this business, but if you aren't good to work with this is going to hold you back in the long run.

Suiting Up Pays off

The "Black Godzilla" team in Three Thing Game made an awesome game. And they turned up at the Finalist Presentations fully suited and booted, and looking really sharp. Like winners in fact. I caught up with one of the team today and he told me that they had decided to dress properly for the event. 

I think this is a great idea. Way back when I was mentoring Imagine Cup Teams I had a habit of nipping down to Asda and picking up sets of matching shirts for the teams that I was looking after. This got a bit expensive when we had four teams in the UK finals one year, but it made a huge difference. For one thing, the students looked like proper teams.

If you're engaged in any kind of team work it is well worth giving some thought to this. It doesn't have to be expensive, just all get the same style T shirt or whatever. And the funny thing is, once you look like a team you start to behave more like a team too.

Give Things Away

One of the smartest things I ever did was to give away the C# Yellow Book. I've had more interest and traffic from the free downloads than I'd ever have got if I tried to make a profit from the text. 

I was talking to one of the musician folks who will be helping make music and sound effects for Three Thing Game on Friday and I was expounding on this theory. My theory is that people really love free stuff, and that if you make a name for yourself as a provider of good, free, stuff then sooner or later someone will want to hire you for a proper job.

The great thing about being young and creative is that you often have more ideas than you know what to do with. So why not put some of the stuff you make out there for free and see what comes back. If you're a programmer you can get a similar effect by taking part in Open Source Projects.  

Failure is not a state, it's an event

I'm not a big fan of trite aphorisms. Today may be the first day of the rest of my life, but putting it that way doesn't really do much for me. But today in a presentation about teaching and learning I saw the phrase "Failure is not a state, it is an event". I didn't get time to jot down the attribution, and the best that the internets can come up with on the matter is this, but I do think that this is a crucial thing to remember.

Never think of yourself as a failure if something you try doesn't work. Just think of yourself as someone who has now got some valuable knowledge along the lines of: "I need to do that differently".

I think you learn more from your failures than your successes. And fear of failure is worse than failure itself. I now allow myself the luxury of trying things that might fail on the grounds that worst case I'll know more than I would by doing nothing. And it is always possible I might succeed.

The Five Knows of Programming

I've been teaching programming for a very long time. I'm still waiting to get properly good at it. In the meantime I'm given to thinking about what it means to learn how to program. I've narrowed it down to five "knows".

1. Know what the computer does.
2. Know how to create a program.
3. Know how to automate a task that you yourself can perform.
4. Know how to think like a computer.
5. Know how to structure and manage your solutions.

I've been teaching the First Year course for the last few weeks and I reckon that we are at level 3 at the moment, moving on to level 4. This is a crucial time.

At "Know level three" you can take something you would be able to do yourself and write a program do perform that action. One example we do is deciding whether or not you can see a particular film. If your age is lower than the rating for that film, you can't go in. When you write the program you can imagine yourself selling tickets and deciding whether or not people can come in.

Level 4 is quite different. You have to let go of how you would do a task and try to think how you could make a computer do it. Sorting is a classic example of this. If you gave me 20 numbers to put in descending order I'd be able to do it, but I'd not really be able to tell you how I did it. To write a program to sort 20 numbers you would make it do the task in a way that a human never would (for example bubble sort). This is the hardest part of programming. Up until you hit level 4 you can think you are doing very well. Ifs and loops make sense, as do variables. And you've even written the odd program. And then wham, you suddenly find that you can't do it. And I mean really can't do it. This can be very painful and demoralising.

Today I did a tutorial with the students where we explored the transition from level 3 to 4. The best advice I have on this matter is not to stress if the penny doesn't drop first, second or third time. Don't think of it as a technical problem (I must re-read my notes so that I understand arrays better) but think of it as a "way of thinking problem".

Work with what you know a program can do (stash things in arrays, get them back, work through elements, compare values and do things with them etc) and then try to figure out how these abilities can be used to solve the problem.

Consider lots of related problems: find the biggest item in an array, find the smallest in an array, count how many times the value three appears in an array etc etc and notice how fundamental behaviours (working through the elements of the array in sequence) can be used to solve a whole class of problems. Don't worry if your answers seem complicated to you. You get better with practice, and some things are just tricky to do.

I learned to program a long time ago, but I still remember the worry of "What if I don't get this bit" every now and then. Your best bet is to start early, find friends to discus it with and keep the focus on what you are trying to do. And you'll be fine.

Of Broccoli and Stoppers

I don't like broccoli. Never have. Give me a plate of food with some broccoli on it and I'll eat the broccoli first. This is because I like to get rid of the bits I don't like before moving onto the stuff that I do. Note that I don't leave the broccoli. That would be impolite. And a waste of food.

I do this kind of thing in software projects too, as I was telling my project students this week. I reckon that step one of any project is to "Identify the stoppers". Stoppers are the tricksy things that must be made to work otherwise you don't have a working system. It might be storing the data. It might be getting the network to connect. It might just be being able to compile and run a program on the target device. These are the "broccoli" in your project. And you should eat them first.

It's tempting to start with the easy bits and leave the nasty, difficult bits to the end. However, this can lead to problems. You really don't want to be doing the hard bits when you are under time pressure at the end of the project. And you really don't want to find out at the end that one of your "stoppers" is actually impossible. Much more recoverable if you find out at the start.

I've asked my students to identify the stoppers in their projects and report back at the next meeting.

Hull Knowledge Factory Student Talk

At least now I know what happens if I try to use the Panorama feature of my camera to take a picture of the audience. Sorry if you were cut off.

I did a talk for a bunch of Knowledge Factory students today. These are folks who will be joining us at the end of the month as students, but have come along early to spend a few days getting a taste of university life.

The subject of the session was the joys of "Making Stuff" and it was great fun. Thanks for being a lovely audience folks. During the talk I mentioned some bits and bobs and I said I'd post references for anyone who fancies following up on the things I talked about.

Arduino

Arduino is the name of a family of embedded computers of different sizes. These are the kind of computers that you would put inside a device to control what it does. I use them in my wedding lights and other gadgets that I've made. You program them in C using a very easy to use framework that you can download for free from the Arduino web site.There are versions of the framework for Mac and PC. You put a program into the Arduino device and it runs that program each time the power is switched on.

You can buy Arduino branded devices but they are a bit pricey. It is much cheaper to go onto eBay and just search for Arduino. A company called Sintron makes some very nice kits of parts to play with, these start at around 30 pounds. Once you have the kit just search the web and you'll find loads of libraries, sample code and videos to get you started. 

If you want some books to read about the platform I'd look for books by Simon Monk. He has written some good Arduino primers, plus a few other fun books. 

Programming 

There is no such thing as the best programming language in the world, but I quite like C#. You can get a free C# book, plus a lot of teaching materials and sample programs, from here. 

If you want to learn some Python (and why not, it's great) we have a course of sorts here. 

3D Printing

My 3D printer is an Ultimaker. I call her Una and I made her from a kit a few years ago. You can find all my 3D printing posts here. 

Blogging 

Bloging is a great way to practice writing and maybe even make a name for yourself. I did a Rather Useful Seminar about blogging. You can find it here. 

Give Yourself Time to Fail

Restarted the teaching today. I did a show of hands in the first year lecture to find out how many people had started the coursework, which is due for completion in three weeks or so. I was pleased to find that pretty much everyone had started work on it. (or was claiming to have)

It is very important to start your computer science coursework as early as you can. This is because you need to have time to fail. By that I mean that there will be times when your program won't work and you won't be able to work out why. (this still happens to me by the way). In this situation you need time to be able to walk away from the computer and go back to it, which is a problem solving technique that works for me a lot of the time.

The other technique I use is explaining the problem to somebody else, or even just the wall. Half way through the explanation I hit upon the "broken assumption" that is the cause of the problem and can then go and fix it.

This is one of the things that makes computing different from lots of other disciplines. I don't think it is OK to work on the basis that you could dash off an essay overnight, but at least by the time morning comes you could have a bunch of words that may or may not be the right ones.

Try this technique with a programming assignment and at around 10:30 in the evening you'll find that your program doesn't work and you've no idea why. And you have no time to step away for a while and then come back and fix it. So start early.

Careers and Internships Networking Event

Gathering at the start. Nothing brings folks in like Free Food..

We held a Careers and Internships event last year. It went really well so we thought we'd do it again. So we did.  And it went really well again. We had loads of companies show up and present, and then they manned stands and took business cards (that we had rather thoughtfully provided) from our students. 

Peter gets things going

One thing that surprised and pleased me was the number of companies in the area doing world beating stuff. And one company mentioned the awesome news that Hull was one of the top ten cities singled out in a recent Tech City UK report. You can find the report here.  Skip to pages 45 and 46 for the good stuff. 

Plenty of action at the exhibition again

It was great to see the students and employers engaging again. Many companies had brought Hull University graduates with them as part of their teams, and there was something of a reunion flavour to the event, which was really nice. And, of course, we'll run it again next year.

Ooh. Free pens..

If you're a Hull student, I wrote a little executive summary about the event. Send me an email and I'll let you have a copy. 

Charlotte Talks Industrial Placements

As soon as I found out that Charlotte Godley, one of our students, had landed a placement at Airbus Industries I made a mental note to ask her to do a Rather Useful Seminar on her experience when returned to the department. Today she came along and gave that seminar.

It was excellent.

Charlotte started with reasons why you should take a placement for a year. (it just makes you all round more awesome) and reasons why not (it is hard work, and you might get out of step with chums in your cohort who will graduate just as you come back). Then she spoke about the best way to get a placement. I think her approach really boils down to three words.

Have a plan.

Having a plan means things like finding out about a company and tailoring your CV and accompanying letter to chime with what they do. It means thinking about the kind of questions you might get asked at interview and coming up with some really good questions of your own for the company. It means preparing for careers events and making hit lists of companies to target. But most important, it means giving some thought to what you really want to do in your future.

A placement is a great way to find out if you really want to work in a large company, or write Python programs, or travel the world in a van solving mysteries (my favourite). It is also a great way to learn the ways of work, where suddenly everyone around you is not the same generation as you and everything stops at 5:30 leaving you exhausted but looking for things to occupy yourself with.  

Charlotte gave a very good description of these issues and the fact that there were so many detailed questions at the end of the session was a testament to how well the material had been delivered. She has put her slides up on her blog, and I've asked if she wouldn't mind doing a screencast of the deck, as I'm sure it would be useful to all our students.

We are having a Careers and Internships Networking event in two weeks. Hull students can sign up here and get a set of free business cards that they can pass around. We'll be releasing the list of companies coming along so that you can prepare your "hit list".

Students from any year really should come along. First years can be thinking about internships over summer (we have some developers in the cohort who would be well up for this) and second and onward years can be thinking about taking years out or finding employers.

Programming At Hull Web Site

Over the last couple of days I've spent some time adding content to our WhereWouldYouThink web site. This is a site that has lots of stuff that might be useful to students in general and computer science students in particular.

I'm trying to rationalise some of the support materials that we have for programming and I've attacked the problem in the only way I know how.

I've bought another domain name.....

I've set up a microsite at the address programmingathull.com. This brings together all the stuff that we've put together to help folks learn to program. This includes the wonderful C# Yellow Book and Arduino and Python content. If we make anything else useful we'll put it there too.

WiFi Security on the Radio

You've probably seen the film "The Truman Show".  It's about a chap who is is unknowingly the centre of a reality TV show. His life is being continuously filmed for a worldwide audience. Everything around him is choreographed so that the viewers can see his reaction to events. There's a memorable sequence in the film where Truman is heading out to work and all the traffic around him is planned like a military operation.

I was reminded of the film this morning when I was trying to drive into the middle of Hull to take part in a radio item about WiFi security. Everything, and I mean everything, seemed to be happening in a manner calculated to make me late. I had a mental vision of someone in a control room speaking into a headset and saying  "OK, he's had the slow running train and the reversing bus, now lets set up the trick cyclist and red light sequence......".

I was a bit late, but they managed to shuffle things around and we had what I thought was a good chat. It was in response to a piece in the news about a seven year old girl who had learned how to hack into an unsecured public WiFi system in around 11 minutes. You can read a good description of it here.

The story had been set up by a WiFi security company (who would have guessed). The girl wasn't actually a hacker in the proper sense, more someone who could find a video on YouTube and then copy the instructions in it. Actually I feel rather sorry for her, in that she now has "how to hack wifi" in her Google search record for the rest of her life. Oh well.

But the story did hold important lessons on security. The most important one is probably that folks need to be aware of the dangers that using free "open" wifi brings. By "open" I mean the kind of connection you don't need a username or password to access. When you use these your phone, PC or tablet will frequently give you a warning, and with good cause.

The open nature of these connections means two things. Firstly it means that the data exchanged between the network and your PC is not encrypted, so anyone can see what you are doing. Secondly it means that it is child's play - literally - to make a computer pretend to be the WiFi connection and perform a "man in the middle" attack, reading the contents of each of your messages before passing them onto the network.

So, using an open WiFi connection must be regarded as fraught with risk. If you have to use a a username and password to connect things are probably OK. Lots of hotels have a little printer on reception that prints out a set of credentials that you can use for a limited time. These are probably OK. But places where you can just find the site and then connect must be regarded as rather dodgy.

If you really must use an open site (and we've all done it - including myself who has been known to install Windows Phone firmware upgrades in Starbucks the world over) then here are a few tips:

• Only visit  web sites that have https (and the little padlock in the address bar) while you are online. These encrypt the conversation between your computer and the server so that any eavesdropper will get an earful of meaningless chatter.
• You can use your banking applications quite safely, as these will encrypt the data sent to and form the bank.
• If you really, really, must log in to use sites that are not https secure, use usernames and password pairs that are unique to that site. One nasty trick that hackers have up their sleeves is to take credentials that you use in one place and then try them on lots of other ones. If possible you should really have different passwords on every site you visit to stop this from happening.
• Once you have finished, check your device to see if it has remembered the connection. Lots of phones and tablets keep a handy list of sites so that they can reuse connections if they see them again. This means your phone might try to remake the insecure connection again without you knowing. I'd advise you to delete the connection from the list to stop this from happening.

Networked devices are massively useful and we have built large chunks of our lives around them. But you also need to remember that some of this wonderful technology was not really built for the nasty world that it is being used in and make sure that you limit exposure to these horrid tricks.