The philosophy

The first choice you need to make is if you want to self host or not. Back in the early web days it was easier to trust platforms. Early Google provided advert free search and free to use email. Early Twitter made easy to connect with friends and communities, following a simple timeline of updates. These companies were focused on making a good product with real value.

As time went by the pressure for these businesses to turn a profit and please investors/shareholders led to a break of that trust. Advertising became more invasive, algorithms were created to manipulate your attention, conversation became divisive and a lack of sensible policy allowed hate speech and disinformation to spread. On Twitter you have probably witnessed your friends and family get quieter and quieter as they felt less comfortable in their surroundings. I certainly have.

As Elon is demonstrating; sensible, fair and considered policy is hard. With each and every poor decision he is making, the Fediverse (and Mastodon in particular) is seeing huge growth. The easiest way to get started is to jump on an existing server (owned by someone else), but to do so without considering the consequences of that choice is a mistake.

Once again you have to place your trust in a third party. Most server admins look fairly sane but as a history has shown us... things change. They may struggle with costs, moderation or pigeon hole you into discussing just a certain topic. This upheaval from Twitter is an opportunity to own your thoughts, on your own domain and on your own terms. A little extra effort now is worth the investment.

The strength of the Fediverse is decentralisation. No single server is any more important than another. If you come across a particularly nasty server, you (or your server admin) can stop your instance federating with it. Decentralisation makes the platform both easier to moderate and less prone to censorship. By running your own instance you gain that control, but when you are a guest on someone else's instance, it is their choice. What happens when two large instances decide to block each other?

By running your own server you will avoid these concerns and help strengthen the network for everyone.

The software

When I first looked at setting up a Fediverse server I naturally gravitated towards Mastodon. It is by far the most popular and polished software, but it also has fairly demanding requirements. I wanted to start small with something I could easily host on a Rasbperry Pi (or low powered PC) from my home network.

Since setting up my solar hosting project I have grown very fond of the freedom that self hosting provides. It's nice to know where my electricity comes from and who has access to my servers and data (that will be me!).

I discovered a young project called GoToSocial (GtS) that is written in Go and currently in alpha. It fits the requirement for something light and efficient:

A single-user instance with about 100 followers/followees uses somewhere between 50 to 100MB of RAM. CPU usage is only intensive when handling media or processing lots of federation requests.

GtS provide a multi-architecture Docker container which is my preferred way to setup my self-hosted services.

To expose GtS to the web I am using Cloudflare tunnels. This means I do not need to open ports on my router and I get a little extra security from the Cloudflare network. Exposing alpha software to the web from my home network probably isn't that smart, so I appreciate Cloudflare's additional layer of protection. I also created a private Docker network for GtS so the container doesn't have access to my local network either. Running it this way (via Docker) keeps the code and network securely isolated.

You can use the docker-compose.yaml below to mirror my setup. You'll need to make sure your domain is running via Cloudflare and ensure that you have setup your tunnel in Cloudflare's Zero Trust control panel. Then add your Cloudflare token (export CF_FEDIVERSE_TOKEN=SECRET) to your .bashrc so its available when running docker-compose up.

version: "3.3"

services:
  gotosocial:
    image: superseriousbusiness/gotosocial:0.5.2
    container_name: gotosocial
    hostname: gotosocial
    env_file: ./.settings.env
    restart: always
    volumes:
      - ./data/db:/gotosocial/storage
    networks:
      fediverse:
        ipv4_address: 172.5.1.2

  cloudflared:
    image: cloudflare/cloudflared:latest
    container_name: cloudflared
    hostname: cloudflared
    command: tunnel --no-autoupdate run --token ${CF_FEDIVERSE_TOKEN}
    restart: always
    depends_on:
      - gotosocial
    networks:
      fediverse:
        ipv4_address: 172.5.1.3

  networks:
    fediverse:
      driver: bridge
      ipam:
        driver: default
        config:
          - subnet: 172.5.1.0/16
            gateway: 172.5.1.1

You will also need a .settings.env file in the same directory as the docker-compose.yaml above. This file contains your desired settings for GtS. I set the following options:

GTS_HOST=toot.scott.ee
GTS_PORT=8080
GTS_APPLICATION_NAME=Scott
GTS_ACCOUNTS_ALLOW_CUSTOM_CSS=true

GTS_ACCOUNTS_REGISTRATION_OPEN=false
GTS_ACCOUNTS_REASON_REQUIRED=false
GTS_MEDIA_IMAGE_MAX_SIZE=10485760
GTS_STATUSES_MAX_CHARS=1000

GTS_DB_TYPE=sqlite
GTS_DB_ADDRESS=/gotosocial/storage/sqlite.db
GTS_LETSENCRYPT_ENABLED=false

This ensures the service is running from the correct domain and port. I also disable registration (this instance is just for me) and customise the post length and image size variables. I disable Let's Encrypt as the Cloudflare tunnel is encrypted and they handle SSL for you. A full list of available options can be found in the documentation for GoToSocial.

Creating your first user with a Docker hosted instance of GtS is a bit of a pain. Luckily it is well documented with command line instructions you can copy and paste into your terminal. Once your user is created, make a note of the login credentials in your password manager.

Unlike Mastodon, GtS doesn't provide a front end/client experience. It is just a Fediverse compatible server (at least for now). That means you need to bring your own client. For the web they recommend Pinafore, and for mobile Tusky. Both are open source and a pleasure to use. There are many more clients though and pretty much any of the Mastodon compatible clients will work with GtS too. You can also use tools like Crossposter to relay your tweets and toots in either direction. When setting up your client, you need to enter the URL of your server (toot.scott.ee in my case) and sign in using your username and password.

For administering your GtS server there is an admin settings section available at example.com/admin and user settings can be found at example.com/user — this includes custom CSS if you want to give your profile a lick of paint.

Wrapping up

I appreciate this guide is a little light in places so if you have any questions let me know (links in the footer). I also appreciate that self hosting isn't for everyone... however I do think it gets us closer to the type of Web that we want (and once had). What would the web look like if every home had a server and a decent internet connection?

