Tricks and treats for new developers
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Part Number | 54 | |
| Number of Parts | 86 | |
| Author | ||
| License | CC Attribution - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/31295 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
InternetworkingXML
00:24
Multiplication signLine (geometry)Coefficient of determinationContext awarenessBit
01:01
Software testingView (database)Process (computing)Computing platformProduct (business)QuicksortSource codeCartesian coordinate systemPhase transitionMathematicsCounting1 (number)SequelWeb 2.0XMLComputer animation
02:38
2 (number)Proxy serverServer (computing)Web 2.0Process (computing)Right anglePower (physics)Cartesian coordinate systemService (economics)Proper mapQuicksortComputer animation
04:10
Cartesian coordinate systemXMLUML
04:37
Configuration spaceProjective planeComputer fileFiber bundleDatabaseXMLComputer animationSource code
05:02
Computer fileIntegerString (computer science)Different (Kate Ryan album)Configuration spaceSelf-organizationGoogolLogical constantBoss CorporationRight angleSet (mathematics)Arithmetic meanSampling (statistics)InformationCartesian coordinate systemDatabaseServer (computing)CodeMathematicsProjective plane1 (number)Real numberComputer animation
07:21
DatabaseComputer fileRevision controlEndliche ModelltheorieHuman migrationAuthorizationRegular graphFigurate numberSelf-organizationProduct (business)MathematicsReal numberState of matterBitDifferent (Kate Ryan album)Software maintenanceWebsiteSet (mathematics)Data structurePoint (geometry)CodeTask (computing)Heegaard splittingAsynchronous Transfer ModeTable (information)TrailBoss CorporationProof theoryRow (database)Cartesian coordinate systemCASE <Informatik>Beta functionSequelFormal languageNeuroinformatikPopulation densityWordServer (computing)QuicksortVotingMultiplication signNetwork topologyObject (grammar)Right angleBranch (computer science)Projective planeXMLComputer animation
12:48
DatabaseObject (grammar)Human migrationProcess (computing)TimestampTrailData structureBit rateXML
13:49
Process (computing)Object (grammar)Term (mathematics)Right angleDescriptive statisticsCartesian coordinate systemFigurate numberSocial classDiallyl disulfideEmailSpeech synthesisRule of inferenceQuicksortOpticsField (computer science)AuthenticationIntrusion detection systemString (computer science)IntegerError messageCodeOrder (biology)XMLComputer animation
16:07
RoutingGroup actionGame controllerProduct (business)Discounts and allowancesQuicksortMilitary baseCore dumpCodeState of matterCASE <Informatik>Right angleElectronic mailing listBasis <Mathematik>CountingContext awarenessSubject indexingMultiplication signRule of inferenceComputer animation
18:46
Exception handlingSinc functionMultiplication signComputer fileTablet computerProjective planeQuicksortError messageRule of inferenceCartesian coordinate systemComputer configurationProduct (business)
20:13
Multiplication signTablet computerPoint (geometry)WeightRule of inferenceMoment (mathematics)Green's functionRight angleConfiguration spaceProjective planeError messageMathematicsSource codeComputer animation
21:02
CodeSocial classMachine visionLine (geometry)Unit testingServer (computing)Software testingSoftware repositoryComputer fileMetric systemStatement (computer science)QuicksortHookingExecution unitLevel (video gaming)Multiplication signUniqueness quantificationGroup actionRight angleXMLComputer animation
24:32
Endliche ModelltheorieProjective planePasswordHuman migrationInformationFactory (trading post)RoutingUnit testingDatabaseSoftware testingSocial classGame controllerMultiplication signComputer fileView (database)Source codeText editorContent (media)Computer configurationOpen setComputer animation
26:24
AuthorizationData loggerQuery languageGame controllerObject (grammar)Row (database)Video game consoleHome pageCartesian coordinate systemWeb pageComputer fileNetwork topologyAlpha (investment)Subject indexingRight angleLoginXMLComputer animation
28:00
Limit (category theory)Right angleCartesian coordinate systemProper mapLeakSocial classCodeQuery languageSemiconductor memorySimilarity (geometry)Server (computing)Game controllerThresholding (image processing)Logic gatePoint (geometry)Web pageSource codeJSONXMLUMLComputer animation
29:29
NumberObject (grammar)InformationCodeProduct (business)MiddlewareGreatest elementQuicksortSet (mathematics)Semiconductor memoryRight angleMultiplication signXMLComputer animation
30:24
Computer animationJSONXML
Transcript: English(auto-generated)
00:13
Welcome. My name is David. You can find me on the internet as David, Twitter, GitHub.
00:21
I work for a company called Michelada, like the drink. If you've never had one, Michelada is a great drink that us Mexicans drink all the time. It's made with ice, clam juice, magical Mexican sauce, chili powder, salt, lime, and of course, beer.
00:42
And it's delicious. You should get one if you've never had one. But anyway, the name of my talk is Tips and Tricks for New Developers. I'm gonna give you a little bit of context why this talk, what I decided to give this talk. Long time ago, Galaxy far, far away,
01:03
2009, Las Vegas, my first RailsConf. And it was great RailsConf. Back then, I was building, I just moved onto Rails, had my first job. I was being paid to write my first Rails app. And I was building a huge e-commerce platform
01:22
but knew nothing about the real stuff, like once you're past the tutorial phase of Rails, like what happens next, right? And I remember that there were several talks at this particular RailsConf that sort of changed my view and helped me a lot.
01:42
Things like solving the riddle of search using Sphinx to read Rails, like it made me figure out that it might not be a good idea to filter my products with SQL or do searches with like, you know, like searches. So I learned that there was this thing that you could use to search. We ended up using Solr, by the way, not Sphinx.
02:02
But anyway, I sort of learned something new. I learned about WebRAT. You probably don't remember WebRAT, but it was what we used to test applications before Capybara and all this fancy new stuff that we have. But I learned about it. And then the most important one,
02:20
or one of the most important ones, is I learned about Git. I was using SVN before that and be so source safe before that. So I learned about Git. And it was, I think it's one of my, the best talks I've ever heard. It started with Git in 60 seconds, I remember clearly.
02:43
And the speaker sat there and just basically read that in less than 60 seconds. It was amazing. And then he proceeded to do the proper talk, right? And another important thing that I learned about RailsConf is how to put, like what was I to do once I had my application?
03:01
I learned that there was this thing called Mongrel, that it was our web server. I don't remember about Mongrel, of course. I learned that I had to set it up in different ports. You had a process, a Mongrel process, that started on each of the port. And then you had NGINX on top, or Apache on top of it,
03:21
that sort of did the processing around. And then if you wanted to scale, well, you scale like that. Just added more servers and HAProxy to do the proxying, and you will be fine. You need more power, you just added another one of those.
03:40
And that was back then in 2009, before Puma and all this new fancy stuff that we have. So I remember Las Vegas, right? So I think that we still need talks for beginners at RailsConf. We do need to know how to do microservices and how to handle a gazillion of requests per second
04:02
and all of that, but we need talks for beginners so people can come here and learn stuff that they don't even know they needed to know, right? So this talk is for beginners. Most of the things that you learn here, maybe you already know it, maybe not, but I do warn you that this talk is for beginners. And it's just based on my experience,
04:23
what I do when I start a new Rails application, like the things that I always use, the things that I usually do, and all that. So hope it helps for you. I had to remove a bunch of stuff, but this is the most important things that I think will work for you. So let's begin.
04:41
First of all, let's talk about configuration files. When you start a new project, right, you use your Rails new command, the first thing that you wanna do, well, it's gonna do your bundle stuff, it's gonna copy files and all that. The first thing that you wanna do, I consider this a courtesy to our developers,
05:02
is please copy your database file into an example file and then ignore the original one so we can always have on hand a configuration file that we can base on. It's awful to go into a new project and then start your Rails server, you have no database JAML file,
05:21
and then you realize there's nothing, you have to go Google it, paste it, and all that, it's just time consuming. So please keep an example file of your database file. It's gonna pay out in the future. And do so for any other configuration file that you think that it's needed for the project to run.
05:43
Please create sample files and copy them and just ignore the real ones from Git, right? And while we're talking about configuration files, did you know that you can have as many as you want that you can separate those in different files,
06:01
like for example, you can have a payments JAML file, and then you can just call it from the application like this, use config for, and just send the name of the file as a SIM, and then you will get that particular configuration. So you can use it to just organize your configuration files better,
06:21
and everyone will be happier when it's cleaner and you know exactly what kind of configuration is on each of the file. And then remember that wherever there's a string or an integer on the code that's comparing to something else, you probably, probably want to use a constant or a setting on one of those config files.
06:43
So remember that if you see code like this in your Rails application, try to change it to something like this. Use a constant for that 30. And if you want to go, like if you think it's gonna change constantly, just move it all the way over to a configuration file.
07:02
You're gonna be very happy that you did this when your boss comes and say, hey, I need to change that to 10 minutes, and then 15 minutes later, he's gonna say like, hey, change it to 20 minutes. This way you know where to change something, just restart your server, and you're done, instead of looking for that setting in the code base.
07:21
Let's talk about the database. Now this one, you can't imagine, on eight years of being a Rails developer, I've seen it a lot. Do not yet ignore the schema file, please. I've been to teams where,
07:40
or I've joined applications where there's no schema file, and then I asked like, what happened to it? And there were too many conflicts with it, so we just got rid of it. I'm like, that's the point. So please do not ignore your schema file. It's very important that you always able to restore your database state
08:00
with either DB setup or DB reset, especially if you are new to the project, you can just go there, configure your database, run one of those, and you're up and running to start coding, so please, please, do not ignore that file. It's very important that you find those conflicts and then talk to your fellow developers
08:20
and say, hey, I added this column. Yeah, me too, so let's figure it out, right? Instead of just ignoring it. This is a tricky one. Don't change your data in your database migrations. This is hard to achieve, so I'm gonna change a little bit the tip
08:41
to be careful when you change data in your database migrations. It is pretty common that you do something like this. You add a column to one of the tables that you already have, and then you decide that you wanna fill it with something, maybe based on the current data that you already have,
09:00
like here, right? We're splitting the code column into two columns, so you do something like this, right? You add the new columns, you go through all the companies, you split it, and then get rid of the old column. The problem with this kind of code, first of all, is that it's not future proof. It's not future proof because, for example,
09:22
what happens in the future, your company model is now the organization model, for example, this migration won't run anymore. And while migrations are not supposed to last that long, they're just, you know, they help you to keep track of history of how the database evolved.
09:40
Your schema rb file is the one that's supposed to have like the real data structure, database structure. It's still nice to sort of, you know, try to keep it as coherent as possible. The other problem that you might find with this kind of code is that you can't, you know,
10:00
have longer deploy times. It's very, very common that you are, you know, on development mode and you run this migration and it runs really fast, but you forgot that there's like three million companies in your database. So now it's going through all of them in production and, you know, it's doing all of that and you can't, like, your database is in a weird state.
10:23
Maybe there's more migrations that are coming and the site can't run without those migrations, so you're doing maintenance mode or whatever and your boss is angry because it's taking long. And you forgot about the three million rows. So try not to do that. You're risking downtime, basically,
10:41
if you're changing your data and your migrations. And the other one, so this code, for example, this is gonna happen in production, I guarantee it. You forgot that maybe code is nil, so it blows up and now, you know, you're stuck with a migration weird state on the database and everyone's yelling at you
11:03
because you have to log into the server, change that code real quick, run the migrations again. I've been there, so it's a really bad idea to do this. So one way to fix it, prefer SQL over Ruby. If you're gonna do it, you're gonna be careful,
11:20
but if you're gonna do it, you might be better off like this. Do your thing, update, you know, use regular SQL to do your updates and move on, right? This is faster, of course, because it's not iterating through all of the objects, it's not instantiating anything, so it's just updating whatever needs to be done.
11:42
If there's nil, it's not gonna blow up, so this is way faster. So try to think your changes in data as SQL and prefer this. It's gonna be safer to do this. But the best thing to do, in my opinion, is to use a gem like this, Rails Data Migrations.
12:02
There's a lot of gems that do the same thing, but I think this is the best one, because it works with Rails 5, by the way. And this gem is gonna give you a different set of rake tasks for your data migrations, right? So for example, if you had this regular migration, once you have the gem, you're adding a column
12:22
and then doing an update on all the records on the table. What you would do in this case is create a data migration, set authors at active. It will create a special migration in a different folder.
12:40
And then in that migration, you will add your data changes, right? So you don't need them anymore in the regular migration. And now when you deploy, you will run first your database migrations that will change the structure, and then with a different rake task, you will run your data migrations. So it's a separate process,
13:01
and it makes everything cleaner. And it also keeps track of how data is changing using the same, like the timestamp that the database migration used. So this is way better. And if you don't want to use a gem, at least maybe first make all the migrations that change the structure,
13:21
and then add migrations later to change the data, right? Let's talk about background jobs. It's pretty useful to say to use background jobs. You have something in place like sad kick, rescue, delay job.
13:40
I still used delay job a couple months ago. And what I noticed is that it's regularly a bad idea to pass objects to your methods that go in the background. There's a few things that can go wrong. But what I mean is this. Let's say you have a job class that has this perform method
14:02
and you probably want to do this, right? You have an order and a user, and you're gonna assign it to it. What I mean is that it's better if you do this. Just pass the IDs, then find again your objects on the job and just do whatever needs to be done. The problem with using objects is that
14:21
they're usually converted into YAML, and they end up being like huge strings that if you're not careful and there's special characters in the description field or something like that, it just makes everything blow up. And you will not notice until you see all the alerts coming up.
14:40
So it's better if you just use the ID. It's smaller to just pass an integer around instead of a whole object as YAML. And it's just gonna be better. It doesn't matter in terms of performance because it's already on the background, so just let it do it, right?
15:01
And speaking of background jobs, always when you start a new application, always, always deliver your email later. Don't wait until your first SMTP authentication error happens and then makes your checkout blow up because you were expecting the checkout to send the email
15:23
after payment was completed or something like that. Always when you start, you start thinking about delivering your email later, always. And the same rule applies for mailers. Instead of passing objects, try to pass IDs and just pull them over from the code on the mailer. This way, even if you don't have anything in place
15:43
right now to sort of delay the sending of the mailers, in the end, you're just gonna need to add that delay method if you're using sidekick or delay job or if you're using active job, just use the label later and that will be it. But use the integers, don't use the objects
16:01
for the same reasons as the background jobs, okay? Let's talk about REST. This is my favorite lesson for all new developers. You have to be RESTful all the time. REST is like the core of Rails and MVC
16:22
and everything that you're doing and it's simple. It's very simple to sort of explain but it's hard to actually implement it. Let me tell you why. REST, to me, it means that on your controllers, you only have these actions, nothing more.
16:44
Actions should always be index, show, new, create, edit, update or delete. No other action but it's pretty common to find in code bases things like this, right? You have the products controller and then you have an action to deactivate the product
17:01
and you create your route and use get and remember, whatever, right? This is wrong, this is not RESTful. When you think about RESTful, you should think that for every request, there's a something, a resource that's changing. So in this case, when you're deactivating the product,
17:22
what's changing, it's the product state. So the correct thing to do here is to create a product state controller and you're updating it, right? This is more RESTful, much more RESTful. For example, if you have a shopping cart, right?
17:41
Instead of having an action to apply a coupon, what's happening? You are creating a discount or a shopping cart discount. So create a controller for the discount and you are creating it. This is RESTful, right? This is very common. If you have contacts, you have a search
18:03
so you create a search action, wrong. That's totally wrong. You create the contacts search controller, searches controller, and then you have an action for that search. This is RESTful, right? You have something that is changing because that's what RESTful is supposed to be.
18:22
So the way to make sure that you're complying with this rule, it's very easy. Just don't have controller actions that are not on that list. It's always index, show, edit, new, create, update, or delete. That's it. If you have an action that's named differently, wrong.
18:41
Right? Okay. Now, a few Ruby gems that I think must be on all projects. I find them useful, I always add them, so I hope this helps for you too. This one, you probably heard of a lot, RuboCop.
19:04
RuboCop, it's gonna analyze your code, it's gonna check how it's written, and it's gonna tell you where you're doing things right and when you're doing things wrong. And it's automated, so it's pretty cool instead of having someone yelling at you,
19:20
it's RuboCop-like. Showing you. Better teacher than humans, trust me. A very common excuse that I've heard about not using RuboCop in your project is because you're already, you know, you have a large application, you're already,
19:42
it's been two years since development, if you add it right now, there's gonna be like 500 errors and you don't have the time to fix them. That's okay. What you can do is you can add this, run it with this option, auto gen config, and it's gonna create a RuboCop todo.jaml file that's gonna include an exception
20:01
for everything that it found. So that way, you just add it to your, as a sort of an include file to your main RuboCop file, and that way you have like a sort of a clean slate at that point in time, and then you are supposed to come back later,
20:21
that's why it's called a todo file, and remove all those exceptions and fix them. That's what you're supposed to do. You probably won't, but it's fine, right? At least from that moment, like for example, right there in screen, at least from that moment on, if there's something like if you write bad Ruby code,
20:42
it's gonna tell you starting from there instead of trying, having to fix all other like 500 or whatever errors you find. So auto gen config also helps for a new project, so you can like pull configurations that you might use,
21:01
like change the rules depending on your style. For example, there's this one where it configures RuboCop to how many columns, how many characters you see per line. I usually have it at 80, 90, you can set it to 130. I know there's people that say, we have large monitors,
21:20
like why do we need this? The thing is that your vision is only, it's really narrow, so it's better if you have less characters to read at once. You just have to sort of nest code around, so it looks better if you try to remove the characters on your lines, so try that one.
21:41
This one, style and documentation, I usually move it to the main file because I'm not gonna write comments on all my classes or methods or anything, so I just get rid of it. No one has time for that, right? And this one, I think it's important, this is the one I value the most about RuboCop,
22:02
the metrics method link, it forces you to make methods that are no longer than 10 lines. It's hard to comply with this one, but if you do, your code will be so much cleaner and so much readable, so trust me, try this one.
22:21
I'll allow you if you go to 12 or 13 lines, that's fine, but don't go over that, but forcing your methods to be 10 statements and that's it helps you clean up your code base. It's gonna, you're supposed to try to abstract all the code into smaller methods
22:43
and then test those, unit testing, that's why I call unit testing. So keeping this one, really, it's gonna make your code so much realable and so much better. And then if you want to run this before you push code
23:01
to your, to get, you can use a hook. If you add that file, .git slash hooks slash pre push, it's gonna run RuboCop before it actually pushes the code to the repo and if it fails, then the push will be canceled, so that way, you can just push,
23:23
RuboCop failed, oh, I have to fix this first, fix whatever offense you have and then push it over. It's very useful, for example, us, we have a CI server that actually runs RuboCop and our repos are filled with comments that, you know, read like,
23:43
fix that RuboCop thing, that RuboCop, because the build fails when RuboCop fails. So it's usual to push, wait for the CI server, fail, why, because, you know, you, maybe you went over with the characters or whatnot so you have to make a commit
24:01
that only fixes that, F RuboCop, damn it, RuboCop, there's a lot of commits like that on our repos. So what I tell the guys is just use a hook, so, you know, you run RuboCop before actually pushing and if it doesn't pass, then you won't push and you can fix it and not curse at it.
24:22
Annotate, this is another gem that I don't see often and I don't know why, but I love it. Annotate, what it does is, let's say that you have a, like a model user with name, username, password,
24:40
active, whatever, when you run annotate on a Rails project well, after you do your migrations, what it's gonna do, it's gonna, well, annotate your models with information about the database automatically, basically. So if you add columns, you just run annotate again and it's gonna add that information
25:02
at the top of your classes. And it's gonna do so for models, test file, unit test files, and factories if you use. So it works as a reference, it's a quick reference if you are working on a model about the columns that it has, instead of, you know, going to the database
25:21
or checking schema or whatnot, you just have it right there at the top of the model and you can see it real quick. So it's pretty useful to have these annotations handy. And this one is pretty useful too. If you use routes as an option, then it will annotate your routes file.
25:41
So you don't have to rake routes every time you need to figure out where my controller should go. You will already have it. And if you're very old like me and use vi as your text editor, you're gonna think that it has like contextual autocomplete.
26:02
So it basically autocompletes only on what's open. So you open your routes file and you have like autocomplete for all those path methods. So it's pretty cool, very useful. But I don't know why people don't use it. So now you know, please use it, annotate, very useful. Bullet.
26:22
Bullet detects the N plus one problem as it's happening, as you're developing. If you don't know what the N plus one problem is, it's very common in Rails, but it's something like this. So let's say you have a book method that belongs to author, has many comments.
26:43
Then you have the author that has name, whatever. And then you have the comment that belongs to user, belongs to book, and your index page looks like this. So when you go to this page, the controller usually looks like this, probably.
27:02
And then when you load that page, your log file will look like this. There's a bunch of queries going on. Like three queries, four queries per row. And you know, it's just getting all the objects one by one
27:23
because that's what you told Rails to do. It doesn't know what else to do. So this is called the N plus one problem. It's very common when you're developing Rails application. So if you use Bullet and you configure it, let's say for example, what I'm doing here is, well, enabling it. I want it to show on the console.
27:41
I want it to show on the Rails logs. And if you add the footer, what happens is as you load that page, you will notice that there is a footer that says, hey, you know, you're probably better off if you include the author on the query or if you include the comments on the query and it's gonna yell at you from the console too,
28:02
from the Rails logger, right? It's gonna tell you, hey, you know, you're doing something weird here, so why don't you fix it? And you're gonna go, oh, okay, yeah, let me fix it. So you go to your controller. You use includes properly. You nest it as needed. And then when you load your page,
28:20
you will now have the queries for each of the classes. You don't have a bunch of microqueries. So this is way better than Bullet. We just tell you as soon as you're developing that you're doing something not wrong but maybe weird.
28:41
And another similar gem, Oink. This detect memory leaks before it's too late. I don't know if you've worked with Rails applications that have memory leaks. You have a memory leak when your applications start growing like, I don't know, 1.2 gigs in RAM
29:02
and then you need to restart. Actually, that's the best way to fix memory leaks on Rails application. Just set up Monet and if it goes past the threshold, just restart the server. Done, right? Because it's so hard to find memory leaks on the code on Rails. It's very, very hard. Once it's there, it's not gone ever.
29:23
Like, you're stuck with it. Deal with it, basically. That's the solution. So Oink, when you have it on your code base and it's some sort of middleware so you initialize it and it's gonna add at the bottom of your logs,
29:41
like when you're developing this information which is basically how much memory it's using and the number of objects that you're instantiating in that request. So if you're developing something like this and you see that you have like 500 common objects instantiated, something must be wrong, right? There's something wrong going on.
30:01
And it's actually kind of safe to use in production. I wouldn't enable it all the time but if you're sort of trying to figure out where the problem is, I would enable it and then just let it log a few requests and try to find where I'm instantiating a lot of objects. So it's very useful for that.
30:22
And wow, right on the 30 minutes. That's it. That's all I have for you right now. Like I said, I had to remove a bunch of them of advice but this is what I thought was most important. And that's it, thank you.