Make All Gems Pristine After Upgrading Ruby

I upgraded to Ruby 2.3.0 today after using 2.2.3 for some time. Next, I ran a Ruby script I’d used many times before only to get a terminal full of output like this:

Ignoring iconv-1.0.4 because its extensions are not built.  Try: gem pristine iconv --version 1.0.4
Ignoring json-1.8.2 because its extensions are not built.  Try: gem pristine json --version 1.8.2
Ignoring nokogiri-1.6.6.2 because its extensions are not built.  Try: gem pristine nokogiri --version 1.6.6.2
Ignoring rdiscount-2.1.7.1 because its extensions are not built.  Try: gem pristine rdiscount --version 2.1.7.1
Ignoring redcarpet-3.2.2 because its extensions are not built.  Try: gem pristine redcarpet --version 3.2.2

Looks like gems with native extensions didn’t work after upgrading Ruby. Makes sense, but how could I reinstall all these gems without having to manually run all of those pristine commands? Fortunately, there’s a way to make all your gems pristine.

gem pristine --all

Beware that, if you have made changes to any gems locally, that this will clobber those changes. Thanks, StackExchange, for leading me to the answer.

I was happy to see the solution was easy, even if it did take a few minutes to process all the gems. I’m sure I’ll need to refer to this post again when I upgrade Ruby in the future.

Introducing everything-core Gem

I’ve been using my everything concept for a while now. I enjoy the structure it gives me for my writing collection. To help me do things with the writings, I’ve written various pieces of software. Quickly enough, I had similar code duplicated across multiple projects, with little differences here and there.

Rewriting that code every time or even copying and pasting it into each new project isn’t an extensible way to build a suite of tools. Instead, I want a single piece of code I can include in multiple projects and just use. I also wanted to explore creating gems for Ruby. The goal is to keep the core software pretty small, and then extend it using other, small gems.

To that end, I’ve been working on everything-core. It provides the basic functionality needed to work with a piece in everything.

I haven’t used it much on my own yet, but that’s because only tonight did I finally get enough functionality in there to make that feasible. Now, you’re able to get a piece’s markdown content as well as its metadata. I’ve also tested the code in the gem, to make things a little more robust. I’d appreciate if you report any issues you run across.

I’m writing this post, in part, to check whether I can rework my WordPress publishing script to use the gem. If this post makes it live at all, it will be proof of success!

I’m happy to share a small milestone in my project. I look forward to expanding on this core going forward.

Directions in the Mountains

I just finished reading my friend Natasha’s post Sometimes, The Journey Is Hard. Her experience with bad routing directions in the mountains reminded me of my own.

Fool Me Once

Several years ago, I was trying to get to the campground at Grays and Torreys. I’d been there a time or two before, but it had been a while. I did what I normally do for directions, and found the area on Google Maps. Then we set out, with that as our destination. The area of the highway exit seemed about right. The dirt road we drove up wasn’t familiar, but I chalked that up to bad memory.

As we went along, the road condition deteriorated. I recall the road up Grays and Torreys being a bit rough in areas, but this had large gouges across the way. It quickly became a 4×4 road, which I navigated in my 2WD sedan. I had to attack the road’s chasms at sharp angles and low speeds to avoid bottoming out or becoming stuck. It can’t last forever, I thought, and we’ll soon be at the campground.

Except we ran out of road. The dirt road literally ended at a closed, steel gate. No signage; nothing. I then realized I’d taken the wrong road completely. There weren’t any turnoffs I could have missed. We were simply on the wrong road. And now it was dark. We’d lost the last of the sunlight on our way up.

After turning the vehicle around and navigating those same damn ravines and gulches in my poor, poor car, we made our way back to I-70 – and cell service. My car handled the road fantastically, all things considered, even though it did take a small beating.

With a data signal, I was able to check out Google Maps, along with directions on the 14ers site to see what went wrong. Google had taken us to a road on the opposite side of the mountains from where we wanted to be. We’d gone too far west, and ended up in Nowhere.

This floored me. The campground for Grays and Torreys might not have been huge, but it was at least a thing. Whereas the road Google Maps had just taken us up was a dead-end with nothing along the way. How could Google get it that wrong? What about all the other thousands of hikers a year who hike Grays and Torreys? How do they get there? Maybe they followed other directions, or knew better than to trust Google blindly. Worse yet, how many other hikers per year are also lead astray by bad directions?

We had to backtrack to get to the eastern side of these peaks. Finally, we found the correct exit and dirt road, and made our way up to the trailhead, to where we would camp. It was many hours later than expected, in the pitch dark, but we did arrive.

This experience taught me to double-check the route and destination Google will suggest when heading into the mountains. It doesn’t seem particularly knowledgeable of hiking trail heads, even for the most popular of destinations.

Fool Me Twice

Earlier this year, Karla and I did some hiking in the mountains south of Idaho Springs. After the hike, we wanted to get into town and have some drinks and pizza at Beau Jo’s. I put the instructions into Google Maps and it calculated the fastest route to the restaurant.

We headed down a paved road, turned onto a well-maintained dirt road, and followed that for a while. A few minutes later, I was turning the car around because I’d taken a fork other than the one Google instructed. The road I kept to was in much better condition that the one the directions used, but it did say to take it. I didn’t have a signal to get an alternative route, so I pressed on, following Google’s lead. I’m sure you know where this story is headed.

The condition of the road wasn’t great when we started, but it got worse the further down we went. I should have taken this as an indication to turn around immediately, but I thought Google knew better. Because you know how smart their technologies are in other parts of your life, so why would this one be any different?

At a certain point, we reached a CLOSED sign, indicating the way wasn’t maintained in winter. That gave me pause, certainly. Except, it had narrowed so that turning around was impossible. There was no option but to keep going down.

Along the way, little streams flowed over the road here and there. Other parts had enormous rocks to dodge, or bang and scrape your car over. Sometimes, the road tilted us quite a few degrees on our side. A couple areas were so narrow that branches touched the car on both sides. Portions of the path had grass growing where the tires rode. That’s how long it had been since someone else traveled through there.

The entire time, I was waiting for us to reach a spot impassible, and then not be able to turn around. Eventually, I realized that even if we could have turned the car around, there’s no way I would make it up the terrain. Gravity was at least working with us in this direction.

It was freaky to realize this road was a giant mistake. No one would find us if we got stuck. We’d have to hike out however far to find someone. I have AAA, but would they even help if my car was stuck in a place like that?

