The new ility

As an architect, you’ll be concerned with a number of qualities that you need to ensure your systems, applications, services and infrastructure have.  I use PASSME as a handy mnemonic to remember the most common of these qualities (performance, availability, security, scalability, maintainability and extensibility.)  It’s fairly common to use the shorthand "ility" to refer to any of these qualities.  When making architectural decisions, you will be keenly aware which ility you are trading for which other ility.  A key ility is affordability.  Most of us do not treat money as an infinite resource.  However, when it comes to energy consumption, there are many among us who do assume there is an infinite supply.  Pretty soon if not already, energy consumption and environmental impact are going to become an ility - and a very important one.

Ruby Tuesday #16 Part 1 : A Little Light Metaprogramming

One of the reasons I was interested in learning about Ruby is metaprogramming.  For those new to Ruby, consider the following code:

class Test
 (0..5).each do |i|
    define_method "method_#{i}" do
      puts "Hello World #{i}"
    end
  end
end

Ok, it may not be the most useful piece of code in that form, but I think it shows just how metaprogrammable Ruby is.  When you remember that you can modify classes at runtime, alias methods and so on, the possibilities start to become clear.  If this has got you thinking about metaprogramming and what you could use it to achieve, this post goes into more detail on metaprogramming techniques in Ruby.

Ruby Tuesday #15 : Ruby Round Up

There’s a few things I’ve noticed over the last week in the Rubyverse that I thought it was worth highligting.  In no particular order, here we go.

In my Ruby doodlings, I’ve spent quite a bit of time with REXML.  GIven that I’m focussed on learning Ruby rather than deploying code, there’s no issue.  However, this post from RubyInside shows there are alternatives such as libxml-ruby.

Testing, both TDD and BDD style, are prominent in the Ruby community.  This post examines the reasons to unit test, questions the emphasis placed on unit testing and highlights the importance of remembering why you test.  Well worth reading and relevant regardless of your preferred language.

Finally, I came across a couple of resources that those who, like me, are learning Ruby may find valuable.  The first is the news that there is a new chapter in the Book of Ruby.  The second is a couple of posts about learning Ruby for C#ers.  These posts also mention IronRuby, so well worth reading.

Ruby Tuesday #14 : Creating an Authority

This week I decided to put my new-found Ruby knowledge to practical use.  Marc has embarked on a micro quest to build a game in WPF.  I’m going to contribute to the project along the way - the first contribution was to write basic save and load routines for maps.  The next step is to enhance that to support SQL Server Data Services - (I’ll blog about the non-Ruby elements to this another time.)  SQL Server Data Services (SSDS) uses an authority as the highest level of storage.  Authorities contain containers, which in turn contain entities.  The first step, then, is to create an authority.  This step is a one-off operation, so it lends itself to an administrative script - I figured Ruby would be a good choice for this task.

As it turns out, someone else must also figure Ruby is a good choice because there’s documentation on MSDN about how to create an authority using Ruby here.  In fact, it looks like there’s Ruby samples for all of the REST interface to SSDS.  Instead of just copying the code and creating the authority, I thought I’d take some of the code I’d written for the Twitter client and re-use it (copy and paste style) for this task.  I wanted the code to be as simple as possible and I ended up with this:

require 'net/https'
require 'rexml/document'

username = 'your user name goes here'
password = 'your password goes here'
authority_id = 'and here is where you put your authority id';

req_xml = "<s:Authority xmlns:s='http://schemas.microsoft.com/sitka/2008/03/'><s:Id>#{authority_id}</s:Id></s:Authority>";

response = ""

http = Net::HTTP.new('data.beta.mssds.com', 443)
http.use_ssl = true
http.start do |http|
  request = Net::HTTP::Post.new("/v1/")
  request.basic_auth(username, password)
  request['Content-Type'] = 'application/xml'
  request['Content-Length'] = req_xml.to_s.size.to_s
  request.basic_auth(username, password)
  response = http.request(request, req_xml)
