Portal containers: Supporting the vision of technology-agnostic applications?

April 15th, 2009 • Internet, Java, Ruby, portal
Tags: linkedin

I’ve been looking at Liferay recently. It turns out to be a fantastic portal container. It’s core is not necessarily better than it’s closest rival JBoss Portal, but it comes with a mammoth selection of portlets out of the box. Also, with the support for the portlet standard being adopted across multiple technologies, you’re not locked into Java for new functionality – in fact, i’m currently building a portlet in Ruby. On top of that, the core system is covered (exactly how covered is unclear at the moment, but we’ll gain that awareness soon), in Selenium RC integration test scripts. Perfect! All that’s missing is an adoption of BDD stories, but that can be added.

One warning – accessibility not out of the box

Liferay’s out of the box portlets are not accessible! It’s a known issue and Liferay want the community to support them in fixing this. Seems like a reasonable request and it’s lack of focus on accessibility stems most likely out it’s origins in USA. They care less than the brits about this stuff!

Tutorials

I’ll post tutorials as i progress through my Ruby portlet development and integration.

Now we’re rocking! DSL story driven development and testing in Java!

December 9th, 2008 • 1 comment Business, Internet, Java, Productivity, Ruby, agile, software development
Tags: linkedin

At TechnoPhobia, we have an interesting challenge to implement a technology agnostic requirements capture process that (in my mind) will enable us, with very minimal effort, to repurpose these documented requirements into fully automated browser tests. I’m thinking that the process could look something like this:

1. The project and client team write end-user functional requirements as User Stories and Scenarios
2. The stories are stored as plain text in SVN or GIT and made immediately available to the development and test teams
3. The development and test teams create a few executable padder files, wrapped around these stories, turning them into fully automatable browser tests
4. The executable files are run, they read the stories and interact with the browser to determine if the stories successfully pass

Pretty cool, huh! No more massive team specific documents, just good old plain textual stories that are shared by all on the project, including the client.

Making this happen across multiple technologies

• In Ruby, we’ve already used this parts of this approach on a live project using Cucumber (formally RSpec story runner). It worked pretty well. 
• In Java, easyb seems to be the a good forward. Here’s a little more about using easyb

I am WAY TOO EXCITED to see an implementation in Java! This opens massive opportunity to progress with a technology agnostic approach. Now to find a suitable solution for .Net and perhaps PHP