The Fairway Technologies Blog

blog
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.

June 13, 2013 | Lorrie Hunsaker

Fairway Unveils Redesigned Website

New site delivers multiple enhancements for a richer user experience

December 7, 2012 | Jeff Johnson

Distributed Transaction Coordinators, Port 135, and Firewalls - Oh My!

The Scenario

A while back, I worked on a project that required persisting data to multiple databases.  The requirement was to save some data to a Microsoft SQL Server (which hosted the billing application data) and save a different set of data to an Oracle database (which housed the database for the flagship Online Transaction Processing [OLTP] system).  Both of the database servers were protected by the almighty firewall, valiantly protecting the valuable database servers from a variety of virulent violations.

Ailing attempts at alliteration aside, here’s a high-level diagram describing the application I’m talking about:

 

 

September 14, 2012 | Kim Sunderland

Development Incentives, What’s the Payoff?

I’m sure you’ve heard of the 20% doctrine implemented by companies like Google.

In a nutshell, they encourage their developers to spend 20% of their time working on anything they want. The purpose is to inspire innovation and help keep developers engaged at the company.

I ran across this article in which the author makes an argument against using this development incentive. He argues that “100% of work time should be used for work and side projects should be done on your own time.” I’m sure I could write pages arguing both sides of this statement, but don’t worry, I won’t. I will however, examine one specific comment he made: “… it's better to find the right fit in a company that gives us work we're interested in 100 percent of the time.”

August 31, 2012 | Ben Griswold

“Optional” Software Development Practices Series — Code Review

In the series opener, I wrote about “optional” software development practices like Test-Driven Development (TDD), Continuous Integration (CI), data migrations, one-click deployment and code review which are fundamental to how we build software at Fairway, but are often touted as optional and embraced by a small percentage of development shops.

In this post, let’s dig into one of the “optional” heavy-hitters, code review.

There is any number of reasons why code isn’t reviewed at all shops – every reason from the presumed time/cost commitment being too high, to just not understanding the true benefit or how to get started, to a general aversion to change. My two favorite reasons include protecting developer morale (i.e. developers can’t handle having their work critiqued) and naively thinking there’s no need/value since developers are producing a good product already. Oh brother. Perhaps worse than avoidance, though, are the truly unfortunate cases where the fears of the skeptics are the reality, where teams preform code reviews poorly.  Here, a lively roomful of peers nitpick and bash away on Johnny’s code or, quite the opposite, the review becomes a total snooze session. In either case, the review is probably scheduled too late in the project lifecycle so there’s no time for anything constructive to be done in response.  There’s absolutely no value – just wasted time.

August 20, 2012 | Ben Griswold

“Optional” Software Development Practices Series

In a recent training session, Noah and I reviewed a handful of development practices including Test-Driven Development (TDD), Continuous Integration (CI), data migrations, one-click deployment and code review.

August 2, 2012 | Lorrie Hunsaker

You Get What You Pay For...

How many times have you heard the expression, “You get what you pay for?”

New Call-to-action

Sign Up For Our Monthly Newsletter

New Call-to-action