quality content marketecture - No Fluff Just StuffA Case for Continuous Integration So You Want to be Agile? quality content marketecture Where RUMPS THE I ... You will find 4-5 articles

Intro toFunctional LanguagesMessage Driven POJOsmessages made easy

A Case for Continuous Integration

So You Want to be Agile?

quality content marketectureWhere

MPSTRU

THE INAUGURAL ISSUE

the Magazine

Jan-Mar 09 | Issue I

Make Your Training Dollars Go Further In 2009NFJS brings a high-quality technical conference to your city... no travel required.Many of our speakers are the same people you will see speaking at JavaOne andother national events.

Develop Your SkillsStaying up-to-date can be overwhelming. NFJS helps developers: improve skills,solve problems, and be productive. The best developers possess many talents. NFJSevents deliver a select body of technical knowledge and hands on training. During anevent, there are always an interesting sessions available to you.

Learn How Agile Teams WinSoftware is a difficult industry with very high rates of failure. NFJS emphasizes Agilepractices such as: Test Driven Development, Continuous Integration, Code QualityMeasures, and Team Building methods to stabilize your processes and improvequality. Do your work better and faster!

Exchange Knowledge with Your PeersDo you want to solve a problem? Get a fresh opinion. Few developer problems aretruly new! NFJS is a great opportunity to interact with your peers and exchange ideas.

Save Big with NFJS Discounts1) Earlybird Rates - register early to get the best rate2) Group Discounts - NFJS makes it practical to bring your team3) Alumni Discounts - Have you attended before? Watch your email for alumni rates. * Be sure to check nofluffjuststuff.com early to get the rate available.

Topics for 2009Most NFJS events offer 5 concurrent sessions. Throughout the duration of an event,there is sure to be sessions of interest available to all developers. Our content isupdated frequently. Check nofluffjuststuff.com for current session details.

Agile PracticesCore JavaEnterprise Java : EJB3 & JMSArchitecture & ScalingGroovy and GrailsSecurityDynamic LanguagesFrameworks: Hibernate, Spring, JSFAJAX, Flex, RIA, REST

For more tour dates and information please visithttp://www.nofluffjuststuff.com/ or [email protected]

Neal FordApplication Architect atThoughtWorks, Inc.

Ted NewardEnterprise, VirtualMachine and LanguageWonk

Venkat SubramaniamFounder of AgileDeveloper, Inc.

Tour ScheduleMilwaukee, WI Feb. 27 - Mar. 1St. Louis, MO Mar. 6 - 8Minneapolis, MN Mar. 13 - 15Boston, MA Mar. 20 - 22Seattle, WA Apr. 3 - 5Chicago, IL Apr. 3 - 5Reston, VA Apr. 24 - 26Omaha, NE May. 1 - 3Atlanta, GA May. 15 - 17Denver, CO May. 29 - 31Dallas, TX Jun. 5 - 7Columbus, OH Jun. 12 - 14Raleigh, NC Jun. 26 - 28Austin, TX Jul. 10 - 12Salt Lake City, UT Jul. 17 - 18Phoenix, AZ Jul. 24 - 26Des Moines, IA Aug. 7 - 9Boston, MA Sep. 11 - 13Seattle, WA Sep. 18 - 20Cincinnati, OH Sep. 25 - 27Minneapolis, MN Oct. 2 - 4Atlanta, GA Oct. 23 - 25Reston, VA Nov. 6 - 8Chicago, IL Nov. 13 - 15Denver, CO Nov. 20 - 22

Featured Speakers

From the Publisher – Jay Zimmerman – creator of the No Fluff Just Stuff Tour Series

Greetings!

First, let me take this opportunity to thank you for subscribing to NFJS, the Magazine. The emphasis of this magazine is all about quality content just like our software conference series. For those of you not familiar with the No Fluff Just Stuff Symposium series let me share a little history. I started NFJS in 2002 to offer high quality technical content in a conference format and offered in over 30 cities throughout the U.S. and Canada. The credo of NFJS is simply: Local Venue, World Class Conference. NFJS offers individuals the opportunity to attend an outstanding conference right in your own backyard whether you live in Milwaukee, or Denver, just to name a few. The NFJS conference series is focused on great technical content(stuff) and little to no fluff – advertising, vendors, etc….

NFJS, the Magazine is an eclectic mix of articles centered on software development and all that entails. Whether you are a developer, architect or manager, you should find all of the articles in NFJS interesting and enlightening. All of the article authors are speakers on the No Fluff Just Stuff Tour and published thereby insuring a great read. We want this magazine to be time efficient for the reader. To me, NFJS the Magazine is all about outstanding content that is easily consumable. The other great thing about the format of this magazine is that you can easily read articles out of sequence over the months and refer back to something anytime. Unlike traditional magazines, NFJS has a much longer shelf life and makes a great reference source.

NFJS, the Magazine will be published 10 times a year (the spring issue (January – March) followed by monthly editions April thru December). You will find 4-5 articles per edition along with a tips section and a great editorial piece. The editor in chief of NFJS, the Magazine is Andrew Glover. Andrew is a published author, speaker on the NFJS tour and has an outstanding blog entitled The Disco blog (www.thediscoblog.com).

We are very excited to bring you NFJS, the Magazine ten times a year. I hope you find NFJS, the Magazine to be a great informational resource. Drop me an email and let me know your thoughts.

Jay [email protected]: NFJS, the MagazineTwitter: @NoFluff

NFJS, the Magazine Inaugural Issue

Agile Development is not a “guaranteed success with little effort” approach. As organizations are increasingly trying to adopt the agile development methods, it is important to realize that there is nothing magical about agility. It takes a lot of discipline and hard work to succeed. Agile Develop-ment can help those determined, by providing a guiding framework that increases the chances of success. In this article, we’ll get back to the fundamentals: why we want to be agile and how we can realize it.

TABLE OF CONTENTS

A Case For Continuous Integration 6 - 10

So you want to be Agile? 11 - 16

Intro to Functional Languages 18 - 25

Message Driven POJOs 26 - 32messaging made easy

Continuous integration is a practice that is increasing in popularity across the industry, and for good reason. CI provides process transparency, saves time, and leverages the expertise of your team.

There has been an explosion of software development languages in recent years. Chief among these languages or programming approaches is functional programming. This article will go through the details of functional pro-gramming; concepts, terms, approaches, and languages. The target audiences for this article are developers that already understand programming but are totally new to functional programming.

Spring provides a simple yet powerful messaging frame-work for receiving and sending messages. In this article I will demonstrate how to develop messaging-based appli-cations using message-driven POJOs (MDPs) and describe some ways to use them in messaging-based applications. Given that no framework is entirely perfect, I will also dis-cuss some of the limitations with MDPs and how to get around them.

Agile Development is not a “guaranteed success with little effort” approach. As organizations are increasingly trying to adopt the agile development methods, it is important to realize that there is nothing magical about agility. It takes a lot of discipline and hard work to succeed. Agile Development can help those determined, by providing a guiding framework that increases the chances of success. In this article, we’ll get back to the fundamentals: why we want to be agile and how we can realize it.

Andrew was the founder of Vanward Technologies, which was acquired by JNet-Direct in 2005. Subsequent-ly, he served as President of Stelligent Incorporated.

Andrew is the founder of the easyb BDD framework and the co-author of Addison Wesley’s “Continu-ous Integration”, Manning’s “Groovy in Action” and “Java Testing Patterns”. He is an author for multiple online publications including IBM’s developerWorks and Oreilly’s ONJava and ONLamp portals. He ac-tively blogs about software at thediscoblog.com.

Welcome to the first issue of the NFJS, the Magazine! This is a project that’s been in the works for a few months now and I’m delighted it has come together in this inaugural issue. We plan to publish 10 issues a year and each one will be filled with relevant articles discussing topics that interest the speakers you come to hear (and hopefully learn something from) at NFJS events.

When I started my career, I would eagerly await the latest issue of JavaPro or the Java Developers Journal (I think there was another magazine called Java Report too) to arrive in my mailbox. I couldn’t wait to get my hands on those magazines and I’d pour through the issues reading everything (including the 97 pages of ads!) cover to cover in matter of hours (isn’t it amazing how much time I had on my hands before children?). Sadly, those magazines lost prominence (at least in my opinion) a number of years ago; yet, I still wish they were around. While I do believe that online magainzes like IBM developerWorks and the blogoshere offer excellent content, I still enjoy reading a tangible piece of paper from time to time-- it’s nice not having to stare at a computer screen now and again. In fact, I often find myself printing various articles and blogs -- I’ll read them on flights or when the weather is nice, on my patio. Consequently, when Jay Zimmerman asked me if I’d like to be involved with a printed magazine, authored by some of the smartest people I know, I jumped on the opportunity. Who wouldn’t?

This first issue is jam-packed with articles from my friends Venkat Subramaniam, Jared Richardson, Ken Sipe, Mark Richards and Wendell Borton. Jared’s article hits the nail on the head with a timely reference to transparency through the practice of Continuous Integration and Ken’s functional programming article is certainly well timed given the fascination with alternative languages these days. I haven’t employed Spring and JMS yet, so I certainly found Mark’s article quite interesting and easy to comprehend as I’ve leveraged Spring’s HibernateTemplate on more

than one occasion; what’s more, Venkat takes a compelling look at the business value of Agile early in his article, which caused me to relate the notion of Net Present Value and its relation to software projects (sadly, I hadn’t ever put the two together before). Lastly, Wendell’s look at the longevity of software is something we should all keep in mind-- very few of us get to spend an entire career on greenfield projects! All of these individuals are a pleasure to watch and listen to in person and I think you’ll find their articles just as enjoyable. Keep your eyes pealed for the next issue too -- we’ll continue to have a cornucopia of articles from some of the most engaging personalities in our industry, including Brian Sletten, Neal Ford, David Bock, and David Geary, just to name a few!

When the weather gets a bit nicer, you’ll surely find me sitting on my patio reading issues of NFJS, the Magazine. I’ll probably leave a few issues on my next flight too -- a gift for the subsequent person who sits in my seat (or at least for the flight attendant who cleans up after me!) . It’s nice to have another technical magazine in our hands again (even if it doesn’t contain 97 pages of ads), isn’t it?

Andrew Glover

Editor, NFJS, the Magazine

Letter from the Editor

6 | NoFluff JustStuff .com