end

case response
when Net::HTTPSuccess then
  puts authority_id + ' created'
  error = false
when Net::HTTPForbidden then
  puts "SSDS Access denied"
  error = true
when Net::HTTPBadRequest then
  puts "Request is not valid"
  error = true
when Net::HTTPConflict then
  puts "SSDS Authority already exists"
  error = true
else
  puts "Unexpected Error"
  error = true
end
if(error)
  # process the http response body
  xml = REXML::Document.new(response.body)
  puts "Error: #{xml.root().elements[1].name} => #{xml.root().elements[1].text}"
  puts "Error: #{xml.root().elements[2].name} => #{xml.root().elements[2].text}"
end

The big difference between this and the Twitter code is the use of SSL.  That’s led to a few differences in the use of the Net::HTTP library.  The code in the MSDN example can also handle proxies, which my code can’t, so it’s worth a look at how that’s accomplished.  The code works and I now have a freshly minted authority - I fell foul of the naming rules a couple of times (e.g. authorities can only contain lowercase characters, numbers and hyphens - more info here), but the error reporting is great at pointing out exactly what you’ve done wrong.  And with the code for creating an authority complete, creating a container should be straightforward.

Made Up Technical Terms #12

Interfarce - an unreliable means of transferring information between systems.

Made Up Technical Terms #9

Narkitecture - an irritating architecture.

Availability Bias

I’ve always been amazed at our memory of weather.  My experience is that everyone (in the UK), regardless of age, grew up in a period of cold, snowy winters and long hot summers.  Occasionally, high winds or heavy rain make an appearance.  I figure that this happens because we the unusual stands out in our memories while the commonplace fades into the background.  Why does this matter?  It matters because there’s a phenomenon called availability bias that affects our decision making.  When asked whether murder or suicide are the cause of more deaths most people say murder, when in fact suicide is far more prevalent (according to a 1978 study called Judged Frequency of Lethal Events.)  Apparently, we judge the probability of events by the ease with which they are recalled.

What has this got to do with architecture?  Quite a bit I’d say.  It’s crucial for us to understand how decisions are made, and be able to see the flaws in decision making (especially our own.)  Because availability bias leads us to overestimate the likelihood of that which we recall easily, we are likely to spend more time, money and energy on stuff which, although it may have very nearly derailed our last project, is actually far less important than the stuff we’re ignoring.  The way to counter this bias is with data - anecdotal evidence will only serve to reinforce the bias.

Don’t build or buy

All of us have heard the old chestnut "Build vs Buy".  As a way of starting a conversation about software decisions it’s fairly unhelpful.  Firstly, it’s a false opposition.  If you choose to build, are you going to build everything?  Chances are you’ll build on top of something else.  (And the buy part should really be "license", since not all software needs to be purchased.)

So, what we really should be doing is assembling: using stuff we already have, licensing bits we don’t have but need, extending bits where necessary and assembling it.

The Twitter Debate

You’ve probably noticed that there’s been some considerable debate about the state of Twitter.  There are two themes at the heart of this debate: the architecture and the business model.  These two themes are central to a lot of discussion about Web 2.0.  If you want to read more about the architectural side of the debate here are some links to follow:

Twitter is getting a Mom
Some Thoughts on Twitter’s Availability Problems
Answers from the Horse’s Mouth
What’s Killing Twitter

The two posts that I’ve found most interesting are this one on whether the use of Rails is Twitter’s downfall and this one about the importance of architecture in a Web 2.0 world.  If there is only one thing we learn from Twitter it is that architecture matters.  Ignore it at your peril.

And if you can’t cope without Twitter, there’s always Twiddict.

Effective Architecture

I found this document about how to evaluate and improve architectural competence a thought-provoking read.  It concentrates on what, in my Architectural Theory of Everything, I call Application Architects.  Worth a read to get you thinking about what makes us effective as architects and what we could do better.