GitLab Backend Pairing, 25 Jul 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: BE Pairing - 20220725 - Simplifying order by and pagination for rails models

Description

In this session we discuss and explore simplifying common "Finder" responsibilities such as ordering and paginating.

A

How do you stay here.

B

C

If you go back to the to the ui most models that use this view and correct me if I'm wrong, uh terry or alexandria or lee, I believe most models that use this view are issuables.

B

C

B

But I don't know is.

C

D

I think we have others as well like. I think we use this searchable thing uh so by models you mean.

C

A

Looks like just alerts and incidents are using this specific component, but I guess there might be a other other implementations of the same um looking ui. If you were.

C

And it is my understanding that incidents are fall under the issuable umbrella, correct the the thing about that is like we to create this reusable behavior. Unfortunately, with like workshop, like we looked at, merge requests issues and all the things that looked you know if you squint your eyes hard enough, it looks like an issue we created this base class issuable and that's how most of the reusable behavior is.

B

C

But now we kind of have this god-based class issuable, which is in charge of way too much, and it has functionality that you can't really extract from it easily or reuse just easily with um this like active inactive counts and the pagination and stuff like that. um So like a base, I mean using inheritance, isn't the best tool for creating the reusable behavior.

C

So it would be really cool if there was a a ruby pattern for us to.

C

Have models that we can quite easily hook into this interface that the graphql glue code would be expecting of needing these? These separate counts and the pagination and all that's all taken care of nicely like.

A

Good, ah so this is, I'm just gonna, add a whole another level of um whatever I want to call it as well, so that that was only half of the problem. I also had to create this nasty thing um for handling the sorting on the back end and again, I feel like this. There must have been a much much easier drier, um reusable way of doing this. So, let's, let's just throw this whole kind of what is life into the mix.

D

I guess there is: there are some ways to kind of um instead of doing all that, just to just define some, how do you call them annotation like things where you just list the things that you want to sort by um and then it will create all of this stuff for you, so yeah.

A

There is something: do you know if we do that anywhere at the moment or.

D

No, I don't think we do that. um Well, we kind of do that, but not for these type of things, but we do it, for instance, to um annotate something as being.

D

Let me think like mentionable so like you would say that the title and the description is something that is mentionable, which means that it will get parsed for any sort of references like um reference to user, to project, to an issue and so on and so forth.

D

So, like you all, you do is say mentionable title right, mentionable description, so you basically can do something similar for like sortable, first name last name, email and so on, and that will create these scopes. For you basically.

A

D

A

Like an interesting um yeah and I'm going to open up one more because I had to do this somewhere else as well, contact saw enum, so I just had to create so much boilerplate.

D

A

D

Yeah that can be, I think we have examples where you just list this in an array and then reuse it in all these places. So then you can iterate through the um basically through the array and not have to write every single line of that.

B

A

I'm wondering if any of these other you know, I I think I was looking at incidents and alerts when I or incidents probably are alerts. I don't know if they're the same thing or different things.

B

Incident you know.

A

Doesn't look like it.

D

Yeah, but I I I kind of see what you're saying, for instance, for pagination right you I think we can have something more implemented like more basic and and did not have to do that for every single um dissolver, because I guess you can generalize that every resolver would want to be paginated anyway. So.

C

Can um can you, can you clarify what the sorts are doing on the model.

A

So, in order to.

C

Like is it does an active record like kind of come up, come out, isn't this stuff out of the box with active record like being able to.

A

Yeah, that's a good good point. So first thing, as I understand it, you shouldn't really. This could be completely wrong. It might be that sorting's, okay in finders in certain places, but I know we've got cops and best practices that say that you should only do certain things in the model, for example, and I think maybe sorting's one of those.

D

Now the scopes need to be so so you cannot do or they're in in the finders and so on. You want it to be defined in one place and that's the model like what becomes kind of tricky. Is you have this organization uh sorting right so now you need to do join, but there is no easy way to know um which ones of this need to have the join and which ones don't need to have to join.

D