What is Continuous Integration?Though the idea is deceptively simple, after using CI awhile, it’s difficult to understand how we missed something so simple for so many years. There are four facets to any CI system: the software watches your sources code, compiles when there are code changes, runs tests when the compiles pass, and then publishes the results.

Despite its name, continuous integration isn’t really continuous. The system is triggered only when your developers check in code to your team’s source code management (SCM) software. You’ll find lots of product support for every major SCM product, whether your team uses CVS, Subversion, Perforce, ClearCase, or any of the dozens of great products available. Your CI system polls the SCM system periodically, usually every five minutes. The builds run using tools like Ant, Maven, and NAnt.

When a developer checks in code changes, the CI system sees the new code and leaps into action. The

{continuousintegration}

A Case forCONTINUOUS INTEGRATIONContinuous integration is a practice that is in-creasing in popularity across the industry, and for good reason. CI provides process transpar-ency, saves time, and leverages the expertise of your team.

by Jared Richardson

code is checked out to your CI server, where it’s compiled and tested. Finally the results are published. Each of these steps fills several needs in a software organization.

CompileYour product’s first line of defense is the compiler. Although compilers don’t verify product functionality, they do tell us when all the basic requirements are in place. Unfortunately, developers often assume if it works on their local machine, then it should work for everyone. All too often we developers forgets to check in every file we change. We’ll check in 17 of 18 files. That one file in a different package is missed, and a co-worker has to find the problem, track it down, and ask us about it. What a waste of time. We can’t afford to send developers on non-revenue producing tangents, like fixing compiles, in any economic environment, but especially our current one. Developers cost too much and time is too precious.

The better solution is to install a CI system on a machine that approximates your production build environment and let it run compiles after every code check-in. If a developer forgets to add in a file or two, or checks in code that doesn’t even compile, this software emails that developer immediately. Rather than a random teammate stumbling into the problem and debugging it, the developer who created the code fixes it. They’re familiar with the product area in question and already have any missing files on their computer.

The developer who can fix the problem the quickest is the one who’s notified. It’s simple economics.

In some shops developers hold on to their changes for weeks (sometimes months!) at a time. Checking in code is painful, so they do as infrequently as possible. If I write code for two months without checking it in, and Andy is doing the same thing, we’re pretty likely to edit the same code at some point. When we do finally check in our code, the last one to commit code has to resolve the collisions. We’ve wasted time both with doubling up on the work and with tracking down collisions. When developers check in code as frequently as possible, the

figur

e 1

No Fluff Just Stuff, the Magazine | 7

Issue I

odds of collisions dramatically decreases. Also, because changes are shared more quickly, other team members can adapt to the new code you’re writing rather than discover in two months that the entire API they’re using has been rewritten.

Save developers’ time.

Compile breaks can cover a broad range of problems.

• Developers hold code for weeks at a time, and their changes collide with other developer’s work

• Modified files weren’t checked in • New files weren’t added • Different versions of compilers between

developer machines and the production environment

• Different version of external libraries • Changing APIs between products • Different operating systems between

environments

Most of these problems aren’t recognized as major issues because the development teams discover and fix the problems during the day. No one reports the issues to management or enters them into the issue tracking system. They’re fixed as they’re found, which means your team is paying a silent tax on build issues. Time that could be spent adding features or fixing bugs is wasted resolving compile problems.

Step out of this situation by electing a truly non-partisan representative, a CI server. Your CI server catches the break the moment new code is checked in, and the tax is paid by the person who caused the problem, not a random team member.

Don’t pay taxes.

Don’t let small problems continually build up within your team. Don’t force your team to fix small bugs all day long. Over time, dust will gum up the gears of the smoothest machine.

Automate TestingAt this point your code compiles cleanly. You’re no longer paying the compile tax, but who really cares? Just because it compiles, can you “Ship It?” Of course not. Compiling is a good first step, but the code has to run and run properly. That’s all our customer really cares about. So that’s our next step.

Automated tests are a key leverage point in today’s

development environment. Traditionally, we’ve hired more people when we need more platforms validated. If the testers didn’t have the bandwidth, we drafted developers into the testing department at the end of the product cycle.

There are two major problems with this approach: it’s expensive and unreliable. Developers and testers are expensive resources, but since they’re human, they never do anything the same way twice. So not only does the organization pay top dollar for good people, but those same people, being only human, constantly make mistakes.

A better option is to have your teams share their knowledge in a test. Instead of creating test plans and having teams click through the product, have them create an automated test. Then the test can be run repeatedly, in a variety of environments, and always in the exact same way.

The possibilities for test automation are huge when the team sees how much time it saves them, and management sees how much money is saved. The product becomes more stable. The customer sees fewer bugs. Everyone is happier!

If it seems too good to be true, it is. Test code, just like product code, suffers from an affliction called “bit rot.” If not regularly run, tests get out of sync with the product code. They rust if you don’t use them every day. In the past, we’ve depended on developers to manually run all the tests before they check in code. However, we’re back to remembering that everyone is human. Even the best developers will occasionally forget to run the tests, and the mediocre developers aren’t likely to run them all. So the investment into test automation would be wasted.

Tests rust.

Fortunately, we have a fairly simple answer to rusting test suites. Run your tests in a continuous integration system. Then the entire test suite is run by the CI system on your server after every code check in. Now the developer can’t forget to run them, or choose to skip the long tests. Tests are run in a production-like environment, not a developer’s workstation where everything has been modified and tweaked to run video games faster.

When a developer checks in code, your CI system will immediately flag the break, just like it does with compiles. The developer receives an email detailing the problem, and they can fix the issue while the code is



still fresh in their mind. We’re providing a fast feedback loop to our teams.

Fast feedback leads to fast fixes.

If a developer has a bad habit, it’s in everyone’s best interest to help them break the habit. If someone constantly changes code in a way that breaks other parts of the system, how do you catch that? What if they habitually check in every file... except for one or two. How about when touching the database breaks the GUI? Overly coupled or brittle code can be broken in the most unexpected ways. The only way to catch these problems, and flag them as bad practices to the developers, is to have the CI system run the entire test suite after every code change.

There are so many reasons not to have human testers fill this role. Sometimes developers are grumpy and defensive when someone points out mistakes in their code. Other times the problems are found weeks later, and no one knows who wrote the code. It’s not always possible to take the time to sort through SCM logs and sniff out the responsible party.

The primary reason, though, is to free up your human testers. There’s no reason they should test basic functionality over and over, on multiple platforms, every time the developers change the code. There aren’t enough hours in the day to give the code the coverage it deserves. So let’s move the basic validation work over to the automated tests and CI software, which frees up the humans for two vital tasks. The first is to create more automated tests (of course!), and the second is to think. Parts of the product are difficult to test automatically: areas that require a thinking human to evaluate. Let’s free up the testers to do what humans excel at, and leave the mind numbing work to the computers. Machines don’t mind it as much, and they’re better at it anyway.

Once you decide to write tests, which tool do you use?

Every major continuous integration system runs your automated tests. Frameworks like JUnit and NUnit have become standards, and most automated testing tools generate log files based on the JUnit standard. So you can use a wide variety of tools, and just drop them into your CI system.

The alternative is being locked into a single vendor’s tools. From a support point of view this might seem attractive, but long-term it costs your organization dearly in both dollars and features. Instead, try to select tools, both open source and commercial, that

support open formats, like the JUnit log file format. This let’s you leverage the tools in a variety of settings. Tools that read and write common formats allow you to “glue” various tools together.

Open standards are glue.

Publish The ResultsPeer pressure is the single best motivator we have in the struggle to build great software. We developers have immense egos and don’t want to be caught in a mistake. When used with a good test suite, a continuous integration system exposes any problems we make. By publishing the results, we ensure that they are visible to the entire team. We become highly motivated to fix any problems before our teammates spot the issue when CI is in place. By appealing to a developer’s ego, we let them motivate themselves.

Published results also provides transparency. Any developer, tester, or manager in the organization can see who checked in code, when it was checked in, and if it had any problems. This level of transparency provides motivation for the developers and insight for managers. Often teams who keep their heads down and code are assumed to be doing very little work. If they were working, wouldn’t they be making more noise? The developers are working hard to avoid making noise... they just want to code. So no one really understands what they’re doing or how much code they churn out. The CI system let’s managers and other teams see exactly how much code the team has checked in, and (with tests) whether or not the code is working properly. This kind of non-intrusive information sharing is a great way to keep a micromanaging boss happy and out of your office.


Issue I

Now that we’ve discussed what CI is, let’s talk about why your team needs it, and why they need it this week.

Transparent Process

A CI system removes the curtain and lets the entire team understand what’s happening. Much like eXtreme Programming’s pair programming and Scrum’s daily meetings, this practice shares information. Too many shops unintentionally foster an environment that encourages developers to hoard code. This wastes time and money when developers duplicate other’s work or head off on tangents, independent of their teams’s direction.

Encourage transparency on your team.

The publishing component of CI reveals everyone who’s creating problems by causing breaks and not fixing them. It’s perfectly acceptable to let your CI system discover a problem, but once you’re notified, you should immediately fix the issue. If you don’t, your coworkers will know that you left your mess for them to clean up.

Save Time

There are many options for team-wide compiles. I’ve seen teams compile nightly, weekly, and even as needed (shudder). The longer your team waits between compiles, the more painful the merging will be and the more time it will take. The best way to eliminate this waste of time is to merge smaller code changes more frequently. Finish one feature or fix one bug, and check it in.

Add one feature, fix one bug, and check it in.

The alternatives simply don’t make sense. The longer a developer holds code, the higher the chances of code collisions and functionality changes. I’ve even seen bugs fixed and deployed, then the code overwritten by developers who had old code on their machine. This is one of the most common way bugs reoccur.

The proper use of a CI system helps train developers into smaller code commits. This eliminates large code merges, and saves the team time every day. From code merges to team wide builds, CI eliminates several classes of time draining problems.

Leverage Expertise

Developers know how their code should run. Testers know how the product should run. (Hopefully there’s some overlap in there!) But neither has the time to do a complete regression test after every code change. Instead, encourage a team-wide culture of automated testing.

Create a testing culture.

People don’t like doing work that feels like a waste of time. If you haven’t provided a testing environment (like a continuous integration server), your team isn’t likely to start writing tests. The payback feels much lower to them. Maybe the work even feels wasted.

