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)

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 2 Agenda

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

There are many different uses for Apache Kafka. It can be used as a streaming broker, event broker for transactional data, and even a database. This session is about understanding streaming architecture and how to implement it using Apache Kafka. I start this session by talking about some of the streaming architecture patterns, then dive into how Apache Kafka works using the Core API. Using live coding examples in Apache Kafka, I also talk about the differences between Kafka and regular messaging (RabbitMQ, ActiveMQ, etc.) and when you should use each. I end this session by putting everything together, showing an actual streaming architecture using Kafka within a Microservice ecosystem for gathering various metrics for business and operational monitoring and reporting.

Agenda:

• Streaming architecture patterns
• Kafka overview
• Kafka producers and consumers
• Kafka vs. standard messaging
• Streaming examples in a microservices ecosystem

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

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

One of the expectations of any software architect is to analyze the current technology environment and recommend solutions for improvement. This is otherwise known as continually assessing architecture vitality. Too many times software architects fail to regularly perform this task, leading to emergency refactoring efforts to save a troubled system from failure. The question is, what does it mean to assess an application architecture? In this session we will explore static analysis metrics and tools and techniques for leveraging those metrics for determining structural decay. Using a real-world large-scale application, I'll show you how to leverage code metrics to find (and fix) structural decay before it gets you into trouble.

Agenda

• Architecture and structural decay
• Architecturally significant code metrics and what they mean
• Interpreting results and tracking metrics
• Code analysis tools and how to use them
• Real-world hands-on architecture analysis using tools and metrics

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.

This talk will focus on interesting features of Java 8 that go beyond the basics. Topics will include:

• the map, filter, and flatMap methods
• simple reductions
• extracting and combining streams
• using Optional as intended
• grouping and partitioning
• downstream collectors
• the java.time package
• generics in detail

Sample code will be provided to illustrate all the techniques, along with tests and a build file.

Gradle is the build tool of choice in the open source world, and rapidly becoming the standard in industry as well. Anyone who works with Gradle on a Java project knows the basics of the Java plugin and how to write simple tasks in Groovy. Gradle can do much more, however. This talk will demonstrate how to write your own custom task classes and how to create Gradle plugins from them. Other Gradle features will be demonstrated as well, including file manipulation, incremental builds, generating the Grade wrapper, and resolving conflicts in dependencies.

Gradle Inc also provides a free build scan capability to analyze build files. This too will be demonstrated, as well as profiling your build, determining dependencies, and more.

JavaScript will celebrate it's 24th birthday in 2020. For a language that has been around for such a while it has seen very few, if any changes to the language itself. Well all that is about to change with ECMAScript.next (or ECMAScript 6). ECMAScript 6 modernizes JavaScript syntax, while bringing in features such as modules for better namespacing, class as a first class construct, and a variety of additional operators thus ensuring that JavaScript is ready for the next era of large scale modern web applications. ES 7, 8, 9 and now 10 all use the features introduced by ES6 to further the language.

In this session we will take a look at some of the features that ECMAScript 6 / 7 / 8 / 9 and 10 bring to the table. We will take an exploratory approach, and by the end of 3 hours, you will be well versed with ALL of the new features in JavaScript.

JavaScript will celebrate it's 24th birthday in 2020. For a language that has been around for such a while it has seen very few, if any changes to the language itself. Well all that is about to change with ECMAScript.next (or ECMAScript 6). ECMAScript 6 modernizes JavaScript syntax, while bringing in features such as modules for better namespacing, class as a first class construct, and a variety of additional operators thus ensuring that JavaScript is ready for the next era of large scale modern web applications. ES 7, 8, 9 and now 10 all use the features introduced by ES6 to further the language.

In this session we will take a look at some of the features that ECMAScript 6 / 7 / 8 / 9 and 10 bring to the table. We will take an exploratory approach, and by the end of 3 hours, you will be well versed with ALL of the new features in JavaScript.

