The Disco Blog Welcome Guest | Login or Register

I have the distinct privilege of speaking at this year’s JAOO conference in Denmark on September 29th. I’ll be spreading the good news of Gant, which is something I’ve been having fun doing over the last year or so.

Briefly, Gant is a highly versatile build framework that leverages both Groovy and Ant to let you implement programmatic logic while using all of Ant’s capabilities. In this talk, you’ll see Gant in action and see first hand how brining Ant into a fully functional language yields an expressiveness unmatched by XML. By the end, you’ll be eager to download Gant and put your Groovy skills into action for constructing a highly flexible and extensible build system that moves concepts to cash in short order. I hope to see you there in Denmark!

I had the privilege of being interviewed by my friend Richard Sharpe of Enerjy at CodeMash back in January of 2008 regarding Java concurrency and specifically how the Java language might evolve to address concurrency. My take was (and is still) that Java is maturing and attempting to address concurrency concerns — case in point, my friend Brian Goetz does a hip job of outlining a proposed Java 7 enhancement in his series “Java theory and practice: Stick a fork in it, Part 1“. Plus, in JavaWorld’s article entitled “The future is now — Java development in 2008“, which attempted to lay the ground work for what we as an industry would most likely see evolve on the Java platform in 2008, even mentions concurrency.

Yet, with the simple truth that indeed, concurrency programming is extremely difficult (to do correctly) and more and more machines are implementing multi-core architectures, I get a dreaded feeling that nobody really cares. Granted, Brian’s book “Java Concurrency in Practice” appears to be selling well (it’s a great book, baby) but I don’t hear a lot of people talking about concurrency or how they’re planning on dealing with it. I suppose, in truth, applications don’t necessarily have to deal with new architectures and in large part, many people appear to be quite happy staying put in Java (as opposed to integrating other alternate languages, which support concurrency much more naturally).

Am I just failing to see something or is concurrency something the Java community will deal with in 2010?

I recently ran across an interesting company called uTest, which aims to leverage a social network of distributed software testers for testing client applications. The basic premise being that if you’re building a software application, why not outsource the testing of it? Outsourced testing is by no means new; however, what appears unique with uTest is that they will test your web application (this is key– you control the environment; that is, you provide them a URL, which dramatically lowers the “set up” costs associated with outsourcing testing) and then you choose the team (this is based upon various aspects such as the person’s location, experience, and even platform). uTest provides bug tracking and apparently you only pay for bugs you approve.

What’s more, via their trippin’ dashboard, which reports various aspects related to testing (number of bugs, number of testers, etc), they also report application “maturity”– that’s fairly intuitive and speaks to the business user in a friendly manner. Without such a metric, you are often left deciphering other related metrics and inferring application readiness.

With uTest, you can also rate testers– this is super hip– essentially, testers in their network are paid by defect. You have to approve defects and what’s more, when you approve one, you can rate a tester– presumably, testers with low ratings fall out of favor within the network and those with higher ratings become more valuable.

Outsourced testing, for many companies, is often a no-brainer– I’ve facilitated these transactions before; however, what’s particularly interesting about uTest is the social aspect of it. Rather than a client relying on the outsourcer to build a test team, the client, in this case, builds the team themselves. What’s more, building the test team is facilitated via the community and the ranking of testers within it. Also, an often big barrier with testing is environmental set up– often times the outsource company will want to set up things in house. This process takes a lot of effort and is often times quite costly. Putting that responsibility on the client definitely lowers a barrier.

uTest’s crowd sourced functional testing just might work– keep an eye on them. Of course, if you find yourself in need of a hip QA team, these guys might prove to be quite cost effective too. Dig it, man?

On Wednesday, September 10th, I will have the privilege of speaking about easyb at the Northern Virginia Java Users Group. This is my hometown JUG and it’s always a blast to converse with old friends and familiar faces. Plus, I can’t think of anything more fun (well, other than perhaps listening to disco music) than chewing the fat about easyb!

As I see it, this presentation will address the notion of executable documentation — agile developmental practices push for reducing repetitive documentation and for a rapid acceptance of change; yet, achieving these goals is by no means easy. While a process can enable increased collaboration, for instance, there are only a few tools that can effectively implement collaboration. Once such tool is easyb, which facilitates collaboration by bridging those that define requirements (i.e. customers) and those who turn requirements into code (i.e. development). With easyb, collaborative teams can develop stories in a specific format which are then implemented as verification assets through a framework which marries the underlying application. This verification suite enables change and produces accordance among teams in short order.

In this presentation, we’ll see how to embrace collaboration and change rapidly by defining hip easyb stories that exercise a Java application end to end. I’ll demonstrate how to define specific easyb structures, how to plug them into real code, and how to run them in an automated fashion. Hopefully, you’ll see first hand how non-coders can define tests easily and how the collaboration this brings yields working software faster.

