Brian Sletten

Forward Leaning Software Engineer @ Bosatsu Consulting

Brian Sletten

Brian Sletten is a liberal arts-educated software engineer with a focus on forward-leaning technologies. His experience has spanned many industries including retail, banking, online games, defense, finance, hospitality and health care. He has a B.S. in Computer Science from the College of William and Mary and lives in Auburn, CA. He focuses on web architecture, resource-oriented computing, social networking, the Semantic Web, AI/ML, data science, 3D graphics, visualization, scalable systems, security consulting and other technologies of the late 20th and early 21st Centuries. He is also a rabid reader, devoted foodie and has excellent taste in music. If pressed, he might tell you about his International Pop Recording career.

Presentations

Resource-Oriented Architecture Patterns

Tuesday, 9:00 AM EST

The typical technologist has a fairly straightforward perspective about the use of resources in modern software systems. They understand the concept of stable identifiers and what some of the HTTP verbs are intended for based upon experiences with the Web.

There is a rich ecosystem of use cases that build upon these basic ideas, however, and in this talk I will demonstrate several of my favorite examples. Drawing upon my pattern-oriented book, I will highlight patterns that surface information, transform it, direct
traffic, and more. These patterns will be presented with intention, consequences, and the usual context we expect in pattern-oriented literature to help us communicate sophisticated design decisions.

Come develop a more sophisticated palette of resource-oriented patterns to help you solve a variety of issues in distributed information systems development.

Building an API Team

Tuesday, 11:00 AM EST

I personally believe that the success of an API initiative is at
least largely influenced by the selection and development of the
team that will build and maintain it.

Code-focused developers are not the right starting point. People who
think about information and long-term value capture are more likely
to produce better results. People who actually care about the API
beyond a thin-layer above their code are a great start.

We often say that we are trying to “Build the Right Thing” and
“Build the Thing Right”. But how do you know you are building the
right thing? How are you validating the implementation and the
behavior of the system? How are your business analysts supposed to
verify the API is doing what it is supposed to if your testing
strategy is complicated and code-focused?

In this talk, I will discuss these ideas and more. I will tell you
about a team I put together with no API background that built
what became a $300 million revenue stream in its first few years.

Web Security for APIs

Tuesday, 1:30 PM EST

There's a clear need for security in the software systems that we build. The problem for most organizations is that they don't want to spend any money on it. Even if they did, they often have no idea how much to spend. No particular initiative is likely to imbue your system with “security”, but a strong, deep defensive approach is likely to give you a fighting chance of getting it right.

Web Security as applied to APIs in particular are an important part of the plan. In this workshop, we'll show you how approaches to defining “enough” as well as concrete techniques to employ incrementally in your designs.

In this workshop, we will pick a hands on framework for implementation, but the ideas will generally be standards-based and transcend technology choice so you should have a strategy for mapping the ideas into your own systems.

We will cover a broad range of topics including:

  • The concepts behind Building Security in
  • Designing for Security
  • Authentication and Authorization Strategies
  • Identity Management
  • Protecting Data in transit
  • Protecting Data at rest
  • Frameworks for selecting security features
  • Attack and Threat Models for APIs

Web Security for APIs

Tuesday, 3:15 PM EST

There's a clear need for security in the software systems that we build. The problem for most organizations is that they don't want to spend any money on it. Even if they did, they often have no idea how much to spend. No particular initiative is likely to imbue your system with “security”, but a strong, deep defensive approach is likely to give you a fighting chance of getting it right.

Web Security as applied to APIs in particular are an important part of the plan. In this workshop, we'll show you how approaches to defining “enough” as well as concrete techniques to employ incrementally in your designs.

In this workshop, we will pick a hands on framework for implementation, but the ideas will generally be standards-based and transcend technology choice so you should have a strategy for mapping the ideas into your own systems.

We will cover a broad range of topics including:

  • The concepts behind Building Security in
  • Designing for Security
  • Authentication and Authorization Strategies
  • Identity Management
  • Protecting Data in transit
  • Protecting Data at rest
  • Frameworks for selecting security features
  • Attack and Threat Models for APIs

Behavior-Driven REST (An API Case Study)

Wednesday, 9:00 AM EST

A client once asked me to take a team that was new to REST, Agile, etc. and put together a high profile, high value commerce-oriented API in the period of six months. In the process of training the team and designing this API, I hit upon the idea of providing rich testing
coverage by mixing the Behavior-Driven Design testing approach with REST.

In this talk, I will walk you through the idea, the process, and the remarkable outcomes we achieved. I will show you how you can benefit as well from this increasingly useful testing strategy. The approach makes it easy to produce tests that are accessible to business analysts and other stakeholders who wouldn't understand the first
thing about more conventional unit tests.

Behavior is expressed using natural language. The consistent API style minimizes the upfront work in defining step definitions. In the end, \you can produce sophisticated coverage, smoke tests, and more that exercise the full functionality of the API. It also produces another organizational artifact that can be used in the future to migrate to
other implementation technologies.

Automating API Evolution with OpenRewrite

Wednesday, 11:00 AM EST

One of the nice operational features of the REST architectural style as an approach to API Design is that is allows for separate evolution of the client and server. Depending on the design choices a team makes, however, you may be putting a higher burden on your clients than you intend when you introduce breaking changes.

 By taking advantage of the capabilities of OpenRewrite, we can start to manage the process of independent evolution while minimizing the impact. Code migration and refactoring can be used to transition existing clients away from older or deprecated APIs and toward new versions with less effort than trying to do it by hand.

 

In this talk we will focus on:

Managing API lifecycle changes by automating the migration from deprecated to supported APIs.
Discussing API evolution strategies and when they require assisted refactoring and when they don’t.
*Integrating OpenRewrite into API-first development to ensure client code is always up-to-date with ease.