Redux has fast become one the pillars for state management in the modern era of web application developments. Though tiny, it packs a punch, and in this session we will explore the principles behind redux and see how to use it in our web applications.

TBD

In this session we will take a look at building applications with Angular. We will build a very simple application from the ground up, and attempt to understand the approach of Angular, as well as understand some of the terminology that Angular introduces.

This session will focus on the Angular 10

TypeScript, Components, Annotations/Directives, Observables, Reactive Stores, Model-Driven forms … Oh my! Angular, much like AngularJs (1.x.x), despite being a powerful platform for building rich client side applications, comes laden with both new terminology, and a “newer” approach to writing client side code.

In this session, as we build a simple application, we will attempt to tease apart these concepts, slowly building our understanding towards how these pieces come together, and how we can leverage them to build rich client side application.

Details

• Quick overview of what Angular has to offer, how it is different from Angular 1.x
• A glance at the project we are going to build, and all the important files that angular-cli generates
• Create our first component
• Proceed with creating a component hierarchy to display all hard coded data

Along the way we will see how to use the Angular style guide to follow conventions adopted by the Angular community at large, and some ways to use the angular-cli tool.

In this session we will take a look at building applications with Angular. We will build a very simple application from the ground up, and attempt to understand the approach of Angular, as well as understand some of the terminology that Angular introduces.

This session will focus on the Angular 10

TypeScript, Components, Annotations/Directives, Observables, Reactive Stores, Model-Driven forms … Oh my! Angular, much like AngularJs (1.x.x), despite being a powerful platform for building rich client side applications, comes laden with both new terminology, and a “newer” approach to writing client side code.

In this session, as we build a simple application, we will attempt to tease apart these concepts, slowly building our understanding towards how these pieces come together, and how we can leverage them to build rich client side application.

Details

• Using in-build pipes in Angular
• Create our own pipe
• Create the necessary infrastructure to allow for HTTP Calls to the backend
• Load all the containers using Ajax
• Introduces routing, and update the homepage to navigate to these routes

Along the way we will see how to use the Angular style guide to follow conventions adopted by the Angular community at large, and some ways to use the angular-cli tool

In this session we will get acquainted with Docker. We will discuss what docker is, how to install it, and how to start using Docker. We will also explore some of the benefits of containerizing your applications.

Containers are taking over the world. Containers provide a means to have hermatic builds of your software, allowing for truly immutable testing, and delivery of your software. Docker is one of many containerization technologies, and in this session we will take a brief look at Docker and what it has to offer.

In this session we will dive deeper into Dockerfiles. We will explore the DSL that Dockerfiles provide to allow for the automation of image creation.

Dockerfiles provide a means to automate the creation of images, and consequently the containers within which our applications run. The Dockerfile, though minimal, provides us with everything we need to package our software, and enable it to run. In this session we will dive deep into the Docker DSL, and explore the many commands that it provides, and along the way explore some differences between similar commands, and some gotchas.

In this example-driven presentation, you'll learn how to leverage Spring Boot to accelerate application development, enabling you to focus coding on logic that drives application requirements with little concern for code that satisfies Spring's needs.

For over a decade, Spring has sought to make enterprise Java development easier. It began by offering a lighter alternative to EJBs, but continued to to address things such as security, working with various sorts of databases, cloud-native applications, and reactive programming. And, along the way, Spring even took steps to make itself easier to use, offering Java-based and automatic component configuration. Even so, there's still a lot of near-boilerplate code required to develop Spring applications.

Enter Spring Boot. Spring Boot's primary purpose is to make Spring easier to work with. It achieves this in three ways:

• Automatic configuration : Considering what's on the runtime classpath as well as other factors, Spring Boot can automatically configure components in a Spring application context.
• Simplified dependency management : Taking advantage of transitive dependency resolution at build-time, Spring Boot offers several “starter” dependencies, focused on specific characteristics of an application, that transitively bring in libraries to enable development of those characteristics.
• Runtime insight : Spring Boot offers insight into the inner workings of a running application via REST endpoints and/or JMX MBeans to better understand what makes a running application tick.

