Category Archives: Blog

All blog posts.

CodeBug – Get one now!

A few days ago I was seduced by an offer for a CodeBug.
CodeBug

From the CodeBug.org.uk website:

“CodeBug is a cute, programmable and wearable device designed to introduce simple programming and electronic concepts to anyone, at any age. It is easy to program CodeBug using the online interface, which features colourful drag and drop blocks, an in-browser emulator and engaging community features. Create your own games, clothes, robots or whatever other wacky inventions you have in mind!”

It can also connect to a Raspberry Pi. Well how could I resist. All this for only £15. It was too good to be true, so I bought 2. They arrived on Monday. Today is Friday. Here is my:-

CodeBug Diary

Monday
CodeBug(s) arrived. Snazzy box. Unwrapped and took a look. Yes, it looks just like the picture. And comes with a USB cable, and a short instruction leaflet.

Visited CodeBug website and followed the get started instructions, watched the short intro video, which at less than 2 minutes shows you in real-time how to write your first CodeBug program, test it, deploy it to your CodeBug and finally run it.

(I didn’t believe the hype. This can’t be true. I tried it. It was!)

Within 10 minutes of opening the box I had a program up and running on the CodeBug. I understood the basics and had experienced a new programming language – Google’s Blocky (Err, actually Blockly – oops. Post updated.)

I thought, 10 minutes. Is that all the fun there is to be had from a CodeBug. Done that. Next.

But, hang on. The CodeBug has two buttons on it, which respond to program control. So my next program included a bit more logic, and used button presses to do different things. Displaying text on the 5*5 LED display. (Amazing to think that a 25 pixel display can actually display text.)

Then I wrote a program to animate a dancing bear. A very simple dancing bear I admit. This time using loops as well as button press logic.

I was beginning to be impressed with this little £15 device. So why not go further. On the website, which is clean easy to use, and has a professional feel to it, there are some learning examples. Next up is a Fruit Keyboard.

Apple Keyboard

I only had apples. So it was going to be a single fruit keyboard. A single key keyboard.

To make this ideally you connect a wire with crocodile clip ends to the CodeBug and the apple. I only had a jumper lead, so I snipped off one end, and wrapped the wire around one of the 4 input / output terminals. Then pushed the pin end of the wire into the apple.

I modded the program to display apple. The tested the program in the on-line emulator, to ensure that it compiled first, and second worked correctly. Happy with a quick test, and desperate to try it in the real world, I downloaded the program to the CodeBug and set it running.

Every time I touched the Apple, “Apple” was displayed on the LED display – scrolling across. This was the most immediate programming feedback I have ever had. I was very impressed at the simplicity of the CodeBug, yet how powerful and flexible it was, combined with a visual programming language and emulator, including cloud storage for all of my CodeBug programs.

This has been well thought through.

Tuesday
But there is more. A code bug can be tethered to Raspberry Pi, and using Python programs running on the Pi you can control the CodeBug. Effectively a program is downloaded to the CodeBug which then works as a client, whilst you run Python programs on your Pi – server, and communicate through the USB cable to your CodeBug. Client Server computing. With a CodeBug. Amazing.

I have to admit here to my first downer with the CodeBug. It plugged it in but it didn’t work. I spent a lot of time trying, but absolutely nothing was happening. I was obviously doing something wrong, but couldn’t work out exactly what. I was using a Motorola LapDock, powering a Model A+ raspberry Pi.

There are 2 ways to tether a CodeBug to a Raspberry Pi. Tethered, and Tethered with I2C, one of the interface standards supported by the Pi. The CodeBug also has expansion pins on its base and can be plugged direct into the GPIO pins on the Pi.

Nothing I tried worked, so I slept on it. Thinking that a bit of rest might help. Before retiring though, I ordered some CR2032 batteries, because the CodeBug can be battery powered so it can work without a computer connection – it really is quite an amazing little device, and I ordered a USB Cable with a switch on it so I didn’t have to keep on plugging it in and out to reset and download programs.

Wednesday
The power of sleep is amazing. If you have a problem, then stepping away from it for a while can sometimes help. Meanwhile in the background your subconscious carries on working on your problem.

