Podcasts about rails api

[00:01:51] Jason and Chris discuss the launching of Hatchbox v2. [00:05:54] Benedikt tells us about himself and what he does.[00:06:55] We learn when Benedikt started using Ember, how long he's been building Userlist, and if he had experience working in Rails API mode with Ember.[00:09:54] Benedikt explains what the process of scaffolding looks like and if ever has to manage and make things happen in sync when he makes a change that affects both sides.[00:11:18] Jason explains what Ember does and we find out if it's in that same vein as React, Vue, and Angular.[00:14:28] We hear what the process is like keeping up to date with things like new Ember releases and new Rails releases.[00:16:40] Benedikt tells us how many developers he has at Userlist, if he's doing more of the Rails side of things, and what it's been like going from a technical Co-founder and the only one developing the application and bringing someone else in to work with it.[00:18:27] Since Benedikt launched Userlist in 2019, he tells us some challenges he faces with building and growing it, as well as any challenges with technical stuff he wanted to build but couldn't to focus on marketing and getting new customers.[00:21:10] Chris asks Benedikt if he picked up an editor that was pre-made, like an Ember plug-in, just to use the first version. He tells us some challenges he ran into as he was building it. [00:24:02] We find out some multiple solutions Benedikt and his team came up with when they tried to update one column in a database that stopped everything. [00:25:30] Jason wonders if Benedikt is doing databases at Heroku or if he's explored another database host.[00:26:46] We hear some other database performance things Benedikt's had to implement solutions for.[00:28:03] Chris wonders how comfortable Benedikt was with SQL before he started, if he had to learn a whole bunch of things on the fly, realizing it may be a challenge, and he explains how he's implementing things with a lot of Arel.[00:30:06] Benedikt talks about what his day looks like for him, how he balances his week to do everything as a Co-Founder, and if he gets to code a decent amount.[00:32:57] Andrew heard Benedikt is really good at Postgres Performance and he wonders if there's any tips he can share for starting out. He tells us about his greatest tool which is pgMustard.[00:35:21] Find out where you can follow Benedikt and Userlist online.Panelists:Jason CharnesChris OliverAndrew MasonGuest:Benedikt DeickeSponsor:HoneybadgerLinks:Jason Charnes TwitterChris Oliver TwitterAndrew Mason TwitterBenedikt Deicke TwitterBenedikt Deicke WebsiteUserlistSlow & Steady PodcastEmber.jsHatchboxpgMustardRuby Radar NewsletterRuby Radar TwitterRuby for All Podcast

Jason announces DHH is back on Twitter, but not back in the Unites States! So, where is he? The guys wonder when the next versions of Turbolinks and Stimulus will be released. Some other topics discussed on this episode are Rails API guides being updated, Webpacker documentation, importing Sprockets files into webpack, problems with webpack configs, CoffeeScript, problems with UJS and Rails Scaffolds, Turbolinks Render library, Cloudflare, and generating routes in madmin. Also, have you heard of security.txt? You can learn more about it here.

Sponsors Sentry use code “devchat” for $100 credit Datadog Panel David Kumira Nate Hopkins Andrew Mason Episode Summary Today the panel is talking about documentation. They begin by discussing what documentation is, where it fits within an application, and if the code documents itself. They agree that documentation starts in the comments to explain what you’re doing, but if that’s your exclusive method, then a refactor is in order. They talk about where to start with documentation and different ways they’ve done it.  The panel talks about the importance of documentation, especially for people just joining a team. In addition to documenting the project itself, it is important to document what different libraries do and how to interact with them. They discuss where to put this kind of documentation. They talk about documenting patterns, best practices, and procedures in addition to the ‘how to’ of a project. The conversation turns to style guidelines, what they are, and how to keep them up to date. They talk about what tools are available to generate documentation that are close to the code but outside of it that can help keep documentation up to date. The panel believes that there is a relationship between the size of your team and the necessity to document. Nate introduces the idea found in the article by Tom Preston-Werner that you should think about what you’re going to create in the code, and document it first.   Links RDoc YARD  RuboCop YAML Slim ERB Prettier Pronto Api.rubyonrails.org Swagger Thoughtbot and Thoughtbot Playbook AirBNB Ruby Testdouble HoundCI Okonet API Blueprint Ruby on Rails API documentation guidelines Tom Preston-Werner article Readme Driven Development Follow DevChat on Facebook and Twitter Picks Nate Hopkins: Code Fund Andrew Mason: SpaceVIM RailsDiff Rails Releases David Kimura: Jackery Supercharger Portable

Sponsors Sentry use code “devchat” for $100 credit Datadog Panel David Kumira Nate Hopkins Andrew Mason Episode Summary Today the panel is talking about documentation. They begin by discussing what documentation is, where it fits within an application, and if the code documents itself. They agree that documentation starts in the comments to explain what you’re doing, but if that’s your exclusive method, then a refactor is in order. They talk about where to start with documentation and different ways they’ve done it.  The panel talks about the importance of documentation, especially for people just joining a team. In addition to documenting the project itself, it is important to document what different libraries do and how to interact with them. They discuss where to put this kind of documentation. They talk about documenting patterns, best practices, and procedures in addition to the ‘how to’ of a project. The conversation turns to style guidelines, what they are, and how to keep them up to date. They talk about what tools are available to generate documentation that are close to the code but outside of it that can help keep documentation up to date. The panel believes that there is a relationship between the size of your team and the necessity to document. Nate introduces the idea found in the article by Tom Preston-Werner that you should think about what you’re going to create in the code, and document it first.   Links RDoc YARD  RuboCop YAML Slim ERB Prettier Pronto Api.rubyonrails.org Swagger Thoughtbot and Thoughtbot Playbook AirBNB Ruby Testdouble HoundCI Okonet API Blueprint Ruby on Rails API documentation guidelines Tom Preston-Werner article Readme Driven Development Follow DevChat on Facebook and Twitter Picks Nate Hopkins: Code Fund Andrew Mason: SpaceVIM RailsDiff Rails Releases David Kimura: Jackery Supercharger Portable

