Mountain Top, Meteora, Greece

Posted 5 months back at omg blog!! lol!!



Mountain Top, Meteora, Greece

Snow Lanterns, West Village, New York City

Posted 5 months back at omg blog!! lol!!



Snow Lanterns, West Village, New York City

Forest Steps, Japan

Posted 5 months back at omg blog!! lol!!



Forest Steps, Japan

Red Petal Meadow, Mainau, Germany

Posted 5 months back at omg blog!! lol!!



Red Petal Meadow, Mainau, Germany

Tile Roof, Provence, France

Posted 5 months back at omg blog!! lol!!



Tile Roof, Provence, France

Manage Team and Personal Dotfiles Together with rcm

Posted 5 months back at GIANT ROBOTS SMASHING INTO OTHER GIANT ROBOTS - Home

Our team has a set of dotfiles at thoughtbot/dotfiles. They contain vim, git, zsh, and tmux configuration that many of us use every day.

Each of us also have personal sets of dotfiles. They augment our team dotfiles with configuration such as aliases for our personal workflow, our name and email for git, and vim syntax highlighting for languages such as Go, Scala, Haskell, or Clojure that we're playing with but that we typically don't use on client projects.

We recently released rcm which, among other things, allows a workflow where those two sets of dotfiles co-exist in harmony.

Team dotfiles as primary

The team's dotfiles could be considered the primary dotfiles repo. It is well-vetted and we can depend on it matching the latest conventions and practices agreed upon by our team.

mkdir thoughtbot
cd thoughtbot
git clone https://github.com/thoughtbot/dotfiles.git

Note the directory convention is to keep local git repos matching the {user,organization}/project GitHub structure, which also matches a Go convention.

Once we have our team dotfiles cloned, we should install rcm. On OS X, we can use the Brewfile:

brew bundle dotfiles/Brewfile

See the docs to install on other platforms.

Next, we use rcm's rcup command to symlink files from thoughtbot/dotfiles to ~/.aliases, ~/.gitconfig, ~/.psqlrc, ~/.tmux.conf, ~/.vimrc, ~/.zshrc, and others:

rcup -d dotfiles -x README.md -x LICENSE -x Brewfile

The -x options, which exclude the README.md, LICENSE, and Brewfile files, are needed during installation but can be skipped during future rcup updates because we are symlinking the ~/.rcrc file during installation, which knows to exclude those files.

If we reload our shell at this point, we'd now have all the great features from thoughtbot/dotfiles available to us. The most obvious immediate change would be the look of our prompt.

Personal dotfiles as secondary

Now, we need our personal dotfiles, for example croaky/dotfiles:

mkdir croaky
cd croaky
git clone https://github.com/croaky/dotfiles.git
rcup -d dotfiles -x README.md

That's it! Our two sets of dotfiles are living in harmony. But how does it work?

The .local convention

At the end of the files we symlinked from thoughtbot/dotfiles are lines such as this in ~/.zshrc:

# Local config
[[ -f ~/.zshrc.local ]] && source ~/.zshrc.local

Or this in ~/.vimrc:

" Local config
if filereadable($HOME . "/.vimrc.local")
  source ~/.vimrc.local
endif

These lines say "now, look for a file of the same name as myself, but with an extra .local extension." This convention makes it clean to have a second set of dotfiles around without one trampling on the other.

Most of the files we have in personal dotfiles end in .local. They are additive to the team dotfiles, which is why it can help to think of the personal dotfiles as "secondary."

Overwrite

In some cases, the .local convention isn't available, so we need to completely overwrite the file.

For example, if we use the fail-fast option in our personal rspec config but it is not popular amongst the team, it is inappropriate to live in the team dotfiles, which should represent only a reasonable subset that is valuable for everyone.

In that example, when we next update team dotfiles, rcm asks if we want to overwrite the file:

rcup -d dotfiles
overwrite /Users/croaky/.rspec? [ynaq] n

This demonstrates how rcm lets us pick a winner, and prefer our personal preference in this case.

What's next?