All together, Spring Boot lets you focus on fulfilling your application's requirements without worrying about writing code that satisfies the needs of a framework.

In this session, you'll learn how to take your Spring Boot skills to the next level, applying the latest features of Spring Boot. Topics may include Spring Boot DevTools, configuration properties and profiles, customizing the Actuator, and crafting your own starters and auto-configuration.

TBD

In this session, you'll learn how to use Spring Data to rapidly develop repositories for a variety of database types, including relational (JPA and JDBC), document (Mongo), graph (Neo4j), and others (Redis, Cassandra, CouchBase, etc).

For decades, relational databases and SQL have enjoyed their position as the leading choice for data persistence. Even though many alternative database types have emerged in recent years, the relational database is still a top choice for a general purposes data store and will not likely be usurped from its position any time soon. When it comes to working with relational data, Java developers have several options.

But relational databases are not a one-size-fits-all solution. Thankfully, there are many options for data persistence, including relational, document, graph, key-value, and column-store databases, each presenting their unique way of handling data suitable for different problems.

Spring Data makes it easy to work with various databases by offering a programming model that is consistent, regardless of which type of database you're working with. And regardless of the database you're dealing with, you will find that Spring Data eliminates a lot of boilerplate code.

In this session, you'll see how to take Spring Data's automatic repository generation to a whole new level. We'll look at ways to model data and manipulate Spring Data to produce repositories and APIs that are more than just CRUD layers on top of a database.

TBD

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.

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.

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.

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.

In Part 1, you learned the core principles of influence and persuasion. How to we take this back to the office and apply what we've learned?

We dive deep in to specific strategies to get both the team and the business on board with your ideas and solutions. We cover several realworld patterns you can follow to be more effective and more persuasive. Part 1 was conceptual, part 2 is practical.

Machine Learning is a huge, deep field. Come get a head start on how you can learn about how machines learn.

This talk will be an overview of the Machine Learning field. We’ll cover the various tools and techniques that are available to you to solve complex, data-driven problems. We’ll walk through the algorithms and apply them to some real but accessible problems so you can see them at work.

Documents contain a lot of information. We'll introduce you to a variety of techniques to extract them.

Machine Learning techniques are useful for analyzing numeric data, but they can also be useful for classifying text, extracting content and more. We will discuss a variety of open source tools for extracting the content, identifying elements and structure and analyzing the text can be used in distributed, microservice-friendly ways.

This open source machine learning framework from Google has taken off. Come learn what you can do with it in your own organization.

TensorFlow is a powerful data flow-oriented machine learning framework developed by Google's Brain Team. It was designed to be easy to use and widely applicable on both numeric, neural network-oriented problems as well as other domains. We'll cover the over view as well as apply it to several fun, realistic problems.

What happens if web applications got really fast?

We are increasingly able to do more in the browser because of faster networks, optimized JavaScript engines, new standard APIs and more. There is a new initiative to allow a binary format called WebAssembly that will provide a compiled, cross-platform representation that will take us to the next level. Complex business applications and 3D video games will alike will benefit from this new standard. Come hear about what it can do for you.

For the last 20-30 years, there has been a never-ending set of solutions for building cross-platform desktop applications. Most of them suck. Electron is one that doesn't.

It is a new solution that forms the basis of the Atom Editor, Microsoft's Visual Studio Code, the Slack app and more.

Come see what happens when you combine the best of the Web, Node.js and Chromium to provide attractive, modern, flexible, useful, consistent cross-platform desktop applications.

