This is the second in a series of articles about build tools in the Go ecosystem.

Goyek is a simple library for creating build automation in Go.

Goyek’s focus is on simplicity and portability: it lacks sophistication found in other tools. For very simple builds, especially those that are only using Go tools, and that need to be portable across different platforms, Goyek might work for you. For anything even slightly sophisticated, I think there are better options.

In this article I will show how I ported my Makefile to Goyek and provide a brief review of Goyek. I’m going to share some code, but no deep explanations – this is not a Goyek tutorial.

This is the twelfth in a series of articles about writing a small reading list app in Go for personal use.

When I first introduced tests for this app, I showed a strategy of checking for “fragments” in the body of the page – these are just strings, including HTML markup, that the test will verify are present in the generated page.

This approach works, but it’s fragile: trivial changes to a generated page like spaces or newlines can trigger test failures that don’t indicate real bugs in the app. The tests will only be failing because they’re too tightly coupled to the output format.

In this post I’ll show a better way to validate the contents of generated pages using the goquery package.

This is the first in a series of articles about build tools in the Go ecosystem.

Mage is a tool that provides functionality similar to make. From their website:

Why?

Makefiles are hard to read and hard to write. Mostly because makefiles are essentially fancy bash scripts with significant white space and additional make-related syntax.

Mage lets you have multiple magefiles, name your magefiles whatever you want, and they’re easy to customize for multiple operating systems. Mage has no dependencies (aside from go) and runs just fine on all major operating systems, whereas make generally uses bash which is not well supported on Windows. Go is superior to bash for any non-trivial task involving branching, looping, anything that’s not just straight line execution of commands. And if your project is written in Go, why introduce another language as idiosyncratic as bash?

In this article I will show how I ported my Makefile to a magefile and provide a brief review of mage. I’m going to share some code, but no deep explanations – this is not a mage tutorial.

This is the eleventh in a series of articles about writing a small reading list app in Go for personal use.

When a user adds a new book to the app, they just get a page-refresh back to the index page. There’s nothing that says “hey it worked”. And if the user has more than fifteen books in their list, the new book won’t even show up on the first page, so they have to flip to the back to make sure it’s there.

In this article I’ll show how to provide that user feedback using flash messages. In order to show flash messages, some kind of session management is needed, so I’ll show that too.

This is the tenth in a series of articles about writing a small reading list app in Go for personal use.

In the last article we looked at pagination, and I promised to share an approach to testing the pagination support with Go 1.18’s fuzzing support. That’s what we’re going to look at today.

At the end of this article you will:

• see how to run fuzz testing against a function
• see why you might want to refactor a function for more effective fuzz testing

This is the ninth in a series of articles about writing a small reading list app in Go for personal use.

Last week we wrote a tool to import books from a CSV file exported from a service like Goodreads to our book database. And we found that it takes about ten times longer to render the book listing page when there are 600 books than when there are three books.

To keep page generation times shorter, we’ll use a strategy called “pagination” to split the book listing up into multiple pages, with each page having a limited number of books on it.

When we are done with this article, we’ll have:

• the books list paginated so that it only shows 15 books at a time
• with multiple pages to show all the books
• and page-by-page navigation links at the bottom of the page

DRY. Don’t Repeat Yourself. It’s a programmer’s mantra. And it’s a great rule of thumb. In general we should work to avoid duplicate code, refactor to functions, and maintain a single set of logic.

And I don’t want to argue against that – within a single codebase. If you maintain and control all the code, you should strive to stay DRY.

The biggest way that this goes overboard is when people try to overgeneralize across projects. Then we end up with tiny “utility” packages for trivial functionality or sprawling frameworks.

This is the eighth in a series of articles about writing a small reading list app in Go for personal use.

Sometimes there are operations that need to be done on the app that don’t need to be built into the frontend. Administrative process like backups, database migrations, or – the thing we’re going to do today – bulk data import.

I’ve got a CSV dump of my Goodreads books, and I want to import those into Aklatan’s db. I only need to do this once, so I don’t need to mess around with making a web form for it. It just needs a backend administrative command to perform the import as a one-off process.

By the end of this post we’ll have:

• a command that loads data from the Goodreads CSV export into akalatan.db
• knowledge of how to use raw SQL – we won’t use Gorm for this task

And we’ll do it in less than 75 lines of code.

Accessibility is Usability. If your app or site isn’t accessible, it isn’t usable – at least by some segment of the population. But also, if your app or site fails to meet accessibility criteria, it’s probably unusable by a larger segment of the population than you think. Just anecdotally I think that if an audit of your website shows a lot of accessibility-related defects, it’s rather likely that it’s crappy to use for fully-abled people too.

Let’s look at how we can build accessibility into our development process.

This is the seventh in a series of articles about writing a small reading list app in Go for personal use.

So far we’ve built a sort-of usable app with Gin. We can see the list of books we have in the system, and we can add new books. But there are some serious usability problems:

• there’s no link to the “New Book” page, or to the “Book List” page – you have to know the URLs and type them in directly
• both the input form and the list suffer from poor layout, almost to the point of being unreadable

In this article we will fix those issues and set up a foundation so that future work will have established patterns for styling.

When we’re done you’ll have:

• external CSS and a way to reference it from the pages in the app
• a navbar to be able to easily click around the app
• some options for managing that external CSS with the app’s deployment

Fair warning: I’m not a CSS expert, so don’t assume that anything I’m doing with the actual CSS is “the right way”. I’m more interested in demonstrating the mechanisms and patterns that we can use for integrating these pieces. When I need stuff to actually look nice and be maintainable and scalable I talk to real designers.