The Fediverse is just one option for decentralised socialising. There are some very interesting projects that you may also find easier to get started with: Secure Scuttlebutt - via Manyverse / Planetary, Matrix via Element, nostr (which I haven't got my head around yet) and good old RSS with blogs and commenting and all that great stuff.

I often wonder how much that one decision impacted digital life. It took a huge number of eyeballs away from blogs and pushed people towards social media. Now we all spend far too much time exposed to the algorithmic nightmare fuel that continues to mess with our minds and society.

RSS didn't die, it just went underground, and we can get it back to the good old days with a few open source tools. I have been tinkering with this setup on and off for a few years and it has been working really well. For a small time investment you get the benefit of fresh, interesting content that you choose to follow. No timelines, no ads, no tracking.

Miniflux

At the centre of it all sits Miniflux. Miniflux describes itself as a minimalist and opinionated feed reader, but I think it is much more than that. It acts as an RSS server. It is also easy to install on low cost hardware like the Raspberry Pi. In fact, with Docker, it can be installed anywhere with a minimum amount of effort.

I host Miniflux locally on my network alongside 14 other Docker containers. You can see my docker-compose.yaml in my home automation repo. Hosting it locally has one draw back — you need to be at home to access your feeds. My solution is to use a VPN to connect home to my local network if I want to check for updates on the road. You might fight it easier to host Miniflux on a cheap VPS instead or you can support development of the project and use the hosted version for $15 a year.

Clients

If you have had a look the Miniflux website, you may have seen the UI and closed the tab. It's not the nicest looking or most intuitive piece of software. Don't feel disheartened though. There are many clients that talk and sync to your central Miniflux server. Here are some of my favourites:

• ConstaFlux — A tidy little reader for Android that uses material design
• Reeder — For Mac/iOS. It's clean, well featured and supports custom gestures
• NewsFlash — For Linux. Built in Rust and works wonderfully with Gnome

Follow everything

You can use RSS to keep up with all sorts of content, not just written text. I am testing moving my YouTube subscriptions to RSS to avoid Google's junk algorithms. For Twitter there is Nitter and Miniflux can support podcasts out of the box. I also recently found a great tool you can self host called RSS Bridge. With RSS bridge I can get content from many sites including: Telegram, Reddit, Mastodon, GoToSocial and Wikipedia.

With all that in place, all that is left to do is make a nice drink, find somewhere comfortable and rediscover some interesting, investigative, forward thinking and quirky content to follow (oh, and me 😉).

This project is something I started tinkering on just over two years ago. It's not perfect, but I feel I have gotten it to a point where it is resilient enough to share.

It is easy to underestimate how much power is needed to sustain modern life and this experiment has given me a whole new appreciation for how power hungry even our smallest devices can be. I'll be updating this project over time as I find ways to further improve on the system and I would love to hear from you if you have suggestions or ideas on what can be improved. I'm not an electrical engineer and have lots to learn.

The philosophy

When we moved to Sweden two years ago, I quickly realised that full time solar hosting wouldn't be possible. During our first winter here, we didn't see the sun for over five weeks (it even made the news). In contrast, during summer we can get a good twenty hours of daylight. Although it's not always sunny and certainly not always strong enough to charge something.

This means I needed to design my system for resilience and have a plan for my solar host going offline. I needed some kind of monitoring and potentially a backup host. Worst case, I wanted to show a simple page explaining why my site is offline from time to time.

Another challenge is that we currently live in an apartment without a balcony. When you look at other well known solar hosting projects they tend to be built around 12V systems, using large lead-acid batteries and huge solar panels. We don't have that sort of room and I would rather avoid lead-acid — it's not very sustainable and can be fairly dangerous.

Most single board computers generally require 5V, so a 12V system is perhaps overkill. You also lose energy in the conversion from 12V to 5V. With that in mind I decided to build my system around smaller components at 3.2V.

The hardware

You will need:

• A Raspberry Pi Zero W/H
• LiFePO4wered/Pi+ solar charger / HAT
• 20 Ah LiFePO4 Battery (1 cell)
• 9W 6V Solar panel (probably needs to be bigger)
• Raspikey eMMC module
• Some wire and a connector for the solar panel
• 31k resistor (value will depend on your solar panel)

I also used a few washers and battery connectors when connecting everything together. For the most part everything is plug and play, but you will need to snap off the battery holder on the solar charger HAT and solder some additional wires; two that run to the battery and two that run to the solar panel connector. The solar charger also requires a resistor matched to your panel. This is covered in the documentation and is something I have tweaked a few times (more on that later).

If I was to start from scratch today, I would consider a bigger battery and a bigger 20 Watt panel. Without the solar panel attached, the 20Ah battery I chose lasts for about 6.5 days, so 100Ah would give about one month of run time. The panel is OK, but once the battery is out, it can take a good week of sunlight for the system to boot again, so a bigger panel is probably going to be my next purchase.

The Raspberry Pi Zero W/H

I tested a few small computers to see which were most power efficient. Using a cheap USB power tester I got the following results:

• VoCore 2: 120mA — 200mA
• TP-Link MR3020: 125mA
• Omega2: 210mA
• Pi Zero W: 80mA — 120mA depending on optimisations

I also checked online to see what other tinkerers had seen in terms of power consumption. The original Pi Zero seemed to do well in most tests. It's also well supported in terms of software and you can optimise its power consumption by turning off features like Bluetooth, the HDMI circuitry and LEDs.

Ideally I would have plugged a USB Ethernet adapter into the Pi Zero for a faster and more stable network connection, but the general consensus is that WiFi requires less power as it only draws power when in use. The other benefit of WiFi is that I can move the Pi around as the sun moves throughout the year.

The LiFePO4wered/Pi+ solar charger / HAT

This little HAT is what makes this project possible. They are made by a small team but are well designed and well supported. The LiFePO4wered/Pi+ has many smart features that make using the Pi off-grid possible. There are wake up timers, a real time clock that manages system time and an application watchdog that can monitor and reboot the system when your software crashes. While the Pi is off, the LiFePO4wered/Pi+ keeps track of time and monitors system voltages while consuming around 4 µA — so the Pi can sit in standby for many years.

The HAT comes with a CLI tool that allows you to get the current health of the panel and battery. This allowed me to create a small python utility that writes a few stats to a JSON file which then gets consumed by this site. If you can see the battery to the left of this article, your visit was served by the solar Pi.

As mentioned earlier, you will need to solder a resistor to the HAT to optimise how your battery charges. From the documentation:

The MPP resistor value can be calculated with the following formula:
RMPP = 51815 / (VMPP – 4.66)

I contacted the solar panel manufacturer and they said the Vmmp for my panel is 7.38V. Therefore I needed a 19 kohm resistor. Unfortunately this didn't really work out for me. It meant that I needed 7.38V from the panel and it just wasn't happening that often. It also breaks USB charging (you only get 5V from the Pi charger) which is less than ideal. At the moment I am testing a 31 kohm resistor which sets the charge voltage to 6.33v… so far this is working quite well and the solar panel is doing a much better job at charging the battery and running the Pi at the same time. I'm sure this is an area of improvement though.

The battery

As the name of the HAT suggests, it supports lithium iron phosphate batteries (LiFePO4). These batteries score well in terms of toxicity, safety and life cycle. This video does a pretty good job at selling the safety side of LFP:

I am particularly impressed by how much better for the environment LiFePO4 batteries are, with lifespans ten times longer than lead-acid batteries and a non-toxic chemistry.

Raspikey eMMC module

SD cards are not overly reliable (although they are getting better). I decided it would be better to use an eMMC module for longevity. The 16GB should be enough room for everything, but it really depends on how big the site you want to host is. I am secretly hoping that this hardware combination will last for a long time, if it does I have a similar project in mind for an off-grid time capsule.

The software

I've put a copy of the custom code you need for this project on GitHub, if you would rather start there.

Once you have the hardware in place, it's time to move on to the software setup. Start with a copy of Raspberry Pi OS Lite - you want as little software as possible. You can use the Raspberry Pi imager to setup WiFi, SSH, a fixed local IP address (for convenience) and a few other bits before putting the eMMC module in the Pi and booting. I also have a guide on my site for setting up the perfect Raspberry Pi. I followed most of the steps detailed there including the power saving tips like turning off HDMI and the LEDs, as well as setting up Docker.

You'll also want to install the software for the solar charger HAT which gives you CLI access to control settings and query the state of the HAT. I tweaked the following settings:

• AUTO_BOOT to 2. lifepo4wered-cli set AUTO_BOOT 2. This ensures the Pi will boot back up when there is enough battery power to do so.
• VBAT_BOOT to 3325. lifepo4wered-cli set VBAT_BOOT 3325. This is about 75% of the battery, so the Pi will boot once the battery hits this level.
• LED_STATE to 0x00. lifepo4wered-cli set LED_STATE 0x00. To turn off the main power LED and save more energy.

These settings can be saved to flash using the command lifepo4wered-cli set CFG_WRITE 0x46. I highly recommend scanning the documentation to see how customisable this board is. At some point I may setup the watchdog feature to reboot the Pi in case of a software crash.

After that I created a custom python script that runs every 10 minutes. It gets started automatically at boot time (see method 4: systemd and this service file) and checks the current battery voltage. It then attempts to turn that into a battery percentage. It's not perfect as batteries tend to discharge in a non-linear fashion, but it does the job for now. There is also some code that translates that percentage into an LED output for a PIMORONI LED Shim. This is commented out for now in order to maximise run time. The python script populates a file called solar.json which sits in the web directory and contains the battery percentage, battery voltage, load, uptime and CPU temperature. This creates a crude API.

Installing Docker takes a bit of time on the Pi Zero but it's worth it. You can explore containerised software without messing up your OS. I use three containers to host my site, a lightweight static web server, cloudflared and watchtower. Here is my docker-compose.yaml.

version: "3.3"

services:
  web:
    image: joseluisq/static-web-server:latest
    container_name: web
    env_file: ./.settings.env
    ports:
      - 8080:80
    volumes:
      - ./web:/public:ro
    restart: unless-stopped
    command: -g info

  watchtower:
    image: containrrr/watchtower:latest
    container_name: watchtower
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    restart: unless-stopped

  cloudflared:
    image: cloudflare/cloudflared:latest
    container_name: cloudflared
    restart: unless-stopped
    network_mode: host
    command: tunnel --no-autoupdate run --token ${CF_WEB_TOKEN}
    depends_on:
      - web

An example .settings.env file can be found on GitHub along with everything else you should need.

Cloudflared and self hosting

Self hosting has always been something I have shied away from. I just don't like the idea of opening up ports on my home router and letting outside traffic stream in. Cloudflare have a solution to this called Cloudflare Tunnels. It's a free service that creates a secure tunnel between your home network and Cloudflare's sustainable infrastructure. You can then expose certain services on your network to your Cloudflare domains. I'm really impressed with this service and the ease at which it can be setup. You can setup most of it via an online control panel, then just install the Cloudflared software on the host or in a container. In my docker-compose.yaml file you will need to replace ${CF_WEB_TOKEN} with your Cloudflare token from their web interface.

Using Cloudflare also brings other advantages like website caching, DDoS protection, a firewall and load balancing (which sounds useful). Cloudflare deserves a thank you or two for making all these fantastic things.

Static web server

Static Web Server (or SWS) is a very small and fast production-ready web server suitable to serve static web files. It is focused on lightness, ease of use, high performance and safety. It's perfectly suited to the memory and processor constrained Pi Zero.

This website is static (a bunch of HTML, CSS and JS files). It's built with Nuxt.js and Nuxt content, replacing the previous site that used a decoupled WordPress backend. I haven't published this site to a public GitHub repo yet, but I plan to in future and i'll update this project when I do.

I created a new Vue component that checks the values in solar.json and then shows the battery value with a background colour and icon. There is a good chance you are seeing it on the left hand side of this page right now.

The background colours change based on the battery percentage and I have output the other data in solar.json into the background too — I hope to make that a little more visually interesting in future.

This site has always responded to various environmental variables. The image quality is reduced if you visit from a weak 2G/3G connection. The images are compressed further if you turn on Save-Data. With battery data now easily accessible, I decided to make this another variable to respond to. It's most noticeable when the battery is < 35% — the images will become grayscale and heavily compressed.

Watchtower

Updating a containerised app is simple with Watchtower. Watchtower will pull down an updated image, gracefully shut down your existing container and restart it with the same options that were used when it was deployed initially. I have this running to ensure that my Docker containers stay up to date… mostly for security.

Security

Whilst Cloudflare does a good job at securing access to the Pi, I still took a few additional steps to improve security. This included:

• Setting up auto-updates
• Ensuring SSH login via key only
• Setting up a firewall to open up very specific ports on the Pi

This last thing I installed is log2ram to reduce writes to the disk. It's not really a security benefit but may help reduce power consumption and improve the longevity of the eMMC.

Designing for resilience

Like I mentioned at the start of this project, I needed to design this system with resilience in mind. That means finding a way to keep my site online when we may not see sun for several weeks.

We run Home Assistant on our home network (I need to write more about this, but for now you can browse this repo on GitHub). Home Assistant is fantastic piece of software and I use it to control and automate all sorts of things.

The first step is to monitor what the solar host is up to. I setup a Home Assistant sensor that checks the solar.json file and logs the battery state. Home Assistant gives us a nice UI for tracking the battery over time:

I also setup some simple push notifications from Home Assistant to my phone to tell me when the the solar goes offline (the sensor switches to Unavailable) and online again (the sensor switches from Unavailable to a value).

The next step was to work out what to do when the solar host goes offline and there are quite a few potential options to explore:

1. I could change my DNS as the Pi powers off, pointing my URL elsewhere (perhaps to a generic HTML page other solar hosts could use, explaining the site is offline, and when it might be back again).
2. I could set up a backup VPS or static host which serves a mirror of my site, perhaps on a different URL (but this seems wasteful).
3. I could explore Cloudflare's load balancing tools, splitting the traffic across the solar host and another self hosted computer (most likely another Pi).
4. I could just let my site go offline, after all it's a low traffic portfolio site.
5. I could power the site up and down on a schedule to make it more predictable and extend battery life.

A little magic

At the moment I am exploring solution 3 with a potential twist.

Cloudflare tunnels support load balancing, so setting up a secondary host running over the same tunnel and with a copy of my website allows Cloudflare to randomly send traffic to my solar Pi or to a secondary host. This is how it is setup today. Your visit will be randomly handled by one of two Pis: the solar Pi or a Pi Zero v2.

Our home electricity is on a renewables tariff and Sweden has one of the lowest carbon intensity grids in the world, so I don't feel too bad about having a secondary Pi sipping around 130mA and acting as a backup host, however I am considering using our Home Assistant instance to improve things further.

With some small tweaks to the Home Assistant push notification automations I mentioned above, I can startup and shutdown the secondary host on demand. When the solar host is online and the battery is at a certain percentage, the secondary host can take a rest. Once the battery gets low though, Home Assistant will see that and get the secondary Pi back online, ready to serve some traffic. To me, that feels a little like magic.

With over 2 million installations, WP Super Cache is one of the most popular open source caching plugins for WordPress. I like to think of it as one of the original static site generators.

This project was a short exploration to understand how WP Super Cache could be modernised and become part of the Jetpack suite of products, alongside Jetpack and Jetpack Boost. As an exploratory project, it was largely free from existing constraints and was used to kickstart further discussion about potential futures.

Challenges

Caching is complicated. Most popular WordPress caching plugins are jargon heavy with tonnes of inline documentation to try and ease the burden of configuration and management. WP Super Cache is no exception with pages of toggle switches, radio buttons and inputs used to tweak cache behaviour.

Whilst a technical interface makes sense for a certain subset of WP SuperCache users, our data suggested that the plugin is being used by a much broader range of people. It has the potential to be installed by any WordPress user looking to improve site performance.

Solutions

Optimising for first time use therefore felt like a good place to start. What can we do during the first use of the plugin to both explain the concepts of caching and the benefits of the plugin?

A soft landing

When launching the plugin for the first time, you will enter an onboarding flow which is used to explain caching, why it matters and also the premium features that are available. This would be shown on first launch and could be expanded to include more cards as the product matures.

Your first use would also be guided by a “getting started” tutorial, explaining key features of the interface, how they work and most importantly, why you might need to use them.

A new approach to settings

Making caching simpler

At its most basic, WP Super Cache is an on/off switch. The challenge becomes tailoring cache behaviour to your particular site requirements. The burden of configuration falls to the user in the existing UI. I believe the solution is to run a number of automated checks during cache activation, ensuring compatibility with other plugins and configuring sensible defaults.

The primary on/off tool becomes a big feature of the UI, and the status ring is used to indicate current plugin state and actions being taken.

Simply activating caching should be enough for most users to get started and see strong performance improvements.

Audiences

Imagine for a moment that you wanted to create a homepage banner that was tailored to the operating system of the device visiting your sites homepage. On Windows it might say “Install the Windows .exe file”, on Mac “Download the .dmg” and on Android “visit the Play store to install the app”. Caching could easily break this functionality, as we now need different caches based on user agent or operating system.

Changing cache behaviour based on the visitor type (logged in vs logged out), URL, file, device and browser are pretty much all possible in the exiting plugin. They are unfortunately quite primitive. You cannot mix these categories or define specific circumstances in which caching can be turned off, or a new cache is defined. The settings are also loosely grouped under various tabs and sections.

Audiences would allow you define these kinds of rules, targeting the specific visitors that require a separate cache. Most of the WP Super Cache interface could be simplified behind this concept, allowing for heavily reduced settings screens.

Demonstrating value

The existing WP Super Cache plugin is really just a huge collection of settings, once configured, there is very little need to revisit the plugin screens (set it and forget it). How do users know the plugin is working? How do we show value?

I believe the solution will be to introduce statistics for both effectiveness and site performance. This gives users a reason to check back from time to time and is aligned with the approach taken in current Jetpack plugin.

Woah this is really breaking new ground, and an excellent unbound exploration bringing fresh ideas. :)

