Posts tagged as weeknotes (page 8)

Week 152 saw my return to the studio after a week off, which was an excellent tonic after a busy August.

I spent much of the fortnight building a standalone environment for Selworthy. It was initially configured for an internal environment provided by one of its end-users, but my client wanted their own install to be able to demonstrate it and use it themselves.

I did this with Ansible. It’s a tool I didn’t know well at the beginning of the fortnight, but by the end, it had already proved its value several times over.

Ansible is a tool to help provision servers. It allows me to write small rules to describe the configuration of a server component, that will be idempotent – I can run them as many times as I’d like, and they either bring the server up to that configuration, or do nothing.

To begin with, it felt quite slow: prodding at syntax until the behaviour I want has been applied. I built the environment by building and destroying servers repeatedly, continuing to test that it’d work from a standing start. And each time I do that, the fact that all previous steps just work immediately becomes a huge advantage.

The other advantage is that Selworthy actually consists of two separate application – the main application, and a media-encoding tool – which have fairly similar system requirements. I built the Ansible playbooks for the media encoder first – which took a bit under a week of work. Then, however, it took about an hour to provision the main application server – because so much of the work had already been done and could be reapplied. It’s useful to be able to provision boxes so fast, and I’m definitely going to be continuing to use Ansible on future projects. The value isn’t just in the repeatability: it’s also in the ease of sharing it with other potential developers – guaranteeing that they can build the same environments as you. I’m not a great sysadmin, and it’s never going to be the main focus of my work, but the more controlled the environment I’m deploying to, the more confident I can be in it – and that’s a huge advantage.

By the end of the work, I could build the entire environment for Scribe in about ten minutes, from a single command, and then deploy each application to it in another single command. I was pretty pleased with that.

Around that work, I fitted a variety of other small pieces of work. I had an excellent chat with Holly Gramazio over coffee one morning, where she told me how Now Play This had gone, and we had a long conversation about the curation of games. It’s always valuable as a freelancer to be able to chat to colleagues, especially those at the edges of some of the spaces I work in, and Holly’s always a delight to talk with; nice to get out of the software for a morning, and hear about other friends’ successes.

I spent an afternoon at the Polyphonic Playground Lab, watching how musicians worked with the playground, and thinking about ways to potentially involve a much wider audience as part of the project. It was also a good opportunity to think about the intersection of music, sound and interaction design, which I’m thinking about a lot at the moment. That overlapped with the TouchOSC controller for Panoramical that I built the weekend before, as a small personal piece of tinkering.

Finally, I spent some time chatting with Richard about bringing Twinklr into land. We’ve got a plan of how to do that, which should fit around our life in the next few weeks, and an idea of where we’d like to take it next. As part of that exploration, I kicked off an attempt to rebuild it in Unity. As ever when porting code from something you know well to something less well, it can feel painfully slow at times, and as a result, I’ve only got code for drawing staves at the moment – but it’s a beginning, and something to build on. I’ve been thinking about a Unity build simply to make it easier to iterate on the real-time aspects of the code, and especially to consider more complex interactions that will become harder and harder to write in the browser.

Oh – and I took the opportunity, nearly six months on, to finally write up Rubato, another project Richard and I worked on together. As usual, project write-ups are always slower than I anticipate (and I still carve out a fair chunk of time for them), but I’m pleased with how that turned out.

A short week, 150. I spent it getting Selworthy to a point to hand it over to the client for inspection, before taking some time out of the studio.

That’s mainly involved confirming that everything works correctly in the deployment environment, which is being maintained by the client. There’s always a bit of back and forth involved here: even though I’ve done my absolute to recreate the live environment in a virtual machine, there are often rough edges that need sanding down, and by the end of the week, we’d got rid of all of them for approval.

I finished up on Thursday afternoon after a hectic week of fettling, and then left on holiday for the rest of weeks 150 and 151: time to recuperate and give my brain a break after a very busy August. Hopefully it’ll leave me rejuvenated for Week 152 onwards.

Still got my head down, which means we’re still on fortnightnotes for the time being.

Weeks 148 and 149 are the usual story: a variety of interesting meetings, keeping the Twinklr ball kicked up into the air, and taking Selworthy well past the inner marker on its landing path.

Twinklr’s firmly in Richard’s hands – he sent me some photos of a rough jig for the enclosure, which definitely felt right to me, so I’m looking forward to seeing how that moves on. I spent some time thinking about a particular possible spin-off for the project, which was an exciting change of direction.

