Winston Churchill famously said, “First we shape our buildings, and afterwards, our buildings shape us.” He was talking about the reconstruction of the House of Parliament, which was damaged in a bombing raid in World War II. There was a debate about how to shape the chamber to best accommodate the deliberative activity of the body that met in it. Churchill was talking about buildings, but it turns out his insight is a very general one indeed.

Developers are constantly debating their choices of language, platform, editor, methodology, and even where to put the curly braces. The robust internal dialog in community is a healthy thing, but our debates are often focused on the wrong topics. Have you ever compared languages by performance benchmarks? Platforms by alleged claims of developer productivity? Methodologies by feature velocity? There is a very good chance you're doing it wrong.

Rather than focus on the material content of our debates—language performance, editor productivity, methodological velocity—we should take Churchill's advice and think about the form of our choices. How will our choice of language influence the way we solve future problems? What assumptions does our methodology make about the nature of work? How will our choice of database affect the kinds of problems we think of as solvable?

Drawing on lessons from building architecture, literature, music, the visual arts, and even software itself, we'll learn the priority of interpreting the form of things before attempting to understand their content. You may never look at software architecture the same way again.

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. This workshop focuses on the Deployment Pipeline concept from Continuous Delivery.

In this workshop I move 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. I 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. This workshop focuses on the agile infrastructure required to implement a deployment pipeline and continuous delivery.

In this workshop, I introduce agile infrastructure, including the use of Puppet to automate the management of testing and production environments. We 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.

JavaScript is one of those very powerful languages that is often misunderstood and underutilized. It's quite popular, yet there's so much more we can do with it.

In this presentation we'll deep dive into the capabilities and strengths of this prominent language of the web.

Programmers often complain that it is hard to automate unit and acceptance tests for JavaScript. Testability is a design issue and with some discipline and careful design we can realize good
automated tests.

In this presentation we'll learn how to automate the testing of JavaScript using both TDD and BDD tools.

Whether you are just getting started, or you’ve made an attempt and well… it could be better… a lot better, this session is for you. Ken has been working on Agile projects as a coach and mentor for a number of years. Come discover the common reasons teams fail to get it right. Bring your own challenges and lets discuss. This is set to be an engaging and illuminating discussion.

This can be a dynamic discussion where challenges facing attendees may have us to focus on some areas and tips of agile development. We will certainly talk about how team or management choices to deviate from core agile practices add risk to a project with suggestions on how to resolve many of these challenges.

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.

Learning the syntax of a new language is easy, but learning to think under a different paradigm is hard.

Learning the syntax of a new language is easy, but learning
to think under a different paradigm is hard. This session
helps you transition from a Java writing imperative programmer to a
functional programmer, using Java, Clojure and Scala for
examples. This session takes common
topics from imperative languages and looks at alternative ways of
solving those problems in functional languages. As a Java developer, you know how to achieve code-reuse
via mechanisms like inheritance and polymorphism. Code reuse is
possible in functional languages as well, using high-order
functions, composition, and multi-methods. I show examples from my book Functional Thinking of shifting your perspective on problems, ceding messy details to the language, working smarter, not harder, and how to deal with multiparadigm languages.

Scala is a statically typed, fully OO, hybrid functional language that provides
highly expressive syntax on the JVM. It is great for pattern matching,
concurrency, and simply writing concise code for everyday tasks. If you're a
Java programmer intrigued by this language and are interested in exploring
further, this section is for you.

We will go through a rapid overview of the language, look at its key strengths and capabilities, and see how you can use this language for your day-to-day programming. This session will be coding intensive, so be ready for some serious Scala syntax and idioms.

Actor based concurrency was popularized by languages like Erlang and Scala. This model of programming provides isolated mutability (as opposed to shared mutability) and easy way implement coordinating processes or tasks. Actors can be local to a JVM, or distributed across VMs and machines. In this presentation we will learn how to use Akka Actors to design and implement distributed concurrent Java applications.

Developing a rich user interface for web applications is both exciting and challenging. HTML 5 has closed the gaps and once again brought new vibe into programming the web tier. Come to this session to learn how you can make use of HTML 5 to create stellar applications.

Workshop Requirements

Attendees are expected to pair up and work on the labs. Software requirements:

Latest version of your favorite browser (suggest having at least two different browsers, for example from Firefox, Chrome, Safari,…) so you can see the difference in support and program to it.

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!

*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)

When it comes to cross cutting software concerns, we expect to have or build a common framework or utility to solve this problem. This concept is represented well in the Java world with the loj4j framework, which abstracts the concern of logging, where it logs and the management of logging. The one cross cutting software concern which seems for most applications to be piecemeal is that of security. Security concerns include certification generation, SSL, protection from SQL Injection, protection from XSS, user authorization and authentication. Each of these separate concerns tend to have there own standards and libraries and leaves it as an exercise for the development team to cobble together a solution which includes multiple needs…. until now… Enterprise Security API library from OWASP.

This session will look at a number of security concerns and how the ESAPI library provides a unified solution for security. This includes authorization, authentication of services, encoding, encrypting, and validation. This session will discuss a number of issues which can be solved through standardizing on the open source Enterprise Security API.

Learn how to add Neo4j to your projects to add social, recommendation and other graph based capabilities to your applications.

We'll start by introducing the strengths, weaknesses and common use cases for neo4j. We'll then look at how to write effective graph based queries - directly or using Spring Data.

What's the point attending a conference unless you do something with the knowledge you gain?

In this session we look at practical strategies for selecting new technologies and proven approaches for driving adoption back at the office.

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.

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.

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.

Alternative databases continue to establish their role in the technology stack of the future—and for many, the technology stack of the present. Making mature engineering decisions about when to adopt new products is not easy, and requires that we learn about them both from an abstract perspective and from a very concrete one as well. If you are going to recommend a NoSQL database for a new project, you're going to have to look at code.

In this talk, we'll examine three important contenders in the NoSQL space: Cassandra, MongoDB, and Neo4J. We'll review their data models, scaling paradigms, and query idioms. Most importantly, we'll work through the exercise of modeling a real-world problem with each database, and look at the code and queries we'd use to implement real product features. Come to this session for a thorough and thoroughly practical smackdown between three important NoSQL products.

Want to go deep on a popular NoSQL database? Cassandra is a scalable, highly available, column-oriented data store in use at Netflix, Twitter, Reddit, Rackspace, and other web-scale operations. It offers a compelling combination of a rich data model, a robust deployment track record, and a sound architecture, making it a good choice of NoSQL databases to study first.

In this session, we'll talk about Cassandra's data model, look at its query idioms, talk about how to deploy it, and look at use cases in which it is an appropriate data storage solution. We'll study its origins in the Amazon Dynamo project and Google's BigTable, and learn how its architecture helps us achieve the gold standard of scalability: horizontal scalability on commodity hardware. You'll leave prepared to begin experimenting with Cassandra immediately and planning its adoption in your next project.

Successful projects require any number of practices but if you don't know who you're building it for or what you're supposed to build, failure is a distinct possibility. How do we capture the who and what? Personas and story maps are two effective techniques that you can leverage. After discussing the basics, we'll break into small groups and you'll have a chance to actually try building a set of personas as well as a story map.

Personas are a time tested technique to help teams understand their users and facilitate building the right interface. While personas are often backed by extensive ethnographic research, they don't require months and months of effort.

Of course just knowing who we're building for is only part of the picture, we have to know what our users are trying to do. Wether you favor use cases, user stories or more traditional requirements documents, at the end of the day our customers are using our application to further some other goal.

Like it or not, with application servers like node.js and increasingly rich client MVC frameworks like backbone.js, Javascript is in your future.

In this session we'll look deeply at the fundamental strengths and weaknesses of the language and how to become a javascript professional. We'll include information on using Jasmine for testing your Javascript.

You're all over jQuery - you write plugins in your sleep - and before that, you were a Prototype ninja. Your team treats JavaScript like a first class citizen, you've even written more tests than Kent Beck. Is that all there is in the land of the JavaScript developer? Believe it or not, the JavaScript party hasn't stopped. What other libraries are out there? What do they offer? This talk will survey the field of modern JavaScript libraries getting you up to speed on what's new. We'll dive in just deep enough to whet your appetite on a wide variety of libraries such as Backbone, Underscore, Zepto and more.

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.