Wednesday morning I decided to rebuild the Pi OS. I started with the latest Noobs (pi speak) build. And try again. So after installing Geany, a lightweight IDE for writing Python I was ready to go.

I plugged in the CodeBug to the GPIO ports on the Pi, then turned on the Pi. Before the Pi had finished booting a dancing bear was showing on the CodeBug LEDs. This made me realise that I had forgotten to download the tethering program, and that I probably needed to read the instructions a little more carefully.

In rereading the instructions I realised that tethering comes in two flavours on the Pi. Firstly, and I had missed this, partly in my haste, that the first tether mode I was attempting was using a USB cable. However I had plugged the CodeBug into the GPIO pins. So USB tethering was never going to work. But i2C tethering through the GPIO pins should have worked. So the software refresh wasn’t a waste of time, but I also needed to read the instructions more carefully.

USB TetherThere were 2 references to connection via a USB cable. In a picture, that doesn’t actually show a Raspberry Pi, and then on the last line of the overview text of the example.

The examples are very good, and well documented. I admit I rushed, and didn’t read the single reference to USB tethering.

Lesson learnt: Use the latest build, and read the example text – thoroughly. Yes, I think that the USB tethering line could have been more prominent in the example, but there was a picture as well, and I had missed 2 clues!

Once plugged in, via a USB cable, I followed the example python scripts and all was well.

Scroll

Python code to scroll text on CodeBug

But that is the thing with CodeBug, you then think, “well I want to scroll some text like Blockly does“. Ah ha. When you write in Python the CodeBug tether library does not provide a scrolling program. So you have to write your own. An example is given, but it is more fun working it out from basics. The way you get text to scroll is by adjusting the pixel map start point. You display the same text over and over again, just decrementing the starting column, from 0, down to a minus value that is 5 (for five columns you have to scroll across) times the number of characters in the string. Therefore “Hello CodeBug!“, is displayed from column 0, to column (0 – (14*5)=  – 70), in decrements of -1.
(NB. Longer lines of text seem to scroll slower!)

I2CPi

CodeBug connected to RasPi GPIO

Then it was on to trying out the direct GPIO connect and the I2C interface.  This means connecting the CodeBug directly onto the GPIO pins of the Raspberry Pi. Something that should always be done with care. And note that you should never connect power from the GPIO Pins, and either battery or USB. There is a warning on the page, but others seem not to be reading all of the text, just like me . . . .

 

I followed the scrolling digital CodeBug clock  example. The python program gets the current time and date from the internet, then formats the time and date outputs and sends them to the CodeBug, scrolling them across the LED. I slightly modded the program to display the short month rather than digits, (%b not %B). On my Model A, it displayed the Time then Date almost exactly twice a minute. To within a fraction of a second.

I only experienced one small problem. I set the scrolling time parameter to 15 (15 seconds), not .15 (point 15 of a second)  which meant that the display stood still for 15 seconds and would have taken approx 20 mins to scroll the time string! Ooops.

I was pleased that I had overcome the initial problems, software and not reading the instructions properly. And now could think of lots of things to do with the CodeBug, RasPi and Python. I think tethering via USB might be more useful than via the GPIO pins, but it is a useful capability.

Thursday
BlockyBeing quite taken with Blockly I decided to investigate further. Following the links I eventually came across the Google Developer Pages for Blockly and the instructions for installing Blockly on your own machine here.

Now thinking about how to get Blockly onto RasPi, and get it to generate Python code.  This sounds like fun. Start small. One step at a time. Then when I have learnt enough, completely revise the architecture and start again 🙂

The CR2032 batteries arrived meaning that the CodeBug can be used without plugging into a computer. This just worked!

Friday
The USB leads arrived. I had bought the wrong ones. No data cable! They only provide power to the CodeBug, but don’t do data exchange. Oh well. Out with the soldering iron to make the lead I really wanted. Should have read the small print. These will be recycled to use with Raspberry Pis.