I spent much of the fortnight deploying Selworthy into its new environment. That’s involved integrating with external authentication providers, collaborating with other developers on the configuration of its environment, and debugging issues with particular versions of libraries and packages.

Needless to say, all quite challenging. There’s a lot of context switching, between server administration, deployment, researching new versions of packages, and then writing application code to reflect those changes. Each context shift takes me a while to recover from, and so I’ve been working on my tenacity.

By the end of the fortnight, many, many moving pieces were settling into their final positions, with only the last bit of fettling left to go. Sometimes, this is what the work looks like – just pushing everything a little bit further forward.

A busy fortnight, bringing Twinklr to life, and pushing Selworthy along its landing approach.

Selworthy continues on its flight path, roughly in line with our plans and projections. The current work is to re-architect the project a little, so that it can live entirely inside a firewalled internal environment. Initially, we built it using web-based services, and so we’re slowly removing those. The main work there is building a secondary application to handle media encoding and processing, replacing Transloadit.

As a result, I’ve spent much of the past few weeks neck-deep in Sidekiq and Redis, to build asynchronous queues; in Vagrant, building up virtual machines to host the new architecture (in order both co get a better understanding of the live environment, and to take advantage of XSendfile); overhauling lots of tests, and finding out about the finer details of CentOS (as I’m usually a Ubuntu user). Lots to take on board.

And sometimes, that means diverging from the shortest route between two paths. The port to Vagrant began when I needed to serve the app through a real web server; that felt like a detour, and the days spent on it felt like a digression from my critical path. When I’d finished the work, though, it turned out I’d not only achieved the goal I was setting out to, but also derisked some later work. It felt like slowing down; in fact, it saved me time. So I’m reminding myself to trust my own competency: if I’ve made a decision, it’s probably a sensible one, and right now, sensible decisions trump fast ones.

By the end of these two weeks, the project is in a really good place: the new architecture works, is tested, and I’m more confident in it. I have a good map in my head for what’s coming next, too. So: onwards!

Meanwhile, Twinklr made some great progress.

The PCB manufacture I’d been exploring in the past couple of weeks didn’t turn out so well: due to various misunderstandings with the way Fritzing labels files, and some misunderstandings with drillbits, the home-made PCBs weren’t particularly satisfactory. On the plus side: I know they’re possible to build. However, I’ve explored getting some simple boards made – from the same layouts – with Ragworm, and look forward to seeing how they turn out. So despite my own PCB manufacture process not working out so well, it’s been useful to wrap my head around the design process.

Richard came down for an afternoon in Week 147. He brought with him the crank handle, attached to a rotary encoder, and quickly held together in a prototype jig. After some staring at a data-sheet, we wired the encoder into my circuitry, plugged into the tablet, and fired up Twinklr.

What happened next was we lost quite a lot of time in the best possible way. We spent a while just playing with the sequencer, tweaking and adjusting the code to fit the feel of the handle, and seeing what suited it. We spent some time sketching and discussing what the final enclosure will look like – something beautiful and very much like an instrument; I spent a while looking at pictures of the old RCA theremin (in which the instrument was also its own music stand, and designed like a piece of furniture).

I’m also using the Chrome Web MIDI API to let Twinklr control other instruments: we’re interested in how other musicians or performers might adapt it with their own work. I wired it into my Microbrute and we spent a good while seeing how the crank-handle sequencer felt attached to the analogue synthesizer; it turned out to be a great fit for a performative, tactile synth.

It was great to see the project coming together, even if we only spent an afternoon together. Very pleasing to feel it working, and to begin to see the opportunities and edges for what to do next with it. The next immediate step, though, is building it up, and I’ve given Richard all the electronics to explore enclosing it. Good stuff.

A busy couple of weeks, both on Selworthy and Twinklr.

This fortnight saw the last few features added to Selworthy before it goes into a period of deployment and re-architecting. Some were minor patches, but one overhauled the shape of the permissions system somewhat. A combination of diligent QA and automated testing helped there. It’s in a pretty good place to be taken forward into its production environment now – which is going to be my main focus in August.

I also spent a while building up the user-facing documentation for it in Zendesk. Selworthy is a complex tool; whilst we’ve tried to make it as intuitive as we can, clear documentation (especially around the various user roles) is also an important deliverable: once that reference is available, we can help users on the path to mastery more easily. Rather than writing it as a long swathe, we’ve been building it inside a “knowledge base” tool. That’s been really useful: it makes it easier just to hyperlink between articles, rather than duplicating information, and the shorter chunks make it much easier to rewrite over time.

