Talks

Packwerk promised modularity in a gem install — but good architecture doesn’t come from `bundle add`. We’ll look at how Packwerk’s story reflects deeper truths about software design, organizational habits, and how we sometimes ask our tools to do our growing for us. This is a call to arms (and to our love of the craft) for teams that want to scale Rails applications by scaling their understanding first.

Are you struggling with large amounts of complexity in your application? A big org with lots of cross-team dependencies? Too much coupling, causing bugs and incidents? Difficult time ramping up new engineers? Or do you just want to improve product optionality by having more reusable building blocks to create new features for your customers?,

Join us to apply the packs ecosystem and packwerk to gradually modularize your application. We'll dive into decomposing your application, moving files into packs, and coming up with a technical and managerial plan to successfully roll this out to and get buy-in from the rest of your organization.

Shopify released packwerk open source in 2020. It may not have been around for long, but it is a game changer in how we can manage the complexities within our applications. It makes modularization work easier, more approachable, more iterable, and probably also more fun. With other approaches like micro services or gems and engines we need to have a lot of the answers at the start. With packwerk we can start with an idea and learn along the way where we want to go and what we need to do to get there. Let's make some packages!

Shopify released packwerk into open source in 2020. It may not have been around for long, but it is a game changer in how we can manage the complexities within our applications. It makes modularization work easier, more approachable, more iterable, and probably also more fun. With other approaches like micro services or gems and engines we need to have a lot of the answers when at the start. With packwerk we can start with an idea and learn along the way where we want to go and what we need to do to get there.

Let’s make some packages!

Moving to a microservices architecture is not just a technology problem. With the level of tooling and support we get from Spring and platforms like Cloud Foundry, the really daunting tasks quickly move to organizational challenges. How does one find and define the organization’s shared services? What are their boundaries? How should they get distributed? In this talk we will use the Spring Framework’s great support for building services infrastructures, harness the superpowers of PaaS for scalable deployment, and combine this with Lean and Agile principles of product development to lay out a blueprint for how organizations can reason about and develop their service architectures effectively.

With components your apps will be happier, healthier, and development will be more fun. Let me show you how!

Components add a layer of structure that is not present in many applications. The structure in question is that of bounded contexts. Bounded contexts with boundaries enforced and tests separated. If you have thought that your app is too big and that the way to save it is micro services, you may want to take it one step slower and look at components first. In Ruby, we create component-based apps with gems; in Rails, we add engines.

The technology is one thing - there is a lot to consider there. This talk will quickly cover the tech and dive deeper into the what, the why, and how of component-based application development.

Component-based Rails helps you regain control over your sprawling Rails application. It helps you structure your new Rails application in a way that it will stay more manageable longer. It helps you think completely differently about writing applications - not just in Ruby and Rails!

This session will help you pass the initial hurdle of getting started with component-based Rails. While there is nothing really new, there is a lot that is just a little different. We will go over those differences so your start with component-based Rails is a smooth one.

You have a big Rails app and are feeling the pains? Stories are hard to deliver, code is hard to refactor, and your tests take a looong time? Getting you and your codebase out of this situation requires you to stop developing a 'Rails application' and start refactoring towards your domain. I will discuss how and where you refactor towards a more structured and manageable application, a component-based Rails architecture.

For his day job Stephan is a Pivot - developing software at Pivotal Labs. With every project he especially enjoys the continuous search for doing the right thing, and doing that right. Outside of that he enjoys more work: on his old house or his rock climbing skills.

It's true that goods are better distributable when they are in packages. That is the common view of what Ruby gems and Rails engines are: packages for distribution. This perception misses the great value that comes from packaging without distribution. That is what makes component-based architectures: a helpful tool for organizing growing codebases. We'll talk about how to do this with (and without) Ruby on Rails.

Ruby makes it a bit hard to do packages right: you really can't hide anything. Rails doesn't want you to do it. I don't care. We'll do it anyways and it will be awesome!