WEBVTT

1
00:00:05.240 --> 00:00:08.240
<v Speaker 1>Hi, everyone, Welcome to another episode of Ruby Rogues. I'm

2
00:00:08.320 --> 00:00:11.439
<v Speaker 1>David Kimura, and today on our panel we have Matt Smith,

3
00:00:12.839 --> 00:00:16.920
<v Speaker 1>Luke Sutters II, and we have a special guest, Kyle

4
00:00:17.239 --> 00:00:18.960
<v Speaker 1>da OLIVERA. Do I say that right?

5
00:00:19.280 --> 00:00:22.399
<v Speaker 2>That's Delivera Doliver. Yeah.

6
00:00:22.559 --> 00:00:24.960
<v Speaker 1>So, Kyle, would you mind telling us a bit about

7
00:00:24.960 --> 00:00:26.719
<v Speaker 1>who you are, who you work for, and some of

8
00:00:26.760 --> 00:00:27.719
<v Speaker 1>the things that you're doing.

9
00:00:28.079 --> 00:00:30.679
<v Speaker 2>Sure. My name is Kyle. I've been working for a

10
00:00:30.719 --> 00:00:36.039
<v Speaker 2>company named CLEO. Let's say Legal Practice Management SaaS software.

11
00:00:36.320 --> 00:00:40.280
<v Speaker 2>It's based out of Vancouver, Canada. It makes practice management

12
00:00:40.280 --> 00:00:43.880
<v Speaker 2>software aimed at lawyers. We're looking at transforming the legal space.

13
00:00:44.359 --> 00:00:47.719
<v Speaker 2>Our mission is to transform the practice of law for good.

14
00:00:47.840 --> 00:00:51.240
<v Speaker 2>There's a nice little double upon for there. And it's

15
00:00:51.240 --> 00:00:54.799
<v Speaker 2>been really interesting seeing some of the changes in legal

16
00:00:55.159 --> 00:00:57.359
<v Speaker 2>that we've kind of made an impact with over the

17
00:00:57.439 --> 00:01:01.200
<v Speaker 2>last few years. I've been working on Rubyan rails for

18
00:01:01.759 --> 00:01:03.719
<v Speaker 2>the better part of the last decade. But when I

19
00:01:03.759 --> 00:01:08.439
<v Speaker 2>started working on rails it was rails versions zero and

20
00:01:08.519 --> 00:01:12.439
<v Speaker 2>I've been upgrading rails ever since and so now finally

21
00:01:12.519 --> 00:01:17.159
<v Speaker 2>up to rail six and so touching all of the

22
00:01:17.200 --> 00:01:20.319
<v Speaker 2>major versions. My major focus at CLEO, which I've been

23
00:01:20.319 --> 00:01:24.359
<v Speaker 2>at now for eight years has been on the back

24
00:01:24.439 --> 00:01:27.840
<v Speaker 2>end infrastructure side of things. So the main focus is

25
00:01:28.079 --> 00:01:31.560
<v Speaker 2>scalability for the codebase, but also in the terms of

26
00:01:31.560 --> 00:01:35.519
<v Speaker 2>the organization, like what happens when we have two hundred

27
00:01:35.560 --> 00:01:40.319
<v Speaker 2>developers working, what happens when the dataset sizes are to

28
00:01:40.319 --> 00:01:42.680
<v Speaker 2>the size where we can exhaust regular integers and we

29
00:01:42.719 --> 00:01:46.319
<v Speaker 2>need to actually go into like vacants. We look at approachability.

30
00:01:46.480 --> 00:01:49.359
<v Speaker 2>How easy can we just take a new developer and

31
00:01:49.439 --> 00:01:51.560
<v Speaker 2>dump them into the codebase and have them up and running.

32
00:01:51.920 --> 00:01:55.439
<v Speaker 2>Because as things go to scale, there's obviously new patterns

33
00:01:55.480 --> 00:01:58.200
<v Speaker 2>that need to be adhere to that you know, we

34
00:01:58.239 --> 00:02:00.480
<v Speaker 2>don't necessarily need to focus on with small project, but

35
00:02:00.560 --> 00:02:03.200
<v Speaker 2>we do need to focus on for large projects, and

36
00:02:03.359 --> 00:02:05.040
<v Speaker 2>my team has focused a lot of that to making

37
00:02:05.120 --> 00:02:09.439
<v Speaker 2>the effort and experience for all of the developers easy

38
00:02:09.520 --> 00:02:10.080
<v Speaker 2>and fast.

39
00:02:10.520 --> 00:02:13.199
<v Speaker 1>Yeah. Absolutely. One thing that kind of rings true is

40
00:02:13.240 --> 00:02:16.639
<v Speaker 1>you always have to think about scalability when you're developing,

41
00:02:17.240 --> 00:02:20.639
<v Speaker 1>but don't actually write for scalability when you're developing. So

42
00:02:21.159 --> 00:02:23.560
<v Speaker 1>keep it in the back of your head saying is

43
00:02:23.560 --> 00:02:26.479
<v Speaker 1>this going to come back and bite me later or

44
00:02:26.639 --> 00:02:30.879
<v Speaker 1>is it you know, a really non issue. I remember

45
00:02:31.199 --> 00:02:34.680
<v Speaker 1>one time I had a situation where I was soaring

46
00:02:34.800 --> 00:02:39.919
<v Speaker 1>just three kilobytes of data in a database, and I thought, Okay,

47
00:02:40.000 --> 00:02:41.840
<v Speaker 1>this is going to get used a little bit. They

48
00:02:41.840 --> 00:02:44.680
<v Speaker 1>were images, so you can kind of see where this

49
00:02:44.840 --> 00:02:47.639
<v Speaker 1>is going. I'm like, you know, that's not a big deal.

50
00:02:47.680 --> 00:02:53.639
<v Speaker 1>It's only three kilobytes. But unexpectedly the consumers loved the

51
00:02:53.680 --> 00:02:57.240
<v Speaker 1>feature that it was supporting. And now that single table

52
00:02:57.439 --> 00:03:01.360
<v Speaker 1>is over thirty gigabytes and it had as millions upon

53
00:03:01.479 --> 00:03:05.960
<v Speaker 1>millions of records. I'm like, oh, that was an unexpected

54
00:03:06.039 --> 00:03:08.400
<v Speaker 1>But I guess that's kind of where I did not

55
00:03:08.560 --> 00:03:12.000
<v Speaker 1>think of scale at the time or proper way. So

56
00:03:12.240 --> 00:03:15.759
<v Speaker 1>introducing that kind of technical debt kind of painted us

57
00:03:15.800 --> 00:03:18.800
<v Speaker 1>in a corner because now transitioning away from that model

58
00:03:19.560 --> 00:03:21.199
<v Speaker 1>is going to be a pain when you're dealing with

59
00:03:21.360 --> 00:03:22.319
<v Speaker 1>that much data.

60
00:03:22.879 --> 00:03:24.840
<v Speaker 2>Yeah. Absolutely, it's hard to know what you don't know.

61
00:03:25.439 --> 00:03:27.159
<v Speaker 2>So if you don't think about the scale at that

62
00:03:27.199 --> 00:03:30.280
<v Speaker 2>point in time, it's hard to know what problems you're

63
00:03:30.319 --> 00:03:31.280
<v Speaker 2>even going to run into.

64
00:03:31.719 --> 00:03:35.800
<v Speaker 1>So you gave a talk last year about death by

65
00:03:36.000 --> 00:03:39.240
<v Speaker 1>one thousand commits. Could you give us a high level

66
00:03:39.280 --> 00:03:42.159
<v Speaker 1>overview of that talk and kind of some of the

67
00:03:42.240 --> 00:03:43.319
<v Speaker 1>things that entails.

68
00:03:44.240 --> 00:03:48.639
<v Speaker 2>Yeah, So working at CLEO, the code base is quite large.

69
00:03:48.680 --> 00:03:52.680
<v Speaker 2>We have tens of thousands of commits that we go through,

70
00:03:53.360 --> 00:03:58.919
<v Speaker 2>and it's really easy to see patterns of developers working

71
00:03:58.919 --> 00:04:03.439
<v Speaker 2>on features. The features go live, and at some point

72
00:04:03.439 --> 00:04:06.680
<v Speaker 2>in the next six months a year, those features come

73
00:04:06.719 --> 00:04:09.159
<v Speaker 2>back to bite us. So as like the first commit

74
00:04:09.240 --> 00:04:11.960
<v Speaker 2>is great, the tenth commit is you're starting to notice

75
00:04:12.000 --> 00:04:14.479
<v Speaker 2>some things. By the hundred, there's maybe some problems. And

76
00:04:14.520 --> 00:04:17.680
<v Speaker 2>by the thousands, lat thousands commit on it. Right, you've

77
00:04:17.720 --> 00:04:21.920
<v Speaker 2>stopped because now you have to completely refactor and rebuild

78
00:04:22.040 --> 00:04:24.720
<v Speaker 2>a lot of this technical debt that you introduced. So

79
00:04:24.800 --> 00:04:27.759
<v Speaker 2>my talk was talking about some of the lessons that

80
00:04:28.439 --> 00:04:32.279
<v Speaker 2>we've learned. And although these the lessons are very specific

81
00:04:32.360 --> 00:04:35.800
<v Speaker 2>to specific problems, there's kind of a generalized idea of

82
00:04:35.879 --> 00:04:38.240
<v Speaker 2>what some approaches that you can take to dealing with

83
00:04:38.279 --> 00:04:41.560
<v Speaker 2>technical debt in your own projects. If you are able to,

84
00:04:41.720 --> 00:04:45.120
<v Speaker 2>for instance, keep if you're able to automate technical debt

85
00:04:45.160 --> 00:04:48.319
<v Speaker 2>away entirely, well, now there's a whole classification of problems

86
00:04:48.360 --> 00:04:50.240
<v Speaker 2>you no longer need to think about, and you can

87
00:04:50.240 --> 00:04:53.480
<v Speaker 2>feel confident that those are just automatically protected and if

88
00:04:53.519 --> 00:04:55.879
<v Speaker 2>you are cleaning up after yourself as you go and

89
00:04:55.920 --> 00:04:59.000
<v Speaker 2>making it easier when there are curve balls being thrown

90
00:04:59.040 --> 00:05:02.240
<v Speaker 2>at you, Fixing technical debt and dealing with it when

91
00:05:02.279 --> 00:05:04.279
<v Speaker 2>you hit scale doesn't have to stop you entirely. It

92
00:05:04.319 --> 00:05:07.839
<v Speaker 2>just becomes a constant, small tax that you pay. But

93
00:05:08.079 --> 00:05:10.759
<v Speaker 2>if you invest in the tools, you can actually start

94
00:05:10.800 --> 00:05:12.639
<v Speaker 2>moving faster even as you.

95
00:05:12.639 --> 00:05:16.600
<v Speaker 1>Scale right, and so would you mine also explaining what

96
00:05:16.759 --> 00:05:20.040
<v Speaker 1>technical debt is, what would you consider technical debt and

97
00:05:20.079 --> 00:05:22.920
<v Speaker 1>what are some things that you would maybe not consider

98
00:05:23.000 --> 00:05:27.519
<v Speaker 1>technical debt? Kind of like some debusting myths about technical debt,

99
00:05:28.079 --> 00:05:28.560
<v Speaker 1>I would.

100
00:05:28.399 --> 00:05:33.319
<v Speaker 2>Say technical debt is like accumulation of decisions that are

101
00:05:33.399 --> 00:05:38.120
<v Speaker 2>made while coding that you eventually need to correct in

102
00:05:38.160 --> 00:05:42.000
<v Speaker 2>the future. And as developers, I think we're always making

103
00:05:42.000 --> 00:05:44.800
<v Speaker 2>these decisions. Can we cut a corner here to deliver

104
00:05:44.839 --> 00:05:47.560
<v Speaker 2>a feature out a little bit early? And I think

105
00:05:47.560 --> 00:05:50.759
<v Speaker 2>those are like technical debt isn't bad. I think when

106
00:05:50.800 --> 00:05:53.879
<v Speaker 2>you are willing to get something in front of the

107
00:05:53.959 --> 00:05:56.680
<v Speaker 2>users and deliver value earlier by incurring a little bit

108
00:05:56.680 --> 00:05:58.759
<v Speaker 2>of this technical debt that you then have to clean up,

109
00:05:59.120 --> 00:06:02.240
<v Speaker 2>I think that's totally okay. But I think technical debt

110
00:06:02.680 --> 00:06:06.519
<v Speaker 2>often comes in the situation of developers making a decision

111
00:06:06.759 --> 00:06:11.279
<v Speaker 2>that a framework needs to be super generic and it's

112
00:06:11.279 --> 00:06:14.879
<v Speaker 2>got a little bit speculative, and then they come to

113
00:06:14.959 --> 00:06:17.120
<v Speaker 2>implement something in the future and it's just really difficult

114
00:06:17.160 --> 00:06:20.199
<v Speaker 2>to deal with because it's so generic and hard to

115
00:06:20.319 --> 00:06:22.959
<v Speaker 2>understand that new developers have to then unpack that and

116
00:06:23.639 --> 00:06:26.480
<v Speaker 2>wind it back just to implement something new in it.

117
00:06:27.000 --> 00:06:29.600
<v Speaker 2>Some things that I think are not necessarily technical debt

118
00:06:29.759 --> 00:06:33.720
<v Speaker 2>can kind of come from maybe decisions that actually made

119
00:06:33.759 --> 00:06:38.759
<v Speaker 2>sense at the time and aren't necessarily any cutting a corner.

120
00:06:39.160 --> 00:06:43.120
<v Speaker 2>So I mean, it may make sense to build a

121
00:06:43.120 --> 00:06:46.639
<v Speaker 2>system that is very generic, and maybe that is the

122
00:06:46.639 --> 00:06:49.720
<v Speaker 2>correct choice, and you build through and then things change,

123
00:06:50.199 --> 00:06:52.639
<v Speaker 2>and when things change, that's when you might have to

124
00:06:52.720 --> 00:06:55.639
<v Speaker 2>have like the technical debt comes back. But until the

125
00:06:55.639 --> 00:06:57.959
<v Speaker 2>things change, it actually might not be I think that's

126
00:06:57.959 --> 00:07:00.600
<v Speaker 2>a bit of like a generic answer. But it's hard

