12 May 2019
A short week, owing to a bank holiday at the beginning and a day largely not working at the end.
Over at Highrigg, I worked on the spec from last week, getting something closer to a list of things to be achieved, as well as making it easier to specify what other assistance we’d require. I met with some colleagues to share that and understand how best to secure that assistance.
I also had some technical successes: fleshing out my GraphQL service backend and, after some assistance spinning up some Google Cloud services, rewriting a service to store files there (rather than locally) and auto-update them. All the
yarntasks to do that are all completed – now I just need to set up whatever the equivalent of a cron job is to run it. And, on another piece of work, I deployed some updates around error logging. Finally, we reviewed some colleagues’ excellent UX research around some changes we were proposing, and gained useful insight into both those changes, and wider issues effecting a particular slice of end-users. A productive couple of days!
On Thursday and Friday, I reached feature-parity on my port of this site to Hugo, and also managed to port all the legacy content over, I think. So at some point, I’ll consider swapping over, and possibly refining the appropriate
rsyncincantation. But I’d also like to spend some time writing up all the projects that have happened since Rubato, if only to see if this new platform works a little better.
Anyhow, a good few days.
06 May 2019
Highrigg continued: a series of meetings with partners, an excellent lunchtime lecture and discussion, and more programming.
After a day spent wiring the backend I started putting together last week with the front-end, I ended up with a shell of an appplication, and at least one screen with real live data. Which was the time to hit the pause button. Why? Well, I was beginning to tip over from learning (about the project) and into production, and it’s not quite the right time for that yet. What I was learning was that it was probably not a one-person job, and it’d go a lot faster with a more experienced React engineer focusing on the client implementation. I was also learning what pace of work would be like on it, and already gaining some confirmation that the architecture I’d settled on was sensible. I was also exposing some of the requirements not captured in our initial documents – for instance, approaches to live updates and data push – that only became more obvious as I began implementing. So that’s something to turn into specification in Week 331.
In the rest of the week, I spent some time exploring updating this website. I’m aware that there’s a long backlog of projects to write-up (especially Selworthy), and I’d like to make it easier to do that. At the same time, I also think I could probably move to something like a static site generator, if only I could find one I could settle on. That’s some work, but would then mean that all my content exists as files, and is relatively easy to port to other platforms in future.
28 April 2019
A four-day week after the bank holiday.
Two days at Highrigg. Last week, I was forcing myself into a deep dive on in React, building a prototype front-end that talked to a third-party API. This week, I decided it was worth introducing our own server-side API between us and the third-party.
This decision – which my colleague Lachie helped me come to, in a highly useful brief rubberducking session – came about for a few reasons. Firstly, so we could separate some responsibility, and make the front-end code a bit less brittle. It also meant that if we wanted to start using other service – notably, some internal data-sources – rather than making growing number of calls on the front-end, we could keep front-end calls down and instead combine all the data from multiple server-side calls into a single payload. That also means we can take a little bit of responsibility for caching in the right place – the server-side.
With that decision made, I wanted to write just enough code to confirm that I’d picked appropriate tools, as well as architecture. I began exploring building a small GraphQL service. GraphQL is very trendy right now, but it feels like an appropriate fit. I’m making something resembling a small mobile app, and being able to serve up all the data for a ‘page’ or ‘view’ in a single lump is ideal. My data model is also fairly hierarchical, and largely read-only, which made life simple.
Unlike last week’s battles with React, this work went more smoothly, and it turns out that I don’t just like the idea of GraphQL, I also really like the implementation. By the end of the second day, I had the beginnings of a service shelled out. More to the point, I’d done enough to decide that this felt like a viable technology to use for the project going forward. I finished up my technical review documents with this knowledge, and updated some architecture diagrams.
On Thursday and Friday, I finished bagging up a run of Foxfield kits for Thonk, and spent some time in the workshop – firstly, starting to brush up some woodwork skills, and secondly, building up an electronics prototype. This second electronics prototype was another SAMD21-based build, which I’ll probably write up, to share my approach for building these boards. It worked first time – and also confirmed that a new footprint was highly viable for what I wanted to do with it.
22 April 2019
Lots of meetings at Highrigg, across a range of projects; some good time thinking through design interactions with colleagues, and then, around that, spelunking an API I’m coding against.
At the same time, forcing my brain through the React mincer possibly faster than is ideal. I am finding getting up-to-speed with React challenging, and often end up frustrated.
Learning new things is hard, yes, and it’s of course sometimes the work of a technologist to stay up-to-date. What I’m finding hard is the gulf between the basic tutorials and guide (which I’ve completed and re-read a few times) and the real-world project I have to operate in. I know this means I haven’t fully internalised the information – going from knowing to knowing – but it’s a while since I’ve felt like this. It doesn’t help that it feels like something I ought to have some faculty with, as a former front-end developer.
Why am I putting myself through this? Because I think it’s important even if I’m spelunking or prototyping to work in the platform other colleagues are most familiar with, and inside a React+Typescript shop, I think it’s reasonable to work with those. (They also, lack of familiarity aside, seem like highly reasonably technology choices). There’s real internal value to playing ball, especially in a larger organisation, and so a balance between ‘output from prototyping’ and ‘lasting value of prototype’ needs to be trod.
We’ll get there. But a frustrating few hours trying to achieve things I know I could do in other platforms or languages, and resisting the urge to chuck in the towel.
On Thursday, I found that Fedex had failed to deliver parts for a Foxfield run, so delayed that until next week. I spent some time in CAD and lasercutting, wrapping up a prototype panel, and then finishing the electronics of the prototype I’ve been working on. This went well: my workflow from panel to cutter is much tighter now, and a single iteration got things spot on. The prototype is working well, too. Time to make a decision about that prototype soon.
And then, a long weekend. Back Tuesday for a four-day week 329.
14 April 2019
Highrigg continued. There’s not a lot I can really say easily in public about my work there; suffice to say, an amount of prodding at code, exploring APIs, discussing interactions with colleagues, and drawing up a technical overview of a future product.
On my couple of days in the studio, I made good headway with the electronics project I was working on in Week 325. I managed to get a better understanding of flashing the device over SWD – and managed to do it with a BlackMagic Probe, which is a more affordable, open-source alternative to the full JLink (though the Segger tools are excellent). By the end of Thursday, I could program the bootloader and application code via
gdb. I also finished porting the code over, and discovered the board worked entirely correctly. A few pin alterations in the firmware, and it looked like it was end-to-end working. I spent a little while thinking what programmer or test boards might look for it, and ordered some material to laser-cut a front-panel in week 328.
Broadly, though, I’m quite excited, as the whole SAMD21 unit can be placed into other projects in future relatively easily.
On Friday, I started working up an order for Thonk of some Foxfield products. That entailed a quick stocktake, work out what I already had lying around, and then ordering parts from Mouser and a few runs of PCBs from China. I also stuck on a new prototype to test some EAGLE part layouts I was playing with, potentially as a future revision to 16n.
I also had some nice meetings this week. On Thursday, I had an excellent chat with Ben Pawle from Nord. Ben and I discovered we were both teaching on the same Hyper Island course, so he suggested catching up – last time we’d spoken was at an IoT Coffee Morning that Matt Webb ran. It was great to talk to another practitioner; we talked about design practice, and making bots, and balancing own work with client work, and it was good to be reminded I’m not the only person doing this.
I also spent some time with a colleague at Makerversity who’d initially asked for some assistance with ESP8266 – but we ended up having a deep dive on designing the connected component of IOT products, and it was good to be able to share some experience across that shape of product design. Namely, I ended up recommending against technical complexity too early in the process, and instead we looked at doing the bare minimum to get to end-to-end – and to find out what making a product connected felt like. By doing that, you get to discover surprises on the way sooner, rather than engineering to spec and not leaving space for serendipity.