Just finished writing a lecture for a session tomorrow in the university. Yiannis has invited me back to give a session about starting a business, so at 1:00 tomorrow afternoon I'm going to be back on the campus talking about "Success Through Failure".
Looking forward to it.
Version 0.9 of my playlist generator for the car had a tiny bug in in. Can you use your skill and judgement to tell me what it was?
The music player in my car is quite good. I can plug in a memory card and load up a whole bunch of music. The player interface also talks enticingly about "playlists", but I don't seem to have any and there seems no way in the car to create them.
So I do some digging. After a bit of searching I discover that the car will accept playlists in the "M3U" format. This format can be exported from some music players and you can also find programs that will create M3U files. Which is useful.
But, me being me, I fancy writing my own M3U file generation program. So I do some more digging. It turns out that the format of an M3U file is a list of tracks in a text file.
That's it. No cunning schemas or encoding techniques. Just a list of names. The only fiddly bit is in the file extension which I think needs to be m3u for non-Unicode and m3u8 if the text is UTF-8 encoded. You can make it more complicated by adding directives (there's a good description here) but it turns out that I can start making these exotic sounding files with just notepad. I'm going to have a go tomorrow.
There's a lesson here folks, which is that in the Wonderful World of Computers(tm) it is quite frequently the case that something horribly complex sounding will actually turn out to be quite simple. Don't work on the basis that "it will always be too hard for me to understand". Every now and then something is as simple as the simplest thing it could be.
I seem to need to have an Apple phone. My favourite, Windows Phone, doesn't do all the things I want, and I've tried Android and that was fairly appalling too. What can I say? I'm picky.
One trick that the iPhone plays drives me completely nuts. The phone provides "Siri App Suggestions" based on the things that you do most. You can use these favourites to slightly compensate for the horrible way that the iPhone manages large numbers of apps on the device.
The suggestions are based on your use of the phone and are updated each time you visit the screen. But here's the appalling bit. They update and redraw themselves in the fraction of a second between the page appearing and you actually selecting something.
So your finger can head for the Nest icon, but by the time your digit touches the screen the icon underneath can be replaced by a different application. So the wrong thing is selected. Most annoying.
This single piece of stupidity makes the feature completely useless to me. Here's a tip Apple, why not update the sorted list before you display it on the screen?
I'm kind of cross with myself. I've broken one of my own rules. I needed bits for 8 robots. So I bought 8 sets of bits. Stupid stupid stupid. You should always buy a few spares in case of failures. It's not that they are expensive. And you can always use the spares on other projects.
Of course a few were duff, which meant that I couldn't make all my robots. Of course (cunning bear move) the faulty parts were the ones I used last. Fortunately have have friends with similar interests (thanks Ian and Robin) so I was able to grab some spares, which is how come I'm sitting on the train with 7 working robots (I couldn't fit 8 in the case...)
I think that building devices is a bit like wrestling a bear (not that I've ever actually done any bear wresting). It's an ongoing struggle and then, just when you think you might be winning (always a dangerous thing to do) the bear pulls out a killer move and knocks you flat on the floor.
I've just suffered from this. Nasty bear.
I've been building HullPixelbot devices for c4di and AzureCraft and connecting them to my home wifi for testing. It's been going well (a dangerous sign). I'm controlling them quite successfully and thinking that I might actually end up with a working system. And then today everything slowed right down. Commands that previously took no time at all to deploy suddenly took ages, which is a problem because all the robots need to move at the same time.
Of course I thought my software was broken and spent a couple of frantic hours trying to speed it up. But the performance was still rubbish.
Then, at 3:00 am this morning the answer came to me. At the same time as deploying the final version of the code I'd switched to my portable WiFi router, rather than the home network. All the problems started then. Turns out that not all WiFi was created equal. Some is much slower than others.
At 3:30 am I was resigned to going off and buying a new router in the hope it might be faster. At 4:00 am I realised that I actually had a router I'd bought a while back for another project. Only problem is that it was running the Chinese version of the router firmware.
So at 8:00 am this morning I was trying decipher Chinese menu screens and load a new version of the firmware into the router. I've finally managed to get it working and performance is back to reasonable again. One up on the bear.
However, the most important thing about the "bear wrestling model of hardware development" is that you mustn't start to think that the bear hates you. He doesn't. He's just there to wrestle, because that is what bears like to do. You need to work on the basis that at some point the bear will step back, bow gracefully and say "I'm going to let you win this one".
Ugh
I still like my Apple Watch. I still like my Apple phone. But mainly for what they can do, not the way that they do it. Going back to my Windows Phone always puts a smile on my face, as I get to use a user interface that is properly usable and scaleable. Then the smile disappears when I find I can't read books or do anything much with it.
For a company that prides itself on design Apple should be ashamed of the above screen. Take a look at it and decide whether or not the watch will make sounds. After a while you might deduce that if silent mode is off, the watch might make sounds. Although you might also be confused because the icon shows a bell with a line through it which might imply silence. The icon is not lit up - although it can be - something that you need to know to make sense of what is happening here.
Ugh, ugh, and ugh. Anyone who thinks that user interface design is easy should take a long hard look at this and consider how they would do it. They are almost certain to come up with something better than this mess. Me, I'd take away the icon and use the words "Noisy" and "Silent", it would be a lot clearer for your's truly.
Update: Turns out I can't spell appalling. That's ..... not good.
You know how it is. You have built a robot army that you're going to use to take over the world, but first you have to get them all under your control. And if you are using tcp/ip (the world domination network of choice) then you have to give them all an ip address and then put those addresses into your world domination program.
mDNS makes this much easier. It's how Apple's Bonjour network discovery works. A device running mDNS is discoverable on a local network. You can find all the hosts and their ip addresses, along with the services they are providing and the ports. Windows 10 provides a Watcher service that you can use to discover all the machines on a local network, but it is a bit of a pain to use.
So I've written a tiny mDNSManager class that you can use to create and manage a watcher object which will start a search for devices, tell you when it finds one and also present a list of all the devices it has found so far. It's very easy to use.
You can find the source code for both the manager and a simple demonstration application on GitHub here.
If you want to just use the manager in your programs you can install it from NuGet:
Install-Package RobMiles.mDNSManager
It works on any Windows 10 device, including the Raspberry Pi, and it makes it much easier to connect to a large number of devices. There are mDNS samples available in the example applications for the ESP8266 devices in the Arduino IDE.
I'm using this to allow me to create a Universal Application that will control a bunch of HullPixelbot devices without needing to know their ip addresses in advance.
I bought Visual Micro a while back. Not that I really needed to. The free version is actually plenty powerful enough for day-to-day use. It was just that I thought the product was so good that I really should support it.
For a registration you get a key that works on three machines. I've been through a few machines over the years (as you do) and last week I found that my key didn't work for my desktop. I emailed them, they cleared the key and I'm back in business again. Thanks folks.
If you are in any way serious about embedded development you should get this tool. The free Arduino SDK is OK for a while, but you'll fairly quickly hit limitations that will grate, and with Visual Micro you get all the lovely intellisense support and general niceness that comes with developing code in Visual Studio.
Visual Micro now works with all the esp devices and pretty much anything Arduino shaped as well. It's got some very interesting debugging support too, but I tend to rely on code instrumentation (print statements) when I'm writing embedded code, so I don't use it very much. Go get it.
We got the latest copy of the C# Yellow Book back from the printers today. We had a whole bunch of copies printed for the new first year course, and to give away on Open Days.
This is the "Cheese" edition. The changes are mainly evolutionary. Thanks to everyone who contributed comment and pointed out mistakes. The pdf version will be going live later in this week. Then I'll update the Kindle version.
The title says it all really. I got all excited about the new release of Visual Studio and so I upgraded my copy of Visual Studio 2015 Community Edition immediately. The upgrade has some nice new features (and I want to use it to write Xbox One programs) but it did do one thing that confused me for a little while. It clears the source setting for Nuget.
The result is that all your Nuget fetches fail. However, it is easy to put back again by going to Tools>Nuget Package Manager>Package Manager Settings and setting the checkbox as shown above.
If you've not heard much about Snaps (my library that's designed to make it easy to learn to program C# which I'm using in a forthcoming book) then that's because I've been too busy writing the book (and the Snaps) to tell anyone about it. But today I built some Snaps that I'm really quite proud of. I've now got a tiny sprite library and a gamepad which you can use to make 2D games. I'm going to use it in the chapter where we talk about class hierarchies.
It's not a particularly fancy engine really. It runs inside a Windows 10 Universal application and uses all the XAML display elements. Having said that, I can get reasonable performance on my machine which has no graphics acceleration and it even runs on a Raspberry Pi.
For learning to program (and of course for Cheese Lander) it's absolutely perfect.
I've been playing with nuget.
It's awesome.
It is fantastically easy to package up an assembly and make it available for just anyone to use in their applications. It is beautifully integrated into Visual Studio and I reckon it is actually easier to download a package from the other side of the world and make it part of your solution than it is to add one that you have written yourself on your own machine.
To practice I've packaged up my Bluetooth Manager library. This is a little wrapper class that makes it really easy to use Bluetooth on Windows 10 applications. I've not tried it on Windows 10 on Raspberry Pi (but I've tried it on lots of other systems and it works fine). You can find out a bit more about it here. I use it so that I can print message on my little home made Bluetooth printer, but you can use it anywhere you want to talk over a Bluetooth serial connection.
Oh, and in case you are wondering why it is version 1.0.1 and not version 1.0.0 I found an interesting quirk in nuget. If your library class doesn't have a public constructor the package will fail to work because Visual Studio will complain that the class is "Inaccessible due to its protection level.". That's what happens when you try to use version 1.0.0
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.
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.
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.
I was giving a Software Engineering lecture this afternoon and the conversation turned to testing. As it frequently does. So I asked everyone what they thought I meant by the word "test". One answer came back "it's what you do to see if it works".
I don't think that's what I'd call testing. I was casting around for a phrase that fitted the occasion. Finally I came up with "Playing with the code". I wanted to get people thinking that actual testing is a lot more than just running with the program to see if it seems to do what we want. .
Proper testing is planned, repeatable and part of the creation process. And, if possible, automated. Don't make the mistake that the thing you do once it compiles is testing. It isn't.
I remember BetaJester from our early Three Thing Game events from way back. And now they've formed a company. Adam has written a nice article setting out three things startups should know.
One thing that got pretty heavy mention at the MVP summit was Visual Studio Code. Turns out this is awesome. I reckon that if aliens ever come to earth it won't be to steal our water or turn us all into their slaves or whatever. It will be to get hold of Visual Studio. It is the best place in the universe to write code.
Visual Studio Code is a lightweight development environment that takes the essence of the Visual Studio development process and makes it work on Lunix, Mac OSX and Windows. It is designed to be extensible, so that you can create bindings for your own development process and programming language (although there are lots available already). And it's free. Great stuff.
Perhaps by beaming the installer out into space we can save ourselves an alien invasion or two.
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.
Rob Miles is technology author and educator who spent many years as a lecturer in Computer Science at the University of Hull. He is also a Microsoft Developer Technologies MVP. He is into technology, teaching and photography. He is the author of the World Famous C# Yellow Book and almost as handsome as he thinks he is.
Begin to Code with JavaScript is now available for purchase and download. You can find it here
