The Disco Blog

Is Scala, which was designed only a short while ago (comparatively speaking, that is) poised for stardom? Or will Clojure achieve greatness instead? There are a number of complementary aspects that seem to indicate for the time being that Scala might; however, what remains to be seen is if Scala can stand above recent newcomer Clojure. Both languages often show up together, especially when the topic of conversation is concurrency; nevertheless, each language is distinctly different. What’s interesting is how each language is starting to show up in various hip places.

First, a recent CIO.com article entitled “6 Scripting Languages Your Developers Wish You’d Let Them Use” listed both Scala and Clojure. While the article doesn’t necessarily give evidence for why Scala or Clojure made the list (all the author does is quote a few developers who use each language), this dovetails nicely with the ongoing results of a recent unscientific poll, entitled “which language is better suited for JVM concurrency?” which has Scala in the clear lead (36% of the vote as compared to Clojure’s 23%).

Second, both languages have books coming out in the near future– because it’s his bag, my friend Venkat Subramaniam is currently writing “Programming Scala: Tackle Multi-Core Complexity on the Java Virtual Machine” for The Pragmatic Programmers and in the aforementioned CIO.com article, one of the developers mentioned, Dean Wampler, appears to be co-authoring a Scala book for O’Reilly. Not to be outdone, however, my friend Stuart Halloway is currently writing “Programming Clojure” for The Pragmatic Programmers as well. It wouldn’t surprise me in the least if there are other books currently in writing regarding each of these languages too.

Scala might have a slight edge on Clojure when it comes to articles, however. For instance, everyone’s friend Ted Neward has a series of articles on Scala on IBM’s developerWorks. Moreover, I’ve had the pleasure of attending a few different presentations on Scala at various conferences. This edge held by Scala might only be related to the fact that the language is simply older than Clojure and I suspect that we’ll start to see, at a minimum, Stuart start to speak about Clojure at various conferences in 2009.

What’s interesting is that both languages lack a killer application– yet, they are already on the map. Ruby, which has been around for ages, was a reference to a jewel for a majority of the IT community until Rails came along. For the most part, the same could be said of Groovy. From what I can tell, the appeal for the majority of Java developers adopting Groovy is Grails. What appears to be propelling each language into the veritable limelight and which might give them a close-to-killer-application-like fame is concurrency. That is, the growing concern that new chip designs are building more and more processor cores coupled with, and I quote from CIO.com’s “Multicore Boom Needs New Developer Skills”

a worldwide shortage of people experienced in parallel computing

And as duly pointed out in the comments related to the previously mentioned poll, Java is suited to handle this challenge (and as pointed out in SDTimes’ “Guest View: Java + multicore = good news” future versions will also facilitate concurrency); however, both Scala and Clojure claim to make the job of addressing concurrency easier. And they offer this promise now (as opposed to a future copasetic version of Java).