Prototyping

To help communicate these ideas with the wider Jetpack team I created a Figma prototype with a number key interactions and screens available to test. The prototype can be found below if you wish to test it yourself.

Try the prototype

Grab Raspberry Pi OS Lite

Head over to raspberrypi.org and download the latest copy of the Raspberry Pi OS (Lite). Every single Pi I have ever setup has been a headless machine so you don’t need the bloat of the desktop environment. Etcher is a great tool for flashing the downloaded image to your SD card. Whilst you have the SD card in your computer, create a blank file called ssh in the boot directory to enable ssh and consider adding wireless network information if your Pi will be using WiFi.

Set a fixed IP

A fixed IP will make it easier to reliably ssh into the machine and browse to any services it may be running. I always set a static IP via my router. I find this a little quicker and simpler to do than on the Raspberry Pi itself and it makes the Pi more portable should I ever change my network, or take it elsewhere. Your router documentation should be able to guide you through the process.

Login and update

ssh pi@192.168.1.10

Once you have set your static IP you can login via terminal with the pi username and the default password of raspberry. You can then update the default software stack using:

sudo apt-get update
sudo apt-get upgrade

Raspi-config

This little utility will do a number of things. It will expand the file system, giving you access to the entire SD card, set a memorable hostname and lower the GPU memory to minimum (16mb). With the Pi running headless you shouldn’t really need any graphics memory and this gives you the maximum amount of RAM for your projects and code. Run the utility with raspi-config, key around to change the above settings. Once that is done you will need to reboot and login again.

