Posts tagged as hallin

Lots of work on Willsneck this week, to bring it into land. We wrapped everything up by Thursday PM, and I’ve got a half-day on this left over to finalise the production deployment. Happy with how it’s turned out, I think.

Hallin got merged into master by the client, so I’m looking forward to hearing how they get on with it in production.

I had a good chat with Christian and Miguel from Schema who were in town, having been introduced by a friend. Always nice to meet new people, and interesting to chat to them about designing for data, working with clients on that problem, and the tools used to do it. Thanks to Steve for putting us in touch!

Finally, I spent some of Friday working on Mayhill, and had a really big breakthrough. That breakthrough is what we called end-to-end at Berg: a complete workflow up and running, even if every component is a bit ‘version one’. I began by working on overhauling some of the browser-based UI: making it look a lot tidier, and refactoring a lot of the large App.svelte file into smaller components, including a big wrapper component for handling the MIDI context. Then, I wrote the JavaScript to translate edits in the browser to Sysex data. Finally, back in firmware-land, I wrote the firmware code to intercept that stream of data and write it to Flash RAM. There were other small firmware kinks to iron out, too.

By the end of the day, I had a system where you could open an editor in your browser, connect a physical object (that I’d both designed the electronics for and coded the firmware on) and see it appear automatically, and reconfigure it in the browser app. The browser app could transmit edits back to the hardware, which would persist those changes. Hugely satisfying: what’s largely left on this is polish, now, and working on the “1.0” hardware (rather than this ‘development board’) that I built for myself.

Still not quite sure how I feel about Svelte. I like the compiled-up-front approach, especially for something that couldn’t really be done many other ways; I’m not quite sure about its idiosyncratic syntax, and whilst I quite like its two-way reponsiveness, that leads to a propensity to get yourself in a tangle. Still, it’s enabled all the things I’ve needed to do so far in a reasonably straightforward manner, and I’m a big fan of its Vue-style single-file components, so it’ll do for now. One thing in its favour is that it was easy enough to pick up after months away: most of it, most of the time, is just browser-based technologies.

A good week, then: mainly code for clients, some more esoteric code for myself with a serious breakthrough, and some good conversations to round it out.

I’m writing these notes awfully late, so let’s rattle through them:

• shipped all the final changes to the client on Hallin. They seem pleased, so hoping to wrap this next week.
• kicked off a second phase of work on Willsneck. This was primarily focused on front-end design changes: new markup and CSS, and content updates. There was still some more unusual code to implement, though. Some of the content on the site is extracted from JSON files using Hugo’s ability to use JSON data in templates. These JSON files are derived from online sources, and needed to be regularly updated. How to do that with a static site? It turns out it’s now quite straiightforward. We’re already deploying the site using Github Actions on every push to master. Actions also supports cronlike functionality, with scheduled actions. I wrote some scripts to download and process the relevant JSON files, and then wrote some Actions workflows that, once a day, would run the script, commit the results back to master, and deploy the site. Really happy with this: I’m sure you can also do similar with CI, but Github Actions are really lightweight and straightforward out of the box. Might use this pattern again in future.
• met up with Gabi from Hyper Island, who have moved their London office into Makerversity - just around the corner from me. We debrief on the module I’d worked on, and caught up more generally.
• did a bit more writing on Ninebarrow. Slowly moving forward; still painful.
• finally, booked all my accomodation for Loop this year. Really looking forward to this again: a neat combination of being personally interesting and enjoyable, and a good source of inspiration and thinking-time for my work-brain. Can’t wait.

Back to code, mainly, in week 370.