Electron grew out of the work on the Atom Editor from GitHub. Developers familiar with JavaScript, Node and Web Development will be comfortable with an engine that uses the same technologies as they move to the Desktop. At the same time, the Chromium engine, which has support for modern technologies such as WebGL, WebRTC and desktop-integration hooks, as well as HTML 5 and CSS, rounds out the platform. The strength of the Web mixed with native desktop integration hooks and the performance and flexibility of Node strikes the right balance for avoiding sucky cross-platform applications.

If Java 8 was all about how we code, Java 9 is all about how we will build. Modularization will have the biggest impact of any change that happened in Java since its inception. In this presentation we will learn about the need for modularization, how it impacts development, the rules to follow when creating modules, and the effect it has on legacy code.

We will explore creating module, using modules, readability, exports, automatic modules, and unnamed modules.

Reactive Programming in gaining a lot of excitement. Many libraries, tools, and frameworks are beginning to make use of reactive libraries. Besides, applications dealing with big data or high frequency data can benefit from this programming paradigm. Come to this presentation to learn about what reactive programming is, what kind of problems it solves, how it solves them. We will take an example oriented approach to learning the programming model and the abstraction.

Reactive Programming
Nature of Problems
Programming API
The Reactive Programming Abstraction
Examples

We all have seen our share of bad code and some really good code as well. What are some of the common anti patterns that seem to be recurring over and over in code that sucks? By learning about these code smells and avoiding them, we can greatly help make our code better.

Come to this talk to learn about some common code smell and to share your experiences as well.

The first part of the Continuous Delivery workshop covers the differences between continuous integration, continuous deployment, and continuous delivery). It also introduces the deployment pipeline_, along with usage, patterns, and anti-patterns. This part concludes with some applied engineering principles.

Releasing software to actual 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. Through automation of the build, deployment, and testing process, and improved collaboration between developers, testers and operations, delivery teams can get changes released in a matter of hours—sometimes even minutes—no matter what the size of a project or the complexity of its code base. The workshop materials are derived from the best selling book Continuous Delivery and creating in collaboration with the authors and other of my ThoughtWorks colleagues. Continuous Delivery details how to get fast feedback on the production readiness of your application every time there is a change—to code, infrastructure, or configuration.

The first part of the workshop describes the technical differences between related topics such as continuous integration, continuous deployment, and continuous delivery. 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 discuss the various stages, how triggering works, patterns and anti-patterns, and how to pragmatically determine what “production ready” means. This session also covers some agile principles espoused by the Continuous Delivery book, including new perspectives on things like developer workstations and configuration management.

Continuous Delivery relies on a variety of interlocking engineering practices to work efficiently; this session covers three related topics. First, I cover the role of testing and the testing quadrant. Second, I specifically cover version control usage and offer alternatives to feature branching like toggle and branch by abstraction. Third, I describe some incremental release strategies, along with their impact on other stages of project lifecycle.

Releasing software to actual 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. Through automation of the build, deployment, and testing process, and improved collaboration between developers, testers and operations, delivery teams can get changes released in a matter of hours—sometimes even minutes—no matter what the size of a project or the complexity of its code base. The workshop materials are derived from the best selling book Continuous Delivery and creating in collaboration with the authors and other of my ThoughtWorks colleagues. Continuous Delivery details how to get fast feedback on the production readiness of your application every time there is a change—to code, infrastructure, or configuration.

Continuous Delivery relies on a variety of interlocking engineering practices to work efficiently; this session covers three related topics. First, I cover the role of testing and the testing quadrant, including the audience and engineering practices around different types of tests. I also cover some best practices around testing, including testing ratios, code coverage, and other topics. Second, I specifically cover version control usage and offer alternatives to feature branching like toggle and branch by abstraction. Generally, I talk about building synergistic engineering practices that complement rather than conflict one another. In particular, I discuss why feature branching harms three other engineering practices and describe alternatives. Third, I describe some incremental release strategies, along with their impact on other stages of project lifecycle.

Two big stumbling blocks for Continuous Delivery adaptation are interactions with operations and the keepers of data. First in this session, I cover operations, DevOps, and programmatic control of infrastructure. Second, I discuss how to incorporate databases and DBA's into the Continuous Integration and Continuous Delivery process.

