This is what Dall-E thinks old software looks like running on a new computer
Hot on the heels of building code from ten years ago I spent a chunk of today installing the Visual Studio 2015 build environment and Windows 8.1 SDK. And they still work on Windows 11. Which is actually very impressive.
The text in red is just the REPL code in ThONNY getting upset…
I love typing in interactive commands to the MicroPython REPL console. It makes development much easier as I can test out program constructions and even view the contents of variables after I have interrupted the code. But the problem is that I lose the REPL console when the program starts running. MindReader fixes that. It lets you type in Python statements which will be executed as your program is running.
To use it you add the MindReader class to your program. Then make an instance of the class (I called it m) and call m.update() in your program at regular intervals. The update method scans the serial port and builds up a command. When you press return it executes the command. This means that you can still type in REPL commands when your code is running, which is neat. You can enter print statements to view variables or even modify them for testing. I’ve found it very useful. You can find the code on GitHub here.
Working work in progress
I’ve spent the last week trying to get an ESP8266 device to host a configuration web site for my Connected Little Boxes. It’s proved to be quite a challenge (see Monday). I had the worst possible fault. One that only appears every now and then. And causes the whole thing to just crash.
In the end I decided to go back to first principles and run one of the example applications in a brand new project. And it worked a treat. That’s good because I now know that what I’m trying to do is possible (always useful knowledge) but bad because my code still doesn’t work. In the end I migrated all my code into the working example and went from there. In the process I discovered that, for whatever reason, the code I had been using was based on very old driver code for the device. Early versions of the ESP8266 libraries were known to be a bit buggy and unreliable. I thought that mine had been updated as part of the normal behaviour of PlatformIO (which I’m using to build and mange the app). This turned out not to be the case.
So - if you’ve got problems that you don’t think are your fault, it might be worth checking to see if you are using the latest version of the libraries for your product. Of course, new versions also bring new bugs of their own, so make sure that you keep copies of the old version too…..
This post is for all the old-timers out there who have fond memories of the MS-DOS command prompt and have bother remembering all the new-fangled (but awfully powerful) PowerShell commands in Windows. You can get back all your command prompt goodness by with the command cmd, which starts a command processor with all the old style commands. As you can see above.
I’ve just had to use this when while deploying a web application to a Linux-powered device. I had a bunch of image files that had the extension “.jpg” which were referred to in the code as “.JPG”. The Windows filestore doesn’t mind this. But Linux does. So all my image links were broken. What I wanted to do was rename all the extensions. You can probably do this in PowerShell. But I can definitely do it in MS-DOS:
rename *.jpg *.JPG
So it was in with the old, out with the rename and the site now works. And I, not for the first time, must try to focus on greater consistency in my coding….
I’ve long been convinced that communication skills are crucial for engineers. Actually, I think they are crucial for everyone, but their importance needs to be sold to us techies. We tend to focus on solving the problem rather than telling people what we have done and why it is a good idea. In my experience an engineer can make themselves around 10 times more useful simply by learning how to communicate properly.
And the critical message for an engineer is that presenting is a skill that can be learned. I used to tell students that they should approach being able to present well in the same way that they would learn a new programming language or application programmer interface (API). In other words, find out how to do it and then do it.
It’s lovely to see that other people take this seriously too. Clive Maxfield and Lucy Rogers have some great things to say about the importance of presentation and how to do it. Both are splendid folks who are well worth following.
Last night I was doing some work on the PICO MIDI cheesebox when I found a bug in the way that note values are assembled when the box is generating random tunes. I came up with a quick fix and opened up the relevant part of the code. And then I stopped. I was wondering if, in the absence of a commercial imperative (after all, nobody’s business is hanging on this code) I should be wading in just right now. Perhaps it would be better to sleep on it and then fix it in the morning.
I put the question to Twitter, and got a variety of replies. I didn’t make it clear that the bug was not affecting anyone else at this point and so quite a few folks pointed out that in a production situation you would triage the bug (decide how important it is) and then either drop everything and fix it or roll it into the next release. Or, of course, live with it. All good stuff. But if the bug appears while you are creating a solution you have a bit of wiggle room when deciding how best to fix it. And I think you should sleep on it. As long as it won’t keep you awake…
Having left the bug and slept on it, I decided that the way the bug manifested itself reflected my poor understanding of how the program should work. To properly fix the bug I’d have to re-structure part of the code. So I did that, and the solution is much better as a result.
I’ve had this kind of experience many times. It seems that to find out how to really write a piece of code you have to write it. No amount of up-front design work shields you from this. And when you write it you must expect to have to change the structure and content of the components. I view this as a kind of battle between warring factions. As I write the code and build my understanding of what I’m trying to do I find that the objects in my solution grow and shrink. A class you think will be pivotal can shrink in importance while a “young pretender” can emerge and take over. So I don’t regard discovering bugs like this as a problem, they are part of the process. So give yourself time to deal with them properly.
This may sound crackers, but bear with me here. Sometimes I do something and it just works. It’s a rare thing for me, but when it happens I always feel a little nervous. Because I’ve not learned anything about what I just did. I can write in my diary the steps that I took but if they don’t work next time I’m in a mess.
I’ve just had this experience again. A few months ago I deployed an JavaScript Express application to Heroku. The process was really quite smooth, and I've totally forgotten about how to do it. Today I wanted to repeat the process and of course it all fell to pieces. Something, somewhere has changed and I’ve no idea where to go to fix it. If I’d had to battle with the first installation I’d be able to draw on a pile of resources to try and fix the problem. I’d know how to read the log files, get messages back from the code, deploy updates and whatnot.
I think that what I’m really saying here is that for a lot of things I try to do with computers I have to go and “live there” for a bit. This means spending time reading documents, writing test code and generally figuring out where all the bodies are buried. If something works first time I’ll not do that, so I’m building up a store of “ignorance debt” that will come back and haunt me later. The good news, I suppose, is that now I seem to be a situation (at least with this project) where I’m going to get a good opportunity to live with Heroku for a while.
When I was doing programming lectures I used to go on about how creative programming is. I also make the point in the introduction to my latest book (subtle plug). I’ve just spent all of today proving the point. The weather has been horrible, so we were forced to stay indoors and do stuff. So I wrote some more code.
My silly little PICO music box can now store multiple rhythm tracks which can be made to run at different speeds. It has a full setting editor using coloured pixels. I rather enjoy playing with it to make little looping sound sequences.
It’s a strange and wonderful feeling when something that you are making starts to take on a life of its own. I’m sure that artists and musicians get it, programmers get it too. Big time.
One little tip for developers. Keep track of what your project can actually do. Otherwise you will find yourself trying to implement the same feature twice. Although I guess this might just be me.
I’ve spent most of today fixing bugs in my software. I didn’t find them myself. Brian fell over them when he was kind enough to have a go with the latest Connected Little Boxes version. I actually quite like fixing bugs. Every one I fix makes the program better.
In a post a while back I surmised that if weird things are happening it is because of a problem with the power supply. It’s still true.
I’ve decided to add a printer to my Connected Little Boxes. I thought it might be fun to be able to print little messages on paper. I dug out my little printer and connected it a Wemos device. I did a tiny test and it worked fine. So I set to and built a printer module into the Connected Little Boxes framework. And it didn’t work. That’s not actually surprising. I’m deeply suspicious of code that works first time. It usually means that I am due a bunch of pain further down the tracks. This time it looked like I was getting all my pain up front, which is fine with me as long as I can fix it.
I did some tests and it looked like a buffer/timing problem. Short strings printed fine. I could print“12345678” but if I tried to print “123456789” it failed. The buffers were all the right size, the logging said the printing had completed OK. The little lights that I had connected to the printer data signals all flickered hopefully. The only thing missing was printed output. Wah.
I did what I usually do when I hit a problem like this. I went and had a cup of tea. I’ve discovered that if you hit a problem where the universe seems to be broken the best thing to do is walk away from it for a while. I’m lucky in that I haven’t actually got a customer waiting impatiently for the product and the printing feature is not the subject of a piece of my coursework that is due in (the other reason for fretting about deadlines).
After my second biscuit I’d figured it out. It was my old nemesis the power supply. The printer I’m using is thermal and prints a line of text all at once. The more you print the more paper it has to heat up and the more power it needs. I was powering it from the USB connection on my PC which can’t deliver much current. In fact, it delivers just enough to print “12345678” and no more.
I tested this by trying to print “1 2 3 4 5 6 7 8”. This is a longer string, but it needs as much heat to print as a shorter one. That printed fine. So I connected a proper power supply and off it went. As much string as you like.
It turns out that creating useful embedded devices seems to be around 80% setting storage and management. I’ve created a nice little setting manager that exposes the settings as C structures, stores them in EEPROM and allows settings to be updated via JSON messages or via direct commands. Settings are bound to the process or sensor that needs them and it works well.
I thought it might be nice to be able to make a complete dump of all the settings so that I can configure a device by sending them all once. This mostly worked. The mostly bit was caused by the way that the settings are stored in EEPROM as they are received. Writing to EEPROM takes quite a long time, certainly longer than setting information takes to arrive down the serial port. So my program loses track of the inputs and misses some setting values.
“No problem” I thought. I’ll create a new setting that tells my device not to persist the setting values as they are received. That way I flip this setting and receive all the values at full speed. Then I save all the settings after they have been updated.
I added the code and got it all going. It mostly worked again. This time it would store more settings but still lose the plot towards the end of the setting file. It took me a little while to work out what was happening.
The block of settings I was restoring contained an instruction to turn the setting persistence back on again. So, half way through downloading the settings the program promptly breaks itself…
I’ve got my two button game working now. It’s fun watching people play a game that you’ve made. They start doing things that you weren’t expecting. But sometimes you find out other things too.
The gameplay (press the red button if there are more red lights lit, blue if more blue) is simple, but I make the task more interesting by adding more colours and making the colours move around the lights. Then I thought I’d make the lights flash on for half a second and then off, so that the player has very little time to count them.
This actually makes the gameplay seem easier (at least for me). The brain seems to retain the information for a while so that you can work out the answer, even with a very brief look at them.
I think this is the basis of “flash cards” although I may be wrong. But it is a useful reminder of the way that you can start going down really interesting tracks when you start fiddling with games.
I like using regions in Visual Studio. They make it much easier to move around code. I’m writing C++ at the moment and functions and code blocks are automatically tuned into regions, which is nice.
If you want to collapse and open them quickly there are a couple of control sequences that you might find useful.
CTRL+M CTRL+O
This collapses all the regions. You can hold down the control key and press M followed by O.
CTRL+M CTRL+L
This collapses all the regions recursively. So if you have regions inside regions you might end up with just one line in the editor if you use this..
These sequences are toggles, so pressing them again will open all the regions. I find them especially useful when copying or moving code, in that you can select the collapsed region and it will select all the code in the region.
I’ve just turned on Two Factor Authentication for GitHub. It occurred to me that seeing as how GitHub is now my “weapon of choice” for organising anything, and I can make my own private repositories, I should take some steps to keep them private.
It’s actually very easy to do, once you have an app that can produce “Time Based On Time passwords” or TOTPS. I’m using Microsoft Authenticator. I figure that since Microsoft now own GitHub, it’s likely that Authenticator will work well with it.
This picture is one of mine. You can find it on Flickr
Had an email from a Peter who’s reading the C# Yellow Book at the moment. He asked about how to learn more about software engineering. I quite like my reply, so I’m putting it in my blog….
I worry a bit about too much emphasis on "software patterns". I just tend to write code that solves the problem, and then discover afterwards that I've used a particular pattern. Things like "dependency injection" just seem like programming common sense to me, but then again I have been programming for a very long time.
By all means read up on the different patterns, but do it from a perspective of refining your technique, not finding a quick solution to a problem. If you use a pattern without understanding how it really works that can end badly.
My strong advice is just to keep writing code. Build your knowledge and develop a habit of looking at existing systems and trying to figure out how you would make them work and what design decisions were made when they were created. If you do it right you’ll be learning new stuff and having new ideas all the time. I still am.
A lot of programming and software design is down to practice and experience, just like any other field. And you also need to remember that any working system is built up of compromises and that it is very rarely that you will find the best solution. You might find the fastest, or the smallest, or the quickest to build, but not the best. So decide what kind of “best” that you want, and go for that.
I've spent a chunk of today improving the Hull Pixelbot software. The improvements were identified when I was showing off the software at the hardware group last week. There's nothing like showing off your stuff to flag up faults and issues in it. Things that seemed like carefully thought out design decisions turn out the be horrible ways of doing things. And if you're lucky the person you're trying to impress will come up with ideas and suggestions that will make what you've building even better.
Perhaps you might be a bit afraid of doing this, but in my experience it makes a huge difference to the quality of a product to have someone take a look who hasn't spent ages living with it.
Today I found out something that I didn't know that Visual Studio could do. It can perform file comparison. This is really useful if you've made a tiny change to a file for a very good reason at the time, but have completely forgotten where the change is, or why you made it. I never do this kind of thing myself you understand, but I've heard that some programmers make this mistake from time to time.
There are lots of file comparison tools out there of course, along with quite a few plugins, but it's nice to see that Visual Studio can do it right out of the box.
The only problem is that that finding the function is a bit tricky. You have to use the Command Window (which you open using CTRL+W, followed by A) or by selecting it from the View menu (take a look in the "Other Windows area if you can't find it).
Once you've got the command window you can type in the command Tools.Difffiles followed by the names of the two files you want to compare. There is some rather neat auto-completion of filenames which makes it a bit easier to navigate to the files that you want, and I love the idea of being able to type three f's in a row in a meaningful context.
Anyhoo, the comparison window that you get is rather nice, and it works well.
I've used Virtual PCs for quite a while. My first proper brush with the technology was when I was building and configuring Class Server systems. I found it kind of magical that I could have several "fake" PCs running inside my one real one. And I loved the way that if anything bad happened to the hardware I just had to spin up another PC on a replacement device.
I've started using them again. I'm writing a "Begin to code Python" book and I'm worrying about the installation documentation. It's important to be able to show the installation just as it would be for someone running Windows 10 Home Edition on their brand new laptop.
So I've built a brand new Windows 10 Home Edition installation on a virtual machine. Took around twenty minutes or so. And the beauty is that I've taken a snapshot of the empty machine, so I can easily "wind back time" to before the installation and practice it again.
I used a really nice guide which you can find here.
c4di is having some great evening events at the moment. On Monday we had CodePen, and today we had Joe Stead talking about future platforms for .NET development. Well presented and thought provoking.
Some interesting musings on how programmers are defined by the languages and tools that they use and how important it is to be looking at what's out there and developing professionally. Plus a look at some shiny new stuff.
I've come away with a list of things to investigate, and I'm pretty sure that most of the people there (and it was a good sized audience) were the same.
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.
Make your own programming language. Find out more here.
