The Rationalist Manifesto

I love abusing method_missing in Ruby, it is great fun.

 module IsDoesIsntDoesnt

  def method_missing(method, *args)
    m = method.to_s
    if (m =~ /^is_(\w*?\?)$/) || (m =~ /^does_(\w*?\?)$/)
      real_method = $1.to_sym
      return send(real_method, *args) if respond_to?(real_method)
    elsif (m =~ /^isnt_(\w*?\?)$/) || (m =~ /^doesnt_(\w*?\?)$/)
      real_method = $1.to_sym
      return !send(real_method, *args) if respond_to?(real_method)
    elsif (m =~ /^(\w*?)s\?$/)
      real_method = "#{$1}?".to_sym
      return send(real_method, *args) if respond_to?(real_method)
    end
    super.method_missing(method, *args)
  end

end

Object.class_eval() do
  include IsDoesIsntDoesnt
end

Which lends itself to these types of natural statements:

?> "team".includes?("i")
=> false

>> "team".isnt_empty?
=> true

and:

>> [].is_empty?
=> true

>> [ :stuff ].does_include?(:stuff)
=> true

While I’m sure Ruby mavens will think of much nicer ways to implement this type of functionality, I had fun doing it.

An exercise for the reader would be to dynamically add the appropriate method, so the next call doesn’t rely on method_missing.

Bookmark to:

Selenium is an open-source test tool for web-based applications and sites. Unlike Canoo WebTest, Selenium actually utilizes the browser itself to perform the tests.

Selenium has a Firefox extension that acts as an IDE for recording and editing test cases however there is a significant difference between running the tests in the IDE and running them as part of a build process — cross-site scripting.

When running tests in the IDE, Selenium is not limited by Firefox cross-site scripting preventative measures and can follow links to external sites (outside your ‘base URL’) and verify that the target has been reached. This is not possible when running it as part of a build process in stand-alone mode.

The reason for this difference is that when running Selenium in stand-alone mode it generates a web-page that contains the test runtime with the actual web-page it is testing residing within an IFRAME. Once you traverse to links outside the domain the Selenium generated web-page is at (usually localhost) then you are subject to cross-site scripting limitations. Put it simply, your top page (Selenium generated) would be in the ‘localhost’ domain, and the external page is at another domain thus triggering the cross-site scripting security restrictions.

I’ll demonstrate what I mean:

In Selenium, a typical link test is done so:

1. A ‘click’ Selenium command with the ‘link=’ target.
2. Then a ‘waitForPageToLoad’ command
3. Followed by an ‘assertLocation’ with the correct expected URL

This test will fail when running in the standalone mode with the link target being external to the domain running the Selenium web-page. Instead of what you expect from the IDE based run you will hit upon permission errors accessing “document.href” and other DOM properties. This is simply because your script is from domain “localhost” (for example) and does not have access to the DOM of the page from the external domain (say “rationalistic.com”)… Note that for the same reason you can’t even call ‘goBack’ after the ‘click’.

An alternative to this method that is useful for external links is simply to verify the existence and ‘href’ attribute of the link. While this is not ideal (as it doesn’t take into account Javascript method links) it is, in my opinion enough verification for off-site links. To use this method of testing a link’s existence and target you must give the <a> element an id, preferably one that starts with “link_” and then using the Selenium ‘assertElementPresent’ and ‘assertAttribute’ commands.

For example, consider a link to my blog site:

<a id=”link_rationalistic” href=”http://www.rationalistic.com”>The Rationalist Manifesto</a>

To test it in Selenium you would do this:

1. Use the ‘assertElementPresent’ command with a target of ‘link_rationalistic’
2. Follow with an ‘assertAttribute’ command with a target of ‘link_rationalistic@href’ and a value of ‘http://www.rationalistic.com’.

This testing method provides reasonable confidence that the link exists and leads to the correct location without following it.

Note:
This method is also useful for links which have symbol characters in them which may be difficult to locate using the ‘link=’ targets.

Bookmark to:

Excellent article about technological superstition by Jeff Raskin.

Bookmark to:

The publishing of Scott Rosenberg’s “Dreaming in Code” and the PR circle around it, has prompted Jonathan Rentzsch writing a post which criticizes one of Rosenberg’s main tenants — that ‘Programmers like to code’ — and suggests instead that ‘Programmers like problem solving’. Rentzsch goes on to claim that programmers’ urge to rewrite problematic legacy code bases is the desire to understand rather than a desire to code.

I agree with Rentzsch completely on this point, however I do believe that Rosenberg, having come from the wrong direction, has hit a point with “Rosenberg’s Law”:
“if you are doing something that has already been done — then you have a frame of reference to estimate how long it is going to take, and to guess how many people are going to be required”

