Podcasts about webpacker

In this episode, Jason and Chris welcome DHH, who joins them after the recent Rails World event. They cover a wide range of topics from the Rails Foundation's mission to attract new talent to open source misconceptions, the value of open source contributions as gifts, and the importance of boundaries between contributions and vendor relationships.  DHH shares insights into his current projects, including “Prop Shaft” and “Skiff,” addressing deployment challenges and building static sites. [00:00:29] DHH describes the incredible energy and positive atmosphere at Rails World, emphasizing the importance of in-person gatherings. [00:05:02] A discussion comes up about the foundation's role in supporting open source and attracting sponsors like Shopify for the benefit of both the community and businesses.[00:11:54] DHH talks about the misconception that open source is primarily about unpaid labor and how it's important to avoid becoming an unpaid employee.[00:15:47] DHH announced in his keynote at Rails World seven new things coming out and he tells us some he most excited about.[00:20:00] DHH describes the development journey from initial concept to validating in production applications, extracting into a library or framework, and ultimately making it the default for broad use. [00:22:12] Jason asks about the static site work that DHH is thinking about, and he introduces a project he's working on called “Skiff,” built on top of Kamal for deploying static sites.[00:26:28] Chris brings up a question about when to build your own solutions or use existing ones, and DHH highlights that it depends on the domain and the impact it has on daily work. [00:29:30] DHH talks about the problems with the existing job running solution, Resque, and the need to maintain multiple gems to patch it. [00:34:46] Jason brings up Webpacker and DHH discusses his frustration with complex bundling systems like Webpacker and his eagerness to simplify them. [00:36:02] Chris talks about the concept of finding the right abstraction layer where there's a balance between providing a simple interface and allowing users to dig deep into specific features when necessary.[00:38:32] The importance of recognizing fundamental improvements like esbuild and adopting them is highlighted.[00:40:59] The conversation shifts to the maintenance of separate frameworks like Hotwire and Kamal, and the question of separate maintainer teams and regular Rails releases is brought up.[00:43:55] DHH describes Hotwire as a “two and a half party” with substantial development happening with Basecamp but contributions from a considerable external community.[00:45:14] DHH talks about the evolving nature of projects like Turbo and the need for experimentation to address real-world issues.[00:50:37] We end with DHH highlighting the inherent tension between project creators and users and clarifies that not all open source projects operate as democracies. Links:Jason Charnes TwitterChris Oliver TwitterAndrew Mason TwitterDHH TwitterRails World 2023 Opening Keynote-David Heinemeier Hansson (YouTube)The Rails FoundationHoneybadger Honeybadger is an application health monitoring tool built by developers for developers.Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.

[00:04:42] Jason and Andrew had an incident at work, they were bamboozled, and we find out what happened. [00:05:40] In other Ruby news, here is where the laughs begin…Andrew sent a picture to Jason declaring that an adult human hand can fit inside an eagle's talon. Is this true?[00:07:30] We find out what did Andrew do with code this week that was so terrible, and Andrew gives us an example of something he's had to do three times, and Chris explains his issue with physically printing a PDF to debug.  Chris mentions a previous episode with Cameron Dutro and the ttfunk gem.  [00:14:44] “Tech the Halls” is happening at Podia where they'll make some minor improvements to the app the last two weeks of the year, and Jason tells us how he finally went back to removing Webpacker work that he started two months ago.  [00:19:26] Chris tells us what he did with Stimulus imports stuff and then made the esbuild node module.[00:21:38] Jason brings up submitting and tells us about a function they use at Podia now where they look at form validity and using CSS will disable buttons if a form is not valid.  [00:22:37] Chris was searching for the issues about the form disabled stuff and found a PR that Sean Doyle made that is really cool and he explains it. Andrew gets triggered at something Jason said about Bootstrap. [00:29:25] The guys discuss building UI components, the React community doing a good job, and Jason thinks he should give Alpine a shot to see what happens. Speaking of Ruby, as part of Tech the Halls, Jason explains they've started to rename some models that have changed their domain naming in the past couple of years.[00:37:09] Andrew shares his thoughts on why bundle opening a gem should be the encouraged way to debug and he highly recommends using bundle open the next time you encounter an issue, and Chris shares some advice for juniors. Panelists:Jason CharnesChris OliverAndrew MasonSponsor:HoneybadgerLinks:Jason Charnes TwitterChris Oliver TwitterAndrew Mason TwitterDavid Attenborough WikipediaRemote Ruby Podcast-Episode 134: Kubernetes, JSX for Ruby, and more with Cameron Dutrottfunk 1.1.1Hotwired Turbo-pull request-Toggle [disabled] on form submitter #386 (Sean Doyle)Tip: Search and debug gems with ‘bundle open' (Boring Rails)Ruby Radar NewsletterRuby Radar TwitterRuby for All Podcast

[00:00:56] Jason did his Hanami livestream on Twitch, he explains the app he built, how Hanami brought in 2 people from the dry-rb team who brought their ideas from there and rom-rb. Also, what's so cool about Hanami 2.0?[00:06:45] Dry-rb gems are so nice and the guys discuss what they like about them. [00:08:25] Find out why Andrew became a Twitch mod for Jason. [00:09:59] Jason mentioned earlier that the parameters are done at the controller level, and he explains how Laravel does the same thing. He also explains a problem he runs into with validation context in Rails and a Twitter conversation about Rails validations. [00:17:20] Back to Hanami being fun, Jason talks about the model level being fun too, and he explains ROM, Ruby Object Mapper. [00:20:06] Have you heard about Tilt? Andrew knows about it because Bridgetown uses it and Jason just learned about it. The creators of Hanami showed up at the livestream and it felt like a community event with a lot of good energy.[00:24:43] Jason brings up something that happened with Elixir, Phoenix, and working with ROM and Changesets.[00:27:09] The guys discuss Twitch and encourage everyone to check out Hanami, because you could definitely learn some new things. [00:31:16] Andrew reveals they've been working on some advanced and cool filtering and segmentation options in their audience table at Podia, and if you're a Podia creator you should check it out.  [00:37:54] Jason and Andrew are having a hack month in December at Podia, and they'll be moving a soft Webpacker to esbuild, along with doing a lot of tech improvements. Jason explains a hack he's been working on that was converted to esbuild and issues he's had with it.[00:41:38] Chris and Jason got challenged to write a frontend view in Hotwire to put it up against the React view, so they'll be working on that.[00:42:23] Jason poses one last question and a statement before they sign off that has to do with developers and Tailwind CSS…Here we go… Panelists:Jason CharnesChris OliverAndrew MasonSponsor:HoneybadgerLinks:Jason Charnes TwitterChris Oliver TwitterAndrew Mason TwitterHanamiTwitchdry-rbrom-rbTilt-GitHubRuby Radar NewsletterRuby Radar TwitterRuby for All Podcast

[00:07:35] Andrew shares a free gem idea for Juniors or people who've never built a gem before. [00:10:20] Jason brings up a previous episode with Konnor Rogers where they talked about migrating Podia off Webpacker, and the guys chat more about that.[00:17:56] Jason was looking something up for JavaScript and he tells us he couldn't get Google to give him any results that weren't for jQuery, and Chris talks about the interesting idea that Rails could sort of simplify Webpack with Webpacker, which they've done with jQuery, Prototype, and Scriptaculous.[00:20:35] We hear about why CoffeeScript was such a welcomed flavor of JavaScript.[00:22:23] Chris tells us what you can do using the railsassets.org site. [00:26:07] Andrew fills us in on his new podcast, Ruby for All, that he's co-hosting with Julie, that's aimed at providing something specifically for Junior Rails Developers or people getting into Rails.  [00:27:49] We find out some things that have been difficult and things Andrew forgot about with starting a podcast. [00:31:57] In case you haven't listened to the first episode yet, Andrew explains the focus of the podcast which is full of honest conversations and advice. [00:38:50] Chris shares a George Jetson announcement and a great idea for a new gem name.Panelists:Jason CharnesChris OliverAndrew MasonSponsor:HoneybadgerLinks:Jason Charnes TwitterChris Oliver TwitterAndrew Mason TwitterRemote Ruby-Episode 189: Joined by Konnor RogersYou might not need jQueryRails AssetsRuby for All PodcastRuby for All Podcast TwitterRuby Radar NewsletterRuby Radar Twitter

