Java is a language in evolution. There are a handful of language changes in Java 9 and 10 plus several JDK changes in 9, 10, 11, and 12. Some of these changes are significant in that they allow us to do things more effectively than before. The difference can be anywhere from reducing code to avoiding errors that come from verbosity. In this presentation we will explore the language changes first. Then we will visit the additions to the JDK. Along the way we will also look at a few things that have been removed from Java as well.

.

We will program with Java quite differently in the future than we do today. The reason is that Java is embracing asynchronous programming like never before. This will have a huge impact on how we create services and web applications. In this presentations we will look at what asynchronous programming is, what continuations are, how they get implemented under the hood, and how we can benefit from them.

.

Java Modules are the future. However, our enterprise applications have legacy code, a lots of it. How in the world do we migrate from the old to the new? What are some of the challenges. In this presentation we will start with an introduction to modules and learn how to create them. Then we will dive into the differences between unnamed modules, automatic modules, and explicit modules. After that we will discuss some key limitations of modules, things that may surprise your developers if they're not aware of. Finally we will discuss how to migrate current applications to use modules.

.

A lot of software development seems to be concerned with finding answers; troubleshooting issues; solving problems. But what if we’re not asking the right questions? Learning to ask the right questions in the various contexts in which we work is one of the key, yet underemphasized skills that any competent engineer should have!

In this session, we’ll examine several critical questions that you should keep in your toolbox. You can use these questions to evaluate tool and technology selection decisions, architecture strategy, data modeling decisions, and more. You should walk away with this session feeling equipped to engage in “adult conversations” about software engineering, where we cut through the hype and focus on the tradeoff decisions before us.

So what are the questions? Well, you’ll just have to come to the session to find out. But if you browse through my Twitter stream, you just might find a few.

NOTE: THIS IS A DISCUSSION ORIENTED SESSION. THERE WILL BE MINIMAL LECTURE AND SLIDES.

According to Wikipedia, metaphysics is the branch of philosophy that studies the essence of a thing. This definition invites the question, “Does software design have an essence?” And if it does, would the discovery and understanding of this essence lead to a fundamental improvement in our ability to build well-designed software? Does design matter? What exactly is the design of software? Can we point to it? Or is it something immaterial?

These are the types of questions that I want to confront in this session. We’ll draw inspiration from various individuals, from Don Norman to Fred Brooks to Jack Reeves to Christopher Alexander. We’ll consider their explorations of design, both in and out of the software realm. But ultimately, we’re going to have a conversation inspired by the Dialogues of Plato, and each iteration of this session will arrive at its own conclusions.

As an architectural style, microservices are here to stay. They have crossed the proverbial chasm, and now it’s time to get to work. Microservices provide us with the ability to create truly evolutionary architectures composed of cohesive and autonomous components using well known and characterized distributed systems patterns.
As we create and compose components across the hard boundary of the network, we become deeply interested in establishing the correct boundaries and has resulted in renewed interest in system design and decomposition. Fortunately, the tried and true practices of Domain-Driven Design are available to us.

In this presentation, we will cover a distillation of strategic (bounded contexts, subdomains, context mapping) and tactical (aggregates, domain events) DDD techniques and demonstrate how they enable us to create effective event-driven microservices.

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, we'll explore the Spring Boot Actuator, a runtime component of Spring Boot that lets you peer inside a running application and, in some cases, even tweak configuration on the fly. We'll look at many of the Actuator's endpoints, learn how to customize and even create new endpoints, and see how to expose Actuator metrics to several popular instrumentation and monitoring systems.

Spring Boot makes developing applications with Spring easy work by offering auto-configuration for many common application scenarios. And with Spring Boot's starter dependencies, even an application's build file can be easily managed. But Spring Boot's powers don't end when the application is deployed. That's where the real fun begins.

All software architectures have to deal with stress. It’s simply the way the world works! Stressors come from multiple directions, including changes in the marketplace, business models, and customer demand, as well as infrastructure failures, improper or unexpected inputs, and bugs. As software architects, one of our jobs is to create solutions that meet both business and quality requirements while appropriately handling stress.

We typically approach stressors by trying to create solutions that are robust. Robust systems can continue functioning properly in the presence of internal and external challenges, but they also have one or more breaking points. When we pass a robust systems known threshold for a particular type of stress, it will fail. When a system encounters an “unknown unknown” challenge, it will usually not be robust!

