Wednesday 07th December, 2016
This week we met up on Monday, Wednesday & Friday to work together. We worked at the Benugo Bar & Kitchen at the BFI on the Southbank on Monday & Friday, and at The Office Group (TOG) in Bloomsbury on Wednesday.
We continued our discussions with GDS about working on a number of possible projects. In the meantime we also tried to find out more about the implementation of the Competition & Markets Authority’s investigation into the Retail Banking Market (PDF) which seems to relate to some of the motivations behind our Credit Union project.
As far as we can tell, it appears that Payments UK have helped establish the Implementation Entity Steering Group which is supposed to be driving the project forward. We’d love to know more about this project and so if anyone knows anything, please get in touch!
Last week we heard from Jack, a recent graduate from UCL, who’s started a worker cooperative in West Yorkshire and is developing Fairmondo UK, an ethical and cooperatively-owned online marketplace. They’re currently using a Sharetribe implementation as an MVP, but plan to run a crowd-funding campaign in the New Year in order to make the platform more sophisticated, perhaps by building on the Rails app which Fairmondo DE have built.
Jack was wondering how sensible it would be to do the latter. Chris had a quick look through the codebase and reassuringly didn’t see anything too scary. Jack’s got a place at the Digital Co-ops Retreat, so we hope to catch up with him there.
Our company website has been much neglected, but we are slowly bringing it up to date. This week we made a few improvements to the list of projects:
- Only display a curated list of three projects on the home page.
- Link to the full list on a separate page.
- Added Smart Answers project.
- Added FutureLearn Video project.
When backing up our DNS settings recently, I noticed that our SPF DNS record mentions Amazon SES. We were both a bit unsure why this was so. After a bit of investigation, I realised we had set it up for the GFR Video project. The project is still technically “alive” and so I’ve left this in place for now, but added a comment to explain this in our DNS zone file.
A while ago James A made an improvement to a fix I’d previously made to the recap project which we use for deployment of our own apps (including this website). It turned out that the fix was only relevant to the GFR Video app, because it’s the only app which has a background worker process in its
Charles Nutter merged a JRuby bug fix last week and so I tried to verify that the Mocha build passed with the HEAD version of JRuby. Initially I tried using
jruby-head, but this didn’t appear to include the fix, so I ended up building the
master branch of JRuby which did and the Mocha build passed - yay!
On Wednesday, Chris very patiently paired with me while we tried to work out what should happen if someone tries to serialize a Mocha mock object or a partial mock. I’m really torn between failing fast or trying to do something vaguely sensible. I think we made some progress, but didn’t manage to bring things to a conclusion.
Having reported a couple of Ruby bugs recently which both resulted in infinite loops, I was interested to understand why in one case it was possible to interrupt the loop, but in the other it was not. According to George Koehler this is to do with the fact that, like Perl, Ruby defers signals.
Last week we responded to an email from Anna Shipman about requests from people in other countries wanting to re-use the Smart Answers code. I followed up this week with a more detailed explanation of where we’d got to in our giant refactoring mission and re-iterating our offer of support. It turned into quite a long email, so I hope it was genuinely useful – if nothing else I found it helpful to reflect on where we got to on the project.
We did our usual Trello prioritisation session on Monday, but this time followed it up by going through the long-neglected “Later” list. Next we had a go at reviewing our goals from last week and coming up with some new ones, although I can’t find any record of what we agreed, so I’m not sure it was very successful!
On Wednesday we picked up our TOG Lounge Membership cards which will make it easier to access their offices, especially the Bloomsbury one which has separate building-level security.
The Papertrail Heroku add-on started generating lots of annoying email notifications at the end of last week as the app kept exceeding the logging limit for the free plan. I addressed this by filtering out a bunch of the DelayedJob-related log messages which seemed to form the bulk of the log files. This seemed to mostly do the trick.
Later in the week Rachel passed on some positive feedback about the app from a client which was nice to hear.
On Friday we met up with Ben G at the BFI with the vague idea of building something fun using software. Ben has been suffering from horrible headaches recently and this has meant he struggled to play computer games with his kids, but he discovered that he was OK playing card games. Apparently he often plays appropriate music in the background when they’re playing these games and even changing the music to something more dramatic at significant points in the game.
Ben wondered whether we could somehow automate the generation of a soundtrack matching the state of the game. We decided that it would probably be too hard to try to work out the state of a card game, but that it might be easier to do with a board game and we ended up choosing chess.
Initially we split our efforts: I was to investigate capturing the state of the game; Chris was to find a way to convert the state of the game into a score indicating who is winning and by how much; and Ben was to look at generating a soundtrack based on this score.
I started off by looking at some image recognition options. We found a paper, CVChess: Computer Vision Chess Analytics, which claimed to capture the state of a chess game in real-time based on the images from a laptop web-cam with a side-on view of the board and the video certainly looked very promising. However, when I came to look at the source code, it quickly became obvious that the code wasn’t in a usable state.
I then explored the possibility of alternative ways of sensing the positions of the pieces. Unfortunately ready-made sensory boards generating a useable output turned out to be prohibitively expensive, so I looked into whether we could build our own. It sounded as if positioning the magnetic sensors would be tricky if we did it from scratch, so thought that building this SolusChess project using a modified Mephisto Modular chessboard would be a good half-way house. Unfortunately it took me a long time to source one of these boards on eBay and I didn’t notice the one I purchased was being shipped from Germany - so we weren’t going to get it any time soon.
In the meantime, Ben hacked together a web page which used the Web Audio API to play a looping background soundtrack with the intensity of the sound dependent on the position of a slider control. I’m pretty sure he based this on the background music example in this tutorial. The idea was for Chris to supply a score to replace the value taken from the slider control.
Towards the end of the day, based on this example, I managed to wire up a user interface into the web page to provide input into the Stockfish engine. This user interface makes use of chessboard.js for the visual component and chess.js to work out legal moves. This meant that we could manually play a game of chess and have the background soundtrack change depending on the state of the game. Yay! A very satisfying end to the day.
We planned to continue work on the project the following week.
Until next time.