After rebooting, it is worth checking your time and timezone with dpkg-reconfigure tzdata. It has a similar interface to raspi-config and should be easy to find your way around with the keyboard.

Add a new user

It is a good idea to create your own user account and trash the original pi user. This will keep your Pi nice and safe should you expose it to the internet or invite a hacker to stay in your house. Run the following commands in sequence replacing <name> with your chosen username.

sudo useradd -m <name> -G sudo
sudo passwd <name>
exit
ssh <name>@192.168.1.10
sudo adduser <name> video
sudo deluser -remove-home pi

These steps will:

1. Create you new user and add it to the sudo group
2. Setup your password for your new user
3. Logout
4. Log back in again (remember to change the IP to that of your Pi)
5. Add your new user to the video group which fixes a few Raspberry Pi tools like checking CPU temp
6. Delete the original pi user and all files in the home directory (make sure you have backed up what you need there first)

If you find you are unable to autocomplete (tab) commands in your terminal with your new user, it may be because you are using the wrong shell. You can fix this following the guide here.

Install Git

sudo apt-get install git-core

I try to store most of my project code on GitHub if possible and the git-core package will make it possible to push and pull code from the command line. Whilst you are messing around with Git, I recommend taking a look at the log2ram project. It will store all of your system logs in RAM which is useful for reducing SD card wear and prolonging the life of the card. I don’t use it on all my Pi projects but it can be useful on busy systems where you have some RAM to spare.

Speed tweaks

As well as the usual processor overclocking that you can do (I haven’t felt the need yet), you can also improve the performance of the SD card. To do so edit boot/config.txt and add dtoverlay=sdhost,overclock_50=100 on a new line in the file. The overclock value will need to be adjusted to suit the SD card you are using. It is a fairly involved process to get the best value for your card but can make a real difference. dmesg is also useful for spotting issues. You should note that this change can cause issues with WiFi too if you are relying on that for your network connection.

Power tweaks

One of my favourite things about Raspberry Pis is how power efficient they are. It means you can leave them all the time without worrying about the environmental impact or huge energy bills. With a few additional tweaks you can save a few more milliamps. There are some great tips come from Jeff Geerling in these excellent posts that are worth running through. My favourite tweak is disabling the HDMI circuitry by adding /usr/bin/tvservice -o to /etc/rc.local.

Docker

Docker is a containerisation software that allows you to isolate software applications. Containers are more lightweight than traditional virtual machines. I find Docker the best way to run services on the Raspberry Pi as it allows me to get the most out of the resources available and removes the need to for reformat the SD card every time my tinkering goes a bit too far. Install docker with the following command and then add your user to the docker group:

curl -sSL https://get.docker.com | sh
sudo usermod -aG docker <name>

Once again replace <name> with your chosen username. I recommend installing docker compose too. This will allow you to configure and start you containers reliably from docker-compose.yml config files.

sudo apt-get install python-pip
sudo pip install docker-compose

This last Docker trick is optional. Docker can use quite a bit of space on your SD card so if you have external storage (like a hard drive) it can sometimes be beneficial to move dockers internals to a different storage location. Edit the docker.service file (sudo nano /lib/systemd/system/docker.service) and modify the line starting with ExecStart to be:

ExecStart=/usr/bin/dockerd -H fd:// -g /path/to/external/storage/

The path should be to your external storage. You can then restart Docker and check the change has saved by running:

sudo systemctl daemon-reload
sudo systemctl restart docker
docker info | grep "loop file\|Dir"

Updating Docker in future may require you to make this change again. You will know if it needs doing as your containers and images will disappear after an update.

SSH

Almost done. These next few steps will configure SSH, allow for a simpler login (SSH via public key) and mount an external server using sshfs. First generate some keys with ssh-keygen -b 2048 -t rsa and add public keys from your other computers to: .ssh/authorized_keys. sshfs should be installed with sudo apt-get install sshfs. Once installed you can mount your external server by editing /etc/fstab and adding:

<name>@192.168.1.11:/media/data/ /media/path/ fuse.sshfs _netdev,nonempty,allow_other,IdentityFile=/home/<name>/.ssh/id_rsa,reconnect,ServerAliveInterval=45,ServerAliveCountMax=2 0 0

Make sure you set the relevant paths, IP addresses and usernames in the fstab entry above. Test it without a reboot by typing sudo mount -a.

With all that completed you are now set with the perfect slice of Pi. Time to get hacking on your projects!

Optional extras

• Tweak your swap if RAM is tight (works well with compute modules)
• Encrypt your home folder
• Encrypt an external drive
• Mount a samba/Windows share
• Adjust the thermal properties of the CPU

Project goals

• Learn. I work with React most days so I wanted to try something else to better understand modern web development, not just a particular framework
• Speed. I wanted a site that is fast, lightweight and better for the planet
• Resilient. A site can handle LOTS of traffic and is also available via the P2P web
• Low cost. Less than £15 a month to host and maintain
• Privacy built in. No trackers, externally hosted JavaScript or fonts

Nuxt.js

At the heart of the experiment is the Nuxt.js framework. Nuxt is a framework for creating universal Vue.js applications and in many ways it feels like working on a WordPress theme. It has a folder for your pages/templates, a hook API, support for plugins and components (or template parts if your thinking WordPress). Nuxt follows a philosophy of convention over configuration, drop Vue components in their respective folders and Nuxt will bind everything together.

This fairly rigid structure is important to the framework as it allows it to operate in three distinct modes:

• Single page application (SPA) — Run as a regular Vue web app
• Server Side Rendered (SSR) — For each request, pre-render the application on the server and send that back to the client
• Static (Generated) — Pre-render the application once during build, and then serve it as an SPA

I was personally interested in the static (generated) and SPA modes which would allow me to host the interface in isolation to WordPress and without the need for Node.js hosting. This would allow me to make use of some of the free static hosting options out there like GitHub pages or surge.sh.

Out of the box Nuxt supports routing (vue router), a store (vuex), filters (core vue 2) and meta data (vue-meta). I added some additional plugins for progressive web app (PWA) features, animation, lazy loading, keyboard navigation, sitemap generation and axios.

After some experimentation I discovered that Nuxt didn’t quite work as I expected to. A statically generated version of the site only loads statically for the initial page load, the app is then bootstrapped and runs client side, making API requests back to the WordPress API. This is probably fine in most circumstances but I wanted to have a version of the site served over Dat (the peer to peer web) and would rather that it didn’t need the API. I was looking for a truly static site.

Luckily Nuxt has some hooks which allowed me to cache a local copy of the API responses as JSON during the build process. When deployed, the app will then query itself rather than the WordPress API. You can see some of the logic here and here.

WordPress

The WordPress side didn’t need a great deal of tinkering. I moved the site to api.scott.ee and set a redirect on that to the main site. I then introduced a couple of filters for supporting lazy loaded images and enabled photon in Jetpack so images are served from a CDN. Images are the only thing that are not part of the generated build of the site.

WordPress should see very little traffic (if any) and only ever be hit when I want to write some new content or during the site build/generate process when the API is fetched and cached.

Performance

Nuxt takes care of a great deal of the app bundling, minification and optimisation for you. Add the PWA module and you can get a decent Lighthouse score right out the box. I also recommend installing the Nuxt webpack monitor module which allows you to inspect the size of your bundles which can be useful when you start to make use of third party add ons. Running yarn nuxt build --webpackmonitor --analyze will launch an interactive breakdown of how your site is put together.

The next thing to implement was lazy loading. Lazy loading ensures that images are not wasting bandwidth by loading unnecessarily. Using Jetpack’s photon CDN I can request a much smaller version of the original image to act as a loading image while the original, full size image, is fetched. I use CSS filters to blur the loading image slightly and make it greyscale. The result is rather neat.

My final trick for images is to detect low bandwidth (2G/3G) visitors and those with the data saver option enabled in their browser. In these scenarios the image quality is reduced to 50% and the resolution divided by four.

As you page around the site a request for the next page is made in the background of the current page to help speed things up too.

Infrastructure

I had grand plans for this. My aim was to use Cloudflare’s load balancing feature to split the site hosting between Netlify and GitHub pages. That way if either service went down, the site would stay up. Cloudflare would also act as a third backup / cache if things got really messy. I struggled to get the load balancing health checks to work and the load balancing feature came in at a whopping cost of $5 a month so I decided to park that idea for now.

After some speed testing I decided to keep things simple. It turns out that GitHub pages are one of the fastest places to put your code and Cloudfare only seemed to make it slower (albeit just a little bit):

netlify: sweden (no cloudflare)

First test: 2.04s 88/100
Second test: 1.79s 88/100
Third test: 1.69s 88/100

netlify: sweden (cloudflare)

First test: 3.17s 94/100
Second test: 2.20s 94/100
Third test: 3.17s 94/100

github: sweden (no cloudflare)

First test: 540ms 88/100
Second test: 200ms 88/100
Third test: 236ms 88/100

github: sweden (cloudflare)

First test: 786ms 94/100
Second test: 312ms 94/100
Third test: 277ms 94/100

Dat

Dat describes itself as:

A p2p hypermedia protocol. It provides public-key-addressed file archives which can be synced securely and browsed on-demand.

In short, you can host your website using peer to peer technology and it is super exciting. Everyone that visits a site is also potentially a host of the site.

In order to visit the Dat version of my site you can use the Beaker browser. Using Dat DNS allows the site to be found at: dat://scott.ee/. There is currently one mirror/peer that is always online at hashbase.io and one of my next projects will be to set a Raspberry Pi to the task of providing another mirror. I would love to see some other mirrors pop up too if you feel like adding it to your library.