While each language appears to be running neck and neck, where they differ drastically is in syntax. They both are functional in nature, but Clojure is a Lisp-like language, which can be quite intimidating to the neophyte developer with a Java background. Of course, well articulated books, articles, and tutorials will only help in obviating any apprehensiveness; nevertheless, Scala’s syntax is more closely aligned with Java’s. What’s more, Scala can also run on the CLR, which means it might (just might, that is, baby) find a following with .NET developers (should they find F# unpalatable).

Is Scala or Clojure poised for stardom? Can two languages co-exist as stars or does one invariably outshine the other? If history is any indication, then I’d venture to guess that the answer is that both can’t be stars– just like both Groovy and JRuby aren’t stars. They co-exist and, in truth, divide the market and have followers with strong opinions on both sides. Thus, if I had to guess right now, I’d say that Scala has the edge with some good momentum.

Yet, as pointed out earlier, if concurrency is the concern that’ll give each language the killer application-like fame, then they’ve got more time to mature and thus educate the market on how they may address concurrency concerns more appropriately than that of Java. What remains to be seen is if they can compellingly convince the Java market to learn their way of programming rather than leveraging what’s home (i.e. the Java language) for the majority of their respective target audiences. Can you dig it, man?

CIO.com recently published a hip article entitled “Stupid QA Tricks: Colossal Software Testing Oversights“, which examines five particularly egregious lapses perpetrated by IT organizations. Software mistakes, defects, and collapses occur, most likely, hourly across the globe, however, two of the five mentioned in the article are specifically worth noting for their direct interdependence with business revenue.

Because it’s my bag, I have often found that while practically every business executive will claim that quality is “job #1″, very few actually mean it when it comes to money and resources. Even the article rhetorically muses:

with IT infused in every aspect of business, doesn’t it pay to take quality assurance seriously?

What’s more, man, I’m sure each of the five companies did (and certainly now do) take quality assurance “seriously”, but apparently not serious enough. Take, for instance, J Crew, which suffered such a catastrophic software upgrade, causing the company to recently announce 3rd quarter income

was down 12% from the year-ago quarter to $18.1 million. J. Crew also lowered its per-share earnings guidance for the year to $1.44 to $1.54 from $1.70 to $1.75. The culprit was a project to upgrade the software it uses to process orders from its Web site that went astray, the company said.

Not only did the nefarious upgrade whack the company’s market capitalization, but they

spent about $3 million in the just-completed quarter to fix the problem

Clearly, there is an expensive lesson to be learned — that is, quality assurance is a lot more than verifying applications work– it’s about making sure the entire copasetic process works. Thankfully this lesson was on J Crew’s dollar and not yours, right?

Not to be outdone, though, by J Crew, the article goes on to profile a financial services firm that mistakingly sent private financial statements to incorrect addresses resulting in a loss of

nearly $450 million in managed assets

Yes, you read that correctly, they lost almost half a billion dollars in assets, which is essentially how financial institutions of this sort measure themselves. I’m sure more than one person lost their job over this faux pas.

Given these two noteworthy gaffs, what’s the big lesson? Simple– quality assurance is more than finding defects in code– it’s about ensuring the process of taking concepts and turning them into cash works. Don’t get me wrong, a large part of that process is making sure a code base contains as few defects as possible– but that focus can often neglect other issues that present risks; for example, deployments. Do you think the J Crew team had an effective roll-back strategy? Apparently not, otherwise the issue would have been a small hiccup and not a market altering event, man.

Don’t let the Titanic happen to you– icebergs (i.e. upgrades, deployments, misunderstandings, etc) will undoubtedly get in your way. It’s up to your process and how it addresses quality that’ll be the difference between striking the iceberg and safely avoiding it. For even though the Titanic might have been faultily constructed, it wouldn’t have sunk if it didn’t hit the iceberg.

I recently had to assist a copasetic client with moving a project from one Subversion repository to another repository. There are essentially two options for such a move– either export artifacts from the old repository and import the same artifacts into the new repository or leverage Subversion’s dump and load commands. The later option preserves everything, that is, tags, branches, and history.

In my case, the client wished to preserve everything; consequently, a simple export/import was out of the question. Conducting a migration using the dump and corresponding load command is fairly straight forward and I found someone who documented it quite nicely. A few other notes:

• depending on how many projects are stored in your repository, resultant dump files might be enormous, baby
• thus, you might want to investigate using the svndumpfilter command
• Reorienting projects to point to the new repository can easily be done via the command line (via the switch command); however, some developer tools, such as Eclipse’s Subclipse don’t offer a GUI way to achieve the same goal
• don’t underestimate the push back and fear some command line neophytes will throw your way

English poet John Dryden, once mused:

None are so busy as the fool and knave.

And while this observation was made hundreds of years ago, it still has a hip ring of truth to it– for as we all know, there are myriad busy people in any organization doing lots of stuff, yet achieving very little. In fact, because it was his bag, a wise executive once confided in me that, while he had a legion of employees doing a lot of work:

one should not confuse activity for progress.

Sadly, this truth is by no means unique to the IT industry nor does the future show any reduction in such impressions. In fact, a recently published article entitled “Building your own web server” reminded me of a broader infliction that exists of our industry; that is, the interminable question of whether or not to build or buy, which is often answered with build. (Before I go any further, let me commend the author of the aforementioned article for writing something interesting– the article is worth a read as it’ll please the inner-geek in anyone.)

This question, though, of should one build or buy and its correct answer have become, in my opinion, much easier to comprehend given the rise and validation of two key facets of our industry:

• open source
• and broadly speaking, validated software (and hardware!) as a service models

Note too, that the later part of the question (that is, the choice of “buy”) isn’t necessarily relevant anymore– a more hip question to ask these days is whether or not to build, buy or borrow.

By borrow, I mean “to use, appropriate, or introduce from another source” — that is, borrowing doesn’t have to imply returning and it could mean paying for such a privilege. But the option is always available to give it back– whether by providing fixes or features through source code or suggestions or by deciding to stop paying for such a service, in which case the thing borrowed is returned.

Take the seemingly mundane backbone of any web application– the web server. When beginning a project, which will ultimately result in a website for people to do interesting things, do you initially decide to:

1. build a web server?
2. buy a web server?
3. or borrow a web server?

The correct answer for most businesses (and people) is, of course, choice 3. While there are numerous web servers on the market, open source and commercial, the leader, in terms of market share, is Apache. In this case, you can easily download it and use it, for free. In this borrow relationship, you are free to give something back to Apache– suggestions, feedback, source code, etc.

In fact, you can conduct the same quiz for practically the entire infrastructure of a software project and you’ll find that you can borrow every item– IDE? Database? Build system? Application sever? You can even borrow nearly every facet of a software library– encryption? Testing? Collection handling? Emailing? Would you build any of the previously listed items from scratch?

The question then becomes, why would a team choose to borrow these things (and others) rather than build them? The answer comes down to speed.

Open source software (whether it be an application server or a library or a web server) enables businesses to focus on solving a business problem, presumably which those teams are better served to solve. That is, copasetic healthcare companies, for example, (and the smart people that work for them) are probably better at dealing with and solving healthcare-related problems than they are at building, say infrastructure components.

What’s more, open source leverages a community. I once consulted for a company that maintained their own web framework. They had an entire team, which worked on a daily basis fixing defects and adding new features that essentially every other MVC framework in the world already has. Every other MVC framework was and is more mature because each one has a community of focused smart people with varying backgrounds maintaining it and usually a wealth a users providing feedback in multiple environments and situations. In essence, open source software leverages the wisdom of crowds.

Businesses in this build, buy, or borrow situation need to step back and ask themselves — as business executives/owners/stakeholders, would we rather pay people to build a web framework (or something else that we can borrow) or would we rather pay them to solve our problems by working on those problems directly (after they downloaded the myriad capable open source web frameworks maintained by a community of people that are, for the most part, smarter at building web frameworks than our people are)? Because if our teams do download and leverage that open source web framework, they’ll have more time to build our features and consequently, we’ll get those features faster.

This veritable dilemma is becoming easier and easier to solve every passing day too. Open source technologies, platforms, and applications make great business sense because they enable businesses to work more efficiently (and therefore deliver value faster) precisely because they allow the business to focus on core issues.

Next dilemma– you’ve built your application leveraging open source technologies where appropriate and built your special sauce on top– how do you deploy it? Do you analyze your infrastructure requirements and decide to:

1. build it?
• that is, do you assemble some servers from scratch?
2. buy it?
• meaning, do you go out and buy some machines?
3. or borrow it?

Of course, the answer is increasingly option 3! That’s right, you borrow your infrastructure. Why buy a bogue machine, when you can rent some space on someone else’s? Why buy a bunch of machines for an infrastructure when you can borrow Amazon’s? Or for that matter, why not borrow Google’s?

Why borrow someone else’s infrastructure? Simple– they’re better at managing it than you. And it is most likely cheaper. Why waste time managing machines and upgrades? Why get up in the middle of the night to replace a crashed hard drive when someone else can do that for you (while you sleep)?

Speaking of infrastructure– when you started the project, you probably needed to figure out where to store your code base. You either can

• install something like Subversion on a local machine
• or if you don’t feel like worrying about a machine you can borrow a Subversion server

You see, man, borrowing may have hurt Wall Street, but in our case, borrowing makes a world of difference that equates to speed. Speed, by the way, is everything in the IT industry. Controlled, predictable speed, baby.

It’s been said that

Efficiency is intelligent laziness.

Given the current global economic climate, businesses are going to further push to “do more with less” — if you aren’t already leveraging open source software (that is, you’re building your own web server, for example) and you aren’t looking into borrowing hardware and software services (that is, you’re spending a lot of money maintaining machines and the like) then perhaps you should, man. Can you dig it?

Concurrency programming is difficult to get right– when I mused that I was concerned “that nobody really cares”, I was pleasantly surprised by a series of comments which serve to highlight the issue at hand; that is, CPU architectures are evolving, man, and Java’s concurrency model might not fit the bill.

For instance, Brian Goetz, author of Java Concurrency in Practice, commented that

…the trend [with CPU design] is towards weaker memory models, so programs that have “worked” for years will start breaking as we deploy on new generations of hardware.

What’s more, Christian Vest Hansen aptly pointed out that

In my experience, people realize that they don’t know enough to deal with concurrency, so they try to avoid writing code where they have to deal with it directly. But they don’t realize that their lack of knowledge on concurrency actually makes it near impossible for them to write code that is devoid of the concurrency they sought to dodge.

And Kirk Pepperdine commented

Any time you access data that is being shared with other threads/processes, you are programming concurrently. So, developers are already writing concurrent code albeit accidentally. This typically results in some very strange bugs. More over, the tools that we have today aren’t very helpful in helping to resolve these issues which makes them difficult if not impossible to resolve.

Accordingly, future versions of Java are targeting improved concurrency features. Nevertheless, Java’s concurrency design is fundamentally different than other languages, such as Erlang, which has no notion of shared memory (consequently, there are no needs for locks, for example). Erlang isn’t the only language built with concurrency in mind, however. Relative newcomers, Scala and Clojure also address concurrency programming and all three languages are capable of running (in some form or another) on the JVM. Thus, if it’s your bag, you can address concurrency challenges now.

Given these three languages (plus future versions of Java) then, which one is better suited for concurrent programming on the JVM?

Concurrency is hard. A language’s implementation of concurrency concerns can make the challenge of dealing with concurrency even more difficult or a bit easier. Case in point: Erlang. Erlang is a hip functional language, developed by Joe Armstrong of Ericsson in the 1980s that explicitly facilitates concurrent programming by enabling distinct parallel processes (as opposed to threads) which communicate via message passing (rather than shared memory). Thus, in Erland, there are no locks or the need to declare synchronization as there is no notion of shared memory, like there is in Java (or C#, for that matter).

The question then remains for those who are Java developers: why should I care? For starters, because it’s my bag, it is undoubtedly interesting to see how Erlang is so vastly different than everyday Java. Not only is the language functional in nature (like Haskell), but it’s also type-less (that is, types are inferred at runtime like with Ruby, for instance). Because the language was built for parallel computing, it does some interesting things that have correlation back to Java– for instance, in Erlang, all variables are essentially final once declared. Thus, Erlang doesn’t support mutable state. As anyone who’s ever coded in Java knows, mutability, while intrinsically supported by Java, can easily create nefarious defects, even in non-threaded code.

But I think the author, Joe Armstrong, does a great job of stating why one should care about Erlang. In chapter 1, a rhetorical question is posted asking “what all this about?”– Joe’s response sums it up quite nicely:

It’s about programming a distributed concurrent system without locks and mutexes but using only pure message passing. It’s about speeding up your programs on multicore CPUs…it’s about designing methods and behaviors for writing fault-tolerant and distributed systems. It’s about modeling concurrency and mapping those models onto computer programs…

All in all, I enjoyed this book– I certainly learned an interesting language that has a long history of production use. It’s a big book (500+ pages including documentation) and I did find myself skipping a few chapters here and there– for instance, there is an entire chapter devoted to a custom database developed for Erlang (my thought being that if I need a database for an Erlang application, I’ll use a language bridge to leverage an everyday RDBMS).

Learning a new language is always helpful, man; in fact, I took my own advice, as I wrote years ago, those that learn new languages:

travel the IT world more freely than do monolinguists (sure that they can apply their skills in any environment), and they also tend to better appreciate the programming language called home, because among other things they know the roots from which that home is sprung.

Next language to learn? Scala, baby!

I read an interesting article on SD Times the other day entitled “Agile Testing Fact and Fiction“, in which the author makes a hip effort at dispelling five perceived myths regarding testing in an agile environment.

Somewhat confusingly, there appears to be a bogue mentality of “anything goes” when it comes to Agile– I’m not sure where this flippant attitude stems from; however, the truth of the matter is that agility (note, no uppercase A there, man!) requires tremendous discipline. For instance, take the notion of

Working software over comprehensive documentation

No one, to my knowledge, has ever said agile means “zero documentation”, yet, strangely, there seems to exist a belief (somewhere out there!) that if there isn’t compressive documentation there must not be any. Nothing could be farther than the truth! Working software is a lofty goal and, unless the project has one person on it, requires some form of documentation– whether those documents capture stories or requirements– it doesn’t matter (heck, all forms of tests themselves are a form of copasetic documentation). The point of the phrase is that working software is valued more than myriad documents.

Thus, the same is true of testing. No one who actually practices agile software development espouses a zero testing policy. As such, I’m not convinced too many people actually believe the five aforementioned myths. What struck me as odd, however, was myth number two, which refutes that:

You can reuse unit tests to build a regression test suite

I believe the actual myth would need to imply a “comprehensive” regression test suite, as on face value, what’s the point of unit tests (using the strict definition of them) if they can’t be used as a regression suite?

I do realize that the term “regression suite” has different meanings depending on who you ask– for example, a traditional QA-oriented definition of regression suite is that of a series of functional style tests that verify an application either manually or automatically. The key point is that these hip tests are functional in nature. If you ask the developmental side of the house, our definition is usually more broad. A regression suite is a series of repeatable tests that can be run anytime– on a desktop or a build server on a scheduled basis or directly after a check-in, for example. The key point, though, is that regardless of your formal definition of a regression suite the end goal is the same. These tests verify things worked as they did before.

Using either definition then of regression suite, when teams opt to utilize continuous integration and they have their build fail when a test fails, isn’t that then a regression suite? Things clearly changed for the worse, right? True, those tests might not account for a comprehensive test suite but they are clearly a from of regression testing.

What is even more interesting, is the attempt at dispelling the myth:

While this may sound feasible, Wilson says it isn’t realistic because the granularity and objectives of white box unit tests developed in TDD serve a different purpose than downstream black box testing.

So far, so good. Indeed, there are different types of tests that serve different needs. Each is valuable in its own right. The author goes on to quote an authority:

“While the overall objective of a unit test is to prove that the code will do what is expected, the aim of regression testing is to ensure that no unexpected effects result from the application code being changed. These two objectives are not synonymous.”

This statement confused me as the person quoted is attempting to draw a distinction between “unit testing” and “regression testing”, which isn’t necessarily true. Indeed, a unit test is designed to ensure a code “will do what is expected”; what’s more, once that unit test is written it absolutely ensures “that no unexpected effects result from the application code being changed” — if they didn’t ensure this aspect, why, in this Age of Aquarius, would people write them?

The authority goes on to further draw a distinction by appearing to assert that a unit test couldn’t be used to verify a given value “contains an expected date” — I agree that both are dissimilar types of tests; however, both concerns outlined can be satisfied via a uniform style of test; that is, a “unit” test can verify both aspects.

For instance, verifying that “for a given input, the value of the field contains an expected date” can be achieved like so:

scenario "dates from atom feed should be handled", {
 given "a date format from an atom feed", {
   time = DateService.getTime("2008-10-16T22:30:27Z")
 }
 then "the time should be 6:30pm for eastern (local) time zone", {
   time.shouldBe "6:30 PM"
 }
}

This behavior also happens to verify that “an attribute has a valid date format”; what’s more, the same behavior can ensure that an attribute which contains an invalid format is properly handled, to boot, right? My verification here can serve as a regression as I can ensure negative paths:

scenario "invalid formatted dates from atom feed should not be handled", {
 given "an invalid date format from an atom feed", {
  invalid = {
    DateService.getDate("Thu, 16 Oct 2008 22:26:00 +0000")
  }
 }
 then "the time should be 6:30pm for EST time zone", {
  ensureThrows(java.text.ParseException){
   invalid()
  }
 }
}

Indeed, man, there are different types of tests and formally “Regression tests” are different than “unit tests”; however, claiming that it is a myth that a team “can reuse unit tests to build a regression test suite” is rather misleading and is itself a myth. That is, the myth that you can’t use your unit tests as a regression suite is a myth. You can and should use your hip unit tests to provide a regression analysis. The myth is that you can rely on those unit tests alone to provide 100% regression confidence. That is simply false, baby.

SD Times recently published a hip article entitled “Lost in translation“, which does a great job of profiling the long standing disconnect between those that define requirements (i.e. stakeholders) and those that implement them (i.e. developers). As the article points out, developers and stakeholders

spring from very different worlds, and every time a customer approaches a developer for an application, those realms are poised to collide.

Indeed, baby! Just as a popular book aptly pointed out that Men are from Mars, Women are from Venus so to, in this Age of Aquarius, are stakeholders and developers different! You could easily say that stakeholders, who speak in normal everyday language, are from Earth, while developers, who are able to speak in code, which is mysterious to everyone but those that have coded before, are probably from a different solar system all together. You see, when it comes to normal language documents that define requirements there is an impedance mismatch once those requirements are translated into code.

And this mismatch creates

gaps in communication and understanding [which] can result in frustration on both sides of the fence. Users get frustrated because their requirements are not being met…

The article goes on to posit that the solution to this issue of translation is

open communication, sharing of information and plain old accountability.

Which, of course, no one is going to disagree with; however, there is a more direct solution to the problem: if there are issues with respect to translation, then stop translating. That is, stop speaking different languages, man!

Case in point, in the aforementioned article, the author points out that Microsoft actually relies on a resource to translate aspects of requirements–

Rollison said Microsoft relies on program managers to translate customer needs into reasonably unambiguous requirements and build prototypes early in the design phase. “Relying on developers to design a software program would be similar to relying on an engine mechanic to design a car,” Rollison said. “Engine mechanics could probably design a car with some really cool bells and whistles, but the only truly satisfied customers would be other engine mechanics.”

While I don’t dispute the fact that some developers would, if left to their own trippin’ devices, build something really slick but totally worthless to a business, I’m shocked that rather than bridge any gaps in communication, one company chooses to throw more people at the problem.

With the advent of dynamic languages and the popularity of copasetic domain specific languages (or DSLs) frameworks are already here that attempt to bridge that stakeholder-developer gap by making code read more like normal language. This is not to say that all of a sudden trippin’ stakeholders will start writing code. No, the implication that DSLs read more like normal languages, such as English, means that developers can more aptly collaborate with stakeholders as when developers ultimately start coding (in Java, etc) they have the normal language descriptions of what they should be coding on hand.

That’s where easyb comes in! By using a specification based Domain Specific Language, easyb aims to enable executable, yet readable documentation. With easyb, software teams can verify the behavior of anything written in Java in a more natural way; that is, the verification is done using the customer’s own words. Consequently, there is no impedance mismatch between those that write requirements and those that implement them. In essence, easyb helps bridge the gap between stakeholders and development by using a language that everyone can understand. In fact, with easyb, the requirements (or specifications) are literally joined at the hip with the code that’ll implement them.

By using a more natural language that is closely in tune with stakeholders, a more collaborative platform is unfolded that permits both parties (i.e. developers and stakeholders) to talk on the same level. By doing so, the traditional bogue ambiguities and misunderstandings that have plagued software development for years have a real chance of being overcome. Of course, there are no silver bullets in software development and easyb isn’t positioned to be one; however, easyb represents an evolutionary step towards that goal of more human centered software development.

If you find yourself plagued by translation issues, don’t throw more people at the problem, man! Instead, see if you can obviate differences in languages by speaking the same one! Let your stakeholders tell you in their own words what they want! Sure, they’ll skip a myriad of things, like non-functional requirements; however, those can (and should) be accounted for by technical folks.

As the article points out

In the case of agile development, focusing early on mismatches between requirements and specifications is a good thing, said Augmentum’s Hom. “Accept that development is iterative. As development proceeds, it is imperative to have fairly frequent software builds for users to validate that progress is happening as expected. One reason is to enhance confidence. But also there is benefit to finding any misinterpretations or implementation deviations in smaller chunks, so the corrections are manageable, instead of at the end in the ‘big ban’ final user acceptance release.”

Indeed, you can let your users speak their language and eat your cake if you accept that change is inevitable and you work in short blocks of time allowing for frequent feedback. Big systems and legions of people to fix the translation problem is overkill and indicative of waterfall-like thinking. Embrace collaboration and use a common language. It is actually that easy. Can you dig it, man?

On October 27th, I will have the pleasure of joining my hip friend Rod Coffin in Boston for an easyb half-day tutorial. In this tutorial, hosted by the Software Development Best Practices 2008 conference, we’ll be spreading the good news of collaborative story development with easyb. We’ve planned out a fun agenda that involves a lot of trippin’ hands-on action– our goals are to demonstrate:

• how simple writing stories with easyb can be
• the power and flexibility of using a domain-specific language which binds stories to Java applications
• how easyb facilitates story documentation
• and how story documentation generation can enable requirements traceability

If you’re planning on attending, bring your laptop and a willingness to meet those around you as we plan on encouraging a lot of pair-programming! See you then!

I recently had the pleasure of chatting with Guillaume Laforge (Groovy’s hip Project Manager) for JavaWorld’s Java Technology Insider regarding the imminent release of Groovy 1.6. In this podcast, Guillaume shares what’s been done to greatly improve benchmark results in Groovy 1.6; what’s more, he also shares tips for optimizing Groovy-based applications and talks about the recent burst of tools support for Groovy. He also elaborates on the current challenges for the Groovy development team, and what the community can expect from upcoming releases such as Groovy 1.7 and 2.0.

If you are interested in hearing about the improvements and efforts related to the upcoming release of Groovy 1.6, then have a listen, man!