We recommend creating and evolving a set of team dotfiles. We can each learn many workflow tips from our teammates in team dotfiles pull requests.

With rcm's ability to manage both team and personal dotfiles together, there's no reason to be afraid of using team dotfiles, because we can always override the decisions in our personal set.

Spiral Staircase, Trinity College Library, Dublin

Posted 5 months back at omg blog!! lol!!



Spiral Staircase, Trinity College Library, Dublin

Cable Car, San Francisco, California

Posted 5 months back at omg blog!! lol!!



Cable Car, San Francisco, California

Lake House, North Carolina

Posted 5 months back at omg blog!! lol!!



Lake House, North Carolina

First Frost, Colorado

Posted 5 months back at omg blog!! lol!!



First Frost, Colorado

Episode #448 – March 14th, 2014

Posted 5 months back at Ruby5

Today, learn about the Circuit Breaker pattern from Martin Fowler, some Cucumber best practices, speedier specs, and the railroady gem.

Listen to this episode on Ruby5

This episode is sponsored by New Relic

New Relic is _the_ all-in-one web performance analytics product. It lets you manage and monitor web application performance, from the browser down to the line of code. With Real User Monitoring, New Relic users can see browser response times by geographical location of the user, or by browser type.
This episode is sponsored by New Relic

Circuit Breaker Pattern

Martin Fowler describes the Circuit Breaker pattern.
Circuit Breaker Pattern

Top 5 Cucumber best practices

Clemmens Helm has a video and blog post listing his top 5 Cucumber best practices.
Top 5 Cucumber best practices

Speed Up Your Rails Specs by 10x

Alex Peachey wrote a post showing how he speeds up his RSpec suite.
Speed Up Your Rails Specs by 10x

Railroady

Preston Lee keeps the UML dream alive with his Railroady gem: generate UML diagrams from your Rails app in DOT or SVG format.
Railroady

RailsConf 2014

The program for RailsConf 2014 in Chicago was just announced.
RailsConf 2014

Rainy Day, Paris, France

Posted 5 months back at omg blog!! lol!!



Rainy Day, Paris, France

Canal Moon Bridge, The Netherlands

Posted 5 months back at omg blog!! lol!!



Canal Moon Bridge, The Netherlands

Back to Basics: Polymorphism and Ruby

Posted 5 months back at GIANT ROBOTS SMASHING INTO OTHER GIANT ROBOTS - Home

Polymorphism - the provision of a single interface to entities of different types

Polymorphism is one of the fundamental features of object oriented programming, but what exactly does it mean? At its core, in Ruby, it means being able to send the same message to different objects and get different results. Let's look at a few different ways to achieve this.

Inheritance

One way we can achieve polymorphism is through inheritance. Let's use the template method to create a simple file parser.

First let's create a GenericParser class that has a parse method. Since this is a template the only thing this method will do is raise an exception:

class GenericParser
  def parse
    raise NotImplementedError, 'You must implement the parse method'
  end
end

Now we need to make a JsonParser class that inherits from GenericParser:

class JsonParser < GenericParser
  def parse
    puts 'An instance of the JsonParser class received the parse message'
  end
end

Let's create an XmlParser to inherit from the GenericParser as well:

class XmlParser < GenericParser
  def parse
    puts 'An instance of the XmlParser class received the parse message'
  end
end

Now let's run a script and take a look at how it behaves:

puts 'Using the XmlParser'
parser = XmlParser.new
parser.parse

puts 'Using the JsonParser'
parser = JsonParser.new
parser.parse

The resulting output looks like this:

Using the XmlParser
An instance of the XmlParser class received the parse message

Using the JsonParser
An instance of the JsonParser class received the parse message

Notice how the code behaves differently depending on which child class receives the parse method. Both the XML and JSON parsers modify GenericParser's behavior, which raises an exception.

Duck Typing

In statically typed languages, runtime polymorphism is more difficult to achieve. Fortunately, with Ruby we can use duck typing.

We'll use our XML and JSON parsers again for this example, minus the inheritance:

class XmlParser
  def parse
    puts 'An instance of the XmlParser class received the parse message'
  end
end

class JsonParser
  def parse
    puts 'An instance of the JsonParser class received the parse message'
  end
end

Now we'll build a generic parser that sends the parse message to a parser that it receives as an argument:

class GenericParser
  def parse(parser)
    parser.parse
  end
end

Now we have a nice example of duck typing at work. Notice how the parse method accepts a variable called parser. The only thing required for this to work is the parser object has to respond to the parse message and luckily both of our parsers do that!

Let's put together a script to see it in action:

parser = GenericParser.new
puts 'Using the XmlParser'
parser.parse(XmlParser.new)

puts 'Using the JsonParser'
parser.parse(JsonParser.new)

This script will result in the following output:

Using the XmlParser
An instance of the XmlParser class received the parse message

Using the JsonParser
An instance of the JsonParser class received the parse message

Notice that the method behaves differently depending on the object that receives it's message. This is polymorphism!

Decorator Pattern

We can also achieve polymorphism through the use of design patterns. Let's look at an example using the decorator pattern:

class Parser
  def parse
    puts 'The Parser class received the parse method'
  end
end

We need to change our XmlParser to include a constructor that accepts a parser as an argument. The parse method will need to be modified to send the parse message to the parser it receives when constructed:

class XmlParser
  def initialize(parser)
    @parser = parser
  end

  def parse
    @parser.parse
    puts 'An instance of the XmlParser class received the parse message'
  end
end

We'll make the same change to our JsonParser:

class JsonParser
  def initialize(parser)
    @parser = parser
  end

  def parse
    puts 'An instance of the JsonParser class received the parse message'
    @parser.parse
  end
end

We'll use the decorators to create our normal XML and JSON parsers, but in the last example, we'll do something a little different: use both decorators to achieve runtime polymorphism:

puts 'Using the XmlParser'
parser = Parser.new
XmlParser.new(parser).parse

puts 'Using the JsonParser'
JsonParser.new(parser).parse

puts 'Using both Parsers!'
JsonParser.new(XmlParser.new(parser)).parse

This script will give us the following output:

Using the XmlParser
The Parser class received the parse method
An instance of the XmlParser class received the parse message

Using the JsonParser
An instance of the JsonParser class received the parse message
The Parser class received the parse method

Using both Parsers!
An instance of the JsonParser class received the parse message
The Parser class received the parse method
An instance of the XmlParser class received the parse message

Notice how we're able to change the results of sending the parse message based on the output.

A Simple Before and After

Now we will look at an intentionally simple example of how taking advantage of polymorphism can simplify our code. Let's say we had the following classes:

class Parser
  def parse(type)
    puts 'The Parser class received the parse method'

    if type == :xml
      puts 'An instance of the XmlParser class received the parse message'
    elsif type == :json
      puts 'An instance of the JsonParser class received the parse message'
    end
  end
end

We can simplify our Parser class by removing the branch logic thanks to simple duck typing. In this particular example we also get the benefit of separating concerns. Now we have our specific parsing logic encapsulated within their own classes:

class Parser
  def parse(parser)
    puts 'The Parser class received the parse method'
    parser.parse
  end
end

class XmlParser
  def parse
    puts 'An instance of the XmlParser class received the parse message'
  end
end

class JsonParser
  def parse
    puts 'An instance of the JsonParser class received the parse message'
  end
end

This example demonstrates that we were able to simplify our class using polymorphism. We were also able to satisfy the Single Responsibility Principle.

In the initial version of the code the Parser class determined which parser to use and then initiated the parsing by instantiating and sending the parse message to the object. In the latter version this class only sends the parse method to kick off the process.

Polymorphism is one of the foundational elements of object oriented programming, but can also be confusing to get a grasp on. Taking the time to understand it and why it's important is a big step towards writing more maintainable and extensible code.

What's next?

If you found this useful, you might also enjoy:

Writing Table, Leeds, England

Posted 5 months back at omg blog!! lol!!



Writing Table, Leeds, England