I fixed up all the major issues the client had requested fixing on Hallin - two fairly chunky bugs I needed to take apart a little to fix, and two minor tweaks. With those resolved, the client’s tech lead gave my branch a thorough code review. They were very happy with the way I’d dived into their codebase, and most of the feedback came down to notes on minor formatting issues, and on code that was perhaps not so legible at first look. A few quick commits took care of some inconsistent formatting. More important was a second pass on the code that wasn’t so clear. That meant simplifying conditionals, reducing fragility of a few parts, and tidying things that hadn’t seemed overcomplex when I was writing them.. I also extracted some highly specific code into something more general - but not too general - that would set a good precedent for any future refactoring of related tasks. As ever, the integration/feature tests acted as an excellent safety net, and I wrapped up the code review in an afternoon.

There was some brief discussion around a pacey second phase of Willsneck that will kick off in week 371. This time around, we have a firmer deadline, but also are much firmer in what needs delivering in that timeframe, so I sat down with the designer to go over what changes needed to be done, and wrote up a thorough document to cover my estimates and highlight anything I thought was a risk. I shall dive into that code on Monday.

I spent some time on Wednesday continuing to work on the writing project that is Ninebarrow. I am making progress - not hugely quickly, but progress nonetheless. It is already proving more challenging than I expected, partly because I cannot quite write as fast as my brain can go, and so I begin to start doubting or questioning what I’m doing whilst in the process of doing it. Shutting down that critical voice long enough to work is going to be something I’ll have to practice!

I launched the Futurelearn courses that were previously known as Longridge, and wrote them up here. I’m pleased that they’re now out in the world. Next week, I’ll check in on how the learners are getting on in their discussion and comments threads.

And finally, I payed my tax bill. Thank god that’s done.

Another largely admin-focused week, for now.

I completed everything to do with taxation at the end of the tax year. My bookkeeping was largely up-to-date, so that just involved going over it all, a quick check-in with my accountant, a few final reports, and then getting everything sent to HMRC.

I did some final tweaks to material for the Longridge courses, which launch on Futurelearn on Monday 27th. They’ll get their own project page and announcement on this site in Week 370.

I finally wrote my yearnotes for 2019. Useful to reflect everything I got up to, and perhaps how I might want the shape of work to change this year.

I got some feedback from the client on Hallin, so triaged those issues ready to return to writing code next week.

I started writing on Ninebarrow. Not for long enough, but enough to break the ground, and leave a few dangling threads that I’d like to return to - usually the easiest way to get me to want to Keep Writing.

I ripped out Adobe Fonts from this site. I’d been using Typekit since way back when. Adobe absorbed it and, for a while, provided it cheaply. However: when my free year of “Adobe XD” (which includes their fonts) expires, the pricing will go up to £120 a year, which is just too much for the odd typeface around the internet. I was reminded of this by a friend getting a ‘surprise’ credit card charge. My renewal turned out to be due in April, so I used the time to remove this dependency.

So I ripped out all reference to Typekit from my live sites, and, where necessary, found alternatives on Google Fonts (where the open-source faces are decent enough for my needs). On this site, that meant moving to a more traditional sans as a face for headlines and display, and adjusting alignment a little across the site. I am happy with the slight refresh. But: if you noticed the design change, this is why.

End-of-year admin out of the way, next week should see a return to more head-down productivity, and perhaps more writing.

Finally, worth noting a little about how I use weeknotes here. Weeknotes on this site are, for me, a diary of work and things I’m doing in a professional capacity. I have a personal blog as well, and I continue to write and link there; subscribing to its RSS feed will keep you up-to-date. I like to (try to) separate work from non-work, although it’s not always 100% straightforward. When I write here, though, it’s equally to log what I was up to for myself, and share the way I work - and how I think about work - publicly. So if they seem dry, that’s a little deliberate - but they’re certainly not the sum total of myself.

Another year - the seventh full one of working for myself. Just enough distance from the 31st of December makes for a good time to review what I got up to in 2019, and match up some codenames to projects.

Clients

Client work is, as ever, the major focus of my work.

