Commonplace Book 9.4.2018

Hello my friends! This one is gonna be as concise as I can make it, but I’m giving you the best of the stuff I’ve jotted down since February, so it may be a little long. Fear not! It will be worth it and you won’t be waiting for near as long for the next installment.

This monthly entry is available as a newsletter, if you like that kind of thing.

“When I was a boy and I would see scary things in the news, my mother would say to me, “Look for the helpers. You will always find people who are helping.” ― Fred Rogers

Don’t Think Outside the Box—Find the Box. When faced with an impossible problem, identify the real constraints. Ask yourself: ‘Does it have to be done this way? Does it have to be done at all?’

Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius – and a lot of courage to move in the opposite direction. – E. F. Schumacher

Three questions to ask yourself:

  • What have I been obsessed with that feels unreachable?
  • What is my biggest fear if I stop reaching?
  • What would it look like to surrender?

Watching tech talks is great. Watching talks that are beyond what you understand is better. Rewatching those talks six months later is the best.

“Worry is inverted faith, faith in evil/harm instead of faith in good” – Florence Scovel Shinn

This is usually a quote about the definition of insanity, but I’ve been applying it to failure, particularly while I’m debugging: “Failure is doing the same exact thing over and over again and expecting different results”

The Steps
step 1: strike the word ‘productive’ from your vocabulary. it is evil.
step 2: always do your best. your best will change from day to day.
step 3: know what works and what doesn’t. know when you have energy and when you need to rest. learning this will take time, attention, and discernment.
step 4: drink a glass of water.
step 5: when you feel like you are getting nothing done, go back to step 1.

The 3 principles of software security according to Tara Lindsey
1. put a good lock on it
2. hire big burly men to stand on either side of it
3. put it under the bed

“A rule to live by: Don’t replace people with abstractions.- They’re not users, they’re people using tools to do a job.- The web is not made of content, it’s a collection of human ideas.- You don’t have a personal brand, you have a reputation.What are other examples?” Practicing Developer

“girls don’t want boys girls want single-player story-driven RPG’s with in-depth character creators and romance options.” –


if you stood in your own two boots, where would you stand? if you said it fully, strongly, clearly, with your chest, what would you roar? if you believed that you would always take care of you, that you could survive anything, where would you place your hands? and if you placed your hands there, could you do it with a smile? strength. (& a leo szn gift)

We outlived the future.
This is a good thing. I like it. I’ve outlived (space) 1999 and 2000AD and 2001 and next year I clear BLADE RUNNER’s 2019 and the rest. We’re barely two feet into the 21st Century and it’s all a blank sheet of paper from here. No maps for these territories. I like it. It’s freeing. Now we’ve gotten used to the speed of the 21C, we can all quit complaining about how near-future SF gets overtaken by the times so quickly and just swing crazily from here to 2101. I hope for, and fully expect, futures scenarios to get weirder and wilder, hyperlocal and supermodernglobal, very quickly. 2001 to 2018 has been the training ground for the New Next.
I’m looking forward to the New Next. I outlived the old future. Give me a new one to live for. Orbital Operations

Weekly Focus 2018: 9.2-9.8

    • LSQ
      • Issue production
      • Plan 2018-2019
      • Organize my posts to write
    • Storybin
      • New sprint
    • Studying
      • Rails Guides
      • Rspec testing book
      • Technical leadership book
    • Enrichment
      • PPY updates
      • Skyrim immersion post
      • Reading A Stirring in the Bones

The focus this week is on mostly the same stuff as last week, but with some adjustments and more clarity.

LSQ issue is done on Wednesday, so by the end of the week that will be fully put to bed. That opens up mental space for planning the next year.

Finally finished the dirt simple sprint for Storybin and now I can get more tests written. Changing to a 2 week sprint cycle will help me actually finish what I outline to do.

Along with that I have some formal Rails studying to do. The Guides are straightforward and I need to sit and read them and take notes, possibly with an eye to creating quizzes for myself and others.