Provide a CI environment, a place where the code can be compiled cleanly and the tests run, and there will immediately be a place for developers and testers to put their tests. Everyone can have confidence that the work they do will be used, not ignored. The time they spend creating great tests will be truly useful. They won’t be writing tests to fulfill a corporate mission statement, but to improve the quality of the product, and get them out the door on time every day.

Practices like Test Driven Development (also known as Test Driven Design) help developers validate their code with effective tests and achieve critical mass on testing coverage. Practices like Defect Driven Testing help testers and developers get test coverage precisely where the code is broken.

It doesn’t happen overnight, but a company with a strong testing culture creates safety nets around their products that keep the product rock solid for customers. A great test suite allows developers to move forward with confidence. They know that the test suite is their first line of defense, and their testing counterparts are an additional layer of protection, not a last line of defense.

Next Steps

Now that you have a continuous integration system in place, and your team is starting to write automated tests, consider that the software you ship might need to run on multiple platforms. Most products support

THE CASEFor Continuous Integration

SummaryContinuous integration can help you tune up your shop, whether your team wants more transparency, less wasted time, or fewer menial tasks. It’s difficult to fully appreciate how this works until you’ve experienced it, so I’d encourage you to consult with an expert to help get your team rolling immediately.

When we get excited about something and we don’t act on it, the ideas are often lost. Our lives are interrupt driven and between cell phones, email, and IM, some emergency will spring forward to distract us. If you want to make this (or another great idea) into reality, I strongly encourage you to act on it today. Waiting for another code merge isn’t going to save you any time!



multiple operating systems, multiple application servers, and multiple virtual machines. When you start to add in various “dot dot” versions of things like JVMs, the number skyrockets quickly. Your CI system can eliminate that pain.

Cruise Control and Hudson are two open source CI servers written in Java. This means they can run on any platform that Java can run on, giving you the opportunity to run multiple CI servers in multiple environments. In other words, when a developer changes your code, the system can be tested, in parallel, on multiple operating systems, with multiple JVMs, multiple databases, and so on.

When was the last time you or your teammates had cross-platform testing and validation within 30 minutes of checking in code?

Another question is that of scale. I’ve personally set up CI servers, in a single install, for nearly 2,000 developers. Several CI servers have clustering (or build cloud) abilities out of the box. You can add as many machines as you’d like to your “build grid.” They don’t break down a large, single compile, but they do allow multiple developers to compile and test simultaneously.

About the AuthorJared Richardson, co-author of Ship It! A Practical Guide to Suc-cessful Software Projects, is a speaker, consultant, and men-tor with NFJS One. Jared has been in the industry for more than fifteen years as a consultant, developer, tester, and manager.

He can be found on the web at http://NFJSOne.com and http://AgileArtisans.com

References

CI resources

http://martinfowler.com/articles/continuousIntegration.html http://cruisecontrol.sourceforge.net/ https://hudson.dev.java.net/ http://www.jetbrains.com/teamcity

Testing resources

http://junit.org/ http://www.jaredrichardson.net/articles/junit-tutorial/ http://seleniumhq.org/ http://en.wikipedia.org/wiki/Test-driven_development http://www.jaredrichardson.net/blog/2005/11/03/


Issue I

Why do we want to be agile?A number of organizations are striving to be agile. I’ve had the privilege of working with organizations small (a few employees) and large (a few hundreds of thousands of employees) that are keenly interested in applying and succeeding with agile practices. The key question is why? Why are these organizations and others interested in being agile.

The straight and simple answer is economics and survival. Consider an organization that embarks on a software project that’s going to take 10 years to deliver. The money burn-down will look as in the figure below. The organization is going to spend money on this project, with no visible guarantee of success. Typically, organizations try to put more money into projects by hiring more people as the lengthy project progresses. Also, other costs go up as well. However, in this figure, I assume the organization spends the same amount of money each year.

Figure 2 (right bottom) indicates a higher level of risk. Smaller organizations can’t survive this model. They can’t be spending money for a long time without making any revenue. Larger organizations, however, have bigger pockets and can afford to stretch their muscles quite a bit. They may have cash cow products that are bringing in revenue and can prolong the release of other products. However, ultimately, no organization can afford to continue with this model forever. This is why you hear news about arbitrary layoffs and drastic cost cutting measures from large organizations.

A number of organizations, fortunately, have felt the heat. They’re interested in running a business that is profitable in the long term. One of the reasons they’re drawn into agile development is due to the iterative and incremental development model that is central to

agility. Such a development makes a lot of economic sense. In figure 3 (next page), you can see the benefit of developing in increments, delivering in smaller milestones [LARM03].

The organization breaks away from the colossal plan to deliver large application with all conceived features. Instead, it aims to deliver a small, yet useful, set of features within a fraction of the time. At the end of first milestone, which may range from a few months to a year, the first release of the product is made. If the customers have no real use for the application at this point, your organization can respond to this early sign of warning. Your organization would much rather cancel a project after spending $500,000 rather than after spending $12M. That represents an organizational success as well (For a discussion of agility and success at different levels, see [SHOR07]).

On the other hand, if after the first milestone, you find that the customers are interested in the software you created, you have several things going for you. First, you start making revenue. This eases the economic pressure of your organization and also provides justification for continued development of the product. Also, you will soon realize that the features you focus

s o y o u w a n t t o b e

AGILE?Agile Development is not a “guaranteed success with little effort” approach. As organizations are increasingly trying to adopt the agile development methods, it is important to realize that there is nothing magical about agility. It takes a lot of discipline and hard work to succeed. Agile Development can help those determined, by providing a guiding framework that increases the chances of success. In this article, we’ll get back to the fundamentals: why we want to be agile and how we can realize it.

by Venkat Subramaniam

figur

e 2

figur

e 3


{beagile}

on building are not quite what you set out in the first place. This is because software exhibits the so called Heisenberg effect [HUNT99]. Heisenberg effect or the uncertainty principle states that by observing a system you change it. In the case of software, when your customers begin to use the application, they tell you what they really like it to be and hence influence your application scope and features. That is a good thing as it enables you to build what is relevant based on the real feedback you receive. If you continue at this incremental small milestone release model, your business can succeed without the economic pains that results from a colossal project.

Feedback Driven DevelopmentWe discussed the advantage of incremental delivery. But, why iterative? Let’s discuss that here.

Edward V. Berard said “Walking on water and developing software from a specification are easy if both are frozen.” The reality is, however, it is very hard to freeze the requirements because they are rarely understood fully in the first place. You’ve heard the phrase “Capture the Requirements.” It’s funny we use the word capture when it comes to requirements, meaning that requirements are elusive, like that bunny in the backyard. Defining the requirements is not a one-step process. You ask your customers and product owners what they want, develop something quickly for part of it, and see if you’re in line with their evolving understanding and expectations. It is hard to succeed if your goal is to build what your customers wanted. You need to build what they still want.

Within an incremental release, by taking iterations

to build the software, you get an opportunity to get continuous feedback (not at the end of an iteration, but during the progress of an iteration) and stabilize more features with each iteration.

With this feedback driven approach, your development team participates in refining the requirements and stabilizing features of the application from the very beginning. In such an approach, there is no need for a significant “hardening” phase at the end. In a traditional project, organizations spend as much as 10 to 30 percent of the time on hardening. In the iterative and incremental approach, the application is hardened in phases instead of during a separate hardening phase. That means less risk and increased confidence.

Customer participation is very critical to the success of your application [LARM03].

Most of the agile books and methodologies say “demo at the end of iteration.” I consider this end-of-iteration demo as a ceremony. It is a time to show off what you have done, to make sure everyone, developers, management, and customers, are all on the same page, and to establish which features are complete, so it helps with planning and release.

If, however, this end-of-iteration demo is used as the only opportunity to get feedback from customers, the result is not what you’d desire. I came across a team that was well into an “agile project” for several iterations. However, their only customer, their product owner, was not available to talk to them during the progress of the iterations. The product owner was too busy with other commitments for the organization and could only focus on the project in the beginning and end of the iteration. Their sprint/iteration backlog looked like this:

The team (which had developers with good domain knowledge) was comfortably reporting progress during each iteration, only to find that the product owner/customer was not satisfied with what has been done and wanted something different. However, this feedback was received only at the end of iteration, and hence the sharp spike in the backlog at the end of the iteration, At the above rate, the project is scheduled to


Issue I

complete close to time infinity.

For this iterative approach to be meaningful, however, you need to have continuous customer participation. Your development team needs to interact on an ongoing basis with the customers. If your developers are completing a feature or user story, say, on the third day of an iteration, you should avoid waiting until the end of the iteration to get the feedback on that.

If you are developing a product for your organization’s internal use, you may be able to (and should) get direct access to users of your products. These users can serve as your customers.

If, on the other hand, you’re developing a product for commercial use, where your users may be individuals (like in the case of a family tax software) or are employees of other companies (like in the case of developing a corporate accounting and taxation application), it will be hard for your users to play the role of customers. In that case, you can find customers among your product owner, domain experts, marketing and sales folks. You may also utilize the help of your consultants who potentially use your application in production at your client sites. Your in-house customers should have good domain knowledge, experience, and ability to interact with the real users from time to time. They may invite some friendly users to participate in the review and exercising of the application during development.

While the product owner can serve as the final authority on deciding the features and scope of your product, you will greatly benefit from having one or two additional customers working with the product owner.

In the event these customers are too busy with other engagements, you can have them participate at different times with some overlap of their schedule on the project. This will allow your development team to have someone to interact with and get feedback on a continuous ongoing basis.

Evaluating Estimates and Adaptive PlanningEstimate is latin for lying. OK, I’m kidding with that definition, but that’s how estimates feel often on projects. It is hard to estimate accurately in the beginning of a project. The ability to estimate even close to accuracy depends on the degree to which the problem is understood, the experience of the developers, their knowledge of the domain, their experience with the technology being used, and the list

goes on. No matter what our estimates are, we need to be realistic, as a team, to see if it is working and how close we are to it.

If the milestones are large, we go off for too long before we realize that we are not close to the estimates for time and scope. It is often too late to take corrective steps.

