Proof of concept

So. I have a local version of my rails re-write of this middleman blog working. For various reasons I decided that going for full control made the most sense1, and thus I ended up with something that's mostly okay. It's clear that certain doors are open now that weren't before, but it's taken a lot of effort to get here.

One of the habits I wanted to train myself in is in learning to accept external code more readily. I think I'm mostly won on that front, but it's still not perfect. The time it takes to learn an API is not always trivial, and it's not clear when my own assumptions differ from those of the authors' whether I'm correct, or they are. Case in point: I wanted some way to slugify categories and tags, and so went looking for ruby libraries that enable that, and found friendly_id. It's pretty capable, but one thing I wanted to do was first_or_create_by_slug. After looking through the docs, then the code, for a solution that would make this possible, I started to open a new issue asking for a way to do this. I quickly realized that my request would be meaningless, and I was better off putting together a hack that addressed my own needs, rather than asking for a general purpose solution that wouldn't be a positive addition to the gem.

Would I have realized this if I had elected to write my own code, or would I have made some hack that got me halfway only for me to realize that it's completely infeasible?

I am certain that using someone's CSS library (in this case, Zurb's Foundation) was a step forward. I hate worrying about browser compatibility, and at the end of the day I simply want a vocabulary that allows me to express visual ideas in a flexible way. CSS is a nightmare to figure out from source; thus, front-end frameworks offer advantages through documentation, examples, and actually being tested by people who care.

Back to the main thread: I've sort of paused out. This is being written via a web page on my local computer, and… I added two-way data pathways (import/export) from rails so that I can import test data (== my old blog posts) and compose new posts that can then be slurped up by middleman. It's not ideal—it's not the hosted solution I alluded to in an earlier post—but it's quite similar to the "admin app for composing static pages" half-solution I sketched out. The interface, and codebase, are both things I feel comfortable working on, and some of the ancillary effects I was hoping to see have panned out.

That is to say, I'm seeing how I can better (solo) handle problems I haven't seen before (like, finding and using Foundation in the first place), and getting better at judging what is and is not worth my time, even when I don't always close the loop on this knowledge. And adding weird features for personal use—like a button to output a post to markdown—doesn't feel as off-putting to me now as it might have in the past.

On the other hand, I did spend too long getting this site's CSS re-written so I could get the form classes for free, so it might be that the biggest gain I've gotten is clarity. I can see clearly now in all the ways I'm doing things that aren't in my best interests.

But it's all so pretttttty, and flexible!

The wall, now, is that getting the proof-of-concept code/configuration for external hosting and e.g. blue/green is … not a priority anymore? I can output whenever I want, and I've found stopgap ways to track the things I want to say, and while they're not all going up on the web yet, I can see a path that will make that happen in due time.

  1. Namely, I want to extend the blog model in ways that aren't easily enabled by most blog platforms/static site generators, and the convolutions I could see happening in the near future were getting extreme.