I wrapped up my engagement with Captionhub at the beginning of the year. CaptionHub had been a highly successful project for me. I took the technology aspect of the project from a prototype to a fully-fledged product. The small team grew; the client built a technology capacity; I learned a great deal in the process. I finally had a chance to write this work up at length, and I’m glad I’ve done so.

I spent much of 2019 working at Bulb as Lead Technologist inside their Labs department. I’d summarise Labs’ role as “product invention and business development”. That is to say: we did R&D around future products and the business units they might spawn. We then worked out what would be necessary to bring those to fruition, from both a business and customer perspective. My role was to understand, explain, and prototype technology, leading technology inside Labs, working with the designers in the unit, as well as other developers, and colleagues throughout the business.

I learned a great deal about the nature of the power and energy industry, a little the specifics of high-voltage electricity, and a fair chunk about electric cars along the way! I greatly enjoyed everyone I worked with inside Labs - Alex, Claire, James, Jenna, Lachie, and Daphne - as well as colleagues throughout the organisation, many of whom went above and beyond to assist us with our projects and research. We also got to partner with some great people outside the business, and in particular, I enjoyed working on prototypes with Pam and Ling from Intellicharge; Bulb’s trial with Intellicharge kicked off in November, a little while after I left.

My engagement at Bulb wrapped up around Week 322 of last year. My time there was codenamed Highrigg.

Since then, client work has included work with After The Flood, IF, and the New Left Review.

Teaching

There’s been more teaching this year. With Hyper Island, I delivered the Digital Technologies module on their Digital Management MA for two cohorts: at the beginning of the year, in January, for the part-time cohort (who’d meet in London every month). This year, I also performed this role for the full-time students, in Manchester, in March.

I also worked on three courses for the Institute of Coding that will launch on Futurelearn in January 2020. Targeting beginners, they are two-week introductions to programming, web development in HTML/CSS, and UX design. I’ll write about them more very shortly. These courses were codenamed Longridge.

Products

In the background, I continued to explore a few avenues around physical products.

I continued to ship kits under the Foxfield label, although I’ve not introduced any more projects. Being honest, I find product support much harder than product development, and adding new products just adds new things to support. So I’m thinking hard about what to do there: how to simplify.

The big product I worked on was 16n. This had been rolling in the background for a while in 2018; in January 2019, I decided to stop dawdling and release it to the world. 16n is a hardware-and-firmware product, sure - but it’s also an open-source product. I don’t actually make any. (Well, that’s not quite true: I have hand-built a few. But in general, I don’t make them). Instead, other people - hobbyists, small businesses - around the world have built their own - and, because of licensing, sold them to others.

I’m happy with that trade-off. The thing is in the world; other people are enjoying it and making music with it. Every time I see a picture of one in somebody’s setup, I’m happy. Also, Richie Hawtin has one.

I continued to support and provide firmware patches for 16n through the year. And now I’m thinking about what successors to it might be in 2020: I have a few ideas about how to improve the core experience of the product. How I get those to market remains to be seen.

Still: without shipping very much beyond data, I shipped a thing.

There were also perhaps a few too many prototypes behind the scenes, which fitted around work during downtime. Some of these were no-goes; a few stalled at around 90%, as I baulked at what it might take to push them over the top. Next yea,r a lesson has to be only working on things with a more defined goal, and a commitment to make them real. If it looks like it’s fun, but might not go anywhere… probably something to stop sooner. A lesson learned.

And, of course, physical/electronic products are a small part of my practice. It’s often easy to chat about them in weeknotes when other, larger work is harder to talk about - and that doesn’t always present an accurate picture of my work’s balance. Again, something to think about next year.

---

And that was 2019. 2020 begins by wrapping up a few pieces of client work. And then it’s time to look for new projects!

As ever, do get in touch if you’re looking for someone to work with on the shape of projects - technology (particularly on the web), invention, R&D, prototyping and strategy, playful interaction, the boundary between digital and physical - that you read about here.

Onwards!