Iterative and Incremental Development helps us to check how we’re doing on our estimates. If we expected a certain amount of progress within the first two iterations (say within the first six to eight weeks) and if we’re way off from that chart, it is an early sign of warning. We can explore to find the reasons why we’re so off. Is it because the staff is inexperienced, is it because they’re pulled in different directions, is it because the customers are not available to provide feedback,... Whatever the reason is, it comes to surface quickly. I heard one of my clients say recently, “there are quite a few things we’ve been doing wrong for years. Now that we’re in an agile mode of operation, those problems begin to surface and are visible to everyone. So, we identify and work towards fixing them.”

You can observe the progress your team is making each iteration and forecast the completion date for the current release. It becomes clear to everyone that it is not a release date, but a range of release dates that you need to be working with. Alternately, if the date is set on stone for whatever good reason (like a trade show you need to present the product at), then the targeted scope needs to become the range instead of being absolute.

Weather report that track hurricanes do not simply provide a predicted path of the hurricane. They show the path and include the so called “Cone of uncertainty,” a wider, but probable area that may be affected by the progressing hurricane. As it progresses and gains strength and momentum, they continuously predict and update this cone.

We should treat project schedules like that, and present a cone of uncertainty. Rather than expecting a delivery date we should ask for a range of dates and the probability of meeting it. Alternately, if we fix the date, we ask for a cone of scope uncertainty---range of scope that will be covered by that date and at what probability.


{beagile}

Figure 4 shows the progress of a project in iterations and the targeted completion date or scope. Adaptive planning is where you continuously evaluate the progress of the project, so you can plan to reach a realistic target.

Retaining Focus and Avoiding Goldratt’s “Student Syndrome”The iterative cycle of development helps get feedback and stabilize the application features early.

There is, however, one additional advantage. Suppose you ask me to get some work done and say that it is due in six months. The chances are I will not be getting to it for quite a long time. There are other pressing things that take up my priority. I will start focusing on the work you assigned when it becomes imminent. This happens on software projects as well.

A Professor who’s been teaching a course on gaming decided to try something different one semester. He typically assigned a semester long group project for students to work the entire semester. Instead, he asked them to submit a working game with limited features within the first two weeks. He promised that the students will have opportunity to evolve and improve it quite a few times during the semester.

When the students submitted the first version of their projects, the Professor was pleasantly surprised. The games were almost as good as the games students submitted each semester in the past. May be the Professor graduated a long time ago and does not remember, students mostly cram things that are due in the end into the last two weeks of the semester. The semester where he tried it differently, he ended up with some of the most interesting and functional projects since students had opportunity to put more

time and effort on the project in reality and not only in perception.

Real world projects exhibit this so called Goldratt’s “Student Syndrome.” If you give a team six months to work on n number of features, the chances are they don’t get real serious about it until after half way past that time. However, if you ask them to deliver fraction of the number of features in a fraction of the time, they will get to work on it with greater focus due to the imminence of those features due in a few weeks. Your chances of receiving something useful greatly increases when you ask for them in small and often, rather than in bulk and less often. In other words, be continuous and not episodic. Maintain a rhythm on software projects [SUBR06].

Iterative & Incremental vs. Agile DevelopmentHow is Agile Development different from traditional Iterative and Incremental Development (IID). IID is a necessary but not a sufficient practice. If you are using IID, that does not mean you are being agile, though if you practicing agile development, chances are you will be using IID. IID recommends the iterative and incremental approach, however, does not emphasize enough two other practices. The feedback from customers and feedback from test cases. These and other practices can greatly influence the ability to succeed on software projects. Agile development is Feedback Driven Development.

Circles of FeedbackYou can rely upon two types of feedback.

One feedback is that the code is meeting your programmers’ expectations. I call this the circle of expectation.

The other feedback is that the code is meeting your customers’ expectations. I call this the circle of relevance.

Good unit tests can help you to realize the feedback circle of (programmers’) expectation. When a programmer changes the code, due to a design enhancement, refactoring or evolving requirements, these unit tests tell you that the code continues to meet the expectations set by the programmers. This is


Issue I

especially important for large applications. Code often has unforeseen side effects. Code always does what you type, but unit tests asserts to make sure it does (and continues to do) what you meant.

You can realize the circle of relevance using frequent demo to customers, letting them exercise the application early and often, and using automated functional and regression tests. Your testers and programmers can help write these automated functional tests using tools like FIT, FITNesse, RSpec, easyb,... These automated tests are executed as soon as possible after a code change, using a continuous integration tool (see Jared Richardson’s article on that topic in this issue). The goal is to know and continue to assert that the code is meeting the customers’ expectations as the application continuously evolves.

Which Feedback is really important?I have found teams that pick up one or the other circle of feedback. Let’s examine the consequence of picking one over the other.

Assume your team is impressed on unit testing and other programmer related practices. Chances are your team got exposed to eXtreme Programming (XP) [BECK04], but did not get the management support to have customer participation (even though that is a core principle in XP). The team spends enough time creating automated unit tests, but since there is not much of customer participation, the project runs the risk of developing something right, but not the right software that the customers really care about. The project suffers lack of relevance. You risk wasting the

time, effort, and money spent on the project developing something that the customers may not care for or find too hard to use.

On the other hand, if your team is impressed on customer participation, frequent demo to customers, but not automated functional and unit testing. Chances are your management got introduced to Scrum [SCHW01] and your developers got following their footsteps. Your team demos frequently what they built. Your customers want you to make some changes---they like what you have done in some areas and suggest improvements in other areas. Your boss happily commits to responding to those changes. The team make those changes while adding a few more features. When the customer goes over the application, during demo or during an exercise session, they find that parts of the application that worked before is broken or not

quite right.

Those of you who have children or who have been children know this very well. When

you visit Chucky Cheese, you can play on this toy called Whack-A-Mole. Children get a wooden hammer to whack at randomly popping moles. It is a lot of fun for the children due to the unpredictable nature of the moles. These children grow up and

become programmers,...

Ignoring the circle of relevance leads to the creation of an irrelevant application.

On the other hand, ignoring the circle of expectation leads to a whack-a-mole system.

While the outer circle is the most important, the inner circle is needed to make it sustainable. Without the inner circle, the outer circle will collapse and the result is not what you’d desire.


References [LARM03] “Agile and Iterative Development---A Managers Guide,” by Craig Larman, Addison Wesley, 2003.

[SHOR07] “The Art of Agile Development,” by James Shore and Shane Warden, O’Reilly, 2007.

[HUNT99] “The Pragmatic Programmer: From Journeyman to Master,” by Andrew Hunt and David Thomas, Addison-Wesley, 1999.

[SUBR06] “Practices of an Agile Developer: Working in the Real World,” by Venkat Subramaniam and Andy Hunt, Pragmatic Bookshelf, 2006.

[BECK04] “Extreme Programming Explained: Embrace Change,” 2nd Edition, by Kent Beck and Cynthia Andres, Addison-Wesley, 2004.

[SCHW01] “Agile Software Development with Scrum,” by Ken Schwaber and Mike Beedle, Prentice Hall, 2001.

So, what does it mean to be agile?To be agile is to develop relevant working software. We can realize that by using a feedback driven iterative and incremental development. However, writing these automated tests and interacting the customers will take time. It will slow us down? Yes. The goal of agile development is not speed. If I care only about speed, I will ignore quality, overall productivity, to show immediate progress. The goal of agile development is sustainable progress. The speed in the long term, not in the short term. It takes consistent, disciplined, hard work. Don’t rush, find your rhythm.

{beagile}

AcknowledgementThanks to several software developers and managers for their insightful discussions over the years. I would like to thank Andy Glover and Jared Richardson for their comments on this article.

About the Author Dr. Venkat Subramaniam, founder of Agile Devel-oper, Inc., has trained and mentored thousands of software developers in the US, Canada, Europe, and Asia. Venkat helps his clients effectively apply and succeed with agile practices on their software projects, and speaks frequently at international conferences and user groups. He is author of “.NET Gotchas” (O’Reilly), co-author of 2007 Jolt Pro-ductivity Award winning “Practices of an Agile Developer” (Pragmatic Bookshelf), and author of “Programming Groovy: Dynamic Productivity for the Java Developer” (Pragmatic Bookshelf).

NFJS One Private Training

Mastering the Art of IT Efficiency

These 3-5 day lab sessions teach the skills required to stay ahead of the curve and lay a founda-tion for successful projects. Our sessions are led by the same speakers you know from the NFJS tour. Our trainers are project leaders, authors, consultants, and recognized industry experts. In

many cases, you will be learning from the people who wrote the book!

We've listed some of the classes we offer below, but we're customer driven. If we're missing something you need, don't be afraid to ask.

¥ Test Automation

¥ Groovy and Grails

¥ GWT

¥ JSF

¥ Hibernate

¥ Drools

¥ Flex and BlazeDS

¥ SOA

¥ Enterprise Architec-ture

¥ Business Intelligence

¥ Agile Coaching

¥ Security

¥ RIA, Ajax, Java Script

¥ Cloud Computing

¥ Dynamic Languages

¥ Functional Lan-guages

¥ Struts Migration

¥ Automation Strate-gies

¥ Moving to Java 6

¥ Moving to REST

¥ Beginning Ruby & Rails

Our instructors deliver an excellent interactive experience that immediately boosts your team’s productivity.

Don’t come for a lecture – be prepared to get your hands dirty and walk away with something you can apply today.

Stay ahead of the curve NFJSOne.com

877-825-0663 ext. [email protected]

by Ken Sipe


