The Ruby Gems Podcast
A Ruby Central podcast that takes an inside look at the people, projects, and progress shaping the Ruby community. Discover the gems in Ruby and connect to this vibrant group of amazing people.
The Ruby Gems Podcast
Evan Phoenix: From Rubinius to Ruby Central
In this episode of the Ruby Gems Podcast, hosts David Hill and Marty Haught sit down with Evan Phoenix, a notable figure in the Ruby community. They discuss Evan's contributions in the Ruby space, including the development of Rubinius and Puma, his role in solving scalability issues for Rails developers, and his tenure on the Ruby Central Board since 2011. The conversation also delves into Evan's journey with Ruby and his fascination with how things work. Additionally, Evan shares insights on the importance of maintainership in open source projects, the evolution of Ruby Central, and the impact of the pandemic on the community and conferences. Evan wraps up with his current ventures and thoughts on the future of tech and AI in coding.
Welcome to the Ruby Gems podcast brought to you by Ruby Central, where we uncover the stories behind the code. We're your hosts. I'm David Hill.
Marty Haught:And I'm Marty Haught. Today, we're joined by a prominent figure in the Ruby community, Evan Phoenix. You might know Evan as a creator of Rubinius, a pure Ruby implementation with a focus on performance and concurrency, or the architect behind Puma, a high-performance web server that powers countless Ruby applications. Evan has solved critical scalability challenges that Rails developers face every day. Evan joined the Ruby Central board back in 2011, where he helped organize RubyConf and RailsConf, as well as played an important role with the operations of RubyGems.
Evan Phoenix:Thanks for having me guys. Great to be here, great seeing you all recently as well, that is true RailsConf concluding just last week.
David Hill:It was a lot of fun to see a lot of old, familiar faces for not the last time but the last time at that particular gathering I guess. Hopefully at the last time it didn last time at that particular gathering, I guess.
Evan Phoenix:Hopefully at the last time it didn't feel that much like a funeral.
David Hill:Thankfully, I admit part of my feelings about it were probably biased, since I was more involved in this one than I have been in any previous RailsConf, but I felt like this was a right shunning moment for it.
Evan Phoenix:My feelings were also biased, but that's because I wasn't worried about what was going on. I wasn't like, oh my gosh, like did we have enough coffee at the conferences? One thing that I always enjoyed about conferences is that the majority of the stress is beforehand, even like two weeks before the conference it's happening. There's kind of nothing you can do. At that point the train has left the station, and so when I would help run conferences when I was there, I would always just be like let me find something to do. Like did the AV work? How are people liking the Wi-Fi? What's the coffee situation? Do I need to go complain to the catering staff to be like come on, guys, you got to put more grounds in the coffee. I didn't figure that this time, which is great, so that kind I didn't have to do any of that this time, which is great.
David Hill:That kind of dovetails nicely to the initial question I wanted to ask to kind of get you started, Evan. I believe this is your first RailsConf kind of back on the stage since leaving the board. What was that like coming back and being on that stage again with that group of people?
Evan Phoenix:It was great. Honestly, I've missed them. It was great seeing them and getting to kind of work with them a little bit to see them see how things were going again, because while we all work remote, we've all worked from home for a long time. The conferences was always a time where I would like actually get to see these people and spend lots of more concentrated time with them.
Marty Haught:So so I want to talk about Rabinius. So I remember, back in 2006 in Denver, I was sitting in the audience next to Aaron Patterson by the way, my hair was much browner at the time.
Evan Phoenix:Yep, right yeah.
Marty Haught:I wondered at the time what motivated you to do, Robinus.
Evan Phoenix:So I'm always fascinated with tools, small tools. It's an inherited trait from my grandfather. We have this great story about my grandfather that when he was a little boy, he was just so interested in how this alarm clock worked that he stole it off his parents' bedside table. He took the alarm clock apart, figured out how it worked, couldn't get it back together, buried it in the backyard, right, like and I've heard that story many times, partly because of the adults in my life would tell it to me because they're like, yeah, we kind of see a similar thing going on here. Honestly, it's true, right, I am a connoisseur in how things work. I love the idea of, like, what is this thing doing? How does the refrigerator work? How does our airplane work? How does the refrigerator work? How does the airplane work? How does my arm work? Just a constant fascinating thing that runs in my head. I'll see things, and so when I got into programming that's a great discipline for someone who wants to know how stuff works, because you're making stuff work for the most part. But I started working on doing Ruby stuff in really 2002, I would probably say, and so I had worked a little bit on programming languages prior to that, and when I was in college I worked with a friend on a programming language and then I got into Ruby and I kind of he went off and did his own thing. And so there's a hazard, though, in wanting to know how things work when you're a programmer, because eventually you're like this tool is so much fun, I can do these things and I can make these programs work, but how does it work work? I would eventually find myself looking at, like, the source code of the Ruby interpreter and trying to figure out like OK, well, how did it implement threads and how did it do this and how does this work? And, partially, it'd be to help me know how to write better programs. Once you know like, oh, these things are fast, these things are slower, this is powerful and this is not powerful, whatever, you get a better sense of how to hold the tool, as it were. And then, as time went on, I was like is there better ways to do this? Is there different ways? And I would just talk with people. And then I got introduced to Smalltalk not actually writing any Smalltalk, just Ruby took a lot of things from Smalltalk, and Smalltalk had a whole like code VM and it was in a book and the book is right over here. It's called the Smalltalk Bluebook and it has a little how to implement a Smalltalk VM in the back. And so I was like, well, this is so interesting because you can see like all the machinery Now the guts are exposed, and so that's really where I started Rub and so that's really where I started.
Evan Phoenix:Rubinius is sort of like phase three of this sort of like interest. The beginning was this sort of like oh, how would this work? The middle part of that stage two was I wrote a bunch of patches. I started writing patches for MRI not necessarily for bytecodes, but like there's a patch it's sort of lost to the winds of history, I think it's on Shugo's server somewhere still for adding like native threads to Ruby 1.8. And I got it working well enough. It wasn't good enough that you'd want to use it for anything, but it was very instructive for me.
Evan Phoenix:And then I started sort of like phase two and a half. There was like what if we just started a new sort of second system syndrome kicked in? And I was like what if we just started a new sort of second system syndrome kicked in? And I was like what if we started over? How hard would that be? And so the sins of that question are all still.
Evan Phoenix:I would invite listeners to go look at the Rubinius repository on GitHub, because you can go back to the very, very, very beginning of the Git history of that thing and you can see the very first experiments, which were basically a bytecode interpreter in Ruby that ran on MRI and used FFI to access raw memory so that it could write its own garbage collector. And there's a whole journey in there, right? And so it was so much fun to be honest with you. It was so much fun to just make a thing and make it work. That's the normal programmer thing, and when you're working at this really low level, the thing that you're making work is like a thing that makes more programming. For every little construct that you make work, you make an infinite number of new programs work, right, right. So that's almost intoxicating idea to me and so kind of just spiraled from there.
Evan Phoenix:I just kept working on it. It just kept going.
Marty Haught:You were at Engine Yard at the time or was that before? That was before Engine Yard, right.
Evan Phoenix:Yeah, it was before Engine Yard. I was working at some startups in Seattle at the time and when I gave that talk the talk you're thinking of in Denver at the hotel by the airport, I had this cool thing and I didn't know why people would use it. I was like, how do I evangelize it? Is it important, is it not important? I didn't really know and so I just submitted a talk about it. That talk sort of famously for people who remember it is the dune buggy talk. Basically, I gave this whole talk there.
Evan Phoenix:Ruby 1.9 was sort of starting to take legs at the time. There was a bytecode VM that was being worked on and I gave this whole thing about how Rubinius was going to be the dune buggy to MRI's dump truck and it was something that you put together. It's going to be the dune buggy to MRIs dump truck and it was something that you put together. It's going to be faster, it's going to be more agile. It might crash, you might get thrown off of it occasionally, but it's going to be a little bit maybe more fun than driving a dump truck around. There's a strange analogy, but it worked.
Marty Haught:Yeah.
Evan Phoenix:The culmination of it was that I talked at RailsConf in 2006, which was in Portland, about Robinus, in like a tiny side room for some reason, and then Tom Roney, the CTO of Engine Yard, said we love what you're doing. Are you looking for a job? Like obviously you're super smart, you've done a lot of Ruby stuff. Engine Yard would love for you to, like you couples, work on this. You can work on Rubinius at the same time, and so then that's how that sort of just came about.
Marty Haught:So you did get to spend some of your time at Engine Yard on Rubinius.
Evan Phoenix:Most of it, the way that it started was they were like we'd love somebody who just knows Ruby around, knows Ruby really well, and then we want you to also work on this thing because we could maybe benefit from it eventually.
Evan Phoenix:And so that was the first time really getting paid to work at open source, and that was the first time really getting paid to work on open source, and so I didn't necessarily manage it all that well. What I would do is I would like work on the open source for a week or two weeks, and then I would switch back over and be like hey, what do you guys need help with? So I would like disappear for two weeks at a time, and every time I would come back the team would be like take us too long to tell you what has happened in the last two weeks. And so this cycle only happened like two or three times before. Tom was like you know, I don't worry about it, just work on rubinius full-time. And so that was three or four months in, and then I just worked on rubinius full-time for the next five years we're maybe doing these questions a little not in the most ideal order.
David Hill:that's fine, but for those of us like me who came to ruby in the ruby community a little late and didn't really have much exposure to Rubinius other than occasionally hearing the name, could you tell us what Rubinius was? For people who may not know, so Rubinius was a Ruby implementation.
Evan Phoenix:So you would download it, you would run it, you would compile it. It would run your Ruby programs. That was what it was designed to do. Why would you want to do that? Well, there's a bunch of limitations, there's a bunch of architectural decisions that the main Ruby interpreter, which is sometimes called CRuby, is sometimes called MRI for a massive Ruby interpreter CRuby now, because math doesn't work on nearly as much as other people. But so why work on it differently? Well, at the time there wasn't Ruby, the was not even a bytecode interpreter, so it was pretty slow.
Evan Phoenix:And so the idea was like hey, how can we bring techniques from the 70s into here? How can we basically just bring to bear all the different techniques? So it's like a bytecode VM. Let's look at what cool garbage collector papers there are. How can we make the garbage collector faster? Oh, we can do just-in-time compiling of the code into machine code. Oh, we can also say like oh well, you want real concurrency, we can add real concurrency so we can have real threads. You can have two threads and they can both take up CPU cores. This was like 2006, 2007, right? So we were at the sort of beginning of the multi-core revolution for computers, and so the idea like, hey, we've got multiple cores, multiple threads, you should be able to eat them both up if you really need to. And so that was the reason to download and use Rubinius Critically for a number of different reasons, both good and bad I guess I would say both in the definition of critical here.
Evan Phoenix:I had decided to write as much of Rubinius in the Ruby language itself. So one of the other things that people took slight umbrage with and it's not that big a deal was that CRuby was written in C. It wasn't written in Ruby. There's almost no Ruby code in Ruby itself at the time. And so if you wanted to go add a new method to string, you're going to write a bunch of C code. If you're going to add a new built-in class, you're going to write a bunch of C code. If you're going to add a new built-in class, you're going to add a bunch of C code. You're going to do all that stuff.
Evan Phoenix:You don't know how the interior worked entirely, and in Robinus we were like you know what. Let's try to have a clean separation between what is the engine and what is the standard library or what we end up calling the kernel because the standard library was already taken as a term and so you wanted to implement string. Let's go implement string. So there's a file you can go look at in the kernel directory called stringrb, and you would implement string. Now we'd eventually sort of cheese our way out of a few things, right. So some things would be just way too slow. So we basically had the ability to glue in a primitive operation which is a term from small talk into a Ruby function so you can say like oh well, when someone calls this, I actually want you to go call this little chunk of code that is written inside the VM. But by and large, you should eventually reach the end of that pretty quickly. And then you'd be like okay, great, I want to go in from that. Each iterators and stuff like that are great examples, right. They're actually much easier to deal with in Ruby code itself than in C code, where you have to do a bunch of weird callback structures and all that kind of stuff.
Evan Phoenix:And so that decision to write it all in Ruby meant that I had a lot more people contributing to it.
Evan Phoenix:Mri didn't have a lot of contributors at the time. It had probably a core group of about, say, five to nine, and I could get five to nine contributors in a day. Right, I could just say like hey, like go out a new method that you haven't added, where do you add it In Ruby? And then so it was easy to get contributors, it was easy to move up from there. We don't have to end here. But I would say, like one of the interesting legacy parts about Rubinius, in my opinion, is that the idea of like hey, let's write more of this stuff in Ruby is now in CRuby as well. So they have basically started to convert more of their code into Ruby. Now, I'm not going to say I'm the genesis of that idea, but I'm glad that the idea that I had has sort of seen its way through to the conclusion. It is now it's easier to contribute to CRuby, now it's easier to write new code for it and all those sorts of things. That's been great.
David Hill:So after Rubinius, I only learned about this wrinkle in preparing for this episode that you were kind of originated Puma, which kind of is the de facto web server that powers a lot of, if not most, ruby applications these days. Can you tell us about that and how that came about?
Evan Phoenix:Absolutely so. It was, I want to say, 2011, 2012, something like that. We were hard at work, working in Rubinius, and I wanted websites to be like oh, I run Rails on this, what does that look like? Or I run Siddhartha or whatever at the time. And so what does that look like? And I wanted to have Rubinius be able to put its best foot forward in terms of like, hey, it's got concurrency, it maps. Well, it's got threads, it's got all the things that make sense.
Evan Phoenix:There were other web servers out there at the time, but none had sort of been optimized with the eye of like okay, well, you've got threads that you can just use for various things. You know famously, webbrick, the web server that's built into Ruby itself. I don't know if it still does this, but it did this at a time. It spun up a new thread for every single request, which was actually super great on Ruby 1.8, because threads were super cheap, they were green threads, they were not native threads, and then it became pretty bad as time went on, and so I wanted to say like okay, great, like, what does it look like to have an architecture that looked like this? Say like okay, great, like, what does it look like to have an architecture that looked like this.
Evan Phoenix:Simultaneously, zed Shaw, the original author of Mongrel, had sort of grown tired of those petty squabbles and had sort of moved on, and so Mongrel was not really being worked on anymore, and everybody was like, oh, do I move to Unicorn, do I move to this, do I move to that? And so it felt like there was a good place to say, like, okay, I want it to work. Well, for my thing, there's sort of a hole in what people are looking for in terms of like, what's maintained, and so I was like, let's just take, one of the best parts of mongrel is the parser, the actual http parser, which we still use today. That's the http parser that puma uses. Let's take that, and let's basically like recraft the outer shell, entire outer shell of like what does it look like to work, to be a web server on top of that existing HTTP parser? So that's how it started. I also was careful to not have it be Robinus specific, though, so I wanted it to be optimized for the patterns that rabidius was good at, but not like laced with things that say if not a rabidius throw, get a life. None of that, not expecting that, oh, rabidius has this one super cool quirk that'll make hgp super fast, like none of that stuff, right, just center of the road sort of behavior. On the actual implementation, and so what that meant was that you could use it anywhere. You could use it on anything that supported all the normal things, and we were careful to also, therefore, not get too esoteric with the implementation, and what that meant was that it was easy to use, it was easy to download, it worked mostly the same as people were accustomed to, and we were maintaining it.
Evan Phoenix:The story of Puma is one of maintainership more than anything else. Right, we wanted to build a thing and we figured out how to continue to build a thing. There's a whole long tale conversation here about open source maintainership, energies, and so I can't even remember what year this was. It was 2017, maybe, maybe 2018. I approached Richard Schneeman and Nate Berkopecht.
Evan Phoenix:Richard was working at Heroku at the time. He might still be there and he had written a whole thing about hey, if you want to run your Ruby apps on Heroku, puma is the best way to do it. So there's a whole article that they had written, and I was like, oh man, we've reached it, we've reached. I've reached the mountaintop here. But I also was like Richard should just be a maintainer, like if he's like, hey, this will work better on Heroku, then I want that stuff in Puma right At the same time, nate Broker Peck was working on performance stuff, which he still is working on, and so I went to them and said would you help me maintain this thing? Because I knew that maintainership was the most important aspect that Puma had at the time was that people were like bugs still get fixed and things get implemented and security fixes get fixed and all those sorts of things, and so that was the other really important part of it.
David Hill:I'm glad you went down that trail of the maintainership because I actually kind of wanted to ask about that. That's kind of been an ongoing conversation in Ruby and Rails for a while now open source maintainers and contributing back and kind of helping maintainers not get burnt out on doing this thing that they're not getting paid for, compensated for in unusual ways. Do you have any thoughts on what we as a community can do better in that area?
Evan Phoenix:Something the community can do is don't look at the like Git history or the release history of a gem or a piece of software as an indication of its usefulness. There is a thing out there that's like oh, this thing hasn't been updated in two years, it probably doesn't work. Move on, this is not that new hotness. I actually want to normalize people writing finished software. I want everyone to have a piece of software that they're like it's done, I'm not doing it anymore. I have a piece of software like that for myself, where it's like it does exactly what it says in the tin, nothing more. If you want other stuff, feel free to put stuff somewhere else. Like, I'm not going to just keep glomming on features and glomming on features, right. So in that same way that, like, frequency of release is not an indication of usefulness, don't also think like oh, I've got this great idea, you should implement it. Or here's some half-assed PR of a feature that only I need. Can you just merge it and live with it, because the maintainer now has to figure out what do I do with this long term, right? It's not a one-time burden, it's an infinite burden, and so maybe that's the flip side of things is like maintainers should be careful in what they accept. That's not to say they shouldn't accept things. I'm a big fan of open source, but you should think you know what this is a domain.
Evan Phoenix:The better conversation is to say okay, person who's suggesting this, pr, how can I do the minimum so that you can do most of this work? In other words, do you need a hook point? What do you need in order to basically release this code on your own that you can go off and work with? Right, it's hard. A lot of software out there is. It does the thing I haven't looked in a while. I would be surprised if not something I work on in a while. I would be surprised if not something I work on, but something else. I would be surprised if Nokogiri has gotten significant API changes over the course of the last five years Because it does the thing I needed it to parse and manage XML and HTML and all that stuff it does. That. Can we just call it done? Yeah, you still take bug fixes here and there, but like it's done, I think that that is a much more interesting and healthy place for people to arrive at. We don't need to be innovating on everything all the time.
Marty Haught:So with RubyGems. I know you did some work with RubyGems. How early did that interaction start? Was that once you were at Ruby Central or was that while you're at Engine Yard?
Evan Phoenix:Yeah, I mean RubyGems, the client software was before that. That was 2009. So there was a time when RubyGems, the client software, was and this is a great counterpoint to what I have just said kind of seen as a piece of done software. It did the thing. It did gem install and that was what was needed, right and lo and behold, that wasn't necessarily the best workflow. This is right before Bundler and people were inventing things like the old config gems file that would just have a list of gems to go install. This is sort of in Rails two days.
Evan Phoenix:And then with Rails 3, Carl and Yehuda had worked on Bundler and that had come out and that had been like, hey, this is a much better way of managing things. So they were innovating. The Ruby gems was doing almost nothing. Bundler was basically like building on top of Ruby gems and none of that stuff was actually in Ruby gems. Like building on top of RubyGems and none of that stuff was actually in RubyGems. And so there's some work, both on the Rubidio side as well as other places, to say like, hey, how can we just make RubyGems better? Bundler is going off on this. It's found all these deficiencies. How can we basically fix those deficiencies and put those into RubyGems.
Evan Phoenix:And so there was a little bit of competition at the time. Like I said, this is like 2009, 10, maybe. And so a little competition about hey, could RubyGems just take all the functionality that Bundler has? And you can go back and look at the RubyGems releases. We started to do that. I wrote a dependency analyzer that was similar to Bundler's superior, in my opinion, to Bundler's at the time, mostly because it didn't run out of stack space. There's a whole long technical conversation here about the original algorithm that Bunder used. But we were like, okay, great, we're inside RubyGems, we've got more access, we can basically wire stuff in a little bit more to have it just work more naturally. And so that was kind of how it started. I was obviously inside RubyGems anyway, because I was putting RubyGems inside Rubidius as well, and so there was sort of this natural place. And so there's a few of us who were just like kind of tinkering, like let's work on RubyGems and add the client software, because it wasn't getting much work at that time.
David Hill:Well, that kind of brings our set of questions up to Ruby Central itself. You were so tightly involved with it for so long. How did that begin for you?
Evan Phoenix:RubyGems actually. So what happened was it was specifically with RubyGemsorg. So I'd been working on the client software on and off, and just me and a few other people had been doing that. So Nick Caranto had written GemCutter and then Chad had come or whomever had come to Nick and said, hey, we just want to make this official RubyGemsorg, because the way that we're running RubyGemsorg is insane. Which was this whole thing where you uploaded a gem file to RubyForge and it would scan them and they would add them to the index, and it was weird. And so Nick's was far superior and so it was like, OK, they had already taken that on and they were running RubyGems, GemCutter, as RubyGemsorg at the time. And there was still RubyForge up. It still existed. It was in a Rackspace Colo machine that was maybe one machine, I want to say and it was running RubyForge. It was running RubyGemsorg, the GemCutter software, and it was running rubyforge, it was running rubygenorg, the gem cutter software, and it was effectively a one-man band being run operationally.
Evan Phoenix:And so I offered to say like, hey, like do you need help with this? I'm worried that this is just a one-person thing, like we'd love some help. And so I started helping out with that. And then I ended up going to RubyConf, New Orleans 2011. And I was not yet really on the board or anything like that, but effectively I think I'm going to start helping out. And then I just saw a zillion places they need help. I just saw a zillion places they need help and so I started just oh, I'm doing this, I'm checking people in and just like kind of just doing that thing.
Evan Phoenix:And then Chad asked me a little while after that, like why don't you just be a Ruby Central Director? You're well known, you've got all these things. You come on, you can help out with rubygemsorg, and then we can figure out what that means from there. And I was like sure They'd been doing it for like 10 plus years at the time, and so I think they were naturally looking for how do we evolve this situation so that it's not just dependent upon them to spend their spare time on? And so I was like, yeah, sure, yeah, that's how I started. Those early trails are rubyjumpsorg as well. We're crazy. I got triggered at RailsConf people bringing up debugging inside IRC sessions and stuff like that. But we can get into that. But yeah, that was sort of the beginning of me at Ruby Central.
David Hill:The responsibilities that Ruby Central has now versus then have changed quite a bit over the years. What's your take on how the organization's kind of evolved over time?
Evan Phoenix:It's what it needs to be. By that I mean that the organization existed originally to run conferences, but the charter for the organization which doesn't really matter, but I think it's just interesting is actually just the betterment of the ruby language community. That's effectively the charter for the non-profit. It's nothing to do with running conferences or anything like that, and so the conferences were just an obvious vehicle for that. Rubygems became another obvious vehicle for that, and I think that we have the benefit of hindsight to look at how that's been managed versus how other communities have ended up managing. It is that the organization taking on more, taking on RubyGems, taking on scholar programs, taking on all the stuff that has taken on has proved to be wildly successful and also what the Ruby community needed at the time. I am so glad that RubyGemsorg is actually run and paid for and administered in terms of policy by a nonprofit that is not looking to like oh, we need to make money off this thing. That's just like. No, it's just here because we want the Ruby community to have it. We want it to be the plumbing, the scaffolding that the Ruby community exists upon. There's a zillion reasons why that's better than a commercial entity working on it. So I think that's one aspect to it right. I think a lot of the other things were grown not out of strategic consultant mindset, but instead of just what do we need to do this next time?
Evan Phoenix:I think that when Marty and I were running it in those early days with Sarah and Abby and Heather, I think that one of the things that we would always look at is we can change two to three things each conference. That was about it because Marty and I were doing it part-time, sarah was doing it part-time, abby was a full-time employee, heather was a full-time employee, so we didn't have a lot. We can't just completely overhaul it, but we were also willing to change two or three things each time. That was how the Scholar Guide Program came out. So we're like hey look, let's offer some free tickets. What does it look like to be a person who's never been at this conference before? We should probably have people show them around, great, what does that look like? Right. So we were interested and willing to sort of like tack the ship, as it were. Right, we weren't like this is the conference, this is how it works. It was that every conference we'd have a debrief. We're like oh, let's go in this direction a little bit. Oh, let's go in this direction like.
Evan Phoenix:A great example here is like for a long we'd make jokes about oh man, there's another testing talk, this conference, yet another person has another. Five people have submitted talks about how to do testing and what we learned. There was one conference where we didn't have as many and then what we learned. People were like there's nothing for new people in the community here and we're like oh, that's why we've got to accept those testing talks. Right, we need to tap more in that direction to say like okay, great, it's not just a talk for the people who have come back every single time.
Evan Phoenix:Another great example here is this is small little things that build up right. We started asking in the opening plenary session raise your hand if this is your first Rialto Conf. People don't know this at the time. They probably don't know this at the time. They probably don't know this writ large, but I would say that now on the podcast, we used that information so much, right, so we would basically be like hey, look, remember when we were there last year and half the room raised their hand that they were brand new. That goes into the thinking about what the program should look like. That goes into thinking about what facilities should we have, how should we be managing it? As time look like, that goes into thinking about what facility should we have, how should we be managing it. As time went on, we're like you know what, like we've got a lot of people who are new parents. Let's talk about having a lactation room.
Evan Phoenix:All of those things are built off of reflection about what the community needed, which is actually a great thing about doing the conferences with a regular cadence and with mostly the same team. We could really forge it carefully over time with what the community needed, and I think that, to get back to your question, it's reflecting what the community needs right now. Right, the community doesn't need another. The sunsetting of RailsConf is sad, but the community doesn't need a second Rails conference. Right, rails world is going to go off and do their thing, and they're happy to do that. I think that Ruby Central is like, okay, great, we don't need to do that anymore. What does the Ruby community need from us? Great, let's just do that thing. In many ways, continuing to do the same thing, despite the community not necessarily needing it, is the problem. The shifting is what we should be doing anyway.
David Hill:Are there any kind of common misconceptions about how Ruby Central operates that you've ever run into, that you feel like, oh, how do I clarify this? Over and over and over again?
Evan Phoenix:I said it at RailsCon, I'll say it again for the podcast. There was a time where we had a really well-oiled machine. People would show up and like the t-shirts would work, the badges work, the sessions are on time, the food is there, like every. It's running like a well-oiled machine and people will be like, oh, you've got like a multimillion dollar company running this, right. No, we have like two full-time employees, period, right.
Evan Phoenix:So it was difficult for people for us to explain that when we would be like, ah well, we're running low on money, they'd be like well, why Aren't you a huge company managing this? Or Abby would get these people coming and saying like, well, can't you provide X, y and Z? It's like we literally have two full-time employees. I don't know what you want me to tell you. Our success in doing those things. We appeared to be punching above our weight, but in fact we were just really good at what we were doing Really scrappy, really scrappy. And so it was difficult to actually explain to people oh yeah, we're doing this because people would ask for something and we'd be like we can't do that. It was difficult for us to get that point across. We would say it all the time once we realized that it was happening, but it was really difficult to get across.
Marty Haught:That's easily the biggest one, so wow, okay, I don't think I ever thought about that before yeah, it's interesting because, sarah, you and me were very busy I mean, it was part-time job even though we had full-time jobs, right, and had active families and I certainly recall many times where, like, this is all I can do and it was just so much that we had to do and like we couldn't take on any more. It was just too much.
Evan Phoenix:I think that the other one that was interesting. You learn a lot about running conferences. Running a conference, no surprise, right? One of the ones I was explaining to Ali, who works at Ruby Central now at RailsConf recently, was that there was a time where we were getting a new designer for every single conference. Let's mix it up, let's be interesting. Let's go get a new designer every single time. Let's mix it up, let's be interesting. Let's go get a new designer every single.
Evan Phoenix:And it sucked, like it was so hard to get good results because, again, we're not on top. We can't stay on top of this. We're like trying to solicit from people and we get people who are good, and then we'd be like we'd get a bunch of people who were just no, none of this is good Now, who are just no, none of this is good. Now we have to go off and do the process again, but now, way at the end. So, like what we started doing I don't know when was this Mark? Like maybe 2014? We started standardizing on vendors. So we had Fred Yates, who was our long-term designer, who was like we're going to pay you for a year and we're going to come back to you twice and we're going to need the same assets every single time. I can't tell you the amount of time that it reduces when you don't have to explain the assets that you need to a designer, because it is a massive undertaking to explain to somebody. Okay, I need a schedule page, I need badges, I need t-shirts, I need even different orders and at different times. You don't need to do them all up front Like it was a lot.
Evan Phoenix:I think that was one thing that again made it seem like we were this well-oiled machine because we'd been through the fire and we knew what worked and didn't work. Another one is like it was slightly more expensive but we ended up with the same AV vendor that would follow us around because we would get consistent AV. Then We'd always have the right projectors, we'd always have the right audio equipment, because we went through a few years where we were using different ones and be like, oh, this is terrible, they didn't have this and they have. That turns out if you pay an extra five percent to have this company follow you around, you get quality results every single time. Stuff like that. Nobody sees those things. That's all back of house activities.
Evan Phoenix:Again, as a person who loves to call back to the beginning of this episode. As a person who loves to know how do things work, before this I would go at a conference and I'd look around and I'd be like I don't think anyone knows that the AV isn't very good here, like they're just not on top of it. And I don't mean at our conferences, I mean conferences that I would go to, right, I always am looking for those like how is this running? Is that person in charge?
David Hill:what's going on and so I feel like that's maybe an unknown here. Yeah, that actually kind of helps. A couple of things click in my head. At RailsConf this year I was like, oh, they're using flagrant again to do all of the web page and the design stuff because that's been working. Why reset the relationship with somebody new when they already know what needs to be done? You're just like new design go. Yeah, absolutely right.
Evan Phoenix:You don't have to innovate every single time. What is this community needed? They needed a nice t-shirt that was a decent weight, with a logo that they wouldn't be ashamed of wearing to the gym in two years Great let's do that.
David Hill:So I think this is the last kind of Ruby Central focused question. But the big kind of tide change for Ruby Central was the pandemic. Yeah, Can you talk a little bit about the changes that came from that, what that necessitated for Ruby Central to keep going?
Evan Phoenix:We were real lean there. So the pandemic starts before RailsConf that year, and so it was obvious that RailsConf's not happening. It's going to be in May. Pandemic starts in the US in full in March, april. We made a call pretty early that the conference was off. I'd have to go back and look at my email, marty, you'd know better than I would, but it was probably like the end of March, beginning of April maybe, and so okay, well, we already had sponsorship dollars locked in because we were well into the conference cycle and so we kind of just scrambled to sort of pivot the program online. So then we're like okay, great, no one knows how long this is going to last, what it's going to look like, and the world is still upside down. And so we begin planning for a remote ruby conf pretty soon after rails conf, which is our normal cadence anyway, and we made the decision OK, it's going to be remote. So Abby went out and found, like what's the best way to run a remote conference? How do we do the audio, the video, what does it look like? And we ran training sessions with everybody and we ran RubyConf 2020 remote as well, and it went great. Weirdly, we decided to renovate our house late in 2020 as well, because contractors are actually really easy to find in late 2020. Abby and I were helping to run the conference actually from a rental house at the time. It's a funny time in my mind and so I think the big difference for me is RailsConf 2021. So you know, we were basically a year plus change into the pandemic.
Evan Phoenix:By the time it was hitting like, let's say, november 2020, maybe December. We were like this is not going to happen, we're not going to be able to get back in person for a number of different reasons. But the big reason was the community was like we are not going back to conferences. The Ruby community was telling us loud and clear we're not interested in that, we're not interested in subjecting ourselves to getting COVID. We're still pre-vaccine at this point. Right, and so I've sort of blocked out.
Evan Phoenix:Marty, you could fill us in here in details about the negotiations we started to do with the hotels for RailsConf and for RubyConf. It was a long, protracted situation because we were going to be in Texas that year and they were not necessarily all that interested in us not being there. Because we're like, oh, there's people who are back. We're like, yeah, I get that maybe there are people who are back, but we are not back and so we had to deal with that. That was sort of thing number one.
Evan Phoenix:Thing number two was once we decided that we were going to have it online. What was it going to look like? And so I ended up taking on the bulk of the role in basically figuring out like, hey, we're going to have an online RailsConf, what does that look like? So we start the program work and I end up not really managing my time very well on this and then building out a RailsConf special site to run the whole thing on. That had all these interesting cool features. Again, kind of burned myself out on it, if I'm honest, trying to work on all these cool things because I really wanted to have something that people were like oh, this was worth my time. So we go through that. I get all the cool features working. Shout out to the watch party feature. Still love it to this day. A lot of cool stuff that was going on there.
Evan Phoenix:It was really stressful because, again, it was sort of like our first time running a conference. For instance, the logins didn't work the first day because we had messed up. The emails weren't getting sent out for people to log in and it was tough. It was tough, but we'd also made the decision also to have it be online time shifted. By that, I mean like we weren't really doing much in terms of live sessions.
Evan Phoenix:I think maybe we had one live session or a couple, but it was mostly recorded talks. So it wasn't the end of the world. People just didn't have access to the recorded talks when they thought they were. So after that me personally I was like look, I've been doing this for 10 years. At that point I don't know how much more of this I have mostly because it felt like we were at the place and time where I don't know what the conferences are going to look like going forward. I don't know where we're going to end up, how it's going to feel, all those sorts of things. So I started being like maybe my time not coincidentally, again, I've been 10 years. I've been 10 years with the previous people when I came in. You know, maybe this is a good time to transition out.
Marty Haught:So years it's been 10 years with the previous people when I came in and you know, maybe this is a good time to transition out, so I can't remember what we did for ruby conf 2021. Do you remember that was denver. That was our first in person. Was denver 2021? Okay, 22 would have been portland again.
Evan Phoenix:Yeah, yeah, in 22 in portland is when I stepped down and I think that like the big thing for me coming back to that event and seeing it and being in the Portland Convention Center all over again, which is sort of hey, it started for me right Back in 2006 is really when I had gotten the robinious job and all that kind of stuff it felt very full circle for me. But it was also good to see that there was enough people there that there was starting to be the appetite for in-person conferences again. In my opinion, it would still be a number of years before we really knew where was the appetite for things right. 2022, in my mind, is still really early as to where people were with their abilities and desire to go to conferences. And so it was tough.
Evan Phoenix:It was tough on the pocketbook. We had some extremely, extremely hard lean conversations around that time about if the hotel doesn't take this deal to push us down the road, then we will just be bankrupt, we will just be out, we will be donezo, because they were asking for like, oh well, you owe us $250,000. And we're like we've brought in $50,000 over the course of the last year. It was pretty scary. It's pretty slim pickings time, but we made it, and I think that the current construction of Ruby Central is both a reflection of the time coming through COVID about what the organization needs to survive A, but also B. What does the community need? Shout out to you, marty, for your work on all the grants that you've been working on, because if we'd had those grants while we were doing all that stuff during 2021, 2022, man, we had a completely different conversation about what we're doing right. It would have been vastly different, right. So diversifying the revenue streams is also good.
Marty Haught:Yeah, there's a funny point there in that back in 2019, before the pandemic, when we expanded the board, we had actually talked about that let's launch a membership program and when can we execute? And we didn't have the staff. And I will say, if I could go back in time and change some things, wouldn't it have been amazing if we had thought about some of that stuff, 2015, 2016, when things were rolling? It would have been like, oh, but we didn't have the need, we didn't need to do that and you know we were so volunteer at that point.
Evan Phoenix:I'm sort of a meta point here about nonprofits and volunteer versus professional boards. So the difference there is that, like a nonprofit with a volunteer board, is people like Marty, like yourself, like the other people, the directors at Ruby Central, who are not paid. They are occasionally if we happen to make enough money. There was times during the good times where we'd have money left over and so we'd be like, okay, great, we're going to pay the directors a stipend this year and then the next year. Well, we're going to pay the directors a stipend this year and then the next year. Oh, we don't have any money left over. No stipend this year, we didn't know. Some years it worked out, some days it wouldn't right. That's a volunteer board, right? Professional board is that it's your job. It's your job to basically be on this board. When you have more professional organization, you have. We had staff, but not staff in terms of like product staff. We had ops staff, right, that would be the way to think of it.
David Hill:I'm going to call myself a liar here, because I have one more question Very along these lines. Because Ruby Central as an organization is so limited on bandwidth in terms of what it can do, for all these types of reasons that you just talked about, how would you advise someone who wants to get involved and participate and help in any kind of way?
Evan Phoenix:If you look at the Ruby Central board members today, all of them were a volunteer in some capacity in the past. Either they were a scholar, they were a guide, they volunteered at a conference. It's a community-driven organization, right? So if you're interested in how can I help out, just help out. Don't overthink it. Don't be like, oh, I got to find the best way forward. Don't do that. Just say like, hey, you need help running rubygemsorg, do that. You need help just volunteering at the conference, just do that. Oh, I'd love to help you make some stickers.
Evan Phoenix:This year I made a sticker design Great, do that, right. Don't overthink it, because your involvement is more important than what you do with that involvement, right? So being around being present, it's going to change, right? Like you don't know what you'll do once you get in the door. But what I can say is that Ruby Central leaves a million doors open. Walk through one of them, find out what's inside. Maybe you'll get in there and you'll be like I came in to design stickers. But oh my gosh, you guys have AV vendor negotiation that you would love to help with. That's my hobby. Let's do that. You don't know, when I started with Ruby Central, it was just because Redis wouldn't restart properly. That was it. That was where we were. I had no intention of being like oh, I'm going to help run these conferences. That was just an accident.
Marty Haught:I have one question, evan, I want to ask you before we get to our Ruby Roundup, and that is what are you up to?
Evan Phoenix:now. Right now I'm a CEO because somebody has to have that title of a company my own company, mirin. We're making dev tools right now. So right now we're working on deployment tools for you to use to deploy your software wherever you want to deploy it. So that's what we're working on now. It's a very small outfit, there's just four of us. It's a lot of getting over imposter syndrome. Oh, can I do this? Am I actually cut out for it? And people might remember I had my own startup about 10 years or so ago and I was not cut out for it then. So I'm hoping my second time around I have a better idea of what I'm doing. Nice good luck, yeah.
David Hill:All right, here we go. What's your go-to comfort food?
Evan Phoenix:Frozen fish sticks. I put them in the air fryer and I eat them with olive oil based mayonnaise. So we have this special diamond kosher flaky sea salt. It's the only salt that I keep around the house now and we keep it in salt pigs, which are basically like a thing that you reach into and you grab salt with your fingers and you sprinkle it on things. Basically, you don't have a salt shaker or anything like that, because the salt is like really big. So fish sticks honestly, I eat that probably once a week.
David Hill:Wow, that actually sounds really good. Are you reading anything?
Evan Phoenix:for fun. Right now I am an audiobook reader. Audiobooks count. That's good, because otherwise I can't answer this question. I'm an extraordinarily slow reader, I don't know why, just is the case. And so about five years ago, abby got me a subscription to Audible and so I always have an infinite number of Audible credits because I never use them all. So that book I'm reading right now is called Meditation for Mortals. It's great, I just started it. It's by the same guy who wrote 4,000 Weeks. 4,000 Weeks is the average human lifespan. In case you're curious about why it's called that, it's great. He used to be a GTD guy. He's like I got to have the systems for how I'm going to organize my life and he completely flipped it upside down and he's like don't know how to organize your life, man, you're not getting anything out of it, just go live your life. And so Meditation for Immortals is sort of that.
David Hill:Are there any recent movies or TV shows that have really hit home for you?
Evan Phoenix:By the way, just so listeners know I'm totally fine. Everything is great in my life. I don't want you to take this the wrong way.
David Hill:I'm like reading a meditation book.
Evan Phoenix:This is going in an interesting direction now. Yeah, because I started watching the Pit, which is a show on HBO about like one day in an emergency room, and as I was watching it recently and I realized why I like those sorts of shows. I always loved House back in the day and this specifically is because you get to see like a level of base human interaction. It's like you watch these people who are like this person is dying of a thing and we're going to fix them. It really does not matter whether or not they filed their taxes yesterday. The real world could not matter less. In the emergency room, you really have one job and one job alone. Everybody is the same. Everyone has a human body. Other than that, nothing else matters, so it's their ultimate escape.
David Hill:What's got you excited in tech right now?
Evan Phoenix:I have been doing a lot of AI coding with Claude and we're at such an interesting time right now with these tools. I don't think that the craft of computer programming is going away, but I think the velocity and the size of a sprint iteration is going to change a lot. I've been doing a couple of experiments for the last six weeks now of basically just having it code a thing entirely on its own and trying to see like how did it go wrong and what does it look like and how could I guide it better, and all those sorts of things. And the tools are good. Will the tools get better? I actually don't know. Maybe, but the tools right now are good enough to be really compelling for a large class of things. This next 12 months I think it's gonna be really interesting to see sort of where stuff starts to shake itself out.
David Hill:So All right, I think this is the last one. What's a favorite gem of yours? Preferably one that isn't super well known.
Evan Phoenix:I'm gonna ignore the second part of this prompt. How dare you, sir? And what I'm going to do instead? I'm going to ignore the second part of this prompt how dare you, sir? And what I'm going to do instead is I'm going to just parrot back something that a very nice person said to me at RailsConf, which was hey, thanks for making Benchmark IPS. I use it all the time and I was like, oh, you're very welcome.
Evan Phoenix:Benchmark IPS for those out there is one of my sort of more obscure gems, but it is a gem that, for whatever reason, is the only gem in this domain, and the domain is reasonable benchmarking. So I wrote it way back in the day, because the benchmark stuff that's built into Standard Library requires you to do one thing that is awful you have to make a total guess about how many iterations you should do your code for. So if you're trying to benchmark a versus b, you have to like is it 10 000 to 5 000, 1 000, whatever? So I wrote a thing called ips stands for iterations for second. You put some code in there and what it tells you is a number where the bigger number is the better number, which is also easier for our human brains to understand.
Evan Phoenix:So you go and you're like, oh, this is 5,000. That is 3,000. The 5,000, obviously better, great. And what that means is I could go through and run this thing 5,000 times per second. So I actually see it pop up kind of once a conference conference. If I happen to see conference slides, I will largely see someone who's talking about performance work have a little snippet of a benchmark APS slide and honestly, it warms my heart. I could not be happier that it's had this enduring performance pun intended.
Marty Haught:Nice, where can people find you on the internet?
Evan Phoenix:Where can people not find me on the internet? Is usually the question. You on the internet, where can people not find me on the internet? Is usually the question. I am on bluesky at mphxdev. I still have an X account but if you message me on there I may or may not see it. Email on GitHub I wish GitHub had better status posting. I would definitely treat GitHub like a social network more if it had more social networking features.
David Hill:If I'm honest, I'm not sure I want that.
Evan Phoenix:No, I'm not sure. Just to be clear here. I'm not sure I want it either. I'm just saying that if it was there I would probably be using it. I don't know that I want it to be there. You don't have to have both for that to be true, right?
Marty Haught:Okay, that's fair, evan. Thank you so much for joining us today. This is a ton of fun, my pleasure.
David Hill:I'm glad to be here, Thank you so much for tuning into the Ruby Gems podcast. We hope you enjoyed this episode. You can find show notes and links to everything we discussed at rubygemspodcastcom.
Marty Haught:If you have a topic you'd like us to cover or have feedback, we'd love to hear from you. Please email podcast at rubycentralorg. If you enjoyed this episode, please subscribe and consider leaving a five-star review. It really helps others find the podcast. Until next time, thanks for being such a gem.
