Podcasts about action cable

Ransquawk Rundown, Daily Podcast

Play Episode Listen Later May 28, 2024 37:03

Joël and Stephanie talk RailsConf! (https://railsconf.org/). Joël shares how he performed as a D&D character, Glittersense the gnome, to make his Turbo features talk entertaining and interactive. Stephanie's talk focused on addressing test pain by connecting it to code coupling, offering practical insights and solutions. They agree on the importance of continuous improvement as speakers and developers and trying new approaches in talks and code design, and recommend Jared Norman's RailsConf talk on design patterns, too! That One Thing: Reduce Coupling for More Scalable and Sustainable Software (https://www.informit.com/articles/article.aspx?p=2222816) Connascence.io (https://connascence.io/) [Connascence as a vocabulary to discuss coupling](https://thoughtbot.com/blog/connascence-as-a-vocabulary-to-discuss-coupling](https://thoughtbot.com/blog/connascence-as-a-vocabulary-to-discuss-coupling) The value of specialized vocabulary (https://bikeshed.thoughtbot.com/356?t=0) Transcript: We're excited to announce a new workshop series for helping you get that startup idea you have out of your head and into the world. It's called Vision to Value. Over a series of 90-minute working sessions, you'll work with a thoughtbot product strategist and a handful of other founders to start testing your idea in the market and make a plan for building an MVP. Join for all seven of the weekly sessions or pick and choose the ones that address your biggest challenge right now. Learn more and sign up at tbot.io/visionvalue. 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, Stephanie, what's new in your world? STEPHANIE: So, I think I can speak for both of us and say what's new in our world is that you and I just came back from RailsConf in Detroit. JOËL: Yeah, we were there for, I guess, it's a three-day conference. Both of us were giving talks. STEPHANIE: Yeah. I don't think we've both spoken at a conference for at least a little over a year, so that was really fun kind of to catch up in person. And there was a whole crew of thoughtboters who were there. Yeah, I feel like we were hanging out, like, a lot [chuckles] all of last week, just seeing each other, talking about, you know, rehearsing our talks and spending time together on...there was, like, a hack day, and we were sitting at the table together. So, I feel like I'm totally caught up on everything that's new in your world, and that's it. That's the end of the show [laughs]. JOËL: On that note, shall we wrap up? STEPHANIE: [laughs] That would not be very fair to our listeners. [laughter] JOËL: Yeah. So, how was the conference speaking experience for you? STEPHANIE: Ooh, it was really great this year. I have not spoken at a RailsConf before, so this was actually, I think, a bigger stage than I had experienced before, and I had a great time. I met Ruby friends, new and old, and, yeah, I left feeling very gooeyed, and very energized, and just so grateful for the Rails community [laughs]. Yeah, I had a very lovely time, kind of being a little bit outside my normal life for a few days. And I think my favorite part about these things is just like, anywhere you go, you can kind of just have a shared interest with someone, and you can start a conversation with them. JOËL: That's really interesting. Do you find yourself just reaching out to strangers at conferences like this? Or do you tend to just hang out with the people that you know? STEPHANIE: Oh, I think a little bit of both. I like to get meals with people I know. But if I'm just hanging out in, like, the lobby or if I happen to get a seat for a talk and I'm sitting next to someone that I don't know, I find it quite easy to just be like, "Hi, like, I'm Stephanie. Are you excited for this talk?" Or, like, "What good talks have you seen recently?" There's an aspect of, like, the social butterfly that comes out of me when I'm at these things. Because I just don't get to have, like, easy access to, I don't know, people with, like, that shared interest or people who are willing to just have a conversation with you normally, I think. JOËL: Yeah, would you describe yourself more as an introvert or an extrovert? STEPHANIE: I am an extroverted introvert [laughter]. I feel like maybe that might be interpreted as a non-answer, but I think I lean more on the introvert side. But you know when you're with a group of people, and there's not, like, a very clear extrovert in that conversation, and then you're like, oh, I have to do the heavy [chuckles] lifting of the social lubrication [laughs] in this conversation, I can step into that role, reluctantly [laughs]. JOËL: Okay. I like the label that you used, the extrovert introvert, in that I enjoy social situations. I do well in social situations. But they also consume a lot of energy for me. I don't necessarily get sort of recharged by doing social events. So, people will be surprised when they find out that I tend to talk about myself as an introvert because, like, "Oh, but you're, like, you know, you're not awkward. You engage very well in different group situations." STEPHANIE: You have a podcast [laughs]. JOËL: And the truth is I enjoy those things, right? I really like social interaction, but it does, after a while, wear me out. STEPHANIE: Yeah, that makes sense. I did want to spend a little bit of time talking about the talk you gave at RailsConf this year: "Dungeons & Dragons & Rails." JOËL: I got to have a lot of fun with the theme. The actual content was introducing people to Turbo by building an interactive Dungeons & Dragons character sheet using vanilla Rails and a little bit of Turbo. So, we're not even writing any JavaScript. We're just using the Turbo helpers, a little bit of Action Cable to mimic something a little bit like...people who are in the know might be familiar with the site D&D Beyond, which is kind of the official D&D online character sheet website. Of course, it wasn't anywhere near as fancy because it's a 30-minute talk and showcasing different features, but that's what we were aiming for. STEPHANIE: Yeah, you know, you've talked a bit about giving talks on the show before, but I wanted to get into what made this one different because I think it could be fun for our listeners. [laughter] JOËL: The way I structured this talk so it has a theme. It's about Dungeons & Dragons, and we're building a character sheet. The way I wrote the talk was it's broken up into chapters. Each chapter is teaching a new feature in Turbo that I want to show off. In order to motivate learning each of these features...because I don't like to just say, "Oh, here's a thing that technology can do. Oh, here's a thing that technology can do." That's boring. You need a reason to learn that. So, I needed a reason to say, "We need to add this to a character sheet." So, every sort of chapter of the talk opens up with a little narrative portion. We're following this character, Glittersense, the gnome, and he's on adventures. And at different points in the adventures, he's going to do different types of roles or need different stats and things. And so, when we reach the point in the adventure where we need that, we sort of freeze frame and then say, "Okay, let's add that as a feature to the character sheet." And then, oh no, it turns out that this feature is a little bit more complicated. We're going to have to learn a new Turbo feature to do that. Who would have guessed? And then, we learn a new Turbo feature together. And then, we go back to the narrative portion. The adventures of Glittersense continue. And then, oh no, we're going to need to add another feature to the character sheet. And that's sort of how the talk is structured. STEPHANIE: Yeah. And you did a really cool thing with the narrative portions, which was you basically performed as Glittersense, the gnome, voice and posture, and a lot of really great acting from you [laughs], in my opinion. JOËL: That is something that came out pretty late in the talk preparation. So, I knew I wanted this kind of alternating story and code structure. Then, like, the weekend before RailsConf, I'm running through my slide deck, and I realized, you know what? What if instead of narrating Glittersense's adventures, what if I went first person for those sections? Glittersense tells his own story. And then, from there, it wasn't a big jump to say, you know what? This is D&D. If I'm going first person and narrating, I really should do a voice. And this is a conversation I had with a couple of people at the speaker dinner. And, of course, everyone's like, "You should 100% do the voice." And I was really not feeling confident in my ability to pull it off. So, for the next two nights, because I was speaking on the third day, the next two nights at the conference, in the evenings, I'm in the hotel room in front of the mirror just practicing my gnome voice to try to get something that got the persona of Glitterense, the gnome, across to the audience. STEPHANIE: How would you describe the persona? JOËL: Very extra. STEPHANIE: [laughs] JOËL: Very high energy. STEPHANIE: Yes. The name Glittersense is very extra, after all. JOËL: [laughs]. I punctuated a lot of the things that he says with just high-pitched laughter. He's also...so, the framing device for all of this is that you're in a tavern listening to him tell his adventures. I wanted a little bit of the sense that Glittersense is maybe embellishing a little bit. I think it may be too much to say he's full of himself, but he's definitely making himself to be the hero of the story, and maybe making himself to be slightly cooler than he really was. STEPHANIE: Yeah. I definitely got, like, a little bit of eccentricity, too, from the persona. And you know when you just, I don't know, meet an older person who has, like, a lot of life experience, and they want to tell you about it [laughter], but you do kind of maybe have a little bit of suspicion around how much they're exaggerating [laughs]. But it was really fun. Everyone I talked to afterwards, like, loved it. And I got to share the little nugget that, like, oh yeah, and Joël only, like, started doing the voice, like, decided that he was going to do it two days ago. And they were just all really, like, blown away because it seemed so well practiced, and it was really fun. JOËL: I got to do something really fun, also, with physical space because Glittersense narrates his portion, sort of the story portions, but then the code portions where we're talking about Turbo, I'm talking in my own voice. And so, when I'm talking about Turbo, I'm standing at the lectern. And when I'm Glittersense, I'm kind of off to the side on the stage and doing the voice. And so, there's this almost, like, two worlds that are inhabited: one by Joël, the speaker, and one by Glittersense, the gnome. And it got to the point where I don't say or do anything. I only move from the lectern to the, like, portion of the stage where Glittersense lives. And the audience starts chuckling and, like, nothing has happened yet, like, no jokes have been told. No voice has happened. No slides have changed. But the anticipation, people know what's coming. STEPHANIE: Yeah. And I think the best part, what I really found just really fun and, I don't know, every time it happened, I just really enjoyed it, when you transitioned out of Glittersense, the gnome, and back to Joël because you were so nonchalant about it. You kind of, like, straighten up rather than having your little kind of crouchy gnome posture, and then just walk across back to the podium. And then, in your normal voice, go back to just, you know, sharing very...not necessarily dry, but just, like, straight to the point. "And this is, like, how you, you know, create a frame in [laughs] Turbo," as if nothing happened [laughs] when even just, like, you know, 20 seconds ago, you were just enthusing about, like, slaying the bandit, chieftain [laughter] known as Glittersense. JOËL: Uh-huh. I think, especially when I open, so I get introduced. I'm off stage. I walk onto the stage, and I'm immediately Glittersense. And I'm telling a story, and the intro goes on for, like, quite a while. It's a big story chunk. And then, at some point, I just walk over to the lectern, drop the voice, hit next slide, and it's my title slide. I'm just like, "Okay, now welcome to Dungeons & Dragons on Rails. We're going to build a character sheet together." STEPHANIE: Yeah, that's exactly the moment I'm thinking of. JOËL: The walking in as Glittersense and just immediately going to the voice caught everyone by surprise. And then, the, like, oh, he keeps going for this. Is the whole talk going to be like this? And then, the, like, just when you think, oh, he's really going for it, the, like, dropping it and going to the podium and title slide. It wasn't intended to be a funny moment, but I think the contrast and the fact that I just switched over was one of the biggest laughs I got. STEPHANIE: Yeah, I mean, I think that attests to how good the delivery of it was because that contrast was very felt. So, props to you. JOËL: I love the idea of, you know, the thought that you put into building a talk and, like, the narrative structure and the pedagogy of the stuff. And, I think, in this particular case, this is almost like a narrative approach called in media res, where you start kind of in the middle. You open your book, or your movie, or whatever in the middle of the story. And then, you kind of come back to the beginning at some point later. So, it starts with some kind of action scene that grabs your attention. So, in this case, my title slide is 10, 15 slides into the talk. We get immediately started with Glittersense and his adventures. And then, once we're sort of all bought into this world, then we move to the title slide and talk about, okay, we're here to build a character sheet and all that stuff. And I think that it wouldn't have had the same impact if I'd, like, opened with that and then gone into Glittersense's adventures. And that's something that was not the case at the beginning. I really reworked the talk to make it in that order. And I think that the talk had a lot more impact for doing that. STEPHANIE: Yeah, definitely. I guess I also just wanted to point out that this is very different from all your other talks. And I think it's really cool that, you know, you are a veteran speaker, but you still find ways to do something new and try something that you've never done before, and yeah, find ways, new ways to, like, speak and engage people and teach. I don't know, do you have just any thoughts about why or how you got into a position to be like, "Oh, you know, I'm going to do something super different this time around" [laughs]? JOËL: So, every talk I give, I try to do something new, something different, to push myself as a speaker to get better. That might be in the writing of the talk; that might be in the delivery. More recently, I've been trying to do more with dynamic presence on stage. So, when I spoke at RubyConf San Diego, I was trying to not just stand at the lectern but to learn to be able to give my talk while also, you know, walking around the stage, looking at the audience, making pauses where it's necessary, not to just be so into the delivery of the talk by just standing at the podium and, like, going through my deck, which is a small thing but I think is an area I wanted to improve in. This time, I was playing around with some more narrative framing and ended up, yeah, like, pushing it to an extreme. And it works with the theme because inhabiting a character and role-playing is the core part of D&D. Not everybody plays a D&D character by doing a voice. You are a little bit extra if you do that. But it's not uncommon for people to do a voice. And so, it kind of fit perfectly with my theme. I just needed to get the self-confidence to do it. So, thank you to everyone at the speaker dinner that was like, "No, you totally got this. You should do this," because I was feeling very unsure. STEPHANIE: It really paid off, so... JOËL: I'd like to circle back to your talk, though. So, you gave, basically, the first talk of the conference. You were the first session after the keynote. A theme that came up multiple times in your talk was this idea of coupling and how it affects different parts of our code and, particularly the way that we structure tests or the way that we feel test pain. How did you, when you were prepping this talk, discover that theme and decide to lift it up? Was that something that you knew ahead of time you wanted to talk about, or did it just sort of emerge as part of the talk preparation process? STEPHANIE: That's a really great question, and I'm glad you picked up on that. So, my talk was called: "So, Writing Tests Feels Painful. What Now?" Originally, when I came up with this idea, it actually started with coupling. I realized that I wanted to give a talk about coupling because it's just something that I was struggling with or, like, had seen other people struggle with and really wanting kind of a discrete resource, wanting to provide that. But as I was just thinking about it, I was like, oh, like, there are so many different ways that this could go. On one hand, it was a very like important topic to me, but also maybe too big of a topic. And so, I actually, like, kind of put that on the back burner. And it wasn't until later when I connected it to another...it wasn't necessarily different at all, but just, like, an extension of this idea is, oh, like, people are struggling with coupling in tests or, like, it manifests in tests. And so, I thought maybe that could be the angle that I took on this topic that kind of gave me a little bit more focus. And I didn't even end up saying like, "Yeah, this talk was, like, born out of just, you know, wrestling with coupling or anything like that." So, it's cool, to me, that you picked up on it as a theme because it was...I had, you know, ended up not being super explicit about it, but it was certainly, like, a thing that was driving the content from my perspective. JOËL: Interesting. So, it started as a coupling talk and then got sort of focused through the lens of testing. STEPHANIE: Yeah. And I think there was a part of me that was like, you know, I don't know if I could just teach the concept of coupling, like, by itself without the framing of testing for people who this is, like, a new concept for them. I realized that maybe it would be more effective to be like, "Hey, like, have you experienced test pain? You know, have you had to mock out a billion objects or changed, you know, made one change and then had to fix, like, a million tests subsequently? Then this talk is for you." And then weave in the idea of coupling in it to kind of start to help people feel familiar with it or just, like, identify it without as much, like, jargon as kind of I've seen when I've tried to figure out, like, how to manage it. JOËL: It's interesting because I think it gives you a, like, concrete, valuable thing to optimize for as opposed to, like, hey, let's lower coupling because then you're writing, you know, quote, unquote, "better code." And you get to feel better about yourself as a programmer because you're doing things the, quote, unquote, "right way." That's very kind of hand-wavy, and I think sometimes leads people down a bad path where they're optimizing things that they shouldn't be. But the tests give you this very concrete way to say, "Hey, we're not just trying to reach the, like, low score record for the app in terms of coupling. We're trying to reduce test pain. Tests are painful. And that pain is telling us something. It's telling us that we've crossed some sort of threshold for coupling. Let's find ways to reduce it, not so that we can feel good about ourselves, but so that our tests are actually manageable." STEPHANIE: Yeah, I am really glad you picked up on that, too, because I feel the exact same way when someone just tells me to decouple something or, like, makes a note that, like, oh, this feels really coupled. I don't know what that means necessarily. And it's not very convincing to just be like, "Oh, you should write loosely coupled code [laughs]," at least for me. What you said just now, it's like, it's not to feel good about ourselves, you know, to write code that way, but, actually, to just feel good about our code, period [laughs]. And, yeah, finding that validation through just, like, actually working with code that is easier to change that is the goal, not necessarily to, yeah, kind of pursue some totally subjective, like, metric. JOËL: So, one of the kinds of coupling that you called out, I think, was where you hardcode a class name of some other class in your object. And that feels, like, really sort of innocuous. Like, of course, my objects can talk to other objects. And maybe I want to, like, refer to a class somewhere. Why is that such a like tricky piece of coupling to work with? STEPHANIE: It's not necessarily intentional sometimes. Like, you just do it because you're like, well, I need access to this class somewhere, and I happen to already be in this file. So, why not just hard-code it here? I do think it's a little tricky because the file that you're writing might be, like, very far down in, like, your code flow or, like, your code path, like, very far from, like, a controller or any kind of entry point into your system, at least based on what I've seen in a lot of modern Rails apps. And so, I think that coupling gets really, really obscured. I have found that, like, if I have to kind of write a more, like, a higher level test, like, maybe a request spec or something, there are times when I'm, like, having to deal with a lot of classes just to set stuff up in a test like that that I didn't think I would have to [chuckles] when I first went about trying to just be like, oh, like, let's just figure out how to get a 200 response [laughs] from this request. So, you're really burying perhaps the things that are needed to set up, like, that full path of execution. And sometimes, it only comes out when you're writing a test for it. JOËL: And you mentioned briefly, in passing, the idea that oftentimes this sort of coupling manifests as a lot of extra test setup because your object that you're trying to test now also needs all these other things that are related in order to be tested. But sometimes even when you hard code a class, though, you can't even just say, "Oh, I want this particular user or something returned." So, you have to then do something like allow this class to receive class method and return, and now you're stubbing. And I don't know how you feel about stubs in RSpec. I always treat them a little bit like a code smell in the like classic sense of it's not necessarily bad, but maybe pause, take a look, and ask yourself, "Why is that there, and should I do things differently?" STEPHANIE: Yeah. I ended up having, like, a lot of examples of stubbing in my example because the code had just been set up where that was the only way that you could access those collaborators, essentially, to, like, make an assertion on them, or have them do something different because you actually needed to go into a different path, right? And I was like, yeah, this should feel weird. You should feel a little bad [laughs] or at least, you know, kind of just pay attention to that feeling, even if you can't really do anything about it in that particular instance. But on the flip side, you know, it's like, yes, it feels a bit strange, you know, but it's not all bad, right? Like, you're kind of learning like, oh, hey, like, I am coupled to this hard-coded class because I am needing to stub, like, a class method that returns it, or that constructs it. And at least you've exposed that, you know, for yourself. One thing that I was running into a lot in my example, too, was that those things, like, weren't obvious when you were just reading maybe, like, the public methods and trying to figure out what was happening in them because they were wrapped in private methods. I was a little bit conflicted about this because there were times when it was already just a single method call, but then it was just kind of wrapped in a private method that actually hid [laughs] the things, like all the dependencies that were passed as arguments. And I found that to be, sure, it looks kind of cleaner. But then all you need to do is scroll down [laughs], and then you're like, oh, actually, there's all these other things involved, but it was kind of hidden away for me. And I found that, actually, like, at least when I actually needed to change things, less helpful than I imagine what the, you know, code author intended. Do you have any thoughts about hiding details like that? JOËL: I'm kind of a big fan. STEPHANIE: Hmmm. JOËL: The general idea, I think, is called the single level of abstraction principle. Whatever sort of public method that you're calling is often implemented in terms of...let's say it does a few different things. It's implemented in terms of, like, these sort of high-level concepts. So, whoever is reading the public method doesn't need to like care about the details of how each step is implemented. So, maybe you're fetching something from an API, and then you're making a database call, and then you're doing some transformation and creating some new objects from it. Having all of the, like, HTTP calls and the ActiveRecord stuff and the, like, transformation all in the public method, yes, there's a lot of complexity happening there, and it makes that obvious. But it also makes it really hard to get a sense of what is happening. So, I like to say, "Hey, there are four steps. Let's wrap them all each in a private method then you can call all of those in the public method." The public method now sort of reads like a very simple sort of script. First, fetch data from the HTTP API, then fetch some data from the database, then apply this transformation, then create this object. And if I'm mostly caring about what this object does and not the how let's say I'm building some other objects that interact with this, that is the information I want to know. Where I care about the actual implementation of, oh, well, exactly how is the ActiveRecord stuff done when I'm doing internal changes to the object, that's when I care about those private methods. I think where it gets tricky, and I think that's the point that you were bringing up, is that if you write code in that way, it has to change the heuristics of how you read code to detect complexity. Because, oftentimes, I think a very classic heuristic for code complexity is just line length. If you have a 50-line method, probably there's a lot of complexity there. Maybe there's a lot of coupling. If it's a four-line method that is written at a high level of abstraction that just calls out to private methods, you scan over. You're like, oh, nice and clean. Nothing to see here. Move on. And so, that heuristic doesn't really hold up in a codebase where you're applying this single level of abstraction. Do you think that lines up with your experience? STEPHANIE: Hmm. As I was listening to you, I was like, yeah, like, that makes total sense to me. But then I also clearly disagreed a little bit [laughs] in my initial...kind of what I was saying initially. And I think it's because that single layer of abstraction was not very well defined. JOËL: Hmm. That's fair. STEPHANIE: Yeah. Where, in fact, it was actually misleading. Like, it wanted to be at that level of abstraction, but it really wasn't. Like, it was operating on things at, like, a lower level and wasn't designed with that kind of readability in mind. So, it was more, like, it was just hiding stuff a little bit, at least for me. And, I think, it certainly would have taken, like, more work to figure out what that code, like, really was meant to convey. It might have taken some refactoring to coalesce at that single level. And that was essentially kind of what I was showing in my talk as, like, how to get to saying, like, "Hey, we actually are operating in the lower level, but I don't think we need to." There was some amount of, like, looking at all of the how to figure out, like, oh, maybe these things we don't even need to expose in this class. And we kind of got to a place where those details weren't, like, needed in that class at all. So, it's one of those things where it's harder than it sounds [laughs]. JOËL: It's definitely an art. STEPHANIE: Yeah. JOËL: And I think what you're saying about some of the coupling being, like, scattered throughout the class, it's something that I see a lot with situations where you're coupled, not so much to, like, a single class, but to something side effectful. So, you're building some kind of integration with a third-party API, and you're going to have to make a lot of HTTP calls. And each of those might be individually simple, and they're all sort of maybe in different private methods or whatever, or they're interspersed among a larger chunk of logic. And that makes your tests really complicated. But there's no, like, one place you can point at and be like, ooh, that's the one place where there's a lot of complexity. What's happening here, though, is that your business object that's doing stuff is coupled to the network, and that coupling is going to force you to do some stubbing. It's going to force you to deal with a bunch of side effects that are non-deterministic in your code. And you used the word coalesce earlier that I really liked because I think that's often a situation where you do have to stand back and say, "Look, there's a lot of HTTP going on here. What if I coalesced it all into an object? Now I have two objects: one that's responsible for business logic, and one that's responsible for just the HTTP calls." And, all of a sudden, the tests just totally simplify. And we've removed some coupling, but that's not something that you would have seen just from reading the code. Because, as you were saying, it's sort of scattered in little bits and pieces throughout your file that don't necessarily catch your eye. STEPHANIE: Yeah. Which brings me to a blog post that I had found a lot of inspiration from in the talk that I'll link. It's called "That One Thing: Reduce Coupling for More Scalable and Sustainable Software." But it's actually about tests [laughs], even though it doesn't make an appearance in the title of the blog post at all. But this is where I kind of got the idea of necessary versus unnecessary coupling in test. Because I had never thought about how, yeah, like, when you write a test, you are very correctly coupling yourself to at least the method and class under test [laughs], if not also the arguments, right? Or anything else needed to construct what you're testing. And literally having that listed out for me in this blog post I think it's a...they use some examples in Java. And so, there's, like, a little bit more [laughs] setup involved. But I think they're like, yeah, these are six things that, like, it's mostly fine if you're coupled to these because that's kind of what needs to happen in a test. But, like, even having something to compare a test I wrote to just, like, okay, these are the things I know I need. And then, you can start to see when you've diverged from that list, when you are finding yourself coupled to some internals of your class. I really...that was actually, like, really helpful for me because, as we talked about earlier, like, it can be kind of communicated so abstractly. But here is, like, a very clear heuristic for when you should at least, like, start to pay attention or be like, oh, this is something that was needed to get the test to run but is now starting to feel a little unnecessary because it's not on this list. JOËL: That list reminds me, or the idea of a list of things to check out for when thinking about coupling, reminds me of the concept of connascence, which is a fancy word for almost a, like, categorization of different types of coupling because coupling comes in different flavors, some of which are tighter forms of coupling than others. And so, having that vocabulary has been really helpful for me when I'm looking at PRs and code review, or even when I'm refactoring my own code. Kind of like that list that you mentioned that you have, now I have some heuristics to look at that and say, "Oh, can I go from a connascence of position to a connascence of naming, and does that help me?" STEPHANIE: Yeah, I like that you mentioned the positional connascence because I also came across a really great metaphor for kind of things that need to change together, like, when that makes sense. And it was basically the idea of a dishwasher and a laundry machine [laughs]. I wish I could recall, like, what book this was from. But it was basically like, oh yeah, like, in theory, you're washing two things. So, maybe they are similar, but then you're like, no, actually, you want these to be a little bit separate because, you know, you don't want to wash your dishes and your clothes in the same machine. I don't know, maybe that exists [laughs], but I don't think it would do a very good job for either goal. And I think that was really helpful, for me, in imagining, like, the difference between kind of coupling and cohesion, like things that...even just imagining, like, kind of where I'm doing those things in the house, right? It's like, okay, that lives in a separate room. And, like, the kitchen is for the dishes, and that could be like, you know, a module if you will. And, like, laundry happens in the laundry room, and how to kind of just separate those things, even though they also do share some qualities, too. Like, they're both appliances, right? And so, that's the way that they are similar, but they're not the same. JOËL: You just mentioned the sort of keyword cohesion. And for our listeners who are not familiar with that term, it refers to an object sort of having one thing that it does well. Like, everything in that class sort of works towards the same goal, kind of similar to the idea of the single responsibility principle. So, in my earlier example, where we're sort of interspersing some business logic, a lot of HTTP requests, and pulling out an object that's focused on HTTP, like everything is based around that, now that object has higher cohesion because it's all doing one thing. So, if you read classic object-oriented literature, the recommendations that you'll typically see are that objects should have high cohesion and low coupling. STEPHANIE: Yeah. Think of a dishwasher and a washing machine next time [laughs] you come across something like that. Because I feel like those are really great, like, real-life examples of that separation. JOËL: Did you go to Jared Norman's talk on the third day: "Undervalued: The Most Useful Design Pattern"? STEPHANIE: No, I didn't. Can you tell me about it? JOËL: It felt like he was addressing a lot of the same themes as you were but from more of a code perspective than a test perspective. Talking a lot about, again, forms of coupling, dependencies, and then, specifically, one of the tools that he focused on to reduce the coupling that we see is value objects and factory methods to construct those. So, for any of our listeners who, when the talks come out, watch Stephanie's talk and are like, "Wow, I would love to learn more about this," a great follow-up, Jared Norman's talk: "Undervalued: The Most Useful Design Pattern." STEPHANIE: Yeah, that's neat because I can see that being a solution to the hard code did class names that we were talking about earlier. And I like how that is kind of, like, a progressive lesson in coupling a little bit. I'm really glad you shared that talk with me because now I'm excited to watch it when it comes out. And in general, I just love learning new vocabulary or finding new ways to speak about this topic with clarity. So, if any of our listeners have just additional mental models for coupling [laughs] different metaphors, different household appliances [laughs], or something like that, I would love to know. JOËL: You would like that, given that our first episode together was about "The Value Of Specialized Vocabulary." STEPHANIE: Yeah, it's clearly undervalued. JOËL: Haha, I see what you did there. STEPHANIE: Thank you. Thank you very much [laughs]. JOËL: On that terrible/wonderful pun, 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!!!!! 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.

vision detroit mvp dragons tests dungeons api turbo java javascript rails prs mandy moore coupling conversing d beyond quenneville railsconf activerecord rspec stephanie you stephanie yeah stephanie how stephanie it stephanie thank stephanie no stephanie oh action cable

Layered Rails Design with Vladimir Dementyev

Remote Ruby

Play Episode Listen Later Sep 29, 2023 47:41

In this episode, Jason and Andrew are joined by guest, Vladimir Dementyev of Ruby on Rails and Evil Martians fame. Today, they touch on Vladmir's new book on designing Rails applications, and dive into the importance of sticking to Rails principles, even in the era of microservices. Vladimir shares insights on working as a consultant on legacy Rails projects and the challenges that can arise when codebases deviate from Rails conventions. We'll also explore the evolution of Rails applications, the power of open source contributions, and Vladimir's journey to becoming a recognized figure in the tech community. Also, Vladimir introduces AnyCable, a performance-oriented solution for real-time communication in Rails applications and provides insights into its capabilities and evolution. Hit download now to hear much more! [00:02:29] Vladimir briefly describes his book on designing Rails applications. [00:05:40] Vladimir talks about sticking to Rails principles and not injecting foreign patterns into Rails applications and emphasizes the importance of maintaining a Rails oriented approach even when using microservices. [00:08:33] We hear about Vladimir working as a consultant on legacy Rails projects and the challenges of maintaining codebases that deviate from Rails principles. [00:10:29] Jason asks for more examples of where the Rails framework ends and developers have to steer their own course. Vladimir discusses the structure of the app folder in Rails applications and mentions the trend of putting everything in the model folder, and he talks about how Rails applications changed during the API-only era, leading to a shift away from Rails conventions and MVC patterns. [00:13:41] Andrew expresses how he feels vindicated for sticking to writing Rails apps even when the trend shifted towards API-only development. [00:15:08] Vladimir shares his journey to joining Evil Martians, starting as a solo developer, and his attraction to the simplicity of Rails. He mentions his experiments with different design patterns and how joining Evil Martians provided a collaborative environment for open source work. [00:19:15] Vladimir talks about how Evil Martians encouraged new engineers to propose conference talks, leading him to present on AnyCable, which sparked his open source contributions. [00:20:18] He talks about how it took a couple of years for his efforts, including writing blog posts and working on AnyCable, to gain recognition and production users outside of Evil Martians. Also, he explains how writing became a way for him to cope with stress and how it contributed to the company's visibility and recognition in the tech community. [00:26:20] We hear about Evil Martians' shift in focus from consumer products to developer tools and how they use and contribute to products built by others. Vladimir briefly discusses HTTPie, and how they helped with its development. [00:28:44] Jason brings up AnyCable, and Vladimir tells us what it is, what problem it solves, and the benefits of using it. Also, he explains how AnyCable allows for seamless replacement of Action Cable in existing applications and its Go-based WebSocket server. [00:32:16] Vladimir mentions that AnyCable has evolved over seven years to offer additional features, including support for different transports and service-sent events, making it versatile for various use cases. [00:34:08] Vladimir discusses the versatility of AnyCable, highlighting that it can be deployed anywhere and used with platforms beyond Rails. He mentions that AnyCable is becoming the default choice for handling WebSockets in Rails applications as they continue to expand their reach into other ecosystems.[00:38:09] We hear about some upcoming features for AnyCable, including presence tracking, and plans to make AnyCable compatible with other ecosystems. Vladimir teases a new feature he's working on for Rails and Turbo.[00:43:04] Andrew shares that he used to read Vladimir's code on GitHub to learn new patterns and gain inspiration for his own work. He mentions reading code from different libraries and ecosystems is a powerful way to expand one's toolkit for problem-solving.[00:43:47] Vladimir suggests the idea of a podcast or show where experts review codebases and discuss patterns, techniques, and the rationale behind certain code decisions. He believes it could be a great way to learn and share knowledge. [00:45:36] Jason shares that he appreciates Vladimir's contributions to Ruby on Rails and the high-quality content shared by Evil Martian's on their blog. [00:46:36] Find out where you can find Vladimir online.Panelists:Jason CharnesAndrew MasonGuest:Vladimir DementyevSponsor:HoneybadgerLinks:Jason Charnes TwitterChris Oliver TwitterAndrew Mason TwitterVladimir Dementyev TwitterVladimir Dementyev GitHubStimulusReflex DiscordEvil MartiansLayered Design for Ruby on Rails Applications: Discover practical design patterns for maintainable web applications by Vladimir DementyevAnyCableHTTPieRails World 2023Ruby for All Podcast

design programming api coding turbo github rails software development layered ruby on rails mvc andrew mason websockets all podcast vladmir evil martians action cable

Europe Market Open: JPY lags after unscheduled BoJ action, Cable below 1.27 pre-BoE

Play Episode Listen Later Aug 3, 2023 2:41

APAC stocks mostly followed suit to the weakness in global peers, albeit with some of the losses stemmed in Asia as participants digested Chinese Caixin PMI figures.European equity futures are indicative of a marginally softer open with the Euro Stoxx 50 -0.1% after the cash market closed down by 1.6% yesterday.DXY remains on the front foot, EUR/USD has moved lower on a 1.09 handle, Cable sits below 1.27 pre-BoE, JPY lags post-BoJ unscheduled bond-buying operation.Brazil Central Bank cut the Selic rate by 50bps to 13.25% (exp. 25bps cut) with the decision not unanimous.Looking ahead, highlights include German Trade, EZ & UK Services PMI (Final), Swiss CPI, US IJC, Factory Orders, ISM Services, BoE Policy Announcement, BoE's Bailey, ECB's Panetta, Fed's Barkin, Bostic & Goolsbee, Supply from Spain & France.Earnings from Adidas, AXA, BMW, Infineon, ING, Lufthansa, Merck, Rolls-Royce, ConocoPhillips, Regeneron Pharmaceuticals, Apple, Kellogg Co, Moderna, Amazon.com, Warner Bros Discovery & Airbnb.Read the full report covering Equities, Forex, Fixed Income, Commodites and more on Newsquawk

Hmmm, Maybe It's The Garbage Collector

Remote Ruby

Play Episode Listen Later Jul 7, 2023 52:05

On today's episode, Chris and Andrew have an early start and catch up on their lives. Then, they dive deep into the latest developments in the Rails community, including the release of Rails 7.0.6, bug fixes, and changes to Active Record. They share their experiences with GitHub deployments, documentation issues, and how they navigate through its challenges. They discuss the benefits of MySQL and Postgres, as well as the ongoing advancements in Postgres, specifically Crunchy Data's contributions. Chris and Andrew share their views on working in different company sizes, the joys of learning new things, dealing with burnout, and the slower pace of feature shipping in larger companies. There's a discussion on Reddit's recent actions, its impact on subreddit moderations, and the discontinuation of the Reddit API. We'll also hear about Chris's cooking adventures, experimenting with different flavors, and making some Texas Twinkies. Hit download to hear more! [00:02:00] Chris and Andrew talk about the release of Rails v7.0.6 with bug fixes and changes in libraries like Action Cable and Active Record, including subqueries and associations with polymorphic relationships.[00:06:10] Andrew is curious about the GitHub deployment stuff and expresses his desire to create GitHub deploys from Heroku. They talk about the complexities of setting up GitHub deployments and the lack of clear information from GitHub, and how the documentation with Checks API can be confusing to set up. [00:09:49] Chris discusses the challenges of figuring out GitHub's deployment process and the lack of documentation. He expresses frustration with the lack of clarity and support for smaller accounts. [00:14:41] PlanetScale is brought up and its association with MySQL, and they discuss the benefits of MySQL and Postgres, and the new features and advancements in Postgres, including Crunchy Data's contributions and the potential use of Postgres in web environments. [00:17:43] Chris shares a fun story about working on implementing jump server support in the new Hatchbox. They encountered unexpected complexities with the net-ssh gem to address the problem. [00:29:51] Chris emphasizes the importance of being mindful of memory usage and performance trade-offs and how it becomes more critical when building large-scale products. [00:31:59] Andrew mentions that releasing features can be challenging and Podia is currently facing that challenge with releasing a feature while also building onto it. He emphasizes the importance of coordination, communication, and learning from code to recognize and solve problems faster. [00:33:46] Chris reflects on his experience working at a consulting agency and how it allowed him to learn quickly by facing different projects and finds joy learning new things as a programmer. [00:34:43] We hear Andrew talk about feeling stuck in a job, comparing small companies which offer more challenges, to big companies where employees get stuck doing the same tasks, and Chris tells us he's happiest when learning new things and how it accelerates burnout.[00:35:57] Chris discusses the challenges faced by big companies when it comes to feature shipping due to the need to ensure existing users are not negatively impacted, and Andrew highlights the varying levels of impact when breaking code and emphasizes the importance of being able to find and fix bugs quickly. [00:39:00] We hear about Chris's mad cooking skills with pulled pork and experimenting with smoked cream cheese which he hopes to use in some Texas Twinkies. [00:43:53] The conversation shifts to Reddit and its recent actions regarding subreddit moderation and the discontinuation of the Reddit API, and they express frustration with Reddit's handling of the situation and the negative consequences it's had on the community. [00:51:30] We end with Chris needing to attend to his cooking tasks and Andrew mentions his responsibility to lead Podia in Jason and Jamie's absence. Panelists:Chris OliverAndrew MasonSponsor:HoneybadgerLinks:Jason Charnes TwitterChris Oliver TwitterAndrew Mason TwitterRails 7.0.6 PlanetScaleCrunchy DataReddit Won't Be the Same. Neither Will the Internet (WIRED)What the Heck is a Texas Twinkie?

reddit heck programming coding github hmmm rails software development ruby on rails mysql podia heroku postgres andrew mason chris oliver planetscale activerecord reddit api garbage collector action cable

Live Streaming to the Command Line with ActionCable ft. Hans Schnedlitz - RUBY 511

Play Episode Listen Later Aug 18, 2021 45:45

Hans Schnedlitz joins the Rogues to discuss how you can use ActionCable to get feedback on ongoing tasks in the commandline by connecting to a websocket. His solution is written entirely in Ruby and provides some interesting options for people building CLI's for their applications. Panel Charles Max Wood Luke Stutters Valentino Stoll Guest Hans Schnedlitz Sponsors Dev Influencers Accelerator Raygun | Click here to get started on your free 14-day trial Links Real-Time Command Line Applications with Action Cable and Thor OptionParser GitHub | ManageIQ/optimist GitHub | rails/thor Rails Application Templates GitHub | rails/rails GitHub | RailsApps/rails-composer TTY GitHub | junegunn/fzf Hans-Jörg Schnedlitz GitHub: Hans-Jörg Schnedlitz ( hschne ) Twitter: Hans Schnedlitz ( @hschnedlitz ) Picks Charles- Kajabi Charles- Devchat.tv/levelup Hans- GitHub | hschne/rails-mini-profiler Hans- Project Hail Mary Luke- CLI OAuth in Ruby Luke- A Rubyist's Walk Along the C-side (Part 6): Classes & Object Oriented Programming Luke- Raspberry Pi Touch Display Valentino- Destroy All Software Valentino- David Dollar | Developer Experience Design Contact Charles: Devchat.tv DevChat.tv | Facebook Twitter: DevChat.tv ( @devchattv ) Contact Luke: GitHub: Luke Stutters ( lukestuts ) Contact Valentino: Doximity Technology Blog Work @ Doximity GitHub: Valentino Stoll ( codenamev ) Twitter: V ( @thecodenamev )

panel thor hans classes github live streaming rogues kajabi hans j cli tty project hail mary command line object oriented programming devchat charles max wood rubyist devchattv dev influencers accelerator action cable raygun click manageiq luke stutters

Live Streaming to the Command LIne with ActionCable ft. Hans Schnedlitz - RUBY 511

Ruby Rogues

Play Episode Listen Later Aug 18, 2021 45:45

Hans Schnedlitz joins the Rogues to discuss how you can use ActionCable to get feedback on ongoing tasks in the commandline by connecting to a websocket. His solution is written entirely in Ruby and provides some interesting options for people building CLI's for their applications. Panel Charles Max WoodLuke StuttersValentino Stoll Guest Hans Schnedlitz Sponsors Dev Influencers AcceleratorRaygun | Click here to get started on your free 14-day trial Links Real-Time Command Line Applications with Action Cable and ThorOptionParserGitHub | ManageIQ/optimistGitHub | rails/thorRails Application TemplatesGitHub | rails/railsGitHub | RailsApps/rails-composerTTYGitHub | junegunn/fzfHans-Jörg SchnedlitzGitHub: Hans-Jörg Schnedlitz ( hschne )Twitter: Hans Schnedlitz ( @hschnedlitz ) Picks Charles- KajabiCharles- Devchat.tv/levelupHans- GitHub | hschne/rails-mini-profilerHans- Project Hail MaryLuke- CLI OAuth in RubyLuke- A Rubyist's Walk Along the C-side (Part 6): Classes & Object Oriented ProgrammingLuke- Raspberry Pi Touch DisplayValentino- Destroy All SoftwareValentino- David Dollar | Developer Experience Design Contact Charles: Devchat.tvDevChat.tv | FacebookTwitter: DevChat.tv ( @devchattv ) Contact Luke: GitHub: Luke Stutters ( lukestuts ) Contact Valentino: Doximity Technology BlogWork @ DoximityGitHub: Valentino Stoll ( codenamev )Twitter: V ( @thecodenamev ) Special Guest: Hans Schnedlitz.

panel thor hans classes github live streaming rogues kajabi hans j cli tty project hail mary command line object oriented programming devchat charles max wood rubyist devchattv dev influencers accelerator action cable raygun click manageiq luke stutters

Live Streaming to the Command Line with ActionCable ft. Hans Schnedlitz - RUBY 511

Play Episode Listen Later Aug 18, 2021 45:45

Hans Schnedlitz joins the Rogues to discuss how you can use ActionCable to get feedback on ongoing tasks in the commandline by connecting to a websocket. His solution is written entirely in Ruby and provides some interesting options for people building CLI's for their applications. Panel Charles Max Wood Luke Stutters Valentino Stoll Guest Hans Schnedlitz Sponsors Dev Influencers Accelerator Raygun | Click here to get started on your free 14-day trial Links Real-Time Command Line Applications with Action Cable and Thor OptionParser GitHub | ManageIQ/optimist GitHub | rails/thor Rails Application Templates GitHub | rails/rails GitHub | RailsApps/rails-composer TTY GitHub | junegunn/fzf Hans-Jörg Schnedlitz GitHub: Hans-Jörg Schnedlitz ( hschne ) Twitter: Hans Schnedlitz ( @hschnedlitz ) Picks Charles- Kajabi Charles- Devchat.tv/levelup Hans- GitHub | hschne/rails-mini-profiler Hans- Project Hail Mary Luke- CLI OAuth in Ruby Luke- A Rubyist's Walk Along the C-side (Part 6): Classes & Object Oriented Programming Luke- Raspberry Pi Touch Display Valentino- Destroy All Software Valentino- David Dollar | Developer Experience Design Contact Charles: Devchat.tv DevChat.tv | Facebook Twitter: DevChat.tv ( @devchattv ) Contact Luke: GitHub: Luke Stutters ( lukestuts ) Contact Valentino: Doximity Technology Blog Work @ Doximity GitHub: Valentino Stoll ( codenamev ) Twitter: V ( @thecodenamev )

panel thor hans classes github live streaming rogues kajabi hans j cli tty project hail mary command line object oriented programming devchat charles max wood rubyist devchattv dev influencers accelerator action cable raygun click manageiq luke stutters

Live Streaming to the Command LIne with ActionCable ft. Hans Schnedlitz - RUBY 511

Play Episode Listen Later Aug 18, 2021 45:45

Hans Schnedlitz joins the Rogues to discuss how you can use ActionCable to get feedback on ongoing tasks in the commandline by connecting to a websocket. His solution is written entirely in Ruby and provides some interesting options for people building CLI's for their applications. Panel Charles Max WoodLuke StuttersValentino Stoll Guest Hans Schnedlitz Sponsors Dev Influencers AcceleratorRaygun | Click here to get started on your free 14-day trial Links Real-Time Command Line Applications with Action Cable and ThorOptionParserGitHub | ManageIQ/optimistGitHub | rails/thorRails Application TemplatesGitHub | rails/railsGitHub | RailsApps/rails-composerTTYGitHub | junegunn/fzfHans-Jörg SchnedlitzGitHub: Hans-Jörg Schnedlitz ( hschne )Twitter: Hans Schnedlitz ( @hschnedlitz ) Picks Charles- KajabiCharles- Devchat.tv/levelupHans- GitHub | hschne/rails-mini-profilerHans- Project Hail MaryLuke- CLI OAuth in RubyLuke- A Rubyist's Walk Along the C-side (Part 6): Classes & Object Oriented ProgrammingLuke- Raspberry Pi Touch DisplayValentino- Destroy All SoftwareValentino- David Dollar | Developer Experience Design Contact Charles: Devchat.tvDevChat.tv | FacebookTwitter: DevChat.tv ( @devchattv ) Contact Luke: GitHub: Luke Stutters ( lukestuts ) Contact Valentino: Doximity Technology BlogWork @ DoximityGitHub: Valentino Stoll ( codenamev )Twitter: V ( @thecodenamev ) Special Guest: Hans Schnedlitz.

panel thor hans classes github live streaming rogues kajabi hans j cli tty project hail mary command line object oriented programming devchat charles max wood rubyist devchattv dev influencers accelerator action cable raygun click manageiq luke stutters

210: Stop Trying to Make Fetch Happen

RWpod - подкаст про мир Ruby и Web технологии

Play Episode Listen Later Aug 20, 2019 34:46

On this week's episode, Steph and Chris discuss mechanical keyboards, combating error fatigue, the joy of admin features and respond to two listener questions about typed vs dynamic languages and various ways to "speed up" third-party API calls. AppSignal New Relic - Six Steps to Combat Alert Fatigue Details and Summary HTML elements Elm Scala Typescript Active Job Action Cable Stimulus Ajax Typheous Rails HTTP Streaming JQuery Become a Sponsor of The Bike Shed!

api stimulus ajax stop trying fetch elm scala typescript jquery action cable

09 выпуск 07 сезона. Rails 6 adds support for timezones to Active Job, .dev for all, renchKiss.js, JavaScript SEO и прочее

Play Episode Listen Later Mar 3, 2019 32:47

Добрый день уважаемые слушатели. Представляем новый выпуск подкаста RWpod. В этом выпуске: Ruby Ruby 2.7 adds shorthand operator for Object#method, Rails 6 adds support for timezones to Active Job, Rails 6 adds before? and after? methods to Date, DateTime, Time, and TimeWithZone, Rails 6 adds negative scopes for all enum values и Debugging in Ruby—Busting a Year-old Bug in Sprockets Diving into Ruby's #dup and #clone, Action Cable vs AnyCable: fight!, Sail - a lightweight Rails engine that brings an admin panel for managing configuration settings on a live Rails app и CryptoZombies - an interactive code school that teaches you to write smart contracts in Solidity through building your own crypto-collectables game Web .dev for all, The CSS Working Group agreed on adding many math functions и 8 Little Videos About the Firefox Shape Path Editor Frontend Bootcamp / Days in the Web, FrenchKiss.js - a blazing fast lightweight i18n library written in JavaScript, Web Accessibility Guide и JavaScript SEO

time web active object bug javascript rails sail time zones debugging french kiss solidity datetime ruby ruby adds support javascript seo css working group action cable

RR 391: Frontend Testing Like a Rubyist with Josh Justice

Play Episode Listen Later Dec 4, 2018 67:04

Panel: Dave Kimura Charles Max Wood Nate Hopkins Special Guest: Josh Justice In this episode of Ruby Rogues, the panelists talk with Josh Justice who is a developer, writer, and speaker. Josh streams JavaScript and web development on Friday’s at 2:00 PM (ET) here! The panelists and the guest talk about Josh’s background and frontend testing in Ruby. Check it out! Show Topics: 0:00 – Advertisement: Sentry.io 1:04 – Chuck: Hi! Dave, Nate, and myself are on the panel and our special guest is Josh Justice! I am developing a show about developer freedom and it’s called The DevRev. It will be streamed through YouTube, and I will record Friday afternoons. Check out Facebook, too! 2:11 – Josh: Thanks! I am happy to be here! 2:18 – Chuck: Introduce yourself, please! 2:24 – Josh: I have been a developer for about 14 years. I have used PHP and then got into Ruby and then frontend development. 2:46 – Chuck: You work for Big Nerd Ranch in Atlanta? 2:56 – Josh: Yep for the last 3-4 years! 3:15 – Chuck: Can you introduce the topic? 3:25 – The guest talks about Big Nerd Ranch and frontend development. Learn TDD is mentioned, too! Check it out here! 5:06 – Panel: How much bouncing do you do between React and Vue? 5:11 – Guest. 5:47 – Chuck: We need to get you on our podcast shows for React and Vue! It’s an approach that I am familiar with in Ruby – and Selenium what a pain! 6:16 – Guest: I’ve had a good experience with Cypress, actually! 7:47 – Guest: Panelist, can you share your experiences? 7:57 – Panel: Not bad experiences with testing, but now I am trying to minimize my use with JavaScript. 8:30 – Guest: I think there is a big push towards considering more server site rendering. 9:35 – Panel: What’s your recommendation to setup Cypress? 9:40 – Guest: Their docs are really great! They had some conference talks on how to set it up! 10:15 – Guest: Check out my talks about this topic. (Connect Tech 2018). 10:29 – Panel: I think Cypress is a pretty cool solution but one thing that left me confused is that you have to have an environment that is already stood-up and running. Is that accurate or has that changed? 11:00 – Guest: Can you clarify what you mean by a “running environment”? 11:04 – Panelist clarifies. 11:44 – Guest: Luckily for me I have something to say b/c I tried a week ago! 12:01 – Guest mentions Vue CLI 3. 14:38 – Panel: How can you test your code coverage? I want to know how much of my code coverage am I hitting? The applications are up and running, it’s not going through the files (per se), and is there anything that would indicate how good your coverage is with the Cypress test? 15:10 – Guest: Let me as a follow-up question: How do you approach it on the frontend? 15:24 – Panelist answers the guest’s question. 16:06 – The guest mentions Vue CLI 2 & 3. 18:31 – Chuck: Are you using the tool Istanbul? 18:36 – Guest: Yep Istanbul is the one! 18:54 – Chuck: I’ve heard some similar rumors, but can’t say. 19:02 – Panelist talks. 20:13 – Chuck: I have been working on a project and what doesn’t get test-coverage gets a candidate to get pulled-out. 20:40 – Guest: Talking about test-driven development... Guest: Have you read the original book? 21:02 – Guest: The book: “Effective Testing with RSpec 3” is updated information – check it out! The guest mentions his live stream on Friday’s. Check out the links found below! 23:57 – Panel: How is the stability with tests like Cypress with end-to-end tests? If you are testing with a login then the user has to be already created. Or what about a Twitter app – the user has to be created and not followed? How do you handle that? 24:22 – Guest: I think we are spoiled in the Rails world b/c of those... 24:53 – The guest answers the panelist’s question! 26:59 – Fresh Books! 28:07 – Guest: Does that help? 28:10 – Panel. 28:21 – Guest: I have been thinking about this, though, recently. Thinking about the contracts through the business. I have dabbled with native development and I see the cost that runs a native app. 30:21 – Panel: It’s refreshing to hear the new market’s demands. I truly haven’t seen an application that requires that. I have built some extensive applications and also very simple ones, too; the need for productivity. 31:17 – Guest mentions a talk at a conference. See here for that information! 31:43 – Guest: I have a friend who was a new developer and he really knows his stuff. He said that he didn’t know if he could be a full stack developer in the next 5-10 years. Wait a minute?! Guest: The freedom to create something that stands alone. Guest: Tom Dale is mentioned by the Guest. 33:35 – Panel: To choose Rails as a new developer (today) it’s not as easy as it was back in the day. Today you have Active Job, Action Cable and so many other components. It’s more complicated today then it was in the past. It could be overwhelming to a new developer. 35:00 – Chuck: I think a lot of that is the community’s fault and not Rails’ fault. 35:57 – Panel. 36:04 – Panel: The counter-argument could say that’s where server-less come in. 36:27 – Chuck: To some degree you can get away with it. You don’t have to worry about the infrastructure or anything else. 36:44 – Panel: Have you tried messing around with server-less functions with AWS? I have and...it’s not easy. There is not a good flow or good work flow in a server-less environment. 38:01 – Chuck: You can go to this website. It makes the setup easier b/c you are adding your Azure or AWS features. 38:30 – Panel: This topic, though, does tie back to the testing topic we were talking about earlier! 39:14 – Panel: Yeah that is why I haven’t gotten into server-less things. The Rails holistic approach is so appealing. 40:14 – Panel continues: I want to take smaller steps when it comes to technology! I want to move into things that we are laying down the tracks to make it easier travelable. That way we can consider the things we’ve learned in the past and help those in the future. 41:07 – Chuck: What are lacking then? What is the friction that is left? Seems like Cypress helped removed that but maybe not? 42:02 – Panelist mentions Cypress, Jest, Mocha, and others! 43:10 – Panel (continues): I am all about experimenting but I want to know all the reasons. What has changed and what hasn’t’ changed? 43:29 – Panel: There is an article written that talks about this topic. 43:59 – Guest mentions the video “Is TDD Dead?” (See links below.) 44:29 – Guest: I like brining thoughts together and taking his or her input and come up with my own thoughts. 46:32 – Guest (continues): The testing trophy is heavier on the top (picture of a trophy). Guest: I think the thing that draws me to unit testing is that... 47:37 – Guest: I am obsessed with testing. The guest gives a summary here! 48:15 – Chuck: We talked with Quincy Larson last week and it’s a really good take on what we are doing and what we are trying to accomplish with our tests. Check it out – it’s coming out soon! 49:05 – Panel: When you are younger into your career – the way you think about structuring your code – when you are comfortable you really don’t need that guidance. 50:00 – Guest: I would encourage folks who were new to coding to do the following... 51:36 – Guest: Think about WHY you are doing (what you are doing) and being able to articulate well what you are doing and why. 52:03 – Panel: There is no question – every time I test I am surprised how much it shapes my thinking about the code and how many bugs that I catch even in code that I thought was operating well. When you go too far though there is a fallacy there. 52:54 – Panel: Yes, testing is very important. I am a test-after-the-fact programmer. That is my self-key term. Don’t write 500-line methods b/c you won’t be able to test that. Don’t make it too abstract so have a common pattern that you will use. Have a lot of private methods that aren’t exposed to the API. 54:03 – Guest: Yes thinking about how to structure your code can be challenging at first but it gets easier. 55:58 – Chuck: I have had talks with Corey Haines about topics like this! 56:47 – Guest: Yes it can be helpful in consultancy now. 59:23 – Guest: Think about this: choosing what level to test at. 1:00:14 – Panel: It’s hard b/c it changes all the time per function or something else. There are tradeoffs with everything we do. 1:00:41 – Chuck: You are the consultant it depends doesn’t it? 1:00:51 – Picks! 1:00:55 – Advertisement: Get A Coder Job! End – Cache Fly! Links: Get a Coder Job Course Ruby Ruby on Rails Angular Cypress Vue React VUE CLI 3 Jest.io Mocha.js GitHub: Istanbul The RSpec Book RR 068 Episode Ember CLI GitHub: Factory_Bot GitHub: VCR Big Nerd Ranch Big Nerd Ranch: Josh Justice / Team Manager The Bike Shed Keynote: Tom Dale @ EmberFest 2018 JSJ 291 Episode Serverless Article: Test-Induced Design Damage Video: Is TDD Dead? Music: Sub Conscious – Electronic / 2004 Music: Interloper / 2015 Disney Heroes: Battle Mode Google Play: Disney Heroes / Battle Mode Book Authoring Playlist Tom Dale’s Twitter Corey Haines’ Twitter Coding It Wrong Josh’s Twitter Josh’s GitHub Josh’s LinkedIn Josh’s Vimeo Video Sponsors: Sentry CacheFly Fresh Books Picks: Nate Phutureprimitive - Sub Conscious Carbon Based Lifeforms - Interloper Dave Dust collections system in Wood Shop Doctor Who - Theme Music Charles Authoring music Disney Hero Battles Josh Effecting Testing with RSpec 3 Growing Object-Oriented Software, Guided by Test XUnit Test Patterns Spectacle App Alfred App

google thinking testing panel dust guided react electronic istanbul api aws github jest javascript azure rails panelists rr php frontend advertisement cypress vue theme music angular sentry mocha serverless ruby on rails freshbooks authoring selenium cachefly corey haines charles max wood big nerd ranch quincy larson jsj rspec ruby rogues devrev rubyist tom dale vue cli nate hopkins chuck you vimeo video ember cli chuck can coder job course connect tech advertisement get a coder job action cable disney heroes battle mode panel it alfred app chuck are panel yeah chuck introduce panel there chuck to

RR 391: Frontend Testing Like a Rubyist with Josh Justice

Play Episode Listen Later Dec 4, 2018 67:04

Panel: Dave Kimura Charles Max Wood Nate Hopkins Special Guest: Josh Justice In this episode of Ruby Rogues, the panelists talk with Josh Justice who is a developer, writer, and speaker. Josh streams JavaScript and web development on Friday’s at 2:00 PM (ET) here! The panelists and the guest talk about Josh’s background and frontend testing in Ruby. Check it out! Show Topics: 0:00 – Advertisement: Sentry.io 1:04 – Chuck: Hi! Dave, Nate, and myself are on the panel and our special guest is Josh Justice! I am developing a show about developer freedom and it’s called The DevRev. It will be streamed through YouTube, and I will record Friday afternoons. Check out Facebook, too! 2:11 – Josh: Thanks! I am happy to be here! 2:18 – Chuck: Introduce yourself, please! 2:24 – Josh: I have been a developer for about 14 years. I have used PHP and then got into Ruby and then frontend development. 2:46 – Chuck: You work for Big Nerd Ranch in Atlanta? 2:56 – Josh: Yep for the last 3-4 years! 3:15 – Chuck: Can you introduce the topic? 3:25 – The guest talks about Big Nerd Ranch and frontend development. Learn TDD is mentioned, too! Check it out here! 5:06 – Panel: How much bouncing do you do between React and Vue? 5:11 – Guest. 5:47 – Chuck: We need to get you on our podcast shows for React and Vue! It’s an approach that I am familiar with in Ruby – and Selenium what a pain! 6:16 – Guest: I’ve had a good experience with Cypress, actually! 7:47 – Guest: Panelist, can you share your experiences? 7:57 – Panel: Not bad experiences with testing, but now I am trying to minimize my use with JavaScript. 8:30 – Guest: I think there is a big push towards considering more server site rendering. 9:35 – Panel: What’s your recommendation to setup Cypress? 9:40 – Guest: Their docs are really great! They had some conference talks on how to set it up! 10:15 – Guest: Check out my talks about this topic. (Connect Tech 2018). 10:29 – Panel: I think Cypress is a pretty cool solution but one thing that left me confused is that you have to have an environment that is already stood-up and running. Is that accurate or has that changed? 11:00 – Guest: Can you clarify what you mean by a “running environment”? 11:04 – Panelist clarifies. 11:44 – Guest: Luckily for me I have something to say b/c I tried a week ago! 12:01 – Guest mentions Vue CLI 3. 14:38 – Panel: How can you test your code coverage? I want to know how much of my code coverage am I hitting? The applications are up and running, it’s not going through the files (per se), and is there anything that would indicate how good your coverage is with the Cypress test? 15:10 – Guest: Let me as a follow-up question: How do you approach it on the frontend? 15:24 – Panelist answers the guest’s question. 16:06 – The guest mentions Vue CLI 2 & 3. 18:31 – Chuck: Are you using the tool Istanbul? 18:36 – Guest: Yep Istanbul is the one! 18:54 – Chuck: I’ve heard some similar rumors, but can’t say. 19:02 – Panelist talks. 20:13 – Chuck: I have been working on a project and what doesn’t get test-coverage gets a candidate to get pulled-out. 20:40 – Guest: Talking about test-driven development... Guest: Have you read the original book? 21:02 – Guest: The book: “Effective Testing with RSpec 3” is updated information – check it out! The guest mentions his live stream on Friday’s. Check out the links found below! 23:57 – Panel: How is the stability with tests like Cypress with end-to-end tests? If you are testing with a login then the user has to be already created. Or what about a Twitter app – the user has to be created and not followed? How do you handle that? 24:22 – Guest: I think we are spoiled in the Rails world b/c of those... 24:53 – The guest answers the panelist’s question! 26:59 – Fresh Books! 28:07 – Guest: Does that help? 28:10 – Panel. 28:21 – Guest: I have been thinking about this, though, recently. Thinking about the contracts through the business. I have dabbled with native development and I see the cost that runs a native app. 30:21 – Panel: It’s refreshing to hear the new market’s demands. I truly haven’t seen an application that requires that. I have built some extensive applications and also very simple ones, too; the need for productivity. 31:17 – Guest mentions a talk at a conference. See here for that information! 31:43 – Guest: I have a friend who was a new developer and he really knows his stuff. He said that he didn’t know if he could be a full stack developer in the next 5-10 years. Wait a minute?! Guest: The freedom to create something that stands alone. Guest: Tom Dale is mentioned by the Guest. 33:35 – Panel: To choose Rails as a new developer (today) it’s not as easy as it was back in the day. Today you have Active Job, Action Cable and so many other components. It’s more complicated today then it was in the past. It could be overwhelming to a new developer. 35:00 – Chuck: I think a lot of that is the community’s fault and not Rails’ fault. 35:57 – Panel. 36:04 – Panel: The counter-argument could say that’s where server-less come in. 36:27 – Chuck: To some degree you can get away with it. You don’t have to worry about the infrastructure or anything else. 36:44 – Panel: Have you tried messing around with server-less functions with AWS? I have and...it’s not easy. There is not a good flow or good work flow in a server-less environment. 38:01 – Chuck: You can go to this website. It makes the setup easier b/c you are adding your Azure or AWS features. 38:30 – Panel: This topic, though, does tie back to the testing topic we were talking about earlier! 39:14 – Panel: Yeah that is why I haven’t gotten into server-less things. The Rails holistic approach is so appealing. 40:14 – Panel continues: I want to take smaller steps when it comes to technology! I want to move into things that we are laying down the tracks to make it easier travelable. That way we can consider the things we’ve learned in the past and help those in the future. 41:07 – Chuck: What are lacking then? What is the friction that is left? Seems like Cypress helped removed that but maybe not? 42:02 – Panelist mentions Cypress, Jest, Mocha, and others! 43:10 – Panel (continues): I am all about experimenting but I want to know all the reasons. What has changed and what hasn’t’ changed? 43:29 – Panel: There is an article written that talks about this topic. 43:59 – Guest mentions the video “Is TDD Dead?” (See links below.) 44:29 – Guest: I like brining thoughts together and taking his or her input and come up with my own thoughts. 46:32 – Guest (continues): The testing trophy is heavier on the top (picture of a trophy). Guest: I think the thing that draws me to unit testing is that... 47:37 – Guest: I am obsessed with testing. The guest gives a summary here! 48:15 – Chuck: We talked with Quincy Larson last week and it’s a really good take on what we are doing and what we are trying to accomplish with our tests. Check it out – it’s coming out soon! 49:05 – Panel: When you are younger into your career – the way you think about structuring your code – when you are comfortable you really don’t need that guidance. 50:00 – Guest: I would encourage folks who were new to coding to do the following... 51:36 – Guest: Think about WHY you are doing (what you are doing) and being able to articulate well what you are doing and why. 52:03 – Panel: There is no question – every time I test I am surprised how much it shapes my thinking about the code and how many bugs that I catch even in code that I thought was operating well. When you go too far though there is a fallacy there. 52:54 – Panel: Yes, testing is very important. I am a test-after-the-fact programmer. That is my self-key term. Don’t write 500-line methods b/c you won’t be able to test that. Don’t make it too abstract so have a common pattern that you will use. Have a lot of private methods that aren’t exposed to the API. 54:03 – Guest: Yes thinking about how to structure your code can be challenging at first but it gets easier. 55:58 – Chuck: I have had talks with Corey Haines about topics like this! 56:47 – Guest: Yes it can be helpful in consultancy now. 59:23 – Guest: Think about this: choosing what level to test at. 1:00:14 – Panel: It’s hard b/c it changes all the time per function or something else. There are tradeoffs with everything we do. 1:00:41 – Chuck: You are the consultant it depends doesn’t it? 1:00:51 – Picks! 1:00:55 – Advertisement: Get A Coder Job! End – Cache Fly! Links: Get a Coder Job Course Ruby Ruby on Rails Angular Cypress Vue React VUE CLI 3 Jest.io Mocha.js GitHub: Istanbul The RSpec Book RR 068 Episode Ember CLI GitHub: Factory_Bot GitHub: VCR Big Nerd Ranch Big Nerd Ranch: Josh Justice / Team Manager The Bike Shed Keynote: Tom Dale @ EmberFest 2018 JSJ 291 Episode Serverless Article: Test-Induced Design Damage Video: Is TDD Dead? Music: Sub Conscious – Electronic / 2004 Music: Interloper / 2015 Disney Heroes: Battle Mode Google Play: Disney Heroes / Battle Mode Book Authoring Playlist Tom Dale’s Twitter Corey Haines’ Twitter Coding It Wrong Josh’s Twitter Josh’s GitHub Josh’s LinkedIn Josh’s Vimeo Video Sponsors: Sentry CacheFly Fresh Books Picks: Nate Phutureprimitive - Sub Conscious Carbon Based Lifeforms - Interloper Dave Dust collections system in Wood Shop Doctor Who - Theme Music Charles Authoring music Disney Hero Battles Josh Effecting Testing with RSpec 3 Growing Object-Oriented Software, Guided by Test XUnit Test Patterns Spectacle App Alfred App

google thinking testing panel dust guided react electronic istanbul api aws github jest javascript azure rails panelists rr php frontend advertisement cypress vue theme music angular sentry mocha serverless ruby on rails freshbooks authoring selenium cachefly corey haines charles max wood big nerd ranch quincy larson jsj rspec ruby rogues devrev rubyist tom dale vue cli nate hopkins chuck you vimeo video ember cli chuck can coder job course connect tech action cable advertisement get a coder job disney heroes battle mode panel it alfred app chuck are panel yeah chuck introduce panel there chuck to

RR 391: Frontend Testing Like a Rubyist with Josh Justice

Ruby Rogues

Play Episode Listen Later Dec 4, 2018 67:04

Panel: Dave Kimura Charles Max Wood Nate Hopkins Special Guest: Josh Justice In this episode of Ruby Rogues, the panelists talk with Josh Justice who is a developer, writer, and speaker. Josh streams JavaScript and web development on Friday’s at 2:00 PM (ET) here! The panelists and the guest talk about Josh’s background and frontend testing in Ruby. Check it out! Show Topics: 0:00 – Advertisement: Sentry.io 1:04 – Chuck: Hi! Dave, Nate, and myself are on the panel and our special guest is Josh Justice! I am developing a show about developer freedom and it’s called The DevRev. It will be streamed through YouTube, and I will record Friday afternoons. Check out Facebook, too! 2:11 – Josh: Thanks! I am happy to be here! 2:18 – Chuck: Introduce yourself, please! 2:24 – Josh: I have been a developer for about 14 years. I have used PHP and then got into Ruby and then frontend development. 2:46 – Chuck: You work for Big Nerd Ranch in Atlanta? 2:56 – Josh: Yep for the last 3-4 years! 3:15 – Chuck: Can you introduce the topic? 3:25 – The guest talks about Big Nerd Ranch and frontend development. Learn TDD is mentioned, too! Check it out here! 5:06 – Panel: How much bouncing do you do between React and Vue? 5:11 – Guest. 5:47 – Chuck: We need to get you on our podcast shows for React and Vue! It’s an approach that I am familiar with in Ruby – and Selenium what a pain! 6:16 – Guest: I’ve had a good experience with Cypress, actually! 7:47 – Guest: Panelist, can you share your experiences? 7:57 – Panel: Not bad experiences with testing, but now I am trying to minimize my use with JavaScript. 8:30 – Guest: I think there is a big push towards considering more server site rendering. 9:35 – Panel: What’s your recommendation to setup Cypress? 9:40 – Guest: Their docs are really great! They had some conference talks on how to set it up! 10:15 – Guest: Check out my talks about this topic. (Connect Tech 2018). 10:29 – Panel: I think Cypress is a pretty cool solution but one thing that left me confused is that you have to have an environment that is already stood-up and running. Is that accurate or has that changed? 11:00 – Guest: Can you clarify what you mean by a “running environment”? 11:04 – Panelist clarifies. 11:44 – Guest: Luckily for me I have something to say b/c I tried a week ago! 12:01 – Guest mentions Vue CLI 3. 14:38 – Panel: How can you test your code coverage? I want to know how much of my code coverage am I hitting? The applications are up and running, it’s not going through the files (per se), and is there anything that would indicate how good your coverage is with the Cypress test? 15:10 – Guest: Let me as a follow-up question: How do you approach it on the frontend? 15:24 – Panelist answers the guest’s question. 16:06 – The guest mentions Vue CLI 2 & 3. 18:31 – Chuck: Are you using the tool Istanbul? 18:36 – Guest: Yep Istanbul is the one! 18:54 – Chuck: I’ve heard some similar rumors, but can’t say. 19:02 – Panelist talks. 20:13 – Chuck: I have been working on a project and what doesn’t get test-coverage gets a candidate to get pulled-out. 20:40 – Guest: Talking about test-driven development... Guest: Have you read the original book? 21:02 – Guest: The book: “Effective Testing with RSpec 3” is updated information – check it out! The guest mentions his live stream on Friday’s. Check out the links found below! 23:57 – Panel: How is the stability with tests like Cypress with end-to-end tests? If you are testing with a login then the user has to be already created. Or what about a Twitter app – the user has to be created and not followed? How do you handle that? 24:22 – Guest: I think we are spoiled in the Rails world b/c of those... 24:53 – The guest answers the panelist’s question! 26:59 – Fresh Books! 28:07 – Guest: Does that help? 28:10 – Panel. 28:21 – Guest: I have been thinking about this, though, recently. Thinking about the contracts through the business. I have dabbled with native development and I see the cost that runs a native app. 30:21 – Panel: It’s refreshing to hear the new market’s demands. I truly haven’t seen an application that requires that. I have built some extensive applications and also very simple ones, too; the need for productivity. 31:17 – Guest mentions a talk at a conference. See here for that information! 31:43 – Guest: I have a friend who was a new developer and he really knows his stuff. He said that he didn’t know if he could be a full stack developer in the next 5-10 years. Wait a minute?! Guest: The freedom to create something that stands alone. Guest: Tom Dale is mentioned by the Guest. 33:35 – Panel: To choose Rails as a new developer (today) it’s not as easy as it was back in the day. Today you have Active Job, Action Cable and so many other components. It’s more complicated today then it was in the past. It could be overwhelming to a new developer. 35:00 – Chuck: I think a lot of that is the community’s fault and not Rails’ fault. 35:57 – Panel. 36:04 – Panel: The counter-argument could say that’s where server-less come in. 36:27 – Chuck: To some degree you can get away with it. You don’t have to worry about the infrastructure or anything else. 36:44 – Panel: Have you tried messing around with server-less functions with AWS? I have and...it’s not easy. There is not a good flow or good work flow in a server-less environment. 38:01 – Chuck: You can go to this website. It makes the setup easier b/c you are adding your Azure or AWS features. 38:30 – Panel: This topic, though, does tie back to the testing topic we were talking about earlier! 39:14 – Panel: Yeah that is why I haven’t gotten into server-less things. The Rails holistic approach is so appealing. 40:14 – Panel continues: I want to take smaller steps when it comes to technology! I want to move into things that we are laying down the tracks to make it easier travelable. That way we can consider the things we’ve learned in the past and help those in the future. 41:07 – Chuck: What are lacking then? What is the friction that is left? Seems like Cypress helped removed that but maybe not? 42:02 – Panelist mentions Cypress, Jest, Mocha, and others! 43:10 – Panel (continues): I am all about experimenting but I want to know all the reasons. What has changed and what hasn’t’ changed? 43:29 – Panel: There is an article written that talks about this topic. 43:59 – Guest mentions the video “Is TDD Dead?” (See links below.) 44:29 – Guest: I like brining thoughts together and taking his or her input and come up with my own thoughts. 46:32 – Guest (continues): The testing trophy is heavier on the top (picture of a trophy). Guest: I think the thing that draws me to unit testing is that... 47:37 – Guest: I am obsessed with testing. The guest gives a summary here! 48:15 – Chuck: We talked with Quincy Larson last week and it’s a really good take on what we are doing and what we are trying to accomplish with our tests. Check it out – it’s coming out soon! 49:05 – Panel: When you are younger into your career – the way you think about structuring your code – when you are comfortable you really don’t need that guidance. 50:00 – Guest: I would encourage folks who were new to coding to do the following... 51:36 – Guest: Think about WHY you are doing (what you are doing) and being able to articulate well what you are doing and why. 52:03 – Panel: There is no question – every time I test I am surprised how much it shapes my thinking about the code and how many bugs that I catch even in code that I thought was operating well. When you go too far though there is a fallacy there. 52:54 – Panel: Yes, testing is very important. I am a test-after-the-fact programmer. That is my self-key term. Don’t write 500-line methods b/c you won’t be able to test that. Don’t make it too abstract so have a common pattern that you will use. Have a lot of private methods that aren’t exposed to the API. 54:03 – Guest: Yes thinking about how to structure your code can be challenging at first but it gets easier. 55:58 – Chuck: I have had talks with Corey Haines about topics like this! 56:47 – Guest: Yes it can be helpful in consultancy now. 59:23 – Guest: Think about this: choosing what level to test at. 1:00:14 – Panel: It’s hard b/c it changes all the time per function or something else. There are tradeoffs with everything we do. 1:00:41 – Chuck: You are the consultant it depends doesn’t it? 1:00:51 – Picks! 1:00:55 – Advertisement: Get A Coder Job! End – Cache Fly! Links: Get a Coder Job Course Ruby Ruby on Rails Angular Cypress Vue React VUE CLI 3 Jest.io Mocha.js GitHub: Istanbul The RSpec Book RR 068 Episode Ember CLI GitHub: Factory_Bot GitHub: VCR Big Nerd Ranch Big Nerd Ranch: Josh Justice / Team Manager The Bike Shed Keynote: Tom Dale @ EmberFest 2018 JSJ 291 Episode Serverless Article: Test-Induced Design Damage Video: Is TDD Dead? Music: Sub Conscious – Electronic / 2004 Music: Interloper / 2015 Disney Heroes: Battle Mode Google Play: Disney Heroes / Battle Mode Book Authoring Playlist Tom Dale’s Twitter Corey Haines’ Twitter Coding It Wrong Josh’s Twitter Josh’s GitHub Josh’s LinkedIn Josh’s Vimeo Video Sponsors: Sentry CacheFly Fresh Books Picks: Nate Phutureprimitive - Sub Conscious Carbon Based Lifeforms - Interloper Dave Dust collections system in Wood Shop Doctor Who - Theme Music Charles Authoring music Disney Hero Battles Josh Effecting Testing with RSpec 3 Growing Object-Oriented Software, Guided by Test XUnit Test Patterns Spectacle App Alfred App

google thinking testing panel dust guided react electronic istanbul api aws github jest javascript azure rails panelists rr php frontend advertisement cypress vue theme music angular sentry mocha serverless ruby on rails freshbooks authoring selenium cachefly corey haines charles max wood big nerd ranch quincy larson jsj rspec ruby rogues devrev rubyist tom dale vue cli nate hopkins chuck you vimeo video ember cli chuck can coder job course connect tech advertisement get a coder job action cable disney heroes battle mode panel it alfred app chuck are panel yeah chuck introduce panel there chuck to

MRS 066: Nassredean Nasseri

My Ruby Story

Play Episode Listen Later Oct 24, 2018 28:55

Panel: Charles Max Wood Guest: Nassredean Nasseri This week on My Ruby Story, Chuck talks with Dean who is a senior software engineer at VTS, Inc. in New York City. Dean uses Ruby and is an advocate for the software. He and Chuck discuss his background, current projects, and more! In particular, we dive pretty deep on: 1:00 – Dean: Hi, Everyone! 2:07 – Chuck: E363 of Ruby Rogues is your past episode. 1:13 – Dean: I am a Ruby developer and out in NY City. I have been developing Ruby for the past 6 years now. 1:42 – Chuck: What made you want to do something like Fir? 1:50 – Dean: I love developing developer tools and using something that I can use in my day-to-day work – I like that. I am constantly debugging and trying new things. That’s how I operate. I wanted to build a tool that would take the concepts that were missing from IRB and...put in a shell like FITCH. That was the motivation to that project. 2:42 – Chuck: Check out his past episode to get into the nitty gritty. Let’s roll back – how did you get into programming? 3:10 – Dean: I started programming in 2009/2010. I was a senior in High School and I wanted to make a social media website. I knew about HTML and other things but databases and servers I had no idea about. I downloaded WAMP – you familiar? It stands for: WINDOWS APACHE, MYSQL, and PHP. 4:19 – Chuck: What about programming that got you started? 4:27 – Dean: To build the thing that was in my head. My motivation was I wanted to see this THING to get built. I had a UI and I used jQuery. I got further and further; I realized that I was enjoying it. I liked the feeling and I spent 6 hours and I felt rewarded. 5:12 – Chuck: I played with programming as a younger person but in college I was introduced to...and I liked something coming together. Programming felt like a toy for me. I built a platform for people to find an apartment with their amenities that they wanted. It never came to light but it was fun to build. 6:00 – Dean. 6:12 – Chuck: I was a software consultant for a while. They spent 10’s of thousands of dollars on this project and me. You get into PHP and how did you come to Ruby? 6:40 – Dean: I didn’t study computer science in college. My friends who had a “background” and they said that I needed to use Python. Python held me back b/c of the 2 to 3 split and the server getting up on my machine b/c certain tendencies needed x, y, and z. That drove me away from Python but I did like the language. My friend told me to try Ruby and I read a book (Ruby on Rails by Michael, 2nd ed.) and I got Ruby. That was really cool to me. I went through the tutorial and that was powerful for me. Motto: Keep things fun and simple and then build on things later. 8:59 – Chuck: I hear people complain about Ruby. Can you still do that? 9:13 – Dean: Yes, I think so. The thing that stands out to me is action cable. Maybe a beginner doesn’t want to have to think about. Rails is the best way to get up and running with minimum friction. 9:45 – Chuck: I worked through a company and I was their tech support – so I can relate to that. Other things that people worry about: Action Cable, etc. you don’t have to worry about that until later. That makes sense. What have you done that your proud of? 10:24 – Dean: I worked at a company and proud of the certain features I have built and shipped. I am proud of learning more and more about Ruby internals. I am proud of FIR, too. 11:43 – Chuck: Yeah, FIR does sound interesting. I hear people say that often: I built this thing and it makes a difference in this way. What are you working on now? 12:11 – Dean: Tech Ops; it’s a hybrid between DevOps and... We have worked on projects like migrating CAM CAM CAM to PUNDIT. That was the last huge Ruby project we’ve worked on. Our ongoing mission is to make sure things are up to date. I have been migrating from our former CI provider to Circle CI. It’s been a challenge. It requires DOCKER and it was important for us to use... (Dean goes into more detail.) Dean: We have been working on flaky tests, which was more Ruby focused. (Dean goes into more detail.) 15:42 – Chuck: I am curious to see what those tips are? 15:49 – Charlie McMillan – check out his blog post: Tips to Fixing Flaky Feature Specs. There is a real art to it. 16:06 – Chuck: Anything else? 16:16 – Dean: That’s pretty much the good stuff. 16:24 – Chuck: Over the course of your career what is an overarching theme? 16:42 – Dean: From the technological side – not really – but important to my development is empathy. Develop empathy for your colleagues, and customers. I love the tech stuff, but I made mistakes. I was so tech focused that maybe at the expense of my team. The soft skills are really important to this business. Being empathetic in this field and this is equally as important to being a really good empathetic person. 18:03 – Chuck: As we continue to see things grow – you can build small applications on your own. But when you are building a Facebook or something complex – then at that point your ability to work with people trumps your technical abilities. Once your past that can you work with other people? 19:06 – Picks! 19:14 – Advertisement – Fresh Books! Links: Ruby Elixir Rails Rust Dean’s Medium Dean’s Website Dean’s GitHub Dean’s Flickr Sponsors: Get a Coder Job Cache Fly Fresh Books Picks: Charles Get A Coder Job Book: Scourged by Kevin Hearne Down? Depressed? Try taking care of other people! Dean VTS b/c we are hiring Book: Iran Awakening – By Nobel Peace Prize Winner

new york city google tips high school medium develop panel programming rust python ui github devops fitch html rails php flickr pundits elixir docker advertisement ruby on rails mysql freshbooks fir jquery irb ny city circleci vts cachefly kevin hearne wamp charles max wood ruby rogues chuck yeah coder job chuck anything get a coder job us 2528sem 2529branded 257cexm action cable chuck check 252bx chuck as

MRS 066: Nassredean Nasseri

Play Episode Listen Later Oct 24, 2018 28:55

Panel: Charles Max Wood Guest: Nassredean Nasseri This week on My Ruby Story, Chuck talks with Dean who is a senior software engineer at VTS, Inc. in New York City. Dean uses Ruby and is an advocate for the software. He and Chuck discuss his background, current projects, and more! In particular, we dive pretty deep on: 1:00 – Dean: Hi, Everyone! 2:07 – Chuck: E363 of Ruby Rogues is your past episode. 1:13 – Dean: I am a Ruby developer and out in NY City. I have been developing Ruby for the past 6 years now. 1:42 – Chuck: What made you want to do something like Fir? 1:50 – Dean: I love developing developer tools and using something that I can use in my day-to-day work – I like that. I am constantly debugging and trying new things. That’s how I operate. I wanted to build a tool that would take the concepts that were missing from IRB and...put in a shell like FITCH. That was the motivation to that project. 2:42 – Chuck: Check out his past episode to get into the nitty gritty. Let’s roll back – how did you get into programming? 3:10 – Dean: I started programming in 2009/2010. I was a senior in High School and I wanted to make a social media website. I knew about HTML and other things but databases and servers I had no idea about. I downloaded WAMP – you familiar? It stands for: WINDOWS APACHE, MYSQL, and PHP. 4:19 – Chuck: What about programming that got you started? 4:27 – Dean: To build the thing that was in my head. My motivation was I wanted to see this THING to get built. I had a UI and I used jQuery. I got further and further; I realized that I was enjoying it. I liked the feeling and I spent 6 hours and I felt rewarded. 5:12 – Chuck: I played with programming as a younger person but in college I was introduced to...and I liked something coming together. Programming felt like a toy for me. I built a platform for people to find an apartment with their amenities that they wanted. It never came to light but it was fun to build. 6:00 – Dean. 6:12 – Chuck: I was a software consultant for a while. They spent 10’s of thousands of dollars on this project and me. You get into PHP and how did you come to Ruby? 6:40 – Dean: I didn’t study computer science in college. My friends who had a “background” and they said that I needed to use Python. Python held me back b/c of the 2 to 3 split and the server getting up on my machine b/c certain tendencies needed x, y, and z. That drove me away from Python but I did like the language. My friend told me to try Ruby and I read a book (Ruby on Rails by Michael, 2nd ed.) and I got Ruby. That was really cool to me. I went through the tutorial and that was powerful for me. Motto: Keep things fun and simple and then build on things later. 8:59 – Chuck: I hear people complain about Ruby. Can you still do that? 9:13 – Dean: Yes, I think so. The thing that stands out to me is action cable. Maybe a beginner doesn’t want to have to think about. Rails is the best way to get up and running with minimum friction. 9:45 – Chuck: I worked through a company and I was their tech support – so I can relate to that. Other things that people worry about: Action Cable, etc. you don’t have to worry about that until later. That makes sense. What have you done that your proud of? 10:24 – Dean: I worked at a company and proud of the certain features I have built and shipped. I am proud of learning more and more about Ruby internals. I am proud of FIR, too. 11:43 – Chuck: Yeah, FIR does sound interesting. I hear people say that often: I built this thing and it makes a difference in this way. What are you working on now? 12:11 – Dean: Tech Ops; it’s a hybrid between DevOps and... We have worked on projects like migrating CAM CAM CAM to PUNDIT. That was the last huge Ruby project we’ve worked on. Our ongoing mission is to make sure things are up to date. I have been migrating from our former CI provider to Circle CI. It’s been a challenge. It requires DOCKER and it was important for us to use... (Dean goes into more detail.) Dean: We have been working on flaky tests, which was more Ruby focused. (Dean goes into more detail.) 15:42 – Chuck: I am curious to see what those tips are? 15:49 – Charlie McMillan – check out his blog post: Tips to Fixing Flaky Feature Specs. There is a real art to it. 16:06 – Chuck: Anything else? 16:16 – Dean: That’s pretty much the good stuff. 16:24 – Chuck: Over the course of your career what is an overarching theme? 16:42 – Dean: From the technological side – not really – but important to my development is empathy. Develop empathy for your colleagues, and customers. I love the tech stuff, but I made mistakes. I was so tech focused that maybe at the expense of my team. The soft skills are really important to this business. Being empathetic in this field and this is equally as important to being a really good empathetic person. 18:03 – Chuck: As we continue to see things grow – you can build small applications on your own. But when you are building a Facebook or something complex – then at that point your ability to work with people trumps your technical abilities. Once your past that can you work with other people? 19:06 – Picks! 19:14 – Advertisement – Fresh Books! Links: Ruby Elixir Rails Rust Dean’s Medium Dean’s Website Dean’s GitHub Dean’s Flickr Sponsors: Get a Coder Job Cache Fly Fresh Books Picks: Charles Get A Coder Job Book: Scourged by Kevin Hearne Down? Depressed? Try taking care of other people! Dean VTS b/c we are hiring Book: Iran Awakening – By Nobel Peace Prize Winner

new york city google tips high school medium develop panel programming rust python ui github devops fitch html rails php flickr pundits elixir docker advertisement ruby on rails mysql freshbooks fir jquery irb ny city circleci vts cachefly kevin hearne wamp charles max wood ruby rogues chuck yeah coder job chuck anything get a coder job us 2528sem 2529branded 257cexm action cable chuck check 252bx chuck as

MRS 066: Nassredean Nasseri

Play Episode Listen Later Oct 24, 2018 28:55

Panel: Charles Max Wood Guest: Nassredean Nasseri This week on My Ruby Story, Chuck talks with Dean who is a senior software engineer at VTS, Inc. in New York City. Dean uses Ruby and is an advocate for the software. He and Chuck discuss his background, current projects, and more! In particular, we dive pretty deep on: 1:00 – Dean: Hi, Everyone! 2:07 – Chuck: E363 of Ruby Rogues is your past episode. 1:13 – Dean: I am a Ruby developer and out in NY City. I have been developing Ruby for the past 6 years now. 1:42 – Chuck: What made you want to do something like Fir? 1:50 – Dean: I love developing developer tools and using something that I can use in my day-to-day work – I like that. I am constantly debugging and trying new things. That’s how I operate. I wanted to build a tool that would take the concepts that were missing from IRB and...put in a shell like FITCH. That was the motivation to that project. 2:42 – Chuck: Check out his past episode to get into the nitty gritty. Let’s roll back – how did you get into programming? 3:10 – Dean: I started programming in 2009/2010. I was a senior in High School and I wanted to make a social media website. I knew about HTML and other things but databases and servers I had no idea about. I downloaded WAMP – you familiar? It stands for: WINDOWS APACHE, MYSQL, and PHP. 4:19 – Chuck: What about programming that got you started? 4:27 – Dean: To build the thing that was in my head. My motivation was I wanted to see this THING to get built. I had a UI and I used jQuery. I got further and further; I realized that I was enjoying it. I liked the feeling and I spent 6 hours and I felt rewarded. 5:12 – Chuck: I played with programming as a younger person but in college I was introduced to...and I liked something coming together. Programming felt like a toy for me. I built a platform for people to find an apartment with their amenities that they wanted. It never came to light but it was fun to build. 6:00 – Dean. 6:12 – Chuck: I was a software consultant for a while. They spent 10’s of thousands of dollars on this project and me. You get into PHP and how did you come to Ruby? 6:40 – Dean: I didn’t study computer science in college. My friends who had a “background” and they said that I needed to use Python. Python held me back b/c of the 2 to 3 split and the server getting up on my machine b/c certain tendencies needed x, y, and z. That drove me away from Python but I did like the language. My friend told me to try Ruby and I read a book (Ruby on Rails by Michael, 2nd ed.) and I got Ruby. That was really cool to me. I went through the tutorial and that was powerful for me. Motto: Keep things fun and simple and then build on things later. 8:59 – Chuck: I hear people complain about Ruby. Can you still do that? 9:13 – Dean: Yes, I think so. The thing that stands out to me is action cable. Maybe a beginner doesn’t want to have to think about. Rails is the best way to get up and running with minimum friction. 9:45 – Chuck: I worked through a company and I was their tech support – so I can relate to that. Other things that people worry about: Action Cable, etc. you don’t have to worry about that until later. That makes sense. What have you done that your proud of? 10:24 – Dean: I worked at a company and proud of the certain features I have built and shipped. I am proud of learning more and more about Ruby internals. I am proud of FIR, too. 11:43 – Chuck: Yeah, FIR does sound interesting. I hear people say that often: I built this thing and it makes a difference in this way. What are you working on now? 12:11 – Dean: Tech Ops; it’s a hybrid between DevOps and... We have worked on projects like migrating CAM CAM CAM to PUNDIT. That was the last huge Ruby project we’ve worked on. Our ongoing mission is to make sure things are up to date. I have been migrating from our former CI provider to Circle CI. It’s been a challenge. It requires DOCKER and it was important for us to use... (Dean goes into more detail.) Dean: We have been working on flaky tests, which was more Ruby focused. (Dean goes into more detail.) 15:42 – Chuck: I am curious to see what those tips are? 15:49 – Charlie McMillan – check out his blog post: Tips to Fixing Flaky Feature Specs. There is a real art to it. 16:06 – Chuck: Anything else? 16:16 – Dean: That’s pretty much the good stuff. 16:24 – Chuck: Over the course of your career what is an overarching theme? 16:42 – Dean: From the technological side – not really – but important to my development is empathy. Develop empathy for your colleagues, and customers. I love the tech stuff, but I made mistakes. I was so tech focused that maybe at the expense of my team. The soft skills are really important to this business. Being empathetic in this field and this is equally as important to being a really good empathetic person. 18:03 – Chuck: As we continue to see things grow – you can build small applications on your own. But when you are building a Facebook or something complex – then at that point your ability to work with people trumps your technical abilities. Once your past that can you work with other people? 19:06 – Picks! 19:14 – Advertisement – Fresh Books! Links: Ruby Elixir Rails Rust Dean’s Medium Dean’s Website Dean’s GitHub Dean’s Flickr Sponsors: Get a Coder Job Cache Fly Fresh Books Picks: Charles Get A Coder Job Book: Scourged by Kevin Hearne Down? Depressed? Try taking care of other people! Dean VTS b/c we are hiring Book: Iran Awakening – By Nobel Peace Prize Winner

new york city google tips high school medium develop panel programming rust python ui github devops fitch html rails php flickr pundits elixir docker advertisement ruby on rails mysql freshbooks fir jquery irb ny city circleci vts cachefly kevin hearne wamp charles max wood ruby rogues chuck yeah coder job chuck anything get a coder job us 2528sem 2529branded 257cexm action cable chuck check 252bx chuck as

RR 342 Rails, Development, and More with David Heinemeier Hansson

Play Episode Listen Later Dec 27, 2017 92:08

Panel: Charles Max Wood Dave Kimura David Richards Eric Berry In this episode, the Ruby Rogues panel discuss Rails, Development, and More with David Heinemeier Hansson. David is the creator of Ruby on Rails, the founder and CTO of Basecamp, and the hosts of The ReWork Podcast. David Answers a number of questions form the panel about the front-end on Rails, Turbo Link, Stimulus, How does this differ, cheaper labor, better hardware, and much more. This is a great episode to understand the background of Ruby on Rails, Basecamps, and things to come with Ruby. In particular, we dive pretty deep on: The new book The Com Company Where are we going with the front-end on Rails? Turbo Links Stimulus Redux Application Productivity Do you Stimulus providing enough? How does this differ from new things coming out? Ruby on Rails will not last… Toolkits Cheaper hardware Basecamp Higher cost of programmers The Frontier C in Java Why don’t you hire senior experience? Experience and career path Remote Work Paying developers enough Competitive pay Switching jobs and values What is your vision of where Active Storage is going? Cloud Storage Action Cable What are your thoughts on bitcoin? Train wrecks and it will end badly How about BlockChain and the web? What is your daily driver? Cars? Watches? Porche 911 Celebrating technological heritage What is in tech that you are liking? VR And much much more Links: http://david.heinemeierhansson.com https://twitter.com/internetofshit?lang=en The ReWork Podcast @dhh Picks: Dave Minio David co2meter.com Sensor Push The Meditations Eric Secret of Luck Post - Funding open source Charles Carrier Wave Git Lab

RR 342 Rails, Development, and More with David Heinemeier Hansson

Ruby Rogues

Play Episode Listen Later Dec 27, 2017 92:08

Panel: Charles Max Wood Dave Kimura David Richards Eric Berry In this episode, the Ruby Rogues panel discuss Rails, Development, and More with David Heinemeier Hansson. David is the creator of Ruby on Rails, the founder and CTO of Basecamp, and the hosts of The ReWork Podcast. David Answers a number of questions form the panel about the front-end on Rails, Turbo Link, Stimulus, How does this differ, cheaper labor, better hardware, and much more. This is a great episode to understand the background of Ruby on Rails, Basecamps, and things to come with Ruby. In particular, we dive pretty deep on: The new book The Com Company Where are we going with the front-end on Rails? Turbo Links Stimulus Redux Application Productivity Do you Stimulus providing enough? How does this differ from new things coming out? Ruby on Rails will not last… Toolkits Cheaper hardware Basecamp Higher cost of programmers The Frontier C in Java Why don’t you hire senior experience? Experience and career path Remote Work Paying developers enough Competitive pay Switching jobs and values What is your vision of where Active Storage is going? Cloud Storage Action Cable What are your thoughts on bitcoin? Train wrecks and it will end badly How about BlockChain and the web? What is your daily driver? Cars? Watches? Porche 911 Celebrating technological heritage What is in tech that you are liking? VR And much much more Links: http://david.heinemeierhansson.com https://twitter.com/internetofshit?lang=en The ReWork Podcast @dhh Picks: Dave Minio David co2meter.com Sensor Push The Meditations Eric Secret of Luck Post - Funding open source Charles Carrier Wave Git Lab

RR 342 Rails, Development, and More with David Heinemeier Hansson

Play Episode Listen Later Dec 26, 2017 92:08

Panel: Charles Max Wood Dave Kimura David Richards Eric Berry In this episode, the Ruby Rogues panel discuss Rails, Development, and More with David Heinemeier Hansson. David is the creator of Ruby on Rails, the founder and CTO of Basecamp, and the hosts of The ReWork Podcast. David Answers a number of questions form the panel about the front-end on Rails, Turbo Link, Stimulus, How does this differ, cheaper labor, better hardware, and much more. This is a great episode to understand the background of Ruby on Rails, Basecamps, and things to come with Ruby. In particular, we dive pretty deep on: The new book The Com Company Where are we going with the front-end on Rails? Turbo Links Stimulus Redux Application Productivity Do you Stimulus providing enough? How does this differ from new things coming out? Ruby on Rails will not last… Toolkits Cheaper hardware Basecamp Higher cost of programmers The Frontier C in Java Why don’t you hire senior experience? Experience and career path Remote Work Paying developers enough Competitive pay Switching jobs and values What is your vision of where Active Storage is going? Cloud Storage Action Cable What are your thoughts on bitcoin? Train wrecks and it will end badly How about BlockChain and the web? What is your daily driver? Cars? Watches? Porche 911 Celebrating technological heritage What is in tech that you are liking? VR And much much more Links: http://david.heinemeierhansson.com https://twitter.com/internetofshit?lang=en The ReWork Podcast @dhh Picks: Dave Minio David co2meter.com Sensor Push The Meditations Eric Secret of Luck Post - Funding open source Charles Carrier Wave Git Lab

Ruby NoName Podcast S08E03

Ruby NoName podcast

Play Episode Listen Later Sep 29, 2016 59:18

В этом году мы записываем серию подкастов со спикерами конференции RailsClub 2016. 22 октября, Москва, подробности и регистрация на сайте конференции. В этот раз мы поговорили с Владимиром Дементьевым про Action Cable, обучение и open source. Ссылки Профиль Владимира на Github первый проект Владимира – Teachbase Универсальный RPC фреймворк Brainwashing – Курс по Ruby on Rails Rubocop Первый open-source коммит в pry-byebug InfluxDB - БД написанная на языке Go Influxer - InfluxDB ActiveRecord-style Telegraf - сборщик логов Thinknetica Расшифровка эпизода, опубликованная на Habrahabr Расскажи немножко о себе? В Ruby сообщество я пришел не так давно. Примерно 4 года назад я в первый раз попробовал рельсы, поигрался. Мне понравилось. но проект, на котором я тогда работал, их не использовал. Поэтому пришлось отложить до очередной реинкарнации проекта Teachbase, нашего стартапа. Teachbase - это SaaS система для организации управления обучением, она позволяет вам сделать собственную Coursera в рамках компании или проекта. Когда я пришел, это был страшный проект на PHP, а я тогда мало что умел. Кодил, что говорили. Потом я познакомился с рельсами и с того момента, как стал техническим директором, начал вынашивать идею написать новую классную версию системы на продвинутой технологии. Такая возможность представилась в 2014 году, и тогда мы полностью перешли на рельсовый стэк в части веб-приложения. С тех пор я начал активно этим заниматься. Как ты смог убедить заказчика перейти на Rails? Все очень просто - я сам себе заказчик. Я один из основателей этого стартапа, двое моих партнеров не имели достаточной технической экспертизы, поэтому доверяли мне. Надеюсь, они не ошиблись и не жалеют об этом :) Выбор технологий был за мной. Вопрос был только в том, чтобы найти время на переход с одной версии на другую. Ну и деньги, естественно. Когда момент настал, мы переписали все на рельсы, и вот эта третья (или четвертая) версия системы работала быстро, четко, все были довольны - как мы, так и клиенты. Она и сейчас работает? Да, она продолжает работать. Мы довели проект до очень хорошего состояния, когда делать новую версию имеет смысл уже не по технологическим причинам, а скорее идеологическим. Не знаю, какие у ребят планы на данный момент. Пока они занимаются поддержкой этой системы, продажей. Все идет неплохо, проект жив, работает. Teachbase довольно большой проект на рельсах. Причем это были рельсы 4.1, на 4.2 мы не стали переходить, хотя планировали. Год с небольшим назад было объявлено о выходе 5 рельс осенью 2015, в этот момент мы решили, что нет смысла переходить на 4.2, когда можно сразу перейти на 5. Все знают, что потом было :). Прошел еще год, пятые рельсы уже вышли, но сейчас переходить на них, наверное, еще опасно. Надо подождать хотя бы 5.0.1, а лучше 5.1, тогда можно будет переходить. Мы понадеялись на релиз-планы команды разработчиков рельс, они не оправдались, поэтому наш проект до сих пор висит на 4.1. И особых проблем с этим нет. То есть, с точки зрения технологий проект закончен, и вы делаете что-то новое когда понимаете, что это нужно бизнесу? Да. Есть планы переделать значительную часть логики, и это, скорее всего, будет новый проект на новых рельсах, а может и не рельсах. В нашем стеке всегда был Erlang, так как мы занимались видеоконференциями, соответственно, нужен был стриминговый сервис, который работал бы с протоколом RTMP. Он нужен, чтобы люди, используя технологию flash (которую все ненавидят), могли общаться в браузере, проводить вебинары на большое количество людей и так далее. Бэкендом для всего этого служил сервис на эрланге, который отпочковался от довольно известного проекта Erlyvideo. Вы взяли форк, который был еще в open source? Да, это был open source, версия примерно 2.18. Происходило это в 2011 году. Сначала мы его просто использовали, потом стали вскрывать баги и править их, адаптировать все под нашу историю. А потом Макс Лапшин закрыл код и начал разрабатывать платный Flussonic. Нам это, в принципе, не мешало. Так у нас появился опыт в Erlang, и мы начали делать некоторые другие второстепенные сервисы для системы на эрланге. Наш стэк обрел второй основной язык Но найти разработчика на эрланге не очень просто. Тот единственный эрлангист, который у нас был, пришел студентом, он знал С и отлично знал математику, у него было олимпиадное прошлое и он хотел работать. Как эрлангиста мы его воспитывали с нуля. Он, кстати, до сих пор работает в проекте. Но больше таких людей не появлялось, поэтому в начале этого года, когда я еще работал в Teachbase, мы начали программу знакомства с Elixir (как для тех, кто программировал на Ruby, так и для тех кто программировал на Erlang). Был отдельный подпроект, в котором было 2 разработчика: рубист и эрлангист. Они должны были осваивать технологию вместе, используя каждый свои сильные стороны. Один лучше знает Ruby и его парадигму, знает Rails, которые похожи с Phoenix в части MVC. А второй человек, который знает Erlang, делал на Elixir какие-то более близкие к этой парадигме вещи. Проект пока не доделан, но он очень интересный. Мы начали переходить на этот стек, скорее из-за его популярности, чтобы было проще в дальнейшем жить и нанимать новых сотрудников. А не хотели все перевести на Phoenix? Полностью отказаться от Ruby, оставить Erlang, поверх него Elixir, а сверху еще Phoenix? Когда стоял вопрос о переходе на Rails, был альтернативный вариант сразу переходить на Erlang. Я готов был это сделать. Наверное, мы бы дольше стартовали, но вероятно это было бы лучше с точки зрения эффективности. Хорошо, что мы этого не сделали: наши нагрузки не требуют каких-то жутких оптимизаций, и рельса вполне справляется, а скорость разработки дает намного большую. Сейчас я не думаю, что Phoenix можно полностью заменить рельсы именно с точки зрения построения бизнес-логики, слоя работы с данными. Все что касается запросов, сокеты (это отдельный разговор мы к нему вернемся) - с этим в Phoenix все неплохо. Но Active Record (или его альтернативы) и экосистема вокруг него пока гораздо удобнее, чем все, что есть в Elixir. Это логично, там другая парадигма, там не так просто сделать удобный для использования инструмент. Поэтому, на мой взгляд, Elixir и прочие, с Phoenix или без, - это скорее технологии для идеологии микросервисов. Нужно использовать их в какой-то тяжелой части, в которую стучится очень много клиентов, с какими-то задачами, запросами. Такие части можно писать Elixir, решать их несколькими разными сервисами. А основная логика должна, мне кажется, оставаться в рельсах, если изначально была написана на них. Но даже если бы я сейчас начинал проект с нуля, я бы все равно не стал делать все на Elixir. Ты говоришь о Teachbase и своей роли CTO в нем, как о прошедшей истории. Сейчас, насколько я знаю, ты работаешь в Evil Martians, работаешь просто разработчиком. Почему ты перешел от управления к разработке? Чаще наоборот, люди хотят пройти путь от разработчика до управленца. Считаешь ли ты это шагом назад, или это какой-то промежуточный этап? Во-первых, долгое время я был в Teachbase единственным разработчиком. Я начал набирать команду только в последнюю пару лет, когда у нас появилась такая возможность. Проблема для меня, как для разработчика, была в том, что я много всего попробовал, много нового узнал, но в основном на собственном опыте. Я никогда не работал в команде под руководством кого-то, кто был опытнее меня и имел какие-то знания, которых у меня не было. Это была одна из причин: мне было скучно, я понимал, что мой самостоятельный рост в Teachbase будет идти тяжело. Особенно, когда проект стабилизировался, не было каких-то супер интересных задач, только текучка типа добавления фич, нет воли творчеству. Я рассматривал марисан, в первую очередь, так как я был знаком с некоторыми ребятами, я был на курсе Brainwashing, с тех пор у меня остались самые приятные впечатления об этой команде. Мне очень хотелось поработать с такими людьми, поделиться опытом, поделиться своими идеями. Когда я работал в Teachbase, мне не с кем было обсудить какие-то технические идеи, не было людей, которые разбирались бы хорошо в технических аспектах. Поэтому я хотел попасть в сильную команду. То, что в Teachbase у меня была “власть”, а теперь я рядовой сотрудник, не страшно. Наверное. Хотя моя жена говорит, что после того, как я перестал руководить, я пытаюсь немножко чаще руководить дома. Компенсирую :) Мне нравится отсутствие вертикали, можно со всеми спокойно общаться, разговаривать, спорить, ругаться иногда. Мне нужно было попасть в среду, скажем так. Мы начали говорить про Rails и долгожданную 5 версию, в которой много всего появилось. Например, Action Cable, про который ты и будешь рассказывать на конференции. Чего еще тебе не хватает в Rails? Я бы поставил вопрос по-другому: что в рельсе лишнее, что мешает. Да, это хороший вопрос В прошлом подкасте мы говорили с Алексеем Тактаровым о том, стоит ли выкинуть фронтовую часть. А что бы ты выкинул? Фронтовая часть и сборка ассетов с помощью Sprockets, на мой взгляд, уже устаревшая схема. Фронт сейчас пишется со своими сборщиками, там своя очень развитая экосистема. Которая работает, по моему опыту, гораздо приятнее, чем Sprockets. Это быстро, удобно, куча дополнительных возможностей, тонкая настройка и так далее.. Тот же автопрефиксер вставить в Sprockets, конечно, можно. Но если вставить еще 20 аналогичных плагинов, то ассеты, скорей всего, будут собираться очень долго. Я использовал рельсу, по большей части, неклассическим образом, с серверным рендерингом, используя javascript шаблоны и подобные вещи для обновления странички. Я использовал Rails практически в API режиме, только JSON. HTML-странички отдавались также рельсами, но была идея избавиться и от этого, грузить статику отдельно, так как динамического рендеринга был минимум, например, : вставка логотипа налету. Все фишки типа шаблонов,Turbolinks, вот это все, должны быть отдельными примочками к рельсам. Если хочешь - добавляй. В свое время Sprockets был настоящим прорывом. Возможно, сейчас эта технология устарела, потому что фронт развивается какими-то сумасшедшими темпами. Потому что на тот момент во фронте был популярен только Grunt, ужасный и монструозный, на мой взгляд. Он долго меня отталкивал от использования всего этого, пока не появились более приятные глазу альтернативы. Если говорить про текущий момент: если бы я сейчас начинал новый проект и брал бы в качестве бэкенда рельсу, я бы, учитывая, что у нас в Rails 5 есть встроенный API режим, сразу бы делал так, чтобы отдельно один проект делали фронты, отдельно бэкенды. Это очень удобно и с точки зрения разработки. Незачем фронту поднимать сервер, копаться там. Пусть он делает фронтовую работу и не знает, что на сервере. Пусть просто работает по спецификации, которую дают бэкенды. Ты поднял интересную тему: если сейчас делать проект на рельсе. А если не на рельсе, то на чем бы ты делал? Все зависит от того, какой проект, конечно. Давай как пример возьмем Teachbase. API, взаимодействие по JSON. Выкидываем Action View, выкидываем что-то еще. Может стоит использовать альтернативы на Ruby, но не Rails? Или вообще другой язык? Хороший вопрос. Если вопрос стоит как “что-нибудь другое на Ruby” - то нет. Во первых, у меня нет особого опыта. Я пробовал микрофреймворки типа Cuba, Sinatra. Такие микро-микросервисы, просто экспериментировал и смотрел, что это и зачем. Большие альтернативы, типа Trailblazer или Hanami, я не пробовал, они меня, в принципе, не заинтересовали. Я пока не понял, зачем они мне. Да, я видел бенчмарки, там все классно, быстро. Но рельсы и руби выбираются не для того, чтобы было быстро, а для того, чтобы было удобно. Поэтому такой аргумент для меня не самый важный. Да, у Hanami есть один очень большой недостаток: его никто не использует. Вот! Сложно тягаться в Rails, на котором пишут все, с них многие начинают свой путь в Ruby. Реальные конкуренты рельсам сейчас не внутри Ruby, а Elixir и Phoenix, которые набирают обороты. На мой взгляд это происходит отчасти потому, что Elixir хорошо пиарят. Его научились продавать командам разработчиков, говорят что Elixir классный, у вас все будет быстро. Даже в России уже есть люди, которые используют гибридный стек - часть рельсы, часть эликсира, все хотят его попробовать. И главное все хотят продать разработку на Elixir заказчику. Как коммерческий проект Elixir - очень классная штука. Он проще Erlang, хотя лично я бы все равно предпочел Erlang. Да, будет немножко больно, местами будет больше кода, хотя и это можно оптимизировать. Если отвечать на вопрос “что, если не Rails”. Я бы выбрал Erlang, но только в том случае, если мне дали бы пару разработчиков и чуть больше времени. В основном, все упирается в наличие разработчиков: их мало. С Elixir тоже проблема: многие, кто начал изучать Elixir и что-то на нем сделали, сразу считают, что они знают Erlang. Это примерно та же история, как когда люди, потыкавшие в рельсы, потом говорят, что они знают Ruby. Скорее всего, рынок пострадает от этого. Найти хорошего разработчика на эрланге будет еще сложнее, потому что будет много левого мусора. Во фронте сейчас похожие проблемы: если люди, которые выучили Angular, но не понимают, что такое JavaScript. Теперь везде есть такая проблема. Мы начали говорить про альтернативы Ruby. У тебя большой опыт работы с Erlang, ты писал на PHP, насколько я знаю, ты еще пишешь на go. На каких еще языках ты что-то пробовал делать и что хотел бы попробовать? Давай говорить хронологически. В школы и университете были Pascal, C, Basic, Assembler. Но в университете я пропускал программирование, оно мне очень не нравилось. Я до сих пор удивляюсь, как я так случайно стал программистом. Начинал я с ActionScript. То есть Flash? Да. Я начинал со второго ActionScript, он был ужасен. А вот в третьем появилось очень много изменений: нормальные классы, прокси объекты, которые все так ждут сейчас в JavaScript (но пока там не очень хорошо с поддержкой). Много всего классного, удобного. Как язык он был прикольным. Со своими минусами в виде не очень простой компиляции, в которой, если у тебя не Flash Builder от Adobe, приходится много колдовать. У меня был очень большой проект в рамках Teachbase, когда мы начали делать свое решение для вебинаров. Оно состоит из двух частей: клиентской и серверной. В серверной был Erlang, а в клиентской - большое ActionScript приложение. Это был мой первый большой проект, я продумывал его с нуля, с серьезной архитектурой, там было много классных идей. Это приложение до сих пор работает. В нем нет багов, я последний раз его правил два года назад! С тех пор оно классно работает. И это очень хорошо, потому что я даже не знаю, как мне его теперь собрать, запустить и так далее, у меня нет никаких систем сборки, и я уже плохо помню, как там все устроено. Подожди, третий ActionScript вышел очень давно, он старый. Около 10 лет. Он вообще развивается? Да, он очень старый, но еще жив, на нем пишут. Особенно много используют в игровой индустрии, сделали очень много оптимизаций с точки зрения графики, рендеринга, использованием GPU и так далее. На нем можно писать классные игры. Кажется, какая-то из популярных онлайн игр, типа танков, была изначально на flash. Сейчас не знаю, может, до сих пор. Был период, когда эти технологии были во всем реалтайме, когда, например, нужно было сделать видеочат, когда не было и намека на другие технологии, flash был везде. Это сейчас он мало у кого стоит. На Flash раньше было реализовано то, что сейчас есть в Web RTC, peer-to-peer. Этот проект в итоге был заброшен. Изначально он назывался Stratus, мы даже делали на нем побочный проект - портал для психологов с возможностью консультации онлайн. Работало через раз. Сейчас те вебинары, которые существуют и работают просто в браузере, заявляют, что используют Web RTC, но в большинстве случаев это не так. Именно для стриминга по прежнему используется flash, rtmp. Там он еще жив. Я очень хорошо знал ActionScript, но сейчас не сказал бы, что я в нем эксперт. И не планирую им заниматься. А теперь вернемся к нашему вопросу: что было после ActionScript? Потом был php. Не помню, какая там была версия, с ним были разные замуты. А как ты познакомился с Rails? Все получилось случайно и просто. Есть такая замечательная площадка Coursera, когда она только появилась, там было где-то пять курсов, один из них был про SaaS разработку и так далее. Этот курс, фактически, был таким введением в Rails, тогда еще 3. Не сказать, чтобы я выучил рельсы по этому курсу. Это был очень простой курс, вывод одной страницы и поиск по элементам из базы. Но там было хорошо рассказано про тестирование, про все его уровни. После этого я написал какой-то микро-микросервис для нашей системы. Очень страшный, некрасивый, он даже был запущен через rails s в development режиме. Но он работал, практически не падал. Сложно сказать, в какой момент я начал изучать и что-то делать, переключаться. Сильным толчком был поход на Brainwashing. Когда я туда шел, я практически ничего не знал именно про Rails: что там, как там. А на курсе получил пинок, скажем так. Сел и начал разрабатывать. Можно сказать что Равиль и Газай оказали на тебя большое влияние? Да, они подкинули вдохновения в этом направлении. Если дальше говорить о языках, потом был Erlang. Сейчас я иногда использую Golang для разных вещей. Язык довольно простой, можно выбирать его, если надо что-то быстро набросать. Он компилируется в исполняемый файл и его можно использовать. Еще я очень много занимался фронтом, сейчас уже меньше. Не тянет во фронт? Перейти темную сторону. Хороший вопрос. Наверное, нет. Я так себе фронетенд, потому что я не очень силен во всем, что касается стилей, верстки и прочего. Особенно с новыми замутами: какие-то CSS модули, CSS 4, все меняется очень быстро, не успеваю за этим следить. Мне никогда это не нравилось, я всегда считал верстку работой для каких-то…как-бы без расизма обойтись…не буду говорить :) Это черновая работа. Практически всегда мы отдавали ее на аутсорс. Нам присылали верстку, мы ее интегрировали. Один раз я предложил не мучиться, и все сделать самостоятельно. Тогда я начал этим заниматься. Спасибо Андрею Ситнику, который рассказал всякие интересные штуки и показал как делать не надо, дал некоторый вектор. И я начал делать много фронта, в итоге у нас в Teachbase основная логика на клиенте - это написанный мною фреймворк. Мы начинали еще до того, как React стал популярен, Angular еще не был особо популярен, но уже существовал. Я решил, что мне быстрее написать самому, я понимал как работает JavaScript, и не хотел тратить время на то, чтобы разбираться как работает Angular. Я ни разу не жалею об этом, потому что Angular работал в первой версии ужасно, на мой взгляд слишком неочевидно. Хотя кому-то это может казаться понятным. Во второй версии может быть что-нибудь поменялось. У меня был свой велосипед, он до сих пор работает, ребята его используют. В свободное от работы врем я пытался написать его новую версию на es6, но свободного времени оказалось не так много. Поэтому на гитхабе висит две недоделанных версии моего фреймворка :) Там прикольные идеи, но учитывая, что я тратил на это один день в месяц, они сильно отстают от тенденций, которые сейчас есть во фронте. Мы начали тему своих велосипедов. Как ты участвуешь в open source? Есть ли проекты, на которые ты хотел бы, чтобы ребята обратили внимание? Классный проект, но его никто не замечает. Свои проекты или чужие - не важно. Снова прорекламирую Brainwashing :) Open source для меня начался там, я сделал свой первый коммит в OS. В рамках курса ребята наткнулись на баг в pry-byebug, который был в экстеншене на C. Я его нашел, пофиксил, отправил и получил свой первый pull request, получил от этого удовольствие и немного подсел :) Начал этим заниматься. Если говорить про чужие проекты: я очень много работал над Rubocop, это проект Божидара Батсова. Мне очень нравится этот проект и в целом идея, что код должен быть стилизован. Я это везде пропагандирую, где есть возможность. Но ты же не используешь дефолтный конфиг rubocop? Конечно, я всегда там что-то правлю, что-то отключаю, что-то включаю. А меняются настройки из проекта в проект? У тебя есть сложившиеся настройки, которые ты всегда используешь или считаешь, что каждый раз нужно договариваться с другими разработчиками в проекте? По-разному. Сейчас я, например, пришел в проект с большой кодовой базой и мы прикрутили обязательную проверку rubocop’ом, но там у нас очень минимальный конфиг, который проверяет на очень плохие вещи, типа забытого дебага в коде или фокусы в спеках и так далее. И еще у нас включено несколько оптимизационных копов. Вещи типа длины строки, количества строк в методе и так далее мы в этом проекте не проверяем. А ты приверженец истории про 80 символов, 120 или просто отключаешь эту проверку? Я поддерживаю эту тему, обычно я ставлю 100. Это число получилось опытным путем: я долгое время работал на 21-дюймовом iMac и разрабатывал со сплитскрином. Я делал так, чтобы в обеих частях экрана входили все строчки. Это как раз примерно 100 символов. Логика выбора длины строки была такая, потому что горизонтальный скролл это очень неудобно. Про длину методов или длину класса… нет. Комментарий в начале строки, enter в конце Пустую строку в конце я всегда ставлю. Делаю это, потому что так удобно перейти в конец файла. Есть некоторый отступ снизу, тебе не надо попадать в границу дисплея. Я где-то читал, какими историческими ограничениями это правило было вызвано, в каких-то старых системах. Точно уже не воспроизведу, что там было. И сейчас гитхаб постоянно это подсвечивает в диффах, ругается когда у тебя нет пустой строки - это не очень приятно. В моем дефолтном конфиге на нулевом проекте многое включено, но эти параметры сложности немного увеличены. Если где-то очень большая сложность, и я не хочу рефакторить какой-то метод осознанно, то я просто отключаю этот коп локально, да и все. Но во всех гемах, которыми я занимаюсь, или в которые я активно контрибьютил, внедрял это дело. Про rubocop понятно. На какие еще проекты стоит обратить внимание? В каких ты принимал участие? Я много работал над проектами из экосистемы InfluxDB. Это база данных для хранения временных рядов. Интересный проект, сейчас он вырос в InfluxData, у них свой стек, это что-то похожее на стек от Elasticsearch, где у тебя есть сборщик логов, визуализатор, сама база, но он заточен не на логи, а на какие-то временные метрики. Я начал его использовать в Teachbase, он тогда был не очень известен, это было примерно полтора года назад. Их история очень похожа на историю с Rails 5: была версия 0.8, они обещали через месяц выпустить следующую, более стабильную и с багфиксами, с кластеризацией и так далее. Я даже с ними списывался, мне отвечали что работа идет, версия скоро будет. Было довольно рискованно использовать не очень production ready историю, пару раз все очень страшно падало. Но в итоге, обещанная версия вышла, как и Rails, только в начале этого года. Мы прожили год на нестабильной версии, пришлось все-таки с ней работать. Один из моих больших open source проектов, как раз известен тем, кто работает с этой базой. Я написал адаптер для работы с этой базой в стиле Active Record. Проект называется Influxer. Он очень похож на ActiveRecord: определяется некоторый класс, говоришь какие у него есть атрибуты (это атрибуты этих меток в базе), и он позволяет делать запросы, такой синтаксический сахар. InfluxDB поддерживает SQL-подобный язык, и вместо того, чтобы писать на нем можно использовать вот такую обертку. Это удобно, там есть некоторые фишечки, связи с моделями и так далее. Он активно использовался в Teachbase, для этого он и делался. Я и сейчас продолжаю его поддерживать, в связи с выходом новых версий базы и изменением API, там все более или менее актуально. Проект кто-то использует, есть несколько десятков звездочек. Помимо Influxer я занимался другими проектами для этой экосистемы. До какого-то момента весь код был открыт, сама база и все второстепенные сервисы, которые там использовались. В этом году они ввели коммерческий вариант. Часть кода, естественно, уже не в open source, особенно то, что касается кластеризации. Все остальное открыто, и разработчики рады, когда туда приходят люди и контрибьютят. Там все написано на go, и мой первый опыт с go получился именно там. Я делал пару патчей в проект, который называется Telegraf : это сборщик логов, что-то типа Logstash или новых beats от Elasticsearch. Проект очень активно развивается, до стабильной версии далеко. Если вы хотите попробовать go и поучаствовать в open source, знайте, что там довольно просто сделать pull request. Расскажи еще про Thinknetica. Ты там играешь роль наставника, что это значит? Какой опыт ты оттуда вынес? Сколько обучил человек? Да, слово наставник мне нравится больше. Раньше мы называли друг друга менторы, но это как-то не по-русски. Я работаю там 1,5 года, но с перерывами. Мы берем группу, занимаемся, потом делаем перерыв и так далее. Я обучил человек 50, может чуть больше. Из них процентов 20 очень классные ребята, которые хорошо трудоустроились после курса. Много кто из выпускников устраивается потом на профильные вакансии, но я не сильно слежу за этим. Когда обучаешь довольно простым вещам (мы не учим чему-то сложному), это расширяет кругозор, не дает глазам замылиться. Ты видишь разный код очень разных людей. Ты видишь разные ошибки, прежде всего. Некоторые ты встречаешь первый раз в жизни, то как люди пишут, странные баги. Очень много интересной информации для мозга. Не даешь себе засохнуть. Нравится ли тебе быть наставником? Когда ученики хорошие - нравится, когда плохие - нет. Я очень нервный человек, мне хочется всех послать. В этом плане я скорее тренер, чем учитель, я довольно жесткий. При этом мне нравится общаться с теми, в ком я вижу интерес. Не обязательно должно получаться, но когда ребята стараются, это очень классно, с ними можно поговорить, мы периодически встречаемся лично. Они задают интересные вопросы, которые меня самого заставляют подумать. В целом, любой вид преподавания, особенно если ты преподаешь что-то связанное с твоей профессиональной деятельностью, - это бОльшая прокачка для того кто преподает, чем для тех, кто учится. Помимо знаний, которые получаешь по Ruby, про то как общаться с людьми, можно оттачивать свое ораторское искусство, общение с публикой по ту сторону кабеля, когда проводишь вебинары. Плюсов в этой деятельности много, минусы тоже есть. Есть рутина, когда ты третий раз ведешь один и тот же курс, тебе не так интересно. Ждешь, когда ученики уже дойдут до интересных тем, чтобы с ними было о чем поговорить, а то все какую-то фигню делают :). Вот и мы дошли до интересной темы :) Лейтмотив нашего интервью - RailsClub, ты там будешь рассказывать про Action Cable. В основном, все ему рады. Есть недостатки, не все еще клево, он подтекает; бывает, что два треда пишут в один канал. Но в целом, все очень довольны. И только от тебя я слышу скепсис. Расскажи о чем будешь докладывать? Не хочется спойлерить, но я чувствую, что у тебя на эту тему есть боль. Поделишься? Давай вернемся в весну 2015. За некоторое время до того, как состоялась конференция, на которой DHH объявил об этой замечательной фиче. Это для тебя действительно замечательная фича или такая “замечательная фича”, в кавычках? У меня к ней двойственное отношение. В чем-то замечательная, в чем-то “замечательная”. В любом случае, это громкая фича. В Teachbase вебсокеты использовались. Естественно, они были поддержаны эрлангом, потому что это был наш стек. У нас были планы по тесной интеграции сервиса, который обрабатывал данные с веб сокетов, с рельсой. Готовые решения, которые были в рельсе, мы не рассматривали, потому что людям, у которых есть вебсокет сервис написанный на эрланге, зачем-то пихать вебсокеты на Ruby было бы странно. Это как дать дворнику игрушечный совок. У нас была собственная идея (она реализована, выложена в open source и работает), как подружить рельсы с сокетами. И вот, в марте или апреле выходит Action Cable. Я посмотрел видео, посмотрел примеры, которые были. Первое впечатление было: “Вау, ничего себе! Это круто, это выглядит очень классно, удобно, красиво - прямо то, что я бы хотел использовать”. Это был дополнительный аргумент, чтобы не мигрировать на 4.2, а ждать Rails 5, чтобы в новой сделать что-то, используя кабель, сделать все классно. Хорошее впечатление от Action Cable относилось в первую очередь к каналам, к тому, что сделано непосредственно в Rails, обертке бизнес-логики. Мне очень понравилось, как все сделано: очень rails way, все как надо. Но была и вторая мысль - а на чем это будет? Это мысль пришла мне в голову, когда репозиторий самого кабеля в исходниках отдельно выложили на гитхаб. Тогда это работало на Celluloid, если я правильно помню. То есть это было реализовано на Ruby, что, конечно, не круто. У меня предвзятое, но распространенное мнение, что писать конкурентные программы на Ruby не нужно. Это не то, для чего этот язык был создан, особенно если говорить о масштабируемости и эффективности с точки зрения потребления ресурсов. Тогда у меня возникла идея подумать над тем, как же нам взять хорошее от Action Cable и хорошее от того, что на тот момент уже было реализовано в сервисе на Erlang. А там было уже много всего: горизонтальная масштабируемость, различные авторизации и так далее. Тогда я еще не знал про Phoenix. Как потом выяснилось, это было очень похоже на то, с чего начинался Phoenix. Но только сделано на живом Erlang. Хотя по факту под капотом все мы используем один и тот же Cowboy как эрланговский веб сервер. За год в кабеле произошло, конечно, очень много изменений. Все они, пожалуй, положительные. Во-первых избавились от Celluloid в пользу nio4r (который тем не менее и к Celluloid имеет отношение).Добавили очень много различных возможностей синхронизации, адаптеры и прочее.Но основные проблемы уходить не спешат. Буквально недавно был нашумевший баг с утекающей памятью, незакрывающимися соединениями. Довольно странно, что он возник уже после релиза 5.0. Еще висит несколько багов, связанных с производительностью. Все это говорит о том, что Action Cable сейчас не подходит для продакшена в какую-то большую систему, не блог с посещаемостью 100 человек, а реально большую систему с нагрузкой в тысячи и сотни тысяч людей. Это не тот инструмент, который может решить задачу. Тогда возникает вопрос, а какие вообще проблемы может решать Action Cable? Все мы знаем, что все нововведения в Rails появляются ради одного всем известного проекта на букву B. Я проверил, там действительно используется Action Cable, насколько это возможно определить, просто посмотрев логи браузера. Там используется там не тот Action Cable, который сейчас предлагается в рельсе, а, видимо, какая-то его предыдущая версия. А может это вообще не Action Cable? Может быть. По крайней мере, протокол веб сокетов подписан как ActionCable, но в какой сервер он стучится - мы не знаем. Протокол очень похож. К сожалению, инсайдерской информации оттуда нет. Но я не удивлюсь, если на самом деле там работает какой-нибудь сервер, который просто работает по тому же протоколу, может быть общается с рельсой, хотя на самом деле для того, что они делают, это и не нужно делают они буквально два сценария: отправить изменения, которые произошли на странице (кто-то написал комментарий, отправил тудушечку и так далее). Это бродкаст, первый сценарий. И сценарий, который, наоборот, от клиента отправляет информацию серверу о том, что человек делает на страничке. Она передается в несколько зашифрованном виде, но там примерно следующее: перешел на страничку или закрыл вкладку, трекинг активности некоторый. То есть, у них это все используется не очень нагружено? Да. И в этом случае Action Cable хватает. С одной стороны. А с другой стороны возникает вопрос: а зачем тут рельса? Я вижу единственный момент, который точно там используется, это аутентификация. Нам нужно как-то подтвердить право человека подключиться к сокету, подписаться на конкретный канал и так далее. Вот тут они наверное взаимодействуют с приложением. Но не факт, может быть и нет. Все остальное имеет малое отношение к бизнес логике. Я делал нечто подобное, у меня как раз веб сокеты использовались для трекинга активности. Все эти данные не писались в основное приложение, они там вообще не нужны, по крайней мере в сыром виде. Они писались в отдельную систему, там уже обрабатывались и потом вытягивались, когда нужно. В данном контексте не очень понятно: нужен там Action Cable или нет? Используется он или нет? Но раз это квакает как Action Cable, давайте допустим, что это он. Больше я не знаю реальных примеров. И я думаю, пока нет известных проектов, которые используют Action Cable. Наверное, многие хотят его использовать, но вопрос в объемах. Он очень хорош в том, в чем хороши все рельсы - быстро собрать MVP, показать кому-то первую версию проекта. Тебе не нужно ничего тащить, все есть в коробке, набросал realtime и работает. Но когда ты начинаешь это дело развивать, и появляются клиенты, нагрузка и так далее - что делать с Action Cable? Можно, в принципе, плодить инстансы, он выносится отдельно, как какой-нибудь фоновый Sidekiq и прочие побочные сервисы, которые есть у нас в приложении. Но насколько это эффективно - не знаю, пока у меня есть на этот счет большие сомнения. На твой доклад я очень хочу сходить. По моим ожиданиям это будет один из самых клевых докладов. Какие у тебя ожидания от RailsClub’а? Я первый раз ходил на конференцию в прошлом году. Чего-то о прямо очень зацепившего не было. Но были хорошие докладчики, например Claudio Baccigalupo, который говорил про Rails 5. Доклад Koichi Sasada про garbage collector, историю с поколениями, был очень сильный и интересный. Я понимал, наверное, процентов 70, но это было очень круто. Но я думаю, что любая конференция ценна не столько докладами, а тем, что происходит в кулуарах. Поэтому такого общения я и жду, учитывая что у нас приезжают “звезды”. Не знаю, насколько они будут готовы выйти в народ пообщаться, но это интересно. То есть ты бы задал пару вопросов Матцу? Честно говоря, у меня к нему нет вопросов :) Я бы послушал, что он будет отвечать на вопросы других, обычно я делаю так, редко сам спрашиваю. На прошлой конференции я общался с тобой, после доклада о микросервисах (Андреем Дерябиным, ведущим подкаста). И немного общался с Клаудио. Еще на прошлом RailsClub я узнал про Crystal, это довольно интересно, я теперь слежу за этим проектом. Подумываю над тем, чтобы как-нибудь где-нибудь его применить, написать на нем какой-нибудь экстеншен для Ruby, благо есть такая возможность. Какое-нибудь узкое место, может быть даже в проекте, над которым я сейчас работаю. Жду, когда выдастся свободный денек, чтобы разобраться и поиграть с этим делом. Про RailsClub этого года пока не опубликована информация о докладах, есть только люди. Посмотрим, что нас ждет. Мы выражаем огромную благодарность Лене Могильниковой за помощь с организацией этого выпуска.

