In this session we will go further with DDD, considering aspects like aggregates, domain events, factories and repositories, and consider how DDD can be represented in architecture, be that hexagonal, REST or RPC.

If you need a deeper dive into DDD, then this is the session for you.

We live in a world of microservices. Yet, what is a microservice? What defines the boundaries of a microservice? How do we define the relationships between microservices? Thankfully domaindriven design gives us the concepts and practices to better design and decompose our services.

In this session we will consider many of the concepts of DDD — How bounded contexts use Ubiquitous language to model the domain, how context maps can be used to establish the interconnections between services as well aggregates and domains events, all of which will service us well as we go about creating our microservices.

The web is arguably the single most impactful revolution in human history (to date). By agreeing on a simple set of standards, we have collectively unlocked all the world's information. Documents can be discovered, retrieved, published, and shared so easily we don't even think about it.

Data, on the other hand, is a different story. Our data remains stuck in the 1980s. Locked in silos, each with a different format, interface, and conventions that must be interpreted by a human, parsed, mapped, and converted. Data is at the heart of many problems we solve today, and we produce data exponentially faster than we can consume it.

Today I can request any document from any server on the web. I need to know nothing about the underlying technology the server uses, nothing about how the information is stored or retrieved, and consume it instantly. We've been evolving those same capabilities with data over the past 20 years and the standards, tools, and technologies are reaching critical mass. The linked data revolution is now one that you can no longer ignore. Join us to see what you've been missing.

Completely Rewritten for 2023

Although the Resource-Oriented Architecture is one of the oldest and most successful distributed architectures, it remains poorly understood and often completely overlooked today.

Much of the microservices architecture pattern is focused on taking applications apart although seemingly everyone has different ideas on how to put things back together again.

In this session, we will start with a summary of the resource-oriented architecture along with it's strengths and weaknesses. Michael will share hard-earned, real-world experience applying ROA concepts to complex microservice environments to successfully build an infinitely scalable, extensible, and understandable system.

Mob Programming is a style of programming in which the entire team sits together and
works on a single task at a time. Teams that have worked this way have found that
many of the problems that plague normal development just melted away, possibly because communication and learning increases. Teams also find that the quality of their code increases. They find their capacity to create increases. However, the best part of all this is that teams end up being happier and more cohesive.

In this session we introduce the core concepts of mob programming and then get handson mobbing on a coding kata.

Integration, once a luxury, is now a necessity. Doing this well, however, continues to be elusive. Early attempts to build better distributed systems such as DCOM, CORBA, and SOAP were widely regarded as failures. Today the focus is on REST, RPC, and graphql style APIs.

Which is best? The goto answer for architects is, of course, “it depends.”

In this session, we look at the various API approaches, how they attempt to deal with the challenge of decoupling client from server, evolvability, extensibility, adaptability, composability.

The biggest challenge is that needs change over time, and APIs must necessarily evolve. Versioning is challenging, and breaking changes are inevitable. You'll leave this session with a highlevel understanding of these approach, their respective tradeoffs and ultimately how to align your API approach with your architectural and organizational goals.

I know what you are thinking. Another unit testing presentation/workshop? That is so early 2000s. But a lot has changed if you haven't been keeping up with the unit testing space recently. Frameworks such as Junit 5 and Mockito 3 have been updated significantly. New programming styles such as lamdas and reactive are becoming mainstream, changing how we test our code. We also have new frameworks for integration testing, such as Testcontainer.

Whether you're a unit testing veteran or a newbie, this hands-on workshop will give you the experience and confidence necessary to write unit tests today.

Workshop Requirements

Java 11+
Clone https://github.com/cjudd/modern-java-unit-testing-workshop
Intellij (preferred)

I know what you are thinking. Another unit testing presentation/workshop? That is so early 2000s. But a lot has changed if you haven't been keeping up with the unit testing space recently. Frameworks such as Junit 5 and Mockito 3 have been updated significantly. New programming styles such as lamdas and reactive are becoming mainstream, changing how we test our code. We also have new frameworks for integration testing, such as Testcontainer.

Whether you're a unit testing veteran or a newbie, this hands-on workshop will give you the experience and confidence necessary to write unit tests today.

Workshop Requirements

Java 11+
Clone https://github.com/cjudd/modern-java-unit-testing-workshop
Intellij (preferred)

