@vaguery and I were talking about the Apple announcements and it came up that they seem to be trying to position iOS and the various iPads and such as the platform for most kinds of work. Maybe. Who knows?
Anyway we started talking about my main gripe with ronjeffries.com, which is that when I just have my iPad, I can’t write and publish an article. So maybe we’ll work on figuring out a way to do that. If so, I’ll report it here. For now, let’s look at what I have now, and what I’d like to have.
All my articles are written in Markdown, and are stored in a hierarchy of folders that matches the folder structure of the site. Using the Jekyll system that I’ve written about before, the Markdown files are converted to
.html in a folder hierarchy that exactly mimics the site. (For values of exactly.)
If one were to FTP that top level folder and all its subfolders up to ronjeffries.com, the site would be there. (There are a few files up there that are not represented in the Markdown hierarchy, I believe. When I find one, I arrange to have it on both sides.)
Once the site is built on my Mac, or my other Mac, I commit new stuff to git and github, and use the Transmit app, which I like, to push the changed files up to the host.
So the new article process now is roughly: On the Mac
- create new folder in the rj-com folder;
- write article and save it in the new folder as index.md;
- run Jekyll;
- review article appearance;
- repeat until happy;
- run Transmit to push the new article to host;
- commit and push to github.
What I’d like …
Here’s what I’d like to have happen: On the iPad
- write article, save in index.md or some name;
- pick a folder name for the site’s copy;
- press a button;
- article is in the base folders;
- article is in git and github;
- article shows up on site.
A few constraints and issues come to mind:
The site’s indexes and home page are created by Jekyll, which accumlates all the tags and links and then creates the index files. Some way of getting the new article on the home page and into the indexes will have to be invented.
Jekyll builds the entire site hierarchy and Transmit figures out which files have changed by looking for file size variances. (Checking for dates doesn’t work because all the files are newer after Jekyll builds.) Some way of moving up just the necessary files is needed. Necessary files means, roughly, the article, any images embedded in the same folder, and any indexes that have changed because of the article’s tags. (Or all indexes could be sent, of course.)
I would like to leave the site hosted where it is, with an old friend of mine, and that may limit the kinds of setup we can have.
I don’t want to build the whole technical stack over again.
I’d like to proceed incrementally, of course.
I really would like the site itself to be static, or as near to static as it can be, so that over the longer term it’s not subject to changes in how it’s created or on special software on the server. Or because I’m paranoid. Anyway I’d like it to be (mostly) static.
All these constraints are able to be changed but I feel they’re pretty solid.
We talked about Tozier’s setup, which uses Sinatra and builds its articles and indexes on the fly. It’s certainly fast enough and is about the same size or larger than my site. If indexes were dynamic on my site, then if an article showed up magically in some new folder, the indexes would accommodate it.
The issues I have with this idea are first, that it makes the site more dynamic even if we just did the indexes on the fly, and that converting fully to Sinatry or the like is right out because I don’t want to invest the time to rebuild my whole technical stack just to get an iPad article written once in a while.
I’m wondering whether there could be some kind of cloud folder into which I’d drop new articles, and some kind of daemon would scarf them up, move them into the site markdown hierarchy, run jekyll, and then push the relevant files. It seems to me that some fairly simple trigger could run a script. Probably it would be OK to push all the index files, and everything in the corresponding
There are complications, of course, such as what happens in the rare case where the jekyll build fails. We’d like not to destroy the site when that happens.
And should the process just assume that my home computer is running? Or should we push the build up to some heroku instance or something.
So therefore …
It’s an interesting little topic and may turn into an interesting little project. I’ll keep you posted.