Write this blog post as a way of documenting the CodeBug experience and start to think of other things to do with the CodeBug. I am definitely going to try the ‘get coding in under 2 minutes’ out on some friends 🙂  And the fruit keyboard – the tactile immediacy, having written the code, seeing all the wires, is great fun.

And I am thinking of doing more with my CodeBug. I bought 2. I gave the other one to my wife. She’s got the bug as well! In fact she got going a little quicker than me. Obviously reading the instructions more carefully!!!  A lesson to be learnt there no doubt?

One project I want to try is to tether 2 CodeBugs to the same computer, then scroll a message across both CodeBugs, so that it appears as if the text is crossing from one to the other. If I get that going I will add a video, so watch this space . . . .

CB Detail

Finally
I am very impressed with the CodeBug. It is immediate. It is tactile. It is fun. But I am not only with impressed with the device, but also the complete environment surrounding it. The interactive, visual, development environment, including compiler and simulator is great. The Cloud storage of your code is excellent. The price, £15, is fantastic. The examples are easy (ish) to follow – as long as you actually read them and not skip ahead. It is a well designed system, which just works.

If you have read this far and haven’t already ordered a CodeBug, then stop reading, and buy one now.

 

 

A Measures & Metrics Hierarchy?

Abstract:

This session has been inspired by following the journey of Solar Impulse 2 (SI2), an aeroplane powered only by solar power, as it circumnavigates the globe.

In June this year SI2 flew non-stop 5,663km from Japan to Hawaii. It took 6 days, using only solar power. The pilot sleeping in 20 minute naps, flying above and around weather systems, whilst travelling at around 30 knots, between 4,000 and 30,000 feet in altitude.

SI2-s

SI2 Landing in Hawaii

It sounds remarkable now describing the feat which smashed all solar powered flight records.

What was even more amazing was as the plane flew it transmitted real time data back to the control centre in Monaco, and the information was then published, live and real time, on the internet at solarimpulse.com.

This got me thinking. Firstly, wouldn’t it be amazing if our software testing projects could broadcast live, real-time metrics and measures just like Solar Impulse? And this must be easier for us to do because we are not high over the middle of the Pacific Ocean, linked only by a sat phone?

Images used by kind permission of SolarImpulse.com

Secondly, of the 14 key measures and metrics that were being displayed, some were fundamental flight and safety related. Always good in an aeroplane to know your; altitude, speed, and attitude. Some were flight plan related, in terms of direction and timing. And others were more inspirational, such as a view of the overall world circumnavigation. Not needed on a second by second basis, but giving overall context to the journey.

And that was when I had the thought that where we often struggle when producing software testing measures and metrics is that we mix up the safety with the inspirational, the planning with the performance.  Which may be why some people are against measurement, because they are stuck in a loop of safety measurement driven by fear. And others think that measurement and metrics can only be achieved as a complete end-to-end program of works, putting off all but the keenest of measurement disciples.

What software testers may find helpful is a hierarchy of software testing measures and metrics, along the Maslow lines of; Physiological, Safety, Belonging, Esteem, and Self-Actualisation.

Maslow

Maslow’s hierarchy of needs – Wikipedia

Knowing which measures address which needs on our projects may help save us from; life in the dark with no measures, producing the wrong ones at the wrong time, or being driven by measures and metrics rather than using them as tools to help us test software.

That could give us a new appreciation of what each of our favourite measures and metrics, S-Curve, Bug Count, Velocity, DDP, Coverage, Defect Heat Map, Burn Down Charts, <insert your favourite measure here>, etc., is achieving for us on the Maslow Hierarchy. And maybe an understanding of what each measure or metric we use is actually doing for us, where we may be misusing them, or where we may wish to use them in the future

Of course this may not work. But I think it is better to try and understand what our software testing measures and metrics are doing for us, than to either blindly generate screeds of impenetrable charts and numbers, or worse still, not produce any at all!

Downloads:

 PowerPoint Show    PowerPoint show (6.6mb)

Presented at:

1. UK TMF, London, Oct 2015.

UK TMF Session Outputs:

Below are the output flips from the session and the resultant hierarchy.