I hope to see you there, man!

Back in the Age of Aquarius, hip cats could somewhat quickly knock out an account creation web page (for basically any web application) that contained a few form fields, such as account name and password to name few. Those days are gone, however, with the proliferation of various nefarious bots that annoy basically everyone except their inventors.

While automated annoying machines are not completely stoppable (much like disco music, baby!), the CAPTCHA has been helpful in at least slowing them down. As such, various CAPTCHA implementations have sprung up– JCaptcha is one such open source implementation built for Java applications; what’s more, there is a JCaptcha plug-in for Groovy’s Grails web framework.

Using the plug-in is easy too — all it takes is four hip steps.

First, you need to download and install the plug-in, which can be done by issuing the command:

%>grails install-plugin jcaptcha

After that’s complete, you’ll need to define one or more captchas in your Grails Config.groovy file– this step was a bit confusing to me at first, so let me explain. JCaptcha offers two logical types of captchas– images and sound files. Image captchas also come in different flavors. For me, I only needed one type of captcha– that being an image one, so I was able to define it like so:

jcaptchas {
 image = new GenericManageableCaptchaService(
   new GenericCaptchaEngine(
    new GimpyFactory(
     new RandomWordGenerator("abcdefghijklmnopqrstuvwxyz1234567890"),
     new ComposedWordToImage(new RandomFontGenerator(
       20, 30, [new Font("Arial", 0, 10)] as Font[]),
     new GradientBackgroundGenerator(140, 35,
       new SingleColorGenerator(Color.white),
       new SingleColorGenerator(new Color(152, 245, 255))),
     new NonLinearTextPaster(6, 6, new Color(108, 123, 139))
     )
    )
  ),
 180,
 180000)
}

There’s a lot going on there, man, but it makes sense once you figure out what’s important.

First and foremost is the RandomWordGenerator object, which essentially represents the available copasetic characters and digits captchas will contain when generated. Because it’s my bag, in mine, all letters in the alphabet are fair game; however, they are all lower case. Also too, I’ve got 10 digits represented.

The GradientBackgroundGenerator enables you to have an image with essentially two colors with a fading effect. For instance, mine fades from white to a blue-ish color (which you can see the left). The NonLinearTextPaster object allows you to declare how many characters (or digits) will appear and what color they’ll be– in my case they are gray-ish.

Note, you’ll have to import all of these trippin’ objects into your Config object; however, that’s about it– it’s boiler plate code and of course, there are other options and objects which are free to be utilized, provided you read the JCaptcha documentation. In truth, this captcha isn’t all that sophisticated and thus, advanced bots can, most likely, figure it out– in any case, you can always make these captchas more cerebral via the various objects the JCaptcha team offers.

The next step is to incorporate the captcha object into a web page. This is easily done via the jcaptcha tag, which, at its minimal usage, takes the captcha name defined in the Config object. In my case, the name is “image”.

For instance, the relevant code which shows the captcha in the image to the left is as follows:

<p><label>&nbsp;</label><jcaptcha:jpeg name="image"/></p>
<p style="padding-bottom: 0.5em;"><label>What's in the image?</label>
<input type="text" id="captcha"
       name="captcha" value=""/></p>

As you can see, there is a form input of type text, which has an id of “captcha” — this will hold the value a user presumably enters. Accordingly, the controller that the form is submitted to needs to validate the captcha. This is done by providing the JcaptchaService (which is provided via the plug-in) with the answer the user submitted, the captcha name and the session id for which the challenge was issued — i.e. the session associated with the browser when the image was viewed.

In my case, I have a closure which contains this code to verify the correct answer was issued:

if (params.captcha.equals("") ||
    !jcaptchaService.validateResponse("image", session.id, params.captcha)) {
        account.errors.reject("blank.captcha",
          "You must specify the correct characters and/or numbers in the image")
}

As you can see, the validateResponse method returns a boolean, which indicates the answer. If false is returned, then the account domain object is provided with an error, which will be displayed on the web page, allowing the person another chance to correctly get the characters and digits correct.

With the JCaptcha plug-in, implementing a virtual wall to facilitate in hampering annoying spam bots for various web forms in Grails is as easy as cake! Can you dig it?

I ran across this hip .NET library for BDD some time ago: Specter. It’s built using Boo, which is a statically typed alternate language for the .NET CLI. Few people noticed (I think I might have been responsible for the sole page view measured), but I wrote an article about Boo for InfoQ.com in March of 2007 dubbed “Much ado about Boo“– Boo is definitely a hip language, which reminds me a lot of Python. If you’re coding on the .NET platform, give it a try and then give Specter a run!

Andy Warhol is famous for having coined the phrase

In the future everyone will be famous for 15 minutes.