I had worried about meeting some 4×4 vehicle coming up the road, and being unable to let them pass. But at least if we passed a vehicle going up, we’d know the road led somewhere. As it stood, we passed no one, and had no idea how long the road was.

Further down, we passed a creepy, abandoned trailer which had furniture torn up and scattered around. In the nearby area, there was a lot of scattered property. It looked like a scene from a horror movie.

Shortly after the cabin of despair, we reached a spot where a couple of guys and kids were walking alongside the road. I rolled down the window and said hello. They were exploring some of the junk that lay scattered in the woods.

I asked how they’d gotten up here, and how much further the road went. Turns out they were also in a Honda Accord and tried to come up the road. They’d given up and turned the car back. One of them said, “The worst is yet to come.” My first thought was, “Oh. Shit.”

Luckily, that little part of the road was nothing compared to what we’d been down. The guy had no idea how much worse the terrain was above. I told him there’s no way he could make it up, so he was smart not to press on.

From here, it was smooth sailing into Idaho Springs. Karla and I had made it through the unsettling uncertainty of how long the road was, and if it would just end.

Only after we’d made it out of there did I realize something else. The road we were originally on was Little Bear Creek Road. The road Google took us down was called Old Little Bear Creek Road. The “Old” in the name should have been a sign. It’s named that for a reason.

Funnily, the Little Bear Creek Road that Google didn’t take us down would have been loads faster, without the threat of being stranded. Google certainly didn’t account for the state of the Old road, or the snail pace required as we negotiated it.

In this case, Google had the right endpoint, and the routing was nearly there. But it reminded me to be more cognizant of what roads the directions take. If, in the mountains, one option is a wide, flat, clear, maintained dirt road, and the other is a narrow, grassy, steep, rocky road, use some common sense, Kyle! You’re better off turning around well before the CLOSED sign, instead of blindly following the output of an algorithm.

Better Not Be a Third Time

Fortunately we made it out in both of the above occasions. My car’s been dinged up before, and I don’t care about keeping it pristine and shiny. It certainly wasn’t the end of the world. Even got some good stories out of it.

Google Maps works really well in cities, but it definitely breaks down in the mountains. I hope to keep these trips in mind going forward so I don’t repeat them. I don’t want a worse experience where the only reason it happened is that I didn’t question the directions as I went along.

Start The Writing

I had finished reading Neuromancer while lying on my futon, and then I stayed there a while. I thought over that book, along with some others I’d recently finished that were written by Arthur C. Clarke. An idea for a science fiction story sprouted in that moment. As my mind raced along, I got up, went into my den, and wrote down my brainstormings. The idea surprised me in its intensity and completeness. This, I thought, is something I can turn into a book. There were still lots of details to flesh out, but it had substance.

Over the next few days, I talked to Zach about some of the technical details to make sure they seemed feasible. I better understood the sequence of events after telling him about it. He gave me the fantastic advice to create something like a storyboard. I’m still working on it, but it will be nice to have a high-level summary of the story as I work on it.

I also talked to Karla, and she helped me realize how I had not yet envisioned individual characters. I had vague notions of people involved like “scientist”, but nothing more detailed. We talked about archetypes and personalities that could help form the basis of actual personalities. Thanks to that brainstorming, I have an idea of who the first character will be.

Next comes the part of figuring out how to make progress toward that leviathan goal of having a completed book. It will take dedication, persistence, regularity, and hard work. I want to hold myself accountable to some standard of effort, but what metric should I use to gauge it?

My initial thought is something like 3 pages per day. But pages is an ambiguous term. The size of the paper and print, margins, and layout of the text can vary the number of pages. Additionally, when I write on the computer, there isn’t a real concept of pages. It’s just a flow of words in a text file.

So what about 300 words per day? I’m not exactly sure how many words that would look like when written out. But it feels like a goal that’s reasonable and doable. One that I could meet regularly. 300 words a day for a year would be nearly 110,000 words. That’s certainly a novel’s worth. This goal of words-per-day does not, however, take into account things beyond the act of writing. Editing blog posts, for example, takes quite a bit of time. I can only hazard a guess as to how much time would be required for something the size of a novel.

Karla suggested something like 30 minutes per day. Or an hour per day, three times per week. This seems like a good benchmark, because this will be a long process. I can imagine there being days where I make decent progress in less than an hour, but that’s foolish optimism to assume it’d happen regularly.

I will have to write the words, and I will have to put in the time. So there’s the possibility of combining the two. 300 words or 30 minutes per day, whichever I reach first.

In reality, these will be guidelines. It’s not a science, and I have never done this before to know better. My hope is that these achievable minimums will encourage me to work on it beyond the 300 words or the 30 minutes each day. Momentum building over time.

The purpose is to have measurable ways to ensure I keep taking steps toward my goal. Perhaps as I get further into it, I’ll know what makes more sense, and what works for me. I can imagine the most difficult part of setting these daily goals to be holding myself accountable.

In the past, I tried writing a book called The Emperor’s War, but got stuck in a loop of editing. I had something like six chapters, and spent a lot of time revising them again and again. Trying to make them perfect. Forward progress was minimal. To keep from repeating myself, I want to set another guideline: keep writing forward. I’ll make good progress if I don’t allow editing until I’m done with the first draft. I can find out what the story is before “refining” it.

I now have a general outline of the story, and a glimpse of how to begin it. But there’s an uncertainty of how to actually start the writing. How do I begin it in a way that makes sense, introduces the world and characters, and doesn’t feel too abrupt? I have a scene in mind, but it needs some setup to not feel jarring. I’ve pondered these ideas lately, but the words are still elusive.

I spent most of yesterday mulling it over, and subsequently putting it off. Around 1am, I found the motivation and then hand-wrote two and a half pages. It was nothing like I expected, and I couldn’t have predicted what it would look like, but it was something. I’m okay with how it turned out.

I aim to write more today, but the idea of starting again is daunting. I don’t know what I’m doing. I’m also afraid it’ll turn out like shit. So I put it off some more. This post is a by-product of that procrastination. Nothing like a goal to help motivate you to accomplish everything else on your TODO list.

Anyway, I need to get to the writing and stop putting it off. It won’t be what I imagined, but it’ll be better than nothing. Forward momentum to get a first draft, and then will come the editing to clean it up.

The Downfall Of Formats

During 2015, I wanted to spend more time at home, and cultivate creativity there. Because I’ve enjoyed writing since I was young, I aimed to write more consistently. The frequency with which I’ve published blog posts this year is a signal of my progress. I’m proud of this, and hope to continue this trend next year as well.

