The Fairway Technologies Blog

blog

Recent Posts

January 29, 2014 | Jeff Johnson

Cool Things You Can Do With the Windows Address Bar in Windows 7

Overview

Sometimes getting stuff in Windows is a pain in the... well... it's a pain.  Maybe I want to shut down the SQL Server service on my machine.  To do that, I have to get to the Services panel.  Getting to the Services panel can be a bit of a pain.  Here are a couple ways:

October 22, 2013 | Jeff Johnson

A Beginner's Guide to Querying LDAP with Ruby. Also Spaceballs.

Overview

I'm at a point in my project where I need to look up stuff.  No doubt you're saying something like "Duh - programs need to look up stuff all the time, dummy!  THAT'S NOT SPECIAL!  TELL ME SOMETHING INTERESTING!"

October 3, 2013 | Jeff Johnson

Delayed_Job, Ruby Serialization Woes and Big Trouble in Little China

Okay - a couple things.  First thing's first - have you seen Big Trouble in Little China?  If you haven't, you should.  You're really missing out on a fun adventure flick.  As a matter of fact, you should stop reading this article and watch it.  Yeah, I know - you're probably struggling with some sort of crazy bug and you've been combing the Internet looking for an answer.  I think you deserve a break.  The bug will be there waiting for you when you get back.  I bet if you wander away from your computer for about 90 minutes your bug will fix itself.  Go ahead - prove me wrong.

July 21, 2013 | Jeff Johnson

Slapstick - a Backbone Tutorial, Part 1 - Modeling the Model

Introduction

It's time to get going on the Slapstick application, 'cause it isn't going to build itself.  Before we jazz up our application with all kinds of swanky JavaScript goodness, we need a foundation to build on.  In this post, we'll talk about the objects we'll be working with to represent our fantasy hockey team.

July 1, 2013 | Jeff Johnson

Slapstick - a Backbone.js Tutorial, Part 0 - the Beginning

Introduction

Two developers.  One Backbone tutorial.  One of us is an avid hockey fan.  The other is a bit of a sci-fi/fantasy nerd.  Therefore, it only makes sense that the app we'll be building is a fantasy hockey league website during this tutorial series.  Because seriously - who doesn't want to see Darth Vader vs. Sauron on the ice?  An epic seven game series of elves of Lothlorien vs. stormtroopers of the Death Star?  Yes, please.  I'm sure there's a "one puck to rule them all" joke in here somewhere.  I'll leave that exercise to you, dear reader.

May 28, 2013 | Jeff Johnson

Gonzo's Puppet Journey: Updating an Existing Package on Solaris 10 Using Puppet 2.7

 A high-level picture of how Puppet applies resources during a run. From Puppet Labs.

Introduction

I'm willing to bet that most of us have built a server or two in our careers.  If you're lucky, you have a long list of cryptic instructions from someone who left the company three years ago that tells you what software is required for your new server.  Are you absolutely sure you followed every instruction to the letter?  What if you skipped a step - how would you know?  Also, how long did it take you to build your maybe-I-sure-hope-I-got-this-right server?  An hour?  Two?  I've often heard the term "work of art" used as an analogy for building a server.  No matter how hard you try, they never come out the same - each server is its own unique and beautiful snowflake.

Enter tools like Puppet or Chef (and the concept of "infrastructure as code").  If you're not familiar with Puppet, it's a fairly popular tool for helping to maintain your infrastructure.  The basic idea is automating the creation of your servers.  That way, your servers are the same in every environment - from development to staging to production.  Puppet thinks of programs, files, users, etc. as resources.  You can write scripts (called manifests, which are organized into modules) using Puppet's DSL (domain-specific language) to interact with these resources and set them up correctly on your new server.  After you've created your Puppet manifests and modules, you can have Puppet apply them to any number of servers.  In effect, you've "scripted out" your server configuration and you can run it at will (more or less).  Using Puppet, you can set up a new environment in a few minutes instead of a few days.  Also, you've automated creating your servers - no more following incomprehensible instructions.  Puppet will build your servers the same way, every time.

February 26, 2013 | Jeff Johnson

Rails 3.2: A Nested-Form Demo Part 4: Switch to Targeting Computer!

Overview

Our heroes have fought their way through the Death Star's fighter screen and can see the trench. As they enter the trench our pilots stabilize their deflector shields, preparing for the torrent of incoming turbolaser fire that will no doubt be coming their way.

