Virtual Surreality

Announcing PreparedEval, prepared statements for generating JavaScript (and the like) from Java. It prepares Java strings for JavaScript evaluation, similar to SQL prepared statements. Saves you from quote escape nightmares! Great for Selenium tests and Rhino JavaScript.

As a follow-up to my post on escaped, quoted strings, Taking the idea of using a different encoding scheme further (and not being super happy about the need to pump the string through unescape()) I thought about interpolation and wondered about prepared statements in SQL. Some quick research turned nothing up, but while chatting with Ola Bini he also mentioned prepared statements, so this convinced me to knock something together that might be useful.

More information is at http://wiki.github.com/delitescere/PreparedEval.

There’s no runtime dependencies so it’s nice and tiny if you just want the JAR.

Let me know if you use if to help with CSS / XPath selectors for Selenium or if you have any suggestions on improving the API.

When you have more backslashes than words in the strings you are constructing, perhaps it’s time to look at another way of handling special characters like quotes.

The problem

You’re generating JavaScript code from another language with C-like quoting and escaping syntax (e.g. Java).

As part of that code generation, you’re substituting strings that have both double quotes (“) and single quotes (‘). My team’s actual problem stems from using XPath locators which include quoted text and sending that to Selenium so we can obtain the particular element that contains the text^*.

Let’s say we want to pop up an alert within which are some double quotes:

String original = "Hello \"stranger\", how are you?";
String quoted = original.replaceAll("\"", "\\\"");
String script = "alert(\"" + quoted + "\")";
eval(script);

We then expect the browser to have this JavaScript code to process:

alert("Hello \"stranger\", how are you?")

and when then expect the alert to display the string:

Hello “stranger”, how are you?

But why doesn’t it work?
Read more…

Should it be assertEquals(expected, actual) or assertEquals(actual, expected)?

This discussion came about because at the Chicago Code Camp, Jim Suchy from 8th light was demonstrating TDD in JavaScript by building a simple unit testing library. One of the methods he created was the typical assertEquals. In the code on github he had a signature of assertEquals(expected, actual) while during the demo he swapped the order, and I pointed out that the original was what I would have anticipated. He commented that there was an interesting discussion about it at his office a few days before. I’m interested to hear more about it, and I tweeted that I was inclined to get a debate going about it just to see what the different rationales were. This post is a collation of thoughts and opinions to date.
Read more…

I’ve been given the privilege of speaking at CodeMash 2009 in Sandusky, Ohio this coming January.

The presentation and discussion will cover the learning from implementations of Guerilla SOA and will include code and demonstration based on the WCF. It may change some minds about the default approach to the WCF programming model and open some eyes on how to build a truly message-oriented service oriented ecosystem.

Looking forward to a conference that comes highly recommended.

The submitted abstract

Title: Guerilla SOA for WCF
Track: Arch & Design
Level: Intermediate

Description:
This talk goes over the fundamentals of Guerilla SOA (a concept conceived in ThoughtWorks and championed by Dr Jim Webber) and how they are applied to WCF in both a SOAP and REST context.

Using principles from agile software development into an emergent architecture, particularly for services, the talk looks at an alternative approach to the usual usage of the WCF programming model which provides a true message-oriented approach (rather than the RPC hole almost every WS-* stack drives us into).

Drawing on real large-scale projects, we’ll touch on consumer-driven contracts, sensible XSD, alternate validation techniques, LINQ to XML, XPath, and a convention-based and MVC approach to web service implementation.

My colleague Jay Fields recently blogged about the value of test names.

We had a little discussion about it yesterday on IM. Here’s a summary.

Josh Graham

I feel the test name is important for two reasons:
1) it is intentional programming – a neural pathway is established in your brain as you write the name of the test method so your mind tries to think about what the hell you are trying to achieve by doing all that typing
2) for those test consumers you speak of to get a sense of the behaviour of the system as specified by the stories and high level acceptance criteria

Jay Fields

2) [is] fair enough. Before introducing expectations on any client project I’ve brought it up as “what do you think about” and let the team decide. The last thing I want is an idea to be branded as bad because the wrong ppl used it
1) I think is based on the person. I always found it 10 times harder to write a sentence, I just want to get to the code but, I’m crazy for making the code intention revealing

Josh Graham

Picking a reasonable moniker for the test name is useful too, when something breaks (particularly if it occurs often)… “That #$%#$%! shouldRejectLostOrStolenCard test is failing again – must be the clearing house API has changed or they’ve crashed once more”.