Releasing software to actual 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. Through automation of the build, deployment, and testing process, and improved collaboration between developers, testers and operations, delivery teams can get changes released in a matter of hours—sometimes even minutes—no matter what the size of a project or the complexity of its code base. The workshop materials are derived from the best selling book Continuous Delivery and creating in collaboration with the authors and other of my ThoughtWorks colleagues. Continuous Delivery details how to get fast feedback on the production readiness of your application every time there is a change—to code, infrastructure, or configuration.

Two big stumbling blocks for Continuous Delivery adaptation are interactions with operations and the keepers of data. First in this session, I cover operations, DevOps, and programmatic control of infrastructure using tools like Puppet and Chef. I also discuss the explosion of tool alternatives in this space, and cover some current-day best practices. Second, I discuss how to incorporate databases and DBA's into the Continuous Integration and Continuous Delivery process. This includes database migrations, strategies for enhancing collaboration between application development and data, and database refactoring techniques.

Cloud continues to grow in importance in even the most conservative companies’ IT strategies. Because of this, even experienced software architects must confront a new world in which many of our normal architectural assumptions no longer hold. Before we create architectures that leverage cloud infrastructure, we need to rebuild our mental model of infrastructure around the appropriate concepts and principles. The purpose of this session is to do just that.

In this session we’ll:

• tour the current cloud infrastructure landscape
• explore the key business and technology motivators for adopting cloud
• explore the unique aspects of cloud infrastructure that violate our traditional assumptions
• examine the risks associated with adopting cloud infrastructure
• navigate some of the key tradeoffs involved with cloud architecture choices
• overlay traditional architecture patterns and examine their suitability to cloud
• define a cloud native architecture that is optimized to exploit the uniqueness of the cloud environment

The learner should leave this session prepared for deeper dives into cloud native architecture patterns and migration strategies.

NOTE: We'll cover roughly 50% of the material in Part 1.

Cloud continues to grow in importance in even the most conservative companies’ IT strategies. Because of this, even experienced software architects must confront a new world in which many of our normal architectural assumptions no longer hold. Before we create architectures that leverage cloud infrastructure, we need to rebuild our mental model of infrastructure around the appropriate concepts and principles. The purpose of this session is to do just that.

In this session we’ll:

• tour the current cloud infrastructure landscape
• explore the key business and technology motivators for adopting cloud
• explore the unique aspects of cloud infrastructure that violate our traditional assumptions
• examine the risks associated with adopting cloud infrastructure
• navigate some of the key tradeoffs involved with cloud architecture choices
• overlay traditional architecture patterns and examine their suitability to cloud
• define a cloud native architecture that is optimized to exploit the uniqueness of the cloud environment

The learner should leave this session prepared for deeper dives into cloud native architecture patterns and migration strategies.

NOTE: We'll cover roughly 50% of the material in Part 1. If you come to only Part 2, we'll be starting in the middle.

On the 2017 tour, I introduced the notion of “serverless” and Functions as a Service (FaaS) platforms. We understood the motivation for serverless computing, compared serverless to other cloud-native infrastructure approaches, navigated some architectural tradeoffs, and took a whirlwind tour of the Big 3 FaaS providers.

In this 2018 edition of the talk, we’ll still cover a few of the same themes to bring new folks up to speed, but we’ll also look at what’s changed in this ecosystem over the past year, take a look at new or enhanced features, offerings, runtimes, and programming models, and examine what use cases are becoming popular for serverless computing. We’ll also look at how tradeoffs have evolved, and definitely throw in a few demos.

Chaos Engineering, pioneered by Netflix, is the discipline of experimenting on a distributed system in order to build confidence in the system's capability to withstand turbulent conditions in production.