In this episode of The Frontside Podcast, panelists Charles Lowell, Rob DeLuca, and Sam Keathley, discuss how much the distinction between frontend, backend, and fullstack developers matter in both personal and professional senses. The differences in mindset between these categories are also discussed, for example, how does a fullstack developer solve a problem vs how a backend or frontend developer? And also, how clear (or fuzzy) is the line that separates them? What are the skills a frontend or backend developer needs to consider themselves fully fullstack? And finally, is there any sort of tribal separation between the factions? Do you have opinions on this show? Want to hear about a specific topic in the future? Reach out to us at contact@frontside.io or on Twitter at @thefrontside. This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. TRANSCRIPT CHARLES: Hello everybody and welcome to The Frontside Podcast Episode 101. My name is Charles Lowell. I'm a developer here at The Frontside and I'll be hosting today's episode. Today we're going to be talking about the different developer profiles that are out there. You might have heard mention of them on Stack Overflow, on job boards, on the Twitterverse. Things like frontend, backend, full stack, half stack, short stack. [Chuckles] Things like that. With me to talk about these are Rob and Sam. Rob is our director of open source here at Frontside and Sam is a software engineer here at Frontside. So, hey y'all. SAM: Hey. ROB: Hey yo. CHARLES: Alright. So, before we get into the meat of the topic, there are a few announcements that we wanted to make. First and foremost, this is some really exciting news. This week, Taras Mankovski officially joined the team at The Frontside. And we are really, really excited about that. [Cheers] ROB: That's exciting. CHARLES: Yeah. It's super exciting. Not only is Taras an exceptional engineer, he's got amazing code skills. He's extremely empathetic and a great person to work with. He's great working with clients and he's also fantastic at really working with developers who are climbing that ladder and helping them level up. So, he's been involved in mentorship literally since I've known him. I think that was the first time that we ever came into contact with him was through his mentorship work in the Ember community. And we've been collaborating with him for years on several open source projects. And so, we just are so excited and know that he's going to come on and do some amazing things by helping us be better developers, helping us be better community emissaries. And so, lots of good stuff coming out of that. ROB: Absolutely. CHARLES: Yeah, yeah. No, that's really exciting. So, definitely wanted to throw that out there. ROB: Too bad he didn't join a little bit earlier. We would have had a good time with him on this podcast. CHARLES: I know. Well he's actually, I think he's been on the podcast twice. ROB: [Laughs] That's true. CHARLES: But yeah, there's definitely a couple of topics where his input would have been absolutely critical. I think it would have been great to have him along when we were trying to run our own apprenticeship programs. Those would have worked out I think a lot better. Well, not to say that the outcomes haven't been stellar in some cases. But I think having his expertise would have made it a lot smoother. That said, before we jump in then, just wanted to let everyone know that as always, if you want to work with us you can get to us at contact@frontside.io or send a shout-out on Twitter @TheFrontside. Okay. Y'all, let's jump into it. Like what is even a stack? ROB: [Laughs] So, do you want to kind of set up where this came from, Charles? I think it came from you and I going back and forth on Twitter. And I was like, “You know what? We need to talk about this on the podcast.” CHARLES: Yeah. I think I was actually on vacation. ROB: [Laughs] That's right. You were trying to ski. CHARLES: [Laughs] I was on the ski lift. And I saw you tweeting and I was like, “No, no, no. I got to respond to that.” Probably because there was maybe a little bit of disagreement but also because I just needed something to do. Looking out the majestic scenery of the Rocky Mountains wasn't enough. So yeah, what's the backstory there? ROB: So, I can't remember what I was actually tweeting about. But I kind of feel like there is a distinction between a frontend developer, a backend developer, and at this point I don't know if a full stack developer truly exists. I mean, it does. But it's used more often than it really implies what they're doing. Usually when you hear of a full stack developer, it's like, “Man, I can sling some code on the backend and I can do a little bit of architecture stuff on the frontend. But CSS, keep that away from me.” And in my opinion, if you're a full stack developer, you need to sling CSS, too. CHARLES: Really? ROB: Yeah. CHARLES: No, no. I certainly agree. Because I was going to ask, is it fair to say that full stack developer is code for like, startup developer? ROB: Yeah. That's a good – like a utilitarian, like a jack of all trades but not a master of any? CHARLES: Right, exactly. ROB: I can take that. So, I guess the way we can start to dig into this one is like, how much distinction is there between a frontend, a backend, and a full stack developer? And does that matter in a professional sense? CHARLES: Right. And so, I think my take was that the skillsets that you need in both places are actually much more convergent than you think, than people might think. In other words, the skills that you utilize on the backend actually translate very well to the frontend. I think my stance is that what makes a frontend developer and a backend developer is more the problem sets that you gravitate towards naturally, the things that interest you. I actually was a backend developer. And now I consider myself to be primarily a frontend developer. But the skills that I had developed writing backend systems in Java translated shockingly well into frontend development with JavaScript. But it was working on the portion of the program that interfaced with the human was, that was the thing that fascinated me. And so, it's what I gravitated towards. And so, I guess in my [6:15 inaudible] or the way that I have been thinking about it is that what makes a frontend developer and a backend developer is more what gravitational pulls you respond to, rather than one particular skillset. But I know that you've got a perhaps more refined take on that, or a different take. ROB: Yeah. Before I do, I want to know what Sam's thoughts are on this. This would be a good one. SAM: Where I come from in the understanding of frontend, backend, and full stack is I – background on me: I did a bootcamp before working here. So, I did a development bootcamp where they were really excited to tell you at the end of it that, “Oh, you're a full stack developer because we've introduced you to everything. Like, touched on every sort of little topic. You're full stack. Tell everyone you're full stack.” And it's like, “Well, you're not really a specialist in any of the sense.” So, what makes a difference to me, I'm going to specifically talk about full stack, but it's like before you can say you're full stack, having knowledge of frontend and at backend, you need to have expertise in at least one of them first, or understanding of that mindset first. Like if I say that I like frontend work more then I need to understand frontend work more before I can say that I understand backend work, you know? ROB: Yeah. CHARLES: So, do you feel like the bootcamp was doing you a disservice? Or do you think they got… SAM: I don't think they did a disservice at all. So, they did a really good job. So, bootcamps are really for introducing you to everything. And then whatever you take from that is your own. So, they introduce you to all the little things like database working and then JavaScript, Ruby, whatever it is. And then it's your job to figure out in those introductions, what you resonate most with. So, I think they did a really good job in that. I think that they shouldn't tell you what you are, like tell you that because they touched on whatever it was, that you're full stack. CHARLES: Right. SAM: So, I don't think they did a disservice at all. I learned a lot. But I wouldn't say I'm full stack at all. CHARLES: So, if you feel as though you're not full stack, what do you feel that you are? SAM: Definitely frontend. CHARLES: Definitely frontend. SAM: I gravitate more towards frontend. ROB: Why would you feel that way? Is it because you're more pulled towards the UI of things? Or is that where you feel like you've gotten most of your experience now? SAM: Actually a little bit of both. I tend to like the UI of things a little bit more. It's interesting. Whenever I was going to the bootcamp, I thought I was going to be more backend because I thought I really like working with the behind the scenes sort of. You don't see this work but you know it's there. But I definitely like the UI of frontend a lot more. Just personal. ROB: I see that. SAM: And it's where my skillset is, because this is all frontend work that I'm doing here at The Frontside. So, it's what I know most at this point. CHARLES: Yeah. I'm curious too. Isn't it true that there's also a conception in the wider tech world that frontend is limited to CSS and HTML? ROB: Ooh. Yeah, that could be. CHARLES: Like when you see job posting for frontend developers, typically it's like, we want someone… ROB: Yeah. It's kind of morphed from – JavaScript developer is now a single-page app developer instead of frontend. Yeah. Yeah, I see what you're saying. It's now, it could be considered as HTML and CSS and not JavaScript anymore. [Chuckles] CHARLES: Which is so bizarre to me. SAM: [9:42 inaudible] a lot of places when a frontend developer who is also a UX designer. Someone who has the knowledge of designing things from the ground up and then only working in things that look good, rather than logic. ROB: Yeah. This can be probably an entirely other topic. But that's like the frontend of the frontend and the backend of the frontend, is like [10:03 inaudible] call it. Because there are [10:06 inaudible] developers. And single-page apps have gotten so complex these days, between your data layer and your testing and managing state on the frontend. There is a backend, an architecture, that you need to consider when you're developing a single-page app. And I've worked on teams where there are developers that are working on the frontend but they still don't like CSS. They don't do CSS things and they don't consider layout or any design. They just take the ticket and they get the data going. Get the data from the server, request it, display it on the page. And then another person would come through and style it up to the spec or the mock. But yeah, that's interesting. So for my take on this, and where this actually really came from, is we were going through some hiring. And we were trying to figure out how we can place somebody or hire someone that can be effective in the role that we immediately needed. And all of our immediate needs were in frontend-specific things. And we can actually talk about if they're frontend-frontend or frontend of the backend. But where this kind of came from or was born was: if we're hiring somebody that needs to fill a frontend role and they're primarily a backend developer, there are gotchas and things you have to know to be an effective frontend developer. Like quirky browser things that happen or like how to set up a Babel transpilation setup. And what are the gotchas here? Kind of the history of the frontend web, because there's a lot of things that are there that can cause a lot of headache if you don't know the backstory. And I know from your perspective Charles, you think – and this is isn't wrong – but you think that if somebody has a really talented backend developer, it's really just concepts that you can apply to the frontend. And I agree with that. CHARLES: Right. But you have to want to do it. [Laughs] ROB: Yes. That is also a key. CHARLES: You have to be gripped by the problem set of the frontend. You want it to inspire you to leverage those solutions. ROB: Yeah. So, would you say there's a different mindset between a frontend, backend developer, and full stack? Does a full stack developer solve a problem that's different from how a backend developer or a frontend developer would? CHARLES: That's a subtle question and probably one that might offend people, my answer to it. So, I'll go ahead and answer it. [Chuckles] ROB: Hashtag [12:23 inaudible] CHARLES: Actually, maybe not. Just in my experience historically – I want to underline the fact historically – I think that it is people who gravitate towards the outside-in mindset, in other words the very first thing they're thinking of is, “How is this going to feel to a person who's going to use this?” If that's your first question that you ask, then you probably are going to gravitate towards the frontend. Then in terms of the backend, I'd say historically – and like I said, I want to underline that, and I'll get to that later – I think it's people who are more drawn to: I want to attack the most complex problem that exists. Like distributing state over 10,000 nodes, managing huge deployment infrastructures that drive these massive websites that happen at this mind-boggling scale. And so, there you really are thinking computer to computer and, “What's the ideal interface for doing that?” And then on the frontend you're thinking more like human to computer, because that's where the interface lies. Now the reason I say… ROB: I feel so let down. Where's the controversy? CHARLES: Well, okay. Well, because I think that basically – I think the controversy is saying like people who are more naturally empathetic. I don't know. That would be the controversy thing. But I want to say historical. ROB: Yeah. I can see that. [Laughs] CHARLES: So, I want to say historical too, because I feel like one of the things that's been magical about the last two decades of software development is the dawning realization that no software you write exists in a vacuum and that it's all interconnected. And so, I think that I for example feel very strongly while I try to think about the user experience first. And the developer, I'm also thinking about developer experience first. The way that you want a system to feel is going to inform the design of the UX workflow and that's going to affect the architecture of your frontend. And if you're interfacing with it through different media, like websites, phone, I don't know, even text messages, Slack, what have you – that's going to inform then the next level of how your APIs are shaped, your public-facing APIs. Which then inform the structure of your internal deployments. So, recognizing that the decisions you make in one end of the stack and ripple through completely and that they're not what we hold as dear these concepts of separation of concerns and complete and total isolation of layers. That really is false. But what it does is it enables us to change the individual layers to more – ironically the reason you want to have separation of the layers is so that it more easily lets you change them provide a more integrated experience. So, I think that's a long way of saying that I think frontend developers are more aware of what's going on in the backend and that they might be drawn into the backend. And the same thing goes for backend developers, realizing that the decisions they make are affected by the frontend and affect the frontend. And so, I think there's been a dawning more of a collective responsibility for design, for operations, for developer experience. And I think it's great. ROB: Yeah. And to [think back off] that. So, I was kind of wondering where the controversy was, because that's kind of my exact answer, too. Where do you gravitate towards on? The difference of mindset is like, if you've got a problem and let's say you're a full stack developer, so whatever that manes, but if you're given a task where you have to implement the frontend and the backend, where you gravitate towards first I would say is how you would attack solving a problem. For me, I would immediately go to the frontend and see how a user would immediately interact with it and then work out that way. Mostly also because I like having a tight feedback loop. And the frontend provides that nicely. I can change something and immediately see the difference there. And in the backend you can spend a little bit of time, unless you're TDD which you should be – you can spend a little bit of time piecing together things and figuring out the architecture. And then you'll have something that you could show for. It's just nice to see UI get thrown on the page. And it's real and you click a button and something happens. That's a really nice feeling. And that's kind of where I gravitate towards. And if yeah, if I had to attack the problem, I'm going there first. I get the endorphins from it. [Chuckles] CHARLES: Right. So, if we want to add controversy to the other side, because you got to always be controversial, right? So, we said the really blunt horrible oversimplification is that people who are more naturally empathetic gravitate towards the frontend. You could also say that from the other perspective, people who are more internally validated will gravitate to the backend. Because if you need to get those endorphins from working on the frontend, basically what you're saying is, “I want to put it in front of people and get the feedback from those people and know whether it's good or bad.” Whereas you could say, “Actually, I don't need validation from other people. I've got this concept of this architecture that is going to be the ideal thing. I know it. I've got this vision and I'm going to chase it, regardless of what's going on.” I think you can more readily do that on the backend because you're not as open to the feedback of a whole bunch of different users. And like I said, I think those are gross oversimplifications. ROB: Yeah. I agree. And so, as a devil's advocate towards the backend developer that is less empathetic, I think actually some of the best backend developers I've ever worked with were the most empathetic people ever. Because they know that software is for humans. And humans are going to be consuming the API that they build. And they take that into consideration. CHARLES: Absolutely. And I actually think that empathy pervades good software development just wherever you find it. Because yeah, someone's going to be using your APIs whether it's software as a service or it's a library. If it's software as a service, it's got to be easy to work with. It's got to be performant. It's got to have a nice command line. And so, you have to be thinking at all times, “What is it like to use this software? What is it like to consume it? What is it like to link it into my library? What is it like to call it from a web client?” So yeah, I think you're absolutely right. I think it's actually one of the great virtues of great software developers. SAM: Yeah. So, something that I've always kind fo had a question with, especially coming from that bootcamp setting: is there any sort of tribal separation between what you would consider a frontend or a backend developer or even full stack? Like, “I'm better because I understand data layers than I understand how a button fits on a page,” that sort of thing. CHARLES: I would say absolutely yes. If you at the, just do a quick poll of the Twitterverse, it seems like people tend to hang out in little circles of similar interest. So, there's definitely a bunch of people that I follow that are always tweeting about backend stuff. ROB: Yeah. Twitter is ‘build your own echo chamber'. CHARLES: Yeah. And there are people who I follow that are tweeting nothing but mostly frontend – when I say frontend, I mean frontend of the frontend. Well basically, from CSS down to nothing deeper than React components. And then there's people who are talking primarily about the backend of the frontend. So yeah, I do think that people – there are clearly, there are different areas of the stack and I think that people do tribalize around them. So, the question is: Who are the border agents? Because always cross-border trade. Any time you have borders, there's an exchange of ideas and information and things that happen at those layers. And actually, one of the things I'm really curious about is: How does that happen? ROB: Yeah. You might have the best perspective on this because you did – you were using Java Swing back in the early 2000s building UI. And that's like backend things. And then you had a lot of experience with Rails and you've moved into the JavaScript world. And the thing that I've noticed with frontend is, we're applying a lot of concepts that existed on the backend. And we're moving all that complexity into the frontend. And that's kind of where that fuzzy line of, “Are you the frontend of the frontend? Are you the backend of the frontend?” comes from. And it's interesting that – like this is going to be another podcast. We'll end up talking about this – but we have – MVC lives on the frontend. Like in React, your C is a container component. The controller is a container component. The model is probably your Redux layer if you have it or if you're using micro-states. And the view is your components, your view layer components that you're rendering down. So, these concepts are moving from the backend to the frontend. We're just kind of renaming them and making them our own concept. But they're there. So, how does that knowledge sharing happen? Is it really just a mass exodus of backend developers interested in frontend developers now? CHARLES: I don't know. I think it goes both ways. So, I can only speak to my own experience. And that was when I first started doing frontend development was back in 2003 I think. So almost 15 years ago. We were building a touchscreen interface for an electronics vendor in the UK. And it was just so much fun, because we were getting to build these interfaces that literally looked like nothing else. And you could touch them and you had support for rudimentary gestures and there was no keyboard. And basically the only interface was your fingers and like a price scanning gun. And everything, all the entire UI had to be developed out of that. And so, it was such a novel system and it was so fun to implement that I just gravitated towards it. I think the thing that was particularly compelling was it was very interactive UI. It was high-touch, literally. This is a clerk who's sitting there using this thing as rapidly as they can to sell stuff and move people through the line. So, it was like a unique problem. But the thing that was cool about it was I realized so many – we kind of already touched on this in this conversation – so many things that I had learned on the backend applied there. And there was in order to provide that experience, there had to be a pretty complex machine behind it. And that was fascinating, that machine. And so, we were able to apply a lot of the concepts. And so, in that time on the backend I'd just come off working off a backend that had basically an event bus – we would probably call them microservices now, although we didn't call them that then – were coordinating based on all these events. And that translated over into the frontend really, really well. And I remember using a lot of the techniques for exception handling – doing it on the frontend and doing a lot of the multithreaded stuff that we were doing on the backend, trying to reconcile that with the frontend and really understanding. So, there were all these analogous concepts. And it could be – so, there was an original exodus of backend development, for me personally. And so for me, it was like I felt like I moved onto the web pretty much exclusively in 2006. And it was a good – I would say 2013 maybe is when web UI development finally caught up with Java Swing. Like it was like, that whole time I was like, “I'm using the web because it's an awesome deployment platform. And it's got all this great stuff,” but man, the developer experience is not as good as like a stateful fat GUI was back then. And now, I would say it's actually surpassed quite significantly. But now, I think there are a lot of people maybe who either – I think there's a casting back of people who are in frontend development and casting back to the web. So right now, my love affair with immutability and functional programming started by using a Clojure web framework which borrowed a lot of the ideas from Clojure. So, I guess there was an exodus there – people from Clojure wanting to develop apps, wanted to have their goodies. But then I found that and I was like, “Whoa, that's awesome.” But then that really set the hook for me. And so now, I try and go back to the well, the backend well or the shared computational well, as much as I can. So, all of that stuff of basically discovering all this functional programming stuff, this highly formalized functional programming, all came from saying, “Wow. I got a taste of that. Let me get more.” So, it's very much like trying to run through the village of the backend and ransack the stores and take as much as I can and bring it back, because I know that it's good. ROB: So earlier in the podcast, you said that you were a frontend developer. You described yourself as a frontend developer. And that's funny, because I actually consider you a full stack developer. It's because you can jump in on the backend and sling any kind of code as well as anybody could, and then you can also do the same thing on the frontend. So, the question I have here is: Do you think actually someone that truly is a full stack developer – and we can define that in a second – but do you think they're at an advantage here, because they have all that experience? You can answer yes. But why? Why do you think they have an advantage? CHARLES: I think they have an advantage in the same way that a person who's bilingual has an advantage. So, if you are living in North America, it behooves you to speak Spanish because you are now open to an entire set of markets that were previously closed to you. Well, not entirely closed but like you can trade with Mexico and you can trade with South America. You can buy and sell goods. You have access to yeah, emerging technologies that might – something special might be happening in Mexico City, or in Medellín, Colombia, and you're going to have first access to that. And so, if you don't, if you're not bilingual, then you're going to have to go through an intermediary who is. And so, there's a premium: you get to be the middle man so to speak. Or you get to be, maybe that has kind of a negative connotation, but you get to be the broker of new ideas and new technologies. If you can, if you are fluent in backend so to speak, then you can go into backend-landia and you can talk with the developers there and see what kind of cool stuff they're doing. And then you can take it across the border into frontend-land and sell it. And so, that's – I think we're very much first to the gun on – not first to the gun but we're ahead of the pack in terms of functional programming. Because we've seen that. We've seen it proved out and we've now actually started to integrate it into your day-to-day routines. And we're ahead of the pack on that, right? And so, I think that's kind of a keystone analogy for me that I think really, really captures what is the advantage in being a full stack engineer. ROB: So, well how do you define a full stack engineer or developer? What things do you have to possess to actually claim that title? In order to be a full stack developer I personally believe you have to know, you have to be comfortable with CSS. You can hate it. You can yell at it. But I think you have to be able to put together a layout if a designer gives you a comp in order to claim full stack. And in the same token, if you're a full stack developer and you mainly came from the frontend, you should be able to implement backend features. I don't actually have – so, I'm strong in the frontend, not so strong in the backend. What would be the analogous of CSS in the backend? Would it be like mocking your controller actions? [Chuckles] CHARLES: I would say you should have a familiarity with HTTP and REST, would probably be the equivalent. Kind of like a foundational technology that just every single technology is oriented around it, or most. Regardless of the protocol you're using – there are things like GraphQL which are not really RESTful, although it's a blurry line there – but they're still delivered over HTTP. And so, understanding things like CORS, understanding the things that are going to be universal to APIs. ROB: I think a lot of people try to claim full stack. I try to claim it. And I know I'm not. I can put together a pretty crummy Rails API on my own for personal projects. But I'm not going to be the one that's setting up indexes on a database to optimize a database or anything. I think that does come in time, but you have – borrowing from Brandon Haye's talks about career development – if you're a full stack developer, I think you end up having to be in the industry for a long time. Longer than what we consider a senior developer these days, I think. Because you could be a senior developer and be specialized. And we see that all the time, and that's okay. But in order to amass that knowledge and experience, I think you have to be in the industry for a long time and done those things a couple of times to really know. CHARLES: Yeah. I agree. So, can I add something there? To continue the analogy of being full stack is like being bilingual or multilingual. I go back to those analogies a lot because that's what I – linguistics is what I studied in school. But when I was studying linguistics, one of the things that was going on there was they were kind of redefining what… ROB: That makes so much more sense of your vocabulary. [Laughs] CHARLES: What it means to be bilingual. There was kind of a reorientation of that definition that was going on while I was in school. And that was being bilingual doesn't necessarily mean you're able to converse about poetry or like deep technology or give speeches in another language. It really is, it's as spectrum of… ROB: Ooh, that's quite interesting. CHARLES: The definition of bilingual is like: Do you use another language in your life? So, if you are let's say someone who is a recent immigrant to a country and let's say you've got less than 1,000 words but you're using them to buy groceries, to pay bills, to do things like that, then you are bilingual. Bilinguility is not an exclusive club. It's really, are you actually using a language? So, if… ROB: Ooh, so that actually gets my wheels turning. Does that mean that you can have a junior full stack developer? Because like, if you just merely speak the both languages, technically by that definition, I jive with that. You can speak two languages. You are bilingual. You can write in two different languages. You might be full stack. But does that mean in the software industry you are a junior full stack developer and then as you go on and get tasks that are full-stack-like, you get better on both sides? Or is it as an industry, we really have to specialize? CHARLES: To start on the first point, I think that if you – let's just restrict it to one language – if you're doing JavaScript on the frontend and using Node.js on the backend, if you're writing Node code you are I would say by definition, and certainly by the definition of bilingual that I just proffered, you would be considered full stack, a junior full stack developer like I was saying. And I think that it's just been my experience that as you go on in your career, you will cross multiple layers of the stack just because you can't keep your hands off. If you have an ownership mentality of, “Here's this thing that needs fixed,” and it's on the backend, you know what? I'm going to go ahead and learn a little bit of how to do this, because I need it to work with the thing that I'm working on. ROB: Yeah, that makes sense. CHARLES: You will just naturally be drawn over borders throughout your career just because someone's got to do it, to do the thing that… ROB: You got to solve a problem. CHARLES: Right, when you've got to solve a problem. So, I think that people become more and more full stack over the course of their careers. But that said, I do think that there are clearly areas where functional specialization is absolutely a requirement. Like if you say, “You know what? We've got this API and we need to support 600 queries per second and we've got this huge, crazy deployment…” ROB: I will not be your person to do that. CHARLES: Yeah, exactly. That's something you're very much – that is something that you're very much hiring for. And you want to be hiring for like you said, someone who has the skill and someone who, that's what they want to do. ROB: Yeah. If you need better state management and rendering performance and testability on the frontend, I'm your person. [Chuckles] If you need me to scale your API, to handle hundreds of thousands of requests a second, nope. [Laughs] So yeah, I agree with the specialization. So Sam, I want to know. Has this conversation swayed you any way? Are you more interested in being full stack or are you leaning to a side more? [Chuckles] SAM: So, I think full stack is, it's as much about skillset as it is about personality. So, like you were talking a little bit earlier on how someone who's frontend might have more empathy towards the user. And someone who's backend might have more empathy towards the computer and the developer, rather than the end user. I think someone who's full stack has to have a wider range or empathy so they can empathize with all rather than just one or the other sets. I think personality-wise, I'd be a fine full stack developer. But I think professional-wise, I do gravitate towards the frontend because that's just how I am. As a person, I like to see the visual rather than the concept. I do a lot of painting. I do a lot of drawings. So, I'm a very visual person. So, it's really helpful to me, especially for someone who's junior and who's still learning and who came from that bootcamp experience, to be able to see what I'm changing. So, I think it does kind of go a little bit into experience as well. So, I think over time when I start touching on maybe some more backend work and I see some stuff that interests me, definitely I'll gravitate towards it, just because I want to learn. But I don't know that it's like an intrinsic quality, you would want to be full stack or be backend or be frontend, you know? ROB: That's interesting. Yeah, I agree with that. CHARLES: Yeah. That is actually a really interesting point. Because I think what I heard you say there is that when you have – software is a hidden world in many ways. You talked about it in the beginning of the conversation, the areas of the site unseen. Like you know it's there but it's hidden from view. So, there's a certain amount of vision that needs to develop. So, you kind of internalize what software, like this hidden software, looks like. So what does a deployment of some load-balanced microservice clustered thing look like? Most people would not be able to answer that question. But the more time you're exposed to it, the more it becomes burned into your inner vision. ROB: Mental model? CHARLES: Yeah. You develop a mental model. Your brain literally wraps around that. It takes time. But on the frontend, especially if you're a visual person – but I would say even if you're not – I think the same would apply to someone who's using assistive technology. It's still something that you can feel with your sense and you don't have to develop a sixth sense to perceive it. So, there's literally a problem of perception there. And so, maybe frontend work is a great on-ramp for everybody, because it's so perceptual. ROB: That's exactly why I picked it. I was trying to do iOS dev before. And I could not do it for those reasons. I didn't have that nice tight feedback loop of even though it was UI, in Objective-C you had to construct your UI and buttons out of Objective-C. Unless you wanted to use Apple's Interface Builder and that was, meh. Everybody built it procedurally. And what I loved about HTML and CSS, was I could instantly throw something on the page, attach some CSS to it, and see it change immediately. And that felt so good. [Chuckles] CHARLES: Yeah, yeah, no. And it's important to get those really tight feedback loops, especially when you're starting out. ROB: So, if we had to tie this back together, did we decide that there is a distinction between frontend, backend, and full stack? And if there is, or isn't, why? SAM: I think there's like… CHARLES: I don't know if we've… go ahead. SAM: Kind of a distinction. But it's also really fuzzy, I would say. So, if I'm going to explain what the difference is between frontend and backend to someone who maybe isn't a developer, I would always go back to a video game. So, when you see your guy… ROB: Ooh, this is interesting. SAM: Yeah. [Chuckles] When you see your guy running around and you're like, “Oh, this game looks really good. I'm really into these graphics,” but do you ever think about what it takes to save the game or what is actually being saved when you go to save it? So, if you're more interested in making the guy run and making the guy and the environment look good, you might gravitate more towards frontend. But if you're really interested in saving the data, like well what is being saved when I hit ‘save to this slot' or whatever? Then you might gravitate more towards backend. ROB: Or like the network layer of the online multiplayer? SAM: Yeah, yeah. ROB: [Laughs] That's interesting. I've never used video games as an analogy. I always go like, you know, if you're a frontend developer, you know that button that you click? That's the button I create. And then the action that happens is usually what the backend developer does. I think I like the game analogy better. [Laughs] SAM: I think the game analogy is something that most people can grasp. And most people can grasp. Like I'll tell people the difference between frontend and backend if I'm talking about Facebook. Like what I do for a job is I'll show you everything that's on your Facebook page. And when somebody, or the backend is somebody who makes all of that come into play, kind of, you know? But I think video games are easier to conceptualize that abstraction of data being saved rather than trying to explain the intricacies of Facebook to somebody. ROB: [Chuckles] CHARLES: Yeah. No, I like that. I like that. So, I guess if we achieved consensus, would we say that these do exist as broad functional categories? And a full stack developer is someone who will move in between those functional categories through the course of their career. And that generally, the trend is that the longer the career goes, the more you will do that. ROB: Yeah. I can get on board with that. I'm going to use your career as like the guiding post of that. The way you just explained it, it kind of made something click for me. You describe yourself as a frontend developer. And I think in our industry with software development and the way teams work, I think you end up specializing no matter if you call yourself a full stack developer or not. Because I do think you're a full stack developer. But you've mainly been working on frontend for the past what, three years, four years? So, I think it's okay to call yourself a frontend developer. But you are a full stack developer. But as you specialize around and amass that knowledge, that's where you become that full stack developer, right? And so, at one point in your career, you were a backend developer. And then now at this point in your career, you're a frontend developer. But now you have those experiences and you can draw on both of them and apply them across the fields, right? That's super interesting to me. So, maybe it is that you have to specialize in order to achieve the full stack. And you're never truly a full stack developer in your role. But it's possible, depending on the team and the team dynamics. It's just interesting that you can be a full stack developer, also at the same time be specializing as a frontend developer at that current time, right? Yeah, that's interesting. CHARLES: Alright, so it sounds like consensus achieved. Let's all virtually hug. [Chuckles] ROB: Send the hug emoji. CHARLES: Alright everybody. That is our show for today. We are The Frontside and we build software that you can stake your future on. We would love to hear from you, especially if you have an idea for a future podcast topic. Any news that you think is something that we should discuss, even if it's not the theme of the whole episode. And we will see you next time. As always, you can give us a shout on Twitter at @TheFrontside or just drop us an email at contact@frontside.io. If you enjoyed today's podcast, it was produced by Mandy Moore, the inimitable @TheRubyRep. So thank you, Mandy. And see you all next time.

