Rick Hurst Web Developer in Bristol, UK

Menu

Tag: featured

I joined the WordPress VIP team at Automattic!

Posted on by Rick Hurst

After working mainly freelance for the past decade or so, I started 2020 with career development on my mind. Freelancing had been going pretty smoothly, but it didn’t feel like it was going anywhere, that I was specialising in being a “jack of all trades” and I couldn’t help but think there was more opportunity out there to develop and find a niche, working within a large organisation, where I could concentrate on developing my software engineering skills rather than running a business. Automattic had been on my radar for years, as an established champion of fully-distributed working and open-source software, but it was relatively recently that I had became aware of WordPress VIP, the enterprise-scale platform run by Automattic. In May 2020 I started full-time as a Developer at WordPress VIP!

As part of the Customer Success (EMEA) team, I divide my time between Code Reviews of customer code, where aim to help customers make their custom WordPress code efficient and secure, proactively and reactively helping customers with optimising code to remove bottlenecks in database queries and caching, investigating solving tricky long-term bugs and performance issues on customer’s sites, and getting involved in a whole load of different internal projects and initiatives. The Automattic creed encourages, amongst other things, continued learning and development, and there’s huge potential for branching out here.

Enterprise-scale WordPress? 

I’ll address this first – I know there will be skeptics out there (including amongst my own friends and ex-colleagues!), but with the right set-up, considerations and infrastructure, there is absolutely no reason why WordPress can’t be run at scale, and if anyone are experts in this, it’s the company that runs wordpress.com. The WordPress codebase is incredibly mature, backward compatible and extremely well tested, powering a significant percentage of all websites (I’ll refrain from quoting this percentage, as the number is both disputed and constantly growing!). WordPress VIP take that a step further by running a (private) cloud-based auto-scaling infrastructure and application support tailored specifically to the needs of high-traffic, enterprise-scale WordPress sites.

During the US elections in November 2020 I got to witness first-hand, amazing amounts of traffic on some of the sites running on VIP Go. Watching the Grafana charts for the back-end of some of these sites was almost exciting as the charts being shown on the sites themselves! Here’s a write-up about FiveThirtyEight – a WordPress site and liveblog hosted on WordPress VIP which was reliably serving WordPress at the rate of 132,000 requests per second during election night.

Whilst historically I haven’t always been a cheerleader for WordPress, it became my go-to CMS (yes, CMS, not just blogging software – that’s probably another blog post in itself!) over the last decade, despite dabbling with other open-source CMS and building a few of my own in the past. There’s a fair amount of anti-PHP sentiment amongst some of my peers, usually based on their perceptions of PHP in the early years, before it became the fully-fledged programming language it is today. I don’t share this skepticism, so have now gone all-in, on both PHP and WordPress! Even on dedicated infrastructure, running WordPress at scale (in terms of both traffic and amount of content), requires every aspect of the applications code to be considered, tuned and tweaked for performance and security. This is the stuff that I like doing, and i’m now honoured to be doing it amongst a team of vast experience in this field.

The hiring process at Automattic

It all starts by sending in the initial application (mine was by email, but currently it’s via greenhouse). In some way this is the first technical task – I did as much reading as possible about the organisation and advertised position before sending in my initial application to make sure it covered everything relevant I wanted to say about myself and my skills/ experience. Having made it past this stage, next-up was a technical challenge, in my case re-factoring a plugin to improve it’s performance and security, done in my own time. This was followed by a text-based interview in Slack, where we got into some in-depth technical and previous experience chat. I was then invited to start a trial, which is paid, and flexible regarding timescales, to allow me to fit in around on-going work. The trial lasted several weeks in my case, and consisted of more challenges simulating real-world scenarios – code reviews, debugging, advising customers etc. before I was invited for a chat (again via slack) with the WordPress VIP CEO. Finally I received my job offer letter and arranged a date in May to start on-boarding.

Fully distributed working

For context – I applied for this before the Covid-19 lockdown occurred in the UK, and at time of writing we are still in lockdown. Many people are now working remotely by necessity and hopefully a large proportion of those people will have the option to continue working remotely when lockdown is over. However, Automattic has always been a distributed company, and this was a major selling point for me. Remote-working is not for everyone, but it has always been a goal for me, which i’ve achieved up until now while working freelance. This will mostly happen from my shed-office, but in theory this could be from virtually any location in the world where I can get an internet connection, which a fantastic freedom. However, there are timezone considerations to stay in sync with my team and commitments and local employments laws/visas need to be considered for some locations.

