Category Archives: Development

Charts Development Web Development

HTML5 Canvas – Donut chart builder

Over the past couple of days I’ve been steadily making progress through Foundation HTML5 Canvas by Rob Hawkes. So far it’s a really great book, and I feel like I’m picking things up pretty rapidly (that’s a recommendation for you, by the way – seriously, if you’re thinking of learning how to use canvas, get it).

To test myself on what I had learned so far I decided to build a donut chart maker. It could just as easily have been a pie chart maker, but I wanted that extra bit of a challenge.


Before you say “don’t you hate pie charts, though?”, I’ll answer with a “generally yes, thanks”. I just figured it to be a decent challenge to set myself. A bar chart would have been relatively easy, I think (although I might have a go at some point in the future.

Now, I know I’ve probably not built it in the most efficient way, but I’m really pleased with progress so far. Basically, enter a comma separated list of values in the box and click ‘Go’ and a donut chart is built in the canvas space. Slice angles are automatically calculated based on what proportion each value is to the sum of all the values together.

Anyway, I just wanted to share it with you. My code is available on Github for those interested in looking at/critiquing/playing around with it. By all means fork it if you find something that you want to add.

I’m hoping to do much more with this in the near future, including maybe incorporating labels and percentage values into the chart, so do keep an eye out. I’m also thinking about how I could use the canvas element to create some other useful charts from scratch – it’s all exciting stuff!!



About 18 months ago I finished development on a system to track team project checklists.  The system was developed using MS-Access and VBA and, in terms of my own work, is one of my greatest accomplishments to date.  Since release we’ve only ever had one issue with the system and that was fixed in about twenty minutes.  Zero downtime, perfect performance and no crashes…awesome.

That is, until Monday.  I was made aware of a really strange error by one of the system administrators:-

“Multi-step OLEDB operation generated errors.  Check each OLE DB, if available.  No work was done.”

This error threw every time a user tried to update a field in the system that stored a file path/location, and hadn’t ever done up to that point.  I loaded up my development copy of the system and followed her instructions to recreate the circumstances that threw the error and, yep, it happened with me too.  Ok, not a local machine issue.

I ran the same routine and tested it with another couple of file paths and there were no similar problems, so it must be something to do with the specific file path selected via the file dialog.  As it happens, that particular file path was huuuge – the document was nested in multiple folders that seemed to go on forever.

Next step was to check the database field that stored the file path and, there in plain sight was the issue…

Originally, when first developed, the system was an Access UI with a link to a separate access database for the backend, but about half a year ago I decided to shift the entire database to SQL Server instead, for various (hopefully obvious) reasons.  The field type had been text with a 255 character limit, and that was the problem.  I had never anticipated that this particular field would need any more than the 255 characters the field would hold, but obviously I was very wrong.  I quickly changed the maximum length of the varchar field type to 1000 (just to be sure) and tested again.  Absolutely no problems.  Issue closed.  Bug fixed.  Yay.

It irks me that I never anticipated that this would happen when I originally designed the database.  I had always assumed that file paths stored in the system would be maybe only a couple of directories deep, certainly not enough to crash the system at some point in the future.  The lesson learned was a pretty harsh one which was this, I may not have anticipated this particular error, but it happened anyway and, whether you like it or not, no matter how good you are, there is likely to be something, somewhere, wrong with the stuff you’ve developed.

The answer to this may be that I just didn’t plan ahead enough, or that I’m a bad coder because I didn’t anticipate this or test for extremes, and in some ways I can agree, but my main point is this – we’re always learning, no matter how far we’ve come.  There will always be unexpected skeletons in our coding closet, its just a case of when they will crop up.  I’m more ready for them now, are you?

Development Web Development

Worried about learning something new? Read on…


Image source – Flickr

A couple of years ago I was faced with a bit of a personal quandary.  I figured that, to progress further in my career I would likely need to learn some new technologies other than Office products and VBA and settled on web development.  After about ten years of using just the one technology I started to worry a little bit and even questioned my abilities to pick up stuff I hadn’t really looked at before..  Now that I’ve been at it for a while I wanted to quickly post answers to the questions I was asking myself then:-

What if I get stuck?

You will.  Google, however, is your friend.  I have no developer friends and very little in terms of a support network for general web development and design stuff, but I’ve coped pretty well.  There hasn’t been a single question I’ve had that I’ve not been able to get the answer for myself through search or posts on sites such as StackOverflow.  In addition to that, there are a whole host of sites and tutorials that can point you in the right direction.  Getting involved in social networking is also useful!  Find well known people who are experts in the field and follow them – you’ll be surprised just how much you can soak up just by reading their tweets/status updates and reading links they provide.

What if I don’t get it?

You will.  The best advice I can give here is that the best way to learn is by doing.  Just reading an article on jQuery, for example, won’t teach you enough to be able to use it. You need to practise, make mistakes, fix them, and then practise again.  The only way to successfully pick up anything new is to keep at it.  Don’t stress out if you keep forgetting things, just keep on going back and repeating what you’ve already done.  It’ll stick, eventually, I promise.

What if the new stuff I’m learning makes me forget stuff I already know?

I worried about this one a lot.  Being reasonably proficient in VBA, I worried that learning a new language like Javascript would confuse me.  I was concerned that I would get the two mixed up and somehow start writing one when I needed to write the other.  It never happened.   The basic answer to the question is this – It won’t, as long as you keep on working at it.  Like anything, if you stop doing something and don’t come back to it for some time you’re more than likely to become rusty at it.  I was good with Physics, Biology and Chemistry at school but there’s no chance I’d remember how to do even half that stuff now if I was asked, but that’s because I don’t use it any more.  Keeping on using the tools you’re already proficient with will make sure you don’t forget the stuff you already know.  The new knowledge won’t push it out of your brain – don’t worry.

But there’s so much to learn!!

Yep, there is..  In fact, there’s probably more to learn than your brain has capacity to take in.  Don’t stress about it though – you can only remember/absorb so much.  I would suggest starting with the basics and as you progress you can pick up the bits you think you’ll actually need to learn.  For web development, for example, start with HTML and basic CSS and then decide whether or not you need to learn CSS3 (you do) and jQuery/Javascript (you should).  There are a massive amount of libraries, frameworks and techniques to learn that you’ll probably never need.  If there are some that you need only once, don’t go crazy about learning them completely – just learn the bits you need to go on with.  There’s also nothing wrong with using or tailoring something somebody else has used and made available online.

Whilst this post relates mainly to web development, it applies to pretty much any new subject that you want to learn.  My main advice to you?  Go for it.  It can’t do any harm, and broadening your horizons also has the potential to open up many more possibilities in life and your career.

Until next time..  Comments as always are welcome.


A cautionary tale about software testing (and cheap kitchen drainer baskets)

We recently bought this for the 2toria towers kitchen.

It’s….a kitchen drainer basket thing.  The one we had before was plasticky and rubbish so, whilst out shopping a couple of weeks back we saw it for a low price and decided to replace our old model.  It was a steal at about £2.99!!

And, it’s great.  It holds dishes and even has a handy plastic container bit that you can clip on to any corner.  Practical and useful – it does what it was intended to do.

Only problem is, it has a flaw.  If the plastic compartment is loaded with cutlery but there are no plates, it does this:

There was no safety note about overloading either…

This is a BIG problem, as you can imagine.  It doesn’t hold nearly enough things!!

The reason behind this post isn’t to tell you about my poorly designed kitchen drainer basket, but to highlight the potential of bad design and a lack of user testing when building anything (although I’m using the analogy for software development really).  When the original plans for this were put together, it probably looked great on paper, but the designers did one of two things:-

  1. They didn’t actually test their prototype before releasing for bulk manufacturing.
  2. They did test it, found this flaw, and decided to build and release anyway, assuming that users would just figure it out for themselves.

Either is a pretty bad thing.

Seriously now, I know it doesn’t matter too much in this case – after all it’s just a kitchen drainer basket. Imagine however that this was software and situations 1 or 2 came about. The compartment could just as easily be an interface to a database, or a routine that deletes or inserts records, and if that was flawed or untested things could really go wrong. It has happened before, and will happen again – some extreme examples can be found here (although admittedly not all are entirely the fault of poor testing).

The takeaway from tonight’s silly little story?  Test the things you develop before you release them into the wild.  Get your users to test them, and then test them again yourself.  Try to think of every possibility – try to break what you’ve just made in every way you can think.  Test until you can test no more, until it gets completely boring, and then test again.  If there is something wrong that you didn’t spot when your product is eventually released, let your users know what to do (or not to do) and (if possible) provide a workaround until you can fix the problem.  Do fix the problem however, and as quickly as you can.  Then, test that the fix works, and then test that your fix hasn’t unintentionally broken anything else.

Got it?  Here ends the lesson.

(There are lots of resources online about software testing, and too many methodologies to discuss in such a short post, but this Wikipedia entry is a pretty good starting point if you want to learn more.)