What is Functional Programming?If you have been writing code for a long time with an object-oriented language (such as Java or C#) it may be difficult to imagine a different way to approach programming. Functional programming does just that. At the heart of functional programming is a new way to address a software problem- by focusing on the function decomposition of the algorithm(s). With functional programming, functions are first class citizens. If you come from the Java world, you can already appreciate the difference. In Java, the only way to express a method is as a component of a class.

Although a recent uptick in special purpose languages has gotten all the attention, functional programming is a technique and not necessarily a language. It is possible to write in a functional way with a general purpose or object-oriented language (in a later section we examine a functional example written in C#). Although it is possible, for anything significant, the lack of expressiveness quickly becomes apparent and anti-patterns start to crop up. Imagine trying to write an object-oriented program of any significant size using Java without the keywords extend or implements. These difficulties naturally lead to the need for a new language; a functional language.

Characteristics of Functional languagesOne of the core tenets of a functional language is that it is not an imperative language. In an imperative language, the variable defined in a function represents a place in memory with a defined size, which usually has an assigned value that can change through the execution of the method. In a functional language the assignment of a value to a variable is binding, just

as it would be in a mathematical function. In a math example, we might say: let x = 2. That is to say for this problem, x is the value of 2. The value of x cannot change as we evaluate this problem it is always 2. As we think in these terms, common programming practices begin to not make sense any more, like the following assignment: let x = x + 1. While this equation makes imperative programming sense, it makes absolutely no mathematical sense. There is no solution to x where x is equivalent to x+1. When you understand this concept, you are on the path to functional development.

As with Math, functional languages are not limited to just numerical value assignments. Methods in a functional language are first class citizen. So a method closure can be assigned to a variable and be passed around or leveraged in other function expressions. Comparing this again to math we can say: let x = f(y). In mathematical terms the value of x is the function f of y. For a value of y we will get a value of x. This is another core concept of functional programming. X will always be the same for a given y; it will never be a different value.

While there are variations in a number of functional programming languages, functional programming usually has the following characteristics:

• Function Closure Support• Higher-order functions• Use of recursion as a mechanism for flow

control• No side-effects• A focus on what is to be computed rather

then how to compute it • Referential transparency

Functional languagesAs we look back in the history of computer languages, we see that functional languages have been with us for some time. The most notable “grandfather” languages would include, LISP and FORTRAN. Since the mid-1980s these languages for enterprise and commercial

Introduction to Functional Languages

There has been explosion of software development languages in recent years. Chief among these languages or programming approaches is functional programming. This article will go through the details of functional programming; concepts, terms, approaches, and languages. The target audiences for this article are developers that already understand programming but are totally new to func-tional programming.


Issue I

development have taken a back seat to object-oriented languages, while functional languages have remained mostly in the academic scene. Above is a list of notable functional programming languages moving into the commercial scene.

It is important to note that functional programming does not require a dynamic language. Functional language choices allow for a dynamic or static typing. The languages listed are just a small subset of all the functional languages, each one as noted fulfilling a unique need. This article isn’t a focus on any one specific functional language, as we will see a number of language examples. The one important question we haven’t answered yet is why? Why has there been should an uptick in demand for functional languages and why now?

Why Functional?A significant change in the modern computing platform is the addition of multiple cores. Outside of the new netbook computers and PDAs, you can’t find a computer or a laptop that has a single core in it any more. We are moving to multi-core, multi-processor machines and all signs indicate this trend will continue. In addition to multi-core, high processing and complex algorithm environments are moving toward leveraging graphic processing units or GPU for highly parallel processing. The sum of all of this from a developer’s standpoint is concurrency.

Most of our programming languages make concurrency hard. Think of it this way; decades ago error handling in a c program was littered through the code base. It was integrated in with the business logic. C functions would return 0 for success and an error number for a failure code. It was obvious this wasn’t ideal, but the language was limited in expressing error handling in any other way. Along come other languages, C++ or Java, where error handling through exception handling abstracts the business code from the error handling

Erlang A general-purpose concurrent programming language and runtime named after A.K. Erlang. It contains elements of functional constructs, along with an Actor concurrency model, allowing for a simplified concurrency approach.

Haskell An open source language greater than 20 years old, which was designed to be a purely functional programming language.

OCaml Objective Caml is an open source implementation of the Caml programming language, which is dialect of the ML programming language, which is a general purpose functional programming language developed in 1970. It is credited as being the base of a number of functional programming languages including F#.

Lisp LISt Processing language is a functional programming language that was originally specified in 1958. LISP has a number of dialects to its credit.

Scala Scala is a language designed to integrate functional and object-oriented programming running on the Java Virtual Machine. It is a strongly typed programming language.

Clojure Clojure is a modern dialect of the Lisp programming language that runs on the Java Virtual Machine, which is designed for concurrency. It is a dynamically typed programming language.

F# A new language which runs on the .Net CLR, which is an implementation of OCaml and brings together functional programming and imperative object-oriented programming. It is a strongly typed programming language.


{functionalprogramming}

code. Some might argument that it isn’t great, but it is at least a step better. This illustrates the same level of maturity in our industry with concurrency. If you have a need to provide concurrency in a program in an object-oriented language, it has to be well thought out. The simple cases of spinning off a print job thread require little in the way of concurrency control, but in many cases there is a need to share state across threads, resulting in blocking on monitors. As the number of cores increases, resulting in a possible larger number of concurrently running threads, the efficiency of the system degrades. What we need is a new language, one that abstracts us from all this work in taking advantage of concurrency.

Functional languages already aid in the development of constructs that ease concurrent development, through the benefit of functions which do not share memory and which exhibit no side effects. As you dig deeper into functional languages you’ll discover that many of them abstract the developer from the concept of concurrency, in some cases it is darn right far to tell that processing is occurring concurrently. Many of the languages implement a pattern of concurrent development referred to as the actor model, where instead of threads sharing state, messages are passed between threads, thereby removing thread blocking.

Another value add of functional languages is conciseness. In chapter 1 of Stuart Halloway’s book Programming Clojure, Stu shows how 3 lines of clojure code is a factor of 3 smaller than the Jakarta Commons equivalent and is simpler in that it has no branching logic.

An important observation is that functional languages are not a replacement for procedural or object-oriented programming language. Reading through the list of functional languages in the previous section, notice that many of the newer functional languages are multi-paradigm languages that run on virtual machines and bridge other object-oriented and imperative languages. The idea is to use the most appropriate language for the problem at hand. I expect that general practitioners will continue to use a general-purpose language such as Java, Groovy or C# for mainstream needs, but when faced with a highly complex algorithm or a high concurrency need they will switch out to functional programming, integrating these solutions. This is exactly what Neal Ford has been describing for years, referring to it as the “polygot programmer”.

Functional Functions and Functional Terms

There are a number of new terms associated with functional programming, but no term comes up faster than Lambda. As mentioned, there is a close association between functional development and mathematics. Lambda refers to lambda calculus or l-calculus. No wait… don’t run away. Lambda calculus is a system designed to investigate function definition, function application and recursion.

Listing SIP-1: A simple lambda expression

There is a lot to lambda calculus we are not going to explore here. In the simplest of expressions as in listing SIP-1, lambda just provides a new syntax. The example listed is a unary function, meaning it only takes one parameter or an arity of 1. We could also pass a function to a function as in listing SIP-2.

Listing SIP-2: A simple lambda function passing

The explanation and details are at the web reference provided on lambda calculus. In listing SIP-2, each row is equivalent. The f function is passed the x function and applies a 3 to it. The x function taking the 3 is 3+2. This a very common practice in functional languages to have one function build upon another function. Consider listing SIP-3.

let scale = λ n. λx. n * x

let scale _ by _ 2 = scale 2

let scale _ by _ 10 = scale 10

Listing SIP-2

(λ f. f 3) (λ x. x + 2)

(λ x. x + 2) 3

3 + 2

Listing SIP-1

f(x) = x +2

// lambda expression below

l x. x+2


Issue I

Listing SIP-3: functions as values

In listing SIP-3, we have 3 functions. The function scale_by_2 is a method that takes the scale function and applies it to 2. It returns the equivalent of λ n. x * 2. Functional development is often layers upon layers of functions in this type of style.

ClosureAnother term and aspect of functional programming is closures. Closures are common in variety of programming languages today and the term is commonly interpreted to mean a method reference or anonymous function. Technically closures are dynamically allocated data structures containing a code pointer, pointing to a fixed piece of code computing a function result and an environment of bound variables. A closure is used to associate a function with a set of “private” variables. Anonymous functions are a technique used to accomplish this in some languages, which is where the line gets blurred for those new to the concepts.

Listing SIP-4: Understanding Closures

In listing SIP-4, the function factory returns a function that will raise a number to a power. When we invoke the square function, the necessary power variable isn’t in scope…how can this work? The function powerFunctionFactory has returned and the stack is

gone. The cube method has the same problem and this is another power to be raised. The language must store the value and it must store it for each created function. This is called closure.

Closures allow for the passing of custom behavior as arguments to functions, which leads us to our next important term “currying”

Currying

Currying is a cool word, which simply refers to the technique of transforming a function that takes multiple arguments in a way that can be called as a chain of functions which each take a single argument. So given a function foo(x,y) which results in the value of z, better expressed foo(x,y) -> z. We need to break the function down into multiple functions, which will require the passing or returning of a function. Do you see how this technique is congruent with lambda calculus?

So what if the function bar(x) -> baz then baz(y) -> z, or stated another way. The method bar will take the parameter x and return a function baz. When the function baz is given the parameter y, the result is z. So foo(x,y) -> z can now be expressed as:

Lets move away from theory and into practice, with a functional programming example in C#. Yes this is possible in C# 3.5.

Functional C#

Listing SIP-5: Functional Concepts in C#

Our normal tendency may be to create a method that takes 2 numbers, the value 100 with our scale factor 2. Using functional practices, the function scale(2) returns the function which can be applied to another variable. We name that function scaleBy2, but we could have

Function powerFunctionFactory(int power) {

int powerFunction(int base) {

return pow(base, power);

}

return powerFunction;

}

Function square = powerFunctionFactory (2);

square(3); // returns 9

Function cube = powerFunctionFactory (3);

cube(3); // returns 27

Listing SIP-3

bar(x) -> baz

baz(y) -> z

Func<int, Func<int,int>> scale =

x => y => x * y;

var scaleBy2 = scale(2);

scaleBy2 (100);

Listing SIP-4



just as easily “chained” the execution. By naming the reference to the function, we have a function that can be leveraged throughout the entire program. If you are still missing the justification don’t worry yet, we are still discussing the building blocks to functional programming.

Data Structures

Some of the data structures in functional languages include tuples, and monad. Tuples are immutable sequences of objects. Sequences, lists and trees are very common data structures in functional languages. Most languages provide operators and libraries in order to simplify working with them. We will see examples in F# later in this article.

A Monad is an abstract data type used to represent control flows or computations. The purpose of monads is to express input/output operations and changes in state without using language features that introduce side effects.

Pattern Matching

Pattern matching is nothing innovative or even specific to functional programming. It is commonly associated with functional programming because the more common mainstream languages still do not have this language feature. Pattern matching is nothing more than a concise way to match a value or type. If you have ever had a long complex series of if, if/else statements or a complicated switch statement, then suffice it to say you understand the value of pattern matching. Listing SIP-6 shows an example of matching using Mathematica to find a given Fibonacci sequence.

Listing SIP-6: Mathematica example of pattern matching

The match of 0 or 1 is 1. The match of any other value causes a recursive call back into fib. It would be a challenge to see a more concise approach to calculate a Fibonacci sequence number. In a later f# example you’ll notice a match on a discriminating union, which is a union of defined specific types. It is a very powerful technique.

Taking a look at Functional Programming Examples with F#F# is a language which was developed in the Microsoft Research and has graduated to a general public release. It is considered to be OCaml on .Net, as it has strong ties to OCaml. What makes it significant to me is its tool support. As an addition to the .Net family of languages it has fantastic language support with Visual Studio. This is rarely the case with other functional languages and specifically the languages that interest me (Clojure, Scala, Erlang). F# is also a hybrid language. It has object-orient support and has the ability to be integrated into a C# or other CLR language with relative ease. Currently F# is strong typed language that uses type interference and runs on the CLR. I haven’t experienced it yet, but all signs indicate that it can be run on Mono.

Let in F#

Listing SIP-7: F# let examples from the Tutorials.fs

The first important operator in F# is let. When dealing with variables as in int1, it is important to realize that this is not really an imperative variable it is a symbolic assignment. let can also assign variables to functions as with the example of function f. The last two code examples are assignments of tuples. pointA is a sequence of all the same type while dataB is a sequence of multiple types. Listing SIP-8 will show some lists and introduce some new operators in F#. (next page)

Listing SIP-8: F# list examples

The next important element of F# is working with lists. The list assignment code in listing SIP-8 is easily readable with two exceptions, the :: and @ operators.

fib[0|1]:=1

fib[n _ ]:= fib[n-1] + fib[n-2]

Listing SIP-5

/// A very simple constant integer

let int1 = 1

/// A function on integers

let f x = 2*x*x - 5*x + 3

// A simple tuple of integers

let pointA = (1, 2, 3)

// A simple tuple of an integer, a string and a floating point number

let dataB = (1, “fred”, 3.1415)

Listing SIP-6


Issue I

The :: operator is the cons operator is another way of describing a list. It is great when used in pattern match, which we will see later. The @ operator concatenates two lists.

The function SumList is a recursive function (defined by the rec keyword). It takes a sequence; if the sequence is empty (defined by []) then 0 is returned, else the head of the sequence (h) is added to the recursive call of the SumList of the remaining sequence. It is very common in F# to see match for a sequence with head or h as the variable representing the head and tail or t representing the remainder of the sequence.

Working with a collection can be quite different using functional techniques. In Java for instance, the approach is to iterate over the collection, with perhaps a “for each” loop. In Groovy we would use an each method passing in a closure. In F# there is a List module and it is possible to pass a function of the List module a sequence. The function would be applied on each element of the sequence. Notice the abstraction from iterations and branching.

Listing SIP-9: F# List.map function

The map function of the List module returns a new list (remember lists are immutable), with the same number of elements, each element being the square of the original list.

Fun in F#

Another language feature of F# is the fun keyword. The fun keyword allows us to write an anonymous function on the fly. This would allow us to rewrite the functions from listing SIP-9 as listing SIP-10.

Listing SIP-10: F# fun keyword defines a function on the fly

Of course this doesn’t allow for function reuse, but it can be a very convenient technique to simplify complex function creation.

let listA = [ ] /// The empty list

let listB = [ 1; 2; 3 ] /// A list with 3 integers

let listC = 1 :: [2; 3] /// A list with 3 integers, note :: is the ‘cons’ operation

let listD = [5 .. 10] /// A list of number 15 through 10

let listE = listC @ listD /// A concatenated list of listC and listD

/// Compute the sum of a list of integers using a recursive function

let rec SumList xs =

match xs with

| [] -> 0

| h::t -> h + SumList t

/// Sum of a list

let sum = SumList [1; 2; 3]

Listing SIP-7

let Square x = x*x /// A function that squares its input

let squares1 = List.map Square [1; 2; 3; 4] // Map a function across a list of values

Listing SIP-8

let squares2 = List.map (fun x -> x*x) [1; 2; 3; 4]

Listing SIP-9



let rec fib n =

match n with

| 1 -> n

| 2 -> 1

| n -> fib (n-1) + fib (n-2)

Listing SIP-13

Pipe operator in F#

For longer curried functions sometimes it is difficult to read what is happening or the order of execution. F# introduces an operator which makes this very easy, referred to as the pipe operator (|>). Listing SIP-11 rewrites the functions from listing SIP-9 and SIP-10 one more time using the pipe operator.

Listing SIP-11: F# pipe operator

This time the sequence is piped into the List.map. In a currying way these pipe operators are often chained as in listing SIP-12.

Listing 12: F# pipe operator chaining

Discriminated Unions in F#

Another feature of F# is the ability to create a discriminated union, which is a type which is limited to a defined set of types. For instance see right.

Listing SIP-13: F# Discriminated Union

Listing SIP-13 defines a type that is limited to an integer string pair, a boolean or nil. This can be incredibly useful when leverage with pattern matching as evident in this listing. This is a great example of a technique that can’t be done with a switch statement. Where a switch statement must be for a specific type, pattern

matching in F# is capable of switching on the type and providing easy access to that types payload.

Since we are pattern matching, lets end with the Fibonacci sequence implementation if F#.

F# Fibonacci Function

This F# example is not as concise as the Mathematica example in listing SIP-6, but close and very easy to read. Unlike Mathematica code however, F# is running on the CLR and is reasonably easy to integrate into a C# application.

let squares3 = [1; 2; 3; 4] |> List.map (fun x -> x*x)

Listing SIP-10

let SumOfSquaresUpTo n =

[1..n]

|> List.map Square

|> List.sum

Listing SIP-11

type exampleUnion =

| ex1 of int * string

| ex2 of bool

| ex3

// constructing instances

let a = ex1(42,”life”)

let b = ex3

let f du =

// pattern matching

match du with

| ex1(x,s) -> printfn “x is %d, s is %s” x s

| ex2(b) -> printfn “b is %A” b

| ex3 -> printfn “three”

f a // x is 42, s is life

f b // three

Listing SIP-12


Issue I

SummaryThis has been a whirlwind tour of the concept of functional programming. There are whole books written on the subject of functional programming and F# which don’t completely cover the subject. This article addresses some of the conceptual differences of functional development as faced by an individual who has worked solely with imperative languages. The concepts of lambda expressions, currying, closures and tuples were covered with sufficient detail to get started. F# examples were provided to put some of the defined terms to practice.

The need for functional programming is growing and the barrier to entry has never been smaller, its time to add functional programming to your knowledge portfolio. I would recommend taking a look at Scala or Clojure on the JVM or F# on the CLR.

Resources

Web

http://en.wikipedia.org/wiki/Functional_programming

http://research.microsoft.com/en-us/um/cambridge/projects/fsharp/default.aspx

http://msdn.microsoft.com/en-us/fsharp/default.aspx

http://deepfriedbytes.com/podcast/episode-23-functional-programming-in-csharp-with-oliver-sturm/

http://www.strangelights.com/fsharp/wiki/

Books

Programming Scala by Venkat Subramaniam

Programming Clojure by Stuart Halloway

F# in a nutshell by Amanda Laucher and Ted Neward

Expert F# by Don Syme

Learning F# 1.0 by Chris Smith.

Functional Programming in C# by Oliver Sturm

About the AuthorKen Sipe is a Technology Director with Perficient, Inc. (PRFT), IBM’s largest service partner, where he leads multiple teams in the development of solutions in the SOA, Web 2.0 and portal domains, on both the Java and .Net platforms.

Ken was the founder of CodeMentor, where he was the Chief Architect and Mentor, leading clients in the execution of RUP and Agile methodologies in the delivery of software solutions. He is a former trainer for Rational in OOAD and RUP, and a CORBA Visibroker trainer for Borland. He continues to enjoy providing training and mentoring in all aspects of software development.

Ken has a deep need to be highly diversified. Ken often works with IT executives on high-level strategic road-maps, currently geared around service oriented architectures (SOA). Ken also likes to keep his hands “dirty” in the code, which has him on a regular basis, pairing or otherwise producing code. Ken is regularly requested by clients that know him to “rescue” projects, either through the streamlining of processes or the rapid production of code.

Ken is a certified JBoss developer and is a frequent participates on open source projects. Ken is currently interested in the growing maturity of SOA solutions in the open source space, such as the ESB solutions like Service-Mix and Mule, or rules engines


IntroductionBefore I begin describing the Spring messaging framework let me first say that although I very much like what the Spring Framework has to offer, particularly in terms of its messaging framework, I do not consider myself a “Spring Fan-Boy”. On the contrary, with the possible exception of my MacBook Pro I pride myself on being largely technology and product agnostic. Using the right tool for the right job is an important ability that avoids the all-too-common “Golden Hammer” anti-pattern. When it comes to messaging and JMS, I find the Spring messaging framework is usually the right tool for the job.

The JMS API (used natively without Spring) is very straightforward and relatively simple to use. Assuming you are using queues with the point-to-point messaging model, you first obtain a QueueConnectionFactory and a Queue destination from JNDI. You then create a QueueConnection from the QueueConnectionFactory, a QueueSession from the QueueConnection, a QueueSender from the QueueSession, and a JMS Message object (e.g., TextMessage) from the QueueSession. Finally, you create your message content and send it to the queue using the send( ) method on the QueueSender. These steps are illustrated in RIC-1, Sending a message using the JMS API below.

public void sendMessage( ) throws Exception {

Context ctx = new InitialContext( );

QueueConnectionFactory factory = (QueueConnectionFactory)ctx.lookup(“QueueCF”);

Queue queue = (Queue)ctx.lookup(“queue”);

QueueConnection connection = factory.createQueueConnection();

QueueSession session = connection.createQueueSession

(false, Session.AUTO _ ACKNOWLEDGE);

connection.start();

StringBuffer xml = new StringBuffer(“\n”);

xml.append(“<trade>” + “\n”);

xml.append(“ <side>BUY</side>” + “\n”);

xml.append(“ <symbol>AAPL</symbol>” + “\n”);

xml.append(“ <shares>100</shares>” + “\n”);

xml.append(“</trade>” + “\n”);

QueueSender sender = session.createSender(queue);

TextMessage msg = session.createTextMessage(xml.toString());

sender.send(msg);

connection.close( );

}

Listing RIC-1

Message Driven POJOs

Messaging Made Easy by Mark Richards

Spring provides a simple yet powerful messaging framework for receiving and sending messages. In this article I will demonstrate how to develop messaging-based applications using message-driven POJOs (MDPs) and describe some ways to use them in messaging-based applications. Given that no framework is entirely perfect, I will also discuss some of the limitations with MDPs and how to get around them.


Issue I

Listing RIC-2: Sending a message using the Spring messaging framework

Although the JMS API is straightforward and simple, it is rather verbose. This is where the Spring messaging framework come in handy. From a Java coding standpoint, accomplishing the same thing as shown in Listing RIC-1 using the Spring messaging framework is simply a matter of invoking one of the send methods on the Spring JmsTemplate object. Listing RIC-2 illustrates the use of the Spring messaging framework for sending a message as a Java Object:

Listing RIC-3: Sending a JMS message object using the Spring messaging framework

The Spring messaging framework takes care of establishing a JMS connection, performing JNDI lookups for queues and topics, managing the JMS session, and all the cleanup associated with the JMS. This allows the developer to focus on application business logic rather than JMS code.

Of course, it isn’t all that simple. There is a fair amount of configuration associated with using the Spring messaging framework. In contrast with most articles and blogs I have read regarding the Spring messaging

framework, I really don’t mind the necessary (and verbose) configuration required for the Spring messaging framework. I rather like having the connection information, JMS destinations, and tuning parameters in configuration rather than code. In addition, Spring 2.5 offers some significant improvements in the configuration for messaging, particularly for Message-Driven POJOs.

Listing RIC-2 above also shows another great feature of the Spring messaging framework: the ability to send and receive Objects rather than JMS Messages. Spring will automatically convert a TextMessage into a String object, an ObjectMessage into an Object, a BytesMessage into a byte[ ], and finally a MapMessage into a java.util.Map (and visa-versa). Of course, Spring will allow you to send a regular JMS Message just as easily, as shown in RIC-3 below:








jmsTemplate.convertAndSend(xml.toString( ));

}

Listing RIC-2


final StringBuffer xml = new StringBuffer(“\n”);






jmsTemplate.send(new MessageCreator( ) {

public Message createMessage(Session session) throws JMSException {

TextMessage msg = session.createTextMessage(xml.toString( ));

return msg;

}

});

}

