Geeky Digital Nomadism on I Lost My Page

Quitting my job to travel the world (again)

Fri, 15 Dec 2023 12:00:00 +0000

A few more years pass, another post about my next dramatic (to me at least) life change. I’m starting to think this is going to be a 5-yearly occurrence at this point. Better than a 7-year-itch I suppose.

So what are you doing Jason?

Technically, I’m airbnb-ing in Thailand for a few months. This so far has involved a fair bit of The Legend of Zelda, some beers and lots of scooting around. There has been a little bit of coding/general infrastructure upkeep in-between that, which I think will start increasing soon as it turns out I get bored quick. After this, I’ll likely continue on to do the same in Vietnam or Malaysia when the tourist visa’s run out. Maybe a cheeky Taiwan trip, who knows? Oh, and probably a few months stint back in blighty too.

But what are you really doing? Like, with your life bro?

Fuck knows. I mean, I’m meant to be figuring that out right. And I’m meant to be taking it easy and letting it come to me, not putting pressure on myself to start the next thing, or find some income stream or whatever. But…. buuuuuut… I’m less than a week in, and already I’m spinning out a bit. And, as above, I’m already starting to tinker. I dunno, I just like it I suppose.

Well, what do you want to do?

Definitely not rattle on in such self-serving wankery via a blog post. I mean, I’m typing these questions as well as the answers, aren’t I? I’m surely not fooling anyone here… But, I don’t have anything better to do, do I? ¯\_(ツ)_/¯. Eh, it might help me work it out so fuck it: I want to “build my own thing”.

I’m not 100% sure what that means though…

Is it doing “a startup”? With all the silly VC-chasing and growth-growth-growth that comes with that? I’m really, really not sure that’s something I want to do. And nearly definitely not something I want to do on my own.

Or is it doing something IndieHackers-esque? Antiquoted might be just that, but can I really finish building something out like this? And even moreso, if I do, can I make any bloody money from it? And all on my own-ish? Ugh, such dilemma.

Anyways, now you’re up to speed at least

It’s a bit of a conundrum eh. I reckon I’ll probably figure it out. I mean in a worst case scenario I’ll end up getting a job again halfway through next year. So like, from a super-privileged perspective, I’m fine. But, from a “WHAT THE FUCK AM I DOING WITH MY LIFE?"-perspective… less so. Watch this space for my next ~~flounderings~~ steps.

Testing out a new deployment system

Tue, 03 May 2022 01:00:00 +0000

This is a test, please don’t ignore! Or well, you can, but it’s only a quick one, all about how I’m trying to hack together some static-site publishing from my ipad.

What my previous static site deployment looked like:

I’d write the new post into my repo.
Commit and push it just for safety/backup.
I’d manually rsync the build folder up to my vps
Hey-presto, new site was live.

What’s happening here? Well to get this post onto my website the following steps must have happened:

A Github Actions workflow has ran, based on a manual trigger or me pushing master.
The runner has pulled this file (and any other markdown files in the right directory) and place them into the /posts folder in my hugo repo.
The runner has done the same for any static content, recursing down into sub-folders to keep the right structure.
The runner performs a hugo build and then archive’s the results.
The runner triggers an AWS remote shell command on my VPS.
The VPS uses a token it has to download the bundle from github and then unpacks it to the right nginx path.
Hey-presto, new post is live.

The main goal here was to enable me to “deploy” a static site using only ‘cloud-native’ tooling so that I can update it from any device that I have access from. I’m in the process of automating and improving how I’ve been hosting more traditional (read static & WordPress) websites over the past month or so, hopefully I’ll be able to write more posts soon about how I’m doing it. Heck I might even share the code/config I have if it’ll be useful for others.

Of course, if you’re not reading this, then it didn’t happen… so I must have broken something somehow 🤔 and that tree probably didn’t make a sound. But you are, and it did, so woop. Here’s a random image to both celebrate and prove that the static image stuff is working too!

Managing your terraform across multiple environments

Fri, 01 Jan 2021 00:00:00 +0000

You’re managing your cloud infrastructure using Terraform. You’ve got your first environment up and running and you’re already reaping the benefits of a codified infrastructure. Changes are easy. But, now you need to set up a second environment (staging, prod, whatever) and you’re finding that managing this is not straight forward. There’s a bunch of arguments to remember every time you switch between environments, and your switching a lot because you want to keep them in sync. Because this is hard you tend to use auto-complete, but then sometimes you forget to change something and accidentally apply prods config to staging. Well, as in many occasions, a Makefile can probably help you there.

I think I’m with you, but do I really need this?

Terraform is a per-environment tool. i.e. you benefit from terraform by knowing that you’ve applied exactly the same configuration to each of your environments, and that this way you can always keep them in sync. This is benefit numero uno, but it means it’s down to you to figure out how to handle the dynamic parts yourself. Terraform helps at least a little by providing a way to pass in variables by environment variables, command line arguments or tfvars files.

Ok, so why not just use a `tfvars` file for each environment?

Well of course environment-based tfvars files are a good idea, but the problem is that not all things can (or should) go in them.

Some things that can’t:

state-file backend information
“dynamic” output from preceding non-terraform code
“standard” CI environment variables that need some name-coercing.

Things that shouldn’t: !1!1!anything secret!1!1!.

Let’s talk through an example of why it might be beneficial to wrap up our terraform commands in a Makefile to ensure our environments are kept both safe and distinct:

include  ../envs/$(stage).env

init:
  terraform init -reconfigure \
    -backend-config="key=$${TERRAFORM_STATE_FILE}" \
    -backend-config="bucket=$${TERRAFORM_STATE_BUCKET_NAME}" \
    -backend-config="region=$${TERRAFORM_STATE_REGION}"

and our env file looks something like:

TERRAFORM_STATE_FILE=project-name.dev.tfstate
TERRAFORM_STATE_BUCKET_NAME=project-name-state
TERRAFORM_STATE_REGION=eu-west-1

Here we have an initialisation wrapper. This sets our backend-config based on environment variables stored in an env file. If we have a different state bucket for our dev, staging & production environments, we can easily switch between each environment without the chance of getting anything wrong. Anything secret has to go into protected variables in our CI pipeline.

Why not just put all of this out into one big state file?

Well, you can’t really, otherwise you’re not applying the same Terraform resources to different environments. You could put multiple state files in the same bucket, which avoids the bucket_name & region arguments above, but then you have to figure out how to ensure access to each place. If you are (probably wisely) running your production environments in a different AWS account, then you end up having to give some runners cross-account access. Don’t even start me on which way this access should flow… Nah, just put them in their own buckets in their own environments and save yourself all of that headache. Dev runners access the dev bucket, prod runners access the prod bucket, etc.

If I’m wrapping init like this, should I do it for other commands too?

Up to you, but probably yes. Here’s how I’d set it up:

tf_plan_args = '-out=.terraform.tfplan -var-file="$(stage).tfvars"'
ifdef special_flag
	tf_plan_args += '-var="special_flag=$(special_flag)"'
endif

plan: clear_plan
	terraform plan $(shell echo $(tf_plan_args))

apply: clear_plan
	terraform apply .terraform.tfplan

clear_plan:
	rm -f .terraform.tfplan

