Virtual Surreality
It’s too real to be true

For a wonderfully concise and lucid synopsis on what you really need to be aiming for while devising an SOA, watch Jim Webber’s InfoQ interview.

He discusses the Agile-hugging benefits of an emergent service ecosystem, provides best practices around building for scalability, highlights what makes RPC (even if you pronounce it “doc/literate”) bad in terms of technical abstractions like types and operations, espouses the simplicity of message-oriented interactions, summarises the features of SSDL (a simpler alternative to WSDL, WS-CDL and WS-BPEL), and touches on the “degenerative” RPC model that is unfortunately being adopted by implementations claiming to be RESTful.

For links to those mentioned in Jim’s interview:

• Savas Parastatidis, the greek geek grid god (PS: Savas, can you confirm my Greek phrase, two posts down?)
• Various SSDL contributors from academia, most of whom have moved on but easily Googled
• Patric Fornasier, SOYA creator and newly joined to ThoughtWorks (woohoo!)
• Mark Baker, the Bob Marley of RESTifarians

…and you’re already at me.

For the Aussies, Halvard Skogsrud and I are presenting a workshop at the October 2008 Ark conference on SOA (Achieving Interoperability in Systems Architecture), which I’m also chairing. Our workshop is entitled “Bearing the standards of interoperability” and, amongst other things, includes some more depth on Jim’s comments around tight coupling, REST, MEST, and “tunneling XML”. There’s some great presentations on the card from credible people, all of whom have real-world experience in forming SOA’s within the corporates and government they are employed by. You can download the conference brochure here. I look forward to seeing you!

My clever co-worker Shane Harvie just blogged about making Ruby constructors protected in a nice way.

Shane, here’s something slightly more terse which might be the new content of your make_constructor_protect.rb file:

class Class
	def protect_constructor
		class_eval(%Q[
			class << self
				protected :new

				def inherited(klass)
					klass.class_eval do
						def self.new(*args); super; end
					end
				end
			end
		])
	end
end

Seems to pass all the tests. So, your party.rb might look like this now (I’ve left the other stuff commented out, and added access to annual_cost just to be sure).

With a little more effort messing around with the Module.protected, I reckon you could make “protected :new” work as a more natural idiomatic approach - the way you originally hoped it might.
Update: not really as some kernel behaviour appears to be suppressed. See comments.

require 'make_constructor_protected'
require 'test/unit'

class Party
#  include MakeConstructorProtected
  attr_reader :name

  protect_constructor
  def initialize(name)
    @name = name
  end
end

class Employee < Party
  attr_reader :annual_cost

  def initialize(name, id, annual_cost)
    super(name)
    @id, @annual_cost = id, annual_cost
  end
end

class Department < Party
  def initialize(name)
    super
  end
end

class PartyTest < Test::Unit::TestCase
	def test_new_raises_no_method_error
	 assert_raise(NoMethodError) { Party.new("some name") }
	end

	def test_department_initialize
	 d = Department.new("name")
	 assert_equal "name", d.name
	end

	def test_employee_initialize
	 e = Employee.new("name", 5, 12)
	 assert_equal "name", e.name
	 assert_equal 12, e.annual_cost
	end
end

A little while ago, my ThoughtWorks colleague Neal Ford was discussing Polyglot Programming.

He highlights a renewed interest in a diversity of programming languages, particularly those that display constructs that are dynamic, functional, or declarative. Those of us that have been around a while don’t actually think this is a new thing. I’ve learned over 15 languages to proficiency in my 21 years of programming and was looking at the DDJ and Byte CDs for alternative languages well over a decade ago.

Today in Sydney (and later this week in Melbourne), Scott Shaw from our Melbourne office is presenting a ThoughtWorks Quarterly Technology Briefing with the following magnificent title: “Are Dynamic Languages the Next Big Thing? Fight Bloatware to Achieve Faster Time to Market. What IT Decision Makers Need to Know About the New Dynamic Languages”.

At a point in his presentation, Scott asks if corporate IT developers can be polyglot programmers. I asked if it’s all just Greek to them. (Hilarious? It’s gold, Jerry, gold!).

I’m figuring that “it depends”. It depends largely on the level of software craft they employ or enjoy. It depends on the environment they work in and whether a Renaissance view and humanist learning is encouraged. It depends on whether they are seen as, or see themselves as, monkeys pounding keyboards until something good enough is churned out.

Some less esoteric thoughts:

• The difference between C-derivative languages has been minimal until recently.
• Perl is dynamic and has some neat features but appears to have lost the plot on simplicity and expressiveness (Perl 6 is even further off beam).
• Java and C# are mostly object-oriented (although applications written in them generally aren’t)
• Java has incorporated Doug Lea’s fine concurrency package into the API, providing some effective, if somewhat inorganic (due to the nature of Java) concurrency features, and continues that through at least Java 7 with his ongoing work.
• Java and C# are now incorporating dynamic features into the programming model (BSF, DuckTyping).
• More importantly, C# 3.0 incorporates some of the fine language research from Microsoft Labs and includes declarative and functional features (Linq, lamdas).

Some languages you should know about today:

• Ruby. If you’ve used Lisp, Smalltalk, Python or Perl, you’ll probably want to give this one a whirl. If you’re using Excel or Access to glue enterprise data together, learn it - you’re going to have to know it soon. If you’re building a web application that does what most of the other web applications do, learn it and Rails - you’re going to have to know it soon.
• Erlang. If you can hear the avalanche of demands for highly-available, concurrent, non-monolithic processing in business applications coming, start learning. You’ll also understand the purpose of ForkJoinTasks in JSR166y / Java 7.
• Haskell. If you want to understand how high order functions contribute to effective DSLs, or how concurrent life becomes easier when you do away with global mutable state, give it a go. You’ll truly grok the concurrency features in JSR166y / Java 7. Also making some headway in the game software space. Scary syntax, but not as scary as Lisp. It’s a “Maybe Language” (mildly hilarious Haskell in joke).

All of them have growing IDE support (at least Eclipse and IntelliJ, some Visual Studio) and varying levels of development tools (Rake, RSpec, and Migrations will impress).

You could wait until C# and Java catch up with building these features in as core constructs in the language, making them more idiomatic, less cumbersome and error-prone than the bolt-on after-thoughts they largely are now (C# has done a better job). Or you could understand and utilise them from first principles now. Even if you don’t actually program in such languages on a day-to-day basis as part of your accountant-like job (although we believe the change is inevitable), you’ll at least approach the same problems with fresh insight while using your more pervasive language.

As those that speak Greek might say: Τι περιμένεις (What are you waiting for?)