[tlug] TLUG Site with Hakyll Update

[Curt Sampson <cjs@example.com>]

On 2019-03-09 20:41 +0900 (Sat), Jim Tittsler wrote:

> As announced at today's Technical Meeting, Curt Sampson has
> volunteered to lead an informal workshop...on Hakyll[1] static site
> generator.... We plan to use the TLUG web site as a test case...
> exploring the idea of rendering it with a static site generator.

So Jim, Justin and I made some nice progress on the following:

1. Pulling all the existing site assets on the server into a repo so
   we can share them and use them for the new site. This is a separate
   repo, `akari.tlug.jp`, because it's huge (a couple of gigabytes)
   and we don't actually want _all_ of those assets in the new site.
   It's also private becuase it includes mailing list archives and we
   don't want to expose those e-mail addresses publicly. (The archives
   served from the current web server are a sanitized version of those
   with the e-mail addresses blacked out.)

2. Doing a proof of concept by generating the English and Japanese top
   pages using Hakyll. This work is publicly available and is in the
   repo <https://github.com/tlug/tlug.jp>. There's an extensive README
   there with details on how you replicate the build and play with a
   local copy of the site; the TLDR is, "run ./Test and look in the
   _stack/ folder it created."

3. Staging deployments. We played around with GitHub pages and
   Netlify, with some success but discovering issues with both. Just
   this morning I updated the code so you can run `./Test -B` to create
   a new commit on the `gh-pages` branch containing just the built site;
   that is currently served at <https://tlug.github.io/tlug.jp/> (and
   from a similar URL for your version if you fork the repo).

The main deployment issue is that currently after a change to the
`master` branch someone needs to build the site on their own computer
and commit that to the `gh-pages` branch. That's dead easy to do, and
has the advantage that non-buildable source won't get deployed and we
can even add tests to the site to catch common errors and keep them
from going into production.

However, another point of view is that it would be nice if one could
just click the "Edit" button on GitHub to make changes to the site's
source and have an automatic build system do the build and deployment.
(This is a typical use case for Netlify, GitHub pages and other
systems.) This avoids having to clone a local copy of the repo and do
the build, and also ensures that the build environment is better
controlled. This can even support staging and preview versions of the
sites by building branches that are served under other URLs.

I don't have a particular opinion about which approach is better. I
personally am fine with the former, since that's my standard software
development workflow, but this really needs to be optimized for the
people most frequently updating the site, which isn't me.

The current issue with the second option is that the initial build
"from scratch" (i.e., on a system without Haskell Stack and Hakyll) is
quite long because the compiler has to be downloaded and Hakyll and
its 150 dependencies has to be built. (This takes about 10-15 minutes
on oldish 4-core laptops and exceeds the 30 minute limit--though just
barely--in Netlify's build containers.) That's just the first time,
though; a clean build of the site, including the Haskell code that
defines the site build procedure, takes only a second or two after
that.

I do have some potential solutions in mind for this which I'll hack on
a bit and we can discuss. In the end, if all of those turn out to be
too awkward, the obvious solution seems to be to move from Hakyll to
one of the zillion other stack website generation systems written in
interpreted languages such as Javascript or Python. (But not Ruby.
Please not Ruby! :-))

Discussion here is fine, or also in the TLUG Gitter room at
<https://gitter.im/tlug/tlug> if you want faster turnaround time
on comments.

cjs
-- 
Curt J. Sampson      <cjs@example.com>      +81 90 7737 2974

To iterate is human, to recurse divine.
    - L Peter Deutsch