Listing RIC-3


{pojos}

Notice in Listing RIC-3 above I had to make the StringBuffer final so that it could be used in the anonymous MessageCreator class needed to build the actual JMS message object (in this case a TextMessage).

Another thing to note about the Spring messaging framework is that it is not a JMS Provider. Thus, even when using the Spring messaging framework you will still need to connect to an external JMS provider such as ActiveMQ, WebSphereMQ, SonicMQ, Tibco, or any Java EE 1.4 and above compliant application server.

Message-Driven POJOsSpring offers two ways to process JMS messages: the JmsTemplate for synchronously sending and receiving messages, and Message-Driven POJOs (MDP) for receiving messages asynchronously. In the introduction I showed a couple of coding examples using the JmsTemplate to illustrate the simplicity of the Spring messaging framework. However, what I want to focus on in this article is the more powerful Message-Driven POJOs available in Spring.

Message-Driven POJOs (or MDPs) are asynchronous message listeners that are managed by the Spring framework. They are similar to the Message-Driven Beans provided by the Enterprise JavaBean (EJB) specification, only much more powerful. MDPs also support the request/reply messaging model and event-driven processing, allowing you to send messages from an MDP using the JMS API or the Spring JmsTemplate.

There are three types of MDPs: Those that implement the javax.jms.MessageListener interface (similar to MDBs in EJB), those that implement the Spring Framework SessionAwareMessageListener interface, and finally those that use the Spring MessageListenerAdapter. Since the latter type are far more interesting and useful than the other types, I will be focusing this article on MDPs that use the MessageListenerAdapter.