In this presentation, we'll take a look at the problem of building resilient software, and discuss how applying Google's SRE principles and patterns for architectural resiliency can help us to solve it. We'll then examine how the practice of Chaos Engineering can help us to prove or disprove the resiliency of our systems.

Traditional approaches to software architecture do not address the core tenet of all agile practices - feedback! We make many of the most important architectural decisions early in the development lifecycle and fail to get accurate feedback on those decisions throughout implementation. Compounding the problem? Agile methods offer no architectural advice. This session explores several architectural practices that help increase architectural agility.

What’s the goal of architecture? To serve as a blueprint of the system that everyone understands? Possess the flexibility to evolve as new requirements emerge? To satisfy the architectural qualities, including performance, security, availability, reliability, and scalability? Yes. Yes. Yes. At the heart of these three questions are the three pillars of architecture - social, process, and structure. But how do we create software architectures that achieves all of these goals? And how do we ensure no disconnect occurs between developers responsible for implementation and architects responsible for the vision? In this session, we’ll explore several principles to increase architectural agility and provide some actionable advice that will help you get started immediately.

Recently, microservices have take the development community by storm. Though a modern architectural paradigm, the underlying principles of microservices are embedded across many proven traditional architectural approaches, especially modularity. At the end of the day, microservices are just one way to the increase modularity of our software system. But there are others.

In this session we will examine several different ways to modularize large software systems. We'll start with the “modular monolith” and demonstrate how this modular monolith gives us a significant degree of architectural agility to evolve the architecture to microservices by incrementally breaking pieces of the application off and deploying them as microservices.

Microservice architecture is a modern architectural approach that focuses on breaking apart the monolith and building modular services. But the framework we use has a tremendous impact on how we build and deploy services. A new type of framework has emerged that provides a lightweight stack for building microservices.

In this session, we will explore some modern Java micro frameworks for building microservices. Example frameworks you may see include Dropwizard, Spark, Ninja, RestExpress, Play, Restlet, and RestX.

The way we build and deliver software is changing. We must deliver software more quickly than ever before and traditional approaches to software architecture, infrastructure and methodology do not allow us to meet demand. We’ve reached the limits of agility through process improvement alone, and further increases demand we focus on improving architecture, infrastructure, and methodology simultaneously. 12 Factor is an app development methodology for building modern apps in the modern era.

Building modern apps requires modern methods and 12 Factor is an app development methodology that helps development teams build software by emphasizing development practices that meld together modern architectural paradigms with agile practices like continuous delivery for deployment to cloud platforms. In this session, we’ll examine the 12 Factors and explore how to apply them to apps built using Java.

You have some modular code with a REST API. You are on your way to Microservices. Next, you package it in a container image that others can run. Simple. Now what? Your service needs to log information, needs to scale and load balance between its clones. Your service needs environment and metadata way outside its context. What about where the service will run? Who starts it? What monitors its health? What about antifragility? Updates? Networking? Oh my.

Don't get flustered. We will explore how Kubernetes simplifies the complexity of distributed computing.

This session will help you understand the terms, architecture and the mechanics of the Kubernetes tools. You will understand how to target your applications to a seemingly complex distributed compute platform.

Prerequisite: If you are unfamiliar with Kubernetes be sure to attend: Kubernetes Koncepts (1 of 2)

Aha moments with apps in containers can be quite liberating. The mobile space is saturated with “there's an app for that”. For us, we now expect “there's a container for that”. “Write once, run anywhere” (WORA) has changed to “Package once, run anywhere” (PORA). The growing community of containers is riding up the hype curve. We will look at many ways to assemble pods using architecture patterns you already know.

Your software package delivery and installation is no longer an rpm, deb, dmg, jar, war, native executable or a run script, it is simply an image that has a common run container command.

During the presentation, we will explore some examples on Katacoda.

Java 8 is pretty great, but mix in JavaSlang (now called Vavr) and get ready for some functional programming excitement.