WordPress VIP and Automattic are hiring! –  have a look at some of the currently open positions at both WordPress VIP and Automattic.

Raspberry Pi WIFI bridged access point

Posted on by Rick Hurst

I usually rely on a wired ethernet connection in my home office, enabled by a powerline adapter running through the mains wiring to the house, where the other end connects to one of the ethernet sockets on an Airport. Yesterday I took delivery of a shiny new Macbook Pro and was reminded that they now only have Thunderbolt 3 sockets, making my Thunderbolt to ethernet adapter redundant. Thanks a lot Apple, that’s another expensive white adapter to add to my box of random useless adapters, and another one or two to buy (I still need a USB port for a couple of things, and displayport/ HDMI for an external monitor or two).

Luckily I had a spare Raspberry Pi 3 B+ lying around, and after a couple of false starts, I now have a bridged wireless access point in the home office, bridging the wired ethernet connection from the powerline adapter. Bridged works best for me so that I still get an IP address assigned via DHCP from the Airport, in the same IP range – it just keeps things simple. I’ve given the PI access point a unique SSID rather than mirror the one used in the house because sometimes it’s useful to know which one you’re connected to.

Installing and configuring the software

This is the how-to I followed: Setting up a Raspberry Pi as a bridged wireless access point. I’m not going to repeat all the steps here, but for what it’s worth, one of my false starts was the result of this part:-

To use the 5 GHz band, you can change the operations mode from hw_mode=g to hw_mode=a.

Apparently this works for Raspberry Pi Model 3B+ onwards, but it just didn’t work for me – the access point didn’t show up. After changing it back to the default “g” it works fine. The powerline adapters (and the mains wiring they use) already limit the speed of the connection a fair amount, so i’m not too bothered about this.

The other false start was following a completely different how-to, which only resulted in locking myself out of the pi via ssh and creating an access point which didn’t provide internet access!

My current tools and tech in 2019

Posted on by Rick Hurst

I try to avoid jumping on every new trend which comes along in the web world, especially over the last few years, where things seem to have moved very fast, with javascript frameworks becoming obsolete before i’ve even got round to trying them, but I also need to keep my skills and tech relevant. Here’s what i’m using as of late summer 2019.

Editor/IDE

I’ve been consistently using Sublime Text (Version 2 because I never got round to upgrading to 3) for years as my code editor, though i’ve never really taken full advantage of the extensions and customisations available. It just works and I saw no real need to change. One thing it has never done well is working over ssh, or rather from a mounted sshfs folder on a mac. I have occasional need to do this, when using the likes of nano in a terminal doesn’t feel good enough, and it’s one thing that I missed from Coda, when I used that for a while, years ago.

Then after spotting a tweet from an old colleague mentioning remote SSH editing in VS Code (via the Remote – SSH extension), I thought i’d take a look at it. Firstly, having used old-skool Microsoft Visual Studio in the past, I was surprised to see that Microsoft had built and released such a cool free editor, with builds for windows, mac and even linux. It’s already become my default editor – the intellisense and built-in terminal and git functionality is really good. There’s a lot there to explore and a ton of extensions. It also looks good.

Languages and frameworks

Most of my work is currently PHP. I no longer feel the need to apologise for that! PHP 7 is mature, stable and fast. I work on a couple of legacy PHP projects, one of which uses a combination of bespoke MVC code, an old fork of codeigniter (currently being refactored out) and Redbean ORM, and the other uses Zend framework, but is being re-built as a de-coupled app with Lumen (micro-framework by Laravel) on the back end and Vue.js on the front-end.

I haven’t done any web projects with Python recently (though i’m keen to try Pyramid), but I have been using it for a custom FTP server, using pyftpdlib (yes, FTP – for an old-skool EDI project – an old, but still very widely used technology where XML and FTP are used to exchange data – probably predating the invention of JSON and REST). I’ve also been using python for a raspberry pi datalogger project, reading serial data from microcontrollers via USB and then relaying it to a REST API.

JavaScript-wise, I still use bits and pieces of  jQuery to get stuff done while I learn Vue.js properly, which is happening as part of a current aforementioned web app rebuild. We settled on Vue.js instead of React because Vue seems to be a popular component in the Lumen/Laravel ecosystem.

For CSS, i’ve settled for now on SASS and Gulp. Sass is a keeper, i’m just using Gulp until I find something that I like better. I tend to use Susy for grid/layout.