This ends up with a few handy features:

We clear the plan file after each plan/apply, meaning there’s no way to accidentally apply a stale plan.
We get much nicer cli syntax like this:
- make stage=dev init
- make stage=dev special_flag=73 plan
- make stage=dev apply

A slight extension

One pattern I’ve come across a few times now is where you need data in your terraform plan that isn’t managed by terraform. This could be:

Some environmental/system data.
Output from legacy systems.
Even something that simply can’t be terraform-controlled.

In this kind of scenario most things output as JSON, and jq is a great tool to parse this output in your Makefile to pass it into terraform. This is another great reason to codify your terraform commands: you can make sure that this stitching always works the same in all of the places. Here’s an example of how I’d change the Makefile to handle this:

ifndef required_parameter
	$(error You must specify the required parameter.)
endif

tf_plan_args = '-out=.terraform.tfplan -var-file="$(stage).tfvars" -var="required_parameter=$(required_parameter)"'
ifdef special_flag
	tf_plan_args += '-var="special_flag=$(special_flag)"'
endif

plan: clear
    $(shell ./go-get-extra-vars-as-json.sh > .extra_vars.json)
	terraform plan $(shell echo $(tf_plan_args))  -var-file=".extra_vars.json"
	
clear:
	rm -f .terraform.tfplan .extra_vars.json

Caveat: depending on your CI setup, the extra_vars.json may simply be input from a previous step, so the file might just come in as an artifact from a previous step and then it’s down to any manual runs to provide this data manually. This obviously depends on the use-case, so take this as just one approach out of many.

Final thoughts

There are probably other ways to achieve the above. I’ve heard that Terragrunt is a thing, and whilst I haven’t dug into it I assume it’s going to solve these kinds of problems (I’ve avoided it because I dislike dependencies, and favour flexibility). To be honest, how you decide to solve this issue is totally up to you, this is just one way of doing it. However, there are a few important things in my opinion that your solution should solve:

Primarily: make sure that you do solve this issue, and that you solve it well. I mean, you have to, but don’t end up picking a poor approach that loses out on the main reason to codify your infrastructure: ensuring it’s the same in all the places.
Make sure that however you solve this, your solution lives in version control. This means that the way you interact with your environments evolves alongside your codebase and that all developers on the project run it in the same way.
Ideally this should be simple to write and simple to run everywhere. I chose Makefiles because it’s a pretty ubiquitous technology, and it’s cleaner and clearer than writing pure bash. The next step up would be a scripting language like Python, or even a full tool like Terragrunt - these both have a higher barrier to entry (in dependencies and new-things-to-learn) and in Terragrunt’s case less flexibility.

Some hints & tips

Use the makefile commands in your CI too, this way they always stay up to date, and you avoid the “it works on my machine” kind of scenarios.
If you have new, even one off commands, add them to your makefile and run them through CI. This has a few benefits: it’ll run (and maybe break) in your dev environment first, and you have a version-controlled history of what ran when.
Having to repeat arguments like stage=dev is annoying. I flip-flop between it being useful to remind you of what env you’re working on, and it being super tedious. You could make it go away with an .init tempfile that gets created during the init command. Just be sure to wipe it whenever you re-init (and be very sure what you’ve initialised when you want to before you run things).

Minimal Viable Journaling - How to use Makefiles to manage a simple journal.
Delivery Driven Developers - The reason behind this kind of approach and the priority of delivery.

Minimum Viable Journaling

Tue, 28 Apr 2020 00:00:00 +0000

Along with the million other things I’ve been trying over the past year of seeking self-improvement, journaling is one of the ones I’ve had partial success with (well, more than zero-success at least). Here’s some implementation detail on my setup and how I’ve kept it as bare-bones as possible, backed-up in the cloud and, most importantly for my tin-foil fetish, secure.

The Concept

I want something easy to maintain & setup (ideally zero-maintenance) and I don’t really want to have to pay for it for the rest of my life. I want it to be future-proof, I don’t want to come back to this in a few years and find nothing supports it’s format. Oh and I also want it to be secure as heck. The goal here is to brain dump my day, including all the thoughts I’ve had about it. I don’t want it accidentally being accessed by some randoms, or even non-randoms, without my express permission. Simple enough right?

The Approach

So, we want a simplistic file format. Any sort of proprietary format or under-popular open source one is only going to cause me pain in the future. This led me to a nice and obvious solution: Text files! They’re infintely interoperable, have been around forever, and will still be supported in a millionty years so it fits all the use-cases. For bonus points let’s make them markdown files (it’s just giving them md file extensions after all), that way we can add in links or a bit of formatting if we want to later and it’ll be pretty easy to turn it into HTML in the future if we fancy that too.

Ok, next up storage. Something like google drive or dropbox would work, but I don’t want these having to sit next to my other life-admin documents that I put in those kinda places. I also don’t want to accidentally delete this stuff, or parts of this stuff, when I’m tidying things up. Version control systems are good for making sure that’s very hard to do, and they come with free decentralized backing up on my machines if I’m into that. Git it is! Also, the interface to wherever I cloudify this stuff is completely interoprable and segmented into it’s own repository, so migration and organisation will be a breeze. Heck, I could even move them to something self-hosted if I cared enough (I probably don’t).

Ok so, markdown files, stored in Git. So far so good, but what about security? This is a super-secret private Journal right? Well, the way I see it there are 2 main attack vectors: the files sat on my machine(s) and the files sat up in whatever cloud storage I put them in (I’m discounting in-transit because whatever I use will have ssl). My machine I worry less about, but the main issue is these pesky cloud providers. I just don’t trust that they keep this info as secure as I need it, which means that I need to figure out a way to encrypt it.

Well, lucky for me, PGP is a thing :D A few simple commands can get me an encryption key that’s going to be pretty unbreakable for many years to come*. The one potential issue with this is that it’s not trivial to setup. With security, the biggest vulnerability is the squishy grey matter inside your head that regularly does stupid things (remember when you used to think shirts with flames on were cool… ugh idiot). Encrypting things with a PGP key is by no means hard, but we want to reduce the chance of human error as much as possible here. Thankfully, I’m used to doing this kind of thing in my day job; automating all the repetitive stuff. Should be a doozy.

The Implementation

So, we want some sort of scripting language, bash’ll do. But we want the interface with it to be as simple and clear as we can, so let’s not write it in raw bash, let’s use a Makefile, they’re universal enough. Here’s how we get a simple “create today’s markdown entry” to keep things nice and organized, and we open** it up using whatever our system’s chosen markdown editor is (in my case I use Mark Text).

# Set the entry to todays date if not specified.
ifndef entry
override entry = $$(date +%F)
endif

open:
	open $(entry).md

Next up we want to be make sure this is easily encrypted. I haven’t gone so far here as to integrate with my editor to auto-encrypt it once it closes, but this feels like an integration too far. I’d be writing a lot of scripting just to work with an editor that might be dead in a few years. Instead we simply write ourselves a save method that generates an encrypted file and wipes any raw ones***.

save:
	gpg --encrypt --recipient $GPG_EMAIL $(entry).md
	$(MAKE) clean

clean:
	rm *.md

And last, but not least, we need to back this up on the interwebs. This is easy right, just create a new repository on your git-host of choice and then run the below in your journal folder.

