Matt Stine
Rocky Mountain Software Symposium
Denver · November 21 - 23, 2014
I Enable Early-Career Enterprise Software Engineers to Continuously Improve
My passion is taking a metaphysical approach to software engineering: what is the nature of the collaborative game that we continuously play, and are there better, more contextually-aware ways to play that game?
By day I lead a team tasked with taking a first-principles-centric approach to intentionally enabling programming language usage at the largest bank in the United States.
By night I write and teach my way through a masterclass in software engineering and architecture targeting early-career software engineers working in large-scale enterprise technology organizations.
What is the primary goal?
To win the game. More seriously: to get 1% better every day at providing business value through software.
Who am I?
I'm a 22-year veteran of the enterprise software industry. I've played almost every role I can imagine:
- Software Engineer
- Software Architect
- Technical Lead
- Engineering Manager
- Consultant
- Product Manager
- Field CTO
- Developer Advocate
- Conference Speaker
- Author
- Technical Trainer
- Technical Marketer
- Site Reliability Engineer
- Desktop Support Specialist
I've worked at Fortune 500 companies, a tenacious teal cloud startup, and a not-for-profit children's hospital. I've written a book, and I've hosted a podcast. I've learned a lot along the way, including many things I wish I'd known when I first got started. And so now I want to pass those learnings on to you, especially if you've only just begun your career.
Presentations
Failure is the Only Option
Even taking into account everything that we've learned about operating at “web scale” in the last several years, most applications are designed and implemented to be, as Michael Nygard highlights in his book Release It!, “feature complete” not “production-ready.” Unfortunately, the architectural patterns associated with operating at scale – notably the move toward “micro-services” – introduce an order of magnitude more ways in which our applications can fail. If we do not plan well for failure, we will experience the ultimate failure. But if we do plan well for failure, we have a fighting chance at success.
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.
A Java Dev Learns to Go
The Cloud Foundry engineering teams have steadily increased their use of the Go programming language (http://golang.org) for building (or rebuilding) components, starting with the Router, and progressing through Loggregator, the “cf” CLI, and more recently the Health Manager 9000.
As a Java-developer-turned-DevOps-junkie focused on helping our customers and community succeed with Cloud Foundry, it's become clear to me that I need to add Go to my knowledge portfolio.
Cloud Application Architecture Patterns
We make many assumptions when we develop our applications. Many of these assumptions no longer hold true when we start to build applications for the cloud. Cloud platforms also introduce architectural possibilities that do not exist in traditional deployment settings. This session will examine five architectural patterns that we can apply to our applications in order to prepare them for the unique characteristics of cloud environments.
Docker for Developers
“Docker is an open-source engine that automates the deployment of any application as a lightweight, portable, self-sufficient container that will run virtually anywhere.” Docker creates containers that provide running process with:
- an equal slice of CPU
- a maximum memory quota
- its own process ID (PID) namespace
- its own network interface
- its own private root filesystem
It does this by leveraging low-level Linux kernel primitives like cgroups and namepaces. The end result is a portable application container that can run anywhere Docker can run, including on VMs, bare-metal servers, OpenStack clusters, public instances, or combinations of the above.