Using Nuxt to statically generate the site makes pushing to Dat a much simpler task, I am not really sure how WordPress will adapt to the peer to peer web as things currently stand.

The Results

So how did I do with my goals?

Learn. I work with React most days so I wanted to try something else to better understand modern web development, not just a particular framework

Completed. I am fairly comfortable with the basics of Vue now and learnt a great deal about Nuxt as well.

Speed. I wanted a site that is fast, lightweight and better for the planet

Pretty good, the load time hovers around 300ms and the page size at around 130kb without images. The lighthouse scores are fairly decent too with the lowest score being 73 for progressive web app features (this is mostly because I have disabled the service worker while I get up to speed with how they work).

It turns out that a friend and colleague at work has also been experimenting with making WordPress more planet friendly at the same time. I highly recommend taking a read of his post on serving WordPress in just 7kb! quite the achievement and it shows there is probably a great deal room for improvement here.

Resilient. A site can handle LOTS of traffic and to be redundant via the peer to peer web

Moderate. Without the load balancing there is a single point of failure. Having the Dat version ticks the box for the P2P web although I would like to consider seeding the site on other protocols as well.

Low cost. Less than £15 a month to host and maintain

Complete. Cost is £0.

Privacy built in. No trackers, externally hosted JavaScript or fonts

Complete. No need for GDPR compliance 🙂

What Next?

I treated this a purely a technical exercise rather than a design one but it provides the foundations for something much more interesting. My plans include:

• Gutenberg support
• Sustainable hosting. Performance is one part of the battle
• Store preservation between sessions which may be a better approach than the locally cached API during build
• Service worker support. I would like to get the Lighthouse score to 100 and find some other performance gains
• An automated build and deploy script that only builds the difference in content

If you are interested in the code you can find on GitHub:

View the code on GitHub

Search has typically been a challenge with WordPress, especially for larger sites with extensive content archives. Jetpack Search was created as a simple way to bring the power of Elasticsearch to WordPress.

Jetpack Search was originally only available as part of the higher tier Jetpack plans. In early 2020, we embarked on a project to create a standalone product that brought improvements to speed, ranking, indexing and theme compatibility.

Research

The research for this project was fairly extensive. We explored competing products, surveyed existing Jetpack Search customers and performed short internal interaction tests to fine tune behaviour of the product.

The research helped us prioritise our roadmap and identify the following features as our main areas of focus:

• Relevance (8.5)
• Search speed (8.4)
• Facets (7.5)
• Prioritising search results (7.2)
• Ability to customise the look and feel of results without code (6.7)

Challenges

Ensuring theme compatibility was our biggest challenge. There are hundreds of thousands of commercial themes to accommodate and bespoke themes too. We set out to find a solution that was theme agnostic, a balance between a opinionated design and something that inherits the look and feel of your chosen theme and brand.

We also wanted to ensure:

• Instant search lived up to its name, providing results as you type
• We could support large data sets with filters and faceting options
• Search worked on all devices, from desktop to mobile
• Searches were linkable and search engine friendly
• Customers could purchase and immediately use Jetpack Search

Refining the user journey allowed us to reduce the time from initial purchase through to working product. This created its own set of unique challenges — the most difficult was determining the point at which we were able to begin indexing the site. Ideally the index will have processed at least the last few weeks of content, ensuring that the customer can test the product after purchase. An incomplete index would potentially make the product look broken, so we needed a way to highlight index progress if it was still ongoing by the time the customer returned to their site.

Solutions

We solved theme compatibility issues by creating a search overlay. The overlay would inherit some theme styles such as typography and link colours, but also impose much needed restrictions on layout and behaviour. This allows us to deliver features of the product like faceted results and search as you type without having to worry how a theme has been created.

Within the WordPress administration interface we also created some new UI elements to communicate the index progress and also plan usage. Jetpack Search is billed per record, so it is important customers understand at which point they are likely to be moved to the next billing tier.

Prototyping

There were two key interactions that we wanted to refine in order to make the product feel instant and responsive.

The first was how the search experience was triggered. Most WordPress themes already have a search field somewhere on the site which gave us multiple options for how the search overlay is triggered; either on focus or after the initial query..

The second thing we wanted to test was the impact of search as you type. Whilst Google have normalised this, we wanted to understand how it impacted the perceived speed of the product and also test our APIs to ensure they are nice and responsive.

I developed a one file plugin for WordPress that allowed us to test ideas quickly in the most popular 20 WordPress themes. We used the plugin to test these specific interactions with customers before having to invest in their development.

Results

I like having a search experience that is sortable, filterable, and feels like it's integrated natively into the site. Jetpack Search does all of this, but most importantly, it returns great results without heavy configuration.

Spinning search into a separate product has worked out well. The lower cost tiers proved really popular with customers just looking to improve search and that didn't need many of the other Jetpack tools and features. New purchasers have been increasing steadily (~45% MoM each month since launch).

This isn't the end of the journey for Jetpack Search. We have already began collecting feedback for further refinements to the product including search analytics and greater control over what content is pushed to the search index.

Try Jetpack Search on CSS Tricks

While packing to move to Sweden, we realised we had hundreds of rolls of negatives and boxes of prints that we had not done a great deal with. Some films were full of random experiments, others taken on expired and untrustworthy film. Some captured something beautiful and others went straight to the bin. Those that survived were put into boxes and shipped to Stockholm.

Let the archiving commence

The Covid-19 pandemic proved the opportune time to start doing something with them. We fired up our scanners and began uploading our favourites to Unsplash. Founded in 2013 as a Tumblr blog, Unsplash has grown into an industry-leading visual community. Despite their sometimes confusing approach to licensing, it remains one of the most active and supportive photography communities.

These are just a handful of my favourites, you will find the rest on mine and Gemma's Unsplash profiles.

View my film photos on Unsplash

Jetpack is a open source WordPress plugin for self-hosted WordPress users. Jetpack provides stats, email subscriptions, backups, malware scanning, anti-spam, and more. Its wide range of features makes it extremely popular with over 5 million active installs.

Challenges

In 2019 market research indicated that security and malware remained the top concerns for WordPress users. Jetpack had backups, login protection, anti-spam and malware scanning, but they were relatively hidden among all the other features of the product. Given the high demand for these features we decided to refocus Jetpack on security.

Audience

The audience for Jetpack is as broad as its feature set. The key audiences are the end users; the website builders and development agencies that are integrating Jetpack features into their sites and builds. But Jetpack also has partnerships with hosting agencies and relationships with other internal Automattic teams too. This project was aimed towards our end users, but would deliver benefits to hosting partners who can leverage Jetpack security products in their own platforms.

Scan and backup

Two teams were formed; one for backup and the other for scan. My team focused on delivering a new UI for Jetpack Scan and my roles included UI design, copywriting and prototype development. We defined the following goals:

• To provide the best customer experience for Jetpack Scan
• To make the Jetpack Cloud a security focused customer experience
• To provide an API and destination for customers of Jetpack hosting partners
• To retire the legacy Automattic security plugin, VaultPress
• To reduce security related support inquiries

Solutions

