 Hello Singapore. I'm happy to see all you and it's my second time in Singapore and Red Dot RubyConf and because today we have after-party I need to say some small thing about Singapore. Do you need or do you know what Maryland is defined? It's a monument of the center of city. It's a big monument with it's layer and fish but in Singapore this means something else. So my name is Anton. You can find some links here and I'm software engineer from Russia. Two days ago I had 10 hours direct flight from Moscow to Singapore it was fun. And just to things what you need to know about me. First I really love stickers and second I really love I'm sorry I really love open source and maybe that's why I'm Hanami core and my commits and pull request you can find in some projects like Ruby Rails, Dry Rome and Crystal. And also I'm curator of one small community in Moscow. It's Moscow RB and we have meetups and cops and something else but today we'll talk about Hanami. In Japanese language you can find definition of Hanami and usually it's a process when you're watching the flower bloom. I have a special illustration for this process but of course today we'll talk about Ruby and framework which is called Hanami too. This framework was created by developer from Italy. His name is Luca and he has a birthday today. So this is the first comment was created three and a half years ago and as you can see Hanami is a really young framework. Also we have a person in core team. Marion was picked half or one hour ago maybe more and let's talk about general ideas. The first idea is modularity. It means two things in Hanami. First you can change any part of Hanami to other part. For example you can drop your ORM and use active record for example. I don't know why but you can. And second part it's a really simple way to separate your logic to small model or models. And the second thing it's simplicity and lightweight. I think the simple tool is provide your ability to start working on production application projects faster and I think that's framework is just a tool. Don't make a cult of it. Next idea is architecture sound. If you are going to use Hanami you gain more freedom. It means that you don't need to think how you can mix in your application and framework conventional and you can just use both and all will good. Also next idea it's poor objects and they're a monkey patching. Why is there a monkey patching? It's so important. For this I have a special quiz for you. Just try to answer. It's Rails method or Ruby. So who thinks that it's Rails method? Okay. Who thinks that it's Ruby method? Okay. It's Rails method. And the last part is the last main idea of this framework. It's straight save. It's really important because we don't worry about parallel computing and please remember if you want to remember only one thing from my talk. Just remember this thing. It's really important. Hanami is not Rails. It's important really. And Rails is not Hanami. It's two different web frameworks and compassion is a really stupid idea but of course we will compare this framework later. So let's talk about typical web project. You can see any web project and you will see two different parts. First part is business logic and second it's data flow. And let's talk about data flow. So what I mean on the data flow term. Usually it's something which take your request, do something what you don't know and after that response is request. And Hanami have a special architecture. It's a container architecture and what's mean for you as a developer. We have one folder and it's applications folder. And in this folder you can see some applications, a small application and in each application for example on this slide it's admin application. You can see controllers, view objects, routing and some assets into place in one place. And also if you look on web application in this example you'll see something like an admin application. And why it's so important and cool? So the first idea why it's cool is for example you have three different instance of your application with three different application, three instance of your project with three instance of, with three applications in each instance. And with this architecture you can in future you can start your server only with one application. For example you can start your server only with admin application or maybe only with web or IP application. And why it's important? For example you want to protect admin application in private network. And in next version of Hanami you can just start server only with admin application where you want and that's all. So let's talk about business logic. All business logic you can find in folder library and usually here you can see model. In Hanami we use repository pattern. We will talk about it later. Also you can find some interactors, mailers and what you want to see. So I told that Hanami is a model web framework and this framework consists of ten different gems. The first five it's Hanami is a base repository with common line interface and usually when you put in your console Hanami new project name works this gem. And also it's router, controller, tools, model and validation helper, view, assess and mailer. And I know that all this theoretical stuff is look difficult as well as talk about difference between Hanami and other frameworks. And first my example is replication. Typical replication consists of one class with one public method, usually it's call method. And this method take environments and you need to return array of three elements. It's status, environments and some body in array. And what we can see in Hanami in this example I used Hanami router. It's a replication and we can mount this replication into our router and it will be work. Let's talk about Sinatra. In Sinatra we have one class with one class method which take path and body. And that's all. In Hanami we can define block for our router and map something to router. And it's logical to compare rail section and Hanami action. I have really nice example of typical rail section. It's look like this. I'm just kidding, relax. So I told that compare of rails in Hanami it's really stupid idea. It's different frameworks. And all these frameworks use MVC pattern and that's why I think it will be good to check every part of MVC and display and show how it makes in rails and Hanami. And we start with controllers. Just a second. In the rails we have one class with some methods and each method in this class is action. You can call this method in any name. You can use anything and what you want. Of course you can use DHH style for your controllers. It will be only rest actions. But in Hanami we have little bit other architecture. We have only one class and each class it's action. It's mean if you have controller with five and points it will generate one model and five classes. And you can see that this class have only one public method. It's call method and it's look like a service object, functional object, what you want. And also it's really important and super cool. You can validate your parameters in action and it's separate logic for all your actions. Let's talk about models. Typical rails model. It's one class and in this class you can find some includes from, I don't know, for example, it's gravastic. Also this class have call back and data logic. Also this class have database logic and associations. And after all this, this class have validations. And I have only one question. Is it normal that one class know about four or five different things? I think no. And in Hanami, Hanami based on Rome. Rome is Ruby object mapper. It's a really nice project. And as I told, Hanami provides repository pattern. This pattern consists of two different things. First things is entity. And entity is usual data object. It's immutable data object like virtus or dry types or what you want. And you can initialize your object with some attributes. You can get this attribute value but you can't assign some new value to the attribute and for this you need to initialize new object with new attributes. And second part it's repository. It's one class which know all about your database. In my case, you can see the repository know about the sessions. And also in instance methods you can see that I call Rome relation and work with this Rome relation. And usage of this is look like this. You need to initialize repository object and after that call some methods for this. So if you talk about view in Rails, we have a view folder. And I don't know why but we have templates in this folder. And Rails helpers. Someone have problem with Rails helpers. In Hanami we have little bit different way. We have view objects. It's just a class for each template. And also we have templates and in this template you can call view logic and some data from your actions. Unfortunately I don't like this part of my talk. This why I leave it as elective for independent review. But in any project you can use webpack. So let's talk about pros and cons. So first process is no magic. It's not about, it's not only about monkey patching. It's about testing for example. And in this example you can see typical Hanami action. It's just a class. Remember this. And if you want to test this class you need to write this test. And that's all. In this test you need to analyze your action instance. And after that you need to call this method call. With params in my case it's just hash. And this action will return array of three different elements. First element is status. Second is environment variables. And last is body. And after that you can check it like a poor Ruby object. So I told about monkey patching and I think it's a big problem because I really often see similar questions on stack over flow. In this question one person asked how he can call method weeks from integer in Sinatra application. I think, this is why I think it's so important to see the difference between language and framework. Next pros it's best practice. And I think Hanami is great tool because they teach developers to dependency injection. You can open Hanami guys and you will see that in one big part of actions, part about dependency in the actions why it's so cool and how we can test some actions without mocking and stubbing. Hanami teach developers to dependency operation. In this case you can use, you can use interactors for this. You start thinking about where I need to put this logic in action in model in entity or maybe in repository. And also Hanami teach developers how to TDD. And this framework use test first principles. And I displayed one example how to test action in the right way. And if you open getting started guide in Hanami, first code will you see it will be a test code. But I'm sorry I forgot that TDD is that. And let's talk about cons. And the first cons is TDD. It's not a problem of Hanami or Rails or something else. It's a problem of TDD. And this TDD you need to cover your test by some strange and not important method like method form in your object. Other cons it's good but not a great documentation. It's a really young framework. And we have really nice documentation but if you try to do something super custom, you will get error. And usually it's really hard to find some documentation for Hanami if we look something I don't know. Join 15 tables with something else, something else, something else. In Rails we have other situations. We have many blog post documentation about it. And other cons it's missing gems. Just think Rails is 10 years old. 10 years old framework. Sinatra is 8 years old. And I had this talk one year ago on Yeruko. And when I prepared to this talk today, I saw one interesting thing. On previous year with all this stuff, we had a problem. But today we have problem only with one part. It's something like device. But in next Hanami release in 1.1, I will fix this problem because it's problem of common line interface. And it's not super important. But anyway, if you want to add something special for Hanami, you can do it by yourself. And this. So I told about some gems and solutions. All we have are awesome list on this link. You can find information about some gems, some integration with sidekick, for example, or something else. And useful and helpful blog post. And if you have a free time, if you want to play with real production applications written on Hanami, I have some open source projects which I use every day, maybe every week. The first project, it's my project. It's a simple way to finding your starter repositories. It's written on Hanami. It's full open source. You can send me pull request if you want. And second project, it's like Rails contributors but written on Hanami. And some contacts on this page. You can find our site. On this site, you can find many useful information. Also, we have a chat where you can ask anything every time. And we have forum for some feature requests and et cetera. And this is end. Thank you. Any questions? As the man said, any questions? Are there hands being raised or am I missing something? Any questions at all? Yeah. So thank you for your talk. So I think you mentioned that there is no monkey patch. How do you enforce that in the project? We use special models and it's look like Hanami utils string. And in this string, we use all methods which we need. Okay. And of course, you can use it in your application. Any more questions? So I was following this, the development of Hanami and the dry RB stack. And I know that at some point Hanami gave up on its own validations module and instead of using the dry validations, I'm wondering if you're planning more merging or do you think that these two stacks will be just developed in parallel from now on? So in Hanami, we use dry validation and you can use all features of dry validation like sharing your scheme and et cetera, et cetera. And about second question, it was about... So I'm wondering if Hanami is going to merge to build its features on top of dry RB in more cases. If you're planning to, I don't know, use it for business logic or for containers or monads. So I'm asking about the development plan of the Hanami. If it's in the road map, if you're planning to make these two stacks work together. Really, I don't know. We use dry when we need it. And you can use dry stack in your Hanami application. It's easily, you can use transactions and what you want. But in Hanami, I don't know, we have features and problems, but we don't have something like, oh, we need to use dry transaction. We really need it. We need to find some problem to fix it with dry transaction. Now we don't have this. Okay. Is... Sorry, was someone speaking? Okay, we have a question from the back. In Rails, we... Data with stable migration, right? For evolution of the database schema. So is there any feature like DB migration? I'm sorry, I don't hear you. Oh, yeah, we have DB migration from SQL by Jeremy. You can use it now and it will work now. And I think in future, guys from around want to create super migrations stuff. And I think in future, we'll use this stuff instead of SQL. All right. Okay, we have one at the back and my friend will run to him instead of me. Oh, I forgot to say, I have a sticker, so if you want stickers. Doesn't ask, what inspired you to do the Hanami? What do I have to say? What inspired you to do that framework or inspired the team to do that framework? I'm sorry. I think it's like why Hanami and what was the inspiration for it? For me? For the Hanami project? So if you want, you can find a blog post from Luca. It's four years old blog post, if I remember right. And he has some troubles with Rails because he tried to fix some stuff which he tried to fix some architecture stuff in Rails and he had to be problem because conventional of Rails is very important thing of Rails and that's why he understands that okay, I'll write my framework with something. Okay. Do we have anyone else? All right. Let's give it up for Anton. Thank you.