It's been ages since you copied random JavaScript off a nameless webpage and your JavaScript is every bit as elegant as any server side code. You know the ins and outs of jQuery and you've even built a plugin or three…but is that it? How do we build rich web applications without resorting to heavy weight proprietary components? How do we leverage HTML5 and everything it brings to the table? How do we craft elegant user experiences that integrate fully with the RESTful web services that are all the rage on the backend? How do we build apps that are at home on a 3.5 inch phone as they are on the 15 inch notebook? This talk goes beyond jQuery to explore new libraries like Backbone are bringing even more to the front end developer's toolbox.

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.

Mutability is something we're quite used to in Java. Sharing is a good thing. However, shared mutability is pure devil's work. If we remove shared mutability, all the problems of concurrent go away. In practice, however, it's hard to completely get rid of shared mutability. This is where STM comes in with managed shared mutable variables. In this presentation we will take an example driven approach to dive deep into STM, look at what it has to offer, explore different implementations, and how we can design concurrent applications without any explicit locks.

Emergent design is a big topic in the agile architecture and design community. This session covers the theory behind emergent design and shows examples of how you can implement this important concept.

This session describes the current thinking about emergent design, discovering design in code. The hazard of Big Design Up Front in software is that you don't yet know what you don't know, and design decisions made too early are just speculations without facts. Emergent design techniques allow you to wait until the last responsible moment to make design decisions. This talk covers four areas: emergent design enablers, battling things that make emergent design hard, finding idiomatic patterns, and how to leverage the patterns you find. It includes both proactive (test-driven development) and reactive (refactoring, metrics, visualizations, tests) approaches to discovering design, and discusses the use of custom attributes, DSLs, and other techniques for utilizing them. The goal of this talk is to provide nomenclature, strategies, and techniques for allowing design to emerge from projects as they proceed, keeping you code in sync with the problem domain. This talk shows lots of examples of how to make this concept work in your environment.

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

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.

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.

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.

For a long while, we've built applications pretty much the same way. Regardless of the frameworks (or even languages and platforms) employed, we've packaged up our web application, deployed it to a server somewhere, and asked our users to point their web browser at it.

But now we're seeing a shift in not only how applications are deployed, but also in how they're consumed. The cost and hassle of setting up dedicated servers is driving more applications into the cloud. Meanwhile, our users are on-the-go more than ever, consuming applications from their mobile devices more often than a traditional desktop browser. And even the desktop user is expecting a more interactive experience than is offered by simple page-based HTML sites.

With this shift comes new programming models and frameworks. It also involves a shift in how we think about our application design. Standing up a simple HTML-based application is no longer good enough.

In this session, we'll discuss what the next generation of applications looks like, exploring such things as the mobile web and cloud computing. We'll also dig into some of the technologies and practices such as REST, OAuth, and JavaScript microframeworks that enable us to move forward.

In this session, we'll look at OAuth, focusing on OAuth 2, from the perspective of an application that consumes an OAuth-secured API as well as see how to use OAuth to secure your own APIs.

Web security is nothing new. As users of the web, we're all accustomed to entering our usernames and fumbling to recall our passwords when trying to access private data on one of the many online services we use. But while traditionally web security could be described as a two-party process between a web application and a user, the modern web involves applications that seek to access other applications on behalf of their users. This presents some new challenges in keeping a user's sensitive data secure while still allowing a the third party application to access it.

OAuth is an open standard for authorization, supported by many online services, that allows one application to access a user's data in another application, all while giving the user control of what information is shared.

Ratpack is a hyper-lightweight, Groovy-based web framework for developing and deploying simple apps in a hurry. Like its high-achieving cousin Gaelyk, it provides Groovy developers with a way to create web apps without days of iteration zero setup time.

In this talk, we'll look over Ratpack's very simple structure and live-code a small, practical example application. We'll look at how to evolve simple controller logic, how to manage templates, how to persist data, and how to deploy Ratpack applications to the web. The Java world needs ways to build small applications in a hurry, and Ratpack is the latest way to do it!

Gradle is a compelling new build tool that incorporates the lessons learned from a decade of Ant and Maven. More than just a compromise between declarative and imperative build formats, or between convention and configuration, Gradle is a sophisticated software development platform that simple builds easy and complex, highly automated continuous software delivery pipelines possible to build. Using its extensible APIs and expressive DSL, you're equipped to build your next build.

