I decided some time ago that I ought to have a personal website. Like most of my personal projects though, there’s a bit of a delay between decision and implementation. I decided that the easiest thing to start with is a blog.
Why a blog? Well, I think of it as a potential extension of my CV. I work in the tech sector, so a blog seems like an ideal medium for creating a portfolio, where current and future employers can get a better understanding of my capabilities.
A blog also means I can write up the things I’m dabbling in at any point in time, and I don’t have to agonise over the most appropriate data structure for my website.
Lastly, it’s a learning opportunity for me. Building this site will provide me with an avenue for exploring new languages, tools and technologies that I don’t usually work with day-to-day. It should be fun.
So I want a blog…
I should start by saying that there are MUCH easier ways to build a website than the approach I’m going to be taking here. If you don’t spend your days fiddling with web technology (or maybe you do, but don’t want to be doing it in your spare time), you can go to SquareSpace or Wix or something like that, and they’ll take care of everything - getting a Domain, DNS records, hosting, certificates, user-friendly content management and creation - everything. This is not the approach I’ll be taking here.
First let’s start with some parameters/goals:
- Cost: I want to pay as little as possible in upkeep, without doing something dodgy.
- Control: I’m a control freak, and don’t want to have to wait for company X to implement some new technology before I can use it.
- Design: I’m not a designer, so I’ll want some help from themes and such in this area.
- Purpose: The whole point of this exercise is to learn new things, so I shouldn’t take the easy option every time.
…and a high-level summary of the steps involved:
- Buy a Domain Name
- Build the website
- Host it somewhere
- Make it discoverable
Buy a Domain Name
Domain Names turn a network address a computer can understand (like 172.217.25.46) into something a human can remember (like google.com). This all needs to be managed centrally so we can have confidence that google.com is actually pointing at a network address owned by Google. There are entire articles written about the governance of that process, but suffice to say:
- You’ll need to purchase (or more accurately - lease) a Domain Name.
- There are HEAPS of companies that sell them.
Choosing the vendor is a bit like choosing a make of car. There’s no right answer. There are some brands that might be best avoided, but you’ll also find advocates for that brand. It usually comes down to personal preference or personal circumstance.
My personal preference (as of Dec 2018) is to buy my Domains through AWS (Amazon Web Services). Their prices are fine, and I have a heap of other stuff in my AWS account, so it suits me to have it all in one place. That said I currently own 3 domains, and they are each with a different vendor: AWS, Namecheap and Hover.
My first domain is a .com, so I got it through AWS. My 2nd is a .tech which AWS didn’t have, so I went shopping around. I knew about Hover from a friend, but I think they didn’t have .tech at the time. I had also had Namecheap recommended to me by a friend, so that’s where I landed. Similar story with my 3rd (.fitness) domain, but I ended up with Hover that time.
Most people will want all their domains in one account for ease of management. It didn’t worry me too much. The only part of “managing” a domain you need to go to your original vendor for is renewal, as you can easily manage your DNS records elsewhere (more on that later).
Lastly - re: vendors to avoid. A year or two ago I heard a number of people reporting that they’d check the availability of a domain on GoDaddy, then go to buy it later, and the domain was now owned by GoDaddy. This meant they had to pay a significantly inflated price if they wanted it. It’s possible that this was just mud slinging, and I have no way to verify it, but it’s worth taking note that when you check the availability of a domain name, you’re essentially announcing an interest in buying a unique thing that can only be owned by one person at a time…so just be sure you trust the company you’re using for the search.
So yeah - I bought the domain for my website (cbax.tech) from Namecheap. Easy.
Build the website
I had planned to go into a fair level of detail here, but given my propensity for rambling, I’ll keep it high-level and put the detail in a separate post.
My decision on how to build it was initially driven by Cost - I didn’t want to be paying for a server; and Design - I wanted a lot of help with making it pretty.
I think it’s safe to say that the most common solution for a DIY website is WordPress. There are lots of reasons why I wouldn’t go with WordPress, but a couple stand out:
- It’s a PHP application, and I’ve developed a pathological dislike of PHP (disclaimer - I know it’s not fundamentally bad, and I may even dabble in it one day)
- It’s a PHP application, so it needs to run on a server to work.
The thing about servers is they cost money to run. You can get some really cheap services these days where the company puts your website on the same server as 100 other clients, so you pay a fraction of the cost…but you still pay for a server one way or another.
The much cheaper option, is to have a static website, and host that in a storage service (I’m talking about AWS S3, but I imagine there’s other vendors). I’ll go into more detail on this in the next section.
A static site just means that your website consists of a finite set of files that are sent to the browser accessing your website each time. The files can only be HTML, CSS and JavaScript files (along with supporting images and fonts), as the browser can understand them natively. These files aren’t dynamically generated by the server - hence, they are static. If I want to update my website, I have to replace these files, and serve up new versions of them in future.
I didn’t really want to write these files from scratch, so I want to find a generator that helps. Go and Google “Static Site Generator” and you’ll see that there is a ton of options.
Initially I decided I’d use Jekyll. It seems to be the most popular, and is written in Ruby - a language I have a passing familiarity with. I started getting up to speed with Jekyll, but then put the project on ice for a while…and when I came back to it I changed my mind and decided to go with Hugo.
I don’t have a good reason for this change of heart. I like the fact that Hugo is a Go application, and rightly or wrongly Go applications feel a bit more self-contained than a Ruby app. It’s probably just that I don’t see all the nuts and bolts…but Hugo is the way I went. I also don’t need to really understand the code here. It’s just a tool I will use.
The idea of Hugo - and indeed most static site generators - is that you write your content on your personal computer, then use the generator to build your static site, which you can then upload to wherever you need it. Each blog post will be written in Markdown, which Hugo will then translate into HTML for me. This could be an onerous process for some people, but it seems straight forward to me, and I know I’ll be able to automate the process as soon as I’m ready.
Host it somewhere
As I mentioned earlier, I’m using an S3 Website for my hosting solution. It’s a fairly straight-forward process:
- Create an AWS Account if you don’t have one. You’ll need a credit card, but due to the “free tier” they offer, you’re unlikely to pay anything for the first 12 months.
- Create an S3 bucket for the site. The convention is to use the domain name for the bucket name,
cbax.techin this instance, but as I’ll discuss in a future post, this isn’t essential. - [Optionally] create a CloudFront distribution.
CloudFront is AWS’s Content Delivery Network, which as the name implies, is a network of infrastructure designed to distribute digital content around the globe. Think of it as a heap of digital warehouses spread around the globe to rapidly deliver your website to whomever has requested it, as quickly as possible.
You can use S3 without CloudFront, but in this case you have to ensure your bucket follows the strict naming conventions.
Make it discoverable
The last step in this process is making it so my website can be found. This means creating DNS records for my Domain, so that when someone visits cbax.tech in their browser, the browser knows where to go to download the site files.
For me this meant setting up some DNS records in the AWS DNS service - Route53…but this is starting to get into the implementation detail which I’ll put into my next post.
Thanks for reading. Toodles!