My second goal has been to preserve my older writings. What does that even mean? For physical writings that exist on paper, it means digitizing them into a format that has the potential to survive technological upheavals. For writings which are already digital, it means rescuing them from the graveyards in which they’re currently trapped.

On this front, I’ve started preserving my early poetry, and typing up hand-written pieces. Going through this process has brought to mind why this is important to me. Bear with me; this is a weaving exploration of these goals and other topics. I won’t apologize, however. Life is not straightforward, so neither can all stories be.

The Early Software

I first wrote on computers with Microsoft’s operating system, software, and file formats. The first piece I remember creating for school was an article on space. I wrote it in Microsoft Works, and the format is .wps. I spent most of my time, however, using Word – particularly for my early poetry – and that format is .doc.

Word worked really well. I was able to focus on the content and even style the documents easily. It had a lot more features than Works, which was another draw. My school’s computers had Word, which meant I could use a single program in multiple places. That was convenient.

I played around with Corel WordPerfect, but it didn’t catch on. Using another text editor like Notepad never occurred to me. Notepad had zero features compared to Word. Even line wrapping was a pain in the ass.

At home, we had a single computer in the house. The entire family would get time on it, although I’m sure I took up the lion’s share. After PDAs came out, I wanted one badly. Having one with an external keyboard would allow me to write more often and easily. I wouldn’t have to share time on it, nor would I have to type up things originally written by hand. I pictured myself using it all the time. Ahh, to dream. I never did get a PDA, and, as you might have guessed, my life has been a complete train wreck ever since.

Occasionally, I backed my documents up on floppy disks. To back up a piece I wrote about the Titanic, I had to split it onto multiple diskettes because it was too large to fit on a single one. But don’t let me fool you, the images I added to the file were the main culprit. It’d take a large amount of text to fill a floppy disk, and I’m not prolific enough for that.

Enter the Web

I recently posted the story of how I became a web developer, which recounts how my love for writing lead me to my profession. Along with creating my own websites, I looked for other sites I could also use for writing.

Writing.com was a big one. It was a great place to find new things to read, and receive feedback from others. Eventually, I got banned for trying to exploit a loophole on the site. That hurt. A lot. It wiped out all the reputation I’d built up on the site, and I couldn’t connect with people I’d met there. That site later went to crap. I’m not saying that happened because I got banned, but that’s kind of what I’m saying.

I learned of Xanga and used that a decent amount. Other friends like Zach and Fergy had accounts too, and we’d post there with all our latest happenings. I also played around with phpBB as an online bulletin board for chatting with friends. From college onward, I have used other programs to compose and store my writings like OneNote, WordPress, Google Wave, and, most recently, Evernote.

Left Behind

All in all, I’ve used a decent number of applications. My experiences with them over the years have been enlightening. I’ve experimented with different software and workflows, which has helped me find what works for me. It’s also brought to light some problems.

Remember the space article I wrote in a .wps file? Sadly, my latest copy of Word can’t even open it. Microsoft has already abandoned one of its formats. An open source alternative called LibreOffice can open the file, so I’m still able to access it. For now.

The majority of my early writings were .doc files, and they’re still accessible today. Oddly, some of the files don’t render properly in newer versions of Word, LibreOffice, or Google Docs. This makes it a bit challenging to read through them today.

I hated Apple even more than I hated Microsoft, so I would have never expected this, but I’ve switched operating systems for my daily computing. Software for web development sucks a lot less on a Unix-like platform like OS X, even though it’s not perfect. Switching OSs has lead to my decreased dependence on Microsoft’s software. Now, I don’t have a copy of Word on the computer I use most often.

What about those early websites I created or used? Realm of Aaxiler is dead. Scrawlpoint still exists, but has been defunct for ages. It limps along until I decide to eventually pull the plug. This blows my mind: even my own sites didn’t survive the test of time. I lost everything on Writing.com. At some point, Xanga wiped out a lot of content. Fortunately, I was able to export my stuff before that happened. Not a good track record with these sites, right?

And the more recent pieces of software? Google Wave was technically interesting, but died out pretty quickly. Google shuttered it years ago now, taking all the content with it. I had OneNote installed on my Windows machine, but that didn’t seem a good option after switching operating systems.

I still use Evernote and WordPress. Evernote is for quickly capturing ideas and notes. I publish my finished pieces to WordPress. Another system I’ve thrown into the mix this year is everything, which is where I flesh out and edit my writings before publishing them.

The Hard Lesson

My main takeaway from using all this software is that letting someone else control or host my content is a poor policy for making it accessible later. Distilling this a bit more:

Software evolves at breakneck speeds and all else is forgotten.

My second takeaway was the slow realization that my creative works are split across many pieces of software and data formats. Each of the applications and formats is a liability. This concerns me, and I don’t like the risk it brings.

One might argue that the content isn’t valuable if I haven’t touched it in so long. And if it were important, wouldn’t I keep it up to date with new formats and new software? Except, this has no analog on paper. I can write on whatever paper I want, and still be able to read it in 50 years. I don’t have to transcribe it every decade or two so that it remains accessible.

Sure, I don’t need to open writings I created 15 years ago, but I like the idea of it. It’s nice to come across pieces later in life, and feel nostalgia for your past. I want a breadcrumb trail of my works to look back on and see what things were like then. There’s also a chance for serendipitous moments when I reconnect with ideas from earlier days.

These lessons are my main motivators to preserve my older writings. I know, I know… I’m a geek. Good thing I’m an adult, and can spend my free time however I like.

The Right Medium

Earlier, I mentioned that my writings are trapped in graveyards, and the preservation I do now should be aimed at surviving technological upheavals. How can I accomplish this?

Choosing the right medium is paramount. What program, service, or format do I use? This is tricky. I want to access the writings today, as well as at some point in the unknown and distant future. Software has the pernicious tendency to rot, but file formats rot as well.

Any format might seem like a good idea, at least initially. Only later would that choice prove dangerous, when it’s no longer possible to open a file. Programs must support reading, displaying, and writing the format. When the format loses enough popularity, software updates will remove support for it. Even the most prevalent formats will fall out of style and be replaced by newer ones.

Software is generally a form of vendor lock-in. Companies invent their own formats, APIs, and syncing mechanisms. Along with being proprietary, they’re often not interoperable. You place your data in their vault, and there it shall forever stay. Graveyards growing larger by the day.

