Docker and containers are getting a lot of attention these days but what do they mean for devs? How do they fit into DevOps and continuous delivery movements? Where do these tools fit into cloud computing? During this hands-on session we will learn how to install and configure Docker, build images and run containers in a local development environment. But we will also explore using them in a continuous deployment environment by deploying them to on premise as well as cloud services such as AWS.

• Setting Up Docker
• Creating Docker Machines
• Docker Lifecycle
• Finding & Running Containers
• Creating Images
• Linking Containers
• Sharing Images
• Composing
• Using the Docker API
• Private Repositories
• Swarm
• Kubernetes
• Cloud (Digital Ocean, AWS)
• Summary
• Resources

Workshop Requirements

• Docker Community Edition (mac or windows) - https://www.docker.com/community-edition#/download or Docker Toolbox - https://www.docker.com/products/docker-toolbox
• (optional) minikube - https://kubernetes.io/docs/tasks/tools/install-minikube/

Docker and containers are getting a lot of attention these days but what do they mean for devs? How do they fit into DevOps and continuous delivery movements? Where do these tools fit into cloud computing? During this hands-on session we will learn how to install and configure Docker, build images and run containers in a local development environment. But we will also explore using them in a continuous deployment environment by deploying them to on premise as well as cloud services such as AWS.

• Setting Up Docker
• Creating Docker Machines
• Docker Lifecycle
• Finding & Running Containers
• Creating Images
• Linking Containers
• Sharing Images
• Composing
• Using the Docker API
• Private Repositories
• Swarm
• Kubernetes
• Cloud (Digital Ocean, AWS)
• Summary
• Resources

Workshop Requirements

• Docker Community Edition (mac or windows) - https://www.docker.com/community-edition#/download or Docker Toolbox - https://www.docker.com/products/docker-toolbox
• (optional) minikube - https://kubernetes.io/docs/tasks/tools/install-minikube/

Tired of trying to manage and maintain servers? Never have a large enough operations team? Don’t have a budget for running lots of server? Don’t want to pay for servers siting idle? Afraid you might become so popular that you won’t be able to scale fast enough? Don’t worry, it is possible to alleviate these issues by moving to a serverless architecture that utilizes microservices hosted in the cloud. This type of architecture can support all different types of clients including web, mobile and IoT.

During this hands-on workshop, you will build a serverless application utilizing AWS services such as Lambda, API Gateway, S3 and a datastore.

During this session you will build a simple web application utilizing AWS services and Angular.

Workshop Requirements

