I was recently setting up on my local machine for a Tech Assessment during an interview process. Lo and behold I came across an error which might look familiar to my fellow devs:

Fetching: ffi-1.9.25.gem (100%)
Building native extensions. This could take a while...
ERROR:  Error installing ffi:
	ERROR: Failed to build gem native extension.
...
make failed, exit code 2

After a quick Google session, I found several posts about this error being encountered. Many of these results offered up a glimmer of hope into why this is occurring. I was expelling whispered sighs of “Of course…must be a brew update…” or “Maybe I have a pending software update” and the ever present, “Damnit Donnie! Why you no work?!”. Here are some of the suggestions I came across, and finally the answer that fixed it for me.

Do as the bundler do

First, what bundler told me to do — run gem install ffi -v '1.11.1' and if that succeeds, then run bundle install again. Nope. Nothing, Make failed. Exit code 2. Thanks. Helpful.

xCode Update?

Second, maybe it’s xcode being xcode-y. Try running xcode-select --install. This gave a handy error of, xcode-select: error: command line tools are already installed, use "Software Update" to install updates.

Too many gems on the dancefloor

Sometimes I forget that I have already installed a gem from an earlier project at a global level using an earlier version. Perhaps I came across this before and the first attempt to fix this did the job. In this case I figured I could try to uninstall the ffi gem incase my assumptions were correct. You can try this by running gem uninstall ffi. To my dismay, although this did uninstall a previous version of the gem ( I believe it was 1.9.21 and I was attempting to install -v 1.11.1 ) trying to install the gem globally again after running the uninstaller still yielded the same error code.

All the world in the tine of a spork

More Googling. More Stack Overflow posts. More pouring through issue notes on GitHub for the ffi gem, jekyll gem, and a couple of other examples where users had similar issues. Finally, like finding the last take-out fork in the back of the drawer in the break-room, I discovered a post that sounded a little out there, but turned out to be correct.

Big shout out to Jamie Macey from Nanaimo, BC ( love your bars by the way! ) for posting the answer. My issue was finally solved and I could move on with my Tech Assessment. It was quite a feeling. To say the least, I was emotional.

A wraith pinned upon the mist

Similar to how I had suspected earlier that I may have multiple versions of the ffi gem installed at the global level, my symlinks to the libraries were incorrectly defined. Not sure if this was an artifact of a recent update to homebrew, or maybe the latest version of xCode, or maybe my own mistake when messing around with npm and react. In either case this was the answer. This was the simple snippet that fixed my issue preventing bundler from progressing down the cascading tree of gems and dependencies.

sudo ln -s /usr/lib/libSystem.B.dylib /usr/local/lib/libgcc_s.10.14.dylib

Some important things to note

You may want to check with your version of MacOS. The post where I discovered this line to change the symlink from the /usr/lib/ directory to the /usr/local/lib/ directory was in regards to the issue being discovered in MacOS Mohave (v 10.4.x). I on the other hand am using MacOS High Sierra (v 10.14.x). I updated my second half of the sudo string to set it to 10.14.dylib rather than 10.4.dylib. You may wan to verify your version and update accordingly.

In case these suggestions in my post haven’t helped your situation as they did for me, here is a link to the discussion thread I found my solution on. Perhaps there is another idea posted here that will work for you. In any case, don’t give up. Keep searching for answers, and when you find yours, consider writing a quick post about it.

A partially impartial look at CSS Frameworks

Gather ’round the rocking chair. Pappy Ryan is going to tell you a story about CSS in my day. When I began my career as a developer in 2008, my first taste of excitement from coding came when I was introduced to the wonderment of cascading style sheets. This was back before CSS compilers, asset pipelines, and standardized frameworks were really even being considered as teachable curriculum. Sure there was always a grid based system, but more often than not it was compared to, or even used within (shudder…) tables.

Fastforward a few years (an eon in programming years) to 2011 when I was introduced to a basic PHP cms with a CSS framework. At the time I had no real world experience using a framework, but I immediately saw the benefit of using one. This particular one was the Zurb Foundation framework.

