Matt Stine

Cloud Foundry Deep Dive, Part 1: The Developer Experience

11:00 AM MDT

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!

Vagrant: Virtualized Development Environments Made Simple

1:30 PM MDT

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

Critical Thinking in Software Engineering, Part I: Lecture

3:15 PM MDT

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.

Critical Thinking in Software Engineering, Part II: Katas

5:00 PM MDT

Now that you've completed the “Critical Thinking in Software Engineering” lecture, it's time to put your new skills to work. In this session, we'll break up into teams. Each team will be presented with either an argument to evaluate or a problem situation for which you must construct an argument advocating a particular course of action.

Teams will then be responsible for presenting their evaluations and arguments to the group, and the group as a whole will evaluate the presentations.

Topics to include:

• Pair Programming Doesn't Work
• Craftsmanship: Friend or Foe?
• The Code IS the Design
• Rap Genius v. Heroku
• Containers and the Cloud
• Good Morning ORM!
• TDD: Guide or Guard Rail?
• Build Tool Battle Royale
• Our DB is Web Scale!
• To Estimate or Not To Estimate?

Functional SOLID

9:00 AM MDT

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.

Programming with Immutability

10:45 AM MDT

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.

Master of Puppet

1:30 PM MDT

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.

Code Archaeology

3:15 PM MDT

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.