• Editor supporting Java and/or JavaScript
• nodejs (https://nodejs.org)
• AWS CLI (https://aws.amazon.com/cli/)
• Clone Git Repositories
  https://github.com/cjudd/giftube-lambda.git
  https://github.com/cjudd/giftube.git
• AWS account is optional

Tired of trying to manage and maintain servers? Never have a large enough operations team? Don’t have a budget for running lots of server? Don’t want to pay for servers siting idle? Afraid you might become so popular that you won’t be able to scale fast enough? Don’t worry, it is possible to alleviate these issues by moving to a serverless architecture that utilizes microservices hosted in the cloud. This type of architecture can support all different types of clients including web, mobile and IoT.

During this hands-on workshop, you will build a serverless application utilizing AWS services such as Lambda, API Gateway, S3 and a datastore.

During this session you will build a simple web application utilizing AWS services and Angular.

Workshop Requirements

• Editor supporting Java and/or JavaScript
• nodejs (https://nodejs.org)
• AWS CLI (https://aws.amazon.com/cli/)
• Clone Git Repositories
  https://github.com/cjudd/giftube-lambda.git
  https://github.com/cjudd/giftube.git
• AWS account is optional

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.

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.

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

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.

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 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 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.

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.

Now that we’ve been equipped with an understanding of how software architectures can exploit the unique aspects of cloud infrastructure environments, it’s time to construct a pattern catalog that can guide our decision making as we journey from concepts and principles to concrete implementations. The software industry has long been motivated by the promise of a “component marketplace” from which we can draw commodity components which can be composed via standardized mechanisms to create powerful systems. These systems are often compared to the myriad of possible creations that can be produced using Lego pieces. The power in the Lego “architecture” is found in the amazing diversity of individual pieces that are composed via a universal system of compatibility. Cloud native architectures approximate the same power via Lego-like patterns.

In this two-part series, we’ll divide the cloud native patterns into two categories:

1. Bricks - how we design cloud native services
2. Mortar - how we compose cloud native systems

In part one we’ll study “Brick Patterns” from the following categories:

• Externalized Configuration
• Externalized State
• Externalized Channels
• Runtime Reconfiguration
• Continuous Delivery via Multi-Version Concurrent Execution
• Brick Telemetry

The learner should leave this session prepared to design and implement cloud native “bricks” that can be composed via any “master builder” of cloud native solutions.

Now that we’ve been equipped with an understanding of how software architectures can exploit the unique aspects of cloud infrastructure environments, it’s time to construct a pattern catalog that can guide our decision making as we journey from concepts and principles to concrete implementations. The software industry has long been motivated by the promise of a “component marketplace” from which we can draw commodity components which can be composed via standardized mechanisms to create powerful systems. These systems are often compared to the myriad of possible creations that can be produced using Lego pieces. The power in the Lego “architecture” is found in the amazing diversity of individual pieces that are composed via a universal system of compatibility. Cloud native architectures approximate the same power via Lego-like patterns.

In this two-part series, we’ll divide the cloud native patterns into two categories:

1. Bricks - how we design cloud native services
2. Mortar - how we compose cloud native systems

In part one we’ll study “Mortar Patterns” from the following categories:

• Service Discovery
• Edge Gateways
• Fault Tolerance
• Event-Driven Systems
• Contract Management
• Integration Telemetry

The learner should leave this session prepared to compose cloud native solutions from any available collection of cloud native “bricks.”

If you’ve been following along, you’ve realized by now that cloud native architectures are fundamentally different than most traditional architectures. Most of the cloud native architectures that we can see in the wild have been built by relatively young companies that began from a zero-legacy state. Architects in more mature organizations are faced with the daunting challenge of building modern systems that exploit the unique characteristics of cloud infrastructure while simultaneously attempting to migrate legacy systems into those same environments, all the while “keeping the lights on.”

Much of the last two years of my career have been spent helping Fortune 500 companies devise cloud native migration strategies, and I’ve built a increasingly large catalog of patterns that have proven useful across multiple systems and industry verticals. In this session we’ll dive into those patterns and more, including:

• the utility of cloud native maturity models
• the cloud continuum: cloud ready, cloud friendly, cloud resilient, cloud native
• the app continuum: evolving toward distributed systems
• criteria for selecting applications to migrate
• the occasionally palatable perils of “lift and shift”
• applying the Strangler Pattern
• leveraging strategic domain-driven design: bounded contexts, context maps, and anti-corruption layers
• insulating from “irreplaceable” legacy systems of record with hexagonal architecture

The learner should leave this session with a tool belt suitable for attacking an upcoming cloud native architecture migration effort.

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.

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

In this sessions we'll see how to use components of Spring Cloud to configure and discover microservices in a cloud native microservice-architected application. Specifically, we'll look at Spring Cloud Netflix and Netflix' Eureka and Ribbon projects for service discovery as well as the Spring Cloud Config project's configuration server to provide a central point of external configuration.

Microservice-architecture presents many benefits, not the least of which include opportunities to develop, evolve, scale, test, and deploy individual modules of an application independently from the rest of the application. But once an application is broken apart, a new set of challenges arises.

If the individual microservices are to work together in service of the greater application, then they must know about each other. Rather than hardcode the specifics of each microservice within every other microservice, it's better to provide a registry with which a service can register and other services may use to lookup those service details.

Microservices, like any application, will also likely depend on application-level configuration. It's generally a good idea to keep that configuration separate from the application itself, and this is even more true with microservices. Using a centralized configuration service, microservices can obtain their configuration details, some of which may be shared across many microservices. Because it is separate from the application/microservice code, that configuration itself can be versioned and evolve at a pace independent of the microservices it serves.

In this session, we'll look at how to monitor the health of individual services in a microservice-architected application as well as trace the path of data and processing as it flows from service to service. Specifically, we'll look at Spring Cloud Netflix and Netflix OSS' Hystrix project to not only apply the circuit breaker pattern for failure and latency protection to microservices and monitor the health of those circuit breakers in a running application. Additionally, we'll look at Spring Cloud Sleuth and Zipkin to trace processing through a microservice-based application.

Microservice-architecture presents many benefits, not the least of which include opportunities to develop, evolve, scale, test, and deploy individual modules of an application independently from the rest of the application. But once an application is broken apart, a new set of challenges arises.

Failure is always a possibility in any application. But when an application is composed of microservices, it's important for that each service contain its failure and keep its problems to itself to avoid cascading errors to other services. Likewise, latency can be a concern that is compounded when felt across multiple microservices and it's important to avoid cascading latency issues. By applying the circuit breaker pattern in your microservices, you can ensure that if anything goes wrong in a given service, it stays in that service and doesn't have any negative impacts to other services. Moreover, metrics published by those circuit breakers can provide helpful insight into the health of an application.

When things do go wrong, it may also be helpful to trace the flow and processing of information as it passes from one microservice to another. Traditionally, tracing involves following the logs of a single application. But in a microservice-based application where many services and many instances of those services are involved, tracing is much more challenging. What's needed is a way for microservices to submit timing and tracing information to a central tracing service that coordinates that data and can present the flow of data in a single, easily digested view.

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.

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.

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.

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.

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.

Unlike earlier languages, Java had a well-defined threading and memory model from the beginning. And over the years, Java gained new packages to help solve concurrency problems.

Despite this, Java concurrency is sometimes subtle and fraught with peril.

In this talk, you'll learn these subtleties. And finally, you'll learn how to handle concurrency by exploring the concepts behind java.util.concurrent and other concurrency libraries.

Today, we all benefit from the sophistication of modern compilers and hardware, but that extra complexity can also make it difficult to reason about performance.

In this talk, we'll examine some surprising performance cases and learn how to
use profiling and benchmarking tools to better understand our modern execution environments.

HotSpot provides a variety of garbage collectors with a variety of strengths and weaknesses. To get the most out of our applications, we need to pick the right garbage collector and design to take advantage of its strengths and avoid its
weaknesses.

In this presentation, you'll learn about criteria for picking a garbage collector, how to measure GC performance, and how to write code that works with rather than against the GC.

Everyone worries about performance but few of us have the time to truly understand it. Fortunately, our modern JVMs and CPUs are capable of some amazing performance tricks, but those same tricks only make reasoning about performance that much harder.

In this talk, we'll take a look at some surprising and often unintuitive performance problems and solutions. Not simply with the goal of memorizing solutions but also to better understand the complexity that lies inside both JVMs and CPUs.

Everyone worries about performance but few of us have the time to truly understand it. Fortunately, our modern JVMs and CPUs are capable of some amazing performance tricks, but those same tricks only make reasoning about performance that much harder.

In this talk, we'll take a look at some surprising and often unintuitive performance problems and solutions. But not simply with the goal of memorizing solutions, but to better understand the complexity that lies inside both JVMs and CPUs.

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.

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.

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

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

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.

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

In this presentation, we'll build, test, and deploy an image-processing pipeline using Amazon Web Services such as Lambda, API Gateway, Step Functions, DynamoDB, and Rekognition.

We'll take a look at some of the following topics:

• Describing serverless deployments with SAM
• Testing lambda functions with SAM Local
• Interacting with AWS API's from lambda functions
• Configuring IAM policies for lambda functions
• Describing workflows of functions with Step Functions
• Deploying with Cloud Formation

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.

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.

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.

For the last several years, the JavaScript world has been awash in various Model-View-Whatever frameworks and libraries with new implementations popping up like bunnies. With the popular React library, Facebook took a different approach to developing JavaScript user interfaces by focusing on the View in MV*. This talk will get you up and running on React, a library that gives us a declarative approach to designing highly performant interactive user interfaces. We'll dive into the basics of components, JSX, the virtual DOM and more. By the end of this session you'll have a solid foundation in what React brings to the table and how it might help you on your next project.

For the last several years, the JavaScript world has been awash in various Model-View-Whatever frameworks and libraries with new implementations popping up like bunnies. With the popular React library, Facebook took a different approach to developing JavaScript user interfaces by focusing on the View in MV*. This talk will get you up and running on React, a library that gives us a declarative approach to designing highly performant interactive user interfaces. We'll dive into the basics of components, JSX, the virtual DOM and more. By the end of this session you'll have a solid foundation in what React brings to the table and how it might help you on your next project.

As a developer, your focus was squarely on the “functional requirements” aka the business capabilities your application must meet. But once you step in the architect role, you discover a world inhabited by “the ilities” otherwise known as the non functional or quality attributes of a software system. But how do we know which ilities matter and which ones don't? And much as we may want to turn every knob up to 11, many ilities are inversely related - maximize one and you by definition minimize another.

In this talk we will look at various architectural problems giving participants opportunities to try and balance non functional requirements. We'll discuss the consequences of various approaches as well as how we can best document the inevitable decisions we arrive at.

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!

Like all languages, Groovy code can be written in many different ways. This talk will review how to write Groovy that follows the most commonly accepted idioms and practices, especially in light of the changes in Java 8. Features demonstrates will include closures, class and method definitions that best accommodate Java integration, testing techniques, and more.

Groovy is, relatively speaking, a mature language on the JVM. Adding it to existing Java systems is easy. Following the recommended practices helps make maintenance and extensibility practical.

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.

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.

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.

In this session we will look to see how we can refactor our learning - what tools, and methodologies can we use to help us learn quicker and better - how we can create a store that gives us quick access to information when we really need it.

We all work in an industry in which not only do the tools that we use change ever few years, but one in which we have to shift the very paradigms these tools are built on! Even the most trivial of projects entails tens of different toolkits, frameworks, and languages coming together, and somehow we need to know how to leverage each one. How does one keep up? Despite all our years in schools, and our in-born nature to learn, we often are never taught how to learn. How can we learn faster, and retain even more?

In this session we will take a look at various tools and techniques available to us and see how we can make our learning effective.

Think back over your career as a software developer. How many great–and I mean truly great–software developers have you worked with? The chances are you can count them on one hand? Developers with 20-30 years experience can rarely name more than two or three. What does it take to be considered truly great? Michael can certainly tell you what NOT to do… from cold, bitter experience.

Ego Driven Development is a humorous and brutally honest look at a career spanning nearly two decades. We dive into war stories, train wrecks and so many misguided attempts at greatness. There is a path to becoming a truly great software engineer, but it's not always where we first look.

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

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.