Twinklr’s going well too. I went along to the Hardware Coffee Morning to have a chat with peers and show it a little; ironically, I mainly showed the software component of it. That’s pretty much where I’d like it to be for the time being, so the next thing is getting the hardware to 1.0 too.

That was the focus of week 145: I finally began the process of manufacturing self-etched single-sided PCBs. Whilst these are still relatively simple, they’re a step away from stripboard and jumper leads, and it’s been a useful thing to learn. By the end of the week, the layouts for the very simple Teensy breakout and less-simple amplifier were complete in Fritzing, and I’d managed – after a day of varying all the variables – to etch a single-sided PCB to my satisfaction.

I’m using toner transfer to make the etch mask: print an inverse of the mask on glossy paper with a laser printer, line it up with the PCB, and then iron it for about six minutes; the toner comes off the paper and ends up on the PCB. Then, fifteen minutes in a ferric chloride bath, and the copper all etches away – apart from where the toner covered it. Frustrating the first few times, but I found the knack in the end. I think the next project after this might involve getting double-sided boards manufactured – but a combination of time and availability has meant that DIY has been the way ahead. Very satisfying to spend some mornings in the workshop, too, rather than at a desk.

Next week, I’m going to drill it, solder it up, and do the same for an amplifier board. That should take very little time – leaving the rest of my capacity to go on to pushing Selworthy through to launch.

Fortnightnotes are becoming a bit of a habit, it seems. That’s partly because I’ve settled into a bit of a routine on Selworthy, so there’s not always that much to mention – and at the same time, I’m moving at a fair pace, so it’s been hard to squeeze them in. Let’s fix that now.

In the past few weeks, my main focus has been on adding a few new key feature to Selworthy. Most of these have slotted in reasonably well, and we’re inches away, it feels, from being what we think of as feature complete. As well as bringing the 1.0 in to land, we’re thinking about re-engineering parts of it for deployment in its intended home, and what the future life of the product will look like.

I spent a day in week 142 tinkering on a WordPress installation with Matt Webb, moving it to a new home, upgrading it and fettling it a little; a day of gentle pair-sysadminning, carefully working through a list of tasks and double-checking them. It was a pleasure to catch up with Matt, as ever, and we made good time on the work.

I’ve also pushed Twinklr a bit further forward – mainly in terms of planning out how I’m going to manufacture a few single-sided PCBs to keep its innards tidy – and started the process of acquiring tools and materials to launch that into the world.

Over the past two weeks, I’ve continued chipping away at the Selworthy featureset, exploring minor additions that might have significant value. That’s not always been successful: sometimes, the material just won’t quite do what I’d like, and that’s meant returning to the drawing board a few times. But I’ve had enough successes to push forward, and at the same time, we’ve begun exploring both a deployment of the product and potential futures for it.

There’s not a lot more to say really, other than yes, it’s continuing, and moving forward, and I’m into a bit of a routine with it.

Meanwhile, Twinklr has leapt forward as I’ve managed to get the prototype code up and running on a tablet. We’re actually using a Windows tablet for this, simply because we need to support USB HID devices, and, ideally, run the code locally; given all Windows tablets are running Actual Windows, that seemed like the best fit for the project. Initial results are promising; I’ve had to remember how to write batch files – something I’ve not done for over a decade – but it’s as satisfying on a touchscreen as I hoped. Richard and I have planned out the work we need to do to hit our first ‘official’ milestone, and it’s all very doable: he’s making good progress on the aesthetics and mechanics of the project, and I’m hoping to meet him in the middle with working technology.

Very quick weeknotes this week, so let’s break out the bullet points:

• Selworthy hit the milestone we were aiming for, wrapping up a list of key features. There’s still a long backlog of ‘wants’, though; some are large and monolithic, but I’ve got some space to start implementing some smaller features, so I started rattling through those, alongside continuing to think about deploying the application.
• An interesting meeting on Tuesday about a project bringing a digital component to an installation piece focused on music, performance, and audience participation. A good session, and hopefully more to say there soon as it takes shape.
• A brief piece of experimentation in a spare moment hacking on Twinklr, exploring Chrome’s Web MIDI support. That turned out very well, and so again, something to show off in the future! For the time being, exciting to play with browser technologies talking to the outside world without ridiculous plugins or other interventions.

