In the past trenchant.org has been produced with long forgotten software like Userland Frontier, shell scripts accessing BeOS filesystem attributes, and organizine.
For most of trenchant.org daily’s run it was produced with a home-grown CMS called mathecms. Matechms was a perl script that transformed text files into the site, and offered a simple web frontend for editing.
I ran the CGI perl script locally to both edit the site and generate. Afterwards I ran an rsync script to transfer the flat files to the web server. A cron job ran nightly to regenerate the site.
This worked OK, but I can do better.
One of the first projects I did in 2010 after leaving my job was replacing mathecms with a more “modern” version written in python called endless inkwell, but it was the same idea: flat files representing the site, a script that creates html files, and an rsync script that transferred it to server.
I never released that, but it was the starting point for endless i/o, a retro-file-blogging platform whose main advancement was monitoring a directory for changes, then creating the static web site, then syncing it to a server, enabling drag and drop publishing.
For 2012 I’ve changed the setup on trenchant.org a bit based on that concept, and some new ideas and requirements.
In the old days it was:
- Draft text in some text editor, usually notational velocity but sometimes Aquamacs, and sometimes in a web browser
- Launch local endless inkwell web site, paste/edit text
- hit save
- Manually rsync files to server from the command line
- Server rebuilds site every night. (Usually, when Dreamhost wasn’t randomly deleting my cronjobs.)
Now it is:
- Create and edit text files in notational velocity
- There is no step 2.
I’m still using the same (creaky) python scripts to generate the site but my workflow is much better.
I had this working for decommodify a while back and decided I like it.
Also, if I want to create something on my iPad the workflow is:
- Create a text file in IA Writer that saves to Dropbox
- There is no step 2
We should be past that.
And I want well written, responsive, native interfaces to my writing process. I want creating and editing and searching to be frictionless. Currently I find Notational Velocity the best in that regard, so that’s the frontend.
(Yes, I know, I was trying to get all that working on the web but I haven’t. Yet.)
Behind the scenes, I want everything to just work and not require actions on my part.
No source or full recipe yet, but here are some of the moving parts:
- Notational Velocity saving text files to a directory synced by Dropbox
- An unix server you can install whatever software you want on
- Dropbox linux
- a cron job to rebuild the site periodically on the linux server
- Fork Notational Velocity to create multiple contexts for different sites. I didn’t do the hard work to do this, and, instead I just renamed the bundle-id and recompiled, so I have different notational velocity binaries for trenchant.org and decommodify.com.
Smarter solutions would be to have a script that doesn’t regenerate the whole site every time, and that monitored the directory for updates rather than just rebuilding it once a night, but this seems to work OK despite the obvious inefficiencies because it’s just me on my Linode and it’s 2012 computing is cheap.
And also I could modify my workflow to support multiple sites from a single directory of text files, but I kind of like keeping them separate.
The only annoyance is editing after publishing requires a manual kick-off rebuild, but, luckily, my words never need fixing!
· · ·
If you enjoyed this post, please join my mailing list