Bring your laptop to this session for the following:

Build a Java project
Resolve transitive dependencies
Run unit tests
Build a Groovy project
Create multi-project, polyglot builds
Wrap your build with a repeatable version of Gradle
Extend Gradle with custom tasks
See the plugin architecture

This presentation covers the Guava library developed by Google (http://code.google.com/p/guava-libraries/). Guava provides collection extensions to the Java Collection API and, along with this, a cornucopia of time-saving utilities that bring Java as close as possible to some of the more functional and dynamic language competitors like Scala, Ruby, and Clojure.

This presentation focuses on the following topics: how to make Predicates and Functions; how to use new collection constructs that make life easier, including MultiMap, BiMaps, and MultiSets; how to set up and use Guava preconditions; and how to create truly immutable collections, and more. All of this is done with Java.

Time is very precious and is often threatened by phone calls, emails, co-workers, bosses, and most of all, yourself. The Pomodoro Technique reigns in unfocused time and gives your work the urgency and the attention it needs, and it's done with a kitchen timer.

In this presentation we discuss how to set up, estimate time, log time, deal with interruptions, and integrate with Agile as a team. We discuss timer software and even some of the great health benefits of the Pomodoro Technique.

JodaTime is Java Date/Time and Calendering done right. There are many problems with the original Date/Time API that came prepackaged in the early Java days. There are even
One of the obvious issues is that Calendar is mutable and can unintentionally be changed. Another issue is that constructing Calendars in Java involves setting certain fields at certain times during coding, but not always getting the expected result. Joda Time repairs those issues and offers a robust and immutable date, time, and duration API.

In Joda Time and a Brief History of the World, I provide a quick rundown of calendaring throughout the centuries, describe UTC, compare UTC to GMT, discuss how time is calculated, and then dive into Joda Time in every popular JVM language. The end result provides the audience with compelling proof that Joda Time should always be their Date Time API of choice.

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.

Build web applications that support both Java and Groovy. This talk reviews many ways that Groovy makes it easy to build web applications, from basic groovlets, to simple frameworks like RatPack, to the major combination of Spring and Hibernate that is Grails.

Groovy supports web development in many ways. Groovylets are built into the language, and support template-based views. RatPack is a “routing” framework similar to Sinatra from the Ruby world. Grails, one of the “killer apps” for Groovy, combines Spring and Hibernate in a plugin-based, convention-over-configuration framework that makes creating sophisticated web applications easy. In this talk, we'll review them all.

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.

In this talk, we will explore decision making pathologies and their remedies in individual, team, and organizational dimensions. We'll consider how our own cognitive limitations can lead us to to make bad decisions as individuals, and what we might do to compensate for those personal weaknesses. We'll learn how a team can fall into decisionmaking dysfunction, and what techniques a leader might employ to healthy functioning to an afflicted group. We'll also look at how organizational structure and culture can discourage quality decision making, and what leaders to swim against the tide.

Software teams spend a great deal of time making decisions that place enormous amounts of capital on the line. Team members and leaders owe it to themselves to learn how to make them well.

Today’s interconnected world requires that organizations rapidly deliver flexible-integrated solutions. The conventional approach is to integrate heterogeneous applications using web services but unfortunately that tends to tightly couple those applications. In this session we will explore several alternatives for achieving Enterprise Integration Agility.

Public Web APIs are increasing at an exponential rate resulting in an ever more connected web. This connected contagion is not just relegated to the domain of Web 2.0 but has infected the corporate world. In fact, companies are becoming more reliant on Software as a Service (SAAS) to provide key business functions.

Combating this contagion requires an approach that provides a type of insurance against constant change and lays the foundation for evergreen enterprise solutions. In this session we will explore three popular architectural styles including Message Oriented, Service Oriented, and Resource Oriented Architecture that are used to achieve Enterprise Integration Agility. In addition, I will provide examples of each architectural style using ActiveMQ/Camel, Mule ESB, and NetKernel.

In this RESTful Imaginarium you will learn about about the core concepts of REST demonstrated through leading RESTful web service frameworks, Jersey (JAX-RS), Restlet, Spring MVC and NetKernel. During this daydream you will learn about the fallacies of URL parameters, the debate of PUT vs. POST and the power of HATEOAS.

RESTful web services have become the preferred approach to synchronously integrate heterogeneous systems. The REST Architectural Style’s success is due in large part to its simplicity and the fact that it is based based on a small set of widely accepted standards, such as HTTP. Furthermore REST requires far fewer development steps, toolkits and execution engines than conventional SOAP web services.

This session covers the core concepts of REST and then walks through how to design and implement RESTful web services using leading RESTful web service frameworks, Jersey (JAX-RS), Restlet, Spring MVC and NetKernel.

With NoSQL data stores you need to completely rethink how to model your data.

In this session we'll look at the very different approaches to data modeling required for MongoDB and Neo4j.

Of all the non-functional requirements of software development, complexity receives the least attention and seems to be the most important from a long term standard point. This talk will look at some of forces that drive complexity at the code level and at a system level and their impact. We will discuss what causes us to over look complexity, how our perception of it changes over time and what we can do about it?

In this session we will break down the meaning of complexity and simplicity and measure the application of those means against the common software development dogma. Looking at common development trends and pressures, we'll discuss where simplify does and doesn't help. We will examine areas of development which at first glance seem to be simple (such as the creation of an equals method in Java), that end up being difficult or impossible based on normal constraints. We will example the drivers of complexity with some discussion on what you can do about it. This session will finish with a discussion around several challenges to high scale software architectures and how to keep it simple.

Intuit and even the US government want to be “lean startups”.

Learn how businesses of any size can improve the effectiveness and efficiency of their software development processes using lean startup principles like Minimum Viable Product, Validated Learning and Metrics Driven Development.

For decades object-oriented programming has been sold (perhaps over sold) as the logical programming paradigm which provides “the way” to software reuse and reductions in the cost of software maintenance as if it comes for free with the simple selection of the an OO language. Even with the renewed interests in functional languages, the majority of development shops are predominately using object-oriented languages such as Java, C#, and Ruby. So most likely you are using an OO language… How is that reuse thing going? Is your organization realizing all the promises? Even as a former Rational Instructor of OOAD and a long time practitioner, I find great value in returning to the basics. This session is a return to object-oriented basics.

This session is intended to balance the often-touted theoretical object-oriented practices with lessons from the real world. The session will start with a review of some of the basics regarding abstractions and encapsulation. Although simple concepts, we will push the boundary of how these techniques are applied. We will discuss the difference between analysis and design and how that is reflected in our code. We will also look at the limitations of Java the language as outlined in Josh Block’s book “Effective Java”. The session will go past the basics of object-oriented principles and into what our true goals of development really are.

The agile focus of software development puts heavy focus on user requirements through user stories. However we can not lose sight of the non-functional requirements as well. The software could be written to the exact specification and desire of the user, however if it takes 5 minutes for a request response, or it only supports 2 users or it isn't secure, then we still haven't done our jobs as developers.

This session will focus on the non-functional requirements of software development, namely: Performance, Scalability, Security, and Software Monitoring and Management. Each subject area discussion will include, goals, design practices, tools, and where it fits in the software development life-cycle.

One of the hallmarks of lean software development is the elimination of waste. Several of the key wastes in software development revolve around incomplete, incorrect, or obsolete documentation, especially documentation of requirements. One effective means of ensuring that your requirements documentation is complete, correct, and up-to-date is to make it executable. That sounds nice, but how do we get it done, especially in the world of modern, cross-browser web applications?

Executable web application specifications are within your reach through the combination of Spock, a testing and specification framework written for the JVM in Groovy, and Geb, an elegant Groovy wrapper around the powerful WebDriver browser automation framework. In this session we'll take a close look at Spock specifications for describing and verifying the behavior of our applications. We'll then examine how we can use Geb's implementation of the Page Object pattern and its “jQuery-ish” API for interacting with our web applications in WebDriver's range of supported browsers. Finally, by gluing these two technologies together via Geb's Spock integration, we'll automate the requirements specification for a simple web app.

Greater Wisconsin Software Symposium

February 24 - 25, 2012

Workshop Requirements

Workshop Requirements

TEST