Programming and DIY

/

I'm not very good at DIY. But I'm the cheapest labour I know, and so I've had a fair bit of practice over the years. As I was laying down each of the strips of flooring yesterday I got to thinking about how the experience of my decorating efforts maps onto writing code. I think there are some parallels here. 

When I started doing DIY I'd measure everything and then cut to precisely the dimensions that I had measured. Then I'd find that none of the corners in the room were square and that lots of my carefully measured items were the wrong size. I'd also find that, because I'd sometimes misinterpreted the numbers from my careful measurements, I'd make things the wrong size anyway. Unhappy times. 

Nowadays I don't measure anything. I hold up the next piece of flooring against the hole that I'm filling at that time, mark it off and then cut it directly. If the size of the room changes as I move down it (and it does) then my process will automatically take this into consideration. And because I don't write things down there's no chance of any errors creeping in.

You can have exactly the same experience when you write software. If you establish the specification at the start and then just build the thing you can be pretty much sure that it will be wrong. Much better to make something, play with it, and then build on top of that. By iterating and refining as you go you'll end up with a much better product. 

Oh, and one other thing I do is work "with" the job rather than against it. If I cut a piece of flooring a couple of millimetres too small there'll be a tiny gap that hardly anyone will see and nobody will care about. If I cut the flooring two millimetres too big it won't fit, which is much more of a problem.

In a programming situation you need to find out what things about the project are critical and make sure that you get those things right. It's also useful to know where you have some flexibility in the specification. Remember that there is no such thing as a perfect solution, just ones that make the user happy and ones that don't. 

At the moment (i.e. nothing has fallen off) the results of my job make me quite happy. 

Interrupts Interrupted

/

I've spent some time writing smooth movement routines for the motors for the HullPixelBot. I want the motor movement to run in the background, so that the program can do other things as the robot moves. This will make the drive very like the behaviour that you get from a traditional "servo" motor that starts turning when the program switches it on.

Thing is, the stepper motors only turn if the program sends the appropriate set of signals to the coils in them. The solution to this problem is to use the timer on the Arduino processor. This can repeatedly trigger a bit of program code at regular intervals using a hardware technique called an interrupt.

Interrupts are used by a computer to respond to real world events. Tapping a touch sensitive screen, moving the mouse or pressing a key are all things that interrupt a running program and cause the computer to run a special piece of code called an interrupt handler which deals with the event. In the case of a key press, for example, the operating system (perhaps Windows 10) responds to the interrupt by sending a keyboard message to the currently active program.

In the case of the HullPixelBot I'm using a timer to produce a sequence of interrupts at regular events which are then used to trigger code which moves the stepper motors to their next position. The code required to do this is quite tiny, and so once the move has been completed the "normal" program can be resumed.

I don't reckon you can call yourself a programmer unless you've written an interrupt handler or two. I've done quite a few and they are rather fraught bits of code. You're not allowed to touch any of the things used by the "normal" program (in case you confuse it), and you must complete your action in the shortest possible time, otherwise you'll bring the computer to a halt. Programming ninjas can write code that uses multiple interrupts from different sources at the same time. 

Which is what I want to do. 

I want programs to be able to use the distance sensor and the motors, and for both of these devices to work using interrupts. Now, I think of myself as a bit of a programming ninja, so I knock out the code and fire it up. And it doesn't work. 

I can have motors, or distance sensor, but not both. 

I'm not surprised by this because it can be tricksy if interrupts occur during interrupt handlers. So I check the hardware manual for the processor and get myself into a state where I'm convinced it should work, but it doesn't. Hmm. Perhaps I'm not a ninja after all. 

So it was back to the start, and a careful re-write of the code to make it as smooth as possible, and remove any ways in which the two handlers (one for the timer, one for the distance sensor) could interact. And it still didn't work. No fair. 

Of course, I eventually figured it out (otherwise you would not be reading this blog post). It turns out that it had nothing to do with the interrupts. It was just that when the program turned the motors on it dropped the voltage level in the robot power supply to such a low level that the distance sensors stopped working. I was testing the code on a machine on my desktop and I'd left the motor power supply turned off so that the robot wouldn't try to run away. That lack of power was my undoing. 

The good news is that I'm now pretty confident that the code I've written is solid, and the HullPixelBot can move in a very nice, precise way, measuring distance values as it goes. And I've learnt something about motor power and distance sensors, which is useful. 

I'll be showing the code off at the hardware meetup on Thursday this week. 

Programming 2 Stealth Videos

/