Each program also has limitations and a lifespan. It won’t be around forever, even if it’s hard to imagine now what would take its place. Ten years ago, I would have expected to still use Windows, and to have Word installed on the computer I use most. That’s not the case, though.

Evaluating Formats

I’ve used various formats, and have writings stored in each of them. My goal is to choose a single one for long term use. This way, I could confidently preserve my existing digital works, and have a solid foundation for backing up other written pieces.

Realistically, choosing just one format itself is risky. I should build redundancy into my process. If my content is stored in multiple formats, it has a better chance of surviving. Picking one format as the source, and then another format or two as fallback would be smart.

To choose, I need to evaluate the options and see what software and formats are suited to this archival purpose. I guess I need some ground rules too. These will allow me to compare formats, and find what is most sensible for my needs.

The format must be:

There’ll be personal preference that gets mixed in here too.

How About Services?

I’m hesitant to heavily invest in new services but if something has the right qualities, I’d consider it. If I consider a service, there are some additional rules.

  • I must be able to export my data.
  • The data export must be in a common format.
  • I must not rely solely on the service’s continued existence.

The third bullet point is most important. I won’t put all my eggs into one basket. All services have uncertainty about how long they’ll be around. That’s when vendor lock-in really comes to bite me in the ass. If I rely on one too heavily, and they shut down, my workflow could be impossible to continue. This is an enormous hazard over the long term.

Let’s Go!

Now we’re onto examining the options and deciding whether they’ll work. If not, I’ll give reasons as to why they get ruled out.

What About Word?

Microsoft doesn’t support the .wps format any more. Eventually, I’m sure the open source software that supports it will cease to. This format is ruled out immediately.

Many of the files I’m concerned with preserving are .doc. Does it make sense use it as the format for the rest of my writings?

The .doc format is binary, which means I need special software to able to work with those documents. It’s not plain text, so I cannot edit it with a basic text editor. The format is also largely proprietary, and Microsoft controls its destiny. Microsoft has made the specification available since 2008, but they still don’t describe all its features. People have reverse-engineered the format, to create other software that works with it, but this is not a format that meets my criteria above.

Without software which knows how to read .doc, my content is inaccessible. Microsoft has created other formats to take its place. In another 10-15 years, it might not be possible to open these files. Or, if it is possible, it could be quite the hassle. Similar to what’s happened with .wps.

So what about something like the .docx format? It’s newer, and has been made into a standard. The latest versions of Word default to this format. Quite a few programs support it, and it’d likely be straight-forward to upgrade my .doc files to .docx. Since it’s backed by XML, the format is, in a way, plain text. But that XML is then zipped, which makes it binary. The advantage is that, even without Word, I ought to be able to extract the content.

I’m not excited by the prospect of tying myself to an XML-based format, even if it is plain text. XML isn’t easy to write in, without software that hides the XML from you, like Word. And using Word would makes me reliant on a proprietary program bound to a single company.

As I mentioned, I don’t use Word much these days. Why bother trying to get myself back into using it? It costs decent money to use and upgrade. It also feels awfully heavy-weight for the writing I do. Sure, there are open-source alternatives that support .docx, but I’ll pass. There are other options left to explore.

What About PDF?

When Adobe’s document-presentation format first came out, there wasn’t an easy or free way to create a .pdf file for my poetry. It was also a proprietary, closed format. Adobe made it an open standard in 2008. Since that time, there’s been an explosion in the amount of software that works with PDFs. For example, it’s easy today to print a PDF from a web page.

Since it is an open standard with a lot of support, .pdf looks like a good option. Except PDF is a weird format. It’s easy to create, but hard to edit. It is well-suited to viewing works, like a hard copy would be. But how do you easily edit a PDF document? That’s a rabbit hole not even I want to peek in.

Since it’s easy to create PDFs from other formats, I will consider it as one of my fallback options. I can use it to back up the final product, since it’s good at preserving the presentation. But I do not want to author works with it, or use it as my system of record.

What About Evernote?

An obvious candidate for authoring and backing up my writings is Evernote. I’ve used it constantly over the last several years. I even pay for the Premium version. It’s particularly adept at taking notes on multiple devices. It has plenty of space, as well as note history. It’s software that’s made for this stuff.

But Evernote uses proprietary software and formats to store the data. My experiences with it leave me wary of depending on it heavily. Some are already calling Evernote the first dead unicorn. I don’t know if that’s true, but I’m sure Evernote as a company has a limited lifespan. The service is the software, and it won’t be possible to use the Evernote software once the company shuts down. That rules it out as a format or writing preserve.

What About WordPress?

WordPress is another application I’ve used for a long time. It’s great at hosting content. The content is mine, and I can export it easily.

WordPress does, however, store that data in a database. The database makes it easy to dynamically build a site, but it’s not a plain text format I can open up with any text editor. Then, the nature of it being a web application means I need a browser and Internet connection to use it. Those are dependencies I don’t really want.

If hackers gained access to my site, I could lose everything. Fortunately, WordPress has plugins to automate data backups to other services like Dropbox. This helps mitigate some of that risk, but it’s just not designed for the kind of use I want.

I plan to continue hosting my blog on WordPress, especially since I’ve automated publishing my finished pieces. But I still have to find something else for preserving and backing up my writing collection.

What’s Left?

I’ve covered what formats and programs and services I won’t use, for various reasons. But what’s left? What can I use? I suppose I should tell you that this post hasn’t been me walking myself toward a decision. It’s been me verbalizing decisions I’ve already made. Trying to understand myself a bit more, and provide insight to anyone else interested. I’ve already settled on a format to use, and have been successfully using it for a majority of this year.

My format is plain, ol’ text files. For styling, I use the Markdown syntax. To indicate this, the files have a .md extension. Markdown draws inspiration from how plain text emails have been formatted over the years. There are conventions on how to indicate things like emphasis, links, quotes, code blocks, and headers. Best of all, I only use regular characters to mark up my content, and these characters are easy to type on any keyboard. This makes it incredibly easy to start and continue using.

Markdown is also a program which converts this plain text syntax to HTML. I’m currently writing this post in Markdown. I’ll later run it through some code that converts it to the HTML you are now reading on this blog.

How long has Markdown been around? Since 2004. That’s not very long, in the grand scheme of things. But it has a lot of pros. It is plain text, well-supported, open, very easy to write in, platform agnostic, easy to back up, easy to version control, and I can create these files on my computer, without needing an Internet connection. Markdown also has a boatload of support on the web.