So, like you can kind of remove a lot of the boilerplate for the basic attributes, the ones that you have up until the organization right.

A

I would be totally cool with if this had to be some kind of um yeah yeah.

C

Okay yeah, so it's like the potential for like reusability, there's like graphql glue code that I'm just defining the types and the resolvers.

C

I think if you had like a finder that adhered to a common interface that would be interesting like you could just generate you.

B

C

The glue code without having to manually implement it every time, um but then I don't think we have any kind of like like abs, abstract, finder, the right might. The only abstract finder I think we have is, is an issuable finder like this, but that's.

D

The only thing I've seen.

C

And I don't play around the backend code a whole lot, uh but I I don't see what would prevent us having like an abstract finder, and maybe that would be more make more sense than trying to attach like includes or mixing something into the model like keeping all this reusable code in the model. Maybe that's problematic. Maybe we want to have a reusable finder or something like what, if this contacts finder was more abstract, is that.

B

C

D

I I think it's difficult to to have an abstract finder in the sense that you'll you'll want to extend it anyway, like every single model, is so different from everything else right, the the even though it like it feels it does the same thing in like searching through a table. It still has its own attributes, first name last name, which is not in the issue right. So then the abstract model doesn't feel like it will actually do anything.

C

But like across all of the pagination is the same like yeah yeah across.

B

The street I agree.

D

With because, like you can probably paginate by well yes and no.

D

I I agree that pagination is kind of the same. It depends also by how how do you work that or what do you order by right, but I guess that can be extracted in its own specific implementation and then passed on to the imagination. It.

A

Is interesting, I may be misunderstanding sort of where you're headed paul but sort of like looking at this and thinking well. Here I've I've got sort of something which seems a bit um okay, so this is kind of like a validation, that's kind of specific to contacts.

A

But then we grab I'm going to call it like the master list, and then we apply all of the filters and then we apply sorting and conditionally depending on whether we're counting we've then got this. So each of these things does feel like it could be fairly um abstracted to some kind of interface. If that's the right term in ruby, where you know, what's the what's the sorting logic, what's the I mean.

C

A

For curiosity,.

C

Maybe let's just compare against issuable finder or work items finder, or something like that. Just out of curiosity.

B

I would look, but I'm currently doing the one-line install my laptop, so it's it's the new laptop though so it's pretty sweet.

C

And so this is, this is the issuable pattern. I see all the time but you're.

D

C

uh I'm I uh you're contributing because.

B

C

I say something and you look like you're deep in thought. I'm like maybe.

B

I'm learning you're.

C

B

Oh no, no! No! This is yeah. That's.

D

B

I've seen the work items finder, but I.

D

B

In and out of the issues and merged requests and issuables finders, quite a bit.

C

Imagine being in search, you're really really familiar with this um some of these yeah, but.

B

This is, this is what.

C

So first, the this pattern that happened with hp levels is ah just a little frustrating to me because, like we're, this is old old, gitlab code and we're regularly paying off. You know this paying the interest of this technical debt of uh encapsulating this reusable behavior through inheritance uh and issuable is not a really great abstraction as merge requests and issues. You know they may have looked really similar at one point and then they really diverged, and then you have other things like issuables and things get really complex with issuable land.

B

uh Yeah, I've even seen sometimes where there's like front-end stuff, where people are starting to like separate things out and be like very specific about like. Actually, this isn't just issuable. This is only for merge requests and so, like you, just need to remove the whole like remove the.

C

Yeah, it gets weird where it's like we'll have in the front end code. There's things like if issue type equals merge requests like you, get weird weird lines like that. um So this is a very complex finder, obviously, and uh but I do feel like hey, there's, there's need for.

C

We do this pattern a lot and it would be cool if there's a way to encapsulate it. um I think he's I don't know. If there's does ruby support, what you were talking alexandria like having annotations, can, can you do annotations in ruby.

D

Well not like I don't know what you understand by an attention. I I haven't.

C

They're coming from like or something.

D

I have a bit of a java background experience where you do add something and that's considered an annotation. It's.

B

D