Now, if you aren’t familiar with Foundation, or what a CSS framework is, the basic thing you need to grasp is that it is a collection of pre-determined styles that make your life a little easier. Easier because you no longer have to copy and paste styles for different types of buttons, or calculate the padding needed around an element to make it display within your grid system. Instead the fine folks at Zurb, Twitter, Google, and Semantic have taken the time to write up some basic styles to give your application standardization.

Depending on what style you prefer, each grid based framework is essentially as good as the next. There may be nay-sayers out there who are more inclined to use one over the others, but when you boil it all down to the essence, these all accomplish pretty much the same thing. And their documentation is pretty sniffty too.

Zurb Foundation

Foundation has been on the scene for a really long time. At the time of this article they are touting version 6 of their framework. This is the first one I ever had exposure to, so maybe it holds a fuzzy little place in my heart, although I don’t visit often or call as much as I should.

The fact that they are now on the sixth iteration of their framework should tell you that they are constantly updating and keeping their code relevant to industry standards. They have recently added support for CSS flexbox. Although they don’t have as many bells and whistles in terms of pre-made styles available for you to use, it is a great option for a bare-bones grid system that you can customize and make into your own flavor.

Twitter Bootstrap

The fact that it is created and endorsed by the big blue bird in the sky should tell you that it is not going away anytime soon and will always be up-to-date with industry standards. Currently Bootstrap is in version 4 land with mentions and rumors of version 5 just around the corner. Bootstrap is most likely to be the foundation you will encounter if you start working at a development shop today. A majority of the tutorials that are out there for Ruby on Rails walk you through how to set up your app and usually include the twitter-bootstrap gem.

As an extra added level of sweetness, the folks over at Bootstrap also now offer you a catalog of themes you can choose from. So if you aren’t so inclined to have your site starting off looking like a tweet-tastic experience, one of their helpful theme packages should be able to help you create the look you’re going for.

Material UI

The approach taken by Material UI is quite fascinating. They have gone a step further than simply creating another CSS framework. They created a style philosophy. Instead of dictating shapes, colors, and fonts, the engineers, designers, and user experience experts at Google analyzed actual physical objects in space and used their findings for inspiration of UI elements. For example, content is always placed in a card. Think of this like a page. Buttons are always presented in a meaningful way with consistent placement in the given space. Interactive elements appear to be protruding to a higher level and seem to press down when you act upon them.

I’m not going to say I didn’t fan-boy over this in the early stages. Most of the time we developers take Google’s musings as gospel. But in this case I think the fanfare was fully warranted. The thought that went into this framework and the science behind the why’s and how’s really speak for themselves.

Semantic UI

Sort of a late-comer to the scene, Semantic UI takes a slightly different approach. In my honest opinion, it is like they started from a version of Bootstrap or Foundation and simply changed the way elements are named. Which, don’t get me wrong, is not a dig on them at all. In fact it’s quite clever. For instance look at the markup for a simple panel for Bootstrap:

# HAML CODE
.row
   .col-md-4.col-md-offset-4
     .panel 
       .panel-body 
         .row
           .col-md-12
             h1 With some content 
             p More content goes here in paragraph form 

And now the same thing in Semantic UI:

.ui.four.column.grid 
   .row 
     .column
       .ui.card 
         .content 
           .description
             With some content 
           .extra.content 
             More content goes here in paragraph form

I’m not saying it is always going to use less code or cleaner looking code. What I am trying to illustrate here is that the class names are, well, semantic. Classes that make more human sense like “ui”, “four”, “column”, “grid” is easier to understand than the “col-md-4”. Which doesn’t really even afford you the knowledge of what “md” is. Is this medium? If so, medium in relation to what?

Take aways and final thoughts