One downside may be that there are quite a few different implementations of the HTML conversion. The original syntax is ambiguous in certain cases, so programs differ in subtle ways. There are other things the original Markdown syntax doesn’t cover, and extensions of the syntax have popped up, which help to make it more powerful and comprehensive. These extensions might conflict with one another, though.

The awesome thing about Markdown is that even if the software to convert my documents to HTML disappeared, the text would still be usable. Any text editor can open these plain text files. And the syntax itself is a good indication of what the desired styling is. This makes me confident that Markdown can stand the test of time.

Since Markdown (and its various flavors) have a lot of traction, there exist programs to generate HTML pages and PDF documents from Markdown-styled text. That’s a big win. Creating those fallback documents containing the content and style is suddenly much easier.

Another huge benefit is that I’m not tied in to any proprietary pieces of software, or services which could shut down, and the syntax is free to use. I don’t need any special software to use it.

To write my pieces, I’m quite fond of using the free and open source vim. I’ve used it for years to write code, and it feels natural to extend it to my prose as well.

What About Plain HTML and CSS?

Markdown converts to HTML, and that page can then be styled using CSS. Why not cut out the Markdown middleman and go straight to HTML and CSS? They’re also open formats, plain text, platform agnostic, and all the rest.

HTML and CSS are even more widely supported than Markdown. Think of how many billions of web pages use HTML and CSS. They are technologies that will have a long tail. You can even view the very first web page ever created, and it renders perfectly in modern browsers. That’s incredible, considering it was first created in 1991.

I could do this, certainly. But typing the HTML while I write would feel clunky. I’m not trying to write a web site as I flesh out a blog post. I’m trying to work on the words themselves. Markdown seems like a nice compromise. I can work on the content, easily add some markup as I go along, and then convert it to HTML when I’m ready to publish. At that point, I can consider other details of styling, if the document requires that attention.

The HTML output from Markdown is itself another fantastic fallback document. It essentially comes along for free, thanks to the qualities of Markdown.

The Backup Strategy

Additionally, I need a process for backing up the writings. I want them safe, even if it’s years before I access them again. A successful backup strategy would allow me to lose one copy of a writing, and still be able to recover that document. This way, an accident, user error, or hardware failure wouldn’t mean a piece disappears forever.

In reality, the best backup strategy is actually multiple, redundant, backup strategies. Having many copies in many locations is even better for covering my ass.

My hesitation about services dissipates when I don’t rely on them too heavily; when a service isn’t a single point of failure. If I use a service as a backup destination, I feel better about it, because it’s one of several.

I love services like CrashPlan and Dropbox, because they’re transparent. I can use both at the same time, seamlessly. They back up files on my hard drive, which is about as unobtrusive as you can get. Backup strategies are fantastic when you can layer or combine them. For instance, it’s easy to throw in another option like Apple’s Time Machine, without changing anything about the others. They just work like normal.

I could even consider Evernote as a backup site. Evernote documents are HTML, so I should be able to take the HTML output from my Markdown piece, and stick it into a note. I’ll have to look into automating this process in the future.

Karla suggests I should print out hard copies and store them in a safe deposit box. Storing backups away from the home is a good way to keep a natural disaster, burglary, or fire from wiping out my data, but I wonder what the costs and effort associated with that are. Like she’s said, it’s not as elegant as the other options, but it is certainly interesting as a last resort. It could be the fallback to all my other fallbacks.

Version Control

For version control, I use git. It’s been around for 10 years, and has strong support around the globe. I’m familiar with git because I use it to version control software, and it turns out to be a great option for putting plain text writings under version control too.

This allows me to keep a history of changes I make to pieces. And git gives me the ability to push my writing repository to multiple places, like BitBucket or GitHub. Each of these places has a full copy of the history, which means they can serve as backups too. This is yet another way to back up my content, along with keeping track of my changes.

Conclusion

I’m using plain text, Markdown files to store my writings. I write using vim. I can convert them to HTML and PDF pretty easily, as fallback formats. I store the Markdown writings in a git repository, and these all get backed up to BitBucket, Time Machine, Dropbox, and CrashPlan. This feels like a robust way to back up my digital writings. It’s something that also ought to scale as I back up more writings in the future.

It’s been helpful to think through these decisions, and I hope this might help someone else. I’d love to hear your thoughts, if you’ve considered these topics at all. I’m sure there are things I haven’t considered, or things I’ll only learn down the road.

I’ve got other goals for writing-focused, web-based software, which I hope to explore. Writing this year helps give me more experience to use when I undertake those software projects in the future.

Thanks for reading, and here’s to writing!

What Drives the Worlds of Fiction?

The Lord of the Rings has a vast world, but an even richer history. This story and the related history are people-driven. The world is subservient to the actions of the beings within that world. What do I mean by this? It’s apparent when we look at Middle-earth itself. The areas of the world take on the characteristics of those dwelling there.

Greenwood the Great became Mirkwood after the Neromancer took up residence. Rivendell is rich, deep, and secure, just like the elves who created it. Lothlorien is golden, dreamlike, and beautiful, as are Galadrial and Celeborn. The Shire is quiet, peaceful, and full of good food, like the Hobbits. Mordor is wretched, ruined, and powerful, because Sauron imparts his will upon the land. The Old Forest is odd, just like its master, Tom Bombadil.

The stories of Middle-earth reflect this as well. Calamities are brought about, most often, by beings. Beings have more a chaotic, unpredictable, awe-inspiring role than does nature. The planet bends to the forces of the characters. This is interesting in that it’s nothing like the world in which we live.

We project the fortitude and resilience of the American people on the Rockie Mountains, but we surely did not make them rise up. Hurricanes, avalanches, and earthquakes happen regardless of the personalities of those living in the area. In fact, for us, the lay of the land can influence the people. Storms cause damage which impacts citizens. Forest fires cause us to evacuate our homes. Mountain ranges feel comforting. Does nature help shape who we are?

Let’s consider another fictional world – that of Dune. It contains humanity and political machinations, but it’s all predicated on a harsh and powerful world. The people bend to the desert; the economy is driven by the spice, “the most important and valuable substance in the universe”. Civilization is built on the back of the ecology of the physical world, and it deals every day with still suits, worms, and sand. This is a reversal of the approach taken in Middle-earth. It models more closely our actual world.