git init
git add Makefile
git commit -m "Can't forget to push this awesome Makefile I'm using."
git remote add origin [ADD YOUR URL HERE]
git push -u origin master

Next, we just need to update our Makefile to push this up when we’re saving:

save:
	gpg --encrypt --recipient $GPG_EMAIL $(entry).md
	git add $(entry).md.gpg
	git commit -m "Saving $(entry).md.gpg to repo."
	git push
	$(MAKE) clean

The Outcome

I’ve popped the file that I use for this in it’s entirety below, but I almost didn’t. I guess, the whole point of this rather simple post is that it’s so bloody simple. This is how I’m jounaling right now. It took me very little time to come up with and so far, zero time to maintain. It’s secure, robust, pretty (because of my editor) and it fits into my workflow easily.

Often when we’re faced with a need these days we take the “don’t re-invent the wheel” mantra and hunt for the newest saas product that fills our need. But often, they’re selling you a swiss army knife, when all you need is a spork. This little script was a nice reminder that sometimes if you just use your brain a little, maybe you can build what you really need pretty easily. One less subscription fee to pay each month isn’t a bad outcome either.

# Set the entry to todays date if not specified.
ifndef entry
override entry = $$(date +%F)
endif


open:
	if [[ -f "$(entry).md.gpg" ]]; 
	    then gpg $(entry).md.gpg; 
	else;
	    touch $(entry).md; 
	fi 
	open $(entry).md


save:
	gpg --encrypt --recipient $GPG_EMAIL $(entry).md
	git add $(entry).md.gpg
	git commit -m "Saving $(entry).md.gpg to repo."
	git push
	$(MAKE) clean

clean:
	rm *.md

Asterisks

* But not forever. Whilst you could publish your encrypted data, and no-one could really access it now, once it’s out there it’s out there for ever. Like EVER ever. Which means eventually, someone will be reading that info, and you’ll just be gambling that you’ve been dead long enough to not care. As such, I’d advise that you still put some practical preventions in place like sensible password protections on the cloud services you use to store this etc.

** The open command is mac specific, but swapping it for something that’ll run on your OS should be trivial.

*** I’m too lazy to write a post on how to use gpg, here’s one somebody else put way more effort into.

The easy way to view web certificate info (probably)

Tue, 24 Mar 2020 00:00:00 +0000

This is a quick little post about how I realised that there’s a nice and easy way to view detailed information about a web certificate available to most sensible people: Firefox

TL;DR: code

This is a built-in feature of firefox: click on the little padlock icon in the address bar when visiting any website using TLS, select the view cert info and a new tab will open displaying info about the cert. It’s pretty nice, they’ve moved away from the old menu-window interface and turned it into an actual web-rendered page. This has a few benefits:

It looks nice.
You can easily read all the info that can be contained in a cert, instead of it all being cramped in a little system window.
There’s, technically, an API interface to this.

Now, the last one is an odd one, but it’s actually the reason that I wanted to write this post. You see, I’ve been working a lot with the provisioning of keys & certs for infrastructure as of late, and it has lead to me needing to check the contents of certificates a fair bit to make sure they have the right information. This is easy once you have your infrastructure set up and everything works and you can connect to the bloody thing to check the cert by simply visiting the url, but that leaves you a bit out of luck when you’re not quite there yet. Or, as I found myself, when you’re debugging and testing scripting that you’re writing to try and automate this cert generation process. The only option available to me here was to either use openssl to parse the cert and decipher the output from the console, or go hunting for a new 3rd-party tool to render all the details in a more human-readable manner.

This is what lead me to my realisation: when firefox is displaying the cert, it’s doing so by simply parsing the base64 encoded certificate from the url of the page. This means that we can use firefox’s nice web-rendery view (yaaay, it’s already installed) to view certs stored locally. As such I wrote up the smallest Python script i could to read these files in a much nicer way*. I love automating the little things like this, it’s the best way to keep up productivity.

Code Sample

#!/usr/bin/python3
import os
import sys
import urllib.parse

if len(sys.argv) < 2:
    raise ValueError('Need to pass file paths in as args.')
    
for arg in sys.argv[1:]:
    with open(arg) as f:
        lines = [
            line.strip() for line in f if not line.startswith('---')
        ]    
        param = urllib.parse.quote(''.join(lines), safe='')
        os.system("/Applications/Firefox.app/Contents/MacOS/firefox about:certificate?cert={}".format(param))

*caveat: Due to the file path used, this will only work on MacOS . That said, it would be trivial to switch the paths out to your system’s one, the executable should take the same arg.

Hugo On Then, I'll find a better Static Site Generator

Thu, 10 Oct 2019 00:00:00 +0000

I recently changed this site generation from using Hexo (a JavaScript static site generator), to Hugo (a Golang-based one) and it made me happy for quite a few reasons. Don’t get me wrong, Hugo ain’t perfect, but having a little less JavaScript in my life has made me a happy chappy.

Well mostly, I’m still using it for my asset pipelines for now, so I haven’t yet gotten completely rid of JavaScript compilation, but at least it’s not a part of my content-generation flow any more. Anyways, here’s a roundup of the differences:

The Good:

Simplicity: Hexo, and specifically having a per-project installed JavaScript generator with LOTS of dependencies, made maintenance more messy than I wanted for a simple blog or content-based site. When someone decides to use a static site generator, it’s usually not because they can’t host something more complex (they’re all command-line tools after all, land of the developer), but instead because they want the easy life that a simpler setup provides. Hexo’s many dependencies that needed installing and updating, not to mention its mixed backward compatibility changes over time weren’t nice. I’d almost gotten to the point that the effort put me off wanting to write and publish at all, and that’s not a good thing for someone trying to start a blog.

In contrast, Hugo is a simple, batteries included approach. The generation is a trivial command and everything just works. The standard templating is nice, easy to use and pretty powerful, without me needing to figure out plugins and extensions to make it nicer. Overall, it just works and I now don’t have to think about the technical aspects (JavaScript or Go) underlying the site to be able to write blog posts or even really edit themes.

And, importantly, any updates are a simple brew update away. A little better than JavaScript’s immature package management.

Docs: They better. They supa dupa better. They’re not perfect as they’re a little hard to search through, but they are definitely a helluva lot more comprehensive than Hexo’s. And on top of that the community seems a lot more active as, so far, finding solutions to my theming problems (which admittedly were mostly PEBKAC) was pretty straightforward.

All of the batteries: This is a clear improvement over Hexo. Even simple things like making a decent sitemap.xml with my site structure work in hexo was annoying. Hugo has everything just working great out of the box. It handles all the little things I didn’t even think about, like tagging and rss feeds really well with, so far, no rough edges. Also, as it’s baked on top of Golang’s templating language (which seems pretty decent so far), it handles escaping/different types of outputting really nicely.

The meh:

No ‘st’, ’nd’, ‘rd’ or ’th’ for date outputting. Why? This is an annoying little missing feature that I hope they add sooner than later (I’m trying to avoid figuring out an extension for this, but maybe it would be fun Go practice). There’s a workaround that I only just found when writing this, but it’s less than perfect and I need something to put here 😝
Asset pipelines/image generation seem a little lackluster and unclear. I would love some sensible defaults to help me think a lot less about images I’m using in my blog (especially headers etc). A simple more/less quality option would be grand.
… yeah that’s all I got so far. It’s pretty rad…

