JavaRanch Radio

New forums for Groovy and Scala

Fri, 04 Jul 2008 05:57:05 GMT

Recognizing the interest in alternative languages for the Java VM, we've started a new discussion section for Other Languages. For starters, it contains the following forums:

Other Languages (this is the old "Object Oriented Scripting" forum with a new name)

Groovy

Scala

Obviously we're interested in people using these to discuss their favorite languages (or in asking questions so that they have a chance to make these their favorite languages), so you can help us in spreading the word about them.

We're also open to suggestions for other languages, if people feel that there's no good place to discuss them in a friendly setting. JRuby? Jython? Heck, there are so many that we may not even have heard about them.

We welcome your feedback in this discussion.

Keep a Sense of Wonder!

Thu, 26 Jun 2008 19:03:13 GMT

I'm currently reading the book "The 9 Disciplines of a Facilitator", which I find to be highly insightful. It discusses nine complementary ways of building self-mastery for facilitative leaders.

One of those ways the authors call "Sense of Wonder". It is about appreciating the unknown, about deciding that it's worth for the learning experience alone, and - in my understanding - about expecting to be surprised. That principle rang true for me from the first time I read about it. I still had some trouble really connecting to it, though - until recently...

Unemployed sheriff is moving out of town

Wed, 25 Jun 2008 22:12:16 GMT

June 23 I left JavaRanch, following Jim Yingst and Max Habibi. The place has changed, and I can't justify my presence there any more.

I need to move this blog, so I am looking for what software/hosting is available. If you have any suggestions, please comment here or drop me a line at mapraputa and then usual gmail stuff. :)

Fix "version `GCC_4.2.0' not found" for VMware 1.0.6 SErver and Ubuntu

Wed, 18 Jun 2008 12:19:56 GMT

Not sure if this will be useful, but I'll throw it out there for prosperity...

After updating to VMware Server 1.0.6, I was getting the following why trying to start vmware:

david@david-ubuntu:/usr/local/lib$ vmware
/usr/lib/vmware/bin/vmware: /usr/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_3.4' not found (required by /usr/lib/libcairo.so.2)
/usr/lib/vmware/bin/vmware: /usr/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_4.2.0' not found (required by /usr/lib/libstdc++.so.6)
/usr/lib/vmware/bin/vmware: /usr/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_3.4' not found (required by /usr/lib/libcairo.so.2)
/usr/lib/vmware/bin/vmware: /usr/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_4.2.0' not found (required by /usr/lib/libstdc++.so.6)
/usr/lib/vmware/bin/vmware: /usr/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_3.4' not found (required by /usr/lib/libcairo.so.2)
/usr/lib/vmware/bin/vmware: /usr/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_4.2.0' not found (required by /usr/lib/libstdc++.so.6)

I didn't find an exact match on the net, but similar hits recommended moving the offending library out of the way:

david@david-ubuntu:~$ cd /usr/lib/vmware/lib
david@david-ubuntu:/usr/lib/vmware/lib$ sudo mkdir bak
david@david-ubuntu:/usr/lib/vmware/lib$ sudo mv libgcc_s.so.1/libgcc_s.so.1 bak/

... and now I'm back :)

Ways to split user stories

Fri, 13 Jun 2008 16:38:27 GMT

I'm sitting in the hallway in Limerick, Ireland, attending the XP2008 conference, downloading something from the company server to my laptop, eavesdropping on an open space session hosted by J.B.. He's talking about user stories and roughly 4 minutes ago he mentioned he's got a blog post up on his website that shows an example of four ways to split a story.

Since I'm so Web 2.0, I'm blogging about this while they're having their open space session two meters from where I'm sitting. I tried to be Web 2.0 and blog this while they were running their open space session but I'm so darn slow and old school that it took me 2 days to get this written! Hardly enough to blog about it as it happens. I should've recorded a podcast, I guess.

I digress.

I'll first reproduce Joe's list of four ways to split:

splitting stories along process lines
splitting stories along architectural lines
splitting stories along procedural lines
splitting stories into smaller stories

What Joe is saying in his blog post (among other things) is that teams often progress through this list, starting from the worse way to split down stories and (hopefully) ending up with splitting stories smaller so that they're still "self-contained increments of value."

Great. I've seen this pattern.