Is it a view from bygone days that all inhabitants of an area are the same? A sort of stereotype of a population. We’re smart, brave, and persistent. We’re American. We conquer the challenges we face. Outsiders are fearful, cowardly, and wrong. They’re foreigners. Their personality brings about the disasters they face. This mindset has no basis in reality. People of all sorts live all over. The brave and the cowardly live side by side in every country.

I can see why stories like those of Tolkien are popular. They give us a taste of what it’d be like to live in a fantastical setting where personality determines nature. It inflates our role in the world, and makes us believe we have more control. We anthropomorphize our surroundings based on our qualities. It’s a change from our everyday experience where we’re subject to the vagaries of Mother Nature.

Are there names for these approaches to portraying and fictionalizing the world? People-as-servant versus World-as-servant?

This idea recently came to me as I thought about potential stories. I’m influenced by things like Pikes Peak, which I lived near for four years. The Waldo Canyon fire also left an impression. The groups I imagine are impacted by the world and that drives action just as much as conflict with other groups. It’s fun to compare my thoughts to approaches other authors have taken, especially those who have created fictional works so popular. I’d love to hear your thoughts on this subject.

All Software Rots

Software is an interesting creature. It’s easy to imagine that a piece of software is, at some point, completed, and goes on to live and run for eternity. The group who wrote it retires happy and comfortable, based on the success of that software.

Except, this is not reality. Over time, software degrades, runs more slowly, or doesn’t run at all. Putting software out there and expecting it to be useful in the future means we’ll have to work at it. It’s a consideration I’ve only recently realized. What causes this?

A technology stack involves a lot of moving parts. Hardware, firmware, drivers, operating systems, libraries, frameworks, browsers, APIs, and applications are all in this mix. There are other things I’m not even aware, I’m sure. And these stacks support the existence, operation, and functionality of an application.

Each of these components has a purpose, design limitations, bugs, shelf life, and life cycles. Security vulnerabilities, performance issues, and annoying bugs are likely present too, perhaps to be discovered decades down the line. Software written to run on systems in the 1960s have different stacks than those written in the 90s than those written today than those written in a few years.

When one piece of the stack goes extinct, the change ripples upward. Have you tried using games or other applications from a decade ago? It’s not easy. Large programs with many dependencies are at the most risk. More pieces can rot out from under it, ruining the beautiful cathedral which many human-hours built.

Services are no exception to this rot. Take Heroku for an example. Developers can deploy their web application without having to worry about the nitty gritty of configuring and managing a web server. The tradeoff is buying into the platform Heroku provides, and their company. These are also vulnerable to rot.

Note: I use the free tier of Heroku, so I can’t really complain. It just happens to be the Platform-as-a-Service I’m most familiar with.

Even if you don’t make any changes to the functionality of a web application, you’ll have to work to maintain it. It won’t run for 10 years on its own. These platforms will upgrade their software, practices, and capabilities. Tech stacks will fall as others rise.

I use the word ‘rot’, which has certain connotations. But it’s similar to the rotting of a house. Termites just do their thing, and it results in the foundation of a house changing in ways that are structurally problematic. It’s not a moral judgment; it’s neither good nor bad. Similarly, a tech stack rotting is neither good nor bad. Developers, software, and hardware just do their thing, and it results in the foundation of an application changing in ways that are structurally problematic.

Dynamic sites have more risk of rot than do static sites. The dynamic part means there’s software, production code, and databases. Security holes, bugs, and cosmic rays will have more chance of impact. There are more moving parts that need tending to.

Sites serving up static assets like HTML, CSS, and Javascript have a better chance to survive into the future. There are fewer moving parts. Static website generators are quite popular today, for many reasons, including their speed, costs, and ease of use. They’re curious to me because the output has the potential of a long lifespan.

The generator itself can be subject to rot, but that doesn’t impact the site you’ve already created. You can switch out the toolchain, and, as long as the site created is the same, the code is transparent.

I’ve currently got The Mechanism Collection hosted as a static site on GitHub Pages, for free. I get to piggy back on GitHub’s infrastructure, but I could take the static pages and host them elsewhere, if needed. Perhaps the Pages infrastructure will rot in the future.

Static sites are something I’ll explore more going forward. Especially for hosting writings, like this blog. I don’t author my content in WordPress anymore. The comments here don’t get used much, because the conversation happens on social media, where I share the links. There are 3rd party services for comments, although I’d be wary of using one. The blog itself could be static, and visitors likely wouldn’t even notice a downside. The benefit of speed would be noticed and appreciated, however. Keeping URLs to posts the same would make the change even more transparent.

Sentient machines are a lofty goal, but what happens when there’s a zero day that turns that ‘being’ into an intelligent botnet? Rot is job security for software engineers. We have the opportunity to create lasting works of code. We’ve got some work ahead of us though.

Why I’m Hesitant To Use New Apps

I’ve noticed lately that I’m hesitant to install new apps on my devices and use new services online. I’ve distilled some of the reasons why this is the case.

Yet Another Account

If I have to create an account and new password, I think twice. I’ll have to remember another set of credentials. A password manager like 1Password, makes this less troublesome, but there’s still some amount of set-up.

What about when they authorize through another service like Google or Facebook? It’s nice that there’s not another password to remember, but will they require access to additional information from those accounts? If it’s more than my email and name, I’m skeptical of what they’re using it for.

Data Breaches

If they get hacked, my credentials could be stolen. One hears of huge companies getting hacked weekly, so it’s not a large jump to assume that smaller services will eventually be hacked too. Especially as their popularity increases.

If you use the same password across sites, one site’s breach can make other accounts vulnerable. One of my favorite features of 1Password is that it generates random , unique passwords. If this practice is used everywhere, a single password being stolen won’t affect your other accounts. That’s a godsend.

If the service contains other sensitive data, like billing, financial, or personal information, them getting hacked is even more of a disaster.

Information Leakage

If it’s an app on my phone, will it ask for access to sources of data like location, photos, or contacts? Some services have a legitimate use case, but it’s not always clearly communicated. This makes it hard to tell what an app will do when you grant access to a resource. Especially if they barrage you right after installing and first opening the app.

Fortunately, some developers have improved how they ask for permissions. This helps separate an invasion of privacy from what’s actually useful.

Trusting a Black Box

Software that’s closed source means no one can investigate the code to see if they’re being honest. Without this transparency, we’re stuck with believing what the company tells us. Omissions, incorrect statements, and outright lies are obvious sources of concern here.

Large corporations like Microsoft, Google, and Facebook have been exposed for doing questionable things with data they’ve collected. It’s even trickier when the company isn’t well-known.