PNG  Flip 1     PNG  Flip 2    pdf  Hierarchy

References:

https://en.wikipedia.org/wiki/Maslow%27s_hierarchy_of_needs
http://badgerscroft.com/home/7-key-measures-for-software-testing/
http://www.solarimpulse.com/

RasPi ‘Selfie’ Tweet Cam

I recently ran a workshop, with my good friend Phill Isles, at the Test Management Summit. The subject was Testing the Internet of Things: The Dark and the Light.  One of the things that we wanted to do was demonstrate a live Internet of Things device, that the delegates could actually interact with, see how it works, and begin to understand what IoT means.

Tweet Cam

Tweet Cam

So I thought I would build a Raspberry Pi Tweet Cam, that the delegates could use to take selfie’s.

It would need a Pi Camera, obviously. Then a button to press to take the photo. An LED to show the user what was happening. And finally another button so that we could turn it off.

The aim was to run headless, i.e. no monitor, keyboard or mouse.

Finally it would be equipped with a Wi-Fi dongle, to enable it to connect to the internet and Tweet.

A fun Raspberry Pi project. I mostly used the instructions for Tweeting from Alex Eames RasPi.TV site (which I find extremely helpful). Details can be found here RasPi.TV Taking and Tweeting a Photo. Then added my own design and functionality.

I needed some parts:

  • Model B+ (Tick)
  • Pibow Coupé Case (Tick)
    The pi looks great in the coupé case.
  • Breadboard Base for Pibow
    Which replaces the bottom layer of the Pibow Coupé case and gives a larger platform onto which a half-size breadboard can be affixed.
  • Some buttons.
    I got ones with round and square tops.
  • An RGB LED.
    Why install three LEDs when you can fit one that does all three colours. You still need 3 input connections though – one per colour.
    (You can then mix the inputs to create additional colours – Tough to do in an individual bulb!)
  • Resistors (Tick)
    I didn’t quit have the right resistors. I managed to use two in parallel.  And ordered a jumbo multi-pack of 2,000.
TweetCam Top

TweetCam from above

The Build. Once all of the parts had arrived, I thought on the matter for a few days.  When I had a rough idea of what I was going to do I started the build.  I used a rapid prototyping approach.

First I assembled the Pi in the coupé case extended with the breadboard base. Connected the camera using a simple flexible mount which plugs in the audio socket. (The mount works, but is a little loose in the socket – holds the camera just fine though.)

I then added a resistor, button and some wiring to the breadboard, and some jumpers to connect the breadboard to the Pi. Wrote some code to detect the button press. Then added code to taka picture when the button was pressed.

Next step was to add the RGB LED. There were no instructions for the RGB LED on the vendors site. I e-mailed them, and they responded with a two page .pdf, which had the orientation, and forward voltage. Not all RGB LEDs are the same. A simple internet search shows that.

After following some on-line guidance I connected the RGB LED, adding a resistor to the Red bulb. Then wrote a simple LED test program. When that was working I updated the TweetCam code to turn the LED Green when Ready, Red when not – I had decided that the TweetCam would only take a photo every 2 minutes, so as not to spam the world. And the LED would flash Blue when it was taking a photo. Wrote the code and tested it.

TweetCam Instructions

TweetCam Instructions

Then I added a second button, which was used to shut-down the Pi, as it would be running headless and this is always a good thing to do when turning off a Pi.  And I made the LED flash Red whilst the Pi was shutting down.

Finally with the program doing everything but Tweet I added in the Tweet code. I followed the excellent instructions from Alex Eames.  And yes, it worked. I pressed the button, the Pi took a photo, flashed the LED, and tweeted the picture.

This is ‘Testing in Production’. It is difficult to test a tweeting program without getting comments! So I only tweeted a few photos. I actually created a version of the program with the Tweeting line of code commented out, so that I could test changes, without bombarding Twitter.

The build took 6 hours from start to finish. I was quite impressed with the speed at which a functional and usable IoT (Internet of Things) device could be built and tested.

And if you are wondering what the pictures looked like the ‘live‘ output can be seen here TweetCam Pictures