Chris talks about a small toy app he maintains on the side and working with a project called capybara_table. Steph is getting ready for maternity leave and wonders how you track velocity and know if you're working quickly enough? They answer a listener's question about where to get started testing a legacy app. This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. jnicklas/capybara_table: (https://github.com/jnicklas/capybara_table) Capybara selectors and matchers for working with HTML tables Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: CHRIS: Just gotta hold on. Fly this thing straight to the crash site. STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. CHRIS: And I'm Steph Viccari. STEPH: And together, we're here to share a bit of what we've learned along the way. I love that you rolled with that. [laughs] CHRIS: No, actually, it was the only thing I could do. I [laughs] was frozen into action is a weird way to describe it, but there we are. STEPH: I mentioned to you a while back that I've always wanted to do that. Today was the day. It happened. CHRIS: Today was the day. It wasn't even that long ago that you told me. I feel like you could have waited another week or two. I feel like maybe I was too prepared. But yeah, for anyone listening, you may be surprised to find out that I am not, in fact, Steph Viccari. STEPH: And they'll be surprised to find out that I actually am Chris Toomey. This is just a solo monologue. And you've done a great job of two voices [laughs] this whole time and been tricking everybody. CHRIS: It has been a struggle. But I'm glad to now get the proper recognition for the fact that I have actually [laughs] been both sides of this thing the whole time. STEPH: It's been a very impressive talent in how you've run both sides of the conversation. Well, on that note, [laughs] switching gears just a bit, what's new in your world? CHRIS: What's new in my world? Answering now as Chris Toomey. Let's see; I got two small updates, one a very positive update, one a less positive update. As is the correct order, I'm going to lead with the less positive thing. So I have a small toy app that I maintain on the side. I used to have a bunch of these little purpose-built singular apps, typically Rails app sort of things where I would play with a new technology, but it was some sort of like, oh, it's a tracker. It's a counter. We talked about breakable toys in the past. These were those, for me, serve different purposes, productivity things, or whatever. But at some point, I was like, this is too much work, so I consolidated them all. And I kept like, there was a handful of features that I liked, smashed them all together into one Rails app that I maintain. And that's just like my Rails app. It turns out it's useful to be able to program the internet. So I was like, cool, I'll do that for myself. I have this little app that I maintain. It's got like a journal in it and other things. I think I've talked about the journal in the past. But I don't actually take that good care of it. I haven't added any features in a while. It mostly just does what it's supposed to, but it had...entropy had gotten the better of it. And so, I had a very small feature that I wanted to add. It was actually just a Rake task that should run in the background on a schedule. And if something is out of order, then it should send me an email. Basically, just an update of like, you need to do something. It seemed like such a simple task. And then, oh goodness, the failure modes that I fell into. First, I was on Heroku-18. Heroku is currently on their Heroku-22 stack. 18 being the year, so it was like 2018, and then there's a 2020 stack, and then the 2022. That's the current one. So I was two stacks behind, and they were yelling at me about that. So I was like, okay, but whatever. Can I ignore that for a little while? Turns out no, because I couldn't even get the app to boot locally, something about some gems or some I think Webpacker was broken locally. So I was trying to fix things, finally got that to work. But then I couldn't get it to build on CircleCI because Node needed Python, Python 2 specifically, not Python 3, in order to build Node dependencies, particularly LibSass, I want to say, or node-sass. So node-sass needed Python 2, which I believe is end of life-d, to build a CSS authoring tool. And I kind of took a step back at that moment, and I was like, what did we do, everybody? What is going on here? And thankfully, I feel like there was more sort of unification of tools and simplification of the build tool space and whatnot. But I patched it, and I fixed some things, then finally I got it working. But then Memcache wasn't working, and I had to de-provision that and reprovision something. The amount of little...like, each thing that I fixed broke something else. I was like, the only thing I can do at this point is just burn the entire app down and rebuild it. Thankfully, I found a working version of things. But I think at some point, I've got to roll up my sleeves some weekend and do the full Rails, Ruby, everything upgrade, just get back to fresh. But my goodness, it was rough. STEPH: I feel like this is one of those reasons where we've talked in the past about you want to do something, and you keep putting it off. And it's like, if I had just sat down and done it, I could have knocked it out. Like, oh, it only took me like 5-10 minutes. But then there's this where you get excited, and then you want to dive in. And then suddenly, you do spend an hour or however long, and you're just focused on trying to get to the point where you can break ground and start building. I think that's the resistance that we're often fighting when we think about, oh, I'm going to keep delaying this because I don't know how long it's going to take. CHRIS: There's something that I see in certain programming communities, which is sort of a beginner-friendliness or a beginner's mindset or a welcomingness to beginners. I see it, particularly in the Svelte world, where they have a strong focus on being able to pick something up and run with it immediately. The entire tutorial is built as there's the tutorial on the one side, like the text, and then on the right side is an interactive REPL. And you're just playing with the Svelte REPL and poking around. And it's so tangible and immediate. And they're working on a similar thing now for SvelteKit, which is the meta-framework that does server-side rendering and all the fancy stuff. But I love the idea that that is so core to how the Svelte community works. And I'll be honest that other times, I've looked at it, and I've been like, I don't care as much about the first run experience; I care much more about the long-term maintainability of something. But it turns out that I think those two are more coupled than I had initially...like, how easy is it for a beginner to get started is closely related to or is, you know, the flip side of how easy is it for me to maintain that over time, to find the documentation, to not have a weird builder that no one else has ever seen. There's that wonderful XKCD where it's like, what's the saddest thing on the internet? Seeing the question that you have asked by one other person on Stack Overflow and no answers four years ago. It's like, yeah, that's painful. You actually want to be part of the boring, mundane, everybody's getting the same errors, and we have solutions to them. So I really appreciate when frameworks and communities care a lot about both that first run experience but also the maintainability, the error messages, the how okay is it for this system to segfault? Because it turns out segfaults prints some funny characters to your terminal. And so, like the range from human-friendly error message all the way through to binary character dump, I'm interested in folks that care about that space. But yeah, so that's just a bit of griping. I got through it. I made things work. I appreciate, again, the efforts that people are putting in to make that sad situation that I experienced not as common. But to highlight something that's really great and wonderful that I've been working with, there is a project called capybaratable. capybaratable is the gem name. And it is just this delightful little set of matchers that you can use within a Capybara, particularly within feature spec. So if you have a table, you can now make an assertion that's like, expect the table to have table row. And then you can basically pass it a hash of the column name and the value, but you can pass it any of the columns that you want. And you can pass it...basically, it reads exactly like the user would read it. And then, if there's an error, if it actually doesn't find it, if it misses the assertion, it will actually print out a little ASCII table for you, which is so nice. It's like, here's the table row that I saw. It didn't have what you were looking for, friend, sorry about that. And it's just so expressive. It forces accessibility because it basically looks at the semantic structure of a table. And if your table is not properly semantically structured, if you're not using TDs and TRs, and all that kind of stuff, then it will not find it. And so it's another one of those cases where testing can be a really useful constraint from the usability and accessibility of your application. And so, just in every way, I found this project works so well. Error messages are great. It forces you into a better way of building applications. It is just a wonderful little tool that I found. STEPH: That's awesome. I've definitely seen other thoughtboters when working in codebases that then they'll add really nice helper methods around that for like checking does this data exist in the table? And so I'm used to seeing that type of approach or taking that type of approach myself. But the ASCII table printout is lovely. That's so...yeah, that's just a nice cherry on top. I will have to lock that one away and use that in the future. CHRIS: Yeah, really, just such a delightful thing. And again, in contrast to the troubles of my weekend, it was very nice to have this one tool that was just like, oh, here's an error, and it's so easy to follow, and yeah. So it's good that there are good things in the world. But speaking of good things, what's new in your world? I hope good things. And I hope you're not about to be like, everything's terrible. But what's up with you? [laughter] STEPH: Everything's on fire. No, I do have some good things. So the good thing is that I'm preparing for...I have maternity leave that's coming up. So I am going to take maternity leave in about four-ish weeks. I know the date, but I'm saying the ish because I don't know when people are listening. [laughs] So I'm taking maternity leave coming up soon. I'm very excited, a little panicked mostly about baby preparedness, because, oh my goodness, it is such an overwhelming world, and what everyone thinks you should or shouldn't have and things that you need to do. So I've been ramping up heavily in that area. And then also planning for when I'm gone and then what that's going to look like for the team, and for clients, and for making sure I've got work wrapped up nicely. So that's a big project. It's just something that's on my mind, something that I am working through and making plans for. On the weird side, I ran into something because I'm still in test migration world. That is one of like, this is my mountain. This is my Everest. I am determined to get all of these tests. Thank you to everyone who has listened to me, especially you, listen to me talk about this test migration path I've been on and the journey that it's been. This is the goal that I have in mind that I really want to get done. CHRIS: I know that when you said, "Especially you," you were talking to me, Chris Toomey. But I want to imagine that every listener out there is just like, aww, you're welcome, Steph. So I'm going to pretend for my own sake that that's what you meant by, especially you. It's especially every one of you out there in the audience. STEPH: Yes, I love either version. And good point, because you're right, I'm looking at you. So I can say especially you since you've been on this journey with me, but everybody listening has been on this journey with me. So I've got a number of files left that I'm working through. And one of the funky things that I ran into, well, it's really not funky; it was a little bit more of an educational rabbit hole for me because it's something that I hadn't considered. So migrating over a controller test over from Test::Unit to then RSpec, there are a number of controller tests that issue requests or they call the same controller method multiple times. And at first, I didn't think too much about it. I was like, okay, well, I'm just going to move this over to RSpec, and everything is going to be fine. But based on the way a lot of the information is getting set around logging in a user and then performing an action, and then trying to log in a different user, and then perform another action that was causing mayhem. Because then the second user was never getting logged in because the first user wasn't getting logged out. And it was causing enough problems that Joël and I both sat back, and we're like, this should really be a request back because that way, we're going through the full Rails routing. We're going through more of the sessions that get set, and then we can emulate that full request and response cycle. And that was something that I just hadn't, I guess, I hadn't done before. I've never written a controller spec where then I was making multiple calls. And so it took a little while for me to realize, like, oh, yeah, controller specs are really just unit test. And they're not going to emulate, give us the full lifecycle that a request spec does. And it's something that I've always known, but I've never actually felt that pain point to then push me over to like, hey, move this to a request spec. So that was kind of a nice reminder to go through to be like, this is why we have controller specs. You can unit test a specific action; it is just hitting that controller method. And then, if you want to do something that simulates more of a user flow, then go ahead and move over to the request spec land. CHRIS: I don't know what the current status is, but am I remembering correctly that the controller specs aren't really a thing anymore and that you're supposed to just use request specs? And then there's features specs. I feel like I'm conflating...there's like controller requests and feature, but feature maybe doesn't...no, system, that's what I'm thinking of. So request specs, I think, are supposed to be the way that you do controller-like things anymore. And the true controller spec unit level thing doesn't exist anymore. It can still be done but isn't recommended or common. Does that sound true to you, or am I making stuff up? STEPH: No, that sounds true to me. So I think controller specs are something that you can still do and still access. But they are very much at that unit layer focus of a test versus request specs are now more encouraged. Request specs have also been around for a while, but they used to be incredibly slow. I think it was more around Rails 5 that then they received a big increase in performance. And so that's when RSpec and Rails were like, hey, we've improved request specs. They test more of the framework. So if you're going to test these actions, we recommend going for request specs, but controller specs are still there. I think for smaller things that you may want to test, like perhaps you want to test that an endpoint returns a particular status that shows that you're not authorized or forbidden, something that's very specific, I think I would still reach for a controller spec in that case. CHRIS: I feel like I have that slight inclination to the unit spec level thing. But I've been caught enough by different things. Like, there was a case where CSRF wasn't working. Like, we made some switch in the application, and suddenly CSRF was broken, and I was like, well, that's bad. And the request spec would have caught it, but the controller spec wouldn't. And there's lots of the middleware stack and all of the before actions. There is so much hidden complexity in there that I think I'm increasingly of the opinion, although I was definitely resistant to it at first, but like, yeah, maybe just go the request spec route and just like, sure. And they'll be a little more costly, but I think it's worth that trade-off because it's the stuff that you're not thinking about that is probably the stuff that you're going to break. It's not the stuff that you're like, definitely, if true, then do that. Like, that's the easier stuff to get right. But it's the sneaky stuff that you want your tests to tell you when you did something wrong. And that's where they're going to sneak in. STEPH: I agree. And yeah, by going with the request specs, then you're really leaning into more of an integration test since you are testing more of that request/response lifecycle, and you're not as likely to get caught up on the sneaky stuff that you mentioned. So yeah, overall, it was just one of those nice reminders of I know I use request specs. I know there's a reason that I favor them. But it was one of those like; this is why we lean into request specs. And here's a really good use case of where something had been finagled to work as a controller test but really rightfully lived in more of an integration request spec. MIDROLL AD: Debugging errors can be a developer's worst nightmare...but it doesn't have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help you cut your debugging time in half. So why do developers love Airbrake? Well, it has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! Airbrake's debugging tool catches all your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. In addition to stellar error monitoring, Airbrake's lightweight APM enables developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps and includes modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. So head on over to airbrake.io/try/bikeshed to create your FREE developer account today! STEPH: Changing gears just a bit, I have something that I'd love to chat with you about. It came up while I was having a conversation with another thoughtboter as we were discussing how do you track velocity and know if you're working quickly enough? So since we often change projects about every six months, there's the question of how do I adapt to this team? Or maybe I'm still newish to thoughtbot or to a team; how do I know that I am producing the amount of work that the client or the team expects of me and then also still balancing that and making sure that I'm working at a sustainable pace? And I think that's such a wonderful, thoughtful question. And I have some initial thoughts around it as to how someone could track velocity. I also think there are two layers to this; there could be are we looking to track an individual's velocity, or are we looking to track team velocity? I think there are a couple of different ways to look at this question. But I'm curious, what are your thoughts around tracking velocity? CHRIS: Ooh, interesting. I have never found a formal method that worked in this space, no metric, no analysis, no tool, no technique that really could boil this down and tell a truth, a useful truth about, quote, unquote, "Velocity." I think the question of individual velocity is really interesting. There's the case of an individual who joins a team who's mostly working to try and support others on the team, so doing a lot of pairing, doing a lot of other things. And their individual velocity, the actual output of lines of code, let's say, is very low, but they are helping the overall team move faster. And so I think you'll see some of that. There was an episode a while back where we talked about heuristics of a team that's moving reasonably well. And I threw out the like; I don't know, like a pull request a day sort of thing feels like the only arbitrary number that I feel comfortable throwing out there in the world. And ideally, these pull requests are relatively small, individual deployable things. But any other version of it, like, are we thinking lines of code? That doesn't make sense. Is it tickets? Well, it depends on how you size your tickets. And I think it's really hard. And I think it does boil down to it's sort of a feeling. Do we feel like we're moving at a comfortable clip? Do I feel like I'm roughly keeping pace with the rest of the team, especially given seniority and who's been on the team longer? And all of those sorts of things. So I think it's incredibly difficult to ask about an individual. I have, I think, some more pointed thoughts around as a team how we would think about it and communicate about velocity. But I'm interested what came to mind for you when you thought about it, particularly for the individual side or for the team if you want to go in that direction. STEPH: Yeah, most of my initial thoughts were more around the individual because I think that's where this person was coming from because they were more interested in, like, how do I know that I'm producing as much as the team would expect of me? But I think there's also the really interesting element of tracking a team's velocity as well. For the individual, I think it depends a lot on that particular team and their goals and what pace they're moving at. So when I do join a new team, I will look around to see, okay, well, what's the cadence? What's the standard bar for when someone picks up a ticket and then is able to push it through? How much cruft are we working with in the codebase? Because then that will change the team's expectations of yes, we know that we have a lot of legacy code that we're working with, and so it does take us longer to get through things. And that is totally fine because we are looking more to optimize our sustainability and improving the code as we go versus just trying to get new features in. I think there's also an important cultural aspect. So some teams may, unfortunately, work a lot of extra hours. And that's something that I won't bend for. I'm still going to stick to my sustainable hours. But that's something that I keep in mind that just if some other people are working a lot of evenings or just working extra hours to keep that in mind that if they do have a higher velocity to not include that in my calculation as heavily. I also really liked how you highlighted that certain individuals often their velocity is unblocking others. So it's less about the specific code or features or tickets that they're producing, but it's how many people can they help? And then they're increasing the velocity of those individuals. And then the other metrics that unfortunately can be gamified, but it's still something to look at is like, how many hours are you spending on a particular feature, the tickets? But I like that phrasing that you used earlier of what's your progress? So if someone comes to daily sync and they mention that they're working on the same thing and we're on like day three, or four, but they haven't given an update around, like, oh, I have this new thing that I'm focused on, or this new area that I'm exploring, that's when I'll start to have alarm bells go off. And I'm like, okay, you've been working on the same thing. I can't quite tell if you've made progress. It sounds like you're still in the depths of the original thing that you were on a couple of days ago. So at that point, I'm going to want to check in to see how you're doing. But yeah, I think that's why this question fascinates me so much is because I don't think there's one answer that fits for everybody. There's not a way to tell one person to say, "Hey, this is your output that you should be producing, and this applies to all teams." It's really going to vary from team to team as to what that looks like. I remember there was one team that I joined that initially; I panicked because I noticed that their team was moving at a slower rate in terms of the number of tickets and PRs and stuff that were getting pushed up, reviewed, and then merged. That was moving at a slower pace than I was used to with previous clients. And I just thought, oh, what's going on? What's slowing us down? Like, why aren't we moving faster? And I actually realized it's just because they were working at a really sustainable pace. They showed up to the office. This was back in the day when I used to go to an office, and people showed up at like 9:00 a.m. and then 5:00 o'clock; it was a ghost town, and people were gone. So they were doing really solid, great work, but they were sticking to very sustainable hours. Versus, a previous team that I had been on had more of like a rushed feeling, and so there was more output for it. And that was a really nice reset for me to watch this team and see them do such great work in a sustainable fashion and be like, oh, yeah, not everything has to be a fire, not everything has to be rushed. I think the biggest thing that I'd look at is if velocity is being called into question, so if someone is concerned that someone's not producing enough or if the team is not producing enough, the first place I'm going to look is what's our priorities and see are we prioritizing correctly? Or are people getting pulled into a lot of work that's not supporting the priorities, and then that's why suddenly it feels like we're not producing at the level that we need to? I feel like that's the common disconnect between how much work we're getting done versus then what's actually causing people or product managers, or management stress. And so reevaluating to make sure that they're on the same page is where I would look first before then thinking, oh, someone's not working hard enough. CHRIS: Yeah, I definitely resonate with all of that. That was a mini masterclass that you just gave right there in all of those different facets. The one other thing that comes to mind for me is the question is often about velocity or speed or how fast can we go. But I increasingly am of the opinion that it's less about the actual speed. So it's less about like, if you think about it in terms of the average pace, the average number of features that we're going through, I'm more interested in the standard deviation. So some days you pick up a ticket, and it takes you a day; some days you pick up a ticket, and suddenly, seven days later, you're still working on it. And both at the individual level and at the team level, I'm really interested in decreasing that standard deviation and making it so that we are more consistently delivering whatever amount of output it is but very consistently doing that. And that really helps with our ability to estimate overall bodies of work with our ability for others to know and for us to be able to sort of uphold expectations. Versus if randomly someone might pick up a piece of code or might pick up a ticket that happens to hit a landmine in the code, it's like, yeah, we've been meaning to refactor that for a while. And it turns out that thing that you thought would be super easy is really hard because we've been kicking the can on this refactoring of the fundamental data model. Sorry about that. But today's your day; you lose. Those are the sort of things that I see can be really problematic. And then similarly, on an individual side, maybe there's some stuff that you can work on that is super easy for you. But then there's other stuff that you kind of hit a wall. And I think the dangerous mode to get into is just going internal and not really communicating about that, and struggling and trying to get there on your own rather than asking for help. And it can be very difficult to ask for help in those sorts of situations. But ideally, if you're focusing on I want to be delivering in that same pace, you probably might need some help in that situation. And I think having a team that really...what you're talking about of like, if I notice someone saying the same thing at daily sync for a couple of days in a row, I will typically reach out in a very friendly, collegial way, hey, do you want someone else to take a look at that with you? Because ideally, we want to unblock those situations. And then if we do have a team that is pretty consistently delivering whatever overall velocity but it's very consistent at that velocity, it's not like 3 one day and then 0, and then 12, and then 2; it's more of like, 6,5,6,5 sort of thing, to pick random numbers out of the air, then I feel so much more able to grow that, to increase that. If the question comes to me of like, hey, we're looking at the budget for the next quarter; do we think we want to hire another developer? I think I can answer that much more accurately at that point and say what do I think that additional individual would be able to do on the team. Versus if development is kind of this sporadic thing all over the place, then it's so much harder to understand what someone new joining that team would be able to do. So it's really the slow is smooth, smooth is fast adage that I've talked about in the past that really captured my mind a while back that just continues to feel true to me. And then yeah, I can work with that so much better than occasional days of wild productivity and then weeks of sadness in the swamp of refactoring. So it's a different way to think about the question, but it is where my mind initially went when I read this question. STEPH: I'm going to start using that description for when I'm refactoring. I'm in the refactoring swamp. That's where I'm spending my time. [laughs] Talking about this particular question is helping me realize that I do think less in terms of like what is my output in the strict terms of tickets, and PRs, and things like that. But I do think more about my progress and how can I constantly show progress, not just to the world but show it to myself. So if there are tickets that then maybe the ticket was scoped too big at first and I've definitely made some really solid progress, maybe I'm able to ship something or at least identified some other work that could be broken out, then I'm going to do that. Because then I want everybody to know, like, hey, this is the progress that was made here. And I may even be able to make myself feel good and move something over to the done column. So there's that aspect of the work that I focus on more heavily. And I feel like that also gives us more opportunities to then iterate on what's the goal? Like, we're not looking to just churn out work. That's not the point. But we really want to focus on meaningful work to get done. So if we're constantly giving an update on this as the progress that I've made in this direction, that gives people more opportunities to then respond to that progress and say, "Oh, actually, I think the work was supposed to do this," or "I have questions about some of the things that you've uncovered." So it's less about just getting something done. But it's still about making sure that we're working on the right thing. CHRIS: Yeah, it doesn't matter how fast we're going if we're going in the wrong direction, so another critical aspect. You can be that person on the team who actually doesn't ship much code at all. Just make sure that we don't ship the wrong code, and you will be a critical member of that team. But shifting gears just a little bit, we have another listener question here that I'd love to get into. This one is about testing a legacy app. So reading this question, it starts off with a very nice note to us, Steph. "I want to start by saying thanks for putting out great content week after week." We are very happy to do so." So a question for you two. I just took over a legacy Rails app. It's about 12 years old, and it's a bit of a mess. There was some testing in place, but it was completely broken and hadn't been touched in over seven years. So I decided to just delete it all. My question is, where do I even start with testing? There are so many callbacks on the models and so many controller hooks that I feel like I somehow need to have a factory for every model in our repo. I need to get testing in place ASAP because that is how I develop. But we are also still on Ruby 2 and Rails 4.0. So we desperately have to upgrade. Thanks in advance for any advice." So Steph, I actually replied in an email to this kind listener who sent this. And so, I definitely have some thoughts, but I'm interested in where would you start with this. STEPH: Legacy code, I wouldn't know anything about working in legacy code. [laughs] This is a fabulous question. And yeah, the response that you provided is incredible. So I'm very excited for you to share the message that you replied with. So I'm going to try not to steal any of those because they're wonderful. But to add to that list that is soon to come, often where I start with applications like these where I need some testing in place because, as this person mentioned, that's how they work. And then also, at that point, you're just scared to ship anything because you just don't know what's going to break. So one area that you could start with is what's your rollback strategy? So if you don't have any tests in place and you send something out into the world, then what's your plan to then be able to either roll back to a safe point or perhaps it's using feature flags for anything new that you're adding so that way you can quickly turn something on and off. But having a strategy there, I think, will help alleviate some of that stress of I need to immediately add tests. It's like, yes, that's wonderful, but that's going to take time. So until you can actually write those tests, then let's figure out a plan to mitigate some of that pain. So that's where I would initially start. And then, as for adding the test, typically, you start with testing as you go. So I would add tests for the code that I'm adding that I'm working on because that's where I'm going to have the most context. And I'm going to start very high. So I might have really slow tests that test everything that is going to be feature level, integration level specs because I'm at the point that I'm just trying to document the most crucial user flows. And then once I have some of those in place, then even if they are slow, at least I'm like, okay, I know that the most crucial user flows are protected and are still working with this change that I'm making. And in a recent episode, we were talking about how to get to know a Rails app. You highlighted a really good way to get to know those crucial user flows or the most common user flows by using something like New Relic and then seeing what are the paths that people are using. Maybe there's a product manager or just someone that you're taking the app over that could also give you some help in letting you know what's the most crucial features that users are relying on day to day and then prioritizing writing tests for those particular flows. So then, at this point, you've got a rollback strategy. And then you've also highlighted what are your most crucial user flows, and then you've added some really high level probably slow tests. Something that I've also done in the past and seen others do at thoughtbot when working on a legacy project or just working on a project, it wasn't even legacy, but it just didn't have any test coverage because the team that had built it before hadn't added test coverage. We would often duplicate a lot of the tests as well. So you would have some integration tests that, yes, frankly, were very similar to others, which felt like a bad choice. But there was just some slight variation where a user-provided some different input or clicked on some small different field or something else happened. But we found that it was better to have that duplication in the test coverage with those small variations versus spending too much time in finessing those tests. Because then we could always go back and start to improve those tests as we went. So it really depends. Are you in fire mode, and maybe you need to duplicate some stuff? Or are you in a state where you can be more considerate with your tests, and you don't need to just get something in place right away? Those are some of the initial thoughts I have. I'm very excited for the thoughts that you're about to share. So I'm going to turn it over to you. CHRIS: It's sneaky in this case. You have advanced notice of what I'm about to say. But yeah, this is a super interesting topic and one of those scary places to find yourself in. Very similar to you, the first thing that I recommended was feature specs, starting at that very high level, particularly as the listener wrote in and saying there are a lot of model callbacks and controller callbacks. And before filters and all of this, it's very indirect how this application works. And so, really, it's only when the whole thing is integrated together that you're going to have a reasonable sense of what's going on. And so trying to write those high-level feature specs, having a handful of them that give you some confidence when you're deploying that those core workflows are still working as expected. Beyond that, the other things that I talked about one was observability. As an aside, I didn't mention feature flags or anything like that. And I really loved that that was something you highlighted as a different way to get to confidence, so both feature flags and rollbacks. Testing at the end of the day, the goal is to have confidence that we're deploying software that works, and a different way to get that is feature flags and rollbacks. So I really love that you highlighted that. Something that goes really well hand in hand with those is observability. This has been a thing that I've been exploring more and more and just having some tooling that at runtime will tell you if your application is behaving as expected or is not. So these can be APM-type tools, but it can also be things like Sentry or Honeybadger error monitoring, those sorts of things. And in a system like this, I wouldn't be surprised if maybe there was an existing error monitoring tool, but it had just kind of decayed over time and now just has perhaps thousands of different entries in it that have been ignored and whatnot. On more than one occasion, I've declared Sentry bankruptcy working with clients and just saying like, listen; this thing can't tell us any truths anymore. So let's burn it down and restart it. So I would recommend that and having that as a tool such that much as tests are really wonderful before the code gets out there into the wild; it turns out it's only when users start using it that the real stuff happens. And so, having observability, having tooling in place that will tell you when something breaks is equally critical in my mind. One of the other things I said, and this is probably the spiciest take on my list, is questioning the trade-off space that you're in. Is this an application that actually has a relatively low defect rate that users use and are quite happy with, and expect that level of performance and correctness, and all of those sorts of things, and so you, frankly, need to be careful with it? Or, is it potentially something that has a handful of bugs and that users are used to a certain lower fidelity experience, let's call it? And can you take advantage of that if that happens to be true? Like, I would be very careful to break something that has never been broken before that there's no expectation of that. But if we can get away with moving fast and breaking things for a little while just to try and get ourselves out of the spot that we're in, I would at least want to consider that trade-off space. Because caution slows you down, it means that your progress is going to be limited. And so, if we're able to reduce the caution filter just a little bit and move a little bit more rapidly, then ideally, we can get out of this place that we're in a little more quickly. Again, I think that's a really subtle one and one that you'd have to get buy-in from product managers and probably be very explicit in the conversations and sort of that trade-off space. But it is something that I would want to explore if I found myself in this sort of situation. The last thing that I highlighted was the fact that the versions of Ruby and Rails that were listed in the question are, I think, both end of life at this point. And so from a security perspective, that is just a giant glaring warning sign in the corner because the day that your app gets hacked, well, that's a bad day. So testing, unfortunately, I think that's the main way that you're going to get by on that as you're going through upgrades. You can deploy a new version of the application and see what happens and see if your observability can get you there. But really, testing is what you want to do. So that's where building out that testing is all the more critical so that you can perform those security upgrades because they are now truly critical to get done. And so it gives sort of more than a nice to have, more than this makes me feel comfortable. It is pretty much a necessity if you want to go through that, and you absolutely need to go through the security upgrades because otherwise, you're going to get hacked. There are just automated scanners out there. They're going to find you. You don't need to be a high vulnerability target to get taken down on the internet these days. So if it hasn't happened yet, it's going to. And I think that's an easy business case to sell is, I guess, the way that I would frame it. So those were some of my thoughts. STEPH: You bring up a really good point about needing to focus on the security upgrades. And I'm thinking that through a little bit further in regards to what trade-offs would I make? Would I wait till I have tests in place to then start the upgrades, or would I start the upgrades now but just know I'm going to spend more time manual testing on staging? Or maybe I'm solo on the project. If I have a product manager or someone else that can also help the testing with me, I think I would go for that latter approach where I would start the upgrades today and then just do more manual testing of those crucial flows and then have that rollback strategy. And as you mentioned, it's a trade-off in terms of, like, how important is it that we don't break anything? CHRIS: I think similar to the thing that both of us hit on early on is like, have some feature specs that just kick the whole application as one connected piece of code. Have that in place for the security upgrade, testing. But I agree, I wouldn't want to hold off on that because I think that's probably the scariest part of all of this. But yeah, it is, again, trade-offs. As always, it depends. But I think those are my thoughts. Anything else you want to add, Steph? STEPH: I think those are fabulous thoughts. I think you covered it all. CHRIS: Sounds good. Well, in that case, should we wrap up? STEPH: Let's wrap up. CHRIS: The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeeee!!!!!!!! ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Oh man, my audio quality is AWFUL here. Luckily Ross's is better and he's great at carrying the conversation! We talk about how Ross "cheats" both to get into teaching and to get into tech, and about some overlap between the two -- we talk about Seymour Papert, of course. Later we get into different paradigms of programming and what you learn from them, as well as the balance between being a generalist and a specialist. Ross has done a lot with WebPacker -- WebPacker and the asset pipeline are a lot like Bundler as a way to control the Wild West of dependency management. For show notes and links, see: http://justtheusefulbits.com/jtub/ross-kaffenberger-teaching-webpacker-and-paradigms/

Welcome to Remote Ruby and thanks for joining us!  We've been trying to have our guest on for a really long time, and that time is here folks!  Today, we're joined by Konnor Rogers, a Developer at Microsoft known for his knowledge of all things front-end. On this episode, we'll hear Konnor's journey from being an EMT, getting into tech, and Andrew introducing him to Snowpack. Konnor tells us more about a new JavaScript runtime called Bun, his go-to Vite Ruby, and using Import Maps as a start tool.  The guys have some deep conversations about ESBuild, Webpack, Webpacker, Web Components, and the new Lit Web Component. Also, there's some great Web Components on GitHub that are mentioned, as well as a cool package called Catalyst.  And if you're a Junior Developer, Konnor, Jason, and Andrew share some important tips that may help with your journey in finding a job.  Download this episode now![00:04:58] We find out when Konnor first met Andrew. [00:08:02] Konnor fills us in on his first job leading into what he's doing now.[00:09:54] We hear about Konnor's journey with Andrew introducing him to Snowpack.[00:14:12] Konnor tells us about a new JavaScript runtime called Bun, what he does when he spins up a Rails Project, and his go-to these days which is Vite Ruby.[00:16:52] The guys chat about ESbuild, Webpack, and Webpacker.[00:22:44] How important is it to target ES5?[00:27:36] Konnor shares his thoughts on something Jason brings up with splitting out the CSS part of things to be a separate process and letting a bundler just bundle JavaScript.[00:31:34] Konnor tells us more about Import Maps.[00:34:58] The conversation takes a turn to Web Components, what a Web Component is, and we hear about the new Lit Web Component.   [00:38:24] If you want to get more Lit, find out how to start, and what you would use the Web Component for. [00:41:02] If you want to install a package, add a custom element and it's there, and you can style it, Andrew wonders how Rails Developers can start taking advantage of this or if it's something we should continue to watch. ,[00:43:09] Andrew mentions a bunch of Web Components on GitHub that are being used by a lot of people, and Konnor tells us about a package they have called Catalyst.[00:46:24] Konnor explains how his experience with Web Components helped him with getting a job at Microsoft, and Andrew shares advice on finding a job. [00:52:02] If you're a Junior Developer, Konnor, Jason, and Andrew share some fantastic tips for you. [00:58:12] Find out where you can follow Konnor on the internet.Panelists:Jason CharnesAndrew MasonGuest:Konnor RogersSponsor:HoneybadgerLinks:Konnor Rogers TwitterStimulus Reflex DiscordGoRails project DiscordRemote Ruby Podcast-Episode 122: Skypack and Snowpack with Fred SchottBunVite RubyEstimator-GitHub[Feature] alias option for path Resolve #38-esbuildLit Web ComponentsLitCatalyst-GitHubgithub-elementsRuby Radar NewsletterRuby Radar Twitter

Добрый день уважаемые слушатели. Представляем новый выпуск подкаста RWpod. В этом выпуске: Ruby Porting YJIT to Rust Webpacker has been retired Happy 10th Birthday, Sidekiq! Bad Ruby: Hash Value Omission Reduce your method calls by 99.9% by replacing Thread#pass with Queue#pop Lecter - show executable code by request OnlineMigrations - catch unsafe PostgreSQL migrations in development and run them easier in production PostgreSQL бесплатные книги Web Remix vs Next.js TypeScript Features to Avoid Replacing jQuery (110kb) With Umbrella JS (8kb) Vanilla List - a Directory of Vanilla JavaScript Plugins Open sourcing Chirpy CSS Fingerprint

[00:00:50] The guys chat about the new release of Turbo 7.0.1.[00:01:46] Chris tells us how he moved all of the GoRails, CSS, and JavaScript from Webpacker into CSS and JS bundling, and it went pretty smooth except for something dumb he did. [00:04:50] Propshaft is brought up and we learn what it does.  [00:08:44] Why do we need the hashes at the end? Andrew explains why it's all about caching. [00:11:08] Ryan Bates is mentioned since he commented on the Propshaft repo. Also, Ryan, if you are listening, we would love for you to be a guest on our show!  ☺[00:12:39] Hotwire is the topic here, and although it's been released, but not officially, Chris tells us some things that are noteworthy. Jason tells us more about the Stimulus 3 stuff and the ability to the callbacks on targets.[00:20:33] Chris shares something that happened when he was looking at fixing a few things with madmin.[00:24:41] Chris asks the guys if they've ever gone into the weeds on engines and initializers in them and all the different callbacks. [00:30:22] Andrew fills us in on what his experience has been like working with Engines in the past month and Chris tells us what his approach for Jumpstart Pro has been.[00:35:33] We hear a story from Chris when he was learning Rails, and he mentions using Lockbox.[00:38:46] Chris wonders if the guys started a PR for Rails 7, and Andrew tells us how it's going. [00:41:30] Since Jason is a Safari user, Chris wonders if he has run into the bug where the CSRF token or the hidden fields can get overridden by Safari and the guys chat about it. [00:45:52] Jason really wanted to talk about Phoenix LiveView because he read a bunch about it and he's super interested in it, but he's saving it for the next episode. Panelists:Jason CharnesChris OliverAndrew MasonSponsor:HoneybadgerLinks:Ruby Radar NewsletterRuby Radar TwitterTurbo 7.0.1 Propshaft-GitHubLockbox-GitHubAdd autocomplete= “OFF” to Firefox-proof automagically added hidden fields like _method #42610-GitHub

[00:03:38] Jason tells us about an interesting project he's been working on this week with a Mockup Generator, and he's on the Ruby side of it now. He tells us how he's rendering the images on top of each other with a React component called Design.[00:09:29] Andrew asks Jason what happens if you have a P and G layer on top of a JPEG. Chris wonders if Jason is doing the commands with image processing, MiniMagick, or RMagick, and if he's doing all of them once or two at a time. Jason mentions looking into Cloudinary and Andrew gives a shout out to Cloudinary. [00:14:22] Find out what ImageMagick is and how magical it is. [00:15:56] Jason talks about hoping to put this project out soon, moving it off Webpacker to esbuild and Chris explains us how easy it was for him with Jumpstart to move everything over in an hour from Webpacker, to esbuild, and the CSS bundling.[00:25:41] The guys chat about the good laugh they had on Twitter about Rails 7. Andrew tells us he started the upgrade and he had a turbo links thing going on.  Jason tells us they haven't used Turbolinks at Podia but they're trying Turbo in certain parts of the app. [00:27:50] Chris asks Jason with the upgrade process and Turbo trying to take over all your forms and links if he's doing that piecemeal. Jason explains what Andrea came up with for them, and Andrew comments that is going to solve all his problems. ☺[00:31:06] Andrew announces he's been trying to get Konnor on this show for a while to talk about mru.js, so this is his invitation to come on! [00:35:00] We're taking the back roads to the end with the guys chatting about Mailchimp being sold for $12 billion to Intuit, hope that MicroConf happens next year, and why Jason thinks he lives in St. Louis, which has to do with him being on Reddit. Panelists:Jason CharnesChris OliverAndrew MasonSponsor:HoneybadgerLinks:Ruby Radar NewsletterRuby Radar TwitterRubyConf 2021ImageMagickRMagick-GitHubImageProcessing-GitHubCloudinaryThe Ruby on Rails Podcast-Episode 368: Frontend Bundlers & Snowpack with Konnor RogersTweet by Chris Oliver to Andrew and Jason about the upgradeMicroConf

Добрый день уважаемые слушатели. Представляем новый выпуск подкаста RWpod. В этом выпуске: Ruby Rails 7 adds support for ActiveStorage expiring URLs Error Highlight gem now in Ruby 3.1 The tale of Sprockets and Webpacker duality RSpec Negated Matchers Taylor - a small, free, and open source game engine Frak - a deployment tool that uses rsync to upload file changes to remote servers Web Q1K3-Quake in Javascript Small Bundles, Fast Pages: What To Do With Too Much JavaScript Accessible Palette: Create color systems with consistent lightness and contrast JSPaint.exe - as a cross-platform native desktop app Lowdb - simple to use local JSON database Tiny-sass-compiler - another SASS compiler written from scratch, runnable both in node and browser environment RWpod Cafe 26 (02.10.2021) Сбор и голосование за темы новостей

[00:03:52] Jason fills us in on how he's building a pretty heavy JavaScript tool, using Vite, and a problem he had.  [00:11:04] We learn about some PR's Jason around Webpacker on the GoRails discord  that had a solution for Jason's problem. [00:13:50] Chris talks about “esbuild for Rails” and other approaches that are coming out right now with DHH's latest stuff is fascinating. He also talks about Babel being a nightmare and  being able to do the Importmap Rails for Turbo and Stimulus that have hardly any dependencies is fantastic. [00:16:59] Chris wonders if the guys think it makes sense that esbuild Rails spits out the final file in the asset pipeline and an esbuild folder under assets, because those should be just .JS files, and if that's just going to be serving up basically Sprockets. [00:21:54] Tailwind CSS Rails gem is explained by Chris as to why it was written, and Andrew brings up about how Docker is going to start charging. [00:23:28] Chris goes into how classes are finally being fully supported which makes a big difference for organizing stuff and how it makes us appreciate what we've got with bundler and how good it's organized. Find out what he says about gems too.[00:25:15] Andrew asks the guys if they have set who their GitHub repos will be given to in the event of their untimely demise.[00:25:50] Jason is looking through the esbuild source code and tells us there's not much, which is super nice, and Andrew shares his BOLD advice. [00:27:25] The topic discussed here is putting Tailwind into esbuild and what to do, and Chris announces that Sass is being removed from Rails 7.[00:30:22] Andrew asks the guys how they felt when Sass was removed since they are “old” and wrote more Sass than Andrew ever did. [00:34:05] Listen to the end if you're in need for some good babble and laughs with the guys! ☺Panelists:Jason CharnesChris OliverAndrew MasonSponsor:HoneybadgerLinks:Ruby Radar NewsletterRuby Radar TwitterVite-GitHubImportmap for Rails-GitHubesbuild for Rails-GitHubSprockets-GitHubTailwind CSS for Rails-GitHub

[00:01:42] Last week the guys discussed using Inertia, and Jason tell us he's been doing more Inertia and messing with forms, “axios” is explained, and using validation.  [00:10:18] Jason talks about showing  some people what he's been doing with Inertia and someone asked him how he was going to handle flash. Jason tells us what he did, and Andrew shares some thoughts on this.[00:12:27] At Podia, Jason said they have a MutationObserver and what it does. Andrew tells us about the Shop Talk Show Podcast- Episode 471, where Dave Rupert talked about how a MutationObserver can lead to a memory leak.   [00:14:45] We find out that Jason decided to bite the bullet and keep going with Inertia on an app, wanting to use Tailwind UI and all that, what Webpacker 5 has, what it does, and Andrew explains why they had to add that.[00:20:24] Jason tells us about how Webpacker 6 seems less in your face, like verbose as Webpacker 5, and he asks Andrew if that makes sense and if he's wrong about that. Andrew explains that they took away a lot of the magic, and the magic is what made it work out of the box for an average use case, and it's really easy to understand now.[00:25:20] Jason pulls up the docs, he sees react is supported, you need to add relevant packages, so he added Babel preset react, but it didn't configure anything. He asks Andrew if Babel just knows and Andrew helps him out. [00:28:37] Jason brings up Webpacker and mentions Andrew's “7 Part Series” on Webpacker 6, and he asks him some questions about it.[00:31:32] Andrew informs us that RubyGems has a Guides tab and he explains what it does.[00:34:18] Andrew talks about a Tweet he got regarding a repo he made back in 2018, which had Rails 6, React, Webpacker, and Tailwind. Also, he highly recommends reading through some of the Webpack docs to help you understand Webpack since it can be super frustrating. [00:43:20] Andrew has a really serious and bold statement he makes that he just had to get out of his system! ☺Panelists:Jason CharnesAndrew MasonSponsor:HoneybadgerLinks:Ruby RadarRuby Radar TwitterAxios-GitHubShop Talk Show Podcast-Episode 471-Perf as a job, Riverside vs Streamyard, Frontend Being Consumed, and How Much to Bill ClientsMutationObserver opportunity for memory leak #482-GitHubTailwindcss-Enabling JIT modeWebpacker 6: Upgrade Guide-Andrew Mason Webpacker-GitHubWebpacker React-GitHubRubyGems GuidesTo Pineapple or To Not: A Pizza Debate (Spizzico Italian Kitchen)

[00:00:50] Andrew fills us in on the Ruby Radar stuff and if anyone is interested in being a part of it or helping out you can reach out to him!  [00:03:25] Andrew tells us about using elink which is like a bookmarking tool.[00:05:03] Chris tells us about doing email work for the job board he wants to set up and we find out what happens since it's been awhile that he did any CSS work in email.[00:07:32] Andrew explains what Maizzle does and how it works. [00:12:07] Chris tells us about Rails Request.JS which is a brand new Rails library.[00:16:13] We learn more about the WWW-Authenticate header.[00:23:42] Andrew talks about a really cool Web Component thing that Rails people like to use which is called Shoelace. He also mentions Lit and Bridgetown Quick Search plugin. [00:28:47] Andrew talks about working on multiple apps and building small web components to share that wraps all the JavaScript, and GitHub has a bunch of them such as element.  Chris talks about Local Time gem from basecamp and Andrew mentions using Design Tokens. [00:33:06] Andrew talks about struggling this week with remote JavaScript form stuff because he hasn't done it in a long time and he's using some existing code that he doesn't understand, and Chris shares some advice. [00:38:49] Chris brings up Rails 7 hoping it will be released soon, and he mentions the Rails scaffolds are not updates yet for using Hotwire and Andrew wonders if they are waiting for Webpacker 6 and he talks about issues with upgrading Webpacker 5 to 6 is a major version change.[00:48:25] There's a bunch of new stuff happening in Ruby and Andrew tells us all the new releases. He also mentions writing about Turbo is a really great thing to do right now because a lot of people are “thirstin' for some Turbo!” ☺[00:51:00] Chris talks about Jonathan Reinink, the “Inertia Guy,” and everything he's doing primarily in the Laravel world and how everything is Rails compatible too. Andrew mentions a podcast he listened to on The Bike Shed with Jonathan talking to Chris Toomey about Inertia, and how it sold Andrew on using the library. [00:54:12] We end with Andrew telling us a bit more about the Ruby Radar newsletter which they are trying to make it very “snack-sized.” ☺Panelists:Chris OliverAndrew MasonSponsor:HoneybadgerLinks: Ruby RadarRuby Radar TwitterelinkMaizzleRails Request.JSWWW-AuthenticateShoelaceLitBridgetown Quick Search plugin element extensions-GitHubLocal Time-GitHubUniversal Tokens for Tailwind-GitHubDesign TokensAwesome Design Tokens-GitHubWebpacker 6 Series Articles-Andrew MasonThe Bike Shed Podcast-Episode 291: All Things Inertia.js with Jonathan Reinink

Ariel Juodziukynas joins the Rogues to talk about how to upgrade your Ruby on Rails application from Sprockets to Webpacker. Sprockets was introduced in Rails 3.1 to help you manage your static assets including JavaScript. Webpack came along to help manage JavaScript and eventually other assets later on and was adopted into Rails in version 5 and is now the preferred way to manage JavaScript assets in Ruby on Rails applications. Ariel has written a guide on how to move from Sprockets to Webpacker and discussed with the Rogues the pros, cons, and pitfalls of such a move in your applications. Panel John Epperson Luke Stutters Guest Ariel Juodziukynas Sponsors Dev Influencers Accelerator Links Goodbye Dependabot Preview, hello Dependabot! How to Migrate your JavaScript from Sprockets to Webpacker Webpack VS Sprockets GitHub | fastruby/next_rails Phoenix.LiveView  Twitter: Ariel Juodziukynas ( @arieljuod ) Picks Ariel- GitHub | arielj/rails-new-app John- RailsBump John- Gas Powered Weed Whackers for Medium/Large Sized Yards Luke- All Ruby Books @ Planet Ruby Luke- The Rising Storm of Ethics in Open Source - Coraline Ada Ehmke

Ariel Juodziukynas joins the Rogues to talk about how to upgrade your Ruby on Rails application from Sprockets to Webpacker. Sprockets was introduced in Rails 3.1 to help you manage your static assets including JavaScript. Webpack came along to help manage JavaScript and eventually other assets later on and was adopted into Rails in version 5 and is now the preferred way to manage JavaScript assets in Ruby on Rails applications. Ariel has written a guide on how to move from Sprockets to Webpacker and discussed with the Rogues the pros, cons, and pitfalls of such a move in your applications. Panel John Epperson Luke Stutters Guest Ariel Juodziukynas Sponsors Dev Influencers Accelerator Links Goodbye Dependabot Preview, hello Dependabot! How to Migrate your JavaScript from Sprockets to Webpacker Webpack VS Sprockets GitHub | fastruby/next_rails Phoenix.LiveView  Twitter: Ariel Juodziukynas ( @arieljuod ) Picks Ariel- GitHub | arielj/rails-new-app John- RailsBump John- Gas Powered Weed Whackers for Medium/Large Sized Yards Luke- All Ruby Books @ Planet Ruby Luke- The Rising Storm of Ethics in Open Source - Coraline Ada Ehmke

Ariel Juodziukynas joins the Rogues to talk about how to upgrade your Ruby on Rails application from Sprockets to Webpacker. Sprockets was introduced in Rails 3.1 to help you manage your static assets including JavaScript. Webpack came along to help manage JavaScript and eventually other assets later on and was adopted into Rails in version 5 and is now the preferred way to manage JavaScript assets in Ruby on Rails applications. Ariel has written a guide on how to move from Sprockets to Webpacker and discussed with the Rogues the pros, cons, and pitfalls of such a move in your applications. Panel John Epperson Luke Stutters Guest Ariel Juodziukynas Sponsors Dev Influencers Accelerator Links Goodbye Dependabot Preview, hello Dependabot! How to Migrate your JavaScript from Sprockets to Webpacker Webpack VS Sprockets GitHub | fastruby/next_rails Phoenix.LiveView  Twitter: Ariel Juodziukynas ( @arieljuod ) Picks Ariel- GitHub | arielj/rails-new-app John- RailsBump John- Gas Powered Weed Whackers for Medium/Large Sized Yards Luke- All Ruby Books @ Planet Ruby Luke- The Rising Storm of Ethics in Open Source - Coraline Ada Ehmke

Chris and Andrew are here today, and we start with Chris telling us a story about his car fiasco that happened this past week with the DMV and the police showing up at his house but has a good ending! The guys dive into talking about Leftpad and the debacle that went down on Twitter with mimemagic. They also discuss the new version of Rails that was released, licenses and GPL packages, Andrew explains Vendor gems, Chris tells us about his talk at RailsConf 2021, and Rails 7 and Webpacker 6 are coming out soon as well. Also, there are a ton of Ruby meetups happening virtually and Andrew is speaking at one very soon!

Paweł Dąbrowski wrote a Deep Dive into Webpacker on his blog. He joins the Rogues to help the understand more of the ins and outs of Webpack and Webpacker for Ruby on Rails developers. He and the Rogues break down how to manage your JavaScript assets, how Webpacker thinks about them, and how to pull together a cohesive strategy for how to make JavaScript work in your Rails application. Panel Charles Max Wood John Epperson Luke Stutters Guest Paweł Dąbrowski  Sponsors Forest Admin Dev Heroes Accelerator Links GitHub | kirillian/shiplane Picks Charles- 16th Wedding Anniversary Charles- Gmelius Charles- Upper Deck Legendary: A Marvel Deck Building Game Charles- Logitech ERGO K860 Wireless Split Keyboard John- Baby Delight Snuggle Nest Dream Portable Infant Sleeper  Luke- Waveshare Paweł- Rails 6 and Stimulus.js - a quick launch 

Paweł Dąbrowski wrote a Deep Dive into Webpacker on his blog. He joins the Rogues to help the understand more of the ins and outs of Webpack and Webpacker for Ruby on Rails developers. He and the Rogues break down how to manage your JavaScript assets, how Webpacker thinks about them, and how to pull together a cohesive strategy for how to make JavaScript work in your Rails application. Panel Charles Max Wood John Epperson Luke Stutters Guest Paweł Dąbrowski  Sponsors Forest Admin Dev Heroes Accelerator Links GitHub | kirillian/shiplane Picks Charles- 16th Wedding Anniversary Charles- Gmelius Charles- Upper Deck Legendary: A Marvel Deck Building Game Charles- Logitech ERGO K860 Wireless Split Keyboard John- Baby Delight Snuggle Nest Dream Portable Infant Sleeper  Luke- Waveshare Paweł- Rails 6 and Stimulus.js - a quick launch 

Paweł Dąbrowski wrote a Deep Dive into Webpacker on his blog. He joins the Rogues to help the understand more of the ins and outs of Webpack and Webpacker for Ruby on Rails developers. He and the Rogues break down how to manage your JavaScript assets, how Webpacker thinks about them, and how to pull together a cohesive strategy for how to make JavaScript work in your Rails application. Panel Charles Max Wood John Epperson Luke Stutters Guest Paweł Dąbrowski  Sponsors Forest Admin Dev Heroes Accelerator Links GitHub | kirillian/shiplane Picks Charles- 16th Wedding Anniversary Charles- Gmelius Charles- Upper Deck Legendary: A Marvel Deck Building Game Charles- Logitech ERGO K860 Wireless Split Keyboard John- Baby Delight Snuggle Nest Dream Portable Infant Sleeper  Luke- Waveshare Paweł- Rails 6 and Stimulus.js - a quick launch 

Добрый день уважаемые слушатели. Представляем новый выпуск подкаста RWpod. В этом выпуске: Ruby Rails 6.1 allows per environment configuration support for Active Storage Rails 6.1 adds support for belongs_to to has_many inversing Rails has added a webpacker Guide IRB’s Built-in Measure An Unusual Performance Optimization How ActiveRecord Uses Caching To Avoid Unnecessary Trips To The Database Interesting throw/catch behaviour in Ruby 3 Practical Uses of Ruby’s method_missing You Should Know. Web How We Improved SmashingMag Performance An Introduction to the JavaScript Temporal API Running Rust in WebAssembly in a Pool of Concurrent Web Workers in JavaScript Forgo - a tiny UI runtime for modern web apps BrowserVM - an efficient X86-64 full-system emulator running in browsers Naming cheatsheet EStimator.dev: The Modern JavaScript Savings Calculator

Hello and welcome to Remote Ruby! Haml is life! There is talk of Andrew getting a HAML tattoo and “apparently” he’s agreed to it!

The gang is all here today and they have so much to talk about. Jason tells us he’s finally updated a Rails app he built in March and he did the Tailwind 2.0 update. Chris talks about patching Webpacker to fix the Webpack DevServer changes, and Andrew shares some info about why it may not have been working for him. Chris shares a fun fact about Rails Webpackers master version that may make you laugh! Other topics discussed are an issue Jason ran into with trying to get PurgeCSS working, the Ryan Bates DigitalOcean extravaganza/Tweet he made, Hatchbox and CableReady updates, the new release of Mac and the M1 chip, Hey is having a dumpster fire, and Andrew’s video trailer for Haml/ERB is premiering here today! You don’t want to miss it!

Chris and Andrew are here today! Chris starts off talking about going down the rabbit hole with their discussion last week about the Rails engines doc for Webpacker, and he finds out it is rough. We find out a problem Chris ran into with JavaScript and CSS to display graphs, installing Action Active Mailbox and a cool feature of Rails, which is ActiveModel. The discussion takes a turn into “Remote Ruby Therapy” for Andrew since he realizes this week that he is completely burned out and he’s taking a week off for self-care. He talks about “burnout,” using an app called “Blinkist” that has been helpful, and the six things he wants to do make his life better, which includes to get some “good smelly stuff!”

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.

Добрый день уважаемые слушатели. Представляем новый выпуск подкаста RWpod. В этом выпуске: Ruby Context on STM in Ruby Squash N+1 queries early with n_plus_one_control test matchers for Ruby and Rails Counting things in Active Record Split your Webpacker bundles to speed up the web Jb - a simpler and faster Jbuilder alternative Humanize - converts numbers to strings Web If not SPAs, What? Why npm lockfiles can be a security blindspot for injecting malicious modules What A Yarn Workspace Is, And The Problem It Solves JavaScript’s Memory Management Explained Getting Audio Visualizations working with Web Audio API Simplest JS paint

React on Rails version 12 brings major improvements for hot reloading and bundle splitting. Justin Gordon talks about creating a great developer experience with React and Rails, the best way to manage your webpack configuration, simplify server and client-side rendering and avoid shaving those yaks! Sponsors Audible.com Raygun | Click here to get started on your free 14-day trial CacheFly Panel John Epperson Luke Stutters Charles Max Wood Guest Justin Gordon Links https://www.shakacode.com/react-on-rails-pro/ RailsConf 2020 CE – Webpacker, It-Just-Works, But How? by Justin Gordon https://github.com/shakacode/react_on_rails https://github.com/reactjs/react-rails Picks Luke Stutters: https://www.bbc.co.uk/news/technology-53835079 https://www.linux.com/training-tutorials/improving-putty-settings-windows/ John Epperson: StimulusJS MaCallan 15-Year-Old Double Cask Chuck:: Super Mario Odyssey podcastplaybook.co Justin Gordon: Wing Foiling Dr. Matthew Walker on Sleep for Enhancing Learning, Creativity, Immunity, and Glymphatic System Vacation Rentals React on Rails Pro Follow Ruby Rogues on Twitter > @rubyrogues

React on Rails version 12 brings major improvements for hot reloading and bundle splitting. Justin Gordon talks about creating a great developer experience with React and Rails, the best way to manage your webpack configuration, simplify server and client-side rendering and avoid shaving those yaks! Sponsors Audible.com Raygun | Click here to get started on your free 14-day trial CacheFly Panel John Epperson Luke Stutters Charles Max Wood Guest Justin Gordon Links https://www.shakacode.com/react-on-rails-pro/ RailsConf 2020 CE – Webpacker, It-Just-Works, But How? by Justin Gordon https://github.com/shakacode/react_on_rails https://github.com/reactjs/react-rails Picks Luke Stutters: https://www.bbc.co.uk/news/technology-53835079 https://www.linux.com/training-tutorials/improving-putty-settings-windows/ John Epperson: StimulusJS MaCallan 15-Year-Old Double Cask Chuck:: Super Mario Odyssey podcastplaybook.co Justin Gordon: Wing Foiling Dr. Matthew Walker on Sleep for Enhancing Learning, Creativity, Immunity, and Glymphatic System Vacation Rentals React on Rails Pro Follow Ruby Rogues on Twitter > @rubyrogues

React on Rails version 12 brings major improvements for hot reloading and bundle splitting. Justin Gordon talks about creating a great developer experience with React and Rails, the best way to manage your webpack configuration, simplify server and client-side rendering and avoid shaving those yaks! Sponsors Audible.com Raygun | Click here to get started on your free 14-day trial CacheFly Panel John Epperson Luke Stutters Charles Max Wood Guest Justin Gordon Links https://www.shakacode.com/react-on-rails-pro/ RailsConf 2020 CE – Webpacker, It-Just-Works, But How? by Justin Gordon https://github.com/shakacode/react_on_rails https://github.com/reactjs/react-rails Picks Luke Stutters: https://www.bbc.co.uk/news/technology-53835079 https://www.linux.com/training-tutorials/improving-putty-settings-windows/ John Epperson: StimulusJS MaCallan 15-Year-Old Double Cask Chuck:: Super Mario Odyssey podcastplaybook.co Justin Gordon: Wing Foiling Dr. Matthew Walker on Sleep for Enhancing Learning, Creativity, Immunity, and Glymphatic System Vacation Rentals React on Rails Pro Follow Ruby Rogues on Twitter > @rubyrogues

Добрый день уважаемые слушатели. Представляем новый выпуск подкаста RWpod. В этом выпуске: Ruby Rails 5.2.4.3 and 6.0.3.1 have been released New 2.7/3.0 keyword argument pain point Improve Ruby Hashing implementation using Tabulation Why does Rails 6 include both Webpacker and Sprockets? Limit Everything: Timeouts for Shell Commands in Ruby How to Fix Slow Code in Ruby The Practical Effects of the GVL on Scaling in Ruby SHA-256 Animation - an animation of the SHA-256 hash function in your terminal Web Deno 1.0 The Deno Handbook ESLint v7.0.0 released Recoil - a state management library for React WebGL guide Perfume.js v5.0.2 RGM - React Google Map Shifty - a JavaScript tweening engine designed to fit all of your animation needs

Добрый день уважаемые слушатели. Представляем новый выпуск подкаста RWpod. В этом выпуске: Ruby Rails 6.0.2.2 and 5.2.4.2 have been released! Webpacker 5.0 released Authlogic 6.0.0 RuboCoping with legacy: Bring your Ruby code up to Standard Truemail - configurable framework agnostic plain Ruby email validator. Dry-rails - official dry-rb railtie Pgsync - sync data from one Postgres database to another Web Bootstrap 5 dropping IE 10 & 11 browser support: where does that leave us? What happens when the maintainer of a JS library downloaded 26m times a week goes to prison for killing someone with a motorbike? Core-js just found out Measuring the Performance of JavaScript Functions Nanoid 3.0.0 CS 253 Web Security - Stanford

Добрый день уважаемые слушатели. Представляем новый выпуск подкаста RWpod. В этом выпуске: Ruby Bundler 2.1.0, Rails 6 adds ability to block writes to a database и JIT and Ruby’s MJIT Nested API parameter validation in Rails with ActiveModel::Validations, How to write Javascript in Rails 6 | Webpacker, Yarn and Sprockets и Snabberb - a simple Ruby view framework built on Opal and Snabbdom Web Electron joins the OpenJS Foundation, Raw WebGL, JavaScript component-level CPU costs и ESNext: Relatively format time with Intl.RelativeTimeFormat 5 Top Cloud IDEs for JavaScript Developers и FX - command-line JSON processing tool

In this episode, we welcome Nate Hopkins to the sho, talk about ActionCable's API, discuss Jason's trouble with using JavaScript in a new Rails engine, get some updates from Nate on Stimulus Reflex, and Andrew shares experience with managing open source GitHub Action projects.

Graham Conzett has been a developer for 12 years. He has worked with Ruby and Rails for half of that, and currently works for a company that does large format touchscreens. Graham gave a talk at RailsConf 2018 called “Old School JavaScript and Rails” where he talks about the experience of JavaScript fatigue. The world of JavaScript changes very quickly, and sometimes it feels like there’s a new framework every week. Because there is no clear winner among these frameworks, many Rails developers feel compelled to reach for something like React. However, there are many strategies for doing JavaScript in Ruby and in Rails that existed before these frameworks, so you can accomplish what you want to get done without bringing one in. Remember that all of them can coexist side by side, so you don’t have to pick one strategy. The panel discusses the effect that adopting a new technology can have on the team, such as the learning curve and hiring people that specialize in it.  To illustrate this, Graham talks about the company he works for. Their app is a 90% is a Rails app, and one component has a lot of React. He talks about how they came up with that strategy and how they have kept React isolated to that page. It’s crept into some other little places, but there is a document in the team charter that defines where and why they use certain things, and that has kept it limited. Graham talks about the tradeoffs between choosing to stay in Rails or introduce React. If you bring in React, you have to bring in a different testing framework. React also has a bigger learning curve than standard HTML or CSS. There are far less conventions around React than Rails, so you have to spend time coming to a consensus as a team. Webpacker helps with this to a degree, but it also pulls in a bunch of third party plugins, so Rails is no longer writing the rules and you may have to debug random plugins. If you want to avoid adding a framework like React, consider using ujs, or Unobtrusive JavaScript. These are JavaScript ‘helpers’ included in the Rails bundle that you can add to various buttons that help you decorate and enhance. You don’t have to change much of your HTML frontend code but it makes it more interactive. Graham talks about he uses them and why he likes them. The panel compares using ujs to other strategies like using Stimulus or ‘sprinkles’ of JavaScript. For small JS sprinkles, Graham advises to keep that focused on a single HTML element and bound to a single event handler. Ujs works best when you piggyback off of that Rails/Rest related stuff, and Stimulus is more about manipulating parts on the page that don’t have a need for asynchronous request. You can really use ujs everywhere, so the three techniques are not mutually exclusive. Graham gives advice to developers considering pulling in a frontend framework. He says to start with minimal JS and then talk to your team about when it feels right to do it, because that’s a tricky conversation to know what your expectations are and problems you’re trying to solve. Sometimes things will force the issue and make you want to explore using frontend frameworks. When it’s a time saver, it makes your team scale better, or when you have something you just can’t do without it, then that might be the right time to use React. The show concludes with the panel discussing their experiences with different compiling languages like TypeScript. They talk about what influences the tools people choose. They agree that the most important thing is getting working code out there, it doesn’t really matter how it’s written, but to only pull things in when you know you need it. Panelists Charles Max Wood Andrew Mason David Kimura Nate Hopkins With special guest: Graham Conzett Sponsors Sentry use the code “devchat” for 2 months free on Sentry’s small plan Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $66 free credits with promo code RubyRogues Adventures in Angular Links Old School JavaScript and Rails at RailsConf 2018 React React Native React Native Web Jest Capybara Webpacker Rails-ujs Turbolinks Stimulus Stimulus Reflex Babel TypeScript Actionview components Angular Follow DevChatTV on Facebook and Twitter Picks Charles Max Wood: St. George Marathon OBS David Kimura: WeDo 2.0 by Lego Workflow Automation Self Hosted Andrew Mason: Publish to Github action JustDunning.com Nate Hopkins: Company of One by Paul Jarvis IndieHackers Graham Conzett: Basecamp’s Shape Up Pigeonforteachers.com  IKE Smart City Follow Graham @gconzett on Twitter and Github

Graham Conzett has been a developer for 12 years. He has worked with Ruby and Rails for half of that, and currently works for a company that does large format touchscreens. Graham gave a talk at RailsConf 2018 called “Old School JavaScript and Rails” where he talks about the experience of JavaScript fatigue. The world of JavaScript changes very quickly, and sometimes it feels like there’s a new framework every week. Because there is no clear winner among these frameworks, many Rails developers feel compelled to reach for something like React. However, there are many strategies for doing JavaScript in Ruby and in Rails that existed before these frameworks, so you can accomplish what you want to get done without bringing one in. Remember that all of them can coexist side by side, so you don’t have to pick one strategy. The panel discusses the effect that adopting a new technology can have on the team, such as the learning curve and hiring people that specialize in it.  To illustrate this, Graham talks about the company he works for. Their app is a 90% is a Rails app, and one component has a lot of React. He talks about how they came up with that strategy and how they have kept React isolated to that page. It’s crept into some other little places, but there is a document in the team charter that defines where and why they use certain things, and that has kept it limited. Graham talks about the tradeoffs between choosing to stay in Rails or introduce React. If you bring in React, you have to bring in a different testing framework. React also has a bigger learning curve than standard HTML or CSS. There are far less conventions around React than Rails, so you have to spend time coming to a consensus as a team. Webpacker helps with this to a degree, but it also pulls in a bunch of third party plugins, so Rails is no longer writing the rules and you may have to debug random plugins. If you want to avoid adding a framework like React, consider using ujs, or Unobtrusive JavaScript. These are JavaScript ‘helpers’ included in the Rails bundle that you can add to various buttons that help you decorate and enhance. You don’t have to change much of your HTML frontend code but it makes it more interactive. Graham talks about he uses them and why he likes them. The panel compares using ujs to other strategies like using Stimulus or ‘sprinkles’ of JavaScript. For small JS sprinkles, Graham advises to keep that focused on a single HTML element and bound to a single event handler. Ujs works best when you piggyback off of that Rails/Rest related stuff, and Stimulus is more about manipulating parts on the page that don’t have a need for asynchronous request. You can really use ujs everywhere, so the three techniques are not mutually exclusive. Graham gives advice to developers considering pulling in a frontend framework. He says to start with minimal JS and then talk to your team about when it feels right to do it, because that’s a tricky conversation to know what your expectations are and problems you’re trying to solve. Sometimes things will force the issue and make you want to explore using frontend frameworks. When it’s a time saver, it makes your team scale better, or when you have something you just can’t do without it, then that might be the right time to use React. The show concludes with the panel discussing their experiences with different compiling languages like TypeScript. They talk about what influences the tools people choose. They agree that the most important thing is getting working code out there, it doesn’t really matter how it’s written, but to only pull things in when you know you need it. Panelists Charles Max Wood Andrew Mason David Kimura Nate Hopkins With special guest: Graham Conzett Sponsors Sentry use the code “devchat” for 2 months free on Sentry’s small plan Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $66 free credits with promo code RubyRogues Adventures in Angular Links Old School JavaScript and Rails at RailsConf 2018 React React Native React Native Web Jest Capybara Webpacker Rails-ujs Turbolinks Stimulus Stimulus Reflex Babel TypeScript Actionview components Angular Follow DevChatTV on Facebook and Twitter Picks Charles Max Wood: St. George Marathon OBS David Kimura: WeDo 2.0 by Lego Workflow Automation Self Hosted Andrew Mason: Publish to Github action JustDunning.com Nate Hopkins: Company of One by Paul Jarvis IndieHackers Graham Conzett: Basecamp’s Shape Up Pigeonforteachers.com  IKE Smart City Follow Graham @gconzett on Twitter and Github

Graham Conzett has been a developer for 12 years. He has worked with Ruby and Rails for half of that, and currently works for a company that does large format touchscreens. Graham gave a talk at RailsConf 2018 called “Old School JavaScript and Rails” where he talks about the experience of JavaScript fatigue. The world of JavaScript changes very quickly, and sometimes it feels like there’s a new framework every week. Because there is no clear winner among these frameworks, many Rails developers feel compelled to reach for something like React. However, there are many strategies for doing JavaScript in Ruby and in Rails that existed before these frameworks, so you can accomplish what you want to get done without bringing one in. Remember that all of them can coexist side by side, so you don’t have to pick one strategy. The panel discusses the effect that adopting a new technology can have on the team, such as the learning curve and hiring people that specialize in it.  To illustrate this, Graham talks about the company he works for. Their app is a 90% is a Rails app, and one component has a lot of React. He talks about how they came up with that strategy and how they have kept React isolated to that page. It’s crept into some other little places, but there is a document in the team charter that defines where and why they use certain things, and that has kept it limited. Graham talks about the tradeoffs between choosing to stay in Rails or introduce React. If you bring in React, you have to bring in a different testing framework. React also has a bigger learning curve than standard HTML or CSS. There are far less conventions around React than Rails, so you have to spend time coming to a consensus as a team. Webpacker helps with this to a degree, but it also pulls in a bunch of third party plugins, so Rails is no longer writing the rules and you may have to debug random plugins. If you want to avoid adding a framework like React, consider using ujs, or Unobtrusive JavaScript. These are JavaScript ‘helpers’ included in the Rails bundle that you can add to various buttons that help you decorate and enhance. You don’t have to change much of your HTML frontend code but it makes it more interactive. Graham talks about he uses them and why he likes them. The panel compares using ujs to other strategies like using Stimulus or ‘sprinkles’ of JavaScript. For small JS sprinkles, Graham advises to keep that focused on a single HTML element and bound to a single event handler. Ujs works best when you piggyback off of that Rails/Rest related stuff, and Stimulus is more about manipulating parts on the page that don’t have a need for asynchronous request. You can really use ujs everywhere, so the three techniques are not mutually exclusive. Graham gives advice to developers considering pulling in a frontend framework. He says to start with minimal JS and then talk to your team about when it feels right to do it, because that’s a tricky conversation to know what your expectations are and problems you’re trying to solve. Sometimes things will force the issue and make you want to explore using frontend frameworks. When it’s a time saver, it makes your team scale better, or when you have something you just can’t do without it, then that might be the right time to use React. The show concludes with the panel discussing their experiences with different compiling languages like TypeScript. They talk about what influences the tools people choose. They agree that the most important thing is getting working code out there, it doesn’t really matter how it’s written, but to only pull things in when you know you need it. Panelists Charles Max Wood Andrew Mason David Kimura Nate Hopkins With special guest: Graham Conzett Sponsors Sentry use the code “devchat” for 2 months free on Sentry’s small plan Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $66 free credits with promo code RubyRogues Adventures in Angular Links Old School JavaScript and Rails at RailsConf 2018 React React Native React Native Web Jest Capybara Webpacker Rails-ujs Turbolinks Stimulus Stimulus Reflex Babel TypeScript Actionview components Angular Follow DevChatTV on Facebook and Twitter Picks Charles Max Wood: St. George Marathon OBS David Kimura: WeDo 2.0 by Lego Workflow Automation Self Hosted Andrew Mason: Publish to Github action JustDunning.com Nate Hopkins: Company of One by Paul Jarvis IndieHackers Graham Conzett: Basecamp’s Shape Up Pigeonforteachers.com  IKE Smart City Follow Graham @gconzett on Twitter and Github

Ross Kaffenberger is a software engineer at Stitch Fix and has been developing web applications for the past 12 years, mostly in Ruby and JavaScript. Today he and the panel are discussing how to survive Webpack. When many folks first encounter Webpack, they feel confused, overwhelmed, and don’t know how to get it to do what you want it to. In the latest version they tried to introduce some more sane default settings, but it is still a major change in technology.  Ross talks about how his company transitioned Rails 5 to Rails 6 with the new Webpacker. His company chose to take an iterative approach and slowly migrated to Webpacker. His app was very JS heavy with a large number of libraries, many of which were not very Webpack friendly. They chose to separate out the vendor libraries into a separate bundle, that way they could contain each deploy. They still had to add some configuration, especially to make things available on global scope.As they started moving jQuery plugins over, sometimes the functionality would disappear, and Ross talks about how they figured out their mistakes. It was difficult for them to get out of their Sprockets mindset and into the new mindset of Webpack, which requires different techniques. There are also things that Webpack can do to keep you out of that situation Ross gives some strategy advice for someone who is in a position to update from Sprockets to Webpack. It’s important to consider your app size, your comfort level with Webpack, your team dynamic, and your timeframe. Ross recommends the iterative approach that they took, which took longer, but allowed them to learn as they went.  Ross talks about the changes that happened in the switch from Webpack 3 to Webpack 4, and some of the contributions they made. He talks about some of his preferred Webpack configs and plugins. They discuss some of the drawbacks of Webpack, particularly the plethora of plugins that can make it seem daunting.  One of the big gotchas with Webpack is the location of your source code. When you install Webpack for the first time, create a JS folder under App, it will place a ‘application.js’ file in another file called ‘Packs”. The idea of that pack file (application.js file under Packs) is that it’s the entry point for all of the JS that you’re going to add to your Webpack build. But if you add additional files to that Pack folder, Webpacker will instruct Webpack to treat each of those files as a separate entry point in a dependency graph. Make sure that only files that are intended to be the entry points for your Webpack builds are in that packs folder.  It is also important to understand how you’re using global scope inside your JavaScript modules in your build. There’s a way to allow Webpack to inspect each of the files for a certain variable, such as a dollar sign. If he could go back and do it again, Ross would not split his code manually, but instead Embrace the notion that Webpack understands how to do code splitting for you, as long as instruct it to do it the right way. Ultimately, it took Ross’ company 3 rather tedious months to transition to Webpack. It could’ve gone faster if they’d known more about Webpack to begin with. The panel discusses whether it was worth it to switch to Webpack. Transitioning to Webpack has changed their team dynamic and their day to day coding and debugging. One nice feature of Webpack is the source maps that aid in debugging. There are still areas for improvement, but now that it’s set up most folks on the team don’t think about it. Overall, the development experience has improved, and he thinks it was worth it, but it’s not for everybody. Panelists Dave Kimura Andrew Mason Nate Hopkins Charles Max Wood With special guest: Ross Kaffenberger Sponsors Sentry use the code “devchat” for 2 months free on Sentry’s small plan Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $66 free credits with promo code RubyRogues Views on Vue Links Webpack Webpacker Sprockets  Knockout.js CKEditor Chosen Webpack Bundle Analyzer Manifest.json Module shimming SplitChunksPlugin Vue Follow DevChatTV on Facebook and Twitter Picks Dave Kimura: Avengers Quinjet Lego set Portable air conditioner Nate Hopkins: MDN JavaScript Reference Brandon Sanderson’s Mistborn series  Charles Max Wood: Restream Twitch OBS Ross Kaffenberger:  Exploring ES6 1 Second Everyday One Sentence Journal Follow Ross on Twitter and Github, and on his blog

Ross Kaffenberger is a software engineer at Stitch Fix and has been developing web applications for the past 12 years, mostly in Ruby and JavaScript. Today he and the panel are discussing how to survive Webpack. When many folks first encounter Webpack, they feel confused, overwhelmed, and don’t know how to get it to do what you want it to. In the latest version they tried to introduce some more sane default settings, but it is still a major change in technology.  Ross talks about how his company transitioned Rails 5 to Rails 6 with the new Webpacker. His company chose to take an iterative approach and slowly migrated to Webpacker. His app was very JS heavy with a large number of libraries, many of which were not very Webpack friendly. They chose to separate out the vendor libraries into a separate bundle, that way they could contain each deploy. They still had to add some configuration, especially to make things available on global scope.As they started moving jQuery plugins over, sometimes the functionality would disappear, and Ross talks about how they figured out their mistakes. It was difficult for them to get out of their Sprockets mindset and into the new mindset of Webpack, which requires different techniques. There are also things that Webpack can do to keep you out of that situation Ross gives some strategy advice for someone who is in a position to update from Sprockets to Webpack. It’s important to consider your app size, your comfort level with Webpack, your team dynamic, and your timeframe. Ross recommends the iterative approach that they took, which took longer, but allowed them to learn as they went.  Ross talks about the changes that happened in the switch from Webpack 3 to Webpack 4, and some of the contributions they made. He talks about some of his preferred Webpack configs and plugins. They discuss some of the drawbacks of Webpack, particularly the plethora of plugins that can make it seem daunting.  One of the big gotchas with Webpack is the location of your source code. When you install Webpack for the first time, create a JS folder under App, it will place a ‘application.js’ file in another file called ‘Packs”. The idea of that pack file (application.js file under Packs) is that it’s the entry point for all of the JS that you’re going to add to your Webpack build. But if you add additional files to that Pack folder, Webpacker will instruct Webpack to treat each of those files as a separate entry point in a dependency graph. Make sure that only files that are intended to be the entry points for your Webpack builds are in that packs folder.  It is also important to understand how you’re using global scope inside your JavaScript modules in your build. There’s a way to allow Webpack to inspect each of the files for a certain variable, such as a dollar sign. If he could go back and do it again, Ross would not split his code manually, but instead Embrace the notion that Webpack understands how to do code splitting for you, as long as instruct it to do it the right way. Ultimately, it took Ross’ company 3 rather tedious months to transition to Webpack. It could’ve gone faster if they’d known more about Webpack to begin with. The panel discusses whether it was worth it to switch to Webpack. Transitioning to Webpack has changed their team dynamic and their day to day coding and debugging. One nice feature of Webpack is the source maps that aid in debugging. There are still areas for improvement, but now that it’s set up most folks on the team don’t think about it. Overall, the development experience has improved, and he thinks it was worth it, but it’s not for everybody. Panelists Dave Kimura Andrew Mason Nate Hopkins Charles Max Wood With special guest: Ross Kaffenberger Sponsors Sentry use the code “devchat” for 2 months free on Sentry’s small plan Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $66 free credits with promo code RubyRogues Views on Vue Links Webpack Webpacker Sprockets  Knockout.js CKEditor Chosen Webpack Bundle Analyzer Manifest.json Module shimming SplitChunksPlugin Vue Follow DevChatTV on Facebook and Twitter Picks Dave Kimura: Avengers Quinjet Lego set Portable air conditioner Nate Hopkins: MDN JavaScript Reference Brandon Sanderson’s Mistborn series  Charles Max Wood: Restream Twitch OBS Ross Kaffenberger:  Exploring ES6 1 Second Everyday One Sentence Journal Follow Ross on Twitter and Github, and on his blog

Ross Kaffenberger is a software engineer at Stitch Fix and has been developing web applications for the past 12 years, mostly in Ruby and JavaScript. Today he and the panel are discussing how to survive Webpack. When many folks first encounter Webpack, they feel confused, overwhelmed, and don’t know how to get it to do what you want it to. In the latest version they tried to introduce some more sane default settings, but it is still a major change in technology.  Ross talks about how his company transitioned Rails 5 to Rails 6 with the new Webpacker. His company chose to take an iterative approach and slowly migrated to Webpacker. His app was very JS heavy with a large number of libraries, many of which were not very Webpack friendly. They chose to separate out the vendor libraries into a separate bundle, that way they could contain each deploy. They still had to add some configuration, especially to make things available on global scope.As they started moving jQuery plugins over, sometimes the functionality would disappear, and Ross talks about how they figured out their mistakes. It was difficult for them to get out of their Sprockets mindset and into the new mindset of Webpack, which requires different techniques. There are also things that Webpack can do to keep you out of that situation Ross gives some strategy advice for someone who is in a position to update from Sprockets to Webpack. It’s important to consider your app size, your comfort level with Webpack, your team dynamic, and your timeframe. Ross recommends the iterative approach that they took, which took longer, but allowed them to learn as they went.  Ross talks about the changes that happened in the switch from Webpack 3 to Webpack 4, and some of the contributions they made. He talks about some of his preferred Webpack configs and plugins. They discuss some of the drawbacks of Webpack, particularly the plethora of plugins that can make it seem daunting.  One of the big gotchas with Webpack is the location of your source code. When you install Webpack for the first time, create a JS folder under App, it will place a ‘application.js’ file in another file called ‘Packs”. The idea of that pack file (application.js file under Packs) is that it’s the entry point for all of the JS that you’re going to add to your Webpack build. But if you add additional files to that Pack folder, Webpacker will instruct Webpack to treat each of those files as a separate entry point in a dependency graph. Make sure that only files that are intended to be the entry points for your Webpack builds are in that packs folder.  It is also important to understand how you’re using global scope inside your JavaScript modules in your build. There’s a way to allow Webpack to inspect each of the files for a certain variable, such as a dollar sign. If he could go back and do it again, Ross would not split his code manually, but instead Embrace the notion that Webpack understands how to do code splitting for you, as long as instruct it to do it the right way. Ultimately, it took Ross’ company 3 rather tedious months to transition to Webpack. It could’ve gone faster if they’d known more about Webpack to begin with. The panel discusses whether it was worth it to switch to Webpack. Transitioning to Webpack has changed their team dynamic and their day to day coding and debugging. One nice feature of Webpack is the source maps that aid in debugging. There are still areas for improvement, but now that it’s set up most folks on the team don’t think about it. Overall, the development experience has improved, and he thinks it was worth it, but it’s not for everybody. Panelists Dave Kimura Andrew Mason Nate Hopkins Charles Max Wood With special guest: Ross Kaffenberger Sponsors Sentry use the code “devchat” for 2 months free on Sentry’s small plan Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $66 free credits with promo code RubyRogues Views on Vue Links Webpack Webpacker Sprockets  Knockout.js CKEditor Chosen Webpack Bundle Analyzer Manifest.json Module shimming SplitChunksPlugin Vue Follow DevChatTV on Facebook and Twitter Picks Dave Kimura: Avengers Quinjet Lego set Portable air conditioner Nate Hopkins: MDN JavaScript Reference Brandon Sanderson’s Mistborn series  Charles Max Wood: Restream Twitch OBS Ross Kaffenberger:  Exploring ES6 1 Second Everyday One Sentence Journal Follow Ross on Twitter and Github, and on his blog

Kaelig Deloumeau-Prigent is a self taught web developer from west France. He has worked for BBC, The Guardian, and The Financial Times in the UK. He has also worked in the US for SalesForce and currently works for Shopify on their Polaris design system. Shopify has multiple design systems, and Polaris is open source. Today the panel is talking about design systems and developer tooling around design systems.  To begin, Kaelig explains what a design system is. A design system is all of the cultural practices around design and shipping a product. It includes things like the words, colors, spacing grid system, and typography, plus guidance on how to achieve that in code. The panelists discuss what has made design systems so popular. Design systems have been around for a while, but became popular due to the shift to components, which has been accelerated by the popularity of React. The term design system is also misused by a lot of people, for it is much more than having a Sketch file.  Next, they talk about whether design systems fall under the jurisdiction of a frontend developer or web designers. Kaelig has found that a successful design system involves a little bit of everyone and shouldn’t be isolated to one team. They talk about what the developer workflow looks like in a design system. It begins with thinking of a few common rules, a language, and putting it into code. As you scale, design systems can become quite large and it’s impossible for one person to know everything. You either give into the chaos, or you start a devops practice where people start to think about how we build, release, and the path from designer’s brain to production. The panelists then talk about how to introduce a design system into a company where there are cultural conflicts. Kaelig shares his experience working with SalesForce and introducing a design system there. They discuss what aspects of a design system that would make people want to use it over what the team is currently doing. Usually teams are thankful for the design system. It’s important to build a system that’s complete, flexible, and extensible so that you can adapt it to your team. A good design system incorporates ‘subatomic’ parts like the grid system, color palette, and typography, referred to as design tokens. Design systems enable people to take just the bits of the design system that are interesting to them and build the components that are missing more easily.  The conversation turns to the installation and upgrade process of a design system. Upgrading is left up to the customer to do on their own time in most cases, unless it’s one of the big customers. They talk about the role of components in upgrading a design system. Kaelig talks about the possibility of Shopify transitioning to web components. Kaelig shares some of his favorite tools for making a design system and how to get started making one. A lot of design teams start by taking a ton of screen shots and looking at all the inconsistencies.Giving them that visibility is a good thing because it helps get everyone get on the same page. The panelists talk about the role of upper management in developing components and how to prioritize feature development. Kaelig talks about what drives the decision to take a feature out. The two main reasons a feature would be removed is because the company wants to change the way things are done and there’s a different need that has arisen. The show concludes by discussing the possibility of a design system getting bloated over time. Kaelig says that Design systems takes some of the burden off your team, help prevent things from getting bloated, allow you to ship less code.   Panelists Chris Ferdinandi Aimee Knight Steve Emmerich With special guest: Kaelig Deloumeau-Prigent Sponsors Sustain Our Software Sentry use the code “devchat” for 2 months free on Sentry’s small plan Adventures in Blockchain Links Shopify Polaris Bootstrap React Sketch.ui Figma.ui  CSS StoryBook ESLint Jest Ensign Webpacker Follow DevChatTV on Facebook and Twitter Picks Steve Emmerich: CedarWorks play beds  Azure’s container instances Aimee Knight: Awesome Actions for Github Chris Ferdinandi: Free Meek docuseries Simplicity: Part 2 by Bastian Allgeier Kaelig Deloumeau-Prigent: Dependabot Ink by Vadim Demedez Follow Kaelig on Twitter @kaelig

Kaelig Deloumeau-Prigent is a self taught web developer from west France. He has worked for BBC, The Guardian, and The Financial Times in the UK. He has also worked in the US for SalesForce and currently works for Shopify on their Polaris design system. Shopify has multiple design systems, and Polaris is open source. Today the panel is talking about design systems and developer tooling around design systems.  To begin, Kaelig explains what a design system is. A design system is all of the cultural practices around design and shipping a product. It includes things like the words, colors, spacing grid system, and typography, plus guidance on how to achieve that in code. The panelists discuss what has made design systems so popular. Design systems have been around for a while, but became popular due to the shift to components, which has been accelerated by the popularity of React. The term design system is also misused by a lot of people, for it is much more than having a Sketch file.  Next, they talk about whether design systems fall under the jurisdiction of a frontend developer or web designers. Kaelig has found that a successful design system involves a little bit of everyone and shouldn’t be isolated to one team. They talk about what the developer workflow looks like in a design system. It begins with thinking of a few common rules, a language, and putting it into code. As you scale, design systems can become quite large and it’s impossible for one person to know everything. You either give into the chaos, or you start a devops practice where people start to think about how we build, release, and the path from designer’s brain to production. The panelists then talk about how to introduce a design system into a company where there are cultural conflicts. Kaelig shares his experience working with SalesForce and introducing a design system there. They discuss what aspects of a design system that would make people want to use it over what the team is currently doing. Usually teams are thankful for the design system. It’s important to build a system that’s complete, flexible, and extensible so that you can adapt it to your team. A good design system incorporates ‘subatomic’ parts like the grid system, color palette, and typography, referred to as design tokens. Design systems enable people to take just the bits of the design system that are interesting to them and build the components that are missing more easily.  The conversation turns to the installation and upgrade process of a design system. Upgrading is left up to the customer to do on their own time in most cases, unless it’s one of the big customers. They talk about the role of components in upgrading a design system. Kaelig talks about the possibility of Shopify transitioning to web components. Kaelig shares some of his favorite tools for making a design system and how to get started making one. A lot of design teams start by taking a ton of screen shots and looking at all the inconsistencies.Giving them that visibility is a good thing because it helps get everyone get on the same page. The panelists talk about the role of upper management in developing components and how to prioritize feature development. Kaelig talks about what drives the decision to take a feature out. The two main reasons a feature would be removed is because the company wants to change the way things are done and there’s a different need that has arisen. The show concludes by discussing the possibility of a design system getting bloated over time. Kaelig says that Design systems takes some of the burden off your team, help prevent things from getting bloated, allow you to ship less code.   Panelists Chris Ferdinandi Aimee Knight Steve Emmerich With special guest: Kaelig Deloumeau-Prigent Sponsors Sustain Our Software Sentry use the code “devchat” for 2 months free on Sentry’s small plan Adventures in Blockchain Links Shopify Polaris Bootstrap React Sketch.ui Figma.ui  CSS StoryBook ESLint Jest Ensign Webpacker Follow DevChatTV on Facebook and Twitter Picks Steve Emmerich: CedarWorks play beds  Azure’s container instances Aimee Knight: Awesome Actions for Github Chris Ferdinandi: Free Meek docuseries Simplicity: Part 2 by Bastian Allgeier Kaelig Deloumeau-Prigent: Dependabot Ink by Vadim Demedez Follow Kaelig on Twitter @kaelig

Kaelig Deloumeau-Prigent is a self taught web developer from west France. He has worked for BBC, The Guardian, and The Financial Times in the UK. He has also worked in the US for SalesForce and currently works for Shopify on their Polaris design system. Shopify has multiple design systems, and Polaris is open source. Today the panel is talking about design systems and developer tooling around design systems.  To begin, Kaelig explains what a design system is. A design system is all of the cultural practices around design and shipping a product. It includes things like the words, colors, spacing grid system, and typography, plus guidance on how to achieve that in code. The panelists discuss what has made design systems so popular. Design systems have been around for a while, but became popular due to the shift to components, which has been accelerated by the popularity of React. The term design system is also misused by a lot of people, for it is much more than having a Sketch file.  Next, they talk about whether design systems fall under the jurisdiction of a frontend developer or web designers. Kaelig has found that a successful design system involves a little bit of everyone and shouldn’t be isolated to one team. They talk about what the developer workflow looks like in a design system. It begins with thinking of a few common rules, a language, and putting it into code. As you scale, design systems can become quite large and it’s impossible for one person to know everything. You either give into the chaos, or you start a devops practice where people start to think about how we build, release, and the path from designer’s brain to production. The panelists then talk about how to introduce a design system into a company where there are cultural conflicts. Kaelig shares his experience working with SalesForce and introducing a design system there. They discuss what aspects of a design system that would make people want to use it over what the team is currently doing. Usually teams are thankful for the design system. It’s important to build a system that’s complete, flexible, and extensible so that you can adapt it to your team. A good design system incorporates ‘subatomic’ parts like the grid system, color palette, and typography, referred to as design tokens. Design systems enable people to take just the bits of the design system that are interesting to them and build the components that are missing more easily.  The conversation turns to the installation and upgrade process of a design system. Upgrading is left up to the customer to do on their own time in most cases, unless it’s one of the big customers. They talk about the role of components in upgrading a design system. Kaelig talks about the possibility of Shopify transitioning to web components. Kaelig shares some of his favorite tools for making a design system and how to get started making one. A lot of design teams start by taking a ton of screen shots and looking at all the inconsistencies.Giving them that visibility is a good thing because it helps get everyone get on the same page. The panelists talk about the role of upper management in developing components and how to prioritize feature development. Kaelig talks about what drives the decision to take a feature out. The two main reasons a feature would be removed is because the company wants to change the way things are done and there’s a different need that has arisen. The show concludes by discussing the possibility of a design system getting bloated over time. Kaelig says that Design systems takes some of the burden off your team, help prevent things from getting bloated, allow you to ship less code.   Panelists Chris Ferdinandi Aimee Knight Steve Emmerich With special guest: Kaelig Deloumeau-Prigent Sponsors Sustain Our Software Sentry use the code “devchat” for 2 months free on Sentry’s small plan Adventures in Blockchain Links Shopify Polaris Bootstrap React Sketch.ui Figma.ui  CSS StoryBook ESLint Jest Ensign Webpacker Follow DevChatTV on Facebook and Twitter Picks Steve Emmerich: CedarWorks play beds  Azure’s container instances Aimee Knight: Awesome Actions for Github Chris Ferdinandi: Free Meek docuseries Simplicity: Part 2 by Bastian Allgeier Kaelig Deloumeau-Prigent: Dependabot Ink by Vadim Demedez Follow Kaelig on Twitter @kaelig

Mike Schutte is a fronted developer at TED conferences and was trained in code school at Turing in Colorado. He likes the idea of code as a communication tool, and in 2018 he gave a talk at RailsConf called Stop Testing. Start Storytelling.  Today the panel is discussing what Mike means by storytelling in testing. In order to combat the hesitancy to start testing, Mike believes that changing your mindset to think away from the implementation details while deploying these tests can help them be more efficient. In short, if the test isn’t readable by a non-developer, then it’s not telling a story, it’s just writing code. The test is almost the first point of contact away from the source code, so if that’s unwieldy in a test it will be hard to use elsewhere in the application. We have an intuition for stories, so use tests in order to communicate the intent of what the application should do under certain conditions. If it’s hard to set that up in a succinct way then maybe it should be written differently. This view is backed up by other experts as well. Sandi Metz and Noel Rappin talk about it in Tech Done Right episode 69. They say if your test isn’t easy to write and you’re having to create tons and tons of objects, then the system or the class your trying to test is too interconnected, so you might want to break that up into more separated concerns so each of your tests can be focused on what you’re actually trying to test. If you follow these principles, your testing will be a lot easier even if there are more classes and modules to test. David applies this approach to an online shopping cart and how to break it up. The idea is to abstract it away from the big picture, in this case the grand total, and breaking it down into smaller stories or things.  Mike shares methods to put this approach into practice and how to test. He finds that reading the code as if you were reading a section in a novel rather than code helps him sketch out what he needs to test. The panelists discuss different methods for testing, emphasizing keeping the models or classes you write very simple, minimizing the amount of full on feature specs. If you take time to think about the mindset and the process you use to write a test, the tools you use becomes interchangeable in a lot of ways. Andrew brings up a trend that he’s noticed of tools coming out that are taking mini tests or rspec and trying to morph it to the programmer’s preferences. Tools like this end up with a lot of weird syntax that is hard to maintain. The panelists acknowledge the challenges that stem from using a custom VIM, and believe that having an agnostic approach makes it easier to jump into different systems. Your focus shouldn’t be your developer preferences or what you’re used to, rather it should be your happiness when you have to update. They agree that because it’s easy to understand, it’s telling a story the reader can understand, which makes it easier to maintain in the long run. The Ruby Rogues panel talk about different methods for testing, particularly if they’ve ever tested JavaScript code in a Rails app. They talk about some of their preferred tools to test their code, such as StoryBook. Mike talks about what StoryBook is and what it’s like to use it. David talks about his experience using Cucumber, why his team used it, and how it works. The show concludes with Mike sharing some of the benefits he has found from using typed languages like TypeScript and the panel talking about their experience playing around with Actionview components.  Panelists Andrew Mason David Kimura With special guest: Mike Schutte Sponsors Sentry use the code “devchat” for 2 months free on Sentry’s small plan Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $66 free credits with promo code RubyRogues Elixir Mix Podcast Links Stop Teaching. Start Storytelling (RailsConf 2018) Tech Done Right episode 69 Law of Demeter Grumpy Old Man RSpec MaxiTest Minitest Spec Thoughtbot  Jest Stimulus Webpacker StoryBook Cucumber TypeScript Actionview component Follow DevChatTV on Facebook and Twitter Picks David Kimura: Rode Podcaster Andrew Mason: Drifting Ruby 196 VS Code Ruby Debug Mike Schutte: Follow Mike on Twitter @tmikeschu StoryBook.js

Mike Schutte is a fronted developer at TED conferences and was trained in code school at Turing in Colorado. He likes the idea of code as a communication tool, and in 2018 he gave a talk at RailsConf called Stop Testing. Start Storytelling.  Today the panel is discussing what Mike means by storytelling in testing. In order to combat the hesitancy to start testing, Mike believes that changing your mindset to think away from the implementation details while deploying these tests can help them be more efficient. In short, if the test isn’t readable by a non-developer, then it’s not telling a story, it’s just writing code. The test is almost the first point of contact away from the source code, so if that’s unwieldy in a test it will be hard to use elsewhere in the application. We have an intuition for stories, so use tests in order to communicate the intent of what the application should do under certain conditions. If it’s hard to set that up in a succinct way then maybe it should be written differently. This view is backed up by other experts as well. Sandi Metz and Noel Rappin talk about it in Tech Done Right episode 69. They say if your test isn’t easy to write and you’re having to create tons and tons of objects, then the system or the class your trying to test is too interconnected, so you might want to break that up into more separated concerns so each of your tests can be focused on what you’re actually trying to test. If you follow these principles, your testing will be a lot easier even if there are more classes and modules to test. David applies this approach to an online shopping cart and how to break it up. The idea is to abstract it away from the big picture, in this case the grand total, and breaking it down into smaller stories or things.  Mike shares methods to put this approach into practice and how to test. He finds that reading the code as if you were reading a section in a novel rather than code helps him sketch out what he needs to test. The panelists discuss different methods for testing, emphasizing keeping the models or classes you write very simple, minimizing the amount of full on feature specs. If you take time to think about the mindset and the process you use to write a test, the tools you use becomes interchangeable in a lot of ways. Andrew brings up a trend that he’s noticed of tools coming out that are taking mini tests or rspec and trying to morph it to the programmer’s preferences. Tools like this end up with a lot of weird syntax that is hard to maintain. The panelists acknowledge the challenges that stem from using a custom VIM, and believe that having an agnostic approach makes it easier to jump into different systems. Your focus shouldn’t be your developer preferences or what you’re used to, rather it should be your happiness when you have to update. They agree that because it’s easy to understand, it’s telling a story the reader can understand, which makes it easier to maintain in the long run. The Ruby Rogues panel talk about different methods for testing, particularly if they’ve ever tested JavaScript code in a Rails app. They talk about some of their preferred tools to test their code, such as StoryBook. Mike talks about what StoryBook is and what it’s like to use it. David talks about his experience using Cucumber, why his team used it, and how it works. The show concludes with Mike sharing some of the benefits he has found from using typed languages like TypeScript and the panel talking about their experience playing around with Actionview components.  Panelists Andrew Mason David Kimura With special guest: Mike Schutte Sponsors Sentry use the code “devchat” for 2 months free on Sentry’s small plan Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $66 free credits with promo code RubyRogues Elixir Mix Podcast Links Stop Teaching. Start Storytelling (RailsConf 2018) Tech Done Right episode 69 Law of Demeter Grumpy Old Man RSpec MaxiTest Minitest Spec Thoughtbot  Jest Stimulus Webpacker StoryBook Cucumber TypeScript Actionview component Follow DevChatTV on Facebook and Twitter Picks David Kimura: Rode Podcaster Andrew Mason: Drifting Ruby 196 VS Code Ruby Debug Mike Schutte: Follow Mike on Twitter @tmikeschu StoryBook.js

Mike Schutte is a fronted developer at TED conferences and was trained in code school at Turing in Colorado. He likes the idea of code as a communication tool, and in 2018 he gave a talk at RailsConf called Stop Testing. Start Storytelling.  Today the panel is discussing what Mike means by storytelling in testing. In order to combat the hesitancy to start testing, Mike believes that changing your mindset to think away from the implementation details while deploying these tests can help them be more efficient. In short, if the test isn’t readable by a non-developer, then it’s not telling a story, it’s just writing code. The test is almost the first point of contact away from the source code, so if that’s unwieldy in a test it will be hard to use elsewhere in the application. We have an intuition for stories, so use tests in order to communicate the intent of what the application should do under certain conditions. If it’s hard to set that up in a succinct way then maybe it should be written differently. This view is backed up by other experts as well. Sandi Metz and Noel Rappin talk about it in Tech Done Right episode 69. They say if your test isn’t easy to write and you’re having to create tons and tons of objects, then the system or the class your trying to test is too interconnected, so you might want to break that up into more separated concerns so each of your tests can be focused on what you’re actually trying to test. If you follow these principles, your testing will be a lot easier even if there are more classes and modules to test. David applies this approach to an online shopping cart and how to break it up. The idea is to abstract it away from the big picture, in this case the grand total, and breaking it down into smaller stories or things.  Mike shares methods to put this approach into practice and how to test. He finds that reading the code as if you were reading a section in a novel rather than code helps him sketch out what he needs to test. The panelists discuss different methods for testing, emphasizing keeping the models or classes you write very simple, minimizing the amount of full on feature specs. If you take time to think about the mindset and the process you use to write a test, the tools you use becomes interchangeable in a lot of ways. Andrew brings up a trend that he’s noticed of tools coming out that are taking mini tests or rspec and trying to morph it to the programmer’s preferences. Tools like this end up with a lot of weird syntax that is hard to maintain. The panelists acknowledge the challenges that stem from using a custom VIM, and believe that having an agnostic approach makes it easier to jump into different systems. Your focus shouldn’t be your developer preferences or what you’re used to, rather it should be your happiness when you have to update. They agree that because it’s easy to understand, it’s telling a story the reader can understand, which makes it easier to maintain in the long run. The Ruby Rogues panel talk about different methods for testing, particularly if they’ve ever tested JavaScript code in a Rails app. They talk about some of their preferred tools to test their code, such as StoryBook. Mike talks about what StoryBook is and what it’s like to use it. David talks about his experience using Cucumber, why his team used it, and how it works. The show concludes with Mike sharing some of the benefits he has found from using typed languages like TypeScript and the panel talking about their experience playing around with Actionview components.  Panelists Andrew Mason David Kimura With special guest: Mike Schutte Sponsors Sentry use the code “devchat” for 2 months free on Sentry’s small plan Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $66 free credits with promo code RubyRogues Elixir Mix Podcast Links Stop Teaching. Start Storytelling (RailsConf 2018) Tech Done Right episode 69 Law of Demeter Grumpy Old Man RSpec MaxiTest Minitest Spec Thoughtbot  Jest Stimulus Webpacker StoryBook Cucumber TypeScript Actionview component Follow DevChatTV on Facebook and Twitter Picks David Kimura: Rode Podcaster Andrew Mason: Drifting Ruby 196 VS Code Ruby Debug Mike Schutte: Follow Mike on Twitter @tmikeschu StoryBook.js

Episode Summary   Today’s guest Elia Schito has been a Ruby developer for 12+ years and works for Nebulab. During his career he looked for Ruby to JavaScript translators and found Opal. The panel discusses where Opal belongs within an app and when the compilation into JavaScript occurs. The main reason a person would want to use Opal is to avoid writing in JavaScript. Elia talks about the benefits of using Opal. One is that productivity is better in a language like Ruby. Also, if you’re working on a project that needs to get done quickly, it makes sense to use Opal so that your speed is not hindered. Elia talks about testing Opal with things like WebPacker and Hyperstack, and explains what Hyperstack is.  Opal recently released a newer, bigger version, and Elia talks about the features of the new release. He details what kind of JavaScript it produces and how to hook it into your CICD, how to run it locally, and overall how to use the compiler.  He talks about how to debug in Opal. He notes that during the development cycle in Opal, you can refresh your page and it will compile the Ruby code into JS, so if there are any errors you will see it immediately. Opal is compatible with other tools to check your code. In the future, Elia wants to increase the coverage of the core and standard library, and believes that Opal is a great way to increase your skills in Ruby and JavaScript. He talks about the general reception of Opal among users. Opal is a perfect fit for smaller teams or older fullstack developers, especially if you don’t have a frontend team Elia notes that Opal, much like anything else, is a matter of preference, and relates it to the past reliance on CoffeeScript. For developers who refuse to write in JavaScript, Opal is an excellent option. He talks about the speed of compiling ruby to JavaScript in Opal and how it supports keeping current with Rails versions and other frameworks.  The panel asks if the Opal community made any inroads with DHH for making it part of the Rails stack proper and whether Opal wants to be integrated with Rails. Elia talks about some of Opal’s contributions to the Ruby Community. Elia talks about what generally happens if you choose to use Opal in a project. Opal is small, but you will have to make some tradeoffs. You have to call your standard library from Opal, but there are many ways to overcome that. The show concludes with Elia calling on the community to help him resurrect the Volt framework. Panelists Andrew Mason David Kimura Nate Hopkins With special guest: Elia Schito Sponsors Sentry use the code “devchat” for 2 months free on Sentry’s small plan Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $66 free credits with promo code RubyRogues My Ruby Story Links Opal  WebPacker Stimulus Hyperstack Capybara CoffeeScript Devise Clearwater Reactive Volt framework Nebulab Follow DevChatTV on Facebook and Twitter Picks David Kimura: AWS Organization Consolidated Billing Pingverse Nate Hopkins: Benjamin Moore paint Andrew Mason: Github Actions (beta) Elia Schito: Follow Elia on his website Explaining Postmodernism Texmate

Episode Summary   Today’s guest Elia Schito has been a Ruby developer for 12+ years and works for Nebulab. During his career he looked for Ruby to JavaScript translators and found Opal. The panel discusses where Opal belongs within an app and when the compilation into JavaScript occurs. The main reason a person would want to use Opal is to avoid writing in JavaScript. Elia talks about the benefits of using Opal. One is that productivity is better in a language like Ruby. Also, if you’re working on a project that needs to get done quickly, it makes sense to use Opal so that your speed is not hindered. Elia talks about testing Opal with things like WebPacker and Hyperstack, and explains what Hyperstack is.  Opal recently released a newer, bigger version, and Elia talks about the features of the new release. He details what kind of JavaScript it produces and how to hook it into your CICD, how to run it locally, and overall how to use the compiler.  He talks about how to debug in Opal. He notes that during the development cycle in Opal, you can refresh your page and it will compile the Ruby code into JS, so if there are any errors you will see it immediately. Opal is compatible with other tools to check your code. In the future, Elia wants to increase the coverage of the core and standard library, and believes that Opal is a great way to increase your skills in Ruby and JavaScript. He talks about the general reception of Opal among users. Opal is a perfect fit for smaller teams or older fullstack developers, especially if you don’t have a frontend team Elia notes that Opal, much like anything else, is a matter of preference, and relates it to the past reliance on CoffeeScript. For developers who refuse to write in JavaScript, Opal is an excellent option. He talks about the speed of compiling ruby to JavaScript in Opal and how it supports keeping current with Rails versions and other frameworks.  The panel asks if the Opal community made any inroads with DHH for making it part of the Rails stack proper and whether Opal wants to be integrated with Rails. Elia talks about some of Opal’s contributions to the Ruby Community. Elia talks about what generally happens if you choose to use Opal in a project. Opal is small, but you will have to make some tradeoffs. You have to call your standard library from Opal, but there are many ways to overcome that. The show concludes with Elia calling on the community to help him resurrect the Volt framework. Panelists Andrew Mason David Kimura Nate Hopkins With special guest: Elia Schito Sponsors Sentry use the code “devchat” for 2 months free on Sentry’s small plan Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $66 free credits with promo code RubyRogues My Ruby Story Links Opal  WebPacker Stimulus Hyperstack Capybara CoffeeScript Devise Clearwater Reactive Volt framework Nebulab Follow DevChatTV on Facebook and Twitter Picks David Kimura: AWS Organization Consolidated Billing Pingverse Nate Hopkins: Benjamin Moore paint Andrew Mason: Github Actions (beta) Elia Schito: Follow Elia on his website Explaining Postmodernism Texmate

Episode Summary   Today’s guest Elia Schito has been a Ruby developer for 12+ years and works for Nebulab. During his career he looked for Ruby to JavaScript translators and found Opal. The panel discusses where Opal belongs within an app and when the compilation into JavaScript occurs. The main reason a person would want to use Opal is to avoid writing in JavaScript. Elia talks about the benefits of using Opal. One is that productivity is better in a language like Ruby. Also, if you’re working on a project that needs to get done quickly, it makes sense to use Opal so that your speed is not hindered. Elia talks about testing Opal with things like WebPacker and Hyperstack, and explains what Hyperstack is.  Opal recently released a newer, bigger version, and Elia talks about the features of the new release. He details what kind of JavaScript it produces and how to hook it into your CICD, how to run it locally, and overall how to use the compiler.  He talks about how to debug in Opal. He notes that during the development cycle in Opal, you can refresh your page and it will compile the Ruby code into JS, so if there are any errors you will see it immediately. Opal is compatible with other tools to check your code. In the future, Elia wants to increase the coverage of the core and standard library, and believes that Opal is a great way to increase your skills in Ruby and JavaScript. He talks about the general reception of Opal among users. Opal is a perfect fit for smaller teams or older fullstack developers, especially if you don’t have a frontend team Elia notes that Opal, much like anything else, is a matter of preference, and relates it to the past reliance on CoffeeScript. For developers who refuse to write in JavaScript, Opal is an excellent option. He talks about the speed of compiling ruby to JavaScript in Opal and how it supports keeping current with Rails versions and other frameworks.  The panel asks if the Opal community made any inroads with DHH for making it part of the Rails stack proper and whether Opal wants to be integrated with Rails. Elia talks about some of Opal’s contributions to the Ruby Community. Elia talks about what generally happens if you choose to use Opal in a project. Opal is small, but you will have to make some tradeoffs. You have to call your standard library from Opal, but there are many ways to overcome that. The show concludes with Elia calling on the community to help him resurrect the Volt framework. Panelists Andrew Mason David Kimura Nate Hopkins With special guest: Elia Schito Sponsors Sentry use the code “devchat” for 2 months free on Sentry’s small plan Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $66 free credits with promo code RubyRogues My Ruby Story Links Opal  WebPacker Stimulus Hyperstack Capybara CoffeeScript Devise Clearwater Reactive Volt framework Nebulab Follow DevChatTV on Facebook and Twitter Picks David Kimura: AWS Organization Consolidated Billing Pingverse Nate Hopkins: Benjamin Moore paint Andrew Mason: Github Actions (beta) Elia Schito: Follow Elia on his website Explaining Postmodernism Texmate

stdout.fm 44번째 로그에서는 Form S-1, 컨테이너 런타임 rkt 아카이브, 슈프리마 개인정보 유출, 레일스5 업그레이드 등에 대해서 이야기를 나눴습니다. 참가자: @seapy, @nacyo_t 주제별 바로듣기 준비중 주제별 바로듣기 기능 추가 stdout_043.log: 갤럭시 노트 10, 테슬라 모델 3, Go 언어 입문, 테라폼 삽질 공유회 | 개발자 팟캐스트 stdout.fm MediaElement.js - HTML5 video and audio unification framework Rebuild - Podcast by Tatsuhiko Miyagawa Amazon Transcribe – 자동 음성 인식 – AWS Cloud Translation documentation  |  Cloud Translation  |  Google Cloud WeWork, Cloudflare Form S-1 제출 Form S-1 - The We Company Form S-1 Cloudflare, Inc. Dart - 플리토/증권신고서(지분증권)/2019.07.04 캐리소프트, 상장 철회…“연내 재도전” | Bloter.net 단독 - 먹구름 낀 IPO…1조클럽 우아한형제들·야놀자 내년 IPO 포기 - 매일경제 소프트캠프, 코스닥 이전 상장 추진 - ZDNet korea 투자 사전 - 스팩(SPAC)이란? 컨테이너 런타임 rkt 프로젝트 아카이브 CNCF Archives the rkt Project - Cloud Native Computing Foundation Home - Open Containers Initiative Docker Seoul (Seoul, Korea (South)) | Meetup Open source, containers, and Kubernetes | CoreOS etcd-io/etcd: Distributed reliable key-value store for the most critical data of a distributed system Red Hat to Acquire CoreOS, Expanding its Kubernetes and Containers Leadership IBM closes Red Hat acquisition for $34 billion | TechCrunch 슈프리마 개인정보 유출 23기가에 달하는 개인 식별 정보와 생체 정보 노출시킨 슈프리마 Elasticsearch: RESTful, 분산형 검색 및 분석 | Elastic Open Distro for Elasticsearch | Open Distro Security for Elasticsearch is now free | Elastic Blog 슈프리마아이디, 증권신고서 제출…8월 코스닥 상장 추진 | 연합뉴스 당근마켓 레일스 5 업그레이드 Legacy SQL 함수 및 연산자  |  BigQuery  |  Google Cloud mperham/sidekiq: Simple, efficient background processing for Ruby Active Job Basics — Ruby on Rails Guides brandonhilkert/sucker_punch: Sucker Punch is a Ruby asynchronous processing library Log Management Rails 6.0: Action Mailbox, Action Text, Multiple DBs, Parallel Testing, Webpacker by default, and Zeitwerk | Riding Rails Cleaning up a huge ruby application - RubyKaigi 2019

Sponsors Sentry use code “devchat” for $100 credit Datadog Panel David Kimura Andrew Mason Charles Max Wood With Special Guests: Julian Fahrer Episode Summary Julian Fahrer has been a guest on Devchat shows before and recently did a workshop at RailsConf about Docker. He specializes in teaching people about Docker and has his own course, LearnDocker.online. Julian begins by giving suggestions for those considering Dockerizing their Rails applications. He talks about why Docker is a good choice to be used in a local development environment and gives some advice for those who might have trouble running Docker in development. He talks about where Docker fits within the development or production environment. He talks about synchronizing code between development and production and running tests. He advises listeners on how to get started with Docker. He talks about using a Docker registry to build and push images. They discuss how to deal with things once you move to production and how to use containers when considering microservices. Julian talks about debugging in Docker. They finish by talking about Docker’s compatibility with frameworks besides Rails and how services talk to each other in Docker.  Links JSJ 340: JavaScript Docker with Julian Fahrer EMX 10: Docker with Julian Fahrer Docker Heroku Alpin.io Ubuntu Docker Sink OSXFS Spring Webpacker AWS  PostgreSQL Elasticsearch Kubernetes Scripts to Rule Them All LearnDocker.online Follow DevChat on Facebook and Twitter Picks Andrew Mason: Alsop Metal Art Dual Monitor Arms  Mental health days David Kimura: Arcade buttons Mini Dewalt air compressor Julan Fahrer: Alexander Technique Railswithdocker.com Blitz Donner Follow Julian at Codetales.io and @jufahr Charles Max Wood:  Four Corners Monument Dallas Children’s Museum

Sponsors Sentry use code “devchat” for $100 credit Datadog Panel David Kimura Andrew Mason Charles Max Wood With Special Guests: Julian Fahrer Episode Summary Julian Fahrer has been a guest on Devchat shows before and recently did a workshop at RailsConf about Docker. He specializes in teaching people about Docker and has his own course, LearnDocker.online. Julian begins by giving suggestions for those considering Dockerizing their Rails applications. He talks about why Docker is a good choice to be used in a local development environment and gives some advice for those who might have trouble running Docker in development. He talks about where Docker fits within the development or production environment. He talks about synchronizing code between development and production and running tests. He advises listeners on how to get started with Docker. He talks about using a Docker registry to build and push images. They discuss how to deal with things once you move to production and how to use containers when considering microservices. Julian talks about debugging in Docker. They finish by talking about Docker’s compatibility with frameworks besides Rails and how services talk to each other in Docker.  Links JSJ 340: JavaScript Docker with Julian Fahrer EMX 10: Docker with Julian Fahrer Docker Heroku Alpin.io Ubuntu Docker Sink OSXFS Spring Webpacker AWS  PostgreSQL Elasticsearch Kubernetes Scripts to Rule Them All LearnDocker.online Follow DevChat on Facebook and Twitter Picks Andrew Mason: Alsop Metal Art Dual Monitor Arms  Mental health days David Kimura: Arcade buttons Mini Dewalt air compressor Julan Fahrer: Alexander Technique Railswithdocker.com Blitz Donner Follow Julian at Codetales.io and @jufahr Charles Max Wood:  Four Corners Monument Dallas Children’s Museum

Sponsors Sentry use code “devchat” for $100 credit Datadog Panel David Kimura Andrew Mason Charles Max Wood With Special Guests: Julian Fahrer Episode Summary Julian Fahrer has been a guest on Devchat shows before and recently did a workshop at RailsConf about Docker. He specializes in teaching people about Docker and has his own course, LearnDocker.online. Julian begins by giving suggestions for those considering Dockerizing their Rails applications. He talks about why Docker is a good choice to be used in a local development environment and gives some advice for those who might have trouble running Docker in development. He talks about where Docker fits within the development or production environment. He talks about synchronizing code between development and production and running tests. He advises listeners on how to get started with Docker. He talks about using a Docker registry to build and push images. They discuss how to deal with things once you move to production and how to use containers when considering microservices. Julian talks about debugging in Docker. They finish by talking about Docker’s compatibility with frameworks besides Rails and how services talk to each other in Docker.  Links JSJ 340: JavaScript Docker with Julian Fahrer EMX 10: Docker with Julian Fahrer Docker Heroku Alpin.io Ubuntu Docker Sink OSXFS Spring Webpacker AWS  PostgreSQL Elasticsearch Kubernetes Scripts to Rule Them All LearnDocker.online Follow DevChat on Facebook and Twitter Picks Andrew Mason: Alsop Metal Art Dual Monitor Arms  Mental health days David Kimura: Arcade buttons Mini Dewalt air compressor Julan Fahrer: Alexander Technique Railswithdocker.com Blitz Donner Follow Julian at Codetales.io and @jufahr Charles Max Wood:  Four Corners Monument Dallas Children’s Museum

Добрый день уважаемые слушатели. Представляем новый выпуск подкаста RWpod. В этом выпуске: Ruby Rails 6.0: Action Mailbox, Action Text, Multiple DBs, Parallel Testing, Webpacker by default, and Zeitwerk, Rails 6 preserves status of #html_safe? on sliced and multiplied HTML safe strings и Rails 6 adds Relation#extract_associated Fail Fast and Fail Often: Handling API Errors at Scale, Magic comments in Ruby и Introducing Konfig: A Kubernetes Friendly Rails Configuration Gem Web Introducing the New React DevTools, Logic-less JSX, The Differing Perspectives on CSS-in-JS и Variable Font Animation with CSS and Splitting JS JavaScript & Node.js testing best practices Announcing meSpeak.js 2.0, Npkill - easily find and remove old and heavy node_modules folders и Deep Dive Into Modern Web Development

Sponsors Sentry use code “devchat” for $100 credit Datadog Panel David Kimura Andrew Mason Nate Hopkins With Special Guests: Taylor Jones Episode Summary Taylor Jones works remotely for Heroku in technical support. He talks about some of the most common issues he helps customers with and what issues he saw when Webpacker was introduced. The panel talks about their experience using Webpacker and how it has influenced their usage of React and Ruby. They talk about the importance of creating maintainable applications and the possible effects of using primarily new technology versus tried and true methods. It is important to keep architecture consistent, so that if you have to debug something old, you still know your way around. They discuss the forward progress in the Rails community and how the need for a JavaScript framework has decreased. They discuss improvements in adding elements from other languages into your code, especially since Webpacker added a way to manage JavaScript assets to the community. They discuss the impact Webpacker has had on application maintainability. For a more sustainable app, they suggest reducing the number of gems and dependencies in your application, and over all knowing what you’re putting in your app. Links Heroku Webpacker React Slack jQuery Ember Broccoli.js Stimulus Turbolinks Bootstrap Conductor Zoom Follow DevChat on Facebook and Twitter Picks Andrew Mason: Migration Builder by Jason Swett demo video David Kimura: Build-your-own arcade machine Honey  Taylor Jones:  Slack Engineering Team  Shape Up book from Basecamp Follow Taylor @hiimtaylorjones

Sponsors Sentry use code “devchat” for $100 credit Datadog Panel David Kimura Andrew Mason Nate Hopkins With Special Guests: Taylor Jones Episode Summary Taylor Jones works remotely for Heroku in technical support. He talks about some of the most common issues he helps customers with and what issues he saw when Webpacker was introduced. The panel talks about their experience using Webpacker and how it has influenced their usage of React and Ruby. They talk about the importance of creating maintainable applications and the possible effects of using primarily new technology versus tried and true methods. It is important to keep architecture consistent, so that if you have to debug something old, you still know your way around. They discuss the forward progress in the Rails community and how the need for a JavaScript framework has decreased. They discuss improvements in adding elements from other languages into your code, especially since Webpacker added a way to manage JavaScript assets to the community. They discuss the impact Webpacker has had on application maintainability. For a more sustainable app, they suggest reducing the number of gems and dependencies in your application, and over all knowing what you’re putting in your app. Links Heroku Webpacker React Slack jQuery Ember Broccoli.js Stimulus Turbolinks Bootstrap Conductor Zoom Follow DevChat on Facebook and Twitter Picks Andrew Mason: Migration Builder by Jason Swett demo video David Kimura: Build-your-own arcade machine Honey  Taylor Jones:  Slack Engineering Team  Shape Up book from Basecamp Follow Taylor @hiimtaylorjones

Sponsors Sentry use code “devchat” for $100 credit Datadog Panel David Kimura Andrew Mason Nate Hopkins With Special Guests: Taylor Jones Episode Summary Taylor Jones works remotely for Heroku in technical support. He talks about some of the most common issues he helps customers with and what issues he saw when Webpacker was introduced. The panel talks about their experience using Webpacker and how it has influenced their usage of React and Ruby. They talk about the importance of creating maintainable applications and the possible effects of using primarily new technology versus tried and true methods. It is important to keep architecture consistent, so that if you have to debug something old, you still know your way around. They discuss the forward progress in the Rails community and how the need for a JavaScript framework has decreased. They discuss improvements in adding elements from other languages into your code, especially since Webpacker added a way to manage JavaScript assets to the community. They discuss the impact Webpacker has had on application maintainability. For a more sustainable app, they suggest reducing the number of gems and dependencies in your application, and over all knowing what you’re putting in your app. Links Heroku Webpacker React Slack jQuery Ember Broccoli.js Stimulus Turbolinks Bootstrap Conductor Zoom Follow DevChat on Facebook and Twitter Picks Andrew Mason: Migration Builder by Jason Swett demo video David Kimura: Build-your-own arcade machine Honey  Taylor Jones:  Slack Engineering Team  Shape Up book from Basecamp Follow Taylor @hiimtaylorjones

Prathamesh Sonpatki and I discuss what Webpack and Webpacker are and how to use Webpack to manage JavaScript in Rails.

In today's episode, I talk to developer and author Noel Rappin about Webpack, Webpacker, and Stimulus.

Добрый день уважаемые слушатели. Представляем новый выпуск подкаста RWpod. В этом выпуске: Ruby Webpacker 4.0.2, Rubygems: March 2019 Security Advisories, Rails 6 adds Relation#reselect и Ruby's Hidden Gems, StringScanner Mruby/c - an another implementation of mruby, StoreModel - gem for handling JSON-backed attributes as ActiveRecord models, Active-record-query-trace - find the origin of all SQL queries in your Rails applications и What's New in Rails 6 (video) Web Storybook 5.0, JavaScript Performance Pitfalls in V8, Maintaining large JavaScript applications и JavaScript naming conventions: do's and don'ts JavaScript Algorithms and Data Structures, Handtrack.js: Hand Tracking Interactions in the Browser using Tensorflow.js and 3 lines of code и RFS - a font size engine which automatically calculates the appropriate font size based on the dimensions of the browser viewport

Sponsors: Sentry use the code “devchat” for 2 months free on Sentry small plan CacheFly Host: Charles Max Wood Special Guest:  Josh Justice Episode Summary In this episode of My Ruby Story, Charles hosts Josh Justice, software engineer at Big Nerd Ranch, a Mobile app development, training and design firm. Listen to Josh on the podcast Ruby Rogues on this episode. Josh wanted to be a software developer ever since he was very young, his father worked in IT so he had access to computers from very early on. After studying computer science, he started working as a developer in JavaScript, PHP and in Ruby. His specialties include Ruby on Rails, Ember, Vue.js and React Native. Josh really enjoys content creation for other developers and is currently streaming React Native TDD Fridays 2pm EST at Twitch.tv. Josh and his family recently adopted a baby boy in addition to his two daughters. Listen to the podcast to hear more about this miraculous adoption story! Links Ruby Rogues 391: Frontend Testing Like a Rubyist with Josh Justice React Native Testing feat. Josh Justice of Big Nerd Ranch Josh’s Twitter Josh’s GitHub Josh’s LinkedIn Michael Hartl's Ruby on Rails Tutorial Josh's Blog Learn Test-Driven Development Object Oriented and Functional Programming Blog Post https://devchat.tv/ruby-rogues/ https://devchat.tv/my-ruby-story/ https://www.facebook.com/DevChattv Picks Josh Justice: Webpacker Object Thinking Learn Test-Driven Development Ember and Rails Live Stream   Charles Max Wood: The Effective Executive by Peter F. Drucker      

Sponsors: Sentry use the code “devchat” for 2 months free on Sentry small plan CacheFly Host: Charles Max Wood Special Guest:  Josh Justice Episode Summary In this episode of My Ruby Story, Charles hosts Josh Justice, software engineer at Big Nerd Ranch, a Mobile app development, training and design firm. Listen to Josh on the podcast Ruby Rogues on this episode. Josh wanted to be a software developer ever since he was very young, his father worked in IT so he had access to computers from very early on. After studying computer science, he started working as a developer in JavaScript, PHP and in Ruby. His specialties include Ruby on Rails, Ember, Vue.js and React Native. Josh really enjoys content creation for other developers and is currently streaming React Native TDD Fridays 2pm EST at Twitch.tv. Josh and his family recently adopted a baby boy in addition to his two daughters. Listen to the podcast to hear more about this miraculous adoption story! Links Ruby Rogues 391: Frontend Testing Like a Rubyist with Josh Justice React Native Testing feat. Josh Justice of Big Nerd Ranch Josh’s Twitter Josh’s GitHub Josh’s LinkedIn Michael Hartl's Ruby on Rails Tutorial Josh's Blog Learn Test-Driven Development Object Oriented and Functional Programming Blog Post https://devchat.tv/ruby-rogues/ https://devchat.tv/my-ruby-story/ https://www.facebook.com/DevChattv Picks Josh Justice: Webpacker Object Thinking Learn Test-Driven Development Ember and Rails Live Stream   Charles Max Wood: The Effective Executive by Peter F. Drucker      

Sponsors: Sentry use the code “devchat” for 2 months free on Sentry small plan CacheFly Host: Charles Max Wood Special Guest:  Josh Justice Episode Summary In this episode of My Ruby Story, Charles hosts Josh Justice, software engineer at Big Nerd Ranch, a Mobile app development, training and design firm. Listen to Josh on the podcast Ruby Rogues on this episode. Josh wanted to be a software developer ever since he was very young, his father worked in IT so he had access to computers from very early on. After studying computer science, he started working as a developer in JavaScript, PHP and in Ruby. His specialties include Ruby on Rails, Ember, Vue.js and React Native. Josh really enjoys content creation for other developers and is currently streaming React Native TDD Fridays 2pm EST at Twitch.tv. Josh and his family recently adopted a baby boy in addition to his two daughters. Listen to the podcast to hear more about this miraculous adoption story! Links Ruby Rogues 391: Frontend Testing Like a Rubyist with Josh Justice React Native Testing feat. Josh Justice of Big Nerd Ranch Josh’s Twitter Josh’s GitHub Josh’s LinkedIn Michael Hartl's Ruby on Rails Tutorial Josh's Blog Learn Test-Driven Development Object Oriented and Functional Programming Blog Post https://devchat.tv/ruby-rogues/ https://devchat.tv/my-ruby-story/ https://www.facebook.com/DevChattv Picks Josh Justice: Webpacker Object Thinking Learn Test-Driven Development Ember and Rails Live Stream   Charles Max Wood: The Effective Executive by Peter F. Drucker      

Добрый день уважаемые слушатели. Представляем новый выпуск подкаста RWpod. В этом выпуске: Ruby What's new in Ruby 2.6? и How fast is Ruby 2.5, 2.6 and 2.6 –jit in generating Prawn PDFs Ruby memory, ActiveRecord and Draper и WebpackerCli - bringing the power of Webpacker to any web framework JavaScript The State of JavaScript 2018, Google to pay JavaScript frameworks to implement performance-first code и The Virtual DOM is slow. Meet the Memoized DOM. TensorSpace - a neural network 3D visualization framework built by TensorFlow.js, Three.js and Tween.js, Slate - a completely customizable framework for building rich text editors и NearDB - simple document db made for globally distributed reads

Joël Quenneville joins Chris to discuss Elm, the strongly typed functional programming language for writing reliable client side web apps. They discuss recent changes from the 0.19 release including reduced bundle size from dead code elimination, the somewhat controversial removal of custom operators. Anecdotally, Joël and team saw a reduction from 31.5K to 16.6K in bundle size going from 0.18 to 0.19 and felt no pain from the custom operators removal, so a big net win for them with this new version. Along the way Joël and Chris detour into the complexity of managing a project and community like Elm's and discuss Joël‘s recent work with the thoughtbot apprentice program. To round things out, Joël and Chris discuss the power of using a type system like Elm's to constrain the valid states of your application and make your apps more robust and maintainable. Elm - A delightful language for reliable webapps. Elm 0.19 Release Notes Webpacker Elm 0.19 - Dead Code Elimination Scala.js The reasoning behind removing user-defined operators Minesweeper for JavaScript Equality WebAssembly Linus Torvalds - "I am going to take time off and get some assistance..." Also Linus, on the importance of "trivial patches" as entry points for new kernal developers Derek Prior - Implementing a Strong Code-Review Culture thoughtbot code review guidelines thoughtbot apprentice program How Elm Slays a UI Antipattern "Making Impossible States Impossible" talk by Richard Feldman "Working with Maybe" talk by Joël Quenneville "Confident Code" talk by Avdi Grimm "Nothing is Something" talk by Sandi Metz The Zen of Python Breakable Toys Joel's many posts on the Giant Robots blog Stop Coding and Start Drawing

Still getting back into that Podcast Grind™ Jason and Chris explore Rails 6's introduction of Webpacker as the default JavaScript pipeline, Stephen Dolan's spectacular StimulusJS website (Stim Awesome), and some ramblings on a codecation Chris and Jason are taking to work on Secret Project X.

Panel: Charles Max Wood Nader Dabit Cory House Special Guests: Juho Vepsäläinen In this episode of React Round Up, the panel discusses Webpack the good parts with Juho Vepsäläinen. He talks a lot about the book he has written on Webpack, which helps people understand Webpack and how to work with it. They also discuss the advantages to using Webpack and discuss how you can use it in your coding to your benefit. In particular, we dive pretty deep on: For 10% off, use “Juho” to sign up for React Dev Summit What is Webpack? Juho’s Webpack book: SurviveJS React How can someone get into learning about Webpack if they’re not from a React background? It’s all about the contents behind Webpack How popular is Webpack and how large is it? You don’t need to read all 400 pages of his book Is there a certain way to write with Webpack? You can learn things as you go with Webpack How to approach code using Webpack How new updates with change the philosophy behind Webpack It’s good for Webpack to have pressure from the outside There is no reason to use a newer tool if it already works in an older tool Are there particular plug-ins that you use in Webpack that you really like? HTML plug-in React Native Interesting Webpack project uses Juho’s GitHub Decreasing need to be a Webpacker expert And much, much more! Links: React Dev Summit Webpack SuviveJS React React Native Juho’s GitHub NGconf React Finland Conference Picks: Charles React Dev Summit View on Vue Podcast The Whole-Brain Child by Daniel J. Siegel and Tina Payne Bryson Scott Beebe Nader React blogpost Ready Player One by Ernest Cline Cory The Knowledge Project Podcast Juho JAMstack

Panel: Charles Max Wood Nader Dabit Cory House Special Guests: Juho Vepsäläinen In this episode of React Round Up, the panel discusses Webpack the good parts with Juho Vepsäläinen. He talks a lot about the book he has written on Webpack, which helps people understand Webpack and how to work with it. They also discuss the advantages to using Webpack and discuss how you can use it in your coding to your benefit. In particular, we dive pretty deep on: For 10% off, use “Juho” to sign up for React Dev Summit What is Webpack? Juho’s Webpack book: SurviveJS React How can someone get into learning about Webpack if they’re not from a React background? It’s all about the contents behind Webpack How popular is Webpack and how large is it? You don’t need to read all 400 pages of his book Is there a certain way to write with Webpack? You can learn things as you go with Webpack How to approach code using Webpack How new updates with change the philosophy behind Webpack It’s good for Webpack to have pressure from the outside There is no reason to use a newer tool if it already works in an older tool Are there particular plug-ins that you use in Webpack that you really like? HTML plug-in React Native Interesting Webpack project uses Juho’s GitHub Decreasing need to be a Webpacker expert And much, much more! Links: React Dev Summit Webpack SuviveJS React React Native Juho’s GitHub NGconf React Finland Conference Picks: Charles React Dev Summit View on Vue Podcast The Whole-Brain Child by Daniel J. Siegel and Tina Payne Bryson Scott Beebe Nader React blogpost Ready Player One by Ernest Cline Cory The Knowledge Project Podcast Juho JAMstack

Panel:  Charles Max Wood Dave Kimura Eric Berry Special Guests: Justin Gordon and Rob Wise In this episode of Ruby Rogues, the panel discusses React on Rails and Webpacker with Justin Gordon and Rob Wise. They talk about the origins of React on Rails and compare it to Webpacker. They also talk about how the two go hand in hand and how you can use them in your own coding to make your life easier. In particular, we dive pretty deep on: React on Rails library Ruby on Rails adopted Webpack and called it Webpacker Define your fence lines for your library JavaScript Key features of React on Rails Props.md Angular issues with Webpacker How the original React on Rails worked Needed a view helper How much of a part is Webpacker to the core team? Webpack was huge win They made a lot of assumptions when making Webpacker Global registration Server rendering HTML HVMN.com jQuery Is there a path with this where you don’t have to be a react expert? Forum.shakacode.com Much Webpack to I need to know to pick up React on Rails? Do we need all of the Ruby stuff built around Webpack? React Router 2 types of developer to target And much, much more! Links: HVMN.com Forum.shakacode.com Shakacode.com @RailsonMaui Rob’s GitHub @RobAWise Picks: Charles Anti-Pick: INTELLIbed Tuft & Needle Bed Dave Bostitch Laminator Eric BitBar Justin Why We Sleep on Audible “Top Health Podcasts, Videos, And Books on Ketosis, Intermittent Fasting, Paleo, and related…”  “Justin’s favorite productivity tools (with Mac and iOS)” HawaiiChee.com Rob The Prettier Project for JavaScript by James Long

Panel:  Charles Max Wood Dave Kimura Eric Berry Special Guests: Justin Gordon and Rob Wise In this episode of Ruby Rogues, the panel discusses React on Rails and Webpacker with Justin Gordon and Rob Wise. They talk about the origins of React on Rails and compare it to Webpacker. They also talk about how the two go hand in hand and how you can use them in your own coding to make your life easier. In particular, we dive pretty deep on: React on Rails library Ruby on Rails adopted Webpack and called it Webpacker Define your fence lines for your library JavaScript Key features of React on Rails Props.md Angular issues with Webpacker How the original React on Rails worked Needed a view helper How much of a part is Webpacker to the core team? Webpack was huge win They made a lot of assumptions when making Webpacker Global registration Server rendering HTML HVMN.com jQuery Is there a path with this where you don’t have to be a react expert? Forum.shakacode.com Much Webpack to I need to know to pick up React on Rails? Do we need all of the Ruby stuff built around Webpack? React Router 2 types of developer to target And much, much more! Links: HVMN.com Forum.shakacode.com Shakacode.com @RailsonMaui Rob’s GitHub @RobAWise Picks: Charles Anti-Pick: INTELLIbed Tuft & Needle Bed Dave Bostitch Laminator Eric BitBar Justin Why We Sleep on Audible “Top Health Podcasts, Videos, And Books on Ketosis, Intermittent Fasting, Paleo, and related…”  “Justin’s favorite productivity tools (with Mac and iOS)” HawaiiChee.com Rob The Prettier Project for JavaScript by James Long

Panel:  Charles Max Wood Dave Kimura Eric Berry Special Guests: Justin Gordon and Rob Wise In this episode of Ruby Rogues, the panel discusses React on Rails and Webpacker with Justin Gordon and Rob Wise. They talk about the origins of React on Rails and compare it to Webpacker. They also talk about how the two go hand in hand and how you can use them in your own coding to make your life easier. In particular, we dive pretty deep on: React on Rails library Ruby on Rails adopted Webpack and called it Webpacker Define your fence lines for your library JavaScript Key features of React on Rails Props.md Angular issues with Webpacker How the original React on Rails worked Needed a view helper How much of a part is Webpacker to the core team? Webpack was huge win They made a lot of assumptions when making Webpacker Global registration Server rendering HTML HVMN.com jQuery Is there a path with this where you don’t have to be a react expert? Forum.shakacode.com Much Webpack to I need to know to pick up React on Rails? Do we need all of the Ruby stuff built around Webpack? React Router 2 types of developer to target And much, much more! Links: HVMN.com Forum.shakacode.com Shakacode.com @RailsonMaui Rob’s GitHub @RobAWise Picks: Charles Anti-Pick: INTELLIbed Tuft & Needle Bed Dave Bostitch Laminator Eric BitBar Justin Why We Sleep on Audible “Top Health Podcasts, Videos, And Books on Ketosis, Intermittent Fasting, Paleo, and related…”  “Justin’s favorite productivity tools (with Mac and iOS)” HawaiiChee.com Rob The Prettier Project for JavaScript by James Long

Tweet this Episode Jason Swett is a former Ruby Rogues panelist and the author of Angular on Rails. He's also a contractor and corporate trainer. Jason and Chuck dive into Jason's story getting into programming, Ruby, and talk about his current and past ventures in entrepreneurship. We also talk about writing courses and ebooks and blog posts. Links: Pascal Geocities Angelfire Perl Symfony framework PHP CodeIgniter Drupal Laravel Lisp Clojure Python Django Ruby Rails Amir Rajan's My Ruby Story Angular on Rails Basecamp Microconf JasonSwett.net Amazon AWS Indie Hackers Post Justin Gordon Justin Gordon's episode on Ruby Rogues Phoenix Elixir React Vue Webpacker Prototype.js JQuery Todd Motto Green Bits Email Jason @jasonswett Picks Jason: Amazon Web Services in Action awsrails.com Chuck Gitlab Mattermost The Daily Lasagna Entreprogrammers Ruby Dev Summit

Tweet this Episode Jason Swett is a former Ruby Rogues panelist and the author of Angular on Rails. He's also a contractor and corporate trainer. Jason and Chuck dive into Jason's story getting into programming, Ruby, and talk about his current and past ventures in entrepreneurship. We also talk about writing courses and ebooks and blog posts. Links: Pascal Geocities Angelfire Perl Symfony framework PHP CodeIgniter Drupal Laravel Lisp Clojure Python Django Ruby Rails Amir Rajan's My Ruby Story Angular on Rails Basecamp Microconf JasonSwett.net Amazon AWS Indie Hackers Post Justin Gordon Justin Gordon's episode on Ruby Rogues Phoenix Elixir React Vue Webpacker Prototype.js JQuery Todd Motto Green Bits Email Jason @jasonswett Picks Jason: Amazon Web Services in Action awsrails.com Chuck Gitlab Mattermost The Daily Lasagna Entreprogrammers Ruby Dev Summit

Tweet this Episode Jason Swett is a former Ruby Rogues panelist and the author of Angular on Rails. He's also a contractor and corporate trainer. Jason and Chuck dive into Jason's story getting into programming, Ruby, and talk about his current and past ventures in entrepreneurship. We also talk about writing courses and ebooks and blog posts. Links: Pascal Geocities Angelfire Perl Symfony framework PHP CodeIgniter Drupal Laravel Lisp Clojure Python Django Ruby Rails Amir Rajan's My Ruby Story Angular on Rails Basecamp Microconf JasonSwett.net Amazon AWS Indie Hackers Post Justin Gordon Justin Gordon's episode on Ruby Rogues Phoenix Elixir React Vue Webpacker Prototype.js JQuery Todd Motto Green Bits Email Jason @jasonswett Picks Jason: Amazon Web Services in Action awsrails.com Chuck Gitlab Mattermost The Daily Lasagna Entreprogrammers Ruby Dev Summit

Tweet this Episode Matias Korhonen has been writing Rails apps professionally at Kisko Labs, a Rails-focused software consultancy in Finland, for almost a decade. In his spare time he works on too many side projects (including Piranhas.co), a book price comparison site, and TLS.care (an SSL certificate monitoring service). He also somehow manages to find time to homebrew beer. The Rogues talk to Matias about securing your Rails applications. Rails comes with a lot of security features built in, but you can still leave yourself open to exploitation if you're not careful. Most of these problems occur in the portion of the app your write as opposed to the parts of the app that Rails handles for you. We go over several tools and techniques for making sure your application, access, and data are all secure. In particular, we dive pretty deep on: Tools that you can use to scan for vulnerabilities or add more security checks to your applications Authentication and authorization mistakes Securely managing data and much, much more... Links: secureheaders brakeman Code Climate CloudFlare zxcvbn Troy Hunt article on pwned passwords Devise Security Extension pundit Drifting Ruby episode on Complex Strong Parameters gemnasium bundler-audit OWASP Zed Attack Proxy Project rack-attack Picks: Brian: Regex 101 Give and Take by Adam Grant Eric: Indie Hackers Dave: Sumo Logic Chuck: Ready Player One Comic-Con trailer breakdown Mattermost Ruby Rogues Parley Ruby Dev Summit (FREE) Matias: Webpacker 3.0 ActiveStorage Heroku

Tweet this Episode Matias Korhonen has been writing Rails apps professionally at Kisko Labs, a Rails-focused software consultancy in Finland, for almost a decade. In his spare time he works on too many side projects (including Piranhas.co), a book price comparison site, and TLS.care (an SSL certificate monitoring service). He also somehow manages to find time to homebrew beer. The Rogues talk to Matias about securing your Rails applications. Rails comes with a lot of security features built in, but you can still leave yourself open to exploitation if you're not careful. Most of these problems occur in the portion of the app your write as opposed to the parts of the app that Rails handles for you. We go over several tools and techniques for making sure your application, access, and data are all secure. In particular, we dive pretty deep on: Tools that you can use to scan for vulnerabilities or add more security checks to your applications Authentication and authorization mistakes Securely managing data and much, much more... Links: secureheaders brakeman Code Climate CloudFlare zxcvbn Troy Hunt article on pwned passwords Devise Security Extension pundit Drifting Ruby episode on Complex Strong Parameters gemnasium bundler-audit OWASP Zed Attack Proxy Project rack-attack Picks: Brian: Regex 101 Give and Take by Adam Grant Eric: Indie Hackers Dave: Sumo Logic Chuck: Ready Player One Comic-Con trailer breakdown Mattermost Ruby Rogues Parley Ruby Dev Summit (FREE) Matias: Webpacker 3.0 ActiveStorage Heroku

Tweet this Episode Matias Korhonen has been writing Rails apps professionally at Kisko Labs, a Rails-focused software consultancy in Finland, for almost a decade. In his spare time he works on too many side projects (including Piranhas.co), a book price comparison site, and TLS.care (an SSL certificate monitoring service). He also somehow manages to find time to homebrew beer. The Rogues talk to Matias about securing your Rails applications. Rails comes with a lot of security features built in, but you can still leave yourself open to exploitation if you're not careful. Most of these problems occur in the portion of the app your write as opposed to the parts of the app that Rails handles for you. We go over several tools and techniques for making sure your application, access, and data are all secure. In particular, we dive pretty deep on: Tools that you can use to scan for vulnerabilities or add more security checks to your applications Authentication and authorization mistakes Securely managing data and much, much more... Links: secureheaders brakeman Code Climate CloudFlare zxcvbn Troy Hunt article on pwned passwords Devise Security Extension pundit Drifting Ruby episode on Complex Strong Parameters gemnasium bundler-audit OWASP Zed Attack Proxy Project rack-attack Picks: Brian: Regex 101 Give and Take by Adam Grant Eric: Indie Hackers Dave: Sumo Logic Chuck: Ready Player One Comic-Con trailer breakdown Mattermost Ruby Rogues Parley Ruby Dev Summit (FREE) Matias: Webpacker 3.0 ActiveStorage Heroku

Merhaba,Bu hafta, geçen haftaki haberleri yayınlamak zorunda kalıyoruz. Gecikme için lütfen kusura bakmayın. Anlayışınız için teşekkürler.[ Dinle ]Multiple vulnerabilities in RubyGemsRubyGems blog postGraphQL in RailsNews in Ruby on RailsWebpacker 3.0AWS Sdk 3.0 for RubyGithub RepoRails and Third PartiesGCP for Private RubyGemsZen Rails Base AppFacade Design Pattern in RailsValidate TCKN RubyGemsTolga GezginişTorrent searching RubyGems CLIMurat Baştaş

Добрый день уважаемые слушатели. Представляем новый выпуск подкаста RWpod. В этом выпуске: Ruby Sequel 5.0.0 Released, Webpacker 3.0: No separate process needed, less config generated, Multiple vulnerabilities in RubyGems и Careful what you measure: 2.1 times slower to 4.2 times faster - MJIT versus TruffleRuby Why I do not use strong parameters in Rails, ExceptionAlarm - a simple gem play an alarm sound when an exception is raised on your Ruby code и ActiveRecord Migrations (video) JavaScript Announcing TypeScript 2.5, Fast Properties in V8 и Concurrent JavaScript: It can work! Patent Free React Ecosystem Migration Plan, React-Move 2.0

The Elm Programming Language With Corey Haines Follow us on Twitter! @techdoneright (https://twitter.com/tech_done_right), and leave us a review on Apple Podcasts (https://itunes.apple.com/us/podcast/tech-done-right/id1195695341?mt=2). Guest Corey Haines (https://twitter.com/coreyhaines): CTO of Hearken (https://www.wearehearken.com/), creator of code retreats, and author of Understanding the Four Rules of Simple Design (https://leanpub.com/4rulesofsimpledesign). Summary Want to build great front-end apps without having to deal with the entire JavaScript ecosystem? Corey Haines joins the show to talk about Elm, a front-end language and framework that is type safe, has great build tools, and a full-fledged MVC framework to create client interactions with less hassle. Corey has been using Elm to build the site for his company, Hearken, and talks about why he picked it, and what has made Elm a success for them. For More Info We've got a blog post relating to the code examples in this episode, you can find it at https://medium.com/table-xi/union-types-in-elm-fb6a974ec427. Notes 02:25 - What is Hearken (https://www.wearehearken.com/)? 05:14 - The Elm Programming Language (http://elm-lang.org/) The ML Programming Language (https://en.wikipedia.org/wiki/ML_(programming_language)) Dealing with Time in Elm (https://medium.com/@lars.jacobsson81/dealing-with-time-in-elm-0-17-3af5274650fb) 08:06 - The Type System and The Compiler Editable (http://package.elm-lang.org/packages/stoeffel/editable/latest/Editable) F# (http://fsharp.org) If you want a really detailed overview of types in programming languages, here's one from Gary Bernhardt (https://www.destroyallsoftware.com/compendium/types?share_key=baf6b67369843fa2) Maybe type in Elm (http://package.elm-lang.org/packages/elm-lang/core/5.1.1/Maybe) Union Types (https://guide.elm-lang.org/types/union_types.html) 21:27 - Elm as a Framework The Elm Architecture (https://guide.elm-lang.org/architecture/) Managed Effects and Elm (https://medium.com/@kaw2k/managed-effects-and-elm-36b7fcd246a9) 26:16 - Deciding to use Elm 28:37 - Elm: Gotchas and Technical Limitations? Uploading files with Elm (https://www.paramander.com/blog/using-ports-to-deal-with-files-in-elm-0-17) 32:37 - Styling and Working with Designers elm-css (https://github.com/rtfeldman/elm-css) 35:45 - The Elm Community Join Elm on Slack (https://elmlang.herokuapp.com/) 37:14 - Getting Started with Elm The Elm Guide (https://guide.elm-lang.org/) The Pragmatic Studio: Building Web Apps with Elm (https://pragmaticstudio.com/elm) Elm Remote Meetup (https://www.dailydrip.com/topics/elm-remote-meetup) Webpacker (https://github.com/rails/webpacker) Special Guest: Corey Haines.

Inline rescuing from blocks in Ruby 2.5, JavaScript & Rails making up with Yarn & Webpacker, system tests in Rails 5.1, and the upcoming Active Storage in Rails 5.2