The testing book and a book on technical leadership go hand in hand with that stuff and I hope the latter will also help me with LSQ management stuff too.

Last but not least is what I’m calling Enrichment. That’s the stuff that’s just for me and my own enjoyment and development. Reading Stirring so I can get my thoughts together for a short story. Writing my immersive Skyrim post. Getting all my “stuff” over here so the site feels more robust and lived in.

Of course as life goes on, I’ll be happy if I get half of all this finished.

Weekly Reads 2018: 8.26-9.1

FATFREE: The Low Fat Vegetarian Recipe Archive
Oh goodness. I just rediscovered the fat free vegetarian recipe archive. 1993-2007. There is zero site design, but this is a treasure trove of recipes. pardon me while I trip down nostalgia lane to 20 years ago when it was so much harder to be a vegetarian and this site was a life safer.

Is It Okay to Say “Hey Guys”? – The Atlantic
Sums up the struggle with the term and yeah, I’ve mostly removed the phrase from my vocabulary because it makes me uncomfortable at this point.

Katharine Hepburn: Leading Man
Oh wow. This gives me a whole new spin (and even more adoration) for Kate the Great.

Unethical programming – DEV Community 👩‍💻👨‍💻

Is Rails still relevant in 2018 ?
More than just an “Is Rails dead?” article, the author backs up their statement with a nice reasoning why Rails is still valid. A few philosophical points about developer lifestyle I disagree with heartily, but a good take otherwise on the current Rails/Elixir/JS pros and cons.

What Makes a Superhero a Superhero? | Luna Station Quarterly

A neuroscientist explains what tech does to the reading brain – The Verge
I pretty much want everyone I know to read this interview. The internet really is fucking up our ability to hold attention and view things critically. This is why I’m trying to read more articles, more long form pieces and spend less time on social media and its hot takes.

Design documents: maybe the only record of what the hell you were thinking — No Idea Blog
I’m a sucker for clear communication on projects. Design docs feel like an extension of, or preliminary to, writing tickets. Similar to a spike.

Stop future proofing software – George – Medium
Mostly agree with this article. Reducing future-proofing, but keep things flexible. I only disagree with the idea of designing for current and next year, as part of the reason for designing for present and last year is to make sure everyone gets to come along for the ride, not just those with the latest and greatest.

What would cities look like if they were designed by mothers? | Christine Murray | Opinion | The Guardian
A call for architects to think more diversely when designing public (and private) spaces that should accommodate folks who aren’t all able-bodied and without children.

4 practices for better code – DEV Community 👩‍💻👨‍💻
A succinct overview of some basic best practices.

Opinion | The Gift of Menopause – The New York Times
An outstanding piece on growing older, passing menopause, and letting go of a lot of the garbage we carry with us every day.

How I learned to love unit testing – DEV Community 👩‍💻👨‍💻
Because I’m still trying to learn to love unit testing. I am on board with its power, but learning to actually write tests is still challenging.

Logged off: meet the teens who refuse to use social media | Society | The Guardian
I don’t even have anywhere near the pressure these kids do to be on social media and I feel this kind of grind anyway. More and more I consider closing it all down. LSQ and losing touch with the tech world I need to engage with for work are the only things holding me back at this point.

Techie to tech lead: My five biggest mistakes | ThoughtWorks
This was a helpful piece for me as I’m thinking about working toward this kind of role in the future. Some good insights and I can see mistakes I’ve made in the past myself.


I was thinking about my phone today. Eventually it will need replacing, but with what? Do I want to stay with the iOS ecosystem? Is there some better option out there?

I went through a little thought experiment where maybe I would purchase a basic, non-smart phone and get an iPod Touch for the stuff I use my current phone for. Getting away from iTunes (which I only use for organizing my music library) is a massive challenge and I’ve got quite a few games I’m pretty attached to.