PostScript.
We used the device in sessions on two days. On the first day the internet was not working at the conference venue. It was a all a bit of a damp squib. We were though able to demonstrate the inner workings of the Tweet Cam to the delegates but were unable to Tweet. Day two was perfect. Press the Blue button and tweet a picture of yourself.

Testing the Internet of Things: The Light and the Dark

Abstract:

IOT or the ‘Internet of Things’ is this year’s buzz word. Everyone is talking about it, but what is it, and what does it mean for Testers?

Every week you read another BBC Technology News article about how your next fridge is going to connect to the internet, your washing machine is setting the central heating, and your household lights work all on their own. The dark side.

This workshop, using practical and interactive demonstrations will help you to:

Tweet Cam

Tweet Cam

o  Identify what IOT devices are,
o  Understand how they are built,
o  Determine how to test them,
o  Share some lessons learnt from; building, testing and using IOT devices,
o  And actually use some live IOT devices during the workshop to ‘make it real‘ and bring to life your understanding.

The session covers low cost hardware, open source software, the recently announced Windows 10 IOT program, scripting languages e.g. Python, internet connection, communication, data recording, and messaging. And from a software testing perspective, we focus on how to go about testing, what approaches to use, what the limitations are, and look at what can go wrong.

The world is changing, and never has it changed faster. The ‘machines’ may not have taken over yet. Current predictions from Gartner are that by 2020 there will be more than 26 billion non-PC and mobile devices connected to the IOT.
(These devices are going to require an awful lot of testing.)

Downloads:

 PowerPoint Show    PowerPoint show (45.6mb)

Presented at:

1. TMS, London, Apr 2015. (½ day Workshop)
2. TMS, London, Apr 2015. (Discussion Session)
[aka Testing the Internet of Things: The Pain and the Gain]

Notes:

This session was developed jointly with my good friend Phillip Isles.  We co-presented both of the above sessions at the Test Management Summit, London.

Techniques for Successful Program Test Management

Abstract:

Bear

Shouty Test Manager

After working successfully as a test manager for a while, the next step forward is into program test management.  Many think this is just some super test manager, or in a lot of cases, a ‘shouty’ test manager. In fact it isn’t. It is a transition into an oversight role where others do the testing, and you are setting the direction, giving guidance, and having oversight.

This is quite a step up and suddenly requires a set of skills that successful test management does not develop.

It is quite common for program test managers to look after a number of testing projects and testing teams. The scale has changed, and you have begun to operate at the organisational level, working with other members of the program management team.

In this workshop we will look at the new range of required skills; Leadership, Accountability and Responsibility, Oversight and Awareness, Stakeholder Management, Communication, Influencing and Negotiation. We will work though some useful models so that you can take away a kitbag of tools and techniques to use back in the office.

We will also look at how to stay relevant to the testing operation, and retain value-add for your role whilst now working at the organisational level, and delivering through others. And even if you aren’t working as a program test manager yet, the skills and techniques we look at in this session will be invaluable today, to start using, developing and refining.

Downloads:

PowerPoint Show  TMS Workshop (28mb)    PowerPoint Show  BCS SIGiST Keynote (12mb)

Presented at:

1. TMS London, Apr 2015. (Workshop)
2. BCS SIGiST, London, Dec 2015. (Keynote)

New Testing Tool – Binoculars

A few days ago I met my good friend Phill Isles for coffee to plan an upcoming workshop centered around testing IOT devices.

Phill is quite interested in electronics and at the end of our meeting he handed me a small circuit board with what looked like half a small golf ball on one side (something like an icosahedron).  It turns out to be an PIR motion sensor (Passive InfraRed sensor). He recently bought 5 and thought I could have some fun with one (Thanks Phill). And all for only 80 pence each including shipping.

Later he sent me a link to the adafruit website with a tutorial for the PIR sensor.

PIR motion sensor connected to Raspberry Pi

PIR motion sensor connected to Raspberry Pi

I wired the PIR sensor into my Raspberry Pi, then slightly modified the example program to print a ‘Movement Detected‘ message on the screen. And then started to test the sensitivity of the device.

