Peter's Blog

Just commenting on things that interest me

Author: adminPeter (page 3 of 16)

Peter’s Programming Principles: Difficult things first

Year ago, I read a book on time management (or procrastination) called “Eat That Frog!”.

In the book the author, Brian Tracy, proposes that you should always tackle the most challenging task on your To Do list first.

Now I have not applied that principle in my life, but I have certainly applied it in my programming.

The first thing you should tackle when writing a program is always the part about which you are most unsure, or the part which the most risky.

It’s amazing how often I have asked a programmer “how did you get on with X” and they reply that they haven’t got to it yet because they decided to start with Y. And Y is often something which involves no risk at all (like settings, configuration, admin screens, or even a splash screen!)

Example

When I was working on the COVID program recently, I started with the things with which I was least familiar: the HTTP Client class first and then the JSON library. Once I got these working, then I knew that everything else would fall into place quite easily.

Conclusion

When you start a new program, always start with the piece which scares you most. Don’t waste days doing the easy stuff before discovering that there really is a problem with that scary piece.

Peter’s Programming Principles: Sleep on it

You often hear stories of programmers who work best in the evening or at night, or programmers who “pulled an all-nighter”.

I take a different approach.

When I am struggling with a piece of code (a bug I cannot track down, for example) I call it a day and sleep on it. I am still amazing at how often I find that I will awaken with a solution.

They say that the following happened in dreams:

  • Dmitry Mendeleyev came up with the periodic table of elements
  • Dr. James Watson came up with the double helix structure for DNA .

Now I have never done anything as earth-shattering, but here are two recent examples from me.

Example One

I wrote a COVID-19 app recently and I was struggling with the HTTP Client class which I was using to interact with the API to get the data.  The documentation for the class was pretty light and I could not find any sample code. The problem I was having was specifically in relation to the callback function.

I was having so many problems that I decided to try the Websocket Client class instead. I was struggling with this too.

But when I woke up the next day I was sure that I could get the HTTP Client to work without using a callback and that is exactly what I did and it worked for me.

Example Two

My daughter was doing a project for her university course which involved designing the hardware and software for a networked automatic hand sanitiser dispenser. I wrote some pseudocode for the software which monitored the proximity sensors and the liquid levels.

The code had a check for thresholds on the liquid levels and could send alerts as these thresholds were passed.

I realised that there might be an issue where (due to slight fluctuations in the readings) the liquid level might seem to cross back and forth over a threshold and this would trigger multiple alerts.

Since this was just pseudocode for a project which would never by built, I decided not to worry about it.

But when I woke up the next day I realised that a simple tweak would fix this.

So now when I get a new reading, I check it see if it is greater then the previous reading. If so, I check to see if the increase is about a configurable threshold (min_increase). If it is not greater then min_increase, then I just set the new reading to be the same as the previous reading. Job done!

Conclusion

If you are struggling with a design or coding problem then try sleeping on the problem.

Peter’s Programming Principles: Shibumi

The first two principles for good programming were Simplicity and Elegance.

But there are not independent. The aim must be to write code which is as simple and elegant as possible, while getting the job done.

Shibumi is a concept I came across in the book of the same name, written by Rodney Whitaker in 1979 under the pen name of Trevanian. I mentioned this book (which is my all-time favourite) in my old blog.

It is a Japanese word with a number of meanings, including “elegant simplicity”. Here is a passage from the book:

Shibumi has to do with great refinement underlying commonplace appearances. It is a statement so correct that it does not have to be bold, so poignant it does not have to be pretty, so true it does not have to be real. Shibumi is understanding, rather than knowledge. Eloquent silence. In demeanor, it is modesty without pudency. In art, where the spirit of shibumi takes the form of sabi, it is elegant simplicity, articulate brevity

When Nicholai Hel (the hero of the book) heard these words, he decided to dedicate his life to achieving Shibumi.

I’m afraid I have not dedicated my life to Shibumi, but I do look for Shibumi when I am programming.

In programming, Shibumi is thinking about a problem until a simple elegant solution is uncovered, and then coding accordingly. Whenever your design or code seems complex or convoluted, you need to do some more thinking.

Peter’s Programming Principles: Elegance

Programming is an art, not a science. Some people might baulk at the idea that it’s an art, but it is certainly a craft.

Bad programmers write bad code, great programmer write elegant code.

I have read a lot of code in my time. And some of it was so badly written that it was scary.

Conversely, it is a pleasure to read code that is so well-written that it is elegant.