A quiet week, as I was working until Sunday night last week teaching.

It’s an admin-oriented time of the year. I finished up all my book-keeping for the previous year to ship to my accountant. This was largely up-to-date thanks to regular FreeAgenting, but there were still a few bits and bobs to catch up on. I also sent a few invoices, and paid a few bills related to the studio fit-out in the autumn.

I spent a day or so presenting a demo of the state of Hallin to the direct client. We worked out what would be necessary to do before we shipped a beta to staging. I finished up that code, wrote some appropriate end-user documentation, and shipped that off to them for testing.

Over on my personal site, I wrote up the Spark AR filter I made one afternoon last week. It’s not so much a technical write-up as it is an exploration of environments for making software toys:

It’s a while since I’ve worked on a platform that’s wanted to be fun. I’ve made my own fun with software, making tools to make art or sounds, for instance. But in 2020, so much of the software I use wants me to not have fun.

[…]

Twitter is now very hard to make jokes on. The word ‘bot’ has come to stand for not ‘fun software toy’ but ‘bad actor from a foreign state’. The API is increasingly more restricted as a result. I’m required to regularly log in to prove an account is real. My accounts aren’t real: they’re toys, automatons, playing on the internet.

I get why these restrictions are in place. I don’t like bad actors spreading misinformation, lies, and propaganda. But I’m still allowed to be sad the the cost of that is making toys and art on the platform.

You can read more (and see the filter in action) in Fun With Software, over at infovore.org.

Finally, a longer-term personal project that I’m calling Ninebarrow began to take shape - or, at least, take a little more solid form. No huge developments here just yet; there’s little more than thinking on it, so far, but I’m writing it down for the sake of tracking the progress of that project, if it happens, over time. Here is where it began.

And we’re back in 2020, with the first full week of the year being Week 367.

I did a small amount of work on Hallin, getting things shipshape for the client demo that was moved to the beginning of Week 368. Most things were in place, though I spent a few hours making one slight improvement to better reflect the existing domain model in the work I was doing.

Some of my time was taken up with typical beginning-of-year admin.

I spent a pleasant afternoon building a toy for myself in SparkAR. Spark turns out to be a highly pleasant development environment, and simple results can be worked up surprisingly quickly. Node-based programming environments aren’t always my favourite, but they make a lot of sense of things involving realtime video or pipelines, and I soon settled into Spark’s mental model.

By the end of the week, I’d sent the toy off for review. Of course, I immediately found a serious number of UX improvements to make the moment I’d hit submit. So I imagine a 1.1 release will be submitted fairly soon after, and that’ll be the one I release for people to play with.

Really, though, the big work this week was preparing for the second weekend of teaching on the MA course with Hyper Island, and then delivering those classes on Friday, Saturday and Sunday. A few talks, including one that’s a crash course in cryptography, that goes on to use that knowledge to better evaluate blockchain (and cryptocurrency, with a brief digression into What Money Is). This is always a hard one: really, it’s about critically evaluating technology by refusing to be told that something is too complicated to describe clearly. Lots of good questions and analysis from the students, and it led nicely into a wonderful session (as ever) from Wesley Goately on critical thinking around AI and related technologies. That seemed to go really well too.

Mainly, though, the weekend focused on the students finishing up their pitches to deliver to the client on Saturday night, and they all delivered excellent, interesting, and varied outcomes. As ever, I greatly enjoyed myself: I don’t just get the chance to think about the ideas and content I’m delivering, but also I get to learn from my students: seeing how they engage, watching what examples they bring to the table, as well as how they merge their learning with their own professional practice and workplaces. They’re always a diverse, international crew, and so my perspectives are always widened. And I’m always learning about how to convey and express ideas: what sorts of coaching and information people best respond to, how to find ways to help them come to solutions for themselves. Hugely satisfying and rewarding, as ever.

The card that says ‘yearnotes‘ is still in my TODO column. I hope I can get those out the door soon.

