Red Petal Meadow, Mainau, Germany

Posted about 1 month back at omg blog!! lol!!



Red Petal Meadow, Mainau, Germany

Tile Roof, Provence, France

Posted about 1 month back at omg blog!! lol!!



Tile Roof, Provence, France

Manage Team and Personal Dotfiles Together with rcm

Posted about 1 month 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 about 1 month back at omg blog!! lol!!



Spiral Staircase, Trinity College Library, Dublin

Cable Car, San Francisco, California

Posted about 1 month back at omg blog!! lol!!



Cable Car, San Francisco, California

Lake House, North Carolina

Posted about 1 month back at omg blog!! lol!!



Lake House, North Carolina

First Frost, Colorado

Posted about 1 month back at omg blog!! lol!!



First Frost, Colorado

Episode #448 – March 14th, 2014

Posted about 1 month 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 about 1 month back at omg blog!! lol!!



Rainy Day, Paris, France

Canal Moon Bridge, The Netherlands

Posted about 1 month back at omg blog!! lol!!



Canal Moon Bridge, The Netherlands

Back to Basics: Polymorphism and Ruby

Posted about 1 month 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 about 1 month back at omg blog!! lol!!



Writing Table, Leeds, England

A Closer Look at Color Lightness

Posted about 1 month back at GIANT ROBOTS SMASHING INTO OTHER GIANT ROBOTS - Home

As much as we strive to control every detail of what we build, we are sometimes left with little choice but to leave some design decisions to algorithms. The challenges associated with these decisions become a lot more significant when human perception comes into play. One common example: programmatically choosing a foreground color based on a given background color.

It may sound trivial at first, but having a closer look reveals that there is a bit more to it under the surface. A quick Google search will give some hints, but it will probably end up in more confusion, not least due to the inaccurate use of terms related to the topic.

So, let’s get this straight.

A bit of terminology

Before crunching any numbers, let's define some key concepts relating to colors in the context of screens:

  • Brightness: In a broad sense, brightness is the attribute of an object emitting or reflecting light. More specifically, it's the arithmetic mean of the three components in the RGB—red, green, blue— color model or the third component in the HSB—hue, saturation, brightness—model.
  • Radiance: The total amount of light that goes through a particular area.
  • Weighted: We do not perceive all wavelengths the same; for instance, we tend to perceived green to be lighter than blue or red. A weighted attribute is an attribute that takes that into consideration by giving more weight to green, and less to red and blue.
  • Luminance: Weighted radiance.
  • Gamma correction: The process of coding and decoding luminance with the aim of optimizing the output for human vision.
  • Luma: Used primarily in video, luma is the weighted sum of gamma-corrected RGB values.
  • Lightness: A subjective measure of brightness, relative to the brightness of a white point.
  • Normalization: The process of expressing lightness as a ratio corresponding to the absolute lightness value of the color to that of pure white.

In short, brightness is an absolute measure of light emitted or reflected from an object, while lightness is a subjective measure of perceived light.

How to Determine Lightness

There are several ways to approximate the lightness of a color, with varying degrees of precision. Some are weighted—they take into consideration how we perceive colors—and some are not. For simplicity's sake, we will refer to the value of lightness as L throughout this section. Pure red (255,0,0) will be used as an example.

Non-weighted Methods

These formulae do not take into consideration the perceived lightness of the primary and secondary colors. In other words you'd find out similar results for hues that are primarily red and ones that are primarily green.

Using HSB Brightness

The brightness component of the HSB model corresponds to the value of the largest RGB component:

brightness

Ex: Pure red would have an HSB value of 255 (1.0 normalized) since both other components are null.

Using HSL Lightness

The lightness component of the HSL—hue, saturation, lightness—model corresponds to the arithmetic mean of the largest and smallest RGB components:

lightness

Ex: Pure red would have an HSL lightness of 127.5 (0.5 normalized).

Using Intensity

Intensity is the average of the three components in the RGB space. It could be calculated using an arithmetic mean

arithmetic

…or a geometric one:

geometric

Ex: Pure red would have an arithmetic intensity of 85 (0.33 normalized), and a geometric intensity of 0.

Using Euclidean Distance in 3D RGB space

Considering a three-dimensional, cube-shaped RGB space, lightness would correspond to the Euclidean distance between the color point and the space origin (black):

