Just as sharpening the saw is the best way to cut down a tree… sharpening your development environment allows for a more focused more productive experience.
This session is a collection of scripts, aliases, shells, editors and tools which will super charge your development experience.

This session will cover:

• zshell, oh my zsh and powerlevel10k
• system aliases, scripts and functions
• switching java, ruby and python environments
• git, hub and git aliases
• working pull-requests and stand-up meetings from the CLI
• iterm2 scripting and wizardry
• ngrok and working with secure call-backs

Bring your machine and lets have you productive within 2 hours!

Contrary to popular belief, software engineering culture is not about the free food, open office spaces, and ping pong tables.

You can sense a great team culture when you observe it, and unfortunately you've probably experienced (or are currently experiencing) elements of a bad team culture. Not to worry - it's never too late to grab the reins and make small changes to steer your team in the right direction!

In this talk, Kate will highlight 8 tactical tips that attendees can implement on their teams immediately to help shape their team's culture!

Do you feel inspired by conference talks but overwhelmed by all of the take aways to remember when you get back to work? This session will provide an opportunity to identify and practice key leadership skills immediately!

We will work to understand what your motivational style means to you and how you can use it as a compass for decision making and improving your enjoyment at work.

Multithreaded programming in Java is changing quite significantly in the near future. Threads were once considered lightweight but soon will face the challenges of Fibers which are considered to be super lightweight.

In this presentation we will discuss the need for this significant change and how that's going to shake up the architecture and design of applications moving forward.

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.

.

Java was once a language that dragged along and evolved at snails' pace. Thankfully, that's no longer the case. The recently years have seen accelerated development of both language features and JDK improvements. In this presentation we will dive into some of the recent changes of Java that are both fun and powerful to use and discuss where the language is heading in the near future.

The modern features of the language
Where's Java heading?

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.

In this example-driven presentation, we'll start with an empty directory and have an application (simple as it may be) running in a production environment, leveraging Spring and 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.

Although Java originally promised write once, run anywhere, it failed to fully deliver on that promise. As developers, we can develop, test, and build our applications into WAR or executable JAR files and then toss them over the wall to a Java application server and Java runtime that we have no control over, giving us zero confidence that the application will behave the same as when we tested it.

Containers fulfill the write-once, run anywhere promise that Java wasn't able to, by packaging the runtime and even the operating system along with our application, giving greater control and confidence that the application will function the same anywhere it is run. Additionally, containers afford several other benefits, including easy scaling, efficiency in terms of resource utilization, and security by isolating containers from their host system and from other containers.

While deploying Spring applications in containers has always been possible, Spring Boot makes it easier to containerize our applications and run them in container architectures such as Kubernetes. Spring Boot's support for containerization includes two options: Creating containers based on buildpacks or using layers as a means of modularizing and reducing the size of our application deployments. Moreover, new components in the Spring ecosystem can make your Spring applications Kubernetes-savvy so that they can take advantage of what a containerized architecture has to offer.

