Thursday 02nd March, 2017
Show and Tell 29
- When: Wed 08 Feb 2017
- Where: Forge and Co, 154-158 Shoreditch High St, London E1 6HU
- Links: attending.io
Rob C - Test-driving performance
Rob talked us through this idea a couple of months ago. This time he had some code to show us. One of his students had modified jMock to make it possible to describe the performance characteristics of each mocked method, e.g. by chaining
responseTime(uniform(100, 200)) on the end of the expectation one can specify that the mocked method should take a random amount of time between 100ms and 200ms with the response times distributed uniformly within this range.
When the test is run, the mocked methods add the relevant response time to a per-test virtual clock so that at the end of a test the response time of the method-under-test is known. Each test is run multiple times to capture a representative sample of response times for the method-under-test.
Assertions can then be added to check the performance of the method-under-test fulfils the requirements, e.g.
assertThat(percentile(80, context.runtimes(), is(lessThan(250.0)))) which ensures that for 80% of the time the response time of the method-under-test is under 250ms.
If one of these assertions fails, it might be hard to work out what was wrong. Rob thinks it would be good to display a graph of the response times if an assertion fails to give the developer as much information as possible to diagnose the problem.
Rob has some ideas for modelling asynchronous requests being queued up, i.e. the interaction between multiple requests. He’s also interested in instrumenting production code and plugging real data distributions into the performance characteristics of a mocked method.
Ben mentioned that he has a problem with an application which is creating a lot of database connections. It takes a long time to create each connection and so this is slowing the application down. Ben thinks it would make sense to introduce a connection pool so the connections can be re-used, but he said it would be nice to be able to model various solutions and compare their relative performance.
James - Raspberry Pi monitoring
I gave a quick update on the kit I mentioned a couple of months back to monitor a vacant property. I’ve improved the dynamic DNS situation by changing providers - I’m now using changeip.org which seems to be a lot more reliable. I’ve also re-visited the property and opened up SSH access on the Raspberry Pi so I can now fix things if they go wrong.
I showed some primitive analysis of the temperature data which I’d done in Google Spreadsheets to convince myself that the central heating was working. The central heating is on a simple time-switch (no room thermostat) and it was encouraging to see that the temperature showed an upward gradient in the periods when it’s supposed to be on and a negative gradient in the other periods. Therefore the heating is working. QED!
During some cold weather, I was able to use the data to make the decision to visit the property and increase the length of time the heating is switched on; James, the human thermostat!
I found some CSV data available online for the the local outside temperature and thought it would be interesting to try to model the thermodynamic characteristics of the house. I got as far as looking at this Simple Home Heating Model before running out of enthusiasm.
James - 3-port central heating valve
I waxed lyrical about this amazing bit of engineering which is used in many small houses across the country. I really like how the combination of a simple mechanical and electrical design provides some quite sophisticated emergent behaviour. If you’re interested in learning more and you can bear the narrator’s monotonous voice, this video is quite good.
James - GFR website conversion
I think I also talked briefly about how we’re considering converting our company website from using vanilla.rb, a Ruby port of vanilla, to Rails. While we like many aspects of vanilla.rb, it feels as if things like routing, layouts, partial templates, etc, sometimes work in unexpected ways. This is exacerbated by some slightly odd customisations which we’ve added to our website app over the years.
We’ve considered a few options, but we’re leaning towards converting it into a database-less Rails app. Part of the thinking is that Rails is our bread and butter and so we ought to be very familiar with it. We did consider moving to a generated static app, but it felt as if this would be a bigger change and might restrict what we can do with the site in the future.
It was reassuring to hear that people didn’t seem to think it was a completely crazy idea!
Amy - micro-licensing music for sync
Hookline have a catalogue of music by independent artists which they license for Sync. They’re always looking for new ways to bring in revenue for their artists and they’re currently investigating micro-licensing shorter edits of their artists’ tracks for use on e.g. Youtube. It would be a bit like a high-quality stock image library, but for music. Part of the thinking is to bring in a steadier revenue stream, because while Sync deals for TV and advertising can be lucrative, they are also more unpredictable.
Riccardo - Amazon Echo & Alexa
Riccardo explained that the Echo is essentially a big speaker with a microphone, all connected to the internet. It uses the Alexa Voice Service to respond to your questions and commands, e.g. buy an item from Amazon. He went on to explain that this functionality is provided by a set of built-in “skills”, but it’s possible to build your own custom skills and there’s even a marketplace where you can buy or sell skills.
He then demonstrated how to use the Alexa developer console to create a simple new skill invoked by saying “Alexa: Open ‘Hello World’” and responding by saying “Hello World”. As I understood it, first you have to set up some “intents” which describe what phrases trigger your skill and then you define an AWS Lambda function to perform the desired operation. Even though he didn’t have an Echo device, he was able to use a simulator to test the new skill.
Riccardo mentioned that someone has built an interactive story called The Magic Door. He’s interested in building a Choose Your Own Adventure game and he’s hoping to write his Lambda functions in ClojureScript. He recommended using the Alexa Skills Kit SDK for Node.js. Apparently a session gets passed to the Alexa Lambda functions so it’s possible to store state between invocations of multiple skills.
I suggested that if he had microphones all around the house, he could have an adventure game where you have to physically move around the house. Riccardo said that you can federate multiple microphones, so this might well be possible. Ben suggested Riccardo might be able to use Infocom’s Z-machine, a virtual machine designed for building text adventures, or parchment.js, an interpreter for interactive fiction.
Finally, Ben then amused us all by telling us about the Alexa dolls’ house fiasco in which a TV news story caused lots of Echo units to order a dolls’ house.
Ben - Board games
Ben has been playing lots of card and board games with his kids recently. He’s discoverd a couple of things which make this a lot easier:
He also showed us a bunch of games which he likes:
- Enchanted Forest - cruel memory game - easy for kids, hard for adults
- Catan Junior - dress up as a pirate
- My First Carcassonne - don’t need to be able to read
- My First Stone Age - for similar reasons
- Ghost Fightin’ Treasure Hunters (aka Geister Geister) - cooperative game - all working together to defeat game mechanic - good for kids who think they always lose when they play on their own
- Zeus on the Loose - maths game
- Dungeons & Dragons board games - ham them up - big monsters - need to be able to read - wander around dungeons
- Thunderbirds - excellent: best board game designer in the world - expansion packs make it better
- Harry Potter: Hogwarts Battle - deck-builder game - 7 games - 1 per book - each one gets harder to win
Show & Tell 30
Please get in touch if you’re interested in joining us for the next Show & Tell on Wednesday, 8th March 2017 - it’ll be fun!