You have been using Git for a while. You know how to stage and commit your work, create and delete branches and collaborate with your team members using remotes. But Git often leaves your confused — ever committed to your work to the wrong branch? Even worse, ever accidentally delete a branch that you needed to keep around? And what is God's good name is “Detached HEAD state”? Why tag commits, when we have branches? Is there a better work-flow than just using merges? What's the difference between a merge and a rebase?

The answer to all of these questions, and more, lies in the constitution of a commit, and the directed acyclic graph (DAG) that Git uses to manage your history. This, right here, is the key to understanding everything in Git.

In this hands-on workshop, we will level up your Git skills. We will foray into the underbelly of Git, and reveal the mystery behind the arcane interface that is the Git CLI.

By the end of this workshop, you will have a keen understanding on how best to use Git, as well as know how to dig yourself any prickly situation you might find yourself in. You will become your team's hero(ine). Most importantly, you will walk away with a keen appreciation of how beautiful and elegant Git really is.

You have been using Git for a while. You know how to stage and commit your work, create and delete branches and collaborate with your team members using remotes. But Git often leaves your confused — ever committed to your work to the wrong branch? Even worse, ever accidentally delete a branch that you needed to keep around? And what is God's good name is “Detached HEAD state”? Why tag commits, when we have branches? Is there a better work-flow than just using merges? What's the difference between a merge and a rebase?

The answer to all of these questions, and more, lies in the constitution of a commit, and the directed acyclic graph (DAG) that Git uses to manage your history. This, right here, is the key to understanding everything in Git.

In this hands-on workshop, we will level up your Git skills. We will foray into the underbelly of Git, and reveal the mystery behind the arcane interface that is the Git CLI.

By the end of this workshop, you will have a keen understanding on how best to use Git, as well as know how to dig yourself any prickly situation you might find yourself in. You will become your team's hero(ine). Most importantly, you will walk away with a keen appreciation of how beautiful and elegant Git really is.

Kubernetes has become the de-facto orchestrator for containers and now is the best way to start engaging with portable distributed computing. This workshop is for software application developers who want to understand what Kubernetes is all about and how it works. It can be a seemingly complex ecosystem full of terms, architectures, and misinformation. We will break it down so you have a solid understanding of how it works so you can start writing applications that run on this distributed platform.

We will cover many topics such as:

• Rise of Kubernetes and containers
• Terms and architecture
• What does it give me?
• App Patterns on Kubernetes
• Building, deploying, serving, and observing apps on Kubernetes.
• Hands on labs

Kubernetes has become the de-facto orchestrator for containers and now is the best way to start engaging with portable distributed computing. This workshop is for software application developers who want to understand what Kubernetes is all about and how it works. It can be a seemingly complex ecosystem full of terms, architectures, and misinformation. We will break it down so you have a solid understanding of how it works so you can start writing applications that run on this distributed platform.

We will cover many topics such as:

• Rise of Kubernetes and containers
• Terms and architecture
• What does it give me?
• App Patterns on Kubernetes
• Building, deploying, serving, and observing apps on Kubernetes.
• Hands on labs

In recent years the development of the Java language has accelerated significantly. Some of the more recent features are quite exciting and can lead to better modeling, fewer errors, less verbosity, and better developer productivity. In this presentation we will take a close look at these features and their significance. We will use concrete examples as use cases to explore the modern features. In addition to looking at these features we will also take a look under the hood at how these are implemented. This will help us to gain a better understanding of the builtin efficiencies these features come with.

Get ready to take part in some live coding as we dive into these amazing features.

Have you looked at the methods of CompletableFuture and wondered how to actually use them? Do the function names appears strange or at least different from what we're used to. Let's take another look so those names become easier to remember and also to make use of.

In this presentation we will take a practical look at CompletableFuture and how to make good use of it, and how to deal with exceptions.

Functional and reactive programming is gaining popularity and use. One hurdle developers face using these approaches is in exception handling. Dealing with exceptions in these styles is confusing in the beginning and is often messy and error prone. In this presentation we will step back and take a closer look at exception handling, about the functional and reactive programming and discuss the dos and don'ts for exception handling. We will learn using concrete examples and live coding to illustrate the problem and the possible solutions.

