Podcast appearances and mentions of andy croll

Code and the Coding Coders who Code it

Play Episode Listen Later Jan 31, 2024 23:39

RailsConf is coming up fast and I can't wait to see you all there! The CFP is open and the program committee is accepting proposals for talks for the conference. Andy Croll joined the show to talk with us about the CFP process and how you can present at RailsConf ** Show Notes** Rails Conf Detroit - https://railsconf.org/ RailsConf CFP - https://sessionize.com/railsconf2024/ Speakerline.io - https://speakerline.io/

cfp railsconf andy croll

Episode 32 - Andy Croll

Play Episode Listen Later Jan 30, 2024 36:52

Imagine stepping into the control room of a major tech conference with us as we chat with Andy Croll, CTO of Coverage Book and freshly minted co-chair of RailsConf. This episode peels back the curtain on the meticulous craft of conference planning – from the adrenaline rush of putting together a tech event to the nitty-gritty of ensuring that every attendee leaves with more than they came for. Andy's vision for RailsConf marries the camaraderie of small engineering teams with the prowess of industry titans, striving for a lineup that reflects the global community's rich tapestry.With Andy at the helm, we travel the path from Brighton Ruby's intimate gatherings to the sprawling expanse of RailsConf, painting a vivid picture of the care poured into speaker preparation and the quest for the Holy Grail of event organization – flawless Wi-Fi. You can almost hear the cogs turning as we delve into the logistics of venue scouting and the art of crafting a compelling call for papers. Whether you're a conference going enthusiast or simply fascinated by the orchestration behind the scenes, Andy's insights offer a unique lens into the world of tech events.Wrapping up the discussion, the podcast takes a lighthearted detour through personal anecdotes and the shared excitement for both the upcoming RailsConf and the cherished Brighton Ruby conference. The warmth of reconnection and the buzz of collective anticipation for future engagements leave us with a sense of renewed community spirit. Join us on this engaging journey through the ins and outs of bringing a beloved industry gathering to life.Links@andycroll on Twitter@brightonruby on Twitter@railsconf on Twitter@andycroll@ruby.social on MastodonRailsConf 2024 CFPrailsconf.organdycroll.combrightonruby.comSupport the showReady to start your own podcast?This show is hosted on Buzzsprout and it's awesome, not to mention a Ruby on Rails application. Let Buzzsprout know we sent you and you'll get a $20 Amazon gift card if you sign up for a paid plan, and it helps support our show.SponsorsA big thanks to OBLSK for being the very first sponsor of the show!

amazon wifi cto wrapping holy grail buzzsprout ruby on rails railsconf andy croll

406: Working Solo

The Bike Shed

Play Episode Listen Later Nov 14, 2023 32:27