RR 323: Queuing and Amazon SQS with Kinsey Ann Durham This episode of Ruby Rogues features panelists Charles Max Wood, Dave Kimura, and Eric Berry. Special guest Kinsey Ann Durham joins to talk about queuing and Amazon SQS. Tune in to learn more! [00:01:19] Kinsey Ann Durham Kinsey writes code for a company called Go Spot Check. She is always a lead mentor in a San Francisco based company called Bloc. [00:02:50] Background on Amazon SQS Go Spot Check is using Amazon SQS on a smaller scale. Kinsey thinks it is sasy to use. She recommends using something like Amazon SQS or even RabbitMQ. It has provided the company with the ability to explore different architecture patterns and tools. [00:04:50] Can you talk a little about your company and what led to using Amazon SQS? Go Spot Check is a start up in Denver. They focus on recording and data collection for big companies that need to know what is happening in retail, grocery stores, and bars. The focus is on alcohol and retail brands. The company analyzes the data collected that previously held no insight. Go Spot Check is currently moving into a computer vision aspect. Kinsey works off a separate service off of main aspect of Go Spot Check. [00:06:46] What does your stack look like? Is it built off Ruby? Yes, it is a Rails API only. The computer vision is done in Python. [00:08:45] Are you feeding the images through the queue? How does the queuing fit in? Started using Amazon SQS because they wanted to have a more decoupled way of developing. This allowed them to decide the contract between the two services and decide what they wanted it to look like up front. Kinsey describes that it is easy to create fake messages for testing with Amazon SQS. Image data is sent back and forth through the queue. The company does a lot of planograms. Information is taken from that data and posted onto a queue from the machine learning side of things. On the Rail side of things, the data can be picked up in API and sent back to the main app. [00:10:50] Does it accept binary data in the queue? It does not send actual images. All comparison data that has been processed is sent from the machine learning aspect side of things. An article has been published that shows that people do send images in the queue. [00:11:35] Do you use SQS in parallel with SNS (Simple Notification Service)? Kinsey says that they haven’t used SNS. This is because there hasn’t been a need. They are using it to post messages to communicate between different services. [00:12:40] What point would you need to consider a SQS over a Sidekick? Kinsey didn’t look into using Sidekick; she was excited to use SQS. She wanted to try it out and see if it was easy to use. Thought it would be more complex than it has been. She enjoys the free features of Amazon such as message visibility and timeout, which is handled by them. It can be customized and two different queues can be used. [00:16:15] How do you write the workers for an SQS queue? Kinsey has a plain Ruby object in the API that she can reuse with any queue. There are three queues in the company. [00:19:45] Are there any other uses for queues and SQS? Kinsey hasn’t come across any personally but she is sure there are some. [00:23:40] What if you’re someone who is new? Where would you recommend they get started? Suggest getting started with SQS Amazon, SQS documentation. Can get up to speed quickly. Amazon SQS is easy to get up and running. Kinsey is tailoring her Ruby Dev Summit talk to people who are new. [00:30:35] How do you go about mentoring? Kinsey loves mentoring. Developers have side projects or freelance work, but Kinsey likes to mentor because she feels like she makes a difference while continuing to learn. An important part of mentorship is giving support. This support level to students’ means not only offering students help with technical skills. Her goal is to build a well-rounded developer: someone who will be a great team member and people will want to work with in the future. This involves helping students build soft skills such as networking, interviewing skills, and helping them build confidence. [00:33:52] How would people get involved with mentorship? Kinsey is involved with an organization called Bloc - they are always hiring mentors. She shares that people can always get involved in their local community. Schools are looking for mentors. People at local meet ups and Rails Bridge are also both good ways to volunteer. Kinsey learned through mentors - she didn’t go to school to learn code. Mentors changed her life and are important to her, which is why she now mentors. [00:36:30] Advice For Women Kinsey’s advice for women who want to work in the technology world is to go for it. She urges women to get as many people and resources on their side as possible, including great developers who are willing to mentor. She emphasizes the importance of confidence and says to be ready for comments on gender. She believes that - while there are definitely still diversity issues with socioeconomic background, sexual orientation, race, gender, etc. it is getting better – women are more welcome in the technology field than they have previously been. There are technology organizations that are doing well and have no problems with welcoming women into the workplace. People in the field need to be open to having discussions about gender inequality. Open dialogue with team members is the key to solving problems. Some people have grown up not realizing the way they think is wrong. They don’t connect that what they say or think is offensive because it is all they know; it is unconscious to them. This is the type of person that is hard to change. Picks Eric: Open Collective  Open Collective – Women Who Work  Dave: Health insurance Charles: Profit First  Secrets of the Millionaire Mind Kinsey: Guide program applications for mentors at RubyConf Release It  Links for Kinsey Twitter Instagram GitHub

RR 323: Queuing and Amazon SQS with Kinsey Ann Durham This episode of Ruby Rogues features panelists Charles Max Wood, Dave Kimura, and Eric Berry. Special guest Kinsey Ann Durham joins to talk about queuing and Amazon SQS. Tune in to learn more! [00:01:19] Kinsey Ann Durham Kinsey writes code for a company called Go Spot Check. She is always a lead mentor in a San Francisco based company called Bloc. [00:02:50] Background on Amazon SQS Go Spot Check is using Amazon SQS on a smaller scale. Kinsey thinks it is sasy to use. She recommends using something like Amazon SQS or even RabbitMQ. It has provided the company with the ability to explore different architecture patterns and tools. [00:04:50] Can you talk a little about your company and what led to using Amazon SQS? Go Spot Check is a start up in Denver. They focus on recording and data collection for big companies that need to know what is happening in retail, grocery stores, and bars. The focus is on alcohol and retail brands. The company analyzes the data collected that previously held no insight. Go Spot Check is currently moving into a computer vision aspect. Kinsey works off a separate service off of main aspect of Go Spot Check. [00:06:46] What does your stack look like? Is it built off Ruby? Yes, it is a Rails API only. The computer vision is done in Python. [00:08:45] Are you feeding the images through the queue? How does the queuing fit in? Started using Amazon SQS because they wanted to have a more decoupled way of developing. This allowed them to decide the contract between the two services and decide what they wanted it to look like up front. Kinsey describes that it is easy to create fake messages for testing with Amazon SQS. Image data is sent back and forth through the queue. The company does a lot of planograms. Information is taken from that data and posted onto a queue from the machine learning side of things. On the Rail side of things, the data can be picked up in API and sent back to the main app. [00:10:50] Does it accept binary data in the queue? It does not send actual images. All comparison data that has been processed is sent from the machine learning aspect side of things. An article has been published that shows that people do send images in the queue. [00:11:35] Do you use SQS in parallel with SNS (Simple Notification Service)? Kinsey says that they haven’t used SNS. This is because there hasn’t been a need. They are using it to post messages to communicate between different services. [00:12:40] What point would you need to consider a SQS over a Sidekick? Kinsey didn’t look into using Sidekick; she was excited to use SQS. She wanted to try it out and see if it was easy to use. Thought it would be more complex than it has been. She enjoys the free features of Amazon such as message visibility and timeout, which is handled by them. It can be customized and two different queues can be used. [00:16:15] How do you write the workers for an SQS queue? Kinsey has a plain Ruby object in the API that she can reuse with any queue. There are three queues in the company. [00:19:45] Are there any other uses for queues and SQS? Kinsey hasn’t come across any personally but she is sure there are some. [00:23:40] What if you’re someone who is new? Where would you recommend they get started? Suggest getting started with SQS Amazon, SQS documentation. Can get up to speed quickly. Amazon SQS is easy to get up and running. Kinsey is tailoring her Ruby Dev Summit talk to people who are new. [00:30:35] How do you go about mentoring? Kinsey loves mentoring. Developers have side projects or freelance work, but Kinsey likes to mentor because she feels like she makes a difference while continuing to learn. An important part of mentorship is giving support. This support level to students’ means not only offering students help with technical skills. Her goal is to build a well-rounded developer: someone who will be a great team member and people will want to work with in the future. This involves helping students build soft skills such as networking, interviewing skills, and helping them build confidence. [00:33:52] How would people get involved with mentorship? Kinsey is involved with an organization called Bloc - they are always hiring mentors. She shares that people can always get involved in their local community. Schools are looking for mentors. People at local meet ups and Rails Bridge are also both good ways to volunteer. Kinsey learned through mentors - she didn’t go to school to learn code. Mentors changed her life and are important to her, which is why she now mentors. [00:36:30] Advice For Women Kinsey’s advice for women who want to work in the technology world is to go for it. She urges women to get as many people and resources on their side as possible, including great developers who are willing to mentor. She emphasizes the importance of confidence and says to be ready for comments on gender. She believes that - while there are definitely still diversity issues with socioeconomic background, sexual orientation, race, gender, etc. it is getting better – women are more welcome in the technology field than they have previously been. There are technology organizations that are doing well and have no problems with welcoming women into the workplace. People in the field need to be open to having discussions about gender inequality. Open dialogue with team members is the key to solving problems. Some people have grown up not realizing the way they think is wrong. They don’t connect that what they say or think is offensive because it is all they know; it is unconscious to them. This is the type of person that is hard to change. Picks Eric: Open Collective  Open Collective – Women Who Work  Dave: Health insurance Charles: Profit First  Secrets of the Millionaire Mind Kinsey: Guide program applications for mentors at RubyConf Release It  Links for Kinsey Twitter Instagram GitHub

RR 323: Queuing and Amazon SQS with Kinsey Ann Durham This episode of Ruby Rogues features panelists Charles Max Wood, Dave Kimura, and Eric Berry. Special guest Kinsey Ann Durham joins to talk about queuing and Amazon SQS. Tune in to learn more! [00:01:19] Kinsey Ann Durham Kinsey writes code for a company called Go Spot Check. She is always a lead mentor in a San Francisco based company called Bloc. [00:02:50] Background on Amazon SQS Go Spot Check is using Amazon SQS on a smaller scale. Kinsey thinks it is sasy to use. She recommends using something like Amazon SQS or even RabbitMQ. It has provided the company with the ability to explore different architecture patterns and tools. [00:04:50] Can you talk a little about your company and what led to using Amazon SQS? Go Spot Check is a start up in Denver. They focus on recording and data collection for big companies that need to know what is happening in retail, grocery stores, and bars. The focus is on alcohol and retail brands. The company analyzes the data collected that previously held no insight. Go Spot Check is currently moving into a computer vision aspect. Kinsey works off a separate service off of main aspect of Go Spot Check. [00:06:46] What does your stack look like? Is it built off Ruby? Yes, it is a Rails API only. The computer vision is done in Python. [00:08:45] Are you feeding the images through the queue? How does the queuing fit in? Started using Amazon SQS because they wanted to have a more decoupled way of developing. This allowed them to decide the contract between the two services and decide what they wanted it to look like up front. Kinsey describes that it is easy to create fake messages for testing with Amazon SQS. Image data is sent back and forth through the queue. The company does a lot of planograms. Information is taken from that data and posted onto a queue from the machine learning side of things. On the Rail side of things, the data can be picked up in API and sent back to the main app. [00:10:50] Does it accept binary data in the queue? It does not send actual images. All comparison data that has been processed is sent from the machine learning aspect side of things. An article has been published that shows that people do send images in the queue. [00:11:35] Do you use SQS in parallel with SNS (Simple Notification Service)? Kinsey says that they haven’t used SNS. This is because there hasn’t been a need. They are using it to post messages to communicate between different services. [00:12:40] What point would you need to consider a SQS over a Sidekick? Kinsey didn’t look into using Sidekick; she was excited to use SQS. She wanted to try it out and see if it was easy to use. Thought it would be more complex than it has been. She enjoys the free features of Amazon such as message visibility and timeout, which is handled by them. It can be customized and two different queues can be used. [00:16:15] How do you write the workers for an SQS queue? Kinsey has a plain Ruby object in the API that she can reuse with any queue. There are three queues in the company. [00:19:45] Are there any other uses for queues and SQS? Kinsey hasn’t come across any personally but she is sure there are some. [00:23:40] What if you’re someone who is new? Where would you recommend they get started? Suggest getting started with SQS Amazon, SQS documentation. Can get up to speed quickly. Amazon SQS is easy to get up and running. Kinsey is tailoring her Ruby Dev Summit talk to people who are new. [00:30:35] How do you go about mentoring? Kinsey loves mentoring. Developers have side projects or freelance work, but Kinsey likes to mentor because she feels like she makes a difference while continuing to learn. An important part of mentorship is giving support. This support level to students’ means not only offering students help with technical skills. Her goal is to build a well-rounded developer: someone who will be a great team member and people will want to work with in the future. This involves helping students build soft skills such as networking, interviewing skills, and helping them build confidence. [00:33:52] How would people get involved with mentorship? Kinsey is involved with an organization called Bloc - they are always hiring mentors. She shares that people can always get involved in their local community. Schools are looking for mentors. People at local meet ups and Rails Bridge are also both good ways to volunteer. Kinsey learned through mentors - she didn’t go to school to learn code. Mentors changed her life and are important to her, which is why she now mentors. [00:36:30] Advice For Women Kinsey’s advice for women who want to work in the technology world is to go for it. She urges women to get as many people and resources on their side as possible, including great developers who are willing to mentor. She emphasizes the importance of confidence and says to be ready for comments on gender. She believes that - while there are definitely still diversity issues with socioeconomic background, sexual orientation, race, gender, etc. it is getting better – women are more welcome in the technology field than they have previously been. There are technology organizations that are doing well and have no problems with welcoming women into the workplace. People in the field need to be open to having discussions about gender inequality. Open dialogue with team members is the key to solving problems. Some people have grown up not realizing the way they think is wrong. They don’t connect that what they say or think is offensive because it is all they know; it is unconscious to them. This is the type of person that is hard to change. Picks Eric: Open Collective  Open Collective – Women Who Work  Dave: Health insurance Charles: Profit First  Secrets of the Millionaire Mind Kinsey: Guide program applications for mentors at RubyConf Release It  Links for Kinsey Twitter Instagram GitHub