As I said in the beginning, this is a partially impartial assessment of the four most popular frameworks. Your definition of popular might be different from my opinion of popular. Maybe you like Bulma better. Maybe there is a framework that you know which I haven’t considered. By the way, can you guess which one I’m more partial to? I saw a couple hands for Google. A few of you voted Foundation. Actually, it’s Bootstrap. Although there are some issues I have pointed out with the B that I’m not particularly fond of, it’s what I have used the most and gotten most comfortable with. That doesn’t mean it’s the best. That doesn’t even mean it’s the best for me. It just means that I am willing to admit that it may be time for me to start using something new. I encourage you to do the same.

The Mr. Meeseeks of the QA world

If, like me, you are a fan of the hit series “Rick & Morty”, you have obviously seen the episode with the infamous Mr. Meeseeks. Elsif you haven’t seen “Rick & Morty” or you simply aren’t familiar with this episode, Mr. Meeseeks is a race of short-lived beings whose sole purpose in life is to solve a single problem, then die. If you have ever worked on a team with a dedicated QA department, which you would like to review one or more features at a time independently of other features which also need QA or UAT (user acceptance testing) before moving on to production, this article is for you.

I should clarify a little more. If you are deploying on Heroku, this article is for you. The Heroku pipeline allows you to generate review site applications based off of pull requests in your Git repository *. Like Mr. Meeseeks, these review applications exist for a short while, allowing a QA agent or other stakeholder to interact with a new feature in your application apart from other features, updates, exorcisms. Then when you are finished with a review app, or the pull request is finished, the review app dies.

Why is this important? Great question. I’m glad I asked it for you. Before I started using the Heroku pipeline and review apps, I would have to provision an new Heroku app with a name like myspecialapp-staging or myspecialapp-dev and spend a couple hours configuring it correctly, setting up my remote connections in my CLI, seeding a database and then testing to make sure everything got set up correctly. This was an ok set up for the time being, but it had major, glaring, ugly, snot-nosed limitations. Mainly, that if I had to do two separate features that made a change to the same view or method or action, I would have to tear down the database and re-seed it with data and run my new migrations. That’s worst case scenario. Best case scenario I would have to frantically email anyone who might be testing that feature to stop immediately so I can push an update and allow another group of testers to interact with my new feature set. Exhausting!

Mr. Meeseeks on the other hand allows me to work on a feature, push it to GitHub, create a pull request and automatically ( within 5 minutes ) have a fully functional review app in place that I can let live until all testing is satisfied. And the best part is, I could do this as many times in a day as I wanted to. No more limitations standing in my way or causing more friction between my team and the QA team.

Now comes the best part. Heroku review apps are also highly configurable. This means that I as the admin can set the review apps to point at a singular database. Something I’ll talk about a little later. More importantly it allows for CI/CD integration! This is huge because now I can have a layer of assurance helping to guarantee that the new application is healthy before I send it off to another team for review.

Back to the singular database I mentioned. Why would I go through all of this work to set up a pipeline and then have all my review apps be limited by a single database? The short answer is, review apps only allow you to create the free tier of PostgreSQL databases in Heroku which is limited to 100,000 rows. If you want to test out some real world data, chances are you are going to want to chunk in a pg backup with a few million rows. By pointing your review apps by default to the same reliable database ( obviously a staging database ) you can avoid this limitation by making real world data available to you.

Hopefully this information finds you well and has inspired you to make some updates to your development process. For more information on Heroku Pipelines, Review Apps, and CI/CD, I have included some helpful links below.

• https://devcenter.heroku.com/articles/pipelines
• https://devcenter.heroku.com/articles/github-integration-review-apps
• https://devcenter.heroku.com/articles/heroku-ci
• https://www.adultswim.com/videos/rick-and-morty/

A while back I worked with some incredibly talented people who taught me basically everything I know, or at least the base understanding which has gotten me to where I am today. Out of all of the code we wrote together, the one thing that sticks out the most is a simple little rails console logger. In this post, I’m going to go through how to set it up, how to use it, and how to modify it to your own needs. I give you o_lo. 

I may have built this up a bit much, but if you have ever, or plan to ever use puts calls in your code to debug your programming, this might put a tiny smile on your face. I know it did for me, and when I took the time to really get acquainted with it, I immediately saw the value-add o_lo has in my day-to-day development.

