 So who I am? I'm Martin. I'm the organizer for one trial Ruby. I'm working at a company called telco bridges on on the south shore And I want to talk to you about rails bridge before I start everything. So where's bridge? I'm not sure who heard about it before So the people from from Ruby, that's not too bad So red bridges is a court that we gave about Ruby and Ruby on rounds for every level of developers The first level is for learning programming. So last time we added we had like 60 years old of difference between the youngest people and the oldest person. That's pretty nice So they just come here They just come over there to start learning about programming. It's one and a half That's pretty nice. And then I have the mid-level which is introduction to rails Which is introduction to web development So you can do the main same thing with Django and the last one is advanced rounds Some more you learn more like libraries and other stuff that they are needed to be Sorry to be able to do real web development. That's it Why we are a rails versus Django So first thing I want to say is that if you know rounds, you really don't need to know Django Okay, no tomato. Yeah, I'm good I'm say that because if you know Django, you don't need to know rails either. So that's pretty much equal Think that because for me both framework are equal or equivalent They don't do the same. They do pretty much the same thing. They all have their own opinion do different thing But in the end to do the same job if you prefer Python use Django if you prefer Ruby use rails. That's pretty much the trick So in the end There's a python in the Ruby But I'm oh, I hope at least we can agree on the next one, right? I Okay, I Know again, it's over for the jokes. So just do some translation Django on the right red on the left. So what you call a models who also call it a models That's what is easy next one what you call a template is what we call a view So just remember that if I say view it really means a template for you But if I'm if I'm speaking about controllers, it's mean views for you. So It's one is kind of ugly and the last one you were all in the routes. It's one pretty easy It's really the view that is harder to understand a little bit of tools for a translation By P as understand is our criminal through B gems is where all our libraries are when we download them from PIP is your library the downloader you manage your stuff we use bounder for it and it's also make us a Production environment. So if you have multiple library in the same Host each rails project will run its own library. I'm not sure if people do the same thing I didn't catch that part PDB, which is your debugger for us. It's called debugger or by bug by bug is for Ruby 2.0 The other one is for 1.9 or 1.8 and the last one is RVM, which is our RVM install 1.9.3, which is not the Ruby version. We don't use the The package manager of the OS we use RVM or RBM to do it. Thank you you are you I think it's virtual and that use the package manager and By by Envy's it was started from Ruby or environment. So I think the same the same idea in that the back So if you continue in Django you use like generic templates So it means that you build your views from scratch and you put everything in it in the rails We can use scaffolding which will generate all what you we need for our project For which for the part of our project we're needed So it's will create for us the models the controller and the views if you talk to any advanced rails programmer He will tell you he doesn't use it anymore because it gives you too much Mexico's that you don't want to support in the long run, but if you're starting it's a pretty nice to have it That's one the models Which is what you use as a orm as I saw from from the Django website for us It's called active record which was built in rails at the start, but it's not extracted from rails. So That's pretty cool So is the orm so gym managing everything from foreign key to Methods on day on the object and stuff like that next one admin interface, which is by default with Django We don't have that with rails if you want to have something similar We can include a library cause active admin it will give you an admin panel in the back But most of the rest project don't have admin built-in from them. You you are we always built-in from scratch Authentication which you have by default in Django We use another library called device and for rails is the classic one the more the more the most use your Authorization which is by default also we use can can which is another library So even if normally we run test there is more convention in it You have more features in the framework that we have for difference needs that you have to build a web application and the last one is south which is within your Included Django in the next version for us. We have migrations since a long time that do everything we need in mind for the migrations And at the bottom what I add What's what I understood from both framework Django was built for server speed and Rails was built for programming speeds So when which rails noise will take you less time to write the web the website, but it will be slower to run on your own So that's the main difference between both framework is that you don't have the same basic idea at the start Let's talk a bit about rails since you already know Django Just want to talk a bit about the magic or the convention that we have So what happens is just we have some rules that we need to follow so the framework will work It's they're not written any works up in the documentation. You just need to know them. That's kind of how it is So project types which is a kind of models that I have that is called project type And it's all will always be in the in the file app models project type that are be all the time That's my conventions always always be there is controller if you want to do save on it What would be in app controllers project types controller that are be? This is not that stupid as a convention Our reviews will be in app views project types and the views will be there are the templates and The database the table will call will be called project types The ID is ID and if you have another for any like on project It will be project underscore ID like if you were using project type as an ID in the database will be project type ID with underscore between each so That's the convention and lastly the routes that will always be in config slash routes for the wall application Let's continue with the routes So resources Column project types we create all the restful rounds that we need for project types West first restful restful is what rails use as a as the basic thing. We're always use restful routes most of the time So you get get of the locale of three thousand is the default URL for rails I don't know which one you use for Django, but for rest will you always use for three thousand by default? So if you go on get project types, you go the index or the list of all the project types that are available If you do slash new on that it will be the view to create a new one As you can say the same time you will check it will crowded the method called project in project types controller The method called new will be invoked automatically if you go to that path And at the same time the view that will be loaded will be in app views project types New that HTML that ERB which is a default view also So everything is there at the start. So you don't need to do a lot of routing inside your code. Everything is there already So pose of project types, which means that you want to create a new one if you do get on project type slash one will give you an edit of the of the project type with the ID one and if you do slash edit Sorry, if you have flash edit is the edit if you don't have slash edit is the show one that I Honestly, I don't really use the show action really often except you have like admin user views But most of the time every no one is admin. So I always most of time will use edit and the last one if you have post patch on what the same one has so which will be an update and Put patch normally don't exist with browser. So it's a post request with an external attributes telling you which one it is and Delete is the same thing So I heard that it's a little bit tricky to do routes in Django So I give you like three the example that do exactly the same thing So you have the choice the first one say get on slash project types slash column ID Which means to be that you put it in the controller project types in the action show And the attribute ID will be the one that got extracted from the line Second one is some idea, but instead of putting control in action We use in the the way I showed the last the last one So the control is on the left and after the sharp you get the action and the last one is you can pull our resources But just limit it to any one One of the method will show you cannot you have also accept which means you have all of them except one Depending on which one you want to have And another thing that's really neat is the nested routes So if you have resource posts do which is correct a block We could resource comments because this is how we do normally each in ruby it will create you I give you two examples. So the first one post will give you the post slash one view For it and you guys who have slack post slash one comments slash one Which means which mean we will you want to see the post one they come in with the ID one in it So it just means that comments are inherited from post. So you need to have a post to be able to get a comments in your routes. So this is our Rails defined wish you should build your URL So another thing to sneak is that the framework will auto load your your your classes So if you want to accept project type for the first time Just type project type and it will be in the framework. We'll just search in the right file So this is why the file is called project type that are be because the rails now know A work to find it. This is why we have the convention So you don't need to have your the import or requiring ruby. It's a real framework do it for you directly We have and when you create a new red application, you have the default get in your so we just commit and get directly Everything is what you need to be in your is already in your so you don't need to mess around with it. It's already built And the views my mime type is another tricky thing that is fun with views So if you get you want to accept project types the list to give you the HTML mime by default So the HTML view, but if you do project types that Jason will give you the Jason representation of the same data So you don't need to have another another controller or other codes to do the same thing Just load the same data and the mime that the framework will support by default will change it for you The asset pipelines this one is pretty nice So in development all your assets JavaScript style sheet will be in their own fires And so you can be so it's easier to work with them when you go into production the framework Compress them compile them and combine them So finish with one JavaScript file and the one style sheet already compressed in your production environment so you don't need to like pre-compile everything is the framework manage that for you and The thing it is tricky is few put an instant variable inside your controller to be passed on to the views So this is how you send variables to views. So you just need to know it and Another thing that you don't have in Django is that the query params are transparent So params is the global variable that you access to any attributes from the route or from any query params So you just you need to know it I know in Django you have another but you have one variable for the URL params and another one with for the query params So what is the pros about the convention? So it's faster to develop because you don't need to write a lot of writing thing inside your code Rans take care that they have the reloading It's a lot easier to work to write to see someone else application because it will be built as the same thing as yours It's easier to write gems This is why we have so much libraries for us that everyone has the same code the same structure So you can inject your code easy in any application And this is what people will expect you to do because if they use the same the same structure as what you expect and It's things easier for newcomers because you don't need to manage all that things on the other side the counts So the first one you need to know and very much better understand the convention This is code. This is running in the background. It's not really magic But can be at order to find this is why debugger is pretty cool because you can see you can go directly in the framework And see what is going on so can better understand the convention and be able to debug your stuff at the same thing and It's harder for us newcomer because you need to know the convention pretty much go with this first point Let's cut some libraries that we're using that we'll just talk about them a little bit first one is device to the authentication It's pretty easy Authorization can can declare everything in the real if I if you go on a website called Ruby toolbox you get all the frame all that all those libraries are on there and they are classified by popularity on by GitHub for GitHub Download and stuff like that so we can know by just doing that that can can has like 75% of the rails market So if you want to do it a recession go with can can device is like 95% or something So if you want to do authentication you use device by default Views you I told you that you can have a like view a like show that HTML that you're be which is one of the of the compiler for your views So I think you for your templates you use something like mustache For rails you can choose which one you have you can you have erb amel slim or any other one that are defined as a library You just need to get could put the right end at the line That's the file at the end of the file and the rails would run the good parser to understand what you want in your view And by the way slim and amel are using the same thing as Python that you don't need to close your brackets So you're just using the indentation to close the HTML, which is personally what I prefer when I wrote the HTML tags And we just talk about test and Ruby we have a lot and a lot of Libraries to do it. That's just not comparable to anything any other language I think and if you need anything it's probably on get up already I probably think the same thing for you with Python and Django But for for us is just if you search something just get up in the name and you probably find that to three libraries for it Just want to talk a little bit about tests for me I think Ruby is the R&D for test framework because We have a lot of them we make a lot of tests with them many reasons that in Ruby You can inject code at in any class or any instance of a class at any point in the execution So if you just say I got like my HTTP class that gave a get method that we That will do it some are you can just say to the my test you will receive a Someone will call get on you when that happens do nothing and return success as a string so He's pretty like you just mark everything you want inside the object Even if the code is badly written you can still test it because can inject everything everywhere in it Normally you should build it that is easier to test, but if you are really stuck with it you can do it Just before I finish some funny things that I saw Django admin customization It's our kind of work like who has convention you need to use your right file name at the right place So the framework will load them automatically and we will you will be able to customize your views with it Where else do exactly the same thing but for everything? Your file format with different app in it This is what we call so I res engines or res engines like other rails app that you can inject in your own app and the last thing Python and Django are older than the rails and Ruby Python by 10 years and Django by about six months This is from Wikipedia dates. So I suppose they are good. I do always wondering which one was the oldest So why I like rounds because it's fun most of them the main reason I'm coding personally in your house Just because I have fun doing it The automatic management of assets is that big pros that you have with it. It's really easy to deploy Because Ruby developer really like really ace to do redundant stuff So we create your libraries like chef to be able to deploy easily the community is pretty nice and It's bleeding edge. So it's one you something you appear most of the time We get get injected in Ruby or in the rails because we are we have another library that will do something similar just because we like to try new stuff and It's easy to get in a new project when you're a consultant It's really fun The drawbacks so I'm using a framework, but I'm sure you're using Django You have your own things that you don't like about it, but you have the same thing for me for the first one It's really slow. It's really slow to execute compared to anything else You can pass it on with jruby on Java gvm, but still it's not the same The RM J rel said that your foreign key should be in the framework and not in the database I do not agree with that. So for me I use a a library called foreigner and with my migration is I always put my foreign key in a database as I put them in my Orm, so I'm sure that I cannot mess up my database by accident And if someone else you want to use the same database, they won't don't break my code But it's one of the thing that is anywhere that I don't like And the other thing that you need to know the to know the libraries if you want to do Authentication you have to use device. That's just not negotiable. This is how it is So if you're a newcomer don't know rounds, you need to ask someone or check on forums If you know which one are the best or check the ruby toolbox Last one's not about rounds. It's my SQL no transaction So if you don't migration in your else and it fails It will try to revert what you did, but with my SQL since there is no transaction is Let is still there like all done So you need to clean it by and in the database or you need to comment your migration in your migration file, which is Which I don't like Yeah, pull postgres as transactions. So you don't you don't have problem with it And the last thing is nowadays they we have skinny controller fat models Which is the last not the last thing maybe two years ago But we don't we didn't find any problem with any solution to it except services for now So skinny controller fat model means that your controller are as small as possible And you put all your logic and your code in your models But that means that your model normal most of the time has too much information in them So they are not there anymore to just save or load the object. They are there to do a lot more stuff than that So sorry, I use services, which means it's more like BDD kind of thing So your service like my user want to do this. So my service will just do that and That's over and if I want if my user want to do something else with my project types They all have another service by the by the side of it that would just describe what see what my user want to do That was pretty much what I had to tell you about rounds. What else do you want to know about it?