Dispatch takes many forms. Single dispatch, switch statements, pattern matching, and multiple dispatch all meet similar needs: Selecting runtime behavior in response to varying runtime conditions. Flexible dispatch is a key element of Java.next. All of the Java.next languages support dispatch strategies that are far more flexible than Java's single dispatch. In this talk (Part 3 of the Java.next series), I will explore how the Java.next languages (Clojure, Groovy, JRuby, and Scala) support dispatch.

The nature of application development has swung away from large, tightly integrated (some might say “coupled”) behemoths into loose collections of highly-granular functionality. This is true both within an application, through tools like Ruby’s metaprogramming facilities and flexible typing, and among a suite of applications, enabled by single-sign-on security architectures and widely available robust messaging providers. This talk will demonstrate these techniques and look at the benefits of this application style, from maintainability, testability, to scalability and sanity. This talk is code-heavy, slide-light, and requires the attendee to have a firm grasp of Ruby, Rails, and patterns of application architecture.

Domain-Specific Languages (DSLs) have hit the sweet spot on the hype cycle. We now hear potential clients say things like:

Our proposed killer app will target (some domain they don't understand). Step 1: Write a DSL. Step 2. ? Step 3. Profit!

DSLs are very useful, but they are no substitute for good domain design... or good code for that matter. In this talk, we will compare DSLs with other analysis and implementation tools, and help you decide when and how they are a good fit. Along the way we will discuss:

• Good API design
• Declarative style
• Mini-DSLs
• Internal DSls
• External DSLs
• User Interfaces

In recent years, the Java community has embraced a variety of new languages that target the JVM, but also offer productivity advantages over traditional Java coding.

One of the most interesting of these languages is Clojure, a "Lisp unconstrained by backward compatibility." In this talk, you will see why Clojure deserves serious consideration as the next big JVM language:

• Clojure provides all the low-ceremony goodness you know and love from dynamic languages such as Ruby and Python.
• Clojure includes Lisp's signature feature: Treating code as data through macros.
• Clojure's emphasis on immutability and support for software transactional memory make it a viable option for taking advantage of massively parallel hardware.

The rise of Ajax and Rich Web Applications, plus the success of dynamic languages, has caused people to revisit the JavaScript language. Now that we take JavaScript seriously as a language, it is time to get serious about the quality of JavaScript code, through refactoring. In this talk, we will approach refactoring JavaScript in three phases:

• Test first, then refactor. Bring JavaScript code under test, so that you can refactor with confidence.
• Refactoring 101. Explore some important refactorings: composed method, extract method, introduce named parameter, and extract object
• Common problems. Work through three problems endemic to legacy JavaScript code: making JavaScript unobtrusive, refactoring to prototype-based inheritance, and refactoring to functional style.

Prototype and Scriptaculous provide great functionality out of the box, but once you use them for a while you will probably want a little more. In this talk, we will look at tips and tricks for getting the most out of Prototaculous, plus some other libraries that can play nicely. You will see how to

• test your JavaScript code
• write unobtrusive JavaScript with Low Pro
• perform client-side form validation
• reach scripts across sites (for good, not evil!)
• create charts with the Google Chart API
• use UI components beyond the basics of Scriptaculous

As we reach the middle of our second decade of Java experience, the community has learned a lot about software development. Many of our best ideas on how to use a Java Virtual Machine (JVM) are now being baked into more advanced languages for the JVM. These languages tend to provide two significant advantages:

• They reduce the amount of ceremony in your code, allowing you to focus on the essence of the problem you are solving.
• They enable some degree of functional programming style. Think of it as a dash of verb-oriented programming to spice up your noun-oriented programming.

In this talk, we will explore and compare three of the most interesting new JVM languages: Clojure, JRuby, and Scala. Each of these languages aims to greatly simplify writing code for the JVM, and all three of them succeed in this mission. However, these languages have very different design goals. We will explore these differences, and help you decide when and where these languages might fit into your development toolkit.

You have probably heard about Git by now, perhaps something along these lines: "Git is a version control system, and it is more powerful than Subversion in every way. You don't even have to be online to commit!"

This is true, but it undersells Git. Git is not the next step in the evolution of centralized source control, following in the footsteps of CVS, SVN, etc. These tools provide centralized history of deltas, where Git provides distributed history of trees of content. In this talk, you will see the advantages of the Git approach:

• Incredible speed.
• Local, disconnected operation.
• Source control workflow customized to your team. Centralized, distributed, or layered, you can build it with Git.
• Cheap and easy branching, tagging, and merging.
• Editing and refactoring your commits.

The Git community prefers power to ease-of-use, and so Git's user interface and documentation can be intimidating. You will learn the straight and narrow path for common, day-to-day Git operations. You will also learn Git's underlying data model, and get a quick introduction to more advanced concepts like submodules, cherry-picking, and bisection.

As a final bonus, you will see how to use Git on an existing SVN project. You can use Git as your SVN client, and the rest of the team can stay on SVN and not even care.

With an expressive language such as Groovy or Ruby and with modern test practices, 100% C0 test coverage is readily achievable. But 100% coverage is meaningless without other supporting habits and practices. Over the last few years, we have taken dozens of projects to 100% coverage, and there are still plenty of things that can go wrong.

We will look at examples of each of these problems, and show how to prevent them from infecting your project:

• Fragile mocking
• Pair bravado
• The ugly mirror
• Parallel abstraction
• Overspecification
• Underspecification
• Invisible code
• Misplaced exemplar

Ruby's dynamic features make it easy to write low-ceremony code. Unlike many languages today, Ruby allows you to

• Override calls to new
• Generate new classes and methods at runtime
• Evaluate code on-the-fly
• Dynamically respond to methods with method_missing
• Create headerless source code files

But you should not be satisfied with these. Ruby's abstractions are neither as rich, nor as composable, as they could be. In this talk, we will look at what's wrong with Ruby. Issues include:

• Unnecessary language features such as class variables
• Syntax variations that require you to overspecify (e.g. instance variables)
• Limitations of Ruby reflection
• Second-class citizens, such as blocks

And, of course, we will show specific, real-world examples where these limitations lead to unmaintainable, legacy code.

Avoid these pitfalls, and your Ruby code will be more maintainable. And you will develop a keen sense of what to look for in Ruby's successor.

Most software developers don't have an exact definition of legacy code, but to paraphrase Potter Stewart, they "know it when they see it." Unfortunately, legacy code has something else in common with Stewart's famous subject--it is embarrassingly ubiquitous.

It doesn't have to be this way. In this talk, we will cover:

• A better definition of legacy.
• How existing technologies and development practices guarantee that most code will slide into legacy immediately.
• How you can stave off legacy by writing low-ceremony, essential code.

Agility can be done right. By respecting the dynamic, living nature of software/human systems, you can create systems that evolve to meet changing needs.

For more information: The ideas in this talk are development more fully in this short essay, and the slides are also online.