The usual pattern of the week – primarily Selworthy, coupled with a few personal projects or trickling future work forward – was broken up this week with a couple of days workshopping with Max and Mike from After The Flood. Productive, interesting, and challenging as ever.

Selworthy continues to be in a strong position: we’re wrapping up a few very last features before we get ready for deploying it for a client.

And Richard and I continue to chat about Twinklr. Lots of interesting discussion points, from player pianos to modular sequencers this week, and lots of new images shared to our moodboard on Pinterest. We’re at the phase of the project where the more ideas and diversions, the better: we’ll start narrowing things down later.

A short week after returning from vacation, but a decent amount to note down.

Selwothy had a pilot run, being given to real users to work with, and I’ll find out more about how that went in Week 138. It seemed good, though – no code errors, lots of work put through it. I spent the two days that the pilot ran for wrapping up lots of minor issues on the snaglist, and a few items on the client’s wishlist. The hands-on attention its had from the end users in the past few weeks has really helped tidy up some rough edges. As well as going over the wishlist, I also started planning out a next potential phase of work for Selworthy.

Friday was largely given over to meetings: lunch with George from Good Form & Spectacle, an ever-useful chat with Tom Taylor from Offset, and then catching up with Richard over coffee about, amongst other things, Hensbarrow. A nice way to end the week.

Three weeknotes rolled into one. Although it’s not, really, as you’ll see.

Week 134 and 135 were spent pushing on on Selworthy: so close to the finish line, and yet lots of potential crinkles to iron out. We hit our deadline pretty much feature-complete, with a decent number of snags gone. Energetic QA on the part of the client caught all the unintended implementation errors, and most of them were easy to patch up – with only a short burst of frenetic Javascript towards the end to iron out one crinkle. This was also the period where I handed over infrastructure to the client, helping them get set up on Github and so forth – and that’s meant we’ve moved issue tracking over to Github Issues, which they’ve really taken to.There are already future feature requests floating around, but for now, we’ve got a really solid end-to-end application and people are excited by it.

Otherwise, the odd smattering of meetings, including a trip to Playhubs to see Alex and his Fabulous Beasts. And then, at the end of all that work on Selworthy, a holiday: week 136 is spent out of the studio, by the sea.

(And, as I sit by the sea, Richard tells me we’ve snagged a very small bit of funding to take the tinkering we did a couple of weeks back forward – lovely news, and celebrate with beer and a read).

Selworthy is in a good shape. The unknown unknowns are slowly shrinking, and much of Week 133 was spent polishing up the workflow elements – tidying up what happens on state change, fixing up the UI dependent on what state the project or user was in, and making sure the experience was coherent for an end-user. By the end of the week, all that had slipped was the dedicated work of transferring the infrastructure to the client, but that shouldn’t take too long to wrap up.

I also spent some time tidying the UI, and found an excuse to put Flexbox to good use, evening out some layouts – how I’d love that technology to have existed a few years back!

I also spent some time porting the audit trail within the application, as well as things that might have once lived in callbacks, to use EventBus. I really didn’t need anything complicated, but I like the Pub/Sub model, and EventBus provides a simple, synchronous way of propagating events around the app. It means my controllers are much more lightweight, and everything that comes down to being triggered when something else happenes is now tidied away. (I don’t mind that it’s synchronous: I’m using it to keep the application code tidy, rather than for asynchronicity).

Barring a few other pieces of functionality, it’s now at the point where the best way to work out what’s next is to use it in anger: give the client some time with it, and test our assumptions. I think there’s still going to be a bit more to do, but nothing insurmountable. B

In the middle of the week, I spent an afternoon tinkering with a small prototype that Richard was idly wondering about. It seemed easier for me to see if it’d work by building it, and so I spent some pleasant hours messing around with Canvas, Backbone, and the HTML5 Audio API. It turns out I’ve learned a lot in the process of Selworthy, and I managed to come up with pretty neatly designed. More to the point, it also made us both grin a lot. So perhaps there’s some more work to be done there. A fun diversion.

Selworthy has now entered its third milestone, which after all the UI and javascript work of Milestone #2 is a change of pace. We’re now moving on to a third milestone all about workflow and permissions.