In this episode, Noel Rappin, developer at Table XI, comes on the show to talk about his new book, Take My Money: Accepting Payment on the Web. Noel Rappin: @noelrap | blog | GitHub Transcript: CHARLES: Hello everybody and welcome to the Frontside Podcast Episode 47. I'm Charles Lowell and with me today is Noel Rappin. Before we get into who you are, because I know that a lot of people know you already and you need no introduction, you're actually calling in from Chicago today, right? NOEL: That's true, yes I am. CHARLES: Did anyone actually show up for work today? NOEL: Yeah, people did actually show up for work a little bit later. So, this is being recorded the day after the Cubs won the World Series last night. I will say that my commute in the parking lot at the commuter rail station in the suburbs was surprisingly empty this morning. The people were a little bit slow to come in. The game didn't end till about midnight last night. CHARLES: I'm neither a Cleveland nor a Chicago Cubs fan but it was a harrowing game. It almost gave me a heart attack. NOEL: Oh, man. CHARLES: I can't even imagine what it was like. NOEL: A Cubbie Blue since I was a kid. So yeah, it was something. CHARLES: So, you're from Chicago? NOEL: Yeah, I grew up in Chicago. I grew up in the Chicago suburbs. I went away for school and I worked in Boston for a while, but came back about 12 years ago. CHARLES: Okay. So, that kind of leads me into the perfect setup for one of our questions is how did you get into development? I've known about you since I got into the Ruby community, probably back in 2010 or something like that. How did you come to be there? NOEL: I was one of those kids who was a developer at a certain age, I guess and I had an Apple II. I started programming Applesoft BASIC in the mid-80's, I guess, and eventually decided that I enjoyed it enough and got pretty over-educated at that and that's just a very traditional background. I went and worked at what we would now call web consulting company around 2000, my first professional job was '98 - 2000. I had done a lot of different languages as a student. That job was mostly in Cold Fusion and then eventually bounced around doing a bunch of different web development solutions. At some point along the way, I picked up the Ruby Pickaxe book and then eventually came to Rails. I started Rails as a hobbyist, either pre-1.0 or very early 1.0. I used it to build some task tracker for my team and a couple of other little tools like that. And relatively shortly thereafter, I started doing it professionally. CHARLES: I think you're kind of the same generation that I am. I call this [inaudible] from that early 2000's web development background where it's kind of fueled by [inaudible] network. NOEL: Yeah, a little bit. My first professional job was at a company that is a very, very small consulting company based in Miami and Boston and they were not developers who run the company. They've been documentary film makers and there's like a whole 90's technology trajectory here because they were documentary film makers and then they were documentary CD makers and then they were asked to add interactive stuff to the CDs that they were putting out and then they became web developers as a sort of a natural extension. And suddenly, it was like 1998, every company in the universe wanted to be on the web and they were like, "Oh, this seems like a good business to be in." And they started trying to hire actual programmers who knew what they were doing even though I was just out of grad school and didn't know what I was doing but it was convincingly put in. We did all the stuff then that would be like the first application that I worked there, the production server lived under my desk and was also the staging server and the development server. We didn't use, at that point, search control although eventually we did. There were no established conventions on what was the good thing to do. CHARLES: Yeah. The production server under the desk: a more elegant weapon for a more civilized age. NOEL: [Chuckles] Certainly old. CHARLES: That was a while back but you've obviously been doing a lot more structured, a lot more formal development over the course of your career. So, most of us, myself included, were kind of content to write the software, maybe blog about it every once in a while, give the occasional conference talk, but you've really, really delved in to those activities and really kind of taken the time to really, for the topics that you're interested in, really kind of research them very thoroughly to the point where you've actually written several books. When I think about the concept of writing a book, it sounds like, "Oh, my goodness! That sounds terrible. That sounds like a hundred of my teeth pulled out," or something like that. But you've done it multiple times. I'm curious, did you experience that kind of fear and uncertainty and what was kind of the decision making process that led up to, "No, this is something that I've got to do. I'm going to sign up for this. I'm going to do this. And I'm going to make this commitment." NOEL: Fear and uncertainty is a different question. I've always written things. I was a writer in some ways even before I was a programmer. So, being able to combine the two is something that I really enjoy doing. And I've always really enjoyed teaching. The more cynical way to doing that is I enjoy explaining things in a way that makes me sound smart. But I've always enjoyed doing it in whatever context. So, when I'm not writing, I've always often been involved in training at the places that I work or other things like that. And I've always been a little bit of a theater background and a little bit of a performance background and conference talks are a way to still scratch that itch a bit. CHARLES: You mentioned that you have a graduate degree. NOEL: No, my graduate degree isn't Computer Science but I did a lot of amateur theater things in high school and college. It's not something that I have a whole lot of other outlet for other than talking about development. CHARLES: [Chuckles] You wouldn't think that it's a natural thing but I think the best talks and the best walks. What's it like to have that element of theatricality to them? NOEL: I try in the books to give them a little bit of a voice. Sometimes you get interesting responses when you try to make a technical book a little bit funny. Some people really don't like it and other people really respond to it. I do it sometimes just as a way to maintain my own interest in the 14th page of this chapter or something. As far as fear and uncertainty, that never really goes away. I have a book out that I'm writing now about payments which is a very serious topic. And as much as I've done work in that and as much as I've done research on that, there are obviously people out there who have done more work and know more certainly about individual pieces of it. And there are a lot of people who are going to take anything that I write and implement it that way. They're going to take it as the way that things are done. So, that does introduce a tremendous amount of unsettling. CHARLES: Yeah, you're on the hook. They're like, "But Noel told me that this is the way to do it and I ran out of business." NOEL: Yeah. Actually, the payment book which is called 'Take My Money' is actually only a second book in the history of Pragramatic Programmers to have a legal disclaimer at the beginning which I'm very proud of. I think that the thing that is the most worrying especially when writing something long is not so much factual errors because I can check facts. Facts can be checked. Emphasis is much, much harder to check and the cultural community practices are much, much harder to check. And so, I'm often much more worried about the idea that I might spend a lot of time on something that nobody really is interested in or that I might not spend time on a really important thing just because it's a part of the world that I don't know as well as other people in there, and therefore, I miss something. Factual errors, I worry about them too. But factual errors are relatively easy to catch often, not always. Many, many years ago, I wrote for Rock's Beginner Rails book which was purchased by approximately nobody. But it's got one of those beautiful rocks black and white cover pictures of the author on it looking terrible. At that point, I had worked in Rails professionally but only for a very, very short time and there were certainly people who had a lot more experience than I did. But for whatever reasons, I had the book contract. In that context, there's a lot of uncertainty around not being sure that I know what the newest tools are or what the best practices are. CHARLES: How do you mitigate that? How do you address that? NOEL: Research is one way. There are pluses and minuses to not being the greatest expert or something when you're writing a book like this. One of the pluses is that your experience is a little bit more immediate and it's a little bit easier for you to make it relevant to somebody coming to it for the first time. But then a lot of times, you wind up doing the kinds of things that you might do if you were actually trying to learn it. But then I am a pretty good researcher and then I can compress that down into something that took me 4 or 5 hours to Google or research, or days to figure out the best practice, or talk to some experts sometimes and then I can hopefully distill that down to something so that you don't have to go on that entire journey. You can just cut the chase a little bit. It's researching. It's finding the people who do seem to be prominent in a particular technology or a particular skill and finding out what they're doing. Sometimes, it's getting it wrong, hopefully not very often. And sometimes, it's just like this is the best I can do and I have to like, "I can't solve every problem." CHARLES: Right, just being satisfied with that. NOEL: Yeah. CHARLES: I get it. That makes a lot of sense. You mentioned that the book you just wrote, the one about taking payments on the web, I saw that. I looked at it and I was like, "Oh, that totally needs to be this book. This book totally needs to exist." And thanks that it actually got written. But in hindsight, it's obvious that there wasn't really anything that like it treated web payments as this holistic topic that needed to be addressed and yet, when I look at the last 5 years or the last 10 years, this is a body of knowledge. It's been part of 90% of the applications that I've developed and it's been something inter-rolling like they've been patterns and stuff developed around it but I've never really thought about it, "We need to draw this circle around this practice." And this needs to be researched and there needs to be at least some guide on how to do this. And so, I think from my perspective looking in hindsight, seeing why it was published, "Oh yeah, that's totally obvious that that should have existed." But being on the other end, looking into the future of, given the infinite number of things that I could write about or I could research, I need to go about kind of the selection process and say, "This is something that really ought to exist." NOEL: This came about kind of interesting to me, I guess. The purpose of the book states it out pretty clearly. I, a few years ago, started working on - not a large web project by any means, but certainly one that had a fair amount of complicated business logic around their payments. And we inherited it with the payment gateway in place and I kind of thought that, "Oh, the payment gateway is there. That's the hard part." We just basically sat and pretty quickly learned that that was not the case. As I was really looking for best practices, things people who had delved to more problems on the assumption that a lot of people had to solve some more problems. One thing in particular that I was looking at was handling the failure case where I have to do something in my database and I have to process the credit card and they can't happen simultaneously but the failure of one affects how I process the other. I'm just looking around for how other people had solved that and really being surprised how little information I found about something like that. I kind of filed that away. About a little over a year ago, I had this weird idea that I was going to start doing some self-publishing again and sooner writing about this or thought about writing this as part of that, writing about payments and data modeling and something like that. And as I started getting into it, I was like, "I had enough issues here. This is longer than like a blog post and this longer than a magazine article. There's kind of a lot here." I worked with Pragmatic, so I know the editors there and I sent them a proposal and they pushed back a little bit on the idea of, "Aside from the documentation, what else do you need?" And I was like there are all these issues here. They know, Dave, they run their own web store, they wrote their own code and I actually was - part of when I got the contract because I got to interview Dave Thomas about how the Pragmatic store works which was great. It was really neat. CHARLES: Did that material actually make it into the book itself? NOEL: Not as such because I was a little reluctant to directly quote him about the internals of the Pragmatic store, but some of the principles Dave talked about. It was actually kind of reassuring that about 85% of it agreed with stuff I already thought I knew, and about 15% of it sort of went beyond that. They have some problems that are -- because they're actually managing physical inventory which a lot, not all web stores do, which introduces a whole host of other problems. It became a combination of I actually really do think I've worked on a lot of these problems and they're interesting. And a lot of people seem to have similar problems and there's now a whole lot here, and so it seemed like a book was a way for me to go on that. Other people might have gone a different direction. I am getting kind of an interesting reaction from people. I get a lot people who are saying, "Well, I really could have used that book two years ago." And not a lot of people say, "I really need to buy this book right now," which indicates maybe the marketing needs to be tweaked a little bit. I'm pretty sure it will. It's not even fully out yet, so it will find its audience. But it's interesting how I think people still even seeing the book is there assume that they know more about what they're getting into when they start doing payments. And then they come out the other end a couple of years later and they're like, "Oh wow! I really wished I had the guide on that." CHARLES: So, what you need to do when marketing this, you need something along the lines of 'you don't need this book two years from now' or like 'don't be the person who wishes they read this two years from now, read it now'. NOEL: If I had this book when we started, I would have saved so much time and not made so many mistakes. CHARLES: Yeah. It's always interesting to me the interplay between kind of the patterns evolving and documenting the patterns and how eventually that kind of precipitates code that makes those patterns automatic. But it feels like there's always this kind of knitting edge where you have to kind of explore the problems phase and do the research and then eventually you can kind of turn and digest and write little pieces of it, but eventually it becomes like code. Have there been actual code like plug-ins or stuff that has fallen out of this, or that people can reference directly? NOEL: Yeah. Not as such. There's a reference application in the book, but I submitted a couple of patch requests to a couple of gems along the way but nothing significant. It's pretty unusual for me to co-model a book like this with a lot of new open source tools. I'm usually more about using the things that are already there. But the book definitely has an opinionated set of thoughts about how you design a Rails application and it's pretty upfront about that. We're going to put all our workflow logic in their own objects and we're going to not put a lot of stuff in the active record models and we're going to do it for these reasons. The first chapter of the book actually is not even payments. It's just shopping carts and a way to talk about the data model and the design because ultimately, money has some word aspect but a lot of it is just principles of doing good software design, encapsulated software design, and the way you will deal with any big external 3rd party dependency. But then on top of that, you have the specific pieces of money is weird, like money has real world implications and has legal implications and things like that. CHARLES: Yeah, definitely. Whenever you're dealing with money, there's an elevated level of pressure that seems like it's put on. And I know personally when I think of -- lately, I was writing my very first payment system. We actually maintained for a while the stripe-rails gem which had moderate popularity but we don't maintain it anymore. But it was that project where we did that where I kind of became an information recorder. And it kind of started me on this journey of never destroying information, kind of that immutability and like functional programming and stuff like that because I was so worried about over-writing any information about the payments coming in. I was like, let's capture it from the web hook and write it to the database and replicate it and back it up and let's never throw away a fact. NOEL: The specific advice in the book is save as little of your user's personal information as you can and as much of the transaction information as you possibly can. It definitely recommends saving the entire response in the payment gateway. It recommends making sure that you store all of the pieces of your partial price calculation so that you can recreate it even if the logic changes because that is something that has specifically bitten me in actual world. CHARLES: Can you elaborate on that when you say partial price information? NOEL: Yeah. The application that I work on, it sells tickets. And it has a processing fee. Originally, the processing fee was whatever the processing fee was and I hard-coded it as a constant in the code base because I thought I do not need to write this processing fee to the database for every individual transaction because I was wrong. And eventually of course, they changed the processing fee which would be fine if you never had to look backwards at all and try to run a report of old transactions and try to validate that the prices on old transactions still held. So, they changed the transaction fee and then they started running reports and all of the reports are off by whatever the changed amount was. CHARLES: Right, I see. So you could still maybe store that constant in the code base but you have to at least write out what it was at that point when you did the transaction. NOEL: Yes. Not all of this has managed to make its way back to the legacy code mass that I'm actually dealing with. But what I would recommend is saving all of the individual pieces. Unit price, any processing fees, any shipping fees, any tax fees, any discounts, saving all those as they were calculated as part of the transaction so that you always have them and they're not dependent on the code or the logic staying the same because all of that logic will change. CHARLES: I'm all about the information hoarding. I think it's useful stuff. [Chuckles] NOEL: I even started recommending originally a failed transaction was in a database transaction so it would go away. But I think that it's a bad idea. I think that you need to save -- whether you actually save a partially failed transaction in your database or whether you log something, the information of those failed transactions is really important and you want to make sure that you hold on to that stuff and you can go back and look at it. The idea that a bunch of transactions are always failing and you don't know about it, that's problematic. CHARLES: It sounds like you're still working on this application which [inaudible] the book. NOEL: Although I'm a lot more critical of the code now that I've gone through -- the book made me sort of think about this stuff a little more systematically that I had and made me make a lot of things concrete that weren't quite in the original application. So, the code in the book is actually better than the code in the application. CHARLES: Of course. NOEL: It's also a lot simpler. CHARLES: Exactly. [Laughs] Because it doesn't actually have to do the real work, it just has to capture the principles. NOEL: It just has to be a good enough façade to show the ideas. CHARLES: Right. So, you're still working in this application that kind of service [inaudible] for the book. But I'm curious then how you manage that because for me, writing a blog post is hugely time consuming. Writing a book must be even more so. Do you just have it dialed in that well that you can just bang it out or do you mix doing the book writing with working on the application because obviously, it sounds like both are kind of crucial to each other. You've already said, "The fact that I wrote the book is actually informing the way that I structured the code that made me write the book in the first place." And so, how do you interleave those activities to make a continuous workflow? NOEL: There's a separation there because the book is the thing I do not at work, it's my side project effectively. I'm not ever mixing them in the sense that I'm really going back and forth between one thing and the other. The application is the thing I do at work; the book is the thing I do at home. They inform each other, obviously, but separating them is not usually a problem. They're not the thing I do at the same time, so they don't relate to each other that directly. CHARLES: I see. NOEL: It's time consuming but it's what I do instead of maintaining an open source project or doing some other community thing in what would be side project kind of work. CHARLES: So you just do it on your spare time. NOEL: Usually, the book is written between 10 and midnight for people who are reading between 10 and midnight. CHARLES: [Laughs] I like that conception. Do you think it would work at all if say, with your job there were some amount of time allocated for writing the book because I think there's some interplay and hopefully, it's [inaudible] interplay between the two activities. NOEL: The way my work job is structured right now, I actually do a certain amount of time for blogging but that's company blogging. It wouldn't necessarily cover working on the book. It would certainly go faster if I had time because certainly trying to squeeze some parts of this into my allegedly spare time becomes challenging. Writing a book like this is not just writing a book. You're actually writing to some extent an application and it's not a fully featured application but it does have to work and the tests have to pass and things like that. It has to work well enough so that if somebody were to copy it, it would run. That can be frustrating when to come to writing the book and find out that, "Some gem is updated and now, there's some weird test failure in my book," is sometimes a little frustrating. CHARLES: Yeah, I know. I can imagine. You said that the book, most of the examples are in Ruby on Rails. Would you see it being valuable to someone who was not doing Rails development at all, maybe he was doing something in Python or Clojure? NOEL: Some of it is in JavaScript because the client-side Stripe library is in JavaScript. That's kind of the central part of it especially for security purposes. Some of the code would carry because the Stripe API is actually pretty similar across a lot of these languages. I think some of the principles would still hold. Some of the tools are a little bit Rails specific but some of the basic ideas of separating things in the background jobs, the way that you need to think about the administration, handling failure, like some of that I think would have some value outside of the Rails world. CHARLES: Were you explicitly thinking of how the developers with the web payment problem in general is your audience or were you really thinking this is more for Rails people or where did the kind of needle fall there? NOEL: The tricky part here is that it becomes very, very hard to write a book simultaneously using the Rails API and the Python API. It's very confusing. It's a 300-page book as it is and you have to make some decisions there. While I would like it to be valuable to anybody who's doing web payments as sort of a practical matter, Rails and the Ruby API are the ones I know best and that's where the examples are because they have to be in something and they can't be in everything. CHARLES: I remember a lot of those books that I read that used Java kind of as the one [inaudible] of the system that they were talking about. But it really was like, you're right, there's a line that we have to tread there because you can't just wave your hands and talk in one piece abstract principles that have no ground in reality. But at the same time, by giving concrete examples, you may limit the potential audience. I do think there is a path in there where your examples are accessible to people from different backgrounds. NOEL: Examples are really hard, actually. It's a very tricky thing to have an example that is complicated enough to get the point across but not so complicated to get buried in extraneous details. It's really a problem actually when you try to write about testing because almost any problem that is simple enough to be an example in a book is not complicated enough to show why test-driven development is a good idea. [Inaudible] has the same issue a lot of times like you start bringing these relatively robust methodologies to this little toy problems and it's hard to get across why they're valuable when you're working on a toy problem. Not impossible. There are people who do it. CHARLES: If I can count the number of tutorials that were like modeling cats and dogs and people, it's like I've never written a single class that even remotely resembled any of that stuff. NOEL: You're bringing in more complicated problems but then you become so sensitively dependent on the weird crooks of whatever problem you've chosen which can be difficult if you make it feel like it's less universal. If the idea is that these techniques or these tools are going to help you manage the complexity in your application, then you need to show an example that actually has enough complexity for them to sort of work. It can be really challenging. CHARLES: You mentioned also the examples [inaudible] some of them are in Ruby that you're actually opinionated about making sure that the main logic is captured in objects which I think actually furthers that goal where you're not really bound so much to the Rails APIs. But then you said obviously, the other stuff is in JavaScript just because the client side Stripe library is implemented in JavaScript. You wrote a book on JavaScript a few years back. So clearly, it factors into your development story. I like to often kind of try and tell people like we are all JavaScript developers, whether you know or not. Do you have any advice for people who were approaching JavaScript from outside the core of [inaudible]? What's the best way to make your [inaudible] approach? NOEL: I have opinions on this. The problem is that I don't do big single page JavaScript apps, for the most part. It's just not part of my nutritional background at the moment. Mostly the JavaScript I'm doing is relatively at the kind of thing they sort of derive as sprinkles of JavaScript. CHARLES: Like I said, I think it's a far larger attempt than anyone cares to acknowledge. NOEL: I feel like my decision to try very hard to stay out of the JavaScript ecosystem battles has paid off for me tremendously in most ways. At the same time, I don't have really strong opinions about JavaScript build tools because I hadn't really had a whole lot of occasion to use them. I very strongly recommend that people coming into JavaScript now that you use some of the ES6 features especially things like classes and stuff that like to give you a better structure. Structure in JavaScript gets a little bit more consistent than what you see in other programming languages. A lot of those changes were I think pretty beneficial to how I work with the language. One thing that I like to do when I am doing something that is smaller, too small to really bring in a framework because I'm still doing mostly kind of jQuery, is I have a style where I really do try to isolate the jQuery in the DOM from the logic in a way that they don't always see people do on the theory that the DOM is a big 3rd party dependency in a way that on the server side, the database is a big 3rd party dependency. And in both of those cases, we kind of pretend that they're not big 3rd party dependencies because it's easier to integrate them, but eventually that kind of hurts. And I find raw jQuery and raw JavaScript is very hard to read and hard to understand. So, I think it does a little bit better if you start burying it behind some stuff that has some more semantic [inaudible] and things like that. And then we get to the point where you need a framework that actually has data binding even if it's a small framework like Vue.js or something like that, then you have some habits that will help you as you start building them. CHARLES: I think it's been interesting. Obviously, you did JavaScript a lot here but having that separation in kind of a mental model of what is my representation of the data and how am I actually presenting that to the user. It's kind of scary how universal that concept is and how well it will serve you as you grow from the simplest little one liner JavaScript thing to a whole full-fledged single page application using whatever framework you choose. If you abide by those principles, it may not be easy but it's going to be a lot more tractable. NOEL: Your transition to using one of those tools is going to be a lot easier if you already in habit of separating out your display logic from your actual logic. CHARLES: Yeah. Believe me, I'm not looking to like draw you into any kind of controversy here with JavaScript or Rails. But in the last several Ruby conferences that I've been to, there's been a lot of talks and a lot of discussions about 'where's the Rails community headed', 'where's the Ruby community headed'. How does it fit into this kind of new ecosystems that are emerging and what's the role that it's going to play down the road? And so, I'm just kind of curious to get your take on that as someone who operates in a bunch of different environments. Is Rails something, if you're starting an application from scratch, you would pick up again? NOEL: Yeah, I still pick up Rails for new applications. I think that, especially because the ecosystem is still so far ahead of all the newer tools ecosystems, I still think it's still the best way for a small team to act like a big team. We're definitely investigating other stuff, other tools. All of our Table XI developers are trying to pick a framework that they don't use everyday ideally in a language that they use every day and build a common app in it just to try out some new muscles and get a sense of what the strengths and weaknesses of some of these other tools are. We're starting to bring them in slowly to our server and client side repertoires where they're appropriate. I think that Rails is great but it's not perfect which leads the possibility that there will be something better eventually. I think it will take a while for something like Phoenix and Elixir to build up the ecosystem and the number of 3rd party tools that the Rails community has. CHARLES: We've been playing around with a bunch of different tools here. I actually started a side project and I was using Rails and I was blown away. I was like, "Oh, I forgot how easy it actually was." And that actually can't be discounted and things like speed and things like this lightweight feeling, you can [inaudible] for the lack of an ecosystem. I certainly made that mistake with Node.js. NPM installs at the very beginning were super fast and that was the reason that you weren't installing anything at all. [Laughs] NOEL: Rails still prioritizes a certain kind of developer experience in a way that is really great for projects up to a certain size. I think there's a significant dispute of where that certain size is. I have a coworker who did a Rails project recently after also having done a bunch of JavaScript projects and had a very similar reaction, "I forgot how easy some of the stuff actually can be." Eventually, you get to a size where some of that easy search could be less [inaudible] in terms of something a little more structured. But there's still a lot of value there. I find the Node ecosystem honestly really complicated and confusing relative to the Ruby ecosystem. And some of that is just my lack of experience with it. CHARLES: We're [inaudible] everyday and it's complicated. It's just that it's huge. It's just mammoth compared to the Ruby ecosystem and I don't think it started out that way, but it certainly is like that today. NOEL: Rails is at least somewhat focused on a particular size problem. And I think that that makes the ecosystem a little bit more manageable. I think the JavaScript tools are trying to solve a lot of different problems for a lot of different people sort of under the same umbrella and it gets very hard to do that. CHARLES: Well, that's about it for our time. Thank you so much for coming and talking with us. NOEL: Thanks for having me. CHARLES: Yeah. The name of the book that you're currently writing is? NOEL: It's 'Take My Money: Accepting Payments on the Web'. It is available at PragProg.com. And then you can find anything I'm doing at NoelRappin.com. Keep an eye out there because there's going to be a new project that hopefully will start by the end of the year. I'm a little less confident that it's going to than I was, but I'm still hoping. Also you can find me on Twitter @noelrap. CHARLES: All right, fantastic. Bye everybody!