Writing a program involves making dozens (or hundreds) of decisions. It involves solving lots and lots of puzzles.  Solving puzzles is one of the great joys of programming. There always multiple ways to tackle each puzzle. And each decision is an opportunity to move towards elegance, or towards chaos.

I don’t think everyone can be a good programmer. I have worked with people who wrote chaotic code. This code was a nightmare to read, and a nightmare to maintain/enhance.

Some people have the gift of finding the elegance, and some do not. That’s what separates bad programmers, from good programmers, from great programmers.

In my opinion, a great programmer would not be happy just to get a program working. They would not be happy until the program is elegant.

I think it’s acceptable to write a small piece of inelegant code while you’re trying to get something working, or to understand it fully. But once you have that clear picture, you should always rewrite/refactor for elegance.

A simple example of the decisions which a programmer needs to make is when functionality should be delivered inline, when it should be moved out to a separate function/method, and when a new Class is needed.

Elegant code should be easy to read and understand. Badly written code can be a nightmare to understand!

First Example

I have a book called “Java Examples in a Nutshell” (written by David Flanagan) which I cannot throw out (even though it is dated – my edition was written in 1997) because the code is so elegant. Each of the programs is as simple as possible, while illustrating the technique in question. Almost all of them have a “main” method and most of them process simple argument so that they can be called from the command line.  One, for example, is called “SimpleProxyServer” and it illustrates a simple web proxy which has one thread for passing on outgoing content, and another for passing on incoming traffic.

Second Example

This is a link to some Java code which implements the Asteroids game as a Java Applet (it was written a long time ago!)

It is a very faithful recreation of the original game and I think the code (although there is quite a lot of it) is very nicely written and very easy to read.

The main look contains the following:

updateShip();
updatePhotons();
updateUfo();
updateMissle();
updateAsteroids();
updateExplosions();

Makes sense right?!

Aside from the main Class, there is only one other one: “AsteroidsSprite”. This is used to manage all of the “vector graphics”-style objects.

The Class has a method called “isColliding” which takes one argument which is another AsteroidsSprite. So you can easily ask any AsteroidsSprite if it is colliding with any other AsteroidsSprite. Simple as that.

And there is a method called “explode” which takes an AsteroidsSprite as an argument. It creates a set of AsteroidsSprites, one for each line in the original object. And then those  AsteroidsSprite are added to an array called “explosions” and those lines move and fade as they would have in the original game.

In the hands of a less capable programmer than Mike Hall this could have been a real mess. But it’s not. It is elegant.

Conclusion

The difference between a mediocre programmer and a great programmer is that the latter can make a series of decision which allow him/her to write elegant code.

 

Peter’s Programming Principles: Simplicity

KISS (or “Keep it Simple Stupid”) is a principle which was created in the 1960s apparently.

Certainly it was something we talked about when I started programming.

It is as true now as it was then.

Apparently Einstein said that ““Everything should be made as simple as possible, but no simpler.” He was a smart guy!

The trick in programming is to resist using something because it’s clever, or because it’s new, or because it’s trendy.

When something is simple, it easier to get right, it’s easier for others to understand, and it’s easier to maintain and enhance.

I have two stories to illustrate this: one new, and one very old.

First Story

The old one was when I was working in Shield Life and going to Trinity College in the evenings.

On my course I learned how you could create files where each record had a pointer to the next record (and optionally a pointer back to the previous record). So when you found the first record in a set, you would easily navigate to the others. And you could have another chain of free records which would could use when you needed to create a new record.

So we had a requirement for an “Outstanding Premium File” (OPF) which would store all of the premiums which made up an individual Direct Debit for the bank. Then if the Direct Debit was declined, you could work out which policies had not been paid so that you could take appropriate actions. I decided that this was a perfect use case for a file with record pointers.

I developed the program and it worked perfectly.

The problem was that, after I left the company, the team decided to re-develop the program using a more traditional approach which everyone could understand and maintain.

So I had ignored the KISS principle and I had developed something that other programmers did not like. I had been seduced by something that seemed to be very clever.

Story Two

The second story is recent. We were developing a solution using SharePoint Online, SPFx, Azure, etc. and the architect and developers decided to use a Term Set in SharePoint to hold data which could have been held in a lookup list.

I could not understand the purpose of using a Term Set for this. Term Sets have an important role to play in some circumstances. But to me it looked like complete overkill for a lookup field.