Configuration BasicsMessage-Driven POJOs are just that – Plain Old Java Objects. They are not required to implement the javax.jms.MessageListener interface (although that is one of the options). From a developer standpoint they appear to be regular objects. The way they become MDPs is by wrapping the POJO class in a MessageListenerAdapter class provided by Spring. The MessageListenerAdapter is used to specify some of the behavioral aspects of the MDP, such as whether Spring should convert the JMS message object to a corresponding Java Object type, and what method name Spring should invoke on the MDP when receiving a message.

The MessageListenerAdapter is added to a MessageListenerContainer, which further specifies how the MDP should be configured. The MessageListenerContainer specifies many additional configuration options, including the JMS ConnectionFactory Spring should use, the Destination Resolver that Spring should use for resolving JNDI objects via lookups, and the number of instances of the message listener class Spring should create. The queue or topic the MDP is listening on is also specified when adding the MDP to the message listener container.

Version 2.5 of the Spring Framework introduced the new JMS Namespace as an easier and less verbose way of configuring MDPs. Prior to version 2.5, each message listener bean defined in Spring required its own message listener container. This is no longer true with version 2.5. You can now have as many message listener beans as you want in a single message listener container.

Receiving JMS Message Objects using Default Handler MethodsThe most basic MessageListenerAdapter MDP is one that receives a JMS message object (e.g., TextMessage) using the default handler method (handleMessage( )). This is similar to how Message-Driven Beans work in the EJB specification. I will start with the configuration and then show the java source code. To illustrate how MDPs work I will create a MDP called TradingMDP that receives a JMS TextMessage consisting of XML payload containing a stock trade order (similar to the one sent in Listing RIC-2.

The configuration for this type of MDP is fairly straightforward. First, the message listener class containing the application logic (in this case TradingMDP) must be wrapped in a MessageListenerAdapter class provided by Spring. This can be done by passing the class name of the MDP in the constructor-arg of the MessageListenerAdapter bean. Specifying a null value for the messageConverter property tells Spring to use the JMS Message objects rather than try to convert the message object into a Java object:

<bean id=”messageListener1”

class=”org.springframework.jms.listener.adapter.MessageListenerAdapter”>

<constructor-arg>

<bean class=”com.trading.TradingMDP”/>

</constructor-arg>

<property name=”messageConverter”><null/></property>

</bean>Listing RIC-4

MDP Message Listener Adapter without message conversion


Issue I

Listing RIC-5: MDP Message Listener Container configuration

Next, The message listener bean (in this case message Listener1) is added to a message listener container. The message listener container tells Spring which queue or topic the MDP will be listening on, how to connect to the JMS provider, and how many receivers to create. JMS supports multiple message listeners (called concurrent consumers) for a single queue. For example, if you have 5 message listeners (as indicated in the concurrency property show in the code below), this means you can process 5 messages from the queue at the same time. The configuration using the JMS Namespace is illustrated below:

Listing RIC-6: MDP without message conversion using the default listener method

Now it is time to code the TradingMDP class. By default Spring will look for a method called handleMessage with an argument matching the JMS message object (in this case TextMessage). The code for the TradingMDP is shown below:

Notice in Listing RIC-6 the use of the method signature handleMessage(TextMessage msg). When a message is received in the queue, Spring will invoke a method with that signature, passing the message along to the method. Notice that the message object is already cast to its correct type. If there were two message objects in the queue, say TextMessage and StreamMessage, then you would have to define two methods in the MDP: one for the TextMessage and one for the StreamMessage.

This MDP is good, but not good enough. The thing I don’t like about it is the fact that it still references the JMS API. To solve this problem you can leverage the message conversion features of Spring messaging, which are described in the next section.

Receiving Java Objects using Default Handler Methods

The above MDP is somewhat annoying because the class still references the JMS API. Wouldn’t it be nice if you could avoid having any sort of messaging code in the POJO and still be able to receive and process messages? With MDPs you can.

Like the JmsTemplate example in Listing RIC-2, you can have Spring convert the JMS message object into a corresponding Java object instead. Spring comes with a default message converter called a SimpleMessageConverter, which will convert an incoming TextMessage to a String object, an ObjectMessage to a Java Object, a BytesMessage to a byte[], and a MapMessage into a java.util.Map object. By converting the JMS message object into a corresponding Java Object in the MDP, you can remove a majority (if not all) of the messaging logic in your code.

The trick to enabling the automatic message conversion is to simply remove the null value in the messageConverter property of the MessageListenerAdapter bean, or more specifically don’t set the property at all. When you don’t specify a value for the messageConverter property, Spring will by default use the SimpleMessageConverter object to convert the incoming JMS message object into its corresponding Java Object type:

<jms:listener-container connection-factory=”queueConnectionFactory”

destination-resolver=”destinationResolver”

concurrency=”5”>

<jms:listener destination=”queue1” ref=”messageListener1”/>

</jms:listener-container>

Listing RIC-5

package com.trading;

import javax.jms.TextMessage;

public class TradingMDP {

public void handleMessage(TextMessage msg) {

try {

String xml = msg.getText( );

//process xml trade order...

} catch (Exception e) {

e.printStackTrace( );

}

}Listing RIC-6



<constructor-arg>


</constructor-arg>

</bean>Listing RIC-7

MDP Message Listener Adapter with message conversion


{pojos}

Listing RIC-8 MDP with message conversion using the default listener method

With message conversion, rather than looking for a method signature matching the JMS message object, Spring will look for a method signature matching the corresponding Java Object. Thus, to process a TextMessage from the queue you would create a method signature containing handleMessage(String s) as shown in Listing RIC-8 below:

There are a couple of things to notice in the code shown in Listing RIC-8. First of all, since you are passing in a String object containing the message payload (in this case XML containing the stock trade order), you no longer need to extract the message payload using the getText( ) method as you did in Listing RIC-6. The other thing to notice is that you no longer need to import javax.jms.TextMessage. As a matter of fact, if you look closely at the code, you will see that there is no sign of JMS or messaging whatsoever.

This code is much better than the previous example in that it no longer contains a reference to the JMS API. This allows you to focus solely on the business logic required to process the message. However, while this code is better than the prior example, it can still be improved. The thing that still annoys me about the code in Listing RIC-8 is that it requires the use of a method named handleMessage( ) (not very descriptive in my opinion). This can be fixed quite easily, as is shown in the next section.

Receiving Java Objects using Custom Handler MethodsThe code in Listing RIC-8 is a big improvement over the code shown in Listing RIC-6. You no longer need to code any JMS logic, allowing you to focus on application business logic. However, the code in Listing RIC-8 is still not perfect in that it is still using the default message handler name (handleMessage( )). The handleMessage( ) method is only the default handler method name for the message listener adapter. You can set the method name to anything you want. Since the method in Listing RIC-8 is processing a trade order, perhaps a more descriptive name for the method would be processTrade( ).

To have Spring invoke a custom method name rather than the default handleMessage( ) name when a message is received, simply set the value of the defaultListenerMethod property on the MessageListenerAdapter to the name of the method in your MDP (in this case processTrade):

Listing RIC-10 MDP with message conversion using a custom handler method

Now, your POJO does not have to define the generic handleMessage( ) method, but rather a more descriptive one as shown in Listing RIC-10 (next page):



public void handleMessage(String xml) {

try {




}

}

}

Listing RIC-8



<constructor-arg>


</constructor-arg>

<property name=”defaultListenerMethod” value=”processTrade”/>

</bean>

Listing RIC-9

Message Listener Adapter using custom handler method


Issue I

Now this is what I call a MDP! Take a close look at the code in Listing RIC-10. This code is actually an asynchronous message listener that receives a trade order in XML format from a message queue. However, there is no reference to the JMS API, and as a matter of fact no reference to messaging or Spring whatsoever. This illustrates the true power of MDPs. The code in Listing RIC-10, although written as an asynchronous message listener, can be used (and tested) outside of the context of messaging and JMS. This means that the same exact source code can be used in the context of a messaging infrastructure as well as other input channels (such as Web Services, Web-based requests, or even VIOP).

MDP LimitationsLooking at the source code in Listing RIC-10, you might be convinced that MDPs are the greatest thing since sliced bread. However, there are a few limitations and considerations to take into account before converting all of your code to MDPs with message conversion and custom handler methods.

The first consideration to take into account when using MDPs with message conversion and custom handler methods (as shown in Listing RIC-10) is that without proper documentation, you can’t tell that the code is actually an asynchronous message listener. A developer, not knowing this fact, may alter the source code

making it incompatible with the messaging framework. Although the code doesn’t show it, the class is still an asynchronous message listener and for the most part should be treated as such.

The second limitation with MDPs will become immediately apparent with the following scenario. Using the code in Listing RIC-10, assume that, along with the XML trade order, you also need to pass some additional information in the message properties section of the message header (such as security credentials) as shown in Listing RIC-11:

Listing 12: MDP without message conversion using a custom handler method

Now assume for auditing purposes you need to extract the traderId property from the message header and write a record out to the audit table when receiving the trade order message in the MDP. Oops – looking at the code in Listing RIC-10, this isn’t possible with a MDP with message conversion because only the








jmsTemplate.send(new MessageCreator( ) {

public Message createMessage(Session session) throws JMSException {

TextMessage msg = session.createTextMessage(xml.toString( ));

msg.setLongProperty(“traderId”, 99);

return msg;

}

});

}