I've started recording some of the first year lectures as screencasts, Just to see how it turns out. I joked with the class that I'd only tell the people that came to the lectures where the videos are, but this is probably not very helpful. Anyhoo, you can find the first one here and I've set up a channel here for the rest.  They're a bit rough and ready, being recorded straight from the Surface using Camtasia and the built in microphone, but they might be of interest to C# students at Hull. 

I'll keep posting them for the rest of this semester. The only slight snag for me is that it takes around four hours to render each captured session so I've got to create a workflow that I can use to do this. 

Say Hello to Dit Lexaragez

/

I've been writing the next lab assignment for our programming course. We are creating a Bank, rather like the one in the Yellow Book.  Anyhoo, we've got as far as making some test data for the system that we are building. Demonstrations of massive account databases are all very well, but it is best if they have more than two or three accounts in them. 

It's best if all the fake accounts have different names, so I started playing with ways to make names programatically. I ended up using a method based on a very popular daytime TV show in the UK. See if you can guess the name of the show. 

My method works because names are frequently made up of the sequence “consonant – vowel –consonant” – for example “Rob”. All my method does is pick a random consonant, followed by a random vowel and then a random consonant. For longer names it just adds more vowel-consonant pairs on the end. 

static Random testRand = new Random(1);

static string vowels = "aeiou";

static string consonants = "bcdfghjklmnprstvwxz";

static string pickRandomLetter(string input)
{
    return input[testRand.Next(input.Length)].ToString();
}

static string makeTestName (int parts)
{
    string result = pickRandomLetter(consonants).ToUpper();

    for (int i=0; i < parts; i=i+1)
    {
        result = result + pickRandomLetter(vowels);
        result = result + pickRandomLetter(consonants);
    }
    return result;
}

static string makeFullTestName()
{
    return makeTestName(testRand.Next(1, 4)) + " " +
        makeTestName(testRand.Next(2, 6));
}

This is the C# that we are using for the lab. I fired it up and the first name that came out was "Dit Lexaragez" which I think is a great name. The names have a vaguely "off-planet" feel that I really like. I've suggested that people might like to fiddle with the letter sequences to modulate how much of each letter you get (you probably don't really want 'z' to appear as frequently as 't' and maybe allow some names to start and/or end with vowels.

I love it when a really simple bit of code produces really interesting behaviours. 

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. 

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.

Going Bananas for the 2015 C# Yellow Book

/

Every year I make a new version of the C# Yellow Book. And recently I've been putting something yellow on the cover. This year I thought I'd go for banana, what with it being custard last year. I took some pictures of a single banana, but these didn't end up looking to good to be honest. So I've gone for a bunch.

The text has been tidied up a bit and I've added links to the code examples that you can now get to go with the text. It will be going to print for our new First Year in a couple of days, and then I'll update the PDF on csharpcourse.com.

Coding Conundrums

/

We've been running the "Wrestling with Python" sessions again. Each Tuesday we get together with some local teachers and continue the process of getting up to speed with the Python language. We've reached the point where we are having a go at programming puzzles. And it is proving quite fun.

I've put the "Coding Conundrums" up on the Python site so anybody can have a go. You don't have to use Python, in fact I'm sending the same puzzles around our department to give folks some programming puzzles to get their teeth into. I reckon that programming is something that you have to work at continuously if you want to get (and stay) good at it. Bit like learning a musical instrument.

I'm also starting to properly like Python. Most of my Python programming takes place in the forbidding environment of the FreeCad graphic design program. I've got no debugger, scant error messages and Python programs can be terribly "brittle", in that a small mistake can cause them to shatter into a million pieces. But I must admit I'm really liking it.

Formatting Code Listings in Kindle Books using the Html Agility Pack

/

Well, that could have gone better. I got an email from Amazon suggesting that I buy a copy of the C# Yellow Book.  I get these from time to time, and this time I thought I'd tweet about it as above.  It turned into a very popular tweet (for one of mine).

Anyhoo, with my ego nicely built up I thought I'd took a look at the Amazon page for the book. And I found a 1 star review which noted that they would have liked the book a lot more if all the code samples were properly formatted....

Oh dear. Turns out that if you view the book on your iPad or iPhone the code samples all get printed on one line. I thought I'd checked this, but apparently I hadn't. So I did some digging. 

Kindle books are basically HTML documents, a bit like web pages. Like web pages, if you want to tell the renderer that you have already formatted the document you can use the <pre> </pre> enclosure to mark text that already has a layout. You can put code samples into text without their layout being damaged. 