As ever, this kind of work is fiddly. First, we need to sit down and sketch out workflows with the team, confirming that they fit real needs and are yet flexible enough to cover most future scenarios. Then, there’s the job of implementing and testing them, which involves as much “QA” as it does automated testing: sitting down and confirm that each user sees what they should.

It’s moving forward well, though, and as we flesh this work out, we’re discovering the unknown unknowns that permissions and workflow always throw up: all of a sudden, UI elements need disabling depending on permissions; all of a sudden, activity on the application needs communicating. It’s not stupid to talk about unknown unknowns; they’re inevitable because the process of building software is one of discovery. Often, they impact our original estimate, but they also help make the software what it should be – fleshing it out, make it useful, making it all flow a little better.

A good week, then, and next week will also focus heavily on Selworthy. Onwards.

The big news this week was the broadcast of Future Speak, my BBC Radio 4 documentary (previously known as Periton). I’ve had lots of great responses to it, which have been really appreciated – and at the end of the week, Radio 4 themselves selected it for Pick of the Week. So that was all very positive. It’s rebroadcast tonight at 9pm, and is currently available for download as Documentary of the Week.

Meanwhile, in the land of programming, Selworthy moves on apace. Last week’s big feature was moving from direct S3 upload to using Transloadit, which I’ve been really impressed with so far – it’s got great documentation, solid functionality, and has enabled lots of little features for Selworthy in the few days I spent porting to it. Impressive.

I also spent a while writing up a lot of documentation and refining some of the features in Milestone 2; Week 132 sees the beginning of Milestone 3, which is going to be a big chunk of transactional code and lots of tests. So for now, tidying up and front-end polish was the way ahead, but next week’s going to be back to heavy-lifting and lots of Ruby.

I spent Week 130 working with Good, Form & Spectacle on Two Way Street.

This was a four-day burst of work with George and Frankie to make a tool to explore the British Museum’s collection. We were aided by some early work from Tom Stuart on translating the available dataset – linked data, stored in N-Quads – into something approaching regular JSON that developers could work with.

George’s Work Diary post about the project has lots more notes, explaining the shape of the project and some of the reasoning behind it. I also really like the explanation on the site’s about page:

The British Museum is a venerable institution that opened in 1753, and has been a centre of scholarship since then.

This project is not that. This is a sketch made quickly to explore what it means to navigate a museum catalogue made of over two million records. It’s about skipping around quickly, browsing the metadata as if you were wandering around the museum itself in Bloomsbury, or better yet, fossicking about unattended in the archives.

It’s a lovely tool to explore and poke, and we had fun making it – by the end, there were loads of URLs just being bounced back and forth in the Slack channel. Look at this!, one of us says, and then look at that! I think that’s a good sign.

It was interesting to build, too: once we’d wrangled the data out of n-quads, we ended up storing it all in Elasticsearch. There’s no traditional relational datastore in the project at all. I wrote more about that choice, and what it enabled, over at the Good, Form and Spectacle Work Diary in a post called Tools For Counting Things Quickly:

So often, what we’re doing is counting and listing – usually both at once. Those counts are often predicated on complex criteria – but Elasticsearch’s aggregations make these counts very straightforward, and allows us to bundle many into a single query. For instance, the page that shows what objects were made in Japan, and which also lists which decades matching objects came from, visualises what other facets are most popular, and then enumerates the objects themselves, is just two queries in total – one of which is just used to construct the row of boxes for the decades.

There’s more in the post if that’s your sort of thing.

A fun four days, with a great deal of code cranked out and a few interesting interactions too. Heartening, sometimes, what a short sprint with good people can achieve.

And then, it was all over. Onwards; week 131 sees a return to Selworthy and the transmission of Periton.

A really good week on Selworthy.

When I come to put together weeknotes, I often take a squint at the output of git log for the past week to remind myself what I did. Some weeks, this will show loads of commits, and the forward velocity is really obvious. Other weeks, it’ll feel like I’ve done a great deal – but there aren’t always the commits to show it.

This was one of the latter weeks. That’s mainly because I’ve been focusing a lot on implementing and refining the front-end UI for the project, and that means lots of slow but meaningful modifications to a handful of Javascript files.

I pretty much wrapped up this pass on front-end UI this week. That included adding lots of mouse-manipulation interactions to the canvas element that is fairly critical to the application. Because Canvases are just pixel-arrays, it’s in some ways harder to do interaction-detection than it is with SVG (where each visual element is also a DOM element). But because of the way the canvas is written – a single Backbone View that renders itself at up to 60fps – it wasn’t too hard to add the manipulations to the event loops on it. These manipulations also update Backbone models as the user uses the mouse, and, ultimately, sync to the Rails back-end. By the time they were in-place, things really felt like they were coming together.