I don't know actually maybe.

B

D

Is something like that in ruby as well? But what we do is like, if you open, even issuable rb.

D

um And then look for I yeah like like this, like redact field right. So what this would do is basically would do some stuff on the on the description field, so that we can do something like this within the finders. I would guess where you'd say scope by um like first name uh or order by first name. So, instead of writing the method you'd do this and then you'd have a.

A

D

Seen a helper method that will take this params and just implement basically the benefit for you um yeah. Something like that. I'm not a huge fan of this because um yeah, it kind of hides something.

C

Yeah yeah, that's a good point, it's really indirect like, and it could be it's weird when these annotations, which look like. Oh I don't.

C

I don't really need to test these like the annotation works, but it can cause like catastrophic issues if you get something wrong there, uh that's a that's an interesting point, so the other like approach to like solving boilerplate is generating code and have have you all in the back and never talked about like code generators.

C

I I personally, this is just my personal preference. I feel like generating code, is a pretty it's a red flag that you know as soon as you create a machine to start creating duplicate code.

A

Definitely a red flag. The only thing that immediately springs to mind. um Another community contributors recently made some changes to the. I forget what they're called exactly, but the rails model template generator. So when you do like rails g generate migration, it creates a new model and a little bit of boilerplate around like a migration script and a model and a few bits like that.

A

So yeah I mean when you think about it, is generally speaking when you create a new model you're going to want the model itself, you're going to want a spec for the model you're going to want the migration script, to create the table, you're going to want a finder, a graphql type, there's quite a lot of stuff, um but I guess all at different points in time. Like I know with this, we didn't create a contact finder.

A

Initially um it wasn't needed until we introduced a way to search for contacts or um yeah and and the same thing here. You know we didn't need the counts until we decided we wanted to improve the list and add the pagination and all that kind of stuff. So um but that being said, I don't think it would be bad if these things were there from the beginning, um but I'm not sure I would be very overly comfortable on the pattern being that yeah the code is generated as opposed to I I really like you know.

A

When I first manually wrote a validation, would it be validation? I don't know if it's validation but a method that essentially stripped white space from the end of these fields and then some reviewer or maintainer said hey, like we've got something that does that you don't need to rewrite that code, um and that was like awesome, wicked great.

A

um So I'd like that idea, but um you know I realized that there's a wider audience that would need to buy into that, um and you know how many of these sort of problems- and I probably haven't very well defined these problems, I'm bringing to the table, um could that would that be able to address.

D

Yeah, I think we can like we can create something like strip attribute for the finders and and just instead of that, do filter by and then specify the and at least that will work for like very simplistic filters. And then, if you need anything, that's more complicated than that. You just write your own method or something right.

B

D

I don't know if that would help a lot, but.

B

So let me just yeah, I guess um I'm interested to see what it looks like because I I feel like the finders yeah, there's quite a few of them uh more than I realized there's. Actually I don't remember how many finders.

C

Yeah, it feels it feels like we almost have something's off. If we have you know for every model, we create almost a new finder for that model like something's off there, because the finding is almost the same for every model. You know.

B

Yeah and well, some of them return one record right and some I found this out like a week like a few weeks ago, like some of them returned one record like it's like I'm looking for this thing. Some of them are looking for these things and.

C

How cool to be me, and maybe- and so even looking at this, I'm just I'm in brainstorming mode, so it's like this. It's probably this might be really bad ideas. um uh How cool would it be if, instead of just contacts finder, which has a flag, are we doing counts or not, and that adds to the complexity?

C

We had a generalized count finder, which, based on the model and attributes on the model, could figure out. You know: hey here's, how we want to count the thing and we just return account or I have my records finder, which is I'm returning. The actual items of the thing like so.

A

C

A

That we could have an item finder so one for an item finder to find a specific.

C

Right, that's a better.

A

Records finder and one counts. One yeah.

C

It's a little bit of a code smell when you have the same function returns different things based on a flag like that's a maybe maybe polymorphism is the is the appropriate approach, but when we have one of these for every kind of model like I understand the desire to not want to create contacts, count finder contacts, item finder, like that's gonna, be way too much. But if we're solving the same problem for every model, I'm oversimplifying this I know I am so.