The not-technically-relevant-but-changing-made-me-rethink-my-approach thing:

Deployment: As titled, this isn’t really relevant to which tool you’re using to generate your static site. But, the act of changing how I generated mine (along with probably some recent workplace devops adventures) lead me to rethink how I was deploying. You see, previously I was lazy. I would deploy the site by pulling the code from Git onto an EC2 instance. This was great in theory, as it meant that I could just checkout the source someone and then run a make script to generate the public output. But it was annoying, because everytime I wanted to publish content, I had to push it, then shell into my machine and pull/regenerate. As time dragged on and server migrations occurred, this became pretty frustrating.

My solution? Rsync & other ancient unix commands! I was browsing Hugo’s docs and came across this pretty simplistic approach to getting my posts & theme changes deployed. I’ve even started making nginx changes by pushing them from my machine over ssh too. This probably isn’t the most repeatable manner when I change servers, and I haven’t yet had to figure out setting the server config up from scratch, but so far I think it’s a winner. Even if the setup is a little turns out to be a little bit more effort (though I doubt it in all honesty), I deploy changes orders of magnitude more frequently than I migrate servers/setup sites. The trade off is most definitely worth it as deploying is so easy now 😆

Things I want to try out next

Hugo Pipes: I want to figure out a way to get all my assets generated in a nice hugo-y fashion. Sass -> CSS and JS minification would be nice, but I think the main time-win here would be the image compression. Going from full-fidelity image to web-perfect at the run of a build would be perfect.
Comments: I don’t know if this is a terrible idea, or just a redundant one (I have like zero traffic so not sure if anyone will ever use them), but I do think it would be a fun project to implement. I’m not sure if this will be something I build myself, or a service/library I use/host, but we’ll see.

Conclusion

More updates are definitely to come as I use the setup more, but I don’t think I’ll be going back any time soon (or looking for another generator for that matter). This (along with probably other more real-life-related things) has made writing blog posts seem fun and exciting again so, hopefully I can rave about some fun expansions to this site that I’ve made in upcoming posts 😁

Delivery Driven Developers

Sun, 22 Sep 2019 00:00:00 +0000

* Don’t worry, this isn’t another job title you’re going to have to add to your CV this year

One thing that I’ve come to notice of late is that I’m a little different to a lot of developers that I meet. Many developers, seem to have a penchant for wanting to write code for the sake of writing code. To optimise, to agonise over, and ultimately to perfect the very specific piece of code that they’re working on, regardless of the bigger picture of the project. An old colleague of mine once described the in-depth discussion about low-value optimisations as “intellectual masturbation”, and I think the phrase suits this kind of thing well. I’m regularly surprised by the eagerness of developers to dive into these rabbit holes, while being oblivious (or maybe just uncaring) of how little value they hold. I just don’t get it.

Admittedly, I’m not entirely devoid of a love of the “craft” of writing code. I do feel the joy of a really well optimised algorithm (jesus that sounds nerdy, even to me). I do find myself grinning at the end of working on a story, when I’ve refactored a bunch of the smells out of the code I’ve just written and halved its size and complexity. But, what really drives me is delivering changes into environments. To me, there’s no point in all the hard work and effort to make it “more perfect”, if it isn’t getting shipped. I could forgo all of the really stereotypical ego-phalating parts of developer life (time-complexity anyone?) if I got to slowly but steadily make the codebase better whilst delivering new features and functionality to it.

I’m not even that fussed about what the functionality is in all honesty. Most of the time it’s more the feeling of accomplishment that comes from getting work done and shipped. What I can’t stand, however, is writing code for the sake of writing code. It’s probably why I struggle so much finding a side project that I actually want to start. I need to have a reason to develop software. Software, in and of itself, isn’t reason enough.

I like to think that it’s a truly altruistic trait. The idea being that I want to do good things. To provide those good things to others and get all the “helping other people” good feels that you get from that. There’s definitely a bit of that maybe (along with the selfish power-trip side of things), but realistically there’s a large part that’s just plain boredom. You see, the thing I’ve come to realise is that maybe it’s not just that I’m a business-orientated developer. One who cares about the overall functionality/completeness of the product I’m building and is happy to sacrifice the minutiae of the craft for the greater good. Maybe it’s that I just get bored easily. After a while of working on the same story, i just want to get it shipped and move on to the next, and maybe I just hit sooner than others.

Another thought that springs to mind, as it often seems to these days, is that this reflects the now age old “agile vs waterfall” conundrum. In this instance, it’s “make the code perfect” vs “get it shipped and make it better later”. The common refrain I hear is “oooh but we’ll never DO it later and it’ll always be CRAPPY”. Well, to that I say “GOOD!”. If we don’t get back to making it better, that means that it wasn’t worth the effort. Or that, more importantly, there are way more important things that are worth the effort. In this case, I’m bloody glad we didn’t waste our time to make your algo use that little bit less memory when it’s parsing. Instead we shipped a new feature, wahoo!

On balance, I think it’s important to remember to pinch a little bit from each camp. Constant rushing without good code leads to getting slowed down later with tech debt. Constant perfectionism leads to no traction at all and thus, no value. For me, I’ll always be a bit more of a delivery focussed developer and that’s alright with me.

Should I go static? An argument for switching to a static site generator.

Sun, 17 Mar 2019 17:20:17 +0000

I’m planning to write a little guide on how you can host a static site effectively, but it got me thinking that first I might wanna write about WHY you’d want to use a static site in the first place. Here goes!

So, why bother with static? Isn’t WordPress amazeballs?

SURE it is, half the internet runs on it, but that doesn’t mean it’s the best option for a lot of blogging use-cases. A few reasons I think that WordPress is usually overkill for blogging:

It requires a database. This means you need to start caring about database backups (you don’t wanna lose all your content one day do you?), which means either paying for automated tools to do this, or figuring it out yourself. And sure, there are fully managed WordPress services these days, but this leads to both more expense, lock-in and less flexibility.
It requires more computing power (both RAM & CPU). Whilst most micro virtual private servers (VPSs) can handle WordPress to some extent, it’s unlikely to be super-performant on the smallest servers.
Which leads into scaling: Making your site able to handle a large number of page-views is going to be a LOT more expensive with a dynamic solution like WordPress than a static one. Realistically you’re going to start thinking about how you can cache things which also ends up leading to a more complex setup.
Security: a simple Nginx install that only serves flat HTML is orders of magnitude more secure than a dynamic program that does lots of complicated stuff with user input (WordPress has historically had issues in this areas, but this applies to any dynamic application to be honest). Heck, you could even put the files on something dumb like S3 and host it from there. This way the security of your site is essentially as secure as your hosting platform (and things like AWS are pretty good at security these days).
Maintenance: If you’re running on a VPS, you’ll still need to think about OS upgrades, but gone are the language/library upgrade issues (like upgrading to the new version of PHP that breaks your theme). Much simpler to keep things technically healthy.
Site speed: both in the time it takes to get all your content to your users, as well as the time it takes their browser to churn it into what they see. Static sites will respond with their content way faster than dynamic ones, and the normal plugin-generated WordPress solution is usually WAY more bloated than a simpler purpose-crafted approach *.

