Matt Stine

Functional SOLID

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.

Programming with Immutability

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.

Critical Thinking in Software Engineering, Part I: Lecture

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.

Master of Puppet

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

Critical Thinking in Software Engineering, Part II: Katas

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.

Vagrant: Virtualized Development Environments Made Simple

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.

Code Archaeology

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.”

Cloud Foundry Deep Dive, Part 1: The Developer Experience

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.