Earlier today I posted a link about how to sync Octopress across multiple machines. That was very helpful because when I took the trivial approach and just went through the set up a second time, I quickly arrived in Merge Conflict, USA and it was decidely not groovy.

When I got back to the first machine, I decided to automate a few things…

##Source vs. Master If you’ve paid attention to what’s going on with Octopress, you know that what gets deployed to GitHub Pages is the master branch of your _deploy directory. The raw, ungenerated material (markdown, themes, layouts, etc.) stick around in the source branch which you can push, well, wherever. I push mine to a private repo.

If I’m going to be working on posts from multiple machines, I find myself doing a lot of this… git pull private source cd _deploy git pull origin master
cd ..

I would rather just do this rake pull

Spoiler alert: Now I can =) I created an Octopress rake gist if you want to add this to your own Rakefile.

##Drafts and Scheduling Two of the things I missed from WordPress

  • working on drafts
  • marking posts as “done”, but for a future date

I know that Octopress has published: false to support drafts, but I’d rather have a _drafts directory. This keeps them isolated so it’s easier to see what’s a draft and prevents mistakes around the published flag.

When a draft is done, I can mv it.markdown ../_posts/YYYY-MM-DD-it.markdown to include it immediately.

**I would rather ** mv it.markdown YYYY-MM-DD-it.markdown and have it included when we reach that date.

Spoiler alert again: Now I can =) At any point, I (or any automated worker process) can just rake post_drafts && rake generate && rake deploy

Yes, for now I called it post_drafts even though it doesn’t include the generate or deploy. I’m still undecided on what I want to do here, and my philosophy is don’t go pushing things live unless you’re sure that’s what you wanted.

So the post_drafts task spins through _drafts, and any files matching YYYY-MM-DD-title.markdown where YYYY-MM-DD is today or earlier get moved to _posts. Files not matching the format, or where the date is still in the future, are left alone.

I also created an Octopress rake post_drafts gist. Do remember to define drafts_dir, as that’s not something in the default Rakefile!

##Am I doing it wrong? This was a fun excercise for me. It eased a couple of my pain points and gave me an excuse to hack on Ruby and Rake for a few minutes. Maybe I’ll look into that automated worker to promote scheduled drafts without any human intervention, so things go live even if I’m on vacation.

I’ve already decided that post_drafts needs a better name, and I’m considering that perhaps promotion of scheduled content into _posts should just be part of the generate task instead. That said, I’m still getting into Octopress, and as much as I love Ruby, it’s not where I have the most depth. Am I missing a better way? How do you handle drafts and scheduling in Octopress.

Update: I created a new_draft task that works much like the new_page task, but it puts the file in the configured drafts_dir. I have used it to quickly create empty stubs of things I want to cover soon, and pushed that to my private repo. This new platform and tool chain might just be what gets me blogging regularly again, but only time will tell.