Dave Kimura

And that could have its own issues if you have thousands of requests per second coming in. So yeah, definitely not a fun problem to solve. And it's also, I guess, good to know what kind of migration or really what kind of SQL functions will cause a table lock. So adding an index or adding a column and stuff can lock your table.

And that could have its own issues if you have thousands of requests per second coming in. So yeah, definitely not a fun problem to solve. And it's also, I guess, good to know what kind of migration or really what kind of SQL functions will cause a table lock. So adding an index or adding a column and stuff can lock your table.

So being aware of what actually is going to lock the table is really good information to know.

So being aware of what actually is going to lock the table is really good information to know.

So that kind of covers the database and schema side of things. To step away from the code, you had mentioned about onboarding people. With a larger client base, what does that process look like for you guys? And how do you really bring a junior or mid-developer into the company and have them productive quickly?

So that kind of covers the database and schema side of things. To step away from the code, you had mentioned about onboarding people. With a larger client base, what does that process look like for you guys? And how do you really bring a junior or mid-developer into the company and have them productive quickly?

Yeah, that's kind of one of my pet peeves, I guess you could say, with linting is that if a particular project has a set of practices it likes to follow, maybe it is no more than 100 characters on a line. That kind of feedback should never happen in a code review. If you have those kind of expectations, then they need to be known expectations via a linter, whether it's RuboCop or standard RB.

Yeah, that's kind of one of my pet peeves, I guess you could say, with linting is that if a particular project has a set of practices it likes to follow, maybe it is no more than 100 characters on a line. That kind of feedback should never happen in a code review. If you have those kind of expectations, then they need to be known expectations via a linter, whether it's RuboCop or standard RB.

And it should never be an unknown expectation to the developer. So I'm definitely on board with that. And that's something that I've had to fight and struggle with is going through code reviews and having everything kind of nitpicked. Because when it decreases the morale of the developer, if every pull request they're making, it's just getting bombarded with styling quirks or requests to change.

And it should never be an unknown expectation to the developer. So I'm definitely on board with that. And that's something that I've had to fight and struggle with is going through code reviews and having everything kind of nitpicked. Because when it decreases the morale of the developer, if every pull request they're making, it's just getting bombarded with styling quirks or requests to change.

So I could definitely... agree with that point. And I think that every project should adopt some kind of linter if there are expectations of what they're doing. Even if you bring in RuboCop, you disable everything by default and then you just start adding in or allowing which exceptions your team follows on that particular project.

So I could definitely... agree with that point. And I think that every project should adopt some kind of linter if there are expectations of what they're doing. Even if you bring in RuboCop, you disable everything by default and then you just start adding in or allowing which exceptions your team follows on that particular project.

Yeah, absolutely. Although you do have to be careful about the auto-correction. I remember one time in my earlier days of development when RubyMind came out, I tried out RubyMind's code refactoring thing. I forget what they call it. But I had some really poorly written classes, and it just absolutely broke everything.

Yeah, absolutely. Although you do have to be careful about the auto-correction. I remember one time in my earlier days of development when RubyMind came out, I tried out RubyMind's code refactoring thing. I forget what they call it. But I had some really poorly written classes, and it just absolutely broke everything.

I have no idea how that happened, but things just were not working the way they were before. I had to pull that merge back out because, of course, as an early developer, I didn't have any tests on the application. So I didn't really notice that things were broken until they got deployed.

I have no idea how that happened, but things just were not working the way they were before. I had to pull that merge back out because, of course, as an early developer, I didn't have any tests on the application. So I didn't really notice that things were broken until they got deployed.

So you also previously mentioned about, so not necessarily onboarding developers, but having a lot of developers work on the project. So what point do you go from a small shop to a large shop where you have to start putting different kinds of practices in place? And what are those kinds of practices when you're dealing with a lot of developers on a single code base?

So you also previously mentioned about, so not necessarily onboarding developers, but having a lot of developers work on the project. So what point do you go from a small shop to a large shop where you have to start putting different kinds of practices in place? And what are those kinds of practices when you're dealing with a lot of developers on a single code base?

Yeah, that's one of the things that I did just for my own hobby project and just continual learning. I have a self-hosted GitLab instance, and I set up a Kubernetes server, which will automatically create the infrastructure for the application that got pushed. So it always happens on any kind of development or master branch push, and then also on each commit.

Yeah, that's one of the things that I did just for my own hobby project and just continual learning. I have a self-hosted GitLab instance, and I set up a Kubernetes server, which will automatically create the infrastructure for the application that got pushed. So it always happens on any kind of development or master branch push, and then also on each commit.