Watch Preview Video

Even with the recent explosion in alternative languages for the JVM, the vast majority of us are still writing code in "Java the language" in order to put bread on the table. Proper craftsmanship demands that we write the best Java code that we can possibly write. Fortunately we have a guide in Joshua Bloch's Effective Java.

In his foreward to the first edition, Guy Steele writes about the importance of learning three aspects of any language: grammar, vocabulary, and idioms. Unfortunately many programmers stop learning after mastering the first two. Effective Java is your guide to understanding idiomatic Java programming.

Effective Java is organized into 78 standalone "items," all of which will be impossible to cover in one session. Instead I've chosen a subset of the most important techniques and practices that are commonly missed by today's Java programmers. You'll pick from a menu and decide where we'll head. Regardless of the path we take, you'll leave this session thoroughly equipped to write better Java code tomorrow!

Even with the recent explosion in alternative languages for the JVM, the vast majority of us are still writing code in "Java the language" in order to put bread on the table. Proper craftsmanship demands that we write the best Java code that we can possibly write. Fortunately we have a guide in Joshua Bloch's Effective Java.

Effective Java is organized into 78 standalone "items," all of which will be impossible to cover in one session. Instead I've chosen a subset of the most important techniques and practices that are commonly missed by today's Java programmers.

*In Part II of this session, we'll cover those items we were unable to reach during Part I. We'll follow that up with a dive into the new features available in Java 7, describing new idioms for effective Java programming in the following areas:

• Strings in switch statements
• Enhanced syntax for numeric literals
• Improved exception handling
• ARM (automatic resource management) blocks
• Type inference for construction of parameterized types (the "diamond" operator)

Watch Preview Video

Object-oriented programming was formally introduced in the 1970's with the advent of Smalltalk. C++ took it mainstream in the 1980's, and Java carried it to the next level in the 1990's. Unfortunately, if you examine the vast majority of Java codebases, what you'll find is a bunch of C-style structs (a.k.a. JavaBeans) and functions. As these codebases grow, a number of design smells can potentially crop up, which in turn cripple our ability to respond to change. We need SOLID principles that we can apply to keep our software clean and malleable.

Robert C. "Uncle Bob" Martin identified several design smells in his book Agile Software Development: Principles, Patterns, and Practices:

• Rigidity
• Fragility
• Immobility
• Viscosity
• Needless Complexity
• Needless Repetition
• Opacity

We can reverse and in fact avoid these techniques by following the principles of SOLID software design:

• Single Responsibility
• Open-Closed
• Liskov Substitution
• Interface Segregation
• Dependency Inversion

You'll leave this session equipped to ferret out design smells and apply these principles on your next project.