In this episode, Yehuda Katz, co-founder of Tilde, OSS enthusiast, and world traveler, talks about what's in store for Ember. Yehuda Katz: @wycats | blog | GitHub Transcript: ALEX: Hey, everybody. Welcome to the Frontside Podcast, Episode 46. My name is Alex Ford, subbing in for our usual hosts, Brandon and Charles, today. We have an awesome episode. We have a really special treat for you. Co-creator of Ember, Yehuda Katz is joining us today. Hello, Yehuda. YEHUDA: Heyo! ALEX: We also have a first time Frontside podcaster, Chris Freeman. Chris, do you want to introduce yourself? CHRIS: Hey, everybody. ALEX: We've also got a podcast Frontside favorite, Robert DeLuca. ROBERT: Favorite? I don't know if you say that. Hey, everyone. How are you doing? ALEX: I'm really excited about our guest today. Yehuda was just in Austin a couple of days ago. He gave a great meet up talk and a deep dive into Ember and it looks like you're going on-tour with that talk, Yehuda. Is that what I saw from your website schedule? YEHUDA: Yeah, I'm not sure exactly. I change it up every time, largely because things happen. So if I say this thing is 'active' or 'in progress', and then it actually shifts, I have to change it up. I've been talking a little bit about what's up on what we were working on. ALEX: Do you want to give us a brief outline as to what's going on in that talk for those podcast listeners who might not be able to attend? What's going on with Ember? What's new? What is it that you're trying to get across here? YEHUDA: Sure. Actually, the talk I gave in Austin was, you're right, it was basically a deep dive. It was really focusing on a few targeted things that we're working on. I would say that at a high level, we're basically working on a couple of things. One of them is generally more integration with the ecosystem, things like ES6 modules, classes, components that look more like HTML and more graphic components and things like that, also improving EmberCLI so it's more integrated with other tools that people are using. A lot of that stuff has to do with the fact that Ember started a long time ago now, like five years ago or so. And so, I think we've actually done a pretty good job of keeping up with things. For example, we adopted ES6 modules and promises a while ago now, and I think generally speaking, we tend to keep up with the ecosystem. But because we've been around for so long, there are certain things like classes, where it took a while for that feature to catch up with the functionality that we were using in Ember. Decorators landed a little while ago as a stage 2 feature in TC39, and that lets us really take a bigger chunk of the functionality that we have in our class model. I make it work for everybody with class syntax and that's something we're pretty excited about. So that's one area just generally taking things where Ember had its own stuff and try to integrate a better ecosystem. Another big area is this mobile readiness and also, a lot of that has to do with the fact that things like service worker have just recently landed. For example, AppCache was a nice feature in some ways. Some people at Google will kill me for using the word 'nice' in AppCache in the same sentence. [Laughter] YEHUDA: But AppCache was trying to accomplish something for a long time. I think it did some version of what it was trying to do. But really, using AppCache is a default behavior for all users having - there's too many caveats to make it work well where service worker, because it's more of level one and more directly controllable is a better fit for something that we could ship with all Ember users. We basically want to use Ember and EmberCLI, you build an application, you get a good mobile experience out of the box. Some of that has to do with trimming down parts of Ember that we don't need to be using in simple applications. Some of it has to do with service workers, some of it has to do with things like Glimmer 2, just making the performance better. But generally, that's the other [inaudible] so it's basically mobile readiness on the one hand and just integrating better with the one ecosystem are both big picture things we're work on. ALEX: Something that you brought up in your talk where private Ember methods and how a lot of people use private methods and you have to keep them around, what you we're just talking about that was unifying around the conventions of programming in Ember. Whatever JavaScript people bring in to Ember, you want to try to incorporate that as the language moves forward which is, I think, a really interesting problem. Also, something you could talk about a little bit further is what you look for in the way people use Ember going forward and how you have to kind of bend the framework to allow it to be backwards compatible. I'm curious what that decision making is like. YEHUDA: What you're talking about and what I talked about yesterday is what we call 'intimate APIs' and that basically means APIs that we never intended to be public. But for some reason or the other, people got their hands on them and started using them. I gave a somewhat elaborate example of funky case yesterday. But basically, the way we approach generally dealing with compatibility is pretty similar to how the web itself does it. First off, there's a thing that we mark as a public API. We just don't break it unless we make a major version which is very rare. We have basically one of those the entire Ember, and I don't think there's anyone coming in the near future. One option is if we don't like something, we just break it. That's very uncommon. Another option, and this is way more common, is that we try to build -- it's for public APIs -- we try to build a new API and we try to nudge people away from the old one. One approach for nudging that is probably the most common is deprecation. So, deprecations themselves don't violate semantic versioning because we're allowed to say, "Please don't use this anymore." The one area that's annoying about deprecations is that if backup code that powers the old feature has to still stick around. And so something that we've been working on around that aspect, around deprecations is something we called svelte build, which is basically the idea that we'll mark every deprecation with the version, that it will start to be deprecated in and people can ask for, "Please don't include any code that was deprecated out of 2.4, or 2.5, or 2.6, or whatever." Then, we'll automatically slip it away. You could think of it sort of like as a reverse feature flag. CHRIS: Wow, that's actually super interesting. I didn't know that. YEHUDA: We haven't finished it up yet but the RFC that talked about it and actually some old guy who actually wrote the RFC along with 1.13 when I noticed that 2.0 was going to end up being a pretty painful release for a lot of users. We did a lot of things around 2.0 to make things less painful, like we made sure that 1.13 contained all of the deprecations that you could possibly need, as well as all the new features. So if you went to 1.13, you could look at all the deprecation warnings, switch to the new functionality. As long as you have no deprecations left, 2.0 was just the exact same code without any of the deprecated features. But as we're working on that, I realized that there is no real reason to give people such a heartbreak, if we could instead just slip away the code. So that's one approach and I think, more or less deprecations, and then eventually, svelte builds are the normal path. With regard to intimate APIs, those are cases where people came to rely on very specific timing or very specific API, very specific details in some internal API and for those things, if we know that a lot of people use them -- usually they get used to like a couple of add-ons. Maybe Ember Wormhole, which is really popular, we'll use it. Then it's really hard for us to remove those things. Those APIs are harder to maintain compatibility for because the exact details of what they even did was never really well-defined in the first place because they were never documented. So usually what we'll do is we'll look at the usage of the API. We'll come up with a new API that is satisfying the exact same use case, and then we'll deprecate the old API. The policy these days is that you have to go through an LTS release so we'll make sure it's deprecated. Let's say, you want to deprecate something now, make sure it's deprecated in 2.8. And you'll know that if you were actually doing the whole song and dance that deprecate what is intrinsically a private API, so it would be within our rights to say like, "Sorry guys. You used the private API. We're not going to help you." But we really think it's important that for Ember, if something feels like a breaking change, that we're not doing it willy-nilly. If somebody upgrades to 2.9 and all of the sudden, Wormhole stops working, they're not going to understand that the reason that happened was because Wormhole did a bad thing. We basically need to do a clear pass. So we'll do a deprecation in LTS release, then we'll wait a couple of releases before removing it. Then usually what happens is, in the meantime, we'll go ahead and we'll submit pull request for the big add-ons that we're responsible for, and we'll also try to talk and write down why it happened. Historically, we've done that a few times and it's worked okay. There was an example of this, which is the lookup factory API in Ember which is really a boring API but it's used by a bunch of high profile add-ons. So the reasons why we needed to deprecate it were silly. They were just a bunch of bad behavior in the old thing that was making everything super slow. We can make things faster by giving people exactly the same functionality without exactly but identical guarantees. So there were some 'guarantees' which don't even make sense for private API. But there were some things that in theory, the API did that we didn't want to support because of performance reasons. And so, we gave people a new API that is, for all intents and purposes, identical. All users will be able to use it in identical way. But it doesn't have exactly the same weirdness and that weirdness was pretty expensive. ALEX: So you've trained Ember developers to be on the 6-week release cycle? They're looking at the blog posts. They're looking to upgrade but you've been involved in a lot of open source projects where I'm sure that wasn't really the case. Say, jQuery has a huge API and obviously, some things have to be deprecated on that and you were on the jQuery core team, I should mention. YEHUDA: Rails has the same story whereas API releases every year, more or less. ALEX: So, I'm just curious. The fact that you have Ember developers, I would like to think bingeing on your word and hinging on those updates, how would you go about, say, the Rails API? Or the jQuery API? Maybe, now you're involved with Rust, and maybe the plan is to have Rust on a 6-week release cycle. I'm curious, if you don't have your developer's attention, as you do the Ember developers, how do you deprecate an API like that? YEHUDA: That's a good question. How do you deal with deprecations if you're releasing quickly? I think there's a couple of important points to make here. First of all, Rust is on the 6-week release cycle. Sometimes, as the same kind of story with intimate APIs, it's much less common with a strong-type system like Rust. I guess, important things to point out, first of all, deprecations don't intrinsically break things. When we talk about intimate APIs and deprecations happening pretty quickly, those are APIs that are large, if someone is not paying super attention to Ember, they're probably not using those APIs, like they would not have known to use them in the first place. They might be using an add-on that use those APIs and the intimate API deprecation process causes the add-ons to update relatively quickly. In terms of regular deprecations, those deprecations stick around forever so you could come back a year later. For the most part, you could make an app that was 2.2 and upgrade it to 2.9 as long as you upgrade the add-ons that you are using at the same time and everything will work. We also realized that some people can't upgrade every six weeks and that LTS release process which is basically a six-month process, more or less. It basically gives us a communications channel to people who want to pay less attention. The way that that works is that, every four release cycles, so that six times four is 24 weeks -- about half a year. Every 24 weeks, there's another release. We assume people are on that release channel. Some people operate at 2.4, 2.5, 2.6, 2.7, 2.8. Some people go directly from 2.4 to 2.8. For those users, we [inaudible] ecosystem, please make sure you support the last LTS release, which means that if your user's on 2.4, and 2.8 comes around, you know that you could have stuck to 2.4 and generally got add-on support and when 2.8 comes around, you should probably upgrade. Also, with intimate APIs, we make sure we always deprecation them one LTS release before we move into an LTS release. Now, what that means is that if we want to remove something by the 2.8 LTS, we have to have already deprecated it in 2.4. If we want to remove something by 2.12, we have to remove it at 2.8. So six months is still not quite the one-year Rails release cycle but it's starting to get to a reasonable state. Also, I would point out that the LTS releases, the support policy for them is that they're four cycles long. We do bug fix support for six cycles and security releases for 10. What that means is that we're actually supporting LTS releases. We were supporting two at a time for security patches -- two and half basically -- and we're supporting one and half at a time for critical bug fixes. The one and a half basically means that when 2.8 comes out, you have two release cycles which is basically three months to upgrade. If you're on 2.4, and 2.8 comes out, it's not like, "Oh, my God. Panic! I got to upgrade right now." You can take a few months to upgrade. Basically, 2.4 came out, you got all the deprecations you need to care about. You had six months to deal with deprecations and then another three months after that. Even in terms of intimate APIs, where in principle, like Rails and jQuery don't even care about those things for the most part -- ah, jQuery cares about it even more. But most projects will get private APIs and say, "Sorry you used the private API. Why did you do that?" Ember is a rare project in that we actually deprecate things that we know where we actually use them. We have a process for dealing with them. Even that process, like I said, it's not a six-week process. We don't deprecate something and remove it. We deprecate something and then give it a pretty long horizon before removing it. ROBERT: I'm curious. You brought up that you are the common element between jQuery, Rails, and Rust. I know that there are, at least, between Rust and Ember and from Rails to Ember, there have been a lot of commonalities and lessons learned in how the projects themselves are managed. But I'm also curious with Rails, Ember is clearly pretty heavily influenced by Rails, which you were doing before. You've been working on Rust quite a bit and I'm curious, does your usage of Rust, even though it's a very low-level language, does that influence Ember at all? Does that change how you think about the framework or JavaScript in general? YEHUDA: The number one thing that I got out of all those projects that I think used to be a thing is something like a conventional reconfiguration idea which is really not - I think the mentioned of reconfiguration is probably not even the best description of what it is. I think the idea that communities that are all working together on the same thing to build that thing bigger and better and better and better and build ecosystems around that thing, those communities are able to build much higher than communities that ask every single developer to put together a bunch of pieces themselves for profit. That's the basic idea. If you look at Rust, which is conceptually very low-level, you'll find that there are things like Cargo, which is a tool that not only builds your thing and not always package manager but it has a convention -- not only a convention -- it has a built-in support for documentation. So you're on Cargo docs, you get all your documentation for all your dependencies. You run Cargo bench. That's a built-in thing that runs your benchmark. You run Cargo test that runs your test. To mark your documentation as being Rust code, it will automatically run your tests for you when you run Cargo test. We will build your examples for you and make sure your samples keep compiling. There's all this stuff in Cargo that you would not necessarily consider, like it's basic [inaudible] helping you get your workflow the same. Then there's things like Rust format which you've been working on and there's been a huge debate in the community about exactly how much configuration we want to allow in Rust format. But the irony of it is something that most people agree with is that we should try to come up with some kind of default style for Rust that everyone agrees to, that most people can pick up and use the Rust products where it's often used. Then there's things like Futures and [inaudible], where the goal of those libraries is really to make there be a single central way that everybody does [inaudible] in Rust. These are all things that if you look at like C or C++, which are languages that are sort of in the same low-level in this space, in the same kind of area, you'll find that those languages have billions of ways in doing all of those things and there's so many different styles and so many different workflow tools, so many different things that you can make in then a million things that [inaudible]. Even the Rust is conceptually low-level, it doesn't really affecting every single environment as some sort of things that everyone doesn't need to do themselves. I think, an important thing that people don't always get about convention configuration is that it's not just that everybody doesn't have to do all of those things and it saves you some time, it's that when everyone is doing the same thing, it's a lot easier to build another level on top of that. For example, a fast food is a great example of this in Ember. The fact that everyone initializes their application using an Ember initializer, the fact that services were these global things that are sort of global- there's no better word than 'services' but global services, the different components could share the fact that those are all going in the same place. The fact that the way we manipulate DOM is always in a constraint single area. Almost things mean that when it comes out and to build something like fast food, it's pretty easy to take almost any Ember application and make it run in the fast food environment because we know what we're looking at, and that's something that isn't necessarily true about other tools. For me, Chris, the number one thing that, I think, all of those sharing, including jQuery, actually, like jQuery said, "There's so many different ways that people do DOM manipulation, why don't we unify it into one thing that I everyone can use?" You know, the 'jQuery plugin', which is something that has falling out of favor over time. The reason it was so popular was largely because people knew, "Okay, I'm dealing with jQuery object. If I just put a plug into the jQuery object, it makes sense." People understand how to use it. I think that's something that a lot of projects that I used to share and it's also something that is not close to ubiquitous. It's very uncommon, actually. So that's one thing -- the conventional configuration story. I think, another major aspect of all this, and this is something that jQuery and Rails do not share, but Rust and Ember have the RFC process, which more or less, is just a wave as a community of saying, "The way that we agree to add new features to the project is not something coming down the [inaudible] with a tablet every year." At a conferencing, we have agreed to add these features but sometimes people are core team, but sometimes they're not. Sometimes, they're actual contributors, coming with an idea, write their view down in a format that we all know how to do with. Then there's a community discussion about it. Sometimes it takes a very long time. Sometimes it's not. But then we eventually come to a conclusion about what it is that we're doing. Eventually, the core team agrees to merge the RFC. I think one of the nicest things about RFC process is that it produces an artifact that you can come back to a year, two years, three years later. If you say, "Oh, I wonder why they've made that decision. I wonder why that's the thing that they did," and the reason why this is great is that the RFCs are not gospel. They're not something that we should hold onto forever. But at the same time, we don't want to reel it again, things that we already discussed that in-depth over and over and over again. If a person comes back and they say, "Oh, why do they do that? The modification of RFC, why are these instructions directors are like that?" If they go back and look at the RFC and the thread associated with it, and the thing that they want to bring up is something that was already discussed, it's really no reason to bring it up again. But maybe someone have thought of a different idea or a different reason to dislike or to disagree with the decision that was already made. That was already discussed. That's a much better rationale for bringing up for re-litigate. In other words, re-litigating is actually good but if you re-litigating five times a day, on every decision, that's not why you move. So RFCs, by their very nature, the fact that the core team is doing things in public like anybody else and everybody else is also participating in that same process, the fact that artifact tells you, more or less, exactly what was discussed, makes it really easy to decide when is a good time to revisit some of the questions. ALEX: Do you find that poll request has the same process as an RFC and it's an artifact you can go back to, it's a place to have communication that is visible to everybody, unlike say, this micro message service such as Slack where context is just lost for the public. I'm curious if you want to see that modeled in poll requests or if an RFC is where something like that belongs. YEHUDA: I think, poll requests are great. I remember that when I was somewhat like the first user on GitHub who's not a founder of GitHub. I remember one of the things that excited me about GitHub early, although, the very beginning, didn't have poll request yet. but one thing that excite me about poll request is that before poll request, every single time I would use an issue tracker so they were like a billion issue trackers like [inaudible] whatever, and at that time I called it 'patch management'. I want something that helps me manage patches because the actual discussions are not the higher of it. The higher of it is something that submitted a request for me to merge in this patch. How do I merge it? How do I discuss with them? Those things were always really hard so I might ask people to upload patch files or whatever. It's hard to remember how bad things were but the number one thing that was just so obvious but also so terrible about the ecosystem before GitHub was patches were like old mailbox approach. Like you'll make a patch, and hopefully, get it to the right place at the right time. So I think, poll request and comments of poll request and many of the improvements that have been made for poll request are great. The reason, I think, RFC are really important in addition to poll request is that, by the time someone actually took the time to write some code and submit it, it's very easy to look at it and say, "Well, I don't necessary agree on all the things here but I don't want to give a person a hard time that will do the work," whereas somebody submit some idea early on and they say, "I have this idea --" It's actually a lot easier to sort of get into details at that point and say, "Don't do this. If we should do this or it doesn't fit that well with this other RFC or this other poll request that's already open --" But once somebody actually does start and actively working on the feature, I think, poll request are great, like most open source project these days. Ember doesn't ever committed anything to master. Everything goes to poll request, and even core team stuff. I also find that when I submitted a poll request or anybody in the core team, there are almost always people who are not in the core team that saves or fix in the poll request, for various reasons. Of course, poll request also are the usual mechanism by which people run things like CI and linting tools and things like that, called quality tools. I think, the poll request workflow is really good. In terms of other messaging services, I think, there just sometimes the need to have conversations that are faster than poll request and I don't really have any problem with check conversations. But I definitely agree that it has a deep conversation. This is something that happened in the [inaudible] a lot where we having this conversation with the core team and somebody will say like, "We should really move this out into a public discussion, or move it into RFC. If you don't agree with this thing that somebody said public, can you say [inaudible]." So I totally agree that if there's a thing that people want to say in private about something but it's just in private for convenience, it's not private or transient for any good reason, actually getting out there onto the issue or the poll request and say your opinion and letting the conversation back and forth happen there is, for the exact same reason as you said, very useful. In fact, Aaron Turon from Rust brings this point out repeatedly. We just had a conversation this past week about the fact that we have sort of a normal Rust project that, let say in the core team room and it's a technical topic, and it doesn't have anything sensitive about it, people always say like, "Hey, can you move that into Rust Internals," which is a public room. Or like moving this course, we have internals at Rust-Lang.org and I keep thinking Ember could use it. Basically, this sort of a hierarchy of private to public or transient to sort of a free-form discussion forum like this course to something like a GitHub issue, something like an RFC to something like poll request. There's like a hierarchy of how much of those artifacts are easy to search and find. But I think, you're totally right that there's no reason why, things like the core team needs to exist because at some point, the buck has to stop somewhere. Somebody has to make decisions. Somebody has to actually responsible for laying out the cross-cutting vision for the entire project. But those things are actually pretty lightweight. The core team when it's doing its job, it's just sort of making an omnibus of everything that the community is thinking at a particular point and making it more concrete. While, I think that's important that there are spaces which are core team spaces, or spaces that are transient, I think, a lot of questions that people have in the Ember slots are important that people who can just jump in and ask them. I think, getting things out into both public and more of permanent artifacts spaces is good. ALEX: Rob, you are a co-runner of Ember ATX and I was hoping you could speak on the fact that we've gotten some core team members down to Texas to come talk. It's nice that they're able to share their message with what's going on in the core team. But also, they're doing work. They're seeing how real people use Ember and then taking that back to the core team. I was wondering if have just want to comment on that and your work on bringing some really excellent people who make decisions down to Austin. ROBERT: As a meet up runner, like a co-runner, I guess. It's me, Jeff, and Lydia that run Austin Ember ATX. We really like to try and bring people that are deep into Embers core into Austin to talk about the framework that these people work in daily. It's always awesome because whenever you get them there in the flesh, you can ask questions. I guess, we can go back to where Slack is, like you have the higher bandwidth communication but it's even higher bandwidth when you're in person. Getting those people to talk to people that are actually working on the framework daily is I think, hugely important and that's why we work really hard to try and bring out people that work on the core. YEHUDA: For what it's worth, I think that Rails and Ember shares a common core value, like other projects have, more or less. Ember core team people almost exclusively actually work on Ember apps as part of their jobs so I work on skylight. Having some responsibility in the real world for apps that you are working. It's a big difference in just [inaudible]. I definitely noticed a few. Sometimes, I'll be working on a project for a while, like when I was working on Rails for 18 months and never actually used Rails. I mean, I used it but not for anything significant during that time. I, sometimes, get into a rut where I'm working on Ember a lot and I haven't had a chance to work on an app at all. Then, you go back to work on that for a day and it's like, "Oh, my God. There are so many obvious things that I can make better here." Like the kind of things that you would think about when you're working on your framework stuff is not necessarily- as quick it gets, the quickest things that you can fix. The Ember welcome page is a good example of this. I think, when someone is training, it's very easy for them to notice that it would be great if there was some kind of welcome screen for people. But it's not something that a framework author would necessarily think of on your own. Similarly, getting down to places that are not my usual haunts and hearing people bringing stuff that I just hadn't heard before. Like things, "Oh, that's a good idea. But I haven't heard that." A lot of that just come from the fact that the core team has a lot of different kinds of users in it so the people doing training, there are people doing apps or people doing consulting, there are people doing rescue projects in that kind of combos is pretty good. There's a long tale of all kinds of stuff, like people using web sockets for network people using React. People are trying to do Redux in Ember, who knows? That long tale is impossible to represent all that long tale. In a core team, we try to get as much as possible. It's impossible to represent all of them so going out there and talking to people doing weird stuff and weird doesn't meant pejoratively, just unusual stuff. Like Ember, really wants to be pretty flexible under the hood. Even though, it's a pretty conventional tool, we want it to be flexible under the hood so I kind of no way of flexibility is but sometimes, I'll talk to somebody and I'll be like, "Oh, in retrospect, that particular thing, I thought that was flexible as missing as little knob that we can add." So I really enjoy it. CHRIS: Since you've been pretty heads down on Glimmer 2 and you are actually traveling out and talking to people, I'm curious, are you noticing any common themes from the feedback that you're getting recently in terms of what users are saying? Do you have an indication of what the next move might be? Or what people are asking for? YEHUDA: For Glimmer specifically? CHRIS: For Ember in general, or Glimmer specifically. But I imagine, you're probably getting general Ember feedback. YEHUDA: Yeah. I talk about this a little before like the two big areas of interest are mobile readiness and better integration with the ecosystem. Integration is the wrong word. There's nothing wrong with Ember to that extent but people want classes. I think, those are the biggest picture things. I actually noticed a couple, somewhat interesting things when working with Ember. We ship the Glimmer Beta six weeks ago and we're doing another beta just because there's a couple of bugs that we got that were trickling and we want to make sure we get it right. I've actually noticed the people have on the one hand, the story of Glimmer is that we're pretty similar to React in the sense that you should think of what we're doing as a top down, you render the whole time and that there are some nice [inaudible] that use Ember.set or the set API, then we are able to do what people should do with component update automatically for you. For [inaudible], then we know, "Oh, this whole area, doesn't need anything to be updated." If you think about it that way, if you think about it as how can we render [inaudible] around set, I think, you'll notice that Glimmer updates are always faster than React's updates. But people have come to really rely on the sort of quasi-guarantee that if you didn't update something, it doesn't change the DOM associated with it, or even execute code associate with it. I find it sort of interesting. This is like meta problem, which is React actually got some things right about how to make this story performance. Part of that has to do with not assuming that you need as much bookkeeping as Ember always assume that you need. In exchange, you get much faster initial render and you have to do more work around updates. We actually have a pretty good story here. Ember.set is pretty nice because it lets us use API that our users are used to, say, generate [inaudible] upon updates for you and that's nice. But people get very upset when things run that they didn't expect, which of course, is not how React people think about it. The way React people thinking about it is, of course, [inaudible]. That's the whole API. It runs until you told not to. In Ember, things run at people who don't expect to get very angry. I think, you have to be one that I'm thinking about and that's a lower [inaudible]. But in terms of low-level, like thinking about how to shift the mental model of an Ember user so that we can get away with less and less bookkeeping upfront. I still do too much bookkeeping as part of initial render but in order to keep reducing the amount of bookkeeping, we need people to get into mindset of things are fast initially and the tradeoff is that your updates are slower, unless you do whatever. There are mighty things like React does this wasted time debugging tool or they basically tell you, "Hey, you didn't tell us not to render this but it never render," so you should try and do that. To be honest, I think, having to write something once your component updates, that exactly, "Do I [inaudible] is not okay. I'm not willing to do that." But there are a lot of things that approximate that were more similar to Ember existing APIs that we can find. I guess, my medium-term goal here is to make it so that we have the sweet spot so that the initial render is always very efficient. I think, we're getting closer. There's still some back problems that we can deal with so. Initial render is very efficient, fast components are fast, and more or less, you get good updates performance until you reach a certain amount of scale and then the escape valves are much nicer [inaudible] before an update. They're basically little [inaudible] where you say, "You know this thing can't change." It would be hard for me to explain. It would feel like it's [inaudible] we talk about. We've had a bunch of discussion about different escape valves, and the thing I'm most interested in is finding once that feels semantic. Should there a component update doesn't feel like you're describing anything other than React's API. I'm more interested in things that feel like you're talking about your app or your data. ALEX: Yeah. ROBERT: Keeping with the Glimmer 2 topic. Glimmer 2 is written in TypeScript, right? YEHUDA: Yep. ROBERT: Do you see that creeping its way more into the Ember community? I guess, I kind of want to get your general thoughts on TypeScript and what your experience was writing in Glimmer 2. YEHUDA: I actually really like that. But the story with TypeScript was that I was writing the Glimmer 2 originally in regular JavaScript and I came back from a long trip. I want to show Godfrey what I've done and I was having trouble explaining some of the interfaces. I happen to know that TypeScript is a lot of it is just interface so I'll just use their syntax and I think, I open the playground and I type in some TypeScript interfaces. Then I was like, "Oh, it's annoying that if I reload, I'll lose it so let me copy the interface into the ReadMe, basically and to the app." Then over time, like not very much time, I was like, "Oh, it's very annoying that now that I have this, I really wish I could just use it inside of the code." So we started doing that. It took us maybe a week of actually being to be able to use TypeScript for real. But honestly, the code base is pretty big at that point, and the actual was not so bad. A lot of the reason why it was at the time, TypeScripts like VS Code, TypeScript was still younger and it wasn't a slam dunk. For example, in today's TypeScript, you can just have JavaScript files in your directory and just tell it to [inaudible] that works. At that time, you couldn't so you have to really change all the files and there are some things like TypeScript requires you to specify in classes. It requires you to specify all your fields and I think that's fine, that's good for TypeScript. But you're not going to have already done that in JavaScript so you can't just like rename all your JS files with TS and have a nice day. So it took as a little over a week, I think, and we also have to write the Broccoli TypeScript thing during that same period of time. That was another thing we have to do. ROBERT: Yeah, that's a [inaudible]. YEHUDA: Then, with TypeScript change the compiler API a few times so we have a bunch of [inaudible] to do. But other than that initial like [inaudible] to get it working, I would say that it was every single point in time, there was always a [inaudible] win, in terms of what we had to do to make TypeScript happy and what wounds that we got out of it. You get things like, obviously, people know about code completion. I personally like code completion. I think, it's helpful. But I think, jumps to definition is actually more important feature than code completion. Just like what is this method? I want to look at it. You can jump directly to it. Also, for me, the code completion of parameters is way important the code completion of method names so when someone teaches you about code completion, they will usually show you, "Oh, look [inaudible]." It gives you the list of all method names, and you're like, "Well, that's fine. But I probably know all of those method names." But you don't necessarily know all the parameters. Especially, once you start using types, the parameter or information is actually quite rich, like it's telling you this is a component definition, this is a string or this is whatever. All that stuff, I think, I basically come to realize from using TypeScript that Microsoft has done a really good job with [inaudible] code of distilling down to just what part of ID experience is really good and just bring you that to an editor, that feels a lot like Atom or Sublime, or other than that. So if you get like a pretty good ID experience, without all of [inaudible]. ALEX: I've seen some talk on GitHub about people who want to write their Ember add-ons on TypeScript and I did not know Glimmer 2 was written in TypeScript until just now. I'm glad that was brought up. But we as Ember developers have been trained to use convention over configuration. The convention is Ember is not written in TypeScript. We're starting to see convention now where logic has crept into the template, or it's not as much as convention as people are doing it right now. I'm curious what your thoughts on that and more is treating Handlebars as a programming language and something that we're seeing now in real production Ember code, so what is the path going forward there because it is happening? YEHUDA: Yeah, I agree. I just want to say, I didn't actually answer the previous question in full. I think my expectation is we have no interest in ever making TypeScript as rudimentary part of Ember. I think Ember should always work and work nicely with regular JavaScript. I don't want to do anything that would lean to heavily on people having TypeScript around. Certainly, I don't want to do with Angular did, which they use the types as semantic markers for dependency injection and something like that. But I do anticipate things like Ember-metal for sure, Ember runtime being written in TypeScript because anything that's pretty low-level and a lot of algorithms benefits a lot from clearly delineating interfaces. I think, another thing people don't realize is that there are all these [inaudible] interfaces floating around your code in JavaScript. But like you are in a class, it's pretty easy to document what the class does. But if you have an interface, it's not really any good mechanism for describing it and it can become very [inaudible] and it's Like, "Please give me an object as these methods on it and build these methods." It's funny because you don't realize until you start using TypeScript that it's a very recursive problem. It's like, it has these three methods on it have these six parameters and these parameters have these interfaces and those have these. So you can actually start describing a very complicated thing and it's like those complicated things didn't exist before, they were just very implicit. The explicitness of the interfaces is not you can write [inaudible]. You can write the three interfaces and have the methods with all types of networks [inaudible]. I think, I expect Ember-metal, Ember runtime, other low-level parts Ember, certainly the component library now it's like directly linking in with Glimmer and Glimmer were written in TypeScript so that stuff would really benefit with TypeScript. In terms of Ember itself, using TypeScript, I think we have sort of a medium term goal of letting Ember apps use TypeScript if they want. I would say that making that story really nice, pretty much leans on ES6 modules and ES6 classes so we have some of the ES6 modules but there's still a lot of Ember [inaudible] whenever module story. In terms of classes, were still using the old-style class system and that class system is actually just really hard to get the types working in TypeScript. It's hard, period. But like React has a similar problem and there's lot of advance features that only really exists in [inaudible] express ES5 class [inaudible] and TypeScript doesn't have all the features. My expectation is that sort of along the same path as getting ES6 classes. We will also get a lot of TypeScript support in Ember and I think a lot of people are interested. A lot of people have work on Glimmer now and they're like, "I would love to use it in my app so we'll probably have that happen." Coding your templates, was the other question. I sort of have a mixed feeling about this because on the one hand, I actually do want Glimmer to be the programming language in production way. So either templating engines are just using the programming language embedded like the ERP. Or they are like Mustache or like the general templating engine -- forget what that thing is called -- but there's a bunch of template engines that use like the curly syntax and those things aren't very rigorous in terms of how they think about scope. Like lexical scope, it turns out to be a pretty important thing about how programming language work. If you have a shitty scope story, people don't have a good sense of what's going on so like the Angular 1 templating story was you basically find your scope on wherever and you attach to a part of your template and that basically means that if you're looking at just temple, you have no idea what the actual variables mean, anyway, because any part of it could be choking up the scope to be whatever. I start with Handlebars but have refined a lot overtime and I'm pretty happy with it now. The Glimmer templating engine is basically defines a programming language. It has scoping story. If you want a variable, name it. Use the as-pipes syntax and you get some variables there. Your function, your output, your components, and your helpers are functions and sometimes it's written in JavaScript, just like in Ruby cellular functions that are written in C. But ultimately, just like a C extension, it can't magically change the scope of Ruby program, helper or component in Glimmer. It can't magically change the scope of your template. With all that needs, if you look at a Glimmer template, it's actually really clear what are the names mean. That sound boring but ultimately, that's one of the things that needs to you look up at a lot templating engine and not only really know what's going on. I don't understand what's going on, without thinking of what every single one of those custom helpers is doing. I think Jinja is the name of the templating engine in Django. If you look at some of the templating engine like that or even like Handlebars before Ember 2.0, you really have to go that like 'for x and y' is a magic syntax that needs a particular thing. Because a lot of these templating engines are very flexible in the sense that they let users have or whatever, any particular piece of syntax could actually be creating random names that mean whatever. I've just found, having worked through that in the Ember community, I'm very happy that we took the time to get that stuff solid. One of the nice side effects of that is that it makes some of the usual optimizations that people do on code work very nicely. Once we know all the names mean and know all the scopes mean, things like in lining specialization from invocation. This component is invoked here. It has these parameters, but those parameters are all strings and I can see the receiving end. The receiving end just fix those strings into attributes or something. At compilation time, like to combine all into one thing. This is an optimization that we haven't done yet because we been working on compatibility. But there's a lot of normal 'programming languages standard optimizations' that we can do because we design Glimmer to be a programming language. The fact that we've done that is actually mean the root cause of people doing more programming language stuff in their templates, in older versions of Ember before, we had done such a good job of rationalizing everything. You would start doing that stuff and you would start hitting clips where the behavior didn't work the way expected for some reason, then you just use a sub-expression as something and then depending on exactly which things you put into the slots, maybe it didn't update on the inside of the template. We always consider those things as bugs so we would fix the bugs that we encountered. There's an explosion of different kinds of things in a programming language and if you don't model variables as variables basically, then it's hard to know callbacks are callbacks, variables as variables. There's a lot of doubt so they would start using the APIs as part of them [inaudible] hit someone and they would pull back. But today, the implementation of Glimmer, especially with Glimmer 2 is extremely [inaudible] standard, and what that means is that you want to do very [inaudible], parenthesized expressions with as type something and then you want to go and take that and send to the component and you have that and you put that value and put it to a service and you do all that and it works. That doesn't necessarily mean that it's a good idea for your template to be in a large program. That's generally that. I think that's main question that you asked me and it is generally, for things to get really complicated. But I think there is a reason for it and I think it's something we're doing to make it better. I think, the reason for it is that, if you think about the Glimmer core language, the main escape of what you have to get complicated expressions out of Glimmer and back into a reasonable place is helpers. Let's say you have a big bunch of [inaudible], and/or whatever people are doing inside of their Glimmer templates and it's like a multi-line thing and you want to pull that out to a more reasonable place. The natural way to do that is to make a helper. But it's also pretty common that you have a complicated piece of expression that isn't reusable. It's not being reusable for multiple places and helpers in Ember right now are global so you may have this big block. Another [inaudible] of computer's property, but computer property's don't have a nice- like I have a few internal parameters and I just do something that they always require you do something against it, the components off of this, and that is usually what's you are doing. You're usually have what is effectively a function with a bunch of parameters in it and those parameters combine some way like with 'and', 'or', maybe there's some comparisons like 'greater' or 'less than' or whatever. One of the things that comes out of module modification RFC and makes everyone pretty excited is the ability to have helpers in your templates that are local so it's a helper that is just sitting right next to your template. I think, those kind of things -- helpers that are right next to your template -- will give people who like you do not want to see so much code in your template, a much nicer story to explain to people why we're doing it, and what we should do instead. A template has a three-line, fifteen is privacy expression and you want to convince the person not to do it. The re-factor is literally just to make a local helper, put the code in there and use the local helper. I think that's the better story to explain to people than, "Hey, I don't like that. It feels bad. What should I do?" CHRIS: This brings up an interesting point that we actually encountered recently at The Frontside, we use helpers a lot and are frequently trying to get them to do all sorts of weird things. But recently, it occurred to us that one kind of blocker was that you can't compose helpers. We had an existing helper and we kind of needed to make a helper on top of it and it suddenly dawned on all of us that, "Oh, we can't go up a level." We can't build a helper and its abstraction over another one because you kind of have to hit the dump. You have to have a component or a template or something to invoke that. Is that's true? YEHUDA: I would expect that you could call the function with the arguments that looked ugly but I would suspect and I would say that you can call it and just pass the parameters and hash these [inaudible] and -- ALEX: Like a helper that invoke or something? Because to write a new helper, you would have to go back to JavaScript. YEHUDA: That array an object. I expect that to work. Do you just need a helper calling another helper? ALEX: Well, a helper composing, like composing several helpers into a bigger helper and then just calling in the template, much like how you might write some functions and that write a function that closes over them or something. YEHUDA: Are we talking about a helper that takes the helper? ALEX: I guess it could be. I guess, higher order helpers could be a thing in this case. YEHUDA: Helpers that call helpers are helpers that close over helpers really should just- helpers are more or less functions. It would just be able to use them directly. I think, what you're saying is an interesting Ember phenomenon. I actually don't know which of two categories this discussion is in. Basically, either. Either there is some good reason why this turns out to be difficult and there's like a missing API that usually fix it. Like in general, my mental model here is you're talking about a function so if you can just [inaudible] the function, it really should work and in that, it is hard. There's something weird. Basically, what I'm saying is either there are some 'gotcha' that how it was structured right now, that's like an accident. That means they're not exactly as much like functions as we think or the mental model that you have using them doesn't make you think of them like functions. So you think that there are hard to compose but actually there are functions. Basically, those two things are equally likely Ember. I think that's unfortunate. ALEX: I think that with them, you can certainly combine them in a template and you could even pass one into the other. What we ran into an issue was, similar to functions, if you are writing like an npm library, you may write five functions and only export one of them. That one function will compose the other four and call them. In some cases, you may not realize, do you want to export that composed abstracted function until much later and it's okay, because you just import the function from somewhere else, then you say like, "All right. I'm just going to consume this function from another and now I have this combination put together." Well, with a helper, if you already have a helper that does something and then you realized, "Oh, actually, I need to build an abstraction on top of this helper in a new helper," we so far have not found a good way to combine them like that. YEHUDA: So probably, it will not succeed and having this conversation through to the completion year. I'll just say for listeners, what I find surprising about this, although, I can believe that there is something that makes it true is that helpers in Ember are really just functions and increasingly they really are like helpers in Glimmer are functions. They have a weird arguments signature. They take positional parenthesis in array and named arguments as dictionary and that's a convenience basically because otherwise, you have to scrape of the last parameter and try to figure stuff out. So that's a signature issue. But generally speaking, helpers are supposed to be functions and if there's something that you could do with regular functions you can't do them with helpers, that sounds to me like something is wrong. Like I said, I can definitely believe I should talk to Chris about this and he should write a blog post about it. I can definitely believe that there is something that makes it true but it's hard for me to imagine what it is. CHRIS: Well, I'm glad to talk to you about it offline. YEHUDA: Yes. We will figured it out. ALEX: Yehuda, thank you for this deep dive into open source process into Ember. I could drill deeper into your brain and just extract as much knowledge as I can. I hope to be able to do that someday soon. We're going to wrap up for today. Thank you very much for Yehuda Katz and your time. YEHUDA: Yeah. Thank you. I apologize for people who didn't understand half the things I said. ALEX: Yeah, it's a podcast for everybody. But we have a lot of Ember developer's listening and I'm sure that they loved it and hated it all up so thank you very much.