Now, having seen this pattern and having found that people find it difficult to split in any other way than what they've done so far unless they can look at examples. And now I thought I should share what I teach about splitting user stories.

Let's start with my list of ways to split user stories (not in any specific order):

by implementation (Joe's first two bullets)
by quality
by data/details
by operations (CRUD)
by major effort
by role

Let me explain what I mean by these, along with an example of each.

Splitting by implementation

First of all, this should be your last option. It's very intuitive for an engineer but you should only do this if you honestly can't think of another way to split it down. Only then you should consider looking at the technical tasks you need to carry out in order to make the original story come to life in the software or split along the lines of architectural boundaries, components, or another technical boundary.

Once you're done splitting it down like this, you call your mother to apologize, check Google Maps for the shortest route to a nearby Catholic church for a confession during the lunch hour, and pick up a new brush from Walmart on your way home. You'll need the brush while sitting in the corner of your shower, scrubbing your back violently, chanting "I feel dirty." That's how bad way this is to split stories.

Now for the example I promised. Let's imagine we're building an online retail system like Amazon.com and we've got a user story like this:

As a potential buyer I want to see available multi-item discounts involving the product Iâm currently looking at.

If this is too big for us, how could we split it further by implementation? We could, for example, split into two stories - the original and a smaller story that's a dependency for the original:

As a product owner I want the discount subsystem to support multi-item campaigns so that I can deliver value to the user in a later iteration.

See? With this split down story we're not delivering any value to the end user because it's a technical split. To emphasize this, I've expressed the story in a form that makes it explicit that we're doing this in order to enable a later value-delivering story.

Now that we're over the evil implementation split, let's look at some more useful ways to split stories.

Splitting by quality

When I think about the goodness of a user interface, I divide the question into two: utility and usability. Utility is about whether the user can achieve the goals he has with the system. Usability is about how easy it is for the user to reach that goal. This dual model can help us split down user stories because the two aspects - utility and usability - can be valuable as such and have different priorities.

Let's look at an example from an online store selling photography equipment:

As a beginning photographer I want to get recommended a camera kit to buy so that I donât need to spend hours reading reviews to figure out which camera would suit me well.

Now how would we split this story along the lines of quality, separating the concerns of usability from pure utility?

Well, the utility aspect - the goal - is for the user to be able to figure out which camera to buy. This would be a lot easier if the system could make a smart recommendation. That recommendation might, however, be too difficult to implement right now, making the story too big. With that said, we can support the user's goal (utility) with less quality (usability) through, for example, a split to these two smaller user stories:

As a beginning photographer I want to see a numeric sales rank so that I can better decide which camera to buy by comparing the sales of my alternatives.

As a beginning photographer I want to see a numeric sales rank grouped by buyer expertise level so that I can better decide which camera to buy by comparing the sales of my alternatives.

These two stories aren't quite as valuable to the user as getting a clear recommendation but they are valuable in that they help the user make that buying decision. They're the cobblestone road solution that's not quite the asphalt highway we'd eventually want but it's already better than no road at all or a bumpy dirt road.

Splitting by data/details

One of the easy ways to split down user stories is by data and details. The classic example is searching:

As a user looking for camera accessories I want to search for products so that I can avoid browsing through the whole product catalog.

Now, let's say that it's too much work for us to implement the search facility in all of the function and polish we'd eventually like to have. We can, however, implement a subset of that fully-featured search by splitting along the kinds of data and details we support. For example:

As a user looking for camera accessories I want to search for products by their name and description so that I can avoid browsing through the whole product catalog.

As a user looking for camera accessories I want to search for products by their price and availability so that I can avoid browsing through items I wouldnât buy anyway.

In other words, we might first implement a search that only looks for matches in the name and description of a product. In the next iteration, we might follow up with extending the search to other data fields such as price and availability.

In some cases the difference between supporting 2 or 4 data fields can be negligible and therefore splitting along these lines might not make much sense. However, it could be that the type of data in question makes that difference significant enough that splitting actually does produce multiple significantly smaller stories than the original. In our example above, we're not really going to match the exact price but rather a price range. Similarly, we might want to search for availability in a specific location rather than a simple "yes, we have it" match.

Splitting by operations

Another intuitive way to split down user stories is along the lines of operations and procedures. An archetypal example of this could be a CRUD (create-read-update-delete) scenario of managing products in a database:

As a shop keeper I want to manage the products being sold in my online store so that I can sell what people want to buy.

If this is too big for us, we might split along the lines of the CRUD operations like this:

As a shop keeper I want to add and remove products from my online store so that I can sell what people want to buy.

As a shop keeper I want to edit product details in my online store so that I can avoid recreating a product to fix a typo etc.

These are both valuable stories. We could just implement the first story and, for now, deal with updating product details by removing and recreating the same product in the system with the new details. We could just implement the latter story and accept that we need to add new products into the system with raw SQL.

Usable? No. Doable? Yes. Acceptable? Depends.

Splitting by major effort

Yet another way to split down too big user stories is by identifying where the effort would go. Let's use the classic credit card example:

As a buyer I want to be able to pay with a VISA, Mastercard, Diners Club, or American Express credit card.

Now, our first thought might be to split along the lines of data and details - the different credit cards we support - but that would give us four user stories (one for each card type) with identical, conditional effort estimates. Why? Because implementing support for any one card takes at least as long as adding support for all the rest. Recognizing that this is how the effort is divided, we might split the above story into these two smaller user stories:

As a buyer I want to be able to pay with a credit card (one of VISA, Mastercard, Diners Club, American Express).

As a buyer I want to be able to pay with four types of credit cards (VISA, Mastercard, Diners Club, American Express).

There is a dependency (the first story must be implemented before the latter) but we might have small enough stories, provided that building the necessary plumbing for credit card processing isn't too dominant in the overall effort.

Splitting by role

Last but not least, we could think about the user story at hand from the perspective of different users and the value to those users.

Let's say we've got this universal story about error handling:

Error handling.

user friendly error messages
detailed stack trace in log file
unique error code displayed to user and in log file

Now, getting an error message that the user can understand probably doesn't make him happy but certainly reduces the degree of frustration if his understanding of the situation improves.

The detailed stack trace and unique error code on the other hand aren't really something the user would specifically appreciate. Their value is for the programmer who wants to be able to locate the source of an error as fast and easily as possible.

In other words, there's two distinct users involved in this ambiguous, two-word "user story" - the user and the programmer. Splitting along this division, we might get the following three smaller user stories:

As a user I want to see an error message I can understand when something goes wrong.

As a programmer I want to see the full stack trace in the log file for any exception thrown during runtime so that I can better debug error situations.

As a programmer I want to show the user a unique error situation identifier so that I can locate the relevant portion of the log file faster and more reliably.

Each of these stories is valuable as such and independent of each other, which is nice. This example also nicely illustrates the value of the explicit "as a role I want something so that benefit" template. If we would've tried to write the original user story using the template, it would've been obvious that we're talking about things that are valuable to two distinct roles - a clear hint at the chance of a split.

Another cue that we're seeing in the original story is the bullet list. Sometimes you can simply look at a story and identify a log-hanging fruitsplit by scanning for keywords such as "and", "or", periods and other kinds of separators.

I'll stop writing now. It took me a lot longer than I thought to get all of this out of my head but I hope it's useful. Perhaps needless to say but I'd appreciate any feedback, suggestions, pointers, etc.

New DZone "RefCard": jQuery Selectors

Mon, 09 Jun 2008 17:10:02 GMT

This week's DZone RefCard is one that Yehuda and I put together describing the jQuery Selectors.

For anyone using jQuery, or even contemplating using it, this "RefCard" is a handy reference to keep at your desk (virtual or otherwise) to look up the syntax of the jQuery selectors and the methods that manage the jQuery wrapped set.

DZone RefCardz Page

jQuery Selectors Refcard

An Expect Oration

Wed, 04 Jun 2008 22:54:00 GMT

I've been asking myself why, without success, I would bother to critcize a book like Exploring Expect, a title printed 15 years ago, amended with only minor corrections a year later, never to be touched again, and still reprinted every so often to what must be the great glee of its publisher, O'Reilly, and its author, Don Libes. That's a successful title, and over a long run. Who am I to sound off against it?

Spot the bug #2: Taming dynamic languages

Tue, 20 May 2008 12:58:07 GMT

It is commonly admitted that dynamic languages are usually more flexible and permissible than static ones. On the other hand, another recognized fact about dynamic languages is that they provide more ways for you to write buggy software if you don't pay enough attention and don't play by the rules.

For instance, I recently came across a nice bug in a web application making heavy use of Spring 2.0.2, JSP 2.0 and JSTL. Here is a piece of code that closely resembles the original code.

...

<%@ taglib prefix='c' uri='http://java.sun.com/jsp/jstl/core' %>
<%@ taglib prefix='spring' uri='http://www.springframework.org/tags' %>

...

<ul>
<c:forEach items="${someValues}" var="value" varStatus="status">
	<li>${status.index}. ${value}</li>
</c:forEach>
</ul>

...

<spring:bind path="address.zip">
	<c:if test="status.error">
		<c:out value="The ZIP code is not properly formatted." />
	</c:if>
</spring:bind>

...

Can you spot it? Ok, it might not be immediately clear what the problem is, but remember that the JSP Expression Language is a dynamic language, and thus, variables are weakly typed. The problem lies around is the status variables and here is why. In the JSTL forEach loop, we are defining a page-scoped variable named status that will keep track of the loop iterations and provide some useful information about each iteration, such as the iteration index, whether it is the first or last iteration, etc. At the bottom, we are using the bind tag of the Spring tag library, which allows to detect whether the value of the property identified by the path attribute (i.e., address.zip) could not be validated properly.

Now the thing is that the bind tag implicitely defines a new page-scoped variable, named... status, too, which provides some information about the validation of the property, such as whether the validation failed for instance (using the status.error property, etc). The error that we were seeing in the browser was along the lines of:

javax.servlet.jsp.JspException: javax.servlet.jsp.jstl.core.LoopTagSupport$1Status

Very explicit as anyone can judge. In the end, the problem was that the first status variable is of type javax.servlet.jsp.jstl.core.LoopTagSupport$1Status, while the second is of type org.springframework.web.servlet.support.BindStatus and those two types share nothing in common. After careful debugging, we could see that the cause of that JSPException was a ClassCastException, which is a typical exception raised when a weakly typed language (i.e., the JSP expression language) is being transformed into a strongly typed language (i.e., Java). So one solution here consists of renaming the first status variable using another identifier, because there is no way to override the name of the second status variable provided by spring:bind, probably one of the few thing you cannot customize in Spring ;)