But I don’t care about any of that stuff, and WordPress seems easier.

So, WordPress is definitely easier to get setup. But as I just explained, it’s definitely not easier to operate. Also, is it better for your readers? They’re likely far more interested in a pleasant and fast reading experience than waiting for your slow-as-hell blog to load. If you’re interested in having happy readers who want to come back, then you really want to care about the experience they’re having on your blog.

This is one reason I think static sites are better for readers. But I also think they’re better for writers.

I mean what is blogging all about? As I see it, it’s writing content (probably quite a lot of it relatively often) for easy consumption by a large number of people.

Writing your words in a WYSIWYG editor in your web-browser is easy to get started with, but it often becomes frustrating in no time at all, especially if you’re doing a lot of it. Think about some of the things that anyone who has written web-content via their browser has had to suffer through:

Because browsers now use a millionty gigabytes of RAM, it randomly crashes out when swithing between tabs, losing all the words you wrote since you last saved.
The weird characters that you just copy/pasted in from word (where you probably do the real writing because you don’t trust chrome) look super weird once you’ve published it, but you can’t figure out how to make them normal in the WYSIWYG.
That link that you’re trying to add ended up being an underlined space character but it was fine before you published it and now you don’t know why.
You have time to kill on the commute and you’re trying to write a post on the trian. And it looks like it’s worked, but your connection just dropped when you hit publish and, once more, you end up having to re-write half of it.

These are some of the problems that markdown-based static-sites solve. You can write it with a phone app, an app on your laptop or just with a plain text editor on your machine. It’s simple, it’s clear, it’s offline. And, as the normal approach is to stick your static-site content in a version-control system like Git, then it’s also rock-solidly backed up. You’re not going to lose it to some weird hosting error that happened one sunday night because the provider you chose for cheapness (because performance issues remember) decided losing your database wasn’t a big deal when they updated something.

After moving to a MarkDown-based writing setup a while back, I find it a million times more writer-friendly than CMS WYSIWYGs. And the upside of this is that a good writing experience is likely to lead to you writing more. Which means more blog content. Can’t be bad right?

Ok, so I’m keen, I think a static site makes sense but why do I need a static-site generator?

Static sites CAN be as simple as some html/javascript/css that you modify manually and stick in some hosting somewhere. I mean we did it that way in the 90’s and nothing went wrong right? And if your site is something super-simple like a portfolio with 1 or 2 pages then this is very likely the right way to go.

However, if you’re aiming for something like a blog with quite a bit of content, then it’s going to start getting very tedious very quickly. You need to edit all your content in HTML for a start. This’ll make it hard to migrate in the future as well as being far more laborious than normal text or markdown. You’re also going to need to think of something like server-side includes to be able to reuse bits of HTML like headers, footers, sidebars etc. And every time you add a new post you need to remember all the places it needs to go: index page, any sort of blog-roll, category pages, sitemaps, and the list goes on.

When you think about it, the ball-ache involved is going to get you quickly looking into how you can automate all these annoyances. This automation is exactly what static-site generators are for. Problem solved :D

Caveats

* This doesn’t mean that ALL static sites are better than ALL WordPress sites, or even that a WordPress site can’t be configured to be almost as performant as a static-site alternative. I’m just pointing out the average output of both these two tools, and it’s generally a LOT easier to get instant performance out of a static site than it is a WordPress one.

The "Don't be a Dick" code

Tue, 06 Nov 2018 21:17:29 +0000

After reading the recent reporting on the SQLite code of conduct I thought it might be fun to take a punt at a code of conduct based around the “Don’t be a Dick” philosophy. Should be fun!

Note: I’m just doing this for fun. No real human should consider this a sensible contribution to the CoC-making world. It’s just a nice thought-experiment.

Summary

Sometimes people take things too seriously. Codes of conduct are just one potential example of where a group or business can “over formalise” their culture. Sometimes it might be really important to have a solid CoC, but sometimes something flexible and more ad-hoc might work way better. Do what works for you. Similar to the Agile Manifesto, a working but undocumented process is better than an out-of-sync documented one.

One suggestion if you want to keep it MVP: trying something informal like this first to see if it fixes whatever problem has caused you to think of giving it a go in the first place. And if it doesn’t keep formalising it until it does.

First of all. The code should have one, and only one, rule.

Don’t be a Dick*

It’s the golden rule, and all discussion and arbitration of incidents should always be derived from it. Behaviour is considered to be contradicting the code of conduct if (and only if) “the group” considers it to be “dickish”.

Documented examples: Whilst these shouldn’t just mirror different types of rules (because then you’re just doing a normal CoC), they should be clear and real-world examples of some things that are considered dickish/non-dickish behaviour. The key here is to have some clear lines drawn in examples that people can then extrapolate from.

Some (admittedly silly) examples:

Flagging issues & problems with peoples code is totally non-dickish behaviour. It’s the best way to learn from mistakes, just be sure to do it in a non-dickish way.
Deploying to production and then clocking off for the day is 100% dickish behaviour. Don’t leave your potential mess for your teammates to pick up for you.
If after-work drinks are occurring, all teammates have an open invite. You don’t need to go and specifically invite everyone, it’s a given, but it is dickish to make them feel unwelcome to join in.

Regular retrospectives: No sensible process survives without retrospectives. Groups change, circumstances change & environments change. This means that what your group considers to be ok and not ok will also change and evolve over time (especially if the group size grows). Pick a frequency that’s right for the group and see how it goes. If you need to do it more or less then change the frequency.

Don’t be a dick about people being a dick: Despite all the steps in the process, it’s inevitable that someone will break the rule. The important thing is (just like any fuck-up) to not blame the person, blame the process. Unless the person is truly a dick (in which case kick them out of the group sharpish), the likelihood is that you didn’t retrospect/document well enough or often enough, meaning that some or all of your group are getting their dick-o-meters out of sync.

Make sure to discuss it initially. Run a postmortem to work out how and why you got out of sync, and get a consensus from the group on any details needed to prevent the dickishness from reoccurring. Treat it as a learning opportunity, then move on and don’t dwell on it. Any mocking of the dick-ee should be light-hearted and last no longer than a week.

Have a laugh about it: The main benefit of being so foul-mouthed with the process is that it’ll encourage discourse in your group and bring peoples’ guard down so that they’re more likely to discuss it openly. Proper discussion between peers about what could be really difficult issues is only ever a good thing. As such, if your group aren’t smiling and coming up with some silly examples of dickheadery then you’re probably doing it wrong.

Large groups will never agree, which means that you’ll never come to a consensus with any practical level of efficiency (just look at every political system ever :P). It’s likely that this will pan out at “tribe”-limits, so, depending on how homogenous the characters in your group are you’re looking at anywhere from 80-120 members max.

What the group considers to be dickish WILL change. Even if a group agrees now, all groups change over time (even if the members stay the same their environment definitely doesn’t). The “consensus” will need updating fairly regularly, and my guess is that frequency will increase exponentially with group size.