A

So the the one thing and I felt like maybe um I could see that thought in alexandria's head there when you were talking paul- is that I think there probably are.

A

I'm gonna say that I I think there are always going to be some specifics in the finders, although I'm not sure you were necessarily saying, but they wouldn't be, but you know the- and this is a perfect example, because we've immediately got this check. That probably doesn't happen for many if any other finders, and that contacts only exist on route groups um and then some other quite good examples is that the search- although that's something that's then implemented, I presume yeah on here- is then a fuzzy search, so you've got fuzzy searches versus non-fuzzy searches,.

C

So um uh you could like put those specifics inside the model, the other. You know I think, adopting looking at patterns here like.

C

I think this is where the rare case for using one of the official patterns, a strategy pattern would be sufficient because you would have here's my contacts model, here's my contacts, finder strategy, and so when I use one of these reusable finders, I would say hey when we're looking for that takes just a strategy type and it would say: hey here's how we search for contacts, here's how we filter for contacts whatever, and so that's like this is the kind of thing I think the strategy pattern tries to adopt.

C

But I realized man that's really close to like java, and we don't want to make anything that looks like java. So.

D

Not necessarily, but like the strategy product will probably not solve it all, because then you need to pick one strategy and and a lot of the times all these finders do combine multiple strategies in that context, where you want to filter by something and also search by something and also to sort by something, and then also do some counts, because it basically does the same thing. It just applies a count, but when you apply account, you don't need the order by because there.

B

D

Ads as performances on a performance hit on the database and so on and so forth, so um I mean we can definitely do something gradually that that removes some of these repetitive patterns that are easy to replace right away.

D

um So yeah, that's that's something I I guess the thing is nobody really took time to to do that because everyone was really busy with their own stuff but yeah. That's that's something we can work on.

C

And that is the risk, though too is like doing when you abstract the wrong abstraction or something is, is to is really hard to understand.

C

That's gonna do some damage to the code base, um so the other idea, if, if we can't find a simple abstraction that we like abstracting uh the tests, uh because that's the other side of duplicate code- that's really frustrating is we have to duplicate all the unit tests for whatever unit we're making, but if we can, if we can then create if we're creating multiple versions of the same thing that follow the same interface, uh it would be interesting to see if we could even duplicate or encapsulate how we test the thing, uh because.

D

C

Just keep these really simple: we don't have to deal with any abstraction complexity and we're have some regular way to enforce that it. I don't know better stay, consistent, yeah. You.

B

Made me think of um okay, uh something with the sidekick workers cause we kind of implemented these, like top of the file like almost like annotations, the workers have them and we have tests that kind of test them.

B

um Our advanced search migrations. Have them too. Let me see if I can uh figure out what code we use for that. Let me go in my browser uh hold on there.

A

Is this is really interesting? Actually, because um you know I've written most of the code to get this um this working and.

A

I haven't started writing the tests yet and what? What like I, I am dreading it, because I've got to figure out, obviously what we should test and what we shouldn't, but certainly having introduced all of these scopes and this method, which my terminology is going to be wrong, but has lots of branches all of a sudden makes me think. Am I seriously going to have to write?

A

um I don't know what this is like 20 test cases for this single method before I even then start to say well, you know this is then called by finder, which is then called by graphql resolver, which- and you know this- this could quite easily. You know double the amount of code, if not more, I'm gonna have to write um just to test which, under the hood, this is just well, I don't know scope.

A

So what do you call them like a an out of the box feature, um but because we've put this crazy thing on top of it, um but, like you said earlier, I think if we could just define this as an array of supported fields to sort on or something along those lines, then all of a sudden.

A

Hopefully that means we kind of don't need to test it, because it's just passing the the parameter through to this. I don't know if you can pass parameters to scopes, I'm sure you can by doing some kind of weird. um I don't know what you do, something.

B

Like that, or that.

A