In the end what I realized is that I needed to declutter my phone, make sure the notifications I get are minimal, and find a better option for a bedside clock.

I dumped most of the games I kept on there “just in case” I wanted to play them (I game a fair bit on my iPad, those games will be there instead). I moved my social media apps (Twitter and Mastodon, I don’t have a Facebook account) deep into a folder. I like the option of posting to them as needed, but burying them makes me less likely to read the feeds on there.

Everything on the homepage is daily use. Apps on the middle page are stuff I use pretty often but not daily, and utilities it would be a pain to have to download (the retail apps particularly) the few times a year I need them. The games I’ve left on their I use daily for brain breaks and I like variety in them.

All in all, I’m glad I went through this process. I feel like my phone is more of a tool again and will help me keep my daily practices more consistent and distract me just a bit less.

Career thoughts and being honest with myself

I seem to persistently waffle on my career. Yesterday it all felt so clear. A path from Individual Contributor to Tech Lead to Engineering Manager. Do it with Rails and JS. Be there in the next five years. I already have 8 years in the industry, this isn’t unreasonable.

Why does it feel so impossible and like the wrong track for me today? I had a lot of trouble focusing yesterday and that’s the likely culprit for my hesitation today. If I feel like I’m being productive, then I feel like I’m succeeding and getting somewhere. But by who’s definition of success and productivity?

For me, success in the day-to-day looks like flow. I’m feeling most productive and successful when I get a flow going. But that’s near impossible to come by with programming because of all the stopping and thinking and logic involved.

I need to recouch what success means here, without flow. Is it acquiring knowledge? Is it gaining understanding and facility with the language or framework? I think that may be a key. If that’s the key to getting good and being productive, by my personal standard, then how do I acquire that? How do I fit in that work along with everything else on my plate?

More importantly, how do I do so consistently and with joy?

Weekly Focus 2018: 8.26 – 9.1

  • LSQ issue production
  • Finish current Storybin sprint
  • Rereading Stirring for story ideas
  • Ruby/Rails study
  • Organize LSQ next priorities
  • Thinking about leadership

Production on LSQ is straightforward. Just need to stay on top of it. I should update the checklist template with anything I had missed along the way.

Storybin sprint is just finishing the planning journal and confirming Factorybot is set up. Also need to move the repo to Gitlab so I can stop paying for Github (a needless cost right now). Next sprint should be testing focused.

Rereading A Stirring in the Bones is a joyful, simple thing. Probably the easiest task of the week.

Ruby/Rails studying. What does this look like right now? I need to read the Rspec book I got for sure. And that means just read it, not worry about taking notes or following the code. I need a down and dirty first pass. Along with that, maybe it’s time to make a chart or something of what I do and don’t know. I need a roadmap.

LSQ priorities need work. Things are moving faster than I would like and I need to set out what’s important for the next year. Might be time to do some calendar setup and reverse engineer some deadlines so I can get better on top of things.

Leadership stuff. This is moving to the front of my mind now that my thoughts about blogging have been satisfied. LSQ is a great testbed for my leadership skills. Perhaps I need to read a book or two, or at least some good articles on the subject.

Why is this site here?

Weblog. Remember that word? It’s a bit old, at least in internet terms. It used to refer to a place where one would write their thoughts, opinions, or share informative articles on their specialty. Eventually it shortened to “blog”, and then Twitter came along and many people forgot about it entirely. This site is here to bring it back, even if it’s just for myself.

I’m going to share a bit of my process (okay, I like to talk about process a fair bit, as a warning) and how I put the site together. These are the notes and lists I wrote when I sat down and thought through how this was all going to work.


A place for logging things in my life. I’ve been thinking about this idea for the last couple of weeks. As I pull back a bit from social media, I find myself wanting to write more and also wanting to consolidate that writing someplace where it’s not subject to the whims of advertisers. I started my first blog in 2002, so this concept feels a bit like coming home again.


For myself: So I can go back over the year and see what I read, watched, thought, learned, etc.