Laws and the real world: I really do think that this kind of code of conduct can be a good way for smaller groups to get the benefits of a CoC, without having to write a bunch of overly-verbose semi-legal waffle that’ll often get ignored. I also suspect that people like lawyers, employment tribunals, media organisations, funding groups and potential business partners are all very likely to disagree. Standard reminder that this is not advice, I am not a lawyer & these are just my thoughts on a fun thing to try.

* I’ve chosen “dick” because I think it’s funny. You can replace it with any mildly offensive word that you want. It just has to be mildly offensive. Because it’s funny.

Reboot all the Things

Mon, 29 Oct 2018 21:00:00 +0000

Nothing is new, everything is rebooted, cloned, redone, reimagined and generally rehashed a million billion times until we stop noticing that it’s more of the same twaddle. Unfortunately, I quite like this domain so I figure that I’ll just stick with it now that I’m giving blogging another go :D

After my last jaunt traveling I kind of lost the drive to write any words. As an update, I got back from my euro-jaunt towards the end of 2017 and ended up re-settling in the UK again. I’ve been back here for a little over a year now and by Jove do I have itchy feet. As such, I’m off again! In a few weeks, my wife and I fly to Singapore. I’ll be starting a new job as a Senior Dev by the end of November and hopefully settling in to be a long-term resident.

In all honesty… I’m bloody terrified.

One thing that I did gain from the past year or so is that (I think) I know myself a bit better than I used to. I’ve learned is that I’m definitely not a natural traveler. I’m not an explorer. James T. Kirk would be appalled at my adventure-introversion. Picard… well I’m sure we can guess his thoughts on the matter.

But I think I’ve come to accept this about myself. It’s maybe ok that I’m not like all the drop-shipping, full-moon-partying nomads on Reddit, that can teach you the best way to travel if only you’ll like and subscribe using the links below. As long as my slightly-less-galavanty version of globetrotting makes me happy, then gosh fuck it that’s what I’ll bloody well do.

Anywho, this was rather a roundabout way of declaring this blog re-open. The theme won’t change: nerdiness, travel & some code, but I might focus a little more on Singapore and expatting for a little while.

That or “what to do when you get fired on your first day at a new job and are about to get thrown out of the country”.

Wish me luck!

Growth the fuck up

Sat, 05 Aug 2017 18:00:00 +0000

I recently read a “self-help” book entitled “Mindset: How You Can Fulfil Your Potential” - and trust me, this isn’t the kind of wanky bollocks that I’m normally keen on. If it lacks mages, spaceships or nerd humour I’m usually not interested but, on this instance a few factors came into play that made me give it a go (and, spoiler alert, it’s pretty damn good, so I’m glad that I did!).

The first motivator (and probably the biggest) was that it was given to me by Hotjar’s CEO at their recent Marbella company retreat. David was keen for us all to give it a read and I rate him as a pretty clever chap so I figured I’d give it a go. This got me through the first chapter. This first chapter isn’t great. It reads a lot like “How to win friends and influence people”, a self-aggrandisement of why you should read the rest of the book, ramming down your throat the authors credentials (ok, it’s nowhere near that bad, but I think it’s safe to say that this kind of thing puts me off).

Based on that, I probably wouldn’t have continued reading but, lucky for me, I was stuck on the plane back from said jaunt in the mediterranean so, on I delved into the next few chapters, and then the few after that. By the time I landed back in Blighty I was about a 3rd of the way through. My initial, pretty critical thoughts, were quashed and I was convinced. This was a good book. But now you’ve heard about how keen I am, here’s some more about the book itself. It’s premise is essentially, no brilliant person is really born brilliant. Sure, some have more innate talent than others, and that sure helps at becoming the best artist, scientist, musician. But really, the only true greats, or the majority at least are only there because of all the hard work that they’ve put into it on the way.

And, probably more importantly, the people who are more successful are those who believed they could get better. This is the key premise, that there are 2 “mindsets”. The first, a fixed mindset where you assume you are as good as you are every going to be at things. Your talents are final and you’ll either be better than someone or worse and there’s little you can do to change that. The other mindset is the growth mindset. These guys think that their skills & intelligence aren’t limited. That with hard work and perseverance they can get better in the things they work at. The most surprising thing is that, even if these 2 people start off at exactly the same level of innate talent and ability, the one with the growth mindset will nearly always end up further/better/more successful than the fixed mindset guy.

Personally, this was kind of a revelation to me. The person the book describes as the static mindset is/was me. I was the clever kid in school that didn’t really have to try hard to succeed (at first). I was the kid who was praised for being the talented top-of-the-class nerd and I was then the kid who eventually got too scared to try. Definitely the kid who didn’t want to try at something that he might fail at, so when he inevitably met other people who were better than him (usually because of all their hard work) he thought well, what’s the point? They’re better than me, and if I’m not the best person in the room when I try it I’ll just fail and look stupid, so why bother?

Don’t get me wrong. I was also lazy. I preferred video games (there I tended to always be pretty awesome cause of all my practice :P) and I preferred drinking and smoking and generally achieving little. But as I look back on it, I definitely see a lot of the roots of my “laziness” in fear and ascertaining the dopamine rush of achievement from doing well, not from becoming better. I think this is key to any thoughts of “self-improvement” and (thank fuck!) something I got to later on in life. Nowadays, I love learning. I love getting better at things, and oddly, I really like helping other people get better too (sometimes even better than me). This kind-of-humility is hard, sometimes I struggle. Sometimes I have to force myself to ignore the fixed-mindset-demon in my head that gets his back up when someone critiques my work. But I do. I manage it, usually without much wasted time along the way. And because of that, I’ve gotten a lot better at a lot of things. I do a job I love at a place I consider to be at the top of my field. I work with super-talented people who I learn from all the time. I have a happy life with a lovely wife and we have a relationship that we work at daily, which makes it super-bloody-awesome.

None of these things have been easy. But they’re worth it.

So in all, this book didn’t really teach me to BE a growth mindset person. I’d already kind of figured that out. But this does help me name it, help me teach others about it and, importantly for me, it helps to remind myself every day, when I slip back into a fixed mindset from time to time, to steer back on course. Another added benefit I got from the book is that mindsets have categories. I’ve got a pretty growth mindset about coding and work and my relationship, but I’m still pretty fixed about art and music. I don’t think I have that aptitude and I now know that if I don’t think it’s possible, then it never will be. Maybe I should spend some time getting better at these things. Learning, working and forcing myself to grow in these directions. I strongly suspect I’d be a happier, healthier and more rounded person if I did so it’s something I plan to give a try.

Anyways, go buy the book, read the book and then do the things the book tells you to do. Trust me, it helps and you’ll be glad you did it. Oh and, once you’ve read the book a few times and you’ve got the concepts to work on down, go give the book to someone else. Maybe someone you think might really benefit from it. I figure helping people is good self-medication too.

7* Reasons Facebook is social cancer

Sun, 09 Jul 2017 21:58:37 +0000

Note: there’s a lot of swearing in this post. Please add all of your complaints onto the first unrelated youtube video you can find - preferably something SJWy so you get the best trolls.

I’ve finally gone and done it. That unconscionable, ruthless and nonsensical act tantamount to modern social suicide. I’ve deleted my Facebook account, and I do feel rather vitriolic about it :D.