The book Enterprise Integration Patterns gave us a consistent vocabulary and notation with which to describe solutions to common integration problems that arise in the modern enterprise. Spring Integration (http://www.springsource.org/spring-integration) harnesses that vocabulary, providing a very natural extension to the well-known Spring programming model that enables the construction of loosely-coupled, messaging-based applications that can also integrate with services in the wild via a variety declarative adapters for heavily used protocols. This talk will provide an overview of the Spring Integration framework, it's relationship to the patterns, and to the problems they aim to solve. We'll also look at several integrated case studies.

Topics covered will include:

• Framework background, goals and principles
• Messages, Channels and Endpoints
• Transformers
• Filters
• Routers
• Splitters and Aggregators
• Service Activators
• Channel Adapters (Feeds, Files, FTP/FTPS, HTTP, Mail, TCP/UDP, JDBC, JMS, RMI, SFTP, Twitter, ...)
• Integrated Case Studies

Much is said today by the software methodology "talking heads" about the need for organizations to "go lean." The question is, what does it mean to go lean? Is this the job of IT management? Or is it the job of the practicing software developer? And furthermore, does this simply mean the adoption of of another set of processes and procedures? Or is it something entirely different?

Ultimately, going lean simply means removing all of the impediments that prevent our organizations from achieving more of "the goal." While that goal may differ from context to context, for the vast majority of us that means "making more money," by improving our efficiency at moving from, as the Poppendieck's have so aptly said, from "concept to cash."

While a great many of us do not have the role power necessary to spur top-down organizational change, there are many practical things each of us can do to bring the power of "going lean" to our teams. As we apply these principles and practices to our day-to-day work, we can build the credibility necessary to become change agents.

In their books, the Poppendieck's have helpfully summarized lean software development into seven principles:

1. Eliminating Waste
2. Building Quality In
3. Creating Knowledge
4. Deferring Commitment
5. Delivering Fast
6. Respecting People
7. Optimizing the Whole

In this talk we'll walk through each of these principles and examine how we as individual contributors and software teams can make practical, actionable changes within our own spheres of influence that will ultimately help us to deliver more value to our organizations.

Watch Preview Video

What is the DevOps movement? It a nutshell, it is the idea that the days of silos are over. Development, QA, and operations can no longer be thought of as separate warring divisons with their own "turfs." Instead, we must focus on the fact that we are all part of a single value stream for the customer. By collaboration and shared expertise, we can find real overlaps between our previously segregated areas of expertise and optimize that value stream.

We'll cover the following topics:

• Death to Silos: developing an culture of collaborative software delivery
• Developing communication and bridge-building skills
• Understanding your business and its domain
• The automated "infrastructure as code" revolution
• Driving performance, process, and people improvements through metrics
• The DevOps' Toolkit: Puppet, Chef, Flapjack, Vagrant, and friends

Watch Preview Video

Feature requests are steadily pouring in, but the team cannot respond to them. They are paralyzed. The codebase on which the company has "bet the business" is simply too hard to change. It's your job to clean up the mess and get things rolling again. Where do you begin? Your first task is to get the lay of the land by applying a family of techniques we'll call "Code Archaeology."

In this session we will learn how to systematically explore a codebase. We'll look at what tools are available to help us out, slinging some wicked shell-fu along the way. We'll look at "code islands" and "code bridges," and how to construct a "map of the code." We'll also examine the wisdom that thought leaders like Michael Feathers and Dave Thomas have leant to this subject.

Once we've gained a thorough understanding of what we have in front of us, we'll learn approaches for getting the system under test and refactoring so that we can start to pick up the pace and respond to user requirements without making a bigger mess. You'll leave this session well prepared to tackle the next "big ball of mud" that gets dumped on your desk.

Watch Preview Video

Chef is a community-developed platform for automated provisioning, configuration, and integration of software infrastructure. It currently boasts 190+ individuals and 40+ companies (including parent company OpsCode) as contributors, and companies like EngineYard, ElectronicArts, GoTime, and Rhapsody as adopters.

Chef achieves fully automated infrastructure via three primary disciplines:

• Automated provisioning of bare metal, virtualized, and cloud environments
• Configuration of servers via roles ("webserver", "appserver", "loadbalancer") and recipes, which are declarative descriptions of resource (e.g. Apache, MySQL, Hadoop) configurations written in a Ruby DSL
• Systems integration via dynamic lookup and discovery

We'll dive deeply into Chef's architecture and features, including its idempotency, its thick client/thin server philosophy, its intentional lack of dependency management (preferring and order-based configuration), and its deep integration with other tools. We'll then leverage Chef to set up infrastructure of a typical JVM-based web development project with various OS, application server and datastore configurations. You'll leave a ready to get cooking with Chef on your next software delivery effort.

Watch Preview Video

Puppet is a powerful framework for the automation of tasks typically performed by system administrators as part of software infrastructure provisioning and maintenance. Puppet adoption is rapidly increasing, boasting use by companies such as Google, RedHat, Constant Contact, Zynga, and Shopzilla.

Puppet is composed of three principle components:

• a declarative language for expressing system configuration,
• a client and server for distributing it,
• and a library for realizing the configuration

We'll dive deeply into Puppet's architecture and features, including its idempotent configurations, cross-platform resource abstraction layer, and graph-based modeling of resources, resource providers, and resource relationships. We'll then leverage puppet to set up infrastructure of a typical JVM-based web development project with various OS, application server and datastore configurations. You'll leave a "Master of Puppet," ready to apply it on your next software delivery effort.