Posts tagged as selworthy (page 5)

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.

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.)