JavaSlang is a project that decorates Java with immutable data structures, better Optionals, tuples, and more. Now with JavaSlang (Vavr) we can really bring in some more power to functional programming and Java. We will even discuss some new concepts like for comprehensions, Try, and Either!

Kafka has captured mindshare in the data records streaming market, and in this presentation, we knock on its door and see what lies behind. What is the draw? What makes it an attractive addition? How does it compare to Message Queues and other message streaming services?

We will do a thorough introduction into what is Kafka. We will also discuss Consumers, Producers, Streams. Integration with ZooKeeper, and discuss the performance aspect of using Kafka.

Our jobs usually deal with something other than new code. It is usually old spaghetti and difficult-to-read code. How do we test such code? How do we get through it? How can we surgically remove and make some of this harmful code testable?

This session looks at lousy code, and we talk about some strategies we can do to diagnose, test, apply, and finally refactor to produce something that would promote some sanity in your development process. We can do much with our code to make it better and testable while avoiding extensive mocking. The content of this course is all in Java and JUnit.

Workshop Requirements

• JDK 11+
• Maven 3.8.x
• IDE (I will be using IntelliJ)

Continuous delivery is not a pipe-dream technology, reserved only for the “cool kids” at hip tech startups. Although it's not easy, many concepts are within reach of most teams. That being said, it require more than simple technology changes. Attend this session to learn the fundamental concepts of CD, how to build your CD pipeline with Gradle and Jenkins, and recommendations on tools and best practices.

No prior knowledge is assumed and this talk will start from first principles.