В этом году мы записываем серию подкастов со спикерами конференции RailsClub 2016. 22 октября, Москва, подробности и регистрация на сайте конференции. Первое интервью было с Лешей Тактаровым Ссылки These Guys Code Hipsters - Ироничные новости фронтенд-разработки глазами бьюти-кодеров Rollup - Next-generation ES6 module bundler Webpack – A bundler for javascript and friends Foreman – Manage Procfile-based applications Hivemind – The mind to rule processes of your development environment Статья Равиля Brunch – A Front end build system CODE. The Hidden Language of Computer Hardware and Software - Код. Тайный язык информатики The Nature of code Being A Developer After 40 – Каково это — быть разработчиком, когда тебе сорок перевод Расшифровка эпизода, опубликованная на Habrahabr Как ты пришел к Ruby ? Моя история знакомства с этими технологиями довольно нетипичная. Я начинал свою карьеру как человек, который делает системные тулзы. Я и с фронтендом тогда не встречался, просто занимался нативными интерфейсами для Windows. Какое-то время потратил на то, чтобы делать программы, которые работают с большим количеством потоков, которые работают с concurrency и так далее. А затем как-то плавно перешел во фронтенд, тогда как раз появился хайп. С Ruby и рельсами я начал работать уже после этого, и для меня это было небольшим откровением, потому что не все вещи, которые там работают, работают так как я привык. Лучший пример: в некоторых средах, где ты всегда должен следить за ресурсами, если ты что-то взял в одном потоке и работаешь, то должен быть уверен, что в другом потоке не будет проблем с этим - в ruby все эти проблемы обходили стороной. Я столкнулся с совершенно другими концепциями. И это было клево! Если говорить конкретно - я пришел на проект как фронтендер, делал только фронтенд задачи. А потом у нас не стало бэкендера :) Он ушел, некому было решать его задачи, и я решил попробовать. Было необычно: обсудить было не с кем, человек который мне помогал был этаким мудрецом. Я приходил к нему раз в неделю, он говорил какие-то магические слова о том, что мне делать. Потом я уходил, вздыхал, думал: “О боже, что происходит”. Через какое-то время мне вроде удалось постичь эту мудрость, хотя наверное не всю. Ту часть, которая заложена во фреймворке и языке, я почувствовал этот вкус. Где и чем ты сейчас занимаешься? Из личного - готовлюсь к свадьбе. Работаю над своим проектом, который еще слишком сырой, чтобы про него рассказывать. А еще работаю с партнером в команде, которая называется These Guys. Мы специализируемся на быстрой разработке MVP. Стараюсь по-максимум применить тот опыт, который я получил работая со Злыми марсианами, и с другими командами. Но сейчас я больше ориентируюсь сейчас не на решение технических задач, а на решение бизнес задач, продумываю как оптимально все построить для клиента. То есть ты сейчас открыл свою компанию? Да. Хотя сказать об этом вслух мне сейчас очень страшно, почему-то :) Что тебе не нравится в текущей реализации рельсов с точки зрения фронтенда? Мне кажется, что произошла такая ситуация: два или три года назад фронтенд резко скакнул и понесся вперед со скоростью локомотива, сметая все на своем пути. Ребята из других сообществ на это смотрели, кто-то скептически относился, кто-то воодушевленно. Но надо признать, что ускакал он очень далеко. В этом плане мир рельс остался без изменений. Есть мнение, что рельса должна перестать быть инструментом, у которой есть и фронт, и бэк, сосредоточиться только на бэке. Потому что фронтенд часть в самой рельсе сейчас явно не успевает. Приходится рельсы использовать как серверную часть, а фронтовая стоит отдельно, там отдельные инструменты, отдельная команда, отдельная история. Какой позиции ты придерживаешься насчет этого? Я всегда пытаюсь смотреть шире. Когда я вижу хайп вокруг фронтенда, я всегда пытаюсь найти и хорошие, и плохие стороны. Хорошо, что все развивается и движется, много идей, много что можно сделать такого, что поможет следующему поколению разработчиков. Но на это нужно смотреть с опаской, смотреть на то, действительно ли все так, как кажется? Это касается и компаний: какой они выбирают стек, как они общаются со своими разработчиками. Например, разработчики брали какой-то популярный сейчас стек, а потом все разваливалось. Компания переставала работать, потому что технология была сырая. У вас было такое? Я стараюсь придерживаться золотой середины. Недавно прочитал статью Равиля Байрамгалина из марсиан про новый рендерер. В ней интересна даже не сама реализация, а то, что идет в начале статьи: у DHH нет большого количества времени, чтобы уделять его разработке, но он записывает и рассказывает много идей, которые могут подхватить другие разработчики, чтобы успешно развивать фреймворк. Мне кажется, это здорово. Круто, когда есть видение, когда DHH понимает куда идти. Возможно будут разногласия, где-то это будет не совсем правильный путь. Но мне нравится, когда есть понимание общей миссии. В рельсах такое видение есть, нужно пережить хайп и двигаться дальше. Мне кажется у нас все получится, моя позиция вполне позитивная :) Если говорить про хайп во фронте. Что сейчас является хайпом, а чем реально можно пользоваться? На что, по твоему мнению, стоит обратить внимание? И что будет интересно дальше? Какое-то время назад мы с друзьями организовали в Ростове небольшую тусовочку, которая называется Code Hipsters. Это, в основном, лента новостей во вконтакте и в Телеграмме, мы пишем про всякие модные штуки во фронтенде (это и пытаемся обыграть в названии). Сейчас я немного отошел от дел, всем занимается мой друг Витя. У него прекрасный стиль, мне очень нравится как он пишет. Иногда мы собираемся и понимаем, что мы не читали за прошедшую неделю ничего нового :) Видимо, немного устали. Последнее, о чем я слышал - это Rollup. На мой взгляд, там нет ничего революционного, но посмотреть интересно. Движение в сторону умных бандлеров, правильной сборки зависимостей я считаю очень важным, это хорошее направление. Хотя нельзя сказать, что это rocket science. Во-вторых, компонентный подход. Он пришел давно, все его приняли, и это здорово. В-третьих, FRP. В этом вопросе есть большая пропасть между теорией и практикой. Наверняка что-то появится, чтобы ее преодолеть. Возвращаясь к вопросу о рельсе как фреймворке и к фронту. Что бы ты добавил а рельсу или убрал из нее, с точки зрения фронтенд разработки? Может вообще убрал бы фронт из рельсы? Я бы не убирал фронт. Мне кажется, решение которые есть сейчас, позволит нам выжить в 80% проектов, по крайне мере таких, которые есть на рынке. Ингода очень удобно иметь такой функционал. Даже когда мы говорим о сборке файлов, которая на самом деле не сборка, а просто конкатенация в правильном порядке. Я считаю, что это плохо. Я слышал, что не любят турболинкс, хотя я к ним отношусь вполне нормально, использую их в некоторых проектах. Да, иногда приходится потратить много времени на то, чтобы сообразить, как все правильно делать. Но это приучает к порядку. Мне было проще: я не писал скрипты, я сразу начал писать single page applications. Приходилось думать о том, как выделять ресурсы, как их правильно тушить, о сервисах, о жизненном цикле приложения, о том, что оно может работать продолжительно время. Когда ты делаешь простой мультистраничный сайт с вкраплением скриптов, ты об этом не задумываешься. Но иногда проект требует того, чтобы все это учитывалось, заставляет держать в голове паттерны, которым нас научил правильный фронтенд. Не знаю, что я бы добавил прямо в рельсы. Есть тенденция выкидывать все ненужное, облегчать, оставлять рельсы только для API. Правильно? Там есть отдельная ветка, связанные именно с Rails API разработкой, отключением ненужных вещей. Да, это касается и сборки. Если ты запускаешь рельсовый проект, наверное было бы здорово уметь как-то управлять процессами, которые запускаются. Сейчас это не просто rails сервер, или какой-нибудь Sidekiq. Было бы клево уметь мониторить процессы, которые запускаются для сборки, которые Node.js-процессы запускаются. Было бы круто что-то такое придумать. Хотя и здесь можно в принципе предложить решения вроде Foreman или Hivemind. Раз мы начали говорить про инструменты: за какими ты сейчас следишь? Какие проекты тебе нравятся, на какие стоит обратить внимание? В некоторых случаях я пользуюсь Webpack, меня он вполне устраивает. Я понимаю весь юмор, который стоит за тем, что у него сложная конфигурация. Мне кажется главной концепция, что модули это клево. Я долго пользовался сборщиком Brunch. Его всегда обходили стороной, он оставался в тени. Но для меня это идеальный инструмент, когда нужно что-то очень быстро накидать, когда нужны просто модули в стиле common js, когда нужна очень быстрая сборка. Потому что он действительно работает очень быстро. Меня поразило, что многие ребята, которые делают фреймворки, начинают лепить boilerplate и command line tools, например Ember CLI, или штука для React, которая появилась недавно. В случае с Ember меня поразило то, что ты очень жестко привязан к сборщику, ты не можешь выбрать другой сборщик кроме Broccoli (который я тогда вообще не смог настроить, и он собирал все ну очень долго). По крайней мере, на моей машине это работало вечность. У меня был опыт работы с Ember, мы проект свой до конца собирали на Brunch. Даже учитывая то, что пришлось очень много портировать под себя, потому что все комьюнити перешло на Ember CLI и , мы все равно пользовались Бранчем, терпели. В нашем случае, мы пожертвовали удобством в пользу скорости и быстрой сборки, потому что у нас было много файлов и мы не могли себе позволить ждать вечность. Ты не пытался влиться в open source историю и начать помогать каким-то проектам? Если да, то куда ты коммитил? Да, у меня есть коммиты. Я бы не назвал себя активным контрибьютором. Коммитил во фронтендовые проекты на уровне мелких пулреквестов. У меня есть несколько своих open source проектов (если можно так сказать). Возможно, они не очень интересны, не получили много звездочек на гитхабе, но все же. Я писал враппер для работы с принтерами под Node.js, для одного из моих хобби-проектов. Я делал что-то вроде распределенной печати фотографий из Инстаграма, нашел прикольный маленький принтер для фотографий и подключил его к Raspberry. Благо на Raspberry работал Node.js, пришлось его собирать. Написал что-то вроде агентной системы (не знаю, правильный это термин или нет). Идея была в том, чтобы подключать такие принтеры-устройства и потом печатать фотографии на произвольной станции. Все это легло в основу моего дипломного проекта, который я полностью выложил на гитхаб, я этим в какой-то степени горжусь. Иметь гитхаб это здорово, и использовать его для образования тоже. Вообще дипломный проект получился довольно прикольный. Где ты берешь информацию о фронте: ресурсы, твиттер-аккаунты, за которыми ты следишь, новостные сайты? Про Ruby мы все знаем куда смотреть, на что подписаться, а с фронтовой частью лично у меня с ходу ничего не приходит на ум На первом месте для меня стоит Code Hipsters. Даже если если я не читаю статьи, не ищу их, я все равно пользуюсь телеграмом и читаю канал Code Hipsters c огромным удовольствием. Конечно, я немного по-другому его воспринимаю, потому что это мои друзья. Еще? Твиттер, особенно англоязычный помогает. Не назову какие-то конкретные аккаунты, это накопившийся за долгие годы слой информации. Иногда ты можешь листать ленту, и если произошло что-то действительно трендовое во фронтенде - ты это сразу увидишь, все лента будет заполнена этим. Еще мне нравятся подкасты. Я слушаю Вебстандарты. Кстати, в недавнем выпуске они спрашивали, кто какие подкасты слушает - оказалось, что никто ничего не слушает :). FrontFlip, наверное? Нет, не пошло, вообще не получается слушать русскоязычные подкасты. Я слушаю The Changelog, еще мне нравится подкаст от Thougtbot. Еще Giant Robots, мне очень нравится стиль, атмосфера. Обычно это два спикера, и создается впечатление, что они просто встречаются на выходных, обсуждают, что у них произошло, забывают что есть тема для подкаста. Но это все равно интересно слушать. Это даже два подкаста, один скорее про бизнес (это подкаст от одного из создателей foreign key и еще какой-то платформы. А про разработку это подкаст парня который тоже будет на RailsClub, который поддерживает Phoenix для Elixir. А про фронтенд это The Changelog. О чем ты будешь рассказывать на RailsClub нам, бэкенд разработчикам? О том, что фронтенд ускакал далеко и фреймворк за этим не поспевает. Я буду рассказывать о том, как собирать фронтенд в окружении рельс, какие есть решения, какие есть проблемы. И почему это на самом деле нужно. Буду стараться опираться на свой личный опыт. Как я понимаю, ты не был раньше на RailsClub. Что ты ждешь от конференции? Много интересных знакомств. Я бы хотел увидеть много ребят с горящими глазами. Да и вообще ребят, которые готовы пообщаться, не только на тему конференции. Конференции интересны людьми. У меня была интересная ситуация: в прошлом году мы поехали на Frontend Union Conf, она была в прошлом августе в Москве, в этом где-то в Прибалтике. Мы приехали всей тусовкой, но так устали с дороги, что очень сложно было поймать волну докладов, мы слушали одним ухом. Драйв начался на афтепати. Мы познакомились с парнем из SoundCloud Jan Monschke. Я не помню, какой у него был доклад, но общение после конференции запомнилось. Он клевый чувак, рассказал нам про свои проекты. Речь зашла о Brunch, сборщике о котором я уже говорил. И выяснилось, что он был одним из чуваков, которые начали этот проект. Да ладно!? Это именно то, для чего нужно ехать на конференции: общение. Ну и доклады тоже :) Помимо разработки, чем ты увлекаешься? Читаешь, поешь, играешь на чем-то, ходишь в горы? Сode Hopsters, хотя это скорее связано с работой. Я могу сказать, что меня вдохновляют (и в работе, и в жизни) многие вещи, которые я узнал когда был ребенком. В детстве мне нравились всякие штуки, механизмы. У меня была небольшая мастерская, в которой я делал из дерева всякие луки, арбалеты. К сожалению, у меня не было наставника, который показал бы как можно подключить все это к электричеству, как делать более продвинутые штуки. Когда-то я наткнулся на книгу, которая называется Код, ее написал Charles Petzold. Книга была интересна тем, что рассказывала о детстве: представьте себе, что у вас есть друг, вы живете в домах напротив. И вы захотели общаться, подавая друг другу тайные знаки. Вы достаете фонарик, начинаете рисовать на стене его дома буквы. Потом он плавно переходит к кодам и азбуке Морза, азбуке Брайля, рассказывает про телеграф. Если ты хочешь делать телеграфную связь, то тебе нужен повторитель, а повторитель можно сделать на основе реле… И тут начинается самое интересное. По книге можно сделать всякие logiс gate и тд. Спойлер: книга заканчивается тем, что он показывает как на ассемблере писать прототип операционной системы. Эта книга - идеальное описание того, что меня вдохновляет, вот такие мысленные эксперименты. Еще мне нравится, когда код как-то переплетается с дизайном. Могу посоветовать книгу “ The Nature of Code”, она написана обычным языком, но показывает как писать processing, как моделировать натуральные системы, типа стаи птиц и так далее. Такие вещи меня сильно вдохновляют. Я думаю, это в какой-то степени определяет то, какой я разработчик, то, как я работаю и живу. Сколько у тебя проектов и какой ты сейчас используешь фронтенд стек? Говорить про текущее время сложно: у меня этап, когда я пытаюсь все закрыть. Могу рассказать про то, чем я пользуюсь в реальной жизни. Все зависит от задач, я пытаюсь быть максимально гибким, на благо команды, с которой работаю, и на благо клиента. Если я понимаю, что проект с большим количеством состояний, не требует сильной интерфейсной логики, то почему бы не сделать его multipage, почему бы не сделать его на рельсах, в них все для этого есть. Если вдаваться в подробности, то я пользуюсь Slim, пишу на SCSS. Я заметил, что когда долго пишешь single page приложения, фронтенд меняет тебя. У нас был сложный проект: отдельный бэкенд и много single page приложений. Все они были написаны на ember.js. Вообще у ember интересный путь, от момента как созрела идея, до момента когда вокруг него начало появляться комьюнити и он начал тягаться с react по производительности. Я очень доволен этим фреймворком, в нем все есть для быстрого старта. Какие-то вещи смущают, особенно это касается Convention Over Configuration. Ребята, которые делали Ember (Ехуда Кац из Rails Core Team), вдохновлялись рельсами и постарались перенести много принципов. Мне кажется, что не все получилось здорово. Convention Over Configuration во фронтенд проектах, на мой взгляд, - это очень сомнительно. Мне проще написать больше фронтового кода, чем полагаться на какие-то вещи, которые встроены во фреймворк. С другой стороны, очень много удобных help'еров, можно быстро стартовать проект и так далее. Возвращаясь к теме multipage. Я заметил за собой, что на рельсовых проектах, которые не используют внешний сборщик, а полностью полагаются на assets pipeline, я начинаю организовывать свои фронтендные файлы в какую-то структуру, писать сервисы, организовывать все в некое подобие view. Хотя это просто чистые ES6 классы, которые получают в конструкторе рутовую ноду, от которой можно работать. Такой облегченный backbone view, но только без всего, просто для изоляции. Я думаю, что это хорошая тенденция. Это позволяет и кодовую базу держать в хорошем состоянии, и избегать эффектов, которые часто вылезают при ее разрастании. Сейчас идет какое-то противоборство Angular и React. Ты на чьей стороне, на темной или на светлой? И что есть темная, а что есть светлая? С Angular я практически не работал. Понимаю, к чему ты клонишь, но об этом сложно рассуждать. Я считаю, что эти споры лишены смысла. Не нужно искать кто главный, кто прав, кто нет. Нужно понимать, кто в какой ситуации хорош, где что лучше использовать. Если будет приложение, в котором я буду видеть четкую структуру, переходы, роуты, авторизацию, загрузки и так далее - я, наверное, положился бы на Angular. Хотя в глаза его никогда не видел, но я предполагаю, что там очень много поддержки для таких вещей. Если бы нужно было писать какой-то виджет, встраиваемую часть, какое-то простое приложение, с небольшим количеством состояний, в этом случае, наверное, выберу React. Я не стал бы ориентироваться на измерения производительности и какие-то фичи типа серверсайд рендеринга. Я считаю, что эти вопросы слишком много обсуждают, серверсайд рендеринг того не стоит. В реальности это нужно в 10% случаев, по крайней мере, мне так кажется. Поэтому я бы смотрел на те вещи, которые фреймворк предлагает: на то, что будет полезно для команды, для всего проекта, для компании. То есть ты занимаешь в этой войне нейтралитет? Да! Если бы меня попросили посоветовать что-то следующему поколению, я бы посоветовал прочитать интересную статью про то, каково быть 40-летним разработчиком. Автор очень интересно рассказывает про всю свою жизнь, чему его научила работа больше чем в 10 компаниях. Он говорит очень важную мысль: не полагайтесь на хайп, это ложное чувство, старайтесь смотреть на все трезвым взглядом. Оценивайте, не полагаясь на кратковременные чувства. Я считаю, это очень мудро. Я бы тоже хотел придерживаться такой позиции. Мы выражаем огромную благодарность Лене Могильниковой за помощь с организацией этого выпуска.