127
00:07:00.639 --> 00:07:03.360
<v Speaker 2>to pin down a concept like technical debt because almost

128
00:07:03.439 --> 00:07:08.120
<v Speaker 2>everything we write is debt of some form.

129
00:07:08.240 --> 00:07:11.079
<v Speaker 1>Yeah, I definitely have to agree with that. So where

130
00:07:11.079 --> 00:07:14.399
<v Speaker 1>are some of the real world examples that you guys

131
00:07:14.399 --> 00:07:18.079
<v Speaker 1>have experienced over your years, where at the time you

132
00:07:18.160 --> 00:07:22.680
<v Speaker 1>made a decision and you or the team thought like

133
00:07:22.839 --> 00:07:25.399
<v Speaker 1>this was a great choice, this is the right way

134
00:07:25.439 --> 00:07:28.480
<v Speaker 1>to do it, but then later you found that it

135
00:07:28.560 --> 00:07:31.519
<v Speaker 1>became more troublesome or more of a headache than it

136
00:07:31.560 --> 00:07:32.040
<v Speaker 1>was worth.

137
00:07:32.639 --> 00:07:34.720
<v Speaker 2>One of the things that popped up is actually something

138
00:07:34.759 --> 00:07:37.600
<v Speaker 2>that you know, we decided on because the rails community

139
00:07:37.839 --> 00:07:39.680
<v Speaker 2>pushes for and this is what comes out of the box.

140
00:07:40.079 --> 00:07:43.120
<v Speaker 2>So if you think about RAILS migrations, if you think

141
00:07:43.160 --> 00:07:45.399
<v Speaker 2>about how they're often applied, if you think about some

142
00:07:45.439 --> 00:07:48.720
<v Speaker 2>examples that you've worked on, there are often times where

143
00:07:48.800 --> 00:07:51.920
<v Speaker 2>you use something like a tool like Capistrano, which deploys

144
00:07:51.920 --> 00:07:54.480
<v Speaker 2>some code and as part of the code database, migration

145
00:07:54.560 --> 00:07:58.160
<v Speaker 2>gets run. And for projects that's fine, that's like a

146
00:07:58.879 --> 00:08:02.240
<v Speaker 2>for most small things like that, migration that runs is

147
00:08:02.639 --> 00:08:05.879
<v Speaker 2>fast and it's not a problem. But so this is

148
00:08:05.920 --> 00:08:08.199
<v Speaker 2>an example of a decision that we kind of were like,

149
00:08:08.279 --> 00:08:11.360
<v Speaker 2>let's just inherit what the community uses. But as we

150
00:08:11.399 --> 00:08:14.079
<v Speaker 2>started scaling out, we started encountering problems with it. So,

151
00:08:14.120 --> 00:08:16.800
<v Speaker 2>for instance, a table that if you ran a migration

152
00:08:16.879 --> 00:08:19.519
<v Speaker 2>on it took thirty minutes. This means that our deployment

153
00:08:19.839 --> 00:08:22.720
<v Speaker 2>took thirty minutes. It also timed out so we lost

154
00:08:22.959 --> 00:08:25.199
<v Speaker 2>all of the context of it. But also during this

155
00:08:25.199 --> 00:08:29.600
<v Speaker 2>period of time, the table locked, so any developer or

156
00:08:29.639 --> 00:08:33.440
<v Speaker 2>any queries that started going to that table stopped being answered.

157
00:08:33.480 --> 00:08:35.960
<v Speaker 2>So all of our servers shut down, and we couldn't

158
00:08:36.039 --> 00:08:39.200
<v Speaker 2>kill the altered table because it was already mid progress.

159
00:08:39.720 --> 00:08:43.240
<v Speaker 2>And after it finished, we now had a table in

160
00:08:43.879 --> 00:08:46.840
<v Speaker 2>UH with like a new state, but the code hadn't

161
00:08:46.840 --> 00:08:49.879
<v Speaker 2>actually finished deploying, so now we're running into different problems.

162
00:08:50.320 --> 00:08:52.720
<v Speaker 2>So this is a little bit of a decision that

163
00:08:52.799 --> 00:08:54.759
<v Speaker 2>it makes a lot of sense when you're small, like

164
00:08:55.000 --> 00:08:58.240
<v Speaker 2>go really quick because you can, and it makes sense.

165
00:08:58.279 --> 00:09:00.240
<v Speaker 2>But when you hit a certain piece of scale, well

166
00:09:00.679 --> 00:09:03.080
<v Speaker 2>you can no longer run with those assumptions and you

167
00:09:03.080 --> 00:09:05.720
<v Speaker 2>need to change those. So a new process needs to

168
00:09:05.759 --> 00:09:08.159
<v Speaker 2>be built. And for database migrations, we need to build

169
00:09:08.159 --> 00:09:10.960
<v Speaker 2>them in a way that are like entirely asynchronous to

170
00:09:10.960 --> 00:09:11.799
<v Speaker 2>a deployment process.

171
00:09:11.879 --> 00:09:14.240
<v Speaker 3>Thirteen minutes is a that's quite a migration.

172
00:09:14.799 --> 00:09:15.039
<v Speaker 1>Yeah.

173
00:09:15.279 --> 00:09:17.879
<v Speaker 2>I think the table, this table that we run uses

174
00:09:17.960 --> 00:09:20.440
<v Speaker 2>us stores a little bit of all of the activity

175
00:09:20.440 --> 00:09:23.200
<v Speaker 2>that users do, and it was like the first table

176
00:09:23.240 --> 00:09:26.159
<v Speaker 2>we ran into that it exhausted like thirty two bit

177
00:09:26.200 --> 00:09:29.080
<v Speaker 2>integers and we needed to flip the IDs to be Biggins.

178
00:09:29.519 --> 00:09:31.759
<v Speaker 2>We didn't think that would be a problem either, and

179
00:09:32.360 --> 00:09:35.120
<v Speaker 2>it's it's leaps and bounds bigger than any of the

180
00:09:35.159 --> 00:09:36.720
<v Speaker 2>other tables we have in our system.

181
00:09:37.159 --> 00:09:39.200
<v Speaker 3>I'm going to ask you of this question now, which

182
00:09:39.279 --> 00:09:44.600
<v Speaker 3>is how do you make your system capable of asynchronous

183
00:09:45.080 --> 00:09:46.120
<v Speaker 3>table migrations.

184
00:09:46.879 --> 00:09:49.360
<v Speaker 2>There's actually there's good question, and there's actually a lot

185
00:09:49.360 --> 00:09:52.159
<v Speaker 2>of tools that exist that we don't necessarily need to

186
00:09:52.159 --> 00:09:56.080
<v Speaker 2>build ourselves. GitHub has a tool called ghost. There's another

187
00:09:56.440 --> 00:09:59.320
<v Speaker 2>tool by Percona in the Percona Toolkit. I can't remember

188
00:09:59.320 --> 00:10:02.639
<v Speaker 2>it's like maybe online schema replacement. Can't remember the exact name.

189
00:10:03.039 --> 00:10:07.679
<v Speaker 2>But the general strategy is to instead of changing a

190
00:10:07.720 --> 00:10:09.720
<v Speaker 2>table with like an altered table, you actually create a

191
00:10:09.759 --> 00:10:14.279
<v Speaker 2>brand new table, populate that table with various mechanisms. Some

192
00:10:14.360 --> 00:10:17.039
<v Speaker 2>of them use triggers, some of them use the binary logs,

193
00:10:17.600 --> 00:10:19.600
<v Speaker 2>get the table to like a table that's in sync,

194
00:10:19.639 --> 00:10:22.159
<v Speaker 2>and then do quick renames. And so you rename the

195
00:10:22.159 --> 00:10:24.159
<v Speaker 2>table to be the old one to be old. You

196
00:10:24.240 --> 00:10:25.720
<v Speaker 2>change the new table to be the new one, and

197
00:10:25.759 --> 00:10:28.240
<v Speaker 2>the new queries start flowing into this new table. And

198
00:10:28.279 --> 00:10:30.919
<v Speaker 2>you can do this as long as you want. It's

199
00:10:31.039 --> 00:10:33.519
<v Speaker 2>entirely non blocking, but it has to be in a

200
00:10:33.559 --> 00:10:37.279
<v Speaker 2>process that exists entirely outside of like the deployment ZECH.

201
00:10:37.679 --> 00:10:39.600
<v Speaker 1>Yeah, and that could have its own issues if you

202
00:10:39.720 --> 00:10:43.720
<v Speaker 1>have you know, thousands of requests per second coming in.

203
00:10:44.320 --> 00:10:47.720
<v Speaker 1>So yeah, definitely not a fun problem to solve. And

204
00:10:48.240 --> 00:10:50.759
<v Speaker 1>it's also I guess good to know what kind of

205
00:10:50.919 --> 00:10:54.120
<v Speaker 1>migration or really what kind of SEQL functions will cause

206
00:10:54.159 --> 00:10:58.360
<v Speaker 1>a table lock. So adding an index or adding a

207
00:10:58.360 --> 00:11:01.960
<v Speaker 1>column and stuff can your table. So being aware of

208
00:11:02.320 --> 00:11:05.519
<v Speaker 1>what actually is going to lock the table is really

209
00:11:05.600 --> 00:11:06.720
<v Speaker 1>good information to know.

210
00:11:07.240 --> 00:11:08.799
<v Speaker 2>Some of them seem obvious, like I think if you're

211
00:11:08.879 --> 00:11:11.440
<v Speaker 2>dropping a column or adding a column, that could potentially lock,

212
00:11:11.600 --> 00:11:13.080
<v Speaker 2>But some of them are not. Like if you changed

213
00:11:13.159 --> 00:11:15.679
<v Speaker 2>a VarChar from like a VarChar one hundred to var

214
00:11:15.799 --> 00:11:17.919
<v Speaker 2>ar chart two hundred and you're just increasing it, does

215
00:11:17.960 --> 00:11:20.519
<v Speaker 2>that lock? Maybe? I actually don't know off the top

216
00:11:20.519 --> 00:11:22.320
<v Speaker 2>of my head. What if you change the character set,

217
00:11:22.360 --> 00:11:24.600
<v Speaker 2>what if you changed the coalition? I don't know.

218
00:11:25.440 --> 00:11:28.000
<v Speaker 3>Is this on my sequel or post ris.

219
00:11:28.279 --> 00:11:30.440
<v Speaker 2>This was in We use Percona, which is just an

220
00:11:30.480 --> 00:11:33.279
<v Speaker 2>offshoot of my sequel, so it'll also be different for

221
00:11:33.440 --> 00:11:36.039
<v Speaker 2>between databases. So PROCONA might have different decisions.

222
00:11:36.440 --> 00:11:40.240
<v Speaker 3>Shout out to the ConA guys. I've done some works

223
00:11:40.240 --> 00:11:42.600
<v Speaker 3>in a place where we had some Pocona consultancy. They

224
00:11:42.600 --> 00:11:44.159
<v Speaker 3>were really good, really delivered.

225
00:11:44.679 --> 00:11:47.960
<v Speaker 1>So that kind of covers the database and scheme a

226
00:11:48.080 --> 00:11:51.000
<v Speaker 1>side of things. To step away from the code you

227
00:11:51.039 --> 00:11:55.519
<v Speaker 1>had mentioned about onboarding people with a larger client base.

228
00:11:55.600 --> 00:11:58.360
<v Speaker 1>What does that process look like for you guys, And

229
00:11:58.679 --> 00:12:02.480
<v Speaker 1>how do you really bring a junior or mid developer

230
00:12:02.600 --> 00:12:05.159
<v Speaker 1>into the company and have them productive quickly.

231
00:12:05.759 --> 00:12:09.519
<v Speaker 2>Yeah, so a lot of this comes from tooling and education. Right,

232
00:12:09.759 --> 00:12:14.320
<v Speaker 2>there's as like senior developers or people who have just

233
00:12:14.360 --> 00:12:18.720
<v Speaker 2>different experience from different places. We've accumulated huge amounts of

234
00:12:18.919 --> 00:12:21.399
<v Speaker 2>knowledge and it's kind of all tribal, and I think

235
00:12:21.480 --> 00:12:24.080
<v Speaker 2>the if you join a company that doesn't have a

236
00:12:24.080 --> 00:12:27.919
<v Speaker 2>great strategy, a lot of the strategies for sharing that

237
00:12:27.960 --> 00:12:31.200
<v Speaker 2>knowledge is like just work together, go submit pull requests

238
00:12:31.200 --> 00:12:33.440
<v Speaker 2>and have them code review and learn from the code review.

239
00:12:33.840 --> 00:12:36.320
<v Speaker 2>And I think that's okay, you can learn that way,

240
00:12:36.679 --> 00:12:40.120
<v Speaker 2>But there are better ways to push information to people.

241
00:12:40.320 --> 00:12:43.120
<v Speaker 2>And this is a concept about like just in time education.

242
00:12:43.799 --> 00:12:47.519
<v Speaker 2>So one of the an interesting example of this can

243
00:12:47.559 --> 00:12:50.639
<v Speaker 2>be through the linters. So I did to talk about

244
00:12:50.679 --> 00:12:52.919
<v Speaker 2>this as well for the twenty twenty Couch edition of

245
00:12:53.000 --> 00:12:57.519
<v Speaker 2>Rails comp called Communicating with Cops that focused on using

246
00:12:58.440 --> 00:13:02.159
<v Speaker 2>rubocop as a mech isn't to provide education. Did a

247
00:13:02.200 --> 00:13:04.799
<v Speaker 2>little bit of deep dive into how ubi cop works

248
00:13:04.799 --> 00:13:07.039
<v Speaker 2>and how to build your own custom camp. But one

249
00:13:07.039 --> 00:13:10.080
<v Speaker 2>of the things that we approach with that CLEO is

250
00:13:10.519 --> 00:13:13.159
<v Speaker 2>as people make mistakes and learn about bad patterns, we

251
00:13:13.240 --> 00:13:17.360
<v Speaker 2>try to codify those patterns so that it's it doesn't

252
00:13:17.399 --> 00:13:20.360
<v Speaker 2>happen again, but people get education about it right as

253
00:13:20.399 --> 00:13:23.639
<v Speaker 2>it happens. A good example of this that is super

254
00:13:23.639 --> 00:13:27.600
<v Speaker 2>trivialent doesn't often bite people until like there's just an

255
00:13:27.679 --> 00:13:31.519
<v Speaker 2>unexpected case would be maybe the Rail's convention of naming files.

