Date: TBD Gradual Modularity
Stay tuned for the details!
I speak about technical stuff that I believe to have a unique contribution to.
Stay tuned for the details!
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!