Новости Phusion Passenger 4.0.14 Гем для того, чтобы делать необычные отметки в коде Своя игра в Ruby Ускорение гема contracts.ruby PostGIS и Rails Параллельный bundler Local path в бандлер Ускоряем загрузку рельс Книга про платежи в Ruby Вышла книга «Confident Ruby» Permit в Rails Тестирование Rails API Полнотекстовый поиск в PostgreSQL Ускоряем прогон тестов Обсуждение Обучающий курс Brainwashing по DevOps от «Экспресс 42» 21 и 22 сентября Конференция RailsClub будет 28 сентября Эрик Ходл — мейнтейнер RubyGems и RDoc Фредерик Чанг — 35 коммитер в рельсы Билеты на railsclub уже продаются, скидка 500 рублей — промокод «rubynoname» Gem whenever — генератор crontab Gem thinking_sphinx — генератор конфигурации для sphinx из rails

Новости Why Nobody Should Use Rails For Anything Page Object Model DSL for Capybara Verbal Expression Расширение core классов - плохо Github trending page Создание конкурентных индексов в Rails Ruby 2.0 что нового? Фотошоп на Руби Тьюнинг Rails API Мысли о непрерывной поставке ПО Обсуждение Интервью с Ильей Зыкиным Гитхаб Ильи Гем the_sortable_tree Гем the_role Гем the_comments Илья просил всех новичков не стесняться и стучать ему в скайп: ilya.killich Остальное Обучающий курс Brainwashing по DevOps от «Экспресс 42» 21 и 22 сентября Конференция RailsClub будет 28 сентября Билеты на railsclub уже продаются, скидка 500 рублей — промокод «rubynoname» Статья Олега Бартунова о hstore Доклад Ивана Евтуховича в Ульяновске про Hstore в AR Проект Vagrant Конференция Highload

It is often asked: Is Rails a good fit if I only need to serve an API? In this episode I show how to use the Rails API gem to create a slimmer Rails application designed to respond with JSON.

It is often asked: Is Rails a good fit if I only need to serve an API? In this episode I show how to use the Rails API gem to create a slimmer Rails application designed to respond with JSON.

The Rails API docs are very useful but can be difficult to read. This episode will give some tips on reading the docs and mention a few alternative sites for accessing the API. Update: sorry about the broken movie, it should work now.

The Rails API docs are very useful but can be difficult to read. This episode will give some tips on reading the docs and mention a few alternative sites for accessing the API. Update: sorry about the broken movie, it should work now.