Ansible is my go-to tool for devops – I use it to provision web servers and for formerly manual tasks such as migrations of websites, moving content between dev, live and staging on wordpress sites etc. For local development of any sort I almost always use Vagrant now, with an ansible provisioning script, which gives me a very portable set-up, provided I have enough RAM to keep multiple virtual machines running as I juggle projects.

During my last foray back into a day-job (back in 2016), working at an agency, I got a fair amount of experience using wordpress as a CMS, including for some fairly complex projects, relying heavily on the Advanced Custom Fields (ACF) plugin. Now, historically I haven’t always been a fan of WordPress, but it proved to be an excellent tool when used with ACF, making the creation of custom page types incredibly quick and easy compared to other Content Management Systems i’ve used, and even compared to using frameworks which would be my usual preference for custom content. Being able to create custom fields, included nested repeater fields via the WordPress admin, having the field definition saved to the filesystem and then versioned in GIT for seamless syncing to production is a game changer!

 

What is a Full Stack web developer?

Posted on by Rick Hurst

TL;DR It’s just a convenient term to describe a web developer who does both front and back-end, and maybe some other things .

I label myself as a Freelance Full-stack Web Developer (or Fullstack, for those who like to join two words together into non-existent ones) , but what does that actually mean?

Web developers who write HTML, CSS and (maybe) JavaScript, but don’t do any server-side code (e.g. PHP, Python, Rails etc.) might call themselves “Front-end” developers. Web developers who only do server-side code, and never do any HTML, CSS or (browser-based) JavaScript might refer to themselves as “Back-end” developers.

Therefore someone (like me) who does both Front-end and Back-end code might refer to themselves as a Full-Stack developer.

But there’s usually more to getting a website or web app built and up on the internet than just writing code.

There’s (sometimes) provisioning servers, installing web server software, installing database software and other dependencies. There’s setting up development, staging and live versions of websites, setting up domain records for websites and mail servers and installing SSL certificates. That might be the job of a sysadmin and/or DevOps specialist, but some web developers might take on that part of the job, either by choice or by necessity.

Most web apps need a database, and this database might need designing, optimising and maintaining. That’s a job for a DBA if you are lucky to have one, but i’ve only worked for one company who had a dedicated DBA, so that job usually also falls to a developer.

There’s often plenty more roles that make up the stack – testers, technical project managers, UX, Designers, and in some companies there will be dedicated individuals or teams for all of these roles, but for a small agency or freelancer, often these are taken on by a full-stack web developer.

Now just like Front-end and Back-end are made-up terms, so is Full-Stack. For me it’s just a convenient way of saying that i’m not just a front-end developer, or not just a back-end developer, I do both, and some other things.

Jack of all trades, master of none?

Hey! I resemble that remark! Actually I prefer to say “Jack of all trades, master of some“. I’d like to get better at all of the various roles that make up my workload, but people dedicated to a particular role exclusively will inevitably master skills in that area that I probably won’t.

But there’s more parts to the stack, can you do all those too?

A heated discussion on a local web dev forum had people extrapolating “the stack” to include hardware and low-level operating system code (and maybe beyond?) at one end. I neither do that stuff, or consider it as part of the web-development stack.

At the other end people were adding in any role that could possibly related to the development of a website or web app – account handlers, financial directors, accountants, HR, office manager. Although as a freelancer I have to take on some of those roles myself, I don’t consider them to be part of the web-development stack!

Deploying and maintaining a website using git

Posted on by Rick Hurst

I’ve kind of used git to deploy/ manage php/ static websites for a while now, but in a very luddite way – basically sshing into the webserver, cloning a repo into my site root directory, then hiding the .git folder in the Apache config.

After recently starting a new job and inheriting some web sites and web apps and starting to take the whole “devops” thing more seriously, I was pleased to see a better technique in place than the one i’ve been using.

The basic premise is this – a repo is set up on the web server as a remote outside of the web root, but configured so that the checkout working directory is another directory. The advantage of this is that there is no need to ssh into the webserver to update the code, as a post-update hook can be used to checkout the updated files.

In addition to this, we usually use tools such as gulp to process scss and minify and js, so the post-update hook can also be used to process these on the server after checkout.

Going into more detail, here is the config of the remote git repo on the webserver, this could be somewhere like /var/sites/mysite_git

[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
worktree = /var/sites/mysite
[receive]
denycurrentbranch = ignore

and in hooks/post-update on the remote, something like:-

git checkout -f
cd /var/sites/mysite
gulp build