It seems like all we talk about these days is making our architectures more modular. Buy why? In this session I will discuss the drivers and reasons why it is essential to move towards a level of modularity in our architectures. I will discuss and show real-world use cases of distributed modular architectures (specifically microservices and service-based architecture), and then discuss in detail the core differences between microservices and service-based architecture and when you should consider each. I'll end the talk by discussing the most effective way of migrating to modular distributed architectures.

Agenda:

Drivers for modularity
Modular distributed architectures
Microservices vs. service-based architecture
The move towards modularity

Even though teams are gaining more experience in designing and developing microservices, nevertheless there is still a lot to learn about this highly distributed and somewhat complicated architecture style. Unfortunately, lots of microservices anti-patterns and pitfalls emerge during this learning curve. Learning about these anti-patterns and pitfalls early on can help you avoid costly mistakes during your development process. While anti-patterns are things that seem like a good idea at the time and turn out bad (see martinfowler.com/bliki/AntiPattern.html), pitfalls are those practices that are never a good idea at the time - ever. In this session I will cover some of the more common anti-patterns you will likely encounter while creating microservices, and most importantly describe some of the techniques for avoiding these anti-patterns.

Agenda

Function-Driven Identification AntiPattern
I Was Taught to Share AntiPattern
The Timeout AntiPattern
Hop on the Bus AntiPattern
Data-Driven Migration AntiPattern

Even though teams are gaining more experience in designing and developing microservices, nevertheless there is still a lot to learn about this highly distributed and somewhat complicated architecture style. Unfortunately, lots of microservices anti-patterns and pitfalls emerge during this learning curve. Learning about these anti-patterns and pitfalls early on can help you avoid costly mistakes during your development process. While anti-patterns are things that seem like a good idea at the time and turn out bad (see martinfowler.com/bliki/AntiPattern.html), pitfalls are those practices that are never a good idea at the time - ever. In this session I will cover some of the more common pitfalls you will likely encounter while creating microservices, and most importantly describe some of the techniques for avoiding these pitfalls.

Agenda

Grains of Sand Pitfall
Where's the Acid Pitfall
Logging Can Wait Pitfall
Jump on the Bandwagon Pitfall
Give it a Rest Pitfall

Reactive architecture patterns allow you to build self-monitoring and self-healing systems that can react to both internal and external conditions without human intervention. How would you like to design systems that can automatically grow as the business grows, automatically handle varying load (cyber Monday?), and automatically handle (and repair) internal and external errors, all without human interaction? I'll show you how to do this with your current technology stack (no special languages, tools, frameworks, or products). In this two-part session I will leverage both slides and live coding using Java and RabbitMQ to describe and demonstrate how to build reactive systems. Get ready for the future of software architecture - that you can start implementing on Monday.

Part 1 Agenda:

Reactive systems introduction
Channel Monitor Pattern (self-awareness)
Consumer Supervisor Pattern (scalability and elasticity)
Workflow Event Pattern (error handling)

Part 2 Agenda

Thread Delegate Pattern (scalability)
Threshold Adjust Pattern (automatic configuration and self-learning)
Producer Control Flow Pattern (self-healing)

Since the dawn of software development, we've struggled with a huge disconnect between the management world and the engineering world – the clash of top-down control, money, and economics, versus art, freedom, working with our friends, and bringing awesome creations to life.

Overcoming these challenges in our industry requires a huge paradigm shift – rather than building organizations as money-making machines with top-down control, our organizations need to become thinking, feeling, interconnected social organisms, where our humanity isn't boiled down to a few numbers.

How do we shift the paradigm of the organization, to bridge these two worlds together? The short answer – with the help of software.

By measuring the friction in a developer's Flow, we have a data-driven feedback loop for personal improvement. What if we measure Flow across the team? Across team dependencies? Across the organization?

What would it take to build an organizational operating system, that uses our past experience and lessons learned as the foundation for an intelligent hive mind, that helps everyone in the organization make better decisions? What if we codified our organizational ideals into the business accounting rules of the software, then sold it as the “the next big thing” in the industry?

At the end of the day, business is a game. If we take responsibility for making up the rules, we can redefine the game we wish to play. In this session, we'll discuss a potential future for our industry, where we design the organizational operating system that runs the world.

This is my story of lessons learned on how to stop the crushing effects of business pressure… I was team lead with full control of our green-field project. After a year, we had continuous delivery, a beautiful clean code base, and worked directly with our customers to design the features. Then our company split in two, we were moved under different management, and I watched my project get crushed.

As a consultant, I saw the same pattern of relentless business pressure everywhere, driving one project after another into the ground. I made it my mission to help the development teams solve this problem. This is my story of lessons learned on how to transform an organization from the bottom up. I'll show you how to lead the way.

The crushing business pressure is caused by a broken feedback loop that's baked into the organization's design. In this presentation, I'll show you how to fix the broken feedback loop. Learn how to:

Gather evidence of developer productivity loss
Identify the key organizational changes required for success
Make the case to management for improvement
Partner with your manager for long-term success

If the system is broken, we need to fix the system. You can change the system by making the decision to lead.

