Lately I’ve been wanting to dig more into some technologies I’ve been wanting to explore and gain more experience. Not only this, but I wanted to make sure my dev workflow was still improving, my tools were getting sharpened, and I was re-establishing the best practices as much as I could.
Those specific technologies I wanted to dig into was:
- Building a CLI in Ruby, using Thor
- A Sinatra Modular API
- Solifying Sequel Model usage and JSON serialization
- Building a dashboard using Dashing
- Diving more into Rubocop for Ruby static code analysis
- Automated Code Review using CodeClimate
I found a way to connect all the dots in what I’m calling the scoreboard project. I chose these technologies because it would let me shine up my ruby/sql skills without a framework carrying me the way. (Although they mostly did anyway!)
This blog post will go over the idea of making an API around scoreboards. There will be a simple CLI tool to gather scores on ‘games’. Those scores will be sent to the API, to store in Postgres. The dashboard project will then pull these values from postgres and display them in an easy to view manner.
With this post, i’ll go over the individual pieces of the project, the interesting tidbits of each one, and finally go over a short retrospective over the entire project.
In entire time, the project took about a day and a half. It was fun, and I really enjoyed the experience over all.
All of the projects are listed on my github profile. I’ve been trying to keep most issues in the github repo’s issue page for each respective project.
All of the projects are checked by CodeClimate, and I’ve been trying to keep up with rubocop’s rules on these as I go.
The idea for the CLI was to prompt the user for a home team and visitor team, then collect data about getting a touch down for the home team, for example:
It would keep prompting for more scoring plays until the user gives a SIGTERM or hits CTRL+D.
First I started by reading up on Thor, which was an absolute pleasure to work with. You can download it via
gem install scoreboard.
To make it available via command line, I added this:
bin/scoreboard link, we just require in our CLI and run it with the arguments:
1 2 3 4 5 6 7 8 9 10 11 12 13
A note on the SIGTERM exception handling
If you see in my
STDIN.each_line loop where I read in scoring entries, you will see I rescue all Exception. This could be improved to find the exact SIGTERM exception is being thrown, but for simplicity, I left it catching the general exception.
The API has a few paths, based on the
/api/v1 namespace for requests.
You can access its teams or the entire scoreboard, via
GET /api/v1/teams or
GET /api/v1/scores. You can see the core Sinatra Application on github.
It was absolutely easy to set up the Sequel migrations to define the team table and the scoreboard table in postgres.
The main tying point was getting the Sequel models to serialize, which was solved in another blog post.
Dashing was really easy to get started, a project set up, and out the gate.
First I had to include Sequel to get me my data, which I included an
Api model to ease the SQL bridge for me.
The main point here was the
scoreboard.rb file which was scheduled to run every 5 seconds, gather data from some crafty queries, and send that data to the dashboard. Other than the HTML markup, this was the chunky part of it:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54
- What went right
- What went wrong
- What could be improved
What went right
- The CLI came together smoothly. Thor was easy to get running.
- Getting data to post to the API was a breeze
- Sinatra and Sequel were easy to hoist up a simple API to take POST data and serve GET requests as JSON
- Getting data into the dashboard was SUPER easy with Sequel, no need to do the ORM dance
- Dashing was easy to create my own scoreboard component, using the
data-type DOM attributes
What went wrong
- Had some issues handling SIGTERM in CLI
- CLI still doesnt validate input
- API for Sinatra was a little difficult to get JSON serialization off the bat
- Dashing is very ‘opinionated’ and doesnt give you more room to fit into an existing app
- No tests were made
- Nothing is deployed to servers yet
What could be improved
- Minitest suite for CLI, API, and the Dashboard
- Dashboard process tasks could be broken out to be more DRY
- CLI needs to check and validate input
- API needs to add in rollbar, new relic, or other metrics to help find errors
- Deploy all the things!
The plan is to keep working on this project and continue improving tooling and getting other best practices in place. Finally, ship it to digital ocean and enjoy the conveniences they provide.