Backstory: Many moons back I avoided it like the plague but a pretty girl (my now wife) convinced me otherwise and for some time since having a Facebook account make sense to me. It kept me in touch with people I’d otherwise lose touch with and it gave me a good place to keep and share my pictures of things like this little self-indulgent life-journey I’m on. But recently, I’ve realised: that’s all complete and utter bollocks. So, I’ve gone ahead and deleted my Facebook account :D

Side Note: I’ve had a range of reactions to this so far and I find the fact that anyone actually cares either way to be actually quite interesting, hence the rant.

Here is why:

White noise

My first facebook-is-bullshit inkling was the realisation: how many real friendships can one person foster? I simply don’t have the time or the ability to maintain a few hundred friendships, that’s ridiculous. And if the argument is “well Facebook friends are really just acquaintances, you don’t really act like they’re friends do you?”, then why the fuck do I want to know all the in’s and outs of these random fucking peoples lives? Just because we went to the same school or worked together for a few months in our first job? It feels like I know more about these chum(p)s than I do about the people I really should be spending my time focusing on. I know when they’ve gotten new jobs and how that tubby chap I care not-very-much about has managed to waddle his way to the end of a charity fun run. It’s info I don’t need and certainly don’t want at a volume that I simply can’t digest.

Keeping in touch

And, for the actual people I do want to maintain ties with, Facebook sucks balls when it comes to maintaining a real friendship with these peeps. I’ve already read about their random lifetime achievements via their Facebook status so when it comes time to actually fucking talking to them, they’re telling me stuff I already knew. This means that conversations with people I’m supposed to care about bore me, as it’s now old news and getting through these chats is a repetitive chore that I have to sit through in the hopes of hearing something they didn’t put on their interweb feed.

I’d posit that Facebook is actually a detriment to real friendships. It stops you talking to people, and I’ve started to think that being forced to speak to people, being forced to ask them about their lives, to form words that show caring and wanting to know about them is a part of forming that bond as well. They say that if you smile it makes you happy, because of the muscles in your face or something. Well maybe if you ask someone how they are and have an honest discourse about it, it’ll help you to care about them that little bit more too?

Getting out of the closet…. no not like that

I guess this all kinda relates to the societal “bubble” issue we’re having of late and I think it kind of proves** how human social interactions need to be more complex than whatever Facebook’s news feed algorithms decide to tell you on the 32nd time you checked it today. We can’t and shouldn’t limit ourselves to the persona-buckets that it attempts to cram us into to fit its data/business-models and the more social communication we put through these heavily sorted channels the worse the problem is going to get.

Isn’t he cuuuuute

And as for the photo-sharing thing, no-one really cares about your holiday/nomad/graduation/wedding/baby pictures, it’s just self-aggrandising. And if you still want to, go use one of the million better platforms to do it with all the other food-picture-wankers out there :D

</endrant>

Anyways, back to normal scheduling next week***, I just felt like this little revelation I’d had was worth a ramble. There are many more eloquent and noble views on how naff Facebook is and how it’s fucking the internet. For info on that maybe try your internet search engine of choice. Hell, getting out of Facebook’s closed-internet hell-hole would probably be a good thing :P.

* I may not be able/care to count… got you to click though eh? :P

** Not actual proof in any way, I’m most likely waffling shit.

*** Take that as whenever I get round to it :D.

Silence is golden; screaming children are hell

Thu, 27 Apr 2017 21:30:00 +0000

Picked up a pair of noise cancelling headphones recently and life now contains significantly less of the mind-numbing drivel that I’m usually forced to put up with than it did before. Here’s some reasons why they’re a perfect fit for remote working & location independence.

I guess the location that I’m writing this post in is perhaps influencing the amount of vitriol it contains. I’m in Barcelona airport after a short flight from Lagos and I can’t remember getting off a flight as chilled out as I feel right now (admittedly I’m halfway through a beer so that might help).

The headphones in question are Bose’s QuietComfort 20’s:

First, the reasons that these headphones helped with my current state of chill (I think I’ll rate these with chill-factor from now on):

They cancel noise! Not all the noise, obviously, but a significant amount and, when listening to music, enough to get you past even the noisiest of environments like flights, buses, streets etc.
The music in my ears sounds good. There’s a teensie bit of background hiss from the noise-cancelling but you can’t hear it at all when music is playing and barely otherwise. And no, in case you haven’t guessed I’m not an “audiowanker”*, but i do like music that sounds not-shit. This music sounds not-shit. In fact it sounds pretty damn well good: good bass for in-ears and the sound quality is more than a match for my old bose over-ears. Which leads me to my next point.
They’re in-ears! This makes them a butt-load easier to cart around in said plane-like environs and just for general wombling around. I’m not sure how comfy the “control-switch dangly bit”™ would be when exercising (and I’ll likely never know tubs), but for general plodding around town it’s perfectly fine. And not once have the buds felt anything other than suction-cupped into my ear-holes like the worms from The Faculty. It’s awesome. Begone over-ear head-sweat! #oversharer

So, in summary, they are good headphones. I’d go as far as to say that they’re great headphones and, with built in microphone it makes the need for carrying a headset pretty redundant, meaning they’re ideal headphones for nomad-life. I use them daily for calls, travelling, coding and just about every moment of my life that I can in order to block out the monotony of others. Two thumbs up! 👍👍

The Algarve, Portugal

Sat, 08 Apr 2017 12:30:00 +0000

So it turns out that the south of Portugal has beautiful coastlines, countryside, fishes, wine, sun, waves and even a nice southerly breeze. I’d ask you not to tell anyone but I think the cat’s already out of the bag… fuckers.

Well, I assume it is, otherwise why would there be so many “bloody foreigners” here? I use the phrase jovially but that was genuinely out of the mouth of some expat here when referring to all the tourists. Mad eh. (I think he voted UKIP…)

Anyways, in case you’ve missed the hint, the Algarve is Portugal’s worst-kept secret. It has all the requisite features to make hanging out with a beer outdoors an excellent experience, which is both excellent and dangerous as a place to work remotely from. I spent a month in Lagos, an expat/tourist-filled pretty little port town. I imagine it’s hell here in August but off-season it’s quiet enough to never worry about how busy a restaurant/bar is, the beach is empty, the tours are quiet and the sun is hot, but not that flay-your-skin kind of hot. There was admittedly a bit of rain for a few days, but meh, I barely noticed it in-between all the glorious sunshine.

Most of my time in Lagos was spent working or pootling around the town itself, and that’s not bad. Got 5 week’s of apartment* for ~900 Euro’s (by no means a huge place but the fiber was sweet and it had a cosy & quiet vibe) which was perfect for what I needed it for. The town is “Okay”. It’s very touristey and, no offence peeps, but the expats here are either 80 or that slightly-too-into-an-odd-combo-of-weed-and-buddhism side of hippy that makes for dreary and awkward pub-conversations. The restaurants and bars are decent. The food is worse than Lisbon but better than other places and the views are marina-filled and nice. All in all it’s average.