The Jetpack Cloud is built on top of the Calypso framework. This allowed us to move much quicker, inheriting the existing component library.

The first release of the UI was reduced to all that was necessary. A scan will begin instantly once your purchase is complete. You are then presented with scan results (if there are any) and history of previous actions taken.

We used animation to help communicate state within the product. It also added a little bit of interest to the UI which is sometimes blocked by long running tasks. These are available on CodePen if you wish to see them larger.

Refinements

Shortly after launch we were seeing a high failure rate with customers attempting to save their hosting credentials. Having hosting credentials on file allows us to perform one click fixes of known security threats and also improves the reliability of our backups product. Our data indicated:

• 54% of all failures were caused by entering incorrect credentials
• 22% of failures occurred on a single host

We created two new mini projects, one to create automated credential sharing with the the largest host and the other to improve the credentials form and flow.

The original form was quite primitive. It provided little support on where to find the information you need and didn't guide you through the process. It also didn't provide guidance when errors did occur with just a single generic error message.

The following image shows the updated flow for the new form. The form was broken into four parts:

1. Host selection: We provide a list to of common hosts but also make a best guess as to what your current host is and put it at the top.
2. Credentials form: The form responds to the type of credential selected and the inline documentation provides hints and a link to your chosen host and related documentation.
3. Credential verification: The credentials are tested in a stepped fashion in order to show the user at what point the failure occurs. This makes it easier to understand the error and adjust accordingly.
4. Confirmation: If everything looks good, you save your credentials.

The form went through twelve design iterations as we refined the flow and ensured we handled all edge cases. Within just a few weeks of releasing the updated form we were seeing around a 30% reduction in failures.

Results

Since launch, Jetpack Scan has become the third most popular Jetpack product and has been one of the best performing products in 2021. We are investing heavily in improving the underlying scan system, making it better at both detecting and fixing errors. Our customers appreciate the simplicity and peace of mind.

My website is my home for everything I do, so it’s important that it's always online for all of my readers and listeners. Jetpack handles my site security and backups, so I can stay focused on keeping a 4-hour workweek.

Two major hosts are looking to integrate our backups and scans products into their WordPress hosting plans and we will hopefully see the first of those launch in the near future.

We are hoping to recreate some of the successes we have seen by breaking Jetpack into more focused solutions. This will hopefully be better value and provide greater clarity around the Jetpack product family for our customers.

Learn more about Jetpack Security

At first glance it seemed like a good idea. It would remove the need to report meter readings manually each month and allow home owners to see (in realtime) their energy consumption. Hopefully that would lead them to adjust their usage, saving both energy and money.

It raised two concerns for me. The first is that the data would not be available locally. The meters report energy use to the supplier and there is no requirement for them to provide an API or access to the data they are collecting. Being able to see energy use over time would be a great way to spot trends and decide if we would be better suited to a different energy tariff.

My second concern was privacy. You can tell a great deal about a home and the people who live there from their energy use. You can determine what time they wake up, what time they make dinner, see if anyone is home and how efficient their fridge is. I would rather be in control of where that data goes.

By 2018 it was clear that we wouldn't be getting a smart meter any time soon and so I set about creating my own that would require zero modifications of our meter.

My solution is called Watz.

Watz is a WiFi smart meter built around a Particle Photon. It mounts to the LED on your electricity meter and measures the number of pulses in a given time period (sometimes referred to as a pulse counter). This is used to generate almost real time power information.

The data is periodically pushed to the Particle cloud and can be subscribed to via server-sent events. To make the data a little more accessible I used Node-RED to subscribe to the events and push the data to the open source Emoncms. Emoncms is a platform designed to track energy consumption.

Our meter sat outside by our front door so I ended up using a fairly large battery and a small solar panel to keep the device topped up with power. This meant I had to reduce the frequency of data being pushed to ten minutes as firing up the Wifi connection proved rather expensive in terms of power.

The firmware, component list, circuit diagram and code can be found on my GitHub account if you would like to build your own.

View the project on GitHub

The Particle Core is an Arduino-compatible, Wi-Fi enabled, cloud-powered development platform that makes creating internet-connected hardware a quick and simple. Most importantly it is open hardware and software — sharing the WordPress philosophy.

My slides are below and I have also added a few of the GitHub links to various experimentations and tools mentioned throughout the talk. If you have any questions ping me on twitter.

• Nimbus — A Spark Core Weather Station
• Sparky — Shortcodes for your Particle Core
• IFTTT — Easy way to connect all the things
• Ham — Home Automation Machine

A video of the talk is now available on WordPress.tv.

WordCamps are conferences dedicated to everything WordPress. WordCamp London 2015 was a 3 day conference held at London Metropolitan University from 20th – 22nd March. As with all WordCamps, it was organised by volunteers who are passionate about WordPress and the WordPress community.

Whilst I have designed for and volunteered at a number of WordCamps, this stands out as my all time favourite.

Punk rocks

For WordCamp London the organising team were keen to find a theme for overall conference design. I created a number of mood boards that covered things we considered to be typically “London” and developed ideas from that.

There was one idea that stood out and having grown up on a diet of punk rock, it felt like a natural fit. WordCamp London 2015 would be based on the punk rock subculture of the 70's. It would give us a conference that is fun, bright and distinct.

Adopting Wapuu

The WordPress mascot Wapuu was born out of the Japanese WordPress community. Whilst the mascot had been used in Japan since 2011, very few WordCamps outside of Japan were adopting the mascot. For WordCamp London we wanted to change that.

Meet Wapuunk! The only Wapuu with DM boots, a mowhawk and safety pin piecing. The little mascot I designed became the star of the show and was made available to purchase via the WordPress swag store shortly after the event. The money raised from the sales has been used to support the WordPress foundation.

Wapuu is completely open source, the source code can be found on GitHub along with the original Wapuu gallery.

Swag

All good WordCamps provide a unique piece of swag to remember the event, normally in the form of a t-shirt. We had some t-shirts made, but given the event was taking place on the tail end of a British winter, we decided we needed a little something extra. The result was a scarf, featuring Wapuunk of course.

Huge props to @scottsweb for the best WordCamp branding & swag I've seen to date. Amazing work, Scott <3 #wcldn

We also made digital swag for those that couldn't attend the event in person. You can download posters and wallpapers from the event website, all under a creative commons licence.

Grab some digital swag

toggle was a boutique gadget case company. Each case a handmade labour of love, designed to protect your precious gadgets, with a little extra personality.

The company was created to offer an alternative to the mass produced, environmentally destructive, synthetic cases that had flooded the market since the release of the first iPhone. The bet was that if people were going to be spending thousands of pounds on smartphones and laptops, they would want to give them a little extra love and protection.

toggle cases were all made from sustainable materials such as wool, upcycled fabrics and old clothing. The products were shipped in recycled “preloved” packaging too.

We liked to say the cases were “made by people, for machines”.

This was the third version of the toggle shop that I designed and built. This version was powered by WooCommerce and WordPress.

Unfortunately we had to wind the project down as the cost per case was pushing too high to be sustainable when competing against the mass produced cases on shops like Amazon.