Recent years have seen new approaches, including resilient, antifragile, and evolutionary architectures. All of these approaches emphasize the notion of adapting to changing conditions in order to not only survive stress but sometimes to benefit from it. In this class, we’ll examine together the theory and practice behind these architectural approaches.

Connascence is a term coined by Meilir Page-Jones in his article “Comparing Techniques by
Means of Encapsulation and Connascence.” It is a software quality metric that attempts to measure coupling between entities in three dimensions: strength, locality, and degree. Rather than describing architectural coupling as simply loose or tight, connascence gives us a tool to describe and measure the huge diversity in coupling that we encounter in systems. Relatedly, it also gives us a tool for encouraging high cohesion within modules.

Connascence can also be divided into static and dynamic categories, with a long list of specific types such as connascence of name, meaning, timing and identity.

Page-Jones gives us a rule to follow, “Eliminate any unnecessary connascence and then minimize connascence across encapsulation boundaries by maximizing connascence within encapsulation boundaries,” which he says can be applied to “any future design paradigm with partitioning, encapsulation and visibility rules.”

In this session, we’ll examine connascence as it appears within architectural patterns such as REST, message-driven collaboration, and microservices, as well as within various serialization techniques. You’ll walk away with tools to help you better describe and manage coupling within your system architectures.

These days, you can’t swing a dry erase marker without hitting someone talking about microservices. Developers are studying Eric Evan’s prescient book Domain Driven Design. Teams are refactoring monolithic apps, looking for bounded contexts and defining a ubiquitous language. And while there have been countless articles, videos, and talks to help you convert to microservices, few have spent any appreciable time asking if a given application should be a microservice. In this talk, I will show you a set of factors you can apply to help you decide if something deserves to be a microservice or not. We’ll also look at what we need to do to maintain a healthy micro(services)biome.

There are many good reasons to use a microservices architecture. But there are no free lunches. The positives of microservices come with added complexity. Teams should happily take on that complexity…provided the application in question benefits from the upside of microservices. This talk will cut through the hype to help you make the right choice for your unique situation.

Every organization has at least a phalanx or two in the “Cloud” and it is, understandably changing the way we architect our systems. But your application portfolio is full of “heritage” systems that hail from the time before everything was as a service. Not all of those applications will make it to the valley beyond, how do you grapple with your legacy portfolio? This talk will explore the strategies, tools and techniques you can apply as you evolve towards a cloud native future.

In this talk, you will learn:

• how to evaluate your legacy applications
• how to take those heritage systems to the Cloud
• what 12 Factors means for you
• where it makes sense to use microservices
• what tools and services you'll need to add to your repertoire

By now I bet your company has hundreds, maybe thousands of services, heck you might even consider some of them micro is stature! And while many organizations have plowed headlong down this particular architectural path, your spidey sense might be tingling…how do we keep this ecosystem healthy?

In this talk, I will go beyond the buzzwords into the nitty gritty of actually succeeding with a service based architecture. We will cover the principles and practices that will make sure your systems are stable and resilient while allowing you to get a decent night's sleep!

Rich Hickey once said programmers know the benefits of everything and the trade offs of nothing…an approach that can lead a project down a path of frustrated developers and unhappy customers. As architects though, we must consider the trade offs of every new library, language, pattern or approach and quickly make decisions often with incomplete information. How should we think about the inevitable technology choices we have to make on a project? How do we balance competing agendas? How do we keep our team happy and excited without chasing every new thing that someone finds on the inner webs?

As architects it is our responsibility to effectively guide our teams on the technology journey. In this talk I will outline the importance of trade offs, how we can analyze new technologies and how we can effectively capture the inevitable architectural decisions we will make. I will also explore the value of fitness functions as a way of ensuring the decisions we make are actually reflected in the code base.

Some developers simply hate type inference. And then there others who love it. Neither one of them is entirely right. In Java we have been making extensive use of type inference for several years without realizing it. The introduction of “var” in Java 10 has stirred up some surprising debate. In this presentation we will step back and review type inference in Java. Then we will dive deep into type inference in Java 10 and 11. We will wrap up the presentation will good recommendations on when to use type inference and when to avoid it.

.

