7 Patterns to Refactor JavaScript Applications: Service Objects

Note: This is part two of a seven part series that starts here.

Service Objects are objects that perform a discrete operation or procedure. When a process becomes complex, hard to test, or touches more than one type of model, a Service Object is useful for cleaning up your code base. Even a Service Object that performs one single step can be a valuable abstraction for clarity and testing.

To ensure isolation of a Service Object, follow these principles:

  • Strict with input and output. Service Objects are designed to handle a very specific process, so we can forego the Robustness Principle in favor of creating a tool for a single, specific purpose.
  • Documented thoroughly. Since Service Object code likely lives in a different file than the code where it is used (e.g. a controller or model method), the reader will not have the benefit of context when trying to understand what the Service Object is doing. Hence, documenting the argument types, logical paths, and return values is crucial.
  • Terminates after completion. This pattern should not be conflated with a worker process, which could set an interval, listen for web socket messages, or perform some other procedure with no immediate end. Service Objects should be invoked, perform their operations (whether synchronous or asynchronous), and terminate.
Read More

Middleman: Static Sites Aren’t Just for Blogs

When working on a new language, framework, or toolset, we’re often working with an example that wants us to build a blog. While blogs are great and easy to build, they are a limited in scope, and it could be we’re looking to build a different sort of static site—one that isn’t a collection of posts arranged by date. So what's the alternative?

Enter Middleman.

Middleman is a framework built for the purpose of creating simple static sites. Think of it as Jekyll, but for everything that isn’t a blog. And in this post, we’ll look at creating a simple static site with Middleman. This example was built using Ruby version 2.1.1p76.

Read More
Learn about Engine Yard
Try Engine Yard for your Ruby or PHP Apps

High Performance C4 Instances Now Available

Conducting machine learning or statistical analysis on large data sets? Running an MMO? Operating your own ad server? AWS C4 instances are ideal for this sort of high intensity computing requirements, and are now available on Engine Yard.

The new C4 instances are based on custom 2.9 GHz Intel® Xeon® E5-2666 v3 (Haswell) processors, optimized specifically for AWS.

All of the following flavors of C4’s are currently available:

C4 Instance Name vCPU Count RAM Network Performance
c4.large 2 3.75 GiB Moderate
c4.xlarge 4 7.5 GiB Moderate
c4.2xlarge 8 15 GiB High
c4.4xlarge 16 30 GiB High
c4.8xlarge 36 60 GiB 10 Gbps

As always, Engine Yard C4 instances are priced at a 25% discount from Amazon On-Demand, and Platform & Support starts at $0.087/hour. Please contact Engine Yard today to learn more about how these instances can help your business grow.

7 Patterns to Refactor JavaScript Applications: Value Objects

Note: This is part one of a seven part series. Visit part two to learn about Service Objects.

On October 17, 2012, Bryan Helmkamp, founder of Code Climate, wrote a blog post outlining seven patterns to refactor fat ActiveRecord models in Ruby on Rails. This post is the first of a seven part series that will demonstrate these concepts in the JavaScript environment. I will show that they are just as applicable, and equally as valuable. Each post will cover one of the seven patterns in detail. In this post we'll be talking about Value Objects.

Bryan's article describes Value Objects as "simple objects whose equality is dependent on their value rather than an identity."

Because JavaScript adheres to the "pass-by-reference" principle for all JavaScript objects, there are no native examples of this in ECMAScript 5 or even Harmony, save for primitives.

For example:

// Primitives
var foo = 2;
var bar = 2;
foo === bar; // => true

// Object identity
var foo = new Number(2);
var bar = new Number(2);
foo === bar; // => false

The first example assigns primitive integers to the variables foo and bar, which are equal by their value, even though primitives are technically still objects in JavaScript. The Number constructor, even though it provides a wrapper for primitives, is a Plain Old JavaScript Object, and is therefore equal by reference, not value. Thus, in the second example, foo does not equal bar, even though both Number instances represent the same integer value.

But Value Objects offer a great place for domain logic to reside. Almost every value type in your application has logic associated with it, such as equality, and the best place for that logic is in a value object.

Read More

Happy, Sad, Evil, Weird: Putting Use Case Planning Into Practice

In part one of this miniseries, we introduced formal Use Case Analysis and a simplified version called Use Case Planning which fits a rapid, iterative development process. That post went over the high-level concepts, and explained how this planning method will help you catch problems with your design before you start to implement.

In this post, the final post of this miniseries, we’ll step through a concrete example so you can see how to put Use Case Planning into practice.

An Example

We'll imagine that we work for a company that is building a multi-tenant Software as a Service (SaaS) platform where people can set up shops and sell products. Tenants will be able to charge their customers through the platform.

We're part of a team that's getting ready to create a credit card payment acceptance feature. It will be a credit card form common to all of our tenants. We'll be writing the markup by hand and using of Stripe for processing cards. We're entering a sprint planning meeting to define the scope of the work to be done and decide how long it will take to build. During this meeting, we'll talk about many different aspects of the billing process.

For the purposes of this post, let's hone in on one specific feature: once a user has clicked Buy, they are presented with a credit card form. We want to plan what will happen when they try to make use of this form.

Let's walk through the Use Case Planning process for this scenario.

Read More

CHECK OUT OUR CURATED COLLECTIONS

Look through our specially curated posts to get focused, in-depth information on a single topic.