In this example-driven session, we're going to look at how to create and deploy Spring applications as container images and deploy them into a Kubernetes cluster. Along the way, we'll also get to know a few of the most useful tools that a Spring developer can employ in their development workflow when building containerized Spring applications. We'll also see how to apply patterns of Spring Cloud–such as configuration, service discovery, and gateways–using native Kubernetes facilities instead of Spring Cloud components. And we'll look at how components of the Spring ecosystem can work with your Spring applications to enable them to thrive in a Kubernetes cluster.

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)
• Docker Desktop (https://www.docker.com/products/docker-desktop/)
• Kind (https://kind.sigs.k8s.io/)
• Kubectl (https://kubernetes.io/docs/reference/kubectl/)
• Skaffold (https://skaffold.dev/)

Test your setup: Make sure that the Docker Desktop is running and then type “kind create cluster”. It should take a minute or so, but then you should be able to type “kubectl config current-context” and see “kind-kind” listed.

At its core, Spring is built on a dependency injection framework that enables (among other things) loose coupling of application components. But dependency injection is not the only way to achieve loose-coupling. Event-driven design, as its name implies, enables components to react to events, not knowing where they came from, process those events, and then publish new events not knowing who (if anybody) will be handling those events.

In this session, we’re going to explore how to apply events in Spring applications to achieve looser coupling of components. We’ll start by looking at some fundamental abilities that the core framework offers for handling events. Then we'll quickly move into a higher-level form of event-driven architecture where events aren’t just handled within a single deployment, but span across multiple microservices by employing Spring Cloud Stream and Spring Cloud DataFlow. And then we’ll see how, when paired with serverless functions based on Spring Cloud Function, we can achieve not only loose-coupling of microservices, but also an efficient yet scalable use of resources in our event-driven architecture.

In a microservice architecture, the API Gateway pattern plays an important role, providing several benefits. It prevents clients from knowing anything about how the application is broken up into microservices or needing to know where those microservices can be accessed. It can optimize interactions with the backend services, by reducing the number of requests required to complete a task. It can act as the front line of security, ensuring that only authorized clients are able to access services. It can address service level requirements such as rate-limiting. And those are just a few benefits of an API gateway.

In this session, we’ll look at how to add an API gateway to you microservice architecture with Spring Cloud Gateway. Spring Cloud Gateway is a fully-featured implementation of API gateway that supports a variety of protocols in addition to HTTP and is fundamentally reactive. You’ll see how standing up a gateway in front of several backend services can simplify a client, optimize request, and more.

In this presentation, we will discuss Kafka Connect. Kafka Connect is an opensource project from Confluent. Kafka Connect provides us a way to move data from a data store as a source and stream or batch that information into Kafka. Kafka Connect also gives us a way to take information from Kafka and send that to another data store, a Sink. Every source and sink can be connected to and from various databases and message queues.

What this presentation will entail:

• A brief overview and review of Kafka
• The Architecture of Kafka Connect
• Where to find connectors
• Standalone vs Distributed
• Connecting a Source
• Creating Single Message Transforms
• Connecting a Sink

At the end of this presentation, we will have a live demonstration of watching a data pipeline using data stores.

How do we move information realtime and connect machine learning models to make decisions on our business data? This presentation goes through machine learning and Kafka tools that would help achieve that goal.

In this presentation, we start with Kafka as our data backplane and how we get information to our pub/sub. As they enter Kafka, how do we sample that data and train our model, then how do we unleash that model on our real-time data? In other words, picture extracting samples for credit card approvals for training, then attaching the model for online processing: The moment we receive an application, we can either approve or disapprove a credit application based on a machine learning model trained on historical data. We will discuss other options as well like Spark, H2O, and more.

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.

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.

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.

Are you a Java Developer looking to work on a Golang project? Are you looking to get involve on cloud native projects such as Kubernetes? This session is for you! This session assumes are are a Java developer and details the nuances of Go with comparisons against Java-isms.

This session will take a deep dive into Go as a language and provide details necessary to understand and write idiomatic go applications. In addition to differences in how to use the language and packaging structures, we will look at options for standard idiomatic Java. This will include:

• Collection comparisons and what to use in Go
• Stream processing for filters and maps
• Packaging and encapsulation
• Error Handling (Go 1.13 style)
• Go formatting, style and linting

In the process, we will look at several Go projects in the Open Source space as style examples.

As you look towards micro-service based solutions, or maturing your existing, there are a number of factors that are fundamental worth being aware of.
This sessions covers the gambit of architectural topics you need to understand to be successful.

This session will touch on the topics of:

• 12-factor application development
• Cloud / datacenter Infrastructure
• Application Categorizations
  • Guaranteed vs Best of Service
  • Core business vs supportive services
  • SLA
    • Response time require
    • Availability require
    • Fastlane / slowlane
    • App affinity / anti-affinity
• Service Discovery and Service Elasticity
• Fault domain
• Multi-tenant
• Metrics
• Tracing
• Debugging
• Capacity vs Scale

Real-world examples will provide working and non-working examples throughout. If you are looking to mature your applications into a set of micro-service this is the session for you.

Awareness is the knowledge or perception of a situation or fact, which based on myriad of factors is an elusive attribute. Likely the most significant unasked for skill… perhaps because it's challenging to “measure” or verify. It is challenging to be aware of aware, or is evidence of it's adherence. This session will cover different levels of architectural awareness. How to surface awareness and how you might respond to different technical situations once you are aware.

Within this session we look holistically an engineering, architecture and the software development process. Discussing:

* Awareness of when process needs to change (original purpose of Agile)
* Awareness of architectural complexity
* Awareness of a shift in architectural needs 
* Awareness of application portfolio and application categorization 
* Awareness of metrics surfacing system challenges
* Awareness of system scale (and what scale means for your application)
* Awareness when architectural rules are changing
* Awareness of motivation for feature requests
* Awareness of solving the right problem

The focus of the session will be mindful (defined as focusing on one's awareness), commentating in sharing strategies for heightening awareness as an architect and engineer.

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.