Functional style of programming was introduced in Java 8. If you are like the speaker, who spent decades on imperative style, then the transition to functional style can be intimidating. In this presentation, we will learn about the fundamentals of programming in functional style, the set of tools that we can reach into to solve problems as a series of state transformation. We will learn the how but also the benefits along the way as well.

.

Based on the book with the same title as this talk, this presentation will explore the modern features of JavaScript that make this a pleasant language to use. Come to this presentation to get a quick jumpstart on the elegant capabilities from passing arguments, to creating iterators, to destructring, and working with classes using ES 6 and beyond.

.

JavaScript modules are highly powerful but an be confusing with the number of options available to explore and import. In this presentation we will take a through look at what modules are, how to export from a module, how to import, and the dos and don'ts. This will help you get comfortable with modules as you develop applications with JavaScript libraries/frameworks, like Angular, React, Vue, etc.

.

In this session we will build a full application using Vue.js. We will start by discussing how you can start working with Vue, all the way to seeing what it takes to build an app with Vue, including state management and routing.

Note: We'll be covering Vue version 3

Vue.js, the new kid on the JavaScript framework block is taking the world by storm. Vue has bypassed React in their count of Github stars, alluding to how popular this framework is starting to become. Vue attempts to provide just enough support with libraries like Vuex and the Vue Router, and tooling like the Vue CLI to get developers productive, without aiming to be too opinionated, and too flexible.

If you are curious about Vue, this is the session for you. Come in for 180 minutes of a thrill ride as we explore this fascinating new framework and mindset.

Note: We'll be covering Vue version 3

In this session we will build a full application using Vue.js. We will start by discussing how you can start working with Vue, all the way to seeing what it takes to build an app with Vue, including state management and routing.

Note: We'll be covering Vue version 3

Vue.js, the new kid on the JavaScript framework block is taking the world by storm. Vue has bypassed React in their count of Github stars, alluding to how popular this framework is starting to become. Vue attempts to provide just enough support with libraries like Vuex and the Vue Router, and tooling like the Vue CLI to get developers productive, without aiming to be too opinionated, and too flexible.

If you are curious about Vue, this is the session for you. Come in for 180 minutes of a thrill ride as we explore this fascinating new framework and mindset.

Note: We'll be covering Vue version 3

In this session we will take a gander around the tools and techniques that have evolved around testing Vue applications. Vue testing requires that we understand a set of newer technologies to help test our Vue components, events, routes (using Vue-Router) and state (using Vuex).

We all realize we must test our code, right? Testing our Vue applications isn't only about ensuring it works correctly, but also tests give us the confidence that we truly understand our applications.

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.

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.

“Forewarned is forearmed”
-Old Proverb

If it seems like humans are easy to deceive, it's because we are. The myriad traits that make humankind so eminently exploitable are practically baked into our DNA. Too often these same traits make it into the software we build. This session takes an entertaining look at why humans are so easy to fool and goes on to explore what we can do to overcome our weaknesses and build more secure software.

Security is everyone's responsibility but the burden disproportionally falls on us. As software engineers, we are the last line of defense in our organization. We build the technology and that technology is constantly scanned, probed, and tested. Building truly secure software requires going beyond mere functional requirements; it requires a complete shift in how we think about problems.

In this example-driven presentation, we'll look at Spring Data REST, an extension to Spring Data that exposes your data repositories as a RESTful API, complete with hypermedia links. We'll start with essential Spring Data REST, but then go beyond the basics to see how to customize the resulting API to be more than just CRUD operations over HTTP.

Spring Data is a brilliant extension to the Spring Framework that makes simple work of exposing a database–any kind of database–via repositories. But as is often the case, your application's data doesn't usually stay within the application. It is consumed by external applications or from a Javascript client in the web browser. That means, we'll need to build a RESTful API around those repositories.

In this session, we'll explore Spring Security and OAuth2, including building an OAuth2 authorization server, fronting an API with a resource server, and verifying an OAuth2 access token's claims to ensure that the client is allowed to access the resource they are asking for.

Securing REST APIs presents some unique challenges as compared to securing a typical web application. The client of any REST endpoint may not even be a user in the traditional sense, but is more likely to be another application or a browser-based Javascript client. How can you ensure that the clients of your REST API are allowed to access the resources they are asking for?

