Tuesday, August 31, 2010

Models, they make everything look good

One of the most common best practices in Rails is to keep the controller light weight. This helps maintain the code's readability maintainability, and refactorability (just like coding, I make stuff up). This is often done by pushing as much of the business logic as you can (where it still makes sense) down into a model.

At kaChing, we don't use ActiveModel as our backend layer. Instead, persistence is handled over the wire through RPC requests. However developers often forget (including myself) that models themselves are good encapsulation objects and can be used beyond the ActiveModel layer. Just the other day, I started out by writing the following code sample in a controller method

def some_method

 date_string = nil

 if params[:param_a] == "false"
  begin
   date_string = params[:date].to_date.strftime("%Y%m%d")
  rescue
   raise "Some error"
  end
 end
 
 array = []
 for key, value in params[:param_C]
  # initialize array
 end

 if params[:param_b] == "set"
  make_rpc_request(params[:account_id]
 end

 make_another_rpc_request(params[:account_id], array, date_string)
end

There are some problems with the above code beyond the bloated controller method
a) it makes testing this controller method harder because now it requires the developer to know how to setup the test, which leads to...
b) testing becomes more fragile.

What I ended up doing instead was to refactor the controller by moving the business logic into a param model as follows

class SomeMethodParams
 attr_reader :array, :param_b_is_set, :account_id, :date
 
 def initialize(params)
    # init params here
    @param_a = params[:param_a] == "true" ? true : false
    @param_b_is_set = params[:param_b] == "set" ? true : false
    @param_c = params[:param_c]
    @account_id = params[:account_id]
    @date = params[:date]
    initialize_date(params)
    initialize_array(params)
 end

 def initalize_date(params)
  unless @param_a
   @date_string = @date.to_date.strftime("%Y%m%d")
  end
 rescue
  raise "Some error"
 end

 def initalize_array(params)
  for key, value in @param_c
   # set array
  end
 end
end

I can then simplify and refactor the controller code down to

def some_method
 some_method_params = SomeMethodParams.new(params)
 make_rpc_request(some_method_params.account_id) if some_method_params.param_b_is_set
 make_another_rpc_request(some_method_params.account_id, some_method_params.array, some_method_params.date_string)
end

What's great now is that not only do I have a super lightweight controller method,
I also have a couple of other additional benefits:
1) the code is easier to read (keep other developers happy)
2) testing becomes easier, less fragile, and more focused (separation of concerns)

Type inference puzzler

Does this compile?

public class Puzzle {
    static Object one() {
        return 1;
    }
    static <T> T safeOne() {
        return (T) one();
    }
    public static void main(String[] args) {
        int one = safeOne();
        System.out.println(one);
    }
}

Take a look at it carefully and think before answering. Why or why not? Once you've thought it through, give it a try.

Were you surprised by the result? Now try this: if you tried it out in Eclipse, try it with Sun's javac. If you tried it with javac, try it with Eclipse.

Monday, August 30, 2010

Creating TypeLiterals in Scala

In case anyone wondered, here is how one can easily create instances of Google Guice's TypeLiteral in Scala. Type literals are used for reifying types.

def typeLiteralOf[T](implicit m: scala.reflect.Manifest[T]): TypeLiteral[T] = (m match {
case m: ClassManifest[T] if m.typeArguments.isEmpty =>
TypeLiteral.get(m.erasure)
case m: ClassManifest[T] =>
TypeLiteral.get(new ParameterizedTypeImpl(m.erasure, m.typeArguments.map {
case n: ClassManifest[_] => typeLiteralOf(n).getType
}.toArray))
}).asInstanceOf[TypeLiteral[T]]

ParameterizedTypeImpl is part of our code base, but a similar implementation is defined in Guice's MoreTypes class.

We can then use the typeLiteralOf function like this:

injector.getInstance(Key.get(typeLiteralOf[List[String]]))

Careful though, this implementation does not cover all cases. Check out scala-guice for a bullet-proof version.

Sunday, August 15, 2010

Had a great Lean Startup TGIF at kaChing

Last Friday we had some great time at the kaChing "Lean Startup TGIF".
Engineers and entrepreneurs came over from all over the Bay area as far as San Francisco and Berkeley. We chatted about Lean Startups, Continuous Deployment, Test Driven Development/Deployment, Monitoring, seeking talent and geeking around about the next big thing. There was lots of good cheese, wine and beer. At the end of the event we had our kaChing traditional TGIF Beer Pong.