And it turned out that it introduced a number of unnecessary complexities:

  • We needed to have separate term sets for test and production. Using lists, it would have been as simple as having two sites and independent lists in each.
  • We had to add values to lists using PowerShell and these scripts were made more complex and more troublesome because they had to populate the term sets
  • The client wanted to export the data to Excel. We used the native export at first. But the term set columns were weird when exported to Excel. In the end, we did a custom export.

Conclusion

Einstein was right: it’s best to keep everything as simple as possible, but no simpler

 

Peter’s Programming Principles

I have been developing software for a long time. And over those years, I have come up with an approach to programming and some basic principles.

These are now part of my “gut feeling” when I’m developing something new. But in the coming posts I am going to try to isolate, examine and document them.

I’m calling this series “Peter’s programming principles”. There are a couple of things to say about this:

  • I could not resist the alliteration!
  • I’m not sure when exactly “programming” became “software development”, when “programmers” became “software engineers”, and when “programs” became applications/apps. But I think the old names were just as good.

The principles are all high-level. They are about an approach. If I talk about a specific technology then it will only be to explain the principle.

The principles I am going to describe are:

  • Simplicity
  • Elegance
  • Shibumi
  • Sleep on it
  • Difficult things first
  • Layering
  • Event-Driven
  • Data-Driven

 

COVID-19 Sketch

Wanting to do something challenging and interesting on my IoT DevKit, I decided to do something with a COVID-19 theme (we have so little else to think about these days!).

My idea was simple: to get some statistics from the web and to display them on the built-in screen.

The first step was to choose a suitable API. I chose the “Novel COVID API“.

This API returns data in JSON format. So I need to choose a suitable library for parsing the data. I choose the ArduinoJSON library.

The next step was to decide how to present the data. The device only has a 4 line display with 16 characters per line. So I ended up creating a series of screens to show the data for each country, trying to group the data logically. Because the first line is a different colour, it was fairly obvious that I should reserve that for the country name.

The last step was to decide how to control the display. The device just has two buttons: A is on the left and B is on the right. I decided on the following:

  • You would press button A to move from one country to the next one
  • You would press button B to move from one screen to the next one
  • You would press the two buttons at the same time to go back to the API to get fresh data

To be honest, I am quite pleased with the way the sketch turned out. You can see a video of it in action below. In the video you can see me viewing data for Ireland, USA, UK and the world.

The data which is shown is correct for today: 17th May 2020.

You can access the code here.

MXChip IoT DevKit (AZ3166)

In late 2018 I attended an IoT training session in Microsoft here in Dublin. They gave us all a “DevKit” which can be used to experiment with IoT in conjunction with Microsoft Azure. The device was jointly developed by MXCHIP and Microsoft.

The device is like an Arduino except that it is packed with sensors and also has:

  • A small (4×16) OLED screen
  • A headphone socket
  • An Infrared emitter
  • Built-in Wi-Fi.

Here’s a diagram showing the various components:

And here is a picture of my device:

Because this device has so much built-in capability, I always intended to develop something for it.

And in my next post I will describe my first project.

Arduino Uno

I got my first computer in the 1970s (an Apple ][) and my second in the 1980s (an Atari 800).

I always had an interest in getting my computer to interface with hardware devices but I never really did anything about it.

In 2011 I came across the Arduino platform and I finally had a chance to use a device which straddled the gap between software and hardware. I bought a book called “Arduino Cookbook” and I learned all about “sketches” (software) and “shields” (hardware).

Later that year I bought the “ARDX arduino experimentation kit“.

To be honest, I spent a lot more time reading the book than I did playing with the kit!

In July 2012 I did bring both on a holiday to Kenmare and I managed to create a fairly interesting light display with 8 LEDs.

Included below is a video from that time showing how it worked.

I planned to add a potentiometer to be able to control the speed of the sequences but I don’t think I ever got that working.

Coronavirus, Leo Varadkar and Sarah Connor

So Coronavirus (COVID-19) has been dominating our lives for weeks and week now.

But we do have some control over what happens. We can choose to stay home. We can choose to wash our hands. We can choose to do social distancing.

And we are lucky (unlike some other countries) to have good leadership at this time of crisis. Leo Varadkar is doing a great job. So is Simon Harris. So is Tony Holohan. So are our front-line workers.

But my admiration for Leo Varadkar went up a few notches back in March when he used a line from the Terminator movies during a very serious speech. He quoted the line: “There is no fate but what we make for ourselves”.

At first I was astonished – I thought I must have misheard.

But no – he really did say it. Fair play to him.

Here are the speeches by Leo, Simon and Tony (the line is at 6:14):

« Older posts Newer posts »

© 2024 Peter's Blog

Theme by Anders NorénUp ↑