In this post, we'll take a look at adding some validation rules to our Ship and Pilot models. Hopefully, this effort will prevent our users from... err... having their way with our meek and rather naive Starfighter Recognition Guide. Our exhaust port is small, it'd be a shame to see it damaged by some ham-fisted users.

Validation

In our last post we walked away with a fully-functioning Starfighter Recognition Guide that could save a Ship and any changes (create/update/delete) to its associated Pilots. Neat, right?

Before we run off and save everything willy-nilly, we should probably go about checking to make sure our users provided the data we need. Let's add some data entry requirements to our application, shall we? Here's what we need to do:

Ship Requirements

  • A Ship must have a name.
  • A Ship's name must be between 3 and 50 characters.
  • A Ship must have a crew.
  • A Shipmust have between 1 and 5 crew members.
    • Arbitrary? Sure. But I figure if a Ship has more than 5 crew members, it's probably a capital ship or on a scale that isn't appropriate for a Starfighter Recognition Guide.
  • A Ship must have a speed.
  • A Ship's speed must be between 50 and 200... err... thingies per... umm... unit of time.
    • At the risk of having my Star Wars nerd card revoked, I'm not sure how the speed of a starfighter is measured. Yes, I looked it up. Nope, I couldn't find anything conclusive.
February 7, 2013 | Jeff Johnson

Rails 3.2: A Nested-Form Demo, Part 3: We're Starting Our Attack Run!

Overview

When we last left our heroes, they fought their way through the superstructure of our application and were setting up to finish it off. Having defeated the TIE fighter screen, our intrepid fighter pilots have descended into the trench of the Starfighter Recognition Guide. Their computers are locked, they're getting a signal...

In this post, we'll capitalize on the code and plumbing we implemented here and here. We'll take a look at the views we put in place and some javascript to make our Starfighter Recognition Guide a bit fancy-pants.

Stabilize your rear deflectors and watch for enemy fighters - there's gonna be a tubolaser battery's worth of code in this one.

January 24, 2013 | Jeff Johnson

Rails 3.2: A Nested-Form Demo, Part 2: Accelerate to Attack Speed!

Overview

In our previous post, our intrepid heroes were hurtling headlong into the trenches of the Starfighter Recognition Guide. They maneuvered through the superstructure of the application, setting up a relationship between themselves (the Pilots) and the Ships they fly. In this post, our ace Rebel pilots will make their approach to the surface of our application.

The Controller

Because all of the heavy lifting is being handled by the ActiveRecord configuration defined in our domain model, the controller for the Ship model is pretty standard fare. As a quick refresher, here's what the create method in the ships_controller looks like:

  def create
@ship = Ship.new(params[:ship])

if @ship.save
redirect_to(ships_path, :notice => "The #{ @ship.name } ship has been saved successfully.")
else
render(:new, :error => @ship.errors)
end
end

If you're interested in looking at the controller in its entirety, you can check it out here.

January 18, 2013 | Jeff Johnson

Rails 3.2: A Nested-Form Demo, Part 1: All Wings Report In!

Background

I've been working on a Rails 3.2 project for the last several months. While it's been a blast to learn a new technology stack (I've spent most of my career working with .NET), there have definitely been some bumps in the road. In particular, I've spent the last couple weeks working on persisting a model that has a parent-child relationship. The bulk of that time was spent poking around the inter-webs, looking for tips and tricks to accomplish my goal. During my inter-web search, I couldn't find a single post (or series of posts) that had a complete example or tutorial on how to persist a model that has a parent/child relationship. My Google-fu might not be as good as some other developers out there, but I searched pretty hard. What I found were bits and pieces scattered about (primarily on my savior, Stackoverflow). After a LOT of trial and error (mostly the latter), I finally have it working. So I thought I'd collect my notes as a series of posts. FYI -  this started as one post, but got WAY too long. Even for me.

Objective/Goals

Reading is real neat, and I do a whole lot of it. I tend to learn by doing, so reading only gets me halfway there. To that end, we'll build a demo application that ultimately addresses the following:

  • Allows a user to save a model that has a parent/child relationship.
    • The operation will allow us to save the parent object as well as insert/update/delete new child objects that are associated to the parent.
New Call-to-action

Sign Up For Our Monthly Newsletter

New Call-to-action