mvp os cuba flash basic saas cto cowboy react frank sinatra api pascal github javascript noname html rails trailblazer css gpu imac php elixir sql brainwashing coursera angular grunt json ruby on rails mvc elasticsearch sprockets celluloid rpc dhh golang erlang stratus hanami webrtc assembler influxdb actionscript influxdata activerecord sidekiq telegraf evil martians elixir phoenix action cable

#052 D大神亲自演示 Rails 5: Action Cable demo

RailsCasts China

Play Episode Listen Later Dec 21, 2015 22:12

DHH 亲自演示, 如何在 Rails 5 中使用 Action Cable 方便的进行前后端实时交互.

demo rails dhh action cable

98: Superhumans Wanted (Naoya Ito)

Rebuild

Play Episode Listen Later Jun 28, 2015 69:30

Naoya Ito さんをゲストに迎えて、Docker, RunC, Elixir, Erlang, プロダクトマネージャーなどについて話しました。 Show Notes 一度死んだ話 Rebuild: 83: Living In A Container (deeeet) App Container and the Open Container Project Open Container Project opencontainers/runc DockerCon 2015 Keynote Videos | Docker Blog Elixir Elixir - The next big language for the web Jose Valim，Rubyにおける並行プログラミングのためのいくつかのアイデアを提案 Phoenix The Changelog #147: Elixir and Phoenix with Chris McCord Rails 5 Action Cable Concurrency in Erlang & Scala: The Actor Model The WhatsApp Architecture Facebook Bought For $19 Billion Crystal 世界で闘うプロダクトマネジャーになるための本 Cracking the PM Interview Webディレクター - Webクリエイター用語集 A Product Manager’s Musings Making It Right: Product Management For A Startup World VP Of Product Michael Sippey Is Leaving Twitter What is a Chief Product Officer?

wanted bc e3 rebuild musings cracking product managers chief product officer rails superhuman elixir docker erlang changelog concurrency web web naoya dockercon runc chris mccord action cable app container

14: An Acceptable Level of Hassle (David Heinemeier Hansson)

Play Episode Listen Later May 12, 2015 54:31

This week, we're joined by DHH and discuss microservices, monoliths, shared abstractions, and the fate of Action Cable. DHH's Keynote Microservices Sacrificial Architecture Scaling Mercurial at Facebook has_secure_password BCrypt Request Forgery Protection error_messages_for removed in Rails 3 Sandi Metz on the cost of the wrong abstraction WebSockets Event Machine Faye Basecamp

keynote acceptable rails basecamp hassle microservices david heinemeier hansson dhh websockets sandi metz bcrypt action cable

13: Begrudging Applause (Aaron Patterson)