We will explore options available in different languages and libraries and learn from them

Architecture is not a static representation of a system. There are several complexities and risks involved in creating them. One way to mitigate the risk is to evolve the architecture. But, there are risks of evolving as much as there are the risks of not evolving. In this interactive workshop we will explore a set of practices that we can use to mitigate the risks. Then we will dive into discussing some common and popular architectural patterns.

Finally, we will take some example applications and discuss how to evolve architecture to meet the needs of those applications.

Workshop Requirements

Computer with git client installed to access the version control system which will have lab related material.

Architecture is not a static representation of a system. There are several complexities and risks involved in creating them. One way to mitigate the risk is to evolve the architecture. But, there are risks of evolving as much as there are the risks of not evolving. In this interactive workshop we will explore a set of practices that we can use to mitigate the risks. Then we will dive into discussing some common and popular architectural patterns.

Finally, we will take some example applications and discuss how to evolve architecture to meet the needs of those applications.

Workshop Requirements

Computer with git client installed to access the version control system which will have lab related material.

There are some amazing features that are being introduced in Java in the coming years. Some of these features are just around the corner. However, these features, in various forms, have been in other languages for a while.

In this presentation we will take a look at some features in Kotlin, Scala, and JavaScript that are soon to be features of Java, understand their power and benefits and how we can make use of them. We will relate these features to how they are manifesting in Java.

The power of Java's functional programming goes far beyond lambdas and the filter, map of the Stream API. In this presentation we will look at various data transformations and see how the functional APIs in the JDK can provide concise solutions for these.

We will start with the Stream's API and quickly dive into some newer functions and also the utilities of the Collectors. Along the way you will get a deeper understanding of some of the excellent functions that are hidden in plain sight.

Many developers around the world have jumped on the Microservices bandwagon. Several organizations, in the past and also in the present, have built around monolithic and also service oriented architectures. What separate, however, Microservices from those efforts at large? How does a Microservices based architecture influence the design of the software applications, what are the key design principles we should keep in mind, and how to leverage design goals like reuse and extensibility?

In this presentation we will revisit the design goals we often focus on in software development and how those evolve in the context of Microservices.

Java introduced sealed classes. We've had enums over the years which gave us control over the members of the hierarchy but Sealed classes take those capabilities far and beyond. In this presentation we will take a deep dive into sealed classes, their capabilities, how to work with them, how they behave across packages and modules, and how they can help us model our applications.

We will take an example driven approach to get a good grasp of this nice feature that has strong influence on our design.

Continuous refactoring is critical to succeeding in projects and is an important part of sustainable agile development.

In this workshop, we will start by discussing how to approach refactoring, the essential steps we need to take, and look into how to incrementally improve the internal design of code to make it extensible, maintainable, and cost-effective to change. In addition to discussing the concepts, we will take several code examples from real projects, discuss the code smells and explore the refactoring techniques. Along the way, we will also dive into refactoring short code samples and measure the quality of code before and after refactoring.

Workshop Requirements

Computer with git client to access git repository.
Java 8 or newer
Your favorite IDE

Continuous refactoring is critical to succeeding in projects and is an important part of sustainable agile development.

In this workshop, we will start by discussing how to approach refactoring, the essential steps we need to take, and look into how to incrementally improve the internal design of code to make it extensible, maintainable, and cost-effective to change. In addition to discussing the concepts, we will take several code examples from real projects, discuss the code smells and explore the refactoring techniques. Along the way, we will also dive into refactoring short code samples and measure the quality of code before and after refactoring.

Workshop Requirements

Computer with git client to access git repository.
Java 8 or newer
Your favorite IDE

Albert Einstein once said — “We cannot solve our problems with the same thinking we used when we created them.”

As developers, architects, managers, tech-leads, our job entails solving big problems. However, our systems are composed of parts, and it is the interaction of those parts that ensure the system works, and tells us where to go looking when things fail. What does it mean to think in systems? What are the benefits, and what are tools are available to us? If any of this intrigues you (and it should) come join me as we explore a new way of thinking about problems, both big and small.

In this session we will take a page from Donella H. Meadows fantastic book “Thinking in Systems” and attempt to get an understanding of what makes up a system, how we can tease apart the moving parts of the system, and get into the mindset of a “systems thinker”.