But there is another way to do this.  You can add "white-space: pre-wrap; " to your styles for the pre-formatted text. This works fine on Kindle devices, Android devices. But not iOS devices.  Guess which technique I'd gone for. My reasoning was sensible enough, I wanted to add other stylistic touches to the code samples (a grey background for example) and it made sense to do it all in once place. But it didn't work.  Stupid me.

I had around 200 pages of text with lots of code samples, all of which were wrong. And a broken text up on Kindle that I really, really, needed to fix quickly. So I did some digging and came across the Html Agility Pack on CodePlex. This is completely wonderful. 

It provides a way of reading in a large HTML text and then traversing the notes in the document and fiddling with them.  Turns out all I needed to do was load each of the chapters and then do this:

void processNode(HtmlNode node)
{
    foreach (HtmlAttribute attribute in node.Attributes)
    {
        if(attribute.Name == "class" && attribute.Value == "CodeExplained")
        {
            node.Name = "pre";
            attribute.Value = "CodeExplainedPre";
            debugString.AppendLine(node.InnerHtml);
        }
    }
    if (node.ChildNodes != null)
    {
        foreach (HtmlNode childNode in node.ChildNodes)
        {
            processNode(childNode);
        }
    }
}

 

This starts at the base node and then looks for anything with the class CodeExplained. It then changes the name of the node to pre (for pre-formatted) and changes the attribute to CodeExplainedPre. 

It is not very elegant, but it does use recursion. If a node contains any child nodes it calls itself to sort those out too. I was going to figure out the structure of the document and only target the page for fixes, but I was in a hurry and this code meant I could reformat the document and make it to the coffee break in time. 

Note: There are probably lots of much cleverer ways of doing this using the Document Object Model or regular expressions or something. But at least this worked and got I was able to get the fixed version up on Kindle within the hour. 

HTML Wrestling

/
thread.PNG

I'm presently working in a much improved Kindle version of the World Famous (in my world) C# Yellow Book. Because the book has been written and upgraded over a number of versions the text formatting is a bit of a mess behind the scenes. It's taking a while to sort out.

I changed the style-sheet to make it a bit easier to see the code embedded in the text and got a preview page that I quite like above. With a bit of luck it should be finished in a week or so.

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.

Updating the C# Yellow Book

/

Yesterday I got an email from Amazon telling me that readers had spotted some spelling errors in the Kindle edition of the C# Programming Yellow book. They are quite right. The errors crept in when I used the Amazon system to convert the word file into an eBook. They've been bugging me for a while.

Not that the errors have&nbsp;stopped my book becoming a best seller......

Not that the errors have stopped my book becoming a best seller......

Anyhoo, I've decided to fix these pesky errors once and for all. I'm doing a new conversion of the text, moving it by hand from Word to HTML, and thence to Kindle.

Lots of things about the layout of the first version of the book didn't translate well into eBook format, hopefully the updated version of the text will be easier to read. It should be out in a week or so, once I've reformatted the text and tidied it up.

There's also some shiny new content that I've added to bring things up to date. 

Birthday Bluetooth

/

It's my birthday today. I had my treat over the weekend and am now saving up for a Segway (just about doable) and a twenty acre estate that I can use it in (pretty much impossible). So I'm here in the office, eating chocolates and writing C#. Which counts as a pretty good situation in my book. 

Anyhoo, I've been playing with a present I bought myself last week. It is a Texas Instruments SensorTag. You can pick these up for a very reasonable sixteen pounds or so and they are enormous fun (if you like connecting devices to sensors). It talks Bluetooth BLE and I've fancied having a go at this for a while.

Turns out to be easy to get it to connect to a Windows 8.1 device. Just remember that for Windows you have to pair the tag over Bluetooth. It just works with iOS and Android - I hope that they remove the need for pairing with Windows at some point. 

If you fancy having a go I've written a very simple universal app and put it on GitHub. You can use this to connect to the accelerometer in a SensorTag and get events fired in your program when a new reading is produced. 

I used a superb post from Dan Ardelean to get started, and just built a little wrapper class around methods that he described.  Great fun.

Scary Things You Shouldn't Do

/

One of my programming rules is that "just because you can do something, doesn't mean that you should". Take this piece of magic for example:

This is a lump of XAML, the code that you use to design the user interface for a Windows application. It tells the computer what the display will look like and defines display objects which link to the underlying code that provides the behaviours.

Except that it turns out that you can actually put code into your XAML, along with the display markup.

You should never do this. But I guess that knowing about it is cool. Find out more here.