Addy Osmani’s talk about performance at the last FFConf had a small segment on serving brotli compressed assets, as opposed to gzip. The claims are that brotli produces smaller filesizes than gzip, so if you want to squeeze some extra performance out of your site, then just switch over and reap those rewards! The talk, however, was light on the implementation details. Well, I decided to take a look to see how easy the switch would be.
I’m not going to extol the virtues of encrypting your site and enabling HTTP/2. The advantages should be pretty obvious by now. The real issue is that when you’ve got your site(s) and your clients’ site(s) encrypted, you’re left with local development versions of the sites which are now at odds with the live version. And it’s always best to mirror your dev and live environments as much as possible to avoid those last-minute deployment panics. Like when I deployed the all-new Clearleft site only to find I hadn’t updated the image links to HTTPS so none of them loaded. Queue a frantic 10 minutes of find and replace throughout the site templates while people were telling me the site was b0rked. Fun times.
A year or so ago, I came across this post by Keith Cirkel, How to Use npm as a Build Tool and it stuck with me. At the time I was transitioning to gulp from grunt both personally and for Clearleft projects. We had a discussion about the feasability of going full NPM and decided that using gulp was still the best for us. There are plenty of great reasons to use grunt or gulp and we will continue to do so at Clearleft, but for my personal site I decided to experiment with pure NPM. And in so doing, show how easy it can be, particularly for small sites, to set up some simple tasks.
Some time around the last Steam sale I knew I couldn’t keep buying games I never intend to play. Or, at least, do not have time for. If I cared about the game, I would have bought it sooner, really. Instead, all I could feel was the burden of games unfinished. The list of which was ever growing. So I decided to make a literal list of those unfinished games and try to beat them before moving on. Or at least make a good dent. And here is that list. My games of shame:
Some of you may know that several weeks ago I got engaged to my amazing girlfriend. However, I am not the type of person who does things… traditionally. Proposals are infrequent but special events, not unlike weddings themselves, and I wanted to treat it as such. But not boring special. Anyone can go to a fancy restaurant and have their beloved find a ring in the bottom of a glass of champagne. That’s not me. That’s not us.
Here at the Clearleft towers we use DigitalOcean and our servers run Ubuntu 14.04 and Nginx 1.8.0.
At the moment, Letsencrypt has an auto installer for Apache only. I actually have no idea what that does, as the other option is to create the certificate files and link to them in your site’s conf file manually, which is all I’ve ever done anyway. I don’t think I’d want anything doing that step for me. But, I digress.
Well, the time finally came. I had been using Remy Sharp’s handy little twitter.js script to show one tweet on the homepage of my latest live site, Pulse, and Twitter’s API changes finally caught up with it.
Now, I’m not the sharpest cookie in the drawer (see?) so wrapping my head round Twitter’s OAuth system in a short time is actually beyond me. Embedding a tweet with all of Twitter’s forced styling is out of the question, really. My client simply wants to show one tweet, on the homepage, with basic formatting. Is that so much to ask? Apparently it is. The only option I could think of was to then ‘scrape’ the feed straight from their Twitter page, in effect, downloading the HTML and pulling out individual tweets. I could have done this straight in the site’s PHP code with curl. I’ve done similar things in the past. However, once you get the HTML, you either have to parse the code with PHP’s DOM functions or enter the land of regex nightmares.
I’d planned on setting up a Fileserver/NAS for quite a while now. Who hasn’t? I even bought all the hardware over a year ago. But, for whatever reason, I’d felt that it would take forever to sort out and put it off time and time again. I also wanted whatever solution I came up with to be perfect. While that’s pretty tricky when dealing with the rapidly evolving tech industry, you actually don’t want to be messing around with a system holding 5TB of data. So my quest for perfectionism wasn’t entirely misguided. Just mostly.
Welcome to Occasional Git! For when you’re working on your own, on small-ish sites. These are the things I encounter sometimes only once a month, if that. I’ll be supplementing the commands with examples I’ve used personally.
git rm --cachedI’m horrendous at knowing what files to ignore until much later. So this little command is definitely the highest on the list of “how do I do that again?”.
Following on from the last post which laid the landscape covering the whys, we now get on to the hows.
I’ve been with MediaTemple for many years, first with their (dv) servers for client work, then their (gs) servers for my personal sites. I’ve never had a problem with them in all that time. Their customer service is impeccable, their knowledgebase is a treasure trove of information, and the user forums have pointed me in the right direction more times than I care to count. So, even though the price was a little higher than probably warranted, I opted for their (ve) server. What you get is 1+ GB of RAM, 20+ GB of HDD space, and, well, that’s about it. I don’t even know how much processing power I’ve got. You choose from 4 different Linux variations, Ubuntu, Fedora, CentOS and Debian, if I recall correctly. Then you get SSH access, and away you go! Anything you want on there, that’s up to you.