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
  • Dev.to
  • 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? pixelpaperyarn.rocks 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.