As I moved away from the desk I could see the ‘Movement Detected‘ messages being displayed on the screen. But when I got 15 feet away I could no longer read the screen. Had a message been displayed? It was hard to tell.

How can I test the range? I was on my own with no-one to help. 2 minutes later I had a pair of binoculars to view the screen and all was well again.

It was the first time I have ever used binoculars for testing software. And a new tool was added to my software testing kit-bag.

Nikon Binoculars

Nikon Binoculars

 

100 Million Things To Do In Under 2 Minutes

Raspberry Pi 2

Raspberry Pi 2

According to Douglas Adams, it was the ‘Long Dark Tea-Time of the Soul‘, better known to all as Sunday afternoon. You can either hate them or engage them. Your mind begins to wander. And then you land on a thought. It won’t go away. An itch that needs scratching.

For me it was wondering how many lines of python the new Raspberry Pi 2 would execute per second. Just to give me a feel for how much work the Pi can actually do. I have 6 different Raspberry Pi models and a comparison would be interesting.

I wrote some simple python code:

#!/usr/bin/env python
import time
n = 0
print " \nBefore " + str(time.time())
while n < 100000000:
    n += 1
    continue
print " \nAfter " + str(time.time())

NB. This is the final version of the code.

I wrote and tested the code on my Windows desktop before transferring it to the Pi. And the first time I ran it I had to crash out because I had forgotten to increment the counter. An endless loop! Ooops.

The code is very simple. I Just wanted a time-stamp before and after, and a minimal loop, to get a rough idea of speed. The amount of work that was being done.

I set the loop to 10,000 iterations to start with. The ran. It completed within the same time-stamp. Almost instantaneous. So I upped the loop to 100,000. Again a fraction of a second. Then a million. Again inside a second. So I jumped to 100,000,000. 100 million iterations. This took 8 seconds on the desktop.

My Windows desktop is an intel core i7 3770K. The program was only running in 2 cores. Using 25% of those cores. Roughly 8% of the processing capacity.

The code was working so I transferred it to the Pi 2.  I thought that this was going to take ages to run. First time through it took 156 seconds which I then got down to 115 seconds with the standard 1000mhz overclock. To process 300 million lines of python code. I find that amazing. (100 million iterations * 3 lines of code.) That works out to be 2,600,000 lines of python code a second. On a Pi.

PerfTest3

(04/12/2015 Updated to include new Pi Zero.)
(04/03/2016 Updated to include new Pi 3 Model B, at just under a minute, and an original release Model B 256mb at 290 seconds.)

NB. The Pi 2 result came from running the program simultaneously in 4 cores and taking the longest core time.

This is in no way scientific. It is not a performance test. But as a very rough guide to just how powerful a Raspberry Pi can be, regardless of model, I found it amazing.

(Do try this at home!)

And links to some more thorough Raspberry Pi Benchmarking:

Pi Foundation
Adafruit

 

2014 Some of My Favourite Things