For others: So someone else may find some use for the things I’ve uncovered.

Consolidating myself to one place, leveraging IndieWeb technology for sending my writings elsewhere.

Places I already post my stuff

  • My commonplace books (Bear Writer, Boostnote)
  • Newsletters (commonplacebook, cool shit)
  • Twitter
  • Mastodon
  • Tumblr
  • Pinboard
  • 8tracks
  • My developer blog
  • Medium

This weblog idea transforms the point of origin for most of that stuff to a single place that’s under my control, disseminating it elsewhere as desired.


Where to host? I have a few domain names, so which one makes the most sense? works. I didn’t have anything else going on here of note.

CMS of choice: WordPress! With IndieWeb-oriented plugins plus a syntax formatter for my code-related posts. This is as low friction as I can get and it allows me to post from anywhere. I’m going with the nice, built-in TwentyFifteen theme.


What am I posting here?

Make this a website of me and my stuff

  • Newsletters get written here and then sent out through Tinyletter
  • Medium and dev blog posts start here and get copied over
  • Pinboard records my reading and goes over to Evernote so I can grab it weekly as a post here
  • Editor’s Ephemera and my editorials for LSQ will be ported here
  • Current comic book subscription list
  • Movies I watch
  • Video games I’m playing
  • Books I’m reading

Storybin Planning

Why did you decide to build Storybin?

I needed to build Storybin because the literary magazine I run (LSQ) needed a better option for taking author submissions than we currently had. We were using Submittable which is a great app, but in order to increase our staff, the cost was too great for us to afford.

In addition, I work in Rails at my job (LZ) and wanted to dig deeper into the framework so I could be more productive in general.

How did you plan it?

I started out by looking at the features I wanted to replicate from Submittable. I also polled my editors to see what features they liked and didn’t like, also offering an option to give me a wishlist. That extra option generated some unique ideas that I was excited to implement.

Once I had a general feature list done, I started doing my own version of UML diagrams using a program called Scapple that’s meant for mind maps. I went through quite a few iterations of what my data models would look like.

In the process of creating the models, I learned a lot about how associations work in Rails and came away with a design I’m really happy with.

What made you choose Rails?

It seemed like the most straightforward path for what I wanted to build. I was already working in it, so I had some familiarity, but beyond that I liked how I was able to get a lot done quickly. I had a deadline for the project, so speed was important. I also liked that it was all encompassing, giving me both front and backend in one package.

I also needed to learn it more deeply.

Why did you choose each gem and tool?


There are quite a few gems that come “prepackaged”. I’ve chosen to accept those defaults, so I’m not going to talk about things like uglifier and puma.

  • dotenv-rails: For loading various variables from .env.
  • pg: I’m using PostgreSQL as my database locally. I’m used to using it at my day job anyway.
  • sass-rails: I prefer to use Sass for my stylesheets. It also allows me to customize Bulma as needed more easily.
  • bulma-rails: Bulma uses modern web standards and is lighter weight than Bootstrap.
  • jquery-rails: I could just write vanilla JS and might in the future, but jquery makes it just a little easier for me to focus on the Ruby code with minimal fuss.
  • figaro: I’ve got two environment variable tools right now. One of these will be deleted before launch.
  • devise: This is the defacto standard for user login handling.
  • pundit: Another day job find, this one for handling user permissions.
  • rolify: This goes hand in hand with Pundit for user role handling.
  • draper: Allows presentational methods to be written, made testable, and kept out of the models.
  • kaminari : Handles pagination on views.
  • shrine-gdrive_storage: Shrine plus the tools needed to publish to Google Drive. This links to my own fork, which has a few fixes in place.
  • ruby-debug-ide: Along with debase, this allows me to debug ruby inside VS Code.
  • debase: Required for ruby-debug-ide to run.
  • pry-byebug: Because I have ruby-debug-ide installed, this is just a backup option for debugging.
  • rspec-rails: Solid test suite option.
  • shoulda-matchers: Make rspec for common elements a bit more friendly.
  • rubocop: Code quality tester with an awesome name.
  • factory_bot_rails: More support for rspec testing setup.
  • faker: Fake data generator to make testing easier. Personally, I’m a fan of the funny name option.
  • simplecov: Generates a handy code coverage report.
  • rails-erd: Generates an association chart so you can see if your data connects the way you think it does.
  • better_errors: Generates better error pages with source code inspectors and a built-in REPL.
  • binding_of_caller: I’m honestly not sure why I have this. Possibly to help better_errors do its thing.
  • annotate: Adds handy documentation to models with the schema and routes info.