I’d like to rephrase this in Rentzsch’s “problem solving” terms, and paraphrase “Rosenberg’s Law” as:

“A relationship between the unfamiliarity of a problem to the difficulty of estimating the required resources to solve it.”

Which is not surprising in hindsight, as it is a relationship between one type of uncertainty to another…

Bookmark to:

Joel Spolsky has another lovely article out titled, “The Command and Control Management Method“. While he hits the nail on the head for most of the article, I feel he misses one of the main reasons while C&C management does not work for software development teams.

Actually, he misses one of the main reasons the C&C pattern doesn’t even work for the military.

It all begins with the 1973 (no, seriously) Yom Kipur War between Israel, Egypt and Syria. Having taken Israel by surprise, the Syrian tank divisions storm through the Golan Heights and almost reach Nafah where the headquarters for the Israeli forces were located.

Had the Syrian forces reached Nafah, they would have most likely defeated Israel and conquered the Golan Heights at the very least. But they haven’t, and didn’t — instead, they stopped.

Just before overtaking Nafah (’on Nafah’s fences’ as Wikipedia describes it), the Syrians halted their advance. This allowed time for Israeli reserve forces to arrive en-mass and overturn the tides of war, eventually costing the Syrians their victory. To this day, no one outside Syria (and maybe Israeli Intelligence) knows for certain why the Syrian force stopped so abruptly.

There is a prevailing theory, however. This theory boils down to the difference in management style between Arab armies (Soviet trained) and the IDF. Arab armies are trained for complete Command and Control management, an underling will not make a move without being issued a command. The most initiative he can show is to suggest a course of action to his superior, who might suggest it to his and so forth until the highest authority on the matter is reached, once he makes a decision the order to action travels down the chain of command. As any software engineer will tell you, this upstream-downstream transaction means very high latency.

Israeli military on the other hand, have an altogether different standing order: a soldier without immediate contact to his supervisor is his own chief-of-staff. This translates to initiative and rapid response during the fog of war.

So imagine that the Syrian tank brigade commander, having surpassed his superiors’ expectations and advanced so quickly into Israeli held territory that he exhausted his current orders. He was not meant to reach Nafah so quickly! As he is trained not to question his orders, and as he is only given very limited information (on a supposed ‘need to know basis’) he can’t assume that proceeding forward would fit with the larger plan.

Thus our well trained commander jubilantly radios back his headquarters and informs them of his brilliant success and requests further instructions. While his report travels up the command vine, he and his forces are minutes away from victory and are standing completely still.

The next step of the reasoning is quite clear:

Use a command and control management style and you will be the bottleneck of every development step, as every decision beyond what to call the class file will be relegated to you. This is not just hit-and-run micromanagement, this is a semaphore locked development cycle and is hardly an efficient use of your very valuable resources (otherwise known as: people).

While there are many (many!) number of arguments why C&C does NOT work for software development projects (for example: writing good software is a creative process, C&C management hampers creativity) I think the above is the most important and most direct argument against such a style of management.

Having said that, there are places where C&C is just fine.

Technorati tags: software-development, management

Bookmark to:

Ruby on Rails is rightfully gaining traction and respect right along with a rapidly growing developer community. This, due to its being the near-perfect match for developing its `home-turf’ software: database backed web site. However, as pleased as I am with RoR’s success, I’m beginning to note with apprehension as it is increasingly being used for writing the kind of software it is not meant for.

It is not unlike the early Java-rush years in which every tiny in-house web-application seemed to some misguided souls like a nail aching for the punch of the overweight EJB hammer.

Rails development scales very well, so if you are developing a web-site, you’re in for a pleasant surprise using it. Whether you develop alone or with many team members, whether you deploy for ten concurrent users or ten-thousand, Rails is definitely the right tool for the job. But if you are developing something more state heavy, such as a web-application, then you are in for a nasty headache when your code goes O(spaghetti^2).

Rails is a great tool for what it does, but when you’re writing software that translates to a different architecture than a thin-state web-site (as rich an experience as it may be!) using Rails will be like trying to fit a square peg into a round hole (when the cliche fits…)

Web site/app, what’s the difference?
The difference between the two boils down to the number and complexity of the states of the software… …Huh?

Let us demonstrate: A good example for a web-site is IMDb, it aggregates information about movies from various sources including other users. Another example for a web-site is OkCupid.com which allow online matchmaking and interactions between users. Contrast this with a web-application such as Google Spreadsheets which is pretty much a hosted version of Excel + collaboration. Another example for a web-application (although one that is smaller in scale) is an application which allows you to control your home automation remotely via a web browser.

What is a web site?
A classic web-site is a thin view layer unto an expansive schema which is modeled and stored in a database. The use-cases it implements are shallow on their own right but their aggregate creates an experience which is much larger than the sum of its flows.

The main draw of a web-site are the users– you are not interacting with the software alone, you are part of a grander ‘community’ (as much as this word brings a bitter taste to my mouth at times)– While using a web-site you become part of the network and as a user you give value back to the site by interacting. This is the ‘Web 2.0′ vision, a painful buzzword on its own.

Web 2.0-type sites are absolutely ideal candidates for Ruby on Rails and as such there are many success stories to be observed. I’ll skip the bother of listing them, go to RubyOnRails.org and scroll down, I’m sure you’ll recognize some of the leading neuvo-web sites.

Now, seeing these successes described in IT Weakly (ha-ha) your average Joe IT Manager figures, ‘Hey! This Rails thing does web sites good! We have an in-house application to plan our customers’ parties which we need to upgrade, so let us rewrite it as a web-application using Rails!’

Gulp! Ding! Big Whoop! No good!

Why?

Because web applications and web sites are not the same thing… Joe IT is going to use Rails for something it is not meant for and actually quite weak for.

Web-Applications, a primer
To understand what web-applications in a deeper sense, consider the expression itself– it is naught but the well worn word ‘application’ with ‘web’ tacked in front. So a web application is simply an application that runs on the web as its platform of choice.

A desktop application’s experience is one of the user vs. The Software. Perhaps a limited remote resource is utilized, such as a query to the Party Supplies Database for the benefit of the purchase order printing screen but other then that– it is the user alone who calls the shots.

You can create deep, stateful use-cases that involve selecting a venue for the party and setting up the table locations and seating arrangements. It doesn’t matter if the experience of using this piece of software is immersive or merely tangential but the main point is that does not involve anyone else but the user himself along with the rich client experience (ah… Buzzwords). There’s a heavy statefulness to applications that doesn’t exist in web-sites.

The Thin Line
AJAX, another aspect of the Web 2.0 paradigm, is bridging the gap between the richness of a desktop application and that of one set on the web. It is also bringing more modal interaction to web-sites. But as thin as the line is, it is still there. And where it is most noticeable is the amount of statefulness of the software.

In a web site the state is maintained in these locations: The URL, the session and the database. You can consider them the short-term, mid-term and long-term memory of the software. For brevity, I’ll refer to any information which is kept client-side and travels back from the user as the URL, although it may be sent to the server in other parts of the HTTP request (such as forms).

To scale a web-site well, as little state as possible should be maintained in the session (for clustering purposes) and yet the cost of a DB call is also prohibitive so it is best for UI state to be contained in the URL as much as can possibly be managed, while taking care to never trust the user-sent data and to avoid assuming that he will ever traverse the flow chain as expected.

This leaves very, very little place for statefulness in web sites and it is the main reasons why web sites have shorter, shallower flows than do applications.

Don’t get me wrong– web-sites may have a rich UI. We are all immersed in the latest trend of enriching web-sites’ UI by creating a more responsive UI using AJAX.

The list that updates without a page refresh, a popup dialog for selecting your state or the modal window which display the clicked-upon photograph, these are just a few of the examples we see daily– but all this adds nothing to the statefulness of the site — it doesn’t turn it into an application and it shouldn’t!

Rails is ideal for developing web-sites because it deals very well with interpreting the current state from both sources (URL –> ActionPack, database -> ActiveRecord) and churning out a view for it. The second you add more statefulness, it gets painful.

Words of Wisdom
I speak from experience— I learned this painful truth about Rails the hard way by trying (and actually succeeding, through painfully so) to create a rich-flow application with Rails. This application should have been a desktop application by all rights, but seeing as I had recently acquired a hammer, I just had to use it to beat the screw in…

This application’s model was simple enough, but the user flow involved the use of resources on the PC itself (the DVD drive, in this case) making it utterly befitting a desktop application, and less so for a web-app… Blinded as I was by the ease of writing web-sites with Rails, I ignored my own red-lights flashing and went ahead anyway. It turned out well enough, but taught me hard lessons about what Rails makes easy and what it makes hard.

Statefulness…Blissfulness?
There are frameworks out there which fit a state-rich AJAX web-application much more than Rails. There are many examples and I would not want to mention one for fear of the flames, but feel free to suggest yours in the comments below.

Technorati tags: Ruby on Rails, Development, Software, Web 2.0

Bookmark to: