A little old lady once challenged a well-known scientist’s explanation on the structure of the universe, countering that the world is really a flat plate supported on the back of a giant tortoise. The scientist rebutted the little old lady’s challenge with one of his own by asking what the tortoise was standing on. The little old lady’s sly reply was that it’s, “turtles all the way down.” So too is software architecture “turtles all the way down”.

In this session, we cover a broad range of topics that include challenging traditional practices of software architecture, examining what it takes to bring down the ivory tower, probing the paradoxical aspects of architecture’s goal, and investigating the inextricable link between temporal decisions and structural flexibility. From the highest level applications and services to the code that exists in the bowels of the system, and everything in between, we explore how an effective software architecture must be turtles all the way down. In the end, we will all have gained deep insight to the value of agile architecture.

Modularity is coming to the Java platform! Java 8 will introduce the Jigsaw module system. OSGi is here today. Don’t wait to start designing modular software. Contrary to popular belief, you don't need a framework or a new runtime to start building modular software applications. You can start today. Learn how!

In this session, we'll examine what it means to develop modular software on the Java platform. We'll examine the goals and benefits of modular software, and explore the patterns of modular architecture that help us develop modular software systems. With just a few easy steps, we'll see how to transform our software from a huge monolith to an extensible system of collaborating software modules. By examining an existing software system, we'll see first hand how we can increase software modularity with minimal disruption. You'll walk away not just with a much deeper understanding of the benefits of modular software, but also a migration roadmap for refactoring existing applications to increase their modularity. In other words, you'll see how to get ready today for the application platform of tomorrow.

OSGi was once heralded as a contender for most important technology of the decade. Today, most developers have heard of OSGi, but few are using it to develop their enterprise software applications.Is OSGi failing? Who is using it? And what exactly are its benefits?

In this session, we'll explain the benefits of OSGi, and show that it's not just for the middleware vendor. We'll learn how you can use OSGi without making significant changes to how you write your software applications. We'll explore the OSGi ecosystem, including platforms that support OSGi. Through code examination, we'll see how the Spring framework allows us to leverage OSGi in a non-invasive way. We'll discover how OSGi encourages Polyglot programming on the Java platform. And we'll take a brief glimpse into the future of modularity on the Java platform. You'll walk away with a much better understanding of OSGi, its strengths and benefits, how to use it effectively, as well as the myths surrounding its use.

The modularity patterns provide us with proven design techniques to develop a modular software architecture that is extensible, reusable, maintainable, and adaptable. In this session, we’ll explore 9 of the 18 modularity patterns.

This session introduces and examines the following patterns:

• Manage Relationships
• Module Reuse
• Cohesive Modules
• Acyclic Relationships
• Levelize Modules
• Physical Layers
• Container Independence
• Independent Deployment
• Levelize Build

The modularity patterns provide us with proven design techniques to develop a modular software architecture that is extensible, reusable, maintainable, and adaptable. In this session, we’ll explore the remaining 9 modularity patterns.

This session introduces and examines the following patterns:

• Published Interface
• External Configuration
• Default Implementation
• Module Facade
• Abstract Modules
• Implementation Factory
• Separate Abstractions
• Colocate Exceptions
• Test Module

There is a good amount of excitement about the new version of Java. The big
evolution of course is the lambda expressions. In this presentation we will dive into the language features in Java 8, take a look at some of their nuances, and look at ways to put them to good use.

Java 8 language capabilities and application.

Invoke dynamic is a Java 7 feature that had the most impact at the bytecode level and also in terms of performance. First perceived as a feature to help dynamically typed languages on the JVM, it turned into a powerful feature that has been exploited quite a bit in the implementation of features in the Java
language itself.

In this presentation we will understand what problem this features really solves and how it has influenced other features in the Java language and on the Java platform.

After almost a decade and several significant releases, Spring has gone a long way from challenging the then-current Java standards to becoming the de facto enterprise standard itself. Although the Spring programming model continues to evolve, it still maintains backward compatibility with many of its earlier features and paradigms. Consequently, there's often more than one way to do anything in Spring. How do you know which way is the right way?

In this session, we'll explore several ways that Spring has changed over the years and look at the best approaches when working with the latest versions of Spring.

In this presentation, we'll see how to use Spring to create, secure, streamline, hyperlink, and consume REST APIs.

In modern applications, there are a diverse array of clients consuming content from the web. Each of these clients has unique capabilities and limitations, therefore demanding presentation of the application to be tailored to each device. As a result, presentation logic is often pushed into the client itself, leaving the application to serve a common data-oriented lightweight API to be consumed by each client.

In modern applications, Javascript is increasingly prevalent both on the client-side and to some degree on the server-side. As we continue to crank out more Javascript code, we're finding that many of the same hard-lessons we learned in writing decoupled Java code are equally desirable in Javascript code. Without the benefit of dependency injection and AOP, both Java and Javascript code can quickly become an unnavigable and untestable mess.

Where frameworks like Spring have helped us gain control over our Java code, Cujo.js similarly aims to give our Javascript code more structure and testability.

In this session, we'll look at Cujo.js, an “unframework” that provides dependency injection that takes Javascript's unique needs into consideration to create loosely-coupled code. We'll also see how, although Cujo.js isn't strictly a UI framework, elements of Cujo.js can be brought together to elegantly build client-side UIs.

So you think you've picked up enough JavaScript to be dangerous, but feel like the whole prototypical language thing is still a mystery. In this session, we'll go from basic JavaScript to advanced JavaScript. We'll discuss and code modular JavaScript with CommonJS. We'll look into the details of a prototype language and discuss things like parasitic inheritance. We'll also look at JavaScript libraries that will help you get the most out of JavaScript - not jQuery, but a library like UnderscoreJS and SugarJS.

This is a fast paced session meant to bring you up to speed with the latest and greatest JavaScript techniques and tools. Whether you're building client side JavaScript with HTML5 or Appcelerator Titanium, or server-side JavaScript with node.js, you'll come away with knowledge and patterns for how the pro's use JavaScript for building real apps.

We've come a long way down the JavaScript road. Gone are the days of 'just hack it' for the web - architecting even a small project in JavaScript can be a challenge. Thankfully, there are several frameworks to help you; the most popular currently is Backbone.js.

Before you start using a framework in JavaScript, you will want to understand the techniques expert JavaScript programmers use to build them. In this session, we'll dive into design patterns in JavaScript, and do live coding so you can see these patterns applied. Even if you're not using a framework, you can use these design patterns to make your code more maintainabile, elegant, and concise.

JavaScript has a mixed heritage: OO and Functional. To date, us developers have focused on the OO side of JavaScript and not much mind-share has been given to the other, more powerful side. In this session we'll explore how to use the power of functional Javascript.

JavaScript has elements of two distinct programming languages: Self and Scheme. These two languages are very different - and some of JavaScript's weirdness is due to this mixing of very different language designs. The conceptual models are also very different between Self and Scheme - one is a prototypical object based language, while the other is a functional language. In this session, we'll discuss the elements of how the Scheme functional programming language manifest in JavaScript. We're going to explore how you can write JavaScript in a more elegant and powerful way by applying functional concepts.

Ever wish you could use your JavaScript-foo to build a NATIVE mobile app? Wish there was an open-source platform that would let you build awesome cross-platform mobile apps? Come to this session and learn about Titanium, an open-source, JavaScript based platform for creating native mobile apps.

Titanium is an open-source development tool for producing cross-platform mobile applications by Appcelerator. Using Titanium, you develop your mobile application using Javascript coded against the Titanium API's. The Titanium platform invokes their builder to take your Javascript and build a native application for iOS and Android.

This session will walk you through the details of building great apps for the Android and iOS platforms. We'll talk about Titanium development, its ecosystem, and architecture. We'll spend time looking at lots of code - we'll build an app, in fact, while we discuss and explore the framework. We'll also spend some time discussing best practices, what to expect when developing against it, and the limits of this type of development.

Relational databases have ruled the world since the dawn of time (or so it appears). They power our enterprises and for many in the corporate world, it may be hard to imagine life without them. Each decade a novel idea would challenge the status quo and make a case to deviate for the tradition. A flock of enthusiastic programmers, like your humble speaker back in the early 90s, would throw their support around it, only to be crushed eventually by the large vendors and enterprise standards. But, the excitement around NoSQL has shown that enterprise data is not the only thing that's persistent.

In this presentation we'll learn how NoSQL deviates from those deep rooted traditional approaches, and how this may be useful. We will also discuss the situations where these types of databases may be more appropriate.

In this session, we're going to combine the magic of Spring Boot and the magic of Spring Data to yield something even more powerful. You'll see how to quickly build an application's persistence layer, whether it stores data in a RDBMS, Mongo, Neo4j, or several other popular data stores. You'll also see how to create a functioning REST API with nothing more than an interface and a domain type.

Spring Boot dramatically simplifies application development with Spring. But before Spring Boot came along, Spring Data was already making developers' lives easy when it comes to working with data. When combined, Spring Data and Spring Boot can make data persistence the easiest part of your application.

Getting software released to users is often a painful, risky, and time-consuming process. This workshop sets out the principles and technical practices that enable rapid, incremental delivery of high quality, valuable new functionality to users. Through automation of the build, deployment, and testing process, and improved collaboration between developers, testers and operations, delivery teams can get changes released in a matter of hours–sometimes even minutes–no matter what the size of a project or the complexity of its code base.

In this workshop we take the unique approach of moving from release back through testing to development practices, analyzing at each stage how to improve collaboration and increase feedback so as to make the delivery process as fast and efficient as possible. At the heart of the workshop is a pattern called the deployment pipeline, which involves the creation of a living system that models your organization's value stream for delivering software. We spend the first half of the workshop introducing this pattern, and discussing how to incrementally automate the build, test and deployment process, culminating in continuous deployment.

Getting software released to users is often a painful, risky, and time-consuming process. This workshop sets out the principles and technical practices that enable rapid, incremental delivery of high quality, valuable new functionality to users. Through automation of the build, deployment, and testing process, and improved collaboration between developers, testers and operations, delivery teams can get changes released in a matter of hours–sometimes even minutes–no matter what the size of a project or the complexity of its code base.

In this workshop we take the unique approach of moving from release back through testing to development practices, analyzing at each stage how to improve collaboration and increase feedback so as to make the delivery process as fast and efficient as possible. At the heart of the workshop is a pattern called the deployment pipeline, which involves the creation of a living system that models your organization's value stream for delivering software. We spend the first half of the workshop introducing this pattern, and discussing how to incrementally automate the build, test and deployment process, culminating in continuous deployment.

Getting software released to users is often a painful, risky, and time-consuming process. This workshop sets out the principles and technical practices that enable rapid, incremental delivery of high quality, valuable new functionality to users. Through automation of the build, deployment, and testing process, and improved collaboration between developers, testers and operations, delivery teams can get changes released in a matter of hours–sometimes even minutes–no matter what the size of a project or the complexity of its code base.

In the second half of the workshop, we introduce agile infrastructure, including the use of Puppet to automate the management of testing and production environments. We'll discuss automating data management, including migrations. Development practices that enable incremental development and delivery will be covered at length, including a discussion of why branching is inimical to continuous delivery, and how practices such as branch by abstraction and componentization provide superior alternatives that enable large and distributed teams to deliver incrementally.

Getting software released to users is often a painful, risky, and time-consuming process. This workshop sets out the principles and technical practices that enable rapid, incremental delivery of high quality, valuable new functionality to users. Through automation of the build, deployment, and testing process, and improved collaboration between developers, testers and operations, delivery teams can get changes released in a matter of hours–sometimes even minutes–no matter what the size of a project or the complexity of its code base.

In the second half of the workshop, we introduce agile infrastructure, including the use of Puppet to automate the management of testing and production environments. We'll discuss automating data management, including migrations. Development practices that enable incremental development and delivery will be covered at length, including a discussion of why branching is inimical to continuous delivery, and how practices such as branch by abstraction and componentization provide superior alternatives that enable large and distributed teams to deliver incrementally.

A Technology Radar is a tool that forces you to organize and think about near term future technology decisions, both for you and your company. This talk discusses using the radar for personal breadth development, architectural guidance, and governance.

ThoughtWorks Technical Advisory Board creates a “technology radar” twice a year, a working document that helps the company make decisions about interesting technologies and where we spend our time. ThoughtWorks then started conducting radar-building exercises for our clients, which provides a great medium for technologists company-wide to express their opinions about the technologies they use every day. For companies, creating a radar helps you document your technology decisions in a standard format, evaluate technology decisions in an actionable way, and create cross-silo discussions about suitable technology choices. This session describes the radar visualization and how to conduct a radar building session for yourself. After a brief introduction, the bulk of the workshop consists of attendees building a radar for the group, following the same procedure you'll use when you do this exercise at your company. At the end, we'll have created a unique Radar for this event and practiced doing it for yourself.

Robert Martin assembled the SOLID family of principles to provide a useful guide to help us create object-oriented software designs that were resilient in the face of change. In recent years, the need to write highly-concurrent software in order to leverage increasingly ubiquitous multicore architectures, as well as general interest in more effectively controlling complexity in large software designs, has driven a renewed interest in the functional programming paradigm. Given the apparent similarity in their goals, “What is the intersection of SOLID with functional programming?” is a natural question to ask.

In this talk, we'll explore this intersection. We'll begin with a tour of the evolutionary patterns associated with enterprise software and programming paradigms, as well as take a look at the ongoing quest for best practices, the goal being to elucidate the motivation for examining this intersection of SOLID and functional programming. We'll then walk through each of the SOLID principles, examining them in their original object-oriented context, and looking at example problems and solutions using the Java language. Then for each principle, we'll examine its possible intersection with the functional programming paradigm, and explore the same problems and solutions using the Clojure language. We'll close by examining the transcendent qualities of the SOLID principles and how they can make any design simpler, regardless of the programming paradigm employed.

For much of the last two years I've delivered a two-part series at NFJS shows entitled “Effective Java Reloaded.” For all pracical purposes, it is an ala carte style rehash of the book Effective Java, written by Josh Bloch. One of my favorite parts of the discussion is of Item #15, which tells us to “Minimize Mutability.” If we turn this inside out, we're actually saying that we want to MAXIMIZE IMMUTABILITY. When we do this, we reap many benefits, such as code that is easier to reason about and that is inherently thread-safe. This can carry us a long way in the direction of program correctness and decreased complexity. However, when we start to program with immutability, several major questions arise.

First, the necessity of using a separate object for each distinct value, never reusing, or “mutating” an object, can quickly cause performance concerns. These concerns are amplified when we're talking about large collections such as lists and maps. These problems are largely solved by what we call “persistent data structures.” Persistent data structures are collections from which we create new values, not by copying the entire data structure and apply changes, but by creating a new structure which contains our changes but points at the previous structure for those elements which have not changed. This allows us to work with data structures in a very performant way with respect to time and resource consumption. We'll examine persistent data structures, their associated algorithms, and implementations on the JVM such as those found in the TotallyLazy library.

Second, because all of an immutable object's state must be provided at the time of construction, the construction of large objects can become very tedious and error prone. We'll examine how the Builder pattern can be applied to ease the construction of large objects, and we'll examine Builder implementations in Java and Groovy.

Third, we run into problems when we start to use frameworks that expect us to program in a mutable style. A prime example is Hibernate, which expects our persistent classes to follow the well-worn JavaBean convention, including a no argument constructor and getters and setters for each property. Such a class can never be mutable! So how do we program with frameworks such as Hibernate and yet still minimize mutability? The key is found in not letting frameworks dictate the way that you design your code. Just because the framework require something, don't let it force you to make the wrong decision. Use the framework as a tool to write your code, don't let your code be a tool of the framework. We'll examine strategies for doing exactly that.

You should come away from this talk better equipped to program in a way that minimizes mutability and maximizes immutability.

Have you ever wished that your local development sandbox could look exactly like production, but you've got a mismatch between your local OS and your production OS? And what about the age old “it works on my machine” excuse that quite often stems from differences between developer sandboxes? Many have turned to virtualization, creating a machine image that can be passed around the team. But who manages the template? How do you keep things in sync?

In this session, we'll explore Vagrant (http://www.vagrantup.com), an open source tool that allows you to easily create and manage virtual development environments that can be provisioned on demand and “thrown away” when no longer needed.

Vagrant is most powerful when we think of it as a tool to enable various workflows that are useful to software development teams. In this talk, we'll walk through the following workflows and examine Vagrant's contributions:

• Software development/spike sandbox management
• New team member onboarding/development workstation management
• Managing production-like environments on developer workstations
• Managing disposable integration testing environments
• Managing production environments

The basics of developing for the Android platform will be explored, from setting up the SDK to using the Android Studio IDE and the generated Gradle build files. No previous experience is required, other than a basic knowledge of Java.

After discussing how Android fits into the marketplace, we'll look at creating applications, how to use activities, and working with layouts.

Building on the the previous talk, we'll add intents, customized layouts for alternative configurations, talk about the activity lifecycle, use logging, and more.

We'll deploy to both emulators and connected devices, and change input styles.

This is a revised and updated version of the previous talk, with current thinking from practice and the literature. The talk presents why conflicts with your manager are inevitable based on differences in priorities and perspectives, and how to plan for them. The goal is to show you how to build the loyalty relationship that allows you to get what you need when you need it.

Topics covered will include diagnosing communication styles, lessons from game theory, working within the organizational hierarchy, and lessons on how to build a relationship with your manager that still allows you the freedom to express yourself and what you really want.

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.

No matter where you slice software engineering:

• architecture
• technology selection
• process
• etc.

The root cause of many, if not most problems, is the common absence of critical thinking in how we approach decision making. Instead of thinking critically about our engineering decisions, we often follow a Cargo Cult mentality or blindly follow the pronouncements of the Blowhard Jamboree. The end results all too often include suboptimal productivity, excessive spending, poor quality and cancelled projects.

When we think instead critically about a component of software engineering, we take it apart. We discard our presuppositions. We challenge tradition. We gather our own evidence. We question everything.

This talk will examine the pathologies associated with not thinking critically, including a tour of the antipatterns that can emerge from such a practice. We'll then walk through the concentric circles of the critical thinking process, including evidence evaluation, argument evaluation, and argument construction. You'll leave this session with a critical thinking framework which can be applied to software engineering as well as beyond.

You're tasked with calling another system from your app. You have the code written, you're parsing the bytes from the wire. But are you done? I assert that there are four more things that you should seriously consider every time you talk to a remote system. These things protect your system, the systems you call and give visibility into your system, the systems you're calling and the network.

These concepts can be universally applied to any stack wherein you call out to another system that is not under your control but we'll use a simple Grails application as a basis for our examples. All the frameworks shown are available for use in other JVM languages.

It's tempting to see Scala features and assume they behave similarly to Java constructs you have used for the last 10 years. This talk is about getting the most out of Scala's idioms early on so you can get well on your way to being idiomatic.

This talk is for the practical engineer who has been doing Java for a while. You get stuff done and the ivory tower world of functional programming hasn't excited you quite yet.

We'll cover things that allow for more stateless and functional programming but the focus of this talk is not functional programming.

What happens when a team of traditional Java engineers decide to port a growing high-profile production system to Scala? By the title you can imagine it is a success but of course there's more to the story.

This talk will be a mix of lessons learned and a general lay of the land for what you can expect for your successful Scala project.

• How do you hire?
• What libraries do you use?
• What tooling is available?
• What contributes to the slow build times?
• What are the trade-offs with build tools?
• What are the best resources for learning?

The Spock framework brings simple, elegant testing to Java and Groovy projects. It integrates cleanly with JUnit, so Spock tests can be integrated as part of an existing test suite. Spock also includes an embedded mocking framework that can be used right away.

In this presentation, we'll look at several examples of Spock tests and review most of its capabilities, including mock objects and integration with Spring.

Groovy isn't designed to replace Java – it just makes Java cleaner and easier to develop. This presentation will look at various tasks Java developers need to do and demonstrate ways Groovy can help.

Topics will include building and testing applications, accessing both relational and NoSQL databases, working with web services, and more.

The enterprise today consists of tens, if not hundreds of applications, all designed to meet the needs of the business. These applications rarely live in a silo, and often there is a need to establish a communication protocol between these applications.

There are various approaches to integration, and in this talk we will discuss the pros and cons of each. We will then focus on one particular approach, and solution - Spring Integration brought to us by the folks at Spring Source. We will talk about both inter and intra application integration, and look at some of the ways we can leverage Spring Integration within the enterprise

Find yourself overwhelmed with hundreds of to-dos? Is your hard-drive littered with dozens of killer ideas that you started with enthusiasm and then just fizzled away? Do you feel like you are moving as fast as can but only getting to the wrong place quicker? Well perhaps this session will help.

There are various techniques and strategies available to us today that aim to help with exactly this conundrum - from Getting Things Done ™ to Personal Kanban. Unfortunately it is often easy to be extremely productive using these systems, but not very effective. After all, it's not about getting things done, but getting the RIGHT things done. In this talk we will discuss not only how to get things done, but also attempt to figure out what it is you actually need to be doing.

In this session, I will attempt to show you how you can leverage various strategies to be more effective, knock to-dos out and have fun while doing it. If time permits we will close with an overview of the tools that are available to you, and how you can use these to become a to-do list ninja :)

In this session we will look to see how we can refactor our learning - what tools, and methodologies can we use to help us learn quicker and better - how we can create a store that gives us quick access to information when we really need it.

We all work in an industry in which not only do the tools that we use change ever few years, but one in which we have to shift the very paradigms these tools are built on! Even the most trivial of projects entails tens of different toolkits, frameworks, and languages coming together, and somehow we need to know how to leverage each one. How does one keep up? Despite all our years in schools, and our in-born nature to learn, we often are never taught how to learn. How can we learn faster, and retain even more?

In this session we will take a look at various tools and techniques available to us and see how we can make our learning effective.

Clojure is a powerful dynamic language that compiles to many target environments, including the JVM, JavaScript, and the CLR. In this talk, you will learn how to think in Clojure, and why you should want to.

Clojure encourages functional style with persistent data structures, a rich library of pure functions, and powerful processing support via the seq and reducer abstractions. Clojure implements a reference model for state, where references represent atomic successions of values, and change is encapsulated by value and reference constructors. This reference model is more substantive and suitable to application development than individual techniques such as Software Transactional Memory (STM) or actors.

The most important single principle behind Clojure is simplicity. Clojure's abstractions are simple and orthogonal. A la carte polymorphism, careful support for names and namespaces, the reference succession model, and a wide selection of small, composable protocols make Clojure programming swift, surgical and accurate.

Clojure's expressiveness does not mean that you have to compromise on power. It is an explicit design goal of Clojure to provide access to the power of the underlying platform, and for programmers never to have to “drop down” to the platform level for performance-sensitive work.

On the Web

• Programming Clojure by Stuart Halloway and Aaron Bedra

Git is awesome, but it knows only text. Codeq extends git to analyze and understand quantum units of your code (codeqs), giving you the power of a database over your code.

Codeq imports your Git repositories into a Datomic database, then performs language-aware analysis on them, extending the Git model both down and up:

• down, from the textual world of files and lines to the code quantum (codeq) level
• up, across multiple repositories

This allows you to track change in terms of program units, e.g. function and method definitions, and query your code declaratively. A codeq database can serve as infrastructure for editors, IDEs, code browsing, analysis, and documentation tools.

In this talk, you will learn

• how to install codeq locally
• how to import and analyze git repositories
• how to query your repositories
• how to extend codeq's builtin analysis with your own custom analyzers

Codeq is open source (EPL), and on github. It works with Datomic Free.

On the Web

• Blog post introducing codeq
• Codeq on the Relevance Podcast

Statistics is hot lately, due in part to the easy availability of large data sets and the successes of people like Nate Silver. These aren't your father's statistics, however. A quiet revolution has swept through the field, shifting it from traditional frequentist methods toward a more Bayesian approach. This talk will discuss Bayes' Theorem and show you how to do simple, back-of-the-envelope calculations to apply it to a wide variety of problems.

In addition, we'll also talk about common errors non-experts make when dealing with statistical conclusions, ranging from small sample size issues to the use of arbitrary endpoints to the problem of overfitting and more.

The Gradle build tool is one of the most successful projects in the Groovy ecosystem because it addresses a difficult problem – every major build is a custom build. Gradle builds are written in Groovy, so the full power of the language is available if you need it. Gradle supports Maven project structure and repositories and uses Ivy dependency management without being bound by their normal constraints. With major systems like Grails, Hibernate, and the Spring Framework moving to Gradle, this is a technology worth taking the time to understand.

This talk will cover the basics of Gradle both through simple examples and by examining the build files for major open source projects.

Traditional automated testing approches combine input generation, execution, output capture, and validation inside the bodies of single functions. Generative testing approaches gain expressive power by isolating these steps.

With generative testing:

• a generator is a declarative description of possible inputs to a function
• execution is up to your program
• outputs are data, and can be captured for future study
• validators are programs that have access to the generators, the program, and the outputs

There are a number of benefits to this approach:

• once test data generation is separate, it is immediately obvious that such data generation should be statistical, not merely a few hand-picked cases
• validators can be reused in a variety of
• it becomes easier to identify and develop declarative, logic-based validations, rather than imperative ones
• the various phases can be decoupled and run at different times

This talk introduces test data generation and generative testing, using for its examples the data.generators and test.generative libraries developed by the author.

Resources

• test.generative
• data.generators
• chapter 10 of Programming Clojure

Simulation allows a rigorous, scalable, and reproducible approach to testing. The separation of concerns, and the use of a versioned, time-aware database, give simulation great power. This talk will introduce simulation testing, walking through a complete example using Simulant, an open-source simulation library.

Simulation allows a rigorous, scalable, and reproducible approach to testing:

Statistical modeling

Simulation begins with statistical models of the use of your system. This model includes facts such as “we have identified four customer profiles, each with different browsing and purchasing patterns” or “the analytics query for the management report must run every Wednesday afternoon.” Models are versioned and kept in a database.

Activity streams

The statistical models are used to create activity streams. Each agent in the system represents a human user or external process interacting with the system, and has its own timestamped stream of interactions. With a large number of agents, simulations can produce the highly concurrent activity expected in a large production system.

Distributed execution

Agents are scaled across as many machines as are necessary to both handle the simulation load, and give access to the system under test. The simulator coordinates time, playing through the activity streams for all the agents.

Result Capture

Every step of the simulation process, including modeling, activity stream generation, execution, and the code itself, is captured and stored in a database for further analysis. You will typically also capture whatever logs and metrics your system produces.

Validation

Since all phases of a simulation are kept in a database, validation can be performed at any time. This differs markedly from many approaches to testing, which require in-the-moment validation against the live system.

Separation of concerns

The separation of concerns above, and the use of a versioned, time-aware database, gives simulation great power. Imagine that you get a bug report from the field, and you realize that the bug corresponds to a corner case that you failed to consider. With a simulation-based approach, you can write a new validation for the corner case, and run that validation against your past simulation results, without ever running your actual system.

This talk will introduce simulation testing, walking through a complete example using Simulant, an open-source simulation library.

Ever get a bad URL, dubious credentials and out dated documentation with the expectation that you will productively consume a service in your application? Before you start coding in your production stack there are reasons to use simple tools to poke around a new API. We'll cover the best tools for the job some you know and others you might not.

Besides investigating a service before you write code the outcome of that exercise also pays dividends at different points in the project. The artifacts from this discovery process also come in handy when problem solving production issues. When you get the pieces in place you end up with something that feels a lot like unit tests but for the operational monitoring of the production systems you depend on.

The word just came down from the VP - you need a mobile app and you need it yesterday. Wait, you've never built a mobile app…it's pretty much the same thing as you've built before just smaller right? Wrong. The mobile experience is different and far less forgiving. How do you design an application for touch? How does that differ from a mouse? Should you build a mobile app or a mobile web site? This talk will get you started on designing for a new, and exciting, platform. Whether that means iPhone, Android, Windows Phone or something else, you need a plan, this talk will help.

The word just came down from the VP - you need a mobile app and you need it yesterday. Wait, you've never built a mobile app…it's pretty much the same thing as you've built before just smaller right? Wrong. The mobile experience is different and far less forgiving. How do you design an application for touch? How does that differ from a mouse? Should you build a mobile app or a mobile web site? This talk will get you started on designing for a new, and exciting, platform. Whether that means iPhone, Android, Windows Phone or something else, you need a plan, this talk will help.

The word just came down from the VP - you need a mobile app and you need it yesterday. Wait, you've never built a mobile app…it's pretty much the same thing as you've built before just smaller right? Wrong. The mobile experience is different and far less forgiving. How do you design an application for touch? How does that differ from a mouse? Should you build a mobile app or a mobile web site? This talk will get you started on designing for a new, and exciting, platform. Whether that means iPhone, Android, Windows Phone or something else, you need a plan, this talk will help.

The word just came down from the VP - you need a mobile app and you need it yesterday. Wait, you've never built a mobile app…it's pretty much the same thing as you've built before just smaller right? Wrong. The mobile experience is different and far less forgiving. How do you design an application for touch? How does that differ from a mouse? Should you build a mobile app or a mobile web site? This talk will get you started on designing for a new, and exciting, platform. Whether that means iPhone, Android, Windows Phone or something else, you need a plan, this talk will help.

You may have noticed today's web applications involve more than a few lines of JavaScript. You've probably also figured out JavaScript lacks certain…features…that make writing non-trivial applications more challenging. How do we resolve this conundrum? Luckily for us, we can leverage libraries like Backbone add some structure to our code. Backbone brings the concepts of the model view controller pattern we've applied to the server for years to the browser.

In this workshop, we'll introduce the idea of asynchronous user interfaces and show how Backbone helps us write that style of application. We'll work our way up from the bottom building a simple application along the way. We'll create models, we'll use a templating library (or two) and we'll also explore Underscore - a JavaScript utility belt you can use right now today without committing to building MVC style web applications.

If you're struggling to manage an increasing amount of JavaScript or you want to build more responsive web applications, this workshop can help!

Workshop Requirements

For this workshop you should have:

• Laptop
• Text editor or IDE
• One or more “modern” (Chrome, Safari, etc) browser

Optionally, you can have Git installed but it isn't required. Before the workshop, take a minute to setup the code somewhere on your laptop. The code is on github:

https://github.com/ntschutta/backbone_workshop

You can clone the repo from there or simply download a zip if you prefer. That's it! See you in Florida!

You may have noticed today's web applications involve more than a few lines of JavaScript. You've probably also figured out JavaScript lacks certain…features…that make writing non-trivial applications more challenging. How do we resolve this conundrum? Luckily for us, we can leverage libraries like Backbone add some structure to our code. Backbone brings the concepts of the model view controller pattern we've applied to the server for years to the browser.

In this workshop, we'll introduce the idea of asynchronous user interfaces and show how Backbone helps us write that style of application. We'll work our way up from the bottom building a simple application along the way. We'll create models, we'll use a templating library (or two) and we'll also explore Underscore - a JavaScript utility belt you can use right now today without committing to building MVC style web applications.

If you're struggling to manage an increasing amount of JavaScript or you want to build more responsive web applications, this workshop can help!

Workshop Requirements

For this workshop you should have:

• Laptop
• Text editor or IDE
• One or more “modern” (Chrome, Safari, etc) browser

Optionally, you can have Git installed but it isn't required. Before the workshop, take a minute to setup the code somewhere on your laptop. The code is on github:

https://github.com/ntschutta/backbone_workshop

You can clone the repo from there or simply download a zip if you prefer. That's it! See you in Florida!

Languages offer a lot more than syntax and compilers. They often have supporting libraries and special facilities that set them apart from other languages. Some languages offer special compiler support for a particular construct, like tail call optimization, for example. Others provide interesting library support or capabilities.

In this presentation we will dive into 12 cool things we can do with different languages on the JVM, things that are either impossible or hard to do in Java, but are quite easy and useful to realize in other popular languages on the JVM. If mixing these languages is an option on your projects, you'll have dozen more reasons after this presentation.

Format: Combination of presentation and hands-on exercises

Synopsis: Introduction to the Git DVCS (Distributed Version Control System) Participants should bring a Windows or Mac laptop to use during the workshop exercises.

Notes:
1) Choose a Windows, Linux, or Mac laptop that you'll be bringing to the workshop (we have some downloads and installs that are better to do before the event). Ensure you have admin or sudo privileges on the machine.
2) If possible, please have Git installed prior to attending the workshop. There's no need to “configure it” beyond the basic install. Installation instructions can be found via operating-system specific pages at:
http://help.github.com/win-git-installation/
http://help.github.com/mac-git-installation/
http://help.github.com/linux-git-installation/
3) Test your git setup is working by running git --version at your terminal prompt on Mac or Linux or at your “Git Bash Prompt” on Windows. Verify the output says Git is version 1.7 or higher.
.

Topics covered:
· What Git is
· How it differs from traditional centralized source control systems
· Local user configurations
· The git “promotion model”
· Local repositories
· Basic source control operations
· Branching and merging
· Interfacing with remote (server-side) repositories

Prerequisites:
No previous knowledge of GIT is assumed or required.

Format: Combination of presentation and hands-on exercises

Synopsis: Introduction to the Git DVCS (Distributed Version Control System) Participants should bring a Windows or Mac laptop to use during the workshop exercises.

Notes:
1) Choose a Windows, Linux, or Mac laptop that you'll be bringing to the workshop (we have some downloads and installs that are better to do before the event). Ensure you have admin or sudo privileges on the machine.
2) If possible, please have Git installed prior to attending the workshop. There's no need to “configure it” beyond the basic install. Installation instructions can be found via operating-system specific pages at:
http://help.github.com/win-git-installation/
http://help.github.com/mac-git-installation/
http://help.github.com/linux-git-installation/
3) Test your git setup is working by running git --version at your terminal prompt on Mac or Linux or at your “Git Bash Prompt” on Windows. Verify the output says Git is version 1.7 or higher.
.