Even More Notifications

If they’ve got a marketing team, I’m going to get a deluge of emails after I sign up. They’ll be emails to help on-board me, re-engage me after a few days use, try to convert me to a paying users, retain my dollars going forward, and generally market new features and other stuff to me.

Do I want to fill up my inbox with additional, distracting material of marginal value?

Push notifications on mobile might be even worse with all the banners, badges, lock screen appearances, and items in the notification dropdown.

Acquisition Doom

If the service is popular enough, will they get bought out? If so, will my data be owned by some faceless gigacorp? What will they do with it? Leak it to other affiliate services and do who-knows-what kind of data mining on it?

Or maybe the service will be shuttered. Great, I bought into an app, used it a lot, and now it’s gone down the drain.

If the service is kept alive, will it be in maintenance-only mode? That’s not such a bad option, but it’s typically a signal that the team and application are walking the plank. The only unknown is how long that plank is.

Monetize It All

After an acquisition or IPO, will they finally try to monetize the service? If so, what path will they choose? The seemingly-only option of advertising? I’ve reached the limits for my toleration for ad-supported services.

I have paid accounts for quite a few services, but I’m sure there’s an upper limit on how many, different services I’ll pay for. Paid accounts seem to be a hard sell in the consumer space anyway.

Even worse, will they turn my usage data into a product to be sold to anyone with a buck? The legalese-ridden terms of service and privacy policies give services enormous leeway on what they can do with the data they collect from you.

Finite Lifespan

Nothing lives forever; even if it’s enormously popular. It’s as true for companies as it is for people. Xanga was big and MySpace was even bigger. They’re still alive, sure, but they’re past their prime and hobbling along. Twitter and Facebook are the social-media-du-jour, but who will fill that role (or invent a new one) a few years down the line?

In reality, the incumbents aren’t the most worrisome thing. That title goes to the startups that rise and fall by the day. Startups live to be acquired or IPO, or die trying. Putting my trust in a service seems silly when they’ll be acqui-killed, or explode in a ball of flames once their funding runway ends. Hypergrowth seems a good model for the people running the company, but not those whom that company supposedly serves.

Data Graveyard

Using proprietary formats or giving up control of my data is unnerving. Sure, the service allows me create and put data in it, but can I ever get it out? If the service doesn’t have a way to export or backup my data, then I don’t have any control over it.

Only In; Never Out is an awful data model from a consumer standpoint. Perhaps, as the service grows, it’ll add on features to get my data out, but if it doesn’t already exist, don’t count on it.

Combine this with the finite lifespan and possibility of acquisition, and it’s risky to give sole control of my data to new services.

Conclusion

These topics run through my mind each time I consider signing up for or paying for a service. There are, of course, apps I use and find incredibly useful, even if they have downsides.

Loads of startups exist out there, with more to come. But considering the above criteria helps separate the wheat from the chaff. It’s a way to know who to support with my limited time and money.

How I Became a Web Developer

Transitory periods are perfect times at which to reflect on where you’ve come from, where you are, and where you’re headed.

Learning the Web

In 7th and 8th grade, I got interested in web development. A friend named Matt Cotter created some awesome graphics and web sites. I immediately imagined making a site to host my writings and be the home for my online presence. At the time, I went by the pseudonym Aaxiler (uh-zay-ler). Matt taught me the basics of HTML while we rode the bus, and later gave me an intro to creating graphics. That’s what started it all.

In the beginning, I used FrontPage to learn what a web site was. I mashed up templates and construction gifs and fonts and colors and sizes and got a little website for my writings put together. I wonder if I still have these pages? They’d make your eyes bleed, but I had a lot of fun creating them. The WYSIWYG aspect really helped learn the basics. Table-based layouts were, of course, the way to go.

As I became more familiar with the web, I created other sites. Realm of Aaxiler was pretty important for me. It was the second incarnation of my writing and online profile. I played around with a pirated version of Photoshop and learned about graphic design. I used Macromedia’s Dreamweaver and Fireworks too. I would post journal entries called Chronicles with some regularity. I learned what it was like to maintain one large file for all these posts. I even hosted it for free on Angelfire. That was glorious. Netscape Navigator was one of the coolest browsers out there. IE sux!

In high school, I took a web design class, where we used FrontPage to kick so much ass. I didn’t learn a bunch of new stuff there, but it reinforced what I already knew. At some point, I pictured myself growing up to be a CGI programmer. CGI programming was the only thing I’d heard of that allowed people to make dynamic websites, like what I wanted for my writings. It also seemed a good way to create text-based, adventure game sites, which also interested me. To this day, I’ve not actually done any CGI programming, but it was a good goal to work toward anyway.

Enter PHP

I kept on learning. I made sure my XHTML was compliant. I learned CSS. I looked into what kind of programming languages I could learn to make those dynamic sites I was so curious about. PHP won out because it was free. Free was very important. My time was free, but hosting or servers could be expensive. I could write PHP on my computer, use a free FTP client to upload the files to a cheap, little, web server, and run the site from there. That was a hell of a deal. I want to thank my parents for footing the bill for my programming!

I read several books on how to program in PHP, and how to create dynamic sites with it. Later on I got a book on DHTML so I could make sweet stuff happen on a page using Javascript. It was a good time on the Internet for copying and pasting Javascript snippets to add falling snow to your page. So dynamic.

Toward the end of high school, Realm of Aaxiler fell into disrepair. But, as I learned more about PHP, I built this new site called Scrawlpoint. I built it from the ground up before I knew of anything like web frameworks. HTML, PHP, CSS, and SQL all lived in the same files. I’d not yet heard of concepts like models, views, and controllers. Whatever, it got things done. I learned a lot. Around this time, creating websites clicked more with me.

This was all fueled by my love for writing and wanting a place to host it all. With how much I enjoyed working on these projects of mine, I knew I wanted to go to college for it. A computer science major was an obvious choice. The career outlook for this field also looked solid, which was a bonus.

The Ol’ College Degree

I went to The Ohio State University and majored in Computer & Information Science, with a minor in Business. My degree focused more on software, because I didn’t find hardware particularly interesting. During my time there, I made a few websites for other people, including a photographer, a professor, and a band. Even got paid a bit!

I worked on Scrawlpoint for the first couple years of college as well. I built some cool features, and convinced/harassed some friends to sign up for and use it too. Adding features to an existing site gave me experience with maintenance and enhancement. One doesn’t do this much as a student when code bases are small and ephemeral.