For the record, the Spring 1.2.2 codebase used to explicitly cast the status variable to the org.springframework.web.servlet.support.BindStatus type, which would cause unavoidable ClassCastExceptions being raised (see SPR-1140 for more info). This has been fixed in Spring 1.2.3 and starting from release 2.0.4, any status variable available in the page or request scope is saved and re-exposed after the tag body has been evaluated (more info)

I hope this post will help other people not fall into the same nasty trap.

Book Review: Adobe AIR for Javascript Developers

Tue, 06 May 2008 07:15:08 GMT

I was trying to learn Adobe AIR and was looking for some good set of learning resources. I found the book "Adobe AIR for Javascript Developers" from Oreilly by and started reading it online. A cool book, the authors have done great job on presenting the topics as an easilit readable pocket guide. Soon after reading this book, i felt i got the right resource i want for now.

A tour de force

Sat, 19 Apr 2008 13:20:09 GMT

This is one of the best technical books I've read in a long time. If you dabble in web development at all, you need to have a look at this book.

jQuery is a Javascript framework that aims to let you think structurally and conceptually, rather than worrying about syntax and other details. In that largely succeeds, and so does this remarkable book.

Every technical book should be like this one; having written a few myself, I know that's a tall order. "jQuery in Action" is concise but clear, humorous but not silly, and answers all the questions it raises, quickly. The reader is never left wondering "But what about..." for more than a sentence or two. The authors clearly gave a lot of thought to pedagogy, because things are explained in a clear way which progresses naturally from chapter to chapter. Factor in the extremely readable style and the handsome diagrams, and it's easy to see why reading this book is a sheer joy.

For each major feature of jQuery, this book provides a "Laboratory page", a kind of interactive HTML playground where you can try the feature out using different options. The remarkable flexibility of these pages is a testament to both the power of jQuery and to the imagination and creativity of the authors.

Perhaps the most commendable feature of "jQuery in Action" is, however, its unflinching honesty. All too often authors are interested in selling you on an approach or a product, and they tend to gloss over the rough spots to win you over. These authors refuse to do that. They present their topic just as it is, describe its merits, and let the reader decide. You should, of course, decide to buy this book!