256
00:13:32.000 --> 00:13:35.000
<v Speaker 2>We've seen cases where people maybe make like a user's model,

257
00:13:35.240 --> 00:13:38.159
<v Speaker 2>but then make a typo in like the spec. So

258
00:13:38.320 --> 00:13:40.440
<v Speaker 2>rather than call them like user, spec called it users

259
00:13:40.519 --> 00:13:43.519
<v Speaker 2>and it's plural or something along those lines, And you

260
00:13:43.600 --> 00:13:45.720
<v Speaker 2>know this is like the spec is still run, but

261
00:13:45.759 --> 00:13:48.840
<v Speaker 2>there might be some tooling that we expect to adhere

262
00:13:48.879 --> 00:13:51.120
<v Speaker 2>to the Rails convention and it doesn't quite line up.

263
00:13:51.440 --> 00:13:54.080
<v Speaker 2>So you can have a linter that basically checks the

264
00:13:54.200 --> 00:13:56.679
<v Speaker 2>name of the files and the name of the classes

265
00:13:56.720 --> 00:13:58.679
<v Speaker 2>and make sure that they're in line, and if not,

266
00:13:59.120 --> 00:14:01.799
<v Speaker 2>alert people and do that as part of their editor

267
00:14:01.919 --> 00:14:04.000
<v Speaker 2>or do that as part of them committing code. And

268
00:14:04.039 --> 00:14:08.360
<v Speaker 2>they get warnings and they get education as they're writing code.

269
00:14:08.399 --> 00:14:11.120
<v Speaker 2>So they just wrote something, they save the file, they

270
00:14:11.120 --> 00:14:12.679
<v Speaker 2>get a little warning popped up being like, hey, you

271
00:14:12.720 --> 00:14:14.759
<v Speaker 2>may have made a type out here. And this goes

272
00:14:15.240 --> 00:14:17.159
<v Speaker 2>even too as far as behavior. If we know that

273
00:14:17.440 --> 00:14:21.639
<v Speaker 2>there exists bad patterns, so for instance, making an HTTP

274
00:14:21.840 --> 00:14:24.720
<v Speaker 2>call inside of a transaction, which we know is going

275
00:14:24.759 --> 00:14:28.000
<v Speaker 2>to be potentially bad, we can actually automatically prevent that

276
00:14:28.159 --> 00:14:30.440
<v Speaker 2>as soon as that starts happening, as soon as we're

277
00:14:30.440 --> 00:14:32.279
<v Speaker 2>able to detect it. So it might be in a test,

278
00:14:33.000 --> 00:14:35.799
<v Speaker 2>might be as part of a winter. We provide that

279
00:14:36.000 --> 00:14:38.600
<v Speaker 2>education right back to the developer so that they understand

280
00:14:38.679 --> 00:14:40.840
<v Speaker 2>what they did wrong and the avenues of what they

281
00:14:40.840 --> 00:14:42.559
<v Speaker 2>need to do to fix it. So now when a

282
00:14:42.600 --> 00:14:46.120
<v Speaker 2>junior developer enters the company, they can actually just feel

283
00:14:46.120 --> 00:14:48.600
<v Speaker 2>free to start writing code, and write even code in

284
00:14:48.679 --> 00:14:52.399
<v Speaker 2>kind of a way that maybe breaks some patterns, and

285
00:14:52.759 --> 00:14:54.440
<v Speaker 2>a lot of time they're going to start getting education

286
00:14:54.600 --> 00:14:57.000
<v Speaker 2>right away, and then we can do all of the

287
00:14:57.240 --> 00:14:59.559
<v Speaker 2>usual things as well. As pull requests come in, we

288
00:14:59.559 --> 00:15:02.320
<v Speaker 2>can review them and provide more education that way. And

289
00:15:02.360 --> 00:15:05.679
<v Speaker 2>if we find constant patterns of every junior developer we

290
00:15:05.759 --> 00:15:08.519
<v Speaker 2>come in makes the same mistake, let's codify that so

291
00:15:08.559 --> 00:15:10.000
<v Speaker 2>that they get the feedback immediately.

292
00:15:10.480 --> 00:15:13.120
<v Speaker 1>Yeah, that's kind of one of my pet peeves. I

293
00:15:13.120 --> 00:15:16.519
<v Speaker 1>guess you could say with linting is that if a

294
00:15:16.679 --> 00:15:21.519
<v Speaker 1>particular project has a set of practices it likes to follow,

295
00:15:22.120 --> 00:15:26.200
<v Speaker 1>maybe it is no more than one hundred characters on online,

296
00:15:27.200 --> 00:15:30.679
<v Speaker 1>that kind of feedback should never happen in a code review.

297
00:15:31.240 --> 00:15:34.120
<v Speaker 1>That if you have those kind of expectations, then they

298
00:15:34.159 --> 00:15:37.759
<v Speaker 1>need to be known expectations via a linter, whether it's

299
00:15:37.840 --> 00:15:42.159
<v Speaker 1>Rubacopper standard RB, and it should never be an unknown

300
00:15:42.200 --> 00:15:48.879
<v Speaker 1>exception to our unknown expectation to the developer. So I'm

301
00:15:48.919 --> 00:15:51.600
<v Speaker 1>definitely on board with that, And that's something that I've

302
00:15:51.639 --> 00:15:54.759
<v Speaker 1>had to fight and struggle with, is going through code

303
00:15:54.759 --> 00:15:58.120
<v Speaker 1>reviews and having everything kind of nitpicked, because one, it

304
00:15:58.919 --> 00:16:04.000
<v Speaker 1>decreases the morale of the developer if every pull request

305
00:16:04.039 --> 00:16:09.120
<v Speaker 1>they're making it's just getting bombarded with styling quirks or

306
00:16:09.759 --> 00:16:14.120
<v Speaker 1>requests to change. So I could definitely agree with that point.

307
00:16:14.519 --> 00:16:17.600
<v Speaker 1>And I think that every project should adopt some kind

308
00:16:17.639 --> 00:16:22.480
<v Speaker 1>of linter if there are expectations of what they're doing.

309
00:16:22.759 --> 00:16:26.120
<v Speaker 1>Even if you bring in rubocop, you disable everything by

310
00:16:26.159 --> 00:16:30.039
<v Speaker 1>default and then you just start adding in or allowing

311
00:16:30.200 --> 00:16:34.320
<v Speaker 1>which exceptions your team follows on that particular project.

312
00:16:34.720 --> 00:16:37.519
<v Speaker 2>Yeah. Absolutely, And I think there's even one step farther

313
00:16:37.639 --> 00:16:40.840
<v Speaker 2>of a lot of linters can do auto correcting. So

314
00:16:41.120 --> 00:16:45.000
<v Speaker 2>if you you know, if you care about having on

315
00:16:45.000 --> 00:16:48.039
<v Speaker 2>one line space between methods, don't even have rubo cop

316
00:16:48.200 --> 00:16:50.519
<v Speaker 2>or a linter warned about that. Just auto fix it.

317
00:16:50.639 --> 00:16:52.799
<v Speaker 2>Like that's something that developer just doesn't need to worry about.

318
00:16:53.279 --> 00:16:55.759
<v Speaker 2>And you know, it also removes a lot of this

319
00:16:55.879 --> 00:16:58.000
<v Speaker 2>argument over like should I use double quotes? Should I

320
00:16:58.080 --> 00:17:00.720
<v Speaker 2>use single quotes? If it just auto medically fixed and

321
00:17:00.720 --> 00:17:03.679
<v Speaker 2>developer can write whatever that they want, that's fine. But

322
00:17:03.840 --> 00:17:07.319
<v Speaker 2>I've also run into issues of having pull requests being

323
00:17:07.359 --> 00:17:10.240
<v Speaker 2>bombarded by style and it really distracts from the code

324
00:17:10.279 --> 00:17:11.400
<v Speaker 2>review about the behavior.

325
00:17:11.880 --> 00:17:15.279
<v Speaker 1>Yeah. Absolutely, although you do have to be careful about

326
00:17:15.319 --> 00:17:17.960
<v Speaker 1>the auto correction. I remember one time in my earlier

327
00:17:18.039 --> 00:17:21.039
<v Speaker 1>days of development, when Ruby mind came out, I tried

328
00:17:21.039 --> 00:17:25.799
<v Speaker 1>out ruby Mine's code refactoring thing. I forget what they

329
00:17:25.839 --> 00:17:30.200
<v Speaker 1>call it, but I had some really poorly written classes

330
00:17:30.440 --> 00:17:34.000
<v Speaker 1>and it just absolutely broke everything. Like, I have no

331
00:17:34.079 --> 00:17:36.799
<v Speaker 1>idea how that happened, but things just were not working

332
00:17:36.839 --> 00:17:39.559
<v Speaker 1>the way they were before, and I had to pull

333
00:17:39.640 --> 00:17:42.599
<v Speaker 1>that merge back out because you know, of course, as

334
00:17:42.640 --> 00:17:45.720
<v Speaker 1>a early developer, I didn't have any tests on the application,

335
00:17:45.920 --> 00:17:49.000
<v Speaker 1>so I didn't really notice that things were broken until

336
00:17:49.559 --> 00:17:50.400
<v Speaker 1>they got deployed.

337
00:17:50.880 --> 00:17:54.039
<v Speaker 2>Yeah. Yeah, I did definitely need to be careful there.

338
00:17:54.400 --> 00:17:58.599
<v Speaker 1>So you also previously mentioned about so not necessarily on

339
00:17:58.759 --> 00:18:02.160
<v Speaker 1>boarding developers, but having a lot of developers work on

340
00:18:02.200 --> 00:18:05.079
<v Speaker 1>the project. So what point do you go from a

341
00:18:05.119 --> 00:18:07.799
<v Speaker 1>small shop to a large shop where you have to

342
00:18:07.839 --> 00:18:11.200
<v Speaker 1>start putting different kinds of practices in place? And what

343
00:18:11.359 --> 00:18:14.400
<v Speaker 1>are those kind of practices when you're dealing with a

344
00:18:14.400 --> 00:18:16.400
<v Speaker 1>lot of developers on a single code base.

345
00:18:16.960 --> 00:18:19.559
<v Speaker 2>So I actually it's not clear where that point exists.

346
00:18:19.640 --> 00:18:22.160
<v Speaker 2>I think it's probably going to be different for every organization,

347
00:18:22.200 --> 00:18:25.920
<v Speaker 2>and probably different for exactly the work that you're running into.

348
00:18:26.400 --> 00:18:28.240
<v Speaker 2>I think the thing is to be listen to the

349
00:18:28.240 --> 00:18:31.039
<v Speaker 2>pain points of the developers. So if you notice that

350
00:18:31.119 --> 00:18:35.079
<v Speaker 2>there are you know, there's pieces of friction that occur

351
00:18:35.240 --> 00:18:38.920
<v Speaker 2>between developers, like that's the point where maybe there's actually

352
00:18:38.920 --> 00:18:41.079
<v Speaker 2>some tools that need to be built to make this easier.

353
00:18:41.519 --> 00:18:43.680
<v Speaker 2>So one thing that I think comes up really quickly

354
00:18:44.119 --> 00:18:47.480
<v Speaker 2>in organizations is often the concept of like a testing server.

355
00:18:47.960 --> 00:18:50.839
<v Speaker 2>So you've got your developers environment, you've got your your

356
00:18:50.839 --> 00:18:53.319
<v Speaker 2>maybe your CI but maybe you want like a production

357
00:18:53.680 --> 00:18:57.319
<v Speaker 2>like environment for things, and so you have a staging serve.

358
00:18:57.640 --> 00:19:00.759
<v Speaker 2>You know, when there's five developers, it's really just coordinate

359
00:19:00.799 --> 00:19:02.480
<v Speaker 2>and be like, oh, staging is mine now, I'm going

360
00:19:02.559 --> 00:19:04.960
<v Speaker 2>to test something. When it's done, I will hand it

361
00:19:05.000 --> 00:19:08.160
<v Speaker 2>off and maybe reset it back to whatever the master

362
00:19:08.240 --> 00:19:12.680
<v Speaker 2>branch and let people work that way. But that really

363
00:19:12.759 --> 00:19:15.319
<v Speaker 2>falls apart when you have one hundred developers. How do

364
00:19:15.319 --> 00:19:18.480
<v Speaker 2>you coordinate one server where everyone is trying to test something.

365
00:19:18.960 --> 00:19:21.200
<v Speaker 2>If you have one hundred developers fighting for that resource,

366
00:19:21.640 --> 00:19:25.359
<v Speaker 2>you can kind of budget a little bit by maybe

367
00:19:25.400 --> 00:19:27.759
<v Speaker 2>having a fixed number, and you know, you round robbing

368
00:19:27.799 --> 00:19:29.559
<v Speaker 2>them out, but again, at some point that's going to

369
00:19:29.599 --> 00:19:33.079
<v Speaker 2>break down. So if you think about, like, what's the

370
00:19:33.119 --> 00:19:35.720
<v Speaker 2>problem here is that every developer wants to potentially test

371
00:19:35.759 --> 00:19:38.920
<v Speaker 2>something on an asynchronous schedule, maybe it actually makes sense

372
00:19:38.920 --> 00:19:41.440
<v Speaker 2>to build some tooling so that you can spin up

373
00:19:41.480 --> 00:19:45.640
<v Speaker 2>a like staging servers on like Amazon Easy two or

374
00:19:45.920 --> 00:19:50.079
<v Speaker 2>on Google on Demand and just route them there. And

375
00:19:50.079 --> 00:19:51.759
<v Speaker 2>so that's something that we ended up having to do

376
00:19:51.839 --> 00:19:55.000
<v Speaker 2>really early of building our own toolings so that we

377
00:19:55.039 --> 00:19:58.359
<v Speaker 2>can we call them beta environments where we can have

378
00:19:58.839 --> 00:20:02.960
<v Speaker 2>arbitrary number of them. Someone spent the effort to basically say,

379
00:20:02.960 --> 00:20:06.720
<v Speaker 2>like this branch on GitHub, I want a clone of

380
00:20:06.759 --> 00:20:12.119
<v Speaker 2>the site on Amazon, and within like ten minutes, you've

381
00:20:12.119 --> 00:20:14.960
<v Speaker 2>got a domain that points to it. You've got the

382
00:20:14.960 --> 00:20:17.119
<v Speaker 2>full stack, you can you have full control, you can