In this example-driven session, we'll review several tips and tricks to make the most out of your Spring development experience. You'll see how to apply the best features of Spring and Spring Boot, including the latest and greatest features of Spring Framework 6.x and Spring Boot 3.x with an eye to what's coming in Spring 7 and Boot 4.

Spring has been the de facto standard framework for Java development for nearly two decades. Over the years, Spring has continued to evolve and adapt to meet the ever-changing requirements of software development. And for nearly half that time, Spring Boot has carried Spring forward, capturing some of the best Spring patterns as auto-configuration.

As with any framework or language that has this much history and power, there are just as many ways to get it right as there are to get it wrong. How do you know that you are applying Spring in the best way in your application?

Workshop Requirements

You'll need…

• A Java IDE of your choice. I'll be using IntelliJ, but you are welcome to use Spring Tools, Netbeans, or whatever you prefer for Java development. (Spring Tools–either the Eclipse or VSCode version–or IntelliJ is recommended, though).
• Java 17 or higher. I recommend using SDKMan (https://sdkman.io/) for managing multiple versions of Java on your machine. I'll be using Zulu 17.0.6 for most tasks, but may switch to a Liberica NIK version for purposes of native builds.
• Docker (optional, but may be necessary for some tasks)

In this example-driven presentation, we'll focus on how to build reactive APIs in Spring. We'll start with Spring WebFlux, a reactive reimagining of the popular Spring MVC framework for HTTP-based APIs. Then we'll have a look at RSocket, an intriguing new communication protocol that is reactive by design.

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

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

In this example-driven presentation, we'll take a high-level look at how Spring applies reactive programming at all layers of an application. You'll also learn the essentials of working with Project Reactor, the reactive programming library for Java that Spring's reactive support builds upon.

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

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

Cloud native applications are distributed to reap the benefits of resource scaling. Distributed computing is powerful but it also makes you think differently in designing applications. Atomic, modular, highly cohesive, and low coupled applications play nicely on these distributed systems. But it comes with costs.

We’ll look at architecture styles that adapt well to running in containers and on Kubernetes. Along the way, we’ll note the extra things your application should do to play nicely with distributed cloud native targets.

In this example-driven presentation, we'll focus on working with reactive data persistence. We'll start by seeing how to create reactive repositories for relational databases with Spring Data R2DBC. Then we'll explore non-relational reactive persistence for MongoDB and Cassandra.

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

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

In this example-driven session, we're going to look at how to implement GraphQL in Spring. You'll learn how Spring for GraphQL builds upon GraphQL Java, recognize the use-cases that are best suited for GraphQL, and how to build a GraphQL API in Spring.

Typical REST APIs deal in resources. This is fine for many use cases, but it tends to be more rigid and less efficient in others.

For example, in an shopping API, it's important to weigh how much or how little information should be provided in a request for an order resource? Should the order resource contain only order specifics, but no details about the order's line items or the products in those line items? If all relevant details is included in the response, then it's breaking the boundaries of what the resource should offer and is overkill for clients that do not need it. On the other hand, proper factoring of the resource will require that the client make multiple requests to the API to fetch relevant information that they may need.

GraphQL offers a more flexible alternative to REST, setting aside the resource-oriented model and focusing more on what a client needs. Much as how SQL allows for data from multiple tables to be selected and joined in response to a query, GraphQL offers API clients the possibility of tailoring the response to provide all of the information needed and nothing that they do not need.

Workshop Requirements

• Java (17 or higher)
• An IDE of your choosing (I'll be using either Spring Tools or IntelliJ, but VSCode or even NetBeans will be fine if you prefer)

Embraced containers yet? If so, that only presents the beginning of the journey. Designing your images to be lean, and your containers configurable requires us to leverage Dockerfiles to their maximum potential. At scale, everything matters—build times, testing, multi-stage builds, conventions around tagging and logging. There is a whole ecosystem of tools around how we can best build our images and containers.

In this session we will learn many a trick on how we can leverage Docker's own tooling as well as third-party tools to ensure that our first steps in the container world are the right ones.

Apache Kafka is the core of an amazing ecosystem of tools and frameworks that enable us to get more value from our data. Let's take a journey through this wonderful world and see what we can learn.

In this session, we'll have a gentle introduction to Apache Kafka, and then a survey of some of the more popular components in the Kafka ecosystem. We will be looking at the Kafka Producer and Consumer libraries, Kafka Connect, Kafka Streams, the Confluent Schema Registry, and ksqlDB. You will leave loaded with ideas of ways to put Kafka to use in your organization, and a list of resources to help you on your journey.

Some say that data is the new oil, and like oil, data needs to be collected, refined, and distributed to gain value from it. For years we've collected data into tankers called databases, and when we had enough, we shipped batches of it to be refined by some process. Then when that was done, we'd make it available to end-users. However, unlike oil, data tends to lose its value the longer we wait to use it. (Data is the new milk?)

So, what if we could hook up a pipeline* to the source of the oil, er… data, and transform it in near real time, on its way to the end-users? That's precisely what we can do with Apache Kafka and Kafka Streams. In this session, we’ll see how we can use Kafka Streams to enrich, aggregate, summarize, and otherwise transform our data while it is flowing through our systems.

• These pipelines are completely harmless to the environment.

Event-driven architectures look great on paper (or a whiteboard), but it's easy to run into snags when trying to implement them.  In this talk, we'll see how tools from the Apache Kafka ecosystem can make this task easier and a lot more fun!

In this session, with Apache Kafka as the backbone, we'll use Micronaut to implement an event-driven architecture that is loosely coupled and easily extensible. Then we'll extend it with a Kafka Streams application without affecting any of the existing applications.

A Docker image is the artifact of the container world. Leaner images allow easier for quicker build times, less resource management (disk pressure and network usage), fewer attack vectors, and better performance when pulling or pushing images for storage or upon deployment. Lean images also produce smaller containers, which in turn require fewer resources at runtime, allowing for higher server density. Multistage Dockerfiles can help reduce the complexity of CI/CD pipelines by reducing the number of moving parts in building, testing, and producing a production-grade image. The key to building leaner (smaller) images, with little build-time overhead is to understand how Docker uses the Union File System (UFS), how Docker builds (and when it busts) the cache, and how to use the Dockerfile specification to it's fullest potential.

In this exercises driven, hands-on workshop, we will dive deep, peeking under the hood to get a glimpse of the Union File System, and then proceed to look at the effects of many of the important Dockerfile instructions. We will see how best to use them, and highlight any caveats that we should be aware of.

By the end of this class you will have gained a keen understanding of how best to write your Dockerfiles, and effectively build and design lean images, and containers.

A Docker image is the artifact of the container world. Leaner images allow easier for quicker build times, less resource management (disk pressure and network usage), fewer attack vectors, and better performance when pulling or pushing images for storage or upon deployment. Lean images also produce smaller containers, which in turn require fewer resources at runtime, allowing for higher server density. Multistage Dockerfiles can help reduce the complexity of CI/CD pipelines by reducing the number of moving parts in building, testing, and producing a production-grade image. The key to building leaner (smaller) images, with little build-time overhead is to understand how Docker uses the Union File System (UFS), how Docker builds (and when it busts) the cache, and how to use the Dockerfile specification to it's fullest potential.

In this exercises driven, hands-on workshop, we will dive deep, peeking under the hood to get a glimpse of the Union File System, and then proceed to look at the effects of many of the important Dockerfile instructions. We will see how best to use them, and highlight any caveats that we should be aware of.

By the end of this class you will have gained a keen understanding of how best to write your Dockerfiles, and effectively build and design lean images, and containers.

Kubernetes is highly configurable and extensible. As a software developer, once you understand how something works the next thing you naturally ask is how to extend it to meet your needs. Kubernetes is declarative by its nature which allows you to configure the state of a cluster to meet your needs. However, with all of the Kubernetes resources, it can't do everything. Fortunately, Kubernetes has a build-in architectural feature of extensibility.

In this workshop, we will build on your existing knowledge of containers and Kubernetes and add techniques for extending Kubernetes to help to meet your real world needs.

We will cover many topics extensibility, such as:

• Kubernetes API
• Custom Resource Definitions
• Controllers
• Security and Roles
• Kubectl plugins
• Operator Pattern
• Public Operators
• Choices for developing your own Operator
• Hands on labs

Kubernetes is highly configurable and extensible. As a software developer, once you understand how something works the next thing you naturally ask is how to extend it to meet your needs. Kubernetes is declarative by its nature which allows you to configure the state of a cluster to meet your needs. However, with all of the Kubernetes resources, it can't do everything. Fortunately, Kubernetes has a build-in architectural feature of extensibility.

In this workshop, we will build on your existing knowledge of containers and Kubernetes and add techniques for extending Kubernetes to help to meet your real world needs.

We will cover many topics extensibility, such as:

• Kubernetes API
• Custom Resource Definitions
• Controllers
• Security and Roles
• Kubectl plugins
• Operator Pattern
• Public Operators
• Choices for developing your own Operator
• Hands on labs

It seems like everyday there is a new headline about a security breach in a major company’s web application. These breaches cause companies to lose their credibility and cost them large sums of money. Security is everybody’s job and requires us to be proactive.

This hands-on workshop is designed to teach you how to identify, exploit (legally) and fix vulnerabilities in modern Java web applications. Using an existing web application, you will learn ways to scan and test for common vulnerabilities using common penetration testing tools. You will learn about OWASP Top 10 vulnerabilities such as hijacking, injection, cross-site scripting, cross-site forgery and more. You will learn best practices around logging, error handling, intrusion detection, authentication and authorization. You will also learn how to improve security in your applications using existing libraries, frameworks and techniques to patch and prevent vulnerabilities making your software safer.

It seems like everyday there is a new headline about a security breach in a major company’s web application. These breaches cause companies to lose their credibility, cost them large sums of money, and those accountable undoubtedly lose their jobs. Security requires you to be proactive. Keep your employer out of the headlines by learning some key security best practices.

This hands-on workshop is designed to teach you how to identify and fix vulnerabilities in Java web applications. Using an existing web application, you will learn ways to scan and test for common vulnerabilities such as hijacking, injection, cross-site scripting, cross-site forgery and more. You will learn best practices around logging, error handling, intrusion detection, authentication and authorization. You will also learn how to improve security in your applications using existing libraries, frameworks and techniques to patch and prevent vulnerabilities.

Workshop Requirements

• Virtual Box 64-bit or alternate virtualization player that can support 64-bit ova files (windows users please make sure you test virtual box ahead of time)
• Kali Linux Varient Virtual Machine
• Docker (Optional)

Over the last decade, DevOps has emerged as an influential business philosophy and practice, helping businesses drive high quality software to market faster. DevOps focuses on the elimination of bottlenecks that occur when development and operational resources are too divorced from one another. But what about friction in the development and test process? What about the delayed feedback cycles that come from slow builds and test flakiness? How can we reduce friction in areas that are outside of the focus of DevOps? Raju Gandhi, Developer Advocate at Gradle Enterprise, will talk about how the emerging practice of DPE addresses these questions. The presentation will include examples of DPE practices in action from Java projects using the Maven or Gradle build tool.

Attendees will walk away from this presentation with a better understanding of:

• Acceleration technologies for speeding up feedback cycles
• How to use data analytics to quickly determine the root cause of problems and prevent problems from happening in the first place
• The costs of a low productivity environment with wasted time waiting for builds, tests, and CI/CD pipelines
• The importance catching errors earlier, including incorrect signals like flaky tests
• How to make the practice of developer productivity engineering a respected discipline

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.

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.

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.

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.

A large part of embracing DevOps involves embracing automation. Over the last decade we have seen the emergence of “as Code” — Build-as-Code, Configuration-as-Code and Infrastructure-as-Code. The benefits to utilizing such tools are huge! We can codify the state of the world around our applications, giving us the ability to treat everything that our code needs like we treat the code itself. Version control, release management, tagging, even rolling backs are now possible. Terraform, an open-source tool from HashiCorp allows us to build, control and modify our infrastructure. Terraform exposes a Domain-specific language (DSL) that we can use to express what our infrastructure should look like. Terraform can work with all the major cloud providers, including Amazon AWS, Google GCP and Microsoft Azure. If you are curious about what this tool has to offer, this session is for you. Come on in, and let's learn how to terraform your cloud.

This session will focus on Terraform. We will look in to how this tool works, explore its capabilities, and see how it can play a pivotal role in our Infrastructure-as-Code (IaC) strategy. With lots of code and demos, this session will certainly give you enough fodder for thought, and provide a baseline so you can decide if Terraform is right for you.