Jay Fields

yeah, that’s an interesting point
wish you would have replied with that one, I’d have put it in my entry

We then talked about how to attach a moniker to the test on different languages – method names in Java being the easiest, while anonymous inner classes being a way to do so without having a moniker (other than perhaps a comment) at all.

I still contended that a method was a reasonable level of granularity to contain a test and use the method name as the moniker. A method (it’s declaration and its body) is location independent – it can be moved around in its module and you can still find it and its moniker appears in the abstract syntax tree so it’s very easy to find when using an editor that maintains an AST.

Jay’s responses to my scenarios in which this proves useful assume a short TDD cycle and also good developers.

So, while the test name may be superfluous in some cases, I don’t mind the extra mental effort of summarising the intent of the test into its name – and if that is overly difficult or not needed (both of which are plausible) then a banal label like enclosing the test in a method called “test1″ is a small price for me to package it up in a manageable, easy-to-find chunk.

YMMV.

My CTO, Rebecca Parsons, announced the publication of the ThoughtWorks Anthology a few days ago:

I am thrilled to announce that the ThoughtWorks Anthology is now ON SALE!

http://www.pragprog.com/titles/twa

There are essays by Roy and Michael Robinson, Martin, Neal Ford, Tiffany Lentz, Stelios Pantazopoulos, Ian Robinson, Erik Doernenburg, Kristan Vingrys and James Bull, as well as ex-TWers Dave Farley, Jeff Bay and Julian Simpson. (And of course your’s truly made her own contribution). Mike Aguilar wrote the introduction.

Some comments that appear in the book:

Jim Fischer writes, “The anthology provides a peek into the diversity of views and perspectives held by a company that dares to take on the long-accepted tenet of the IT industry that custom software is too hard and too costly.”

Big Dave Thomas writes, “Software is in many ways a team sport, and the leaders shape the software culture. Often successful organizations don’t take the time to document them, and hence others don’t benefit from them. This interesting collection of personal essays gives a glimpse into the culture of ThoughtWorks through some of its leaders.”

I’m really excited that this project has come to fruition and I hope you all enjoy what you see.

Rebecca

I was lucky enough to review the content earlier this year. It’s a keeper.

UPDATE: Some press… http://www.sys-con.com/read/541124.htm

After a meeting of the office of the CTO, most of us stayed around in our San Francisco office for a few days to do some podcasts and to participate in a Code Jam for Inveneo, a not-for-profit who provide computers and connectivity to developing countries (especially their schools, hospitals, and poorer villages).

They install a server in, say, a hospital with a few lower-powered, custom desktops (almost iMac in configuration). These, as well as the servers, can run off solar panels for power.

We were presented with a worthwhile problem with a number of interesting constraints:

• Low-power server running Ubuntu, with two small SATA hard disks in a Linux software RAID-1 array
• VMWare images of the servers for testing
• Python, bash, mdadm, and beep as our “programming languages”

When a RAID array fails, we need to alert any (if any) humans who are near the server. This can be interesting as the only things nearby might be the tree it is mounted in with a long-range WiFi, or the goat who uses it as a heat source at night. This means that any alert should be sufficiently frequent and annoying for the locals to contact someone who can let the support technician know. The conflict is that it also might be the nurses in their office at the hospital who have work to do and don’t want to be disturbed.

The solution was to use the PC speaker to beep. We can control the pitch and duration of the beep. Some combinations sounded too much like an ECG machine so that was no good. In the end, we chose a simple rising scale that would sound odd in any environment (except, perhaps, in a Mike Oldfield recording). This is repeated by default every 30 minutes.

We also had to send an email to the support technician. This doesn’t work when the server doesn’t actually have any connectivity (as some are used only as a local communications hub), or when connectivity is unreliable. Even then, many of the technicians are hours or even days away from the servers.

As many of the technicians aren’t particularly technical, we also had help by identifying which of the two disks had failed and allow them to simply change the one labelled “Disk 1″ or “Disk 2″. Serial numbers are good for this but VM hard disks don’t have serial numbers (I think that’s a feature request to both VMWare and Parallels).

We had Jeff Wishnie from Inveneo as the customer, Anda Abramovici as IM, Jonny Leroy as BA, Paul Hammant and Chad Wathington as QA, and the star developer crew of Drew Olson, Sammy Zahabi, Ola Bini, Erik Doernenburg and your’s truly. We quickly learned the following:

• The skills we needed (and had, just a little rusty) were more along the lines of Unix devices, shell, ASCII control characters, and simulation
• Python sucks (a bad tradesman blames his tools? perhaps – but it still sucks)

Anyway, we got most of what we wanted done in the time, and given the context, more than we anticipated. But we all would have liked to get a lot more done and would have if we were using our tools of choice (which are chosen for very good reasons).

Nonetheless, we’re doing it for the kids and it was great!

What a buzz. Super Agile. Super Fun. Go Inveneo, you rock!!

Charles Nutter has just written up a nice summary of the things in Thomas Enebo’s announcement of RC2 of JRuby 1.1

He talks in general about the astoundingly improved performance characteristics, particularly when compared to the Ruby 1.8.6 and 1.9 native interpreters, as well as the better use of JVM resources. Let alone the 260 bug fixes since RC1.

There’ll be more from me soon about our commercial experiences with JRuby and hopefully give you some fuel for introducing Ruby into your large, conservative corporate environment. I have to say, going back 2 years and thinking about the “enterprise readiness” of Ruby, things have changed a lot – almost exclusively due to the work done on JRuby. The pace at which the JRuby team work to address issues and improve the platform is outstanding, and puts commercial software vendors (particularly those hawking development tools) to shame. Things also have a long way to go – there are many, many solutions that would still be recommended around a recent version C# / .NET or Java implementation and that doesn’t look like changing for some time. The team behind JRuby is multi-skilled and very aware of innovations in other languages and platforms and I think this is one of their key success factors.

If you are evenly remotely interested in working on an OSS project, I encourage you to contribute to JRuby, even if it’s just to identify a problem to be fixed – it’s fun, it’s a great community, you’ll learn a lot about Ruby and the JVM, and you’ll work with some of the best guys in the business.

I suppose we Aussies might give up too easily, Ola

Antonio Cangiano let everyone else who isn’t on the list know the disappointing news from earlier this afternoon.

Language ninja, Ola Bini made a remark that Ruby was strongly-typed. Without confusing “strong” with “static”, this still made me pause.

I knew it was type-safe. I knew it was dynamically-typed. I knew it used Duck typing. I didn’t think about it in terms of strong types. I suppose arithmetic exceptions and array-bounds checking make a language strongly typed (and we all like that) but I would have put this more into the “type-safe” category.

What I didn’t think about so much is that Ruby does also raise type conversion exceptions and it raises exceptions if the object (ultimately) doesn’t accept the message it is sent (two other important aspects to what most people mean by “strongly typed”). It’s obvious – and if you’ve ever tried to add a number to a string, or vice versa, in Ruby then you have met the strong typing of Ruby.

Eli Bendersky has a good taxonomy of typing systems which I encourage you to read (as well as the comments).

I now figure that Ruby is strongly-typed just as long as you don’t do anything to weaken it. At least from the Ruby user’s (the application programmer) point of view. As Ola pointed out on #jruby, “but manipulating it can’t crash the underlying implementation (in a perfect world, of course)”. This means that while the following adds apparent weak typing, it doesn’t actually corrupt the Ruby runtime to remove the strong typing protections it has built in.

Adam Glasgall also on #jruby pointed out that he thinks of strong typing as “every value has a type, and that type doesn’t change”. There wasn’t consensus about the latter phrase (it is also a little ambiguous), and even so it doesn’t seem to truly apply to Ruby.

Operations on incompatible types

x = 5
y = "42"
x + y  # => TypeError: String can't be coerced into Fixnum
y + x  # => TypeError: can't convert Fixnum into String

Open classes and operator overloading weaken this, though.

class String
  alias old_add +

  def + (other)
    begin
      self.old_add other
    rescue TypeError
      self.old_add other.to_s
    end
  end
end

y + x  # => "425"

With some appropriate patching of the usual types, you could have the implicit Perl-like coercion in Ruby. Do you reallly want it? Perhaps not.

The important thing is that unless you do something explicit to weaken it, the Ruby runtime will strongly enforce the checking of operations on incompatible types.

Unknown messages

x.foobar  # => NoMethodError: undefined method `foobar' for 5:Fixnum

Again, open classes help weaken this, as does the method_missing method.

class Fixnum
  def method_missing (methId)
  end
end

x.foobar  # => nil

So, as long as you have a special method_missing method defined, you can weaken the rejection of unknown messages too. You could have an empty method_missing on Object and weaken this feature too.

The important thing is that unless you do something explicit to weaken it, the Ruby runtime will strongly enforce the checking of acceptable messages for a type.