As the year draws to a close it is fun to reflect on a few of my favourite things of the year.

  1. Pebble Watch
    Pebble Alert Message

    Pebble Alert Message

    I had known about the pebble watch for a while. I saw the initial KickStarter project but was too late to sign up. Over Christmas I thought that it was time to buy one. So on New Year’s Eve 2013 I bought one from the Pebble Watch site. It was on offer as a New Year special.
    The watch shipped from Singapore, and arrived about 10 days later. I paid the ‘government taxes‘ and the ‘mail handling charge
    First Impressions were that there was a fault with the screen, and the watch strap was too small.  It took several go arounds with support before someone told me all screens looked like that – a moire pattern. The software was poor, hardly worked from one day to the next.  The watch was put on the pile of ‘technology that I wish I hadn’t adopted too early
    A few months later the battery in my main watch died. I needed a watch to go away, so I turned to the Pebble. At the same time the software was updated to Version 2
    Now the watch worked, once you battled through the vagaries of set-up – I need to run Pebble Notifier on my Android phone to get Mail notifications. I bodged together a watch strap, and I was off.
    6 months later the Pebble is my main watch. I can’t go anywhere without it. It works perfectly, although the software is still updated a little too frequently. Some of the apps are a bit rough around the edge, but the main purpose is excellent.
    I don’t need to get my phone out to see whether I have an e-mail, or other messages, e.g. Twitter. They are delivered direct to my wrist.
    And having different watch faces is excellent. We use time differently as we do different things, and it is great to be able to do that all from your wrist watch. It is even better now that I have managed to send messages to the pebble from programs running on my Raspberry Pi 🙂
    And the screen moire – in certain lighting it is noticeable, but mostly it is not, and it doesn’t detract from the Pebble experience at all. I am sure they will fix that, but I love it all the same!


     

  2. Raspberry Pi A+ and B+
    The Raspberry Pi, but better.

    Lapdock and Model A+

    Lapdock and Model A+

    This is my new Raspberry Pi Model A+ sitting on top of a Motorola Atrix Lapdock – a screen and keyboard device for certain Motorola phones which can also be connect to the RasPi.

    Some people even think I have connected my Pi to a laptop in some way. No. It is a Pi Laptop, or should I say Pi LapDock.

    Connect a nano wi-fi dongle in the back of the Lapdock, open up a hotspot on your phone, and you are truly mobile with a snazzy Pi Laptop.  And I am getting 5 – 8 hours battery life.


     

  3. Google Sheets
    It is not often that I trip over something that I didn’t know, but the charting feature in Google Sheets that lets you scroll around a chart is excellent.  Someday all charts will look like this.  This might have been around for ages, but when I found it I could immediately see the potential – and used it for my Pi Weather Station.

    Scrollable Charts

    Scrollable Charts


  4. Heathrow T5 Pods
    I have travelled on the driverless personal electric transport Pods at Heathrow T5 a few times now and never fail to enjoy the experience. This year I was accompanied by a friend. They had a smile on their face for the whole way 🙂


     

  5. WordPress
    In just a short while it was possible to completely redesign this website.
    Yes, WordPress does have about 3 different ways to do everything, and each menu is context driven so the functions look different depending upon which way you arrived at them, which may account for why it takes ages for newbies (like me) to find what you are looking for. Notwithstanding all of that, the results are impressive to say the least:

    Ps. The old Doesn’t look that bad, but the new just looks ‘better‘.


     

  6. A £10 Temperature and Humidity Sensor

    Headless on Kitchen Windowsill

    Headless on Kitchen Windowsill

    I have had hours of fun with a £10 temperature and humidity sensor connected to my Raspberry Pi.
    I had to solder together some leads, then write a python program which updates an online Google Docs Spreadsheet, and sends low temperature messages to my Pebble watch (above).
    There is an immense amount of satisfaction to be gained from building something yourself. And great fun writing, and testing, the software to control it.
    A longer project post can be found here.


     

I hope 2014 has given you some favourite things as well?

A year in the life of Programming for Testers

It has been an exciting year presenting Programming for Testers It’s Easy! with my good friend Phillip Isles.

HorsesThe year actually started late September 2012 at the UK Testers Retreat at the village of  Eesergroen in the Netherlands (I struggled with that concept for a while as well).  Phill and I were in a discussion with someone about what we would like to present at a conference. I think I said something like “I would be interested, but only if I could run a workshop using the Raspberry Pi, a robotic arm, and got some testers to do some programming.

Well, I take credit for the idea, but it was just in the meme. I had unknowingly been influenced by the group. Later on in the weekend I spent an hour with Isabel Evans walking her through some basics in python programming. She had fun, and this became the programming spine of the workshop.

Phill and I added in the Robot Arm, the Raspberry Pi, some design and preparation, then headed off to Bruges for Belgium Testing Days.  Conferences now request speakers produce a video:

We were well prepared, rehearsed all of our moves, and not withstanding a few ‘technical issues‘ with an aged projector, got up and running for a 2 hour workshop. Amazingly we got through to the end, and managed to write some code to successfully achieve the Robot Arm challenge.  A good start then, and a real buzz that the workshop was successful.

