Functional Rails API

A while back I wrote a library called rfunk. This library provides some functional programming concepts that you can give a try or contribute to if you like.

I know there are other libraries now out there and they might do a better job. Regardless I wanted to try it out to see how one might build an API that used these concepts.

Here you can find the controller that performs the action and the associated features to see it working. I think it clearly defines what a success case might be and what a failure is.

The whole repository is here if you want to check it out. Might add more features as I go along. I hope you enjoy it!

Cucumis

After getting tired of writing the same steps over and over in Cucumber I decided to start a gem. Currently in it's infancy though I plan to grow it as time goes on.

It currently supports the following:

1. Checkin ActiveRecord models wiht the table provided.
2. Checking a table matches a HTML table.
3. Sets up all sorts of browsers so you can quickly switch between them (headless and real)

Check it out and contribute if you like. You can find it here.

KnockoutJS

Recently I had the opportunity to do some work with this awesome framework. Not like any other JS framework that I have used before.

In the past we all have had the obsession of usually writing two versions of an MVC application both in the front and the back.

Though for me this felt liberating (it just uses data-bind attributes). The front end was all seperate from the backend. Meaning I could replace the backed with whatever technology I wanted (I chose Ruby On Rails) and the application would still work. The caveat is that you generate the same HTML (which should not be an issue, until you redesign). The MVVM pattern is really exciting and can't wait to try it out on other technologies.

It does not lock you into any testing framework. Does not tell you how to get the data from the server (use Backbone or jQuery as examples). Doesn't tell you how to route (I chose Navigo). Having this flexibility for me was so good as I was learning and when I hit an issue I could not solve I could just replace it

The only downside that I found was with testing (as I do all my testing in Cucumber) was that it could not be used with a headless browser (webkit or poltergeist), so you have to use either Firefox or Chrome with selenium-webdriver. I am sure that this will get better.

Highly recommend learning it and it has great support online. If you get some time check it out KnockoutJS and its great tutorials.

Ruby and NO_PROXY

Proxy Servers

Like most people where they work there is always a proxy server present.  Love them or hate them they are here to stay. Recently where I am working we faced a problem. All the HTTP traffic is going thorough the proxy. However there was a specific case where we did not want it to.

The Problem

When we sent a request to a URL lets call it http://example.com (please note that this is an internal address) it would resolve to a load balanced address. For some reason (I'm not a networking guy) the proxy could not connect to it.

The Solution

What I needed to do was the following:

1. I edited the /etc/hosts file and added IP_ADDRESS example.com
2. I added export no_proxy="example.com" so it does not use the proxy. 

However the fun did not stop there. We were using Faraday to connect to this server. What I realised is that the default Ruby HTTP implementation does not honour no_proxy environment variable. So after some researching I found that httpclient does. So all I needed to do is install the gem and then use it:

conn = Faraday.new(url: 'example.com') do |faraday|
  faraday.request  :url_encoded
  faraday.response :logger
  faraday.adapter  :excon
end

Call conn.get and everything worked.

As I found it hard to find a solution I thought I would write it down for someone else to find it useful.

Configuring Chef Development Environment

Background

At the current place that I am at one of the things that we are lacking is the concept of Infrastructure as Code. So I have decided to put my DevOps hat on and get the ball rolling.

I decided to use Chef as it feels more natural to me as a Ruby developer. The setup process was not as straight forward as I thought so I decided to document it, as I will forget later on.

Installation

1. Download and Install Virtual Box.
2. Download and Install Vagrant.
3. Download and Install the Chef Development Kit.
4. We are going to be using Berkshelf so we need to set this up:
1. If you are using RVM find where RVM sets 'source "$HOME/.rvm/scripts/rvm"' after that place the following: export PATH=$HOME/.chefdk/gem/ruby/2.1.0/bin:/opt/chefdk/bin:$PATH
2. Type which berks and you should get /opt/chefdk/bin/berks
5. Lets create a cookbook to test out:
1. Type berks cookbook chef-test
2. Type cd chef-test
3. Open up the Gemfile and remove gem 'berkshelf'
4. Type bundle install
5. Open up your Vagrant file and comment out 'config.vm.network :private_network, type: "dhcp"'
6. Lets install some Vagrant plugins:
1. Type vagrant plugin install vagrant-berkshelf
2. Type vagrant plugin install vagrant-omnibus
7. Lets fire up the cookbook by typing vagrant up.
8. Profit!

Implementing Specification By Example

Recently I have had the pleasure to work with different teams and companies. The interesting part of seeing how different people work is that I learn a lot from their codebase.  At my current work we follow the concept of specification by example, however these specifications are often a pain point for our teams. I wanted to take the time to explore some successful ways of implementing specification by example.

