People who've been following me for a while will know that a key feature of my site has always been the dynamically generated CV button on the homepage. It's made it through multiple itterations and I'd like to think I've gotten pretty good at building that sort of thing. Something I've been asked for years however, is if I'd be willing to licence that to others so that they can have a dynamic CV on their own site.
I could also have called this article "How to Speed Up Rust Compilation on Google Cloud Build" but that wasn't as fun. The setup for this article is quite straight forward. As apposed to previous projects of mine, I've been diving much deeper into Google Cloud Build recently. I've been building a collection of Rust Micro-Services that will be running on Cloud Run and as such I've been dealing with incredibly slow build times with some regularity. Rust notoriously concedes to extremely slow compilation time so as to achieve efficiency and safety at run time. As such, I've taken steps to decrease the build time as much as possible - because sitting there waiting for a build is not how I like to spend my evenings.
I've done a few blog posts about features that rely on Twitter built into this site, from Custom Twitter Embeds to WebMentions. Given the recent news of Twitter's API becoming paid (and from what I've seen it's not cheap), I'm likely going to have to rework this functionality in the near future. It's not a good situation for Twitter. It was always a favourite of developers due to the ease by which we could build on top of Twitter or into it and it seems that's now coming to an end.
Javascript and its derivatives are immensely flexible. I've used some variation of Javascript for pretty much every use case you can think of - desktop applications, mobile apps, APIs and entire backend processing systems. You can train a complete newbie on the basics incredibly quickly, and I love working with it. I've primarily been a Javascript developer my entire career and I started using typescript when I joined Pretty Little Thing back in 2020. I've been a big fan of the support that having a typed version of Javascript offers and you'll find almost all my blog posts use typescript in some capacity. Be that as it may, currently I find myself spending my weekends learning Rust.
I've long since wanted to add a mailing list to the blog as a way that people could directly show interest in what was being posted. I did however have the big provision that I didn't want to manually be creating emails to send out. I wanted to automate it. Off the back of my recent release process improvement I realised that I could finally start to build this feature.
One of the earliest articles I ever wrote was about the posting process that my blog posts followed. It used a local typescript script that accessed the mongoDB database and added/updated a blog post. It was simple and good enough for the features that the site had at that point. I've been using and expanding that posting process for a while now, but I find myself at a crossroads... OG Images are being generated and stored the first time they are accessed (which takes a while), My local machine is taking a good 20 or so seconds to run all the local release steps, and I find myself wanting to add new features such as a mailing list to announce new posts. I need to start running this on a server so that I can start running these steps in parallel. That does mean, however, that I'm going to have to rebuild the posting process from the ground up.
I write every one of my blog posts in Markdown. Markdown is easy to store, easy to edit and above all easy to implement. I, specifically, use a variation of Github Flavored Markdown with a few of my own additions that make my workflow easier - for example, I can use [tweet tweetIdHere] to embed a tweet in one of my posts. Github Flavored Markdown (GFM) is the most common Markdown Spec to see implemented around the internet, likely due to the fact it was developed by Github and is therfore open source. That being said, there are many features of GFM that I think more people should be using but aren't. You could say that I read the spec so that you don't have to.
It seems like simple daily web games, à la Wordle or Framed, have been quite popular over the pandemic. One could argue that interest began to wane as everything opened up again, but I still know many people who consistently log in to challenge themselves each day. My partner especially, loves these games - playing about 3 different ones without fail. I had an idea whilst this craze was going on for a similar daily game but one, unlike Wordle or Framed, which required you to log on the next day to see if you had guessed correctly. I decided I'd build it to see if I can get it added to my partner's daily schedule.
A while back I introduced likes to the blog through the use of Webmentions and Bridgy. I even went so far as to release my own library for handing Webmentions which I'm pleased to say I've been steadily working on ever since. On the other hand, this blog has been using Utterances to handle comments practically since I started it. Despite how happy I've been with Utterances, I've also been very aware of it's limitations as a comment platform. Not everyone has a GitHub account, and while this blog is primarily targeted at technical individuals, I want to decrease barriers to interaction for those who are possibly newer to the development scene.
For a long time now, I've been frustrated by how slow the official twitter embed is. Any page where I've embedded a tweet, becomes noticeably slower. The warnings on lighthouse are always the same - "Reduce the impact of third-party code". When broken down further, you can see that you spend on average 730ms exclusively on twitter javascript files. This is frankly unusable. However, there is a solution, albeit one that requires some effort.
Often times when I speak to developers who have just started writing typescript, they have begun to understand static typing. They understand that they can label a variable as type string and then rely on the fact that it will be a string within a function. There is however, another, rather large part of typescript that I don't see newer typescript devs use very often. Type Guards and their ability to branch code in the event a function takes multiple types are extreemly useful. So today, I'm going to explain Type Guards and why you should be using them.