Listing RIC-11

Sending additional header info.

package com.trading;v


public void processTrade(String xml) {

try {




}

}

}

Listing RIC-10


{pojos}

message payload is passed to the method (not the header information). The MDP does not have access to the original message and cannot access the message header. This is a serious limitation in that you cannot perform request/reply processing (you would need access to the JMSReplyTo header property) and cannot process additional opaque information contained in the message properties area of the header.

Of course, this can easily be fixed by moving back to the MDP version that processes a JMS message object. You simply need to set the messageConverter property on the MessageListenerAdapter to null (as shown in Listing 4) and change the method signature in the source code, which is shown in Listing RIC-12 below:


import javax.jms.TextMessage;


public void processTrade(TextMessage msg) {

try {

String xml = msg.getText( );




}

}

}

Listing RIC-12

ConclusionIn this article I introduced the JmsTemplate for sending messages and described the stages of a simple MDP from using the JMS-specific handleMessage(TextMessage msg) method to the message-agnostic processTrade(String xml) method used in the stock trade example. The Spring messaging framework significantly re-duces the amount of code needed to send and receive messages, allowing you to focus on the application business logic rather than the JMS infrastructure. Although there are some limita-tions and considerations to take into account when using MDPs, they are nevertheless a pow-erful tool for processing JMS messages.

About The AuthorMark Richards is a Director and Senior Technical Architect at Collaborative Consulting, LLC (http://www.collaborative.com). He is the author of the 2nd edition of Java Message Service (O’Reilly, 2009) and of Java Transac-tion Design Strategies (C4Media Publishing, 2006). He is also a contrib-uting author of several other books, including 97 Things Every Software Architect Should Know (O’Reilly, 2009), NFJS Anthology Volume 1 (Prag-matic Bookshelf, 2006) and NFJS Anthology Volume 2 (Pragmatic Book-shelf, 2007). Mark is a regular speaker for the No Fluff Just Stuff Sympo-sium Series and speaks at other conferences and user groups throughout the world.

NFJS One Private Events

Bring the No Fluff Just Stuff Software Symposium to you

The No Fluff Just Stuff Software Symposium Series covers the latest in trends, practices, and developments in enterprise Java, Java/Groovy, ESB/SOA, Ajax, web services, Agil-

ity, and architecture. We provide the best speaker quality and conference experience.

We've hosted more than 150 events with over 25,000 attendees – we now offer this to you on a private scale tailored to your environment, goals, and initiatives.

Forum

Events will be conducted over 2-5 days ( weekends accepted)

Once classes are selected we will select speakers ( mini-mum of 2 )

We allow you to either host event at your facilities or a public location

We can assist you with ca-tering

Classes

We offer training classes for teams of all sizes, providing instructional style classes as well as hands-on workshops to immerse your team.

Our classes range from two to five days, and range from introductory to expert level.

Our cutting edge instructors deliver an excellent hands-on experience to boost your team’s productivity.

Current courses

¥ Test Automation

¥ Groovy and Grails

¥ GWT/JSF/Ajax

¥ Hibernate

¥ Agile Coaching

¥ Security

¥ Automation Strategies

¥ Moving to Java 6

¥ Moving to REST

¥ Ruby & Rails

Imagine where your product can be in six months

We'll help you plan and customize your event

Give us a call for a free planning session

Stay ahead of the curve NFJSOne.com

877-825-0663 ext. [email protected]


{cobol}

Are you currently maintaining a COBOL application? Planning to write one anytime soon? Chances are that if you are reading this magazine, you aren’t. I’m certainly not; in fact, I’d probably struggle to count, on one hand, the number of people I know who could recognize COBOL (let alone actually maintain it!). Yet, (hopefully this doesn’t come as a surprise) COBOL applications are still running today.

Referencing a Gartner study, Wikipedia points out that a mere 10 years ago “80% of the world’s business ran on COBOL with over 200 billion lines of code in existence and with an estimated 5 billion lines of new code annually.” [1] As a matter of fact, the use of COBOL is still growing -- by “about a billion lines per year.” [2].

Yes, that does read a billion; nevertheless, why should you care? After all, NFJS is a conference that primarily focuses on the Java platform and I rather doubt we’ll ever see a presentation regarding COBOL. Perhaps learning COBOL could prove to be a financial boon -- ultimately, if COBOL’s usage is growing (remember, a billion lines a year!) then it might make sense to learn it, right? Someone’s got to maintain all that code!

Think about it another way, however. If COBOL is still out there running; indeed, running business critical applications judging by its formidable growth, what does that mean for the code you’re writing today (whether it be Java, Ruby, Groovy, or C#)? If history is any indication, the code you write today will most likely be around a long, long time, especially if it has any business value to it.

Apparently, that’s the case with COBOL; for example, one source states that “the investment in COBOL technologies, staff and hardware, is estimated to be greater than 5 trillion dollars.” [3] That’s a large number

(even in these times of $800 billion stimulus bills!). Here’s another interesting fact: “Of 352 respondents to a recent Computerworld survey of IT managers, 218 -- or 62% -- said they use COBOL.” [4] Is the picture becoming clearer? 5 trillion dollars. 62% usage -- yet, perhaps less than 10% knowledge (or even desire!) of COBOL programming from the readers of this issue alone.

That means the practices and decisions you put into place today when you develop software will affect someone, most likely not yourself, in the future -- in some cases the very distant future. This also implies that the decisions of the past are affecting you now.

Clearly, software applications that achieve business value are far from ephemeral flashes in a pan-- so what are you doing today to ensure these systems can still run tomorrow? Not only does software live a lot longer than intended, it’s also entropic-- without an insightful software process that encourages quality, software systems will become more complex and harder to change. Indeed, the 62% of respondents who still use COBOL-- 25% said that they would throw it out “if it weren’t for the expense of rewriting all of that code.” [5]

Latin is often labeled a dead language, yet, I had to take a year of it in high school-- and I didn’t attend high school 2,000 years ago. Spoken languages never really die; they survive in texts and are carried forth by academics (and nuns with rulers). Programming languages rarely die either. They linger as applications that go on and on until the cost to maintain them overtakes the cost to rewrite them. And, it seems clear, as demonstrated by the longevity of COBOL, that software applications can last “in aeternum”, which in Latin means “for eternity.”

In aeternum of software

Referenceshttp://en.wikipedia.or/wiki/COBOL

http://www.linuxinsider.com/story/linux-developer/53842.html

http://en.wikipedia.org/wiki/COBOL#cite_note-4

http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=266156&intsrc=kc_rfavs

http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=266156&intsrc=kc_rfavs

by Wendell Borton


Issue I

Coming Next MonthStay tuned to NFJS in April as the tour heads to the bright and beautiful cities of Seattle, Chicago, and Washington, DC! Plus, the next issue of NFJS, the Magazine will feature:

• Brian Sletten’s The Extensible Messaging and Presence Protocol• Nate Schutta’s Test Infecting the Legacy Organization • David Geary’s Flex for Java Developers• David Bock’s The Theory behind a “Whats Hot” Ranking Filter

If that doesn’t make your April a fabulous month, seek professional help (or stop coding so much COBOL)!

www.groovymag.com

the Magazine

Documents

quality content marketecture - No Fluff Just StuffA Case for Continuous Integration So You Want to be Agile? quality content marketecture Where RUMPS THE I ... You will find 4-5 articles