Over a few of my summers, I had software internships which gave me additional knowledge of web development, and software in general. It was awesome to get paid to code!

I was fortunate to do these internships. I knew others who would graduate without having this kind of practical experience, which seemed risky. Might you not like it? Theory is also different than practice. How do you find what niche of software you’re interested in?

These internships were instrumental in reaffirming my interest of and potential in the software field. The web still had a sweet spot in my heart, too.

Jumping into Industry

After graduating, I worked for Lockheed Martin in Colorado Springs as a Software Engineer. It was a good place to start, considering the state of the economy in 2009. I met some great friends here, and got exposure to large, legacy, embedded systems. Moving to Colorado and being near the mountains is one of the best things I’ve ever done.

The programs I worked on at LM didn’t involve web development. My passion lay there, however. After several years without developing for the web, I wanted to get back to it. It was an itch I had to scratch.

Lots had changed, including the software landscape, and my skill with software. I searched for what to teach myself, because I’d heard of web frameworks which would help out a lot. I knew what kind of spaghetti Scrawlpoint was, and was eager to see what newer practices could do for a site.

Re-Learning the Web

Ruby on Rails won out because of its maturity and the fantastic community. It’s easy to start with Rails, because of the quantity and quality of materials out there for beginners.

I worked on small, side projects. Web development is a daunting thing to learn, because there are so many facets to it. Discerning what magic is Ruby’s and which is Rails’ also takes some time. But you can learn things in chunks, which is how I eventually did it. Trying to learn everything at once melted my brain. Learning things modularly helped encapsulate knowledge. Kinda like OOP.

I got involved with a developer group in Colorado Springs called Springs.rb. This group of fantastic people was a force multiplier. If you’re new to the scene, I’d recommend participating in the community. You get to broaden your experiences, see what others are doing, and network. I recommend it even if you’re an experienced developer. If you’ve gained a lot from the community, it’s nice to give back and help it grow.

In 2012, I gave a talk on how to get started using vim. It was stressful to create the presentation, as well as to give it, but I found I like public speaking. Needing to know my stuff when I present helps me learn the topic better, which is itself addictive. In that way, it’s similar to writing.

I went on to organize Code and Coffee in Colorado Springs, after hearing about and attending one in Chicago. This weekly meeting helped keep up with other developers and maintain progress on my side projects. After I talked him into learning Rails, Chris Bachicha and I ended up doing C&C five days a week. That accountability and regularity really helped me keep on learning.

My First Web Developer Job

After a year and a half of teaching myself the web again, I started interviewing for developer positions. It was difficult to find a place that would look past the fact that I didn’t have professional experience as a web developer. My friend Scooter put me in touch with Spatial Networks. They were more interested in my potential and ability than my years of experience. This was refreshing! The personal recommendation carried a lot of weight, I’m sure. And a GitHub profile doesn’t hurt.

In July 2013, I started as a Software Engineer with SNI. I worked almost exclusively on Fulcrum, a platform for geospatial data collection. Some of the features I’m most proud to have worked on are webhooks and data shares. They were both technically interesting and challenging, and provided a lot of value for our paying users.

We rolled out a lot of other awesome features and improvements over the following two years. I didn’t have much familiarity with the geospatial industry, but there’s a lot of incredible stuff happening in that field. Location is important in many applications, so gaining experience here is certainly worthwhile.

The Fulcrum service is solid, and the team is wonderful. Getting to work remotely was also amazing. It’s here I discovered how much I enjoy working on server-side code. I also gained experience on the client-side, and deep respect for the people who make it look easy.

I’m grateful for all the opportunities, fond memories, and professional experience the Fulcrum team provided me. Working as a software engineer on the web has been a dream realized. I can’t express how thankful I am for them giving me that chance! Also looking forward to seeing what they do next.

Moving to Denver

Since my position with SNI was remote, I took advantage of the flexibility, in 2013, and moved to Denver. Several people I knew from Colorado Springs had also moved to Denver, and I’d gotten to experience it a bit through visiting. I could tell it had a lot of of opportunity in the social and professional arenas. The Ruby/Rails communities here are stellar. Tons of members, lots of activity, and great quality. I’ve lived in the area for about two years now, and it’s certainly been worthwhile. The tech scene is growing impressively, and there’s a lot of possibility in the area.

With the knowledge I gained with webhooks, I gave talks this year at both Denver.rb and Denver Startup Week. These were the first talks I’d given in a few years, but I found them rewarding. I enjoy the challenge of technical, public speaking.

The Path Ahead

Next Monday, I’ll start my new position at Cardfree. I’ll be a technical lead, which is very exciting. There’ll be a lot to learn, but I’m more eager than anxious. From my experience with mentoring and public speaking, I know I enjoy helping others learn and gain proficiency. Also invigorating is the opportunity to help influence the design, implementation, and roadmap for an application.

Additionally, over this past year, I’ve made progress toward my aspirations of writing. Software has, naturally, tied into this. Most of my blog posts this year have been written in and published through my everything concept. There are lots of places to improve it, which I will do over time, but it’s already been helpful. Getting back to the basics of writing regularly has been fantastic.

It’s interesting to look back on how my passion for writing and software started, and compare that to where I am now. I’ve been very fortunate to do what I enjoy. And I’m stoked to think of what potential the future holds!

Writing and software are inextricably linked for me. I look forward to discussing both more in future posts. If you’re interested in writing, software, or both, I’d love to talk!

Savagery

Savagery stood on a stool tonight.
Whooped and hollered with a noose at its neck.
Earth quaking, just teasing at the future.
Naught to do but tip the fellow over.

Streets as scars, crisscrossing and pithy,
artistically lashed into Her hide here.
Filled with feet stamping on the asphalt
to an anthem born of innateness.

Sweat still falling and dust now rising –
the embrace of a prophetic end game.
To beat out a rhythm that builds momentum
requires some sort of inspired madness.

Our gears turn a ferocious flywheel
to build up and pen up
the wailing and mesmerizing
dashed with recklessness.

Just wrapping paper over a gaping maw,
given away by the flutter of our breath.
Ripples and shadows hint at the truth.
Couldn’t keep calm holding a rapture in our chests.

No well-precisioned equipment on this block
to dampen that tremoring.
Just blood and flesh, and tempers flaring.
Can’t dress up an horrid truth like us, see.

But Savagery stood on a stool tonight.
Whooping and hollering with a noose at its neck.
The rage resounding until it’s a standing
wave deep in all our bones.