 Right, hello. I'm feeling a bit sick today, which is the reason I'm sitting down. Because of that, I also decided to cut out some of my talk, which is why you're strangely staring at part two here. But don't worry, the first part is essentially a 10-minute rant about something that can easily be summarized in 30 seconds. So please take a moment to visualize this to get into the right mood. And then I will recap some of the problems that I noticed we run into while building Rails application using conventional Rails approaches. So some of the problems I've seen is the models, views and controllers of Rails seem to offer very limited expressive power. Usually, your business logic is crackled to the framework to the point where they are almost the same thing. And also it has some restrictive mental models that we'll get into later. So the point this talk makes is to solve these problems, we need more objects. We can't do with just the m and the v and the c. So to reiterate the problem just briefly, when we begin our adventure, we're basically told that you have three different tools to choose from for any given problem. And you learn that there's something called concerns, but probably you don't want to use that. But at some point something happened and a new kind of object popped up. And this object was proposed in 2010 by a guy named James Golik. So he called his own idea crazy, heretical and awesome, which probably hints at the controversy that the suggestions sparked at that time. And actually what he proposed was a new type of object that many of you have heard of today that is called a service object. And yes, I checked this up. His name is actually Golik. And this is the only thing I can think about when I hear this. All right, fast forward five years. And we now have a richer taxonomy of objects. Two of these service objects have been added some new ones. So why is there a hundred sec bill in this picture? Well, it's not about the money in this case, it's actually about the guy. So this is Carlin Eos. He spent his whole life naming, classifying and cataloging different species of plants and animals. And he was also Swedish. And I thought, okay, I'm Swedish. And I wouldn't mind having my face put on the hundred sec bill. So I decided to sort of go in his footsteps. Only that I only spent the better half of a week compiling this list. So here is the taxonomy of objects that I'm presenting to you today. The first object is an object that I heard this word getting thrown around a lot in the office. But it took quite some time before I decided to really dig down and see what this mystical service object was all about. And it turned out it was not very mystical at all. It was just a regular object. What was special about it is it does something different. Conceptually, I think about it as an action inside your application. So if you open your services folder in your Rails application, it should give you a good indication of the things that your application can do. And the life cycle of a service object looks something like this. It accepts some inputs, performs some work and then returns a result. And this is fairly straightforward. It looks like a regular method almost. But the question is what is a result? And essentially this is up to you because none of these conventions have been ratified by Rails. So it's really up to you to create and apply and refine these conventions. Personally, I like to return another type of object, sort of a value object that can tell me if the call to the service was successful or not. And also that can hold some data and errors that were caught along the way. So here is an example of a service object. In this case, it's a service object that registers a user in your system. So in the initializer, it takes something called a form, which is actually another type of object that we'll cover shortly. It also allows you to pass in a notifier, which is essentially another service that sends a notification to the user. And because the notifier is passed in like this, it allows you to easily extend this object without having to go and mess around inside the object. I also should note that my examples, they are sometimes incomplete and almost always a bit contrived because I sort of needed them to fit into one slide to make it comprehensible. And I didn't really think the code would show up this big on the projector, but if you see any problems, then feel free to not do anything about it. So here is an example of the kind of object that my service will return. It's a very simple object that has some data, perhaps some errors. It can also tell me if the call to the service was successful or not. And this is how you might use it in your controller. So I guess the question on everyone's mind right now, which is usually the question is, so is there some gem that I can use that does this? Personally, I haven't found any gem that does this that I like yet. Some people ask, okay, why don't you use solid use case? Well, some people like solid use case. I don't like solid use case. I think it takes an object-oriented concept and it sort of weirdly applies a functional language construct on top of that. And it just feels really, really dirty. You might get the same end result kind of, but not without feeling just a little bit wrong. And yes, Ruby is a multi-paradigm language, but just because you can seamlessly combine things that normally shouldn't go together doesn't mean that you should do it. Okay, so I included a couple of these to give myself a break. And this is my favorite one. All right, service object covered. Next up is form objects. You saw one used in collaboration with the service objects that we just used. Essentially, a form object takes some input. It can validate it. Sometimes it can also save it. To achieve this, it's very common for people to include the active model module. But obviously this sort of couples your form object with Rails again. Even though it does give you a lot of nice things like you can initialize from a hash, which is why there's no initializer. You also get the active record style validations inside your object, which can be cool. But there are other options. So if you don't feel okay with you coupling it to Rails, you can try something like reform, which is a gem that is standalone and gives you really neat form objects. All right, next, something called a query object. This is one of the most straightforward objects. So you have some complex query. It doesn't quite fit in a scope in your model. You don't really want it in your controller either. So here is an example of a somewhat contrived query object. It searches products by tags. So again, it takes in a form object that has parsed some probably input from your user. It can have some tags and some indication of how the user wants to order the results. I also give the options to specify the source of what collection of objects should we search in. All right, next up come value objects. So value objects are very lightweight objects that encapsulate some value and some logic that provides that value with some behavior. And I think the perfect example for a value object would be Ruby's time class. Unfortunately, I didn't think about that when I made the slides. So I also created this less perfect example of a value object. In this case, it's called weight. So you can create new weights and you initialize it with some value and a unit which can be either kg or pounds. It encapsulates some logic to translate itself from kgs to pounds and it can also serialize itself to a string. Another good example of value objects would be money rails. If you have ever had the pleasure to work in a project that deals with money and maybe currency exchange and that money is passed around as floats and which currency is in depends sort of where you're in the application. Then you might understand why this is actually a good idea. So money rails basically gives you a money object that can tell you which currency it is, it can tell you how much the value is and you can also convert between different currencies. Next, something called a decorator object. So I like to think about decorators as sort of a lightweight wrapper around your model that adds some behavior that is usually related to the view. And I think the archetypical example of a decorator would be something like this. So you decorate your user objects with a full name method that takes the first name and the last name of the model and concatenates them together. Now in this example it does this by using the Ruby simple delegator to send any method calls that don't exist in the decorator onto the model. But you might also look into other options like draper or action presenter. But actually wasn't presenter the last item on our object list then how come action presenter is actually a gem for decorators. And that brings me on to the presenter object. Probably the most common question I've had from our juniors and interns in the last six months is, so what is the difference between a decorator and a presenter really? And to be honest, I wasn't quite sure myself at first. And as it turns out, there is no real consensus right now on what exactly is a presenter. Decorator, there is a very strong consensus that it is what I actually told you. But for the presenter some use it interchangeably with decorator which just adds to the confusion. And there's also a wide range of other interpretations of what a presenter is. So this is my personal take on it. I see the presenter as sort of a view model object. So if you've ever dealt with a framework that has something like view models then you might get a good idea of what it is. But if you decide to use this when you're talking to someone else or in your project, it's probably a good idea to clarify what exactly you mean when you say presenter. So here is an example of a presenter that I created. Say that I want to create a graph somewhere in my view. And this graph takes data from several different models. But I don't really want to add a graph active record model because it's sort of transient. I don't need to persist it or anything. So I choose to use a presenter in this case which takes in the models that it needs together with some options. It does all the calculations it needs and it sets up things like the axes. It calculates all the points and then it passes this to the view so it can easily be rendered. In some cases I've even seen people making their presenters renderable. So where you would normally render a view partial you can actually render your presenter object, which in this case would render the graph. So that brings us to the end of our simple taxonomy of objects. So in all of these cases I chose to go with the simplest possible implementation which is usually just a Ruby object without any metaprogramming or anything. Of course you can add that if you want but I think it's important to remember that there's nothing special about these objects. They are just plain old Ruby objects. Another question is, okay, what's next? Except obviously to go home and try all these objects out in your projects. Well apart from the value objects, none of these objects are really used to model the business domain. All of these objects are actually enhancing how we model web applications. But as developers we also need to model very complex and dynamic businesses and we don't have a lot of tools for that right now except rolling your own objects. There are sort of several ways to go from here. Earlier this year Adam Hawkins made a post titled The Ruby Community, the next version. It outlines some of the problems with how we approach building applications now and some suggestions how we can improve it. So I definitely recommend go and check this blog post out and maybe his other blog post as well. Another hot tip is to pick up probably both of these books. Rails as she spoke is a very light read but it makes a very compelling case for some things that are wrong in Rails and why it is kind of okay anyway. And it sort of helps you articulate this strange feeling you had sometimes that okay this is probably not right because in most of those cases it actually isn't. I also strongly recommend picking up object thinking. It can be a true eye-opener and it provides you with a very strong mindset that goes extremely well together with Ruby. And that is all, thank you. Any questions? So for the text it's aerial and for the code it's consolas. So I'm using Google slides so my font selection is very limited. Alright, thank you.