Thursday, April 3, 2014

Econify Watercooler Episode 5 - Lisp macros and source to source compilers

Episode 5 of the Econify Watercooler is out! Listen in as we chat a bit about Lisp macros and source to source compilers. Have a topic you want us to discuss? Leave us a note in the comments below or reach out to us through our contact page.

Tuesday, March 11, 2014

Econify Watercooler Episode 4 - client side frameworks

We've got another episode of our podcast ready. Take a listen around the watercooler with Dan, Stephen, Lou, Billy, and John. In episode 4 we tackle some questions around client side frameworks.

Staff Picks:

Weekly Newsletters:

Monday, February 3, 2014

Econify Watercooler Pt 3 - Single Page Apps, AngularJS

Our final installment of January's Watercooler is now live. We'll be shortening the podcast going forward and also adding an RSS feed if we can somehow get into Soundcloud's beta. When that happens we'll let you know on our twitter feed and also right here on the blog.

Monday, January 27, 2014

Econify Watercooler Pt 2 - Single Page Apps, AngularJS

We're continuing our Econify Watercooler discussion with Part 2. If you missed Part 1, you can check it out here.

As always, we welcome your feedback! Also, we are HIRING a senior ruby developer in Washington, DC. If you're interested, please take a look at our careers page or take a look at our job listing over at Stack Overflow.

Friday, January 17, 2014

Econify Watercooler - Single Page Apps, AngularJS

One of the advantages of having a small, team is that we get to have interesting chats by the "water cooler". Occasionally, those get recorded. Recently we decided to publish a few of them so others could hear some of the things we talk about in between coding. Keep an eye on the blog for future episodes. We also welcome requests and constructive feedback!

Update: Part 2 is up!

Wednesday, September 25, 2013

Dirt-simple validation and coercion in Ruby

Dirt-simple validation and coercion in Ruby

How many times have you been bitten by Ruby’s dynamic typing? Personally, this happens to me all the time–which might explain why the last few posts here have been Haskell posts ;)

It’s not Ruby’s fault though, many times this flexibility is exactly what we want to get something up and running quickly. Get it done. Ship it!. Right? Right. Well…maybe.

Perhaps we can find some kind of happy medium? Are there any lightweight strategies we can use to ensure that the values in our program are what we think they are?

Picture this: you are working with some sort of service. You need to deal with values accessible in your domain object that might or might not be nil. Further, when these variable are not nil, they will be coming over the wire as strings.

How can we develop a nice way to deal with this?

Coercive behavior

Let’s take a crack at this with wish driven development.

Say we have a method named coerce. coerce will take a value, and if it is nil, it will leave the value alone. If the value is non-nil it will return the value untouched.

@foo = nil
@bar = "34"

coerce(@foo) # => nil
coerce(@bar) # => "34"

Hey wait, that’s not helpful at all! That’s just the identity function, passing back whatever we give it. Well, sure, but you gotta start somewhere. How can we make it better?

Instead of just returning the non-nil value, we’d like to convert the parameter using some logic that we specify. This is a perfect place to use a block:

coerce(@foo) {|foo| foo.to_i} # => nil
coerce(@bar) {|bar| bar.to_i} # => 34

Cool, but it’s a little bit verbose. Let’s use the old symbol #to_proc trick to cut it down a bit:

coerce(@foo, &:to_i)  # => nil
coerce(@bar, &:to_i)  # => 34

And, if we don’t pass a block, it will keep the old behavior and just return the value as a string.

coerce(@bar) # => "34"

Nice. But what happens when we don’t want to silently ignore a nil value? Depending on the use case, ignoring bad data like this could be a recipe for disaster! The answer here is obvious, we can just make a version of our method that will raise an error on nil.

coerce!(@foo) # => raise CoercisionError, 'Expected a non-nil value'
coerce!(@bar, &:to_i) => 34


Alright, so how do we implement this logic. We want to have this method available in any class or module we right, so let’s create it as a Module that we can include in our domain classes.

module Coercion
  class ::CoercionError < StandardError; end

  def coerce(value, &transform)
    transform = transform || identity_transform

    if value.nil?

  def coerce!(value, &transform)
    raise CoercionError, 'Expected non-nil value' if value.nil?
    coerce(value, &transform)


  def identity_transform
    @identify_transform ||= lambda { |value| value }

Super simple, but effective. We could easily add to this framework to raise errors if the transform doesn’t have a value it can do something meaningful with, etc.

The point is though, that we can use a method like coerce to do lightweight validation at the beginning of a method, and then not have to worry about it anymore. Instead the code can focus on doing the one thing the method is supposed to be doing.

The method is doing just one thing, right?

What do you think? How do you handle ensuring that the values you’re passed are the type you expect? Do you do some sort of lightweight validation like this? Use a gem to do it? Don’t worry about it and let Ruby throw an error?

Let us know in the comments below!

P.S. Interested in working with us? We’re currently looking for a senior level Ruby developer. Check out our listing and get in touch.

Wednesday, September 18, 2013

Fun with Applicative Functors, Pt III

Fun with Applicatives, Pt. III

Welcome back. This time we're going to wrap up our series on Applicatives by taking a look into command line option parsing. Using the optparse-applicative package, we'll add flexibility to roller's CLI. Optparse-applicative leverages Applicative to separate the handling of options parsing from the actual function that uses those options. It also provides some niceties like creating our program's help banner.
Let's get started and see how it works.