WEBVTT 00:00:17.190 --> 00:00:19.160 STEPHAN HAGEMANN: Thanks for coming. 00:00:19.160 --> 00:00:21.130 You came to Big Rails. 00:00:21.130 --> 00:00:23.190 If you did not intend to go to Big Rails. 00:00:23.190 --> 00:00:24.890 My wife's actually currently in a plane, 00:00:24.890 --> 00:00:27.630 and so for some reason I had to think of a plane metaphor. 00:00:27.630 --> 00:00:29.350 And her flight just got canceled. 00:00:29.350 --> 00:00:30.360 If you did not intend to go to Big 00:00:30.360 --> 00:00:33.140 Rails, which I can understand. It can be messy. 00:00:33.140 --> 00:00:37.750 Better get out now, the flight might be bumpy. 00:00:37.750 --> 00:00:39.640 So I want to talk about really large Rails 00:00:39.640 --> 00:00:41.840 apps, and my buddy Austin suggested, a couple days 00:00:41.840 --> 00:00:45.730 ago, let's use GitHub. Search for Rails. Sort by 00:00:45.730 --> 00:00:49.050 size. This is officially the biggest Rails app you've 00:00:49.050 --> 00:00:52.059 never heard of on GitHub. It's open source. It 00:00:52.059 --> 00:00:55.269 also only has eight models. Which is because they 00:00:55.269 --> 00:00:56.260 upload all their assets. 00:00:56.260 --> 00:00:58.050 It's a hundred and fifty megabytes big, and that's 00:00:58.050 --> 00:01:01.230 not the kind of big I'm talking about. I 00:01:01.230 --> 00:01:05.430 want to talk about component-based Rails architectures and why 00:01:05.430 --> 00:01:09.430 you should refactor towards them. And how to do 00:01:09.430 --> 00:01:11.770 that. 00:01:11.770 --> 00:01:15.130 Component-based Rails architectures is a term I use. I 00:01:15.130 --> 00:01:19.020 tag my Tweets about it as #cbra, and I'm 00:01:19.020 --> 00:01:20.360 the only person in the world doing it. But 00:01:20.360 --> 00:01:24.590 if you use that too, I'm certainly replying. And, 00:01:24.590 --> 00:01:27.510 here's a memo for that. 00:01:27.510 --> 00:01:32.410 If I can get one idea in straight off 00:01:32.410 --> 00:01:35.720 the bat, then it is that this is, this 00:01:35.720 --> 00:01:38.510 stuff is easy. If you can think about your 00:01:38.510 --> 00:01:41.500 application by writing, by painting boxes and drawing arrows 00:01:41.500 --> 00:01:43.920 for things that depend on each other and how 00:01:43.920 --> 00:01:47.040 they interact, then you know everything else you need 00:01:47.040 --> 00:01:50.040 to know about component-based architectures and you just need 00:01:50.040 --> 00:01:52.770 to start doing them to what I think will 00:01:52.770 --> 00:01:55.560 be improving the quality of your application and the 00:01:55.560 --> 00:01:57.680 quality of your code. 00:01:57.680 --> 00:02:01.390 Since I called this talk refactoring towards component-based Rails 00:02:01.390 --> 00:02:03.360 architectures, this talk assumes that you all know what 00:02:03.360 --> 00:02:06.420 that is. So, no. I will actually explain what 00:02:06.420 --> 00:02:07.450 that is to you. You're not screwed if you 00:02:07.450 --> 00:02:09.758 don't know what that is. 00:02:09.758 --> 00:02:14.810 So, I started talking and actually writing applications pretty 00:02:14.810 --> 00:02:19.310 much exclusively in this kind of odd way, so, 00:02:19.310 --> 00:02:23.480 like, two, three years ago. And it, I wrote 00:02:23.480 --> 00:02:26.090 this sample app that you find at this address. 00:02:26.090 --> 00:02:29.900 I'm shageman with one n on GitHub. And there's 00:02:29.900 --> 00:02:32.590 just the_next_big_thing sample app. 00:02:32.590 --> 00:02:35.510 It does nothing. Only it shows you the structure 00:02:35.510 --> 00:02:37.450 and how to hook certain things up. And let 00:02:37.450 --> 00:02:40.060 me quickly go through what that means. So this 00:02:40.060 --> 00:02:42.540 is the root of the project. And, as you 00:02:42.540 --> 00:02:45.410 can see, it's not a Rails application. But it 00:02:45.410 --> 00:02:47.810 is. There's actually no particular prescribed way on how 00:02:47.810 --> 00:02:50.150 to do this. In many apps where I've done 00:02:50.150 --> 00:02:51.870 this, the Rails application is still at the root 00:02:51.870 --> 00:02:54.120 of the project. But in this particular one, I 00:02:54.120 --> 00:02:56.700 chose the other version, where Rails moves into a 00:02:56.700 --> 00:02:58.940 sub-folder and, as you can see here, so this 00:02:58.940 --> 00:03:02.550 looks pretty much like Rails. But it doesn't have 00:03:02.550 --> 00:03:05.080 an app folder. There, and you might be asking, 00:03:05.080 --> 00:03:06.880 is there nothing happening in this app? 00:03:06.880 --> 00:03:10.209 Well, there is. Here, we see there's, at least 00:03:10.209 --> 00:03:12.240 one thing is mounted. There is an engine that's 00:03:12.240 --> 00:03:18.250 mounted. So, Teaser::Engine. I don't know if anyone has 00:03:18.250 --> 00:03:21.260 ever downloaded that from RubyGems. Well, don't try. I 00:03:21.260 --> 00:03:22.640 don't know what that gem would be. But I 00:03:22.640 --> 00:03:23.990 didn't upload it there. 00:03:23.990 --> 00:03:25.430 Let's look at the gem file to find out 00:03:25.430 --> 00:03:28.280 what that gem is. So this is the, the 00:03:28.280 --> 00:03:30.270 only kind of trick that you need to employ 00:03:30.270 --> 00:03:33.700 when you want to write component-based architectures. And that 00:03:33.700 --> 00:03:36.310 is, you use gems as not a, not as 00:03:36.310 --> 00:03:39.060 a distribution mechanism, but just as a packaging mechanism 00:03:39.060 --> 00:03:41.430 for parts of your application. 00:03:41.430 --> 00:03:43.400 You leave them in the same source tree and 00:03:43.400 --> 00:03:45.620 you just reference them. And then you can do 00:03:45.620 --> 00:03:47.700 everything you're used to with those things. 00:03:47.700 --> 00:03:49.489 So, as you can see here, if we go 00:03:49.489 --> 00:03:51.430 to the components folder, we expect to see a 00:03:51.430 --> 00:03:53.489 teaser folder. Ah. Which we do. And there is 00:03:53.489 --> 00:03:56.020 an engine. So that's just a Rails. Ah, sorry. 00:03:56.020 --> 00:03:58.700 A RubyGem that is pimped a little bit so 00:03:58.700 --> 00:04:02.900 it has Active star. All the Actives. So Rails 00:04:02.900 --> 00:04:05.650 in it. And this, indeed, now looks like an 00:04:05.650 --> 00:04:06.670 application. 00:04:06.670 --> 00:04:09.730 If you don't know what an engine is, it's 00:04:09.730 --> 00:04:12.099 essentially Rails minus everything you need to actually get 00:04:12.099 --> 00:04:15.800 it booted. So, if we look in here, what 00:04:15.800 --> 00:04:18.279 we can see, you know, there's a routes file 00:04:18.279 --> 00:04:21.199 and this engine is doing something, right. There's. It's 00:04:21.199 --> 00:04:23.960 normal. Here we'll look in apps. So the controller. 00:04:23.960 --> 00:04:26.400 So you can see this is namespaced under the 00:04:26.400 --> 00:04:28.930 name, which is nice. But it's just, you know, 00:04:28.930 --> 00:04:32.789 your ordinary controller. But, again, everything's namespaced. 00:04:32.789 --> 00:04:38.220 There's assets in here. Yeah. This is pretty normal, 00:04:38.220 --> 00:04:42.620 standard stuff. We even have migrations down here in 00:04:42.620 --> 00:04:45.510 this engine. What else would I talk about? Well, 00:04:45.510 --> 00:04:48.190 ah, yes. Maybe the coolest part. There's specs in 00:04:48.190 --> 00:04:49.990 here. I like to use rSpec. That could be 00:04:49.990 --> 00:04:52.220 tests in here if you're doing this and liking 00:04:52.220 --> 00:04:53.330 those better. 00:04:53.330 --> 00:04:57.980 But there's, there's a spec here for this controller 00:04:57.980 --> 00:05:00.080 that I just looked at, and the cool thing 00:05:00.080 --> 00:05:02.540 about that, and I don't know how to emphasize 00:05:02.540 --> 00:05:04.000 it more than to come up to the front 00:05:04.000 --> 00:05:07.340 of the stage and say it's very important that 00:05:07.340 --> 00:05:09.240 I can run these tests, and the only thing 00:05:09.240 --> 00:05:11.300 that these tests are gonna load is the code 00:05:11.300 --> 00:05:13.600 from this engine, and not from all the other 00:05:13.600 --> 00:05:16.490 stuff in my Big Rails application. 00:05:16.490 --> 00:05:20.090 So, just by there being a spec folder in 00:05:20.090 --> 00:05:21.800 here, I have a part of which I can 00:05:21.800 --> 00:05:24.650 prove that it is small. Or, at least, as 00:05:24.650 --> 00:05:26.620 big as only this part, and not depending on 00:05:26.620 --> 00:05:28.710 anything else. 00:05:28.710 --> 00:05:33.100 I, for, what I typically do, then, to kind 00:05:33.100 --> 00:05:36.100 of bind these components together - and there's more 00:05:36.100 --> 00:05:37.840 in this folder, as you can see. There's this 00:05:37.840 --> 00:05:40.300 event counter signup and whatnot. So I write a 00:05:40.300 --> 00:05:42.290 little script here that binds all the tests. As 00:05:42.290 --> 00:05:43.840 you can see there's some request specs and some 00:05:43.840 --> 00:05:46.320 Jasmine specs, and if you look into the other 00:05:46.320 --> 00:05:49.490 folders, you find more of these test files. And 00:05:49.490 --> 00:05:54.169 then in the root. I typically put this, this 00:05:54.169 --> 00:05:56.500 build script here. And what this does is loops 00:05:56.500 --> 00:05:58.449 over all the folders and tries to find test 00:05:58.449 --> 00:05:59.320 files and runs them. 00:05:59.320 --> 00:06:01.330 So you can still run this as the app, 00:06:01.330 --> 00:06:03.449 as the specs to one application. But if you 00:06:03.449 --> 00:06:05.229 just change one part, you can just test that 00:06:05.229 --> 00:06:08.699 one part and still be sure that it works. 00:06:08.699 --> 00:06:11.590 So, now that you know what these applications are, 00:06:11.590 --> 00:06:13.190 you don't need to think about all those little 00:06:13.190 --> 00:06:14.780 things. How to hook them up. You'll find out 00:06:14.780 --> 00:06:16.410 about that when you try to do it. What's 00:06:16.410 --> 00:06:17.630 important about them is that you can now talk 00:06:17.630 --> 00:06:22.280 about your application as a sum of smaller parts. 00:06:22.280 --> 00:06:24.030 For example, the app that I just showed you 00:06:24.030 --> 00:06:26.759 is a empty Rails container that mounts an engine 00:06:26.759 --> 00:06:28.259 that uses two other engines that I didn't talk 00:06:28.259 --> 00:06:30.110 about and another gem. 00:06:30.110 --> 00:06:31.900 This is a project that it recently, it o- 00:06:31.900 --> 00:06:34.389 that was a tiny project, so this was Tiny 00:06:34.389 --> 00:06:37.650 Rails. Empty Rails container. Two engines. The one was 00:06:37.650 --> 00:06:40.660 using two gems to talk to APIs, and the 00:06:40.660 --> 00:06:45.290 other one was just straight-up, pretty much normal application. 00:06:45.290 --> 00:06:47.320 Or this site that was a travel site. It 00:06:47.320 --> 00:06:49.780 was so small, we didn't even bother to use 00:06:49.780 --> 00:06:51.620 engines. We just put a couple gems in there 00:06:51.620 --> 00:06:53.630 that were talking to APIs. 00:06:53.630 --> 00:06:55.889 This site was a bit bigger. It started out 00:06:55.889 --> 00:06:59.080 like this. We had six engines, one gem, and 00:06:59.080 --> 00:07:01.139 it ended up about like this. But this is 00:07:01.139 --> 00:07:03.150 a lie, because there were about twice as many 00:07:03.150 --> 00:07:05.440 engines, only the other ones are abstracted away for 00:07:05.440 --> 00:07:07.060 clarity in this picture. As you can see, it's 00:07:07.060 --> 00:07:08.150 a very clear picture. 00:07:08.150 --> 00:07:12.210 Now, this looks chaotic. But the fact that I 00:07:12.210 --> 00:07:14.770 can draw such a chaotic picture about your application, 00:07:14.770 --> 00:07:16.680 but if you, if you were to draw the 00:07:16.680 --> 00:07:19.220 arrows a bit straighter, you would see that the 00:07:19.220 --> 00:07:23.009 dependencies all go in one direction, and that there 00:07:23.009 --> 00:07:25.500 are parts that other parts are based upon, right. 00:07:25.500 --> 00:07:28.330 So this app is composed of parts, and it's 00:07:28.330 --> 00:07:31.360 no longer a ball of mud. 00:07:31.360 --> 00:07:32.690 The fact that you can see that this is 00:07:32.690 --> 00:07:36.539 a complicated domain is an improvement, despite this picture 00:07:36.539 --> 00:07:38.220 looking a bit weird. This picture is from Ben 00:07:38.220 --> 00:07:41.180 Smith's talk about how he architected his Big Rails 00:07:41.180 --> 00:07:43.630 app for success, which he gave at Rocky Mountain 00:07:43.630 --> 00:07:46.630 Ruby last year. And I recommend you watch that 00:07:46.630 --> 00:07:47.550 talk. 00:07:47.550 --> 00:07:51.139 So, if you're like, what? Now? Why would I 00:07:51.139 --> 00:07:53.610 do that? As I just said. Because it helps. 00:07:53.610 --> 00:07:57.160 When applications get big, I believe it's fundamentally important 00:07:57.160 --> 00:07:58.949 to be able to think about the parts of 00:07:58.949 --> 00:08:04.919 the application independently, as much as possible. 00:08:04.919 --> 00:08:08.259 There's a bunch of resources that, you know. I've 00:08:08.259 --> 00:08:10.430 given talks about this. Ben's given talks about this. 00:08:10.430 --> 00:08:13.300 There's blog posts about this. And there's, most importantly, 00:08:13.300 --> 00:08:16.729 that repository that I recommend you look at. 00:08:16.729 --> 00:08:22.509 OK. Back to Big Rails. How big? Does anyone 00:08:22.509 --> 00:08:25.039 here think they're working on a big Rails application? 00:08:25.039 --> 00:08:29.910 OK. That's about a third. So, I've, I think 00:08:29.910 --> 00:08:31.590 I've worked on a couple, but I didn't know 00:08:31.590 --> 00:08:33.818 what to show, because I work for Pivatol Labs 00:08:33.818 --> 00:08:36.198 and we consult and the code is our clients', 00:08:36.198 --> 00:08:38.509 so I can't show it here, so I won't. 00:08:38.509 --> 00:08:41.130 But I went onto this thing called Google and 00:08:41.130 --> 00:08:43.289 I searched for open source Rails apps, and there 00:08:43.289 --> 00:08:45.350 they were. So these claim to be big Rails 00:08:45.350 --> 00:08:45.940 apps. 00:08:45.940 --> 00:08:50.060 How big, I wondered. Well, if you have, currently, 00:08:50.060 --> 00:08:53.660 on your laptop, your company's code, please, execute this 00:08:53.660 --> 00:08:57.279 script and Tweet the result with a #cbra hashtag, 00:08:57.279 --> 00:08:58.930 cause this is just gonna open how many lines 00:08:58.930 --> 00:09:00.630 of code your app has. 00:09:00.630 --> 00:09:03.420 And here's the result for this list of applications. 00:09:03.420 --> 00:09:06.580 So, as you can see, they're not all simi- 00:09:06.580 --> 00:09:09.890 not all the same interpretation of big. So we're 00:09:09.890 --> 00:09:13.910 going from about 400,000 lines of code to still 00:09:13.910 --> 00:09:17.000 in the thousands. If you look at the files, 00:09:17.000 --> 00:09:20.770 same picture. Thousands of files for the biggest apps, 00:09:20.770 --> 00:09:24.660 and still hundreds for the smaller ones. 00:09:24.660 --> 00:09:28.300 I'll accept that as big. And I hope you 00:09:28.300 --> 00:09:32.910 will too. Ever wonder what happens to the complexity 00:09:32.910 --> 00:09:37.110 within a system as it grows? Something like this 00:09:37.110 --> 00:09:40.390 happens. And maybe this is bad as that, and 00:09:40.390 --> 00:09:43.649 you just can't take it anymore. 00:09:43.649 --> 00:09:46.700 When you introduce structure, you fundamentally change the game. 00:09:46.700 --> 00:09:49.899 Oh. I'm supposed to say, first, that this is 00:09:49.899 --> 00:09:52.860 because the number of interactions between the elements inside 00:09:52.860 --> 00:09:56.370 the system grows somewhat like an exponential, in an 00:09:56.370 --> 00:10:00.089 exponential function when you add new, new parts to 00:10:00.089 --> 00:10:01.830 this system. 00:10:01.830 --> 00:10:06.230 So it explodes in complexity. Well, what if you 00:10:06.230 --> 00:10:11.290 were able to split a system and use a 00:10:11.290 --> 00:10:14.600 complex web of service objects, maybe, to connect the 00:10:14.600 --> 00:10:17.010 two. But you have two smaller parts that can 00:10:17.010 --> 00:10:20.200 now, that are now isolated, in some way, what 00:10:20.200 --> 00:10:21.510 happens to the complexity? 00:10:21.510 --> 00:10:26.440 Well, turns out, it's still this, and probably still 00:10:26.440 --> 00:10:33.440 that. But only half as fast. And that's good. 00:10:35.760 --> 00:10:37.430 If you. I wish I could run up to 00:10:37.430 --> 00:10:39.310 the slide right now. But, you see that green 00:10:39.310 --> 00:10:42.160 line at the bottom? It's almost flat. Now imagine 00:10:42.160 --> 00:10:44.680 you could split it again, and again, and again, 00:10:44.680 --> 00:10:46.700 and you always stay in this flatter part, so 00:10:46.700 --> 00:10:50.040 your complexity never really explodes. You get those crazy 00:10:50.040 --> 00:10:52.320 diagrams that I was showing earlier, but your complexity 00:10:52.320 --> 00:10:55.060 doesn't explode quite as badly. You're still writing a 00:10:55.060 --> 00:10:57.200 huge app, and that's something that I'm not gonna 00:10:57.200 --> 00:11:00.010 discuss away. But you might be able to manage 00:11:00.010 --> 00:11:06.480 it better. 00:11:06.480 --> 00:11:11.260 The rich get rich and the poor get. Anyone? 00:11:11.260 --> 00:11:17.420 Children. I. This is from a song from the 00:11:17.420 --> 00:11:20.100 1920s, and while it's funny, the, the first part 00:11:20.100 --> 00:11:25.660 of this alludes to a thing called preferential attachment. 00:11:25.660 --> 00:11:29.200 Preferential attachment is a set of processes where, when, 00:11:29.200 --> 00:11:33.350 where, god. This is so hard to say. Where, 00:11:33.350 --> 00:11:36.630 when you, where the amount of things you have, 00:11:36.630 --> 00:11:38.230 whatever that might be - the thing, or you 00:11:38.230 --> 00:11:42.899 - defines how much you will get. 00:11:42.899 --> 00:11:47.830 So, 2006, Chris Anderson I think, wrote about the 00:11:47.830 --> 00:11:51.420 long tail in, in publishing and books. And he, 00:11:51.420 --> 00:11:53.870 this, this curve became very popular. He called, I 00:11:53.870 --> 00:11:55.600 think he even called the book The Long Tail. 00:11:55.600 --> 00:11:57.160 And he was concentrated on the right side of 00:11:57.160 --> 00:11:58.930 this tail. 00:11:58.930 --> 00:12:00.790 So you have many, many small things that don't 00:12:00.790 --> 00:12:04.540 get any traction. But, you know, Netflix allows us 00:12:04.540 --> 00:12:06.870 to view all those movies that no one wants, 00:12:06.870 --> 00:12:08.930 that no one else wants to see. But there's 00:12:08.930 --> 00:12:11.370 just a very few movies at the front that 00:12:11.370 --> 00:12:14.410 everyone wants to see. The Blockbusters. And, while the 00:12:14.410 --> 00:12:17.440 long tail is very interesting, it's the ones in 00:12:17.440 --> 00:12:22.760 the front that harvest most of the benefits, well 00:12:22.760 --> 00:12:24.700 I guess in the case of movies. 00:12:24.700 --> 00:12:27.519 So, the green to the yellow relationship is about, 00:12:27.519 --> 00:12:32.829 80% of the, the tail versus 20% is inverse 00:12:32.829 --> 00:12:34.769 in the relationship to how much they have. So 00:12:34.769 --> 00:12:38.500 it's 20/80, 80/20. 00:12:38.500 --> 00:12:43.209 And, preferential attachment, as I said, happens when you 00:12:43.209 --> 00:12:45.910 already have a lot, so you get more. And 00:12:45.910 --> 00:12:48.350 I have seen so many code bases that I 00:12:48.350 --> 00:12:50.140 have the feeling there's something like that going on 00:12:50.140 --> 00:12:52.750 in code. So I looked at these code bases, 00:12:52.750 --> 00:12:56.180 and again, I typed in this bash script. First 00:12:56.180 --> 00:13:00.670 try of course. 00:13:00.670 --> 00:13:02.230 And I urge you to do the same. Now, 00:13:02.230 --> 00:13:04.029 you will not be able to Tweet this, because 00:13:04.029 --> 00:13:06.579 this lists all the files, all the Ruby files, 00:13:06.579 --> 00:13:10.790 in your app by size. And when you do 00:13:10.790 --> 00:13:14.730 that, that looks about like this for these applications. 00:13:14.730 --> 00:13:19.860 Now, does that not look similar? 00:13:19.860 --> 00:13:22.040 There's another way of saying this, you know, the 00:13:22.040 --> 00:13:24.700 rich get richer. There's a German proverb. I'm from 00:13:24.700 --> 00:13:29.860 Germany. Hi. That proverb is that Der Teufel scheißt 00:13:29.860 --> 00:13:32.310 immer auf den größten Haufen. Or, the Devil always 00:13:32.310 --> 00:13:35.560 shits on the biggest pile. 00:13:35.560 --> 00:13:39.089 And I think something like that is going on 00:13:39.089 --> 00:13:46.089 here. And which file might that be? So who 00:13:46.440 --> 00:13:48.010 thinks that might be a good guess as to 00:13:48.010 --> 00:13:51.700 which file that is? And, lower your, don't lower 00:13:51.700 --> 00:13:54.290 your hand, because it's probably actually yours. I said 00:13:54.290 --> 00:13:55.839 this two days ago and then the guy next 00:13:55.839 --> 00:13:57.870 to me shows me his Ruby, his user file 00:13:57.870 --> 00:14:00.160 and it's literally this long and I'm like, oh 00:14:00.160 --> 00:14:02.170 god, don't do this to me. 00:14:02.170 --> 00:14:04.550 But everyone else knows this problem. The user is 00:14:04.550 --> 00:14:07.420 around earlier. He is important to the system, so 00:14:07.420 --> 00:14:10.950 he attaches, he attracts functionality. But to the point 00:14:10.950 --> 00:14:13.100 where I would say that is a pile of 00:14:13.100 --> 00:14:15.310 shit, man. 00:14:15.310 --> 00:14:19.570 And I thought that would be something else I 00:14:19.570 --> 00:14:22.420 could find. So I looked at associations. Associations are 00:14:22.420 --> 00:14:28.510 another way of expressing dependencies. In fact, so when, 00:14:28.510 --> 00:14:30.250 I want to talk about has_manys, because I find 00:14:30.250 --> 00:14:31.730 them particularly interesting. 00:14:31.730 --> 00:14:38.730 So, you have something that has_many. User, maybe. So 00:14:40.360 --> 00:14:42.130 since I assumed it was user, I want you 00:14:42.130 --> 00:14:45.029 to read this code and, kind of reflecting on 00:14:45.029 --> 00:14:48.950 yesterday's keynote, I find this file very readable. The 00:14:48.950 --> 00:14:55.810 user has_many :cars, :flowers, :trees, :houses, :moods, :checks. Hopefully. 00:14:55.810 --> 00:14:57.360 I think we can agree that it's very readable. 00:14:57.360 --> 00:15:00.040 It makes a lot of sense and we can, 00:15:00.040 --> 00:15:01.850 we can empathize with this class. 00:15:01.850 --> 00:15:04.389 Have you ever wondered what's funny about this when 00:15:04.389 --> 00:15:05.769 you look at the table and there is no 00:15:05.769 --> 00:15:09.019 mention of :cars, :flowers, :trees, :houses, :moods, and :checks 00:15:09.019 --> 00:15:13.000 in that table at all? You don't find it 00:15:13.000 --> 00:15:14.779 funny to write that user class, but would you 00:15:14.779 --> 00:15:16.570 find it funny if I wrote a color class 00:15:16.570 --> 00:15:18.750 like that? 00:15:18.750 --> 00:15:20.060 Why do we not write that color class? Why 00:15:20.060 --> 00:15:22.329 do we always write that user class? I'll tell 00:15:22.329 --> 00:15:24.950 you why. Because users are important to us, and 00:15:24.950 --> 00:15:26.970 we always write them first, and then we attach 00:15:26.970 --> 00:15:30.290 all sorts of stuff to them that doesn't belong 00:15:30.290 --> 00:15:34.579 to them. This table clearly says what belongs to, 00:15:34.579 --> 00:15:37.399 sorry, a user. Namely, in this case, a name 00:15:37.399 --> 00:15:39.880 and a home. 00:15:39.880 --> 00:15:42.500 So I've kind of gotten the opinion that we 00:15:42.500 --> 00:15:47.329 shouldn't be using has_many too much. You can check, 00:15:47.329 --> 00:15:49.220 and I would be very interested in the results, 00:15:49.220 --> 00:15:52.560 again, so there's another gist. Please, try it out 00:15:52.560 --> 00:15:55.880 if you can. 00:15:55.880 --> 00:16:02.639 Whoops. And guess which file is on the left? 00:16:02.639 --> 00:16:07.170 Yeah. He shat on that again. The, it's the 00:16:07.170 --> 00:16:10.740 user. And it's ot always actually the user. I 00:16:10.740 --> 00:16:13.470 shouldn't be saying that. I should say, it's probably 00:16:13.470 --> 00:16:15.810 always, to some extent, the user. But what's your 00:16:15.810 --> 00:16:21.079 domain? If your domain is, I don't know, money? 00:16:21.079 --> 00:16:25.730 Houses? Properties? I don't know. It's probably that file. 00:16:25.730 --> 00:16:28.010 Whatever I just said or whatever is in your 00:16:28.010 --> 00:16:30.300 name. That's that file. 00:16:30.300 --> 00:16:32.160 And that attracts all the functionality. But the user 00:16:32.160 --> 00:16:36.040 is typically not far behind. And, because I want 00:16:36.040 --> 00:16:39.070 to. Yeah, I just. I think this is very 00:16:39.070 --> 00:16:41.079 enlightening. So, I just opened to the project I 00:16:41.079 --> 00:16:43.029 just showed you. I opened all the user files, 00:16:43.029 --> 00:16:46.220 and I'm just gonna scroll through them, K. 00:16:46.220 --> 00:16:53.220 This is not very intimidating. Eh. This is a 00:16:54.579 --> 00:17:01.510 bit better. Ooh. I'm trying to be non-discriminatory here 00:17:01.510 --> 00:17:08.510 and go the same speed 00:17:15.130 --> 00:17:15.599 all the time. Ooh. 00:17:15.599 --> 00:17:22.378 Oh. Oh you wait. Now, I have to speed 00:17:22.378 --> 00:17:26.039 up. 00:17:26.039 --> 00:17:29.509 And it's, you, this one file looks particularly bad 00:17:29.509 --> 00:17:32.789 maybe, but it's probably the case that these user 00:17:32.789 --> 00:17:36.119 files are big to the extent that their applications 00:17:36.119 --> 00:17:40.999 are big. These files just tend to do that. 00:17:40.999 --> 00:17:44.359 These models just attract that. 00:17:44.359 --> 00:17:51.359 So, what does that mean? 00:17:51.549 --> 00:17:53.850 To recap. We have things that grow, and when 00:17:53.850 --> 00:17:56.619 they grow, they get exponentially more, they get more 00:17:56.619 --> 00:17:59.879 complex. They get exponentially more complex. And then in 00:17:59.879 --> 00:18:01.399 those things, there are certain things that are, you 00:18:01.399 --> 00:18:05.700 know, that are the top of the badness scale. 00:18:05.700 --> 00:18:09.879 And, and those things that also depend on everything 00:18:09.879 --> 00:18:15.859 else in the system. 00:18:15.859 --> 00:18:22.100 I don't know. I think we can do better. 00:18:22.100 --> 00:18:24.479 We can try to reduce the size of the 00:18:24.479 --> 00:18:28.210 parts. Maybe flatten out that curve and reduce the 00:18:28.210 --> 00:18:34.859 number of dependencies in between those parts. Something that 00:18:34.859 --> 00:18:38.429 has helped me in doing that has been Solid, 00:18:38.429 --> 00:18:45.159 the five ideas, principles. Signs, truths. I don't know. 00:18:45.159 --> 00:18:45.840 No. 00:18:45.840 --> 00:18:48.950 And especially for this problem, the Single Responsibility Principle. 00:18:48.950 --> 00:18:52.859 I think if you just apply that as a 00:18:52.859 --> 00:18:56.409 rule of thumb, as a, as a starter for 00:18:56.409 --> 00:19:00.739 a conversation, it will, over time, on average, improve 00:19:00.739 --> 00:19:04.119 the quality of your code. But I think there's 00:19:04.119 --> 00:19:06.859 something funny going on when we discuss single responsibility. 00:19:06.859 --> 00:19:10.999 Oh. Yes. What's single responsibility for? To find things 00:19:10.999 --> 00:19:17.999 that don't belong. Clearly it's the cat with the 00:19:18.239 --> 00:19:21.179 green eyes. 00:19:21.179 --> 00:19:27.889 Where, where to apply Single Responsibility Principle? If you've 00:19:27.889 --> 00:19:29.489 been to any of the refactoring talks - I 00:19:29.489 --> 00:19:31.190 didn't have a chance this time - but I'm 00:19:31.190 --> 00:19:35.509 pretty sure you refactored some methods. We look at 00:19:35.509 --> 00:19:37.679 methods, we want them to be better. We make 00:19:37.679 --> 00:19:40.210 them smaller. We find what they are about and 00:19:40.210 --> 00:19:44.249 we give them one responsibility. Class. We probably did 00:19:44.249 --> 00:19:46.639 the same, right. We look at a class, we're 00:19:46.639 --> 00:19:48.909 like, oh, this does a little bit much. But 00:19:48.909 --> 00:19:51.159 then we're like, OK, ActiveRecord is cool. I'm like, 00:19:51.159 --> 00:19:53.739 allowing it to save itself and soforth. So maybe 00:19:53.739 --> 00:19:55.519 that's OK. But it still kind of should be 00:19:55.519 --> 00:19:57.799 about this one thing. 00:19:57.799 --> 00:19:59.629 Except for user. 00:19:59.629 --> 00:20:01.309 So we're, on these two levels, I think we're 00:20:01.309 --> 00:20:06.600 really good. Module, and by that I mean a 00:20:06.600 --> 00:20:08.929 namespace. If you use module as mixin, I get 00:20:08.929 --> 00:20:10.769 like that I don't want to talk about that, 00:20:10.769 --> 00:20:13.970 and that's why I continue to say namespace. Why 00:20:13.970 --> 00:20:15.720 do I think this about mixins? I should maybe 00:20:15.720 --> 00:20:18.559 explain in one sentence. If you mixin stuff into 00:20:18.559 --> 00:20:21.159 your objects, the only thing you're doing is hiding 00:20:21.159 --> 00:20:23.190 away the fact that you have more complexity than 00:20:23.190 --> 00:20:24.869 you can bear to look at on one screen, 00:20:24.869 --> 00:20:26.129 so you put it on another so you don't 00:20:26.129 --> 00:20:29.179 have to see it. I would not do that. 00:20:29.179 --> 00:20:31.119 I mean, I have done it. I have written 00:20:31.119 --> 00:20:32.929 apps like that, and now I hate myself for 00:20:32.929 --> 00:20:35.210 it. But, I want to not do it anymore. 00:20:35.210 --> 00:20:37.749 So I think we shouldn't. So I use modules 00:20:37.749 --> 00:20:42.289 a lot, but as namespaces, to group things together. 00:20:42.289 --> 00:20:44.489 I think you should do that. You know, look 00:20:44.489 --> 00:20:47.450 at modules or namespaces and, and analyze whether they 00:20:47.450 --> 00:20:51.970 have one responsibility. But have you done that lately? 00:20:51.970 --> 00:20:54.099 It's harder, right? It doesn't mean a lot. You 00:20:54.099 --> 00:20:55.919 can, it doesn't, you know, no one cares if 00:20:55.919 --> 00:20:57.909 you go across these things. You just, you can 00:20:57.909 --> 00:21:01.789 load any class anyways. 00:21:01.789 --> 00:21:05.909 So I think we could get better at that. 00:21:05.909 --> 00:21:09.149 Let me jump a level. Application. And I think, 00:21:09.149 --> 00:21:11.169 again, you should. And the fact that we have 00:21:11.169 --> 00:21:13.220 this Big Rails track, and the fact that I'm 00:21:13.220 --> 00:21:15.499 talking about components, but pretty much everyone else is 00:21:15.499 --> 00:21:19.200 talking about SOAs, shows that we are talking about, 00:21:19.200 --> 00:21:21.879 what do applications mean? What does it mean for 00:21:21.879 --> 00:21:25.419 an application to do something? Or, yeah. To have 00:21:25.419 --> 00:21:27.849 a function in, in something bigger. 00:21:27.849 --> 00:21:30.519 So, I encourage you to go to all those 00:21:30.519 --> 00:21:34.039 tracks and make your applications better on that level 00:21:34.039 --> 00:21:35.889 as well. But I just talked to you about 00:21:35.889 --> 00:21:37.919 the component, and I think that sits in the 00:21:37.919 --> 00:21:40.749 middle. And in, in a certain way, the component 00:21:40.749 --> 00:21:44.039 is, is an improved namespace. Because of that thing 00:21:44.039 --> 00:21:46.299 I said earlier, namely, I can run tests and 00:21:46.299 --> 00:21:48.739 I can prove that those tests run without ever 00:21:48.739 --> 00:21:52.399 touching any code that is not in that namespace. 00:21:52.399 --> 00:21:56.799 So, now you can. And I urge you to 00:21:56.799 --> 00:22:02.019 do it. Because the cat picture, the discussion of 00:22:02.019 --> 00:22:04.950 what doesn't belong. If you are in your Big 00:22:04.950 --> 00:22:07.879 Rails app and you're writ- painting all those classes 00:22:07.879 --> 00:22:10.789 as boxes and the dependencies they have as arrows, 00:22:10.789 --> 00:22:14.700 first off, it's really easy to screw that up. 00:22:14.700 --> 00:22:16.389 Because there's no, you can't really prove that you're 00:22:16.389 --> 00:22:18.309 not using another class. At least not in run 00:22:18.309 --> 00:22:21.519 time with big applications. 00:22:21.519 --> 00:22:25.789 So components give you an arbitrarily scalable and provably 00:22:25.789 --> 00:22:29.509 independent way to talk about parts of your application. 00:22:29.509 --> 00:22:32.690 So I use it. Now, I said you should 00:22:32.690 --> 00:22:36.099 look at SOAs, and when, if you're considering refactoring 00:22:36.099 --> 00:22:38.389 your application to improve its quality and to make 00:22:38.389 --> 00:22:40.470 it more maintainable, I think there are a couple 00:22:40.470 --> 00:22:45.080 things you should know about or consider when deciding 00:22:45.080 --> 00:22:47.729 between the two. Right, you're kind of feeling pains 00:22:47.729 --> 00:22:50.559 right now, or you're not even yet feeling pains. 00:22:50.559 --> 00:22:53.249 Great place to be in, too. But there's a 00:22:53.249 --> 00:22:55.529 couple things that are really cool about just splitting 00:22:55.529 --> 00:22:57.379 up your application into these components. 00:22:57.379 --> 00:23:01.489 And that is, you stick with one repo. You 00:23:01.489 --> 00:23:04.399 have one test suite. But you can split it 00:23:04.399 --> 00:23:07.899 up. You have, still, one deployment. You can, however, 00:23:07.899 --> 00:23:11.279 use, like, a load balancer to push traffic to 00:23:11.279 --> 00:23:13.849 certain parts of the application to make the one 00:23:13.849 --> 00:23:16.340 faster, the other, you know, has less of a 00:23:16.340 --> 00:23:19.590 demand or, you know, you can go crazy. But 00:23:19.590 --> 00:23:21.929 you don't get these additional versioning constraints of where, 00:23:21.929 --> 00:23:23.799 like, if you, if you have this app and 00:23:23.799 --> 00:23:25.519 it needs that app and that app doesn't have 00:23:25.519 --> 00:23:27.619 the API yet, then I need to add this 00:23:27.619 --> 00:23:30.450 stuff here at the same time, and I need 00:23:30.450 --> 00:23:31.690 to deploy them at the same time. And if 00:23:31.690 --> 00:23:33.799 I didn't do that then everything goes down. 00:23:33.799 --> 00:23:35.210 You don't have that because you're still talking about 00:23:35.210 --> 00:23:40.099 one application. And also, one other thing that's very 00:23:40.099 --> 00:23:41.830 interesting to me, at least, is that, I never 00:23:41.830 --> 00:23:45.099 know which parts I need. On this crazy graph 00:23:45.099 --> 00:23:47.379 project that I just showed you, it went on 00:23:47.379 --> 00:23:50.450 for about six months. And, and there were three 00:23:50.450 --> 00:23:53.539 pairs on that. And at some point. Four pairs. 00:23:53.539 --> 00:23:55.090 And at some point, there was always one pair 00:23:55.090 --> 00:23:57.940 refactoring something. And they created, I think there were 00:23:57.940 --> 00:24:00.179 a couple weeks where they created basically a component 00:24:00.179 --> 00:24:02.519 a day. But they also removed a component. 00:24:02.519 --> 00:24:03.929 Try to do that with a SOA. Try to 00:24:03.929 --> 00:24:06.349 move that stuff around quickly. You can do a 00:24:06.349 --> 00:24:09.669 SOA, I think, when you, when you're sure you 00:24:09.669 --> 00:24:12.409 need pieces. But when you're playing around with parts 00:24:12.409 --> 00:24:14.529 of your application and you, you want to just 00:24:14.529 --> 00:24:16.009 structure it, and you want to still be able 00:24:16.009 --> 00:24:18.840 to move a part from one to the other, 00:24:18.840 --> 00:24:21.369 SOA is a bit heavy. 00:24:21.369 --> 00:24:26.690 Within a SOA, you can still think about your 00:24:26.690 --> 00:24:29.929 applications as being built of these components. There's, you 00:24:29.929 --> 00:24:34.129 know, nothing is exclusive there. Just do both. 00:24:34.129 --> 00:24:41.129 So, I've now spent about, most of my time 00:24:41.499 --> 00:24:44.299 telling you why you should refactor towards this. But 00:24:44.299 --> 00:24:45.840 I haven't done what I said in my title 00:24:45.840 --> 00:24:47.309 I would do, namely tell you how to refactor 00:24:47.309 --> 00:24:51.469 towards it. I'm sorry about that. But I gave 00:24:51.469 --> 00:24:55.429 you this idea, right. And you all believed me. 00:24:55.429 --> 00:24:58.659 This is easy. 00:24:58.659 --> 00:25:01.769 Today's day of the, International Day of the Book. 00:25:01.769 --> 00:25:06.869 I looked in these books. Refactoring to Patterns. Refactoring. 00:25:06.869 --> 00:25:10.849 Awesome books. But they don't talk about this either. 00:25:10.849 --> 00:25:12.379 And I think the reason is that this stuff 00:25:12.379 --> 00:25:15.429 is not very important in other languages. In Java, 00:25:15.429 --> 00:25:17.759 you do packages every day and you have implicit 00:25:17.759 --> 00:25:20.070 imports. In Go, you do that. Other languages do 00:25:20.070 --> 00:25:22.859 not have this problem, because other languages do not 00:25:22.859 --> 00:25:25.580 allow for this kind of freedom and openness that 00:25:25.580 --> 00:25:31.210 we've gotten because we do Ruby. 00:25:31.210 --> 00:25:35.259 So, I call these two refactorings, teasing out an 00:25:35.259 --> 00:25:39.090 app component and extracting a functional component. And the 00:25:39.090 --> 00:25:40.259 reason I don't want to spend much time on 00:25:40.259 --> 00:25:42.049 it is because it's actually very simple to do 00:25:42.049 --> 00:25:46.429 it. The devil's just in the details. 00:25:46.429 --> 00:25:48.969 And there is no book about this. But I'm 00:25:48.969 --> 00:25:52.219 trying to write one. And if you, I don't 00:25:52.219 --> 00:25:54.469 know, show, if you're interested in this, send a 00:25:54.469 --> 00:25:56.440 message there and I might be more inclined to 00:25:56.440 --> 00:25:58.059 actually sit down. 00:25:58.059 --> 00:26:01.789 All right. But to the first one - teasing 00:26:01.789 --> 00:26:08.729 out an app component. So, step zero. Got tests? 00:26:08.729 --> 00:26:11.099 If, if you don't have tests, I wouldn't move 00:26:11.099 --> 00:26:13.590 as much code as we're about to move. I 00:26:13.590 --> 00:26:16.710 mean, virtually. But, you should add some tests around 00:26:16.710 --> 00:26:19.190 the stuff that you want to extract. 00:26:19.190 --> 00:26:21.479 And then you, for the app component. So that's 00:26:21.479 --> 00:26:24.539 this teaser thing we looked at. So we're, a 00:26:24.539 --> 00:26:27.119 component of your application, where you almost thing, this 00:26:27.119 --> 00:26:30.070 could be its own application, maybe. So you look 00:26:30.070 --> 00:26:35.139 for this vertical. Views, controllers, models. You find that 00:26:35.139 --> 00:26:38.149 vertical that makes sense on its own and you 00:26:38.149 --> 00:26:39.479 namespace it. 00:26:39.479 --> 00:26:42.059 A funny thing happens when you just namespace it. 00:26:42.059 --> 00:26:44.609 Suddenly, the things in there. Well, first off, what's 00:26:44.609 --> 00:26:46.369 awful about it is you have to rename all 00:26:46.369 --> 00:26:49.479 your tables. OK. But that aside, you suddenly start 00:26:49.479 --> 00:26:53.499 seeing what's actually in your vertical and what's not. 00:26:53.499 --> 00:26:55.379 You could actually put colon colon in front of 00:26:55.379 --> 00:26:56.849 everything else that's not, and you would get a 00:26:56.849 --> 00:26:59.719 really easy view parsing or, or way of seeing 00:26:59.719 --> 00:27:02.269 in your files what's not in your vertical. 00:27:02.269 --> 00:27:06.200 Those are your external dependencies to, an external to 00:27:06.200 --> 00:27:08.259 the app. So when you do this at first, 00:27:08.259 --> 00:27:09.929 you're apps gonna be unhappy. So please make your 00:27:09.929 --> 00:27:12.889 tests green. And to do that, you will need 00:27:12.889 --> 00:27:15.340 to find other parts that you didn't know you 00:27:15.340 --> 00:27:19.899 depended upon, and you move them into what's gonna 00:27:19.899 --> 00:27:25.379 be the component. Into this vertical. 00:27:25.379 --> 00:27:28.599 And when you got this vertical green, you extract 00:27:28.599 --> 00:27:34.139 it into an engine. Extracting into an engine is 00:27:34.139 --> 00:27:37.519 rails plugin new component dash dash full, dash dash 00:27:37.519 --> 00:27:39.659 mountable. In most cases. 00:27:39.659 --> 00:27:41.239 It doesn't matter. 00:27:41.239 --> 00:27:48.239 And step three, profit. Now, most of the time, 00:27:49.460 --> 00:27:52.200 this vertical will not be as easy to find 00:27:52.200 --> 00:27:55.330 as I just pretended it would be. And that's 00:27:55.330 --> 00:28:01.519 because of, you guessed it, user. Right? The user 00:28:01.519 --> 00:28:05.419 is probably somewhere, and other things as well, are 00:28:05.419 --> 00:28:08.589 used somewhere, are needed somewhere, but don't really belong 00:28:08.589 --> 00:28:09.940 to this verticle. 00:28:09.940 --> 00:28:13.119 And what I've found is when you refactor towards 00:28:13.119 --> 00:28:14.979 this, if you abstract. If you, if you're coming 00:28:14.979 --> 00:28:17.649 from one big piece, if you want to abstract 00:28:17.649 --> 00:28:20.570 one thing, you're gonna abstract two. The one thing 00:28:20.570 --> 00:28:24.200 you wanted and the common stuff. But please do 00:28:24.200 --> 00:28:26.339 not call that stuff common, because that's just gonna 00:28:26.339 --> 00:28:28.219 be another pile of shit that you can attach 00:28:28.219 --> 00:28:30.169 stuff to. Call it something else. Call it user 00:28:30.169 --> 00:28:34.210 if you have to. 00:28:34.210 --> 00:28:36.049 So this special case is not a special case. 00:28:36.049 --> 00:28:38.460 I think this is, of course there is lots 00:28:38.460 --> 00:28:40.529 of meat in how to do this and where 00:28:40.529 --> 00:28:43.029 you get hung up on certain gem dependencies and 00:28:43.029 --> 00:28:45.210 engines not doing it exactly the way that Rails 00:28:45.210 --> 00:28:48.019 does it and blah, blah, blah. But essentially this 00:28:48.019 --> 00:28:52.139 is it. 00:28:52.139 --> 00:28:55.109 The other side to this is, is, something even 00:28:55.109 --> 00:29:01.839 more interesting. It's abstracting functional components. Now your app 00:29:01.839 --> 00:29:05.469 is round, suddenly. I don't know why. Again, got 00:29:05.469 --> 00:29:08.759 tests? Let's start there. 00:29:08.759 --> 00:29:11.200 So you find a functional component, and yes, I 00:29:11.200 --> 00:29:14.029 made that much smaller than that verticle. Because typically 00:29:14.029 --> 00:29:16.239 you find a piece that is really, really separate. 00:29:16.239 --> 00:29:20.369 A very special functionality. Maybe even something mathematically a 00:29:20.369 --> 00:29:23.839 function. In and out. Some processing. You find that 00:29:23.839 --> 00:29:27.909 and you create a gem. 00:29:27.909 --> 00:29:30.109 And you move the tests in there as well, 00:29:30.109 --> 00:29:31.960 and your gem is, when you run those tests, 00:29:31.960 --> 00:29:34.440 the gem's gonna be unhappy, because of all those 00:29:34.440 --> 00:29:38.219 dependencies that you didn't see coming. So, you take 00:29:38.219 --> 00:29:42.419 all those and you move them in. And you 00:29:42.419 --> 00:29:44.539 make your tests happy. 00:29:44.539 --> 00:29:47.489 Well, and now you require that gem in the 00:29:47.489 --> 00:29:50.349 main app, and your main app is totally unhappy. 00:29:50.349 --> 00:29:51.719 Because it doesn't know how to talk to that 00:29:51.719 --> 00:29:57.950 gem anymore. And if there were any ActiveRecord dependencies, 00:29:57.950 --> 00:30:00.690 or other dependencies on, on stuff that came from 00:30:00.690 --> 00:30:03.659 Rails, I would urge you to try and keep 00:30:03.659 --> 00:30:06.139 that out of, of these kinds of gems, because 00:30:06.139 --> 00:30:08.200 it just adds such a huge surface area and 00:30:08.200 --> 00:30:11.339 stuff that could happen, could be done and could 00:30:11.339 --> 00:30:12.139 go wrong. 00:30:12.139 --> 00:30:15.299 I, I would urge you to find these connections, 00:30:15.299 --> 00:30:20.629 these, the shims, maybe. Call them ports and adapters. 00:30:20.629 --> 00:30:23.419 And move them in the app closer to the 00:30:23.419 --> 00:30:25.799 surface area of this gem, so that you can 00:30:25.799 --> 00:30:28.309 do the processing of whatever that is there, and 00:30:28.309 --> 00:30:30.969 that talks to the gem and makes it work 00:30:30.969 --> 00:30:33.580 again. So now the app is happy. And you 00:30:33.580 --> 00:30:37.080 got this weird kind of lump on the side. 00:30:37.080 --> 00:30:38.349 But that's a good thing. 00:30:38.349 --> 00:30:40.739 In, in one of the books, actually I think 00:30:40.739 --> 00:30:42.909 it's Eric Evans, it's called Bound to Context. Now 00:30:42.909 --> 00:30:45.440 you have a thing that is only relevant for 00:30:45.440 --> 00:30:49.639 a context. But that's how you take from that, 00:30:49.639 --> 00:30:52.450 from that curve that has the huge left side. 00:30:52.450 --> 00:30:54.149 That's how you chip away at the top and 00:30:54.149 --> 00:30:56.529 put it somewhere at the end. Because this thing, 00:30:56.529 --> 00:30:59.149 in a bound context, it only has one meaning. 00:30:59.149 --> 00:31:00.599 And that's why it's gonna be smaller. 00:31:00.599 --> 00:31:07.599 So, step three. Profit. 00:31:07.820 --> 00:31:14.299 I hope that made sense. And I know. It 00:31:14.299 --> 00:31:16.649 doesn't work that easily. It's not five steps. It 00:31:16.649 --> 00:31:19.609 can take weeks. The first time we tried this, 00:31:19.609 --> 00:31:22.089 it took three attempts and four weeks in one 00:31:22.089 --> 00:31:24.759 app that we wanted to split into two. And 00:31:24.759 --> 00:31:26.889 we ended up with three, and now I think 00:31:26.889 --> 00:31:30.169 it's about ten. But, trust me, you can get 00:31:30.169 --> 00:31:30.820 there. 00:31:30.820 --> 00:31:35.570 And I kind of felt challenged by Far- by 00:31:35.570 --> 00:31:40.489 Farrah's keynote yesterday. So, I will help. If you 00:31:40.489 --> 00:31:42.330 want to attempt this, and you don't find the 00:31:42.330 --> 00:31:44.279 resources and any of those links that I gave 00:31:44.279 --> 00:31:47.089 you, Tweet at me, talk to me, send me 00:31:47.089 --> 00:31:49.669 an email. I'll respond to all of them. Maybe 00:31:49.669 --> 00:31:53.389 publicly so it helps others, too. I just think 00:31:53.389 --> 00:31:55.769 this is a great way to structure applications and 00:31:55.769 --> 00:31:58.269 to make them better, and that's why I just 00:31:58.269 --> 00:32:00.769 will help. 00:32:00.769 --> 00:32:04.330 So don't let these guys ruin your day. Make 00:32:04.330 --> 00:32:06.609 friends with the #cbra, and thanks for your attention.