Joël got to do some pretty fancy single sign-on work. And when it came time to commit, he documented the ridiculous number of redirects to give people a sense of what was happening. Stephanie has been exploring Rails callbacks and Ruby debugging tools, using methods like save_callbacks and Kernel.caller, and creating a function call graph to better understand and manage complex code dependencies. Stephanie is also engaged in an independent project and seeking strategies to navigate the challenges of solo work. She and Joël explore how to find external support and combat isolation, consider ways to stimulate creativity, and obtain feedback on her work without a direct team. Additionally, they ponder succession planning to ensure project continuity after her involvement ends. They also reflect on the unique benefits of solo work, such as personal growth and flexibility. Stephanie's focus is on balancing the demands of working independently while maintaining a connected and sustainable professional approach. ASCII Sequence Diagram Creator (https://textart.io/sequence) Callback debugging methods (https://andycroll.com/ruby/find-list-debug-active-record-callbacks-in-the-console/) Kernel.caller (https://ruby-doc.org/core-3.0.2/Kernel.html#method-i-caller) Method.source_location (https://ruby-doc.org/core-3.0.2/Method.html#method-i-source_location) Building web apps by your lonesome by Jeremy Smith (https://www.youtube.com/watch?v=Rr871vmV4YM) Transcript: STEPHANIE: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Stephanie Minn. JOËL: And I'm Joël Quenneville. And together, we're here to share a bit of what we've learned along the way. STEPHANIE: So, Joël, what's new in your world? JOËL: I got to do something really fun this week, where I was doing some pretty fancy single sign-on work. And when it came time to commit, I wanted to document the kind of ridiculous number of redirects that happen and give people a sense of what was going on. And for my own self, what I had been doing is, I had done a sequence diagram that sort of shows, like, three different services that are all talking to each other and where they redirect to each other as they all go through the sequence to sign someone in. And I was like, how could I embed that in the commit message? Because I think it would be really useful context for someone trying to get an overview of what this commit is doing. And the answer, for me, was, can I get this sequence diagram in ASCII form somewhere? And I found a website that allows me to do this in ASCII art. It's the textart.io/sequence. And that allows me to create a sequence diagram that gets generated as ASCII art. I can copy-paste that into a commit message. And now anybody else who is like, "What is it that Joël is trying to do here?" can look at that and be like, "Oh, oh okay, so, we got these, like, four different places that are all talking to each other in this order. Now I see what's happening." STEPHANIE: That's super neat. I love the idea of having it directly in your commit message just because, you know, you don't have to go and find a graph elsewhere if you want to understand what's going on. It's right there for you, for future commit explorers [laughs] trying to understand what was going on in this snippet of time. JOËL: I try as much as possible to include those sorts of things directly in the commit message because you never know who's reading the commit. They might not have access to some sort of linked resource. So, if I were like, "Hey, go to our wiki and see this link," like, sure, that would be helpful, but maybe the person reading it doesn't have access to the wiki. Maybe they do have access, but they're not on the internet right now, and so they don't have access to the wiki. Maybe the wiki no longer exists, and that's a dead link. So, as much as possible, I try to embed context directly in my commit messages. STEPHANIE: That's really cool. And just another shout out to ASCII art, you know [laughs], persevering through all the times with our fancy tools. It's still going strong [laughs]. JOËL: Something about text, right? STEPHANIE: Exactly. I actually also have a diagram graph thing to share about what's new in my world that is kind of in a similar vein. Another thoughtboter and former guest on the show, Sara Jackson, shared in our dev channel about this really cool mural graph that she made to figure out what was going on with callbacks because she was working on, you know, understanding the lifecycle of this model and was running into, like, a lot of complex behavior. And she linked to a really neat blog post by Andy Croll, too, that included a little snippet sharing a few callback debugging methods that are provided by ActiveRecord. So, basically, you can have your model and just call double underscore callbacks. And it returns a list of all the callbacks that are defined for that model, and I thought that was really neat. So, I played around with it and copypastad [laughs] the snippet into my Rails console to figure out what's going on with basically, like, the god object of that that I work in. And the first issue I ran into was that it was undefined because it turns out that my application was on an older [laughs] version of Rails than that method was provided on. But, there are more specific methods for the types of callbacks. So, if you are looking specifically for all the callbacks related to a save or a destroy, I think it's save underscore callbacks, right? And that was available on the Rails version I was on, which was, I think, 4. But that was a lot of fun to play around with. And then, I ended up chatting with Sara afterwards about her process for creating the diagram after, you know, getting a list of all these methods. And I actually really liked this hybrid approach she took where, you know, she automated some parts but then also manually, like, went through and stepped through the code and, like, annotated notes for the methods as she was traversing them. And, you know, sometimes I think about, like, wow, like, it would be so cool if this graph just generated automatically, but I also think there is some value to actually creating it yourself. And there's some amount of, like, mental processing that happens when you do that, as opposed to, like, looking at a thing that was just, you know, generated afterwards, I think. JOËL: Do you know what kind of graph Sara generated? Was it some kind of, like, function call graph, or was it some other way of visualizing the callbacks? STEPHANIE: I think it was a function call graph, essentially. It even kind of showed a lot of the dependencies, too, because some of the callback functions were quite complicated and then would call other classes. So, there was a lot of, I think, hidden dependencies there that were unexpected, you know, when you think you're just going to create a regular old [laughs] record. JOËL: Yeah, I've been burned by unexpected callbacks or callbacks that do things that you wouldn't want in a particular context and then creating bad data or firing off external services that you really didn't want, and that can be an unpleasant surprise. I appreciate it when the framework offers debugging tools and methods kind of built-in, so these helpers, which I was not aware of. It's really cool because they allow you to kind of introspect and understand the code that you're going through. Do you have any others like that from Rails or Ruby that you find yourself using from time to time to help better understand the code? STEPHANIE: I think one I discovered recently was Kernel.caller, which gives you the stack trace wherever you are when executing. And that was really helpful when you're not raising an exception in certain places, and you need to figure out the flow of the code. I think that was definitely a later discovery. And I'm glad to have it in my back pocket now as something I can use in any kind of Ruby code. JOËL: That can, yeah, definitely be a really useful context to have even just in, like, an interactive console. You're like, wait a minute, where's this coming from? What is the call stack right now? STEPHANIE: Do you have any debugging tools or methods that you like to use that maybe are under the radar a little bit? JOËL: One that I really appreciate that's built into Ruby is the source location method on the method object, so Ruby has a method object. And so, when you're dealing with some sort of method and, like, maybe it got generated programmatically through metaprogramming, or maybe it's coming from a gem or something like that, and you're just like, where is this define? I'm trying to find it. If you're in your editor and you're doing stuff, maybe you could run some sort of search, or maybe it has some sort of keyword lookup where you can just find the definition of what's under your cursor. But if you're in an interactive console, you can create a method object for that method name and then call dot source location on it. And it will tell you, here's where it's defined. So, very handy in the right circumstances. STEPHANIE: Awesome. That's a great tip. JOËL: Of course, one of the most effective debugging tools is having a pair, having somebody else work with you, but that's not always something that you have. And you and I were talking recently about what it's like to work solo on a project. Because you're currently on a project, you're solo, at least from the thoughtbot side of things. You're embedding with a team, with a client. Are you working on kind of, like, a solo subtask within that, or are you still kind of embedding and interacting with the other teammates on a regular basis? STEPHANIE: Yeah. So, the past couple of weeks, I am working on more of a solo initiative. The other members of my client team are kind of ramping up on some other projects for this next quarter. And since my engagement is ending soon, I'm kind of left working on some more residual tasks by myself. And this is new for me, actually. I've not really worked in a super siloed by-myself kind of way before. I usually have at least one other dev who I'm, like, kind of partnering up with on a project, or an epic, or something like that. And so, I've had a very quiet week where no one is, you know, kind of, like, reaching out to me and asking me to review their code, or kind of checking in, or, you know, asking me to check in with them. And yeah, it's just a little bit different than how I think I like to normally work. I do like to work with other people. So, this week has been interesting in terms of just kind of being a more different experience where I'm not as actively collaborating with others. JOËL: What do you think are some of the biggest challenges of being kind of a little bit out in your own world? STEPHANIE: I think the challenges for me can definitely be the isolation [laughs], and also, what kind of goes hand in hand with that is when you need help, you know, who can you turn to? There's not as much of an obvious person on your team to reach out to, especially if they're, like, involved with other work, right? And that can be kind of tough. Some of the other ones that I've been thinking about have been, you know, on one hand, like, I get to make all of the decisions that I want [laughs], but sometimes you kind of get, like, really in your own head about it. And you're not in that space of, like, evaluating different solutions that you maybe might not think of. And I've been trying to figure out how to, like, mitigate some of that risk. JOËL: What are some of the strategies that you use to try to balance, like making good decisions when you're a bit more solo? Do you try to pull in someone from another team to talk ideas through? Do you have some sort of internal framework that you use to try to figure out things on your own? What does that look like? STEPHANIE: Yeah, luckily, the feature I'm working on is not a huge project. Well, if it were, I think then I wouldn't be alone on it. But, you know, sometimes you find yourself kind of tasked with one big thing for a while, and you are responsible for from start to finish, like all of the architectural decisions to implementation. But, at least for me, the scope is a little more narrow. And so, I don't feel as much of a need to get a lot of heads together because I at least feel somewhat confident in what I'm doing [laughs]. But I have found myself being a bit more compelled to kind of just verbalize what I'm doing more frequently, even to, like, myself in Slack sometimes. It's just like, I don't know who's reading this, but I'm just going to put it out there because maybe someone will see this and jump in and say, "Oh, like, interesting. Here's some other context that I have that maybe might steer you away from that," or even validating what I have to say, right? Like, "That sounds like a good idea," or, you know, just giving me an emoji reaction [laughs] is sometimes all I need. So, either in Slack or when we give our daily sync updates, I am, I think, offering a little more details than I might if I already was working with someone who I was more in touch with in an organic way. JOËL: And I think that's really powerful because it benefits you. Sort of by having to verbalize that or type it out, you, you know, gain a little bit of self-awareness about what you're trying to do, what the struggles are. But also, it allows anybody else who has potentially helpful information to jump in. I think that's not my natural tendency. When I'm on something solo, I tend to kind of, like, zoom in and focus in on something and, like, ignore a little bit of the world around me. Like, that's almost the time when I should look at overcommunicating. So, I think most times I've been on something solo, I sort of keep relearning this lesson of, like, you know, it's really important to constantly be talking out about the things that you're doing so that other people who are in a broader orbit around you can jump in where necessary. STEPHANIE: Yeah, I think you actually kind of touched on one of the unexpected positives, at least for me. Something I wasn't expecting was how much time I would have to just be with my thoughts. You know, as I'm implementing or just in my head, I'm mulling over a problem. I have less frequent, not distractions necessarily, but interruptions. And sometimes, that has been a blessing because I am not in a spot where I have a lot of meetings right now. And so, I didn't realize how much generative thought happens when you are just kind of, like, doing your own thing for a little bit. I'm curious, for you, is that, like, a space that you enjoy being when you're working by yourself? And I guess, you know, you were saying that it's not your natural state to kind of, like, share what's going on until maybe you've fully formed an idea. JOËL: I think I often will regret not having shared out before everything is done. The times that I have done it, I've been like, that was a really positive experience; I should do that more. I think it's easy to sort of wait too long before sharing something out. And with so many things, it feels like there's only one more small task before it's done. Like, I just need to get this one test to go green, and then I can just put up a PR, and then we'll have a conversation about it. But then, oh, this other test broke, or this dependency isn't installing correctly. And before you know it, you've spent a whole day chasing down these things and still haven't talked. And so, I think if some of those things were discussed earlier, it would help both to help me feel more plugged in, but also, I think everybody else feels like they're getting a chance to participate as well. STEPHANIE: So, you mentioned, you know, obviously, there's, like, the time spent just arriving at the solution before sharing it out for feedback. But have you ever been in a position where there is no one to give you feedback and, like, not even a person to review your code? JOËL: That's really challenging. So, occasionally, if I'm working on a project, maybe it would be, like, very early-stage startup that maybe just has, like, a founder, and then I'm, like, the only technical person on the team, generally, what I'll try to do is to have some kind of review buddy within thoughtbot, so some other developer who's not staffed on my project but who has access to the code such that I can ask them to say, "Hey, can you just take a look at this and give me a code review?" That's the ideal situation. You know, some companies tend to lock things down a lot more if you're dealing with something like healthcare or something like that, where there might be some concerns around personal information, that kind of thing. But generally, in those cases, you can find somebody else within the company who will have some technical knowledge who can take a look at your code; at least, that's been my experience. STEPHANIE: Nice. I don't think I've quite been in that position before; again, I've really mostly worked within a team. But there was a conference talk I watched a little bit ago from Jeremy Smith, and it was called Building Web Apps by Your Lonesome. And he is a, like, one-man agency. And he talked about, you know, what it's like to be in that position where you pretty much don't have other people to collaborate with, to review your code. And one thing that he said that I really liked was shifting between writer and editor mode. If you are the person who has to kind of just decide when your code is good enough to merge, I like that transition between, like, okay, I just spent however many hours putting together the solution, and now I'm going to look at it with a critical eye. And sometimes I think that might require stepping away for a little bit or, like, revisiting it even the next day. That might be able to help see things that you weren't able to notice when you were in that writing mode. But I have found that distinction of roles really helpful because it does feel different when you're looking at it from those two lenses. JOËL: I've definitely done that for some, like, personal solo projects, where I'm participating in a game jam or something, and then I am the only person to review my code. And so, I will definitely, at that point, do a sort of, like, personal code review where I'll look at it. Maybe I'm doing PRs on GitHub, and I'm just merging. Maybe I'm just doing a git diff and looking at a commit in the command line on my own machine. But it is useful, even for myself, to sort of switch into that editor mode and just kind of look at everything there and say, "Is it in a good place?" Ideally, I think I do that before putting it out for a co-worker's review, so you kind of get both. But on a solo project, that has worked actually pretty well for me as well. STEPHANIE: One thing that you and I have talked about before in a different context, I think, when we have chatted about writing conference talks, is you are really great about focusing on the audience. And I was thinking about this in relation to working solo because even when you are working by yourself on a project, you're not writing the code for yourself, even though you might feel like [laughs] it in the moment. And I also kind of like the idea of asking, like, who are you building for? You know, can you ask the stakeholder or whoever has hired you, like, "Who will maintain this project in the future?" Because likely, it won't be you. Hopefully, it won't be you unless that's what you want to be doing. There's also what my friend coined the circus factor as opposed to the bus factor, which is, like, if you ran away to the circus tomorrow [laughs], you know, what is the impact that would have? And yeah, I think working solo, you know, some people might think, like, oh, that gives me free rein to just write the code exactly how I want to, how I want to read it. But I think there is something to be said about thinking about the future of who will be [inaudible 18:10] what you just happen to be working on right now. JOËL: And keep in mind that that person might be future you who might be coming back and be like, "What is going on here?" So, yeah, audience, I think, is a really important thing to keep in mind. I like to ask the question, if somebody else were looking at this code, and somebody else might be future me, what parts would they be confused by? If I was walking somebody else through the code for the first time, where would they kind of stop me through the walkthrough and be like, "Hey, why is this happening? What's the connection between these two things? I can see they're calling each other, but I don't know why." And that's where maybe you put in a comment. Maybe you find a better method or a class name to better explain what happens. Maybe you need to put more context in a commit message. There's all sorts of tools that we can use to better increase documentation. But having that pause and asking, "What will confuse someone?" is, I think, one of the more powerful techniques I do when I'm doing self-review. STEPHANIE: That's really cool. I'm glad you mentioned that, you know, it could also be future you. Because another thing that Jeremy says in this talk that I was just thinking about is the idea of optimizing for autonomy. And there's a lot to be said there because autonomy is like, yeah, like, you end up being the person who has to deal with problems [laughs], you know, if you run into something that you can't figure out, and, ideally, you'll have set yourself up for success. But I think working solo doesn't mean that you are in your own universe by yourself completely. And thinking about future, you, too, is kind of, like, part of the idea that the person in this moment writing code will change [laughs]. You'll get new information. Maybe, like, you'll find out about, like, who might be working on this in the future. And it is kind of a fine balance between making sure that you're set up to handle problems, but at the same time, maybe it's that, like, you set anyone up to be able to take it away from where you left it. JOËL: I want to take a few moments to sort of talk a little bit about what it means to be solo because I think there are sort of multiple different solo experiences that can be very different but also kind of converge on some similar themes. Maybe some of our listeners are listening to us talking and being like, "Well, I'm not at a consultancy, so this never happens to me." But you might find yourself in that position. And I think one that we mentioned was maybe you are embedded on a team, but you're kind of on a bit of a larger project where you're staffed solo. So, even though you are part of a larger team, you do feel like the initiative that you're on is siloed to you a little bit. Are there any others that you'd like to highlight? STEPHANIE: I think we also mentioned, you know, if you're a single developer working on an application because you might be the first technical hire, or a one-person agency, or something, that is different still, right? Because then your community is not even your company, but you have to kind of seek out external communities on social networks, or Slack groups, or whatever. I've also really been interested in the idea of developers kind of being able to be rotated with some kind of frequency where you don't end up being the one person who knows everything about a system and kind of becomes this dependency, right? But how can we make projects so, like, well functioning that, like, anyone can step in to do some work and then move on? If that's just for a couple of weeks, for a couple of months. Do you have any thoughts about working solo in that kind of situation where you're just stepping into something, maybe even to help someone out who's, you know, on vacation, or kind of had to take an unexpected leave? JOËL: Yeah, that can be challenging. And I think, ideally, as a team, if you want to make that easier, you have to set up some things both on a, like, social level and on a tactical level, so all the classic code quality things that you want in place, well structured, encapsulated code, good documentation, things like that. To a certain extent, even breaking down tasks into smaller sort of self-sufficient stories. I talk a lot about working incrementally. But it's a lot easier to say, "Hey, we've got this larger story. It was broken down into 20 smaller pieces that can all be shipped independently, and a colleague got three of them done and then had to go on leave for some reason. Can you step in and do stories 4 through 20?" As opposed to, "Hey, we have this big, amorphous story, and your colleague did some work, and it kind of is done. There's a branch with some code on it. They left a few notes or maybe sent us an email. But they had to go on leave unexpectedly. Can you figure it out and get it done?" The second scenario is going to be much more challenging. STEPHANIE: Yeah, I was just thinking about basically what you described, right? Where you might be working on your own, and you're like, well, I have this one ticket, and it's capturing everything, and I know all that's going on [laughs], even though it's not quite documented in the ticket. But it's, you know, maybe on my branch, or in my head, or, worst of all, on my local machine [laughs] without being pushed up. JOËL: I think maybe that's an anti-pattern of working solo, right? A lot of these disciplines that you build when you're working in a team, such as breaking up tickets into smaller pieces, it's easy to kind of get a little bit lazy with them when you're working solo and let your tickets inflate a little bit, or just have stuff thrown together in branches on your local machine, which then makes it harder if somebody does need to come in to either collaborate with you or take over from you if you ever need to step aside. STEPHANIE: Right. I have definitely seen some people, even just for their personal projects, use, like, a Trello board or some other project management tool. And I think that's really neat because then, you know, obviously, it's maybe just for their own, like, self-organization needs, but it's, like, that recognition that it's still a complicated project. And just because they're working by themselves doesn't mean that they can't utilize a tool for project management that is meant for teams or not even teams [laughs], you know, people use them for their own personal stuff all the time. But I really like that you can choose different levels of how much you're documenting for your future self or for anyone else. You had mentioned earlier kind of the difference between opening up a PR for you...you have to merge your branch into main or whatever versus just committing to main. And that distinction might seem, like, if you were just working on a personal project, like, oh, you know, why go through the extra step? But that can be really valuable in terms of just seeing, like, that history, right? JOËL: I think on solo projects, it can really depend on the way you tend to treat your commit history. I'm very careful with the history on the main branch where I want it to tell a sort of, like, cohesive story. Each commit is kind of, like, crafted a little bit. So, even when I'm working solo and I'm committing directly to master or to the main branch, I'm not just, like, throwing random things there. Ideally, every commit is green and builds and is, like, self-contained. If you don't have that discipline, then it might be particularly valuable to go through the, like, a branching system or a PR system. Or if you just want, like, a place to experiment, just throw a bunch of code together, a bunch of things break; nothing is cohesive, that's fine. It's all a work in progress until you finally get to your endpoint, and then you squash it down, or you merge it, or whatever your workflow is, and then it goes back into the main branch. So, I think that for myself, I have found that, oftentimes, I get not really a whole lot of extra value by going through a branching and PR system when it's, like, a truly solo project, you know, I'm building a side project, something like that. But that's not necessarily true for everyone. STEPHANIE: I think one thing I've seen in other people's solo projects is using a PR description and, you know, having the branching strategy, even just to jot down future improvements or future ideas that they might take with the work, especially if you haven't kind of, like, taken the next step of having that project management system that we talked about. But there is, like, a little more room for some extra context or to, like, leave yourself little notes that you might not want necessarily in your commit history but is maybe more related to this project being, like, a work in progress where it could go in a lot of different directions, and you're figuring that out by yourself. JOËL: Yeah, I mean, definitely something like a draft PR can be a great place to have work in progress and experiment and things like that. Something you were saying got me wondering what distinction you typically have between what you would put in a commit message versus something that you would put in a PR description, particularly given that if you've got, like, a single commit PR, GitHub will automatically make the commit message your PR message as well. STEPHANIE: This has actually evolved for me over time, where I used to be a lot more reliant on PR descriptions holding a lot of the context in terms of the decision-making. I think that was because I thought that, like, that was the most accessible place of information for reviewers to find out, you know, like, why certain decisions were made. And we were using, you know, PR templates and stuff like that. But now the team that I'm working on uses commit message templates that kind of contain the information I would have put in a PR, including, like, motivation for the change, any risks, even deployment steps. So, I have enjoyed that because I think it kind of shortens the feedback loop, too, right? You know, you might be committing more frequently but not, you know, opening a PR until later. And then you have to revisit your commits to figure out, like, okay, what did I do here? But if you are putting that thought as soon as you have to commit, that can save you a little bit of work down the line. What you said about GitHub just pulling your commit message into the PR description has been really nice because then I could just, like, open a thing [laughs]. And that has been nice. I think one aspect that I really like about the PR is leaving myself or reviewers, like, notes via comments, like, annotating things that should not necessarily live in a more permanent form. But maybe I will link to documentation for a method that I'm using that's a little less common or just add some more information about why I made this decision over another at a more granular level. JOËL: Yeah, I think that's probably one of the main things that I tend to put in a PR message rather than the commit message is any sort of extra information that will be helpful at review time. So, maybe it's a comment that says, "Hey, there is a lot of churn in this PR. You will probably have a better experience if you review this in split view versus unified view," things like that. So, kind of, like, meta comments about how you might want to approach reviewing this PR, as opposed to something that, let's say somebody is reviewing the history or is, like, browsing the code later, that wouldn't be relevant to them because they're not in a code review mindset. They're in a, like, code reading, code understanding mindset or looking at the message to say, "Why did you make the changes? I saw this weird method. Why did you introduce that?" So, hopefully, all of that context is in the commit message. STEPHANIE: Yeah, you reminded me of something else that I do, which is leave notes to my future self to revisit something if I'm like, oh, like, this was the first idea I had for the, you know, the way to solve this problem but, you know, note to self to look at this again tomorrow, just in case I have another idea or even to, like, you know, do some more research or ask someone about it and see if they have any other ideas for how to implement what I was aiming for. And I think that is the editor mode that we were talking about earlier that can be really valuable when you're working by yourself to spend a little extra time doing. You know, you are essentially optimizing for autonomy by being your own reviewer or your own critic in a healthy and positive way [laughs], hopefully. JOËL: Exactly. STEPHANIE: So, at the beginning of this episode, I mentioned that this is a new experience for me, and I'm not sure that I would love to do it all of the time. But I'm wondering, Joël, if there are any, you know, benefits or positives to working solo that you enjoy and find that you like to do just at least for a short or temporary amount of time. JOËL: I think one that I appreciate that's maybe a classic developer response is the heads downtime, the focus, being able to just sit down with a problem and a code editor and trying to figure it out. There are times where you really need to break out of that. You need somebody else to challenge you to get through a problem. But there are also just amazing times where you're in that flow state, and you're getting things done. And that can be really nice when you're solo. STEPHANIE: Yeah, I agree. I have been enjoying that, too. But I also definitely am looking forward to working with others on a team, so it's kind of fun having to get to experience both ways of operating. On that note, shall we wrap up? JOËL: Let's wrap up. STEPHANIE: Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeeeeeeee!!!!!! AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

