Matthew Lang

Last month I mentioned my intention to look at BlitzJS. After a few hours of wrestling with a small application, I wondered if it would be better to spend some time refreshing my React knowledge first (it’s been a while since I used this) and then re-visiting BlitzJS. So I decided to park this for something else.

I wrote and maintained my own blogging CMS using Ruby on Rails for a couple of years. It was simple, and it had several excellent features like posts grouped by dates and supported posts without titles. There were a couple of downsides to the application, though.

Running even a small Rails application isn’t cheap, and while I can afford to host the app, it was money that I thought I could spend elsewhere. I looked to alternatives, but I couldn’t find anything with a significantly cheaper CMS to host. I started then to look towards a static site.

With some experience in using Jekyll, I started migrating all my posts both on the Rails application and in Micro.blog to my own Jekyll blog. I’m running the site on Render using one of their cheap static site plans, and I’m pleased with the result.

The added benefit of this is that I now have complete control over my blog, both in content and hosting. My content for the website is just a bunch of files. Posts use Markdown and are effectively just plain old text files. My images are stored in a folder that is served as part of the website. I find this much easier to control than digging into the database for a CMS.

As for hosting, I loved having my blog hosted on Micro.blog, but I did find it limiting in some ways. I would still recommend it for most people, but for me, self-hosting everything was the way to go.

One final benefit of using Jekyll is that I can still use Tailwind CSS to style the website and play about with it a bit more. You can see an example of this on my now page, where I have created a book component to show the progress of the books I am reading. I’ll be expanding on these over the year as I read more books.

It’s been a while since I made any changes with my writing prompt generator Writeabout, but it’s seen a flurry of activity over the last few weeks.

• Writeabout is now running on Rails 7 and Ruby 3.1. I’ve been keen to move away from Webpacker and embrace Rails’ new JavaScript options with Rails 7.
• I’m using the latest version of Tailwind. I love Tailwind. I find it easier to build web pages using Tailwind’s classes.
• I replaced the dark/light theme with a better recommendation using the suggestion from the Tailwind docs. This behaviour is still bundled in a Stimulus controller, but I’m pleased with the result.
• Self-hosted font. I used to use Google Fonts to serve this website’s font, but I’m keen to reduce outside dependencies where I can, so I switched to self-hosting the font for Writeabout.

I’m still not done with Writeabout, though. As a small application, it provides me with an excellent place to try new things. Over the rest of the year, I plan to add the following two significant changes.

The first is an admin screen built on Hotwire. I’ve done some things with Hotwire, but nothing major. It would let me manage the prompts for the website and provide some information on API requests.

The second change will be an iOS app using React Native. Yes, I know React Native lets you build apps for both iOS and Android, but I’ll initially just be making a Writeabout app that supports iOS. If there’s not too much legwork to get it working in Android, I will also support that.

This morning I put the final touches on a Rails application that I planned to move from DigitalOcean to Render whilst upgrading it from Rails 6 to Rails 7. The actual change of platforms wasn’t too much of a problem, but the upgrade to Rails 7, and the third one that I have done, still presented me with a few issues. These problems were not too difficult to fix, and after an hour or minor tweaks, I managed to get the application up and running on Rails 7.

With this being the third Rails 7 upgrade I have done, I’m gradually building up a checklist that uses the Rails document as a base and includes a few other steps when it comes to moving away from Webpacker as well. This checklist will prove invaluable for another couple of Rails 7 upgrades that I plan to do over the next couple of weeks.

With a checklist, you know where you are and the steps you need to take. It allows me to do these upgrades in sections as well, so that I can do a few steps, take a break and then pick up where I left off, knowing what the last step was and what the next step will be. It’s a wonder I don’t use checklists a bit more. I know a few tasks are coming up over the next few months where a couple of checklists will be invaluable once again.

More checklists, please.

I’ve been trying to get more out of my Todoist setup recently by using labels to tag more of the tasks that I have there. It’s similar to the previous setup when I used Todoist a few years ago. I have labels for the duration of the task, labels for the context of the task, and some GitHub style labels that provide some further context to tasks related to building web applications.

It’s working well so far, and now the next step is to use Todoist’s filters to pull together some tasks from various projects. It’s at this point where I fell away from Todoist last time. I ended up with far too many filters that split all my tasks into multiple lists that were too hard to maintain.

This time I have vowed that things will be different. This time I am starting with just a single filter of minor tasks that I can pick off through the week.Most of my tasks are scheduled throughout the week. So there’s no need to apply additional filters to these tasks. It will get done on the scheduled date and time. For those minor tasks that can take me up to 15 minutes, I’ve decided to allow them to sit in Todoist and get done when I need to do them. With them spread over several projects, the new filter will bring them together under one view.

I’ve been intentionally slow on my uptake with Todoist this time. It can become overwhelming to try and use everything from the get-go. However, this time, I decided to pace myself and try out different parts of Todoist when I needed to. It is working well so far.