Other tools and components

Google Drive
I’ve decided on Google Drive rather than using ActiveStorage or AWS because my editors need to be able to read the submissions online rather than having to download the files and open them. It’s possible I could have found a way to read the files into each submission’s page, but there seemed to be no straightforward method for that.

As a bonus of using this method, when the time comes to edit the submissions, using Google Drive provides a consistent edition and comment standard for myself and the editors to use.

Trello and Agile
I’ve been using Trello for a lot of other personal projects. It’s worked out well for a single developer. I can see it working for a small, well organized team as well. I’m doing a sort of agile process, running weekly sprints with a retro and planning session at the end. It’s helped me stay on track and keep an eye on what’s coming next.

This seems to be the straightforward, standard hosting choice for Ruby/Rails applications. It has a reasonable pricing structure and handles a lot of things I don’t have the time or energy to learn how to handle on my own.

Most folks go for Bootstrap or Foundation, but I wanted something that would work well without JavaScript and also implemented the newest standards. Bulma is lightweight and well documented.

I might not have much need for JavaScript on this project and could probably write what I need in vanilla JS. However, since I need to focus my efforts on the Rails areas of the application more than the JS, it makes sense to use this library to speed development.

What makes you nervous?

I’ve never taken on a project this big before, especially not by myself. Much of the tools and techniques are new to me so I’m nervous about getting stuck and not being able to fix the problem. I also haven’t had my own software out there for others to use before and this will be a critical piece of infrastructure for LSQ. Failure is kind of not an option.

Why journal the process?

I wanted to record the experience, including my own opinions and perspectives as they change during the process. Having a record of these decisions will be helpful the next time I start a new project. It’s also helpful for being able to show my process to others. Hopefully someone else down the line will benefit.

Storybin: Sprint retro #1


  • Spike: journal this thing
  • Review Bulma
  • Set up postgres
  • Set up rspec
  • Set up capybara
  • Set up rubocop
  • Set up overcommit
  • Set up devise
  • Write rspecs for Users
  • Create users and roles
  • Set up rubocop extension in VS Code
  • Set up annotate
  • Create basic static homepage
  • Clean up user form styling and logic
  • Set up Devise mailers
  • Set up shoulda-matchers

What went well?

  • Was able to find most of the resources I needed to get to creating the app
  • Managed to revert Simple Form without crying
  • Devise setup was nice and straightforward

What needs improvement?

  • Bulma has a few quirks or something not working in navbar
  • Less getting lost in the weeds on configuration. Try defaults before playing with stuff.
  • Rspec tests


Over all it was a good sprint. In some ways I got further than I thought I would, with the exception of testing.

I was surprised by how much configuration I ended up doing. For a framework with a philosophy of “convention over configuration” there was a lot of config to do. I put that more on the gem developers than on Rails itself, which did indeed feel more straightforward.

I was frustrated that I didn’t get as much done on the functionality because config took so long and omg I was so underprepared for Rspec and tests to be so complicated. It’s basically a framework inside a framework, so the learning curve there is steep af.

I didn’t get to deploy to heroku yet, so that’s more config that needs to be done.

I don’t think it was an awful sprint, but I’m looking forward to seeing what I’ve got done by the end of the next one.