Week 364 was my last working week of 2019.

I spent one last day on Willsneck, cranking through snaglists from the designer and content strategist. We got to where we wanted to be at the end of the day, after a lot of tweaking and polishing.

I didn’t really spend any time on Mayhill - too busy with clients this week.

I added one final edit to one of the Longridge courses, which had me wracking my brains for ages to find the right thing to drop in. But: I did, and it’s in, and I’m happy with the choice I made there.

Most notably, I kicked off Hallin. It’s really nice to be writing Ruby after so long away, and to be working against a nice, well-laid out codebase. It’s not a small codebase by any means - all monolithic Rails apps of a certain size have their own quirks of patterns, after all - but the choices and trade-offs made in it are all pretty understandable, and it didn’t take me too long to fit into the house style. Good to have a comprehensive test suite, too: it’s encouraged me to keep adding to it generously, and has caught several regressions I might otherwise have missed. The state of automated browser-based testing these days always impresses me. Testing interaction flows with Capybara and headless Chrome as part of our regular test suite is a delight. Tests are written from the perspective of the user - go here, click on this, and you should see that - and they work fast enough that they can be run regularly. Of course, this type of testing has been pretty standard for a good while now, but having been away from large web applications for a few months, it’s nice to return to them and be reminded of both the performance and impact of automated acceptance testing.

It looks like by the time I’m about halfway through the work - early next year - I’ll have an end-to-end demo of everything in the statement of work. That’s good. I like getting to end-to-end as fast as possible. It doesn’t meant that I’m going to finish earlier. Rather, it means I get at least one more pass at the whole piece of work, having explored the depths and edges of the problem. Unknown unknowns rear their heads faster when you can see the entire workflow laid out.

It also means that I’ll have learned enough about the real problem, which enables me to make an informed second pass. My first pass, which I’ve nearly wrapped up, is a highly literal interpretation of the brief. It achieves the tasks and pass the tests, but that’s about it. There is room for polish, and also room to refine the brief based on what we now know. So we’ll look at how well everything works, what assumptions I’ve made that are incorrect, and what assumptions the brief made, and see how we can refine everything in a second pass.

That’s a job for a meeting in the first week of 2020. For now, though, that’s a cap on the year. I’ll write up a quick summary of the year’s work over the winter break, I imagine.

This week, I:

• spent three days wrapping up a lot of Willsneck. That meant pairing on finishing up all the content edits, and working through the designer’s snaglist, sanding off many rough edges in my work. Lots of fettling SVG files and learning about some of the esoteric bits of CSS that only apply to SVG. By the end of the week, I’d cleared almost all of my ‘todo’ column, and we’re just in to some final bits of QA and layout tweaks.
• had a long meeting-cum-workshop on Hallin to refine the specification we were agreeing to. No huge surprises here, but it helped a lot to meet the team and go over a lot of things in detail. I’ve got a clearer understanding of their product and domain model, and we’ve largely agreed on what’s to be done.
• found a few spare hours to prod at the electronics project I mentioned last week. Let’s call it Mayhill. This week, I started work on the computer-based tool that will talk to it. I’m writing it in the browser, with a view to porting it perhaps to Electron later on. By the end of the week, I had a neat flow of information between hardware and browser, over MIDI Sysex, and a reactive UI built in Svelte playing ball with everything. Fun!

I submitted the last of the content for Longridge this week. That means that project is now into review, and should be going live next month. It’s been a bit longer to get here than planned, but I’m very pleased with the results.

I started getting into the meat of Willsneck. That mainly involved more old-fashioned front-end code: HTML, CSS, and the lightest sprinkling of Javascript where appropriate. I also spent some time applying CSS keyframe animation to SVGs, which led to results swiftly.

