Last month I switched to SVG icons instead of a web font. I did it as an excuse to play around with SVG and remove an extra HTTP request from each page. It seems there are other benefits too:
Seren provided several eye-opening examples of accessibility issues caused by icon fonts. I learned, for example, that many people with dyslexia use a special system font that breaks icon fonts.
I like coffee. I like the taste and I like the experience. It forms a part of my routine,and I look forward to my morning coffee each day. Yeah it’s only a drink but it’s one of my hobbies and with hobbies one is permitted to be obsessive or unnecessarily indulgent.
I don’t think I’ve ever been particularly adventurous in my methods for brewing coffee at home. I’ve never had an espresso machine, (espresso is a treat for outings) and had only brewed with a french press… until one day I read someone I respect rave about the AeroPress. They didn’t seem to be expensive, so I grabbed one and have never looked back. The easy cleaning got me, and the great taste and alternative recipes kept me.
Unless it’s an emergency 1 , I get my coffee from Zokoko which is the retail front for Morgan’s coffee. They import and roast, and tend to have new single-origin beans each week (here’s a map of the last year or so of single-origins). The staff are really friendly, make great coffee and have incredible brownies so it’s never a hard thing to drive the 10 minutes down the road from my place to visit.
I’ve recently started a fortnightly subscription from SampleCoffee. Each fortnight they post a bag of freshly roasted single-origin beans and while it’s a bit more expensive than a trip to Zokoko, I thought I’d try something different. Followup: SampleCoffee didn’t work out. I loved the packaging and attention to detail from them but found their light roasts to be too sweet. Once they start an espresso roast I’ll probably try them again.
I couldn’t bring myself to spend several hundred dollars on a burr grinder, so for ages I used a $50 blade grinder. Yeah, it gives an inconsistent grind and apparently it heats up the beans as it grinds, but it’s served me well and I’ve enjoyed the coffee that I’ve made with it, and that’s what counts for me. The downside of the blade grinder was that I couldn’t use it to make my morning coffee (4:30-5am) because of the noise. So I’ve been getting my coffee ground by the place where I’ve bought it, mostly Morgan’s/Zokoko. My rationale is that they have a top end grinder, which gives a great grind, and I go through a bag of coffee every week so it doesn’t have a chance to loose much of its flavour. Actually, it did have a chance to lose some of its flavour but I was none-the-wiser and still enjoying it, so it was a good option. Having started a subscription with SampleCoffee, which only delivers beans, I thought I’d investigate options for grinding and found that the Porlex Mini Hand Grinder was inexpensive ($40) and quiet, and easy to use. Having the grinder at home meant that I switched to buying beans from Morgan’s. The aroma from freshly ground beans is wonderful and the taste is a step up. It was a great purchase.
There are about infinity different ways to prepare coffee using an AeroPress. I use an iPhone App called AeroPress Timer that has step-by-step guides to some of the better preparation methods, and a timekeeper function to help while using the recipes. I like it because tells me when to do move to the next step (so I don’t need to think, which is an important consideration at 4:30am) and it gives several preparation methods (different grinds, different timing), all from winners of national AeroPress competitions (yeah, that’s a thing). I generally use Martin Karabinos’ second place recipe from the 2014 comp with a few small modifications. The original recipe is:
18.5g coffee, 92℃, 215g water, EK43 grind at 6.2. AeroPress in regular position. 80g of water at 35C for 3 minutes, stir well and close AeroPress. 135g of water at 92C, stir once and push slowly for 30 seconds.
My changes:
The only other thing worth mentioning is that I preheat my mug, lest I have beautifully brewed, tepid, coffee.
Coffee preparation can be as simple or as complex as you want to make it. This is my sweet spot at the moment, where preparation and consumption remain enjoyable - hobbies should always be enjoyable, and this certainly is for me. If it looks like it’s not, a gentle reminder is most welcome!
An emergency involving a lack of coffee. A first-world problem if ever I saw one ↩
I’m in the process of rebuilding my primary Mac (stuff broke and it was easier to do a clean install than try to fix them). One of the things that broke was my normal backups to my Time Capsule, and while I’d successfully done a temporary backup to a local USB drive, that data wasn’t available in the Time Machine interface. I reverted to the old skool approach and did the restoration directly, following this pattern (in the case below, restoring my ~/bin directory):
mercury:~ root# cd /Volumes/Offsite Set 1/Backups.backupdb/mercury/2015-07-05-074244/Macintosh HD/Users/esteele/
mercury:esteele root# tar -cf - bin/ | (cd /Users/esteele/; tar -xvf -)
When I tried to edit one of the transferred files, I got permissions problems even though, at first glance, filesystem permissions suggest I shouldn’t have problems at all:
mercury:~ esteele$ touch bin/testfile
touch: bin/testfile: Permission denied
mercury:~ esteele$ ls -l bin/testfile
-rw-r--r--@ 1 esteele staff 159 4 Jul 08:52 bin/testfile
Most of my day is spent on Linux machines, with occasional ventures onto OpenBSD, but I knew that the @ in the listing was significant and that MacOS made use of flags and extended attributes on files. After fumbling around in chflags (1) and xattr (1) man pages and then the ls (1) man page, I could see that the @ meant that extended attributes had been set, and that there were no flags on the file (the dash to the left of 159). I thought it unlikely that those extended attributes were responsible for the permissions problems that I was seeing, so I moved on:
mercury:~ esteele$ ls -lO bin/testfile
-rw-r--r--@ 1 esteele staff - 159 4 Jul 08:52 bin/testfile
mercury:~ esteele$ ls -l@ bin/testfile
-rw-r--r--@ 1 esteele staff 159 4 Jul 08:52 bin/testfile
com.apple.metadata:_kTimeMachineNewestSnapshot 50
com.apple.metadata:_kTimeMachineOldestSnapshot 50
But any operation to modify the file was impossible, and the messages from rm were quite confusing
mercury:~ esteele$ rm bin/testfile
override rw-r--r-- esteele/staff for bin/testfile? y
rm: bin/testfile: Permission denied
I knew that more granular permissions existed past the usual owner, group, other paradigm, but didn’t think they were in play here because of a comment in the ls man page.
If the file or directory has extended attributes, the permissions field printed by the -l option is followed by a ‘@’ character. Otherwise, if the file or directory has extended security information (such as an access control list), the permissions field printed by the -l option is followed by a ‘+’ character.
After quite some gnashing of teeth, I discovered that they were in play…
mercury:~ esteele$ ls -le bin/testfile
-rw-r--r--@ 1 esteele staff 159 4 Jul 08:52 bin/testfile
0: group:everyone deny write,delete,append,writeattr,writeextattr,chown
But why didn’t I see a + when I ran ls? It seems extended attributes get display priority over ACLs (notice how the @ is replaced by a + when the extended attributes are removed)
mercury:~ esteele$ ls -l@ bin/testfile
-rw-r--r--@ 1 esteele staff 159 4 Jul 08:52 bin/testfile
mercury:~ esteele$ sudo xattr -d com.apple.metadata:_kTimeMachineNewestSnapshot bin/testfile
mercury:~ esteele$ sudo xattr -d com.apple.metadata:_kTimeMachineOldestSnapshot bin/testfile
mercury:~ esteele$ ls -l@ bin/testfile
-rw-r--r--+ 1 esteele staff 159 4 Jul 08:52 bin/testfile
How frustrating. In retrospect I can see how the man page is alluding to this behaviour, but it’d be easy to make this more explicit e.g.
If the file or directory has extended attributes, the permissions field printed by the -l option is followed by a ‘@’ character. If the file or directory has extended security information (such as an access control list), the permissions field printed by the -l option is followed by a ‘+’ character, unless the file or directory also has extended attributes, in which case only the ‘@’ character will be shown. In this case, view extended security information using the -e option.
Or better still, if you’re going to jam several flags into a single character and there aren’t many combinations, use another character to represent combinations of the two e.g.
If the file or directory has extended attributes, the permissions field printed by the -l option is followed by a ‘@’ character. If the file or directory has extended security information (such as an access control list), the permissions field printed by the -l option is followed by a ‘+’ character, unless the file or directory also has extended attributes, in which case the permissions field printed by the -l option is followed by a ‘#’ character
So finally I was able to remove the ACLs, and everything was back to normal
mercury:~ esteele$ chmod -a# 0 bin/testfile
mercury:~ esteele$ ls -le bin/testfile
-rw-r--r-- 1 esteele staff 159 4 Jul 08:52 bin/testfile
mercury:~ esteele$ touch bin/testfile
mercury:~ esteele$
So, this was a small journey into less frequently used file attributes made necessary by a failure but complicated by unintuitive documentation. I don’t know why the failure happened but it makes me appreciate good documentation all the more, and particularly the effort that the OpenBSD guys put into their man pages.
My day job is mostly running a team within IT Operations but I also do a bunch of product management for in-house web-based and command-line tools that help us manage our production environment. My employer sent me to Velocity Conference where I heard some great Ops and Web development talks. Some of the talks were also relevant to this site, so I’ve put a few into action and this post will explain the wins.
My two favourite webby talks were Ilya Grigorik’s presentation on HTTP2 and Bruce Lawson’s talk about web performance in the third world. My take-aways were:
The Designing for Performance book suggests ways to reduce image download size without tangibly compromising quality. I took their advice and used ImageOptim to apply a bunch of size reduction techniques to my images, including setting JPEGs to have a maximum quality of 80%. ImageOptim reduced the filesize by about 60% (compared to the flickr-hosted images) and I couldn’t tell the difference.
Previously I was allowing Flickr to host the images, so this optimisation technique meant that I needed to host them myself. Hosting the files on this site saves a DNS lookup and SSL handshake (as long as I’m not loading so many images that multiple connections are opened) but I don’t get the advantage of using Flickr’s CDN. When I host the images myself, the site loads faster for Australian viewers (1.5s document complete) than when I use the flickr CDN (1.7s document complete) because the nearest Flickr CDN to Australia is in Singapore, which is a ~160ms round-trip. An Irish viewer would have a slower experience from my self-hosting (4.3s document complete) because Flickr has a CDN in Ireland, and that’s only a few milliseconds away.
While I could easily make the site faster for all users by hosting the whole site with Cloudflare I’d lose control of the end-to-end technical setup and that’s been a fun experience so far, so part of me would like to keep it in my control.
Responsive images allow a browser to download an image that is appropriate for the device in use. This means that a browser on a phone can download a small image, a browser on a wide screen can download a larger image and a device with a retina screen can download a more detailed image.
When I started looking at responsive images, I immediately started looking at the picture tag, which was the thing that people were excitedly talking about. The picture tag is very powerful (examples), but after a while I realised that if I don’t care about orientation (a.k.a. art direction) or alternative media formats, the srcset attribute of the img tag is just as effective, and is far simpler. Incidentally, srcset support is a little better than picture support). When I started implementing, I followed Opera’s nice explanation on srcset-style responsive images but if the picture tag is your thing they have one for picture-style responsive images too.
I ended up using the srcset width (w) descriptor and making 4 image sizes available to make sure that there was an appropriate range of images to cover phones up to desktop retina screens. While Safari and mobile safari don’t support the width descriptor (they only support the resolution switching (x) descriptor), the fallback is no worse than what I had before and it produces really nice output on Chrome and Firefox, which is good enough for me (it’s what I use).
While HTTP2 reduces the need to minimise HTTP requests, I won’t start serving HTTP2 until nginx supports it later this year, so I’m still choosing to approach optimisation with an HTTP 1.1 mindset, which includes minimising requests. One of my requests is a web font that is visible on small screens where I replace navbar text with icons. This optimisation involved moving the icons from a font file into (inline) SVG. This change retained the resolution independence that comes from using fonts, as SVGs are vector-based, while reducing page weight and eliminating an HTTP request. I had already created a customised, low-weight web font using Fontello and this was a reasonably smooth transition given they also provide an SVG version of the glyphs. The only gotchas involved setting the dimensions of the glyph and applying a transform to display the glyphs the right way up (see step 3 & step 5 of this article). This was a chance to learn a little about SVG to be honest and while the outcomes are nice, they’re not particularly compelling.
I was a px holdout. I didn’t see the value in using em over px, so I’d been defining everything (borders, margins, text size, media breakpoints) in pixels (px) rather than in terms of the base font size (em). During the conference I finally understood that using em meant that elements would scale appropriately when someone set a custom font size (+ for accessibility) or when someone was using a retina screen… so I changed it all to em. Reading The Dao of Web Design also helped me let go of the idea of controlling every last pixel on the screen and allowing the reader to choose how my content was presented. Oh, how freeing. This new mindset led to a rethink and removal of most of the micro-positioning and micro-formatting directives that were cluttering my CSS. One can now change the base font size in a browser, or zoom, and the text and all the elements scale nicely and in an unsurprising way… and the CSS is cleaner.
Along the way I spent a little time trying to work out whether I should specify media breakpoints in px or em. I got stuck thinking about particular devices and the number of pixels on their screens, but one doesn’t want to set breakpoints for particular devices, or even classes of devices as there are simply too many. The recommendations that sat best with me were ones that set media breakpoints based on content rather than device widths. In practice that meant I brought up my normal layout, measured the width of the normal layout text header (in em) added a bit for fat, and then made that the max-width of my mobile layout icon header. Here are two good articles that helped me with the process: Where And How To Set Breakpoints in Media Queries and 7 Habits of Highly Effective Media Queries
So those are the recent changes - three cheers for Velocity conference. What a great learning environment.
Recently, I’ve had a bit of fun combining coffee, programming and geography to plot the locations of single-origin beans that I’ve tasted in the last year or so.
Here’s the result: Single-origin coffee sources. Note the clustering around the few areas that are suited for coffee growth, with Australia as the outlier!