OAuth2 offers a means by which a client application can request authorization to access a resource and be given an access token that must be presenting when making HTTP requests. This involves creating an authorization server that issues tokens and defining a resource server which acts as a wall around an API that verifies the presented access token's claims before allowing the request to proceed.

Spring Security has historically supported OAuth2 as part of a separate project called Spring Security for OAuth. But gradually, Spring's OAuth2 support is moving into the main Spring Security project.

The way we communicate with our applications is an ever-evolving experience. Punch cards gave way to keyboards. Typing on keyboards was then supplemented by pointing and clicking with a mouse. And touch screens on our phones, tablets, and computers are now a common means of communicating with applications.

These all lack one thing, however: They aren’t natural.

As humans, we often communicate with each other through speech. If you were to walk up to another human and start tapping them, you’d likely be tapped (or punched) in response. But when we talk to our applications, we communicate on the machine’s terms, with keyboards, mice, and touch screens. Even though we may use these same devices to communicate with other humans, it’s really the machine we are communicating with—​and those machines relay what we type, click, and tap to another human using a similar device.

Voice user-interfaces (Voice UIs) enable us to communicate with our application in a human way. They give our applications the means to communicate to us on our terms, using voice. With a voice UI, we can converse with our applications in much the same way we might talk with our friends.

Voice UIs are truly the next logical step in the evolution of human-computer interaction. And this evolutionary step is long overdue. For as long as most of us can remember, science fiction has promised us the ability to talk to our computers. The robot from Lost in Space, the Enterprise computer on Star Trek, Iron Man’s Jarvis, and HAL 9000 (okay, maybe a bad example) are just a few well-recognized examples of science fiction promising a future where humans and computers would talk to each other.

Our computers are far more powerful today than the writers of science fiction would have imagined. And the tablet that Captain Picard used in his ready room on Star Trek: The Next Generation is now available with the iPad and other tablet devices. But only recently have voice assistants such as Alexa and Google Assistant given us the talking computer promised to us by science-fiction.

In this example-driven session, we'll explore the Alexa Skills Kit (ASK) and see how to develop skills for Amazon's Alexa. You'll learn how to use the ASK CLI to jumpstart skill development and how to create conversational applications in NodeJS.

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.

Deep Learning is an evolution of the capabilities of more conventional machine learning to take advantage of the extra data available from Big Data systems. With more data, many of the manual aspects of feature selection and other machine learning steps can be derived automatically. We will highlight many of the main deep learning frameworks and give you a hands on introduction to what is possible and how you can start to use them.

We will cover:

• Basic Neural networks
• Recurrent neural networks
• Convolutional neural networks
• Deep Learning frameworks such as TensorFlow, Pytorch, H20, DeepLearning4J and more.

What comes after machine learning and deep learning? How about dynamic systems that need new ways of finding paths through complex scenarios such as video games, challenging board games and more.

In addition to covering the main ideas of deep reinforcement learning, we will cover some of the main tools and frameworks

• Ray
• OpenGym

An integral part to any DevOps effort involves automation. No longer do we wish to manage tens, hundreds or even thousands of servers by hand, even if that were possible. What we need is a programmatic way to create and configure servers, be those for local development, all the way to production.

This is where tools like Ansible come into play. Ansible offers us a way to define what our server configurations are to look like using plain-text, version-controlled configuration files.
Not only does this help with avoiding “snow-flakes”, but it promotes server configuration to participate in the SDLC, pulling server configuration closer to the developers.

In this session we will explore what Ansible has to offer, decipher the Ansible terminology, and run some examples to configure a local server.

Ansible, like Git, aims to be a simple tool.
The benefit here is that the level of abstraction that Ansible offers is paper-thin, with no complicated workflows, or opinions enforced by the tool itself.
The downside is that without a prescribed approach to Ansible, developing your playbooks often becomes a case of trial-and-error.

As engineers steeped in the DevOps mindset we must be able to use the tool effectively, allowing us to accelerate and shorten the lead time from development to production.

In this session we will take a look at some lessons learned when working with Ansible. Topics covered:

• Variables, variable lookup precedence, and the best way to use variables in your Ansible scripts
• Setting up Ansible to work locally, allowing for faster development, iteration and testing
• Laying out your inventory files, and positioning them to work best with group_vars and host_vars
• Thinking about the “hierarchy” of your infrastructure, and how best to use Ansible to reflect that hierarchy