And I kicked off building out the deployment infrastructure. I always like to get deployment up and running early: it’s one less thing to worry about later in the project. In this case, I’m doing things a little differently. We’re deploying the site to Github Pages, and using the just out-of-beta Github Actions as a continuous integration to do so.

I really like this setup. It’s similar to the way tools like Netlify work, but with a little more control in exchange for a little more complexity. Rather than being reliant on the few static-site builders that Github Pages allows you to use, we’re using Actions as our builder. That means on every push to our master branch, an Action runs on a virtual machine. That Action checks out our code, installs dependencies (and caches them for future runs), and builds the site to a dist/ directory. And then it commits the contents of that directory back to our gh-pages branch.

That means we get continuous deployment of a static site on every push to master, but without having to store the compiled artefacts in the repository. Which is exactly as it should be: the repository contains the source for the site, not the compiled code as well; it’s generated as necessary. This setup is working well with my temporary Parcel-based site, and it’ll be straightforward to move to using Hugo for the final site.

I’m impressed with Github Actions, and will consider it more for future tooling - the ability to run actions on a schedule means that many of the sites I’ve not moved to simpler builds or platform largely because of a lack of cron on them… might now be possible to move to a static site, and a few scripts running on GitHub.

Finally, I took a quick look at the code for Hallin and got it spun up on my own machine - good enough going to be able to schedule a first meeting for that project.

A good week: lots of code, nice to be back in a client office again, and one project nearly on the runway.

Longridge is properly coming into land now. That’s meant almost all my work on it has been dealing with feedback: minor edits, checking the content on the platform itself, final feedback on videos. There’s a big deadline next week, and there’s about the right amount of things left in the right state, which is about the best you can ask for. It helps that, having taken a while to come together, I’m pretty pleased with the content we settled on, and how it’s come out. I’m hoping the peer review process will go smoothly.

Willsneck kicked off on Thursday: a short website build gig. I’d already been briefed by the team, and so hit the ground running, working on building up basic infrastructure for developing the site, and the first pass of the flat pages. Working in the browser in 2019 is really rather satisfying compared to twelve years ago: the promise of web standards is finally truly paying off, and Grid and Flexbox make life a lot easier.

One of the new things I’ve decided to learn on this project is Parcel, which I’m using as a bundler/build tool for writing the flat pages. Normally, the minimum I need is compiling SCSS (which I like for tidiness), so that means integrating with PostCSS for compilation. This time, I’m also using posthtml for processing my static markup. posthtml is doing two things for me. By using posthtml-include, I can use very, very simple templating - just including one HTML file in another. But that’s enough to handle repetitive elements like headers and footers, before I port the whole static build to a content management system. I’ve also found that posthtml-expressions will let me include data and simple JS expressions in my templates. That’s particularly handy for some pages that are going to be driven from JSON-based data - I can prototype with the real data before we even get near the CMS. Always useful to add new tools to the belt, and I’ve found these libraries combined with Parcel to be the Right Level of Simple for the job at hand. Willsneck continues next week, as I get into the thornier detail work around art direction, SVGs, and CSS animation.

Hallin, the other small software development job that’s on the table, edges closer to likelihood. I spent an hour or two going over the existing code and writing enough documentation for myself to be able to spin up the project from a bare checkout. That was… neither as easy as I’d like, nor anywhere near the hardest spin-up I’ve had to do. But it’s useful for getting a feel for what adding functionality to someone else’s long running codebase will feel like, and useful feedback to the potential client.

Finally, for an entirely separate personal project, I ordered an electronics prototype from JLCPCB. I’ve used JLC a few times for prototype boards. This time around, I’m also taking advantage of their prototyping service to build up the boards (or, at least, about 75% of them, the remaining components being things they don’t have, or that I can source cheaper). Exciting to see how those will come out. This is also the first board I’ve designed in KiCad. This article and the scripts in it were highly useful for generating a positioning file.

Looking at those notes reinforces what I already was feeling in my bones: it’s going to be a busy end to the year.