I teach a Guardian Masterclass as part of their “Digital Journalism Bootcamp” course. Specifically, my part of the month-long class is a 90 minute workshop aimed at journalists, outlining how developers work, what they do, and how they use process to organise work (there’s an Agile taster session). There are also some more general tips on how to get on with a type of person who’s traditionally seen as a bit grumpy, difficult to communicate with, or even hostile.
In this latter section, I found myself being challenged by one vocal member of the group who interrupted me a few times to point out that “I do that too”, particularly during a section on the cost of context-switching. I was talking through a slide which looked like this:
I was beginning to say something about the situation where a developer is juggling multiple things in their head at any one time, and how costly it can be when someone comes along and interrupts that flow. She spoke up to say that when dealing with clients, for example, she too is often juggling multiple things around. I tried to fumble an example of how a developer may be thinking about variable scope, cross-browser API implementation, an outstanding pull request to review and remembering which branch to commit on – all at the same time – but to a non-technical audience this was quite a challenge to explain.
It did get me thinking, though. I have other slides in this section dealing with the developer clichés: don’t fill their calendar with meetings; don’t disturb them when they have headphones on; keep communications brief and ideally asynchronous. But why do any of these things apply specifically to developers?
This same woman had challenged me earlier in the session when I hinted at some of these points and she suggested developers were “just being precious”. I conceded this, saying that because of their (likely) introvert personas, sometimes humouring them with this was the way to achieve results. This resulted in some challenging questions from another attendee at the end who felt I was telling them to “pander” to developers. Again, I was left wondering why we talk about things in this way.
Developers (“makers”) aren’t some special race of superhumans, whose every sensitivity and quirk needs to be preciously catered for. We’re normal people and shouldn’t be made to feel otherwise. Developers love to scoff at project managers and HR people, clogging up important coding hours with pointless meetings and busywork. Again, while there’s some truth to that, it’s also supremely arrogant to label ourselves as somehow above the systems everyone else works with (grudgingly or not).
Maybe my slides are just plain wrong and these tips just apply to people in general. But when researching the talk and reading up on other people’s top tips for productive relationships with developers, these were the kind of points being raised time and time again. Do we really think that as a profession we deserve special treatment?
The woman at the end suggested there was some give and take in both directions, which I agreed with, pointing out I was teaching a class to journalists about working with developers, and not vice-versa. Still though: why do you think we treat developers like their needs are special and different from others? How much of this is really true?
It was one of those fateful moments where you catch yourself thinking “how difficult could it be?”.
It’s been ten years (almost eleven now) since I started Scene Point Blank, the online music zine which came to define my late teens and the eventual career path I’d choose. It started out as a collective of music-loving nerds from an online messageboard writing about punk and hardcore. The website branched out and expanded and a decade later we were wondering what we could do to celebrate ten years of publishing.Since our roots were in the punk publishing world of fanzines, we talked about producing a print zine for the tenth anniversary. Eventually we rejected this due to the complexity of distribution and up-front printing costs. Scene Point Blank isn’t a profitable venture and we didn’t want to have to learn complex lessons about shipping product and fulfilling orders.
It was around this time that I remembered that Kindle books are literally a zip file containing HTML, CSS and image files. This is pretty much all the content of Scene Point Blank is. How hard could it be to just write a quick template to spit out eBook-friendly markup and publish the thing?
Quite hard in places, it turns out.
The decision to publish for e-readers was expanded by the discovery of lulu.com, a self-publishing platform. Lulu offer a print-on-demand service: you upload a PDF, your users buy it, and a single copy is printed somewhere near their location and mailed to them. It’s basically vanity publishing and the cost per unit is so high that it’s probably non-profit publishing too, but our goal wasn’t to make money, but simply to have a book of our best work that people might read.
This changed things a little. While it’s certainly possible to convert HTML into a PDF, I didn’t want to have a print edition of the book which was an afterthought. Dusting off my copy of InDesign, I decided to return to the skills of my former job as a graphic designer and actually create a proper print edition.
Next I discovered that Amazon offers an “Export to Kindle” plugin for InDesign. A few quick experiments revealed that the output of this tool was pretty decent for our needs: we weren’t using any images (mainly due to copyright concerns about things like album artwork and press photography) and it handled typography pretty well. My strategy became: design the book for print, then export a Kindle version from that.
This almost worked. I reacquainted myself with InDesign and printed pages of proofs to test font families, line spacing and margins. There are a lot of things I’d forgotten about that ended up being important concerns for a well-typeset book:
1. Inside margins need to be larger than outside ones to compensate for the spine/fold:
2. Hanging punctuation probably belongs on the outside of the margins otherwise justified text looks a little unusual:
3. Hard linebreaks between paragraphs look good on the web, but weird in print: the job of replacing them all was a tricky one (but luckily, InDesign supports regexes):
4. Widows and orphans are difficult to fix automatically (eg. without actually editing text) unless you’re happy to sacrifice consistent tracking (which you shouldn’t be):
Getting this right wasn’t impossible but took a fair bit of trial and error. It wasn’t until I received the first test print of the book from Lulu before I could find out if some of my work was usable or not. It turned out that the chapter intro pages I thought looked great onscreen looked a bit rubbish in print:
The cover was another thing I made a mess of initially: like a fool I forgot to account for the spine (perhaps because the magazine I worked for as a designer wasn’t bound with one) and so when it came to uploading the cover my design was several centimetres short. I quickly added one but the fact that its width was variable because of my page count meant I had to wait till all the book’s content was finalised to confirm its dimensions.
Generating a table of contents was also problematic: I’d used InDesign’s paragraph styles religiously, but perhaps not in the way it wanted me to: for our album reviews I typeset them like this:
This meant that when generating the ToC I couldn’t achieve an output of “Janelle Monáe – The ArchAndroid”: InDesign would treat each entity as a separate (but duplicate) page reference. After giving up finding a smarter solution I ended up manually curating the ToC, which has left me wary of changing the page numbering (and therefore most of the content).
The Kindle aspect became more difficult at this point. The aforementioned chapter pages became more of a challenge for the e-reader. Although Amazon’s plugin didn’t attempt to recreate the shaded background or circle shape, it did do weird things to the type in terms of pagebreak locations and heading sizes. I tried playing with the export options to no avail and began to investigate InDesign’s methods of outputting different layouts.
It turns out InDesign has several different methods for varying content:
Alternate Layout, which lets you keep the content but lay it out for another device or dimension, which seemed exactly what I needed. Amazon’s plugin ignored this completely when exporting: back to the drawing board.
Next I tried Conditional Text, seeing if I could just change a variable (e.g. print=true) when exporting and supply different text fields to the Kindle edition. Again, Amazon’s plugin ignored this. I could generate PDFs happily using these techniques, but I wanted the pure . format as exported by Amazon, presuming it would be the most “correct” format.
Object States seemed like another solid option: surely I could use them to just change the visual styles for the problematic pages at export time? Nope: once again, meaningless to Amazon’s plugin.
In the end I gave up and did the thing I’d been worrying I’d have to do: duplicated the entire document, saved it as “Kindle Edition”, and made the changes manually. The whole reason for doing it this way to begin with was so I could make changes in one place and export to all platforms. That dream had died with my chapter headings.
In the end, I think it was the right call. There was a certain feeling of liberation: every time I changed things in the print edition I didn’t have to spend five minutes nervously exporting to Kindle to check I hadn’t broken something. The problematic ToC became less of an issue as I could manually edit the print one but fix the auto-generated one for Kindle without butchering the printed version. Page breaks that worked in print but felt pointless on the Kindle were removed and vice-versa. The thing I’d been worrying most about – fixing typos and editing content in multiple formats – was rarely an issue. Maybe this was down to fairly diligent spellchecking before forking the document, or just luck (or ignorance).
Finally, it was time to actually publish the things. Lulu provides you with an ISBN for free when using their service, which was nice and helped me feel like the process was legitimate. They also allow you to set the book price, but it must be above a minimum, which is their printing costs + their own cut of profits, I assume. Our minimum for a ~350 page book was £9.20, which is fairly steep for a paperback, but we set it at £9.50 and on we went. Once the PDF was uploaded it was available to buy: vanity publishing, no question.
Amazon was interesting: I thought it’d take a while for it to be approved for sale. As it turned out it took less than a day. An automated scan came back after I uploaded the .mobi file, which pointed out typos I’d missed. These fixed, I resubmitted and suddenly there it was, on Amazon. I had to fill out some lengthy tax information for the US taxman, despite my bank account being a UK one, which meant I had to guess at some of the values and acronyms used in this form. I also had to create a separate author profile for each country Amazon operates in: this seemed sensible, in that you may wish to tailor these to each market/language, but it would’ve been helpful to have an “Import from Amazon.com” option when editing the UK profile.
All in all, the process was more complex than I naïvely expected. I think I would have ultimately saved time if I’d forked the book earlier and avoided trying to reach the “purity” of a single input with multiple outputs. I suppose I could’ve simply published the Kindle edition as HTML/CSS and hand-tweaked it, but life’s too short when the content is 115,000 words long.
For all the vanity publishing jokes, Lulu is a great service. The price is fairly competitive given that it’s printed on demand, and the quality was fairly good (I could’ve picked more expensive paper stocks and dimensions but was aiming for a sub-£10 product). Getting an ISBN helped make it feel more “real” (Amazon doesn’t require these for Kindle self-publishing) and although I found them slow, their tools for uploading and managing content were pretty usable.
If I was to do it all again I’d have accepted that publishing multiple formats is too different to expect one tool to process them all. That said though, it’s almost trivially simple to get something online and for sale. It’s easier than ever to publish your stuff, so why aren’t you doing it too?
Note: this blog entry is taken from the first print issue of the experimental “algorithmic newspaper”, The Long Good Read. You can find more about that project on the official site.
A developer I work with has been at the company for a decade. His argument for that longevity? He says it takes five years for code you wrote to come back and bite you once it needs replacing. This reminder of our role in the half-life of technology is something I find fascinating: what does it mean that we’re not futureproof?
It’s a humbling experience to have that realisation, that moment of clarity. To know that your decisions which were once sound, best practice, are today the examples shown to fledgling hackers to scare them into avoiding monolithic codebases or teach them why modular programming is important. But if it takes five years for this process to happen, why bother building things for the future in the first place?
We’re taught as software developers to architect our work with an eye on scalability: not just in terms of traffic and speed, but in terms of feature growth and expansion. Every simple problem becomes a complex challenge to solve: it’s smart to be multiple steps ahead of what your users want today.
Why bother with any of this? We’re building systems trying to anticipate every problem or change and then throwing them all away again a couple of years later. How many projects have you been involved with where the agreed solution is to chuck out the old, legacy code, and start afresh? All those architectural decisions have been learned from, updated, but ultimately dropped. Five years.
The first company I worked for was a small magazine with a dozen staff. The owner had a bit of a tech background and had gone all-out when preparing the company’s IT systems. In a dedicated room in the basement there was an enormous server rack complete with multiple RAID setups and copious air conditioning. There was a six-way monitor switch allowing you to view output from any of the machines and a steel cupboard full of cables, accessories and tools.
The office was running Windows 2000. In 2010.
Sometimes it’s easier to focus on futureproofing things and building with flexibility in mind than it is to work out what’s valuable and how to get there quickly. In practical terms, nobody at that company cared how many redundant disk backups there were, they were annoyed that they were still stuck using IE6.
Do I really believe we should code by the seat of our pants? Perhaps not quite. Anyone can hack together a quick PHP/MySQL fix which solves a problem temporarily, but the skill of analysing the problem domain and being several steps ahead of it is one that takes real practice – and adds real value. But perhaps there’s something in the idea of accepting the length of your tech half-life – and embracing it. You’re going to be wrong, one day. And that’s fine.
Twenty-four hours ago I posted a mildly ranty tweet (I know, I can’t believe it either) about the current proliferation of techniques/tools for modern web development. Here’s the tweet in question.
This was a frustrated summary of something I’ve been feeling for quite a while now. I’m a front-end web developer of a fair few years now and I feel like the last couple of years have really seen the rise of a kind of web development I’m not sure is actually good for the web. I’d like to expand a little here on why that is.
The rise of the DevOps movement of late has been a large factor in this process. There’s a lengthy article doing the rounds from Smashing Magazine describing a semi-mythical superdeveloper who can deploy code anywhere, test anything, automate package management and compile code assets like her life depended on it. Nowhere in this fantasy does it talk about the quality of the user experience of this imaginary product; the metrics of its user engagement; the visual language of its design (except to say that they’re all meaningless if the performance is poor).
Performance is of course a hugely important measure in this age of the mobile web, but performance for performance’s sake trivialises what we do. A relentless focus on how to scrape every last frame from Chrome’s rendering engine seems a bit redundant when the page it’s loading is a half-baked rendition of something a smarter agency did nine months previously. Why render a beautiful graph of pageload speeds if nobody’s converting on your product signup page?
I want to see more people talking and writing about incredible digital experiences they’ve had. How can we build products and sites more like them? How can we achieve a sense of playfulness and interaction that’s so uniquely native to the web? What kind of interface can we create to best reflect what our tool aims to solve?
The web browser is a bit like a car built to travel on the road that is the web. Each website and app we make is a destination on that road. Let’s stop tuning up the engine and start driving somewhere.
After the example set by my friend Andy, a veritable homebrew beer connoisseur, I decided it was about time I took my liking for proper craft beer and real ale to a new level by attempting to make some of my own. Anything that was possible to do in medieval times with a few wooden buckets and some questionably-sourced water should be more than do-able by a modern-day tech nerd, right?
It turns out that basic homebrewing is almost laughably simple, although the best results I’ve had have been from skipping the most basic methods and graduating to something a bit more respectable. The aforementioned Andy has taken things to an even higher level and his beers have the taste to match — look out for his stuff on sale in Leeds soon, I hope/imagine.
This post aims to document (by request of several beer enthusiast friends) my processes, equipment, what I’ve done wrong and what’s been the best tips. I’m also going to link copiously to the BrewUK website where I’ve bought most of my kit, because they’re a great little store competing with the big boys with brilliant customer care. Show them some love.
What you need to make drinkable homebrew beer
This isn’t an exhaustive list and I’m not an expert by any means, but these are the things I’ve gradually acquired since starting homebrewing in September 2012. You can get all these bits from any good homebrewing shop (or Amazon, but seriously, BrewUK have a great online shop and deliver anywhere) and they don’t take up too much space or require much expertise to use.
All of the stuff I do is “extract brewing” (so perhaps not “proper” homebrewing, but then I don’t have the time/money to fork out for equipment to do “all grain” just yet). You can probably get yourself set up to brew your own beer for about £60 for the equipment and maybe £20 a time for each brew. Here’s my kit list:
- 2x plastic 5 gallon fermenting bin
(these are used to store the brew while it’s fermenting – I use two so I can transfer the fermented beer to a new, clean vessel when bottling, although you don’t have to do this)
- 1x large metal pan
(needs to be able to comfortably hold 5 litres of water — if you’re lucky you’ll already have one; I did)
- 1x decent thermometer
(I bought a jam thermometer from Wilkinson which fits brilliantly into the above pan)
- Set of tubing
(used for transferring the brew from your vessel to your bottles)
- 1x automatic pump
(don’t bother with the suck-and-run type tube where you use your mouth to start it going, it’s unsanitary and often results in a mouthful of tepid beer)
- 1x pack of sanitiser
(this is a powder you add to water to sanitise all your equipment before brewing. I use VWP.)
- 1x bottling tap
(not essential but cheap and makes bottling much, much easier)
- 1x bottle capper
(you’ll need this to properly seal the caps on the bottles)
- 30-40x empty beer bottles
(ideally coloured as transparent bottles let light in, which is bad)
- 30-40x bottle caps
(probably buy a few more than you need, just in case)
- hydrometer and measuring tube
(this is used to measure the “gravity” of your brew, eg. how high its alcohol content is)
- 2x muslin bags
(not essential but make it much, much easier to filter your brew for hops etc)
You can buy starter kits which supply most of the above items for a relatively cheap price, if that’s your bag.
A note on “brewkits”
When I first started I began with a brewkit — these are ready-made tins of syrupy gloopy which you simply add water and yeast to. The results I got from these were fairly uninspiring: both tasted acidic and flat (I’m sure my lack of experience didn’t help either) and generally didn’t really feel like “proper” homebrewing. I’d compare it to cooking a meal from a sauce out of a jar versus making it from scratch yourself.
Extract brewing, the type I’m describing here, is a kind of halfway house: you’re essentially boiling malt extract, hops and sugar together, cooling it and adding water, then “pitching” yeast into it and leaving it to ferment. All-grain brewing is more complex still: you boil the entire thing (not just part of it) so need more equipment and you have to “mash” the malt yourself rather than use pre-prepared stuff like I’m doing.
Okay, that’s enough preamble. Here are the steps I take when making an extract brew. It’s worth pointing out that these are “recipe packs” I’ve bought from BrewUK: their members often reverse engineer popular ales and reproduce their taste and style using common hops and malts. I’m finding this a good way to learn more about the process as I’m not completely in the dark and have a recognisable taste goal to aim for when brewing. When I get more confident I’m excited to start experimenting with flavours on my own.
Brewing your first extract kit: step-by-step
0. Sanitise all your equipment (not pictured)
This is the most boring but most important step, so it comes before all the others. Using your sanitisation solution, soak all your equipment in it for the period indicated on the packet. I tend to fill my fermentation vessels with the solution then dump all the equipment I’m using in this liquid for an hour or so, which seems to work. You’ll also need to sanitise your bottles when it comes to bottling, but for my last few brews I’ve just ran them on a hot dishwasher cycle (after carefully washing them) which hasn’t seen any ill effects.
1. Boil your water and add the malt extract
The specific recipe you’re using will tell you how much to use. In my case I bring 5 litres of water to the boil and monitor the temperature carefully. Here’s the malt extract from my Timothy Taylor Landlord recipe pack:
The malt extract then goes in the water where I maintain a constant temperature for around 90 minutes. It goes in looking like this:
Once it goes in, depending on the type, you’ll immediately get a delicious, rich aroma, a bit like a strong coffee or dark chocolate. This scent is liable to fill your flat so be mindful of non-beer-loving friends and flatmates. Here’s me with a pan of malt exuding deliciousness (the malt, not me):
2. Add the hops
Next come the hops. These are my favourite part, mostly because I like hoppy beers, but also because the effect they have on the character of the brew is really interesting. First I separate them out in a bowl (they typically come in tightly-packed storage so this stops them being clumped together):
One thing I learned about this stage of the brew is the importance of bagging things. Here’s what I do now using a cheap muslin bag:
In earlier brews I just dumped the hops straight into the brew like this:
This smelled great but was a pain in the arse to then filter so I could leave it to ferment cleanly without the hops continuing to effect the flavour. It also meant I had to mess around with this sieve, too small for the vessel, so I sellotaped it in place:
I’ve since bought a large funnel instead, but you don’t need this so much if you don’t foolishly fill your brew with floaty bits instead. Here’s what a proper one should look like:
You can see the usefulness of the muslin bag: the hop flavours are still allowed to soak through and engage the brew, but like a giant teabag, I can just take it out when it’s time.
3. Add the malt and further hops
After an hour or so of maintaining the hops at the correct temperature, you can see how the brew has reduced somewhat and darkened. Now it’s time to add the spraymalt, which is a bit like sugar.
You add loads of this and stir it in: don’t be alarmed if it clumps together in white lumps; stirring it frequently means these mix in.
The brews I’ve done usually stipulate a second type of hops to be added here. Once this is done and the boil is finished, it’s a case of carefully transferring it to your primary fermentation vessel. I use my funnel and filter to strip away any remaining bits as I do this.
4. Fill up, cool, and check the gravity
Then I fill the vessel up with cold water (right from the tap, although if you’re ultra-paranoid about contamination you could use bottled water or cooled boiled tap water) and wait for the temperature to be around 20C. At this point you should take a hydrometer reading:
This tool basically shows you the “gravity” of your brew, which can then be combined with another reading once fermentation is complete to determine the alcohol content of your beer. I usually photograph it from a few angles then I have a less ambiguous reference if I need to refer back to it. On one brew I forgot to do this before adding the yeast meaning I had no concrete idea what the ABV was, but it’s not really a showstopper.
5. Pitch the yeast
At this point you should be ready to pitch your yeast. For this brew I used live yeast (as opposed to dried): I’ve had much better results with these types. This one is liquid yeast and simply requires a good shake before pitching (although it’s very active so treat it like you would a shaken beer can):
This one is a “smack-pack”: still liquid, but contains a dissolvable packet inside which basically activates the yeast cells once broken. You just slap the bag a few times to break the inner packet and then the whole thing expands excitingly. It looks like this:
This yeast worked amazingly well for me, so much so that the fermenting stage got a bit too vigorous and ejected foamy solution all over my bathroom cupboard. Here’s the (very active) fermentation a few days in:
6. Wait (not for the last time)
Now the waiting game begins. Many brewkit recipes say to leave it to ferment for a week but I’ve always done two weeks. Be patient and resist the urge to keep looking inside the vessel as you’ll increase the chances of contaminating it. After two weeks it should’ve reached “final gravity”, which you can see by taking a hydrometer reading. If the reading doesn’t change after two days’ readings, then it’s done and ready to bottle. Here’s the before and after shot of my brew’s gravity reading:
Once the gravity reading stops changing (or two weeks have elapsed, which usually does the trick for me), you’re ready to bottle. Some people at this point run a secondary fermentation where they transfer the brew to a new vessel but I’ve never bothered with that.
7. Get ready for bottling
Before you’re ready to bottle you’ll need to sanitise everything again. In this picture I’ve got a bunch of bottles soaking in hot water in my bathtub. This isn’t to sanitise them, but to make it easier to get their labels off. Some bottles have annoying plastic-based stickers which won’t come off so I gave up and threw them out. You can buy bottles from homebrew stores but it’s more fun to drink them yourself and save them, right?
Once the bottles are label-free, you’ll need to sanitise them. I’ve just been putting them in the dishwasher on a hot cycle which seems to work, but I’ve also experimented with leaving them to soak (again, in the bath) with sanitiser solution and then carefully rinsing them. The dishwasher is my preferred method since the inside of the bath is obviously not going to be the most sterile environment ever.
8. Priming your brew
Before you can bottle your brew you’ll need to “prime” it: this is basically to begin a secondary fermentation inside the bottle where yeast is allowed to react again. To do this you simply need to sanitise around 100g of sugar (I bought special priming sugar which gave better results than household sugar) by dissolving it in boiling water and letting it cool. You can speed the cooling by resting the pan in cold water, covered, like this:
My first brew, I manually added a teaspoonful of sugar to each bottle. This was messy, inaccurate and time-consuming. By transferring the brew into a new vessel containing the priming solution you ensure an even distribution and make things much simpler. Definitely worth the investment in a second vessel, just for this purpose.
Once the priming solution is ready, I add it to my other vessel and position it on the floor (gravity comes in useful in this next section). I then run a tube from the brew vessel (which I moved an hour beforehand to allow it to settle again) into the priming vessel. I bought an automatic pump which makes it pretty trivial to start the flow going as pictured here:
It’s important to try not to disturb the contents of the beer too much and allow oxygen into it at this stage so try to keep the end of the hose inside the priming solution so it doesn’t splash around and cause bubbles. This is how the inside of the fermented brew looks while this is happening:
9. Bottling tap fun
Once you’ve moved your brew into the priming vessel you can swap its position with the original fermentation vessel, again allowing some time for it to settle. I then add the bottling tube to the end of the hose and get it ready to go, as pictured here:
The beauty of the bottling tube means I can just place it inside a bottle and press it to the bottom of the glass. As soon as I lift it up it stops releasing beer so it’s trivial to fill up a bottle. Save yourself time and spillage by just buying one of these right away — much easier than manually turning on/off a tap.
10. Capping and labelling your bottles
All bottled up? The final step is to cap those bottle. I’ve found that the capper can occasionally break the top off bottles and this has only ever happened with clear bottles, for me. Given that clear bottles let the light into your brew this is already a reason not to use them, so I’d avoid them altogether. Remember you should have sanitised your bottle caps too by soaking them in some solution.
All done? You should be tired, probably covered in beerstains, but proud of yourself. I end up with something like this.
And finally, if you have some artistic ability, you can make a label. If you’re a cheapskate you can just nick some envelope label stickers from work and write the name of your brew on there, but I bought some sticker template sheets from Amazon and printed a design onto them which I could then stick over the bottles. They looked like this:
11. A bit more waiting
The next step is more waiting: this beer will improve over time so give it a couple of weeks before you crack one open. If you did everything right you should have something flavoursome, drinkable and even good. Don’t give up if it doesn’t taste quite right: my first few were disappointing but once I got the hang of it I was producing things that I was prepared to share with other people (even with Andy, whose opinion was nerve-wrackingly important to me).
As a final note, it’s worth pointing out that I’ve only done four brews myself and am far from an expert. If I was starting from scratch, though, these are the tips I wish I’d known and the (cheap!) bits of kit I wish I’d had to save time. Good luck, and good brewing.