We had also learnt a few things, like what to do for Mac users, the precise sequence to install the software in, and when people say “Yes my install is working” what they in fact might mean is “No, my install is not working!

 

 

Daffodils

We followed up Belgium with half day Tutorial at the London Test Management Summit (TMS). The longer half-day format giving us time to go into real depth with each exercise.  And the enthusiasm in the group after the session was a real reward for all the hard work and effort.

After London I was invited solo to the Czech Test conference in Prague to run the session again as a half day Tutorial.  Unable to turn down a trip to Prague, even though it also involved giving a track and Keynote, I immediately said “yes”.

As with the TMS the longer half-day format paid dividends. The real reward from the session was the fact that everyone managed to successfully finish the Robot Arm exercise, and the first to complete was a tester that had never coded before.

The next conference was at Agile Testing Days in Potsdam, on the outskirts of Berlin in early November. Phill and I had a few months off. We still had work to do though: updates to make to the slide pack and code exercises.

We also decided that to get real value out of the workshop we would write a supporting paper, which would take the reader through the process at an almost atomic level of detail. Given that when people were reading the paper, Phill and I would not be there to walk them through it.

I loaded all of the presentation material, including; slides, paper, video and code examples, onto my website here http://badgerscroft.com/home/programming-for-testers/ .

The workshop in Berlin went very well . We encountered some new problems. Language. Fortunately Daniel Maslyn joined us and was able to help out ‘internationalizing‘ the presentation. Mostly around the punctuation that is specific to python. Who would have through that # ! and :  would have caused so much trouble?

The following day in Daniel’s excellent presentation about Robotics he showed a couple of photos that he had taken in our Workshop to demonstrate the Robot Arm, Raspberry Pi, and Wii mote controller. Thanks for the kind words Daniel.

Afterwards Phill and I headed down to the Test Lab being hosted by Bart Knaack. Phill and I ran through the extra code submissions for the Robot Arm exercise that we hadn’t had time to run. All worked perfectly. Another testament to testers as programmers.

A weeks rest and then off to EuroSTAR in Dublin.  Phill only came to Dublin for the day. He wasnt originally coming but when we found out that over 70 people had signed up to an introductory programming session after the closing keynote we realized that it was going to take at least 2 people,  that our hard work was paying off, and we were gaining real traction.

The paper, although nominated which is a result in itself, didn’t win best paper. It was close . . . .

A lack of speaker prep facilities meant that we had to rehearse in the main hall. Sitting at table running a Robot Arm from Raspberry Pi is going to attract a crowd, and by a stroke of serendipity one of those was Neil Studd, who had attended the TMS workshop back in April. It took no time at all to persuade him to come along and help – thanks Neil.

We really did have over 70 people in a programming workshop at EuroSTAR. It went very well. Everyone got set-up. Completed all of the exercises, and even got the Robot Arm going.  A few did have to leave for the Guinness trip through. Hard choice that, Robot Arm vs. Guinness. We understand.

2014-11-25 15.48.46

Not quite the sunset for Programming for Testers, but we are nearing the end. Phill and I headed off to the BCS SIGiST in London for a half-day Tutorial. This was almost the hardest session to run. It took us fully an hour to set-up. Fortunately we had arrived early.  The session went very well. Everyone managed the Robot Arm challenge.

A few conclusions from what has been an exacting but very rewarding year.

Testers are more than able to write code. Of course it isn’t easy. But the hardest part is not writing the code. It is actually taking the simple steps to start.

And it was fun.  Best comment half an hour in at EuroSTAR. Head pops up and says “This is fun“.

We may well run the session again somewhere in the New Year. And if you have got this far then it will be no surprise to find out that I have ordered another Robot Arm and am looking forward to performing some hand-shake testing (thanks for the joke James!)

Thanks to everyone who helped, attended, supported, took part, or just influenced us.

Thanks
Graham Thomas

Dublin Sunset

Tuesday afternoon in Dublin, taking a moment out from the opening day of EuroSTAR 2014.

Looking out from the 3rd floor of the new Convention Centre with a view of the sun setting over the Dublin silhouetting the Samuel Beckett Bridge.