Well, today is September 6th, 2016, and I already have two long article drafts in progress that require me to go back to them, and focus, but I also haven’t published anything in a while, and my work is a bit scattered between projects, concepts, and ideas right now. For instance, I’m still working on front-end stuff, 4 individual Rails projects, some (hopefully) smaller JS projects that can at least get to completion and strengthen my UI/UX skills (plus my javascript skills if my RPG character generator ideas ever get done.)

So without my normal preamble and lead up, I’m just going to get into the two cool things I discovered today.

Ruby on Rails Makes it Simple to Have Compound Validations

(Compound is in italics because it might not be the precise term of what I’m about to describe, apologies in advance)

I’m currently working on one project that needs to build recipes (two projects actually, but one at a time). And the way I work with recipes is that I create a Recipe model, and an Ingredient model. A recipe will have many ingredients and an ingredient will be in many recipes. To make this concept work, I created the Component model, which in its infancy, has three attributes. Two of the attributes just identify what recipe and what ingredient we are working with, and the third attribute is the quantity of said ingredient within the recipe.

As I start out the Create part of the component C.R.U.D (yes, with testing of course), it occurs to me that I need to make sure that any given ingredient can only be added to a given recipe once. If you’ve already added 1 part butter to your cookie recipe, you don’t want a new butter component that is 2 parts, you just want to change the original butter entry to 2 parts. Therefore, you want your application to smoothly alert the user that butter is already part of the ingredient while not creating the new butter entry in the recipe. Now in theory, I understand how this works. Whenever you enter a new component, you have to go through all existing components for the current recipe to see if the ingredient has already been entered. Theory is great, but just because you know the theory doesn’t mean you know how to make it work in practice. So, off I go to the interwebs, which, as always, helped me out.

I first started with the Rails Guide on validations, specifically uniqueness. A quick read indicates that the scope: option probably fits my need. While the Rails Guides usually do have useful information, they don’t always have the most clear and useful code explanations, but that’s ok, because, if you’ve been reading me at all, you’ll know that StackOverflow almost always has the answer. Now, this was a question using a different database than the one I’m using, in fact, it’s a NoSQL database whereas I’m still in the SQL world of databases (more future learning), but the answer is in Rails, and Rails, to the best of its ability, is database agnostic. Rails code that works on one database, works on them all.

So, instead of some complicated work around solution, or long web search for code I might not fully understand, I was able to quickly write one line of code:

validates :ingredient_id, uniqueness: {scope: :flavor}

And my test (and paranoid second test to make sure I could still add the same ingredient to a different recipe) passed quickly and easily. Once again, I learn something about Rails that I could probably could have figured out how to do myself, but I don’t have to, because the designers know it’s a common happenstance so it’s built in for me.

Any Rails tutorial you do is going to have some some layout work. It just is. You can’t really build a web application without working on the views and the layout, and what your sample app looks like. It’s not complicated, it’s not exquisite, but it is usually functional, and it’s usually built using Bootstrap because as most people know, Bootstrap makes it much easier to do a lot of layout. (You still need a designers eye, and I just don’t have one, but that’s for another day and another article.) Anyway, in one of the tutorials I’ve been working through, they do this custom code where they make a link look differently if it’s the active page you are on. What I’ve always wanted was the ability to deactivate a link if you’re on the same page. It’s just one of those simple things some websites do that I do actually appreciate, and guess what, no surprise here, Rails does have a simple way to do this as well.

I wasn’t really looking for this one. Honestly, I was researching something else, but as I scrolled down this page, I came across this method. Now, I had imagined some creative CSS and Ruby gymnastics to try and get this to work when I finally approached it, but as it usually turns out, I didn’t have to. I just had to look in the right place to find the link_to_unless_current built-in method. So, in the future, when the links up at the top become functional and useful I’ll be able to deactivate the active one so you don’t leave your page accidentally.

So, there you go. This is probably my shortest article to date (and I know they need to be shorter, but that’s not as important to me as getting things written yet) but I thought it was kind of cool that in one day I not only found the solution for something I hadn’t even been looking for, but I also came upon another built-in to Rails that I can use to save myself time, but still understand how it works underneath, which is sometimes just as important.