We developers really like code.
Code, being plain-text, can be version-controlled, versioned, and follow a traditional SDLC lifecycle.
For the longest time however, we were forced to live with having most of our Ci/Cd and server configurations live outside of our codebases, often at the mercy of infrastructure/operations teams.

With the evolution of DevOps comes the notions of constructs like IaaC (Infrastructure-As-A-Code), and with Jenkins 2.0, we can now manage our Jenkins jobs configurations as code!

In this session we will explore the concept of “Pipelines-As-A-Code”, including the DSL that Jenkins offers, and how we can use this to configure Jenkins jobs via simple, version-controlled Jenkins files. We will see how we can create Jenkins jobs by autodiscovering repositories, as well as when we branch our code to create releases.

As developers we not only operate in different contexts, but also often have these different contexts interplay as part of our work.
Each of the tools that we use — version control systems like Git (along with collaborative tools like Github/Gitlab), IDE's like Eclipse/IntelliJ, build systems like Gradle, Ci/Cd tooling like Jenkins, IaaC tools like Ansible, the command line — all introduce context.

To be effective developers we need to know when to operate in a certain context, combine or tease apart how these contexts interplay.
Can you improve your release announcements if format your commit messages consistently? You bet!
How should your build tool interact with your version control system?
What does naming your files have to do with how you use your IDE?

This session will take a look at several of these contexts — it will attempt to discern between them, explore when you should separate them and when you attempt to bring them together.

With lots of examples, and lots of quizzes this session will definitely leave you thinking about a few things.

Many developers aspire to become architects. Some of us serve currently as architects while the rest of us may hope to become one some day. We all have worked with architects, some good, and some that could be better. What are the traits of a good architect? What are the skills and qualities we should pick to become a very good one?

Come to this presentation to learn about things that can make that journey to be a successful architect a pleasant one.

Design patterns are common place in OO programming. With the introduction of lambda expressions in languages like Java, one has to wonder about their influence on design patterns.

In this presentation we will take up some of the common design patterns and rework them using lambda expressions. We will also explore some other patterns that are not so common, but are quite useful ways to apply lambdas.

Creating code is easy, creating good code takes a lot of time, effort, discipline, and commitment. The code we create are truly the manifestations of our designs. Creating a lightweight design can help make the code more extensible and reusable.

In this presentation we will take an example oriented approach to look at some core design principles that can help us create better design and more maintainable code.

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.

Learn the basic syntax and semantics for the Kotlin programming language. Kotlin is an alternative JVM language that provides null safety, static typing, and powerful IDE support. This talk will emphasize the relationships between Kotlin and Java, highlighting the differences in types, functional programming, collections, and more.

Demonstrations will include:

• how to transform Kotlin code to view the equivalent Java
• how to work with classes, interfaces, and objects
• how to use collections, streams, and sequences

and much more.

Many new features have been added between the last Long Term Support release in Java 8 and the current one in Java 11. This talk will summarize many of those capabilities, from the Jigsaw implementation of JPMS to unmodifiable collections to local variable type inference and more. In addition to the basic code changes, the new six-month release schedule and associated licensing issues will be reviewed.

If, as anticipated, Java 12 is released in March and Java 13 in September, new features from those versions will also be included, even though they will break the joke in the title of this talk.

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.

The fundamental testing libraries in Java have undergone complete redesigns in the past few years. JUnit 5, known as JUnit Jupiter, redesigns the most well-known tool in all of testing. This talk will demonstrate the new features, how they are intended to be used, and discuss experimental ideas in the pipeline.

JUnit has been remarkably stable over the years and is one of the most widely adopted frameworks in the Java world. The latest version, JUnit 5, takes JUnit to the next level. Full of new features like conditional test execution, parametric testing, labeling and filtering tests, and more, it brings all the modern thinking on testing into the JUnit world. It also takes advantage of the functional features added to Java since version 8 to create a powerful, new library for testing your code.

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.

If you are interested in a different approach to writing your next micro-service, or are knee deep in the DevOps world with Kubernetes and Docker (both written using Go) you need to know go.

Come join me in a rather quick introduction to the language and it's merits and short-comings.

Micro-services, DevOps, command-line utilities — Go has been the catalyst in a quiet revolution happening right under our noses. Go, from Google, aims to be a language that is simple, with the aim of writing scalable and reliable software. Go brings a unique tilt to many aspects of language design, including enforcing a strict project structure, powerful tooling to support things like code-style enforcement, as well as “goroutines” to allow for concurrency.

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.

