rob.rho.org.uk

3D printing has, for a few years now, been something that I’ve watched with interest from a distance, but never quite felt compelled to plunge into. This began to change when the girls found some cute articulated dragons in a souvenir shop. When they learned that these had been made by a machine that you could actually have in your house, they were immediately hooked on the concept. This turned out to be the push I needed to start looking more seriously.

The world of hobbyist 3D printing has come a long way in the 15 years since the patent on FDM lapsed. The printers of today are leaps and bounds ahead of those from even a few years ago, in terms of quality, reliability, and, in particular, ease of use. While it’s still possible to get a printer that is also a project, I decided that (for the moment, at least), we were more interested in the capabilities than the device itself. Hence, I wanted something simple, dependable and beginner friendly. Bambu Lab kept cropping up in both personal recommendations and reviews as a stand-out in these areas, and they happened to have an early Black Friday sale on. I bit the bullet and ordered their entry-to-mid-range A1 Combo.

Delivery took a week or so, which gave me time to clear out a bit of space in the spare room, and reinforce the desk to make sure the printer had a solid home. Unpacking and setting it up was a breeze, and (with a quick check on my thinking on Reddit) I was soon holding my first Benchy, pictured above.

The A1 itself lived up to the hype in terms of ease of use. In fact, it was so straightforward that it felt like cheating, with none of the manual calibration, tweaking of settings and crossed fingers traditionally associated with 3D printing. Modern printers in general, and Bambu Lab’s in particular, have really reached the point where you can just use them. There’s still plenty of tweaking and learning that’s possible, but you get pretty good results out of the box with a minimum of fuss. The question remains, though: why?

When you get, say, an upgraded iPhone, it does basically the same things as your old one, just better and more. In contrast, getting a 3D printer opens up something entirely novel, a new capability that you didn’t have before. This is exciting, and increasingly rare in the realm of technology. The ability to design something unique on screen, and then press a button and have it in your hands¹ feels truly magical.

3D printing is not yet quite mainstream, either in terms of cost or ease, but it’s not far off. In some ways, it’s reminiscent of the microcomputer revolution of the late 70s and early 80s, where home computers went from something that you had to build to something that you could buy ready to use. This kicked off a flowering of creativity and exploration, making it (then and now) an interesting time to be getting into the area.

More important than the big picture, though, is the happy surprise of the degree to which it’s fired my imagination (and the girl’s). My mind is fizzing with what to make next.

As part of my recent host move, I decided it was time to review my web server situation. Specifically, I decided to move on from Apache. It’s served me well over twenty years, and adapted to all of the changes I’ve thrown at it (most notably HTTPS), but my configuration was a tangle of two decade’s of cruft, and since I started other options have emerged that would be more directly applicable to my use case. The switch presented an opportunity to start with a clean slate, so I took it.

My initial plan was to move to nginx, as I’m already very familiar with it, and was confident it would do what I need. However, my friend and colleague Cal suggested I take a look at Caddy, and this turned out to be a very good call.

Caddy is a relatively new kid on the block, and I’d only previously looked at it in its very early days. Coming back to it, it’s now a fully-fledged, production-ready web server, with a few tricks up its sleeve. The most obvious, and most widely applicable, is that it automates the serving of HTTPS, right down to requesting certificates from Let’s Encrypt. Moreover, it touts streamlined configuration that’s so simple you can be up and running in minutes, rather than hours.

This all sounded too good to be true, but I gave it a go and it was 100% on the money. I had a fully working copy of this site, including HTTPS, up in well under 15 minutes (including installing Caddy itself), and by the end of half an hour had sorted out all of the weird redirection and legacy HTTP stuff I wanted to and switch over the DNS. It really is as easy as they claim, at least for the sort of things I want to do.

Of course, nothing is perfect. I suspect there are plenty of edge cases that it can’t handle as well as other options, and for very high volume usage you can find better performing options. Those caveats only apply to a small minority of users, though. If you are within the (very wide) range of what Caddy can do, it’s hard to beat.

My recent post was accompanied by a picture of the Lion and the Unicorn from Through the Looking Glass, flanking Alice holding a cake. This isn’t as random as it might seem. My new server is called unicorn (partly in a nod to Mythic Beast’s traditional branding), and the old server was called cake.

Those names aren’t random either; I follow the venerable sysadmin tradition of naming computers according to a theme. In fact, I have two schemes; one for my personal machines, and one for my work ones. See if you can guess what they are:

Personal: unicorn, cake, cheshire, dodo, tweedle, redqueen, hatter…

Work: gnoll, carrion, kobold, bugbear, owlbear, hobgoblin…

The first is probably pretty obvious, but the latter less so (it’s very specific). As an extra point of clarification, my current personal laptop is called gryphon, and that’s not ambiguous.

I’ll update this post to include a (hidden) answer, but for the moment I’d be interested to hear your theories on Mastodon.

A long while ago, when I first moved this domain to its own server¹, I went with ByteMark, on the basis of recommendations from a few people I knew and who’s opinion I trusted. This trust turned out to be well-founded, and I was a happy customer for a long while.