Today is no exception and watching the way he interrogates, questions and learns had me realise that there is a great deal a designer can learn from this unassuming TV detective.

Ask the right question at the right time

Columbo is famous for his catchphrase “Just one more thing…”, which is his way of squeezing in one last question before he leaves. As a detective he thrives on data and knows the right questions to ask and when to ask them.

This week I have been gathering plugin data across our VIP Go platform and using it to better understand how clients are using plugins on our platform. My aim is to reduce the number of options available for managing plugins and for us to provide a better service when it comes to updates and security fixes. The question I am asking myself right now is: what plugins are in use and how have they been activated?

We will start collecting the data and graphing it over time so we can actively monitor the progress of my work from start to finish. I can see the same data being hugely useful as time goes on. We just haven’t found the need to ask the next question yet.

Put yourself in your killers customers shoes

In “Any Old Port in a Storm” the murder takes places in a winery. The murderer is a wine connoisseur and in order to understand how the killing took place Columbo immerses himself in the world of wine. The knowledge he gains from his research allows him to solve the case and determine where the body was stored. The research also created a huge amount of empathy between Columbo and the killer.

With the launch of the new VIP website a few weeks ago it has been a great reminder of the challenges our clients face when they need to push code from a modern version control environment like GitHub to our SVN setup on WordPress.com. Putting ourselves through the same experience as our clients has been immensely valuable and highlighted some of the pain points developers face with our WordPress.com platform. We are hoping to use our new found empathy to help streamline the process if possible.

Equipment doesn’t have to be the best

Rust bucket doesn’t quite describe the poor state of Columbo’s car. He arrives on scene in a puff of smoke in a old French car that looks like it could barely take a corner without rattling to bits. The car serves him well across the entire 32 year lifespan of the programme. It gets him where needs to go and does the job well enough.

We are very privileged at Automattic to receive a new computer every 18 months and have access to the very latest and greatest technology. The problem with this is our tools do not necessarily reflect those of the people we serve. This is one of the reasons I moved away from an Apple laptop this year.

The more we can diversify the technology we use, the greater it represents the audience we serve and the better our products will be as a result.

Name for SEO

When Columbo adopts a dog in “Étude in Black” he spends most of the episode trying to decide a name for his new pet. He settled on “Dog”.

The names we use for projects, software and teams are hugely important for discoverability, especially when most of us begin exploring cyberspace with a search.

And one last thing…

If you are feeling inspired to sit down with Columbo for an hour or two then I recommend the following episodes:

• Double Exposure
• Blueprint for Murder
• The Bye-Bye Sky High IQ Murder Case

Walking back to our hotel one evening, we discovered a building that stood out to us. It was a huge, abandoned and had ‘Stop Wars’ painted in red across the front. The lettering was the height of two floors and spanned the width of one end of the building. A fairly impressive piece of graffiti on an even more impressive building.

It seemed odd that such a huge structure had been left to decay in what is a fairly central and busy part of the city. If this was London, it would be have been re-developed into flats and restaurants long ago.

We got a little closer and made our way into the central courtyard to see if we could find a way to photograph or see inside. We took a few steps into the courtyard and realised we were already being followed. Not knowing the area we scuttled back the main road and continued to walk along the entire length of the building, it went on forever.

Back at the hotel and on a stable Internet connection, we started researching this mysterious, bleak and intriguing lump of concrete. It turns out we had discovered Haus der Statistik, the former statistics-gathering HQ of the German Democratic Republic. The top search result was a blog called Abandoned Berlin. It is a fascinating site that explores the history of forgotten landmarks in and around Berlin. It has some beautiful photos of these forgotten buildings — including photos inside of Haus der Statistik that we didn’t manage to snap ourselves:

Haus der Statistik finished construction in 1970 and the top three floors were allocated for use by the Stasi. When unified Germany took over the building, the Stasi archives were made available to the German people. It would have been interesting to see what information may have been gathered about you by people never met. The archives were all moved out of the building in 1995 and the building was eventually abandoned in 2008. Looking at historical photos it is fascinating to see how the building changes and responds to the environment around it. Now it sits empty and is rather beautiful in a strange sort of way.

Unfortunately we discovered the Abandoned Berlin site just a little too late into our trip which meant we didn’t get to investigate more of the places that Ciaran has written about. Gemma surprised me with the Abandoned Berlin book for my birthday (who says blogging doesn’t pay?!) and I have since been browsing through more of these fascinating landmarks and stories.

Reading through the book it got me thinking about the things we build and leave behind. In the digital space there is no real concept of decay, change or imperfection. Everything is binary, it either exists or it doesn’t. We have very little interest in preserving the things we make and all too often they simply disappear.

You may have heard of the Japense saying ‘Wabi-Sabi’ which roughly translates to:

…the acceptance of transience and imperfection. The aesthetic is sometimes described as one of beauty that is imperfect, impermanent, and incomplete.

There are very few objects in life that become more beautiful as they wear and age. From time to time you will find something and I like to think Haus der Statistik is one of them. I have yet to find anything digital that displays these same unique qualities. I’d like to find it. I would like to leave behind something that lasts.

In our profession it is very easy to lose sight of the bigger picture. Our days are spent obsessing over graphic design details; typography, grids, hierarchy, message and meaning. Occasionally we need to step back to consider the collective effort that has gone into making our society the way it is today. Many generations of work, time, money and thought has led us to this very point in time.

Everything is designed. Few things are designed well. — Brian Reed

A few years back I had the opportunity to visit two very different European cities in very quick succession. A stag weekend in Benidorm, followed by a short break in Copenhagen. In just one week I was exposed to two very different approaches to design.

Prior to the 1960s, Benidorm was a small village. Today it stands out for its hotel industry, beaches and skyscrapers, built as a result of its tourist-oriented economy. The newer buildings are largely bland boxes with little respect for the heritage of Old Town Benidorm. Restaurants focus on price over quality and attractions distribute scooter riders with megaphones in a bid for your attention. Benidorm epitomises cheap, quick and convenient.

When walking around the streets of Benidorm it feels as if everything has been designed for price over experience. As a result it lacks culture and depth. The beautiful beech (the reason people flocked there is the first place) is no longer visible through the rows of sandy sky scrapers.

Copenhagen is a major regional centre of culture, business, media, and science and it is also considered one of the world’s most environmentally friendly cities. Aesthetically Copenhagen is a vast contrast to Benidorm. Historical buildings have been cared for whilst new builds are edgy, architectural master pieces that will stand the test of time to become historical attractions themselves.

Our hotel (Hotel Fox) invited different illustrators and designers from around the globe to create unique experiences for each room. Restaurants serve fresh, delicious dishes with attention to tiny details such as cutlery and furnishings. The Copenhagen experience has been crafted, considered, refined and is likely the primary reason why the city has repeatedly been recognized as one of the cities with the best quality of life.

It is our joint responsibility to consider the impact our work will have on our society and the world we live. The smallest of details have a real impact on the quality of our work, its longevity and its effect on culture.

Design creates culture. Culture shapes values. Values determine the future. — Robert L. Peters

If everything is designed, perhaps design is everything. Design changes the world. Done well, it changes it for the better.