If you're interested in the next meetup drop a comment below and we'll shoot you a message when the time comes.

August Coolness

The entrepreneurs roundtable are hosting us this Thursday to talk about kaChing's engineering practices. To sign up, head to Facebook event page.

The event is this Thursday August 19th and is hosted by Pillsbury Law Firm in Palo Alto, 2475 Hanover Street. It will start 6pm.

Thursday, August 12, 2010

Type Safe Bit Fields Using Higher-Kinded Polymorphism

Refering to securities, such as stocks or bonds, is far from standard. We all know Apple's ticker AAPL; But what about the Oracle of Omaha's company Berkshire Hathaway? Google says BRKA, Yahoo! BRK-A, Bloomberg BRK/A and Reuters BRKa.

Due to these oddities, every serious automated trading system like kaChing's has at its core a powerful cross-referencing system called a security master.

To handle ambiguous tickers which are context sensitive we have resorted to tagging. For instance, BRKA will be tagged with "good for Google" whereas BRK-A will have a "good for Yahoo!" tag. In this article, we will cover tagging data in a type safe way using higher-kinded types in Java.

Since Java's type system does not offer kinds, we will emulate them using marker types.

interface SecurityTag {
interface Google extends SecurityTag {}
interface Yahoo extends SecurityTag {}
interface Bloomberg extends SecurityTag {}
interface Reuters extends SecurityTag {}
}

Using our kinds, we can create a kinded tagged ticker wrapper.
class TaggedTicker<T extends SecurityTag> extends AbstractIdentifier<String> { ...

Wrappers like TaggedTicker (see AbstractIdentifier) are immensely useful to let the compiler hand hold you in various contexts. Consider the following API.

double getPriceFromGoogle(TaggedTicker<Google> ticker) { ...

void sendBuyOrderToBbg(TaggedTicker<Bloomberg> ticker, int quantity) { ...

It is simply impossible to trip yourself. The code embodies the intended data flow. Correctness by design as exemplified by these signatures pays such high dividends that it has become second nature in our code base.

Finally, let's add a method to retrieve a tagged ticker from a security.
interface Security {
<T extends SecurityTag> TaggedTicker<T> getTaggedTicker(Class<T> kind);
}

Here again, the signature precisely captures our intention.

  1. Kinds, such as T, extend SecurityTag
  2. Given a kind (materialised by values of Class<T>)
  3. Return a ticker tagged by T


Under the hood, we associate with each ticker a bit field where positions encode contexts. The mapping between kinds and bit field position is captured in a map.
private static final Map<Class<? extends SecurityTag>, Long> TAG2MASK
= ImmutableMap.<Class<? extends SecurityTag>, Long>builder()
.put(SecurityTag.Google.class, 0x01)
.put(SecurityTag.Yahoo.class, 0x02)
.put(SecurityTag.Bloomberg.class, 0x04)
.put(SecurityTag.Reuters.class, 0x08)
.build();

It is then straightforward to write the usual set and unset methods.
public <T extends SecurityTag> void set(Class<T> kind) {
tags = (tags | TAG2MASK.get(kind));
}

public <T extends SecurityTag> void unset(Class<T> kind) {
tags = (tags & ~TAG2MASK.get(kind));
}

You'll notice that the non type safe part of the implementation is kept to the strict minimum and easily testable.

From the high-level description provided here, it should be easy to apply this technique to your own problems. By investing a little time upfront, you will be able to better leverage domain experts' knowledge. Consider a new employee discovering TaggedTicker<Yahoo> in the code; He will either understand why this complexity is required or pause and ask a peer. In most organisations, you would instead have String yahooTicker and a legion of bugs. Test-Drive Safely: Use Types!

PS: If you like such topics, register for the Applying Compiler Techniques to Iterate At Blazing Speed talk at the next Silicon Valley Code Camp.

Thursday, August 5, 2010

Lean Startup TGIF at kaChing

kaChing is hosting a TGIF on August 13th to gather smart people doing hard stuff around wine and cheese. We'll talk about software architecture, test-driven development, continuous deployment and what not.
Few invitations left, contact us if you're interested!

  ©kaChing