Background

There are many terms that have been described for these sets of practices that I won't go into. However I think specification by example is the better term, as we tend to describe software via interactions (or examples). To get yourself up to speed I will recommend two great books on the topic:

1. Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing
2. Specification by Example: How Successful Teams Deliver the Right Software

Recommendations

Below will be a set of topics that I believe are important in having good specification by example. Please take them as a recommendation and not as a rule. I also encourage you to challenge these recommendations to find better ones.

Language

The biggest thing I find when writing these features is the language that is being used. We have to remember that the language that we use needs to reflect the domain we are trying to model. Often I encounter that these features are written through the eyes of the computer.

What we have to remember when writing these features is to focus on the WHAT not the HOW. A great friend of mine has done a fantastic job explaining how to do this. I urge you all to read it.

The language is really important. Try to get other people to read it and get them to explain what the example is trying to do.

Pick your battle

Follow the guidelines of the testing pyramid. Often I see people complain about their tests taking too long and being brittle. Remember that the UI is brittle at times, however in my view the end-to-end test is the most important one. If you can comfortably test a layer below it then go ahead. Use your judgement.

Informative Steps

Often I have seen that some information is missed out because there is no action for that step. This should be avoided. It does not matter if a step performs an action, if it helps with the intent write it in.

Behind the Scenes

Here is the big thing that I think people get wrong (of course this is my opinion). When writing features we seem to forget that we need to still apply all the great concepts we do for our main application. The biggest thing here is knowing what layer does what.

Usually when writing these features, people tend to dump all of their code into the steps file. This quickly becomes a nightmare to manage. Here are some guidelines I have used to make sure this becomes easy to follow:

1. The steps should only contain the builders and expectations.
2. Use the concept of a PageObject pattern. If you want a great library use dill.
3. Limit the use of the World. This just becomes a massive god class.
4. If you find yourself writing similar code, move it to a reusable module that all your projects can use.

Remember: Treat your test code the same way as your production code.

Creating Preconditions

Often we need to create a precondition (the given step in gherkin speak). What I have found is that people create a table where the key of that table is put through a mapping of the property of the model. This should be avoided. One of the worst things that you can do is create a translation layer. DDD has a concept of Ubiquitous Language, I suggest that you follow it.

Watch your Failures

One of the most underrated techniques I see is that people don't look at the failure message. How often have we seen expected true but got false. These errors don't help. Make sure you get a failing scenario first and read the message. Does it make any sense? Could you diagnose the issue?

Conclusion

These patterns have served me well in the past so I wanted to share them with you all. Feel free to challenge them so we can all learn to do things better. Of course context is king. So if you have any specific examples you would like discussed feel free to share.

Micro and Nano Services

Recently there has been a lot of hype around services. Why would there be any hype we have had the concept of Service Oriented Architectures for a long time. Well for some people SOA has not served them well. I think this just coms down to not understanding and the fact that SOA can be a complicated topic to get your head around.

With the advent of SOAP, RPC, DCOM, CORBA, etc made the SOA a very hard thing to get right. None of these technologies are compatible with one another or event interchangeable.

After going through some of these technologies we realised that maybe we should embrace HTTP as the transport. This gave rise to REST. A long with this realisation people started to remember what smart people before us have done to build software. If you look at the UNIX Philosophy we see some points that have really fascinated me:

1. Small is beautiful.
2. Make each program do one thing well.
3. Choose portability over efficiency.

I think REST and the UNIX philosophy gave rise to micro services.

Micro Services

I first heard of this term a couple of years ago. We have been building services for a very long time, though I always felt there is something wrong, oh thats right it was always a monolithic pile of crap I was building. The basic idea of a micro service is to break up your problem into smaller problems and the only coupling you have between them is the HTTP protocol (which really has proven to be stable). Micro services can be thought of as a the bounded context in DDD.

So what are some of the good properties that a micro service can bring us?

• We can implement the service in whatever language we want.
• We can deploy each service individually.
• We can scale each service individually.

I will try out a few things and see what is the best way to build these services. This was inspired by a great talk I heard at YOW 2013 by Sam Newman called Practical Considerations of Micro Services

Nano Services 

The concept of nano services was brought up when I was at YOW 2013 by Steve Vinoski. When he first raised it he mentioned that he found an article that described it as an SOA Anti-Pattern. Though what he meant was having the ability to build really small services within the language that you use.

These services are really about some of the new concurrency and parallelism patterns, such as:

1. Actor Model
2. Communicating Sequential Processes

A very interesting term indeed.