If you’ve spent any amount of time in the software field, you’ve undoubtably found yourself in a (potentially heated) discussion about the merits of one technology, language or framework versus another. And while you may have enjoyed the technical debate, as software professionals, we owe it to our customers (as well as our future selves) to make good decisions when it comes to picking one technology over another.

In this talk, I will explore what criteria we should consider when comparing technologies, how we can avoid burning platforms as well as what to do when we’ve reached a dead end. We will also apply these techniques to a current technology or two.

In this session we will see what Kubernetes is, what it has to offer, and what it takes to get started with it. We will take a look at the basics of Kubernetes, and a peek at its architecture. By the end of this session you will have enough knowledge to assess if you need Kubernetes, and start experimenting with it.

Kubernetes is fast becoming the de-factor orchestration and scheduling tool for organizations leveraging containers everywhere.

We live, and operate in a world where our services do not need to be available 24/7, but also respond to surges in demand, and scale down when demands are less.
Reactive systems, and reactive architectures have arisen to address this very concern.
Vert.x is a ployglot toolkit that makes writing reactive applications on the JVM possible.
With a non-blocking, event driven architecture, Vert.x can help you scale your application, leveraging the multi-threaded nature of the JVM, and the multi-core abilities of your hardware.

In this session we will take a look at Vert.x, it's programming model and architecture.
We will write some code, and explore the ecosystem around Vert.x, as well as discuss some of the gotchas that you might come across as you develop Vert.x applications.

Everyone knows security is important. Very few organizations have a robust and comprehensive sense of whose responsibility it is, however. The consequence is that they have duct-tapped systems and a Policy of Hope that there will be no issues. (Spoiler: there will be)

We will review the various roles that most organizations need to fill and how they overlap as well as what should and can be expected from each of them.

Good discussions are supposed to diverge from their intended path. Free association is a feature, not a bug, and helps you see new connections between ideas. Without structure, however, it can be difficult to add context to new ideas and understand how they relate to more immediate problems. This talk discusses the technique of mental bookmarks – how to remember where you were when a discussion diverged. In addition to giving you a reputation for having an amazing memory, the skill also helps with personal awareness in general.

To give the technique context, we'll look at the fractal nature of success – the way we tend to see our current environment in relative terms, always comparing ourselves to those slightly more successful and slightly less successful.

There's nothing new or exciting about relational databases. We abstract them away with ORMS, grudgingly write a query here or there, but generally try to forget about them entirely. Then the performance and scalability problems begin. “Shading, the secret ingredient to the web-scale sauce” often won't help us.

The database is at the heart of nearly every system we build. Reading data and writing data account for the majority of performance bottlenecks. When it comes to SQL and relational databases, the syntax is easy, but the concepts often aren't. The most important knowledge is not obvious but it is necessary to make the right design, query, and optimization decisions.

Indexing, a glimpse under the hood of the storage engine and the query optimizer, and some best practices are all you need to know bring your DB skills head and shoulders above your peers and ready to build bigger, better, faster apps.

In tech teams it's a constant firefight. We react. Then we react to the reaction… the cycle continues. In all this noise, in all this chaos, how do we move forward. How do we remain proactive?

A great leader must be an enabler for the team. At times this means insulating the team from the noise. At other times it means improving the environment for the team. At all times, however, it requires setting clear priorities and conditions for success.

This session is focused on the art of moving forward in even the noisiest environments.

The #1 fallacy of distributed computing is “The Network is Reliable.” Yet we still build web apps that 100% rely on a server and a network connection. What if we could build web apps that work, regardless of connection state? The promise and capabilities of Progressive Web Apps (PWAs) make this possible, and these capabilities are available today.

This session doesn't focus on a specific technology or backend technology; while those demonstrations are impressive, they are only useful for a handful of use-cases. Instead we look at architecture patterns and techniques that can work with any framework, any backend, and virtually any app.

In 2005 the way we built web applications changed when Google released Google Maps and the AJAX map canvas. This approach fundamentally changed how users expect to interact with web applications. Suddenly any app that sent postback after postback felt cumbersome and positively ancient.

