My preferred poison for almost 10 years had been Thunderbird. The tool that started out as a potential replacement for Outlook, but in the end never quite had the integration of calendaring and contact management required to take on the 600lb gorilla. I made the hard choice a year ago to switch from Thunderbird to Mail.app on my Macbook, because Thunderbird performance had gotten so bad, and had blown up to such a huge memory hog, it just didn’t make sense anymore.
I’ve been working with Jekyll on the US Drone Racing Association site. It seemed like a nice idea. Check all your content into Github, then, when ready to do work with it, check it out, make your edits, run a local test site (that part is really nice), and when finished, check it back in. One update on the master site, and you’re done. Woo.
Yeah, see, that’s where they getcha.
Jekyll is great for very fast setups for static sites. If you never want to really change the site, such as changing themes or regularly adding blog posts quickly and efficiently, you’re probably good.
But I found the blogging process enormously painful.
- Check the site out of github
- Go into the _posts directory, pick an old entry, copy it to a new filename. The new filename must be yyyy-mm-dd-uniquename.markdown. This date is important because it’s used as a sort order.
- Edit the newly created file with whatever editor you like, but the YAML Front Matter must be correct. Using YAML for structured data is already problematic, but this is supposed to be a markdown document. But, no, it’s sort of a hybrid of YAML and Markdown and HTML.
- If you get the YAML Front Matter right, you get to write your post. Markdown is nice, but it has it’s limitations
- Save the file, make sure you go back to your root (god knows how many times I’ve failed at this one), and do ‘jekyll serve’. Test your site locally. Swear and curse as it doesn’t work right. Repeat previous steps until right. (Credit here. The live preview is really nice, and it updates automatically when a file change is noticed. I can’t fault that.)
- git add -r
- git commit
- git push origin master
- Log into your blog host
- cd to your working directory
- git pull origin master
- cd sitename
- jekyll build –destination=/var/www/yoursitename
Now, this really isn’t that horrific. Irritating, sure, but you can automate pieces of this and add some nice wrappers around it.
I wanted to theme my site. Here’s where things go sideways. In short, you can theme a Jekyll site.
But you can only do it once.
Why? Because you don’t apply a theme to a site. You apply a site to a theme.
Sound crazy? Lemme splain. To theme a site, you download the theme, build it (and in Ruby land, this can be a nightmare experience. Ruby dependencies are horrific. Don’t believe me? Check out the conversation I had with a theme developer. We couldn’t get it running at all.) But even if you do get it running, after you build a theme, you copy your existing content into the new theme directory, and commit the whole thing up to git. That’s your new site. Want to change themes? HAHHAHAHAH. You have to do this process all over again, extricating your content from your old themed site and copying it into the new theme directory structure.
Sorry jekyll. I’m done with you.