In this session, I'll lead a guided tour through the latest that Spring has to offer. Whether you're a Spring veteran or a Spring newbie, there will be something new for nearly everyone.

In this example-driven session we'll see how to swiftly develop Spring applications using Spring Roo. We'll start with an empty directory and quickly work our way up to a fully functioning web application. You'll see how Roo handles a lot of heavy-lifting that you'd normally have to do yourself when working with Spring. And we'll stop at a few scenic points along the way to see how Roo accomplishes some of its magic.

Alistair Cockburn has described software development as a game in which we choose among three moves: invent, decide, and communicate. Most of our time at No Fluff is spent learning how to be better at inventing. Beyond that, we understand the importance of good communication, and take steps to improve in that capacity. Rarely, however, do we acknowledge the role of decision making in the life of software teams, what can cause it to go wrong, and how to improve it.

Games? What do games have to do with good business-oriented applications? Turns out, a lot of interesting little tidbits of user-interface, distribution, and emergence, found normally in the games we play, have direct implications on the way enterprise applications can (or should) be built.

Some systems are too large to be understood entirely by any one human mind. They are composed of a diverse array of individual components capable of interacting with each other and adapting to a changing environment. As systems, they produce behavior that differs in kind from the behavior of their components. Complexity Theory is an emerging discipline that seeks to describe such phenomena previously encountered in biology, sociology, economics, and other disciplines.

In this presentation we will take a quick walk though the issues with concurrency and how the solutions provided in Scala and Clojure help address those.

Building an application is not the straightforward exercise it used to be. Decisions regarding which architectural approaches to take (n-tier, client/server), which user interface approaches to take (Smart/rich client, thin client, Ajax), even how to communicate between processes (Web services, distributed objects, REST)... it's enough to drive the most dedicated designer nuts. This talk discusses the goals of an application architecture and why developers should concern themselves with architecture in the first place. Then, it dives into the meat of the various architectural considerations available; the pros and cons of JavaWebStart, ClickOnce, SWT, Swing, JavaFX, GWT, Ajax, RMI, JAX-WS, , JMS, MSMQ, transactional processing, and more.

Fred Brooks said, "How do we get great designers? Great designers design, of course." So how do we get great architects? Great architects architect. But architecting a software system is a rare opportunity for the non-architect.

The kata is an ancient tradition, born of the martial arts, designed to give the student the opportunity to practice more than basics in a semi-realistic way. The coding kata, created by Dave Thomas, is an opportunity for the developer to try a language or tool to solve a problem slightly more complex than "Hello world". The architectural kata, like the coding kata, is an opportunity for the student-architect to practice architecting a software system.

One of the first principles of lean software development is the elimination of waste. Shigeo Shingo identified seven types of manufacturing waste in his "A Study of the Toyota Production System." Later, the Poppendieck's translated these to seven wastes of software development.

Despite what some developers think, we spend a lot more of our time reading code, code that was often written by someone that isn't around anymore. How do we deal with this common scenario without resorting to burning our predecessor in effigy? Better, how can we write code in such a way that our successors will heap effusive praise upon us at the mere mention of our name? During this talk, we'll read actual code discussing ways it could be improved. As we work through real examples, we'll explore the importance of patterns, principles like SOLID and SLAP and essential practices like unit testing and continuous integration.

Kanban. What is it? It is most certainly not just moving sticky notes around on a board. Far from that, it is a method for gradual, evolutionary improvement of existing software processes. That's right, existing software processes. There is no "Kanban Development Process." Think you're "doing Kanban?" Think again.

Sure, Ajax might not be the hardest thing you'll have to do on your current project, but that doesn't mean we can't use a little help here and there. While there are a plethora of excellent choices in the Ajax library space, jQuery is fast becoming one of the most popular. In this talk, we'll see why. In addition to it's outstanding support for CSS selectors, dirt simple DOM manipulation, event handling and animations, jQuery also supports a rich ecosystem of plugins that provide an abundance of top notch widgets. Using various examples, this talk will help you understand what jQuery can do so you can see if it's right for your next project.

The single most important tool in any developers toolbox isn't a fancy IDE or some spiffy new language - it's our brain. Despite ever faster processors with multiple cores and expanding amounts of RAM, we haven't yet created a computer to rival the ultra lightweight one we carry around in our skulls - in this session we'll learn how to make the most of it. We'll talk about why multitasking is a myth, the difference between the left and the right side of your brain, the importance of flow and why exercise is good for more than just your waist line.