Progressive web apps and offline capabilities are that next big shift. Soon any app that doesn't work offline is going to be as jarring and frustrating of a user experience as it would be to go back to a pre-ajax world. Don't let this be your app!

One of the biggest impediments to overall developer productivity and the overall success of the software organization is inefficient processes. Without the right tooling to get to the root of the problem, debugging build and test failures is incredibly frustrating and leads to delays in shipping software.

In this workshop, you’ll work through examples using Maven, Gradle, and Gradle Enterprise on our real data and that of some popular open source projects. You'll learn how to measure build speed and reliability, which metrics are important, how to apply these analyses to your own builds, and how to use build caching to make those builds dramatically faster enabling your team to achieve better developer productivity.

If you are interested in a different approach to writing your next micro-service, or are knee deep in the DevOps world with Kubernetes and Docker (both written using Go) you need to know go.

Come join me in a rather quick introduction to the language and it's merits and short-comings.

Micro-services, DevOps, command-line utilities — Go has been the catalyst in a quiet revolution happening right under our noses. Go, from Google, aims to be a language that is simple, with the aim of writing scalable and reliable software. Go brings a unique tilt to many aspects of language design, including enforcing a strict project structure, powerful tooling to support things like code-style enforcement, as well as “goroutines” to allow for concurrency.

While the Web itself has strong decentralized aspects to how it is used, the backend technologies are largely centralized. The naming systems, the routing systems and the traffic that all points back to the same place for a website are all centralized technologies. This creates both a liability as well as a control point.

In order to break free of some of these limitations, new technologies are emerging to provide a more decentralized approach to the Web.

This talk will walk you through some emerging technology to provide decentralized content storage and distribution, edge computing and more. We will touch upon the Interplanetary Filesystem, WebTorrent, Blockchain spin offs and more.

Jez Humble and David Farley unleashed a revolution with their prolific book “Continuous Delivery”, leading to the evolution of a movement aptly named DevOps.
DevOps is about bring development and operations closer together, letting developers manage their releases and operationalize their applications in production, leaving operations to do what they do best.

In this session what DevOps really entails — what does it mean to embrace DevOps, what changes should we be expecting, what kind of tooling should we be thinking about, and finally, see what are the benefits of embracing DevOps.

As new, shiny and interesting this architecture looks, its equally complicated and needs lots of
consideration. Beyond the technology challenges, microservice architectures require mental and organizational culture shifts to align with agility to deliver rapid changing business needs.
​So if you are thinking of moving to microservices this session will clear the pictur

Anyone considering microservice architectures should have these 4 Ws and a H in mind.​
Why microservices ,is it really a new concept ? Why itscomplicated?
​Where it began and where its going ?
​What all I need to get started and maintain it later on?
​Who are the players ?
​How can I make a smooth move to Microservices from monolith ?

Jamie Zawinski once said “Some people, when confronted with a problem, think “I know, I'll use regular expressions.” Now they have two problems.“. Many consider regular expressions to be indecipherable, but the truth is that every programmer should consider regular expressions an integral part of their toolkit. From the command line to your favorite text editor, from parsing user input to scraping HTML pages - once you know regular expressions you will find a use for them in almost every programming context.

In this session we will attempt to unriddle the mystery that regular expressions pose. We will start at the basics and work our way towards more complex expressions.

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.

Rust has quickly become an incredibly popular language with exceptional tooling, documentation and a renowned community that welcomes and helps those who are new. It is intended as a systems programming such as C/C++ but has modern functional capabilities and intentionally-designed safety features.

We will not assume knowledge of Rust and will introduce the major features of this modern systems programming language. This will include:

• The Rust memory model
• Traits and Generics
• Lifetimes
• Functional programming
• The Standard Library
• Concurrency

Come learn why Rust is one of the most popular and important programming languages of the 21st Century.

In this session, we'll explore the Spring Boot Actuator, a runtime component of Spring Boot that lets you peer inside a running application and, in some cases, even tweak configuration on the fly. We'll look at many of the Actuator's endpoints, learn how to customize and even create new endpoints, and see how to expose Actuator metrics to several popular instrumentation and monitoring systems.

Spring Boot makes developing applications with Spring easy work by offering auto-configuration for many common application scenarios. And with Spring Boot's starter dependencies, even an application's build file can be easily managed. But Spring Boot's powers don't end when the application is deployed. That's where the real fun begins.