I’ve known and used Markdown here and there for some time, but I’m starting to really see its value. On the surface, Markdown is a way to take text and make decent looking HTML out of it, and the text still looks like some typical formatting in a plain text environment. I’ve sent managers these kinds of files, and they can just open these files in any text editor if they don’t have means of viewing Markdown.

The real power that’s coming to me from Markdown (and I’m sure there’s other stuff that fills a similar role), is that I really can just edit it with a text editor. The uses here are many. For one, this blog post was written in Markdown; it’s a new thing I’m trying out. I’ve basically replaced Evernote with Markdown and Dropbox.

My Markdown+Dropbox solution came from a worry about what would happen if Evernote was usurped by some better note taking app. Evernote has enough going wrong with it that the landscape is ripe for disruption. With over 1000 notes, that’s a tall order to start moving. Companies sometimes close their doors without notice. I’m not scowering hacker news for this kind of stuff, so announcements that the company is in dire straights is something I could easily miss. All of the sudden I have my data in a proprietary format with no know means of getting the data out, short of manual copy-paste stuff. With a Markdown+Dropbox solution, I can swap out my host at any point. I can even version my notes with git. Markdown means I can still format my documents, make links, and basically have a local wiki (which is what I really went out looking for when I settled for Evernote). I can always switch file formats later if I want, and just leave Markdown for older posts using a stable version of the editor/renderer available for historical use, or incremental updates to documents that just don’t make sense to port to whatever is new and shiny.

Today’s endeavor is on a markdown flavored blog. I’ve had Jekyll generate a blog site for me which I intend to deploy to github. This will be my 3rd blog host, but this time the blog host doesn’t know that’s what it is. This is great - the software that runs the blog is completely independent of the content in the blog itself. If github starts to suck I can pack my bags and be out in minutes.

This kind of decoupling is nothing something I’ve thought much of, but I’m starting to consider more. What other things could I migrate onto a simpler solution?

Are there other avenues this can go? What other forms of decoupling have you tried?