This is my story of lessons learned on why improvement efforts fail… I had a great team. We were disciplined about best practices and spent tons of time on improvements. Then I watched my team slam into a brick wall. We brought down production three times in a row, then couldn’t ship again for a year.

Despite our best efforts with CI, unit testing, design reviews, and code reviews, we lost our ability to understand the system. We thought our problems were caused by technical debt building up in the code base, but we were wrong. We failed to improve, because we didn’t solve the right problems. Eventually, we turned our project around, but with a lot of tough lessons along the way.

In this talk, we'll go through a deep-dive case study that starts with project failure, then revisit all the mistakes we made over a 3 year journey to turn the project around. We'll discuss bad assumptions, strategies that failed, ideas that changed, techniques and tools that changed, and how we eventually learned our way to victory.

After reviewing each mistake, we'll have a group discussion about the underlying reasons, so you can avoid these mistakes on your own project.

“Open Mastery” is the discipline of learning out loud. In Open Mastery Circles, we put the pain on center stage, dig into the causes of pain as a group, then codify lessons learned into patterns and principles. With a simple 5-step problem-solving protocol that's easy to apply on your team, you can drastically increase the rate of learning.

Have you ever wondered whether your retrospective format was actually effective at fueling learning and improvement? Are you ready to try something different?

First, we'll identify the most common “pain type” experienced by the audience (from “The Ten Pains of Software Development” in Idea Flow), and choose the focus for the discussion. Then we'll dig into the details of one experience at a time, understand the causes of pain, and come up with strategies for improvement.

Focus: Choose an experience with a specific unsolved #PainType
Observe: Ask questions about the facts (maximize perspective)
Conclude: What major factors caused the pain? (share ideas)
Optimize: What strategies could we use to reduce the pain? (share ideas)
Learn: Distill the lesson learned into #Patterns in the context of a “Journey”

Since this is much easier to do than to explain, there will be a short intro that explains the format, and why it works, then we'll spend the rest of the time in discussion.

By the end of this conference you will have learned many new tools and technologies. The easy part is done, now for the hard part: getting the rest of the teamand managementon board with the new ideas. Easier said than done.

Whether you want to effect culture change in your organization, lead the transition toward a new technology, or are simply asking for better tools; you must first understand that having a “good idea” is just the beginning. How can you dramatically increase your odds of success?

You will learn 12 concrete strategies to build consensus within your team as well as 6 technique to dramatically increase the odds that the other person will say “Yes” to your requests.

As a professional mentalist, Michael has been a student of psychology, human behavior and the principles of influence for nearly two decades. There are universal principles of influence that neccessary to both understand and leverage if you want to be more effective leader of change in your organization.

In this session we discuss strategies for getting your team on board as well as when/how to approach management within the department and also higherup in the organization.

It happens to us all; there are simply days where it seems impossible to get anything done. This session focuses on techniques and tips to get into the zone, stay in the zone and to protect your productivity, even in disruptive environments.

Rather than focusing on any one productivity methodology (e.g. GTD) This talk analyzes the internal and external factors that affect our productivity and offers broader strategies to get back on track.

An evolutionary architecture supports incremental, guided change along multiple dimensions.

For many years, software architecture was described as the “parts that are hard to change later”. But then microservices showed that if architects build evolvability into the architecture, change becomes easier. This talk, based on my upcoming book, investigates the family of software architectures that support evolutionary change, along with how to build evolvable systems. Understanding how to evolve architecture requires understanding how architectural dimensions interact; I describe how to achieve appropriate coupling between components and services. Incremental change is critical for the mechanics of evolution; I cover how to build engineering and DevOps practices to support continuous change. Uncontrolled evolution leads to undesirable side effects; I cover how fitness functions build protective, testable scaffolding around critical parts to guide the architecture as it evolves.

The software development ecosystem exists in a state of dynamic equilibrium, where any new tool, framework, or technique leads to disruption and the establishment of a new equilibrium. Predictability is impossible when the foundation architects plan against changes constantly in unexpected ways. Instead, prefer evolvability over predictability. This keynote illustrates how to achieve evolutionary architectures and how to retrofit existing systems to support better evolution.

Hypothesis and data driven development ties together current thinking about requirements, Continuous Delivery, DevOps, modern architecture, and engineering techniques to help rethink building software.

Agile development claims to abhor “Big Design Up Front”…yet what is that giant backlog building session but BDUF in other clothing? Back in the olden days of software development, we were forced to speculate on what users want, then build it. We were basically running a buffet. But what if we could switch to à la carte? With modern engineering practices like Continuous Delivery, we can shift our perspective and start building by hypothesis rather than speculation. This talk shows the full spectrum of software development, from ideation through execution and deployment, through the lens of modern software engineering practices. I discuss building a platform using feature toggles, canary releases, A/B testing, and other modern DevOps tools to allow you to run experiments to see what your users really want. By building a platform for experimentation, product development shifts from up-front guessing to market driven. This talk unifies the practices of modern architecture, DevOps, and Continuous Delivery to provide a new approach to feature development. This talk also demonstrates how to undertake major architectural restructuring with zero regression failures by relying on data and the scientific method.

