Matt Stine
Community Engineer @CloudFoundry
Matt Stine is a Community Engineer with Cloud Foundry (http://cloudfoundry.com) by Pivotal (http://goPivotal.com). He is a twelve year veteran of the enterprise software and web development industries, with experience spanning the healthcare, biomedical research, e-commerce, retail store and insurance domains.
Matt is obsessed with the idea that enterprise IT “doesn’t have to suck,” and spends much of his time thinking about lean/agile software development methodologies, DevOps, architectural principles/patterns/practices, and programming paradigms in an attempt to find the perfect storm of techniques that will allow corporate IT departments to not only function like startup companies, but also create software that delights users while maintaining a high degree of conceptual integrity.
Matt has spoken at conferences ranging from JavaOne to CodeMash and serves as Technical Editor of NFJS the Magazine (https://www.nofluffjuststuff.com/home/magazine_subscribe). Matt is also the founder of the Memphis/Mid-South Java User Group.
Presentations
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."
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.
Effective Java Reloaded
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!
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
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.
Effective Java Reloaded, Part II: Hello, Project Coin!
Even with the recent explosion in alternative languages for the JVM, the vast majority of us are still writing code in "Java the language" in order to put bread on the table. Proper craftsmanship demands that we write the best Java code that we can possibly write. Fortunately we have a guide in Joshua Bloch's Effective Java.
Effective Java is organized into 78 standalone "items," all of which will be impossible to cover in one session. Instead I've chosen a subset of the most important techniques and practices that are commonly missed by today's Java programmers.
*In Part II of this session, we'll cover those items we were unable to reach during Part I. We'll follow that up with a dive into the new features available in Java 7, describing new idioms for effective Java programming in the following areas:
- Strings in switch statements
- Enhanced syntax for numeric literals
- Improved exception handling
- ARM (automatic resource management) blocks
- Type inference for construction of parameterized types (the "diamond" operator)
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.
Our agenda will include:
- Creating new base OS templates using the Vagrant Veewee plugin
- Creating a new development box using Vagrant
- Provisioning the box using Puppet
- Provisioning the box using Chef
- Deploying a simple web application to a multi-box development environment
- Packaging and distributing the box within your team
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.
In this talk, we'll explore this intersection. We'll begin with a brief overview of Martin's catalog of software design smells, which describe properties of software designs that have not addressed change effectively, and thereby become increasingly hard to evolve. We'll then take a tour through the SOLID principles, addressing the following topics:
- What is the principle?
- What design smells does it combat?
- How does it work?
- Does it still apply within the functional paradigm?
- How can multiparadigmatic (combining concepts from OO, functional and other paradigms) programming better align with the principle?
- Examples from Java
- Where a particular language feature greatly enhances alignment with the principle, examples from Groovy, Scala and Clojure
Critical Thinking in Software Engineering
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 walk through the critical thinking process, examining what skills we need to develop, what analysis techniques we can use, and how to make decisions both individually and as a group. We'll then critically examine many "industry best practices" that are often followed without question and come up with our own evaluations.
Programming with Immutability
For much of the last two years I've delivered a two-part series at NFJS shows entitled "Effective Java Reloa ded." 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, two major questions arise.
First, the necessity of using a separate obect for each distinct value, never reusing, or "mutating" an obje ct, 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 Functional Java library and in the Clojure language.
Second, 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.
Critical Thinking 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.
Teams will then be responsible for presenting their evaluations and arguments to the group, and the group as a whole will evaluate the presentations.
Matt's NFJS Schedule
Books
Biomedical Informatics for Cancer Research
by
- This book will review work from a number of researchers who have produced open source software addressing the need for data management, integration, analysis, and visualization to aid cancer research. With the advent of high-throughput technologies in biomedicine, the need for data management and appropriate data analysis tools in genomics has increased dramatically, joining clinical trials data as a major driver of informatics at cancer research centers. The gathering of this data requires careful encoding of metadata, usually through the use of controlled vocabularies or ontologies, as well as the linking of data from model organisms, done at both a physiological level (e.g., anatomy) and at a molecular level (e.g., orthology). This data will then find use within computational and statistical models, which require data pipelines and analysis systems, as well as algorithms, visualization methods, and computational modeling systems. We will introduce open source tools available for these aspects of the problem. The editors plan to divide the book into five sections, beginning with a section containing high level overviews of the field and key issues. This will include an introductory review of informatics in cancer research, followed by five overviews addressing issues in authentication and authorization, data management, data pipelines and annotations, algorithms and models, and the NCI caBIG initiative. This will be followed by sections dedicated to data systems, data pipelines, algorithms for analysis and visualization, and modeling systems. Each of these areas has seen publication of open source tools, ranging from the widely known R/Bioconductor package to little known but powerful systems such as SImmune for biochemical modeling. The area of laboratory information management systems has seen development of a number of unpublished but powerful systems, which we would also include. Three groups have agreed to provide chapters in this area (USC/Norris CAFE extensible clinical trials system, St Jude Unified LIMS, Fox Chase/British Columbia flow cytometry LIMS). While there has been a great deal of development of informatics tools that can be applied to problems in cancer research, there has not been adequate dissemination of details on these tools to the community. As such, there remains low adoption of all but a few tools. This book aims to increase overall adoption of tools by providing cancer center leaders and researchers with a single volume detailing both issues that must be addressed and tools that are ready for use.