And I I think that this, in my eyes is maybe the simplest bit that we could start by simplifying simplest bit. We can simplify the the the least contentious sort of like yeah, most clearly repetitive, undry thing that we're doing here, the the counting and um some of the foundry stuff etc is a bit more of a hana worms like I think, there'll be a lot of opinionation or whatever. The term is a lot of different approaches, but but this seems like something that I I even felt like.

A

We've probably already done it um somewhere, but I just don't know the what you call it the um grep foo or whatever, to to find what pattern we've maybe implemented somewhere else already.

C

Yeah, uh so so this is um those scopes. Correct me if I'm wrong, but that's what's like the scope on line 32 declares that hey this is an order of the first name, the first name field sending and that's what's getting triggered on line 48.

C

When we get a uh symbol, a first name ask then we do the order of the thing like does that: okay.

A

D

The problem for me is what we get in the order, because we got like first time ask if we can get two problems here. We can simplify these two by quite a bit, as you suggested, by passing in the uh attribute by which you want to to sort and the direction ascending or descending right. So.

A

Yeah and that's the other thing I mean even this, could this probably not can.

D

You can you make an array of this like? Can you do it here.

A

I was just gonna say something like build, um not.

D

Even that just like first name and then ask.

A

We do either that or yeah like so you're saying or more like this.

D

Yeah and remove the desk from the from the end.

A

um Yeah good point.

D

Yeah now, if that value, you can pass it on to order by um then in the method, in the model.

A

D

A

We just pass this straight. Yes, I have some kind of yeah.

C

Can you just, can you just call order and and the method itself.

D

In conflict with something defined already on the rails side,.

B

Oh okay, okay, we'll decide.

D

Comma and then you have that dash crater science.

B

A

The call yeah I don't want to use order by here. Do I cause that's the same.

D

D

You probably don't even need the order. Oh yeah, you may need it for the these two organization and whatnot thing, but.

C

I mean, is it um ah man I can't? I can can't help myself is.

B

C

Is this defining all you know all these order methods? Is this really the like responsibility of the model like? Could we could we just say like here's, our here's, our sortable fields and just call.

D

Yeah, that's what I was suggesting. I think as creating some sort of a. um I don't remember how rails calls it, but.

C

Basically, you.

B

D

Sort by these fields, and then that will create all of these scopes. You still need the scopes because, like that's, that's what generates the sequel that is going to be passed on to.

A

Yeah, I I know I've seen it um so.

C

The finder can't do this, the finder can't say like order by or whatever like the fight, the finder isn't in scope, land.

D

Yeah the finder, it can't do it, but we don't allow it just because we want it to be in one place like all the because then you start doing it in different services like order by this order. By that and.

B

Need to be kept.

D

In one single place, when you want to modify it for any reason and store it in one place,.

C

Okay, um yeah having a uh sortable feels things looks cool and it's it's not. You know it. It wouldn't be that complex to do the the one that needs. The include right, like that's just a.

A

C

A

Find where that magic is, um I've definitely seen it before.

C

B

C

Maybe we can just.

B

um Oh, what's it called processor.

B

These are the actual processes.

B

A

Looking for the way you, you have a method that kind of loops or and creates methods.

B

A

Think I found that.

B

I might appear out no, it's not in here.

A

Oh yeah yeah each, uh oh, no, no! That's creating a list! Now. um I've.

B

A

B

D

Is something even in uh in our gitlab code base, but.

A

I'm sure that yeah sure we like it's probably uses the word, the fire.

D

A

Yeah yeah well remembered that yeah yeah, so we can loop through something and we can actually dynamically define methods. So, whether there's a defined scope.

D

Yeah, I think we have something for scrubs as well.

B

D

In general, maybe an internal idea somewhere, I feel like.

B

I've seen something, but maybe I'm just like.

A

But that seems okay, oh.

D

Yeah, that's that's! That's something that that we can do basically generate these scopes.

A

And so yeah we would define an array uh of um kind of sortable fields to automatically define the scopes.

D

