Watch Preview Video

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.

Watch Preview Video

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.

Watch Preview Video

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.

Watch Preview Video

Alistair Cockburn has described software development as a game in which we choose among three moves: invent, decide, and communicate. Most of our time at No Fluff is spent learning how to be better at inventing. Beyond that, we understand the importance of good communication, and take steps to improve in that capacity. Rarely, however, do we acknowledge the role of decision making in the life of software teams, what can cause it to go wrong, and how to improve it.

In this talk, we will explore decision making pathologies and their remedies in individual, team, and organizational dimensions. We'll consider how our own cognitive limitations can lead us to to make bad decisions as individuals, and what we might do to compensate for those personal weaknesses. We'll learn how a team can fall into decision-making dysfunction, and what techniques a leader might employ to healthy functioning to an afflicted group. We'll also look at how organizational structure and culture can discourage quality decision making, and what leaders to swim against the tide.

Software teams spend a great deal of time making decisions that place enormous amounts of capital on the line. Team members and leaders owe it to themselves to learn how to make them well.