383
00:20:17.160 --> 00:20:19.200
<v Speaker 2>do whatever you want, you can break it, and it

384
00:20:19.200 --> 00:20:22.880
<v Speaker 2>gives developers a lot of autonomy to test things that

385
00:20:22.920 --> 00:20:25.720
<v Speaker 2>they want, and you know, removes a lot of this, Oh,

386
00:20:25.759 --> 00:20:27.799
<v Speaker 2>let's deploy it and see what happens. You have a

387
00:20:27.839 --> 00:20:29.880
<v Speaker 2>full environment that you have full control over, Go test it,

388
00:20:30.160 --> 00:20:31.720
<v Speaker 2>go see it with as much data as you want,

389
00:20:31.839 --> 00:20:34.759
<v Speaker 2>and then see what happens. Another example kind of along

390
00:20:34.839 --> 00:20:38.680
<v Speaker 2>those things is like deployments. Do you have a handful

391
00:20:38.759 --> 00:20:41.559
<v Speaker 2>of senior developers who can deploy or do you deploy

392
00:20:41.640 --> 00:20:45.079
<v Speaker 2>on like a every Monday you do a big deployment

393
00:20:45.720 --> 00:20:47.400
<v Speaker 2>that's going to start really breaking down when you have

394
00:20:47.440 --> 00:20:51.440
<v Speaker 2>a lot of developers. You know, at CLEO, everyone has

395
00:20:51.480 --> 00:20:54.519
<v Speaker 2>the ability to deploy, everyone has the ability to merge code.

396
00:20:55.000 --> 00:20:57.759
<v Speaker 2>So we give the power to the developers and now

397
00:20:58.160 --> 00:21:00.279
<v Speaker 2>you know, a junior developer can come in, write a

398
00:21:00.279 --> 00:21:02.599
<v Speaker 2>fix to a read me, merge the code, deploy it

399
00:21:02.640 --> 00:21:05.400
<v Speaker 2>without having to really bother people outside of getting a

400
00:21:05.480 --> 00:21:10.200
<v Speaker 2>code review. And know, now we're deploying code probably upwards

401
00:21:10.240 --> 00:21:12.759
<v Speaker 2>of thirty ish times a day, and that number is

402
00:21:12.799 --> 00:21:15.720
<v Speaker 2>just only going to go up. And so as we're

403
00:21:15.799 --> 00:21:18.279
<v Speaker 2>running into these issues, we are just looking at what

404
00:21:18.319 --> 00:21:20.000
<v Speaker 2>can we do to build tooling so that it's no

405
00:21:20.079 --> 00:21:23.200
<v Speaker 2>longer frustrating for developers. And the important part of this

406
00:21:23.240 --> 00:21:26.319
<v Speaker 2>is developers need to voice things, and you know, managers

407
00:21:26.319 --> 00:21:29.519
<v Speaker 2>and companies need to listen. If we're wasting five hours

408
00:21:29.559 --> 00:21:32.920
<v Speaker 2>a week per developer on this one thing that's frustrating,

409
00:21:32.960 --> 00:21:34.319
<v Speaker 2>like build tooling around it.

410
00:21:34.720 --> 00:21:36.799
<v Speaker 1>Yeah, that's one of the things that I did just

411
00:21:36.839 --> 00:21:41.119
<v Speaker 1>for my own hobby project and just continual learning, is

412
00:21:41.160 --> 00:21:45.039
<v Speaker 1>that a self hosted git lab instance and I set

413
00:21:45.119 --> 00:21:50.680
<v Speaker 1>up a Kubernet server which will automatically create the infrastructure

414
00:21:50.920 --> 00:21:54.440
<v Speaker 1>for the application that got pushed, so it always happens

415
00:21:54.519 --> 00:21:57.920
<v Speaker 1>on any kind of development or master branch push and

416
00:21:57.960 --> 00:22:02.000
<v Speaker 1>then also on each commit up to the repository and

417
00:22:02.039 --> 00:22:06.039
<v Speaker 1>they'll spin up an entire infrastructure within Kubernetes with the

418
00:22:06.200 --> 00:22:10.319
<v Speaker 1>FQDN that that feature can then be tested. So it

419
00:22:10.359 --> 00:22:12.720
<v Speaker 1>works on smaller applications. I don't know how it would

420
00:22:12.759 --> 00:22:17.640
<v Speaker 1>work on applications that consume thirty gigs of RAM of resources,

421
00:22:17.759 --> 00:22:21.000
<v Speaker 1>but I think on smaller applications that kind of thing

422
00:22:21.039 --> 00:22:24.680
<v Speaker 1>can really save you from having to have dedicated test

423
00:22:24.720 --> 00:22:27.079
<v Speaker 1>servers that shared by several people.

424
00:22:27.519 --> 00:22:29.640
<v Speaker 3>When are you going to do an episode on that, Dave?

425
00:22:32.920 --> 00:22:37.000
<v Speaker 1>I do have a Jefre Ruby episode on Kubernetes, which

426
00:22:37.200 --> 00:22:40.279
<v Speaker 1>that's where I got the inspiration from. On that episode,

427
00:22:40.359 --> 00:22:44.200
<v Speaker 1>I just didn't tied into the CICD portion.

428
00:22:44.880 --> 00:22:47.039
<v Speaker 3>I got a I got a question for you, Kyle.

429
00:22:47.400 --> 00:22:48.759
<v Speaker 3>It sounds like you've got to You've got a lot

430
00:22:48.759 --> 00:22:52.599
<v Speaker 3>of data if you're running thirty minute migrations, and you've

431
00:22:52.640 --> 00:22:56.359
<v Speaker 3>got a lot of developers, and you've got a good testing,

432
00:22:56.440 --> 00:22:59.680
<v Speaker 3>good infrastructure. What I what I've found is a lot

433
00:22:59.680 --> 00:23:04.920
<v Speaker 3>of kind of real memorable problems I've had is where

434
00:23:04.960 --> 00:23:07.400
<v Speaker 3>you get something running and it feels like it's going

435
00:23:07.480 --> 00:23:11.079
<v Speaker 3>to be fine, but then it gets deployed to the

436
00:23:11.359 --> 00:23:14.960
<v Speaker 3>master database and that's the point at which there's some

437
00:23:15.119 --> 00:23:17.960
<v Speaker 3>bad data in there. There's something in there from ages ago,

438
00:23:18.039 --> 00:23:22.960
<v Speaker 3>from a previous version, and it absolutely sinks you. And

439
00:23:23.680 --> 00:23:27.440
<v Speaker 3>these days, whenever I possibly can, I just pulled the

440
00:23:27.640 --> 00:23:31.880
<v Speaker 3>entire production database out and test against that. Do you

441
00:23:32.079 --> 00:23:35.880
<v Speaker 3>do that or is your database just so huge, kind

442
00:23:35.880 --> 00:23:39.119
<v Speaker 3>of throwed around. You can't do that, especially with a

443
00:23:39.160 --> 00:23:40.160
<v Speaker 3>lot of her developers.

444
00:23:40.440 --> 00:23:42.200
<v Speaker 2>It used to be something that we did. We used

445
00:23:42.240 --> 00:23:44.000
<v Speaker 2>to have We used to call it the snapshot, and

446
00:23:44.119 --> 00:23:47.680
<v Speaker 2>you could point environments at the snapshot and run test

447
00:23:47.799 --> 00:23:50.359
<v Speaker 2>queries on it, but we actually do it did hit

448
00:23:50.400 --> 00:23:52.759
<v Speaker 2>a size where the time it took to set up

449
00:23:52.759 --> 00:23:55.839
<v Speaker 2>the snapshot every day was taking longer than it would

450
00:23:55.839 --> 00:23:59.000
<v Speaker 2>take to actually back it up. So it was just

451
00:23:59.400 --> 00:24:01.720
<v Speaker 2>starting to become unfeasible for us. And we're also dealing

452
00:24:01.720 --> 00:24:04.480
<v Speaker 2>with sensitive data and we don't necessarily want to give

453
00:24:04.559 --> 00:24:09.000
<v Speaker 2>free access to all of that data for our our clients,

454
00:24:09.359 --> 00:24:12.279
<v Speaker 2>so we instead try to invest in a little bit

455
00:24:12.279 --> 00:24:15.599
<v Speaker 2>of tooling. We definitely still have issues where everything looks

456
00:24:15.640 --> 00:24:17.599
<v Speaker 2>good in development, everything looks good in like data or

457
00:24:17.680 --> 00:24:20.880
<v Speaker 2>test and we deployed to production, something is wrong. So

458
00:24:20.880 --> 00:24:23.920
<v Speaker 2>we think about what can we do to make that better?

459
00:24:24.400 --> 00:24:28.279
<v Speaker 2>And so we you know, if it's about a lack

460
00:24:28.319 --> 00:24:30.680
<v Speaker 2>of index on like a database query or something like that,

461
00:24:31.119 --> 00:24:33.119
<v Speaker 2>we can try to check that ahead of time and

462
00:24:33.119 --> 00:24:36.240
<v Speaker 2>build some tooling and alert people when something goes wrong.

463
00:24:36.519 --> 00:24:38.960
<v Speaker 2>But also in production we can be say like, hey,

464
00:24:38.960 --> 00:24:42.599
<v Speaker 2>this query took thirty minutes, that's unacceptable, this career took

465
00:24:42.640 --> 00:24:45.759
<v Speaker 2>five minutes and return that information as like an exception

466
00:24:46.000 --> 00:24:48.519
<v Speaker 2>to the developers that they need to fix, but without

467
00:24:48.519 --> 00:24:53.839
<v Speaker 2>interrupting the actual request behavior. And if things go really south,

468
00:24:54.480 --> 00:24:57.480
<v Speaker 2>just roll it back, like we don't really have. It's

469
00:24:57.519 --> 00:25:00.720
<v Speaker 2>not a blame if someone deploys thing and goes south

470
00:25:00.759 --> 00:25:02.559
<v Speaker 2>and they quickly roll it back. We just try to

471
00:25:02.599 --> 00:25:04.599
<v Speaker 2>take that as a learning opportunity. And how can we

472
00:25:05.039 --> 00:25:07.559
<v Speaker 2>take that learning opportunity and share it to everybody so

473
00:25:07.599 --> 00:25:10.000
<v Speaker 2>that everyone learns from it. Then answer your question.

474
00:25:10.200 --> 00:25:11.680
<v Speaker 3>Yeah, I mean you must be dealing with a lot

475
00:25:11.720 --> 00:25:15.079
<v Speaker 3>of data, and I've worked with you call it hipA

476
00:25:15.200 --> 00:25:18.880
<v Speaker 3>data in the States where it's kind of confidential data,

477
00:25:19.039 --> 00:25:24.640
<v Speaker 3>and that hugely complicates testing data chranswers because you have

478
00:25:24.720 --> 00:25:28.839
<v Speaker 3>to have to either heavily anonymize or write your own

479
00:25:28.920 --> 00:25:34.039
<v Speaker 3>tools kind of replicate a few one hundred thousand medical records.

480
00:25:34.359 --> 00:25:36.920
<v Speaker 2>Yeah. All we can also do is I mentioned earlier

481
00:25:36.960 --> 00:25:38.960
<v Speaker 2>that we could talk. We have these data environments that

482
00:25:39.000 --> 00:25:41.400
<v Speaker 2>we can spin up. You just use like a sequel

483
00:25:41.480 --> 00:25:45.000
<v Speaker 2>dump to store data in there. And although this isn't

484
00:25:45.039 --> 00:25:47.920
<v Speaker 2>necessarily production data, developers have full control over what that

485
00:25:48.000 --> 00:25:51.000
<v Speaker 2>data looks like. And so you know, if we wanted

486
00:25:51.000 --> 00:25:53.799
<v Speaker 2>to see what happens if there is tens of thousands

487
00:25:53.799 --> 00:25:56.039
<v Speaker 2>of something in a table or more, we can just

488
00:25:56.039 --> 00:25:59.359
<v Speaker 2>build like little scripts that can feed this seed that

489
00:25:59.480 --> 00:26:02.680
<v Speaker 2>database and then test it outside of production. It's not

490
00:26:02.759 --> 00:26:05.880
<v Speaker 2>perfect because it doesn't always match the same shape as production,

491
00:26:06.319 --> 00:26:08.680
<v Speaker 2>but you can. It's an iterative process, and that information

492
00:26:08.720 --> 00:26:11.400
<v Speaker 2>gets codified, so you can keep adding to the seeds

493
00:26:11.400 --> 00:26:14.319
<v Speaker 2>in those manner so that it becomes a better and

494
00:26:14.359 --> 00:26:16.039
<v Speaker 2>better representation as.

495
00:26:15.960 --> 00:26:18.240
<v Speaker 1>We go forward. Yeah, so kind of back to the

496
00:26:18.279 --> 00:26:22.480
<v Speaker 1>technical debt. I have a unfortunate story of something that

497
00:26:22.559 --> 00:26:27.319
<v Speaker 1>I inherited one time where I think metaprogramming is awesome

498
00:26:27.519 --> 00:26:29.720
<v Speaker 1>and can do a lot of really cool things and

499
00:26:29.759 --> 00:26:32.759
<v Speaker 1>can really get you out of a bind in certain situations,

500
00:26:33.240 --> 00:26:37.519
<v Speaker 1>but then it can also be overly abused. And I

501
00:26:37.640 --> 00:26:41.000
<v Speaker 1>was searching for a function that was not working properly

502
00:26:41.240 --> 00:26:44.000
<v Speaker 1>within Ruby, and I couldn't find it in the code

503
00:26:44.000 --> 00:26:46.880
<v Speaker 1>base at all. So I thought, okay, well, surely that

504
00:26:47.119 --> 00:26:50.240
<v Speaker 1>this is in the gym or something. So I started

505
00:26:50.240 --> 00:26:53.599
<v Speaker 1>looking at all the gems that's included into this Rails application,

506
00:26:54.200 --> 00:26:57.720
<v Speaker 1>started tearing apart the gems, opening them to search for

507
00:26:57.839 --> 00:27:01.920
<v Speaker 1>this function. Still couldn't find it. Turns out they are

508
00:27:01.960 --> 00:27:06.440
<v Speaker 1>doing a classy val on something that's pulled from the database.

509
00:27:07.000 --> 00:27:12.319
<v Speaker 1>So they actually stored Ruby functions as column or data