This session compares Service-oriented, Service-based, and Micro-service architectures, describing the problem each is designed to solve, differences and similarities, variants and hybrids, and engineering practices.

Microservice architectures are quite popular, described as “SOA done correctly”. But what are the real differences between SOA, Microservice, and service-based architectures? What about middle ground between the shared everything of SOA versus shared nothing of microservices? This talk explores the similarities and differences between various service-oriented architectural styles. I describe the characteristics of SOA, microservices, and hybrid service-based architectures, along with the considerations and constraints for each. I also discuss specific engineering practices, orchestration styles, reuse strategies, and migrating from monolithic applications to service-based or microservice architectures. No one architecture can solve every problem, and many projects take on more complexity than necessary by choosing the wrong paradigm.

Starting with JDK 5, we have had Futures, and they mostly went ignored. Now with concurrency and reactive technology in demand, it is essential that we understand what futures are, and how to handle them and make use of their power in asynchronous systems.

This presentation is a basic ground up introduction to Futures. We start with Futures and how they came packaged with JDK 5. We take a look at Executors, how to create a thread pool, which pool you should choose. How to model Futures in the JDK and show the difference for awaiting the answer and taking on the answer asynchronously. We also take a look at what a Promise is and when to use one. We then invest time taking a look at Guava's callback solution. Then we finally look at the handling of futures in both Scala and Clojure.

Reactive is a the latest buzzword to consume our industry. This presentation distills and defines reactive systems, describe the difference between reactive architecture vs. reactive programming, describe common patterns, and demos the popular reactive JVM technologies like RXJava, and Akka.

Introduction to reactive gets in deep on a discussion of patterns: Source, Sink, Back Pressure, Reactive Pull/Push including a Light introduction to actors using Akka, ReactiveX using RXJava and Reactive Streams in RXJava and Akka. We also will showcase the differences between ReactiveX and Akka.

ReactiveX is a set of Reactive Extensions developed by Netflix, and is developed for various programming languages, like Java, Scala, and Clojure. ReactiveX overhauls the observable design pattern to achieve reactive goals. This presentation will solely focus on the Java version of ReactiveX, RXJava.

RXJava is combining the Observer Pattern with Functional Programming to compose complex asynchronous reactive systems. This presentation will also give an overview on RXJava concepts like Source, Sink, BackPressure and Reactive Pull and Push.

Many of us would love to embrace microservices in our day-to-day work. But most of us don’t have the opportunity to start over with a pure greenfield effort. We have to understand how to refactor our existing monolithic applications toward microservices. Practical steps include building new features as microservices, leveraging anti-corruption layers, strangling the monolith.

In this presentation we’ll go light on the theory and walk through the actual process of turning a strawman monolith into a family of well-factored microservices.

While rummaging through some books the other day, I came across my copy of The Pragmatic Programmer. Flipping to the copyright page, I realized that it had been 16 years since its publication. Many of our careers have been deeply affected by reading and considering the many nuggets of wisdom contained in this book, and it is near the top of multiple recommended reading lists.

In this presentation, we’ll revisit this book, and we’ll also consider what we’ve learned since its publication - what would we change? And what remains timeless?

Over the past year I’ve had the pleasure of wearing the hat of “product manager” for the Spring Cloud Services team at Pivotal, operating using a distributed variant of the Pivotal Labs process. Along the way I’ve learned many valuable lessons that I hope you’ll be able to apply to your product development efforts.

In this presentation we’ll examine the relationship of product management to engineering and to your customer, and how you can be an effective broker between the two groups.