Yeah, you would say orderable by and then you list all the fields that you want to be awarded by right. Yeah.

B

A

D

Order will buy will basically go and say I have this defined. I have this this array as a param, so you'll iterate through the that array value to create a scope for basically every single.

A

D

A

D

A

That sounds sounds really good. um I'm just wondering, then, the the next small sort of step in terms of then cutting out this middleman. So do we think we would probably create the scopes with the same sort of scientex. So it's what's the field name underscore. What's the direction.

D

Yeah, I think, that's fuel that feels reasonable.

A

um Now I remember seeing there's something that again, I don't think we allow. I think it might be for security reasons, the way that you would then, if I was past an array that contains.

D

Actually, you don't even need that right because then you can pass in. You can basically create just two, uh whether by ascending and then passing the field name.

B

That you have in the array in order.

D

By descending, so you, you basically create only two scopes in instead of creating all these scopes for every single one.

A

So you're thinking more this, this sort of route than the other.

D

Yeah yeah so yeah, so basically you'll do this. You don't even need to then specify all of those.

C

Is it important for the model to allow list what fields you can sort by.

A

D

It's not important perspective, but you need it in place to generate this sequel. So you, you kind of need to let the model know what for for what thing you want you to generate the sequel um but yeah. If you go with this approach, if I order scope, then you basically don't even need to to know which columns you want to order by, because you can then call that from the finder the finder will decide uh which ones I want to where they're buying.

A

I wonder if that's cheating the fact that we don't allow ordering from outside of the the model, there's. Presumably a reason for that, if we're pretty much just exposing that by wrapping it is, is that a smell or.

C

I I feel like we can create a uh a class method that generates these scopes. Oh man, I'm feeling it so much. We can do this.

A

So you you prefer something that creates all of the scopes rather than this, which just uses a generic scope and allows you to pass params.

C

A

C

If line 33 344 is like this is our preferred way of doing it, then that way at least we're not circumventing the preferred way we're just so.

A

Why aren't we what I guess I would um I don't know what gets me what I like about this is it's clear and wherever you call it, you would be calling it like this.

A

If we created some magic method that created all of these scopes, that's where I get um ruby, blackmagic kind of frustrates me when I see something that I'm like. I can't can't do um death blah. If you know what I mean, I can't find where this is defined. So then I have to again that's that's fair. As a newbie.

B

A

An issue, if you know what I mean, but, as you learn browse a bit better, you start to understand how to then figure out how and where these things are kind of.

C

Let me just search for part of the word yeah.

D

So yeah, let's do the order, scope but again, uh filter by order by I'm trying to think of a name. But let's go with the order scope for now and then then you want in the order you basically I think you want a rel table so in the implementation already yeah. I think you want something like a real underscore table.

D

Oh field yeah, yeah.

A

But then that would be wouldn't it be more like color, no.

D

That's that's, no, that's a real table and then I think, as a method called you, you stick in the field.

D

uh Another the method call but from as an array, call like a rail table and then square brackets from the field yeah, um and then you have that equal greater than sign whatever that's called and then the direction.

D

B

D

B

uh Did I break.

A

This I'm just thinking I can spin up a rouse console just to test this right. Quite yeah.

D

Yeah yeah. That would be great.

A

Just checking I haven't hacked too much stuff before I probably should commit.

B

B

B

Come on rails here.

A

We go just needed a bit of communication right. Oh.

C

What what is a rail table? This is a object that.

D

Yeah, it's an object around this model that creates an basically a table definition for this specific model, so it will reference whatever the whatever the uh table. Name is called interesting: okay, cool.

A

So we read it like a symbol or.

D

We can try both do do a symbol and then do this thing. It should both should work.

D

um Let's see select and then.

B

A

Oh, that that was there anyway.

B

So there is an uh select from ah so it doesn't like that.

A

I mean, can I can I try just kind of doing build or is that definitely not going to work? That's right.

D

Oh okay, so it's it's the table. Let me paste in because leon I work just dictating stuff, so I'll paste in uh even zoom chat.

D