510
00:27:12.440 --> 00:27:16.799
<v Speaker 1>within a column on the database, and that's what was

511
00:27:16.839 --> 00:27:21.559
<v Speaker 1>getting executed. That's where the function was defined. So to me,

512
00:27:21.680 --> 00:27:22.960
<v Speaker 1>that's a what's that?

513
00:27:23.519 --> 00:27:25.680
<v Speaker 3>What's wrong with that?

514
00:27:26.759 --> 00:27:30.279
<v Speaker 1>Yeah, so you know, other than you could not possibly

515
00:27:30.319 --> 00:27:33.079
<v Speaker 1>even test that bit of code any with any kind

516
00:27:33.119 --> 00:27:38.039
<v Speaker 1>of reason. But it was a nightmare. So just a

517
00:27:38.039 --> 00:27:40.759
<v Speaker 1>warning to when you think that you're doing something really

518
00:27:40.759 --> 00:27:45.000
<v Speaker 1>cool and elegant that's avoiding code duplication or whatever. I

519
00:27:45.000 --> 00:27:48.759
<v Speaker 1>would much rather have code duplication all across my application

520
00:27:49.279 --> 00:27:52.960
<v Speaker 1>than having that level of obfuscation where you're never going

521
00:27:53.039 --> 00:27:55.400
<v Speaker 1>to be able to even remotely troubleshoot it.

522
00:27:55.839 --> 00:27:59.440
<v Speaker 2>Yeah, metaprogramming is a like it's actually one of the

523
00:27:59.480 --> 00:28:02.039
<v Speaker 2>best lengths of Ruby. You can do so much with it,

524
00:28:02.359 --> 00:28:04.480
<v Speaker 2>but it's on you once you have it. It's the

525
00:28:04.480 --> 00:28:06.640
<v Speaker 2>hammer and everything is a nail, and you want to

526
00:28:06.720 --> 00:28:09.119
<v Speaker 2>use it. And that's that's often a trap that new

527
00:28:09.160 --> 00:28:11.759
<v Speaker 2>developers when they learn about metaprogramming, they really want to

528
00:28:11.799 --> 00:28:14.720
<v Speaker 2>go into. I think a good lesson to come out

529
00:28:14.759 --> 00:28:19.400
<v Speaker 2>of that story is that if you think about code,

530
00:28:19.759 --> 00:28:23.920
<v Speaker 2>it's written once but read countless times, and so if

531
00:28:23.960 --> 00:28:26.640
<v Speaker 2>you can take the little things to optimize the code

532
00:28:26.680 --> 00:28:30.920
<v Speaker 2>for the reader, that is much better than sacrificing readability

533
00:28:30.960 --> 00:28:33.680
<v Speaker 2>to optimize for the writer. So if it takes you

534
00:28:33.720 --> 00:28:36.799
<v Speaker 2>an extra thirty minutes to write a whole bunch of

535
00:28:36.880 --> 00:28:39.599
<v Speaker 2>cookie cutter methods, but now those methods are in place

536
00:28:39.599 --> 00:28:42.680
<v Speaker 2>and they're static and it's easy to read and reason

537
00:28:42.680 --> 00:28:45.680
<v Speaker 2>about end test, that is well worth that thirty minutes,

538
00:28:45.720 --> 00:28:48.319
<v Speaker 2>because you're going to lose more than that reading that

539
00:28:49.000 --> 00:28:50.119
<v Speaker 2>piece of code in the future.

540
00:28:50.440 --> 00:28:54.720
<v Speaker 1>Yeah. Absolutely, And it could even be taken into something

541
00:28:54.839 --> 00:28:58.039
<v Speaker 1>like private methods where if you have a class which

542
00:28:58.039 --> 00:29:01.599
<v Speaker 1>has a bunch of methods, start sorting them out which

543
00:29:01.599 --> 00:29:05.119
<v Speaker 1>ones are private methods so they do not need to

544
00:29:05.119 --> 00:29:09.720
<v Speaker 1>be accessible to the consumer, because I've had situations where

545
00:29:09.799 --> 00:29:13.240
<v Speaker 1>I've worked on a class that grew over a thousand

546
00:29:13.279 --> 00:29:16.799
<v Speaker 1>lines and there were hundreds of methods in there, and

547
00:29:16.839 --> 00:29:21.119
<v Speaker 1>I had no idea which ones were publicly accessible, that

548
00:29:21.200 --> 00:29:24.759
<v Speaker 1>were truly supposed to be publicly accessible, and which ones

549
00:29:24.839 --> 00:29:28.400
<v Speaker 1>were really meant to be private. So not having that

550
00:29:28.519 --> 00:29:32.359
<v Speaker 1>level of abstraction, so to speak, you lose a lot

551
00:29:32.359 --> 00:29:37.279
<v Speaker 1>of visibility in how important is this class to the consumer.

552
00:29:37.759 --> 00:29:40.559
<v Speaker 2>Yeah. Absolutely, anything that you can do to make those

553
00:29:40.640 --> 00:29:44.240
<v Speaker 2>kind of classes easier to understand and read for a

554
00:29:44.000 --> 00:29:47.480
<v Speaker 2>new person is great. And also just backing up a

555
00:29:47.480 --> 00:29:50.279
<v Speaker 2>little bit to your example, this is also an instance

556
00:29:50.279 --> 00:29:52.880
<v Speaker 2>where metaprogramming bit you, but metaprogramming is also interesting that

557
00:29:52.920 --> 00:29:55.640
<v Speaker 2>it could save you because you can also ask Ruby

558
00:29:55.680 --> 00:29:59.559
<v Speaker 2>about Ruby. So if anyone didn't know what this is

559
00:29:59.559 --> 00:30:01.759
<v Speaker 2>a attack that I use all the time for debuton

560
00:30:01.759 --> 00:30:04.079
<v Speaker 2>pieces of code that I've never been familiar with, you

561
00:30:04.119 --> 00:30:06.359
<v Speaker 2>can If you can have access to a console, you

562
00:30:06.440 --> 00:30:09.720
<v Speaker 2>can ask Ruby what methods are available with like a

563
00:30:09.759 --> 00:30:12.319
<v Speaker 2>dot methods call. You can also get access to the

564
00:30:12.359 --> 00:30:15.279
<v Speaker 2>method itself and then ask it like, what is its source,

565
00:30:15.519 --> 00:30:19.039
<v Speaker 2>where does it live where? That can make life easier

566
00:30:19.079 --> 00:30:22.680
<v Speaker 2>to track down methods that may be dynamic or created

567
00:30:22.720 --> 00:30:23.480
<v Speaker 2>by gems.

568
00:30:23.720 --> 00:30:28.759
<v Speaker 3>I recently learned how to use the LS command in Prey,

569
00:30:29.480 --> 00:30:31.480
<v Speaker 3>and now I just I just live out of the

570
00:30:31.640 --> 00:30:36.200
<v Speaker 3>LS pri command. The Ruby API traffic's drop off considerably.

571
00:30:36.680 --> 00:30:39.720
<v Speaker 3>I find I find the dot methods to be quite noisy.

572
00:30:40.160 --> 00:30:42.519
<v Speaker 3>This is very the bose if you're kind of trying

573
00:30:42.519 --> 00:30:45.200
<v Speaker 3>to pick out which command it is. And I really

574
00:30:45.319 --> 00:30:47.200
<v Speaker 3>like the pre LS command.

575
00:30:47.440 --> 00:30:49.799
<v Speaker 4>Yeah, I mean you can do to make that less

576
00:30:49.839 --> 00:30:54.319
<v Speaker 4>noisy is take like object dot new and subtract the

577
00:30:54.359 --> 00:30:56.920
<v Speaker 4>methods out of that and sort it and all that

578
00:30:56.960 --> 00:30:58.359
<v Speaker 4>sort of stuff, and you can do it all on

579
00:30:58.400 --> 00:31:01.720
<v Speaker 4>a one liner because we're in But yeah, I'll ask

580
00:31:01.839 --> 00:31:02.680
<v Speaker 4>is another great option.

581
00:31:03.160 --> 00:31:06.240
<v Speaker 3>It's my documentation suffered for it. I must admit. Now

582
00:31:06.279 --> 00:31:08.559
<v Speaker 3>my attitude is just I can just arlest the class

583
00:31:08.599 --> 00:31:09.640
<v Speaker 3>and see what's going on. Man.

584
00:31:10.440 --> 00:31:13.640
<v Speaker 2>I think that's another example of someone making some tooling

585
00:31:13.799 --> 00:31:16.480
<v Speaker 2>that you know, makes something that. Yeah, if you knew

586
00:31:16.480 --> 00:31:19.279
<v Speaker 2>to call dot methods and subtract object dot new dot

587
00:31:19.319 --> 00:31:22.279
<v Speaker 2>methods or object dot methods, it's great. But now it's

588
00:31:22.319 --> 00:31:24.960
<v Speaker 2>two characters and it's nice and easy, and it's much

589
00:31:24.960 --> 00:31:28.119
<v Speaker 2>more approachable, and then you can have access to things

590
00:31:28.160 --> 00:31:29.519
<v Speaker 2>that you may not knew existed.

591
00:31:30.119 --> 00:31:32.559
<v Speaker 3>Can I ask you about can we turn back the

592
00:31:32.640 --> 00:31:35.599
<v Speaker 3>clock and ask you about Rail's zero?

593
00:31:36.240 --> 00:31:38.640
<v Speaker 2>Oh, it's been a long long time since I've worked

594
00:31:38.680 --> 00:31:40.799
<v Speaker 2>on rail zero. I can try to answer questions, but.

595
00:31:41.480 --> 00:31:43.240
<v Speaker 3>So it sounds like you've been on a bit of

596
00:31:43.240 --> 00:31:46.839
<v Speaker 3>a journey with scaling things up. What did you do

597
00:31:47.000 --> 00:31:48.279
<v Speaker 3>before rail zero?

598
00:31:48.920 --> 00:31:52.079
<v Speaker 2>Oh? I Actually most of my career has been working

599
00:31:52.079 --> 00:31:56.519
<v Speaker 2>with rails. So before rail zero, I was working at

600
00:31:56.559 --> 00:31:59.720
<v Speaker 2>like an enterprise Java shop that I don't remember a

601
00:31:59.720 --> 00:32:02.079
<v Speaker 2>lot of details of it anymore. It's kind of too

602
00:32:02.160 --> 00:32:05.480
<v Speaker 2>far in the past. But I think I've been working

603
00:32:05.480 --> 00:32:09.000
<v Speaker 2>with rails now for eleven years. I think, so it's

604
00:32:09.039 --> 00:32:10.920
<v Speaker 2>been just a long time just rails. I don't remember

605
00:32:10.920 --> 00:32:12.559
<v Speaker 2>a lot of the pre rails world. To be honest,

606
00:32:12.960 --> 00:32:13.559
<v Speaker 2>that is.

607
00:32:13.519 --> 00:32:18.680
<v Speaker 3>The correct answer. There is no other system. I ask

608
00:32:18.839 --> 00:32:22.119
<v Speaker 3>because we were talking about the N plus one queries,

609
00:32:22.480 --> 00:32:27.519
<v Speaker 3>and my complaint is that rails makes it too easy

610
00:32:28.000 --> 00:32:30.440
<v Speaker 3>to do N plus one queries because if you just

611
00:32:30.519 --> 00:32:32.799
<v Speaker 3>kind of thought of all the guides, that's what you get.

612
00:32:33.319 --> 00:32:35.680
<v Speaker 3>If you kind of do a dot lder each. Then

613
00:32:35.960 --> 00:32:38.079
<v Speaker 3>you're going to be there for a while and you

614
00:32:38.160 --> 00:32:42.000
<v Speaker 3>start noticing that when you start getting into a few

615
00:32:42.079 --> 00:32:46.359
<v Speaker 3>thousand objects. So you can be sitting there prototyping something

616
00:32:46.400 --> 00:32:49.240
<v Speaker 3>and think this is great, and then when people start

617
00:32:49.359 --> 00:32:51.720
<v Speaker 3>using it, you drop it in. That's when you start

618
00:32:51.799 --> 00:32:55.839
<v Speaker 3>hitting these gotchas. But I think people forget what the

619
00:32:55.880 --> 00:33:00.160
<v Speaker 3>battle days were before you had the rails tooling out

620
00:33:00.200 --> 00:33:01.920
<v Speaker 3>of time it took when you had to write your

621
00:33:01.920 --> 00:33:06.720
<v Speaker 3>own queries. It's really quite significant. And they mentioned Enterprise

622
00:33:06.880 --> 00:33:10.200
<v Speaker 3>Java that was not a whole lot of object relation

623
00:33:10.359 --> 00:33:14.480
<v Speaker 3>mapping going on in that, so that it is a

624
00:33:14.559 --> 00:33:18.680
<v Speaker 3>double edged sword when you're operating at the scale you do,

625
00:33:19.519 --> 00:33:23.279
<v Speaker 3>what are the parts of rails that start to bite.

626
00:33:23.759 --> 00:33:26.440
<v Speaker 2>We've definitely been bitten by how easy it's been to

627
00:33:26.480 --> 00:33:28.880
<v Speaker 2>make M plus one queries in the past. I think

628
00:33:28.920 --> 00:33:31.240
<v Speaker 2>pretty much any rail shop is going to be doing it.

629
00:33:31.680 --> 00:33:35.880
<v Speaker 2>Rails offers tooling to help with that, but the tooling

630
00:33:35.960 --> 00:33:39.559
<v Speaker 2>still requires a lot of effort. You have to kind

631
00:33:39.559 --> 00:33:41.599
<v Speaker 2>of know what N plus one query you're introducing and

632
00:33:41.680 --> 00:33:44.920
<v Speaker 2>fix it. So though that's where you can build some

633
00:33:44.920 --> 00:33:47.720
<v Speaker 2>more tooling. There exists a gem that we built a

634
00:33:47.799 --> 00:33:51.000
<v Speaker 2>jip preloader. There's also another community gem called a Goldie

635
00:33:51.000 --> 00:33:54.880
<v Speaker 2>loader that removes stuff like M plus one queries, and

636
00:33:55.480 --> 00:33:59.960
<v Speaker 2>those are ways to like basically eliminate those kind of problems.

637
00:34:00.000 --> 00:34:02.440
<v Speaker 2>Some other things that kind of come off on Rails