In my case, I still have roughly 38 seconds left. Ok, fine, you are correct, I have yet to achieve famousness and have, still, to use my 15 minutes; nevertheless, I had the pleasure of chatting with my good friend Scott Davis about a year ago regarding all things Groovy.

This video was shot while a few of us were in lovely Florida in early December 2007. In this conversation, Scott inquires as to how I got involved with Groovy and how I (at the time) was using Groovy from day to day. A few quotes jumped out at me– one in particular is Scott’s musing that

Groovy is more of a seasoning than an entrée.

Well said friend! It dovetails nicely with something I probably said three times in our conversation:

Groovy is just another JAR file!

Interestingly, Scott asked me to comment on what I saw as an upcoming aspect of Groovy that excited me. Probably to most people’s surprise, I indicated that I was looking forward to improvements to Groovy’s console. At that time, the console was lagging in usability as compared to Ruby’s IRB or Python’s shell– I was sure that the community was as excited as I was regarding improvements to this aspect. Indeed, the Groovy console is much improved (you no longer need to issue the “go” command); however, it appears that most people overlook it– at least, I don’t think I’ve talked much about the console since that day last December.

Lastly, I’ve definitely jumped head first into Grails since this video was recorded and I’m still as excited about Grails now as I was then.

The next release of easyb will support the notion of ignoring entire stories or various scenarios within in story via the ignore keyword.

As currently coded, ignore supports two features– either ignoring the entire story all together via ignore all or you can pass in one or more scenario names which to ignore. This selective ignoring feature can take three different types of parameters– a single String (which represents the particular scenario to avoid), a series of Strings (separated by commas, which represents a series of scenarios to ignore) or a Collection of Strings (which also represents a series of scenarios not to run).

As you can see, this keyword is very much like the standard xUnit paradigm’s ignore; however, it might be a bit more flexible as you can specify just what scenarios to ignore and which to presumably run in one statement, rather than having to repeatedly issue ignore statements.

For instance, the following story, dubbed noworking.story, would be completely ignored:

ignore all

scenario "this is purposely a broken scenario", {
 given "some variable with a value", {
  val = 12
 }
 then "to force an error, one should verify it is not 12", {
  val.shouldNotEqual 12
 }
}

That is, nothing within the story would be executed; consequently, no state would be captured– nothing is pending either. As of right now, pending and ignoring stories/scenarios are completely different and also convey different meanings.

Using the same exact story, you could also specify the particular scenario to ignore by passing it its name as follows:

ignore "this is purposely a broken scenario"

scenario "this is purposely a broken scenario", {
 given "some variable with a value", {
   val = 12
 }
 then "to force an error, one should verify it is not 12", {
   val.shouldNotEqual 12
 }
}

If this same story had more than one scenario, you could then either continue passing in comma delimited scenario names or just pass in a collection like so:

ignore "this is purposely a broken scenario",
    "this is also a purposely broken scenario"
//or
ignore  ["this is purposely a broken scenario",
   "this is also a purposely broken scenario"]
//which is the same as saying
coll = ["this is purposely a broken scenario",
   "this is also a purposely broken scenario"]
ignore coll

This feature is currently considered a prototype and only lives in the tip of easyb’s SVN repository. Feel free to download the source and give it a spin for yourself (building easyb is easy, man!)!

I recently had the pleasure of chatting with Max Ross, who is one of the guru’s behind Hibernate Shards, which is a fairly hip project that aims to make horizontal partitioning (aka sharding) easy within Hibernate. As Max explains in this JavaWorld Java Technology Insider podcast, Hibernate Shards provides a unified view into any number of databases, making huge amounts of data manageable even as the system evolves.

Max is a super interesting cat and I thoroughly enjoyed this conversation as I learned quite a lot– if scalability is something on your mind, then sharding might be the answer. As you’ll hear in this conversation, scaling and synchronizing multiple databases is a fairly complicated problem to solve and the Hibernate Sharding team has done a great job with this project.

Ever since Agitar lamentably shut its doors earlier this summer, there have been quite a few postings stating, predicting, or refuting the demise of unit testing. In fact, I was lucky enough to be quoted in one hip article regarding this subject written by my good friend Andrew Binstock. In his article, dubbed “Is unit testing dooomed?” Andrew does not, in fact, reach the conclusion that the practice of unit testing is doomed– he merely suggests that there might be sufficient evidence to conclude the practice might have not caught on like most of us think has.

He states that while other languages (Python and Ruby are named) appear to have a strong following of unit testing,

there are signs that, in the Java community at least, resistance has built up against the unit testing idea.

Andrew goes on to note that, in many cases “unit testing seems to offer little value” and that “evangelism [such as TDD] has become so overbearing that it makes unit testing as a whole unappealing.” Because it’s his bag, he then goes on to make a compelling case for unit testing naming four benefits, which, for those of us that actually practice unit testing, are hard to refute:

Defects are identified nearly immediately, and because unit testing isolates their cause and effect, they are also resolved more quickly. As a result, you can be more confident in the schedule. You also get better code-level documentation.

The question remains, however; is unit testing doomed? The answer to this question, of course, depends on your point of view, baby– or more precisely, what kind of development you are currently performing. For, as Andrew noted, if you are currently practicing Agile development, where unit testing has taken a strong hold and where “developers write hundreds of small tests for exercising their own code” the answer to the former question is a resounding no!

Unit testing is thriving in that crowd– people often claim (me included) that they can’t live without it! In fact, to the multitude that lives and breathes unit testing, the subject has most likely become simply boring. JUnit, by this point, is old hat– it was super interesting almost a decade ago and when 4.0 came out it was something to chat about, but for the most part, there isn’t much more to say about unit testing in general (for evidence of this, read InfoQ.com’s posting and the subsequent comments dubbed “JUnit Still Not Dead“). Sure, few books regarding JUnit have been published lately and Google’s trends seem to indicate that no one searches on JUnit. But guess what? I don’t need anymore copasetic books on JUnit– I’ve read them and I’ve got enough knowledge now on how to properly utilize it. I have zero need to go to JUnit’s website either– there’s nothing new there. In fact, in some cases, people have moved on to other frameworks, like TestNG (at least one person, other than me, is also using easyb!).

The reality of the Java market though, is that there is an entire throng of people who didn’t (or couldn’t) jump on the JUnit bandwagon all those years ago– this crowd is largely maintaining enterprise applications that are, simply put, incredibly hard to unit test, man. In these organizations, I have found that, more often than not, this is where the battle for tried and true unit testing is being lost.

In fact, Andrew correctly quoted me as stating in response to why I don’t implement a lot of TestNG solutions for companies:

most organizations do so little unit testing, if any, that I stick with the simple, well-known xUnit tools, so as not to create confusion. Most organizations are just not ready to learn anything more than basic unit testing — if that.

Many of these companies are the entire reason why there is a Java based financial ecosystem. They are why products like Websphere exist. They are why products like JBuilder existed. They are also the same companies that companies like Agitar hoped would buy their products.

These companies employ a lot of trippin’ developers. These companies have many projects that are huge. Unit testing for these companies is like trying to eat an elephant– you can start with one bite, but the overall task is daunting! When people, who work on these projects, hear evangelists bang the TDD drum, many are left scratching their heads– “how do I write a unit test for an application that has more dependencies on external systems than I have figures on both my hands? It would take me longer to handle the dependencies than to just code the feature.” (True, there is folly in this statement, however, this statement is uttered daily across the globe, man.)

These comments and this line of thinking by people faced with maintaining these code bases on a daily basis then logically answers the question of why would someone assert that unit testing “seems to offer little value” and evangelism “has become so overbearing that it makes unit testing as a whole unappealing”– for these folks, the strict term unit testing is doomed.

Don’t get me wrong, it isn’t that unit testing is impossible for these code bases and these teams. I’ve made a career of assisting in this arena; however, this is no easy task. It takes years to effectively introduce cultural change that can yield disciplined unit testing across an organization. In fact, in these situations, you can’t introduce unit testing alone– to effectively gain the manifold benefits of proper unit testing, you need an entire infrastructure to support it– namely, you need continuous integration, which means you need predictable builds.

Think about it for a second– unit testing is the elephant in the room. You’ve just been asked to eat it. But you can’t just take a steak knife and fork and start eating– the elephant is still alive looking right at you. No, you’ve got to first kill it, cut it up, cook it, etc. No wonder few people eat the elephant. Burger King is around the corner! No wonder unit testing often times seems doomed. We have a QA team that finds bugs!

Indubitably, these development teams are forced to rely on late cycle testing or at best, in the short term, can of course build up a hip suite of higher level tests. As a matter of fact, this is probably the best place to start! Can’t isolate that Account object for unit testing? No problem, bite the bullet and code an integration test– just make sure you realize you’ve got to handle the myriad dependencies associated with that business transaction (think a properly seeded database, etc).

As I said, if unit testing, as it is defined within the context of TDD, is an elephant for you and your organization, then it

is likely to remain a niche solution, found at organizations that really understand its value and progressively adopted by sites that can no longer stand the long debug cycles.

The answer to most questions depends on your point of view– if you are working on a team that has embraced agile principles, unit testing is alive and well. It’s a healthy practice that when questioned brings extreme consternation to those who’ve drank the Kool-Aid.

If you find yourself working on a legacy code base, your answer might be somewhat different– indeed, unit testing in these cases is not as easy as downloading JUnit and coding away. It’s a sizable elephant that a culture has to collectively figure out how to eat. And that takes time, commitment, and a lot of discipline. If you can’t get a handle on those three aspects, then yes, unit testing is doomed. Can you dig it, man?