WEBVTT 1 00:00:06.120 --> 00:00:10.039 Welcome to Ruby Roags today. On our panel this week 2 00:00:10.080 --> 00:00:14.599 we have Dave Kimura everyone, and we have Luke stutters 3 00:00:14.839 --> 00:00:18.559 Hi and I'm John Epperson. And for a guest this week, 4 00:00:18.879 --> 00:00:23.519 we have case Leo. Luke Yes, Hi, welcome. Would you 5 00:00:23.559 --> 00:00:26.839 tell us what you're famous for, what you do, just 6 00:00:26.839 --> 00:00:28.399 a little bit about you so we can get kind 7 00:00:28.399 --> 00:00:28.879 of going here. 8 00:00:29.079 --> 00:00:29.359 Sure. 9 00:00:29.719 --> 00:00:33.679 I'm currently working at Shopify on the Ruby and Rail's 10 00:00:33.719 --> 00:00:37.159 infrastructure team. I've been at Shopify for about a year 11 00:00:37.240 --> 00:00:40.880 and a half and since I've joined, I've been first 12 00:00:40.920 --> 00:00:45.240 on the Rails upgrade project, and then I quickly switched 13 00:00:45.280 --> 00:00:49.439 over to the Sorbey adoption team and so we spearheaded 14 00:00:49.520 --> 00:00:53.920 the adoption of Sorbey across our monolith and across our 15 00:00:53.960 --> 00:00:54.880 other code. 16 00:00:54.600 --> 00:00:58.600 Basis as well. And now I'm slowly transitioning to being 17 00:00:58.759 --> 00:01:02.600 the team lead or the Ruby part of the team. 18 00:01:02.880 --> 00:01:04.519 So the team will. 19 00:01:04.439 --> 00:01:09.959 Be responsible for contributing to MRI and contributing to Sourbet, 20 00:01:10.319 --> 00:01:14.920 basically solving and maintaining and building on the. 21 00:01:14.799 --> 00:01:16.519 Open source Ruby foundations. 22 00:01:16.680 --> 00:01:20.840 I've been in the software development industry for over twenty years. 23 00:01:20.879 --> 00:01:23.799 I've worked with very statically type dynamic. 24 00:01:23.400 --> 00:01:27.840 P time languages across that time. Initially I was working 25 00:01:28.120 --> 00:01:31.159 in a startup. I was one of the family employees 26 00:01:31.560 --> 00:01:35.840 where we were developing voice XML based applications, and we 27 00:01:35.959 --> 00:01:39.359 built a voice XML platform, and then we did like 28 00:01:39.480 --> 00:01:44.040 various networking things voice so variety, text to speech, speech recognition, 29 00:01:44.120 --> 00:01:47.000 et cetera, et cetera. I had a short stint in 30 00:01:47.040 --> 00:01:50.599 between for a couple of years doing startup acceleoration, and 31 00:01:50.560 --> 00:01:54.319 then went back to developing software and so apped me 32 00:01:54.439 --> 00:01:55.040 in a nutshell. 33 00:01:55.680 --> 00:01:58.680 Wow, So there were there have been a couple of 34 00:01:58.719 --> 00:02:01.319 talks that you've given it that I know about. I 35 00:02:01.359 --> 00:02:02.879 don't know if you've given more than that, but. 36 00:02:03.159 --> 00:02:06.200 Yeah, I have one talk at Ruby COMF twenty nineteen 37 00:02:06.400 --> 00:02:11.439 last year, and I also submitted a Rails comp twenty 38 00:02:11.439 --> 00:02:14.240 twenty the couch edition, the remote one. 39 00:02:14.439 --> 00:02:15.840 I also had a talk there. 40 00:02:15.960 --> 00:02:18.120 Yeah, sorry about the confusion. One was on sorbet and 41 00:02:18.159 --> 00:02:21.120 one was on the network. I know that I, particularly, 42 00:02:21.439 --> 00:02:26.039 for one, am interested in hearing about your adoption at Surbey. 43 00:02:26.199 --> 00:02:28.719 I think that's super interesting to me. Anything that you 44 00:02:28.840 --> 00:02:31.680 particularly want to note about either of those things that 45 00:02:31.759 --> 00:02:33.360 you're super interested in yourself. 46 00:02:33.560 --> 00:02:36.319 I think we can maybe talk about the network stack 47 00:02:36.439 --> 00:02:39.360 video and the talk from Rails comp near the end 48 00:02:39.400 --> 00:02:41.479 of the show if we have time, because I think 49 00:02:41.479 --> 00:02:44.759 most people would be interested in the sorbe adoption and 50 00:02:45.199 --> 00:02:47.639 how a company with a code based as large as 51 00:02:47.680 --> 00:02:52.280 Shopify has been successfully adopting it. I'm presuming that's what 52 00:02:52.520 --> 00:02:54.919 most of the listeners would be interested in, so we 53 00:02:54.960 --> 00:02:56.439 can get startled with that if you want. 54 00:02:56.719 --> 00:03:02.199 How large is the Shopify code? Because Shopify moved forty 55 00:03:02.280 --> 00:03:08.400 one billion dollars of merchandise in twenty eighteen, forty one 56 00:03:08.719 --> 00:03:12.520 billion would have been how many dollars per line of 57 00:03:12.599 --> 00:03:14.439 code does that work out to? 58 00:03:15.479 --> 00:03:17.000 I haven't calculated that. 59 00:03:17.759 --> 00:03:20.840 I don't know, But like in case some of the 60 00:03:21.080 --> 00:03:25.039 listeners aren't familiar with the company, and maybe I should 61 00:03:25.120 --> 00:03:26.120 just give a quick intro. 62 00:03:26.599 --> 00:03:28.240 So what Shopify does? So. 63 00:03:28.439 --> 00:03:33.000 Shopify is a leading global commerce company that provides tools 64 00:03:33.039 --> 00:03:37.439 to start, grow, market and manage a retail business of 65 00:03:37.520 --> 00:03:40.960 any site. So it started off in two thousand and 66 00:03:41.039 --> 00:03:46.080 six codebased that was built on Rail's pre one point zero, 67 00:03:46.560 --> 00:03:48.439 so it was the time of Rails when it was 68 00:03:48.479 --> 00:03:53.800 still being shared as zippiles and it's been growing ever since. 69 00:03:53.879 --> 00:03:56.960 It started as an e commerce platform and has grown 70 00:03:57.000 --> 00:04:00.800 into being a multi touch general commerce platform, so it 71 00:04:00.919 --> 00:04:04.719 provides solutions both for e commerce and also in store commerce, 72 00:04:05.159 --> 00:04:08.199 in person commerce, so it has many solutions. 73 00:04:08.240 --> 00:04:08.439 Now. 74 00:04:08.520 --> 00:04:13.240 It supports more than one million merchants now and throughout 75 00:04:13.240 --> 00:04:17.519 its lifetime it supported one hundred and seventy two billion 76 00:04:17.680 --> 00:04:21.800 USB in total sales for all the merchants. Of course, 77 00:04:21.839 --> 00:04:25.920 that's lopsided to the recent here, So the figure that 78 00:04:25.920 --> 00:04:30.120 that you quoted is probably correct. Look like, I don't know, 79 00:04:30.279 --> 00:04:31.319 off the top of mind. 80 00:04:31.040 --> 00:04:34.600 Calls it from Wikipedia, so it's almost certainly wrong. 81 00:04:36.800 --> 00:04:38.279 It sounds believable. 82 00:04:38.279 --> 00:04:41.439 Then, As for the code base, it's most probably the 83 00:04:41.600 --> 00:04:43.759 largest Ruby on Rails code base in. 84 00:04:43.720 --> 00:04:44.519 The world right now. 85 00:04:45.000 --> 00:04:50.160 It has about thirty thousand Ruby files in our core monolith. 86 00:04:50.480 --> 00:04:53.759 So I'll keep referring to Core. So when I say Core, 87 00:04:54.240 --> 00:04:58.160 that's our main monolith that provides almost all of the 88 00:04:58.199 --> 00:05:00.079 shop off solutions. 89 00:05:00.120 --> 00:05:02.000 Even though we now. 90 00:05:01.800 --> 00:05:06.040 Have some other services that operate outside of Core, most 91 00:05:06.040 --> 00:05:08.839 of our code base and most of our operation is 92 00:05:08.879 --> 00:05:13.600 actually still being handled by Core, which is our hour monolith. 93 00:05:13.680 --> 00:05:18.680 And that's about thirty thousand Ruby files. And on each push, 94 00:05:18.920 --> 00:05:22.079 on each deploy there are about one hundred and fifty 95 00:05:22.279 --> 00:05:27.319 thousand tests that run to ensure that everything is still same. 96 00:05:27.839 --> 00:05:30.000 So that's the size of the code base, that's the 97 00:05:30.040 --> 00:05:31.639 size of the platform. 98 00:05:31.160 --> 00:05:33.199 And that's crazy. I think, you know, a lot of 99 00:05:33.279 --> 00:05:37.439 us would dream to get to that kind of scale. Honestly, 100 00:05:37.480 --> 00:05:39.759 I think it would be a nightmare. Not only do 101 00:05:39.800 --> 00:05:42.439 you have the super huge codebase to maintain, but then 102 00:05:42.920 --> 00:05:46.759 just the infrastructure alone, and what that would look like 103 00:05:47.480 --> 00:05:50.360 would is probably be really crazy. Can you speak into 104 00:05:50.360 --> 00:05:53.560 the infrastructure, you know, are you guys using a very 105 00:05:53.600 --> 00:05:56.920 simple infrastructure or has it kind of gone from simple 106 00:05:57.000 --> 00:05:58.360 to like very elaborate. 107 00:05:58.639 --> 00:06:01.120 So I've only been at the for about a year 108 00:06:01.160 --> 00:06:05.279 and a half and most of the infrastructure has been 109 00:06:05.360 --> 00:06:09.879 in place before I joined, and I'm also still learning 110 00:06:09.879 --> 00:06:13.000 about some of the infrastructure that we use. But like 111 00:06:13.079 --> 00:06:17.000 I can tell you, it's a kubernkkis deploy so everything's 112 00:06:17.079 --> 00:06:21.680 virtualized in Docker containers and deployed to Kubernets pods, and 113 00:06:21.800 --> 00:06:24.879 there are like some load balancing solutions, and we also 114 00:06:24.920 --> 00:06:28.839 have this concept of pods. Pods are these logical units 115 00:06:28.839 --> 00:06:33.519 that host a group of certain merchants in one location 116 00:06:34.199 --> 00:06:37.800 with their own basic infrastructure. So that's like one way 117 00:06:37.839 --> 00:06:42.839 of sharding the customer database and the customer load across 118 00:06:42.920 --> 00:06:46.720 different machines. I'm pretty sure that, like others from the company, 119 00:06:46.759 --> 00:06:51.839 have presented at various conferences talking about that infrastructure part, 120 00:06:52.319 --> 00:06:56.240 but that's not necessarily my strongest point, so I don't 121 00:06:56.240 --> 00:06:59.079 want to really go much more in depth about that, 122 00:06:59.680 --> 00:07:02.839 even though the team that I'm working on, the Rails, 123 00:07:02.920 --> 00:07:05.959 the Ruby and Rail's Infrastructure team, is a part of 124 00:07:06.160 --> 00:07:09.879 the product line in the company called Kernel. Kernel is 125 00:07:09.920 --> 00:07:15.480 basically responsible for ensuring that the platform is off and running, 126 00:07:15.720 --> 00:07:19.759 so it's responsible for all the infrastructure problems, but also 127 00:07:19.839 --> 00:07:23.399 it includes Developer Acceleration, which my team is a part 128 00:07:23.439 --> 00:07:26.680 of as well, which provides solutions for the developers within 129 00:07:26.720 --> 00:07:29.399 the company so that they can do their work better, 130 00:07:29.639 --> 00:07:34.040 they can produce solutions faster, and also we provide solutions 131 00:07:34.040 --> 00:07:35.879 for the infrastructure part of the team as well. 132 00:07:36.000 --> 00:07:38.800 Yeah, I definitely remember more than one talk at Rails 133 00:07:38.800 --> 00:07:41.839 comp throughout the years on how you guys infrastructure changed. 134 00:07:41.920 --> 00:07:44.079 And I remember sitting at the table with some Shopify 135 00:07:44.160 --> 00:07:46.959 people one year who were talking me through how they 136 00:07:47.079 --> 00:07:50.560 were moving from Vagrant to Docker. So yeah, I do 137 00:07:50.600 --> 00:07:53.399 remember the story changing. I'm not expert enough to talk 138 00:07:53.399 --> 00:07:56.319 about it by any means. But that's been crazy to 139 00:07:56.360 --> 00:07:59.800 watch from the outside. Yes, so all right to get 140 00:08:00.360 --> 00:08:04.040 down into sorbet. What maybe from a high level talk 141 00:08:04.040 --> 00:08:06.920 about what you guys did to make survey happen at shopify. 142 00:08:07.120 --> 00:08:10.040 Sure again, maybe I should give a little bit more 143 00:08:10.040 --> 00:08:13.120 context as to what sorbet is, who developed it. What's 144 00:08:13.399 --> 00:08:18.279 used for sorbet is gradual type checker for Ruby that 145 00:08:18.439 --> 00:08:22.399 was developed by the fine folks at Strip. So sorbet 146 00:08:22.800 --> 00:08:27.360 provides you the tools to add type checking information to 147 00:08:27.439 --> 00:08:31.000 your Ruby code base, and it gives you both static 148 00:08:31.120 --> 00:08:34.840 typechecker and a runtime type checker to ensure that your 149 00:08:34.960 --> 00:08:38.240 type assumptions are makes sense and are valid. The static 150 00:08:38.279 --> 00:08:41.759 type checker is the most important part of sorbe. The 151 00:08:41.799 --> 00:08:45.679 static type checker is a tool. It's an executable built 152 00:08:45.919 --> 00:08:49.679 using C plus plus. It has its own Ruby parser, 153 00:08:49.960 --> 00:08:53.440 so it's able to parse and understand Ruby and in 154 00:08:53.480 --> 00:08:57.320 some ways simplify the Ruby language, so it can do 155 00:08:57.559 --> 00:09:01.519 those kinds of static analysis without necessarily running your code. 156 00:09:01.799 --> 00:09:03.080 Well I shouldn't say necessarily. 157 00:09:03.159 --> 00:09:05.960 It doesn't run your code at all, So in that way, 158 00:09:06.000 --> 00:09:07.240 it's a static type. 159 00:09:07.039 --> 00:09:12.039 Checker and it's built to be blazingly fast, so it 160 00:09:12.120 --> 00:09:17.159 can parse, understand, and type check our whole code based 161 00:09:17.200 --> 00:09:20.399 the code based core code base that I've been talking 162 00:09:20.440 --> 00:09:24.519 about of about thirty thousand files in a matter of 163 00:09:24.639 --> 00:09:30.039 like ten fifteen seconds. And it was built with intentionally 164 00:09:30.120 --> 00:09:33.759 to be fast and to be as safe as possible. 165 00:09:33.840 --> 00:09:39.120 And when you're developing, sorbet was open sourced about a 166 00:09:39.240 --> 00:09:42.159 year ago, so it was June twenty nineteen when it 167 00:09:42.200 --> 00:09:46.559 was open sourced, but it was being developed by Stripe 168 00:09:46.600 --> 00:09:49.799 for about I think two years before that, And by 169 00:09:49.840 --> 00:09:54.360 the time I joined Shopify, we'd already gotten on the 170 00:09:54.919 --> 00:09:59.519 early release beta program where they were doing like code 171 00:09:59.519 --> 00:10:03.279 sharing with Shopify, so we were able to start our 172 00:10:03.360 --> 00:10:08.240 adoption earlier than when it was initially open source. Then 173 00:10:08.480 --> 00:10:11.279 afterwards Stripe also got like a few other companies that 174 00:10:11.320 --> 00:10:14.240 were interested into the public data program as well. But 175 00:10:14.600 --> 00:10:17.519 so that's why our story is a little bit different, 176 00:10:17.679 --> 00:10:21.320 because we ended up solving some of the problems that 177 00:10:21.519 --> 00:10:24.600 people who might want to adopt sorbe don't have to 178 00:10:24.639 --> 00:10:28.639 solve right now because it's a much more mature product. 179 00:10:29.000 --> 00:10:31.440 But back when we were trying to adopt it on 180 00:10:31.440 --> 00:10:35.399 our code base, it was mostly a tool that was 181 00:10:35.879 --> 00:10:39.399 built with the Stripe code based in mind. And I 182 00:10:39.440 --> 00:10:43.320 can't talk too much about what Stripe codebase is like 183 00:10:43.399 --> 00:10:46.240 because I don't know, but from our understanding is it 184 00:10:46.799 --> 00:10:50.879 doesn't use RAILS. It tries to use as little meta 185 00:10:50.879 --> 00:10:55.000 programming as possible. So they're like really big on intention 186 00:10:55.240 --> 00:10:59.759 revealing code and not so much meta programming. So Sorbet 187 00:10:59.919 --> 00:11:02.919 was the right tool for them, and they were developing 188 00:11:02.960 --> 00:11:06.279 to solve their own solutions obviously initially, but because ar 189 00:11:06.360 --> 00:11:10.200 codebas is RAILS, which already has a lot of meta programming. 190 00:11:10.960 --> 00:11:15.080 So meta programming brings in a lot of dynamic methods 191 00:11:15.080 --> 00:11:19.120 that can only be seen when you're running the code right, 192 00:11:19.159 --> 00:11:23.279 So there are lots of methods that you don't see. 193 00:11:23.399 --> 00:11:27.000 For example, on active record models, you don't see all 194 00:11:27.039 --> 00:11:30.039 the attributes right because the attributes are created at runtime. 195 00:11:30.360 --> 00:11:33.080 All the methods that relate that are related to attributes 196 00:11:33.080 --> 00:11:36.519 are created that runtime, after RAILS has had a chance 197 00:11:36.639 --> 00:11:40.679 to introspect your database levels. Obviously, that's a big problem 198 00:11:40.759 --> 00:11:43.759 for Surbey because it looks like the code tries to 199 00:11:43.840 --> 00:11:46.960 understand and sthatically and it says, oh, this. 200 00:11:46.720 --> 00:11:51.039 Model has no methods. So in another part of the codebase. 201 00:11:51.200 --> 00:11:55.559 When you're trying to do shop dot something Serb says, oh, 202 00:11:55.759 --> 00:11:58.919 like shop doesn't have this method, so that ends up 203 00:11:58.919 --> 00:11:59.720 being a problem. 204 00:12:00.200 --> 00:12:04.159 So one of the first things we contributed. 205 00:12:03.720 --> 00:12:07.879 To the Sorbeko disk was a way to have the 206 00:12:08.240 --> 00:12:12.399 static type checker understand some of the NATA programming concepts. 207 00:12:12.600 --> 00:12:16.399 So our initial idea was that we could write scripts 208 00:12:16.440 --> 00:12:21.679 in Ruby and so they could basically execute them so 209 00:12:21.720 --> 00:12:26.200 that the scripts could generate what methods would exist if 210 00:12:26.240 --> 00:12:28.200 the code had ran, but it would still be a 211 00:12:28.200 --> 00:12:31.519 static type checker. It kind of tided us over that 212 00:12:31.600 --> 00:12:35.279 solution for a while, but it ended up slowing down 213 00:12:35.320 --> 00:12:37.879 the type checking process a lot, but at least it 214 00:12:37.960 --> 00:12:42.240 allowed us to do our own initial adoption at the time. 215 00:12:42.639 --> 00:12:46.159 Another problem as we were adopting was that all the 216 00:12:46.200 --> 00:12:50.480 types that are coming from our GEM dependencies, So our 217 00:12:50.559 --> 00:12:55.919 core monolith has about four hundred GEM dependencies, which is 218 00:12:56.080 --> 00:12:59.960 already like a huge maintenance problem, right, like we need 219 00:13:00.080 --> 00:13:03.399 to maintain them to be on the latest versions and everything. 220 00:13:03.960 --> 00:13:05.480 But it also means there are. 221 00:13:05.320 --> 00:13:10.519 Lots of classes, modules, constant definitions coming from those gems. 222 00:13:11.200 --> 00:13:16.039 But Survey doesn't go and look for class definitions inside 223 00:13:16.080 --> 00:13:19.120 of gem source of it just looks at your code base, 224 00:13:19.600 --> 00:13:23.279 so it says, oh, you're using this foo class here, 225 00:13:23.480 --> 00:13:26.000 or like this food constant here, but I have no 226 00:13:26.080 --> 00:13:29.559 idea what foods. So it needs to be told what 227 00:13:29.759 --> 00:13:32.639 foo is, what kind of methods it has, what kind 228 00:13:32.639 --> 00:13:36.480 of subconstances it has, what type of a constant it is? 229 00:13:36.480 --> 00:13:39.960 Is it a class, is it a module, what's superclass? 230 00:13:40.000 --> 00:13:42.840 What are the mixings, et cetera, et cetera. So we 231 00:13:42.919 --> 00:13:45.279 needed a tool that would just take. 232 00:13:45.159 --> 00:13:51.039 A GEM somehow, introspect it, and then generate an RBI file. 233 00:13:51.519 --> 00:13:54.720 So it's called an RBI file that's a Ruby interface file. 234 00:13:54.840 --> 00:13:58.000 It's almost the same thing as a c header file. 235 00:13:58.279 --> 00:14:00.840 So it's just the definitions of these things that I 236 00:14:00.960 --> 00:14:03.240 just said, is it a class, is it a module? 237 00:14:03.519 --> 00:14:07.440 What's the superclass? Mixing the methods and its arguments. So 238 00:14:07.480 --> 00:14:10.440 it just generates those without any of the implementation. So 239 00:14:10.919 --> 00:14:13.799 we had to build a tool and we open sourced 240 00:14:13.799 --> 00:14:15.559 it afterwards as tapioca. 241 00:14:16.039 --> 00:14:20.200 That does that. It takes your GEM file, it discovers 242 00:14:20.240 --> 00:14:22.399 all the gems, it loads them into memory. 243 00:14:22.879 --> 00:14:26.519 Then it does runtime reflection on all the types that 244 00:14:26.639 --> 00:14:30.600 can find from all those gems, and then it tries 245 00:14:30.639 --> 00:14:33.720 to understand what the shape of all those types are 246 00:14:33.879 --> 00:14:38.519 and it generates that into a set of rbiphads, which 247 00:14:38.679 --> 00:14:42.080 then so they can read, and then it then it 248 00:14:42.159 --> 00:14:45.279 knows about food coming from the gem flo or something. 249 00:14:45.480 --> 00:14:48.159 So just a quick follow up there, So sure you 250 00:14:48.200 --> 00:14:50.759 guys have that or you have this problem in shopify 251 00:14:50.799 --> 00:14:53.039 because you have a bunch of gems. Did the people 252 00:14:53.080 --> 00:14:54.320 they created this gems right? 253 00:14:54.480 --> 00:14:54.679 Yeah? 254 00:14:54.759 --> 00:14:56.519 Stright? Yes, I don't know why I couldn't think of 255 00:14:56.519 --> 00:15:00.519 it for a second. Did stric not have any gems? Depends? Then? 256 00:15:00.720 --> 00:15:05.000 No, they did. So basically they had a script that would. 257 00:15:04.799 --> 00:15:07.559 Kind of do the same thing that they were using internally, 258 00:15:07.600 --> 00:15:09.480 but it wasn't part of the Sorbet. 259 00:15:09.200 --> 00:15:10.080 Tooling at the time. 260 00:15:10.639 --> 00:15:14.159 Okay, So they shared the initial skeleton of that script 261 00:15:14.559 --> 00:15:17.840 with us, and then we ended up turning that into 262 00:15:18.240 --> 00:15:22.519 the tool that's now Tabioka, and then the Storbe team 263 00:15:22.559 --> 00:15:26.000 at Stripe they actually also took that script and then 264 00:15:26.279 --> 00:15:30.559 built it into the sorbet in It script, which does 265 00:15:30.639 --> 00:15:34.159 something very similar. It also can look into gems and 266 00:15:34.279 --> 00:15:38.559 load types and generate ruby interfestiles for you. So that 267 00:15:38.759 --> 00:15:41.480 ended up being a part of the tool, the Sorbet tool, 268 00:15:41.879 --> 00:15:46.840 but we took a slightly different route than that tool, 269 00:15:46.919 --> 00:15:50.759 and so that's why we're actually using Tapyoka internally rather 270 00:15:50.840 --> 00:15:53.159 than the Sorbet in it tooling. 271 00:15:53.919 --> 00:15:55.440 Okay, what else did you encounter? 272 00:15:55.840 --> 00:15:57.159 Yeah, so the other thing. 273 00:15:57.519 --> 00:16:01.080 So going back to the DSL problem, it turned out that, 274 00:16:01.879 --> 00:16:06.279 you know, making Sorbet run Ruby scripts as it's trying 275 00:16:06.320 --> 00:16:08.480 to make sense of your code. 276 00:16:08.279 --> 00:16:11.279 Based statically was a huge slowdown. 277 00:16:12.360 --> 00:16:16.519 So we basically stopped doing it, and then also realized 278 00:16:16.559 --> 00:16:20.679 that the same approach, even though it has some disadvantages, 279 00:16:20.679 --> 00:16:24.759 but the same approach of generating Ruby interface files for 280 00:16:24.919 --> 00:16:28.919 all the meta programming, would be a much better fit 281 00:16:29.200 --> 00:16:33.200 for our problem. So recently we've been working on that problem. 282 00:16:33.320 --> 00:16:36.440 There are other solutions in the same area as well. 283 00:16:36.919 --> 00:16:40.159 One of them is, for example, the gem called sorbet 284 00:16:40.279 --> 00:16:44.360 Rails that's built by people at the Chans Zuckerberg Initiative. 285 00:16:44.559 --> 00:16:48.279 So they had the same problems of Sorbey not understanding 286 00:16:48.320 --> 00:16:51.679 some of the meta programming that's coming from rails again, 287 00:16:51.759 --> 00:16:56.120 like all the column related methods on models, all the 288 00:16:56.200 --> 00:17:03.159 association related methods on models, all the the class methods, sorry, 289 00:17:03.200 --> 00:17:06.680 all the instance methods in mailers that are turned into 290 00:17:06.759 --> 00:17:11.359 class methods, all the helpers on your controllers, they're all 291 00:17:11.400 --> 00:17:14.960 happening at run time in rails. So Sarbe rails was 292 00:17:15.000 --> 00:17:18.519 the first attempt to actually build a gem that could 293 00:17:18.640 --> 00:17:22.519 generate Ruby interface files for all those things, so that 294 00:17:22.640 --> 00:17:25.839 Sarbe can look at the Ruby interface file. So you 295 00:17:25.880 --> 00:17:29.000 have your shop model or like shop dot irb file 296 00:17:29.319 --> 00:17:32.720 which hosts your shop model, but you also have this 297 00:17:32.880 --> 00:17:36.759 shop dot rbi file that's generated for you, which contains 298 00:17:37.200 --> 00:17:39.839 all the method definitions that would be on the shop 299 00:17:39.880 --> 00:17:44.880 model dynamically. So having that, Sarbe can say, oh, yeah, okay, 300 00:17:44.920 --> 00:17:48.880 I know a shop as this name method, So if 301 00:17:48.920 --> 00:17:51.920 you call shop dot name, then yes, I know what 302 00:17:51.960 --> 00:17:55.039 that is. And even better if you can also create 303 00:17:55.079 --> 00:17:57.519 signatures for it, so if you can tell it what 304 00:17:57.799 --> 00:18:01.079 parameters it takes and what the return type is, then 305 00:18:01.119 --> 00:18:04.079 you can also keep typing those things as well, so 306 00:18:04.119 --> 00:18:05.200 you can build on. 307 00:18:05.200 --> 00:18:06.160 Those types as well. 308 00:18:06.440 --> 00:18:09.720 So survey rails was the initial solution to this, but 309 00:18:09.759 --> 00:18:13.519 we also realized that we had other meta programming DSL 310 00:18:13.720 --> 00:18:17.640 concerns within our code base that obviously wasn't addressed by 311 00:18:17.680 --> 00:18:21.640 Sarbe rails so we wanted a broader framework, so we 312 00:18:21.799 --> 00:18:24.599 built one in house, and we actually are in the 313 00:18:24.640 --> 00:18:28.720 process of folding that also into Tapioca, so that Tapioca 314 00:18:28.799 --> 00:18:32.920 becomes this once with army tool of generating RBIs either 315 00:18:33.000 --> 00:18:37.440 from gems or from all the DSL meta programming that's 316 00:18:37.480 --> 00:18:40.920 going on across your code based and initially we've again 317 00:18:40.960 --> 00:18:47.000 targeted the same RAILS meta programming concepts, so we borrowed 318 00:18:47.039 --> 00:18:51.000 and built on some of the solutions from Sarbe Rails, 319 00:18:51.160 --> 00:18:56.079 but we've also built DSL generators for other common gems 320 00:18:56.119 --> 00:18:59.400 across our code base, and we intend to grow that 321 00:18:59.519 --> 00:19:02.920 set based on contributions from the community. So we have 322 00:19:03.359 --> 00:19:07.079 a generator for an active record type store frozen record 323 00:19:07.519 --> 00:19:11.680 identity cash that's also a Shopify gem, So like Rails 324 00:19:11.799 --> 00:19:16.039 plus a few gems will already be addressed with Tapioca, 325 00:19:16.079 --> 00:19:19.000 and that was the biggest pain point stopping us from 326 00:19:19.440 --> 00:19:22.640 increasing our typing even further across our code based. 327 00:19:22.839 --> 00:19:25.880 Okay, so you guys went through all of this working 328 00:19:25.960 --> 00:19:30.119 effort to get survey working at Shopify. So what did 329 00:19:30.160 --> 00:19:33.160 you get from that? Like, what was your value? What 330 00:19:33.319 --> 00:19:35.799 was you guys's value proposition? As best you understand it. 331 00:19:35.920 --> 00:19:36.759 Yes, great question. 332 00:19:37.559 --> 00:19:42.839 So the obvious headline thing for SORBET is to obviously 333 00:19:42.920 --> 00:19:46.599 to ensure that your code is type safe, right, so 334 00:19:46.680 --> 00:19:50.759 that you're not making silly mistakes, that you don't have 335 00:19:51.359 --> 00:19:55.119 a reference to references to classes or modules across your 336 00:19:55.160 --> 00:19:58.400 code based that are no longer there. We've found many 337 00:19:58.440 --> 00:20:01.240 instances of that across our co based through the use 338 00:20:01.240 --> 00:20:05.200 of survey for example, or that you're not calling methods 339 00:20:05.279 --> 00:20:09.920 on constants that don't actually have those methods, or that 340 00:20:10.000 --> 00:20:13.640 you're not providing arguments to those methods that they don't 341 00:20:13.640 --> 00:20:14.440 actually accept. 342 00:20:14.920 --> 00:20:16.480 So all of those things. 343 00:20:16.839 --> 00:20:19.559 If you're working on a normal RUT code based all 344 00:20:19.599 --> 00:20:22.200 of those concerns, you can only discover them at. 345 00:20:22.119 --> 00:20:24.839 One time, so you either need to. 346 00:20:24.799 --> 00:20:28.319 Have extensive testing to ensure that all those edge cases 347 00:20:28.839 --> 00:20:33.720 are executed on your CI or you discover them in production. 348 00:20:34.160 --> 00:20:38.519 So the initial goal is obviously was to reduce those 349 00:20:38.559 --> 00:20:42.680 types of trivial errors as much as possible. Unfortunately, in 350 00:20:42.720 --> 00:20:48.960 our initial adoption phase we couldn't validate or invalidate that hypothesis, 351 00:20:49.240 --> 00:20:51.160 but we did other things to. 352 00:20:51.200 --> 00:20:52.079 Compensate for that. 353 00:20:52.400 --> 00:20:56.720 So there's a very understandable reason for why we couldn't 354 00:20:56.759 --> 00:21:00.640 conclude on that hypothesis if we were able to reduce 355 00:21:00.720 --> 00:21:05.720 trivial errors. Is because our core monolith does more dynamic 356 00:21:05.799 --> 00:21:08.960 things then the stuff that we have in our code base. 357 00:21:09.279 --> 00:21:12.279 So it kind of like serializes objects to the database 358 00:21:12.319 --> 00:21:15.240 and then read serialized objects from the database, et cetera, 359 00:21:15.240 --> 00:21:18.039 et cetera, And there's no way aesthetic type checker can 360 00:21:18.200 --> 00:21:22.759 like prevent you from, you know, de serializing an object 361 00:21:22.880 --> 00:21:27.039 that definition for which has mistakenly even remote from the 362 00:21:27.079 --> 00:21:30.759 codebas Right, So suppose you had like a user class 363 00:21:30.920 --> 00:21:34.160 and there was a user object serialized somewhere, and then 364 00:21:34.200 --> 00:21:37.000 someone removes the user class, and now someone tries to 365 00:21:37.079 --> 00:21:41.079 de serialize the user object, and then boom, your application fails, 366 00:21:41.160 --> 00:21:44.240 right because the user class doesn't exist anymore, so you 367 00:21:44.319 --> 00:21:48.279 can't deserialize it. So we obviously can't prevent those kinds 368 00:21:48.279 --> 00:21:51.039 of errors. So there are like other dynamic things going on, 369 00:21:51.279 --> 00:21:56.200 And like I said, Core is such a large code base, 370 00:21:56.960 --> 00:22:01.119 and there's like so much variance across like its failure 371 00:22:01.160 --> 00:22:05.079 modes that it's hard to get the signal that we 372 00:22:05.119 --> 00:22:08.960 were looking for among all that background. So then we 373 00:22:09.039 --> 00:22:12.640 said we actually need a smaller code base to test 374 00:22:12.640 --> 00:22:16.359 our hypothesison to see if we're able to move the 375 00:22:16.440 --> 00:22:21.200 needle in that type safety in any direction. So after 376 00:22:21.240 --> 00:22:25.279 we did the initial adoption on Core, we turned our 377 00:22:25.319 --> 00:22:29.279 attention to a much smaller and more opinionated code. 378 00:22:29.039 --> 00:22:32.079 Base within the company, and that's a tool that we 379 00:22:32.119 --> 00:22:32.720 call DEV. 380 00:22:33.319 --> 00:22:36.880 So DEV is a tool that every developer at Shopify 381 00:22:37.079 --> 00:22:40.839 has on their computer and it's the tool that every 382 00:22:40.880 --> 00:22:46.119 developer uses during their daily work workflows. So DEV is 383 00:22:46.119 --> 00:22:51.119 a command line tool. You use it to clone Shopify 384 00:22:51.119 --> 00:22:56.680 imposteres then to you only invoke dev up and it 385 00:22:56.880 --> 00:23:00.559 knows based on a configuration file with an repo. It 386 00:23:00.599 --> 00:23:05.039 knows which dependencies to install, which commands to execute to 387 00:23:05.079 --> 00:23:07.359 bring the application up. 388 00:23:07.960 --> 00:23:10.119 And it also gives you different. 389 00:23:09.799 --> 00:23:13.559 Shortcuts like DEV tests or DEV type check, which was 390 00:23:13.559 --> 00:23:17.440 something we added to run like various various things. So 391 00:23:17.559 --> 00:23:21.039 DEV is a very opinionated code base because it's a 392 00:23:21.079 --> 00:23:24.079 developer tool. It's a command line tool. Everyone uses it 393 00:23:24.359 --> 00:23:27.079 throughout the day, so it needs to be fast. It 394 00:23:27.119 --> 00:23:31.799 has for that reason. It has no external dependencies, so 395 00:23:31.839 --> 00:23:35.000 it doesn't use any any gems or anything. If it 396 00:23:35.160 --> 00:23:38.160 needs some other code, it vendors them in. So it 397 00:23:38.279 --> 00:23:41.599 was like the ideal code base, and the team that's 398 00:23:41.640 --> 00:23:44.519 working on that codebase is a small team that's been 399 00:23:44.519 --> 00:23:46.680 working on the same codebase for a long time. So 400 00:23:46.720 --> 00:23:50.400 we talked to that team and we told them that 401 00:23:50.440 --> 00:23:54.799