638
00:34:02.519 --> 00:34:06.559
<v Speaker 2>as we are building is like discoverability of templates. So

639
00:34:06.599 --> 00:34:08.800
<v Speaker 2>I think you're one of the previous episodes of Ruby

640
00:34:08.880 --> 00:34:12.280
<v Speaker 2>Ropes was talking about this, but as as it scales

641
00:34:12.360 --> 00:34:15.039
<v Speaker 2>up like rails, EERB makes it really easy to render

642
00:34:15.039 --> 00:34:18.480
<v Speaker 2>partials all over the place, but it's really hard to understand,

643
00:34:19.000 --> 00:34:21.400
<v Speaker 2>like if you're looking at a page, where are those

644
00:34:21.440 --> 00:34:24.119
<v Speaker 2>partials actually coming from? And how can you dig back

645
00:34:24.159 --> 00:34:27.639
<v Speaker 2>into them? So we've like that's a challenging thing with

646
00:34:27.719 --> 00:34:30.480
<v Speaker 2>rails as well. There's also some things with the community

647
00:34:30.480 --> 00:34:34.039
<v Speaker 2>for things like paging that can be problematic at scale.

648
00:34:34.320 --> 00:34:37.119
<v Speaker 2>If you look at what some of the basic gems

649
00:34:37.119 --> 00:34:40.119
<v Speaker 2>that offer, it often comes down to a limit offset,

650
00:34:40.519 --> 00:34:43.920
<v Speaker 2>which is also really fine on small data sets, but

651
00:34:44.000 --> 00:34:46.000
<v Speaker 2>as you get too data sets that are really really

652
00:34:46.079 --> 00:34:49.400
<v Speaker 2>large and you're going to page really deep into them,

653
00:34:49.760 --> 00:34:52.119
<v Speaker 2>it actually starts really falling apart and breaking down and

654
00:34:52.239 --> 00:34:53.920
<v Speaker 2>things that you might not know until you actually just

655
00:34:54.000 --> 00:34:58.199
<v Speaker 2>hit that scale. I think the some of the RAILS

656
00:34:58.239 --> 00:35:03.519
<v Speaker 2>conventions also starts becoming a little bit problematic, and you

657
00:35:03.519 --> 00:35:05.280
<v Speaker 2>see a little bit of discussion about this. You know,

658
00:35:05.360 --> 00:35:07.280
<v Speaker 2>Rails at one point said throw all the logic into

659
00:35:07.280 --> 00:35:10.400
<v Speaker 2>the controller, and then eventually the controllers became skinny and

660
00:35:10.440 --> 00:35:13.639
<v Speaker 2>all the models became really fat. And I'm sure everyone

661
00:35:13.760 --> 00:35:16.039
<v Speaker 2>has that god object that exists in their project, the

662
00:35:16.199 --> 00:35:19.239
<v Speaker 2>user object or the account object that is five thousand

663
00:35:19.320 --> 00:35:23.599
<v Speaker 2>lines and really difficult to reason about. And people are

664
00:35:23.880 --> 00:35:27.920
<v Speaker 2>offering opinions of having like service classes or various different

665
00:35:27.920 --> 00:35:31.119
<v Speaker 2>patterns to try to combat that. But we're still trying

666
00:35:31.119 --> 00:35:33.960
<v Speaker 2>to unpack some of the things that you started to

667
00:35:34.039 --> 00:35:35.119
<v Speaker 2>RAILS projects with.

668
00:35:35.360 --> 00:35:38.639
<v Speaker 4>One question on that as far as how you've seen

669
00:35:38.920 --> 00:35:42.079
<v Speaker 4>and the progression of the companies you've worked at, have

670
00:35:42.920 --> 00:35:47.679
<v Speaker 4>documentation right, Like, on the one hand we've just talked about,

671
00:35:47.840 --> 00:35:50.000
<v Speaker 4>you can use cops, you can use linters and say

672
00:35:50.079 --> 00:35:55.280
<v Speaker 4>go out and try things, break things, autocorrect things, experiment basically,

673
00:35:55.840 --> 00:35:59.480
<v Speaker 4>then there's self documentation making sure you're writing good method names,

674
00:35:59.480 --> 00:36:03.559
<v Speaker 4>good class names that are intuitive, and then there's inline documentation,

675
00:36:04.079 --> 00:36:08.039
<v Speaker 4>and then there's high level documentation of hey, we're using

676
00:36:08.039 --> 00:36:12.199
<v Speaker 4>this set some conventions and everything else. This is a

677
00:36:12.199 --> 00:36:15.599
<v Speaker 4>big question, but what what do you think is the

678
00:36:15.679 --> 00:36:18.199
<v Speaker 4>right thing to put in each of those buckets in

679
00:36:18.320 --> 00:36:22.079
<v Speaker 4>order to make an intuitive project that scales across you know,

680
00:36:22.280 --> 00:36:25.039
<v Speaker 4>more than twenty developers up to one hundred developers.

681
00:36:25.360 --> 00:36:27.719
<v Speaker 2>Yeah, and you know, here's a little bit of like

682
00:36:27.760 --> 00:36:29.400
<v Speaker 2>my kind of thoughts from it. But I'm not going

683
00:36:29.480 --> 00:36:31.519
<v Speaker 2>to say, like my thoughts here are perfect. I think

684
00:36:31.559 --> 00:36:34.440
<v Speaker 2>everyone's mile edge will vary because documentation is a tricky thing.

685
00:36:34.639 --> 00:36:37.559
<v Speaker 2>So when you get to if you're getting to like

686
00:36:38.239 --> 00:36:40.639
<v Speaker 2>gotcha's like if you ever tell someone like, oh, if

687
00:36:40.679 --> 00:36:43.320
<v Speaker 2>you see this pattern, don't do it like this is

688
00:36:43.400 --> 00:36:45.440
<v Speaker 2>like if you have code reviews that like, oh, I've

689
00:36:45.480 --> 00:36:47.800
<v Speaker 2>been bitten by this before, that should be something that

690
00:36:47.840 --> 00:36:51.039
<v Speaker 2>falls into like the linting or the like the just

691
00:36:51.079 --> 00:36:53.960
<v Speaker 2>and time education where you try to codify that. If

692
00:36:54.000 --> 00:36:58.480
<v Speaker 2>you see people that have inline comments and code that says,

693
00:36:58.480 --> 00:37:00.599
<v Speaker 2>you know, like this next few lines are going to

694
00:37:00.760 --> 00:37:04.199
<v Speaker 2>iterate over something and do these operations, that's probably an

695
00:37:04.239 --> 00:37:07.280
<v Speaker 2>indication that their code is not written well to describe it,

696
00:37:07.320 --> 00:37:10.440
<v Speaker 2>and that comment is not super valuable, so that actually

697
00:37:10.480 --> 00:37:13.880
<v Speaker 2>it might be something like that comment shouldn't exist, and

698
00:37:14.039 --> 00:37:16.400
<v Speaker 2>instead we should maybe extract a method that describes it

699
00:37:16.440 --> 00:37:19.320
<v Speaker 2>better and kind of move in the direction of code

700
00:37:19.360 --> 00:37:24.119
<v Speaker 2>describing itself. When you are implementing something that's specifically tied

701
00:37:24.199 --> 00:37:27.199
<v Speaker 2>to code, it should probably exist at the code level.

702
00:37:27.320 --> 00:37:30.440
<v Speaker 2>So if you are if you have like a module

703
00:37:30.480 --> 00:37:33.159
<v Speaker 2>that you want things to include, and someone developers need

704
00:37:33.199 --> 00:37:36.320
<v Speaker 2>to implement certain methods in there, maybe the module should

705
00:37:36.760 --> 00:37:39.400
<v Speaker 2>define those methods and raise like a not implemented error

706
00:37:39.679 --> 00:37:41.800
<v Speaker 2>that have a very clear this is what this method

707
00:37:41.800 --> 00:37:43.880
<v Speaker 2>should do, this is what it should return. Here are

708
00:37:43.880 --> 00:37:46.480
<v Speaker 2>some examples, and just link to them in your own codebase.

709
00:37:46.960 --> 00:37:49.880
<v Speaker 2>And so now when a developer looks at that specific

710
00:37:49.880 --> 00:37:53.159
<v Speaker 2>piece of code, it's still tied to the codebase. But

711
00:37:53.480 --> 00:37:55.639
<v Speaker 2>all of that's, you know, at the code based level.

712
00:37:55.679 --> 00:37:58.400
<v Speaker 2>There still needs to be something at like a higher

713
00:37:58.519 --> 00:38:02.320
<v Speaker 2>level that's like a read me in the documentation or

714
00:38:02.639 --> 00:38:06.800
<v Speaker 2>in something else entirely, So we have stuff that exists

715
00:38:06.800 --> 00:38:08.960
<v Speaker 2>and read me that's kind of more about like process,

716
00:38:09.000 --> 00:38:13.000
<v Speaker 2>but process is specifically related to our code based So

717
00:38:13.840 --> 00:38:15.800
<v Speaker 2>a good example of this would be how do you

718
00:38:15.880 --> 00:38:19.320
<v Speaker 2>do this these asynchronous migrations? So like this isn't really

719
00:38:19.559 --> 00:38:22.039
<v Speaker 2>super tied to code, because you might make a migration,

720
00:38:22.119 --> 00:38:24.880
<v Speaker 2>but then what's the process for getting that live? So

721
00:38:25.119 --> 00:38:28.320
<v Speaker 2>we have a like a step by step guide to

722
00:38:28.400 --> 00:38:30.880
<v Speaker 2>be for ra clio. If you want to do a migration,

723
00:38:31.239 --> 00:38:33.639
<v Speaker 2>here are the steps that you need to take, and

724
00:38:33.960 --> 00:38:35.679
<v Speaker 2>as much as we can, we just link back to

725
00:38:35.719 --> 00:38:38.320
<v Speaker 2>code rather than re implement the code. But we'll also

726
00:38:38.400 --> 00:38:41.559
<v Speaker 2>just describe things in English and offer templates there and

727
00:38:41.559 --> 00:38:44.679
<v Speaker 2>then we go one level higher to things that exist

728
00:38:44.800 --> 00:38:47.440
<v Speaker 2>more at like a process level for the organization. So

729
00:38:47.480 --> 00:38:50.239
<v Speaker 2>for that we use a tool called Confluence. There's lots

730
00:38:50.280 --> 00:38:53.039
<v Speaker 2>of tools that exist that kind of do similar things,

731
00:38:53.400 --> 00:38:56.360
<v Speaker 2>but for those that's that's things that exist outside of

732
00:38:56.360 --> 00:38:58.880
<v Speaker 2>the code based So if an incident happened, how do

733
00:38:58.960 --> 00:39:02.000
<v Speaker 2>you do a post or would cause analysis on that

734
00:39:02.079 --> 00:39:05.440
<v Speaker 2>and there'll be documents for that. Or you know, if

735
00:39:05.480 --> 00:39:09.119
<v Speaker 2>you wanted to propose a new style of a new

736
00:39:09.119 --> 00:39:10.960
<v Speaker 2>feature that you wanted to get some buy in using

737
00:39:11.079 --> 00:39:13.599
<v Speaker 2>some new architecture, just wanted to make sure that the

738
00:39:13.599 --> 00:39:16.119
<v Speaker 2>approach is correct, you can do like a design doc

739
00:39:16.199 --> 00:39:19.000
<v Speaker 2>in this confluence and get people kind of bought in

740
00:39:19.199 --> 00:39:21.320
<v Speaker 2>well before you've actually written the code. But once the

741
00:39:21.320 --> 00:39:24.079
<v Speaker 2>code is written, that document is less relevant.

742
00:39:24.440 --> 00:39:28.199
<v Speaker 4>Absolutely. I was kind of going from the standpoint of,

743
00:39:28.519 --> 00:39:30.719
<v Speaker 4>like we were talking about bringing a new developer in

744
00:39:30.800 --> 00:39:33.000
<v Speaker 4>and getting them used to the whole environment, and you've

745
00:39:33.039 --> 00:39:35.480
<v Speaker 4>definitely tackled some of that in terms of, you know,

746
00:39:35.559 --> 00:39:39.639
<v Speaker 4>here's the process migration example there. What about just getting

747
00:39:39.639 --> 00:39:43.119
<v Speaker 4>them used to the entire structure of your application where

748
00:39:43.159 --> 00:39:47.400
<v Speaker 4>certain logics live, certain design paradigms that you've talked about.

749
00:39:47.639 --> 00:39:50.480
<v Speaker 4>Some of those can be encapsulated in lnters, but some

750
00:39:50.559 --> 00:39:53.840
<v Speaker 4>of them are larger than winters, And so is that

751
00:39:53.880 --> 00:39:57.360
<v Speaker 4>when you're doing the specific guide for walking them through

752
00:39:57.400 --> 00:39:58.079
<v Speaker 4>that process.

753
00:39:58.960 --> 00:40:01.320
<v Speaker 2>Yeah, so then there's definite things that lenders aren't going

754
00:40:01.360 --> 00:40:03.320
<v Speaker 2>to be able to do, Like linder won't be able

755
00:40:03.360 --> 00:40:06.000
<v Speaker 2>to tell whether this thing should be a model or

756
00:40:06.000 --> 00:40:08.679
<v Speaker 2>a service class or something. Right, it's not really going

757
00:40:08.719 --> 00:40:10.719
<v Speaker 2>to be able to it doesn't understand the business logic

758
00:40:10.760 --> 00:40:13.599
<v Speaker 2>of it. So for things like that that we kind

759
00:40:13.599 --> 00:40:15.760
<v Speaker 2>of have to rely on like little handbooks of being

760
00:40:15.800 --> 00:40:18.360
<v Speaker 2>Like here, like we've code fight, our style guide. We

761
00:40:18.440 --> 00:40:20.519
<v Speaker 2>try to make sure that we keep that up to date.

762
00:40:20.880 --> 00:40:23.880
<v Speaker 2>There are some things that we still teach through kind

763
00:40:23.920 --> 00:40:26.679
<v Speaker 2>of tribal knowledge and code reviews, like if some smits

764
00:40:26.719 --> 00:40:29.519
<v Speaker 2>a pull request and we notice it, we'll still correct

765
00:40:29.519 --> 00:40:31.639
<v Speaker 2>it there and we'll do a lot of pairing, so

766
00:40:31.960 --> 00:40:34.480
<v Speaker 2>we'll get developers up to speed by working with people