pr building solo method sort slack github rails trello prs mandy moore kernel callback jeremy smith ascii quenneville activerecord sara jackson stephanie yeah stephanie so andy croll stephanie right

Live at Rails World 2023

Remote Ruby

Play Episode Listen Later Nov 3, 2023 33:09

In this live afterparty episode from Rails World 2023, Jason, Chris, and Andrew are joined by Andy Croll, Robby Russell, William Kennedy, and Jason Cheal. Today, they discuss various aspects of the Rails World conference, sharing experiences and loads of humor. With each guest, they have conversations about their conference experiences, Ruby confessions, and the vibrant Ruby community. Also, they explore the behind-the-scenes work of core contributors to Ruby on Rails and discuss the significance of awards and recognition in the Ruby world.[00:00:46] Andy talks about his favorite part of Rails World which is the joy of not having to travel across the Atlantic for a Ruby event and he can simply attend this one.[00:01:40] Chris won an award and he's trying to figure out how he's going to take the giant check home, and he jokes about having a wall of giant checks at home. [00:02:24] Andy suggests using Honeybadger and they thank Buzzsprout for their support and comment on the quality of the podcast hosting service. [00:02:49] Andrew mentions the great talks from Chris and Jason, and Chris talks about his experience presenting at the conference and the challenges of staying within the time limit. Jason tells us about his presentation gags and creating presentations with humor. [00:04:46] What was everyone's favorite part of the conference? Chris talks about enjoying talking to people, attending their talks, and Remote Ruby stickers. They all mention the venue was impressive, and how they enjoy Amsterdam, the food, and friendliness of the people. Also, next year it will take place in Toronto. [00:07:34] Jason shares an unconventional life hack involving airport parking. [00:09:52] Robby Russell arrives and describes the conference as inspirational and asks Jason what he learned from the Rails Core team. [00:11:27] Robby discusses the goal of the panel was to show that anyone can contribute to projects like Ruby on Rails without a computer science degree, and he talks about the large number of project contributors and audience interaction. Chris expresses appreciation for core contributors' work behind the scenes.[00:13:51] The panel discusses awards and Ruby Heroes. Robby talks about his contact with Rick Olson (technoweenie) and his contributions to Z shell and “Oh My ZSH!” and he talks about his band “The Mighty Missoula” and recording a new album.[00:19:24] William Kennedy is joining us now and they discuss his famous blog post on Single Page Applications (SPAs). They discuss the satisfaction of coding humor and how frustrating errors can be.[00:23:43] The conversation takes a turn towards sharing Ruby confessions, starting with William's early metaprogramming mistake. Chris recalls a Python experience related to metaprogramming and potential security issues. [00:25:11] William shares how he won the ticket to Rails World 2023, and he shares his appreciation for the banter and personal stories shared on Remote Ruby. [00:26:41] Vladimir Dementyev joins us and gives a signed copy of his book, Layered Design, to Chris. [00:29:18] Chris discusses his role as a luminary and his contributions to the Ruby community. [00:30:39] Julian Cheal, a Rails developer from Bath, joins us and shares his experiences attending Ruby conferences in Romania and Amsterdam. He confesses to writing bad code when using Sonic Pi and DRb to send MIDI data to instruments. Honeybadger Honeybadger is an application health monitoring tool built by developers for developers.BuzzSprout Podcast Hosting Made Easy.Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.

toronto atlantic amsterdam romania bath python rails buzzsprout midi honey badger ruby on rails drb william kennedy sonic pi oh my zsh rick olson andy croll

Episode 479: Create What You Want to Exist: Brighton Ruby (Brittany + Nick + Andy)

Play Episode Listen Later Jul 19, 2023 35:07

