Setting up Hatchbox

I’m posting a short post tonight as I’ve been spending the evening setting up a Hatchbox account and migrating the first of a handful of Rails applications to it. The setup was straightforward, and after 45 minutes of tinkering, I got my Writeabout app running on it. I’ll try to move a couple more applications over tomorrow.


Building a single page admin section

I’m currently following through the hotrails.dev tutorial series so that I can build an admin section for the Writeabout website.

For too long, I’ve just updated Writeabout’s prompts using the Rails console, which is fine. Using a web interface, though, would make it a bit easier for me to add prompts.


This is the second in my build updates for 2022.

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.


I need to ship Rails app updates more often

On Sunday night, I migrated a couple of Rails apps to Ruby 2.7, including Writeabout. Last night, I did the same with another Rails app. By the end of the week, I hope to have Markcase moved over to Ruby 2.7 and Dailymuse upgraded to Ruby 2.7 and Rails 6.0.

Upgrading apps is a pain if they’re left alone for too long. I’ve left Dailymuse alone for such a long time that it’s still sitting on Rails 5. Markcase is on Rails 6 but requires a wee bit of maintenance regarding Webpack.

I’ve learned that leaving apps for such a long time between updates is not the best thing to do. Even upgrading an app regularly through its patch versions is better than just leaving them sitting gathering dust.


I’m going to add a back-end admin plugin to Writeabout to make the adding and updating of writing prompts easier.

I intended to have an admin API endpoint to manage the prompts, but for a short term fix, I’m going with the admin plugin route.


Last night I added a fav icon, a touch icon and Twitter card handling for Writeabout.

On the face of it, one could argue this is purely a vanity change. It was actually a test run to see what’s the minimum icon changes I need for a web app.


Baby steps with StimulusJS

Last night I needed a much needed break from the usual Rails coding, so I worked through an example on the StimulusJS website so that I could add a “copy to clipboard” button for the displayed writing prompt on Writeabout.

For me, this is the ideal level of integration I need with JavaScript. A framework that does some of the heavy lifting on the user-interface without me having to re-write the whole front-end.

The end result is nice, but I don’t like the way the elements on the page move up and down when the copy button has been pressed. I’ve added a little div section with an indicator that the button has been pressed. It disappears after a few seconds, but it moves the elements on the page up and down when it changes its display state. I’ll fix it another day, but the first pass at this functionality is still good.


Adaptive product naming

A favourite saying of mine is Phil Karlton’s quote about hard things to do in computer science.

There are only two hard things in Computer Science: cache invalidation and naming things.

— Phil Karlton

I can’t say that cache invalidation has given me major issues in the past but naming things has always been a challenge. If I was to take this beyond the realms of programming though, I would say that naming anything is a difficult thing to do.

My portfolio of web applications include DailyMuse, Markcase and WriteAbout. I find it hard to get away from the compound naming theme. It’s just a way of naming things that I stick with. It’s easy to do, but it feels like it lacks imagination. I would love to come up wth alternatives that don’t follow this convention but everything I have come up with didn’t feel like a good fit.

The other thing I don’t like about compounded product names is deciding whether to upper-case the second word or leave it as lower-case. GitHub’s branding is clear that they favour upper-casing the second word, but there are examples of other brand names that are made of two words that just user a lower-case word for the second word. Take Feedbin for example.

For my bookmarking service, Markcase, I choose to use the lower-cased form instead of MarkCase, and I have to say I prefer it.

I’m working on something that is bigger than anything I’ve worked on in the past. I’d like it to become my full-time gig eventually so it’s quite important to get the naming of it right. I do have a name for it, but I’m torn between whether to use the upper-case form or the lower-case for.

I am edging towards the lower-case form. It reads easier and looks better in the different styles that I have for it.

I find all aspects of branding and marketing quite a challenge. I’m creative to an extent, but I’m definitely not well-versed enough to launch a huge marketing campaign. To get my product off the ground though, I’m taking little steps in executing it and learning as I go. I might not always get it right to begin with, but adapting the product and the marketing as I go, is better than not doing anything at all.


On a brighter note I did ship my random writing prompt web page.

I’m not sure about the name, the domain choice or what the future holds for it, but it felt good deploying it again.