~ Andrew Pillar's Blog

There will come a point in time during your time administering a Linux server where you will want to perform a job on a schedule. Perhaps you want to rotate some TLS certificates before they expire, or delete old files that are no longer needed. Typically for this, you would use cron, perhaps the most widely used job scheduler for UNIX like systems. You would fire up the crontab for the user, punch in the schedule followed by the command, then write and quit. If you wanted to monitor the job, then you would add MAILTO at the top to receive the cron logs should the job fail.

Go is known for having a pretty extensive standard library, it's one of the things I like most about the language. This includes a templating library for generating either textual or HTML output, against a set of provided data. What with the latter being highly useful in the development of web applications wherein you would want to generate secure HTML. With embed, you can have your HTML templates bundled within the binary, meaning at deployment time you don't have to worry about managing additional files, reducing the administrative overhead. Today, I would like to demonstrate another approach to achieving this however, using a different templating language that generates Go code for generating the templates, and allows for generating minified all-in-one HTML pages with ease.

When I first dipped my toe into web development it was with PHP. Building quick and dirty inelegant websites, where the HTML and PHP would blur between one another. At the time, I did have a very firm grip on what HTTP was, where exactly PHP sat in the stack, other than it being in the backend, whatever that was, nor did I understand what a database was, other than a place to query data from. On top of this, I was writing this inelegant PHP code on Windows. If you've ever done PHP development on Windows, then you are most likely aware of WampServer. This is a solution stack for Windows that provides an Apache web server, OpenSSL, MySQL and PHP.

I've written previously about my thoughts on ORMs in Go and how the typical Active Record style ORMs seem to be a poor fit as a whole. With the advent of generics however, I've decided to revisit this topic, and see how generics could be utilied to make working with databases easier when it comes to modelling data. The parts I'm mostly interested in is providing a thin abstraction over the typical CRUD (create, read, update, delete) operations an ORM would provide for each model. Ideally, we want to provide this abstraction in a way that makes as few assumptions about the data being modelled as possible, and that builds on top of what has already been explored with regards to query building. I'm not going to cover what generics are in this post, as the authors of the language have already done that, instead we're going to dive right in.

There comes a point in time during the development of a piece of software when a configuration language needs to be used, you can only do so much via flags before it becomes too tenuous. The language chosen should provide a format that is easy for a person parse as well as a computer. Typically, most people would reach for YAML, TOML, or sometimes even JSON. For the development of Djinn CI, none of these fitted my needs, so I developed my own, specifically for Go.

Programming languages are always something that have fascinated me, how they're designed, how they're implemented, and how they're used. Whether they're a DSL (domain specific language) or more of a generic programming language. A programming language is always something I had wanted to take a stab at creating, even if it ended up being terrible, or being of no true utility, but only for the sake of learning. Well, over the Christmas break I decided to occupy my time on developing a language, one that was small and simple, designed for a specific use case that I had encountered but hadn't found a solution for. The language that I ended up developing was [req][req], a language designed only for HTTP scripting.

A small update

Sat 7 Aug 2021

Been very quiet for quite some time, so may as well provide a small update to the handful of bots and webscrapers that visit this site. A project that I have been working on for some time has been fully deployed, and I'm getting ever closer to showing it off to a wider audience, once I've finished up an feature or two. If you've been snooping around my GitHub account or some of the repository's I have on there, then you may be able to find out what it is. The next post I make here will be an introduction to this project. Once I've shown this off to a wider audience I intend on writing some more posts here too about the project itself, and some of the approaches I took to building it.

Over these series of posts I have been exploring an approach that could be taken when working with SQL relationships in Go. The precursor to all of this was the initial ORMs and Query Building in Go. This explored one aspect of ORMs, the query building, but it didn't address how relationships could also be handled in an idiomatic way. So before I wrap up this series in this final post, let us address the code we have currently.

Previously, we implemented some new interfaces, and utility functions to aid in the loading and binding of the model relations. This was a much better improvement than what we had before, however we still don't have a way of defining the relations themselves in code. So far, we have heavily utilised callback functions to do most of the lifting for us. For example, the model.Bind function we implemented returns a callback that will gracefully handle binding the models we load. In this post we will look at how we can utilise callbacks to set the relations between models via code.

Last time, we refactored our code, and implemented the loading of the relationships for the Post entity. The implementation of this however was rather messy, as we did the equivalent of sweeping everything under the rug. In this post however we will look at what we've done, and see how this could be improved upon.

In the previous post we setup the entity models for the blogging application, and built some custom query options to handle the data we would be receiving via an HTTP request. Here we will go about implementing pagination for our models, so we can support the page query parameter, look into how we can refactor what we have in our HTTP handlers, and start looking into loading entity relationships for models.

In my last post I touched on the idea of using query builders for building up somewhat complex SQL queries in Go. Well, in this post I'd like to go further, and explore how this can be used to idiomatically build out a simple system for modelling relationships in Go. This post going forward will assume that you have read the aforementioned post.

Recently, I have been looking into various solutions for interacting with databases with ease in Go. My go to library for database work in Go is sqlx, this makes unmarshalling the data from the database into structs a cinch. You write out your SQL query, tag your structs using the db tag, and let sqlx handle the rest. However, the main problem I have encountered, was with idiomatic query building. This led me to investigate this problem, and jot down some of my thoughts in this post.

Patience in Programming

Sat 11 May 2019

I am an impatient man (if my sporadic typos, and last minute edits late at night on my blog didn't make it obvious already). Recently this has started to stick out to me much more, especially in regards to programming. More often than not I would find myself just writing code haphazardly, then let the compiler/interpreter point out the errors for me, some not so obvious, others more obvious than I would have liked. This is a rather reckless approach to take when it comes to development. I find that it prevents me from actually thinking about what I am doing, and results in me producing tools and code that are in unsatisfactory state.

Another update

Tue 23 Apr 2019

It has been too long since my last post in which I announced mgrt, the simple SQL migration tool. Has much happened between then and now? Well, I showed off mgrt to some people with little fanfare, and got around to implementing TLS support for the tool. Right now it supports TLS for PostgreSQL, and to a certain extent MySQL/MariaDB. And during my further developments of the tool itself I have come to realise how much I truly despise working with MySQL. My feelings for it are all superficial, so they hardly warrant a tangent.

mgrt: Simple SQL migrations

Sun 27 Jan 2019

As mentioned in my previous post, I have been working on a tool for handling SQL migrations. Well, that tool is now ready to debug, and is called mgrt. Much like jrnl, I decided to take the Welsh approach when it came to naming it.

An Update

Thu 24 Jan 2019

It's been almost a month since my last post, in which I detailed what I hoped to achieve in regards to this blog, and to a slightly further extent this year.

2019 is around the corner, and it has been 2 months since the first post I made on this blog, though I doubt anyone is actively following/reading. I have done very little to advertise it so what should I expect? However I think now is an apt time to justify the purpose of this blog, and layout some of the things I would like to achieve in the coming year.

Introducing jrnl

Sun 7 Oct 2018

jrnl is a simple static site generator written in Go. It takes posts written in Markdown, and converts them to HTML. The generated HTML files are then copied to a remote destination, this can either be a location on disk, or to a remote server. Unlike most other static site generators jrnl does not serve the content that is generated. This post shall serve as a brief introduction to jrnl, for more in depth usage refer to the readme on the project's GitHub.