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
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.
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.