But enough about the town, its brilliance comes from its ‘base’-ability (I should totes trademark that). For the first few weeks I didn’t get it. I stayed local. But then a buddy visited for a week and he hired a convertible**. Turns out the rest of the Algarve is excellent. It’s pretty sparsely laid out, there are beautiful coves, endless cliffs to walk along the top of, bits that are ace to wander up with a little bit of fear that the tide might not let you get down. Even the touristey lobster traps (get it, because they’re sun-burnt pink? … like lobsters? 😛) such as Sagres and Benagil are super-awesome.

But, if an endless sea-scape isn’t your thing, the hills and forestey bits around here are superb. As a proud British northerner I tend to warble on about the brilliance of the North of England’s countryside (we got moors for days bruv). But today I know that we’ll never win when compared to the Algarve. Driving around the area on empty roads, singing terribly to 90’s britpop and soaking in the sights makes it impossible to keep up my usual grumpy frown. It’s like a sunny, better version of home.

So to summarise, I’m giving the Algarve a score of 347***

Pros:

Natural Coastal Beauty.
Natural Non-Coastal Beauty.
Some good historic-y tourist traps.
Decent monthly-airbnb deals, especially if you avoid the peak seasons.
Sun, Surf & Wine****

Cons:

Fucktons of expats, either old-as-fuck or hippy-as-fuck.
Food is mostly meh due to tourists.
A Kayak bashed into my arm leaving a really big bruise which is something that could definitely happen to you too and so counts as a con…. fuck kayaks.

* Yes that’s my airbnb link, what of it? 😛

** It wasn’t quite a big red shark but DAMN is it a fun way to get around a sunny country :D

*** Scoring method yet to be decided.

**** Seriously, I get the occasional Sangria but for more regular drinkings why not just stick to wine?

Lisbon, Portugal: First port of call

Thu, 16 Mar 2017 13:00:00 +0000

Lisbon seems to be the western-european mecca for digital nomads at the minute so, to avoid using any brain-power whatsoever, we made it our first stop. It was a good choice.

We left Lisbon the weekend before last after a month there and I’ve finally gotten around to summing up my thoughts. I think the most surprising thing about it is that it felt so comfortable after such a short period of time, like a pair of comfy old shoes. The people are friendly, the food is plain but fresh & delicious and the weather, for February, is a damn sight prettier than back home.

I’ll admit, none of the above sounds like high praise, but Lisbon gives me the impression that it probably doesn’t give a shit. That’s not to say that Lisbon isn’t worthy of high praise though. Far from it; from the Hipster-cool of LX Factory, to the great drinking & eating around Cais do Sodré to the Basilica de Estrella - Lisbon really has some excellent bits. But I found that while the “bits”, the neighbourhoods spread out and nestled in the bosom of Lisbon’s many hills, are excellent, the part I loved was the in-between.

I’m definitely a fan of walking cities and Lisbon had me at hello on that point. On my first day in the city I was wandering down alleys (always down or up Lisbon’s never-flat streets, never along), bumbling through gardens and coming across some of the most excellent of vistas. I think Lisbon mirrors San Francisco a lot (though probably the other way around) and not just with the bridge thing. It has it’s different areas, it has ridiculously steep hills and definitely has the beautiful watery vistas, but it exceeds it in the ability to spend the day following your feet from neighbourhood to neighbourhood drinking in the sites and getting to know the feel of the city. Drinking the excellent wine too, but then that’s a bit of a given.

And neighbourhood isn’t a term to describe a set of blocks, or rough geographical approximation. These are actual neighbourhoods. Locals heading down to their local bakery for a coffee, a snack and a loaf of bread for the day. Family-run restaurants where regulars know they’re getting far tastier food for half the price as long as they don’t mind putting up with a little less fancy of an affair.

In retrospect, i think this is why I came to grips with Lisbon so quickly, or at least I think I did. Each part of the city wears its heart on its sleeve and the character of the place shines through as soon as you plod past it (have I mentioned all the walking, the comfy shoe thing is kinda relevant now huh 😊). So even if parts are a bit touristy (though thankfully I missed most of that in Feb), the feeling is overwhelmingly that of a thoroughly lived in and loved city, that knows and understands the rest of the world, but is pretty happy sticking to the way the Portuguese do things.

I’m pretty happy with that too I find. The food, the wine and the friendliness really make it.

A Place Called Home

Tue, 07 Mar 2017 22:30:00 +0000

One of the initial justifications for this international jaunt upon which I find myself was the goal of finding a new forever home. A new place I can refer to myself as “being from” and somewhere that was empirically better than where I’d been before.

I tend to prefer innovation via trial-and-error in my professional life so surely the concept would fit perfectly well when choosing where to eek out the rest of my years right?

At a month in, I think I was, as per usual, rather naive. That’s not to say that I was wrong though. I do think that this will be a damn good way to figure out the place, and probably more importantly the kind of place, that makes me more happy. But I definitely don’t think it’s anywhere near as black and white as I thought it was. A lot of this isn’t about finding happiness in a place, or maximising the number of daylight hours or minimising living cost while maximising lifestyle. I think really the trick is to use the fun new experiences, events and memories to help inform the kind of person I want to be and the lifestyle I want to have. I think in that way the travelling is useful twofold: not only do I learn by having new experiences but it gives me an understanding of what different parts of the world are like, and seeing how they’ll fit in with & support what is going to make me a happier person.

Now I realise, that this may sounds pretty fucking obvious to most. But I really did start out on this trip thinking that it was a simple case of investigating the pros and cons, recording the HP, MP & DEX of all the places I go to and using it all to work out the best of the top trump city cards to play for the next 50 years before I die. Thinking about it now, that sounds bloody morbid doesn’t it?

So, I ’m going to crack on with mooching around the globe, seeing what bits of life keep the smiley face the right way round and hopefully figuring out a bit more about what makes me tick.

Heh, shit, maybe I just need a hobby? :D

Hello World!

Wed, 15 Feb 2017 12:00:00 +0000

Here begins my blog. I’ve contemplated starting one of these for several years now but, like many things, I’ve only just gotten around to actually doing it.

As an introduction to me: I’m a British nerd from the internet, wot travels a bit. As such, a lot of the things I write about will be nerdy, internety or experiences from the things I come across on my travels (more about me).

This blog is all about giving a more geeky/developerey/introverted viewpoint on the world of remote-working whilst travelling the world (digital nomadism if you’re not afraid of labels). I’ll try and be useful where I can and, where I can’t, I’ll at least try and keep it interesting.

Anywho, that’s hello for now. If you have any thoughts, requests or suggestions then hit me up on twitter and hope this lil blog o’ mine can be of some use.

Happy Trails!

- Jason

About

Mon, 01 Jan 0001 00:00:00 +0000

I’m Jason Kelly, a Software Developer from the wonderfully rainy city of Manchester, England. After far too long under the oppressive British gloom I’ve decided it’s time for a change and I’m using my freedom as a remote-worker to explore the world. As you probably assumed from “Software Developer”, I’m a pretty nerdy and introverted kinda guy but I’m using the excuse of worldwide travel to try and get as far out of my comfort zone as I can manage.

On this blog you’ll find… well I’m not 100% sure yet, but it’ll be part geek, part travel and hopefully a little bit interesting. If you have any hints, tips, konami codes, critiques or just down-right corrections then hit me up on twitter and, in the meantime, hope you enjoy the blog ☺ (I’ll try and keep the emoji use to a minimum, I promise).