Part one begins with a detailed overview of what CD is (and isn't) and how to build a business case for CD. Making both the technical case and business case for CD is vital as it's necessary to get the entire organization on board with the changes required.

Part two is a deeper dive into building a continuous delivery pipeline with Gradle and Jenkins (although the broader concepts can be applied to the tooling of your choice) You'll see how easily Gradle integrates with Java and how to leverage configuration management and gradle plugins to build all of your quality gates.

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.

The silent and deadly competitor to React and Angular. Meet Elm. All functional and client language. Clean

This presentation discusses Elm, how to set up Elm and use it to design a better web client using tenets of functional programming. We discuss some of the simple ideas of the language and talk about how it uses its own MVC style architecture. Other items include:

• Functions
• Function Application
• Modules
• Currying
• Records
• Commands
• Subscriptions
• Tasks
• Elm Architecture

With the advancement of AI, the paradigm shift of blockchain, the media war for the Internet, and escalating emotion, it's time to explore brand new territory – using software as a metaphor to construct a functional model of the human mind. Imagine your brain's logic is written in code. You fire up the debugger, set a breakpoint in the “Self” class, and inspect your brain's internal state. What are the state variables? What does the code look like? How do we fix the bugs?

I.flow() is a theory of consciousness that models motivation behavior of humans using software as a metaphor, because… why not? From the origin of gut feel reasoning, to the feedback loops that drive you, we'll breakdown the functional architecture that makes the universe tick.

I.flow() is the underpinning theory behind MetaOS, the generalized AI platform being pioneered by Open Mastery. In an age where everything is changing faster than ever, and the magic of sci-fi novels is coming to life – we're faced with some of the most difficult questions about what it means to be human:

Who am I? What do I live for? What is the purpose of life?

“I.choose() therefore I.am()”

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.

In this session, we'll use I.flow() AI as a metaphorical lens to explore the world of philosophy.
Each one of us is on a journey to discover who we are, why we're here, and what it all means. I.flow() Emotional Intelligence AI evolved as a result of deep self-reflection, in the search for an authentic self, and the courage to live an authentic life.

“I.choose() therefore I.am()”

This session is a collection of life reflections and lessons learned, codified into diagrams and code abstractions using I.flow() AI. We'll start with the assumption that life is a video game, and humans are the AI. We'll break down models for human relationships, different ways of being in the world, and discuss the meaning of the game of life.

If you are someone that delights in a great philosophical discussion over dinner, you won't want to miss this talk.

In this session, we'll explore the new reactive features in Spring 5 to build reactive, non-blocking applications using Spring's familiar programming model.

Traditionally, applications have been built using a blocking, synchronous model. Although comfortable and intuitive for most programmers, this model doesn't scale well. And although there are several new approaches to reactive programming, they don't necessarily fit into the familiar programming model that Spring developers are accustomed to working with.

Spring 5 has introduced a set of new reactive features, enabling non-blocking, asynchronous code that scales well using minimal threads. Moreover, it builds on the same concepts and programming models that Spring developers have used for years.

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.

Encryption is great, especially when it works.

You put a lot of trust that the encryption offered by browsers, frameworks and libraries is giving you the protection you need to exchange sensitive information over the web. E-commerce, remote shells, bearer token-based authorization schemes and more would not be possible without technologies like the Transport Layer Security (TLS). Come listen to how it works, how it breaks and how you can become more confident that it does what you think it does.

Big data applications have entire different demands than typical CRUD applications that have ruled the enterprise for decades. When dealing with high frequency and high volume of data, we have to reach to a different set of tools than we have been used to.

The objective of this presentation is to first discuss the issues with dealing with big data and high performance computing. Then we will take a look at libraries and tools that can more easily help us address those issues.

Prerequisite: If you are unfamiliar with Kubernetes be sure to attend: Kubernetes Koncepts

At the 2009 Agile conference, J.B.Rainsberger declared “Integration tests are a scam”. I agree. Come see some compelling reasons why consumer-driven contract testing is a much better approach. Particularly for microservices.

We will explore different testing techniques on Kubernetes, including an important one called “Consumer-Driven Contracts”.

After a brief overview of the concepts a live demonstration will show you how to:

1. set up a Pact Broker on Kubernetes
2. write a consumer that defines and publishes Pact contracts
3. deploy and run a few Spring Boot microservices on Kubernetes
4. connect microservices to a database and public data source
5. verify the consumer pacts against a producer
6. find API defects and fix them

This is the droid you are looking for. Within this droid are hundreds of rules designed to review your code for defects, hotspots and security weaknesses. Consider the resulting analysis as humble feedback from a personal advisor. The rules come from your community of peers, all designed to save your butt.

We will explore techniques on how to add these checks to your IDE, your build scripts and your build pipelines.

Too much chatter in your pull requests? See how the analysis tools teach best practices, without ego or criticism, to a spectrum of developers. As a leader see how to develop an effective code quality intern program around this technique. We will also see some techniques to use Kubernetes to obtain reports and dashboards right on your local machine and from your continuous integration pipeline.

In this session we will explore the router that ships with Angular. We will see how to leverage its power and flexibility to build real world applications.

Angular ships with a powerful new router. One that allows you to manage your application state, allow for things like nested and child views, as well as loading modules on demand. If you have complex workflows and you wish to learn the new way of navigating your Angular application, this is the session for you.

In this session we will explore how the dependency injector works in Angular2.

Angular has always leverages DI, and along with all the benefits that come with DI. In Angular2 (much like Angular1) there is no escaping the dependency injection mechanism. Though like everything else in Angular2, there is more here than meets the eye. We will take a deep dive into Angular's DI in this session, first seeing some of the benefits of DI, and some of the gotchas

For those still grappling with Generics. This will be an attempt to clear the air about generics. What are wildcards? What is extends? What is super?  What is covariance? What is contravariance? What is invariance? What is erasure? Why and when do I need this?

Generics or parameterized type is one of the more pain items in any statically typed language on the JVM. This presentation is set to overcome some of these hurdles and understand some of these confusing terms. We will cover the following:

• Covariance
• Contravariance
• Invariance
• Erasure
• Generic Assignments
• Weird Generic Funky Stuf
• Use-Site vs. Declaration-Site Variance
• Differences between Java vs. Scala vs. Kotlin