Concourse (http://concourse.ci/) is a CI system composed of simple tools and ideas. Concourse can express entire pipelines, integrating with arbitrary resources, or it can be used to execute one-off tasks, either locally or in another CI system. Concourse attempts to reduce the risk of adoption by encouraging practices that keep your project loosely coupled to the details of your continuous integration infrastructure.

Concourse optimizes around the following principles:

Simplicity
Usability
Build Isolation
Scalable, reproducible deployments
Flexibility
Local iteration

During this session we'll learn the simple key concepts from which Concourse pipelines are constructed. We'll understand how to deploy a local Concourse cluster using Vagrant as well as a scalable Concourse cluster to your cloud of choice using Cloud Foundry BOSH. Finally, we'll look at basic and advanced examples of pipelines for Java projects.

In this session, we'll see how to build real Spring applications using Spring Boot. We'll also look under the covers to see what makes Spring Boot tick.

Spring offers a number of configuration options: XML configuration, Java configuration, and Groovy configuration to name a few. To some degree, component-scanning and autowiring help eliminate some explicit configuration. But in general most Spring applications require some essential “bootstrap” configuration to enable key functionality. What's the right way to build Spring applications when there are so many choices?

What if I told you that configuration was optional?

Spring Boot is an exciting new programming model for Spring that makes it extremely easy to create stand-alone, production-ready Spring applications. Rather than writing lots of code to satisfy the needs of a framework, Spring Boot helps you focus your coding efforts on your application. Spring Boot takes an opinionated approach to configuring Spring, making it possible to create Spring applications with little or, in some cases, no Spring configuration at all!

In this session, we'll open the hood on Spring Boot and see how it works. Using this knowledge, we'll look at ways to optimize Spring Boot, override autoconfiguration, and create custom extensions to Spring Boot's Actuator.

Spring Boot does many wonderful things that get you well on your way to developing amazing Spring applications. But how does it tick? How can you customize it? And how can you override it's default autoconfiguration when you want something a little different?

In this session, we'll explore Spring Cloud, the extension to Spring which addresses many of the common challenges of developing cloud native applications. We'll focus primarily on Spring Cloud's support for centralized configuration, service discovery, and failover/monitoring.

You wouldn't write your entire application in a single main() method or servlet. Nor would you develop an entire production-ready application in a single class. It's even unlikely that you'd cram everything into a single package.

Modularity helps us gain order in our code, breaking it into easily digestible, refactorable, pluggable, and testable chunks. Classes and methods are a form of modularity that we're all familiar with. But once the code is built, modularity goes away and we're left deploying a single WAR file.

Aside from being buzzword-compliant, Microservices are a means of defining entire systems from composable, but distinct deployment units gaining all of the benefits of finer-grained modularity.

Microservices present new challenges to developers, however. How do you configure your microservices? How are microservices discovered? And how can you avoid a cascading failure when one microservice becomes sluggish, unresponsive, or otherwise unhealthy?

In this session, we'll look at Spring Cloud Data Flow, a cloud native programming and operating model for composable data microservices on a structured platform.

Microservices are commonly thought of as small REST-based services that are assembled to form a larger, more complete application. In reality, however, REST is only the communication mechanism which is only a implementation detail and not intrinsic to the notion of microservices.

Meanwhile, data processing and integration between various components of an application and external services is a key factor of many applications. In cloud native applications, this kind of data flow and processing is still relevant. Spring Cloud Data Flow offers a solution for data processing and integration where each step in the flow is, in fact, a microservice…but not necessarily a REST service.

In this session, we're going to combine the magic of Spring Boot and the magic of Spring Data to yield something even more powerful. You'll see how to quickly build an application's persistence layer, whether it stores data in a RDBMS, Mongo, Neo4j, or several other popular data stores. You'll also see how to create a functioning REST API with nothing more than an interface and a domain type.

Spring Boot dramatically simplifies application development with Spring. But before Spring Boot came along, Spring Data was already making developers' lives easy when it comes to working with data. When combined, Spring Data and Spring Boot can make data persistence the easiest part of your application.

Much is said about the decentralized governance of and local autonomy given to “two pizza teams” build microservices. But how do you organize teams to effectively collaborate to build the eventual composite system?

In this presentation we’ll examine how to apply the Tracer Bullet Development methodology described in Ship It! to effectively construct distributed systems composed of microservices.

Embracing microservices also means embracing distributed systems. Distributed systems carry with them multiple challenges. One set of challenges includes problem of visibility into the behavior of the composite system, understanding that behavior, and being able to isolate the cause(s) of problematic behavior. These challenges can be addressed by applying the techniques known collectively as Distributed Tracing.

In this presentation, we’ll examine the theory of distributed tracing put forth in Google’s Dapper paper, and we’ll look at how this theory is put into practice in the design of Zipkin, an OSS distributed tracing platform.

Didn't you hear the news? TDD is dead. Yet many developers rely on it for quality code. Come join the zombie apocalypse and learn and understand TDD, what sets it apart from unit testing after the fact, what to do when you need to update code, effective mocking, automatically generating test data and lots of it, leaving code alone and respecting your work, and more

This presentation will cover:

What is TDD?
Benefits of TDD
How to TDD
Mocking
The Great TDD Debate
Opinions of TDD from Industry Leaders
JVM Testing Tools
JVM Testing Languages
Testing Static Calls
Updating Code

This presentation will cover:

What is TDD?
Benefits of TDD
How to TDD
Mocking
The Great TDD Debate
Opinions of TDD from Industry Leaders
JVM Testing Tools
JVM Testing Languages
Testing Static Calls
Updating Code

The technology space is a lot like the ocean - miss one wave and another will come along shortly; most shiny new things begin with a sizable amount of hype as everyone rushes to play with the new toy. This cycle is often met with a level of disappointment as we quickly discover our new bauble isn't all that and a bag of chips so we rush off to the next best thing ever.

A few short years ago, HTML5 was the new hotness but at the time browser support was spotty at best. Despite the spotlight moving on to something else, browser support has improved markedly and we even have new toys to play with! In this talk, I will walk you through what is possible in today's browser as well as what other new features you might not be aware of. HTML5 may no longer qualify as bleeding edge, but it is still deserving of our attention.

Take a look at your codebase. Go ahead, this abstract will wait. Notice anything? Perhaps a few more lines of JavaScript than years past? JavaScript is no longer an outlier, a language for the interns, something we can just mash together. Today, JavaScript is a first class citizen. As such, we need to treat it will all the care and feeding we extend our server side languages. This talk will introduce you to a set of tools that will help you write bulletproof JavaScript.

Step one, make sure we aren't making any basic mistakes like using == when we really mean ===. To remedy these types of bugs, we'll leverage JSHint to statically analyze our code. In addition to walking through the setup, we'll discuss how to ratchet up the rules as you improve your codebase. Just like Java or C#, we also need to test our JavaScript code. We'll introduce Jasmine, a BDD style testing tool as well as other tools that make help in the testing process. Last but not least, we'll take a tour of Plato, a JavaScript source code visualizer. Taken together, these tools can go a long way to improve your JavaScript code.

Back in the day, web developers had to rely on their wits and a plethora of alert statements - to say our toolkit was spartan would be an understatement. But with the increased importance of web front ends and the rise of JavaScript MVC frameworks, a modern web developer toolkit is finally emerging.

We've evolved from text editors to full fledged IDE's with code completion and refactoring tools but our toolchain doesn't end there. With multiple testing libraries, mocking frameworks, test drivers and even code coverage tools, today's web developer gets to walk downhill on a sunny day.

If you have ever studied a martial art, chances are you are familiar with katas: the practice of individual training exercises. Repeatedly. It may seem pointless to practice the same move again and again, the only way to improve is repetition. We can apply the same concept to learning programming languages.

Working individually or in small groups, attendees will work through a set of problems using JavaScript to solve them. Whether you are new to JavaScript or an old hand, this session will give you an opportunity to hone your craft! Bring a laptop or be prepared to make a friend.

How do we define identity in a distributed software system? How do we manage it securely? How do we make identity assertions and verify those claims?

Technologies don't magically become solutions. They are used within domain, design and deployment contexts. This talk will focus on the singular notion of Identity and how it cross-cuts the distributed systems we are building.

We will focus on a variety of technologies and standards that help us make, identify, claim and verify identities.

Authenticated Identities are the first step to establish Privilege. Most systems fail to have sufficiently, deeply entrenched notion of how to apply and minimize privilege to avoid data and systems from being abused.

Technologies don't magically become solutions. They are used within domain, design and deployment contexts. This talk will focus on the singular notion of Privilege and how it cross-cuts the distributed systems we are building.

This talk will focus on the Valet Key problem and how to avoid it. We will visit various standards and technologies that help us strengthen our security profiles by reducing our dependence on open-ended and unfettered access to our systems and data.

Data integration costs are well beyond what they should be for such a crucial business function. The good news is that they needn't be. By relying on integration-friendly standards and technologies that were designed to support sharing information, we can reduce these costs while increasing our business capabilities.

Technologies don't magically become solutions. They are used within domain, design and deployment contexts. This talk will focus on the singular notion of Integration and how it cross-cuts the distributed systems we are building.

We will look at how the REST Architectural style leads us to integration-friendly standards such as RDF, Linked Data, SPARQL and JSON-LD. These technologies are useful both within our firewalls and with third party partners.

Our biological world changes gracefully. Our information world changes much less so. How can we embrace the inevitable technological, procedural and schematic flux that we know is going to visit upon us at some point?

Technologies don't magically become solutions. They are used within domain, design and deployment contexts. This talk will focus on the singular notion of Evolution and how it cross-cuts the distributed systems we are building.

We will focus on strategies from the Web standards space to define information systems that embrace change and handle it with relative ease.

This will include strategies for dealing with changing technologies, changing schemas and more.

Information conveys value as it travels around our systems, resting for a time in our data stores. The value we get out of it is sometimes matched by the value others would get from it as well. We need mechanisms to protect sensitive information from prying eyes and control with whom we share it.

Technologies don't magically become solutions. They are used within domain, design and deployment contexts. This talk will focus on the singular notion of Secrecy and how it cross-cuts the distributed systems we are building.

This talk will focus on strategies from the world of encryption to keep secrets secret as we produce, store and transfer information in distributed systems. A successful strategy for doing so will rely on notions of Identity and a strong Privilege model, but we will mostly focus on specific building blocks upon which we maintain Privacy and Confidentiality.

We will also address the forces that undermine our ability to trust encryption such as bugs, design flaws and those who wish to actively undermine our need to maintain Secrecy.

Learning to Trust in a distributed system is a complex and harrowing process. By combining the notions of Identity and Secrecy we can build protocols that help us achieve it.

Technologies don't magically become solutions. They are used within domain, design and deployment contexts. This talk will focus on the singular notion of Trust and how it cross-cuts the distributed systems we are building.

This talk will focus on a variety of standards and technologies that help us connect the worlds of Identity, Secrecy and Integration. We will look at technologies that benefit from open standards to allow us to make and verify claims that strengthen our ability to Trust. This will also include a look at the Distributed Trust models such as Blockchain-based transactions and platforms that build upon them.

Being a professional software engineer, it's easy to fall into the belief that one's role in a company is to write code.
Another perspective might be that one's role is to solve problems for the business and that writing code is merely one of several tools available to help solve those problems.

There are numerous problem-solving “anti-patterns” that are rampant in the industry today. “Forewarned is forearmed” as they say. In addition to highlighting these “anti-patterns” with real-life examples and the (sometimes) disastrous consequences, Michael asks some of the difficult questions about our true motivations for our decisions and how our decisions can either positively or negatively affect our team and our organization.

Containers and Micro-service are like peanut butter and jelly, they just go together. However do you know how resources are managed in a container and how that affects your application. This session will dive into how Java is affected living under control groups.

This session will review containers, the underlying technology to containers along with different container runtimes such as Docker. We will look at the anatomy of a container including control groups (cgroups) and namespaces. This session will conclude with the challenges of running the JRE in a container and the impact that has on the efficiency of the process at scale.

TBA

Understand Java from a functional programming point of view. This part covers the basics of lambdas and streams, emphasizing functional programming by transforming collections using the stream approach.

Also includes method references and static and default methods in interfaces.

Functional features in Java, including parallel streams, the java.util.function package, the Optional data type, and reduction operations.

The talk also covers the new date and time package based on Joda time, as well as collectors and implementing the Collector interface.

Java SE 8 introduces many new features that can simplify your code. Using streams, lambdas, and the new Optional type all change the way we write Java. In this presentation, we'll work through a series of examples that show how to rewrite existing code from Java 7 or earlier using the new Java 8 approach.

Examples will include replacing anonymous inner classes with lambdas, switching from iterating over collections into transforming streams, using immutables wherever possible, lazy evaluation, and more.

Groovy is unusual among programming languages in that it doesn't seek to replace its predecessor. You can freely mix Groovy with Java on a class-by-class, or even line-by-line, basis. If you are working with Java, there's no reason not to make your life easier by adding Groovy where it helps the most.

Groovy helps Java in many ways, especially when processing XML or JSON data, replacing anonymous inner classes, adding tons of library methods that Java has needed all along, vastly simplified file and database manipulation, and much more. This talk will demonstrate how you can add Groovy to Java applications and simplify your development job immediately.

On the NFJS tour, there are questions that seem to come up again and again. One common example is “How do we determine which new tools and technologies we should focus our energy on learning?” another is “How do we stop management from forcing us to cut corners on every release so we can create better and more maintainable code?” which, after awhile becomes “How can we best convince management we need to rewrite the business application?”

There is a single metaanswer to all these questions and many others.

It begins with the understanding that what we as engineers value, and what the business values are often very different (even if the ultimate goals are the same) By being able to understand these different perspectives it's possible to begin to frame our arguments around the needs and the wants of the business. This alone will make any engineer significantly more effective.

This session picks up from where “Stop writing code and start solving problems” stops discussing what is value, how do we align the values of the business with the needs and values of the engineer.

When you hear the term “Internet of Things (IoT)” what do you think of? From a customer perspective it is a bunch of cool gadgets. From the datacenter perspective IoT == the onslaught of data and previously unprecedented scale.

This presentation is provide a walk through of the technologies necessary to dynamically create in data pipelines and process them for near real-time access to analytics.

This presentation will provide an overview of the Lambda architecture along with a brief walk through of each of the components of a common IoT datacenter infrastructure. Topics to include:

AKKA
Kakfa
HDFS
Spark
Cassandra
Mesos / DCOS

Brief mentions of Hive, Storm and InfluxDB included.

A look into Java memory including Metaspace and garbage collectors including G1.

This session will look at the Java monitoring and management capabilities, which includes the ability to make VM argument changes on the fly. This session will dive into the different memory compartments including details on Metaspace and how they are used by the JVM. Finally this session will explore the different GC options and how they affect response times and throughput.

Spark Streaming
Kafka
Cassandra
Mesos

Spark Streaming
Kafka
Cassandra

An introduction to Apache Myriad on Mesos which provides the flexibility to increase or decrease Hadoop resources on the fly.

The current demands on the datacenter require a dynamic environment to succeed. The legacy approach of static clusters limits overall cluster utilization and does not allow for the growth demands of different versions of the analytic clusters. There is an increasing need to integrate big data and related Apache Hadoop applications with other datacenter services, ideally, by co-locating the data in HDFS/HBase with the services that need it.

In this talk, Ken (one of the committers on project) will show off Apache Myriad, which integrates Apache YARN with Apache Mesos. Mesos enables efficient resource sharing and isolation across a variety of distributed applications. This allows Apache Hadoop workloads to run alongside other datacenter applications, while sharing the same cluster, and hence breaking silos. This multi-tenancy strategy improves overall cluster utilization and operational efficiency.

This is a revised and updated version of the previous talk, with current thinking from practice and the literature. The talk presents why conflicts with your manager are inevitable based on differences in priorities and perspectives, and how to plan for them. The goal is to show you how to build the loyalty relationship that allows you to get what you need when you need it.

Topics covered will include diagnosing communication styles, lessons from game theory, working within the organizational hierarchy, and lessons on how to build a relationship with your manager that still allows you the freedom to express yourself and what you really want.

Unlock your latent photographic memory. In this session you'll learn failsafe techniques and systems that allow you to never forget names, appointments, or numbers. In the process you'll be more effective and imaginative at work; improve reading speed and comprehension, and shorten study times.

An improved memory will change your life, literally. In the session we will describe in detail several memory techniques that, with a little practice, will have you remembering virtually anything you want.

You've heard the old adage “It's not what you know it's who you know.” The focus of this session is divided between ways to better connect with everyone you meet as well as ways to grow your network, help and influence people and ultimately build long-term relationships and build your reputation.

Networking isn't about selling nor it isn't about “taking.” Done properly it benefits everyone. Among the benefits are strengthening relationships; getting new perspectives and ideas; building a reputation of being knowledgable, reliable and supportive; having access to opportunities and more!

Slides available online: https://prezi.com/ck1fdbhgqwiq/?token=8f8240f753ad9ae2c50ce696657020f40a877a40fa224790652eb412ac5eb8d3

In this session, we will take a look at Angular - the powerful MVVM SPA framework from Google. We will discuss some of the terminology that Angular offers, and see how we can use that to develop highly interactive, dynamic web applications. See “Detail” for a list of topics I cover and the Github repo URL

In this session we will take a look at Angular and using it to develop rich web applications. Angular embraces HTML and CSS, allowing you to extend HTML towards your application, and uses plain JavaScript which makes your code easy to reuse, and test.

Note: This is an intro level talk. It is targeted towards developers who are curious about Angular and want to learn about the fundamental features and concepts in Angular.

Topics Covered -

Bootstrapping an AngularJS application using ng-app
ng-init and the evaluation {{ }} directive
A brief look at $rootScope and scoping rules
ng-model
Controllers, Dependency Injection, and the View-Model
Looping using ng-repeat
Forms using ng-form, form validation and submission in AngularJS
ng-messages to display form validation messages to the user
Angular provided filters and custom filters

GitHub URL - https://github.com/looselytyped/angudone-workshop/tree/solutions

In this session we continue our discussion from Part I. As we continue to evolve our application we will seek to use, and understand a few more of AngularJS' core constructs.

Factories and services
Routing using ng-view and $routeProvider
AJAX calls to a backend using $http

If time permits we will look at a few good practices when developing AngularJS applications, ways to modularize your code, and some tools that aid in the development of AngularJS applications.

In today's world, our applications need to be both responsive, fast and scalable. Our applications need to respond to user interactions such as mouse movements, clicks and inputs as well as asynchronous inputs like XHR calls, server sent events, setInterval, even web socket events! Unfortunately as things stand today, there is no consistent way to deal with the myriad of different “changes” that could happen in an application.

But what if there is? This is what Reactive Extensions (specifially RxJs in this session) allow us to do. It offers us an abstraction that allows us to treat everything from DOM events (infinite streams) to our domain (maps, sets and arrays) as streams. This consistent interface now permits us to create and manipulate any source identically. Futhermore, it allows us to react to different sources as if they are one!

Reactive Extensions are fast becoming the de-facto approach of managing asynchronicity in JS land. From Netflix's UI to Angular 2 $http to ES7 - reactive programming is everywhere!

This session is RxJs 101, covering

A brief introduction to reactive programming
How reactive programming is analogous to dataflow programming
The architectural patterns underlying reactive extensions
How we can create and manipulate “observable” streams within our applications
Error handling
Hot and Cold observables
The reactive landscape, and a couple of gotcha

If we have time we will look at a simple demo, and reactive progamming's role in Angular 2

In this session we will look at some JavaScript patterns, and how you can use them within your code.

No longer can you think of JavaScript as a kiddie-scripting language. JavaScript has now been promoted to a first-class citizen within your application - and with this, comes the need to think of better abstractions, code re-use - even thinking of establishing a common vocabulary to discuss approaches to writing better, cleaner and ultimately more maintainable JavaScript code.

In some organizations, architects are dismissed as people that draw box and arrow diagrams - the dreaded whiteboard architect. While we don't want to foster that stereotype, it is important for an architect to be able to construct basic architectural diagrams. An architect must also be able to separate the wheat from the chaff eliminating those models that don't help tell the story while fully leveraging those that do.

In this workshop, we'll discuss the various diagrams at our disposal. We'll walk through a case study and as we go, we'll construct a set of diagrams that will help us effectively communicate our design. We'll talk about stakeholders and who might benefit from each type of diagram. Additionally we'll discuss how to constructively review an architectural model.

Workshop Requirements

Neither a laptop nor special software is required for this workshop though your modeling tool of choice (Spark, Visio, OmniGraffle, etc.) is welcome for the exercises. Of course paper and pencil are very effective too and frankly recommended! Feel free to work in pairs or teams. That's it! Well, and a willingness to participate!

Workshop Requirements

Functional programming (FP) is fast becoming the tool that programmers reach for in this era of multi-core processors. Although the definition of “functional” varies quite a bit between implementations, there are a few facets that remain core and true to the paradigm. Facets such as functions as first-class, higher order functions, closures etc. In this session we will explore the meaning of these using JavaScript as our medium.

Why JavaScript? The answer in short is: omnipresence. The long answer is that hiding at the core of JavaScript is a language that is not only beautiful and elegant, but one that supports many of the core ideas in FP. If you are interested in what the fuss is all about, or are confused about some of the concepts that make FP a reality, then this is the session you should attend.

A set various tools to write reactive, concurrent, fault-tolerant applications and services using immutable data, asynchronous message passing using local and remote actors, software transactional memory, and supervised systems. This entire presentation is done in Java.

Akka is a set of various tools to write reactive, concurrent, fault-tolerant applications and services using immutable data, asynchronous message passing using local and remote actors, software transactional memory, and supervised systems.

Akka is also part of the Typesafe stack, a stack that include the Play web framework, Spray, Slick, and the Scala programming language. This Akka presentation will cover Java style usage of Akka with actors, asynchronous message passing, supervision, and streams

It seems like Continuous Delivery (CD) and DevOps are everywhere, but there's not very much information about how to get started. Are they just hype? Rebranding of the same old thing? In this hands on technical session, Ken Mugrage shows the benefits of practicing Continuous Delivery and adopting a DevOps culture, backed by industry studies and peer reviewed scientific research. Ken starts with how the need for CD developed, and then fed the need for culture change to support the practices. Delegates start a provided virtual machine with everything needed for the workshop. The group then configures a complete continuous delivery pipeline from source code commit through deployment. Delegates learn when to run each common type of automated test for the fastest possible feedback, as well as how to run tests in parallel for shorter cycle times. Participants in this workshop learn how to design and create a continuous delivery pipeline from the ground up.

This workshop is designed for software professionals, however no Continuous Delivery or DevOps experience is required. Delegates should bring a laptop with the latest versions of Virtualbox and Vagrant installed.

What if we could measure the indirect costs of pain building up on a software project? What if we could measure the effects of learning curves, collaboration pain, and problems building up in the code?

With visibility we can:

Identify the biggest causes of pain
Make the case to management for improvement
Optimize productivity with a data-driven feedback loop

We've been trying to explain the problems of Technical Debt for generations, but we've never been able to measure it. By measuring the “friction” in a developer's “Idea Flow”, we can see the effects of disruptions, test maintenance, confusing code, unfamiliar code, and collaboration problems. They all have a direct impact on developer experience.

In this talk, we'll discuss what is “Idea Flow”, how we can measure it, then we'll talk through the implications for our teams, our organizations, and our industry.

I.flow() AI is an emotional intelligence AI that learns to respond in real-time to the pain of humans, for example, developers that are having a hard time. The I.flow() AI Platform is still in the early stages of mapping theory to concrete implementation, so in this talk we'll breakdown architecture strategy, pain metrics, pair programming buddy, supply chain flows, and the underpinning of Flow theory.

Flow is an old concept, adopted into the software world by mapping Flow from Lean manufacturing. When we map a metaphor between two different domains, our brain locks onto the isomorphisms between contexts, and “Flow” becomes stickies flowing on a whiteboard, or features flowing out to customers. It becomes difficult to see Flow any other way.

What if our object-oriented blinders led to an object-oriented notion of Flow, and there's a totally different way to look at the system? Flow, at it's core, is a paradigm shift, a metaphorical lens, that helps us see, understand, and predict the behavior of any Flow System. Better predictive models, enables AI automation like we've never had before. It's about time we started applying AI to our own problems.

Inspired by success stories from companies such as Amazon and Netflix, many organizations are moving towards microservice architectures at a brisk pace. This session provides a thorough overview of the pros and cons for microservice architectures, when it is applicable, and some nascent best practices.

Microservice architecture is important because it’s the first architecture to fully embrace the Continuous Delivery and DevOps revolutions. In this session, I cover the motivations for building a microservice architecture (including making the distinction between “regular SOA” and microservices), some considerations you must make before starting (such as transactions versus eventual consistency), how to determine service partition boundaries, and ten tips to dowse you towards success. I also discuss the role of polyglot development, enterprise governance, how data and databases fit into this new world, and tooling to help ensure consistency between core services like logging and monitoring. This session provides a thorough overview of the pros and cons for microservice architectures, when it is applicable, and some nascent best practices.

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. This talk discusses using the radar for personal breadth development, architectural guidance, and governance.

ThoughtWorks Technical Advisory Board creates a “technology radar” twice a year, a working document that helps the company make decisions about interesting technologies and where we spend our time. ThoughtWorks then started conducting radar-building exercises for our clients, which provides a great medium for technologists company-wide to express their opinions about the technologies they use every day. For companies, creating a radar helps you document your technology decisions in a standard format, evaluate technology decisions in an actionable way, and create cross-silo discussions about suitable technology choices. This session describes the radar visualization and how to conduct a radar building session for yourself. After a brief introduction, the bulk of the workshop consists of attendees building a radar for the group, following the same procedure you'll use when you do this exercise at your company. At the end, we'll have created a unique Radar for this event and practiced doing it for yourself.

Greater Atlanta Software Symposium

September 16 - 18, 2016

Workshop Requirements

Workshop Requirements

Workshop Requirements

Workshop Requirements

TEST