Brittany and Nick sync up after Nick's one-night-only talk at Brighton Ruby 2023. It wouldn't be a recap without the conference organizer so they were lucky to find Andy Croll free to fill them in on why he continues to run the event and his thoughts on the uptick on conference attendance. Show Notes: Brighton Ruby Conference (https://brightonruby.com/) Andy Croll's personal site (https://andycroll.com/) scarpe-diem Discord Server (https://discord.com/invite/Ca5EHSsGYp) Sponsored By: Honeybadger (https://www.honeybadger.io/) If you want to simplify your stack, and lower your bills, it's time to check out Honeybager. Honeybadger combines all of those services into one easy to use platform—it's everything you need to keep production healthy and your customers happy. Get started today in as little as 5 minutes at Honeybadger.io (https://www.honeybadger.io/) with plans starting at free!

exist brighton discord server honey badger create what you want andy croll

Favorite Ruby Methods: Part 4 - Enumerables + Bonus Methods

Play Episode Listen Later Feb 23, 2023 37:58

On this episode of Ruby for All, Julie tells us she's fostering a seven week old puppy and having lots of fun, and Andrew reveals he would love to get a dog in the future. Also, it's the end of the month and you know what that means? Andrew and Julie are wrapping up their February series on Ruby Methods, so first up, they'll be discussing the module Enumerable since Andrew learned more about it, we'll find out about polymorphic record, and then on to the object methods tally, partition, sort by, send, is_a, itself, respond_to, .methods, .tap, strftime, and integer.digits. Thanks for joining us on this journey and we hope you enjoyed this series as much as we did! Download this episode now to hear more! [00:01:15] Julie and Andrew share how they both felt about this series, and how they love all the support they've been getting from the listeners. [00:03:10] Andrew kicks things off with explaining module Enumerable since he couldn't explain what it was the other week, he has since learned about it, and now you can too. [00:05:00] Aside from array and hash, Julie wonders if there are other objects that might pull the enumerable in, like set?[00:07:32] Julie explains the object method tally, which returns a hash containing the counts of equal elements, and we hear some examples.[00:08:52] What is a polymorphic record?[00:10:37] Andrew tells us why he likes flat map, and Julie shares it's very readable and when she learned to use it[00:13:01] Our next object method is partition, which Julie explains she hasn't had a chance to use it in practice, and we hear what it does. [00:15:30] The next object method is sort by, with a block given, returns an array of elements of self, sorted according to the value returned by the block for each element. The ordering of equal elements is indeterminate and may be unstable.[00:17:29] Andrew likes the next object method send, which invokes the method identified by symbol, passing it any arguments specified. When the method is identified by a string, the string is converted to a symbol. Andrew explains this one in depth. [00:22:33] The next object method is called is_ a, also an alias for kind of, which returns true if class is the class of object. [00:24:45] Julie put the next object method on the list and Andrew didn't even know about it! The next object method is itself, which returns the receiver. If anyone knows how to use itself in practice, please let Julie and Andrew know. [00:25:52] The next object method is respond_to, and when you should use this.[00:27:43] The next object method is .methods, that returns a list of all the methods that are available to that object, and Andrew uses this for debugging.[00:29:28] Coming up now is the object method .tap, which yields self to the block, and then returns self. The primary purpose of this method is to “tap into” a method chain in order to perform operations on intermediate results within the chain. Julie asks Andrew to explain what strong parameters are and what tap does.[00:33:05] Julie's been using this next object method called strftime, which formats time according to the directives in the given format string. She shares a great resource she used to build, Andrew tells us that Rails has formatted strings, and a website made by Andy Croll. [00:36:45] We made it to the last object method which is integer.digits, and this returns an array of integers representing that number. Panelists:Andrew MasonJulie J.Sponsors:AvoHoneybadgerLinks:Andrew Mason TwitterAndrew Mason WebsiteJulie J. TwitterJulie J. Websitemodule Enumerabletallyflat mappartitionsort bysendis_aitselfrespond to.methods.tapstrftimeinteger digitsFOR A GOOD STRFTIMERails DateTime Formats

technology software methods rails andrew mason enumerable andy croll

Andy Croll - Keep the Weird Stuff Weird

Maintainable

Play Episode Listen Later Feb 6, 2023 49:45

Robby has a chat with Andy Croll (he/him/his), the CTO at CoverageBook, a Rubyist, the Organizer of the Brighton Ruby Conference, an author, speaker, and bootstrapper. The most important thing when it comes to the maintainability of software is “That code is read much more than it's written”, Andy says. He insists that the core focus should always be on readability. Andy will dive into the rationale for why weird things in our code should stay weird until we find a better way to express it and even shared some specific examples within a Ruby on Rails environment. He will share his career journey from the front end into the backend, what prompted him to start the First Ruby Friend project to connect newcomers to a community with people who want to be mentors, examples of how to manage technical debt in a small team and why it's okay to let some stuff "sit in the air", and so much more. Stay tuned. It's going to be an epic one.Book Recommendations:The Overstory by Richard PowersHelpful Links:Andy's websiteOne Ruby ThingBrighton RubyFirst Ruby FriendSubscribe to Maintainable on:Apple PodcastsOvercastSpotifyOr search "Maintainable" wherever you stream your podcasts.Join the discussion in the Maintainable Discord Community

code software engineers programming cto coding organizers software engineers ruby on rails weird stuff technical debt rubyist andy croll

Episode 451: How We Hire Junior Developers with Andy Croll

Play Episode Listen Later Jan 4, 2023 33:52

The podcast voice is back! Andy Croll is starting 2023 off right by joining Brittany to discuss the process they went through at CoverageBook to hire a junior developer. The timing is perfect because TextUs was also hiring a Junior developer so Brittany cons Andy into sharing a bunch of free advice. Happy New Year, listeners! Show Notes & Links: CoverageBook (https://coveragebook.com/) Episode 384 - The TextUs Junior Trio with Saundra Catalina, Jeff Golden and Luke Mason (https://www.therubyonrailspodcast.com/384) My First Ruby Friend (https://firstrubyfriend.org/) One Ruby Thing - Andy Croll (https://andycroll.com/ruby/) Chats in the Cupboard (https://chatsinthecupboard.com/) Sponsored By: Honeybadger (https://www.honeybadger.io/) Status Pages now come with incident management! Build confidence with a public status page that shows your live service status, incident history, and more—and bring your own domain! Transparency inspires trust—when your next outage happens, communication is key. Go to Honeybadger.io (https://www.honeybadger.io/) to learn more. Atlantis Technology (https://www.atlantistech.com/careers) Atlantis is looking for great engineers! Why work at Atlantis? You'll work with great people. You'll work on projects that change the world. No matter where you are in your career, they're prepared to help you advance it. Find out more here (https://www.atlantistech.com/careers).

happy new year hire transparency developers atlantis honey badger cupboard textus andy croll luke mason

Reading Source Code with Daniel Colson

Play Episode Listen Later Dec 22, 2022 31:48

Timestamps[00:45] Daniel Colson is our guest today and gives a brief introduction. He is also a FactoryBot maintainer and explains what it is.[02:40] Andrew is curious about the relation to Music majors and programming and Daniel has some ideas on it.[03:20] How much of your time is spent reading code? Daniel talks about the different types of code programmers often have to read and the benefits that come along with it. Andrew explains why he reads a lot of source code and how it made him better at code review.[06:30] Do you copy and paste code without always understanding it fully? You aren't alone! Daniel has some suggestions for trusting your curiosity and how he likes to read gem source code and how the tests can provide lots of clues. [13:38] Daniel has been reading the Ruby source code and dives into the why and his journey into learning C.[20:20] How do we test the performance of code? Daniel suggests using benchmark-ips for Ruby code and why evaluating performance is important. [23:10] Julie asks if Ruby Under a Microscope would be a good book for juniors to read. [25:40] Daniel believes in a concept called "flipped classroom", which he explains and how it applies to learning programming. He also explains how he would prefer to give more interactive conference talks, which Julie and Andrew both encourage.[29:20] Daniel has a new library for profiling FactoryBot that you will definitely want to check out!SponsorSpecial thanks to Andy Croll for personally sponsoring this episode. Be sure to check out firstrubyfriend.org and onerubything.com for nice, free community resources for newer devs!LinksDaniel on GitHubRuby Under a Microscopebenchmark-ipsTestProffactory_bot_profile

music technology reading software rails microscopes source code andrew mason andy croll ruby under

GitHub Codespaces & Julie's RubyConf Mini Recap

Play Episode Listen Later Dec 8, 2022 25:44

Timestamps[00:45] Andrew recaps pairing with Collin and some other folks over the weekend on an open source PR[2:40] Andrew launches a discussion around GitHub Codespace configs for open source projects and how that would have made his life easier. Julie also brings up Tuple as another great tool for pairing[5:15] Julie brings up trying to use Codespaces to pair on Rails, which does have a configuration file [6:00] Andrew gives a basic explanation of what Codespaces, why it's helpful, and some of the struggles he's had with it[10:45] Julie gives Andrew a recap of RubyConf Mini[11:40] Andrew and Julie talk about feeling down after conferences[14:00] Julie talks about why flying is stressful for her and how she got a lucky break on her flight home from the conference[17:00] Julie talks about the speaker dinner prior to the conference and some of the other events she attended[18:30] Julie talks about giving her talk. And don't worry! She had a nodder![20:00] Julie talks about being on the conference panel that you all heard last week[22:00] Andrew wants to hear about the food and Julie delivers![23:30] Julie gives her final thoughts on the conference and Andrew advocates for doing more local conferencesSponsorSpecial thanks to Andy Croll for personally sponsoring this episode. Be sure to check out firstrubyfriend.org and onerubything.com for nice, free community resources for newer devs!LinksTupleGitHub CodespacesUsing Codespaces with VS Code

technology pr software github rails vs code andrew mason tuple github codespaces rubyconf codespaces andy croll

364: Constructive vs Predicative Data

The Bike Shed

Play Episode Listen Later Dec 6, 2022 34:07

Stephanie and Joël attended RubyConf Mini, and both spoke there. They discuss takeaways and highlights from the conference. The core idea for this episode is explained in this article: Constructive vs. Predicative Data (https://www.hillelwayne.com/post/constructive/). This came up recently in a conversation at thoughtbot about designing a database schema and what constraints could be encoded in the schema directly versus needing some kind of trigger or Rails validation to cover it. This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. RubyConf Mini (https://www.rubyconfmini.com/) Episode on CFP - The Bike Shed 352: Case Expressions (https://www.bikeshed.fm/352) Podcast panel: The Ruby on Rails Podcast Episode 446: I'm Giving A Talk on Thursday (https://www.therubyonrailspodcast.com/446) Slides for FP talk: Functional Programming for Fun and Profit!! (https://speakerdeck.com/jennyshih/functional-programming-for-fun-and-profit?slide=107) Episode on language: The Bike Shed - 356: The Value of Specialized Vocabulary (https://www.bikeshed.fm/356) Constructive vs. Predicative data (https://www.hillelwayne.com/post/constructive/) Avoid the Three-state Boolean Problem (https://thoughtbot.com/blog/avoid-the-threestate-boolean-problem) Transcript: JOËL: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Joël Quenneville. STEPHANIE: And I'm Stephanie Minn. And together, we're here to share a bit of what we've learned along the way. JOËL: So something that's very recent in both of our worlds has been that both you and I, Stephanie, attended RubyConf Mini, and we both spoke there. What are some of your takeaways or highlights from the conference? STEPHANIE: Seeing you in person was definitely a highlight. I really enjoyed that. Because we're working remotely, I don't, you know, get to be in an office with you day to day. And it was really awesome to hang out with you, I think, for the first time as co-hosts of the podcast. And we both, I think, met some people at the conference too that were listeners. And it was really awesome to share that experience with you. JOËL: I had the interesting experience of several people who told me they recognized me by my voice, which I think is a common thing for podcasters, but as a new host, I was surprised by that. STEPHANIE: Yeah, that's weird. As a podcast listener, too, I definitely know exactly what you're talking about where it's like, oh yeah, I can identify someone by their voice. But to then be that person that people can recognize is pretty weird. I also really enjoyed being an audience member of the podcast panel that you are on at the conference with other podcast folks. It was moderated by Brittany Martin. And yeah, I just thought you represented The Bike Shed really well and spoke for both of us about podcasting in a way that I really appreciated. JOËL: And for any of our listeners who were not able to be there in person, Brittany has published that episode as a podcast, and we will link to it in the show notes. STEPHANIE: Another thing I really liked about RubyConf Mini was the smaller scale. I think it was about 150 or so attendees, which felt very different from traditional Ruby Central conferences with several hundreds of people. I heard a lot from other folks there that they really liked the regional aspect of it, the intimacy of the smaller conference. I think I got more of an opportunity to run into people that I'd met at the conference over the next few days. And there was, yeah, definitely a sense of tighter knit community there, you know, when you meet someone, and then you bump into them on the way into a talk, and then you can ask how their day was going and any highlights that they had. And yeah, I guess I haven't really attended a conference that size before, and so that felt like a very special experience for me. JOËL: I 100% agree. I think the smaller format definitely makes it a little bit more intimate, makes it much easier, I think, to build some of those social connections, to meet with people, and to have some good conversations. I think the format of the conference as well favored that. There were, I think, larger breaks between talks that encouraged people to hang out and talk. And, as you said, because it's smaller, you also get to see the same people over the course of a few different breaks instead of being like, oh, I met a stranger on the morning of day one, and then in the afternoon, I met another stranger. And it's just constantly introducing yourself. One thing that was really interesting to me is the experience of being a speaker is very different than just attending. As a speaker, you get to go to the speaker dinner and connect with a lot of the other speakers there. Some of them might be quote, unquote "famous people" that you're not quite comfortable just walking up to and introducing yourself. But in the smaller dinner, you just find yourself sitting next to them and enjoying some food or a drink and getting conversations. It's also much easier to have people come up to you during the conference. Because you're a speaker, people will come and talk to you. So if you tend to be a little bit more introverted, as long as you can get over your fear of being on stage and public speaking, it actually makes social connection interaction much easier to be a speaker. I would recommend to any of our listeners who were wondering how can I get more out of a conference? How can I get better connections, better conversations? Consider being a speaker. STEPHANIE: Yeah, absolutely. We've talked about this before; I think when we chatted about writing our CFPs for this conference that speaking doesn't have to be a really big, scary thing, but everyone has something to say. I think we had mentioned in previous episodes that your talk topic came out of just a discussion that you had internally, and you were like, wow, enumerables are so cool, like, let me dig deeper into them and just share what I learned. So I totally recommend it. And this conference was my first in real-life speaking opportunity as well, and that felt super different from my experience last time doing it virtually, you know, talking about how much I love that sense of community all the time. But it really felt true for me this time around, where I could see the audience react to the things I was saying, like, maybe go off the cuff a little bit. And then yeah, at the end, having people come up to me was really awesome to just talk about pairing, which is what I spoke about, and just share our experiences. And they asked what I thought about some things, and it was really cool to just be able to spread that knowledge around. And one thing I noticed you did a lot was come up to speakers after they wrapped up their talks. You were almost always the first person to get up and congratulate them and just get the ball rolling on following up on the things they talked about. Is that something that you really enjoy doing or find particularly valuable as an audience member or speaker? JOËL: Yes, both. I think, as a speaker, it's really validating to have people come up to you after the talk and either just tell you they liked the talk or ask a question. I generally don't like to do just open questions after a talk from the audience because then you get the classic; this is more of a comment than a question or people who will tell you that you had a typo on one of your code slides. Like, none of that is useful to anyone. So, if you're really interested, come talk to me afterwards. And then that actually makes me feel like my talk connected with people, and people were paying attention, people enjoyed it, people were learning. So I try to pay that forward as well for talks that I listened to, go up to the speaker, and tell them one thing that I appreciated about the talk or a thing that I learned, or something that got me excited in their content. STEPHANIE: Yeah, I'm sure that it's very appreciated. And it also breaks the awkward silence at the end when the speaker finishes and people aren't sure if it's okay for them to get up and start moving around. Yeah, I thought that was a really good way to kind of just encourage people to start chatting with each other and moving into those break times that we mentioned earlier, those opportunities to socialize. JOËL: Another thing that I think is really fun that you can do at in-person conferences, and I know you were doing it a lot, is going to see the talks of friends and colleagues and sitting in the front row and just being there to cheer them on and encourage them. Again, I think that makes a big difference when you are on stage, and you see these people who are your friends and colleagues there to support you. It gives you that boost of confidence. And when you're there in the audience, it's fun to cheer on somebody else. STEPHANIE: Oh yeah. You gave me a lot of thumbs-ups during my talk, and I really appreciated that. [laughs] So I'm curious if there were any talks that stood out to you that you got to see. JOËL: And I was really inspired by your talk, pair programming. I think there are a lot of things that I can take from that to improve the way I pair. I was also inspired by Aji's talk, Aji Slater, on automating manual tasks that you have to do in an iterative way. That one really hit home because, on my current project, I have been doing a lot of manual things. And I just have random snippets of code, like, some shell script lines or Ruby console lines, that I copy-paste out of Slack conversations because I've shared them with other people who are doing similar work. And I realized that a lot of his advice would apply to the work that I'm doing and how that could really make things better. So that was one of those talks I was listening to, and I was like, oh, you know what? Monday morning, when I go back to my project, this is something that I'm going to start doing. This is something I'm going to change in the way I do my day-to-day work. STEPHANIE: Yeah, absolutely. I have so many tasks that I would like to get automated, and think that one day I will magically have more time in my schedule to get to it. But I liked that his talk gave pretty concrete strategies for baking it into your regular, like you said, day-to-day workflow, and that lowers the activation energy to getting them done. And then those things can be iterated on and could eventually become, in an ideal world, a fully-fledged feature that you put together from doing those repetitive tasks. And yeah, they provide a lot of value not just to you but can eventually provide value to your co-workers and then even your users in the future. JOËL: Were there any talks that stood out for you? STEPHANIE: One talk that I really enjoyed was Jenny Shih's about Functional Programming for Fun and Profit. I have attended a lot of functional programming talks within the Ruby realm, at least to try to get a better sense of how it can apply to my work and the languages and paradigms that I use. And honestly, what I liked about it was that it didn't get too in the weeds about functional programming. What she did was provide mental models for understanding the paradigm that I think was a good vehicle for understanding things very generally. And, for me, like,¬¬ a talk, it's really hard to pay attention to lines of code and to read code on the fly while people are presenting. For me, that is just not how I like to consume that information. And so she provided themes and, like I said, those mental models, which I know you really like to use a lot too in teaching people new concepts. For me, I didn't fully learn what a monad was, once again, but at least having that repeated exposure to those foundational aspects, I think, will eventually lead me to be able to grok those things a little more comprehensively the next time I see it or whenever I decide to dig deeper. JOËL: What was a mental model that was shared that connected with you particularly? STEPHANIE: So one of the main mental models that she shared was thinking about a program in terms of these three dimensions: value, behavior, and time. She had a nice slide that showed the difference between the object-oriented paradigm, where value and behavior are contained by objects, where time is kind of inherently wrapped up in those objects that hold information about the state through values and behavior. Whereas in her functional programming example, those three dimensions were a bit separate. And I found that distinction to be really helpful in separating things that felt very implicit before, but it was nice to see them broken out into very clear concepts in terms of building blocks of a program. JOËL: So it's helpful then when thinking...when you look at code, if you can think about it in those three different dimensions to help think about, am I taking a functional or other approach in this particular dimension when working with this code? STEPHANIE: Yeah, exactly. I think it also gave me more of a vocabulary to describe the pros and cons of each and a lens of thinking about which I might want to choose for the particular problem at hand. JOËL: So you mentioned there's a visual for these three dimensions from the slides. Are those slides publicly available? STEPHANIE: They are. I will link to them in the show notes. JOËL: So all of these talks were recorded. They're not yet available to the public, but I think the plan is to publish them on YouTube sometime in the new year, so that means probably January 2023. And a big shout out to the AV team and everyone who is involved in recording these. STEPHANIE: Yeah, I am definitely looking out for a link to my talk so I can send it to my mom. I also wanted to give a little shout-out to the organizers of RubyConf Mini: Jemma Issroff, Emily Samp, and Andy Croll. JOËL: Woo! STEPHANIE: They put on just a really awesome conference, and I feel very grateful that I got a chance to attend with you, Joël. JOËL: It was definitely a delightful experience. STEPHANIE: Delightful. That's a reference to Joël's talk for those of you who are listening. MID-ROLL AD: Debugging errors can be a developer's worst nightmare...but it doesn't have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! Airbrake's debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. In addition to stellar error monitoring, Airbrake's lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! JOËL: Coming back from the conference, I recently had a really interesting conversation with some other colleagues at thoughtbot. We were looking at a database schema for a new application and talking about some of the trade-offs involved in how that schema is structured, so what tables we want to have. Do we want to have indexes? Things like that. And particularly around some of the assumptions are business rules that would come into play. So we're looking at...we'd drawn out this Entity Relationship Diagram (ERD). In it, we're looking at all the tables, and something that comes up immediately is like, oh, it's possible to have some bad data that could show up in these columns. Or it's possible that this relationship could exist where this table has a foreign key on this table, but really, that should never happen in this particular way of working. And so then the question became, how do we try to prevent these things that currently the schema allows but that are not valid in this particular business domain? Do we want to change the schema somehow and make that stricter or find some way to prevent it? Do we want to add some kind of validation that will check some business rules first before inserting or updating a record? I'm curious, have you ever been in a situation like that where you had to balance those two approaches to enforcing business rules on your database? A classic small example of this is a situation where let's say, you have a users' table and you have a name column on there. And you want to ensure that that name must always be present; all users must have names. Do you try to enforce that via the schema with a NOT NULL constraint? Or maybe you try to enforce that with a validation, maybe a presence validation at the Rails level. Or if you're really into SQL, maybe some fancy trigger, but do it in a validation style rather than trying to force this using the schema. And our particular scenario was a little bit more complex than just one column; it was more to do with associations. But I think this sort of problem shows up even in constraints as small as a required field. STEPHANIE: That's really interesting. I think that, in my experience, when we are spinning up new tables, at that point, we do try to put some intentional thought into what the schema should look like and what requirements we might need to encode at the database level. But things that are more complex might need a little more code, like Ruby code. I have then pushed to an ActiveRecord validation. One thing that I think is important to know is that when you do set those things on the schema, it's harder to change. And so you usually have to feel pretty confident that that's what you want. Otherwise, you'll run into issues later if that does have to change and making changes to whatever existing data you might have. But it's also pretty common to just do your best when you are deciding on a database schema and then having to make adjustments down the line as you know more about your domain. JOËL: This conversation reminds me a little bit of the idea of database normalization. I think that might almost fit as a subset of general tactics of using the schema to ensure your data is more correct. When you are generating new tables, let's say you're creating a greenfield app and you need to create four or five tables; how much emphasis do you put on database normalization when you're initially designing those? STEPHANIE: I think for a greenfield project when you are setting everything up and creating tables for your main domain models, there is an aspect of it that should be considered because you're in this unique position where nothing really is in existence yet. And you do want to try to set yourself up to be successful and hopefully have information about your main use case for this app and can kind of make decisions about the schema then. At least in my experience, that has been part of the conversation, though, to be fair, because it's so early, you do have the opportunity to change things without as much effort or pain. But I think it's worth considering when you're just sitting down and working through what those models are going to look like. JOËL: And for our listeners who may not have heard the term normalization before, it's a series of...you can think of them as rules that you apply to your database design to try to avoid data redundancies in your tables. There are different levels of this; they're typically referred to as normal forms. So you'll see things like first normal form, second normal form, third normal form; those are kind of the fancy terms for them. But they generally involve breaking out other tables so that you don't have data redundancies. And in many ways, this is similar to principles such as the single-responsibility principle that we apply to objects when we're designing our objects in an OO system. But this is more at the table level for databases. STEPHANIE: I do think that it is so hard, maybe even impossible, to plan something out, to not have any of those redundancies, to begin with. And I do think sometimes they are a bit inevitable. But I also have had the experience of having to figure out what the heck I'm looking at when I am querying data and see all these things that are duplicated or maybe slightly different. And yeah, I think when you are in that position of starting a greenfield application, it is really interesting to see how you make those decisions about what needs to be enforced and where. Where did you end up landing, or what did you discuss in this conversation with the co-worker? JOËL: I think we went with a bit of a hybrid approach. Some things, we can use the schema to prevent bad data, and then some things either cannot be represented with a schema, or it's possible, but it's really cumbersome and painful. And so, we chose to try to enforce it with a validation. To me, this feels very similar to a problem in typed languages. So some communities that use a lot of types try to use those types to only allow data to come through that's in a valid shape. And so you'll hear things like make impossible states impossible or make illegal states unrepresentable. And that works for many things, but it's not always possible to enforce all of your business constraints through a schema. Or sometimes it's possible but just not practical. And so, I think there is a balance of finding when you can use the schema or when it's better to use the validation.¬ STEPHANIE: Yeah, I think my general rule of thumb is, like I mentioned earlier, things I feel really confident about that we want to make sure that we have in our database or in our data for sure. I do lean towards requiring those in a schema, and it also communicates that confidence or communicates that intent that it's something that at one point was decided is important. And so, if a future developer comes in, it would take a lot of work for them to write a migration, to remove some database constraint. Whereas I think sometimes validations at the Rails level are potentially a little more open to change and then even more so if you get to validating on the client side. JOËL: That can get to be a really, like, it's a useful tool, but one that you can really hurt yourself with. If you modify your validations at the Rails level or at the front-end level, but then you don't backfill those changes on your data in the database, then you might have records in your database that if you were to load them into memory and hit save on them again, would refuse to save because they no longer match the validations. And on longer-lived applications, I've seen that happen sometimes where not all rows in the database pass the Rails validations. STEPHANIE: Yeah, I think I've seen that be a problem either for developers who then have to backfill that data or write some migration to change some of the data to meet the new requirements, or just unexpected bugs on the users who discover something new but like you said, have been there long enough before those things were implemented. JOËL: The more I think of this, I think maybe constraints that are enforced at a validation level might still require changing the data in your database. So if you had a constraint enforced via a schema, you don't have a choice. You have to write some way to migrate that data so that it fits the new schema. You can kind of lie to yourself with validation and not change the historic data, and sometimes that is the case; you want to keep the old data and only prevent new data from being written in the old format. But if you need consistency, then you probably need a data migration regardless of which approach you take. STEPHANIE: Yeah, that definitely sounds like the more robust way to go about it for sure. JOËL: I have an article that I like to reference a lot by Hillel Wayne on Constructive Versus Predicative Data, which is basically looking at these two general approaches to enforcing data correctness and formalizing them a little bit. So do you try to enforce them based on the construction or the shape of the entity that you're creating, be that a database table, an object, a type, something like that? Or do you enforce it via some kind of predicate? So that could be a validation or other similar logic that runs kind of at runtime to enforce your constraints. STEPHANIE: That's interesting. I hadn't heard of those terms before, but I think they provide a lens through which you can look at the problem. Did the article end up suggesting different strategies for solving that problem, or was it more theoretical in different ways to look at it? JOËL: I think the article does two things. First, like you said, it gives us the words to talk about those approaches. And having those labels now, I start seeing them everywhere. I see them in databases, I see them in objects, I see them when doing types across a variety of languages. So that's already a huge win for me. I think you and I had done an episode a couple of months back where we talked about the value of having labels to put to ideas. And I think for me reading that article gave me those two labels. And all of a sudden, it really helped to make connections that I wasn't seeing before. The second thing that the article does is, I think, explore some of the limitations that each approach has and when you might want to use one versus another. The constructive approach, so using a schema, is more consistent because you know it is impossible for the program to create data that's in the wrong shape. That being said, not all constraints can be represented in a constructive manner, or it might be possible but really cumbersome. Also, sometimes it's not really invalid data; it's just sort of undesirable data. So you might want a looser schema. And let's say that you're storing some kind of intermediate state or some kind of raw input from another system that you might want to layer validations on top of, but you don't want to reject that data out of your database. You want that sort of incomplete or imperfect data in your system. Something that I find myself doing more and more these days when I create new tables is to really lock down the schema as much as possible. I think that might be contrary to maybe the way a lot of people in the community like to work. Some people might prefer to start with a very loose schema with no constraints and then work towards making things stricter as they explore the domain, and that's kind of the default that Rails has. If you're creating a new table, all columns, for example, are nullable by default. Personally, I will put a null false on every column and every migration that I make unless somebody can make a convincing case otherwise, and even then, I might try to think of is there any possible way that we could avoid that scenario and put that null false. Part of the reason for that is that it is much easier to loosen constraints on existing data than to tighten them afterwards. So if I have a column where no value is allowed to be null, and then later on we decide, you know what? It is okay for some of them to be null, I can change the requirement on that column, and I don't need to make any changes to the existing data. It just works. If the reverse happens, if I have a column that allows a bunch of nulls and then I want to make that column required, now I have to go and find a way to backfill all the empty spots in that column. And that could be a very challenging process. It might even be impossible. There might be some values there that it's just like, the user did not supply them at the time because we didn't ask for them. And now there's nothing we can put in there. So do you put in, like, unknown or not available? Then you have to ask yourself some really difficult questions about your data. STEPHANIE: Yeah, absolutely. I think I agree with you there. Another thing I like to do is provide default values for columns, especially ones where they can't be null, because, like you were saying, that helps me have a better understanding of just what is going on in the database. An issue I have seen come up involves a Boolean column where if a default value of false, for example, if that's what we're going with, is not encoded in the schema, you end up with potentially three values for a Boolean, which would be true, false, and null, and that I think has been -- JOËL: The infamous three-state Boolean. STEPHANIE: Yeah, exactly, the three-state problem, which is just inherently contradictory to what a Boolean is, to begin with. And I've definitely run into issues with that where you have to decide, or figure out, or write code to determine is null false? Is that what we mean here? It's not clear. But if you, like you said, locked it down at the beginning, provided those default values, that puts in those guardrails to prevent things from getting out of hand. JOËL: It also makes it easier for users of your database, application, whatever to interact with your code. I've run into this a lot when working with GraphQL APIs. And the default in many GraphQL server implementations is to make all fields nullable by default. When you build your schema, you have to add some extra things there to say, "This field is non-nullable," which means that a client that's now consuming it, anytime they deal with the data they need to check, is it present or not? You can't have the confidence that that data is there. And so it can force a lot of extra checks on the client. Or I guess you could just take it on faith and hope nothing breaks. STEPHANIE: Yeah, it's funny you mention that because I definitely think there's like spheres of impact. So as a developer, you maybe start having to write code that checks those kinds of things, like if it's null or not in your code. Then that can even extend to, like you said, your users or consumers of the API, who then have to contend with data that they have no control over. And I've been there too, and that can be frustrating as well. JOËL: We've talked a lot about data correctness and different ways to achieve it, different strategies. Why is this something that we care so much about? STEPHANIE: I think data correctness is really important from a developer experience perspective. And it's way easier to fix a bug in your code than it is to wrangle a lot of accumulated bad data. JOËL: Yeah, sometimes bad data is not fixable at all, and those are situations where you have a really bad day as a developer. STEPHANIE: Agreed. JOËL: Well, on that note, shall we wrap up? STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeee!!!!!!! ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

head data fun profit personally slack api av rails slides constructive sql fp sdks mandy moore oo apm graphql functional programming boolean cfps quenneville aji graphql apis activerecord jenny shih ruby central hillel wayne stephanie yeah stephanie so andy croll stephanie oh stephanie they

BONUS! The Rubyconf Mini Podcast Panel

Play Episode Listen Later Dec 1, 2022 40:37

About this EpisodeLive from Providence, RI, it is the Rubyconf Mini Podcast Panel! Panelists from different community podcasts come together to discuss their experiences at the conference, field questions from the audience attendees and of course, mention their upcoming talks they were giving at the conference. Moderated By:Brittany Martin, The Ruby on Rails Podcast Panelists: Andy Croll, Chats in the Cupboard Drew Bragg, Code and the Coding Coders who Code it Joël Quenneville, The Bikeshed Julie J, Ruby for All A special thanks to the organizers of Rubyconf Mini for making this panel happen: Jemma Issroff, Emily Samp and Andy Croll.

technology code software providence ri rails panelists mini podcast podcast panel quenneville rubyconf andy croll

Episode 446: I'm Giving A Talk on Thursday (The Rubyconf Mini Podcast Panel)

Play Episode Listen Later Nov 30, 2022 43:07

Live from Providence, RI, it is the Rubyconf Mini Podcast Panel! Panelists from different community podcasts come together to discuss their experiences at the conference, field questions from the audience attendees and of course, mention their upcoming talks they were giving at the conference. Moderated By: Brittany Martin, The Ruby on Rails Podcast (https://www.therubyonrailspodcast.com/) Panelists: Andy Croll, Chats in the Cupboard (https://chatsinthecupboard.com/) Drew Bragg, Code and the Coding Coders who Code it (https://podcast.drbragg.dev/) Joël Quenneville, The Bikeshed (https://www.bikeshed.fm/) Julie J, Ruby for All (https://www.rubyforall.com/) A special thanks to the organizers of Rubyconf Mini for making this panel happen: Jemma Issroff, Emily Samp and Andy Croll. Sponsored By: Honeybadger (https://www.honeybadger.io/) Status Pages now come with incident management! Build confidence with a public status page that shows your live service status, incident history, and more—and bring your own domain! Transparency inspires trust—when your next outage happens, communication is key. Go to Honeybadger.io (https://www.honeybadger.io/) to learn more. Scout APM (http://scoutapm.com/rubyonrails) Try their error monitoring and APM free for 14-days, no credit card needed! And as an added bonus for Ruby on Rails listeners: Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at http://scoutapm.com/rubyonrails (http://scoutapm.com/rubyonrails).

live giving code transparency providence ri panelists honey badger ruby on rails cupboard apm mini podcast podcast panel quenneville rubyconf andy croll

Screencasting Basics with Collin Jilbert

Play Episode Listen Later Nov 17, 2022 26:54

Timestamps[0:30] Collin introduces himself![2:40] Andrew asks what it's like to create Ruby on Rails educational content in 2022[3:25] Collin talks about study groups in his bootcamp and how that correlated to student success[4:12] Collin talks about creating his first GoRails video[5:37] Julie asks how many times Collin has to rerecord himself while making screencasts[7:00] Julie asks about the planning process for videos and what that entails[9:49] Andrew asks what kind of software Collin uses when making screencasts[12:58] Collin responds to Julie's discussion of trying to get topics out of your head and admits he still struggles with it[15:10] Julie asks about teaching subjects while also learning them at the same time[18:18] Andrew asks where people should start if they want to start creating screencasts[20:19] Julie asks if people request videos on GoRails[21:47] Julie asks about mob pairing with juniorsSponsorSpecial thanks to Andy Croll for personally sponsoring this episode. Be sure to check out firstrubyfriend.org and onerubything.com for nice, free community resources for newer devs!LinksRuby RadarGoRailsCollin on Twitter

technology software basics rails ruby on rails andrew mason screencasting andy croll

Attending Conferences 101

Play Episode Listen Later Nov 10, 2022 24:30

Timestamps [1:10] Andrew can't do arts and crafts [1:42] Julie is speaking at RubyConf Mini soon! [4:00] Andrew recommends pushing yourself out of your comfort zone and meet new people at conferences [5:20] Julie talks about her experience as a scholar at RailsConf 2022 [10:00] Andrew and Julie share how they try to be more welcoming to others at conferences by making room for people to join you. [11:30] Julie talks about making connections with people [12:20] Julie shares her idea for a "Buddy Bench" at conferences [14:00] Andrew explains the Hallway Track [14:55] How do you decide between attending a talk or a workshop? [15:30] What is the proper way to arrive late or exit early from a talk? [17:15] Julie wants a nodder in her talk and Andrew explains what that is [20:10] Finding dinner friends [20:50] Julie will be your buddy at RubyConf Mini [21:30] Volunteer opportunities at conferences [22:20] Have fun! [24:15] Find Julie at RubyConf Mini for Ruby for All stickers! SponsorSpecial thanks to Andy Croll for personally sponsoring this episode. Be sure to check out firstrubyfriend.org and onerubything.com for nice, free community resources for newer devs!

technology software volunteers conferences attending rails andrew mason railsconf buddy bench andy croll

Updating The PickAxe Book with Noel Rappin

Play Episode Listen Later Nov 3, 2022 21:29

The 1st edition of Programming Ruby, commonly known as "The PickAxe" book, came out in 2001. Now, in 2022, Noel Rappin is releasing the beta of the 5th edition, updated for Ruby 3.2. Why should you pick up the book? To get mind on how Ruby works, what makes it unique, and how Ruby developers think about Ruby.These are some of the topics we cover: How Noel decided the book was ready for early access Noel gives the history of the PickAxe book Why Noel decided to update the book What will be different in the 5th edition What you need to know before reading the book What's left to do before the final edition is ready How long Noel has been working on the book What the expected final release date is What the hardest part of the project has been How Noel recommends you read the book How Rubyists of all levels will benefit from reading the book Why you will benefit from reading the latest edition SponsorSpecial thanks to Andy Croll for personally sponsoring this episode. Be sure to check out firstrubyfriend.org and onerubything.com for nice, free community resources for newer devs!Links Programming Ruby 3.2 (5th Edition) Programming Ruby 3.2 (5th Edition) Devtalk Noel on Twitter Noel's Website Sorbet RubyMine RBS Support

technology software rails andrew mason pickaxe noel rappin programming ruby andy croll

Episode 439: One More Podcast Pitch with Andy Croll

Play Episode Listen Later Oct 12, 2022 35:47

Andy Croll is back and he has something to say. Brittany and Andy chat from their cupboards about My First Ruby Friend, bringing yourself to work, Apple note driven development and Rubyconf Mini. They spend the rest of the episode on Andy's podcast pitch. Show Notes & Links: My First Ruby Friend (https://firstrubyfriend.org/) One Ruby Thing - Andy Croll (https://andycroll.com/ruby/) Rubyconf Mini 2022 (https://www.rubyconfmini.com/) Chats in the Cupboard (https://chatsinthecupboard.com/) Andy Croll (@andycroll) / Twitter (https://twitter.com/andycroll?lang=en) Sponsored By: Honeybadger (https://www.honeybadger.io/) Honeybadger monitors your cron jobs and services to make sure they don't silently disappear. When Honeybadger is quiet, life is good. Check monitoring off your todo list. Try Honeybadger free for 15 days. Atlantis Technology (https://www.atlantistech.com/careers) Atlantis is looking for great engineers! Why work at Atlantis? You'll work with great people. You'll work on projects that change the world. No matter where you are in your career, they're prepared to help you advance it. Find out more here (https://www.atlantistech.com/careers).

apple pitch atlantis honey badger cupboard andy croll

Andy Croll on First Ruby Friend, RubyConfMini and more

Remote Ruby

Play Episode Listen Later Oct 7, 2022 44:03

[00:03:02] Andy tells us some details about RubyConf Mini coming up in November, as well as RubyConf in Houston, TX.[00:08:10] Jason wonders if RubyConf Mini is unique to this year or if it's something that Andy could see happening in the future.[00:12:35] We hear more about the Ruby Friends program that Andy started and he explains how it was born out of frustration.[00:18:29] Find out how many people are currently in the Ruby Friends program and benefit of being a mentor.[00:21:25] Jason talks about how refreshing it's been being a mentor, meeting all the friends along the way, and his new Ruby friend.[00:24:04] Andy explains the key things in a mentor/mentee relationship to make it work.[00:26:02] We find out if Andy's been able to get all the applicants looking for mentorship paired up with someone.[00:27:56] Andy mentioned he was not trying to fix the hiring process yet, and Jason wonders if he's thought about it.[00:32:00] Chris brings up how he started making videos to help newer people when he was only a few years into doing Rails, and Andy talks about how videos are a different kind of learning and a great book he read called, Sustainable Web Development with Ruby on Rails. [00:34:31] The conversation turns to the guys discussing Authentication and Authentication Zero. [00:41:28] Jason talks about the app he built earlier this year and how he went with the Rails has secure password approach.[00:42:18] Find out all the places you can follow Andy on the web.Panelists:Jason CharnesChris OliverGuest:Andy CrollSponsor:HoneybadgerLinks:Jason Charnes TwitterChris Oliver TwitterAndrew Mason TwitterAndy Croll WebsiteAndy Croll TwitterOne Ruby Thing- NewsletterChats in the Cupboard PodcastCoverageBookWhy's (poignant) guide to RubyRubyConf MiniRubyConf Houston, TXFirst Ruby FriendRemote Ruby Podcast-Episode 190: Junior Devs, Mentoring, and Training with Adam CuppySustainable Web Development with Ruby on Rails by David Bryant CopelandAuthentication Zero-GitHubRuby Radar NewsletterRuby Radar Twitter

training friend tx mentoring programming coding rails software development authentication ruby on rails andrew mason chris oliver rubyconf andy croll

Episode 425: The Railsconf At Home 2022 Ruby Podcast Panel

Play Episode Listen Later Jul 6, 2022 43:17

Moderated By: Brittany Martin, The Ruby on Rails Podcast (https://twitter.com/BrittJMartin) Panelists: Aaron Francis, Framework Friends (https://twitter.com/aarondfrancis) Andy Croll, Chats in the Cupboard (https://twitter.com/andycroll) Brian Mariani, The Ruby on Rails Podcast (https://www.mirrorplacement.com/) Drew Bragg, Coding Coders (https://twitter.com/DRBragg) Jason Charnes, Remote Ruby (https://twitter.com/jmcharnes) Jemma Issroff, The Ruby on Rails Podcast (https://twitter.com/JemmaIssroff) Show Notes & Links: Framework Friends (https://www.frameworkfriends.com/) Code and the Coding Coders who Code it (https://podcast.drbragg.dev/) Chats in the Cupboard (https://chatsinthecupboard.com/) Remote Ruby (https://remoteruby.transistor.fm/) Sponsored By: Honeybadger (https://www.honeybadger.io/) Honeybadger makes you a DevOps hero by combining error monitoring, uptime monitoring and check-in monitoring into a single, easy to use platform. Go to Honeybadger.io (https://www.honeybadger.io/) and discover how Starr, Josh, and Ben created a 100% bootstrapped monitoring solution. Scout APM (http://scoutapm.com/rubyonrails) Try their error monitoring and APM free for 14-days, no credit card needed! And as an added bonus for Ruby on Rails listeners: Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at http://scoutapm.com/rubyonrails (http://scoutapm.com/rubyonrails).

code devops honey badger ruby on rails cupboard apm podcast panel railsconf andy croll

Ep 1: Life in 19th-century slums

Rewind The Clock

Play Episode Listen Later Sep 11, 2021 23:33

Join Steve Noonan for the pilot episode of Rewind The Clock. Steve is joined by Andy Croll a principal lecturer in history at the University of South Wales and the two of them discuss this week's topic which is life in 19th-century slums.

university south wales 19th century slums andy croll

060 - Andy Croll, Organizer of Brighton Ruby Conference and CTO of CoverageBook

Rails with Jason

Play Episode Listen Later Sep 1, 2020 39:12

In this wide-ranging episode I talk with Andy Croll about tech conferences, living in Singapore, spicy food, Andy's employer CoverageBook, and legacy code.

conference singapore brighton organizers andy croll

310: Pivoting Brighton Ruby 2020 with Andy Croll

Play Episode Listen Later Mar 19, 2020 26:50

Andy Croll is CTO at CoverageBook & AnswerThePublic, Rubyist, conference organizer of Brighton Ruby, author, speaker, bootstrapper & twin dad. Amidst the COVID-19 pandemic, Andy had to pivot this year's conference into a new experience. He and Brittany discuss the details and the potentially lasting effects on the community.

covid-19 cto brighton pivoting ruby on rails answerthepublic rubyist andy croll

310: Pivoting Brighton Ruby 2020 with Andy Croll

Play Episode Listen Later Mar 19, 2020 26:50

covid-19 cto brighton pivoting ruby on rails answerthepublic rubyist andy croll

009: Planning Childcare at Conferences

Play Episode Listen Later Jul 11, 2018 55:32

Parent Driven Development Episode 009: Planning Childcare at Conferences 00:25 We're joined by Abby Phoenix (https://twitter.com/aphoenix) today 01:00 When did childcare at Ruby Central events start? started in 2015 and have now been at 6 conferences The intention is to always have childcare at RailsConf (https://railsconf.com/) and RubyConf (https://rubyconf.org/) 03:37 Where to start when you want to have childcare at your conference Treat it as any other vendor Go to the conference venue and ask for recommendations Ask for recommendations from the hotel, local user groups, etc. 6:10 Smaller conferences Smaller conferences are a little more difficult but also easier because if it's in the same location every year you can use the same provider year after year 7:30 Very important that childcare is based in the city of the conference They know how to get around They have alternative options They are on time They have the equipment they need 9:10 How many people use childcare at conferences? Typically 5-7 kids Usually younger children especially since RubyConf and RailsConf are during the school year so most older children are in school Always a question of whether or not a parent can make it work because bringing a child to a conference can be challenging 13:45 Lactation room is also offered Visibility is very important It is important that it is known in the community that childcare and lactation rooms are available at these conferences What to call the lactation room? How it works at a conference to make sure you don't get walking in on and to make sure it is easy The lactation room has outlets and a fridge. 20:20 We tangent about all the things we can't wait to forget as parents Diapers Wiping bums and more 21:30 Lactation rooms are really easy to put in place as a conference organizer 22:20 What have been the biggest challenges of providing childcare at a conference? There were things we did not know to ask when we started and so now we have a list which is helpful Abby goes in to which questions they have started to ask 26:00 What do you wish you could provide? Evening childcare so parents can do things. They will try to work with childcare providers to offer after-hours care but can't provide it themselves 31:00 Childcare is often tailored to 1-5 year olds Most of the participants are younger 32:00 Mandy talks about what you can do with an older child at a conference Is it worth it to bring an older child to a conference? What conferences have a "kids track"? How to engage older kids at conferences? The childcare provider will often tailor childcare towards the age range of the children there 39:30 What are the costs involved for organizers and participants Participants are not charged for using childcare Discussion about costs in different cities 44:00 Genius / Fail moments Allison - My daughter has had a rough few weeks and loves being bounced on a ball but it's tiring for me and hurts my back, so I put her on the ball, tummy down, bounced her, and it calmed her down and she got gas out #Genius Andy - After a difficult day, my daughter wrote "I love you daddy, even when you're grumpy" #Genius? or #Fail? Mandy - My daughter got the principals award for having a positive attitude, was responsible, did homework, and more. I was very proud! #Genius KWu - I'm on call for the week and so I set up a daybed in the office and negotiated with my husband that after the wake-ups, I would go to the office and turn off the monitor and be off duty for a few hours #Genius Abby - My daughters are very picky eaters. My youngest will eat waffles that she'll eat for breakfast. Recently she brought one over to me and said, "mommy I really like these. I like that there is candy inside" #Fail With my oldest, I asked her to describe her perfect meal and I thought she'd talk about candy or ice cream but she said "My perfect meal is a cheese plate" and so from then on every night has been a cheese plate for dinner, which to her means little bits of a variety of food #Genius 54:00 RubyConf is coming! Find more information at @rubyconf (https://twitter.com/rubyconf) and rubyconf.org (https://rubyconf.org/) has some information right now. Registration will open in August or September 54:40 Contact Us! Email us to ask questions. Follow & Support Please follow us @parentdrivendev (https://twitter.com/parentdrivendev) on Twitter or email us at panel@parentdrivendevelopment.com (mailto:panel@parentdrivendevelopment.com). Our website is at ParentDrivenDevelopment.com (https://parentdrivendevelopment.com) Support us via Patreon (https://www.patreon.com/parentdrivendev) and get access to our our Slack Community. Panel: Mandy Moore (https://twitter.com/therubyrep) Allison McMillan (https://twitter.com/allie_p) KWu (https://twitter.com/kwu) Andy Croll (https://twitter.com/andycroll) Special Guest: Abby Phoenix.

planning genius conferences childcare lactation railsconf slack community rubyconf ruby central allison mcmillan andy croll kwu

008: Remote Work with Kids

Play Episode Listen Later Jun 20, 2018 54:08

Parent Driven Development Episode 008: Remote working with kids 00:37 Who all works remotely? 02:30 Working remotely with kids at home Lifestyle choice Nursing and alternate schedules Spouses working from home as well 06:00 Working remotely before and after having a child The difference between working from home with a spouse also working from home vs. not Hard starts and stops to your day 10:00 JC forgets pickup 11:00 Dealing with interruptions This classic example (https://youtu.be/Mh4f9AYRCZY) Interruptions from your spouse vs. the kid(s) 15:00 Allison joins 15:45 Do companies who accept remote work also do better at understanding flexible schedules and work/life balance? Tyranny of the green dot on Slack What are the expectations of being remote? Do we feel guilty about doing "life" or kid stuff during the work day? 19:53 Being a remote worker vs. being on a distributed team Understanding working hours Helping colleagues be more purposeful about working hours and communication 23:00 Shared calendars and communicating hours to your team slack notifications and snoozing google calendar work hours basecamp Tools 24:00 Based on Cate's blog post (https://cate.blog/2016/12/29/figuring-out-remote-work-is-figuring-out-work/) Going in to an office established a lot of defaults for a team and working remotely it helps to be more explicit 25:30 Being in the office is nice because you get to talk to other adults. How do you deal with isolation? Going to stores Being in the coffee shop Parenting groups and daycares Playdates with other kids The difficulty of coworking and coffee shop working while pumping Leads to great isolation which is pretty difficult Rant about when people tell you to be social while pumping (spoiler: it's not that easy!!) 31:00 Being home instead of going out as a matter of priorities What do you want to have time for? 33:00 Listener Question!! Our first!! It is so exciting!!! When is the right time to introduce screens to your child and how did you do it? Allison introduced games first, mostly on flights. When Allison introduced tv shows, she tried to make it educational like Daniel Tiger (http://pbskids.org/daniel/), PBS shows (http://pbskids.org/), etc. Talking to your child about what they watched and what they learned KWu thinks what screen time and for what purpose. And introduce something, see the effect and make changes from there. JC said as you have more kids, it's harder to control media and screen time. Having structure around things is very important. Josh remembers lots of research but can't remember when they introduced screens Andy says do it collectively and sparingly KWu says that technology and watching things can be used as bonding time and can focus on artistic or creative endeavors as opposed to isolating JC talks about use of imagination using programs like minecraft (https://minecraft.net/en-us/). 45:00 Genius / Fail moments JC - my daughter has been playing softball and she looked at pictures of herself batting and fixed an issue! She was resilient and didn't get discouraged. #Genius Allison - Everything is a genius and fail right now. My son's preschool teacher told me that he's doing fantastic #Genius Josh - my daughter has guinea pigs named Ana and Elsa and one of them fell which led to a visit to the vet. There they found out Ana and Elsa are male which led to a great discussion about gender and what gender means. #Genius KWu - Marriage win! We started watching the Americans together and it is so nice to be doing something together and have something not household related to talk about. #Genius Andy - After a difficult day, my daughter wrote "I love you daddy, even when you're grumpy" #Genius? or #Fail? 53:00 Contact Us! Tell us what you're learning! Follow & Support Please follow us @parentdrivendev (https://twitter.com/parentdrivendev) on Twitter or email us at panel@parentdrivendevelopment.com (mailto:panel@parentdrivendevelopment.com). Our website is at ParentDrivenDevelopment.com (https://parentdrivendevelopment.com) Support us via Patreon (https://www.patreon.com/parentdrivendev) and get access to our our Slack Community. Panel: Josh Puetz (https://twitter.com/joshpuetz) Allison McMillan (https://twitter.com/allie_p) JC Avena (https://twitter.com/jcavena) KWu (https://twitter.com/kwu) Andy Croll (https://twitter.com/andycroll) Additional links: https://medium.com/@benthompson/breaking-down-the-father-on-bbc-being-interrupted-by-his-children-9840cdc8857b https://youtu.be/-Ojvk-4IcOE

kids americans fail rant genius remote pbs shared nursing listener questions tyranny remote work jc daniel tiger slack community allison mcmillan andy croll kwu

004: Managing Multiples

Play Episode Listen Later Mar 7, 2018 50:20

00:19 - Dave Bock - Multiples! Dave has been a software engineer since 1991, with several forays into management, and even ran a small consulting firm with a couple of friends for 8 years. He’s currently the DevOps Service Area Lead at Excella Consulting, a father of 10 year old triplet boys, is the director of the nonprofit LoudounCodes, helps organize the RubyNation and DevOps DC Days conferences, and co-organizes a handful of meet ups in the Northern Virginia area. 00:55 10 Year old triplet boys! Dave and his wife did IVF. They were hoping for one child and were delighted/shocked to have three! The odds for three embryos implanting was 2%. They always wanted three, just didn't expect them all at once. 3x of everything! It was 3x the work with only two of them. Now that they are older, they do help each other a lot. 3:50 Going back to work Leveling up the difficulty by quitting his job and starting a consultancy 3 months into the pregnancy. Dave talks about the tension with billing hourly and feeling like you're losing money if you're not working while trying to manage three newborns. They realized with triplets all milestones (walking, talking) happened within days of each other too, so you need to be paying attention. It took a while to get the consultancy to the point where there was a good work/life balance. 8:52 Triplets vs One at a time The stages are spread out across longer years vs doing all the work for each stage at once. Some people with three kids do diapers for 10 years. For them, when they were done with diapers, they were done. They had to use assembly line processes to get the kids fed. They couldn't keep up and started buying pre-mixed formula. The delivery person thought she was delivering food for a pony and asked to see it. No hand-me-downs. Have to have at least 4 choices when getting something so each kid can have a choice even if picking last. 13:23 Andy joins the call! We continue talking about how the triplets have their individual personalities and how they've nurtured that individuality. They've kept the kids in separate classrooms with their own friends and such. They go on one-on-one outings with each kid. Invidual personalities come out when they are on their own but blend when the kids are together. 17:15 Multiples learn to share early on The kids develop a sense of fairness early on. Older kids seem to get stricter parents, but it's probably just a matter of being able to control their environment. Kids are growing up with a lot of screen time. 20:35 Technology at different ages Spread out kids have different technology available when they get to a certain age. Triplets hit the same tech at the same time. 21:54 How do you find events to take kids to? Dave talks about how he's volunteered for years in different capacities and at different places. That's allowed him to influence the curriculum the kids are exposed to regarding technology. He suggested Hour of Code and they've been using it since his kids were in first grade. He also teaches highschool kids and runs the LoudounCodes program. He buys started kits that teach his kids how to solder and build electronics. Also local events in the community, playgrounds, museums, etc. Programming with Scratch. Letting the kids find something they like to do and giving them free time to do it. 27:44 An endlessly adapting river of water of parenting After a long and varied career, Dave's wife decided to stay home and work at home with the children. She's the one that keeps everything running. Dave also credits his mom with helping keep things going. She has an in-law suite at their home and helps with the children and dinner. Andy talks about how he and his wife have been able to work from home while having their children. JC talks about being able to work from home for a large part of his children's early years and how that helped the balancing act with his wife who eventually went back into the workforce. Allison talks about mental load and how difficult it can be to mentally unload the home management part of life while working full time. Dave talksa about being equal partners and sharing the load. It's called parenting, not babysitting your kids 36:44 Teasing your children Dave talks about a few ways they've pranked the children. Zombies, the Walking Dead and RubyDCamp. Gummy bear addiction. 40:42 Genius/Fail moments JC - Decided to take his kids to see Black Panther as a surprise and forgot about his daughter's end of season pizza party which she missed. #FAIL Andy - Managed to survive their childrens' "half-term" days off when all their plans fell apart. #GENIUS Allison - Ran out of patience and yelled. The rest of us feel like it's called "morning". - #FAIL Dave - After one of his kid had his apendix removed, a second started having similar symptoms. The third child started worrying that it may be contagious. Dave tried to tease him about it and the kid turned it around on him. - #FAIL 48:44 Where's Dave? You can usually find dave under bokman on various sites. He's bokmann on Twitter (https://twitter.com/bokmann), Github (https://github.com/bokmann), Skype, and just about anywhere. His non-profit can be reached at Loudouncode.org (https://loudouncodes.org) with a mission to support computer science education for Loudoun County's K-12 students. 49:40 Contact us! We'd love to hear from our listeners. Follow & Support Please follow us @parentdrivendev (https://twitter.com/parentdrivendev) on Twitter or email us at panel@parentdrivendevelopment.com (mailto:panel@parentdrivendevelopment.com). Support us via Patreon (https://www.patreon.com/parentdrivendev) and get access to our our Slack Community. Panel: Allison McMillan (https://twitter.com/allie_p) Andy Croll (https://twitter.com/andycroll) Chris Sexton (https://twitter.com/crsexton) JC Avena (https://twitter.com/jcavena) Special Guest: Dave Bock.

kids technology managing zombies code black panther skype walking dead programming older scratch ivf github jc northern virginia teasing triplets multiples gummy slack community chris sexton andy croll excella consulting

003: Internet Privacy and Kids

Play Episode Listen Later Feb 21, 2018 44:00

0:31 First Guest! Heidi Waterhouse (https://twitter.com/wiredferret) - Parent of two. Developer evangelist for LaunchDarkly (https://launchdarkly.com/). Volunteers teaching sex ed to teenagers. She likes to sew her own conference dresses and ride her bike. 1:00 Internet privacy and safety and how it is adaptable to kids of all ages. How should kids protect themselves online, have manners, and use their time wisely. Online behavior is permanent these days, so kids should also consider using obfuscated names online. Pseudonyms are personas you can discard if necessary while keeping you safe. Online predation is possible, but you are more likely to be get gendered grief online. 8:00 Problematic relationships with Facebook You can have a real name account, but you have to behave as if in an office all day. Kids have a harder time controlling impulses. Due to COPPA regulation, parents wanting their non teenage children to have an online account have to lie about the child’s age when signing them up. COPPA (https://www.ftc.gov/enforcement/rules/rulemaking-regulatory-reform-proceedings/childrens-online-privacy-protection-rule), well intentioned, but disenfranchises kids under 13 and forces parents to jump through hoops when getting their children online. 10:57 Wallet identity Sometimes you want accolades and other positive achievements tied to your persona. Each kid is different and some will want the attention while others won’t. Some things you do in public and online forums will be public, regardless of your preference. As parents, we make decisions for our children. Everything decision we make for our children will be things they’ll have to live with. Some parents choose to not make choices for their children regarding online personas. 14:45 Less physical spaces A book from Danah Boyd (https://www.amazon.com/Its-Complicated-Social-Lives-Networked/dp/0300166311) discusses how we’ve deprived teenagers from any space they can meet and hang out so the only space they have left is cyber space. Overscheduling, curfews, no hanging out at malls. Technology is making physical gatherings less common. 16:29 Cyber safety is the new Sex Ed Schools have Google accounts for kids to use the Google suite for education. Cyber security education is the equivalent of abstinence only sex ed. 70% of parents have a password to their kids’ phones and monitor their devices. 20:35 Safe places for kids to explore online communication and not raising trolls. Online platforms where kids can interact safely. Discord (https://discord.me). Teach children what is appropriate, and give them the ability to identify what is right and wrong. “It’s only online, it doesn’t matter” is how you build an online troll. Everyone is a human on the other side of the screen. 24:51 Determining when your children should level up Each kid is different and timing depends on each kid. Learnign what should be downloadable to your computer so it doesn’t break. What about your kid wanting a YouTube career? (Yes YouTube, no comments) Keeping their online circles to friend they know in person helps, while having open discussion about their online lives. Let them know they can be monitored, and privileges can be narrowed. 35:13 Genius/Fail moments Andy - Picked up his kids from school but left his dog there. #FAIL Allison - Continuation of last episode’s fail. Still reading fire safety book at bedtime. #FAIL Heidi - 15YO assembled IKEA storage system by himself. #GENIUS Chris - Kids decided to spend time roughhousing instead of online. Though he overheard from downstairs: SON: Stop! You’re going to break my arm! DAUGHTER: I don’t want to break your arm, I want to break your spirit! #GENIUS Mandy - Going to Disney World! After a long long time of saving, it’s happening. #GENIUS Follow & Support Please follow us @parentdrivendev (https://twitter.com/parentdrivendev) on Twitter or email us at panel@parentdrivendevelopment.com (mailto:panel@parentdrivendevelopment.com). Support us via Patreon (https://www.patreon.com/parentdrivendev) and get access to our our Slack Community. Panel: Allison McMillan (https://twitter.com/allie_p) Chris Sexton (https://twitter.com/crsexton) Andy Croll (https://twitter.com/andycroll) Josh Puetz (https://twitter.com/joshpuetz) Mandy Moore (http://twitter.com/recursivefunk) Special Guest: Heidi Waterhouse.

google kids internet technology online safe teach parent discord volunteers disney world ikea developers cyber determining problematic mandy moore coppa pseudonyms internet privacy launchdarkly overscheduling slack community danah boyd chris sexton andy croll

Episode 31: Andy Croll

Indiedotes Podcast

Play Episode Listen Later Feb 20, 2018 56:14

Software developer Andy Croll on the impermanence of software, how closing down a project helped him figure out his technological preferences and helped his career.

software andy croll

001: Greetings & Salutations