One embed to rule them all.
In this episode, we talk about how we created unified embeds with Arit Amana, software engineer at Forem, and Jeremy Friesen, lead software engineer at Forem.
Ben Halpern is co-founder and webmaster of DEV/Forem.
Jeremy Friesen is an open source software developer focused on mentoring, process improvement, and crafting analogies.
Arit Amana is a bootcamp-educated software engineer who transitioned to her current role at 37, after being a public-health analyst, and then a stay-at-home mom of two. In her free time, Arit passionately supports those attempting similar career transitions through speaking and mentoring.
[00:00:00] AA: I remember the day when I looked over my list of liquid tags and I think I had like four or three left and I had done like 20 something, and it just felt incredible.
[00:00:23] BH: Welcome to DevDiscuss, the show where we cover the burning topics that impact all of our lives as developers. I’m Ben Halpern, a co-founder of Forem. Today, we’re taking on a little case study on a project we took on recently on Forem, and we’re going to talk with a couple of the engineers who led the project. Arit Amana, Software Engineer at Forem, and Jeremy Friesen, Lead Software Engineer at Forem. Thank you both for being here.
[00:00:48] AA: Thank you for having me.
[00:00:50] JF: Yeah, thank you.
[00:00:51] BH: So our listeners might recognize both of you from occasional appearances as hosts of the show, and that’s always awesome. But today, you’re both guests. But as always, it’s just sort of a round table and we’re going to chat. Let’s hear a little bit about each of you. Arit, can we start about your background as a developer?
[00:01:11] AA: Yes. I have been a developer for about three years now. Prior to that, I was a stay-at-home mom. And prior to that, I was a public health analyst. I am bootcamp educated, landed my first job at 38 years old. So yes, you are never too old to start. And currently at Forem, loving it. I’ve been at Forem now for just over two years and it’s been a blast.
[00:01:34] BH: And Jeremy?
[00:01:35] JF: I have a little more of the background. I went to college for computer science degree, and I’ve kind of done that for the last four years now. And I joined Forem in October. And one of the projects that we had to tackle was helping make our liquid tags and our embeds a little easy.
[00:01:56] BH: All right. And we’re going to get all into that discussion. I think this is going to be a really fun episode because I think we’re going to dig into the real problems at hand here. And I think that’s always worthwhile. I think we should start with some context. Can we talk about what Forem literally is? So when we use the word… we call our company Forem. We also operate DEV. We also have a mobile app called Forem, which has the same name, but it’s actually not the same as what Forem is, but these kind of technical and naming distinctions kind of exist for a reason. But I think it would be worthwhile to kind of start there because this affects anybody who’s on DEV, but it’s a Forem problem. And then how does that even work? So can we start with that discussion?
[00:02:46] AA: Well, I’m going to speak from my understanding. Jeremy, feel free to jump in anytime. So Forem, so we have Forem, the company, as Ben said, but our product is called Forem. And so a Forem is an instance of our software and our software is for community, right? And so our Forem is the software that allows communities to be online, to communicate online, to share online, and basically carve out your community space on the web. That’s what Forem means to me in a nutshell. Yes. Like Ben mentioned, I guess you could say the flagship Forem is DEV.to. And so that is our biggest Forem to date. But we have several dozen others that are growing nicely and other Forem Creators, we call them. So people who want to use Forem for their community needs are signing up every day. So the work that we were doing was to sort of enhance the ability to share rich content in your Forem posts.
[00:04:02] BH: Jeremy, do you want to add anything to that?
[00:04:04] JF: Yeah, I think that’s a great description. DEV.to is powered by the Forem code base. You can find it at github.com/Forem/Forem and see how DEV comes about.
[00:04:17] BH: Yeah, absolutely. And I kind of wanted to start there with this discussion because our open source software, Forem, and that’s Forem with an E, for anybody who’s listening to this, but doesn’t really kind of know the context there. F-O-R-E-M, it stands For Empowering Community. It was extracted from DEV. So when DEV was first written, it was designed to be a single application for a single use case. And over time, our journey took us towards this idea that we really, really should make DEV open source. It’s the best thing for the community, for transparency and social media, for everything we want it to do. We want it to work more closely with the community. Anybody who is using DEV should be able to contribute. And ultimately, we wanted people to be able to reuse the software for whatever their needs were. For one thing that just enhances our long-term capacity to help create cool things because we can only administrate DEV from our perspective. But there’s so much opportunity out there. We’re seeing some people are forking the code base in ways to kind of catch up with features not yet shipped. Some people are getting ahead of us or keeping up with us. Overall, that’s the context, but that also puts this project into perspective because the thing we called back to earlier, which we’ll get into in a sec called liquid tags, this all started with DEV as a single code base, strictly for software developers, very much kind of this first version of this with like a whole different context and everything. So we’re talking about a project which was started years ago in a certain content, but eventually had to improve and evolve for the future needs. If this feature is going to support like the long-term cool stuff that this does, and it really is one of the coolest features on the platform, it had to go through a bit of a rewrite, a bit of a renaissance, and that’s where the project comes from.
[00:06:14] JF: I want to contextualize that a little bit. Arit was mentioning like these multiple communities and trying to how they serve that. And so the phrase unified embed is really about how do we make it easier for our users because the use case, like you said, Ben, that works for a very developer centric community starts to fray a little bit, and also new places and new sources of rich information show up regularly. And we wanted to make sure we don’t have to chase that treadmill. So that’s something that’s also happening with this to really give a feature that is for all communities instead of DEV-related communities.
[00:06:59] BH: Yeah. And at the end of the day, from my perspective, we made choices, which just made the feature better no matter what. Part of this was future looking, ensuring once we serve a broader set of use cases and things like that that we have a better platform to build off of that. But at the end of the day, this feature is already so much easier to use. I’m so happy this shift personally. But yeah, I think we sort of cutoff before we really got into the details of this. So Arit, can you kind of really describe what we’re talking about in terms of the unifying embeds project?
[00:07:36] AA: Absolutely. So like you all have alluded to, before this project came to, be liquid tags are a native, I want to say Ruby on Rails, Ruby Rails, a native Ruby Rails feature that allows you to embed content. Right? That’s what we mean when we say liquid tags. And so originally, we had a number of liquid tags defined for very specific resource types. So for example, GitHub, if you want it to embed a GitHub repository or a GitHub issue in a way that a surface with rich content like it looks nice and it’s not just text on the screen, then you would use the GitHub liquid tag. So we had a GitHub liquid tag defined in our code base, and I’m giving that just as an example, but we had dozens of individual liquid tags. We had one for Instagram. We had one for YouTube. And so the way that you would embed the resource that you wanted to was you needed a keyword that specified which type of liquid tag you are embedding. And so, for example, if it was a YouTube video link, then you would use the keyword YouTube, and then the idea of the video. Right? And so that was the general syntax was a keyword specifying what the liquid tag was and then either an ID or a username, or in some instances, a full URL, but those were few and far between. And so as you can imagine, we had dozens of these liquid tags and you also need it to have the knowledge of whatever the keyword was in order to make it work for the resource that you were embedding. So that was the original situation. And so the unified embeds project sought to unify the way that we generated these embeds. And so we wanted to switch from resource specific keywords to just using one keyword, which is embed. And so regardless of what the resource was, we wanted our users to be able to just use the one keyword embed. And then the other change that we sought to make was instead of figuring out whether it’s an ID or a slug or a username, because those also vary depending on the resource type, we want it to unify whatever is passed in with the keyword and just make it a straight URL. So no need to extract the ID. No need to extract the username or any other thing. Just pass in the URL for whatever the resource is, along with the one keyword embed. That’s the summary of the unified embeds project. That was what we sought to accomplish with the project.
[00:10:30] JF: One other thing. Make sure that the old methods keep working while we bring about the new methods that was a critical component because we couldn’t roll it all out at once.
[00:10:43] AA: Yes, that’s very true. So we needed that backward compatibility. And so that whatever are the liquid tags the users had already created in their posts wouldn’t break upon post resave.
[00:10:56] BH: We maintained backward compatibility from the perspective of posts not breaking, but we also maintained some of the more interesting things that the existing embeds did. For example, there’s no official GitHub embed. But a long time ago, we had kind of created some really neat GitHub embeds from scratch, which fit right into posts, because this is DEV. Going back in time, we felt like that would be a great feature and it continues to be probably one of the more beloved sort of publishing features is that stuff like GitHub has native HTML in the post that sort of just works like magic. But yeah, it used to be really hard to use. Now it just kind of works as one might expect. Right?
[00:11:39] AA: Right. Absolutely.
[00:11:41] BH: So Jeremy, you paired with our last sort of, this idea started late last year, where early spring now and it’s shipped. I think there’s still parts of this, which we’ll continue to iterate on, but I’ve seen this project shipped. I’ve been really excited to start using it. I think folks are much more comfortable hosting these embeds now. From a managerial standpoint, kicking off this project, helping things stay organized, what did this take from your perspective, Jeremy?
[00:12:10] JF: So as Arit was saying, there was a lot, and these are high profile things. If they break, we’re going to hear about it and we don’t want to break it. So it was trying to set up and work with Arit at that beginning point to say, “How can we make sure that what Arit is going to be working on we can continually ship it?” We don’t want a long running branch. What it means is now we’ve got this checklist and suddenly we get this momentum of success. So that was the framing when I was thinking about it, “How can we get piece by piece, inch by inch make it happen?” And that felt like the right way to frame the approach.
[00:12:56] AA: I have to say, when we first started the project, just like Jeremy said, we kind of looked at it like, “How can we really do this piece by piece?” Right? And I saw the potential for huge pull requests. And I was like, “We want to stay away from that.” I had a vision of being able to implement the unified embed approach for each liquid tag on its own individually. And so when we started, Jeremy was so instrumental in the beginning because he helped me to build the underlying architecture, which I then used to build the implementation for each liquid tag. Right? So that underlying architecture allowed me to then roll out the unified embed approach individually for every liquid tag. And that was what made the project very manageable for me. I worked on this project over the better part of three months, throughout the whole three months, but it didn’t feel as overwhelming as it could have, because I was able to focus on each liquid tag individually, it felt like a number of mini projects within a bigger overarching project, if that makes sense. Right? And it also allowed me when bugs started coming up, because as the users are using it or some use cases or some URL structures, my regex wasn’t capturing maybe all the possibilities for a resource URL. When those bugs started coming up, I was able, again, to address them individually, just because of how we kind of set things up from the beginning. So that was critical, in my opinion, like having that underlying implementation from Jeremy really created that foundation for me to gain some momentum and speed without sacrificing actual working unified embeds. It helped set up a pattern for me. And in many cases, I was just repeating what I had done for other liquid tags. So it was fun.
[00:15:12] JF: I came upon an analogy. So Arit had, I’m just going to call it 30 embeds, and they became like your math book. The math book introduces you to sections of work and they build on each other, but one section is roughly the same kind of work and then you get to the next section and you’re like, “Oh, I need to change my approach.” Yes, I can kind of do this. So that was something that I saw happening from a manager’s perspective is Arit went and found like, “I know these are the easy ones and these ones I don’t know what to do with.” And by the time she was done with the easy ones, she was like, “I think I know what to do with these.” And so she moved to the next ones and kept building this momentum of understanding the more and more complicated embed tags. GitHub, I think, was one of the more complicated ones.
[00:16:25] BH: So the details of this project when we’re talking some parts are simple, some are complicated, I think some of that might be the way things are fetched or whatever, but this project was very regex heavy at the end of the day. That’s what we’re talking about. We’re talking about forcing the user to provide an explicit input or letting the computer parse a slightly more complicated piece of the information, which is a URL. So very, very regex heavy project. What was that like, Arit?
[00:16:59] AA: Before this project, I hadn’t even landed on RegexPlanet. Like I knew next to nothing about regular expressions. And the little that I had come across in my DEV work up until this point left me completely intimidated. So it wasn’t even something that I had on my list of like things to learn. And so, I mean, Jeremy will tell you. When I started this project, that was the most nerve-wracking aspect of it was I can’t escape regex anymore. Like, “It’s here, it’s here. It’s now. I’m going to need to learn this.” Right? So like Jeremy said, I did kind of go through and sort of determined which liquid tags would be easier to convert to the unified approach. But yes, I am forever grateful to Rubular.org, I think it is, huge shout out because that service was instrumental and just vital to my learning process. I mean, it was great. I paired the Jeremy at the beginning. The thing that was the hardest for me to understand were the capture groups. Right? Unnamed capture groups versus named capture groups, and that was important because after parsing the URL input from the user, we then still needed to extract either the ID or the slug or the username in order to ensure the backward compatibility with the old approach. Right? So that still needed to happen. And I just remember days where Rails would give me errors, like, “Oh, you can’t mix named and unnamed capture groups. And I would be pulling my hair out, like, “Where? Where is the unnamed? Where is the named?” I can’t find it. So it was aggravating, but in a good way. You know when you stretch and it feels like you’re about to break something, but at the same time you know you’re not going to break something, but it feels like you are, but you know it’s good for you? That’s kind of how it felt. So that’s definitely a feather in my skills cap because I’m pretty comfortable with regex now, I would say.
[00:19:10] BH: Comfortable with regex. That is a huge, huge, huge software development milestone.
[00:19:15] JF: Yes.
[00:19:15] AA: Thank you.
[00:19:17] BH: What was it like building some new domain authority within our code base, our organization? I really felt like an observation, Arit, this is a real step for you to take on really something so big. Jeremy is very involved. The team was involved. We have designers helping. This is a big project, but from my observation, a lot of work and shipped by you and seemed like you built your confidence throughout. How was that? What was that like?
[00:19:55] AA: It was amazing, but I can only say that now because I’m like on the other side. Right? But while in the process, because it was a lot going on, right? Like I’m working through all these embeds. I get done with the easier ones and then I’m diving into the harder ones and sometimes like I remember this particular resource has so many different options and parameters and they all mean something and the URL can get like really, really long. So just things like that and just working through like how to make sure that my regex actually captures it well and doesn’t invalidate a valid link, things like that. When I was in the weeds of it, it kind of felt like, “Okay, when am I getting out? When am I getting out?” But I remember the day when I looked over my list of liquid tags and I think I had like four or three left and I had done like 20 something, and it just felt incredible. I remember when I started and it seems like this would go on forever, but I’m actually getting to the end. And when you speak about domain knowledge, that has been just a huge confidence boost because I think anyone who kind of became a developer “through the nontraditional route”, there’s this sense of intimidation and sometimes feeling like you’re not good enough and you might never be good enough, especially when you compare yourself to like more experienced developers or developers that just exhibit that wide range of knowledge and expertise. I know I do that, just in awe of like my teammates and my developer friends that just have that range and that breadth of expertise. Right? And sometimes you forget that maybe they’ve been developers for like 15, 17 years. Right? Because you’re comparing them to your two and a half, three years of experience. Right? But it still kind of feels like, “Wow, that’s amazing.” But this embeds project kind of helped me to see how you get there. Right? It’s a process and you get there by taking on these projects and taking ownership. And even if you don’t know how you’re going to implement something or you don’t have a clue, ownership does not necessarily mean that you know what to do. Ownership means you are responsible for the final product. Right? And so if you don’t know what to do, then you get the help. If you’re fatigued or you’re tired, you get the support, but you are committed to seeing that project or that feature to the end and taking ultimate responsibility. And that’s what I learned real ownership is. And I think sometimes we confuse that with ability. You may not have the ability, but you can still take ownership over something a piece of what your company is working on. And so that was a wonderful learning experience for me. And even until today, like Jeremy will tell you, like once the word “embed” is dropped in our Slack or other company communication, my ears freak and I’m like, “Oh, that’s my baby! That’s my baby!” And it’s great because I kind of know practically every inch of that section of our code base. And I do have the domain knowledge and I do have the expertise and I do have the background. And so I’m able to inform kind of whatever else is going on around that aspect of what we’ve built. So it was amazing. It’s amazing to be in this place.
[00:23:33] BH: Yeah. For better or worse, whenever the phrase caching comes up, I feel like I usually kind of have to answer a question because of something, a decision I made several years ago, which has only complicated things ever since. It could be really exciting to really kind of understand something pretty deeply in a way that continues to be important for a long time thereafter. What would you say your learning style is, Arit? I know from experience that you can’t take on a big project without learning a lot. When you’re given the ownership and when you have to solve a lot of problems, how would you describe your learning process holistically?
[00:24:17] AA: It’s a combination of things. I think for me, it’s actually one of the slogans of, “I guess my developer brand, Arit developer is learned by doing.” And I think if I were to summarize my learning style, it is learned by doing. And so it’s more difficult for me to just sit and absorb information that I’m being given. I kind of need to play with it and I need to get in there and like make mistakes and break things, and then things begin to click more for me. So my learning style is to get in and just kind of start figuring out how things fit together, putting, well, it depends, like either put statements if I’m in the back end, or console logs if I’m in front end man, but just kind of giving myself back, letting the code talk to me. Right? Even before I get in to start implementing a solution or a feature, I like to kind of get the call to talk back to me and like tell me, like, “What is it you’re doing or what is it that needs to change?” And then I also do appreciate, and this is why Jeremy was so instrumental in this project is I do appreciate pairing. I think it’s one of the activities that really level up earlier in mid-career developers like really quickly is the ability to pair programs with a more experienced developer and sort of have them watch what you’re doing and talk through what you’re doing. So it’s different from like someone coming in and “making it work” and “saving the day”. Right? That doesn’t really help anyone in my opinion. But if you can talk through your process and sort of explain, “Okay, this is why I’m doing it this way, but this is working, that isn’t working,” and then have that supportive input from a more experienced developer, that also really helps me to not just get it working, but understand why it is working and then you can apply it to future work.
[00:26:21] JF: I recall early on, Arit, that we paired up a few times in a couple short weeks or something. We paired up. And then you move on and then you’re like, “Okay, I hit the hard spot.” And so we paired again for like 20 minutes to get you unstuck, and then you were off to the races again. So yeah, from my perspective being manager, I was always saying, “Arit, you can drop something on my calendar with very little heads up and we’ll get you unstuck and moving.” So we did that and eventually it was like riding a bicycle. If you’re teaching a kid to ride a bike, the analogy, you just let them go off. And eventually, you’re not running behind them. You’re there if they need help, but off you went and zip and zoom.
[00:27:10] AA: Absolutely. That was helpful in the beginning was just having that freedom. And I’m highlighting this because I know part of what we are doing here is sort of dropping like tips for maybe developers in Jeremy’s position, how can you better empower and serve your reports? And that was a key way that Jeremy did serve me in executing this project was he made himself available, literally with very little lead time, like 30 minutes, 15 minutes at times. It was like, “Hey, I need your input on this.” And he made himself available for that. And that really helped me and it kept me moving forward. So I didn’t really have time to kind of sit in my not-able-to-do-this nest, if that makes sense, and kind of psyched myself out mentally, which sometimes can happen. So that was helpful as well.
[00:28:25] BH: Jeremy, you haven’t been with Forem forever. Arit was already here when you joined, but you two had actually worked together, I believe, but in the past. But Jeremy, you're pretty new to our code base, our problems, and our past solutions and stuff like that. What has it been like to try and ramp up your own domain authority within what we do? It’s all Ruby on Rails, but the domain is different. Our approach is unique in certain areas. What’s the ramp up in like for you?
[00:29:05] JF: It’s been very interesting. There was a question on DEV. I think I asked about, “How do you orient to a new code base?” And what I really like to do is go in and look at the routes of an application and then just start seeing, “Okay. What’s the important stuff?” And then just start looking at the code and looking for similarities for logic pass on, like, “Huh, wonder what that’s about.” So I did a lot and still do a lot of that, just trying to understand it. There’s some static code analysis that I’ve used before. I think it’s Debride and Flay and Reek are different things that I will run to just see, “Hey, where’s might there be duplicated code?” Every code base has it, and it can give an insight into what’s trying to happen. So a lot of it, like Arit was saying of like how you solve problems, I gain an understanding by playing with the software. Software should be soft. It should be like clay. So I play with it. I’ve been very fortunate because we have a lot of tooling to make sure I don’t overly break things. We also have some wonderful ability to roll back changes very instantaneously. I just completely changed how the feed was generated today. And I think nobody will have noticed because I instrumented it in a way that allowed our site reliability engineers to turn it on, see what’s happening. And if it’s a problem, turn it off. And having those kinds of fail-safes where I know that we can go back to a past working state very quickly is super useful. The challenge for me has been, as Ben alluded to, the caching. There are aspects of it that can be surprising. And I’ve now learned to not be surprised by them and saying, “Okay, the cache is in play. The purpose of the cache is to make sure that we have a very performant site for lots of people distributed throughout the world.” So that is a constraint and I work to understand how is it impacting me. It’s something you work with and work through and reevaluate is this what we need to do now. And so again, I’ll think, “Do we need to do this? If not, let’s run either an experiment. Let’s poke at it a little bit. Let’s get some cache hit rates from our site SREs,” just going to say that. Ask them to help me make the code more, help grow the shared knowledge of a code base. I think that’s the goal of it.
[00:31:50] BH: So you two have domain authority within the team called “content experience”. And Arit’s developed this even tighter domain authority within the embed project, but all of this is fluid. What’s next for you two and the projects you’re working on and challenges and things you’re daunted by and excited by?
[00:32:20] AA: I will say the embeds project kind of has two parts to it. And we haven’t had our retrospective meeting on embeds yet, and I will bring this up there as well, but we had two parts. And so the first part was of course unifying all the different liquid tags to use one approach. Right? And then the second part was for the resources that we do not have a defined liquid tag for, how do we still render rich content in a way that kind of flows with the users’ posts? Right? And so we call that a fallback. So how do we implement a fallback for the URL types that we don’t have defined liquid tags for? And so I worked on that with our teammate, Dwight, shout out, Dwight, and that was an experience in and of itself because it surfaced some other functionality that I hadn’t implemented in part one. But the point I’m making there is when I got done with part two, I realized that maybe It kind of felt like an afterthought kind of part two when it should have been, I think, more like integrated with part one, which felt media. It felt like the more involved aspect of the project. Right? So I finished part two and then, like I said, there was several bugs and observations coming up and having to fix those as they came along. And there may be more, but having at least reached a good stopping point, I feel like embeds are humming along, we’ll fix the bugs as they come up if they do, but I’ve kind of just taken a break since then and just worked on some small wins within content experience priorities. But as far as what I’m looking forward to jumping in next is our roles. Our roles project related to authentication, authorization as well, which Jeremy has done some great work on as far as part one, but it’s just part one of many parts. So I’m looking forward to jumping into that. I think that’s going to be more of a team effort as opposed to solo effort. So I’m looking forward to that dynamic as well.
[00:34:40] JF: We had two long running projects wrapped up basically in the same week. And there were a couple of projects that are ramping up, but that meant the team needed to go back and just do some care and feeding. So we’re in a little bit of a lull. We finished a race, drinking our Gatorade, taking it easy, solving the problems that we couldn’t do beforehand. But as Arit said, the roles is one, and there’s a lot of interesting things there, but the one that I’m currently mostly wrapping up I think my portion of has been, like I mentioned, the feed change. So one of the things that we want to do now that we have kind of our team back off of the two different projects is to be able to look at the feed holistically and what is relevant to the various people who come to DEV. And so the swap-out of the past feed is so that we can now run easier these variant experiments to say, “Is this something that produces a more relevant feed to people?” And we’ll be rolling those out kind of continuously over the next while to try and really, yeah, like I said, improve what folks see in their feed and how they can then have better engagement with the things that they say are very relevant to themselves. So I’m very excited about that and looking forward to tackling the roles as well because there’s some interesting things on the horizon around how we’re going to group content, but also how we’re thinking about site-wide moderation of content as well. Those all interact because, again, the goal is to make sure that the Forem code base makes it easier to have a robust community and be able to support the values of the community. So we want to make sure that the tools that we bring forward help content creators, help the moderators, help the site creators all best manage their Forem. And as a happy byproduct, make DEV even better for everyone else.
[00:37:07] AA: Absolutely.
[00:37:09] BH: A lot of what went into this project, unifying embeds, and you know what I know about roles and what you’re talking about, Jeremy, a portion of this, the tip of the iceberg affects end users directly, there’s the new style of creating embeds, which is just makes it easier in general, which is maybe motivation one for some of this. But there’s a lot of, we’ve mentioned, re-architecture of how this is done. Jeremy, I know the roles project will come with new product features along the way, but a lot of this is about making it more sustainable and refactoring and rewriting parts of existing functionality in a more logical extensible way. What about that part of these projects are each of you sort of anticipating, like the stuff that’s only going to possibly matter to a software engineer listener? What sort of refactors do you feel like are kind of going to be a part of the future? And what parts of the code base do each of you sort of anticipate spending time in and seeking out?
[00:38:24] AA: So with the little that I have read, because we have been having a long running conversation about the roles project, and from that conversation, I definitely feel like it’s almost going to feel like sub-forums within a forum. Yeah. That’s what it’s going to feel like for me. And so the challenge or part of the challenge that I’m anticipating is how do we effectively build that encapsulation without compromising the way things work now. It’s almost like we’re going to have to get the roles and the spaces. I know it’s roles and spaces. We’re going to have to get it to work so that the user, the member, the Forem member can move seamlessly between the whole Forem and then the spaces within the Forem that have been set up. So that’s a key part that I’ve kind of been mulling over, and I think it will be a juicy challenge for us to take on.
[00:39:27] JF: The piece that I'm seeing, so Ben, you said we extracted DEV into an open source project. So the Forem code base has the DNA of what does it take to run DEV, but we need to expand that. So inevitably, that means we need to look at how we implemented some of these things to make it more flexible, which is going to look a lot like what we just did with the unified embeds is going through doing an audit, saying where are the places we need to pivot on these things, and then basically writing out the tasks and swarming on it. I don’t know, I ran a query at one point. I think we have about a hundred locations that we need to at least audit and the hundred locations, I don’t know. Like if you get one of them, I think you knocked 30 out right away. So you got 70. You got another one. You knocked out another 15, but it’s revisiting each of those places and saying, “What are we trying to accomplish in this authorization moment?” That will be an interesting project. And then the idea of the spaces is how do we really look at a new concept of, I’ve been using the language of like spaces is where you put things. So if you think about a campsite, there might be the campfire, people are gathered around it. There’s probably also a tent where someone might be trying to sleep or they’re just quietly talking and there might be somewhere out in the woods where they’re going for a hike. Those would be the spaces where you’re having these conversations. And so we want to be able to reflect, like there’s activity at the campsite, but there’s also activity at these places where you might say, “You know what? I’m going to go hop by the fire, grab a nice cup of hot chocolate and start roasting a marshmallow and have a conversation.” So that’s something that I’m curious and working with design and product to see how we’re going to make sure that that feel carries through. But there’s going to be a lot of work.
[00:41:33] BH: It’s a real honor to have both of you be in part of the process and part of the journey and part of the mission, and it was really awesome to have you on the show today.
[00:41:44] AA: Thank you, Ben.
[00:41:45] JF: Thank you much.
[00:41:56] BH: Thank you for listening to DevDiscuss. This show is produced by Gabe Segura. Our senior producer is Levi Sharpe. Editorial oversight by Jess Lee, Peter Frank, and Saron Yitbarek. Our theme song is by Slow Biz. If you have any questions or comments, email [email protected] and make sure to join our DevDiscuss Twitter chats on Tuesdays at 9:00 PM Eastern Time. Or if you want to start your own discussion, write a post on DEV using the tag “discuss”. Please rate and subscribe to this show on Apple Podcasts.