That was the large change to the front-end; but there was also a lot of smaller polish. Adding keyboard shortcuts; fixing issues with flickering as Javascript templates render; refining the UI as we played with the application. Not many obvious commits, but lots of progress.

I spent some time experimenting with installing ffmpeg on Heroku, by having multiple buildpacks on one host, and discovered that whilst it was possible, it probably wasn’t something I was going to spend much more time playing with; instead, I’d use some of the banked time on the project to rewrite some early work to use an external transcoding service.

I’ve been making good time on Selworthy, and I’ve kept the client abreast of the difference between my original estimates and reality. They’ve been receptive to this, and very understanding. What it’s also meant as that now that we’ve discovered that something implemented back in Milestone 1 wasn’t necessarily going to hold up in production, we’ve actually got the time – largely left over from Milestone 1 – to implement it properly, and also gain some nice-to-have functionality for free. Frequently, I find that time saved often gets applied to improvements on that work, and it’s been great that the client’s been in entire agreement with that, making important improvements easy to work into the schedule.

Selworthy continues to be hugely satisfying, touching at lots of interesting edges: rich interactions; intensive but selective use of lots of features only possible in modern browsers and HTML5; just enough modern Javascript to make sense. I’m enjoying it a great deal.

Week 129 is a short week, because it’s the Bank Holiday, and whilst I may be freelance, I take Bank Holidays. That makes Week 130 short, too; I’ll be spending it with Good, Form & Spectacle, and returning to Selworthy in Week 131.

I’m knee-deep in Selworthy at the moment, and that’s a good thing.

Much of Selworthy is simple transactional web stuff: users, content objects, and permissions thereon. I spent most of Week 127 focusing on that – writing lots of tests, getting the foundations in place.

But its core is a rich interactive web tool, which manipulating a list of data both through a traditional table and a visual timeline of events. Selworthy’s the sort of project that four or five years ago would have been far beyond me, and pretty beyond the web. In 2015, it’s all achievable in modern browsers with relatively few esoteric libraries. It’s been an exciting learning project, but also eye-opening. (I’m using the Canvas and HTML5 video APIs extensively, for instance).

I’ve also been using a lot of Backbone. I’ve come to Javascript frameworks relatively late, but also relatively carefully; I’ve never really had the need to use one until the past couple of years. I’m keen on making things as simple as possible to begin with, so always start with transactional POST/GET: plain old websites, like you might have made with Perl CGI. And then we layer on the more dynamic layers, usually delivered through Javascript elaboration.

Recently, though, I’ve found myself repeating particular patterns of usage when it comes to binding back-end data to front-end code, and it was on Swarmize that I realized this was exactly what Backbone was for, and perhaps I ought to investigate it. That turned out well, and I found a way of implementing Backbone-based rendering without compromising the proper-pages-with-proper-URLs approach to web design.

So Selworthy isn’t a ‘single-page app’ by any means: it’s lots of pages and lots of HTTP. But there is one page – probably the most important page, the page you spend longest at in the app – which is where all this rich interaction lies, and where Backbone comes into its own. The page is largely rendered server-side in Rails initially, and then Backbone models are populated from inline JSON (rather than HTTP GET) – before the whole Backbone rendering pipeline takes over.

I’m enjoying working with Backbone, mainly because it does almost nothing. The number of places where it has no real opinion about how you proceed is refreshing; as such, I’m free to keep things as simple as I like. Its lack of opinions does have the unfortunate side-effect of making nobody’s Backbone code look the same, but at least you’re not bound to one developer’s understanding of what a rich webapp looks like. (If you ever wonder how little it does, Backbone has some of the best annotated source code of any project I’ve used; you always learn something looking at it).

I’d laid some foundations last week of how Backbone would render the page, and that set the stage for Week 128, in which I build a lot of the rich interactions that bridge Backbone’s data model, with multiple related Backbone views, and also the Rails backend. There was also the first push on look and feel, not just looking at design and layout, but also clarity of communication with the end-user.

That wrapped Milestone 1 and took us well into Milestone 2, which we might well finish before Easter, and a good demo on Friday with the client in their offices helped clarify what the next steps would be. By the end of Milestone 2, we’ll have a really solid demo and be at the point where we need to understand the complex workflows ahead.

