Kasper Timm Hansen on Rails Core, 37signals, and the Craft of Going Independent
What we talked about
Kasper Timm Hansen is an independent Rails consultant and member-owner of the Spinel co-op, based in Copenhagen. He spent nearly six years on the Rails Core team helping maintain the framework that powers Shopify, GitHub, and Basecamp, including almost two years inside 37signals, the company that created Rails. He now runs his own consulting practice helping teams get the most out of Rails, and is the author of the Oaken data-seeding library and rv, a Ruby version manager inspired by Python’s uv.
Show notes
Kasper Timm Hansen spent nearly six years on the Rails Core team and almost two years inside 37signals before going independent, and he traces the path from a 2013 Google Summer of Code project to committer to Rails Core. He gets concrete on the engineering-efficiency work he does now, from why slow test suites are the tax most growing Rails apps quietly pay to how associated objects keep domain models clean.
What we covered
- The path from a 2013 Google Summer of Code project to committer to Rails Core, and what he tells engineers who find contributing to open source too intimidating to start.
- Why open source is not about getting your code merged, but the right code at the right time and what you learn on the way there.
- Why slow test suites are the tax most growing Ruby on Rails apps quietly pay, and how he seeds test and development data from the same recipes using his Oaken library so you debug the story you already know.
- How associated objects pull behavior out of God objects to keep domain models clean.
- “Riffing,” his scratch-file design method for exploring a problem before generating a single line of code.
- rv, the Ruby version manager he built inspired by Python’s uv that installs Ruby in about a second, and what is next for Rails 8 and Ruby.
About Kasper
Kasper Timm Hansen is an independent Rails consultant and member-owner of the Spinel co-op, based in Copenhagen. He spent nearly six years on the Rails Core team and almost two years at 37signals, and now works with teams who want to get the most out of Rails. He is the author of the Oaken data-seeding library and rv, a Ruby version manager inspired by Python’s uv.
- Website: https://kaspth.com
- Spinel co-op: https://spinel.coop
Episode 164 of the PreVetted Podcast.
Full transcript
Federico Ramallo (00:00) Welcome back to the pre-vetted podcast where we spotlight. Extraordinary people and remarkable talent reshaping our world. Today I am joined by Caspar Tin Hansen. He’s an independent Rails consultant based in Copenhagen. Kasper spent nearly six years on the Rails Core team helping maintain the framework that powers Shopify, GitHub, Basecamp, and a huge slice of the web, including
Almost two years inside thirty seven Signals, the company that created Rails. He now runs his own consulting practice, working with teams who want to get the most out of Rails. Kasper, welcome to the show.
Kasper (00:41) Hey, thanks so much for having me. Great to be here.
Federico Ramallo (00:44) it’s it’s an honor to have you here today. so for people meeting you for the first time, can you describe a little bit more of what you do?
Kasper (00:51) Yeah, for sure. Well these days it’s actually slightly different. I’m now at a like a co-op where it’s spinel, spinel.co-op if people want to see it, where we’re a team of people who are we said in a team recently that we’re kind of pathological about doing open source. And so that’s kind of where the connective tissue is. got Andra and David from Bundler and and RubyGems as well, and then Sam Stevenson who’s also like done a ton of stuff like RBN and like hot wire and all that stuff. yeah,
Federico Ramallo (01:15) wow.
Kasper (01:17) And so right now we’re kind of banding together and being a co op, so we’re both like
members in there but also sort of owners. So if people talk to us, we’re kind of we don’t just like push it on to say other people or whatever, we also get in there, like get our hands dirty, so to speak. And figure out what like how can we help clients do better and be faster and all that stuff. And we’ve taken like a focus on engineering efficiency, which is basically well, a mix of efficiency and effectiveness. So for instance some of the projects we’re doing is like speeding up test suites because we want like a s little bit of a faster feedback loop, than what’s
Federico Ramallo (01:48) Right.
Kasper (01:49) You know, for rails apps that grow larger, typically it’s like factories and R spec and things like that. And it just like start slowing to a crawl. That’s one of the things that happens, happens to everybody. So yeah, so that’s one of the things we’re like looking at. And then there’s more like infrastructure focus. We’ve looked at stuff like deployments and things like that. So it’s usually been at that intersection of
Well, actually s slightly lower level than your typical Rails app of like some of that plumbing that goes beneath it. and how do you like keep that clean or make it better or even like I my focus is a lot on like domain modeling. So it’s like how do these pieces fit together and is this its own model that’s within an auto model, or is it just an attribute somewhere, or where do we want these slices to go kind of? sort of wide ranging aims but that’s a lot of the stuff that I’m focused on right now, yeah.
Federico Ramallo (02:28) Right.
Interesting. Interesting. Yeah, the I think that the infrastructure is something that it’s not not well taken care of on a lot of projects. I mean w I I’ve I’ve been in projects where that that was mishandled and then we had, you know, a lot of bottlenecks but nobody kind of focused on paying attention to that, so I find that very interesting.
Kasper (02:54) Yeah, yeah. I guess just to put a little bit more of a broad point on it, what I’m thinking of is kind of the difference between just working on the individual features and then also like the underlying system. Like I’m generally a big fan of if you have a pretty good foundation, what I’ve seen happen is like you work on something and NSC ends up pushing back into the foundation but in a way that strengthens it as opposed to creating holes or whatever. That’s very abstract, but it’s like
Know you kinda know if you have it or not, which is like, I can clarify something over here, and now it becomes even the foundation actually gets strengthened by it as opposed to like it gets slower or more confusing or whatever. But it’s yeah, it’s it’s more about figuring out like what’s the actual system we’re building here as opposed to all the individual parts. So it’s kind of I also said this in a team meeting.
recently. sometimes I like to think of it where I think as programmers we can kinda get a little bit obsessed with like creating the perfect unit.
But then it’s like, yeah, I might create the perfect bike pedal, but it’s just supposed to go on this one bike. I don’t need it to be the best thing ever. It could it’s just it’s supposed to go on this one specific bike I’m building. It’s it’s supposed to fit into a hole. It doesn’t need to be the most polished, whatever. But it has to be cobbled somewhere. I just don’t want it to be cobbled to everything, you know. It’s just supposed to cobble to this one I guess that metal rod or whatever, I don’t know what that’s called, but you know. That’s the way I’m kinda thinking about it.
Federico Ramallo (04:09) Right.
Right. Interesting, interesting. Yeah, the I think that the you know the perception that I’ve seen, you know, on online is that Ruby is low, that you know that Ruby is is you know s a few years ago people were saying is Ruby dead, right? I mean I I disagree. I mean I I
Not only because I love Ruby personally, but also because the the speed that you can’t innovate with Ruby it’s much higher than any other you know, coding language, right? and w what you’re what you’re able to provide is, you know, once once you get to a level of complexity where the tools are becoming complex and slow. And I think this applies to th th this situation happens to any other any other language, right? You get to
level of complexity where that happens regardless of the speed of the language, right? and the and you being able to get there and boost the performance of the team by honing the tooling, I think that’s amazing.
Hm. So why did you decide to to do a co op? Tell me a little bit more about that.
Kasper (05:12) Yeah, basically I’ve been doing individual consulting for a number of years and for the most part I was kinda like that that actually fits me really well, like because what I’ve really wanted to be is like almost like a roaming staff engineer, being able to take all that experience from like various different companies and also on a Rails core team and all that and doing a bunch of open source. And it’s like that’s quite a varied skill set there that I don’t necessarily see a ton of other Rubyists have. So I feel like it’s it placed itself well to a lot of these companies. But
over time going it alone was just proving to be a little too difficult in some ways where it’s actually nice to have people who are of this same kind of variety, if you will. That’s where it was a like there was a lot of mutuality in banding together with these people. Sam I’d worked with before, so I know him well. but the other people are new. But that’s been really good actually, just to have more of a sense of camaraderie that we’re all in this together. And it takes a little bit of the pressure off from any one person because now it’s also more like sparring. But
What seems to be really useful to me is just the fact that it’s like we’re all equals here. Then we have a lot of that same experience where sometimes that can feel a bit isolated because people don’t necessarily work on libraries or have that kind of vast open source experience. But because we all have that, it’s actually really easy to have a lot of these conversations because we’ve seen so much stuff. So that’s kind of a part of it for me. And then the other part with the specific co-op is that it’s like we’re all
owners of it. So again it has that quality there where it’s not we’re not anybody’s boss here. We’re all we all know how to get stuff done and go in there and and and do the things we need to do and then also kinda want to get out, you know. Not necessarily wanna stay forever. But that kind of stuff and that kind of like mentality of
Yeah, kind of getting at it or whatever, and then also that sense of ownership because we’re also used to that from the open source side of things, where it’s like, Well, nobody’s tackled this problem yet, so but I have an idea for how I want it to be tackled, so let’s do it this way, and then you can follow that all the way through. And it’s kind of the same thing for clients of like some amorphous set of requirements or whatever. They don’t they have an idea of what the problem is, but we could also go in and then figure out what it actually is that they need to fix or whatever, you know, over time. But so it’s the same thing of like,
That ownership just goes both ways, kind of, both within the co-op and also on clients’ behalf or working for them essentially.
Federico Ramallo (07:18) Right, right. So cla clients can get a a team that is fully committed because everybody has a share of ownership within the organization, right? Right.
Kasper (07:28) Yeah, exactly. Yeah. And, you know,
if if clients talk to us, we’re we’re the people who are also doing the work. So it’s not like hand off to people who have no idea or like we’re not a s I mean I guess we do sales, but it’s not like a sales team where it’s just like we’re the same people. So it’s like we take the sales hat off and put the engineering hat on, or it’s like both are on at the same time. I don’t know what the what the visual image is gonna be, but something like that, you know.
Federico Ramallo (07:42) Right.
Mm-hmm.
Yeah, I mean you you don’t have a dedicated sales team that that that doesn’t have any experience s any technical experience. So you know every every time a client talk talk with the sales team, they’re actually talking with the technical people that will do the implementation, which is a big difference, right? Yeah. A and the same you you kind of implied you also talk about that you’re not delegating the tasks to
Kasper (08:06) Yeah, totally. Yeah.
Federico Ramallo (08:15) juniors that don’t have that level of commitment or expertise that you and your team has, right?
Kasper (08:20) Yeah, exactly. I do wish that we’d do it we’re still early, but I still wish that we’d do a little bit more for like including juniors and things like that. But I think that’s gonna be a little bit further down the road and we do it differently as well, which not just like handoff, but yeah, we haven’t figured that part out yet. I I still wanna do something there just because of, you know I was a junior once and I think Ruby is a great place to work in. So it’d be nice to have more who can do this kind of stuff and be able to hopefully like train them up really well and everything. So I’m still curious about it. We just didn’t like
Federico Ramallo (08:36) Ha ha.
Kasper (08:46) explored that yet. That’s just more like me big picture thinking at some point. but it still wouldn’t be that handoff part. but again it would be that sense of ownership where it’s like, yeah, we know how which parts to give to someone else but still have that sense of like shared oversight or whatever you want to call it. I don’t know exactly. Again we haven’t tried it yet, but like I I’m sure we’d figure it out pretty well.
Federico Ramallo (09:03) Right. Right.
I I’m I’m happy to, you know, t tell you more offline if you want about my experience managing juniors because I had that same you know impulse of I want to
train more juniors, but also on the other hand, I don’t want to water down the value of of the you know how much the team can deliver, right? So I had I had I trained juniors that then were not up to the level that needed to be to work on the team, right? So I got I I got kind of stuck with that underperforming junior, right? so I I you know I had some experience with that. And then the the last one that that really worked
really well with us is we did this it’s a three-year training program where we train people for three months before they they join and we do this with the client approval right so basically we we vouch for the we vouch for the people that we we present so we we train 10 to hire five right we have the best five and then we do that with
with client. mo most of the the managers that we work with that that we start doing that, they wanted to get more involved into that process, right? my intention was I will train them and then I will present the best ones, right? And then I can vouch for them because a a junior doesn’t know much about doesn’t have any experience. So the the level of experience was not important. What what I wanted is to figure out the word ethic
Kasper (10:15) Hmm.
Federico Ramallo (10:33) the communication skills and a lot of things that I could train them them on, how fast they could catch up on that, right? and we we by by working with them for three months we were able to know them personally and then we were able to make that recommendation, right? but the the managers wanted to get involved. It’s like I I I want to see how they work on this, how to work on that. So they they start filling on on that process, which was you know, it it kind of screw up our logistics, but it was amazing because there were
They were really engaged, right? So so we did that, and then after that, we did we had a three-year plan with a soft commitment. So basically every year they had a performance evaluation with a salary increase and everything for the trainees, and and then we worked towards what responsibilities, new responsibilities they should they should own by that time, right? So
Kasper (11:02) Yeah, yeah, definitely, yeah.
Federico Ramallo (11:27) That way we got a clear expectation to the trainees. We reduced that fr stress of I wanna ask for a race, right? I I’ve been there, you’ve probably been there. It’s like, you know, as a trainee as a junior, you know, it’s a stressful thing. So we try to reduce that. We were able to achieve a hundred percent retention for the three year plan. On both the trainee and the manager both were happy working on the project. So for us that was very very interesting and you know.
You know, happy to share more details.
Kasper (11:56) Nice, nice, yeah. Yeah, that’s really interesting. I’m just thinking about it. Yeah. Cool.
Federico Ramallo (12:00) Right,
right, yeah. I th that was kind of our last evolution of of the whole thing and it worked real really well, right? And and then having a senior that would owned be accountable for the performance of the team, right? So that that was the other thing, right? Yeah. But then we’re able to deliver a lot of value to the client, you know, because the rates were really, really low and then but also explain that yeah, they’re really low but they’re going to be increasing year over year and this is kind of the plan.
Kasper (12:12) Mm.
Federico Ramallo (12:27) and the dates were kind of more of a milestone than a that a hard date, right? Because I I don’t think it’s fair to give a race to somebody just for saying a year. I think it’s it’s fair to give a race when they they own certain responsibilities, right?
Kasper (12:43) Sure, yeah, yeah, yeah. I think that makes sense. Yeah.
Federico Ramallo (12:47) Yeah.
so anyway, going back to you, you know, how did you end up on the rail score team?
Kasper (12:53) Yeah, I mean this is a while ago. originally it started all the way back in twenty thirteen where I was still like a student and then I found on the Rails blog, I just happened to find it one day, that they were doing a Google Summer Code project where Google Each Summer, I think they still do it, they pay a student some amount of money to work on open source. And then you have participating organizations and even companies and something like that where well the deal is people work students work on open source. and Rails was a participant that year and so I submitted a proposal. They had Rails had like a
And a built-in HTML scanner library that used Regex to parse HTML, so it’s both slow and it was also like insecure. And so we swapped that out for something called LUFA, which then parses using your gear and everything. So it’s actually safe and also a lot faster.
And that was what I did that year in 2013. And then in 2014, Rails is global ID thing came out. That’s what backs active job. So when you do like a an active job integration, whatever you pass an active record into it, it gets serialized. So you actually don’t have to call find on like a post, post upfind one or whatever else handles that for you. That’s global ID because it serializes a a model into like a
like a URI string essentially. and does that for you. And so I just started contributing to that as well and then became a maintainer of that, I think, technically. pretty quickly after that. I just responded to a whole bunch of stuff. You could probably still find a cub the comments and things like that. So they’re all way the way back from like August twenty fourteen. And
Then in like early 2015, I just started I had subscribed to Rails on GitHub. You could do that, like watch the repository. So I just got an email for like everything. So just started looking at that fire hose and then sifting through it and reading stuff that I was interested in. And it’s like, that’s too much or whatever. But then over time I felt a little bit more confident in how that went and that flow. And you know, a lot of these details are now foggy. But then eventually just started reviewing stuff and getting into that. And I was really interested in that. And I think
Pretty quickly after that, because the team already knew me, I got an issues team invite, which basically means that you’re allowed to merge documentation pull requests. I don’t know if that’s it still works that way. You I’ve been out on a product for a while now. and at the time you couldn’t GitHub couldn’t distinguish between someone who has commit access and someone who’s can only merge like documentation pull requests. So you technically got commit access, just not just don’t do just don’t merge code.
Federico Ramallo (15:01) Yeah.
Kasper (15:01) And then I kept doing reviewing stuff here and there and quite intensely I think in that early twenty fifteen period. And then I think in May or something, I got an invite to be a committer, which then means that I could merge code. And so then I could review more pull requests and then I actually could merge contributor pull requests as well. And then
A year later in like June or July twenty sixteen, I then got D mite the core team to join that. And then that was the same process throughout that whole year of just like reviewing stuff and I think I did a couple of features as well at that point. and yeah, that’s that was that. I didn’t yeah. From from then on there, yeah.
Federico Ramallo (15:33) Very interesting. Yeah. I th I I think that it’s it’s very underw overwhelming for a lot of people to to start you know reviewing open source code. so it’s very interesting to hear h you know, how you were able to get into into that project and then being able to understand how everything works and then being able to get access to start doing committing, right? Which is a big deal, right? Yeah.
Kasper (15:57) Yeah, yeah, for sure. I
I will say I think that’s partly what I see people sometimes mistake. That sometimes I think people think that OpenToS is about the code, which it is to an extent, but it’s like the right code at the right time. And I think that granularity is where a lot of people kind of
fall off a little bit because like what I have to get my code in now and I get it if you have like a production bug and everything. But the issue was that we get a lot of people who are kinda obstinate or difficult to work with because they hadn’t like they hadn’t gone through the process was totally fair. but it was just like, well, I have a bug that needs fixing now. And it’s like yeah but I don’t want to maintain that. So we need to tweak this and this. But then they weren’t really able to have that
When you deal with a lot of open source maintainers because they’ve been through the process and been through that ringer, they’re kind of more flexible. So they’re like, okay, I know which things to change and whatnot. But if they’re not used to that process, it’s a lot like, what do you mean? Just merge it almost. Not entirely. And I’m like generalizing a whole ton of like a decade of experience there. but that was for sometimes it was become easier where people are more flexible. Okay, I see that. I’ll make this change here. Or then they give pushback, but in a way that was also more.
I don’t know how else to say it, like intelligent or something, where like sometimes we’d have people that were pushed back but are like, What do you mean it’s supposed to be this way? It’s like, not really And the the other thing that was also slightly difficult about it was that mismatch between someone who’s like a new contributor and then also you having seen
Federico Ramallo (17:09) Yeah.
Kasper (17:16) Like I’ve reviewed over a thousand polar pressed on Rails like helped merge that and whatever. So you get to see a lot of code throughout that whole code base. And the difficult part was that like their local maximum and their Rails app versus our local maximum from like looking at the code base over time. So it’s like, hey, this is some of the code that I’ve written that’s really good. And it’s like, I sorry, that doesn’t really impress me because I’ve seen So it’s like a weird mismatch between
Federico Ramallo (17:36) Ha ha ha.
Kasper (17:38) between those different levels and that’s just, you know, the nature of it. But it was like I I get I get where you’re coming from, but like hey, we do need some changes to make this because we want to we have to maintain it. You’re not maintaining it. So I want to see some changes to the code quality before I want to click merge. then you do it afterwards or whatever. But I did generally enjoy that process of talking to people and giving a little bit of feedback here and there and then, you know, eventually merging it. It’s f I flushed a lot of that on my memory because I’m not doing it anymore. But
But that’s how I remember it.
Federico Ramallo (18:07) and what advice would you give to people that you know, other software engineers that might want to do contributions but they find it overwhelming, so eventually they don’t do it. what advice would you give them?
Kasper (18:18) Yeah, yeah. I I like to think of it more as like it’s not about getting the code in, it’s more about learning. Because then it doesn’t really matter if your PR gets accepted exactly as it is. Again, I get it, if it’s like a production bug you wanna help fix or whatever.
But usually that makes it a lot easier for people because it’s like, well, at least I learned something here, which is also the mentality you kind of want, where sometimes we have people show up and then they’re very eager and then they submitted like five pull requests within like a week. And then you reviewed the first one and then you knew that they were gonna go like, okay, hey, I have another pull request too. I was like, hey, I a break. Like I don’t need to just because I know there’s four more waiting. And I’d much rather the people commit or contribute slightly less, but learn something from going through the whole process of it.
Federico Ramallo (18:43) Mm-hmm.
Ha ha ha ha.
Kasper (18:57) You know, because otherwise it’s just a little bit like, what are we doing here? because then they’re not learning anything. I just wanna just wanna like get the code through and I’m just a bottleneck and it’s like I I don’t know. At least for me that was kind of the part that I enjoyed. This is like ten years ago, so who knows if it’s if it’s still the same or whatever, but
That’s at least what I kind of enjoyed. There was a little bit of a give and take where I got to learn how to give feedback and then you got to learn a little bit more about how to receive it and we all sort of hopefully learn something and also ship the code eventually. and I guess the other advice is also just I I I do recommend still what I did, which is just watch that fire hose. Like click watch everything on the repository and then you’ll get to s get like literally an email for every comment. and you get to see which things get merced and why things get declined and stuff like that and who’s showing up and how are they communicating.
And it’s also a lot more about just showing up here and there and keep nippling at it as opposed to like full-on.
Contribute every day or whatever. I mean I suppose you could do that, but I don’t know. That’s that’s not necessarily sustainable. And then the other thing I’ve sent to advise people on is like sometimes I think for a lot of people the contributing frequency is actually more like every six months to every twelve months as opposed to at least for Rails, as opposed to like every week or every month. You could do that over time, but yeah, I just I just wish more people would just let that process sink in and go through it and then let it change them a little bit as opposed to like
It’s not the day job. So you get to dream a little bit more in a way of like how could I actually approach this and how could I l learn something in the process as well and how could I upscale myself as I’m doing this as opposed to just like pummel coat through. But you know, that’s my perspective. I I think other people on the core team have a different perspective. I don’t really know, but yeah.
Federico Ramallo (20:27) Right. Right. Yeah, I I I like the idea of being about learning because I mean we when we’re using you know any framework, any high level framework, it’s it’s easy to learn. it takes a while to learn, but it’s kind of easy to learn how it wor how how to use it. But if you don’t know how it works, you’re missing out so much, right? So I I usually when I interview I ask
about Rails, I ask about Ruby, I ask about a little bit of C, you know, I I ask how how the the the language is being compiled and how it’s being interpreted, right? and try to poke how much that engineer knows about those those things, right? Because that gives you lot of insights, you know, or active record, how active records work, because you know that allows you to to understand does that that does the engineer understand N plus one problems?
understands how databases, indexes work, you know, and you know, if if you understand the the the lower layers then you have more insights on how everything works and you are able to make things you know perform better, faster and and you know you can make better design design better software overall, right?
can can you tell us a little bit more what are your recommendations for for people to do on the project? What advice what are the most common things you see you know, becoming the bottlenecks and you know, what advice would you give to other software engineers that are maybe struggling with with infrastructure?
Kasper (21:56) Yeah, yeah, that’s interesting. I tend to think a lot just again from the Rails Core experience, is like I tend to think a lot in those patterns and the code to like help make better tooling as well. So I can sometimes be a little bit at fault for thinking that a lot of these things are just like s if we just have slightly better tooling, maybe we would fare a little bit better to help frame a lot of that the work we’re doing.
So to put that a little bit more less abstractly, I guess, is like you know, a lot of teams struggle with both domain modeling. It that’s one of my like bugaboos, and then or pet peeves. And then also like just slow tests or like not really being intentional with their data. So for instance, one of the the the products I’ve got going, it’s like less than a hundred lines of code, it’s like active record associated object. But the idea is that what a lot of people struggle with is finding a ways to extract like collaborator models from
in like an active record. So it has the data and also has just like tons and tons of behavior and grows and grows and becomes almost those like God objects. And then on the other side of the spectrum, I guess you have someone like a master or a repeat person that just knows what every what the right choice is at every point in time.
But so what I’m trying to do is pull people slightly towards that trajectory without being like, you have to figure everything out yourself. So it’s just like giving people an extra like some extra language so you can actually, when you decompose new features, you can kind of see where this concept might fit in of like an associated object. So what it is is let’s say do you have like a post.find one, you know, it finds the first post or whatever.
The only thing ActiveRecord needs to be able to find a record is both that class name and then also the ID. And so my thinking was, well, what if we actually slot in like a poro like within that active record? So we have post colon colon publisher dot find one. And so that publisher is just a a a poro.
Doesn’t store anything in your database, but it piggybacks on the fact that it’s nested within that post so it can actually respond to global IDs. So you could pass these poros to jobs. And then you could so you’d have like post dot first dot publisher so you can get back at it again as if it’s like almost like it’s a has one relationship, but it’s just in memory.
And that’s been pretty interesting too. Did you get like, you now I can actually pass these power to jobs or I also did credits way back. So that was also on my mind at the time because this is all the way back in 2022. I sort of first had the idea for and like sketched it out and like I think this could work. And so I wanted to make sure that that also works so you can have that automatic credit support in there. So you could use all the stuff in there. Credits was like Redis with some optic types in there. Like there’s some distinct types that seem to be in there and the way that we’d use Redis, wherever it used to work. And so that was just
an
extraction of that. And so I just wanted to make sure that also worked. And again, it also just piggybacks on the fact that we have that post ID within the publisher and then we can like access back and forth.
Yeah, I don’t know, that’s been very interesting. That’s one level where you see help the extract and spot some of these I call them collaborator objects. Again, going back to that example of the bike thing, like I don’t want everything to be one unit. I want to extract some of these things a little bit, but the data might still be stored on the post because that’s just easier because databases. But maybe you want to untangle some of the behavior into like a dedicated
Federico Ramallo (24:35) Right. Mm-mm.
Kasper (24:47) scope or something and so it also helps you organize things because you do like app slash model slash post slash publisher dot rb so you get like automatic organization as well where you don’t really have to think about it. So that was the other part. And then it makes it a little bit easier to decompose new features when you’re actually like I’m working on something and like I think this actually is its own thing as opposed to not really having a place for it or having to battle a bunch of boilerplate to figure it out. it just make it slightly easier. Again with that
Rails’ framing of conventions, I was like, I don’t really wanna have to think about this, but I also don’t wanna go completely into my own of like the the most perfect ideal OOP thing, whatever, because it’s I I might not figure that out on every case. I want something that’s slightly more patterned to be able to follow. So that’s one thing that helps a little bit with the domain modeling piece. It’s not meant to be like a a grand solution to Rails’ modeling issues. You kinda wanna figure out how to decompose that correct there and
No, sometimes I’ve said that your app is in the associations, so that’s another thing I see people kinda struggle with. It’s like again they think in terms of units, but to me it’s really about the connection between these different optics in the system who are building an optic graph. It’s not just
one unit or whatever isolate it from itself. We are building like small worlds essentially. so that’s the other way I’m kind of seeing it. And I want to make sure that that connection between these optics actually fit together or work nicely. It’s it’s tough to put into like abstract terms. So that’s another thing. And then coupled with that, the other thing I see a lot is like people on factory bot and then the test suite gets slower and slower time. There’s a lot of setup and
In my experience, factor code like optimized for isolation. So it looks really clean on the surface where you have create something or whatever, and then you create an account, but then it pulls in everything else in the app or eventually, and it’s just like I find it difficult personally. And then everything’s anonymized. So when I try to go in and debug something, it’s just like, well, I don’t know if this
I I there’s something that’s like compared here, but the username is now different, so it wasn’t what it was before and I don’t remember and I don’t know, I find it really cognitive actually kinda difficult to handle over time. and then I’d also work with fixtures because they’re supposed to be better and faster. And they do let you tell a bit of a story, but it’s all in GAML and I also found that really difficult over time. So eventually I created a tool called Oaken that’s sort of meant to be
a match between these two things. It takes Fictures approach of seeding records in up front. So their tester suite is pretty fast. And but you also what you also get is you get to have data scripts that are more like recipes and you can share them in development as well. So the data you test with you see in your browser is also the data you test with to help make that close that loop of like what are we actually doing here?
in that optic graph from a slightly higher level as opposed to just like, here’s the individual little thing I’m working on, but how does it actually fit in with the rest of the system? That’s kind of the question I want people to ask more. So we can be a little bit more intentional with the apps we’re making as opposed to just like banging stuff out or whatever. I don’t know, I hope that makes sense, but that’s
Federico Ramallo (27:35) Right. Right.
Interesting. Interesting. Yeah, I I I I use I used to have seats on my database that I sometimes populate on the test just for you know th seeing things. But but yeah, I ended up having two different stories. One the development seed, which I try to tell my stories like okay, I have this user, I have this, whatever object I have, and then you know.
I use that data to kind of destroy database, sit it again, and kind of repeat, and I keep expanding into it. So I I build my my my development examples with that. And then on the test side I have a whole different set of examples. And then I have that cognitive load of having to kind of switch between, I’m on test now, how I have to think about that, right? And the and then when you start having dependencies, right? So you have a a project that has tasks. So now tasks cannot live
isolated, right? They need a project. So now on tests and especially when you want to run them in parallel, now you have conflicting projects, tests and you start getting those those issues, right? Or at least I think of the test as as a story, right? Like as a user, I I add a task, I know another task or whatever it is, right? and then when I start to running in parallel, it kind of breaks down because it doesn’t have that level of isolation that it should have, right.
Kasper (28:53) Mm.
at
least not in my experience. I think that’s that’s fixed now. I haven’t had experience. We use parallel tests with this Oaken thing and you could do that with fixtures as well and they just like create several databases and it they sort of run just talk to their own databases each and then that kind of works. so it’s as a way to get around that. Yeah.
Federico Ramallo (29:11) Yeah, I I I started doing that, but then I had to make sure that the the data that I had for each test was a correct one, right? So I used to do a a chain dependency that probably was not the best approach, but I don’t know, it was what I did at that time for that project, right? and then you kind of learn and then you do it differently the next one, right? Yeah. Big Right.
Kasper (29:20) Yeah.
Yeah, exactly. Yep. Yep. Yeah, it’s not easy. That’s the other part with all this stuff. It just it’s just
difficult. there is not necessarily an easy answer. I guess for me it’s just more like what I like in that fixtures approach is like at least you write the names down or the values down. So you create a little bit of that storytelling and you use those specifics to explain your optic graph. So if you have like a project of tasks and everything, you could give those projects names and task names, but in reuse those so you keep training on and now I remember. And then if you use that as also your development season.
at least when you sign in your browser you can see the same thing so it helps connect that like cognitively so you’re not learning two new different scenarios or whatever. at least to me that makes it a lot easier. It makes it a little bit more difficult up front when you’re first joining your code base because there’s a little bit more to ingest and learn or whatever. But I feel like it actually pays off pretty quickly because at least you’re like, we’re using the same task here. And yeah it’s connected to this project here, but at least it’s the same as the post server was like
Federico Ramallo (30:11) Mm-mm.
Kasper (30:26) a factor bar create a task, but now it also creates a project and then like okay and then they’re always named something different because everything’s just like auto generated. And I don’t know. I I I just find it difficult.
Federico Ramallo (30:37) Right.
Right. Yeah, I I I understand what you’re talking about. The I had that that same you know that that same issue and I was trying to avoid kind of generating everything from the beginning, right?
But once you have like a a project, a username, or whatever objects you you you need for the you know, you you you can say, Okay, I want to add a task or I want to delete that task, right? So it’s easier f for us to kind of understand which part of the story we are, right?
Kasper (31:07) Yes, exactly. Yeah, yeah, yeah. Yeah, I find it that that easier as well, like over time, because you learn that scaffolding or whatever, and you don’t have to keep that in your head as much. It’s like, well I’m familiar with this project and I’m familiar with this task and so I know sort of what’s on it. And you learn a little bit of that, like I guess it’s where’s like f there’s like a pff actually I’m gonna forget this. So it’s just too yeah.
Federico Ramallo (31:09) Mm-hmm.
Right.
It’s all good. It’s all good. Yeah.
and the same with the names of the users, right? Because if you let’s say you have to add a task and then you say, Okay, I have to add a task, but I have to create a project and I have to create a user. So, you know, all those dependencies, right? If you have the story, you know, okay, I’m in in project Acme or whatever it is, right? And I’m the user John, you know, and John is a super admin, right? Then okay, then I can create I know I can create a task. It’s
it it loads loads off your your your cognitive load because it’s a story, right? And if you sync sync that up with development, then you can go and click and see what happens, right? And then you can fix it, right? Yeah, yeah, yeah.
Kasper (32:05) Yeah. Yeah, exactly. Yeah, yeah.
there’s actually a blog post series. I keep wanting to write like a response post to it of how I actually think Ogun does it better or like can accomplish some of the things that a blog post is talking about. But it’s on BlowMage. I don’t know the person but wrote a series on like fixtures both as like documentation and it was just all the stuff that I wanted to write at one point I just could never find the words for. but I found that’s a really good
Federico Ramallo (32:26) Yeah.
Kasper (32:29) explainer for the thinking involved in there. And I still want to write like response posts because I think actually Oaken helps facilitate the ideas in there better for most apps. I it’s just, you know, on the blogging to do list. So yeah. But that’s the recommendation there at least. There’s a whole series on there.
Federico Ramallo (32:44) Interesting, interesting. A and wha what other you know main problems have you seen on real code bases that people should you know should focus on on fixing or improving?
Kasper (32:55) This might be what I have for right now in that space. I don’t know if I have any more. It’s off the top of my head. Yeah.
Federico Ramallo (32:59) Right.
Right. I you know, it’s kind of changing topics. I’m excited about Rails eight. I started using it and I I love it very much. And I’m starting to explore more and more the Ruby L L you know library from Carmine and you know trying to get more more features into my my applications because it’s it’s been amazing how much how much is is is is being improved s from seven to eight. So I’m excited for that, yeah.
Kasper (33:27) Thanks. Yeah.
Federico Ramallo (33:28) So you also designed a methodology, right? You call reefing, right? Can you tell me a little bit more about what is that?
Kasper (33:36) Yeah, yeah. So basically it’s a way to figure out your domain modeling and helping with that and helping you again decompose features and making it slightly easier to find better designs over time through exploration. So again, that’s a lot of abstract stuff, but basically what it is, is you open up a scratch file and you start you have an idea for what it is you’re working on, like a broad sense of it, and then you just start writing in the code and filling in the blanks. Like, I have a rough idea for what it is I want to. And then you don’t necessarily run that code. And it sounds a little
silly maybe, but I’ve actually found it to be really useful. So it’s almost more like in the same way that you might with like a therapist where you have like an open dialogue and you can sort of externalize things and you can mirror it back to yourself. That’s kind of what you’re doing here. You’re using that scratch pad as like a dialogical tool to figure out what it is you’re working on. And then over time you either like both get stuff out of your head so things become clearer and then or you get other ideas for I think I need this thing or I need this thing. And so it’s kind of most
What I found with it is that it’s actually pretty fast to run these things. It takes like an hour and you get a lot of feedback for like at the very, very granular level for things that are missing or what else you need or how this interacts with the rest of the system. So I guess it’s slightly similar to what people are doing with LMs these days. I just like still being i it’s not so much about being in control, it’s more just about having your ears out and listening.
Essentially, because you’re trying to work on that system. And I’m a little bit worried about some of the LM stuff where we’re moving so fast that we’re degrading some of that trust in the code base and that what’s there’s like an I word I’m looking for. There’s not integrity exactly. I can’t figure it right now, but there’s like a
Federico Ramallo (34:54) Mm-hmm.
I
think you’re talking about craftsmanship, right?
Kasper (35:07) Yeah, it I guess to a degree. It’s not so much about a craftsmanship. To me, it’s more about the the i I I guess for me it’s more about the s kinda I at least for me, I like having my ears close to the ground so I still have a sense of
What are we even doing here? I think some people talk about how when they use DLM stuff, like it’s going fast and that’s cool. but then it’s like, well, what is right? What happened, and what are we doing? And so they start losing touch with what the code base is actually doing. And so there’s a little bit of a loss in terms of like what the hell is it? It is like an eye word, it’s not intuition exactly, but there is like a it’s not integrity either. I can’t think of it.
Federico Ramallo (35:28) Mm-hmm.
Yeah, but w what you’re describing is that you you don’t know, you cannot trust the co the code that you don’t seen first hand yourself, right?
Kasper (35:48) Not exactly. It’s more about for me it’s more about the the problem space itself where sometimes what I hear from people that are very into the limb stuff is like, well you also have to verify it. And I’m like, okay, but then how are you doing that? And so for me at least, and they kinda have to know a little bit of what how they want to solve the problem to be able to verify it. And so I’m like, okay, but then some that’s this riffing stuff is my approach to that aspect. How do we actually explore something
And how to actually get in there and play around with this problem space a little bit to have a sense of it and you can understand where some of the the issues might be lurk or whatever. And you can also help de-risk a feature because it’s like, well I’ve at least mapped aspects of it out and then you can figure out like sometimes I like to say that you’ve settled the organizational skeleton around something, where it’s like, all this piece is actually its own thing. I thought these two were together, but they’re not. And so I could generate this stuff with
But whatever you want or whatever. And then you could focus more intently on the bits that are now the the unclear parts. So it’s kind of weird. You end up generating like a map of sorts. I was talking to someone else that just like I’d done YouTube videos of this stuff as well where you can see it online if you want to. Because it’s a little bit easier to see how it actually works. And someone else has just seen it from there, they’re like, I think I’m gonna try to do this. And they were more of a senior person than they brought a junior along. And I think they had like a
two hour session or something, where like looking at a f some sort of feature they were building out and they were just like sketching this out over time and then eventually it was like, Okay, I think we’re kinda done here and then they left a few comments in there for some of the other things that they had also then thought about. And you just grabbed that whole piece of Ruby code and paste it into like a Euro ticket because it was a map for where they needed to go then. so it’s been really useful. That’s the same experience I’ve had, where it’s like, okay, now I kinda have a rough sense of what it is I actually want this to do. and that’s been really useful for me. Yeah.
Federico Ramallo (37:26) Interesting. That’s interesting. Yeah, the I I think that one of the interesting things about HNT coding is that you can you know, move faster, but you kind of lose the granularity of what’s going on within the code, right? and the it w for me it works great. For instance, I I’m I’m finishing my book, right? I I I think I told you this before, but
and I had I I had to review a lot of, you know, the e editing and things like that.
So what I do is I’m converting that into an audiobook, right? So I can listen to my my my my my book and the changes and then I’m thinking about it. you know, does the story make sense? It kind of sounds like somebody else wrote it, right? I kind of you know, it’s different when you when you read it, you type in read it, it’s kind of one channel in your mind, it’s a different channel in in the ear, kind of, right? so I can pick up my son to school and I have like thirty minutes of of just listening for, you know, a few chapters.
So anyway, I built a a tool to do that and I I I work with with Claude and say, okay, what what is the most the fastest way that I can do the audio conversion? And basically you know Claude said
We should build it with Swift, we should build it with A N E, right? The the a the text to speech engine, right? And so we kind of went through different options. I don’t know I don’t know Swift and I said, Okay, let’s go and build it, right? So it built it. I kind of I I review the code even though I don’t know the syntax, but you know, it was fifteen times, twenty times faster than the previous tool that I was using. So it was
Kasper (38:43) Yeah.
Federico Ramallo (39:02) good enough right for for my my my internal audiobook tool thing, right? what I’m trying to say is that for that scenario, you know agent decoding is great because it can move faster. I don’t need to learn Swift. Probably the code is not as good as if if I know Swift and I read it and I realize you know what, it’s this is you know their design issues, right? When when I when I write Ruby code with agents
and I read it, I realize that it’s lower quality that I would write, but I haven’t had to write it. So I can provide that guidance and say, okay, these are the requirements, this is what I want to build, these are the rules that you need to follow. And then with that it does a much better job, even though I had to do iterations with the agent to kind of improve the quality of the code. But it’s for a lot of things where good enough is good enough, then it works, right? but
I do feel that I that I’m losing that craftsmanship where where I could you know, if if I have the time I could build it so, you know, beautifully compared to what agents could do, right?
Kasper (40:05) Yeah.
Yeah, for me it’s more just like staying close to that problem space that we’re actually looking at as opposed to like the ultimate code shape or whatever. Because it’s not so much about that for me. Like the other thing I get out of this process is also just because I’m kind of dispensing with a lot of process, like I’m not necessarily running migrations, I’m not necessarily doing separate files. So it makes it a lot easier for and also not necessarily doing git commits because it’s a little bit more like a rough first draft of things of what do I actually think here and where I think I need to go.
I end up exploring a lot of like alternatives and also like naming as well of just like, it’s actually a lot easier just to change something because it’s just in this one like slightly messy scope. and you might get working code out of that, you might not, but it’s not really the point of the process. It’s more about like having that sense of exploration, and then you can also like surface a lot of stuff that you might not have seen if like an LM just generates you like whatever, and you’re like, Well, where’s the noise where’s the signal and all this stuff? I don’t really know, but at least for me, doing that.
Federico Ramallo (40:52) Right.
Kasper (41:00) exploration up front helps me find that and then you can always have an LM help generate. So it’s a little bit like a different flow you’re like you’re talking about where like you’re doing the iterations with the LLM where I might start iterating for myself first and just doing all the parts that are like relevant. And then after that you could go in and do an iteration there. But at least for me I find it that’s relevant to still have I don’t lose that sense of like what’s actually going on here. And then you can like spot things when you didn’t see the LLM output whatever. At least for me. But you know
Federico Ramallo (41:17) Right.
Right. W what you’re talking about is more on the designing the under san and yeah, designing and understanding the the problem, right?
Kasper (41:32) Yes Yeah.
Yeah, yeah. It’s actually my friend Jeremy Smith who did the the YouTube videos with, he had a great way of phrasing this because he’s doing a lot he’s done a lot of design stuff. He is now a Rails developer and also hosts the Indie Rails podcast and you know stress watching stuff there as well. but he had had he knew about this idea of like the design phases where there’s both like convergent at the end and but it also it starts with like actually being divergent. And when I think sometimes in like
maybe the rail space in general, I think we’re only looking at the convergent phase, where we’re thinking everything’s just like close to done and then we’re just like
We just collapse everything and then we’re done now. but what I find is I would like to be a little bit more space for like like divergent thinking in the start where things the problems just seem to grow and like you have no idea what’s going on here and like where’s this and what are we even solving here or whatever. at least I find it that’s helpful to have that space. a little bit more open-ended, a little bit more breathing room to also like think and figure out like is this yeah, we could generate a whole prototype with this, but it what is that actually gonna tell us? Do we what do we even know about the problem?
So it’s more about like that problem exploration as opposed to like the the pure execution faster or whatever. which definitely has a place like you’re saying in like the good enough scenarios, but I’m like yeah, yeah.
Federico Ramallo (42:44) Right, right. Yeah. Makes sense. Makes sense. Very interesting. Awesome. So you know I we’re r almost running out of time, so I want to ask you one one last question. What it’s w what is the future for you? What are you looking forward for you know for the next year or so?
Kasper (43:02) Yeah, I for me it’s actually R V. We’ve been working and Spinelli be working on this tool called R V that helps manage Ruby’s and like we’ve done some work on like a port homebrew, we’ve they have like a pro portable Ruby thing so you can compile Ruby and move it to separate directories. There’s a whole thing there. Andrew just did a talk on it that explains it much better. But the idea is like it’s a Ruby manager for the future essentially, where we’ve done a little bit of work to make sure we can compile pre-compile Ruby. So you can install Ruby in like a second. So you could do Brew install RV or
Rv Ruby install and then like you basically have Ruby right there. instead of waiting for like five minutes for it to install and everything. and then the other thing we’re looking at there is also well what if it could also manage dependencies or even generate its own tools? I forgot to say this at the front, but it’s inspired by Python’s UV, and that’s also where the name comes from. so there’s a lot of interesting stuff there like
Again, if you do like Brew install RV and then RVX Rails new my app, then you could be like up and running for like a new Rails app, like within less than a minute at least, you know. I don’t even know. Like I can’t remember how fast it is to install. It takes a little bit compile some of the the gems, which we’re also looking at. But that’s kind of where I’m at. Actually that’s one thing. And then another thing is we’re also building gem co op. I’ve been working a lot at the domain modeling there and like fixing all the issues and figuring out what else we want to do because I’m kind of curious about
what else we could do for like the package recreation side of yeah, how else can we can we shape some of these things? Because I have some ideas there I wanna explore. So that’s where that goes.
Federico Ramallo (44:23) Interesting, interesting. Yeah, because the I mean I remember the there was a a gem many years ago that would take your Ruby applications and compile it into a single binary, quote unquote, because it wasn’t a binary, it was just, you know, a
package right of of of Ruby. it was this idea of running binary, you know, to to to make a single file for a for the application, right? yeah. But but I I do like your approach of R V because it’s you know it’s it’s something that would allow us to pack package you know pieces of of code, functionality, you know without having to deal with the hassle of installing Ruby and everything else, right?
Kasper (44:48) Yeah, yeah.
Yeah, and like my big wish would it is a sense that it could enable
like a whole new era of Ruby tooling because it makes it a lot easier to like send a script to someone because you could do the what is it like the the sheep bang, whatever, like exclamation marks slash user slash bin slash and and then you could do R V X or I can’t remember the syntax right now. and then if you have R V installed, that’s all you need. And we like install Ruby for you, we’d install dependencies for the script as well. And so then you can be up and running in like very quickly. And so that would enable a lot more people to ship things in Ruby.
Federico Ramallo (45:11) Right.
Right.
Kasper (45:37) where I think, you know, right now the way people install Ruby is what you Ruby build, which compiles on your machine, which makes sense. Like that’s how we’ve done it for a long time. But I think it actually misses
It doesn’t let new people join as easily because they look at stuff like Python now or like Node or whatever where in they don’t have to wait five minutes. So why do we want to look at Ruby? And so I think there’s something interesting there of just like moving that goalpost to be like we can actually catch up to this stuff and make it really fast to get someone else started. So people in your team where they might be front end people and they haven’t really looked at the Rails back end, all of a sudden it makes it a lot easier for them to get started because if they have a working home brew installation, they can just brew install RV and then be up and running really fast. That’s the goal at least.
to have more people try out Ruby and be able to like run it locally and they have a full install they could do whatever with it and then, you know, they can use a tool that might happen to be written in Ruby and they don’t have to care, essentially. so that enables more people to write more tooling in Ruby, because it’s a lot easier to get triple started. For all the reasons that we want people to write in Ruby, you know, as opposed to like C or whatever. You know, it’s not gonna be the fastest, but it’s gonna be like you’re saying good enough earlier. More than good enough.
Federico Ramallo (46:27) Right.
Yeah, for for for small tools, you know, command lines interface or things like that, I think it’s very powerful. And with all the mature gems that we already have for databases, you can actually build a much more complex application and just say, you know, R V run application and boom, you have it running, right?
Kasper (46:56) Yeah.
Yeah, exactly. Yep. Yeah. You could use like Actual Record or the SQL TM and then connect to maybe like a SQLite thing locally that runs there and then it could do stuff for you and store I don’t know. Whatever you want to do with your local analytics, I don’t know what you want to do, but like, you know, that that’s up to the tooling developer, but stuff like that essentially.
Federico Ramallo (47:14) That’s amazing. Yeah. Looking forward to see how you take that to the next step because I’m I’m interested in that, yeah.
Kasper (47:20) Yeah, yeah. I think the next step is like RV is now at like zero point six, so it’s still, you know, development and everything. But the next thing is like point seven release is Rv Sync, which du with sort of functions similar to bundle install. So it’ll just like read your gem file and like figure out w how to resolve it if it needs to, and then install other dependencies. We already got RV clean install, which is analogous to bundle install dash dash frozen.
Which is what you do for deployments and that’s pretty fast. we’re I’m using it locally for Gem Coop and it’s just like installs pretty fast. The slowest thing now is like installing having to pre-compile GEMs. So that’s another thing we’re looking at, where like can we pre-compile those and ship them to people? So we also just like we do for Ruby now, the Ruby installs and make that really fast, because then we can install everything in like less than a second, you know, and then it would stop our running really fast. So that’s the that’s the goal.
Federico Ramallo (48:08) Interesting.
Interesting. Yeah. I I’m interested in running R V run JKL and then being able to compile this the site. because I’m I’m using what is the name? Cloud Cloudflare, right? And basically what it does is install all Ruby installed, you know, Jekyll, install the gems, everything. So it takes like five minutes to then run the the static site. And and I’m thinking, well if if we have an RV run JKL then that would be, you know, mind blowing.
Kasper (48:17) Yeah, yeah, that’ll be really cool.
Yeah, yeah, yeah. I I’m pretty sure it would already work for that almost. Like if you have a result, if we have like a gem file to log already, then I think it should work by now. Probably. I mean we could try it. I haven’t tried it with Jekyll, but yeah. Hopefully soon. Yeah. Yeah, perfect. Cool.
Federico Ramallo (48:41) Nice.
Maybe, yeah. I’ll I’ll let you know when I do, yeah. Casper, it was
truly a pleasure to have you here today. We’re running out of time, unfortunately. but yeah, I’m looking forward to to stay in touch and you know and I’m wishing you the best on this new co op, because I think it’s an you know, innovative, new new way of organiz organizing the team and I I wish you all the success.
Kasper (48:56) Yeah.
Yeah, thanks so much. Yeah, and great to be here. yeah, if people want to learn more, this is spinel.coop. That’s the way you you get there and then you can see more about who we are and what we’ve done so far on our blog and that’s what we’re right about R V as well. So yeah. Cool. Thanks so much. Yes. Perfect.
Federico Ramallo (49:25) Great. we’re going to leave the links in the description before be below. Yeah. Thank
you, Caspar.
Listen on your favorite app