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?
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.
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
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.
Note: This is part one (next) of a seven part series.
Bryan's article describes Value Objects as "simple objects whose equality is dependent on their value rather than an identity."
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.
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.
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.
Feature planning has to be done early and often. But it can be a complicated process due to all of the stakeholders involved, each with different viewpoints and goals.
What's more, it's easy to overlook key behaviors of a feature, which can lead to expensive and rushed code later. It's usually intuitive to figure what should happen when everything goes according to plan, but what about edge cases? What should happen when a user supplies bad data? A hacker launches a malicious attack on our application? What about when chaos makes the whole system unstable?
In the first post of this miniseries, we'll take a look at one way to get everyone's voice heard in the planning process, including the product owner, developer, designer, and QA engineer. Using this approach, teams can draw on their diverse perspectives to tease out a detailed blueprint of a feature that costs less and performs better.