If you haven’t written or worked on any modules in the past, that my friend is about to change. o_lo is a simple module and is about a scary as Lucas the Spider. For the following topic, I will be using Rails 5.2.3 with Ruby 2.5.1. 

The code for o_lo is really simple. It consists of a basic definition block and some calls to ActionPack structures like ActionController, ActiveRecord, and ActiveView. Here’s the gist of it: 

 module Olo 
    def o_lo(output, decorator) 
        output.blank? ? ‘’ : output 
        decorator.blank? ? ‘*’ : decorator 
        3.times{ puts “” } 
        3.times{ decorator * 20 } 
        puts “” 
        puts output 
        puts “” 
        3.times{ decorator * 20 } 
        3.times{ puts “” } 
    end 
end 

Now, remember I said this also included some calls to ActionPack structures? 

 module Olo 
    ... 
     
    ActionController::Base.send(:include, Olo) 
    ActiveRecord::Base.send(:include, Olo) 
    ActionView::Base.send(:include, Olo) 
end 

Why are you including the module in all controllers, models, and views?

I’m glad you asked that Timmy. By using the extend hook we can access the o_lo method directly from any Controller, Model, or View that inherits from the ActionPack. We can then output the resulting string to the rails logs, your Heroku logs, or any other logging service that captures the status of your application. That’s what makes this so elegant; it can be used in any environment. 

What if I want to use it in a controller that isn’t inheriting from ActionController? 

Gold star Janet! And a great question for all the other boys and girls out there in internet-land. The answer is simple. Ruby on Rails gives you the extend hook to use allowing you to extend methods, properties, and attributes of a module to other areas of your application. This lets us keep our code DRY. Let’s look at an example. 

 class PasswordsController < Devise::PasswordsController 
    layout ‘dark' 
     
    def new 
        super 
    end 

    def update 
        super 
    end 
end 

In the above example we are setting up a local controller to be used as an override controller for Devise’s PasswordsController. Let’s say we just wanted to do something simple like change the layout of the view files associated with the change password interface. We’ve accomplished this by setting the layout to ‘dark’ which in this case references a layout file in our application called dark.html.erb (as an example). If we wanted to see what sort of parameter values, headers, etc are coming into this controller for further analysis, we can bring in our new friend o_lo to help us out. This is where the extend method comes into play. Let’s take a look. 

class PasswordsController < Devise::PasswordsController 
    extend Olo 
    layout ‘dark' 
     
    ... 
end 

That’s it. Super simple, right? Simply add the extend method to the top of your document inside your class declaration and reference the module you want to extend. Easy. 

Great, but how do we use o_lo in the wild? 

I was getting there Phillip, no need to get pushy. To use o_lo in a Controller, Model, or View file just reference the following: 

 // In a controller 
o_lo “User: #{@user.inspect}”, “&” 
// in this example we are inspecting the @user object or instance variable within string interpolation and passing the “&” symbol as our decorator 
o_lo params[:user][:login] 
// in this example we are passing in the user login parameter value as the first argument. We left the decorator blank, so `o_lo` will use the “*” by default. 
o_lo “My code made it to this point”, “I’m Here! “ 
// yes you can pass strings as your decorator. Just remember that the value will be repeated 20 times (unless you modify your version) so don’t get verbose about it. 

// In a model 
o_lo self.gender, “@“ 
// in this example we can grab the gender attribute from the object. 
o_lo “M.E.T.H.O.D man”, “$$ “ 
// otherwise use is exactly the same as in the controller 

//In a view 
<% o_lo “This is a view output”, “V” %> 
// in ERB you don’t need to use the `=` to output the o_lo call 
- o_lo “This is a view output”, “V” 
// in HAML you can use the dash syntax like you would with conditional statements. 

That’s it. I hope you enjoy using o_lo as much as I do. It has saved me more than a couple of headaches in the past. Just try not to forget to remove o_lo before you make that push to production. No need to output extra logging if you can help it.