Week 126

A good week, setting up exciting foundations for Week 127. For starters: a couple of days on Bredon, a workshop with Max and the team at After The Flood. It’s always a pleasure to work with Max, and this was no exception: two intense days of good chat and brainfood.

There were also a bunch of meetings – a few exploratory ones, and one setting up a project called Selworthy that would need a pitch writing next week.

Week 127

Week 127 saw the beginning of Selworthy: a fairly intense full-stack web project with a really interesting problem to solve.

I spent Monday formalising a pitch, whilst also derisking the project. That meant writing small bits of code to explore particular issues – parsing particular formats, understanding Amazon S3’s security model, testing character encoding issues. I also researched my proposed architecture for the project a little.

I always find it hard to balance the right amount of research and derisking: too much, and you end up starting to build the project; too little, and it impacts estimates and planning. In the end, I think I err on the side of too much, knowing that with any luck it’ll be re-usable in the course of the project.

The client was happy with the proposal on Tuesday, so off we went. It turned out that the early derisking had paid off and in the rest of the week – including a Friday on-site – I managed to achieve most of the first milestone of the project.

I’ve broken the project into three milestones. The required functionality won’t be complete until the end of milestone 3 – although milestone 2 could feasibly be described as a minimum viable product. At the same time, breaking the work down this way has been helpful for sharing my understanding with the client and getting their input. It’s also a way to keep risk contained – each milestone builds on the previous one and confirms that the next one is possible.

That also assists estimates. Like almost all developers, I find estimating hard, and I also find that the easiest way to make an estimate more accurate is to do the work. To that end, each piece of work helps estimate the next one.

Milestone 1 is basically a prototype; it tests all the core functionality and sets up the architecture of the code, as well as getting the production infrastructure good to go. By the end of the week, it was clear that my conservative estimates were reasonable, and we might well have some time spare. Rather than saying right now ‘it’ll be cheaper‘, I’m clarifying that it’s all time-in-hand within our current budget and it gives us room to breathe if future code turns out more complex.

Anyhow: it’s going well so far, and it’s exciting to work on something that’s challenging in all the good ways. The next few weeks are going to be head down on Selworthy, and that’s going to be good.

(Oh, and I almost forgot: on Tuesday, I finished the script record for Periton. So that’s all in the can, from my end.)

I wrapped recording interviews on Periton this week, with a studio session on Thursday and an on-location set of interviews on Saturday. All that remains is a script and one final studio session for voiceover. I’m looking forward to seeing how it’s turned out shortly.

On Thursday, Richard was invited into BBC R&D to chat about Rubato, so I went over with him to see their reactions and hear him chat. It’s always nice to see other people’s responses to which inevitably vary with their expertise, and so to hear from people with experience of all manner of broadcast platforms and approaches was interesting.

At the beginning of the week I spent a day sketching and thinking on Walbury, planning out some simple interactions and working out how they map to a third-party vendor’s API.

Midweek was a conversation about future work with a gang convened by George at Good Form & Spectacle, which were as always super-interesting. And I spent a while in the week tinkering with a small Elasticsearch project, porting an application previously reliant on a relational database to use a big-bucket-of-documents. By the end of the week, I had a really solid port that was remarkably snappy.

Code, design, talking; a little of everything, then.

Tuesday saw the second performance of Rubato, at the Apple Store on Regent Street. Not quite the same acoustic as St John on Bethnal Green, but it was still a cracking performance. This time around, the animated words were also projected onto a pair of large screens in the front of the audience; though this occasionally removed some of the intimacy, it meant it was possible to take in the live performers whilst also seeing the words – something that the audience earlier in the month mentioned they’d have liked. So it was more useful information about how the project worked, and we had some lovely feedback from the audience members.

Otherwise, though, I’ve been running around the country for Periton: to Newcastle and Cambridge, to several locations throughout London and, on Saturday, up to Cardiff. I’m writing these weeknotes on the train back; it’s been a tiring week of travel and lots of talking. We’ve got lots of strong material from a variety of different voices and I’m looking forward to how everything will come together over the coming weeks. More in due course, but probably worth explaining: Periton is a radio programme.

And as ever: the usual sprinkling of meetings and phone calls to fill out the week. One phone call in particular helped me understand a lot of the parameters for Walbury which I’ll be starting work on next week – a short piece of specification and exploration.