Speaker 1: Hey folks, Welcome back to another episode of the Ruby
Speaker 1: Rogues podcast. This week, I'm your host, Charles Maxwood, and
Speaker 1: I am talking to Ridwana Kahn from South Africa. Very cool.
Speaker 1: I've always wanted to go down there and see different
Speaker 1: areas down there. But anyway, you gave a talk at
Speaker 1: Rails World. You talked about a whole bunch of the
Speaker 1: internals on Ruby on Rails, and it looks like you
Speaker 1: also help write the Rails guides, which is awesome. That's
Speaker 1: one of the nicest things about rails is when I'm
Speaker 1: talking to people and it's like, well, how do I
Speaker 1: even get started? It's like, we've got these great guides.
Speaker 1: Just go, you know, go spend a half hour or
Speaker 1: so with them, and then you're pretty much off to
Speaker 1: the races. So why don't you go ahead and introduce
Speaker 1: yourself as far as anything else you want people to
Speaker 1: know about you, why you're popular or famous and all
Speaker 1: that stuff.
Speaker 2: Yeah, So I'm Ridwana, like you mentioned, I'm a technical
Speaker 2: writer for the Rails Foundation. I've been helping to improve
Speaker 2: the official Ruby on Rails guides for the last year
Speaker 2: or so. I'm also a lead engineer at a company
Speaker 2: called Circle where I focus on building tools that empower
Speaker 2: creators and communities, and I have about over a decade
Speaker 2: of experience in software development. Over my career, I've worked
Speaker 2: mostly within the Ruby and Rail space as well as JavaScript.
Speaker 2: I think if I had to sum up the things
Speaker 2: that I'm passionate about, it would be making code more
Speaker 2: accessible through documentation, and that's why I write the Ruby
Speaker 2: on Rails guides, thought for engineering, and just inclusive community building,
Speaker 2: which is why I work at Circle because there are
Speaker 2: community building platform and I've built many communities over my career.
Speaker 2: I try to both communities where I see a gap.
Speaker 2: So the most obvious one is sort of the woman
Speaker 2: in Tech gap. So over my career I've both communities
Speaker 2: like women in Tech. I've both Rails goals in South Africa,
Speaker 2: Rails Bridge, Black Gull's Code Ladies that You Ax, which
Speaker 2: is the intersection of a development and user experience. So
Speaker 2: just really passionate in that space. And on a personal note,
Speaker 2: if I'm not coding, I'm trying to keep an eye
Speaker 2: on my ever growing collection of house plants and trying
Speaker 2: to keep them alive. They're constantly dying. I also really
Speaker 2: enjoy traveling and going to speak at conferences. It's one
Speaker 2: of my favorite things to do. And finally, just hanging
Speaker 2: out with my very opinionated feline peer programmers or per programmers,
Speaker 2: Zoe and Zeus. If you watch my talk at Rails World,
Speaker 2: you've seen some really goofy photos of them. Yeah, it's
Speaker 2: basically me.
Speaker 1: Very cool. So I have you Circle before? We used
Speaker 1: it for I try to set up a community for
Speaker 1: the podcasts, and I tried it out, so yeah, that's cool.
Speaker 1: I didn't know they were a rail.
Speaker 2: Shop, so yeah. And before Circle, I was at dev
Speaker 2: dot two also known as Forum, also a community platform.
Speaker 2: So I've just been moving around community platforms recently.
Speaker 1: Right, Yeah, I was going to say I'm detecting a trend.
Speaker 1: So I am curious as we dive in, right, because
Speaker 1: I think a lot of times when we talk to people, it's, oh,
Speaker 1: you're doing this very cool thing with code. And I'm
Speaker 1: sure you do cool things with code. I'm not trying
Speaker 1: to say you don't. But the thing that's interesting to
Speaker 1: me is I think a lot of people don't really
Speaker 1: think about, Okay, what goes into the documentation, what goes
Speaker 1: into the rails guides and things like that, and I'm curious,
Speaker 1: how did you get involved there? Did you just I
Speaker 1: don't know, go tell the foundation, Hey, you need to
Speaker 1: fix the easer. I don't know what will happen there.
Speaker 2: No. I think around last year, I want to say
Speaker 2: around January twenty twenty four, Amanda from the Rails Foundation
Speaker 2: was actually looking for writers to work on the Rails
Speaker 2: Foundation Ruby on Rails guides, and so they put out
Speaker 2: a post to say they're looking for two freelance writers
Speaker 2: to work on the Ruby on Rails guides. And during
Speaker 2: that time, I was sort of between different gigs and
Speaker 2: I'd been using the Ruby on Rails guides a lot,
Speaker 2: and so I decided, why not let me apply and
Speaker 2: see how it goes. And yeah, I started writing for
Speaker 2: the Rails Foundation myself and another writer, Boomy. We started
Speaker 2: off and we worked with a couple of other peoples
Speaker 2: to people to review the guides, and that's how it
Speaker 2: all got started.
Speaker 1: Very cool. So is that paid or are you doing
Speaker 1: it because you love us?
Speaker 2: I mean, I'm doing it because I love y'all and
Speaker 2: I love the guides and I love what I do.
Speaker 2: But it is also paid, Okay?
Speaker 1: Cool?
Speaker 2: Yeah?
Speaker 1: I mean I had I guess I hadn't really thought
Speaker 1: too much about it, but now that I'm thinking about it,
Speaker 1: I'm like, oh, wow, so are there because the guides
Speaker 1: have been around for a while, are there any new
Speaker 1: guides or is it mostly just updating what was already there?
Speaker 2: So initially we started with updating what was there, but
Speaker 2: when Rails eight got released, we had a couple of
Speaker 2: new guys that we needed to implement, and we've done
Speaker 2: that as with the release. So it's a combination of both.
Speaker 2: We look at the old guides, we audit them, we
Speaker 2: see what needs to be updated, and we update them.
Speaker 2: But then we're also as Reels releases new features, we
Speaker 2: go in and we create new guides. Also, if contributors
Speaker 2: create prs for new features, sometimes that means we go
Speaker 2: through the pull requests and we update the guides with
Speaker 2: new information on new sections.
Speaker 1: Gotcha, So how much time are you spending every week
Speaker 1: working on the guides?
Speaker 2: So we put a pause a little bit recently is
Speaker 2: the new year started, but I'll be begin it up
Speaker 2: again later this month. I spend around I want to say,
Speaker 2: I forget the actual number of hours because we've put
Speaker 2: a pause on it for the last three months and
Speaker 2: we're just starting again, but I think it's around two
Speaker 2: in two hours a week. I stand to be corrected.
Speaker 2: It's been a while.
Speaker 1: Uh huh, that makes sense. And what's the process. So,
Speaker 1: I guess the process is different if you're auditing versus
Speaker 1: writing new ones. But yeah, what does the process look like?
Speaker 2: Yeah? So, I mean I don't do a lot of auditing.
Speaker 2: We have a specific contributor that helps with the auditing,
Speaker 2: so Patrick Patrick Hosh he does the auditing of the
Speaker 2: guides and a lot of the reviewing of the guides.
Speaker 2: But essentially what he does is he comes in, he
Speaker 2: audits them, he checks which ones we need to update,
Speaker 2: and then once he's audit audited it, we use base
Speaker 2: camp and we basically keep track of which guides need updating.
Speaker 2: Then one of the writers will go in and they'll
Speaker 2: look at the existing guides. The trick will already have
Speaker 2: some notes in on what he thinks can be improved.
Speaker 2: We look at it with fresh eyes. We then decide
Speaker 2: what can be improved from our side. Sometimes that's how
Speaker 2: I started diving into the source code. I dive into
Speaker 2: the source code see how the internals work, because I
Speaker 2: feel that if you really understand how the internals of
Speaker 2: Rails works. Then you're able to explain the things better.
Speaker 2: Once that's done, we send out a PR. It goes
Speaker 2: through internal review first within our team. Once internal review
Speaker 2: is done, we then create a PR for the open
Speaker 2: source community to be able to review the guides. Maybe
Speaker 2: they pick up some areas or gaps that we may
Speaker 2: have missed, and then finally we emerge it.
Speaker 1: Very cool. So are they in the Rails repo or
Speaker 1: are they somewhere else?
Speaker 2: Yeah, so they're in the Rails repot and usually we
Speaker 2: encourage which open source contributors to have a look through them.
Speaker 2: The guides are marked with a label RF docs and
Speaker 2: it has a label sorry in the title. We usually
Speaker 2: have a prefix rf docs and then it has a
Speaker 2: label Rails Foundation. So if you're trying to find any
Speaker 2: of the docks, you can do that, and we really
Speaker 2: encourage the Rails community to review them because it means
Speaker 2: that if you're learning Rails, or even if you've been
Speaker 2: using Rails for a long time, you basically know we
Speaker 2: some of the gaps lie what you've struggled with, and
Speaker 2: when you review them, you can bring some of their
Speaker 2: fresh perspectives to our prs.
Speaker 1: Right, makes sense. So yeah, I'm curious how deep into
Speaker 1: the internals have you gotten, because I mean your talk
Speaker 1: was a half hour, so you didn't get too deep
Speaker 1: into things, But it sounds like you spend a bit
Speaker 1: of time looking at how RAILS is actually put together
Speaker 1: under the hood.
Speaker 2: Yeah, I think. I mean, depending on what guide I'm
Speaker 2: writing at the time, I then dive into the internals,
Speaker 2: and sometimes it requires a deeper dive. Sometimes it doesn't.
Speaker 2: I feel like when you're writing documentation, it's not really
Speaker 2: enough just to describe what a method does in a surface.
Speaker 2: You need to understand how it works, why it behaves
Speaker 2: the way it does. And that's taken me to some
Speaker 2: of the more complex parts of RAILS are code based.
Speaker 2: So for example, in the talk I talk about mime types,
Speaker 2: I've traced through how RAILS handles the different mind types
Speaker 2: using math. Missing I've done. I've dug really deep into
Speaker 2: active recorde associations because that's a very big part of
Speaker 2: RAILS as well when you're writing applications, so things like
Speaker 2: the definitions of the dynamic methods and so on, I've
Speaker 2: looked at I think I mentioned in the talk, as
Speaker 2: well as validations. So RAIL uses like the dynamic callbacks
Speaker 2: things like that. I've dove into some parts like that,
Speaker 2: and I think that the most common pattern is just
Speaker 2: the meta programming aspect of it. Right, So trying to
Speaker 2: find those patterns across the different parts of Rails or
Speaker 2: components in Rails and then trying to understand it a
Speaker 2: little bit better. The Rails codebase is really huge, and
Speaker 2: there's like always more to learn, but the magic is
Speaker 2: beginning to feel a little bit less like magic is
Speaker 2: you start understanding more of it.
Speaker 1: Yeah, I mean it seems like we've talked to different
Speaker 1: people about metaprogramming on this podcast over the years, and
Speaker 1: so yeah, a lot of what you put up there
Speaker 1: was like I was like, oh, I see how that works,
Speaker 1: and yeah, so I can kind of get the idea
Speaker 1: that yeah, it feels a whole lot less magic and
Speaker 1: a whole lot more. Oh. You know, this is a
Speaker 1: tool that we used, and you know, and so it's
Speaker 1: able to you know, for example, you know when it's
Speaker 1: defining methods using defined method right, it just puts things
Speaker 1: in place, It does the work. And one thing I
Speaker 1: hadn't thought of with the mind type mind type is
Speaker 1: you define the method and then you just call it.
Speaker 1: I was like, oh, that that makes sense. So yeah,
Speaker 1: I really liked that, and really liked just the clean
Speaker 1: approach to explaining how all this stuff works.
Speaker 2: Yeah, I think the main aspect really and again I
Speaker 2: have to emphasize it's the patterns. Rails is a lot
Speaker 2: of magic. But once you identify some of the patterns,
Speaker 2: and once you understand how meta programming works, you sort
Speaker 2: of start putting these puzzle pieces together and you're able
Speaker 2: to understand the code a lot better. And then you'll
Speaker 2: see with the different components, there'll be one pattern here,
Speaker 2: and then it's applied in this different place. And what
Speaker 2: I tried to also do within the talk is show
Speaker 2: how those patterns are applied across the different components. So
Speaker 2: if you understood it in one component, you can go
Speaker 2: and dive into a different component and it has very
Speaker 2: similar patterns. And once you think of it like that,
Speaker 2: it feels a lot more approachable. Because when I started
Speaker 2: off in rails, and even like up until a few
Speaker 2: years ago, I there was all this magic happening in rails.
Speaker 2: So when you reach a point of like, hey, I'm
Speaker 2: doing this thing, but it's a little bit more complex,
Speaker 2: and now Rails isn't playing nicely with me. You don't
Speaker 2: really know where to go from there. But if you
Speaker 2: try reading the source code or you try looking into
Speaker 2: how Rails is actually working, you're able to move past
Speaker 2: that blocking point and do more complex things. I mean,
Speaker 2: ideally you don't want to break away from the magic,
Speaker 2: but unfortunately there is real of it is when you
Speaker 2: both complex applications, you end up needing more tools under
Speaker 2: your belt, and I feel like understanding the code base
Speaker 2: is a tool under your belt.
Speaker 1: Yeah, that makes sense for me. What I found was,
Speaker 1: as I've learned, I learned Rails first, and then they're
Speaker 1: Ruby later. As far as like what all the other
Speaker 1: things are that Rails kind of makes it so you
Speaker 1: don't have to deal with right off the bat was
Speaker 1: I would build stuff and then yeah, I would get
Speaker 1: stuck on something right It'd be like, I don't know
Speaker 1: why it is doing this, Why is it acting this way?
Speaker 1: Why is it, you know, doing this thing to whatever
Speaker 1: it is that I'm trying to work on. And it
Speaker 1: it became pretty apparent once I started to learn Ruby.
Speaker 1: It was like, oh, it's doing this because Ruby works
Speaker 1: this way, and so it's just using the Ruby mechanism
Speaker 1: to do the thing. And so yeah, I love that
Speaker 1: idea of saying, Okay, look go look at the internals.
Speaker 1: It may be something you haven't done before, but it's
Speaker 1: it's not a mystery, it's not complicated or hard. It's just,
Speaker 1: you know, it's something that maybe you need to learn
Speaker 1: a little bit more about. And then you look at
Speaker 1: it and you go, huh, Okay, this is where this
Speaker 1: is coming from. This is why I have this the
Speaker 1: way that it is.
Speaker 2: Yeah, And another aspect of it is that when you
Speaker 2: go through the Rails code base, you're also not only
Speaker 2: learning about Rails itself, but you're potentially learning how to
Speaker 2: solve problems elegantly. Right. So, Rails does solve problems elegantly
Speaker 2: and very often when we're working on our features within
Speaker 2: whatever application or companies were working for with you solving
Speaker 2: similar problems in just different use cases or different forms.
Speaker 2: And so by going through the Rails code base, you
Speaker 2: were able to also learn problem solving skills.
Speaker 1: Yep. Absolutely, So let's talk about some of those skills
Speaker 1: or some of the things that you've seen in the
Speaker 1: code base. You kind of went straight to metaprogramming, and
Speaker 1: I've seen plenty of people over the years basically talk
Speaker 1: about how metaprogramming is scary or you can get yourself
Speaker 1: into trouble with it. I don't know how do you
Speaker 1: feel about that argument about using metaprogramming or not.
Speaker 2: I think that using meta programming, I think you're going
Speaker 2: to have a lot of people saying meta programming is
Speaker 2: the best, and some people saying that you shouldn't use
Speaker 2: meta programming. I think that there's a use case for
Speaker 2: meta programming. Meta programming is a superpower and it can
Speaker 2: lead to really elegant, expressive code, but it also can
Speaker 2: lead to very scary and intimidating code that's very hard
Speaker 2: to follow. So I appreciate meta programming, but I also
Speaker 2: respect that it has a lot of complexity and it
Speaker 2: can make code harder to debug, especially if you're not
Speaker 2: familiar with the patterns, or if it's overused without like
Speaker 2: clear naming or clear direction. So I wouldn't say that
Speaker 2: I feel strongly that everybody should use meta programming. I
Speaker 2: think that meta programming needs to be used based. I
Speaker 2: think metaprogramming has a place, and depending on your use case,
Speaker 2: meta programming may be a good fit. But if you're
Speaker 2: using metaprogramming for any for everything, you may just be
Speaker 2: over complicating things.
Speaker 1: M hm, yeah, I think that's I think that's a
Speaker 1: fair way to put it. I do a lot of
Speaker 1: work on my cars or my house or whatever, and
Speaker 1: what I found is that most of the time, you know,
Speaker 1: just just the regular tools work right, you know, and
Speaker 1: even if I pull out the power to tools, right,
Speaker 1: they work. But occasionally I've got to open up a
Speaker 1: wall with a saw, or I've got to use some
Speaker 1: other tool that, yeah, you know, may have some safety
Speaker 1: hazard to it or something if you're not using it properly.
Speaker 1: And that's the way I think about metaprogramming is is
Speaker 1: you know, you don't want to take more out of
Speaker 1: the wall than you have to, so to speak, you know,
Speaker 1: you don't you have to be careful not to hurt
Speaker 1: yourself with it. Sometimes the code can be hard to
Speaker 1: debug when you're using metaprogramming, and so, yeah, you know,
Speaker 1: what I find is most of the time when I'm
Speaker 1: reaching for something like metaprogramming, I am doing something on
Speaker 1: the level of rails, right, And so what I'm doing
Speaker 1: is I'm actually using it to provide myself with the
Speaker 1: pattern I want to see in my code, and so
Speaker 1: that winds up being in like the lib folder, you know,
Speaker 1: somewhere else where. It's it's not code that I'm going
Speaker 1: to go touch all the time, and it's not code
Speaker 1: that I'm using to solve all my major problems. What
Speaker 1: I'm doing is I'm just basically using the metaprogramming to
Speaker 1: create a better tool for me to solve the problem.
Speaker 2: Yeah, and I think I think your example, by the way,
Speaker 2: was great about how you do work around why I
Speaker 2: work around the house, and sometimes you need to bring
Speaker 2: out the right tools. In my talk, I talk about
Speaker 2: like a real world use case where we use meta programming,
Speaker 2: which I think is really valuable. So when I was
Speaker 2: working at dev dot two or known as forum as well,
Speaker 2: we were building of course community software, and we needed
Speaker 2: a way during onboarding to letter from communities define custom
Speaker 2: profile fields for their members. So, for example, in the talk,
Speaker 2: I use the example of a go gardening community, and
Speaker 2: for a gardening community, during onboarding, we may want a
Speaker 2: profile field that a user can enter their favorite plant,
Speaker 2: or a developer community might ask if you're available for hire.
Speaker 2: So these fields need to be highly customizable, and they
Speaker 2: might need to be dynamically edited at run time. They
Speaker 2: also might support different data types like strings, booleans, dates, etc.
Speaker 2: So rather than hard coding a bunch of different profile
Speaker 2: attributes that are different for different communities, we use mata
Speaker 2: programming to dynamically define gatters and setters for the custom
Speaker 2: fields is the community has created them, and it meant
Speaker 2: that communities could define as many custom fields as they
Speaker 2: want and the system would just respond. There were no
Speaker 2: migrations or extra model code or no like hardwired logic.
Speaker 2: It just made the system really flexible. And I feel
Speaker 2: like that's a great example of how meta programming is
Speaker 2: used in a real practical way to solve a problem.
Speaker 2: But like you say, I feel like they are very
Speaker 2: like meta programming. In my career, I think that's probably
Speaker 2: like one of the very few cases I've needed to
Speaker 2: use metaprogramming, And maybe there's like one or two others,
Speaker 2: But over ten years you're mostly building standard applications that
Speaker 2: don't necessarily require that level of customization, right.
Speaker 1: Yep, absolutely, So what other things have you found going
Speaker 1: back to rails internals, What other things have you found
Speaker 1: that maybe you wanted to add to the talk but
Speaker 1: didn't have time or have thought were interesting that people
Speaker 1: don't really see or know in the Rails codebase.
Speaker 2: I think there's so many gems no pun intended in
Speaker 2: the Rails hood base. One of the things that I
Speaker 2: really enjoy about, like exploring the rail's internals, is seeing
Speaker 2: how thoughtfully things are architected. So when you like how
Speaker 2: it gives you a whole ecosystem of dynamic methods. How
Speaker 2: things are named really well, such as very thoughtful processes,
Speaker 2: how things sorry very thoughtful naming. Also how the different
Speaker 2: components are well separated, things like how well the code
Speaker 2: is documented. I think that's really a superpower. If you
Speaker 2: go through the Rail's code base, you'll find sort of
Speaker 2: method definitions, you'll find how the Rails API documentation is
Speaker 2: within the code base, and you can see what the
Speaker 2: different methods are doing. So I think there's a lot
Speaker 2: of sort of other practices that the Rails team uses
Speaker 2: within their sort of actual development, and I found a
Speaker 2: lot of those useful alongside the matter programming aspect and
Speaker 2: the great architecture. I also think so may one more
Speaker 2: thing to air the like the PR. I found that
Speaker 2: when I'm writing documentation, I also sometimes tend to go
Speaker 2: through like the open issues or poor requests to see
Speaker 2: did someone touch on this. Maybe there's something I don't
Speaker 2: really understand and I want to understand it better, but
Speaker 2: maybe the rail's code base doesn't provide as much information.
Speaker 2: I find that when I go through poor request reviews
Speaker 2: or even issues, contributors and the core team are very
Speaker 2: for both about explaining things. They do a really great
Speaker 2: job about articulating themselves and working together to form a solution.
Speaker 2: So it's really nice to go through poor requests, to
Speaker 2: go through issues, and I really encourage people to just
Speaker 2: if you're not contributing to rails, or you're not reviewing
Speaker 2: documentation prs or even just normal rails code, like just
Speaker 2: browsing the issues and the poor requests casually can provide
Speaker 2: a ton of information and useful knowledge.
Speaker 1: Makes sense. So do you have any advice for people?
Speaker 1: Let's say that you know somebody. I mean, I have
Speaker 1: to admit I haven't really contributed to rails. I think
Speaker 1: I've I've filed bugs. I think I've maybe put in
Speaker 1: one poor request in my whole life against rails. So
Speaker 1: if somebody wants to get involved and they're sitting there
Speaker 1: and they're thinking, okay, well, I just want to understand it,
Speaker 1: you know, and maybe they want to contribute to the docs,
Speaker 1: or maybe they you know, just want to understand things
Speaker 1: better and you know, maybe help with some little thing
Speaker 1: here or there. Like where do you recommend that people
Speaker 1: start with the RAILS code based to just understand what's
Speaker 1: going on in there? Yeah?
Speaker 2: I feel like I am so I get so excited
Speaker 2: when someone asks me this question. I'm biased, but I
Speaker 2: feel like starting with documentation is a really good way
Speaker 2: to get into contributing to RAILS or just understanding things better.
Speaker 2: Rails places a lot of value on clear, accessible documentation.
Speaker 2: So if you're reading a guide or an API document
Speaker 2: and something's confusing or missing, just open up a pr
Speaker 2: to improve it to add value to the next person.
Speaker 2: You don't need to be a core contributor to that.
Speaker 2: You don't need to be writing the guide to do that.
Speaker 2: You just need to be someone who wants to make
Speaker 2: it clear for the next person reading the guides. And
Speaker 2: especially I feel like a lot of people that are
Speaker 2: new to the industry or that feel they feel they
Speaker 2: don't have enough knowledge to contribute to RAILS or something
Speaker 2: or the other. That's how I felt for a long time.
Speaker 2: I feel like documentation is a clear way to contribute
Speaker 2: because if you're not understanding something in the documentation, I
Speaker 2: can guarantee you there's hundreds of other people that are
Speaker 2: not understanding it as well. Another way to get yourself
Speaker 2: familiar with the rail's code based if you're looking to
Speaker 2: just dive a little bit deeper, I think read the tests.
Speaker 2: They incredibly instructive. So the Rail's test suite is massive,
Speaker 2: but it's very descriptive. It shows you how methods are
Speaker 2: supposed to behave. It often gives you breadcrumbs to trace
Speaker 2: back to the source code. And when you're trying to
Speaker 2: understand something or if you think you know fixing a bug,
Speaker 2: test are often the best entry point, and writing or
Speaker 2: improving tests or just reading the test is a fantastic
Speaker 2: way to start. And then if you're looking actively to contribute,
Speaker 2: you can look for a good first issue or you
Speaker 2: can look, like I mentioned, the docs, TIG the rails
Speaker 2: getthub repots very well organized, so there's very often open
Speaker 2: issues that are labeled as like a good first issue
Speaker 2: or where we need contributions on the documentations. And finally,
Speaker 2: like don't be afraid to read this was called Even
Speaker 2: if you don't understand it, that's fine. Just a lot
Speaker 2: of reading of it. Eventually your mind starts to put
Speaker 2: the pieces together. It's like the more you read, the
Speaker 2: more somehow your mind just like connects different parts of it.
Speaker 2: You start seeing patterns emerge. There's lots of tools as
Speaker 2: well that I mentioned in my talk unlike things that
Speaker 2: will help you to navigate the rails scode better. So
Speaker 2: use some of those tools to navigate the rail source code.
Speaker 2: And finally, you don't have to do it alone. There
Speaker 2: are so many people in the rail's community who are
Speaker 2: so kind and supportive and willing to help. So whether
Speaker 2: it's in rail slack or discord or get up discussions,
Speaker 2: you can ask questions and you can get unstuck. I
Speaker 2: think the main thing, finally, to wrap it all up,
Speaker 2: is that rail's contributing to rails isn't really about being
Speaker 2: perfect or knowing everything. It's about just being curious and
Speaker 2: wanting to make rails better, even if it's in small ways.
Speaker 1: Awesome, All right, Well, I'm just trying to think where
Speaker 1: else we go from here? Are there are there things
Speaker 1: that you want to add or change or bring forward
Speaker 1: with the rails documentation or areas that we should dove
Speaker 1: into that it doesn't.
Speaker 2: I think, yeah, I think there's there's a couple of
Speaker 2: places or where or we could improve the documentation. There's
Speaker 2: a couple of guides and I'm whipping up the guys
Speaker 2: is we speak, so bear with me as I do this.
Speaker 2: There's a couple of guides which I think could really
Speaker 2: use some improvement, and we've got them noted. So. For instance,
Speaker 2: one of the ones that I'm hoping to work on
Speaker 2: within this year is the active record query interface. It's
Speaker 2: a really big guide. I think it's in a good start,
Speaker 2: it's in a good place, but I think they could
Speaker 2: also be a lot of improvements. We could explain things
Speaker 2: a lot better. We could maybe move out sections, make
Speaker 2: them smaller, more approachable sections. I think it's one of
Speaker 2: the biggest guides, and so I think just breaking it
Speaker 2: up into smaller, more digestible pieces will make it a
Speaker 2: little bit more approachable. There's also some other sections that
Speaker 2: could use some improvement. I think we're already in a
Speaker 2: I think the Rails Guides in general is one of
Speaker 2: the better guides we have out there across languages. I
Speaker 2: think the Rails Foundation has been doing an amazing job,
Speaker 2: but there are just individual ones that are working progress.
Speaker 2: So like the rails initialization process that's a work in progress,
Speaker 2: as well as the active support instrumentation things like active
Speaker 2: record encryption. So the first thing we want to do
Speaker 2: is we want to finalize those working progress guides because
Speaker 2: they may consider they may have right now not like
Speaker 2: the full picture picture of what their topic income. So
Speaker 2: we just want to fill out that information and cover
Speaker 2: the bases, and then we'll go about improving some of
Speaker 2: the other guys and breaking them down. But we're hoping
Speaker 2: to achieve a lot this yeah, and improve it significantly,
Speaker 2: as well as create some new guys that haven't been
Speaker 2: covered with RAILS eight.
Speaker 1: Yeah, there are a lot of things that I see
Speaker 1: you can do with RAILS eight or I mean even
Speaker 1: some of the stuff that came out in Rail seven
Speaker 1: that aren't super well documented, right, and I see people
Speaker 1: use them and they do amazing things with them, and
Speaker 1: it's like, man, why hasn't anyone really just broken this down?
Speaker 1: So yeah, I'm looking forward to some of that. Yeah,
Speaker 1: So I'm a little curious. I want to kind of
Speaker 1: switch over to both Cape Town and to Circle. So
Speaker 1: what do you do at Circle exactly, Like, do you
Speaker 1: work on a specific part of the platform or do
Speaker 1: you just kind of hit whatever needs to be hit.
Speaker 1: And by the way, I'll just explain because I've used
Speaker 1: Circle and what I find is if you work at
Speaker 1: a place, you kind of look at it differently from
Speaker 1: the way that people use it look at it sometimes.
Speaker 1: So Circle is essentially a forum. You can think of
Speaker 1: it as kind of a focused Facebook. It kind of
Speaker 1: feels like that Facebook group. And then on top of
Speaker 1: that you can add like courses and other things to
Speaker 1: your community. You can set it up as a paid
Speaker 1: community or a free community. And yeah, it's a really
Speaker 1: well put together system. So yeah, so what kinds of
Speaker 1: things do you work on there? And yeah, what kinds
Speaker 1: of concerns or improvements do you find at work?
Speaker 2: Yeah? So Circle is really established, well written product. We
Speaker 2: have some really big communities using it, and it's one
Speaker 2: of the It's one of the companies that I've worked
Speaker 2: for that is constantly improving and always looking to batter
Speaker 2: the product. And it's very exciting because they constantly building
Speaker 2: new features but also improving the features that exist in
Speaker 2: the application itself. So specifically, I work on what we
Speaker 2: call the Email Hub or marketing Hub team at Circle,
Speaker 2: and we're basically responsible for things like email broadcasting and
Speaker 2: sort of that domain whereby you able to send our
Speaker 2: broadcasts to either community members or what we call contacts
Speaker 2: within the system or leads. And there's just a lot
Speaker 2: of are things that tie into it, so for example,
Speaker 2: analytics and that ties into things like workflows where for instance,
Speaker 2: when you're onboard a community, you might want to send
Speaker 2: a broadcast and then we might want to wait for
Speaker 2: five days and send them a follow up things like that.
Speaker 2: It's a relatively new team at Circle. I think we
Speaker 2: launched the email hub slash marketing hub feature last year.
Speaker 2: I want to say around September October. It was around
Speaker 2: Rails world time, so it's relatively new. We're actually hiring
Speaker 2: for the team at the moment, so I'm leading the
Speaker 2: team and we have our two engineers and we're looking
Speaker 2: to hire another two engineers for the team. So I've
Speaker 2: been doing lots of interviews and hiring at the moment.
Speaker 2: Our tax stack is Ruby on Rails and we use
Speaker 2: JavaScript as well. It's a pretty big engineering team, so
Speaker 2: each sort of sub engineering team is focused on a
Speaker 2: particular part of the platform. So we have like a
Speaker 2: CRM team and a CMS team and you sort of
Speaker 2: focus on a specific domain.
Speaker 1: Very cool. Yeah, I just got hired at Price Picks
Speaker 1: and so I've been got you know, we're seeing some
Speaker 1: of this stuff, and I'm on the growth team where
Speaker 1: we it's kind of your traditional R and D where
Speaker 1: we come up with ideas on what we could do
Speaker 1: better and then go and invent it and see if
Speaker 1: it works. But yeah, I love what you're talking about
Speaker 1: where it's yeah, the growth. That's always exciting to see
Speaker 1: companies growing and then yeah, just yeah, constantly looking for
Speaker 1: that level of improvement. Those are the best companies to
Speaker 1: work at. So if people want to apply, how do
Speaker 1: they do it?
Speaker 2: We are on we have If you go on the
Speaker 2: so called website, you should see a careers Yes, a
Speaker 2: careers link and you can view the open roles and
Speaker 2: you can find the roles. They're role for a senior
Speaker 2: full stack engineer on the Marketing Hub team and you
Speaker 2: can apply through this. It's very exciting you'll be working
Speaker 2: with me, so please apply. It's also a fully remote opportunity,
Speaker 2: which is nice. Those are real and few nowadays.
Speaker 1: Yeah, So you're based in Cape Town. Is your team
Speaker 1: like all over the.
Speaker 2: World or yeah, so we have developers from pretty much
Speaker 2: all over the world. We in the marketing Hub team
Speaker 2: right now, it's myself and then we have two developers
Speaker 2: in India, and we're hoping to hire someone in a
Speaker 2: European time zone and then maybe sort of North America,
Speaker 2: just so that we have that full time zone support,
Speaker 2: but also ensuring that we're not too far apart that
Speaker 2: we can't collaborate when we need to. So maybe like
Speaker 2: with a one hour two hour overlap just in case
Speaker 2: we need some sink time, so that gives us sort
Speaker 2: of good collaboration across the board. But for the most part,
Speaker 2: we use as in tools like Slack and Notion. We
Speaker 2: document things very well.
Speaker 1: And yeah, nice, Where where's the company based out of?
Speaker 2: To be honest, I guess since there isn't actually a
Speaker 2: head office, No, there's I guess. Yeah, I mean on
Speaker 2: the on the on the invoices and stuff. You're probably
Speaker 2: it's I think I stand to be corrected. I want
Speaker 2: to say the US New York, but again that may
Speaker 2: not be actual.
Speaker 1: Sounds good. So, so what's the community like in Cape Town?
Speaker 1: I mean Are there a lot of rails developers out there?
Speaker 2: Or yeah they are. We used to have, I want
Speaker 2: to say, a well known conference, because when I went
Speaker 2: to Rails World and a couple of other conferences, people
Speaker 2: have asked me about this conference. It's called Ruby FUSA,
Speaker 2: and we ran it in South Africa for a couple
Speaker 2: of years. But we haven't run it, I think since COVID.
Speaker 2: But there's a really big Ruby community here. There used
Speaker 2: to be a lot of meetups previously. I want to
Speaker 2: say that since COVID, that's sort of when things slowed
Speaker 2: down a little bit. I'm also not originally from Cape Town.
Speaker 2: I was based in I was living in Joburg, Johannesburg,
Speaker 2: and then moved to Cape Town only like five years ago.
Speaker 2: Johanna's Burg also has a really big Ruby community. Is
Speaker 2: to have constant meetups every couple of weeks, and yeah,
Speaker 2: it's really good. I will say though, because I work
Speaker 2: for a lot of US Over my career, I've worked
Speaker 2: for a lot of US companies, my community tends to
Speaker 2: be more sort of global. I tend to attend conferences
Speaker 2: where I'm sort of traveling, and so it's been a
Speaker 2: little bit more difficult to keep in touch with the
Speaker 2: rails community within Cape Town. But I'd like to see
Speaker 2: Ruby Fuza hit the ground running again. That would be
Speaker 2: really cool.
Speaker 1: That would be cool. Yeah, So are there any other
Speaker 1: personal projects or anything else that you're working on or
Speaker 1: is it mostly the Rails Guides?
Speaker 2: So between the Rails Guides and then I like to
Speaker 2: tinker on just personal tracks, I've been trying to tinker
Speaker 2: with arduinos and connecting that with sort of Yeah, it's
Speaker 2: really cool. I've really been enjoying it. I like seeing
Speaker 2: like the physical aspect of like things working. So I've
Speaker 2: been working on this like sort of with moisturee detectors
Speaker 2: and sort of like a like merging my passion for
Speaker 2: keeping my house plants alive together with like a little
Speaker 2: gardening system. So I've been tinkering with that and it's
Speaker 2: been really fun. But between writing code the Rails Guides
Speaker 2: and then are doing some of the tinkering, and then
Speaker 2: also speaking at conferences, I've been very busy over the
Speaker 2: last few months. My next conference is I'm really excited
Speaker 2: about is Ruby kontailiand and that's next huge January. One
Speaker 2: of the keynotes speakers, So I'm really excited about that.
Speaker 1: Oh nice, that would be so fun.
Speaker 2: Yeah. I've never been to Thailand as well, so super
Speaker 2: excited about that.
Speaker 1: Yeah. So do you have any I guess you've been
Speaker 1: on the conference circuit for a while. I think I
Speaker 1: went and looked at your website and it listed a
Speaker 1: whole bunch and I was like, oh, wow, she's been
Speaker 1: to quite a few. Do you have any advice for
Speaker 1: people who are thinking they want to speak at conferences?
Speaker 1: It seems like a lot of people decide they want
Speaker 1: to speak, they put in a CFP, and yeah, they
Speaker 1: get rejected at the first bunch and then they give up.
Speaker 2: So yeah, I think that I'd say just go for it,
Speaker 2: like even if it feels scary at first, Like I think,
Speaker 2: if you have a passion for it and you want
Speaker 2: to do it, you should. I think the main thing
Speaker 2: that I have to say is you don't have to
Speaker 2: be an expert. You just need to be curious and
Speaker 2: willing to People sometimes assume that conference speakers know everything
Speaker 2: about a topic. That's not true. I very often I
Speaker 2: will put together ACFP about something that I know nothing
Speaker 2: about but want to learn more about, and those make
Speaker 2: for the most interesting talks. So things that you're interested in,
Speaker 2: things that you may have learned that you think others
Speaker 2: might find useful. And especially I find that the cfps
Speaker 2: that have the most success rate, at least from my
Speaker 2: personal experience, is the cfps that talk about that have
Speaker 2: a story that is something that you've experienced and you
Speaker 2: want to share with the world. So, for instance, my
Speaker 2: reals will talk demystify in the rails code base that
Speaker 2: came from a storyline of being a technical writer and
Speaker 2: diving into the documentation and some of the difficulties that
Speaker 2: I experienced and then sort of what I did in
Speaker 2: order to be able to learn how to demastify the
Speaker 2: rail's code base. So a lot of the time it's
Speaker 2: things that you know, sorry, things that you've experienced, and
Speaker 2: you want to tell that story. I feel like writing
Speaker 2: an abstract first, even before you have like a full
Speaker 2: idea of the talk, that's okay. Sometimes people write their
Speaker 2: talks first, or they try to have every not necessarily
Speaker 2: to write their talks, but they try to have every
Speaker 2: aspect ined out first before you're submitting. They feel that
Speaker 2: they need to know everything before submitting. You really don't
Speaker 2: have to. It just needs to be a pitch and
Speaker 2: then just ensure that you have enough time before the
Speaker 2: conference talk of course, and then you can learn on
Speaker 2: the way, right, Yeah, and start small and then grow.
Speaker 2: So if you've never spoken before, a good opportunity. I
Speaker 2: remember when I started talking, the first kind of places
Speaker 2: that I submitted my talks to were like local rails
Speaker 2: communities that meetups that I went to and I would
Speaker 2: talk there. I would get a little bit more confident
Speaker 2: in front of people, I would get feedback on a talk,
Speaker 2: and then I started applying to the bigger ones. And
Speaker 2: that way, you can also put in your cfps that like, hey,
Speaker 2: I have spoken at these different communities, I have experienced
Speaker 2: speaking things like that.
Speaker 1: Yep, makes sense. All right, Well, I think I'm going
Speaker 1: to start leading us toward toward the end of the
Speaker 1: show and picks. But before we do that, like, where
Speaker 1: do people find you? If they're looking for you on
Speaker 1: the internet and they want to.
Speaker 2: Connect, So you can find me on Twitter? What do
Speaker 2: we call it? X It's been a few years, but
Speaker 2: I still say Twitter.
Speaker 1: I still call it.
Speaker 2: You can find me on AX. My username is Redwana
Speaker 2: under school K. My name has a silent age, so
Speaker 2: it's our id H w a n a under school k.
Speaker 2: You can find me on LinkedIn as well. Sometimes I
Speaker 2: post the and I username is Redwuana, but mostly on X.
Speaker 1: Very cool. All right, well let's go ahead and do
Speaker 1: the picks. Then I'll start it out and just kind
Speaker 1: of show you how we do it, and then you
Speaker 1: can shout out about whatever you want. Uh So, the
Speaker 1: first pick that I have is it's a board game,
Speaker 1: and I almost always do a board game of some
Speaker 1: kind if I haven't played anything new, I'll just pick
Speaker 1: one that I like that I've played that I probably
Speaker 1: picked before. But we played a new one yesterday with
Speaker 1: my So I played board games every Wednesday night with
Speaker 1: my friends, and we played a game called Colt Express
Speaker 1: and it's a train robbery game board game. Geek waits
Speaker 1: it at one point eight four, which is kind of
Speaker 1: So two is what is about where I tell people
Speaker 1: the casual gamers are kind kind of going to go, Okay,
Speaker 1: this was a little bit complicated, but not so complicated
Speaker 1: that I didn't like it, and it was fun, right.
Speaker 1: A one is like the game should play with your kids, right,
Speaker 1: so you know, and so it's got enough to it
Speaker 1: to where there's some competition and stuff, and some of
Speaker 1: the ones are really fun, right, there's simple dynamics you
Speaker 1: just but anyway, so this one's one point eight four,
Speaker 1: so it's almost a two. It's called Cult Express and
Speaker 1: uh it plays two to six players. My friend has
Speaker 1: the the Cult Express Big Box Edition, which has two
Speaker 1: of the expansions in it, so his will play up
Speaker 1: to nine. And apparently there's another expansion that adds another
Speaker 1: player too as well, so you can play with a
Speaker 1: lot of people. Came out twenty fourteen, and what it
Speaker 1: is is it actually has a little train cars that
Speaker 1: you put together for your game board, and so you
Speaker 1: have the locomotive and then you have one train car
Speaker 1: per player, and there's loot on the floor of the
Speaker 1: train cars, and so then what you wind up doing
Speaker 1: is you have a deck of cards, and the cards
Speaker 1: allow you to shoot at the other players. You can
Speaker 1: punch the other players. You can move up to the
Speaker 1: roof of the car or back into the main part
Speaker 1: of the car, and you can move across the car,
Speaker 1: so you can move from one car to the next.
Speaker 1: And there's a marshal and if you wind up in
Speaker 1: the car with the marshal, then then he shoots you
Speaker 1: and you move to the roof of the car. The
Speaker 1: marshal doesn't go on the roof, and so then the
Speaker 1: rest of it is when you owe, and then you
Speaker 1: can pick up loot, you can move the marshal. I
Speaker 1: think that's it. So if you shoot another player, you
Speaker 1: put the shot card in their deck, right, and it's
Speaker 1: a no op card, so it dilutes their deck. It
Speaker 1: makes them harder, It makes it harder for them to
Speaker 1: get what they want. If you punch a player, then
Speaker 1: you make them drop a piece of loot. You know,
Speaker 1: picking up loot's worth anywhere from two hundred and fifty
Speaker 1: to five hundred dollars. There are gems that are worth
Speaker 1: five hundred dollars. And there's a lock box or a
Speaker 1: strong box on the locomotive where the Marshal starts that's
Speaker 1: worth a thousand dollars. And so you just move around
Speaker 1: the train and try and get as much money as
Speaker 1: possible in five turns. And the way you play the
Speaker 1: turn is whoever's first, they put a card on the pile,
Speaker 1: and then you go around the circle and everyone else
Speaker 1: plays a card right, and so you can see what
Speaker 1: they're playing. On the turns where you play face up,
Speaker 1: but there there's sometimes there are twists where you go
Speaker 1: you go around the circle the other direction right, and
Speaker 1: so you may get If you're first, you know you're
Speaker 1: it doesn't change a lot for you. But if you're set,
Speaker 1: if your last and it changes the direction, you get
Speaker 1: to play, the first player plays and then you get
Speaker 1: to play again, and so you know that that may
Speaker 1: change the dynamics. There's others where you play and face down,
Speaker 1: so for for those cards on that on that round,
Speaker 1: you don't you don't see what the other players did,
Speaker 1: so you can't react to it. There's another where you
Speaker 1: play two cards at a time and so you play
Speaker 1: twice right, and so you can move and then pick
Speaker 1: up loot because you know that you're gonna be able
Speaker 1: to get there before anyone else. Or you move and
Speaker 1: you punch another player and make them drop loot because
Speaker 1: you know that they're going to be there. And then
Speaker 1: if you shoot the most shots then you you get
Speaker 1: a thousand dollars. So anyway, then you tally it all
Speaker 1: up at the end, and and anyway, it was a
Speaker 1: lot of fun, a lot of fun. So and the
Speaker 1: game board is really unique because it is it's actually
Speaker 1: a train that you just set up on the table
Speaker 1: and so, you know, I mean it's real small. But anyway,
Speaker 1: it was a lot of fun, really really enjoyed that.
Speaker 1: It took us about an hour and fifteen minutes to play,
Speaker 1: but we were learning how to play, so I think
Speaker 1: you could probably play it. We played it with five people.
Speaker 1: We probably play it in forty five minutes, I think.
Speaker 1: So anyway, very very fun. So I'm gonna pick Cult
Speaker 1: Express and then I'm going to shout out about a
Speaker 1: few others. So yesterday we had a team lunch with
Speaker 1: my team and basically we got sent gift cards for
Speaker 1: door Dash, right, so I had food show up at
Speaker 1: my house and then we played wiki race and that's
Speaker 1: at wikidashrace dot com. And the way that wiki race
Speaker 1: works is you and you could put in your own
Speaker 1: things that that you start at and end at, but
Speaker 1: it starts you on a page on Wikipedia and then
Speaker 1: you have to click links to get to the other page. Right,
Speaker 1: And so one of the ones we played that it
Speaker 1: was like some soccer player from like the nineteen fifties
Speaker 1: that you know, there were probably like four links that
Speaker 1: went there, right, and so, and I can't remember we
Speaker 1: started at but it was something like completely weird, right,
Speaker 1: and so you start figuring out some of the tricks
Speaker 1: right where it's okay, well, I know this guy's from England,
Speaker 1: and so I'm going to get to England, right, and
Speaker 1: so I click some of the links that take me
Speaker 1: to the world and then countries and then England right,
Speaker 1: and then I know he played on these teams, so
Speaker 1: I go to the soccer leagues and then England right,
Speaker 1: and so anyway, it was It's very, very fun, and
Speaker 1: it's basically a race, so whoever gets their first wins,
Speaker 1: you know, and then when somebody wins, it shows their
Speaker 1: progression through Wiki Wikipedia. There was one that we got
Speaker 1: that everybody eventually just gave up on. So it is
Speaker 1: possible to get some that just are hard to figure out.
Speaker 1: I'm sure, well I'm not sure it was possible. I
Speaker 1: just think it was really, really, really tough to figure
Speaker 1: that one out. But anyway, it was really fun, and
Speaker 1: they picked some really obscure Wikipedia articles sometimes, and so
Speaker 1: that's fun too, because part of the game that we
Speaker 1: figured out pretty fast was Okay, the first step to
Speaker 1: figuring out how to complete this chain is to open
Speaker 1: another tab in my browser and go look up the
Speaker 1: thing that I'm trying to get to because I have
Speaker 1: no idea who this person is or what this thing is, right,
Speaker 1: and so you go look it up and it's like
Speaker 1: it's like, oh, it's a plant South America, right, all right,
Speaker 1: so you know, then you start figuring it out. So anyway,
Speaker 1: tons of fun and so I'm gonna pick Wiki Race
Speaker 1: and then I'm just trying to think through things because
Speaker 1: there was something else I wanted to pick and I
Speaker 1: can't remember what it was, but anyway, I'll just say
Speaker 1: it for next time. Do you have some stuff you
Speaker 1: want to shout out about?
Speaker 2: Yeah? So that also very cool. I'm very into games
Speaker 2: and so I'm definitely going to check them out. So
Speaker 2: a problem that I've been having recently is just being
Speaker 2: able to, I guess, document meetings a little bit better.
Speaker 2: So having to write down notes from every meeting and
Speaker 2: then consolidate it all together has been a really big
Speaker 2: pet peeve of mine. That's very tiring and sometimes really
Speaker 2: unnecessary to have to take things from different places and
Speaker 2: then put it together. So I've been looking for a
Speaker 2: good tool that will be able to help me a
Speaker 2: little bit with no taking, especially with AI and its advancements.
Speaker 2: So recently I've been exploring a few of these. So
Speaker 2: the one that I've been using has been CRISP dot AI.
Speaker 2: I don't know if you've part of it, but it's
Speaker 2: basically an AI assistant for collaborative meetings. So some of
Speaker 2: the team meetings are basically enable CRISP and it will
Speaker 2: It does recording if you want it to, or it
Speaker 2: can do transcribing, so it will give you the entire
Speaker 2: sort of transcribed version as well as the audio recording
Speaker 2: of the meeting. But that's not the coolest part. The
Speaker 2: coolest part is that it will give you a summary,
Speaker 2: It will give you the action items from the meeting.
Speaker 2: It will give you a detailed outline if you ask
Speaker 2: it to. But then also it has this AI chat
Speaker 2: that is attached to sort of every meeting once it's
Speaker 2: been uploaded, and with the AI chat you can get
Speaker 2: pretty specific. So if there's a specific part of the
Speaker 2: meeting that you want to dive into, you can just
Speaker 2: ask the AI chat to summarize or detail certain parts
Speaker 2: of the meeting, which is really nice. Sometimes the output
Speaker 2: of the meeting is I maybe need to I have
Speaker 2: specific questions and I just want to summarize these, summarize
Speaker 2: the meeting, and answer these by answering these specific questions.
Speaker 2: And so I just go in and I put in
Speaker 2: the questions in the AI chat and it will basically
Speaker 2: spit out the solutions that we came up with in
Speaker 2: the meeting. So really really cool. I've been exploring that
Speaker 2: against a different AI too, which is Granola AI, and
Speaker 2: that's like an AI note piered people in meetings. So
Speaker 2: the difference being is that CRIS will transcribe the entire
Speaker 2: meeting and potentially if you wanted to record as well,
Speaker 2: whereas Granola will simply just provide you with sort of
Speaker 2: notes for the meetings, so it will take your raw
Speaker 2: meeting notes and make them into something more legible. So
Speaker 2: both those tools have been pretty interesting, and I found
Speaker 2: that it's made meetings a lot easier, especially like team meetings.
Speaker 2: We'll be making big decisions and I just want to
Speaker 2: summarize it. I also find myself sometimes so focused on
Speaker 2: taking notes that I'm not processing what someone's saying in
Speaker 2: real time. So the fact that I can just give
Speaker 2: my notes over to a tool and let the tool
Speaker 2: handle the note take in and I can be present
Speaker 2: and process. What people are saying makes it a lot
Speaker 2: easier and a lot more efficient for me personally.
Speaker 1: Nice. So one thing I'm going to clarify for folks,
Speaker 1: crisp Ai is billed with a K. It took me
Speaker 1: a second to find it. But yeah, very cool, very
Speaker 1: very cool. All right, Well, I don't think there's anything else.
Speaker 1: I'm gonna go ahead and wrap it up. Thank you
Speaker 1: for coming. This is fun.
Speaker 2: Yeah, thank you for inviting me. And I hope that
Speaker 2: you will end up visiting Cape Town one day because
Speaker 2: it really is beautiful.
Speaker 1: Yeah, I've I have to admit, so I'm going to
Speaker 1: leave this on the recording, but I'm curious, you know,
Speaker 1: I'll just bring it up. So, my wife is a
Speaker 1: huge Shark Week person. Right, So every year in the summer,
Speaker 1: Discovery Channel does Shark Week and they have a ton
Speaker 1: of documentaries out in Cape Town, right where they're have
Speaker 1: the sharks jumping out of the water or you know,
Speaker 1: they're they're just out there kind of filming them doing
Speaker 1: their thing and you know, chasing seals and whatever. And
Speaker 1: then you know, sometimes they do show part of the
Speaker 1: town or at least the coast and it just looks amazing.
Speaker 1: It just looks like, oh wow, this would be a
Speaker 1: really cool place to visit. And I don't know that
Speaker 1: I would necessarily want to go out on a boat
Speaker 1: looking for sharks, but you know, I think it would
Speaker 1: be a blast. And I have to say that my wife,
Speaker 1: after watching some of these shows, she might be the
Speaker 1: one going, I want to go out on the boat
Speaker 1: looking for sharks.
Speaker 2: Yeah, but well, there's other there's other there's other animals
Speaker 2: that you can go looking for, like dolphins. And we
Speaker 2: have a penguin beach Corboulders Beach when you can intacte Oh,
Speaker 2: there you go penguins, Yeah, you can. You can interact
Speaker 2: with the fun cute ones.
Speaker 1: Yeah. So, so what's the best part of living in
Speaker 1: Cape Town. I'm just curious.
Speaker 2: I think the nature is the best part. It's along
Speaker 2: the coast. It's absolutely gorgeous. There's this drive called Chapman's Peak.
Speaker 2: If you look it up on the internet, it's just
Speaker 2: beautiful scenery along the coast. On the one side, you
Speaker 2: see the sea, on the other side you see the
Speaker 2: mountains and it's just absolutely gorgeous. We have Table Mountain,
Speaker 2: which I mean, based on the name, it's basically like
Speaker 2: a table top. There's lots of hiking opportunities in Cape Town.
Speaker 2: There's a lot of if you're an outdoor person, there's
Speaker 2: a lot of things to do, lots of like diving, swimming,
Speaker 2: lots of long drives, lots of good sunset views, and
Speaker 2: I think people here are just very relaxed and laid back.
Speaker 2: I will say that took me a long time to
Speaker 2: get used to. I'm still I'm five years in Cape
Speaker 2: Town and I'm still not used to that because from Johannesburg,
Speaker 2: we're very like hustle and very serious about things hand.
Speaker 2: Cape Town is just a vibe that's a real's that's
Speaker 2: the way I can describe it, a very child vibe.
Speaker 2: So yeah, lots of fun things to do in Cape Town.
Speaker 2: People are very friendly as well. I find South Africa
Speaker 2: to be one of like the friendliest people around. Like
Speaker 2: you'll walk in the street and you'll say hello to
Speaker 2: people and you'll smile at them. Not every city is
Speaker 2: like that in the world, but South Africans are really
Speaker 2: friendly people.
Speaker 1: Nice. So I think a lot of people if they
Speaker 1: pay attention to South Africa, you know, they've probably heard
Speaker 1: of Cape Town. I think most people are I think
Speaker 1: Johannesburg's the biggest city in South Africa, and so yeah,
Speaker 1: I mean how accessible is it. I'm assuming you have
Speaker 1: direct flights in and out of there because it's not
Speaker 1: a small city.
Speaker 2: But yeah, so my family lives in Johannesburg, so I
Speaker 2: basically fly up to Johannesburg, I want to say, every
Speaker 2: four to six weeks to see them and just spend
Speaker 2: some time with them. It helps that I work remotely,
Speaker 2: so it means that I am I'm just able to
Speaker 2: walk out of any of the city. My husband's family
Speaker 2: stays in Delbin, so we fly in and out of
Speaker 2: Delbin pretty often as well. Yeah, it's very easy to
Speaker 2: get to the different cities, and each city offers something different.
Speaker 2: So Cape Town is I don't know if you know this,
Speaker 2: but Cape Town has a part of Cape Town and
Speaker 2: we call it Cape of Good Hope or Cape Point.
Speaker 2: It's where the Atlantic and the Indian Ocean meet, and
Speaker 2: so you can actually see a some point of the
Speaker 2: year where you can see like the different colors of
Speaker 2: the ocean and they sort of meeting at that point.
Speaker 2: It's really beautiful. But unfortunately you're not really able or
Speaker 2: I personally don't swim in the in the ocean. Here,
Speaker 2: the Atlantic Ocean is really cold and just not for me.
Speaker 2: But if you travel to Dlbin, that's the Indian Ocean,
Speaker 2: and the Indian Ocean is just beautifully warm and really
Speaker 2: nice to swim in. So very often we'd cop over
Speaker 2: to Durbin and go swimming at the beach and things
Speaker 2: like that. And then in Johannesburg you'd mostly like do
Speaker 2: a lot of shopping there. There's a lot of big buildings,
Speaker 2: a lot of corporates there as well, so higher earning potential,
Speaker 2: a lot of people that are just very busy doing things,
Speaker 2: a lot of good takeouts, yeah, and just a lot
Speaker 2: of shopping malls. And then we have the Kruger National
Speaker 2: Park as well. So if you want to see what
Speaker 2: we call the Big five in South Africa, which is
Speaker 2: the lion, leopard, elephant, rhino in Buffalo, you'd basically go
Speaker 2: to Kuruga National Park and you could do a safari
Speaker 2: and see them. No, we do not have animals walking
Speaker 2: around the streets of South Africa. I know, sometimes I
Speaker 2: can ask the question, now, really that's not the case.
Speaker 2: I mean sometimes we have had a tiger on the
Speaker 2: loose once or twice, but not on a daily basis.
Speaker 2: So yeah, really good safaris as well. Lots of very
Speaker 2: cool things to.
Speaker 1: Do, cool, very cool. All right, well, I'll I'll stop
Speaker 1: asking you questions about South Africa. But thanks for coming.
Speaker 1: Was this is awesome, no problem.
Speaker 2: I had so much fun. Thank you for inviting me.