If you have ever looked at my github repository before today (June 8th, 2016), you would have seen a variety of repositories in various stages of development. You’d even see the repository for this blog. What you wouldn’t have seen, however, is a single repository related in anyway to the work I currently do. This was a purposeful choice I had made. There are numerous project possibilities related to my current job (small and beyond me) that I could have worked on but I consciously avoided that so as not to feel too overwhelmed and stuck ‘at work’ when I was working in my free time. That may not seem like it makes sense since it would seem that I’d have a lot more insight to what a project would need based on the job I’ve worked over 15 years, but hey, that was my thought process at the time. However, the times have changed.

Recently, a new venture has been started revolving around nitrogenated teas and herbal drinks at our company. Nitrogenated beverages are pretty hot and trendy right now and we are hoping to jump on it and build a good business with a small brewing facility within our location. This business while under the company umbrella is sort of a stand alone in terms of the preparation of the product to sell. The kegs we use for storing, nitrogenating, and distributing the product are kegs that are customized with our company information and when delivered to customers it will be based on a deposit. We will get empty kegs back and they will get their deposit back. Thus, an opportunity presented itself in the form of the kegtracker to build a useful project for the company and reinforce my current knowledge while stretching it in other ways.

Each keg that the company has purchased has a unique identifying ‘serial number’. This seems like as good a piece of information as any to uniquely identify each keg within our system. As such I would need to set up my Keg Model so that not only was each serial number unique, but so that each serial number followed the format that the pattern seems to follow. (If you’re interested that pattern seems to be NN-NNNNNNB where N represents an integer and B represents the letter B.)

In all the times I’ve gone through the learning process in general, the one thing that has driven me more batty than the rest is regular expressions. For those who might be reading this without any programming background, regular expressions are a special way of telling your program the pattern of text you want to look for. If you want to learn more, check this out. Regular expressions have always been a bit of a roadblock for me. Sometimes that roadblock was intense, sometimes it was easy to navigate, but I’ve never really been a fan of them (though I recognize their utility, I’m just bad at creating them). However, I realized at this point, to ensure the proper formatting of keg serial numbers, I would need to use these pesky buggers. Fortunately, Rails, and a nice little website at rubular.com would make it much easier for me.

Getting started

Every rails application starts at the same place, rails new (your_app_name). Usually you can start just like that and a perfectly useful Rails framework will be set up for you to start coding. Your needed gems and folders will be set up for you and you can go from there. Of course, if you couldn’t modify it a bit, than it would be a bit too rigid to work now wouldn’t it? The default database for a new Rails app is SQLite, and the default test frame work is not a test framework I like to use. Sometimes I allow SQLite to be the default database in my apps, but this one I wanted to use PostgreSQL, because once you get to hosting you won’t be using SQLite, and I wanted to use a different test framework, so my new statement had some added terms at the end to instruct Rails to use PostgreSQL and NOT set up the default testing unit. Thus my create statement was slightly more verbose: rails new kegtacker --database=postgresql -T.

Regardless of what database I may or may not use when developing an application, I always have the -T because I prefer to use Rspec for my test-driven development. For a time, most Rails tutorials I tried used Rspec to teach their test-driven development. Many have back to the default test unit in Rails, but I like how Rspec (combined with a few other gems) works. To that end, there is a list of gems (some rspec related and some layout related) that I automatically put in my Gemfile whenever I start work on a new application. They include

The first four of the five listed are test related, but the last gem listed (Bootstrap Sass) is a framework for making lay out and formatting much easier. Such things are not my forte, either building or just designing. Bootstrap was developed by the good folk at Twitter, and made public, to make it easier for people to make functional, though not always that stylish or unique, layouts more easily.

So those gems were installed, and then I set up the github repository and did an initial GACP to get my repository going and off we go to getting started with setting up the kegs.

Setting up the Kegs - the basics

The basics of any Model set up require you to set up the database, the controller so the database can pass information through to the user, and the views so that the user can see and (if allowable) create/edit new records. It even has an acronym CRUD (Create-Read-Update-Destroy) for these basics. They’re so prevalent that rails has some shortcuts built in to facilitate this creation. You can set up all the basics routes (links and code for links) to the basic functionalities with one line in your routes.rb file which then lends to the methods (functions) needed in your controller. Using TDD, you tend to start with the basics and build your way up, so in that I created the Keg Model and the controller methods for creating a Keg (only) at first. I created some truly basic (unpresentable , but functional) layouts so my testing could ‘feature test’ and allow me to see that user input could be taken.

The most basic test you can run is just that the application takes the user input, creates the record, and then goes to the right page, so that’s what you do first. For those unaware TDD involves writing code to ‘test’ your desired outcome. The test of course fails (RED) at first because no code exists. Then you write just enough code in your application to make the test pass (GREEN). You then refine the code so that it’s cleaner and leaner (REFACTOR). So if you ever hear the phrase ‘red, green, refactor’, now you know what it means, though it’s more likely you either already knew what it meant or have no reason to know what it meant, but if you’ve been here before, you knew this was bound to happen in this article.

So, anyway, I wrote (and passed) tests for basic entry of a keg serial number, requiring a serial number (i.e. it can’t be blank), and making sure the serial number is unique (i.e. it hasn’t been entered previously) so I’m to the point of the new thing I need to do. Thankfully, as usual, Rails is going to make this so much easier it’s ridiculous.

As I stated above, writing a regular expression to match patterns can be easy or difficult depending on the pattern you’re looking for. The rubular website listed above helps you write (and test) your regular expressions to see if they match the pattern you’re looking for (and no others). Using rubular, what I do know about regular expression, and the pattern I got above, I was able to come up with the regular expression /^[0-9]{2}-[0-9]{6}B$/. Rubular’s guides at the bottom were extremely helpful in setting up the pattern quickly and easily.

And then it’s time to set up the code in my application to work with this regular expression. At first, I thought it was going to be difficult, but that’s because I hadn’t read everything I needed to read. The folks who are ‘in charge’ of Rails have made some wonderful guides to teach you the basics of the built in functionality and how to best use it. They’re mostly written by programmers so sometimes they aren’t as clear (to me) as I’d like them to be, but the validations guide section on using fomat: in your validation is clear, concise, and exactly what I need to make sure that the user input serial number matches the format I want it to match. I used the format: option with my regular expression, and the test at first still failed. It turns out that my ^ and $ represent the beginning and end of a line respectively, whereas my failed test asked me if I meant to use \A and \z which represent the beginning and end of a string respectively. After I made that change, the test quickly passed, and I had set up the kegs to have a unique serial number that followed a specific pattern, and it was much easier than I thought it would be, though upon reflection, having a built in method/function that allows you to define the pattern of user input easily, as it is so common on the web today.

So, what I thought would take a long while was actually pretty simple, so after the preamble of setting up the app, the expected ‘meat’ of this article was rather lean, but I will publish it anyway. It’s good to have this as a reminder that sometimes something that seems daunting, might not be, as long as you take a little time to do the research beforehand.