However, in 2018, they were acquired by IOMart. This was uneventful at first, but then prices started to creep up, and I started to hear grumblings from other customers about the service going downhill. However, I didn’t hit any problems myself (my needs are very simple), so inertia kept me where I was.

Things came to a head last February, which ByteMark (“An IOMart Company”) announced that they were shutting down BigV, the virtual hosting product I used, with three month’s notice. This put the wind up me and many of their other customers, and I started to look around for alternatives. Ultimately, on that occasion, they relented and kept the service going, but my confidence in them was gone. When they made a similar announcement again a few months ago, I pulled my finger out and actually started to move things.

After a brief search, I’ve gone with the strongly Cambridge-connected Mythic Beats, again on the basis of many personal recommendations. Not only has this cut my monthly bill in half, but I’ve so far been impressed with the service, the support, and the general ease with getting everything set up. As of this evening, all of my web, mail and DNS presence has been migrated over to a brand-new virtual server, and I can wind down the old one.

I’ve also used the opportunity to revisit and modernise my setup (some of the configuration was literally two decades old; time tested, but due a refresh). I’ll be following up with some more posts over the next few weeks, going over some of the highlights of what’s changed. Overall, though, it was a very straightforward process, and my only regret was not doing it sooner.

Update — Posts about the move:

• What’s In a Name?
• Moving to Caddy

Last weekend, I decided to take a break from the ZX81 to play with something more colourful, a Recreated ZX Spectrum that we picked up at the same time. When looking at the extra BASIC commands on offer, I noticed CIRCLE, and before I knew it had whipped up something topical:

This was pleasingly easy to do, and also reveals the Spectrum’s characteristic colour clash. For comparison, I decided to do the same thing on the Electron:

Pro: no colour clash. Con: had to write my own circle-drawing routine. Pro: in BBC BASIC, you can do this as a PROC.

I posted a video of the Electron laboriously drawing the circles, and then quickly folowed by tweak that made it approximately as fast the Spectrum. It was at this point an old friend nerd-sniped me by pointing out that I’d used a naive algorithm, and there was a far smarter one available.

100 REM Circle drawing using simple trigonometry
110 DEF PROCcircleT(cx%,cy%,r%,s)
120 tau=PI*2+0.3
130 MOVE cx%,cy%+r%
140 FOR t=0 TO tau STEP s
150 DRAW cx%+SIN(t)*r%, cy%+COS(t)*r%
160 NEXT
170 ENDPROC

Suitably chastened (and switching to Owlet for convenience), I implemented Jesko’s method, an extension of Bresenham’s line drawing algorithm that draws accurate circles with only integer additions. (Forgive the repetitious PLOTs; I wanted a quick proof of concept.)

200 REM Bresenham circle drawing
210 DEF PROCcircleB(cx%,cy%,r%)
220 t1% = r%/16
230 x% = r%
240 y% = 0
250 REPEAT
260 PLOT 69,cx%+x%,cy%+y%
270 PLOT 69,cx%-x%,cy%+y%
280 PLOT 69,cx%+x%,cy%-y%
290 PLOT 69,cx%-x%,cy%-y%
300 PLOT 69,cx%+y%,cy%+x%
310 PLOT 69,cx%-y%,cy%+x%
320 PLOT 69,cx%+y%,cy%-x%
330 PLOT 69,cx%-y%,cy%-x%
340 y% = y% + 1
350 t1% = t1% + y%
360 t2% = t1% - x%
370 IF t2% >= 0 THEN t1% = t2%: x% = x% - 1
380 UNTIL x%=y%
390 ENDPROC

The result were a bit of a surprise; it was slower by a factor of two when compared to my naive trigonometry method (7.88s vs 3.86s), as you can see here. For comparison, the circle plot function in the Acorn Graphics Extension ROM (available in Owlet, but obviously not my Electron) clocks in at 0.01s.

A bit of thought revealed the problem; the above implementation takes unit steps in coordinate space. BBC BASIC keeps this fixed at 1280x1024, no matter what how many pixels are actually available. I was running in MODE 2 (the only mode capable of displaying enough simultaneous colours to recreate those Olympic rings), which as a resolution of 160x256 pixels, meaning that each pixel was eight by four coordinate units. Hence, my naive implementation was plotting each physical pixel many times.

Fixing this fully would involve taking into account the non-square pixels, making the symetry between the octants far trickier. However, we can get most of the way there by taking a simpler approach and skipping four pixels at a time (the smaller edge). Here, we’re still double-drawing some pixels, but the symetry remains intact and the resulting circle doesn’t have any gaps. Making that change brings the time down to a far more respectable 2.02s. Flushed with success, I managed to get it down to 1.6s by moving the PLOTs into assembler.

The next step would be to move the main loop into assembler, but that’s a fair but of work due to the bigger-than-a-byte integer maths, so I decided to call it a day. It was an enjoyable diversion; the well-defined problem on a limited system meant the above was only a few five- and ten-minute stretches of playing around between other things, rather than a major commitment. A brain-teaser rather than a whole project. Sometimes, that’s exactly what you’re after.