767
00:40:34.800 --> 00:40:36.840
<v Speaker 2>as supposed to just going off on their own. But

768
00:40:36.880 --> 00:40:38.800
<v Speaker 2>I think this is just a learning process. Like we

769
00:40:39.119 --> 00:40:41.639
<v Speaker 2>I don't think we are perfect at getting developers onboarded,

770
00:40:41.800 --> 00:40:43.960
<v Speaker 2>and I don't think anyone is. And I think that's

771
00:40:44.159 --> 00:40:46.519
<v Speaker 2>the important distinction that you just it's an iterative process.

772
00:40:46.599 --> 00:40:48.760
<v Speaker 2>Is if you if you bring in three developers and

773
00:40:48.760 --> 00:40:51.400
<v Speaker 2>they all have the same issue, that's probably when you

774
00:40:51.480 --> 00:40:55.079
<v Speaker 2>might need to introduce some new documentation and be like, hey,

775
00:40:55.159 --> 00:40:58.039
<v Speaker 2>here's our new developer handbook. You might want to read it.

776
00:40:58.559 --> 00:41:01.239
<v Speaker 4>And then that absolutely and you've been on top of that.

777
00:41:01.280 --> 00:41:04.719
<v Speaker 4>You have personalities too, and you know certain people gravitate

778
00:41:04.760 --> 00:41:08.400
<v Speaker 4>towards certain things. How what's your methods to when you

779
00:41:08.480 --> 00:41:11.840
<v Speaker 4>have what I would consider external documentation, whether that's living

780
00:41:11.880 --> 00:41:14.960
<v Speaker 4>and or read me. It's not in a Ruby file

781
00:41:15.119 --> 00:41:18.920
<v Speaker 4>or an HTML file or something like that. How do

782
00:41:18.960 --> 00:41:21.760
<v Speaker 4>you guys have any triggers in order to Hey, if

783
00:41:21.800 --> 00:41:24.480
<v Speaker 4>something happens over here and we decide on a new paradigm,

784
00:41:24.760 --> 00:41:28.599
<v Speaker 4>make sure you go update that guide documentation or is

785
00:41:28.639 --> 00:41:31.280
<v Speaker 4>it oh, just like we brought a new person in

786
00:41:31.480 --> 00:41:36.000
<v Speaker 4>and we've got this new convention that's not documented. Oh geez,

787
00:41:36.039 --> 00:41:38.719
<v Speaker 4>we got to go update that documentation. And it's kind

788
00:41:38.719 --> 00:41:42.559
<v Speaker 4>of a only when you discover it type of issue.

789
00:41:42.760 --> 00:41:45.840
<v Speaker 2>So I think the answer is both. I definitely think

790
00:41:45.840 --> 00:41:48.880
<v Speaker 2>we still have places where our documentation drifts and then

791
00:41:48.920 --> 00:41:50.920
<v Speaker 2>somebody notices and we're like, oh shit, we got we

792
00:41:50.920 --> 00:41:54.320
<v Speaker 2>gotta fix that. But we also do leverage tools like

793
00:41:54.639 --> 00:41:58.000
<v Speaker 2>danger danger GSS, like GitHub where it can look at

794
00:41:58.079 --> 00:42:00.440
<v Speaker 2>code and it's not necessarily like a linter of basically

795
00:42:00.519 --> 00:42:02.639
<v Speaker 2>saying like hey, this is bad, but it can make

796
00:42:02.679 --> 00:42:05.320
<v Speaker 2>a comment of being like, hey, you're doing something maybe

797
00:42:05.360 --> 00:42:08.119
<v Speaker 2>this is related to this this link over here, and

798
00:42:08.320 --> 00:42:11.360
<v Speaker 2>direct developers or whoever's reviewing to go take a look

799
00:42:11.360 --> 00:42:14.559
<v Speaker 2>at the documentation. Maybe there's no changes that require there.

800
00:42:14.559 --> 00:42:16.239
<v Speaker 2>And we definitely need to be careful about how much

801
00:42:16.280 --> 00:42:19.000
<v Speaker 2>noise we generate. But you know, if in the case

802
00:42:19.000 --> 00:42:21.800
<v Speaker 2>of like a migration, if a developer writes some on

803
00:42:21.920 --> 00:42:24.360
<v Speaker 2>migration and then submits it, we could basically say, hey,

804
00:42:24.360 --> 00:42:25.800
<v Speaker 2>did you add a new file to like the dB

805
00:42:25.880 --> 00:42:28.559
<v Speaker 2>migrate file. If so, like make sure you're following the

806
00:42:28.599 --> 00:42:31.239
<v Speaker 2>gut steps in here and make sure that it aligns

807
00:42:31.320 --> 00:42:33.760
<v Speaker 2>and kind of point them back at the documentation, both

808
00:42:33.760 --> 00:42:35.719
<v Speaker 2>for the writer of the pull request but the reader

809
00:42:35.800 --> 00:42:38.760
<v Speaker 2>and then kind of helps make sure that things stay

810
00:42:38.760 --> 00:42:41.039
<v Speaker 2>in sync. Not a perfect process. I think we're just

811
00:42:41.079 --> 00:42:43.880
<v Speaker 2>we're slowly getting better at making sure that documentation stays

812
00:42:44.159 --> 00:42:44.599
<v Speaker 2>up to date.

813
00:42:45.039 --> 00:42:49.000
<v Speaker 4>Yeah, that's always the painful part. Those are great insights.

814
00:42:49.400 --> 00:42:52.559
<v Speaker 3>What do you think about DHHH? Guy, it's a Weirdosney

815
00:42:54.559 --> 00:42:58.400
<v Speaker 3>I was, I was. It did denounce that just me. No,

816
00:42:58.480 --> 00:43:00.880
<v Speaker 3>I love DHH. She did a book of quite a

817
00:43:00.880 --> 00:43:04.679
<v Speaker 3>few years ago Could Rework, which was prophetic really in

818
00:43:04.719 --> 00:43:10.480
<v Speaker 3>the current situation about working from home. He did a

819
00:43:10.639 --> 00:43:13.320
<v Speaker 3>Rails comp you know, I think it was a couple

820
00:43:13.360 --> 00:43:17.159
<v Speaker 3>of years ago where he said that at base Camp

821
00:43:17.239 --> 00:43:21.679
<v Speaker 3>they have never had a DBA, so they've never employed

822
00:43:21.800 --> 00:43:25.960
<v Speaker 3>a person whose job it was to administer the database.

823
00:43:26.079 --> 00:43:29.840
<v Speaker 3>This is something which Rails has just just magically scaled

824
00:43:29.920 --> 00:43:33.480
<v Speaker 3>up and the database is scaled up. Do you are

825
00:43:33.480 --> 00:43:36.639
<v Speaker 3>you in the same situation? Have you never employed a

826
00:43:37.000 --> 00:43:40.719
<v Speaker 3>DBA for your very large Rails database?

827
00:43:41.119 --> 00:43:43.480
<v Speaker 2>Yeah, actually we are in the same situation. I believe

828
00:43:43.559 --> 00:43:46.039
<v Speaker 2>we I think we were going to hire a DBA

829
00:43:46.360 --> 00:43:48.840
<v Speaker 2>this year prior to the pandemic, and then I think

830
00:43:48.840 --> 00:43:51.800
<v Speaker 2>there were some complications. But prior to that, the company

831
00:43:51.880 --> 00:43:54.559
<v Speaker 2>has been operating for over eleven years, and I think

832
00:43:54.559 --> 00:43:58.039
<v Speaker 2>now no DBA, we definitely have some DevOps that are

833
00:43:59.360 --> 00:44:01.760
<v Speaker 2>a little bit like focused on making sure that the

834
00:44:02.400 --> 00:44:06.079
<v Speaker 2>database is running and making sure that you know, we've

835
00:44:06.119 --> 00:44:08.880
<v Speaker 2>got replications set up and proper statistics. But we kind

836
00:44:08.880 --> 00:44:11.280
<v Speaker 2>of put the onus on everyone, like you don't have

837
00:44:11.320 --> 00:44:15.679
<v Speaker 2>one person who is the guru of SQL, you have everyone,

838
00:44:15.960 --> 00:44:19.559
<v Speaker 2>and so everyone tries to teach everyone these things and

839
00:44:19.679 --> 00:44:22.400
<v Speaker 2>we try to do our best to share that knowledge

840
00:44:22.400 --> 00:44:25.119
<v Speaker 2>where we can to make everyone as experts as we can.

841
00:44:25.599 --> 00:44:28.599
<v Speaker 2>So we've managed to go, you know, eleven years with

842
00:44:28.679 --> 00:44:31.719
<v Speaker 2>no DBA, and I think we're only getting to wanting

843
00:44:31.800 --> 00:44:34.280
<v Speaker 2>one now because we're trying to do like really customized

844
00:44:34.320 --> 00:44:37.559
<v Speaker 2>processes of how do we you know, this online schema

845
00:44:37.639 --> 00:44:41.280
<v Speaker 2>migration stuff, how do we make that completely automated, which

846
00:44:41.360 --> 00:44:44.559
<v Speaker 2>is actually going to be a completely distinct system to

847
00:44:44.639 --> 00:44:46.480
<v Speaker 2>the rail system, because we're going to want to apply

848
00:44:46.480 --> 00:44:49.079
<v Speaker 2>it to any of our projects, or maybe some gotchaes

849
00:44:49.199 --> 00:44:53.199
<v Speaker 2>between like upgrading my sequel there's probably some things that

850
00:44:53.280 --> 00:44:56.599
<v Speaker 2>they might actually have really good insight into. But I

851
00:44:56.599 --> 00:44:59.199
<v Speaker 2>think our general approach is, even in that situation, we're

852
00:44:59.199 --> 00:45:02.320
<v Speaker 2>going to have one DBA and hundreds of developers, and

853
00:45:02.400 --> 00:45:04.079
<v Speaker 2>we want to make sure that, you know, they may

854
00:45:04.480 --> 00:45:08.199
<v Speaker 2>have knowledge and might be useful for talking through things

855
00:45:08.199 --> 00:45:10.000
<v Speaker 2>and sharing things, but the work it's going to still

856
00:45:10.039 --> 00:45:12.679
<v Speaker 2>fall in with the developers, and you know, I mean

857
00:45:12.760 --> 00:45:15.800
<v Speaker 2>to make sure that everyone is learning as much as

858
00:45:15.800 --> 00:45:19.800
<v Speaker 2>they can and not just blindly hoping that the DBA

859
00:45:19.920 --> 00:45:20.599
<v Speaker 2>is going to handle it.

860
00:45:20.880 --> 00:45:25.440
<v Speaker 3>Yeah, I mean it's the way. The way if DH

861
00:45:25.599 --> 00:45:28.480
<v Speaker 3>presented it, it was kind of this is this is

862
00:45:28.519 --> 00:45:32.320
<v Speaker 3>a necessary evil mind was to have a database specialist

863
00:45:32.440 --> 00:45:36.719
<v Speaker 3>this instead who rails enables developers to kind of handle

864
00:45:36.760 --> 00:45:40.840
<v Speaker 3>this themselves and not just kind of blame the database

865
00:45:40.920 --> 00:45:45.000
<v Speaker 3>man or woman when the when the thing goes wrong.

866
00:45:45.559 --> 00:45:49.639
<v Speaker 3>Surely as a company gets bigger, you have more specialized

867
00:45:49.760 --> 00:45:52.599
<v Speaker 3>roles and not less specialized roles.

868
00:45:52.760 --> 00:45:54.800
<v Speaker 2>Yeah, I would agree, and I think there are more

869
00:45:54.800 --> 00:45:57.719
<v Speaker 2>specialized roles, but I think there are skills that apply

870
00:45:57.880 --> 00:46:01.199
<v Speaker 2>to everyone. So you know, as the company grows, you

871
00:46:01.239 --> 00:46:03.960
<v Speaker 2>may have more specialized roles that have more specific knowledge.

872
00:46:04.079 --> 00:46:07.079
<v Speaker 2>But I think probably with that specific knowledge comes the

873
00:46:07.119 --> 00:46:10.599
<v Speaker 2>responsibility that they are not gatekeepers of that knowledge, right

874
00:46:10.719 --> 00:46:13.920
<v Speaker 2>they They may be experts and they're maybe building content,

875
00:46:14.440 --> 00:46:16.079
<v Speaker 2>but I would say part of their job is to

876
00:46:16.119 --> 00:46:19.960
<v Speaker 2>make sure that it's that content is consumable by everyone.

877
00:46:20.079 --> 00:46:23.480
<v Speaker 2>And you know, if they're answering the same questions over

878
00:46:23.559 --> 00:46:26.079
<v Speaker 2>and over and over, they're not doing their job to

879
00:46:26.400 --> 00:46:30.440
<v Speaker 2>educate people on how to self serve and do it themselves.

880
00:46:30.880 --> 00:46:32.840
<v Speaker 2>And that's how we learn and grow as a community

881
00:46:32.960 --> 00:46:35.760
<v Speaker 2>and get better is just by sharing this knowledge.

882
00:46:36.119 --> 00:46:40.320
<v Speaker 3>It's a it's a really quite an interesting situation. I

883
00:46:40.360 --> 00:46:43.239
<v Speaker 3>don't know what it means for the DBAs, but I

884
00:46:43.280 --> 00:46:47.079
<v Speaker 3>think there's there's definitely more database work out there. But

885
00:46:47.440 --> 00:46:50.599
<v Speaker 3>I think because RAILS just makes it so easy to

886
00:46:50.760 --> 00:46:54.360
<v Speaker 3>work with databases at scale, that you kind of tend

887
00:46:54.400 --> 00:46:57.320
<v Speaker 3>to hit hit that stage much much later on.

888
00:46:57.920 --> 00:47:00.880
<v Speaker 2>Yeah, I agree, you don't necessarily have to have everyone

889
00:47:00.920 --> 00:47:04.440
<v Speaker 2>customly building SQL like Active record does a pretty good

890
00:47:04.519 --> 00:47:07.960
<v Speaker 2>job of being an RM that let's developers just do

891
00:47:08.239 --> 00:47:11.440
<v Speaker 2>the things they need to do. And you know, there's

892
00:47:11.639 --> 00:47:15.679
<v Speaker 2>data notifications available to easily add tooling that you don't

893
00:47:15.679 --> 00:47:18.360
<v Speaker 2>need the DBA for. But you know, as things grow.

