Sessions at Central Iowa Software Symposium on Friday 3rd August

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.

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.

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.

The first in a series of talks that are part of an arc covering next-generation information-oriented, flexible, scalable architectures. The ideas presented apply to both external and internal-facing systems.

The REpresentational State Transfer (REST) architectural style has emerged as a winning strategy for building scalable, flexible, resilient systems that lead with an information focus. Far from being the simple "Web Services through URLs" idea many people have about them, REST-based systems require a new perspective, a fair amount of consideration and the discipline to look beyond simple point-to-point interactions.

The benefits are exciting and provide a gateway to a whole new world of information technology. This first talk will be an introductory session covering the basics of the REST architectural style.

A little old lady once challenged a well-known scientist’s explanation on the structure of the universe, countering that the world is really a flat plate supported on the back of a giant tortoise. The scientist rebutted the little old lady’s challenge with one of his own by asking what the tortoise was standing on. The little old lady’s sly reply was that it’s, “turtles all the way down.” So too is software architecture “turtles all the way down”.

In this session, we cover a broad range of topics that include challenging traditional practices of software architecture, examining what it takes to bring down the ivory tower, probing the paradoxical aspects of architecture’s goal, and investigating the inextricable link between temporal decisions and structural flexibility. From the highest level applications and services to the code that exists in the bowels of the system, and everything in between, we explore how an effective software architecture must be turtles all the way down. In the end, we will all have gained deep insight to the value of agile architecture.

Neo4j is an open-source, enterprise-class database with a conventional feature set and a very unconventional data model. Like the databases we're already used to, it offers support for Java, ACID transactions, and a feature-rich query language. But before you get too comfortable, you have to wrap your mind around its most important feature: Neo4j is a graph database, built precisely to store graphs efficiently and traverse them more performantly than relational, document, or key/value databases ever could.

Neo4j is an obvious fit to anyone who thinks they have a graph problem to solve, but this is not many people. It turns out that the most interesting property of Neo4j is its architectural agenda. It wants you to think of the entire world as a graph—as a set of connected information resources. Steeped in the thinking of resource oriented architecture, this NoSQL database wants to change the way you look at your world, and unlock new value in your data as a result.

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.

OSGi was once heralded as a contender for most important technology of the decade. Today, most developers have heard of OSGi, but few are using it to develop their enterprise software applications.Is OSGi failing? Who is using it? And what exactly are its benefits?

In this session, we'll explain the benefits of OSGi, and show that it's not just for the middleware vendor. We'll learn how you can use OSGi without making significant changes to how you write your software applications. We'll explore the OSGi ecosystem, including platforms that support OSGi. Through code examination, we'll see how the Spring framework allows us to leverage OSGi in a non-invasive way. We'll discover how OSGi encourages Polyglot programming on the Java platform. And we'll take a brief glimpse into the future of modularity on the Java platform. You'll walk away with a much better understanding of OSGi, its strengths and benefits, how to use it effectively, as well as the myths surrounding its use.

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.

The second in a series of talks that are part of an arc covering next-generation information-oriented, flexible, scalable architectures. The ideas presented apply to both external and internal-facing systems.

People already familiar with REST (or who have attended the first session) will be walked through the deeper topics of building Level 3 Hypermedia-based RESTful systems, security, content negotiation, etc.

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.

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.

ThoughtWorks' Technical Advisory Board creates a "technolgy radar" 3 or 4 times a year. It is a working document that helps the company as a whole make decisions about what technologies are interesting and where we should be spending our time. This is a useful exercise both for you and your company. This session describes the process we use and how to adapt it to both your company and, more importantly, yourself. For career risk mitigation, you must know what the next big thing is, or at least be able to narrow it to a reasonable list. Attendees will leave with tools that enhance your filtering mechanisms for new technology and help you (and your organization) develop a cogent strategy to make good choices.

When you want to measure fractions of a millimeter, you get a micrometer. When you want to measure centimeters, you get a ruler. When you want to measure kilometers, you might use a laser beam. The abstract task is the same in all cases, but the tools differ significantly based on the size of the measurement.

Likewise, there are some computations that can be done quickly on data structures that fit into memory. Some can't fit into memory, but will fit on the direct-attached disk of a single computer. But when you've got many terabytes or even petabytes of data, you need tooling adapted to the scale of the task. Enter Hadoop.

Hadoop is a widely-used open source framework for storing massive data sets in distributed clusters of computers and efficiently distributing computational tasks around the cluster. Come learn about the Hadoop File System (HDFS), the MapReduce pattern and its implementation, and the broad ecosystem of tools, products, and companies that have grown up around this ground-breaking project.

Modularity is coming to the Java platform! Java 8 will introduce the Jigsaw module system. OSGi is here today. Don’t wait to start designing modular software. Contrary to popular belief, you don't need a framework or a new runtime to start building modular software applications. You can start today. Learn how!

In this session, we'll examine what it means to develop modular software on the Java platform. We'll examine the goals and benefits of modular software, and explore the patterns of modular architecture that help us develop modular software systems. With just a few easy steps, we'll see how to transform our software from a huge monolith to an extensible system of collaborating software modules. By examining an existing software system, we'll see first hand how we can increase software modularity with minimal disruption. You'll walk away not just with a much deeper understanding of the benefits of modular software, but also a migration roadmap for refactoring existing applications to increase their modularity. In other words, you'll see how to get ready today for the application platform of tomorrow.

The third in a series of talks that are part of an arc covering next-generation information-oriented, flexible, scalable architectures. The ideas presented apply to both external and internal-facing systems.

The move to a good REST API yields an explosive combination of options due to content-negotiation and arbitrary workflows. At the same time, the uniform interface you project (representations, how you respond to verbs, response codes, etc.) becomes your contract with your clients. The API itself becomes a completely transportable, reusable bit of organizational knowledge when done well. Testing it sufficiently will give you a safety net but may drive you crazy unless you do it right. We will walk through the use of Behavior-Driven Development (BDD) to test these kinds of APIs.

We will highlight the problems of sufficiently testing REST APIs while providing a rich and relatively straight-forward solution to the problem. We will use a Behavior-Driven Development (BDD) tool like Cucumber to establish reusable steps and comprehensive, but lightweight testing strategies for testing REST APIs.

This talk will not be an introduction to REST. If you have come to the REST I or REST II talk, or have a good understanding, it should be very accessible.

Prerequisite: Resource-Oriented Architectures : REST I (or a good understanding of REST)

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.