So if you can see that basically you want to do arrow film and then dot password by the direction, I'm not sure how to do that.

D

B

Me think oh yeah.

D

B

D

No easy way to specify the direction. I guess.

A

There's there's two sorting methods in ruby: aren't there, and I can't remember for the life of me when and why we.

D

A

But then I think I think this is the right one, because I think the other one evaluates locally rather than on the service. That brings back all the records and I think, there's sort, maybe rather than order buy, um but I'm sure that we don't like that. One.

B

Yeah, I think you want order.

D

Yeah the sword acts on an array and- and the word thereby is basically active record thing.

B

That's perfect: this is the secret. Let's just.

A

Check, there's no chance that we've already done this. Oh man.

A

Oh yeah, so this would be doing what you had suggested, where we just had maybe two to cheat for the moment. So we just have oh.

C

Look, I go back down, do you see, do you see what go there? Do you see what happened so there, our rl table, name, dot, lower dot, ask.

D

Yeah so like I, don't see an easy way to call direction. That's.

A

All right all right, so you can.

D

Do order scope ascending and order scope, descent, exactly yeah, we.

C

Can but we can call, I mean if the, if ask, is a method or property of this thing like we could just call that's the direction that we call.

D

Yeah, we can call sad, but we don't.

A

That was what I had in my head earlier. Yeah yeah send with something we.

D

Maybe in this instance is actually okay, because, like that's a that's, not something that so we don't usually want to call send on methods or on stuff that comes from the user right, because then you can.

B

D

All kind of very bad stuff, but when you do it for like very hard-coded things, it's probably okay,.

B

B

We shouldn't need lower, should we offshore, I don't know what.

C

Lower is oh that must be lowercase, so.

D

Yeah yeah that's a little wicked, but I don't think we need to.

B

D

A

B

Feel like for this problem.

D

You see this is where it's very specific for the field name. Sometimes you want it lowercase. Sometimes you'll really want to keep the the case in place.

D

A

I think I jumped the gun with my reload before the file finished, ruby, copying and saving.

B

C

Well order scope: ask order scope desk, that's an improvement. That's that's. Definitely an improvement right.

B

Oh hey david, oh hi, paul. I didn't actually mean to join the background pair programming whoa. I came at the tail end. I actually have to give.

C

Like showing up to a party and being like whoa,.

B

C

I didn't actually mean to come here me and you. I would like to stay here, because this would be much more fun than what I'm about to go. Do go to the reliability, stand up and talk about our pages fcl, but um yeah.

A

Well, I was singing your praises earlier david on the thing that I copied tagged you in the other day about your alternative. Awesome, paginated, tab search. What's it uh assuming you can take credit for that anyway, I'm not sure if somebody else did all the.

B

A

B

Well, thank you very much lee much appreciate us. This looks nicely. I think.

A

I think it's a step in the right direction: right, yeah, um one small iteration on the bigger um assuming nobody kind of shouts and says: oh no, that's not good, because I should hard code the list of available so.

C

We should like, we definitely should like we do want an allow list of the fields I I do think we'll want to do that, and it looks like organization and or organization asked organization desk or interesting, um but I think this is pretty good.

A

So I I'm not gonna it doesn't matter, I'm not gonna worry about shoehorning or like dependencies of doing this before my mr, because I think I don't think it'll be a complete can of worms. I think we'll find a fairly logical first step. Yeah.

C

I I would consider you know the the pain of testing is meant to be a signal, and so, if, if writing tests, it's like, I just can't stand this.

C

Maybe it's even more profitable for you to find them easier to test abstraction that creates more reusability of something like that happens. Sometimes.

A

Yeah so yeah, so so this is very prone to do. They call it copy pasta or you know I I copied this line and I forgot to change the ask to a desk and therefore I should really write a test case for all of these, but this kind of avoids that potential concern right. So all of a sudden, I don't really need to write tests for all of these different.

C

No just for one.

A

C

Them maybe and like yeah yeah, that's kind.

B

A

A nice dress, then awesome um consciously everyone's time. Super helpful as always, and.