euclidean

Ex: Pure red would have a euclidean lightness of 255 (0.57 normalized).

Weighted Methods

Weighted formulae take into consideration the perceived lightness of the three primaries, by giving each a coefficient corresponding to how light or dark the human eye perceives it. In video, weighted lightness is commonly referred to as luma.

W3C Method (Working Draft)

w3c

Ex: Pure red would have a W3C lightness of 76 (0.299 normalized).

sRGB Luma (Rec. 709)

709-luma

Ex: Pure red would have a lightness of 54.2 (0.21 normalized).

Using Weighted Euclidean Distance in 3D RGB Space

This method is not official, but it has been reported that it produces better results than the above two:

3d-distance

Ex: Pure red would have a lightness of 125.1 (0.49 normalized).

Tests

In order to determine which of these methods is more reliable, we need to test them with different colors and lightness thresholds, then aggregate the results.

  • Each color will have a subjective, expected outcome (dark or light).
  • If the test result matches the expected outcome, it will be assigned a value of 1. Otherwise it is 0.
  • The higher the score of a method/threshold combination, the more reliable it is.

The tests will be manually run using this online tool made specifically for the purpose.

Results & Conclusion

<figure> Results <figcaption> Plotting the accuracy of the different method/threshold combinations </figcaption> </figure>

Looking at the test results and the chart above, we can make few observations:

  • Weighted methods yield better results than non-weighted methods.
  • In general, the higher the threshold, the more accurate the results.
  • Purples, magentas, and greens yield the most inconsistent results across the different methods.
  • HSB brightness with a .5 threshold yielded the least accurate results.
  • Weighted Euclidean distance (.7) and sRGB luma (.6) performed best within this test.

While there is no method that will be accurate 100% of the time for all the colors in the gamut, using sRGB luma to approximate the perceived color lightness will get decent results for the most common use cases. Otherwise, adjusting the threshold (using the tool mentioned above) or even the per-color coefficients might help improving the outcome.

Here are some example implementations that you can already start using in your own projects.

Junior Dev Ops Award winning company, prestigious country location, near Reading/High Wycombe

Posted about 1 month back at Ruby on Rails, London - The Blog by Dynamic50

Great opportunity for an engineer/developer or design minded technical administrator to work with an award winning and high profile bespoke Ruby on Rails application. Supporting, customising and developing the deployment toolset for the cloud based web apps in a SaaS environment.

Prestigious countryside town location, Oxfordshire near Reading/High Wycombe

Working in small team on award winning web application.

Opportunity to really contribute in an award winning small company.

- Using and developing infrastructure management and application deployment tools for automation and continuous integration of systems and applications.

- Learning Ruby and Shell scripting as well as using script based tools such as Capistrano and Puppet.

- MYSQL management and programming.

- OS and application builds and updates.

- Capacity planning and application deployment

Send your resume to contactus@dynamic50.com or give us a call on 02032862879

Linking up Manchester's data

Posted about 1 month back at RicRoberts :

My helpful screenshot

We’ve recently started work on an new open data initiative called the Greater Manchester Data Synchronisation Programme, (or GMDSP for short). As the name suggests, we’ll be working with authorities in the Manchester area including Manchester City Council, Salford City Council and Trafford Metropolitan Borough Council, who will all publish some similar data sets as Linked Open Data at the same time - that’s the synchronisation bit.

To make this happen we’ll be helping some local code fellows (recruited specifically for this project to work alongside council staff) to convert and publish a selection of datasets to rdf. With our guidance, they’ll model the data and upload it to our PublishMyData platform. In future phases of the project, we plan to build on the work of the code fellows to produce tools and workflows to make the whole process more repeatable.

This project is a collaboration between the Connected Digital Economy Catapult, Future Cities Catapult and Future Everything - the latter we worked with on Nesta’s digital social innovation project over the last year.

As part of their annual festival in Manchester at the end of the month, FutureEverything are organising a hack event (with a £3500 prize fund) focused around the first release of the data. There’s a pre-event at this month’s OpenDataManchester, for propsective participants to meet some of the stakeholders and get advance notification of judging categories.

It’s always great to be involved with others who are also passionate about public sector linked open data. And it’s especially exciting to be working on this Manchester-based project, because it’s where our technical team lay their hats after all.