Topics covered:
· What Git is
· How it differs from traditional centralized source control systems
· Local user configurations
· The git “promotion model”
· Local repositories
· Basic source control operations
· Branching and merging
· Interfacing with remote (server-side) repositories

Prerequisites:
No previous knowledge of GIT is assumed or required.

Git, at it's core, leverages a relatively simple data structure to maintain history. In this session we will take a look at this data-structure, which in turn will give us a better view of how Git manages history, and how better to work with it. NOTE: This is NOT an introduction to Git. This session assumes familiarity with Git concepts such as init, add, commit and merge.

Git has fast emerged as one of the leaders in DVCS. Git may seem arcane, but under the covers, leverages a very simple data-structure to store your version history. As developers, it has always serves us well to know how things fundamentally work, and Git is no different. In this talk we will explore this data-structure, and how the various commands you invoke against Git mutate it.

When I got into Java I had a “Wow, look how easy it is to implement these patterns.” When I got into Groovy, I had the same reaction, but only better. The dynamic nature of Groovy makes it easier to implement some common patterns. What's better, there are some patterns that you can exploit in Groovy that are not so easy in Java. In this section, you will learn how to implement some traditional patters in Groovy, and also other patterns you are simply not used to in Java.

This presentation will go far beyond the Gang-of-four (GOF) patterns. You will learn how to implement some GOF patterns, but also some patterns that will allow you to exploit dynamic nature of Groovy and the elegance of Groovy closures.

Programming concurrency has turned into a herculean task. I call the traditional approach as the synchronized and suffer model. Fortunately, there are other approaches to concurrency and you can reach out to those directly from your Java code.

In this presentation we will discuss the actor based concurrency and also the software transaction memory. We will then develop examples using AKKA and compare the power of these approaches in contrast to the traditional approach.

In recent years, the cloud has gone from Larry Ellison's “Maybe I'm an idiot, but I have no idea what anyone is talking about,” to Microsoft's “TO THE CLOUD!” to a central part of many companies IT strategy. At the same time, the way that we consume the cloud has continued to evolve. Many of today's cloud efforts revolve around utilization of various “infrastructure as code” products (e.g. Puppet and Chef) and homegrown automation to create deployment pipelines. When we start at this level, we often end up reinventing many of the same wheels as we climb the abstraction ladder.

Platform as a Service (PaaS) offerings are positioned to allow developers (and operators) to start climbing the abstraction ladder from a higher rung, shifting the model from machine-centric deployment to application-centric deployment. This session will focus on life as an application developer using Cloud Foundry as a PaaS, with demos using Pivotal's Hosted CF at http://run.pivotal.io.

We'll cover the following topics:

• Hello World: Pushing Java, Ruby, and Node.js apps
• Service Binding: Talking to DB's and other services
• Buildpacks: Flexible application runtime stacks
• “Places to Put Your Stuff”: organizations and spaces
• Promotion Pipelines: Dev to Test to Prod
• Scaling: From 1 instance to 100 instances in 30 seconds or less!
• Health Manager: No more 2 AM support calls…
• Blue-Green Deployments: Zero downtime for your users
• Deploying Cloud Foundry in YOUR data center
• It's Open Source and YOU can contribute!

Workshop Requirements

All parts will require:

• Git (“brew install git”)
• Your favorite Java editor (Eclipse, IntelliJ IDEA, Netbeans)
• The Cloud Foundry CLI - download the latest!

Needless to say you'll need a laptop! For best experience, a Mac or Linux environment is ideal (it's technically possible to get most of this working on Windows, but it's VERY DIFFICULT). Also, you'll need at least 8 GB of RAM to support running Cloud Foundry locally without too much of a performance hit.

Part one of the workshop will require a free account on Pivotal Web Services. You can create a 60-day trial with no credit card at https://run.pivotal.io.

Parts two and four will require the use of BOSH Lite. More instructions will be provided at the conference. But, to ease setup, please install the following dependencies (in addition to those for part one!):

• Virtualbox
• Vagrant
• Ruby 1.9.3 (rbenv or RVM are great options!)
• The BOSH CLI Ruby Gem (after installing Ruby via one of the version managers, “gem install bosh_cli” will do the trick)
• Spiff

An alternative to setting up BOSH Lite if you have trouble with the environment (or you are stuck on Windows!) is to use TryCF. This only requires an AWS account (obviously a credit card required) and an email address, and eliminates the need for this entire dependency list. The estimated cost is 28 cents per hour, so you won't run up a huge bill!

Part Three will require the use of a FREE Cloudbees account. Create one at https://grandcentral.cloudbees.com. Once you're set up, click on “Get Started with Builds” to provision your Jenkins instance. We'll complete the remainder of the setup during the lab, but it's important to get the Jenkins instance provisioned in advance so that you don't lose 10 minutes of workshop time!

It will also require the use of a FREE TRIAL account of Artifactory Online from JFrog. You can obtain an account at https://www.jfrog.com/registration/registration.html. This one is a bit quicker, but you still should try to create it before the workshop.