894
00:47:18.440 --> 00:47:21.039
<v Speaker 2>There's things that RAILS doesn't yet have tooling, and maybe

895
00:47:21.039 --> 00:47:24.000
<v Speaker 2>that's something that like if you have a DBA who

896
00:47:24.280 --> 00:47:26.760
<v Speaker 2>is well versed in RAILS, like maybe they can contribute

897
00:47:26.800 --> 00:47:30.079
<v Speaker 2>back to the framework or at their own gems that

898
00:47:31.000 --> 00:47:35.480
<v Speaker 2>can help everybody get better at working with databases. And

899
00:47:35.840 --> 00:47:38.800
<v Speaker 2>you know, it doesn't necessarily invalidate their job, but their

900
00:47:38.880 --> 00:47:41.599
<v Speaker 2>job becomes more of a knowledge producer and they try

901
00:47:41.639 --> 00:47:44.960
<v Speaker 2>to share that knowledge and make the community better.

902
00:47:45.360 --> 00:47:47.719
<v Speaker 4>Yeah, we're in the same boat. We like to push

903
00:47:47.800 --> 00:47:50.400
<v Speaker 4>that knowledge down as far as possible, but there certainly

904
00:47:50.440 --> 00:47:54.320
<v Speaker 4>are opportunities when you're deep in the materialized viewsed and

905
00:47:54.400 --> 00:47:57.480
<v Speaker 4>windowing and postgraphs or something like that, where you're just like,

906
00:47:57.559 --> 00:48:00.440
<v Speaker 4>I really want to phone a phone, a deba friend.

907
00:48:00.880 --> 00:48:03.960
<v Speaker 4>And that's the conside I would suppose, Yeah, And.

908
00:48:04.000 --> 00:48:07.199
<v Speaker 2>I think that's that's like the roles of the specialists,

909
00:48:07.239 --> 00:48:09.920
<v Speaker 2>the people who have the specialized knowledge, they're probably more consultants.

910
00:48:10.320 --> 00:48:12.519
<v Speaker 2>And you know, you have someone who's like, I've got

911
00:48:12.519 --> 00:48:15.159
<v Speaker 2>a really gnarly problem. I don't know what to do. Yeah,

912
00:48:15.199 --> 00:48:17.400
<v Speaker 2>like get them to like sit down and help with you.

913
00:48:17.440 --> 00:48:19.599
<v Speaker 2>And that's a big asset that they can help with

914
00:48:19.639 --> 00:48:21.559
<v Speaker 2>people and you know, if that's a one off, it's

915
00:48:21.559 --> 00:48:23.920
<v Speaker 2>a one off. But if they do this ten times

916
00:48:23.920 --> 00:48:26.840
<v Speaker 2>in a week, maybe there's education there, or maybe there's

917
00:48:26.840 --> 00:48:29.079
<v Speaker 2>two ling. And I think it goes to pretty much

918
00:48:29.079 --> 00:48:31.480
<v Speaker 2>any role that you ever feel like you're just throwing

919
00:48:31.480 --> 00:48:35.239
<v Speaker 2>something over the fence. If you push that responsibility also

920
00:48:35.320 --> 00:48:37.400
<v Speaker 2>to the developers, you can also end up with a

921
00:48:37.480 --> 00:48:38.800
<v Speaker 2>much higher quality project.

922
00:48:39.119 --> 00:48:42.679
<v Speaker 4>Kids them how to use includes and avoid some of

923
00:48:42.679 --> 00:48:46.199
<v Speaker 4>those massive queries and plus one problems.

924
00:48:46.079 --> 00:48:49.480
<v Speaker 2>Or use some of the gems available and have the

925
00:48:49.719 --> 00:48:52.840
<v Speaker 2>n plus one queries just automatically avoided for you. You bet.

926
00:48:53.719 --> 00:48:58.079
<v Speaker 1>Yeah, I've had some include statements which spend fifty lines

927
00:48:58.440 --> 00:49:02.119
<v Speaker 1>on some projects that inherited. Its insane the kind of

928
00:49:02.199 --> 00:49:06.079
<v Speaker 1>data that they're trying to return, But yeah, it's crazy

929
00:49:06.400 --> 00:49:07.039
<v Speaker 1>good advice.

930
00:49:07.559 --> 00:49:09.079
<v Speaker 2>One also, is anything else.

931
00:49:09.320 --> 00:49:11.920
<v Speaker 1>That we want to talk about. I know we're getting

932
00:49:12.280 --> 00:49:13.360
<v Speaker 1>at about that time.

933
00:49:13.840 --> 00:49:15.760
<v Speaker 2>I'm just going to mention one thing about includes, because

934
00:49:16.039 --> 00:49:19.719
<v Speaker 2>I think this is a another gotcha of RAILS is

935
00:49:19.719 --> 00:49:21.880
<v Speaker 2>they don't really teach you what happens with includes and

936
00:49:22.159 --> 00:49:24.880
<v Speaker 2>includes as actually does two things in the backgrounds. It

937
00:49:24.920 --> 00:49:28.119
<v Speaker 2>either uses a preload or an eager load, and a

938
00:49:28.480 --> 00:49:31.760
<v Speaker 2>preload splits it off into a different query entirely, where

939
00:49:31.760 --> 00:49:34.079
<v Speaker 2>you do something like select star from table where id's

940
00:49:34.159 --> 00:49:36.960
<v Speaker 2>in this big list. But then there's eger load, which

941
00:49:37.079 --> 00:49:40.079
<v Speaker 2>tries to smosh it into one big query. This is

942
00:49:40.199 --> 00:49:44.119
<v Speaker 2>something where Rails always suggest using includes because it'll handle

943
00:49:44.159 --> 00:49:47.000
<v Speaker 2>that distinction for you. But that distinction actually makes a

944
00:49:47.000 --> 00:49:51.400
<v Speaker 2>difference at scale, and when you're dealing with large tables,

945
00:49:51.639 --> 00:49:57.280
<v Speaker 2>eager load is almost always worse significantly, and so it's

946
00:49:57.280 --> 00:49:59.159
<v Speaker 2>almost all the time you actually want to use preload,

947
00:49:59.800 --> 00:50:02.440
<v Speaker 2>same interface, but it's just this interesting little goatcha that

948
00:50:02.480 --> 00:50:05.400
<v Speaker 2>you don't really realize until it starts biting you.

949
00:50:05.800 --> 00:50:08.159
<v Speaker 4>And you got to remember everything is just a tool,

950
00:50:08.519 --> 00:50:11.119
<v Speaker 4>and you can either smash your finger with that hammer

951
00:50:11.239 --> 00:50:13.559
<v Speaker 4>or you can build what you want to build with it.

952
00:50:15.440 --> 00:50:16.840
<v Speaker 2>Exactly great, Kyle.

953
00:50:17.039 --> 00:50:19.840
<v Speaker 1>If people want to follow you and some of the

954
00:50:19.880 --> 00:50:21.760
<v Speaker 1>stuff that you're doing online, where should they go.

955
00:50:22.400 --> 00:50:24.960
<v Speaker 2>I don't really have a huge online presence. I do

956
00:50:25.079 --> 00:50:28.199
<v Speaker 2>have a GitHub account, but that's mostly working on like

957
00:50:28.599 --> 00:50:31.159
<v Speaker 2>either public gems for the company. But what I'm trying

958
00:50:31.199 --> 00:50:34.039
<v Speaker 2>to do is be a little bit more present in

959
00:50:34.159 --> 00:50:36.639
<v Speaker 2>the community. So I do have some talks available at

960
00:50:36.800 --> 00:50:39.599
<v Speaker 2>rails cof and I will like my goal is to

961
00:50:39.760 --> 00:50:42.480
<v Speaker 2>be pushing out a little bit more written content which

962
00:50:42.639 --> 00:50:46.719
<v Speaker 2>is available at like the blogs that Cleo provides, so

963
00:50:46.960 --> 00:50:48.920
<v Speaker 2>I can provide a link for that in the future,

964
00:50:49.039 --> 00:50:51.159
<v Speaker 2>as well as a link to any of the talks

965
00:50:51.199 --> 00:50:54.719
<v Speaker 2>that I have. But unfortunately I'm not a super user

966
00:50:54.760 --> 00:50:57.920
<v Speaker 2>on Twitter, but I can also provide my LinkedIn where

967
00:50:57.960 --> 00:51:00.119
<v Speaker 2>I sometimes post new introgeration there as well.

968
00:51:00.480 --> 00:51:04.239
<v Speaker 1>Awesome, Well, I'm going to move us over to some picks. Looke,

969
00:51:04.280 --> 00:51:05.480
<v Speaker 1>do you want to start us off?

970
00:51:05.880 --> 00:51:10.400
<v Speaker 3>Yeah, listen, listen to this. Listen to this. Can you

971
00:51:10.440 --> 00:51:10.719
<v Speaker 3>hear that?

972
00:51:12.760 --> 00:51:14.679
<v Speaker 2>I can't hear anything that.

973
00:51:14.679 --> 00:51:18.719
<v Speaker 3>That is the sound of me signing up for Drifting

974
00:51:18.840 --> 00:51:22.440
<v Speaker 3>Ruby dot com, which is a quite excellent a series

975
00:51:22.480 --> 00:51:27.719
<v Speaker 3>of rails gusts, including the accident from jQuery to ES

976
00:51:27.880 --> 00:51:33.119
<v Speaker 3>six episode. I am a notorious jQuery user, almost an

977
00:51:33.199 --> 00:51:36.880
<v Speaker 3>unrepentant one, but Drifting Ruby has let me see the

978
00:51:36.960 --> 00:51:40.760
<v Speaker 3>light and I'm a newly reformed character. So my pick

979
00:51:41.519 --> 00:51:43.440
<v Speaker 3>is Drifting Ruby dot com.

980
00:51:43.920 --> 00:51:48.039
<v Speaker 1>I must say that's a great pick. So all right, hey, Matt,

981
00:51:48.239 --> 00:51:49.880
<v Speaker 1>you want to chime in with some picks.

982
00:51:50.079 --> 00:51:52.679
<v Speaker 4>Well, my pick comes out of this. I'd say that

983
00:51:52.880 --> 00:51:55.599
<v Speaker 4>danger JS is something that I really want to look into.

984
00:51:55.840 --> 00:52:02.440
<v Speaker 4>We're significantly investing in see I see infrastructure and deploying

985
00:52:02.440 --> 00:52:04.800
<v Speaker 4>those branches like you were talking about, Dave, and so

986
00:52:05.440 --> 00:52:08.320
<v Speaker 4>that looks like a really great way to tie back

987
00:52:08.360 --> 00:52:11.719
<v Speaker 4>to documentation and check the best practices that can form

988
00:52:11.800 --> 00:52:14.239
<v Speaker 4>with the rest of the company. And that's my pick

989
00:52:14.280 --> 00:52:17.920
<v Speaker 4>for today. I'll let you know what I discover awesome.

990
00:52:18.639 --> 00:52:21.159
<v Speaker 1>I'll jump in with a couple of picks. One is

991
00:52:21.199 --> 00:52:24.599
<v Speaker 1>from Google. It is a type in security key. Other

992
00:52:24.719 --> 00:52:29.039
<v Speaker 1>companies have similar products, like the Ubo key. It's a

993
00:52:29.719 --> 00:52:34.239
<v Speaker 1>USB or a NFC key that will do your authentication

994
00:52:34.400 --> 00:52:36.199
<v Speaker 1>for you. So actually, I have a couple of these

995
00:52:36.280 --> 00:52:40.199
<v Speaker 1>arriving in the mail today in preparations for another Drift

996
00:52:40.199 --> 00:52:42.639
<v Speaker 1>and Ruby episode that I want to do on these things.

997
00:52:43.000 --> 00:52:46.480
<v Speaker 1>So that should be a pretty interesting one. I don't

998
00:52:46.519 --> 00:52:49.199
<v Speaker 1>think it's going to have too much popularity because I

999
00:52:49.360 --> 00:52:52.920
<v Speaker 1>never have one of these keys before later today. And

1000
00:52:53.000 --> 00:52:56.000
<v Speaker 1>the other is I have now in front of me

1001
00:52:56.280 --> 00:53:01.360
<v Speaker 1>a little rack of Raspberry p i eight gigabyte of

1002
00:53:01.440 --> 00:53:07.719
<v Speaker 1>rams that I'm building into a tiny Kubernetes cluster for well,

1003
00:53:08.800 --> 00:53:12.800
<v Speaker 1>just because that can really so. I love raspberry pies

1004
00:53:12.840 --> 00:53:16.559
<v Speaker 1>and they just released their eight gigabyte versions, which actually

1005
00:53:16.599 --> 00:53:20.320
<v Speaker 1>banks it nicer to run some heftier things on it now.

1006
00:53:20.920 --> 00:53:24.039
<v Speaker 1>Still slow, but still a lot of fun. All Right, Kyle,

1007
00:53:24.079 --> 00:53:25.719
<v Speaker 1>do you want to join in with some picks.

1008
00:53:26.000 --> 00:53:28.840
<v Speaker 2>I didn't prepare anything, so I actually don't have anything

1009
00:53:28.880 --> 00:53:31.239
<v Speaker 2>that's off the top of my mind here for things

1010
00:53:31.239 --> 00:53:32.119
<v Speaker 2>to just call out.

1011
00:53:32.320 --> 00:53:35.360
<v Speaker 1>All right, fair enough, Well, it was great talking to you, Kyle,

1012
00:53:35.440 --> 00:53:39.079
<v Speaker 1>and I always like talking about technical debt because I

1013
00:53:39.119 --> 00:53:41.199
<v Speaker 1>am notorious for introducing it.

1014
00:53:41.400 --> 00:53:44.199
<v Speaker 2>I'm always happy to like building tools to fix these

1015
00:53:44.199 --> 00:53:46.559
<v Speaker 2>things so that we can make better.

1016
00:53:46.840 --> 00:53:49.599
<v Speaker 1>All right. Well, that's a wrap for this episode. We

1017
00:53:49.639 --> 00:53:52.079
<v Speaker 1>appreciate you coming and talking with us. So it was

1018
00:53:52.599 --> 00:53:53.320
<v Speaker 1>a lot of fun.

1019
00:53:53.639 --> 00:53:56.880
<v Speaker 2>Yeah, it was wonderful. Thank you, Bye, take care.