Podcast appearances and mentions of dave rupert

  • 41PODCASTS
  • 77EPISODES
  • 50mAVG DURATION
  • 1MONTHLY NEW EPISODE
  • Dec 16, 2024LATEST

POPULARITY

20172018201920202021202220232024


Best podcasts about dave rupert

Latest podcast episodes about dave rupert

ShopTalk » Podcast Feed
646: Hard Code & Soft Skills

ShopTalk » Podcast Feed

Play Episode Listen Later Dec 16, 2024 71:14


Show DescriptionThe employees of the startup RAPPTR (Quinn Pine, Blaze Lightyear, Astra Q, and Eddit Kit) find themselves in quite a pickle as a rogue investor tries to take over the company while CEO Chad is recovering in his napping pod. Join us on a workplace-themed role playing adventure created by Dave Rupert. Listen on Website →GuestsAlex (Eddie)Guest's Main URL • Guest's TwitterA web developer from Atlanta, GA that specializes in Vue.js, python, and PHP. Ben (Blaze)Guest's Main URL • Guest's TwitterA user-centered frontend developer with a focus on web accessibility. Miriam (Astra)Guest's Main URL • Guest's TwitterCo-Founder of OddBird, working on CSS in a W3C group. Links Hard Code & Soft Skills Lasers & Feelings by John Harper one.seven design studio SponsorsBluehostFind unique domains, web hosting, and WordPress tools, all in one place. Empower your business or digital agency with Bluehost.

The Changelog
ShopTalk & Friends (Friends)

The Changelog

Play Episode Listen Later Dec 6, 2024 94:14


Chris Coyier and Dave Rupert join Adam and Jerod for a ShopTalk & Friends conversation on the viability of the web, making content, ads to support that content, Codepen's future plans, books, side quests, and social networks devaluing links.

Changelog Master Feed
ShopTalk & Friends (Changelog & Friends #72)

Changelog Master Feed

Play Episode Listen Later Dec 6, 2024 94:14 Transcription Available


Chris Coyier and Dave Rupert join Adam and Jerod for a ShopTalk & Friends conversation on the viability of the web, making content, ads to support that content, Codepen's future plans, books, side quests, and social networks devaluing links.

ShopTalk » Podcast Feed
640: Navigating the Pros and Cons of Web Components

ShopTalk » Podcast Feed

Play Episode Listen Later Nov 4, 2024


Show DescriptionRiffing off a Dave Rupert blog post, Chris and Dave talk through the pros and cons of web components, when to use them, when it's a bad idea to use them, what would it take to make the Next.js of web components, and how long until we don't need anymore frameworks? Listen on Website →Links Where web components shine - daverupert.com Fluent UI - Get started - Fluent UI React Website Improvement Begin Team to Join Eleventy Generator Components URLPattern Polyfill SponsorsBluehostFind unique domains, web hosting, and WordPress tools, all in one place. Empower your business or digital agency with Bluehost.

Syntax - Tasty Web Development Treats
813 - CSS: Scroll Driven Animations

Syntax - Tasty Web Development Treats

Play Episode Listen Later Aug 26, 2024 21:32


In this episode of Syntax, Wes and Scott talk about CSS' new scroll-driven animations, its implementation, uses, and potential pitfalls. They also discuss animation-timeline and animation-range, and how they can be utilized to control animations based on scroll positions. Show Notes 00:00 Welcome to Syntax! 00:46 Brought to you by Sentry.io 01:35 Scroll-driven animations Syntax 695: 5 New CSS Features You Should Know Scroll-driven animations demos and tools 04:13 @keyframes 05:22 animation-timeline 11:35 animation-range 08:49 View-based timelines 17:45 Neat uses: Dave Rupert on styling :stuck Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Underbelly
S2 E12: The Other Side of Town

Underbelly

Play Episode Listen Later Jun 5, 2024 38:49


Dave Rupert retires to a life in hiding, reflecting on a journey that took him across the Atlantic and back. We visit an icon of Belfast that shows just how much the north has changed. We reflect on what Dave contributed to the peace in Ireland and whether a reunited Ireland could be possible in our lifetime.  Learn more about your ad choices. Visit megaphone.fm/adchoices

Underbelly
S2 E11: McKevitt v. Pallasch

Underbelly

Play Episode Listen Later May 29, 2024 43:16


Dave Rupert's contract was just for intelligence gathering, but now he's asked to testify in court. Will he out himself as an agent and informer, furthering putting himself and his family in danger? When Mickey McKevitt faces charges under a new law in the Irish Special Criminal Court, his lawyers are going to have to dig deep to discredit a potential witness. That's when they get wind of a book deal back in Chicago.  Learn more about your ad choices. Visit megaphone.fm/adchoices

Underbelly
S2 E10: Spying on Mickey

Underbelly

Play Episode Listen Later May 22, 2024 37:02


After years of hard work and learning the ins and outs of Irish republicanism, Dave Rupert is in with the Real IRA. He's rubbing shoulders with one of the most dangerous men in Ireland. Dave is fast friends with the man who Irish and British governments say is the terrorist who must be stopped to prevent another tragedy like Omagh. Dave knows how to work his angles, but he worries about whether the security services can keep up.  Learn more about your ad choices. Visit megaphone.fm/adchoices

Underbelly
S2 E09: The Two Mickeys

Underbelly

Play Episode Listen Later May 8, 2024 42:26


The last militant Republicans still willing to fight after the Omagh bombing are looking for support. What better support could you ask for than a wealthy American offering cash and weapons from the United States? Joe O'Neil introduces Dave Rupert to a storied Republican named Mickey Donnelly and with that connection, Dave is whisked off to a meeting with the Real IRA's top man: Mickey McKevitt. Learn more about your ad choices. Visit megaphone.fm/adchoices

Underbelly
S2 E08: Omagh

Underbelly

Play Episode Listen Later May 1, 2024 44:19


A car bomb explosion kills 31 people -- including unborn twins -- in the town center of Omagh in Northern Ireland. The Real IRA takes public responsibility for the bombing, but the story that trickles out maintains it was a horrible mistake. In this episode, we explore the aftermath of the bombing that infuriated Irish from coast to coast, north and south. Meanwhile, Dave Rupert is suddenly in real danger as any IRA associates become public enemies and a central target of security services.  Learn more about your ad choices. Visit megaphone.fm/adchoices

Underbelly
S2 E07: Good Friday

Underbelly

Play Episode Listen Later Apr 24, 2024 43:07


On Good Friday in 1998, a treaty that will come to be called the Good Friday Agreement is signed by several nations. At its core, it's an a plan for peace that will involve a decommissioning process for paramilitary groups and a plan for a future vote on a united Ireland. For some, it's about forgiveness, hope and peace. For others, it's the same old story: another surrender to British Authority. Dave Rupert has a front row seat for the final significant fracturing of militant Republicans of the 20th century. Where does he go from here? Learn more about your ad choices. Visit megaphone.fm/adchoices

The Ben Joravsky Show
Abdon Pallasch and Bob Herguth—The Rebel Kind

The Ben Joravsky Show

Play Episode Listen Later Apr 22, 2024 68:33


Abdon Pallasch and Bob Herguth talk about their recently released 12-episode podcast—Underbelly: The Rebel Kind. It tells the story of Dave Rupert, a truck driver who winds up as an FBI mole, insinuating his way to the highest ranks of the Real IRA. Yes, the IRA, as in Irish Republican Army. Bob and Abdon—investigative reporters in Chicago—met Dave and one thing led to another and the FBI started coming after them. What happed was—oh, just listen to Abdon and Bob tell the story.See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.

Underbelly
S2 E06 The City That Dyes its River Green

Underbelly

Play Episode Listen Later Apr 17, 2024 46:08


Dave Rupert has spent years earning the trust of his IRA friends in Ireland and they've finally given him a military task. Dave heads back to Chicago with a name: Frank O'Neill. He's about to discover why an FBI agent like Ed Buckley was tasked with rooting out any connections between Chicago and militant Republicans. Dave's next moves will be in a city that goes as far as dyeing a whole river green on St. Patrick's Day.  Learn more about your ad choices. Visit megaphone.fm/adchoices

Underbelly
S2 E03: The FBI Walks Into a Bar

Underbelly

Play Episode Listen Later Mar 27, 2024 46:33


Dave Rupert experiences a little indigestion as he mulls over an offer from the FBI. He'll learn the agent who approached him has a background in investigating international terrorism back in Chicago. In fact, Ed Buckley is well known to Irish Republican supporters in the city. When Dave sees an opportunity to make some money, he goes for it.  Learn more about your ad choices. Visit megaphone.fm/adchoices

Giant Robots Smashing Into Other Giant Robots
517 - Building Better Design Systems with Luro's Trent Walton

Giant Robots Smashing Into Other Giant Robots

Play Episode Listen Later Mar 21, 2024 44:59


Hosts Victoria Guido and Will Larry are joined by Trent Walton, CEO of Luro. Trent shares his journey into the design world, from his early fascination with typography and logos to co-founding Paravel. This agency later evolved into creating Luro, a no-code solution for building design systems and tracking their adoption across products. Trent emphasizes the importance of understanding the materials one works with in design and development and stresses the need for a holistic approach to product building. This approach blurs the lines between disciplines, encouraging a generalist mindset over specialization. Luro, as a product, stemmed from the realization that existing design systems often fell short in adoption and application, leading to a search for a more integrated and comprehensive solution. Trent outlines the functionality and vision behind Luro, explaining how it serves not just designers and developers but entire organizations by fostering better collaboration, documentation, and understanding of design decisions. Luro aims to streamline the creation and maintenance of design systems, making them more accessible and manageable, even for teams facing resource constraints. By incorporating performance, accessibility metrics, and the ability to track component adoption and integration, Luro provides a platform for continuous improvement and alignment with organizational goals. Luro (https://luroapp.com/) Follow Luro on LinkedIn (https://www.linkedin.com/company/luroapp/), YouTube (https://www.youtube.com/channel/UCsS9BEmX1NPBXkbaLGcMZlw), Discord (https://discord.com/invite/aNEdjnR6A5), or Instagram (https://www.instagram.com/luroapp/). Follow Trent Walton on LinkedIn (https://www.linkedin.com/in/trent-walton/). Visit his website at trentwalton.com (https://trentwalton.com/). Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Transcript:  VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. WILL: And I'm your other host, Will Larry. And with me today is Trent Walton, CEO of Luro. Luro is a no-code solution to build your design system and track adoption across your entire product. Trent, thank you for joining me. TRENT: Oh, thanks for having me. It's great to be here. WILL: Yeah, I can't wait to dive into Luro and get to know more about the product. But before we go into that, tell us a little bit about yourself. I know you're based out of Texas. TRENT: Yeah, I grew up, lived here my whole life. I'm in Austin with the other co-founders, Dave and Reagan. Been a designer probably all my life, always been interested in, like, typography and fonts. When I was little, I used to buy badges for cars from swap meets and take them home, not because I needed, like, I had a car I was building and had any interest in, like, sandblasting or building an engine. I just liked the typography, and the design of the icons, and the logos, and all that kind of thing. And so, now it's evolved into me just being, like, a type aficionado and a graphic design aficionado, and then that evolved into, especially when I discovered the web in the early 2000s, building and designing websites with Dave and Reagan, who I mentioned. And so, we had an agency called Paravel early on and had a lot of time putting into practice kind of that design and development and building for the web. VICTORIA: So, your first interest in design came from, is it a car engine? Is that what I heard? TRENT: Well, yeah, my father is a mechanical engineer, and so is my brother. And they work on cars, have classic, like, old Mustangs and Cobras and things that they build in their spare time. And I have no interest in that kind of work [laughs] but grew up in that environment. And, you know, pre-internet growing up in the '80s, one of the things that really got me was the aesthetic and the design around those kinds of muscle cars, so, like, old Shelby or Cobra or Mustang Ford ads, just, I really got into that. So, I'd buy, like, car manuals for a few bucks, or if there's a Mustang Cobra and there's a cool, like, chrome snake logo with a condensed uppercase typeface or some sort of lettering that says, you know, "Shelby Cobra." And that's when I realized [laughs] where my interests lie. You know, engines are cool. They sound cool. Fast cars are cool. But I was just totally, you know, enamored with the typography and the design aspect that surrounded those things, and then it just kind of evolved from there. Anything else I could get my hooks into, I picked up on. VICTORIA: I love that because when I talk to people about design, for folks who don't have a background in it, they kind of think, oh, design, that's logos. You know, I'm redesigning my house right now. My husband is like, "Oh, it's picking the tiles and the colors. We can do that." And I'm like, "No, like, design, there's a lot more to it. Design is everywhere." Like, you can find design inspiration from car manuals [laughs], it's so funny that you bought those, or from random logo design and actually, like, really good design. If it's something that's designed well, you probably don't even notice it. You just flow and use the space or use the app as you're intended to. TRENT: Yeah. And I also think that getting inspiration or starting ideas out from anywhere but the medium you're working in might be a nice little trick to bring some, like, naïve, fresh perspective to things. So, I try to go back to that stuff as much as possible. I have heaps of manuals I've bought off of eBay in recent years, yeah, things you wouldn't think you'd find on, like, you know, whatever, a graphic designer's bookcase, just anything to sort of break the monotony or break my own little lenses of what a website should look like, or what a logo or a brand should look like, how to step outside of that a little bit. But it's funny because it really does go back to that initial sense of wonder I experienced at those really just, you know, we're talking, like, in a gross, swampy field in Texas with, like, funnel cakes being served at every corner, like, not the most slick, rad graphic designy vibe, but that's where it all started for me. So, I go back there as often as I can [laughs]. VICTORIA: So, how do you talk to founders or people who are thinking about building products? How do you talk to them about design and give them a where to get started approach? TRENT: I don't know that I ever specifically talk about design or even maybe, like, engineering or about performance. I talk about all those things, accessibility, et cetera. I try to blur those lines as much as possible. It's maybe an idyllic thing that I've had for years. But going back to the agency days, I'll call them the agency days, but up until, like, you know, 2015, '16, Dave, Reagan, and I ran an agency called Paravel. And by nature, the three of us are some sort of a hybrid between a designer, maybe, like, a front-end developer. You know, Dave's more of an engineer now. But we've all been very careful to make sure that we're generalists, which I don't know that that, like, career-wise that, might pay off long term, but I cannot work on the web any other way or talk about the web any other way. I've always felt like, I mean, there was the old, which we don't have to get into, gosh, but the debate on should designers code? But I think the essence of that is really, like, should we be familiar with the materials we're working on? So, anytime I start to talk about designing for the web or designing a product, you want to make sure everyone has a clear understanding of the environment that they're working with. So, is it, you know, a website? And is performance important? And is our site that we're redesigning is it performant now? Is it fast or slow? Or am I a designer who only cares, and this is a thing that I have to fight inside of myself all the time? So, I'm not trash-talking anybody, but, like, do I want to load a bunch of fonts and cool images, and is that my KPI is how interesting and engaging the visuals are? Which is a great one to have, but it also, you know, while you're talking about design, you have to consider all of these other things that can define quality for an experience. Maybe those other things don't matter as much from one person to the next. But the more they are in front of me, the more they evolve the way I perceive what I work on. And so, I try to never really isolate any kind of aspect into maybe, like, a stage or a sprint that we're doing as a team. It's just sort of this holistic kind of hippie vibey way to look at sites, but I want to make sure that it's always, like, we're always starting from a very, very broad place that involves every aspect, and all team members and stuff like that. VICTORIA: Well, I love that because I try to think about that in the same way from the other end, like, on the operations perspective when you're talking about site performance. And, you know, like, is the site responding fast enough? And it comes back to the question of, like, well, what is the experience, expectations of the user? And what's important to get done on the site? [laughs] And having those conversations, like, early on and integrating all these different teams from the design and development and operation side to have that conversation so everyone knows what is the goal of the site and what is the important aspects of the user experience that the system needs to be able to support? So, I also like that you said that it's like, well, should you be familiar with the materials that you're using? [laughs] Thought that that was really cool. Like, I'm actually...my husband and I are renovating our home. And I'm talking about why we should invest in design [laughs], and part of it's because there's things to know about the materials. Like, if you're choosing a floor for your house, like, the designers will know, like, what's the durable ones? What's the ones that are going to fit your need, and your cost, and your budget? And so, like, they don't necessarily need to be a person who's going to lay the floors [laughs], but they need to know what to expect out of what you decide to use. TRENT: Yeah, it's, like, all of these constraints. And so, being familiar with the real-world implications of the decisions we make, you know, inform that. So, yeah, I mean, I think that's pretty similar, too. It's like, well, you need this floor because it's more durable in this climate or whatever, same thing for, you know, the websites that we build. It's all contingent upon the outcomes that, hopefully, we can mutually agree on. You know, there's kind of a general sense of, like, performance is important, and accessibility is paramount and extremely important. But then there's some nuance to that as you get into some smaller decisions. So, having these kinds of discussions early on and frequently and almost...the way I like to think about it is rather than, like, a check-in where we say, "Okay, this is it," but having a place where we can all look to check in and find information and share information that's maybe not so fast. One thing I like to think about is things get lost in chats and maybe even tickets, so as you're closing tickets and opening tickets. There's a bug. I solved it. It's gone. Can you send me this logo? Can we tweak this? These micro changes they open and close very, very quickly. And so, there's this firehose that happens. And so, I find that having a place separate from that for discussing these things and remembering these things, and referencing these things while we are in our code editors or inside of our Figma or any kind of design tool that we use to sort of cross-reference and simmer on things as we think about the decisions that we have to make, as opposed to just knocking them out super quick, always being mindful of those constraints. And again, yeah, the [chuckles] materials we're working with, whether it's just, you know, HTML, CSS, and JavaScript or whatever, but all of those things. It's good to be mindful of that. WILL: I know you said that you've been in design for a while, and so I love just picking the brain of someone who's been into it a while and see how far we've come from, especially just the 2000s. So, in your opinion, with design, how do you feel about where we've come since the beginning of tech to where we're at now and, also, I guess, where we're going with the design? TRENT: Yeah. So, I guess I can really just frame...this is going to help me remember just framing [laughs] where we were. I started off on Homestead, which is sort of like GeoCities. I was in college. I graduated, and I think it was 2001, maybe 2000, anyways. And it was mainly just taking images...I didn't even have Photoshop at this point. And you realize you could, like, tile a background for a build your own website. Homestead was one of those kinds of deals. And I thought that was very interesting. So, I had this cheap digital camera. It took a lot of cords to figure out how to, like, port that onto this old, crappy Hewlett Packard computer that was, like, a hand-me-down. Fast forward a couple of years, I had graduated, did not study design, so I'm all kind of self-taught or just taught by the web, the peers, the information that has been shared and been influenced by. But Dreamweaver was out, and Macromedia was huge, and I loved Fireworks. And so, Dave Rupert, I paid him $80 to teach me HTML [laughs], and so we've been together ever since. This is right out of college. And so, the tools that we used there were pretty rudimentary, but Fireworks was rad. Like, it was kind of web-based. It felt like it made more sense. I love Photoshop, and that's kind of, like, a primary graphic design tool that I still use to this day. But early on, it just felt like everything was so harshly limited. So, if you had any kind of idea that you wanted to execute that you could just draw on a piece of paper, mock it up in Photoshop, the amount of work that you had to do to get that to happen was either extremely high, or it was just impossible. And then, if it was impossible, I bet you can guess what we did. We went to Flash, and we made, like, a crappy video of a web page that was not accessible and really hard to use. I was heavy into Flash for, like, two or three years until kind of, as I had been warned by Dave that, you know, HTML and CSS are going to be the way the web works. But when I came back to that, there was this wonderful time where it felt like we were charting out every single...it was just new territory. It's like we had come to this other planet or this other world, and everything that needed to be done, we had to figure out how, like, getting web fonts onto pages, rounding borders. I mean, getting that done aside from slicing images in Fireworks felt like this new monumental discovery that changed the lives of many. Maybe it did, maybe it didn't, but in my world, it felt like that. And so, early on, you can look back on it and go, gosh, everything was a pain in the ass, like, living with all of these limitations. But for me, I do look back at it like that, but I also look back on it as this wonderful time where we were building the web that we're working on now. So, all these things that make designing easier and quicker come with some sort of a, you know, an evolution of your perception, and [inaudible 13:14] fond memories of work along the way. For me, it's sort of I've just always sort of been around working on the web and watching design evolve, and every little step maybe feels like a tiny one or a large one. But these days, it just seems like, oh, this is exactly how it should have [laughs] always been, like, convenient grids and convenient box shadow and all that kind of stuff. But yeah, it's been nice to sort of grow up only being a web designer. Like, I mean, I've done graphic design. I've done brochures and, print design, and logo design for sure. But, I have always been anchored to and centered around web design and thinking about things in the context of how they will be applied to the web first and foremost. MID-ROLL AD: Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you're tight on time and investment, which is why we've created targeted 1-hour remote workshops to help you develop a concrete plan for your product's next steps. Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success. Find out how we can help you move the needle at tbot.io/entrepreneurs. VICTORIA: So, what was the turning point for you that led you to found Luro? How did it all get started? TRENT: With Paravel, the agency days, we had a lot of fun. I think, for us, our big agency spike was when responsive web design came out. Ethan coined the term. There was a lot of people on the web, you know, a lot of agencies or a lot of teams, a lot of companies that needed to pivot into that. And so, we found this great working relationship with companies where we would come in and sort of had a little bit more practice just because we got in early learning kind of how to do that well, I think. And it was a sort of we're going to redesign a page, a homepage perhaps, or, like, a marketing page. You'll do that project; three to six months go by. And then the next thing turns into, well, we have this giant network of e-commerce stores. We have this giant network of pages with, like, download centers and support documents. And now, we need to make everything responsive, and it can be anything. We need to make everything accessible. We need to make everything performant. We need to update the brand on everything. And I don't think we're alone in this. I think this is the beginning of the greater design system discussion as it applies to the web. Obviously, design systems predate the web; design systems pre-date, like, 2012 or '13 or whenever we got into it. But projects started to migrate from, "Hey, can you design this really amazing, responsive marketing page," to "We have a system, and we need you to solve these problems." We love working on those problems. I still do to this day. But the reason why we switched from kind of being a, you know, individual contributor-type agency consultant type roles to building a SaaS product was because we were realizing that things got complicated...is a very, like, boring way to say it. But to get a little deeper, it was, we would see things not ship. So, like, our morale went down. The teams that we were working with morale kind of went down. And as I was digging into why things weren't shipping...and when I mean ship, I think, like, pages would ship, of course. Like, here's a page. It just needs to be built, somebody decided, or a new feature needs to be built. Of course, those went out. But the idea of, is our design system or the system that we're designing launched? Is it applied? Is it fully adopted? Is it partially adopted? It never felt like the amount of traction that we were promising or that we were being asked for. And I don't mean we, as in just the three of us, but the entire team or the entire organization who, in many cases, all were bought into the idea of design systems. So, what we found was, when things got real, and we had to give up things, and we had to work on things and prioritize things, it became much more difficult to work in that capacity, probably partially because of the cross-discipline nature of those things. So, as opposed to what I consider maybe a miserable way to work in many cases, is the classic; here's my Photoshop comp. And I have a red line document JPEG that I will give you, whatever engineer I'm working with, or it's myself, and I'm just giving myself a red line document, but you're just going through and trying to make those things match. And that is sort of not fun for the team because now we're just sort of chiseling each other and sort of, like, going through and critiquing our work over and over versus really kind of in the spirit of prototyping and inventing together. I find that products are diminished when you do that. So, as you try to get into this design system part, it requires a lot more insight into what everyone around us is doing, kind of, as I was saying at the beginning, how to have this cross-discipline view of what we are actually working on. And that view is what we thought, and we still believe in many cases, is absolutely missing. So, you can spin up a design system. And Luro is not the only design system tool. Of course, you can spin up your own. And what I mean by that is, like...I'm maybe going to answer, like, three questions in one. Maybe you haven't even asked them yet. But just to kind of frame this, if you ask anyone what a design system is, it might be a different answer. It might be these are my Figma components that I've created and I've shared out, and there's a public link. You know, an engineer might say, "Well, it's the GitHub repo of components that I'm actually using." So, the design is helpful as documentation. But the design system is the code, or the design system is the actual...or the actual components that are live that users see, which I would argue probably is the most accurate, just because we're talking about user experience impacting whatever business objectives we may have. So, those components need to make their way into live sites or products. So, finding out what that answer is, what's the source of truth? What is our design system? What are our components? What are our standards? You have to have multiple sources for that, just because there's multiple people with multiple opinions and multiple measures of success involved in those. And all of those opinions and measures of success, I would say, are valid. So, accounting for those and kind of crossing the streams, if you will, in one sort of central UI, we believed was crucial enough that we should jump out of the agency days and into a product-building scenario. VICTORIA: That's really interesting. So, you saw this pattern in the delivery of your work as an agency that made you want to build a solution to create better outcomes for a potentially exponential number of clients, right? [chuckles] TRENT: Yeah, hopefully. I think that working on how you work together as a team is vitally important, and if you can find the right environment, then the actual product will benefit. I mean, and I'm not even just thinking about these maybe soft things like, oh yeah, if engineers and designers can work together, the typography will be a little bit better, and the site will feel a little bit more cohesive, and it'll be maybe a little bit easier to digest. I believe that. But I also believe that there are people in organizations doing research, financial analysis, customer analysis, A/B testing, you know, all sorts of work that contributes to the decisions that we make about our sites and products that sort of just gets lost in the shuffle, in the firehose of the day to day. So, having something that takes not only a, I guess, what you could classify as the what for a design system, it could be the design of a component. Maybe it's actually even, too, as well, the code that makes up that component. But then there's this giant why. Why does the button look the way that it does? Why does a card have a border around it? Why? Why? Why? Why? Why? These things maybe they come up during meetings. Maybe there's something that, as a designer or an engineer, I found maybe on the company's shared OneDrive or somebody mentioned in passing. Those things are vitally important, and they need to be, again, back to the morale and perception evolving; they need to be accessible to everyone. But it's a needle-in-a haystack situation. It's funny. We would consult. And one of my favorite stories is we were building this prototype. We were hired to build a prototype for a startup in Austin. They were on a big, open floor-plan office with the glass meeting rooms. And we were showing off our prototype, and we just felt really clever and witty about the way we were going to solve this and the pages that we were going to build. And who is a friend now, a person named Angela walks by, and she's like, "What are you working on?" And we told her what it was. And she says, "Oh, wow, you know, six months before you started contracting with the startup, we did this all, and we've user-tested it. Everybody's been reorged, and nobody remembers. But I have this PowerPoint I can send you, and it will show you the results. Some of these things you're doing are probably going to be great. The other things you should absolutely not be repeating these mistakes." And I thought about how likely it was that she walked by and happened to see that through the window and happened to look on the sharp television on the wall. And it's probably not very likely, and as we become, you know, we're remote and working remote the likelihood of those things happening maybe goes down. The idea of building a product that increases the likelihood or almost makes it seamless that you can find information relevant to what you were working on, even if you're new to that project or you haven't worked on it for a long time, is very, very key. So, within Luro, you can build a design system. You can add your styles. You can add your components, configure your tokens, and do all that, but you can also integrate those things that I was mentioning: prototyping, research, and testing. We also do an accessibility and performance through Lighthouse and give you metrics there. All of those things are associated to the pages that your site is comprised of. They're associated to the components that you use to build everything. So, we're sort of crossing the streams here. So, if you're going into imagine a button component and you're like, okay, the border-radius is four pixels. The type size is 16 pixels, and here's how you code it. We're putting in an actual button. The class is dot btn. That's all great. It's helping us build the button. But if you are asked by leadership or anyone, "Why did you decide this?" Or "What is the impact of design?" Or "What is the impact of the product team on our bottom line? How are you moving the needle? How are you helping us as an organization achieve?" The answer isn't, "Well, we made the border four pixels just like the design [chuckles] said." That's great. Good job. But I think having all of this information associated with design and associated with engineering not only makes us more informed as contributors to teams but it helps us to articulate the value of what we do on the daily in a much more broad organizational sense. So, you can say, "Well, we user-tested this, and we realized that if we took out these form elements from a signup flow, we get more signups by having fewer steps. And so we removed a step. We user-tested it before and after, and signups went up 30%." That's a much cooler answer than, "Well, our design system helps us be consistent," even though we know that that is vitally important, and it makes our app or our site feel much more cohesive, and it contributes to that sign up metric or a sales metric just as much. But having this data and associating it with a component so it's not something that you have to sort of...I guess it almost sounds subjective if you bring it up and say, "Well, we're moving faster, and we're selling more stuff." That's not great. But if you can link and say, "Well, here's a PowerPoint before," or "Here's a summary of a user test before and after. Here's real numbers," it helps you to portray yourself as the designer or engineer or product team member who thinks very deeply about these things, and it helps you to accurately portray yourself in that way. So, I went on a real tangent, but actually just there, I think I just was describing sort of the nuts and bolts of why we built Luro to not only be a design system tool but, like, what we kind of also call a product development tool, a product development system. So, it's extending the idea of design systems to the practice of building a product with an entire organization. WILL: That's really, really cool, and you did a great job explaining it. I'm excited to see it and see where it's going. I felt like a lot of what you were saying was the why you're doing stuff, why you chose, you know, X, Y, Z. Is that where the analytics and the tracking portion of Luro comes into play? TRENT: Yeah. I think that one thing we heard a lot from agencies or even just teams within an organization that are working on design systems is back to that articulating the value of maybe a design system or articulating the value of the work that we do as designers or product builders and similar to we've done a user test and these are the results, and sales or signups, or whatever the case may be, have improved. I think one of the key metrics for a design system is, is the component adopted? There are other ones, and people will mention those, things like, is it helping a team be quicker? So, if there's a design system team, and then there's multiple product teams within an organization, and they all want to work together, and they want to be able to take the components that they need and build their ideas quicker, prototype quicker, that's a great metric as well. But one that we find vitally important is, are the components live to users? And so, being able to track that has a lot of value. One, obviously, is that communicating that to the greater organization, saying, "You know, we've spun up a design system team. The card component is on 49% of pages. The button is on 100% of pages." And then if you're trying to be more tactical about how to improve the product or even just track down, you know, which components or which pages or which experiences aren't, I guess, consistent with the design system, you can say, well, "There's 49%, and there's 51% of pages that may or may not have the card component." And so, you can go find outdated components if you're trying to phase new ones in, and all of those sorts of things as well. So, the metrics are sort of great from a thematic sense, saying, this is the value that our design system is, you know, affording us as a business and the users are experiencing while they're using our app or our site. But then, also, you can drill down into these metrics and see, okay, the button is appearing here. I can click into pages and see views where it's being used on the page level and see, is it being used properly? Those kinds of things. You can track legacy components as well, so, for example, if we've rebranded the site that we all work on together and our old button was, like, dot button and the new button is dot BTN or however we would want to class those things. And you can use classes. You can use data attributes, all those kinds of things. But I would say we can track legacy along that. So, if your goal is to completely adopt the new design system across the entire network and products within six months or whatever the case may be, you know, month over month, week over week, you can check our, you know, line graphs and see, hopefully, the legacy occurrences of that going down over time. So, if, like, the button is being used less and less and then the dot BTN is being used more and more, you can see those sort of swap places. And so, what we have found is talking about things in sort of an objective or fuzzy way, saying, well, we're trying to ship this, and we're doing these inventories, and we're going through all the pages. And we're clicking around trying to find old things, or we're redesigning pages. But it's very, very difficult. This is just an instant quantification of where our components are manifesting in the product. So, what we do is, with Luro, you can give us...whether it's behind an authentication layer or not, we crawl web pages, first and foremost. So, you can give us a site. And this is all optional. You can spin out a design system without this. But we crawl the site, and then we will go ahead and do performance and accessibility scores for there. So, that's one way to itemize work, where you can just say, well, as an agency, we're going to work with this company, and we want to show them, like, the starting point and expose weak points on where we might be paying a lot of attention to. In the design or engineering phase, we need to improve the speed here. We have accessibility violations we need to think about, all that kind of stuff. And then, once you crawl those, you can add your design system, and then you can cross-reference those, and I kind of mentioned that. You can use CSS classes to do that. And so, you'd enter in dot BTN for button. We've already crawled your pages. And so, we can tell you every time that that class appears inside of any page inside of the network. So, it's this very, like, two-minute way to get a wealth of information that's shared and communicated with...the entire organization will benefit. Like I said, like, leadership they can get a sense of how the design system is being used and adopted, but also, the active teams working on things so that they can go find outliers and work on replacing those. VICTORIA: It's been over a year in your journey with Luro. What challenges do you see on the horizon? TRENT: I still think it is an adoption challenge. I think that, you know, one thing that we found is that a lot of teams, and this is going back to our agency days, but I sort of sort of still see this happening now is that building the design system, you know, let me separate these two things. I think designing components and building the design system in the sense of picking styles, and choosing fonts, and iterating upon something like a search box or, a footer, or a modal that's a lot of work. That's just design and product design and product development in general. But the act of, you know, creating the design system, maybe it's the documentation site, or however, we're communicating these standards across the organization. That part, to me, it's always kind of taken too much time and effort. And to be really candid, the amount of budget that's being allocated for those tasks is less. So, we're having a lot of users who are saying, "Well, I wasn't in charge of a design system. We had a team for that. We don't anymore. And now I'm responsible for it," or "The team's been combined, and I'm working on, like, three things at once." And so, something that's very, very crucial to us at Luro is to help with the struggle of spinning up a design system. For us, I fully believe that there are design systems that can be fully custom available to the public and need to have, you know, every page and view needs to be unique unto itself. But for Luro, the starting place that we get you with, you know, you can link in your Storybook. You can link in Figma components. You can add components manually and all those sorts of things. Where we can get you in a few minutes is really close. And then, if you started to fold in, you know, the idea of performance, accessibility, and then all of the other insights that you can then integrate, so if you're doing A/B testing or user testing and doing research, and you want to make sure that that's all involved inside of your design system, then it becomes a really attractive option. So, I think that decreasing the time it takes to get started and to spin up a design system is the number one thing we see people struggling with and the number one thing we want to bring. I kind of like to compare it to services like Netlify. Like, I remember I used to have to set up servers to demo things for clients, and it would take an hour, and I don't know what I'm doing. And I would break stuff, and they would have to help me fix it. So, then I'm bothering him. And then, now I'm just, you know, will either link to a CodePen or drag and drop a deployed URL from something like Netlify. And it's this amazing, almost like it feels like deploying is just as difficult as, like, sketching something out on a napkin. We want spinning up a design system to kind of feel that way so it's not so precious. You're not worried about...it is just easy to get started. And so, we're kind of integrating all these other tools that you use to make that easier and quicker because if you do have other things that you're working on and you need to move beyond that so that you can focus on prototyping, or designing, and building the actual components, you can do that. And you have that option as opposed to having to be mired in some of these other details. VICTORIA: It seems like change management and integrating change into larger organizations is always the biggest challenge [laughs], even for great innovations. And I'm curious: what types of people or groups have you found are quick to adopt this new method and really the right group for you to center your message on? TRENT: Yeah, it is...I was joking, I think, maybe before the podcast started, but it's, like, very ambitious because it's easy, I think, to say, "This tool is for designers. And if you're a designer, you can integrate your Figma, and then you'll have your components published to your team so that they can use them." And that's absolutely true. Like, if you're a designer, Luro is for you. If you're an engineer and you have just received components, and you need a way to document that and show your coded version alongside the design version and be able to collaborate with people in that sense, it is absolutely for you as well. So, you can see how it's almost like you almost have to frame Luro for individuals across the organization. So, it's one of those deals where...and we've kind of experimented with this with the marketing. And the way we've discussed it, we talked to lots of, you know, leadership, heads of product, CMOs, even CTOs, things like that. And so, it's like, if you're trying to get your entire organization to work better, to ship, you know, more effectively, then Luro is the tool for that as well because we're getting into knowledge retention via uploading. Like, my favorite story there is if you're an A/B tester, probably, and this is what we've experienced, is you run these tests. A lot of time and effort goes into building the prototypes for the test, whether that's you or an engineering team that's doing those things. This is one of the things we used to do as an agency. We would be brought on to prototype something totally new. We would test that alongside the existing experience. And an A/B tester, we'd work with them, and they would create, like, a PowerPoint or something that would explain the pros and cons and what should happen next and summarize the test. And that would live on that person's hard drive, whether it's on their computer or, like, a Dropbox or a OneDrive account. And no one ever thought about it ever again. You would just move on to the next test. But the amount of money spent on us to build the prototype and the amount of money spent on the SaaS to spin up the, like, A/B testing environment and all of these things, and then the time spent on the A/B tester to analyze the results and generate a PowerPoint it's not nothing. And so, one of the things that we find pretty appealing for leadership within Luro is the idea of integrating all of these tools and all this work that you do in mapping them to components so that when you pull up, for example, a button component, you'll see all the user tests that have been added over any period of time. So, if you were a new hire and you're trying to onboard, you can go interview everybody in the organization and ask them about the history of a button or a card component or the history of a sign-up page. But then, also, in a self-service way, you can just click into Luro, click a button, click a card, click to the sign-up page, any of those things, and find all that stuff I was mentioning earlier, whether it's a test, or research, or prototyping, or any kind of documents that have been written. These aren't the arguments that Dave or I might have around the actual border-radius value. Those are small things that probably should be lost in the firehose. But if we have learned an outline button with a stroke is performing way better than a solid-filled button or vice versa, that's important information that doesn't need to disappear in six weeks. So, that's the other kind of metric there is explaining kind of the holistic version, telling the holistic story of Luro to those types. And so, yeah, navigating that and trying to get, like, buy-in on a broad level is kind of what we're working on these days now. WILL: Sweet. So, I actually really like how it's almost like version control. You can see the history of what you've been working on. And I really like that because so many times...you're correct. When I go to Figma or anything, I'm like, why are we doing it this way? Oh, we made these decisions. Maybe in comments, you can kind of do it, but I think maybe that's the only place you can see the version control. So, I like that feature. Like you said, you can see the history of why you did something like that. TRENT: Yeah. And think about that, so if I am a front-end engineer and I receive a design and everyone thinks that, why are we doing it this way? I would hate to code something...I can do it. It's my job. But if I don't understand why, my feeling about work and maybe the quality of my work goes down, you know what I mean? I guess what I'm trying to say is, like, feeling like you understand, and you're lockstep with the entire team, and you understand what the goal is...what are we trying to do? What are we trying to achieve? Like, what have we reviewed that has made us believe this? And if you don't have that information, or if I don't have that information, like, there's some traction within the team, whether it's actual momentum forward and the amount of tickets that are being closed, or just the spirit of what we're doing, that the product is going to be diminished. These are all these little things that add up, up, up, up, up over time. So, being able to show this information to be able to access this information kind of passively. So, for example, if you got VS Code open and Luro open and you can see here's the user test from six weeks ago that shows us why we went with option B, you'll say, "Okay, cool. Even better." You know, you can review those things way before you get things handed to you. You know, it's much more kind of this utopian vision of an open, collaborative deal. And the way I would say that is it's, you know, we all kind of hand things off. So, of course, like, there's some version, even if it's like a micro waterfall that happens on a daily basis. We're all doing that. Like, somebody needs to be done with something to hand it off to something else, so we're not all up in each other's space all the time. But one thing that we like about Luro, whether we use Teams, or Slack, or whatever, it's not a real-time thing where I have to say, "Stop, look what I'm doing [laughs]. Come over here and look because I need you to know this." You can get notifications from Luro, but it's not something that is a context-switching demand type of a situation. So, the idea is if you're like, I'm wondering what's going on. I know this is coming up. I'd like to review. Or I could let you know and tell you, and just on your own time, you can go see this. So, separate from, like, the firehose of tickets and chats, you can see the actual product evolving and some of these, like, key milestone decisions on your own time and review them. And if they've happened before you even started on the project, then you can do that as well. WILL: I think that's probably where the breakdown between developers and designers that collab that's where it probably breaks down, whenever you're trying to get your tickets out as a developer. And then there's a change while you're working on it, and it's a complicated change, but you're still responsible for trying to get that ticket out in time. So, I think, like, what you're saying, you can get it beforehand. So, it sounds like, to me, Luro would be a huge help because you have to have developers and designers working together; if you don't, you're just in trouble in general. But anything that can help the relationship between the two I think, is amazing, and that's what I'm hearing whenever you're talking about Luro. It helps. It benefits that relationship. TRENT: Yeah, that even makes me think a little bit about the ongoing collaboration aspect. So, it's like, if something is shipped...or maybe let's go the agency scenario here. You've launched a site. You've launched a product. How do we know how it's performing? Of course, you'll have everybody...they're going to have analytics, and we'll be talking about that. And are signups up or down? But Luro will run tests. It'll continue to run component analytics. So, you can sense whether, like, somebody is changing a component. Or, you know, is the fully adopted design system not being utilized or being utilized less or more over time? But then, also, we're running, again, performance and accessibility metrics. So, we've seen it where we've shipped a product for a client. You know, we've had Luro running. We've sort of used that as our hub to collaborate over time. And then we'll notice that there's a giant performance spike and that, like, the page speed has gone way down. And we itemize issues and can point you to exactly the page that it's happening on and give you some insight into that. Of course, you could go through after you've worked with the client and run Lighthouse on every single page in your own time for fun, but that's not reality or fun. So, you'll get this information. And so, you almost...before we were telling people who were using Luro, we were kind of using it ourselves just to help ourselves do a better job. About a month into a project, we were able to email a customer, a former client, and say, "Hey, site's looking great. Amazing to see this. There's a 3-megabyte, 50-pixel avatar. Someone uploaded a giant image. It displays as 50 pixels. But somebody must have uploaded the full one to your homepage, and your page speed score tanked." They're like, "Oh, wow, they must [laughs] be monitoring us and checking in on us every day." We love them dearly, but we were not doing that. We were using Luro off to the side. So, there is this other aspect of just sort of monitoring and making sure things stay, you know, as they were or better once we ship things and move forward to the next. VICTORIA: That's really interesting. And I'm excited to explore more on my own about Luro. As we're coming towards the end of our time today, I wanted to give you one last chance to shout out anything else that you would like to promote today. TRENT: Oh, that's it [laughs], luroapp.com, you know, that's the main thing. Check out component analytics. We have a YouTube channel, and I would say that's probably the easiest, a lot of effort, even though the videos maybe I'd give myself an A-minus or a solid A, not an A-plus on video production. I'm trying to get better. But explaining just, like, how to set things up. There's, like, a one-minute, like, what is all this? So, if you want to see all the things that I've been trying to describe, hopefully well on the podcast [chuckles], you can see that really well. So, I'd say Luro App and then the YouTube channel. We've got, like, five, six videos or so that really kind of help get you into maybe what your use case would be and to show you how easily things are set up. VICTORIA: Great. Thank you so much for joining us today, Trent, and for sharing about your story and about the product that you've been building. TRENT: Yeah. Thank you for having me. This has been great fun. VICTORIA: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. WILL: And you can find me on Twitter @will23larry. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Underbelly
S2 E02: A Little Bit Off Base

Underbelly

Play Episode Listen Later Mar 20, 2024 45:30


When an FBI agent walks into Dave Rupert's truck stop, his mind starts racing. There's so many things law enforcement might want to address. A few friends he made though a dalliance is the last thing on his mind. Dave Rupert's unusual background in upstate New York led from a family doing what they had to do to survive to becoming a trucking entrepreneur. But a night out at a bar in Florida will eventually change Dave's life.  Additional Music by Guinness the Duo.  Learn more about your ad choices. Visit megaphone.fm/adchoices

Bad at CSS
Styling better custom inputs with Dave Rupert

Bad at CSS

Play Episode Listen Later Mar 15, 2024 62:56


Dave Rupert knows his inputs and we got a lot to learn. Dave's great blog - https://daverupert.com/ Dave on Twitter - https://twitter.com/davatron5000

Underbelly
Underbelly: The Rebel Kind Trailer - Out March 13

Underbelly

Play Episode Listen Later Feb 29, 2024 3:44


The Rebel Kind is the unreal, real-life story of Dave Rupert—a six-foot-seven Chicago trucker who infiltrated the heart of a dangerous faction of the Irish Republican Army. From Entropy Media, the second season of the Underbelly series focuses on the unlikely man with entrepreneurial dreams and a willingness to do whatever it takes to get the job done. Veteran journalists Bob Herguth and Abdon Pallasch tell the story through tape recordings they made of Rupert in secret locations 20 years ago. Premieres everywhere podcasts are found Wednesday, March 13. Learn more about your ad choices. Visit megaphone.fm/adchoices

ShopTalk » Podcast Feed
602: What Does Accessibility Really Mean?

ShopTalk » Podcast Feed

Play Episode Listen Later Feb 12, 2024 65:38


Show DescriptionVoiceover pays us a visit, we talk about what accessibility really means, the difficulty of closing a dialogue element, web components at work, and jQuery 4 is out. Listen on Website →Links Opportunities for AI in Accessibility – A List Apart the-pastry-box-project.net An Alphabet of Accessibility Issues by Anne Gibson Alphabet of Accessibility Deck Understanding accessibility through ABCs – On the Issues Frontend Masters Boost – Helping Your Journey to Senior Developer storage-form Web Component - David Darnes CodeMirror FitVids.JS - A lightweight, easy-to-use jQuery plugin for fluid width video embeds. HTML with Superpowers | HTML with Superpowers Learn from Dave Rupert's courses | Frontend Masters jQuery SponsorsMiroFind simplicity in your most complex projects with Miro. Your first three Miro boards are free when you sign up today at Miro.com.

ShopTalk » Podcast Feed
599: Fighting the Algorithm With RSS, Blogging, and the IndieWeb

ShopTalk » Podcast Feed

Play Episode Listen Later Jan 22, 2024


Show DescriptionDave and Chris discuss indie web culture, the role of social media in today's society, and the challenges and strategies of freelancing. Additionally, they discuss a range of topics from content moderation, coding and refining tech skills, to emerging startups and the future of web technology. Listen on Website →Links Cracking The Cryptic How Adam Savage COMPLETELY Overhauled His Workshop Where have all the websites gone? I miss RSS kottke.org - home of fine hypertext products Daring Fireball Chris Coyier – Web craftsman, blogger, author, speaker. The Homepage of Dave Rupert | daverupert.com Naz Hamid Substack Is Not Infrastructure – Pixel Envy Why Platformer is leaving Substack Duolingo - The world's best way to learn a language Shutting down Artifact. We've made the decision to wind down… | by Artifact Team | Artifact News | Jan, 2024 | Medium Daring Fireball: Artifact Is Shutting Down After One Year The Quiet Death of Ello's Big Dreams - Waxy.org IndieWeb - IndieWeb Webmention - IndieWeb Quick thoughts on chips | daverupert.com Quicker Thoughts on Chips - Snook.ca Email is good. – A site about email productivity. Lemon Productions - Podcast Editing and Production by Chris Enns Brad Frost | Design system consultant, author of Atomic Design, web designer, and musician Courses by Kent C. Dodds SponsorsJam.devYou've probably heard of Jam.dev, it's used by more than 60,000 people. It's a free tool that saves developers a ton of frustration. It forces your teammates to make the perfect bug report. They can't do it wrong because it automatically includes a video of the bug, console logs, network requests, everything you need to debug. It automatically lists out the steps to reproduce. It's so easy to get your teammates to use. It's just a Chrome extension. When they see a bug, they click a button and right away it creates a ticket. So it saves time for them.

Igalia
Igalia Chats: Web Ecosystem Health Part IX: economics

Igalia

Play Episode Listen Later Feb 16, 2023 58:19


Igalia chats/Shop Talk crossover - Brian Kardell and Eric Meyer chat with Chris Coyier and Dave Rupert from the Shop Talk Show about the economics of browsers and engines

PodRocket - A web development podcast from LogRocket
Web Component Tricks with Dave Rupert

PodRocket - A web development podcast from LogRocket

Play Episode Listen Later Aug 10, 2022 23:27


Web components help you break your code into smaller chunks, build design systems, and also ship less code. Dave Rupert, the co-founder of Luro, lead developer at Paravel, and co-host of ShopTalk, joins us to talk about his course on web components and the other projects he is working on. Links https://shoptalkshow.com https://luroapp.com https://paravelinc.com https://frontendmasters.com/courses/web-components Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket combines frontend monitoring, product analytics, and session replay to help software teams deliver the ideal product experience. Try LogRocket for free today. (https://logrocket.com/signup/?pdr) Special Guest: Dave Rupert.

Kodsnack
Kodsnack 484 - Underneath your library, with Chris Ferdinandi

Kodsnack

Play Episode Listen Later Aug 2, 2022 52:41


Fredrik chats with Chris Ferdinandi about vanilla Javascript, the pros and cons of libraries, the state of web components, and a lot more. Chris tells us about how and why he became the vanilla Javascript guy, and why he dislikes vanilla-js.com. We talk about why we as web developers pick up so many libraries, and why we often seem to use really large tools on really small problems. We wonder if different types of developers should think in different ways about libraries. Chris also talks about how different groups attending his courses approach the subject of vanilla Javascript in different ways, and of course a bit about where he hopes and thinks web development might be heading in the next few years. Thank you Cloudnet for sponsoring our VPS! Comments, questions or tips? We are @kodsnack, @tobiashieta, @oferlundand @bjoreman on Twitter, have a page on Facebook and can be emailed at info@kodsnack.se if you want to write longer. We read everything we receive. If you enjoy Kodsnack we would love a review in iTunes! You can also support the podcast by buying us a coffee (or two!) through Ko-fi. Links Chris Ferdinandi Vanilla Javascript Vanilla JS podcast - Chris' podcast Chris' newsletter gomakethings.com Jquery vanilla-js.com - a joke which may not have stood the test of time Library or framework? ES 5 Post from Dave Rupert about ripping Jquery out of Wordpress Chris' e-books vanillajsguides.com Chris' workshops DOM diffing Dan Abramov Redux Dan Abramov's course on Redux Vue Svelte Astro The stage 3 API for passing in a string of HTML and sanitizing it JSX Details and summary elements ARIA Web components Chris' course on web components Shadow DOM Constructable stylesheets Titles I help people learn vanilla Javascript Largely because of Jquery The vanilla JS guy The phrase “at scale” gets thrown in there Trying to hang a painting on your wall with a sledgehammer Perfect for a very narrow and specific set of use cases Just throwing one more of them in The pain of their own tech choices Teaching engineers how to find their next job I didn't realize you could do so much without a library Underneath your libary Without punishing the user Mostly HTML and a little bit of Javascript Waiting for the build to compile You never have to feel bored

Kodsnack in English
Kodsnack 484 - Underneath your library, with Chris Ferdinandi

Kodsnack in English

Play Episode Listen Later Aug 2, 2022 52:41


Fredrik chats with Chris Ferdinandi about vanilla Javascript, the pros and cons of libraries, the state of web components, and a lot more. Chris tells us about how and why he became the vanilla Javascript guy, and why he dislikes vanilla-js.com. We talk about why we as web developers pick up so many libraries, and why we often seem to use really large tools on really small problems. We wonder if different types of developers should think in different ways about libraries. Chris also talks about how different groups attending his courses approach the subject of vanilla Javascript in different ways, and of course a bit about where he hopes and thinks web development might be heading in the next few years. Thank you Cloudnet for sponsoring our VPS! Comments, questions or tips? We are @kodsnack, @tobiashieta, @oferlund and @bjoreman on Twitter, have a page on Facebook and can be emailed at info@kodsnack.se if you want to write longer. We read everything we receive. If you enjoy Kodsnack we would love a review in iTunes! You can also support the podcast by buying us a coffee (or two!) through Ko-fi. Links Chris Ferdinandi Vanilla Javascript Vanilla JS podcast - Chris' podcast Chris' newsletter gomakethings.com Jquery vanilla-js.com - a joke which may not have stood the test of time Library or framework? ES 5 Post from Dave Rupert about ripping Jquery out of Wordpress Chris' e-books vanillajsguides.com Chris' workshops DOM diffing Dan Abramov Redux Dan Abramov’s course on Redux Vue Svelte Astro The stage 3 API for passing in a string of HTML and sanitizing it JSX Details and summary elements ARIA Web components Chris' course on web components Shadow DOM Constructable stylesheets Titles I help people learn vanilla Javascript Largely because of Jquery The vanilla JS guy The phrase “at scale” gets thrown in there Trying to hang a painting on your wall with a sledgehammer Perfect for a very narrow and specific set of use cases Just throwing one more of them in The pain of their own tech choices Teaching engineers how to find their next job I didn’t realize you could do so much without a library Underneath your library Without punishing the user Mostly HTML and a little bit of Javascript Waiting for the build to compile You never have to feel bored

JS Party
Frontend Feud: ShopTalk vs CSS Podcast

JS Party

Play Episode Listen Later Jul 22, 2022 58:01 Transcription Available


What's this? A Frontend Feud! The ShopTalk guys return to defend their championship over Syntax against new contenders: Una and Adam from The CSS Podcast!

Changelog Master Feed
Frontend Feud: ShopTalk vs CSS Podcast (JS Party #235)

Changelog Master Feed

Play Episode Listen Later Jul 22, 2022 58:01 Transcription Available


What's this? A Frontend Feud! The ShopTalk guys return to defend their championship over Syntax against new contenders: Una and Adam from The CSS Podcast!

Front End Nerdery Podcast
22 - Chris Coyier & Dave Rupert

Front End Nerdery Podcast

Play Episode Listen Later Feb 14, 2022 62:50


In this episode, I talk to Chris Coyier and Dave Rupert from the Shop Talk Show! We talk about all sorts of topics having to do with front end development, design, and accessibility. Specifically, web components, CodePen, Eleventy, Astro, and much, much more! Intro/Outro music graciously given permission to use called, "Settle In" by Homer Gaines. Sound editing by Chris Enns of Lemon Productions. Transcripts can be found at: https://toddl.dev/podcast/transcripts/shoptalkshow/ Show Notes https://twitter.com/chriscoyier - Chris on Twitter https://twitter.com/davatron5000 - Dave on Twitter https://chriscoyier.net/ - Chris's Homepage https://daverupert.com/ - Dave's Homepage https://codepen.io/ - CodePen https://paravelinc.com/ - Paravel https://css-tricks.com/ - CSS-Tricks https://shoptalkshow.com/ - Shop Talk Show https://www.youtube.com/realcsstricks - Real CSS Tricks YouTube https://larahogan.me/donuts/ - Lara Hogan Donut Manifesto https://www.deque.com/axe/ - axe (Deque) https://tenon.io/ - Tenon https://webaim.org/ - WebAIM https://wave.webaim.org/extension/ - WAVE browser extension https://developers.google.com/web/tools/lighthouse/ - Google Lighthouse https://www.w3.org/TR/WCAG21/ - WCAG (Web Content Accessibility Guidelines) https://twitter.com/goodwitch - Glenda Sims (@goodwitch) https://astro.build/ - Astro https://slinkity.dev/ - Slinkity https://www.netflix.com/title/81228573 - Komi Can't Communicate --- Support this podcast: https://podcasters.spotify.com/pod/show/frontendnerdery/support

The Bike Shed
322: Toxic Traits

The Bike Shed

Play Episode Listen Later Jan 18, 2022 35:21


Happy New Year (for real)! Chris and Steph both took some end-of-year time off to rest and recharge. Steph talks about some books she enjoyed, recipes she tried, and trail-walking adventures with her dog, Utah. Chris' company is now in a good position to actually start hiring within the engineering team. He's excited about that and will probably delve into more around the hiring process in the coming weeks. Since they aren't really big on New Year's Eve resolutions, Steph and Chris answer a listener question regarding toxic traits inspired by the listener question related to large pull requests and reflect on their own. The Midnight Library by Matt Haig (http://www.matthaig.com/books/midnight-library/) Tim Urban on Twitter (https://twitter.com/waitbutwhy/status/1367871165319049221) How to Stop Time by Matt Haig (http://www.matthaig.com/how-to-stop-time/) Do the Next Right Thing (https://daverupert.com/2020/09/do-the-next-right-thing/) Debugging Why Your Specs Have Slowed Down (https://thoughtbot.com/blog/debugging-why-your-specs-have-slowed-down) test-prof (https://github.com/test-prof/test-prof) Tests Oddly Slow Might Be Bcrypt (https://collectiveidea.com/blog/archives/2012/11/12/tests-oddly-slow-might-be-bcrypt) Transcript: 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 Steph Viccari. CHRIS: And I'm Chris Toomey. STEPH: And together, we're here to share a bit of what we've learned along the way. So, hey, Chris, what's new in your world? CHRIS: What's new in my world? Well, spoiler, we actually may have lied in a previous episode when we said, "Hey, happy New Year," because, for us, it was not actually the new year. But this, in fact, is the first episode of the new year that we're recording, that you're hearing. Anyway, this is enough breaking the fourth wall. Sorry, listener. STEPH: [laughs] CHRIS: Inside baseball, yadda, yadda. I'm doing great. First week back. I took some amount of vacation over the holidays, which was great, recharging, all those sorts of things. But now we're hitting the ground running. And I'm actually really enjoying just getting back into the flow of things and, frankly, trying to ramp everything up, which we can probably talk about more in a moment. But how about you? How's your new year kicking off? STEPH: I like how much we plan the episodes around when it's going to release, and we're very thoughtful about this is going to be released for the new year or around Christmas time, and happy holidays to everybody. And then we get back, and we're like, yeah, yeah, yeah, we can totally drop the facade. [laughs] We're finally back from vacation. And this is us, and this is real. CHRIS: Date math is so hard. It just drains me entirely to even try and figure out when episodes are going to actually land. And then when we get here, also, you know, I want to talk about the fact that there was vacation and things, and the realities of the work, and the ebb and flow of life. So here we are. STEPH: Same. Yeah, I love it. Because I'm in a similar spot where I took two weeks off, which was phenomenal. That's actually sticking to one of the things we talked about, for one of the things I'm looking to do is where I take just more time off. And so having the two weeks was wonderful. It was also really helpful because the client team that I'm working with also shut down around the end of the year. So they took ten days off as well. So I was like, well, that's a really good sign of encouragement that I should also just shut down since I can. So it's been delightful. And I have very little tech stuff to share because I've just been doing lots of other fun things and reading fiction, and catching up with friends and family, and trying out new recipes. That's been pretty much my last two weeks. Oh, and walks with Utah. His training is going so well where we're starting to walk off-leash on trails. And that's been awesome. CHRIS: Wow, that's a big upgrade right there. STEPH: Yeah, we're still working on that moving perimeter so he knows how far he can go. Before then, he needs to stop and check on me. But he's getting pretty good where he'll bolt ahead, but then he'll stop, and he'll look at me, and then he'll wait till I catch up. And then he'll bolt ahead again. It's really fun. CHRIS: I like that that's the version of it that we're going for. This is not like you're going to walk alongside me on the trail; it's you're obviously going to run some distance out. As long as you check back in once every 20 feet, we're good; that's fine. Any particularly good books, or recipes, or talks with friends to go with that category? But that one's probably a little more specific to you. STEPH: [laughs] Yes. There are two really good books that I read over the holidays. They're both by the same author. So I get a lot of books from my mom. She'll often pick up a book, and once she's done with it, she'll drop it off to me or vice versa. So the one that she shared with me is called The Midnight Library. It's written by Matt Haig, H-A-I-G. And it's a very interesting story. It's a bit sad where it's about a woman who decides that she no longer wants to live. And then, when she moves in that direction to go ahead and end her life, she ends up in this library. And in the library, every time she has made a different decision or made a decision in life, then there is a new book written about what that life is like. So then she has an opportunity to go explore all of these lives and see if there's a better life out there for her. It is really interesting. I highly recommend it. CHRIS: Wow. I mean, that started with, I'm going to be honest, a very heavy premise. But then the idea that's super interesting. I would, actually...I think I might read that. I tend to just read sci-fi. This is broadly in the space, but that is super interesting. There's an image that comes to mind actually as you described that. It's from Tim Urban, who's also known as Wait But Why. I think he posts under that both on Twitter, and then I think he has a blog or something to that effect. But the image is basically like, all of the timelines that you could have followed in your life. And everybody thinks about like, from this moment today. Man, I think about all of the different versions of me that could exist today. But we don't think about the same thing moving forward in time. Like, what are all the possibilities in front of me? And what you're describing of this person walking around in a library and each book represents a different fork in the road from moving forward is such an interesting idea. And I think a positive reframing of any form of regret or looking back and being like, what if I had gone the other way? It's like, yeah, but forward in time, though. I'm very intrigued by this book. STEPH: Yeah, it's really good. It definitely has a strong It's a Wonderful Life vibe. Have you ever watched that movie? CHRIS: Yes, I have. STEPH: So there's a lot of that idea of regret. And what if I had lived differently and then getting to explore? But in it's A Wonderful Life, he just explores the one version. And in the book, she's exploring many versions. So it's really neat to be like, well, what if I'd pursued this when I was younger, had done this differently? Or what if I got coffee instead of tea? There are even small, little choices that then might impact you being a different person at a point in time. The other book that I read is by the same author because I enjoyed Midnight Library so much that I happened to see one of his other books. So I picked it up. And it's called How to Stop Time. And it's about an individual who essentially lives a very long time. And there are several people in the world that are like this, but he lives for centuries. But he doesn't age, or he ages incredibly slowly, at a rate that where say that he's 100 years old, but he'll still look 16 years old. And it's very good. It's very interesting. It's a bit more sad and melancholy than I typically like to read. So that one's good. But I will add that even though I described the first one, it has a sad premise; I found The Midnight Library a little more interesting and uplifting versus the other one I found a bit more sad. CHRIS: All right. Excellent additional notes in the reading list here. So you can opt like, do you want a little bit more somber, or do you want to go a little more uplifting? Yeah, It's a Wonderful Life path being like, starts in a complicated place but don't worry, we'll get you there in the end. STEPH: But I've learned I have to be careful with the books that I pick up because I will absorb the emotions that are going on in that book. And it will legit affect me through the week or as I'm reading that book. So I have to be careful of the books that I'm reading. [laughs] Is that weird? Do you have the same thing happen for when you're reading books? CHRIS: It's interesting. I don't think of it with books as much. But I do think of it with TV shows. And so my wife and I have been very intentional when we've watched certain television shows to be like, we're going to need something to cut the intensity of this show. And the most pointed example we had was we were watching Breaking Bad, which is one of the greatest television shows of all time but also just incredibly heavy and dark at times, kind of throughout. And so we would watch an episode of Breaking Bad. And then, as a palate cleanser, we would watch an episode of Malcolm in the Middle. And so we saw the same actor but in very different facets of his performance arc and just really softened things and allowed us to, frankly, go to bed after that be able to sleep and whatnot but less so with reading. So I find it interesting that I have that distinction there. STEPH: Yeah, that is interesting. Although I definitely feel that with movies and shows as well. Or if I watch something heavy, I'm like, great, what's on Disney? [laughs] I need to wash away some of that so I can watch something happy and go to sleep. You also asked about recipes because I mentioned that's something I've been doing as well. There's a lot of plant-based books that I've picked up because that's really my favorite type of thing to make. So that's been a lot of fun. So yeah, a lot of cooking, a lot of reading. How about you? What else is going on in your world? CHRIS: Well, actually, it's a super exciting time for Sagewell Financial, the company that I've joined. We are closing our seed financing round, which the whole world of venture capital is a novel thing that I'm still not super involved in that part of the process. But it has been really interesting to watch it progress, and evolve, and take shape. But at this point, we are closing our seed round. Things have gone really well. And so we're in a position to actually start hiring, which is a whole thing to do, in particular, within the engineering group. We're hiring, I think, throughout the company, but my focus now will be bringing a few folks into the engineering team. And yeah, just trying to do that and do that well, do that intentionally, especially for the size of the team that we have now, the sort of work that we're doing, et cetera, et cetera. But if anyone out there is listening, we are looking for great folks to join the team. We are Ruby on Rails, Inertia, TypeScript. If you've listened to the show anytime recently, you've heard me talk about the tech stack plenty. But I think we're trying to do something very meaningful and help seniors manage finance, which is a complicated and, frankly, very underserved space. So it's work that I deeply believe in, and I think we're doing a good job at it. And I hope to do even a better job over time. So if that's at all interesting, definitely reach out to me. But probably in the coming weeks, you'll hear me talk more and more about hiring and technical interviews and all of those sorts of things. I got to ramp myself back up on that entire world, which is really one of those things that you should always be doing is the thought that I have in my head. Now that I'm in a position to be hiring, I wish I'd been half-hiring for the past three months, but I'll figure it out. It'll be fine. STEPH: That's such a big undertaking. Everything you're saying resonates, but also, it's like that's a lot of hard work. So if you're not in that state of really being ramped up for hiring, I understand why that would be on the backburner. And yeah, I'm excited to hear more. I've gotten to hear some more of the product details about Sagewell, but I don't think we've really talked about those features here on the show. So I would love it if we brought some more of the feature work and talked about specifically what the application does. I am intrigued speaking of how much energy goes into hiring. Where are you at in terms of how much...like, are there any particular job boards that you're going for? Or what's your current approach to hiring? CHRIS: Oh, that's a great question. I have tweeted once into the world. I have a draft of a LinkedIn post. This is very much I'm figuring out as I go. It's sort of the nature of a startup as we have so many different things to do. And frankly, even finding the time to start thinking about hiring means I'm taking time away from building features and growing out other aspects. So it's definitely a necessary thing that we're doing at this point in time. But basically, everything we're doing is just in time compiling and figuring out what are the things that are semi-urgent right now? And to be honest, I like that energy overall. I've always had in the back of my mind that I like this sort of work and this space, especially if you can do it intentionally. It shouldn't feel like everything's on fire all the time, but it should feel like a lot of constraints that force you to make decisions quickly, which, if we're being honest, I think that's something that is not my strongest suit. So it's something that I'm excited to grow that muscle as part of this work. But so, with that in mind, at this point, my goal is to just start getting the word out there into the world that we are looking to hire and get people interested and then, from there, build out what's the interview process going to look like? I will let you know when we get there; I will. I will figure that out. But it's not something that I've...I haven't actually very intentionally thought about all of this. Because if I were to do that, it would delay the amount of time until I actually say into the world, "Hey, we're hiring." So I very purposely was like, I just need to say this into the world and then continue doing the next steps in that process. I'm prone to the perfect is the enemy of the good just trying to like, I want to have a complete plan and a 27-step checklist, and a Gantt chart, and a burndown. And before I take any first action and really trying to push back, I'm going to be like, no, no, just do something, just take a step in the right direction. There's actually a blog post that comes to mind, which is by Dave Rupert, who is a former guest on this podcast. It was wonderful getting to interview him. But he wrote a blog post. The title of it is Do the Next Right, which is a line from a song in the movie Frozen 2, I believe. He is like, all right, stick with me here. And I know this is a movie for kids, maybe. But also, this is a very meaningful song. And he framed it in a way that actually was surprisingly impactful to me. And it's that idea that I'm holding on to of you can't do it all, and you can't do it perfectly. Just do the next right thing. That's what you're going to do. So we'll link to that blog post in the show notes. But that's kind of where I'm at. STEPH: I love that. I'm looking forward to reading that because that has been huge for me. I used to be held back by that idea of perfection. But then I realized other people were getting more work done more quickly. And so I was like, huh, maybe there's something to this just doing the next thing versus waiting for perfection that is really the right path. So, how do folks reach out to you? Should they reach out to you on Twitter or email? What's best for you? CHRIS: Oh yeah, Twitter. This is all probably going to be said at the end of the show as well. But Twitter @christoomey. ctoomey.com is my blog. I'm on GitHub. I make it very easy to contact me because I haven't regretted that up to this point in my life. So basically, anywhere you find me on the internet, you will be able to email me or DM me or any of the things. I'm going to see how long I can hold on to that. I want to hold on to that forever. I want just a very open-door policy. So that's where I'm at right now, but any of those starting points. And bikeshed.fm website will somehow link to me in any of the various forums, and they're all kind of linked to each other, so any of those are fine. I will happily take inquiries via any of the channels. STEPH: Cool. Well, I'm excited to hear about how it goes. CHRIS: Me too, frankly. But in a very small bit of little tech news or tech happenings from my holiday time, this was actually just before I started to go on break for the holidays. I had noticed that the test suite was getting very slow, like very, very slow but on my machine. It was getting a little bit slow on CI, but the normal amount where we just keep adding new things. And we're adding a lot of feature specs because we want to have that holistic coverage over the whole application, and we can, so for now, we're doing that. But our spec suite had gotten up to six-ish minutes on CI and had a couple of other things. We have some linting and some TypeScript and things like that. But on my machine, it was very slow. So I hadn't run the full spec suite in a long time. But I knew that running any individual spec took surprising amounts of time. And in the back of my head, I was like; I guess I hadn't configured Spring. That seems weird. I probably would have done that, but whatever. And I'd never pushed on it more until one day I ran the specs. I ran one model spec, and it took 30 seconds or something like that. And I was like, well, that's absurd. And so I started to look into it. I did some scanning around the internet. There was a wonderful post on the Giant Robots blog about how to look through things from Mike Wenger, a wonderful former thoughtboter. Unfortunately, none of the tips in there were anything meaningful for me. Everything was as I expected it to be. So I set it down. And there were a couple of times that this happened to me where I'd be like, this is frustrating. I need to look into this a little bit more, but it was never worth investing more time. But I mentioned it in passing to one of the other developers on the team. And as a holiday gift to me, this person discovered the solution. So let me describe a little bit more of what we've got working on here. On CI, which in theory is less powerful than my new, fancy M1 MacBook, on CI, we take about six minutes for the test suite. On my computer, it was taking 28 minutes and 30 seconds. So that's what we're working with. The factories are all doing normal things. We're not creating way too many database records or anything like that. So any thoughts, anything that you would inspect here? STEPH: Ooh, you've already listed a number of good things that I would check. CHRIS: Yeah, I took all the easy ones off the list. So this is a hard question at this point. To be clear, I had no ideas. STEPH: Could you tell if there's a difference if it's like the boot-up time versus the actual test running? CHRIS: Did that check; it is not the boot-up time. It is something that is happening in the process of running an individual spec. STEPH: No, I'm drawing a blank. I can't think of what else I would check from there. CHRIS: It's basically where I was at. Let me give you one additional piece of data, see if it does anything for you. I noticed that it happened basically whenever executing any factory. So I'd watch the logs. And if I create this record, it would do roughly what I expect it to. It would create the record and maybe one or two associated records because that's how Factory Bot works. But it wasn't creating a giant cascade or waterfall of records under the hood. If we create a product, the product should have an associated user. So we'll see a product and a user insert. But for some reason, that line create whatever database record was very, very slow. STEPH: Yeah, it's a good point, looking at factories because that's something I've noticed in triaging other tests is that I will often check to see how many records are created at a certain point because I've noticed there's a test where I think only one record is created, but I'll see 20. And that's an interesting artifact. But you're not running into that. But it sounds like there's more either some callback or transaction or something that's getting hung up and causing things to be slow. CHRIS: I love those ideas. I didn't even know those were sort of ideas in the back of my head. I didn't know how to even try and chase that down. There was nothing in the logs. I couldn't see anything. And again, I just kept giving up. But again, this other developer on the team found the answer. But at this point, I'll just share the answer because I think we've run out of the good bits of the trivia. It turns out bcrypt was the answer. So password-hashing was incredibly slow on my machine. What was interesting is I mentioned this to the other developer because they also have an M1. But there are three of us working on the project. The third developer does not have the M1 architecture. So that was an interesting thing. I was like, I feel like this maybe is a thing because we're both experiencing this, but the other developer isn't. So it turns out bcrypt is wildly slow on the M1 architecture, which is sort of interesting as an artifact of like, what is password hashing, and how does it work? And in normal setups, I think the way it works is Devise will say by default, "We're going to do 12 runs of bcrypt." So like take the password, put it into the hashing algorithm, take the output, put it back into the hashing algorithm, and do that loop 12 times or whatever. In test mode, it often will configure it to just run once, but it will still use the password hashing. Turns out even that was too slow for us. So we in test mode enabled it so that the password hashing algorithm was just the password. Don't do anything. Just return it directly. Turn off bcrypt; it's too painful for us. But it was very interesting to see that that was the case. STEPH: Yeah, I don't like that answer. [laughs] I'm not a fan. That is interesting and tricky. And I feel like the only way I would have found that...I'm curious how they found it because I feel like at that point, I would have started outputting something to figure out, okay, where is the slow process? What's the thing that's taking so long to return? And if I can't see tailing the test logs, then I would start just using a PUT statement to figure out what's taking a long time? And start trying to troubleshoot from there. So I'm curious, do you know how they identified that was the core issue? CHRIS: Yes, actually. I'm looking back at the pull requests right now. And I'm mentioning that this was related to the M1 architecture, but I don't think that's actually true because the blog post that they're linking to is Collective Idea blog post: Tests Oddly Slow? Might be bcrypt. And then there's a related Rails issue. They used TestProf, which is a process that you can run that will examine, I think the stack trace and say where are we spending the most time? And from that, they were able to see it looks like it's at the point where we're doing bcrypt. And so that's the answer. As an aside, my test suite went from 28 minutes and 30 seconds to 1 minute and 30 seconds with this magical speed up. STEPH: Nice. That's a great idea, TestProf. I don't know if I've used that tool. It rings a bell. But that's an awesome sales pitch for using TestProf. CHRIS: Similarly, I don't think I'd ever use it before. But it truly was this wonderful holiday gift. Because the minute I switched over to this branch, I was like, oh my God, the tests are so fast. I have one of those fancy, new fast computers, [laughs] and now they're so fast. STEPH: Wait, you had to switch to a branch? I figured it was something that you had to do special on your machine. So I'm intrigued how they fixed it for you, and then you switched to a branch and saw the speed increase. CHRIS: So they opened a pull request. And that pull request had the change in the code. So it was a code-level configuration to say, "Hey, Devise, when you do the password hashing thing, maybe just don't, maybe be easy for a moment," [laughter] but only in the test configuration. So all I had to do was check out the branch, and then that configuration was part of the Rails helper setup, and then we were good to go from there. I added an extra let me be terrified about this because the idea of not hashing passwords in production is terrifying. So let me raise...I put a couple of different guards against like, this should only ever run in test. I know it's in the spec support directory, so it shouldn't. Let me just add some other guards here just to superduper make sure we still hash passwords in production. STEPH: Devise has a bcrypt chill mode. Good to know. [laughs] And I like all the guards you put in place too. CHRIS: Yeah, it was really frankly such a relief to get that back to normal, is how I would describe it. But yeah, that's a fun little testing, and password hashing, and little adventure that I get to go on. Mid-roll Ad And now a quick break to hear from today's sponsor, Scout APM. Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more. Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform. See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. STEPH: So I have something that I've been wanting to ask you, and it's not tech-related. But we can make this personal and work however we want to tackle it. But there is a previous episode where we read a listener question from Brian about their self-diagnosed toxic trait being large pull requests. And Brian was being playful with the use of the term toxic trait. But it got me thinking, it's like, well, what is my toxic trait? And it seems like a fun twist on you, and I aren't really big on New Year's Eve resolutions. And in fact, I think you and I are more like if we're interested in achieving a goal, we'd rather focus on building a habit versus this specific, ambiguous we're going to publish ten blogs this year. But rather, I'd rather sit down and write for 15 minutes each day. And it seemed like a fun twist instead of thinking about what are my toxic traits, personal, at work? Large pull request is a really fun example. So I'll let you choose. I can go first, or you can go first, but I'm excited to hear your thoughts on this one. CHRIS: I think I've been talking too much. So let's have you go first at this point/ also, I want a few more seconds to think about my toxic trait. STEPH: [laughs] All right, I have a couple. So that's an interesting point start there [laughs], but here we are. So I was even bold because I asked other people. Because I'm like, well, if I'm going to be fully self-aware, I can't just...I might lie to myself. So I'm going to have to ask some other people. So I asked other folks. And my personal toxic trait is I am tardy. I am that person who I love to show up 5, 10, 15 minutes late. It's who I am. I don't find it a problem, but it often bothers other people. So that is my informed toxic trait. That might be a strong term for it. But that's the one that gives people the most grief. CHRIS: Interesting. I do find the framing of I don't find my own tardiness to be a problem as a really interesting sort of lens on it. But okay, it's okay. STEPH: I see it as long as I'm getting really good quality time with someone; if I'm five minutes late, I'm five minutes late. I think the voice going high means I'm a little defensive. [laughs] CHRIS: But at least you're self-aware about all of these aspects. [laughs] That's critical. STEPH: I am self-aware, and most of the people in my life are also self-aware, although I do correct that behavior for work. That feels more important that I be on time for everything because I don't want anyone to feel that I am not valuing their time. But when it comes to friends and family, they thankfully accept me for who I am. But then, on the work note, I started thinking about toxic traits there. And the one I came up with is that I'm a pretty empathetic person. And there's something that I learned that's called toxic empathy. And it's when you let people's emotions hijack your own emotions, or you'll prioritize someone else's physical or mental health over your own. So, for example, it could be letting another person's anxiety and stress keep you from getting your current tasks and responsibilities done. And there's a really funny tweet that I saw where someone says, "Hey, can I vent to you about something?" And the first person telling it from their perspective they're crying in the middle of a breakdown. And they're like, "Yeah, sure, what's up?" And I felt seen by that tweet. I was like, yeah; this seems like something I would do. [laughs] So over time, as something I'm aware of about myself, I've learned to set more boundaries and only keep relationships where equal support is given to both individuals. And this circles back to the book anecdote that I shared where I had to be careful about the books that I read because they can really affect my mood based on how the characters are doing in that book. So yeah, that's mine. I have one other one that I want to talk about. But I'm going to pause there so you can go. CHRIS: Okay, fun. [laughs] This is fun. And it is a challenging mental exercise. But it is also, I don't know, vulnerable, and you have to look inside and all that. I think I poked at one earlier on as we were talking, but the idea of perfect is the enemy of the good. And I don't mean this in the terrible like; what's your worst trait in a job interview? And you're like, "I'm a perfectionist." I don't mean it in that way. I mean, I have at times struggled to make progress because so much of me wants to build the complete plan, and then very meticulously worked through in exactly the order that I define, sort of like a waterfall versus agile sort of thing. And it is an ongoing very intentional body of work for me to try and break myself off those habits to try and accept what's the best thing that I can do? How can I move forward? How can I identify things that I will regret later versus things that are probably fine? They're little messes that I can clean up, that sort of thing. And even that construing it as like there's a good choice and a bad choice, and I'm trying to find the perfect choice. It's like almost nothing in the world actually falls into that shape. So perfect is the enemy of the good is a really useful phrase that I've held onto that helps me. And it's like, aiming for that perfection will cause you to miss the good that is available. And so, trying to be very intentional with that is the work that I'm doing. But that I think is a toxic trait that I have. STEPH: I really like what you just said about being able to identify regrets. That feels huge. If you can look at a moment and say, "I really want to get all this done. I will regret if I don't do this, but the rest of it can wait," that feels really significant. So the other one that I wanted to talk about is actually one that I feel like I've overcome. So this one makes me happy because I feel like I'm in a much better space with it, but it's negative self-talk. And it's essentially just how you treat yourself when you make a mistake. Or what's your internal dialogue throughout the day? And I used to be harsh on myself. If I made a mistake, I was upset, I was annoyed with myself, and I wouldn't have a kind voice. And I don't know if I've shared this with you. But over time, I've gotten much better at that. And what has really helped me with it is instead of talking to myself in an unkind voice, I talk to myself how someone who loves me will talk to me. I'm not going to talk to a friend in a really terrible, mean voice, and I wouldn't expect them to talk to me. So I channel someone that I know is very positive and supportive of me. And I will frame it in that context. So then, when I make a mistake, it's not a big deal. And I just will say kind things to myself or laugh about it and move through it. And I found that has been very helpful and also funny and maybe a little embarrassing at times because when pairing, I will talk out loud to myself. And so I'll do something silly, and I'll laugh. I'm like, "Oh, Stephanie," that was silly. And the other person hears me say that. [laughs] So it's a little entertainment for them too, I suppose. CHRIS: Having observed it, it is charming. STEPH: It's something that I've noticed that a lot of people do, and we don't talk about a lot. I mean, there's imposter syndrome. People will talk about that. But we don't often talk about how critical we are of ourselves. It's something that I will talk to people who I highly admire and just think they're incredibly good at what they do. And then when they give me a glimpse into how they think about themselves at times or how they will berate themselves for something they have done or because they didn't sit down for that 15 minutes and write per day, then it really highlights. And I hope that if we talk about this more, the fact that people tend to have such a negative inner critical voice, that maybe we can encourage people to start filtering that voice to a more kind voice and more supportive voice, and not have this unhelpful energy that's holding us back from really enjoying our work and being our best self. CHRIS: That's so interesting to hear you say all of that for one of your traits because it's very similar to the last one for myself, which is I find that I do not feel safe unless (This is going to sound perhaps boastful, and I definitely do not mean it as boastful.) but unless I'm perfect. I guess the standard that I hold myself to versus the standard that I hold others to are wildly different. Of course, for other people, yes, bugs will get into the code, or they may misunderstand something, or they may miss communicate something, or they may forget something. But if I do that, I feel unsafe, which is a thing that I've slowly come to recognize. I'm like, well, that shouldn't be true because that's definitely not how I feel about other people. That's not a reasonable standard to hold. But that needing to be perfectly secured on all fronts and have just this very defensible like, yeah, I did the work, and it's great, and that's all that's true in the world. That's not reasonable. I'm never going to achieve that. And so, for a long time, there have been moments where I just don't feel great as a result of this, as a result of the standard that I'm trying to hold myself to. But very similarly, I have brought voices into my head. In my case, I've actually identified a board of directors which are random actual people from my world but then also celebrities or fake people, and I will have conversations with them in my head. And that is a true thing about me that I'm now saying on the internet, here we are. STEPH: [laughs] CHRIS: And I'm going to throw it out there. It is fantastic. It is one of my favorite things that I have in my world. As a pointed example of a time that I did this, I was running a race at one point, which I occasionally will run road races. I am not good at it at all. But I was running this particular race. It was a five-mile January race a couple of years back. And I was getting towards the end, and I was just going way faster than I normally do. I was at the four-mile mark, and I was well ahead of pace. I was like, what is this? I was on track to get a personal record. I was like, this is exciting. But I didn't know if I could finish. And so I started to consult the board of directors and just check in with them and see what they would think about this. And I got weirdly emotional, and it was weirdly real is the thing that was very interesting, not like I actually believed that these people were running with me or anything of that nature. But the emotions and the feelings that I was able to build up in that moment were so real and so powerful and useful to me that it was just like, oh, okay, yeah, that's a neat trick. I'm going to hold on to that one. And it has been continuously useful moving forward from that of like, yeah, I can just have random conversations with anyone and find useful things in that and then use that to feel better about how I'm working. STEPH: I so love this idea. And I'm now thinking about who to put on my board of directors. [laughs] CHRIS: I'm telling you, everybody should have one. As I'm saying this, there is definitely a portion of me that is very self-conscious that I'm saying this on the internet because this is probably one of the weirdest things that I do. STEPH: [laughs] CHRIS: But it is so valuable. And it's one of those like; I like getting over that hump of like, well, this is an odd little habit that I have, but the utility that I get from it and the value is great. So highly recommend it. It's a fun game of who gets to go on your board. You can change it out every year. And it is interesting because the more formed picture that you have of the individual, the more you can have a real conversation with them, and that's fun. STEPH: So, as I'm working on forming a board of directors, how do you separate? Is it based on one person is running work and one is finance? How does each person have a role? CHRIS: So there are no rules in this game. [laughs] This is a ridiculous thing that I do. But I find value in it's sort of vaguely the same collection of individuals. Some of them are truly archetypal, even fictitious characters. As long as I can have a picture in my head of them and say, "What would they say in a situation?" If you're considering, say, moving jobs? What would Arnold Schwarzenegger have to say about that? And you'd be surprised the minute you ask it in your head; your brain is surprisingly good at these things. And it's like, let me paint The Terminator yelling at you to get the new job. STEPH: [laughs] CHRIS: Not get to the chopper, but get the new job. And it's surprisingly effective. And so I don't have a compartmentalized like, this is my work crew, this is my life crew. It's a nonsense collection of fake people in my head that I get to talk to. I'm saying this on the internet; here we are. [laughs] STEPH: That makes sense to me, though, because as you're describing that situation, I do something similar, but I've just never thought about it in these concrete terms where I have someone in mind, and it's a real person in my life who are my confidence person. They're the one that I know they are very confident. They're going to push for the best deal for themselves. They're going to look out for themselves. They're going to look out for me. They're going to support me. I have that person. And so, even if I can't talk to them in reality, then I will still channel that energy. And then I have someone else who's like my kind filter, and they're the person that's going to be very supportive. And you make mistakes, and it's not a big deal, and you learn, and you move on. And so I have those different...and in my mind, I just saw them as coaches. Instead of board of directors, I just see them as different things that I don't see as strong in my character. And so I have these coaches in those particular areas that then I will pull energy from to then bolster myself in a particular way or skill. This was fun. I'm so glad we talked about this because that is very insightful to you, and for me as well, and to myself. CHRIS: Yeah, we went deep on this episode. STEPH: No tech but lots of deep personal insight. CHRIS: I talked a little bit about bcrypt. [laughs] You can't stop me from talking about tech for an entire episode. But then I also talked about my board of directors and the conversations I have with myself, so I feel like I rounded it out pretty good. STEPH: It's a very round episode. CHRIS: Yeah, I agree. And with that roundedness, 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: Byeeeeeeeeee!!! 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.

The Swyx Mixtape
[Weekend Drop] Adam Argyle: Complexity Cliffs, DX, and the Disruption of Web Design

The Swyx Mixtape

Play Episode Listen Later Dec 5, 2021 70:06


The following is my conversation with Adam Argyle, CSS Developer Advocate for Google Chrome.Watch on YouTube: https://youtu.be/xEyJ6LY7DKIThe conversation covers a quite a few topics that are relevant in the webdev and web design industries: UI complexity cliffs, DX vs UX, Self Disruption, and what Web Design Tooling could be.Along the way we touch on what OpenUI is, Adam's Deferred Inputs proposal, the 4 Jobs of Developer Experience, Thoughtleading for Good from Emily Freeman, Ilya Grigorik, and Dion Almaier, and Adobe vs Figma vs Webflow!Links:  Button tweet https://twitter.com/swyx/status/1450333133300064259 https://open-ui.org/ https://jasonformat.com/application-holotypes/ https://siliconangle.com/2021/09/29/devops-dummies-author-emily-freeman-introduces-revolutionary-model-modern-software-development-awsq3/ https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar Ilya Grigorik Perf.now talk https://www.youtube.com/watch?v=vtIfVPtN6io Visbug https://chrome.google.com/webstore/detail/visbug/cdockenadnadldjbbgcallicgledbeoc?hl=en https://web.dev/learn/ Timestamps:00:00:00 Cold open00:01:05 Complexity Cliffs and the Reusable Button Problem00:03:28 OpenUI00:04:32 DevRel vs Personal work00:05:52 DRY vs Design Systems00:07:10 Building in Phases00:08:04 Thought Leading for Good00:10:33 Learning00:14:13 The Surprising Complexity of Tabs00:17:12 What is Open UI?00:19:59 Hot Take: Deferred Inputs00:23:40 Cathedral vs Bazaar00:28:01 Illya Grigorik: Head/Torso/Tail00:32:45 UX vs DX00:45:51 4 Jobs of DX00:50:33 Self Disruption00:54:50 Adobe vs Figma vs Webflow01:01:04 VisBug01:05:05 Shameless PlugsTranscript swyx: Alright So the first thing we're talking about is ui complexity cliffs what's on your mind what was his first on your on your list. Adam Argyle: yeah you had a tweet the other day that was i'm at my fourth startup or something like this and we're pressing buttons again like, how s it 2021. swyx: And by guys Adam Argyle: Are popping up i needing refactoring or something like How are they not solved and. Adam Argyle: i'm sure you had threads of people that have their ideas there and mine was it's a omplexity cliff it's the first introduction, where you as a front end ui person who actually. Adam Argyle: is like goingto go build out all this matrix of states that a button needs that it lands on you it's like you've been in the car using a shifter this whole time using a steering wheel this whole time and then someone said hey. Adam Argyle: Go change the steering wheel out and you're like oh that's just a component just a single use like that things totally only got like one attachment right, and then you walk up to it and you start working on it you'd like. Adam Argyle: To see just like really integrated into the system. Adam Argyle: And or whatever right, you have these like discovery moments with it and you realize it's much more complex than it is in a button just does that buttons like yeah well let's allow an icon to be on our button and you're like okay left and right. Adam Argyle: sides can be I can have both sides because you could have a shopping cart with a little drop down arrow. Adam Argyle: Oh man Okay, and you have to have dark mode you better have this and that and that the matrix like i've seen the of states, is what I mean by this complexity cliff like it's just not visible from the surface, it looks all innocent. Adam Argyle: And then you go map it like if you mapped out everything you need it's it's a lot, like the CSS alone that it takes to have like a custom button and the design system is absurd it's absurd, but at the same time I love it anyway. swyx: So this is the tweet and question and honestly like this is this is genuine because. swyx: yeah I had that to Sigma away, where I had my first front end job and then modify and now it's immoral same stuff again and all did you handle disabled Oh, is it a link, or is it a button. swyx: And it was interesting was also just the replies like Nicole from Google So what does she do she like. Adam Argyle: beats I worry record directly. Adam Argyle: These days, she was on frameworks and she's now shifted to ui and sort of like how did she empower people to build flexible and fluid interfaces on the web. Adam Argyle: And that's why she points to open your eyes it's like a community for that, but anyway that i'm part of her team because i'm I work on similar things. swyx: Okay yeah and so like you know, first of all I didn't I didn't expect this to reach anyone in Google. swyx: But then also like the Web components people reached out to me and they're like how come work a foreign service officer for you and i'm like it's not about the tech. swyx: it's more about like understanding the specs of what people wanted people not agreeing what a button should do. Adam Argyle: yeah. Adam Argyle: yeah Google cloud had had too many. Adam Argyle: They had them in multiple frameworks in the same. Adam Argyle: repo right being like just because they grew so fast or whatever like your project always gets out of hand and all of a sudden yeah you have more than one button. Adam Argyle: which some people have enough time or England one, how are they going to wrinkle two or three and built in different frameworks right you could your islands architecture with buttons you're just like oh snap touch mean any button from any framework just shows up in an island. swyx: that's an interesting discussion is that a big. swyx: Is the islands architecture, a big discussion within Google, or because I always have hard I have trouble separating Jason from Jason Miller, who wrote the article architecture markers. swyx: When is he talking in his own personal capacity, or when is he saying like No, this is something we're tight with thinking about a Google. Adam Argyle: Oh, in my opinion Jason and I are pretty straight shooters about our own stuff like we work for Google and chrome and we love our job, and we want to represent chrome well and do all the things our job want us to do, but we have this like I don't know where our own personal opinion like. swyx: jake Archibald as to he. Adam Argyle: he's working on a lot of his own stuff we kind of balance, both I mean Jason definitely does things internally that he might not have chosen to go do if he just could choose whatever he wants to do. Adam Argyle: But that doesn't mean that's what he's going to go pitch outside of Google and the islands architectures. Adam Argyle: yeah This is just sort of the micro friends evolution into let's eventually docker eyes every component and then manage them with communities in the front end right we'll get there, I don't know. Adam Argyle: yeah. swyx: Well, so the this discussion of the reusable button and the ui complexity cliff makes me wonder because there's a lot of discussion about how dry is overrated you know. swyx: We should we should write everything twice and sometimes if you're just customizing it so often you're reusing it so much maybe just don't reuse code just just copy and paste and then that makes it easy to the really easy to modify the only thing that. swyx: That goes wrong with that so whenever you need to do a global update then you'd run into trouble, but how often do you really need to do that. Adam Argyle: Right isn't that what the super RAD typescript refactor button is for like that's why you typed your whole thing, so that you could refactor across something globally, I mean this is a value prop of typescript right. Adam Argyle: If you are, you know, employing it that way, on your project but yeah I think that's a really good point, though, is that sometimes you don't need to build a mega button yeah. Adam Argyle: yeah mega buttons get built and then mega buttons fall down. swyx: And also wonder if it's like. swyx: If it should be gated by number of people working on the project, so we had at my first company. swyx: Three front end developers and we were building both the design system and the APP. swyx: And I was just like maybe we should build the APP and forget the design system. Adam Argyle: Okay, this is actually something i've said multiple times is that. Adam Argyle: projects and people are in phases, a startup is in a phase. Adam Argyle: And in your first phase where you're in the creation state, you should not be in typescript you should not be hardening all of your stuff with hundred percent test coverage and you should be not be making a design system which you need to do. Adam Argyle: Is build a really good experience that's messy and expressive. Adam Argyle: And then go hard and all the things that are tried and. Adam Argyle: True, because you can't predict it all, and if you try to sit down and predict it all and. Adam Argyle: and build this like perfect thing from the start you'll just never going to get to the point at which it should have as fast as you can it's weird we think we move faster with all of these rules, and all this stuff but we end up moving way slower. Adam Argyle: And so yeah i'd say phase two of your company. Adam Argyle: let's say you have success in your sustainable and it's time to like rethink something, because you can need to grow, the team by 10 or 15 or whatever. Adam Argyle: Go ahead and spend a few months and and refactor and harden and create the components that are obvious like and don't go micromanager design system okay wait i'm getting wrapped up sorry okay anyway. swyx: No, I think, look like you have this i've seen you do this rant a couple times. swyx: I think he needs to slap a fancy label on it and then put it put into a nice graphic and go like this is the way that you should do things because I have you seen i'm Emily freeman. swyx: At aws she did she basically had some issues with the software, the traditional software development lifecycle where it's like a very waterfall approach and shows you V shaped it into like a. swyx: Like a circular concentric circle grid with the six dimensions and it made a lot of sense for some people. swyx: But that at least encoded her opinion and she could give it a name and and she she said, like this is the way you do things now, and she had whole spiel on it, but like. swyx: Sometimes it's better to sell an idea or like a workflow if you give it a name and you put some put some diagrams on it and make it a thing, rather than repeating the rent every time. Adam Argyle: yeah and so yeah, this is the phases ranger mentioning like yeah. swyx: yeah catchy acronym or like you know, whatever. swyx: And and yeah I mean you know sea islands architecture was a catchy catchy name for it, you know. swyx: It was yeah was your last name, he had for. Adam Argyle: A holiday types right, it was holotype. swyx: hollow times, I never heard that word before. Adam Argyle: So cool yeah. Adam Argyle: that's what that's what Jason called it in an article, he was, oh no he was saying, your APP is one of these holiday types. Adam Argyle: And if you were yes certain holotype he could lead well to you know, an islands architectural river. swyx: yeah very good so Basically, this is like part of my long running a study on how the thought leader or thought leading for fun and profit, you know there's like sort of the cynical thought leading, which is like hey I want you to buy my ebook. swyx: But then there you can also follow me for for benefit if, like you really have a cause that you just really want to align people on, you have to package, it in a message that that people can spread for you, instead of you, having to do all the work. Adam Argyle: Totally yeah I think you're doing a good job with that being a thought leader, by the way, I very much enjoy your thoughts. swyx: I don't know what i'm meeting people to. Adam Argyle: I mean, I think that's what's fun as you're on an exploration constantly digging. Adam Argyle: And going to these archives and you're just kind of shooting it out, as it happens, and honestly that's kind of all, I do with my CSS tips i'm building stuff every day, almost all day and so i'm like here's it I just did this thing this is cool I think anyway. Adam Argyle: Yes, what else will and. swyx: I will say, like the thing about CSS like no one ever feels like you know all of it. swyx: Do you think that's a problem. Adam Argyle: No, I think that's how every language feels. swyx: So i've been trying to. swyx: push back on this little because I think being able to say, this is the entire map like Okay, you know, there is a spec right. swyx: And it's not an infinite list it's a finite list, and you can you can at least kind of draw like here's the world map, you will never visit. swyx: The entire world, but at least you know, like okay here's a comment here there's a comment there I haven't gone there yet, but it's there when I need it. swyx: At least like having boundaries around like Okay, the world ends ends here and. swyx: I think that's an interesting way to think about like learning or evangelizing something, and this is relevant for me, because at my job. swyx: We have a fairly complex system, and no one had ever enumerated the features until I went through and just went like Okay, we have 30 features and once you know these 30 features that's about it for the system. swyx: and being able to say that's it. swyx: And, and having an end to your learning I think it's a really interesting concept to have. Adam Argyle: yeah docs kind of give you that sense right you land on docs and you're like I have the world in my hands every API call and every function is. Adam Argyle: articulated here with every parameter yeah and I definitely see where you're going, I think that can help someone. Adam Argyle: Get perspective of the language that they're jumping into but there's like surprises right like you learn javascript for who cares how long and then all of a sudden someone goes, you heard of functional programming you. Adam Argyle: Like what and then you go look at you like, what are you doing with javascript and then it will. swyx: Stop. Adam Argyle: you're bringing it to infinity right and then like typescripts the same way you're like I thought I was like I liked were new like javascript and. Adam Argyle: In typescript just tells me all day that I have no idea what I know, and you know, like. Adam Argyle: CSS is the same way i've been studying and building things in it for a long time and I I also am a human, you know some of these things are so big that I can't memorize every map and territory. swyx: So I revisit in and. Adam Argyle: So I think what happens with experience is that you know, like okay every programming language has a moment where you're banging your head against it, you know whether it's FLEX box or it's. Adam Argyle: You know, some extends in typescript or something that's extending extend extend and you're just like lost in the extension world like in these scenarios you eventually emerge. Adam Argyle: Right you bust out. Adam Argyle: In your head comes popping out and you get a breath of air and you're like. Adam Argyle: I have defeated it like and what I think professional developers are they're just seasoned at defeating all the little things in so much that they're now in a perspective, where they expect things to pop up that they're not going to know. Adam Argyle: But be they've if they run into things that they run into before. Adam Argyle: They don't have the same hour or four hours or two days that it takes to solve it, they just walk right over it, because they're like oh that was in that territory over here. Adam Argyle: I remember like two years ago, when I had to go there, like i'll just go there, I don't remember everything about it. Adam Argyle: But i'll go read it and study and be like oh yeah that was it okay and i'll put that back in the 70s, like every time he's intersection observer i'm like I know in your section observer and then i'm like I don't remember the syntax I gotta go look it up so. Adam Argyle: Anyway, yeah. swyx: And they basically, I just want to copy and paste intersection observer code and just give me like the three or four design patterns that work and that's about it that's that's all people want out of it. Adam Argyle: Section observer, I mean I think people want the matrix I think they want to stick a thing in the back of their neck. Adam Argyle: And, just like CSS I know it, I will now command every box in the way that i've ever desired. swyx: yeah. Adam Argyle: Briefly, though, before we get off of complexity cliffs well the first components that reminded me of complexity cliffs was the tabs component. Adam Argyle: And we've been talking about that, so we talked about Nicole already, and so one of the things we're trying to do is make tabs on the web. Adam Argyle: easier and in my studies, I have found that it's a massive complexity cliff like there's 100 variants of what tabs are more than that, over the years we've seen thousands of variants of tabs. Adam Argyle: And they all have little niche features some little niche features, make a tabs feel like a carousel some tabs kind of feel like an accordion. Adam Argyle: Some tabs feel like those paper tabs you had in a binder and they all have this like little thing and they all have different accessibility implications and usually. Adam Argyle: that's like the deciding factor, at least, like open ui they're like okay here's what tabs are tabs are basically this accessibility ux as a foundation, like the skeleton of the thing works like this, but I go look in the wild. Adam Argyle: And I see all of these different tabs and i'm excited by it and it kind of frustrates other people, because they want to go harden the pattern right, this is what. Adam Argyle: The button is trying to do it's like hard and a pattern and so people want to harden these patterns, they they look so obvious to harden and then I go research and I basically called him Kara tabs now i'm like oh tablet cells you mean oh CARA tabs. Adam Argyle: you're like no tabs. Adam Argyle: i'm like care tabs. Adam Argyle: Because the variations are so fun and exciting and I actually think that's what the web is excelling at is this weirdness is that. Adam Argyle: Anyway, so, but the complexity cliff is very clear in tabs where there is really no single way to build one that would fulfill every tabs component needs that's out there. Adam Argyle: Like a lot of tabs have nothing to do with swiping when I think that's mandatory on like mobile you gotta be able to swipe between tabs. Adam Argyle: we've been trained that way for like five years but they would disagree, like the open ui organization because that's just not part of the. Adam Argyle: float anyway, so what i'm getting at is these complexity cliffs make it really hard to harden things and i'm at a point where i'm trying to study which ones are on which side of the cliff Sean that's what I want to know. Adam Argyle: Because the ones that are on the side that it just goes steep downhill I think it's okay to let those be free ship primitives and let people be weird. Adam Argyle: Let people build all these fun different exciting tabs like I don't i'm not that interested in that, but we could move into different inputs, if you want as that that next topic. swyx: I have a two things to ask you, before you do this so one thing you seem to have a image in your head about complexity cliffs have you visualize this because I feel like it's an analogy, that is right for visualization. Adam Argyle: know I mean it'd be an iceberg you looking at a button and it looks like a simple button on top, and then you look under the water and you're like holding this thing has like request animation frame loops in it, or something you're like I just did not predict that. swyx: yeah I think I think some visuals will be nice to for people to really is totally get it. swyx: And then, secondly, could you introduce for those who would like i've dug around open ui it seems like a basically it tries to be a browser vendor agnostic. swyx: spec have you here's how here's extensions to standard html well how about you do, how about you help me define like what is open ui who runs it, what is the near term like should people pay attention is now is it's just an r&d phase like what what's uh what phases it isn't it. Adam Argyle: Sure yeah and you know you should have unit on because she's a member of the open ui. Adam Argyle: cabinet, I have no idea anyway it's a Community group it operates like a Community group. Adam Argyle: it's led by I think Greg whitworth maybe Brian cartel also. Adam Argyle: Dave Rupert is on it also he does a lot of presentations Dave Rupert is a he's pro tabs not pro tab excel he has a spicy accordion that he's made that is basically tabs but it's. Adam Argyle: Not tabs it's a spicy accordion anyway okay so that's the sort of things that sometimes get talked about it open your eyes, but their goal is to. Adam Argyle: move faster as an agnostic implementation team, then what browsers would do and how can they operate like how the community groups do for CSS but do it for components. Adam Argyle: And so they have one that's like a recent success, I think, and it's taken a long time to get there, which is the POP over component, if you heard about the POP over component. swyx: know if I can pull it up, you can tell me about it. Adam Argyle: awesome it's cool it's classic you mouse or you focus into a link and you get a pop up right. swyx: This is it, this one. Adam Argyle: yeah. Adam Argyle: And so, this took a long time to get through it has tons of you can see that they are very look it's an editor's draft Oh, they have three and editors draft interesting, so the select element is also there, I know that my working on that one so something that's sustainable select. Adam Argyle: And I bet you that dependent on the pop up. Adam Argyle: Anyway, so i'm not a super pro hear about how they operate, but I do know that their goals are to make accessible well defined open source community group driven web components, I think their web components. Adam Argyle: And yeah and eventually I think their goal is to have those things accepted into browser specs and how browsers implement them natively maybe i'm not really sure. Adam Argyle: Where that goes from there, oh look, you can see mason freed on there for pop up he's the Google or who's doing a lot of implementation and he's on the group there to Melanie richards awesome. Adam Argyle: yeah it's got a great crew of cats that are like hacking on it, they they're diligent they seem passionate and i'm not a Member. Adam Argyle: Because i'm kind of. Adam Argyle: I don't know if we need more primitives. Adam Argyle: Sean. Adam Argyle: I want to, it is a heartache and i've talked to Brian and a couple other people about what look like i'm actually. Adam Argyle: So this is why the fruit inputs as an interesting conversation. Adam Argyle: I like to swing for the fences i'd like to swing a lot bigger. Adam Argyle: Okay, so, for example, let's say open ui or someone else and open you I seriously, I admire them so much, I think there is a really important and impressive thing that they're doing so I think i'm also just intimidated, but anyway. Adam Argyle: What I would like to suggest is okay consider the calendar so maybe a calendar component gets you know standardized so you could customize it you don't just get the 20 year old dinky one it's in your browser I. Adam Argyle: hate that one it drives me nuts and like she's the leads there's No one. Adam Argyle: else and. swyx: there's one that's worse than that it's the number number input. swyx: You know, with a small. swyx: tiny arrows. swyx: Oh, my. Adam Argyle: God seriously I don't know someone on a netbook with like one of those. Adam Argyle: mini mouse's or something anyway. Adam Argyle: Okay, so imagine this Sean This is my crazy idea called deferred inputs you put an input in there type equals date and you put an attribute called deferred on it, and what the browser does when they user temps that input. Adam Argyle: Is they broker a relationship between that webpage and a third party widget. Adam Argyle: And a third party experience, because what I want when I click on a calendar widget is not just a stupid calendar Sean I want my events on there. Adam Argyle: I want to know if what i'm picking is going to interrupt or something if i'm booking dinner I need to know. Adam Argyle: All of these different cases I want to know my stuff in there, but I don't want the webpage to know anything about it so imagine for a second that we went to the APP store MAC os and we installed. Adam Argyle: A calendar component called Google calendar who cares or maybe it's icon right account makes sense for safari to prompt. Adam Argyle: So you get these different inputs, with a broker, since the request to this APP and says this user is requesting a date All we want is a string format it like this, give them an experience that's rich and set and has a session and you're logged into. Adam Argyle: And let them pick a date and then we'll just get the date back so the date input is still just a static text input, but the browser brokered a relationship to third party. Adam Argyle: developers who can create specific and robust experiences for these inputs so i'm not talking we just, you know as a group. Adam Argyle: come up with a cool date picker that people can pass custom properties to to silent, I think that's a great stopgap but i'd love to see us like make a rich. Adam Argyle: Do picking a date is a rich experience moment it's something that people can excel at and show you how beautiful, it is like imagine sunrise like that APP they made the calendar thing that just like disrupted every time they made one and then imagine someone else. Adam Argyle: Now you had choices Sean you had choices for your date input as a user that's what I want to see, I want to see users, having the ability and I want developers to build a compete for the. Adam Argyle: Creation of those widget experiences I think browsers have been sitting on it and it drives me NUTS they're crappy and it looks like they don't care so just open it up. Adam Argyle: Just broker the relationship to a bunch of developers that want to get a $2 components, so that you can have a session logged in calendar picker like. Adam Argyle: in any way, so a lot of these inputs that are a lot of these components that we're waiting for. Adam Argyle: that are more robust that we need more out of like some of our primitives i'm like don't just give us some new crappy primitive that looks like crap. Adam Argyle: I just i'm tired of those like give us an opportunity and an open up the open up the industry to a new monetization flow like you're basically creating third party developer anyway, whatever Sean I think i've pitched it enough what, what do you think is that crazy. swyx: So I need to clarify one more thing so first of all, have you written this up anywhere. Adam Argyle: This is a slides I have like a little presentation and i'm giving it to people it's just it's pretty much can we find it somewhere. swyx: Just just so people can follow up if they want. Adam Argyle: I think it's just a random idea I have songs and like you know. swyx: I mean I if you know if you you believe this so. swyx: What this this kind of conversation always reminds me of the cathedral versus the bizarre. swyx: You know that Nice that a Fred brooks this is this is old school software development right like, how do you design it ecosystem, do you want, do you want to say, like I do it for you, because I know best, or do you want to say I don't know best, and that everyone just have it out. swyx: And so open your eyes kind of the cathedral and they're like Okay, a little research everything and then we'll we'll pick the best way, that is, the superset of everything and then. swyx: The bizarre it's kind of like this different input approach where it's just like I don't know and i'll just give you a single extension point and you guys go nuts. Adam Argyle: yep that's exactly what it's basically just be what I call them. Adam Argyle: Because they have an android or an intent the. Adam Argyle: input basically admitted intent. Adam Argyle: And it says, who can handle the intent right. Adam Argyle: And all these developers now have Apps living on your operating system that the browser can broker the intent, was it says. Adam Argyle: it's just like how intense it's actually extremely modeled after, then the mobile experience of. swyx: Intense. Adam Argyle: Because I love that experience it's really nice you're just like yeah look at all my fun custom stuff I have they can handle where my image goes like that's really nice. Adam Argyle: And yeah we should have a color picker like that, like give me the opportunity to click on a color and put in I bring my own color picker to the table chrome. swyx: You know so. swyx: I don't know yours yeah. swyx: Is this the user so. Adam Argyle: there's a few personas yeah there's user. swyx: APP developer, and then the user viewing the site so each viewer has like their own experience of this thing okay. Adam Argyle: They got. Adam Argyle: A utility built of personalized widgets in their browser so anywhere their browsers logged in and. swyx: How many of these are there. Adam Argyle: I mean a perfect kind of labeled a few here. Adam Argyle: yeah calendar auto fill payment. Adam Argyle: photo picker and file picker oh photo picker and file picker already done, is what this says in my deck I haven't looked at my deck and like a year. Adam Argyle: Because yeah if you think about photo picker. Adam Argyle: Well, I guess, on mobile it's different but on desktop it's not right on mobile when you click on a file uploader you click on some things allows you to upload you get to fulfill it with your own choice of an APP your phone. Adam Argyle: Your personal stuff just needs to return an image right, and then the browser doesn't have to know to care about the whole experience that it took you to find it because you went back three years on June 24. Adam Argyle: To find the hamburger that you were looking for right like anyway yeah so auto fill would be an awesome one and payment like why can't I just install a third party payment installation thing and. swyx: When I so i'm. Adam Argyle: Pay yeah invokes my own experience. swyx: Well, what about security like if it's a third party widget and it's payment like i'm giving you my card details. Adam Argyle: User installed it, and so there, hopefully they're trusting what they installed and that the page itself is only getting results back so it's like the same static results they would have got before. Adam Argyle: So the page doesn't get to know anything about the third party experience there's like a very it's just a message that's going to get passed back and forth him. swyx: And do you think so, one example of this, that is done in user land is essentially password managers. swyx: Like a right they they override all the password fields and then they've given their own little things why can't it just be done like that. Adam Argyle: Oh so like an extension model. Adam Argyle: sounds good to me so yeah you could as a developer go build a whole bunch of really awesome you know extensions built on the extension version three manifest and deploy them across all the browsers and. Adam Argyle: deliver a unique logged in experience for color picking and sure yeah maybe you could intercept those clicks and invoke your own overlay ui actually makes sense to me. swyx: Okay got it so it sounds like you know of those things that you missed it those are inputs. swyx: There are a lot of things there a lot of components that are not inputs. swyx: And I guess open you I would be involved. Adam Argyle: Like tabs carousels pop overs yeah. swyx: So you're not in conflicts, you know. Adam Argyle: I don't think so yeah. Adam Argyle: yeah Okay, and both can coexist, they could create a new date picker and that should be the default, we need better date pickers so better default components anyway so yeah i'm like this isn't me trying to stop them it's like I just think there's a whole opportunity for competition, like. Adam Argyle: yeah and it could be cool yeah. swyx: One one last thing that comes up when when we talk about image speakers. swyx: Did you ever see that talk by ilya regard about. swyx: The image picker up like file size optimizer. Adam Argyle: I don't think so tell me all about it. swyx: So he had a fantastic talk, which, like really shaped the way I think about so okay oh God, I can give me a SEC to pull this up Okay, because. swyx: I don't I don't think i'm gonna do this justice. swyx: Unless I literally have it up. swyx: What is his Twitter handle he's not super active on Twitter. Adam Argyle: it'll yet some. swyx: I Google org. Adam Argyle: Oh, I was wrong. swyx: Okay, all right. swyx: All right, here we go so. swyx: This is where this is where I shouted it out, he had this concept of the. swyx: The head the torso and the tail. swyx: and swyx: It was like, how do we solve. swyx: How do you solve image performance forever right like you can do some fancy stuff with like. swyx: Your image optimizing cdn you can do all these like source set things no one's going to do it, it just is too complex like yeah it's cool and you should feel bad if you don't do it right, but also there's just too much to learn. Adam Argyle: Serving images is very hard yeah it's hard. swyx: So, like he was fee fantastically broke it down to like okay so he's he's at this performance now conference right and he said. swyx: Okay yeah here we go. swyx: I like I just I just love how clearly stated this if you want to solve the image problem once and for all the cost should be free, the number of choices should be zero the tools must do the work not require work. swyx: Right now, the tools that we're being given require more work hey the default sucks but just to be backward compatible here's a source at thing with like five different options and hey you got to do image processing on your own good that. swyx: That requires work, so people don't do it right, so the kind of person that goes to a performance now conference that watches performance videos in their free time, that is what he calls the head. swyx: That and i'm not finding a slide but essentially like there's a there's an adoption curve right there's there's the really like performance oriented performance minded people. swyx: who are going to adopt all the best practices they're going to listen to your target have read your blog posts, then the torso they're like they're just you know, following whatever the. swyx: Body says, and then and then there's a long tail that just will never read anything they'll just do whatever this is easiest So you see, if you want real impact, you have to address the torso under the tail not just the head, because the head. swyx: Has the time to this to learn all your stuff but that's not the problem, the problem is the rest of it, like everyone else. swyx: Sorry, I think i'm like doing doing things the job of. Adam Argyle: Now I think i'm following yeah. swyx: So so his proposal by the end of his talk, and this is like in 2019 was that okay all right image optimizing cdn too complicated set too complicated. swyx: Never just never upload a giant file that you never giant photo that you never need so he was like let's introduce an image uploaded a component that has image optimization built into that that point of upload so all points down the chain just never get there. swyx: I thought that was like that this I thought that was where you were going I don't know if you talk to them before about this. swyx: Okay. Adam Argyle: I have not. Adam Argyle: That kind of reminds me of ink ink uploader which I used I don't know, five years ago, or so it was kind of like early image X server but yeah you upload the biggest image, you had and then request it with one URL. Adam Argyle: And maybe some parameters on the URL and you get you could get a whole dynamics of the images back yes. Adam Argyle: And only had to deal with the one image tag and yeah yeah well that's the way forward motion. swyx: that's an image optimizing cdn. swyx: So you have to pay money for that and, of course, like you know that that. swyx: Costs of engineering resources, so he wanted to go a little bit more than that, I don't know how practical it was, but it was very convincing at the time. swyx: And you know I hope he I don't know if he's still a Google or not, but you know. Adam Argyle: He is yeah. swyx: He gets some sway in the design of this thing. Adam Argyle: Nice yeah I like that analogy, though, I think that works really good. swyx: Which is I mean it's so in a broader context of Dev developer tools and like designing for us versus the exercise next topic. swyx: yeah. swyx: I think about this a lot, which is that whenever we appear at conferences and we like dropping you blog posts and new feature and we just expect people to like. swyx: know about it and learn about it and adopt it like within a year, otherwise it's their fault not yours and i'm just like no people don't have time. swyx: Most people just want to know, like what the best practices they're going to do that and then they'll they'll move on with their day and that's about all the time that they have for you. swyx: And, and so, if we want to you know, improve user experience like we have to make it basically bring this for people to adopt the best practice. Adam Argyle: yeah so we can yeah do you want to start there like. Adam Argyle: yeah that's The goal of the phrase, or like that's like the. Adam Argyle: The the heartfelt meaningful good side of the phrase that dx can lead to good ux is the intent is there, which is that people want to deliver good ux and they're not wrong that good dx can deliver a portion or maybe a lot of ux. Adam Argyle: But I think that the phrase is kind of not doing itself a favor like it's it's kind of a short sighted view of what dx is versus a short sighted view of ux and i'm like. Adam Argyle: I don't even know why we're so okay so first off let's just say that to have dx it even could facilitate good ux someone had to teach the dx what good ux was like ux had to start it. Adam Argyle: In order, like be the initial cause for dx to exist, that it was knowledgeable to give you good ux so i'm like. Adam Argyle: wow is people think the dx just magically gives good you actually had to be written by somebody like the good ux was created and someone spent valuable time thinking about good ux. Adam Argyle: In order to bake it into something that could be shared better that then helped facilitate a workflow which is just like how like a bakery it would work right you just got like okay we've got all these processes they're working like this. Adam Argyle: And now we're going to always use this flower instead of have random flowers and we're always going to use this scoop or something like that, and you just start to like. Adam Argyle: harden these things over time, so that when new people join they don't have to go learn there's three scoops there's just one scoop now to choose from, and every time those decisions get made like they're made in a good faith that, like us, like the bakers, are trying to make more. Adam Argyle: You know muffins or something for everybody, like the ux is eating a muffin. Okay. Adam Argyle: That. Adam Argyle: Essentially you can. Adam Argyle: overdo it, just like in a design system, you can overdo it so where eventually maybe you make a factory maybe you've got you know, and this happens all the time and code we build tons of factories to stamp out web pages to stamp this out to stand we'd love our automation. Adam Argyle: And sometimes automation. Adam Argyle: All it does is harden one good ux choice and it might make subsequent ux choices harder. Adam Argyle: in any way so okay so then here i'm going to go back to like the like dx is so much more than providing good ux like there's so much more to it, like you can have an entire. Adam Argyle: day's worth of dx that never touches ux and that should be fine like you should be happy with that, because what you're trying to do is empower everyone after you. Adam Argyle: or whatever it is like I think it's valuable time so basically I think it's short sighted dx to think that it can only be valuable if it's affecting ux I don't think that even needs to. Adam Argyle: go away. Adam Argyle: And then. Adam Argyle: Right, I think dx it's like you could do anyway so dx can be entirely in a whole other sector of the organization and never changed the ux and I don't think that's bad. Adam Argyle: I think sometimes it can in consequently change ux and that's awesome sometimes it can intentionally do it, you know, maybe data, the data Center team over here. Adam Argyle: They switch to a different cluster system and now they're you know shaped 50 milliseconds off a request or whatever you're like cool the user might feel that or whatever. Adam Argyle: But then also ux it's short citing what ux is if you've ever met a ux designer. Adam Argyle: To them, the user experiences and how fast the milliseconds went down the wire, even though this is part of the user experiences how fast you got it to them. Adam Argyle: They spend weeks and months researching users to make informed decisions about ux. Adam Argyle: it's so to think that dx can just magically have all of that, I mean unless the designers are baking and they're the ones, creating the dx maybe dx is directly affecting us. Adam Argyle: But really I think ux starts with research it doesn't start with good dx you have to you have to know what good ux is spend time on it. Adam Argyle: and actually create it before you can then go harden it and make it like repeatable and shareable or whatever it is, and also ux is just so much more than. Adam Argyle: That moment the button downloaded and you pressed it so it's like belittling. Adam Argyle: The whole concept of ux and dx at the same time it's a comparison that doesn't even really matter like here's another thing too. Adam Argyle: Is you can have the worst dx in the world let's say you can only ssh into this one server you have no tools you're just with vim and it's like an. Adam Argyle: insane react project you don't even have web pack, you have to go edit the output of a bundle let's say that who knows. Adam Argyle: dude a determined ux person will do whatever it takes to make the ux good they'll go hack that code it doesn't matter the dx will matter, what matters is the desire that someone had. Adam Argyle: And you know, conversely, you could have like the best dx the entire world and deliver a button that says fart. Adam Argyle: Because the text in a button bro. Adam Argyle: is part of ux man there's ux writers that's All they do is provide text so maybe if you're dx or your button was so RAD that you could like. Adam Argyle: A new button and then you drop it in, and it has a whole suggestion of ux written content in it like I don't think you're really getting the full fledge. Adam Argyle: Delivery of ux because it's so contextual it's so subjective it's so human that. Adam Argyle: All you get from dx in terms of ux is anything that's on rails and anything you get from dx that can lead to good ux usually can because good ux sourced into the dx that then change the ux so I just don't. Adam Argyle: it's just like i'm like i'm not sure everyone's trying to say other than I think you know, which is, I said at the beginning i'm like I see the initial goal here, which is like hey if you have. Adam Argyle: really great tools, it can make it easier to slice some bread and put butter on it and then now you have slice butter way faster, you know, like look at us and we made a process for it, and now we can do 10 breads and 10 butters. Adam Argyle: In a parallel right we're gatsby and now we're doing parallel bread's buttered. Adam Argyle: Right until the designer says oh we're not using butter or new new butter and peanut butter and everyone's like Oh, we made a factory for that last process you're like dude users want peanut butter now too so. Adam Argyle: Are you have to update all the dx to match the new ux. Adam Argyle: So that's kind of what I see I think it's almost like ux is equal to dx which could trickle down to ux again early that's the intent, and so I just don't. Adam Argyle: know why we. Adam Argyle: don't talk about the full cycle and I don't know why we want to belittle the two concepts like ux is more than just developers. Adam Argyle: Building buttons and forms and flows and stuff like that there's a whole team of ux designers that they are literally fighting your company to have good ux. Adam Argyle: And I just that's why I think a lot of designers don't retweet the dx is better than us, or that dx will lead to good ux designers just know that they're at the table every day. Adam Argyle: arguing with somebody that they need to refactor this because it's not good user experience and the person over there is going move I see all your research, and I see you did user studies. Adam Argyle: I just can't allocate the resources and meanwhile they've got a team of 10 people increasing the dx of the backend system over here right and they're just not funding. Adam Argyle: The ux so anyway, I can just see like all these different sides to it and i'm. Adam Argyle: i'm just not it just doesn't do anyone to favor it's not doing dx a favor like it's not it, if anything, it kind of like makes dx look like the hero to I think that's my biggest issue with it, it makes dx look like it's The thing that lead to good ux i'm like. Adam Argyle: No, it doesn't it. Adam Argyle: Never anyway so i'm like it's not the hero. Adam Argyle: The hero here is. Adam Argyle: Having good ux like that's what everyone wants is, could you X dx steals the show and that freezing. Adam Argyle: And it's just so anyway i'm mostly annoyed with it and i'm like it's just it's based on like these couple of paths like people we look at this dx lead do that, like that's one path of 1000 that you'll take and building a product that has good ux. Adam Argyle: sure your dx lead to good ux there congratulations just don't praise that phrase like it's going to solve all of your ux problems. swyx: It is not. Adam Argyle: The responsible party for good choices ux focused individuals are the ones that make the good ux choices. Adam Argyle: and get funnel those through dx and background or whatever. Adam Argyle: So I just think it's missing the point and always. Adam Argyle: How do you feel. swyx: know why you know why we hear so much about it. swyx: it's because the ux people have nothing to sell you where's the dx people have something to sell you. swyx: there's a there's an economic incentive to drive things. Adam Argyle: yeah dx is the hottest phrase to get your product recognized right now that's for sure how. swyx: Do you think so, do you think the term is tarnished now you think it's so. No. swyx: No it's. Adam Argyle: tarnished to me, but no it's still hot, as ever, you kidding. swyx: it's my it's my it's my fault either mentally so my job titles literally had to develop experience. swyx: And I don't know if I want to. swyx: associate myself so closely with this thing. Adam Argyle: Oh, really, oh dear, I mean hey dude I associate myself with CSS how many people want to do that. swyx: I think it's amazing that would you that I think that una una or like my like I idolize you guys so much because. swyx: Oh no way be able to advocate for CSS Hello like. swyx: it's just it's just so first of all, you have to be good at, you have to be like really good at both of you are actually really great. swyx: But also just you're advocating for something that everyone can use so there's nothing to sell you it's just like you already have this and. swyx: Like 90% of you are terrible at it, or like you could be better, you know let's put it politically correctly, so I mean I think it's great I CSS will be around longer than both of us will be around, and I think it's. swyx: No one I don't know every everyone can always use a bit more CSS and their life. swyx: I need a CSS shirt, by the way. Adam Argyle: I could probably figure that out i'll send you a link later. swyx: it's just funny right like you know they're they're like 100 different js cons and like maybe I don't know if i've ever seen the CSS COM. Adam Argyle: There is yeah and I think. Adam Argyle: There was one of really popular one for five years and Europe and it's spread there was like once happening in other. Adam Argyle: continents, but it's I think kind of I don't know the conferencing is shaken up recently but yes. Adam Argyle: Yes, she's definitely underdog, and all this stuff. swyx: I mean I yeah so I mean I was really encouraged when he joins and then you started putting out a really good stuff and I just I think Google does something right when you when you hire developer relations, I don't know what it is, but. swyx: Every every person I see it's just stellar. Adam Argyle: To Dr Mayer dion has. swyx: I have. Adam Argyle: An emotion is he responsible addiction yeah he's the one who saw me. Adam Argyle: Like I anyway yeah he pretty much pulled me out of the team, I was at and Google and was like hey you want to do this over here and chrome and I was like I idolize you all I couldn't do that he's like you're one of us would you like to be like. Adam Argyle: Okay, and he totally believed in me and. Adam Argyle: gave me lots of chances and was and yeah i'm and I think there's lots of so he left recently a couple months. swyx: yeah shopify. Adam Argyle: shopify and you could tell he shattered people like there were people that were like dion was like. swyx: A. Adam Argyle: Different person he was someone I was emotionally. Adam Argyle: engaged with he has this amazing ability to listen and anyway, what what a great leader and manager, he was and he had he has some sort of skill I don't you know you'd have to ask him how he. swyx: knows asking. Adam Argyle: Someone and how we can judge people but yeah he's got a talent there. swyx: I you know I had so I went to boulder recently, and I think he is like just just outside builder or something and. swyx: I had lunch with him and he never he's so humble he never brings this up he's just like yeah I like I like tech like you know I think shopify school, you know he never talks about like how he runs. swyx: His Oregon how he how he thinks about hiring. swyx: Interesting guy interesting. Adam Argyle: Interesting guy and he just curious his candor so well. Adam Argyle: yeah but hey back to the dx says, like a job title, I do think it's still important, I just a and that's what i'm saying I don't think the phrase does your job, justice, like it's making dx sound like it's only valuable if it is impacting ux and i'm like that's not the case. Adam Argyle: You can integrate our developers to save hundreds of hours a week and and maybe never touches the ux and who cares you just still saved hundreds of ours, like, why is the value of dx somehow hinting. Adam Argyle: on its ability to hang on so we're getting more ranchi again why is yeah just doesn't like it's not doing it justice like it wants dx to be respected, and like it already is. Adam Argyle: So why push. Adam Argyle: This is like it's best moment to like. swyx: yeah whatever, so I think you know just just because you're you're interested in this i've been defining it in. swyx: In maybe like four ways, so the first this API design because. swyx: That is that every everything is downstream of like did you did you design the right abstraction right like the same thing that you're doing with different inputs and stuff like that. swyx: And then second of all docs for for that API right, you have to. swyx: be able to find it first of all, it needs to have full coverage everything that is in your API should be locatable and then it should be anticipatory like tell me what i'm going to need before I know about it, which is a high bar. swyx: But like. Adam Argyle: No, I like that's like visiting a docs page and it's already got my keys in it like I don't have to go find my keys it knows i'm writing. Adam Argyle: and looking at the docks and it. Adam Argyle: But yeah. swyx: To me that's just like template this template of docs I mean everyone can do that, you know, like it's. swyx: It is, it is, it is good people do do enjoy that but I always want to have an opinion, like Okay, you know you have like two required options and five not required options, but this is recommended in these situations, and this is only for power users tell me that. swyx: In the docs before before letting me go on configure it on my own so that's what i'm trying to do with our docs and then the last part is, if I have a done for you, the last word is. swyx: Three yeah right. swyx: Okay, so so there's there's developer relations, which is like traditional. swyx: Content creation is like teach me how to do stuff. swyx: Do tutorials do beaten, I mean. Adam Argyle: hype man. swyx: hype it up hype man yeah and then the last part is community which basically like do you have a place to go to ask questions and how how much you know. swyx: Like can you get a job in this is there, like a training is there, like career progression do I see myself identifying with this technology as a career like. swyx: There are lots of technologies in our lives there's only a certain technologies that we choose to call to like say like I am a developer, I am a reactor developer that that means something that's over and above just the the particular library and framework that you use. swyx: I don't know if I should do that I don't know if I should be so expensive and say like oh yeah communities part of this, too, but also it kind of is. Adam Argyle: It definitely is it's something that I tried and I still try to focus on by having open office hours doing the AMA is. Adam Argyle: I try to reach out and yeah that's why I do conferences, I like to do I don't think I can effectively do my job. Adam Argyle: If i'm not connecting to the Community, because otherwise i'm living in a bubble and i'm not putting my shoes on that are uncomfortable for me like I need to be constantly putting on shoes of other people to have my own perspective. Adam Argyle: shaped well and then it makes me a better educator It makes me better at all these other roles yeah. Adam Argyle: it's that it's included. swyx: it's my that's my map of developer experience so far and i'm trying to implement that. Adam Argyle: awesome that sounds very amicable and it sounds like you have four pillars and everything at Google ends up being in four pillars. Adam Argyle: So, congratulations on. swyx: Google the coming. swyx: weeks to come in threes I don't know. Adam Argyle: Three is a little more catchy huh yeah. swyx: Wait so what's an example of the thing is that that's four pillars at Google. Adam Argyle: let's see if I can I don't know if I could remember one right now but it's like anytime a leader is presenting like. swyx: there's always. Adam Argyle: One slide that's got like four pillars of our beliefs or whatever and you're like come on this is just a template slide everyone slaps and they go. Adam Argyle: Oh, this was some crap. Adam Argyle: Anyway, so we tease it every time we see it we're like there's the pillars. swyx: I mean it, this is the whole thing about draw the map right like like I want to know, like where do I end, because if you just say it's all the things I don't have to. swyx: do with that, but if I have covered like the big macro is kind of like your your meal right like when you're when you're eating you want to make sure you're taking care of your big macros and in you you're roughly like you're going to survive. swyx: So. swyx: Nice yeah it's kind of how I think about should we talk about self disruption. Adam Argyle: yeah. swyx: Alright, so tell me about what this what this is and what prompted it actually. Adam Argyle: Okay, and let's see what prompted it. swyx: was just something like not innovating or was it. Adam Argyle: That was just me making a comparison yeah I was apple and their new machines. Adam Argyle: It was. Adam Argyle: Chris cormier sharing a CSS tricks article about alternative browsers based on chromium that are offering unique can express of experiences. Adam Argyle: It was me reflecting on opera when they tried to do this with opera next as like a self disrupted browser implementation, it was really cool it's like bubbles every town was pretty neat. Adam Argyle: And I just was like started I just started thinking about it, I was like in tech okay it's like as a naive implemented right because i'm pretty much swinging the hammer on the engine every day like i'm constantly. Adam Argyle: In the House, making sure the door handles are shiny and open easy like this is what I mean by like being a ux developer like i'm just going around and making sure. Adam Argyle: That it all flows and i'm like in my head i'm like if we had tons of money and this thing was just so successful you know what I would do is I would roll that all into like a labs team. Adam Argyle: That made it so that I made the next generation of house like let's quit hacking on these same houses, we have it up, we have a great process and it's all hunky dory but at the same time, like we're out putting a factory looking thing. Adam Argyle: And, and we seem to be happy and proud about it, we are but i'm like okay So for me I got really confused i'm like I would, if I had all this money and success. Adam Argyle: Roll it entirely into disrupting myself into the next coolest thing, because now I don't have to have the same stresses, I did the first time, the first time, when I made my product, I was fighting right and you were pushing you had this ideal in this mentality. Adam Argyle: And i'd want to live that again, and what I don't see happening is companies do that I see chrome browser what is it 10 or 15 years old. Adam Argyle: It looks kind of the same has a ton of new features under the hood but i'm like this is a very unexciting user experience but that's probably fine that's fine for mainstream application and yeah you don't want to go to so anyway, I like I understand why. Adam Argyle: it's risky to try to self disrupt but at the same time, I made the adobe comparison with you i'm like 20 years of success of photoshop. Adam Argyle: And yet there's still like every three years, a new design tool popping up that. Adam Argyle: turns everyone's head away and is almost it always feels next gen when it shows up sketch showed up everyone freaked out three years later we'll freaked out over Sigma three years later we freak out over xd. Adam Argyle: And and yeah they're like they're disrupting photoshop but photoshop not disrupting itself like why can't they just sit back and be like we've got hundreds of thousands of dollars and lots of. Adam Argyle: developers let's pivot everything until like V2 of this thing and just rocket into the future, you know, like let's do what everyone actually wants, instead of just repeating. Adam Argyle: Anyway, so that that was the thought process and I was like why. Adam Argyle: Like Sean why don't more people roll their success Okay, because they do this in business right if you get a big fat success in your bitcoin output, or what I don't know like you roll your money back into a bigger investment and you roll it again. Adam Argyle: But they don't seem to do that with their products it's almost like it gets big they get. Adam Argyle: Rich they get not inspired anymore, and their focus has changed and they're no longer in that mindset of. Adam Argyle: Building the best product there now and then they're just in a new phase right and i'm like yeah, but you can be in the new face and invest in like another disruptive face right like now, you have the funds for it and that's what. it's all coming from yeah. swyx: A lot of thoughts on that. swyx: First of all, wasn't so wasn't xd doesn't actually count because it's also from adobe. Adam Argyle: I would argue it's of this is so rude of me to say is pretty much a fig macloan. Adam Argyle: yeah and it's great I love xd In fact I like it better than figure you. swyx: want them to innovate, the end of the day, I want them to. Adam Argyle: here's what I want photoshop to do with all their money and all their fantastic developers is make an actual web design tool like a real. Adam Argyle: represent tool and stop messing around with 20 year old style gradient makers and all this old crap that you've been carrying around like shed all that baggage go something straight up web focused and just. Adam Argyle: chew that crap off and just spec centric design tool, something that actually like has html elements in it, it helps designers facilitate something that is like more oriented towards a real thing instead of continuing to yeah. swyx: So we're flow like I mean. Adam Argyle: Yes, sure yeah so they so web flow chart it does disrupt the design market right big building like a web centric and web focused and spec focused design tool. Adam Argyle: And yeah i'm like why doesn't adobe look at that and go Okay, we need to do the same, we need to have. Adam Argyle: Our own version of this with our name on it we've got the funds we've got the people like they. Adam Argyle: See like from the outside, they have everything they need to do it like I look at Google, the same way i'm like look at chrome like they have all the money and all the people they need to make another version that's just incredible. Adam Argyle: And just does something fresh. Adam Argyle: But yet they're not and so yeah I was mentioning to you it's like ego it's just like to Polish turds apparently, so I think that's just kind of what happens is your ego grows. Adam Argyle: And you're like you, your smuggle I think I think what happens, this is success turns a lot of teams into some eagles and they sit and go my. swyx: Precious. Adam Argyle: yeah and they just. Adam Argyle: They just stroke, the ring and don't do anything new, with it, or whatever, and I guess that doesn't make sense, because they're. Adam Argyle: Not sitting on a pile of money, but anyway, you get what i'm saying. swyx: What adobe sitting on a pile of money, I definitely vouch for them for doing that, if they're like a 200 when I last looked at them like five years ago there, like a 60 billion like like decent size and now they're like 240 billion and. i'm just. swyx: To create like this, you think you think you know these companies, and then they they just blow past any form of expectation. swyx: Okay, so a couple couple things on this, so one is you know I had, I had a APP that I updated you know there's a I have 200 Apps probably on my phone, they do not update. swyx: You know why I don't update them because they may they may change and i'm scared of change, they work fine for me right now. swyx: And I updated one of them and yeah now like the old ux is gone and I can't get it back yeah so sometimes like don't fix what he broke, you know, like if I rely on this from a living in my business tools like. swyx: It just makes sense to just keep it for the others who will a very you have it, that that means something you know what I mean like that. swyx: That lack of change actually is a feature sometimes but yeah I mean obviously innovation is helpful, he did not want them to produce a Sigma clone I get it. swyx: they're probably looking at building a workflow or by workflow is both they're both totally possible but I don't think it's proven itself, yet I don't think like designers have like flocked to web flow like they have to figure. Adam Argyle: they've been distracted with yeah design systems and components third. Adam Argyle: Design tools are competing competing in that space to you know, make an API for all your tokens if you make your art boards like this put your squares like this and give them a name and you'll output, an API blah blah blah. Adam Argyle: yeah they're over there, turning their wheels hard. Adam Argyle: digging holes yeah my opinion yeah. swyx: Well, so Okay, and then there's also the fact that, like. swyx: It I think it takes a few years for a product to season. Adam Argyle: yeah. swyx: And, and like photoshop just you know I think it's not like there's like the Web version or creative cloud or whatever like that hasn't been that been around that long and it takes. swyx: A long time to reach like the mass population again, this is the whole concept of like you're in the head you evaluated all these tools and they came out you're like you know the difference between them, most people don't. swyx: Most people like hear about them like five years after they're out because, like that's what that's how long it takes to like hear about things you know from your friends and stuff. swyx: So you're you're wanting innovation at a pace that, like most of the country, your most the most of the industry doesn't operate on so I just want you to norm yourself. Like. swyx: Because you're at the cutting edge of a lot of things. swyx: Like and maybe it feels like the companies are not kee

Enjoy the Vue
Episode 77: Enjoy the Petite Vue with Dave Rupert

Enjoy the Vue

Play Episode Listen Later Oct 11, 2021 69:24


This week's episode is sponsored by Cloudflare Workers (https://enjoythevue.io/cloudflare-workers)! Have you ever wished that Vue was smaller? We know we have. Petite-Vue is an astonishing 5.5KB, which is so small, it's almost invisible. Dave Rupert, a developer at Paravel, joins us today to discuss all things Petite-Vue. We hear how this smaller version was released, and Dave shares what his experience of using it has been like. Often, when a framework is more compact, there are tradeoffs or sacrifices users have to make, but this does not seem to be the case with Petite-Vue. We talk about Alpine, how Petite-Vue is different, and we also get stuck into the use cases for Petite-Vue. Dave shares one of his totally wild ideas, which, naturally, Alex is all over. Our wide-ranging conversation also touches on interviews and what needs to change with them, templates and styles, and as usual, we wrap up with everyone's picks for the week. Tune in to hear it all! Key Points From This Episode: Get to know today's guest, Dave Rupert. Everyone's take on how they would feel if Vue was five kilobytes. The story of how Petite-Vue came to be released. Dave's experience of using Alpine and some of the challenges he had with this. What the jump from Vue to Petite-Vue is like. Hear about the idea that Dave runs past Alex. Some other great use cases for Petite-Vue. Unpacking the broken coding interview system; things need to change. Questioning some obscure hiring requirements. The framework Dave uses given that he works in an agency. In business, frameworks can become politicized and sites for contention. Things other people do that make everyone believe they are monsters. Diving into the world of template style and script. Where you can find Dave online to tell him how wrong he is about all his choices. Everyone's picks for this week; there are some great ones! Tweetables: “I think five kilobytes is the perfect stealth technology, like Alex is talking about that you can kind of sneak it into a project and no one's going to go, ‘Hey, hey, hey, what's going on now? I didn't approve this.'” — @davatron5000 (https://twitter.com/davatron5000?lang=en) [0:02:54] “I was kind of a late bloomer I guess for Vue but I just was like, you know, I think the more I've used Vue, the more it has all the features I like.” — @davatron5000 (https://twitter.com/davatron5000?lang=en) [0:37:36] “I'm just saying if you drop the opening curly brace on a four loop, you're a monster.” — @davatron5000 (https://twitter.com/davatron5000?lang=en) [0:47:58] Links Mentioned in Today's Episode: My petite-vue Review (https://daverupert.com/2021/07/petite-vue-review), Dave Rupert Evan You's petite-vue preview (https://twitter.com/youyuxi/status/1410759893359874050), Twitter Angie Jones (https://twitter.com/techgirl1908), Twitter Twitter: davatron5000 (http://twitter.com/davatron5000) Website: daverupert.com (http://daverupert.com) Mini Motorways (https://dinopoloclub.com/games/mini-motorways/), Dinosaur Polo Club (Apple Arcade, Steam) Bubble (https://bookshop.org/books/bubble-9781250245564/9781250245564), Morris, Morgan, Cliff, Riess  Chester's Cheddar Flavored Paws Cheese Flavored Snacks (https://www.kroger.com/p/chester-s-cheddar-flavored-paws-cheese-flavored-snacks/0002840056426) Bat,bat Black Coffee Soda (https://www.batbatsoda.com/shop/black-coffee-soda) Special (https://www.netflix.com/title/80987458), Netflix The Great Ace Attorney Chronicles (https://www.ace-attorney.com/great1-2), Capcom (Nintendo Switch, PlayStation 4, Steam) Special Guest: Dave Rupert.

Syntax - Tasty Web Development Treats
Changelog Frontend Feud

Syntax - Tasty Web Development Treats

Play Episode Listen Later Sep 29, 2021 53:15


In this episode of Syntax, Scott and Wes do a crossover episode with Changelog's JS Party! Your favorite web dev podcasts join forces for a super collab that'll knock you frontend off! Amelia joins Chris Coyier and Dave Rupert from ShopTalk Show, while Divya teams up with Wes Bos and Scott Tolinski from Syntax. Let the FEUDing begin! .TECH Domains - Sponsor .TECH is taking the tech industry by storm. A domain that shows the world what you are all about! If you're looking for a domain name for your startup, portfolio, or your own project like we did with uses.tech, check out .tech Domains. Syntax listeners can snap their .TECH Domains at 80% off on five-year registration by visiting go.tech/syntaxistech and using the coupon code “syntax5”. LogRocket - Sponsor LogRocket lets you replay what users do on your site, helping you reproduce bugs and fix issues faster. It's an exception tracker, a session re-player and a performance monitor. Get 14 days free at logrocket.com/syntax. Mux - Sponsor Mux Video is an API-first platform that makes it easy for any developer to build beautiful video. Powered by data and designed by video experts, your video will work perfectly on every device, every time. Mux Video handles storage, encoding, and delivery so you can focus on building your product. Live streaming is just as easy and Mux will scale with you as you grow, whether you're serving a few dozen streams or a few million. Visit mux.com/syntax. Show Notes 02:49 - Frontend Feud Rules 04:06 - Round 1 10:28 - Round 2 17:26 - Round 3 25:37 - Round 4 35:15 - Round 5 42:03 - Round 6 Links Changelog JS Party Chris Coyier Dave Rupert Wes Bos Scott Tolinski Jerod Santo Amelia Wattenberger Divya The Feud At The Seventh Mountain Amelia's repo visualizer CSS-Tricks freeCodeCamp Wes Bos' courses Changelog Merch Level Up Tutorials Shameless Plugs Scott: All courses - Sign up for the year and save 25%! Wes: All Courses - Use the coupon code ‘Syntax' for $10 off! Tweet us your tasty treats! Scott's Instagram LevelUpTutorials Instagram Wes' Instagram Wes' Twitter Wes' Facebook Scott's Twitter Make sure to include @SyntaxFM in your tweets

ShopTalk » Podcast Feed
481: Frontend Feud: ShopTalk vs Syntax

ShopTalk » Podcast Feed

Play Episode Listen Later Sep 20, 2021 52:14


Crossover! Your favorite web dev podcasts join forces for a super collab that'll knock you frontend off! Amelia joins Chris Coyier and Dave Rupert from ShopTalk Show while Divya teams up with Wes Bos & Scott Tolinski from Syntax. Let the FEUDing begin!

Changelog Master Feed
Frontend Feud: ShopTalk vs Syntax (JS Party #192)

Changelog Master Feed

Play Episode Listen Later Sep 10, 2021 54:10 Transcription Available


Your favorite web dev podcasts join forces for a super collab that'll knock you frontend off! Amelia joins Chris Coyier and Dave Rupert from ShopTalk Show while Divya teams up with Wes Bos & Scott Tolinski from Syntax. Let the FEUDing begin!

JS Party
Frontend Feud: ShopTalk vs Syntax

JS Party

Play Episode Listen Later Sep 10, 2021 54:10 Transcription Available


Your favorite web dev podcasts join forces for a super collab that'll knock you frontend off! Amelia joins Chris Coyier and Dave Rupert from ShopTalk Show while Divya teams up with Wes Bos & Scott Tolinski from Syntax. Let the FEUDing begin!

Remote Ruby
Now We're A Webpacker Podcast

Remote Ruby

Play Episode Listen Later Aug 6, 2021 44:38


[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)

Syntax - Tasty Web Development Treats

In this episode of Syntax, Scott and Wes do a collaboration with Chis Coyier and Dave Rupert from ShopTalk Show! They talk about favorite tech stacks, podcasting, learning new tech, dealing with FOMO, and more! Prismic - Sponsor Prismic is a Headless CMS that makes it easy to build website pages as a set of components. Break pages into sections of components using React, Vue, or whatever you like. Make corresponding Slices in Prismic. Start building pages dynamically in minutes. Get started at prismic.io/syntax. Sentry - Sponsor If you want to know what's happening with your code, track errors and monitor performance with Sentry. Sentry's Application Monitoring platform helps developers see performance issues, fix errors faster, and optimize their code health. Cut your time on error resolution from hours to minutes. It works with any language and integrates with dozens of other services. Syntax listeners new to Sentry can get two months for free by visiting Sentry.io and using the coupon code TASTYTREAT during sign up. Cloudinary - Sponsor Cloudinary is the best way to manage images and videos in the cloud. Edit and transform for any use case, from performance to personalization, using Cloudinary's APIs, SDKs, widgets, and integrations. Show Notes 07:23 - What's your favorite stack right now? 28:52 - What are your thoughts on WordPress? Do you still use it? 33:59 - What do you want for listeners of Syntax? 38:21 - How do you deal with FOMO / the pressure to learn new tech? Links https://shoptalkshow.com/469/ Chris Coyier Dave Rupert Syntax 372: CSS Container Queries, Layers, Scoping and More with Miriam Suzanne https://svelte.dev/ https://kit.svelte.dev/ https://mercurius.dev/ https://www.prisma.io/ https://keystonejs.com/ https://graphql.org/ https://redwoodjs.com/ https://nuxtjs.org/ https://astro.build/ https://vercel.com/ https://wordpress.org/ https://dayoneapp.com/ https://automattic.com/ https://mongoosejs.com/ https://www.blink182.com/ https://newsroom.spotify.com/2021-02-22/a-new-era-for-podcast-advertising/ Chase Reeves YouTube Channel https://xdebug.org/ ××× SIIIIICK ××× PIIIICKS ××× Dave: 1: Haikyu!! 2: Nintendo Garage Chris: Ray App Wes: 1: Connor Ward YouTube Channel 2: Ryan Knorr YouTube Channel Shameless Plugs Scott: All Courses - Sign up for the year and save 25%! Wes: All Courses - Use the coupon code ‘Syntax' for $10 off! Tweet us your tasty treats! Scott's Instagram LevelUpTutorials Instagram Wes' Instagram Wes' Twitter Wes' Facebook Scott's Twitter Make sure to include @SyntaxFM in your tweets

The Dark State
Michael McKevitt: The Legacy of a Republican Hardliner

The Dark State

Play Episode Listen Later May 11, 2021 53:35


This is a feature length episode on the life and crimes of Michael McKevitt, the republican hardliner who is considered to be the founding father of dissident republicanism. McKevitt died on January 2 from cancer. The show examines McKevitt's role in the Provisional IRA, his decision to set up the Real IRA, the 1998 Omagh bombing, and how an MI5 spy called Dave Rupert helped the Irish and British security services to bring him to justice. John Mooney is joined by the journalist and author Michael O'Toole and Tony Hearty, a retired special branch detective who investigated McKevitt.

The Bike Shed
263: Keeping The Night Brain At Bay (Dave Rupert)

The Bike Shed

Play Episode Listen Later Oct 6, 2020 54:00


Steph's taking a quick break this week, but in her absence, Chris is joined by Dave Rupert (https://daverupert.com/). Dave is the lead developer at Paravel, co-host of the Shop Talk Show podcast, creator of The Accessibility Project, and an all-around prolific and thoughtful maker of digital things. Chris and Dave chat about creating and sharing content like podcasts and blogs and how to get past your inner editor. They discuss the web platform and accessibility, and finally, they round out the conversation with a chat about design systems as an intersection between design and development. This episode is brought to you by: Indeed (https://Indeed.com/bikeshed) - Click through and get started with a free seventy five dollar credit for your first job post Datadog (http://datadog.com/thebikeshed). Click through to get a free 14-day trial and a free Datadog t-shirt! ScoutAPM (https://scoutapm.com/bikeshed) - Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy Dave on Twitter (https://twitter.com/davatron5000) Dave's site / blog (https://daverupert.com/) Paravel (https://paravelinc.com/) The Accessibility Project (https://www.a11yproject.com/) Shop Talk Show Podcast (https://shoptalkshow.com/) How to Start a Podcast (https://daverupert.com/2020/01/how-to-start-a-podcast/) The Good Path (on Blogging) (https://daverupert.com/2018/11/the-good-path/) Jeremy Kieth (https://adactio.com/) Jekyll (https://jekyllrb.com/) static site generator What is the Value of Browser Diversity? (https://daverupert.com/2020/09/the-value-of-browser-diversity/) The WebAIM Million Project (https://webaim.org/projects/million/) Web Content Accessibility Guidelines (WCAG) (https://www.w3.org/WAI/standards-guidelines/wcag/) Accessible Rich Internet Applications (ARIA) (https://www.w3.org/WAI/standards-guidelines/aria/) The Accessibility Project Checklist (https://www.a11yproject.com/checklist/) Scott Hanselman (https://www.hanselman.com/) The Hanselminutes Podcast (https://hanselminutes.com/) Five Key Milestones in the Life of a Design System (https://daverupert.com/2020/05/5-design-system-milestones/) Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed!

The Web Platform Podcast
197: Modern HTML

The Web Platform Podcast

Play Episode Listen Later Mar 25, 2020 60:43


Dave Rupert, podcaster and web developer, talks with us about modern HTML practices. In a world full of JavaScript where does HTML & CSS fit in? What are the roles of Web Components and web standards? Visit the website for This Week in Web, resources & more: https://thewebplatformpodcast.com/197-modern-html   Follow The Web Platform podcast on Twitter for regular updates @TheWebPlatform.

That's my JAMstack
Sam Julien on authentication, Gatsby and the serverless methodology

That's my JAMstack

Play Episode Listen Later Jan 7, 2020


Quick show notes Our Guest: Sam Julien What he'd like for you to see: Auth0 Community Forum | His Gatsby Course on Thinkster | Get a Job in Tech His JAMstack Jams: The methodology and not needing to stand up a server for every little thing His Musical Jam: "Not" by Big Thief Other Technology Mentioned Gatsby Jekyll NextJS AirTable Twilio Our sponsor this week: TakeShape Transcript Bryan Robinson 0:02 Hello, everyone, and welcome to the first real episode of 2020 you're listening to That's My JAMstack, the podcast where we dare to ask the question, what is your jam in the JAMstack. I'm your host, Bryan Robinson. And today on the show, we have a speaker, author, teacher, a developer relations engineer at Auth0, Sam Julien. Bryan Robinson 0:24 I'm also pleased to welcome back to the show are sponsored TakeShape, find out more about their content platform after the episode or head over to takeshape.io/thatsmyjamstack for more information. Bryan Robinson 0:39 All right, Sam, thanks for joining us on the podcast today. Sam Julien 0:41 Yeah, thanks. I'm really happy to be here. Bryan Robinson 0:43 Cool. So tell us a little bit about yourself. What do you do for work? What do you do for fun? That sort of thing? Sam Julien 0:47 Yeah. So I am a Developer Advocate engineer at Auth0, which is just sort of a fancy word for Developer Relations. And so basically, spend my time I'm doing a lot of interacting with developers who use Auth0 the product and then kind of taking that feedback back to the different teams. Sam Julien 1:11 And so I, I do a lot of speaking at events and things like that and working on basically combining x technology with Auth0 and trying to find the problems with it. Sam Julien 1:22 And then for fun, I actually live in a rural area of the Pacific Northwest. I live on 10 acres of land with my partner. And then we have some friends who also are in the own the land with us, and so they come up on weekends and stuff. And so we have, we have 20 chickens that we raise, and we're getting some eggs from and yeah, and so ever since moving on to this land that's sort of taken over as my hobby. I feel like I was a lot more interesting when I lived in Portland as far as like hobbies and activities but that's aside from taking care of the property.I see you have a Breath of the Wild artwork on your wall. And that's basically my current hobby is playing Breath of the Wild. Bryan Robinson 2:13 You could think almost a lifetime into that. So that'd be fine. Sam Julien 2:15 Yeah, it's pretty crazy. I don't know if I'm gonna go ... So we only got a Switch a few months ago. And I don't know if I'm going to go for completion on it. But Amy is definitely. She's already I think she's already got like, 105 shrines or something. And she's, she's going for 100%. Bryan Robinson 2:36 You could spend a long time going for 100%. So you eat a lot of the eggs that you get fresh from the chickens? Sam Julien 2:43 Well, we we just actually just started laying. Like a week ago, actually, we got them when they were chicks. And so I think we've almost got a dozen at this point. So we're probably going to start eating them pretty soon. There first ones are always kind of duds because they're like trying to figure it out and not fully formed. And so but I think we're just about there to start eating them. Bryan Robinson 3:10 All right. Well, this is this is neither a chicken podcast nor a gaming podcast. Let's let's talk about the JAMstack a little bit, right.Unknown Speaker 3:17 Yeah, I suppose we should talk about the JAMstack. Bryan Robinson 3:20 So what was kind of your entry point into this idea whether there was static sites back in the day, JAMstack nowadays? What's your what's your entry point? Sam Julien 3:28 Well, I mean, aside from, you know, the, the, the real static site being like, index.html and everything. Aside from that, I would say my introduction to the JAMstack was through Gatsby, and my introduction to Gatsby was just through, umm... So before I was in Developer Relations at Auth0, I was on the content team. So I was writing tutorials and stuff and we sort of went through this process. The blog at Auth0 is in Jekyll, and there's sort of this ongoing debate internally of whether to migrate to Gatsby or not. And I don't, I don't know if they're going to end up doing it or not. Because you know how it is with wanting to rewrite a platform. It's like, it's like, is this a good idea? Like, legacy code is still, it still works. So. But uh, so anyway, so that's so some colleagues on that team, were telling me about Gatsby. Sam Julien 4:24 And so I started looking into it. And I kind of just like instantly fell in love with it and started messing around with it and building stuff with it and looking at everybody else's blogs and portfolios that they were making with it. And it just really like scratch the itch for me of both being a developer and a writer, and I just really liked it. So then that kind of led down the path of the rest of the jam stack and all that. I guess Bryan Robinson 4:51 So, when you got into Gatsby, had you done a lot of react previously or was that new too? Sam Julien 4:56 It was actually kind of my way into React. Because I, I'm historically an Angular developer, like I came from C# and then like C# and Angular kind of go really well together. And so I've done I had done a bunch of Angular over the last few years. And then, but Auth0 basically uses React almost exclusively internally. And so I was, it was already sort of on my list of things to learn. But Gatsby was sort of a nice, like way into react because it handled all the tooling and everything, since it's just, it's basically just a supercharged create react app. And so it sort of gave me this nice platform to just dig into react, while not having to kind of worry about the all the tooling involved. Bryan Robinson 5:50 it's also got, I think, I think, a pretty strong set of opinions to which helps kind of guide on best practices. Sam Julien 5:56 Right, exactly. And an Angular like, angular has A ton of strong opinions. And so that's sort of what I was used to. I mean, it's sort of there's pros and cons to both approach both approaches. But I think when I was first starting to learn react when I joined Auth0, I was a little like dizzy by just how many different ways you can slice and dice react. And so Gatsby really did kind of help just kind of narrow the focus of like, here's like, a set of tools, like a ready made thing for you now just write some react and and figure it out, you know. Bryan Robinson 6:31 So, how are you using the JAMstack professionally? I mean, I know you said that they're debating coming to Gatsby and they are on Jekyll. But you're not on that content team anymore. Are you doing some JAMstack type things and your developer relations that Auth0? Sam Julien 6:46 Yeah, so I I, I'm sort of doing both stuff personally and professionally with it from the professional side at off zero. It's mostly I've been really kind of digging into What authentication looks like in the jam stack because it's kind of an interesting. It's an it's an interesting, new problem set, because it's sometimes it's more like a traditional web app. And sometimes it's more like just a single page application. And sometimes you have these serverless models that you have to authenticate and stuff like that. Sam Julien 7:23 So so I'm sort of in this research phase right now if like trying to build different prototypes with Gatsby or Next or you know, things like that and wrap my head around what the problem set looks like of like, when is it more like a traditional web app? When is it more like a spa? When is there sort of this in between weird case of serverless stuff and all that and so that's sort of what I'm doing now is is figuring out how Azzurro fits in with jam stack stuff and how we can make it easy for developers and that kind of thing. And then from the on the personal side of things, I'm using Gatsby to build, build, I'm rebuilding, I am rebuilding my own personal site with Gatsby, which is I still am not convinced it's a great idea, but I'm going to do it anyway. And, and, and then I built I loved Gatsby so much, but I, I couldn't find exactly like the way of teaching it that that I liked. And so I built a course for a platform called things through.io on Gatsby just sort of like getting started with Gatsby. And so that's minute sort of another side project endeavors this, this course and different content, I ended up doing a couple egghead lessons on some Gatsby stuff. And so that's sort of my Gatsby sort of fueling my side hustle as well as my day job right now. Bryan Robinson 8:57 Cool. So uh, so what is kind of the thing that brings you to the JAMstack in terms of what do you love about it? What's your what's your jam in the JAMstack? Sam Julien 9:07 I really think this whole concept of not needing to pair a server with a front end is really nice. I just think that nowadays there there are so many different like SaaS products and like serverless products and things like that, that like, it seems like for a lot of cases other than complex enterprise stuff. You don't really need to spend a lot of time messing with building your own server and all of that, you know, it's just like, if you're just doing if you're pulling in data from outside, you know, like Twilio or wherever, you know, or AirTable or things like that. Sam Julien 9:53 Or if you're just making like a recently, a lot of developer relations as you know as building a lot of sample apps. And so recently I've been thinking I would always build like a little Express server to serve up data and stuff like that. And now I'm sort of like there's not really any point, I could just put this in a serverless function and reuse the same thing over and over again, and I don't really need it. So I'm really liking that, that the JAMstack has sort of opened up, like it's making so much stuff easier for a large a large percentage of apps that people need to build, you know what I mean? Bryan Robinson 10:31 Yeah, and so so you come from like a C# background so you're obviously not afraid of server side languages. I myself, deathly afraid serverside languages, so kind of, do you have a point where you would go and spin up your own server now or are you going to just be going in this serverless way going forward? Sam Julien 10:49 Well, I mean, I can see so like my my previous jobs were at like in doing like line of business applications for like bigger companies. One was like a finance company one was like a renewable energy nonprofit. So there, those places have a lot of complex business logic that has to happen, you know, with a bunch of data in a database where you have to manipulate and run a bunch of business rules and stuff like that. And to me that, that seems like kind of the obvious use case for like a real server where you actually, like, have a lot of stuff that has to interact with the database and, you know, sort of the more traditional route of, of servers and databases and all that. And so, but I think for a lot of modern stuff that's not enterprise level, the serverless JAMstack stuff works pretty well, you know, and especially with having node I mean, you can sort of just use JavaScript all the time and it's just things are just so much easier. It's It's really nice. Bryan Robinson 11:54 Front End Dev and designer like me, like it just makes my life so much more pleasant Sam Julien 12:00 Yeah, for sure. Definitely. Bryan Robinson 12:02 So so the kind of the whole methodology of that is is where where you're going with your jam, right? Sam Julien 12:07 Yeah, yeah. Basically the whole philosophy. Bryan Robinson 12:10 Yeah. So. So in terms of serverless and all that, right, so you said you started exploring authentication in this world for all zero. How's that going? Because I'll be honest, I haven't done a whole lot of research into it yet. Sam Julien 12:24 It's interesting. And one thing we can link to is one of our architects named Sandrino wrote this really cool article on NextJS and Auth0, but I mean, it's with Auth0, but it also anytime we write about Auth0, we try to also have things that are basically broad, more broad for authentication in general. But we're sort of figuring out that there's these like I said, sort of three different models basically, of like, sometimes it's more like a traditional web app because you're basically, if you're if you're doing everything server side, then it's sort of more like a traditional web app, right? Because you're, you're not really running anything in the browser. I mean, you're running it in the browser, but you're not. There's nothing dynamic happening in the browser. And so you would kind of go with the standard, standard web app approach. Sam Julien 13:21 And then there's things like Gatsby are sort of like Gatsby is interesting, because it's, it got its start as like a static site generator, but it's never actually like, holy a static site, right? Because it's still react, running, you know, like as a spa. And so that sort of this weird case where it's like, it's kind of a static site, but really, you would authenticate it just like you would a spa, pretty much. But then there's this like Next has this whole thing with the serverless deployment model. And from there, you sort of have to determine like where I need The authenticated data like do I need it when the page first renders? Or do I need it later? and Sandrino, you know, has some nice diagrams in that article that will do a better job of explaining it than I can in audio. Bryan Robinson 14:14 Lovely Mouth Blogging as Dave Rupert would say Sam Julien 14:16 Yeah, yeah. Yeah. So that stuff's really interesting. And I'm still sort of wrapping my head around at all and building out sample apps and stuff like that. But but it's, it's interesting. And it's definitely as the JAMstack continues to be as popular as it is more and more people will need to understand how to protect all their data and everything. Bryan Robinson 14:39 And Auth is probably the one of the biggest challenges to like adoption in the JAMstack right now to like, how do I protect pages when it's just static? Sam Julien 14:47 Yeah, yeah. Yeah. Our architecture and content and developer relations at Auth0 have all been sort of mulling this over for a little while, because I think actually, for this article, Sandrino was talking to people outside and stuff because it's sort of like how do we want to do this? You know, like, what are the best practices here? Bryan Robinson 15:08 Let's create some standards for it and kind of go Sam Julien 15:12 Yeah, exactly. Bryan Robinson 15:15 So let's let's talk musical jam now what are you listening to? what's what's your favorite song or musician or genre? Sam Julien 15:23 I finally I have a great answer for this now and it's because So have you ever heard of the band Big Thief I have made so they on their last on their most recent album, their their single is called Not. And it's got it's like one of the my, like, favorite songs that I've heard in several years. Like there's something very emotional about it. That is just really awesome. And it's nice because I yeah, I just haven't I haven't felt that kind of like connection to a song. In a really long time so I've been I've been playing that a lot not by big thief. Sam Julien 16:06 Let's see what else what else have I been? I feel like as I get older I have less and less like emotional connection to things because I'm not young and nostagic anymore but let's see what am I've been listening to you other than that. I like Tool's new album a lot. I liked Angel Olsen's most recent album, I'm a really big Angel Olsen fan. She's sort of like the singer songwriter type, but her album couple years ago, called What was it called My Woman in 2016. That was a fantastic album, if you haven't listened to it. Bryan Robinson 16:46 That's actually my favorite thing on the podcast other than learning about new technology is learning about all these like drastically different musical tastes and going and listening to what what everyone says. Sam Julien 16:53 I love that. I think that's a really great when I saw that question in the invite. I was like, Oh, that's cool. That's Great I like that. I'd be curious, what's what's your current jam right now? What are you listening? Bryan Robinson 17:05 You turn the tables on me! Sam Julien 17:06 I'm turning the tables Bryan Robinson 17:07 First time! You know, I just I'm behind the times always like that perpetually. But I just this past summer went and saw Hamilton, the touring company came around, and I didn't think I was going to... Like, I thought I would like it; like musical theater well enough, but like, I am in love with it. And it gets me going in the mornings like it really pumps me up. And then I go and research all the founding fathers and realize how horrible they were. But it it gets me going at least. Sam Julien 17:36 Yeah, now, Hamilton; Amy was really into Hamilton. And so I kind of I'm like neutral towards musical theater. Like, I don't I don't dislike it. I don't you know, but Amy was really into it. And so when it came to Portland, I got us tickets and we went, and I'll admit, like, I loved it. I thought it was like it was not overrated at all like I kind of went into it expecting it to be a little overrated because it's so popular, but like, I thought it was fantastic. Bryan Robinson 18:07 There's a reason it won all those awards. Sam Julien 18:08 Yeah, I mean, some some things are hyped up because they're actually that great, you know, like, like Beyonce. Bryan Robinson 18:17 Yeah, exactly. I found that running to it actually works really well, too. So I'm trying to get into running and that has just the right beat for how bad I am at running. SoUnknown Speaker 18:26 Oh, yeah. Yeah, that's great. I am. I really I had seen In the Heights A long time ago. And so I already liked Lin-Manuel Miranda. But yeah, it's, it's a great yeah. If you ever have a chance, I don't know if In the Heights is still playing anywhere, but if you ever have a chance to see it, it's a really good one. Bryan Robinson 18:46 I didn't even know he had written anything before that. And I researched what he had done was like, Oh, you've done this before. Okay. Sam Julien 18:51 Yeah, yeah, he's Yeah, he's super talented. But that one is about like Washington Heights in New York and stuff like that. It's really great. Bryan Robinson 19:00 For someone indifferent towards towards musical theater you you've got at least that much now. Sam Julien 19:05 Yeah, that's true. I I kind of Yeah, I would say. Other than that though I'm I tend to be pretty neutral about about theater, I could take it or leave it. I respect it. And I respect that other people love it. It's just not it's just not my thing. Not my jam... Bryan Robinson 19:24 All right. And so let me let me ask, Is there anything that you would like to promote? Get out to the JAMstack community? Anything that you're doing that you won't get out there? Sam Julien 19:30 Yeah, I'll say on the on the professional side. Yeah, just keep an eye on Auth0 for JAMstack stuff because we're actively working on it. And, and if people have like input or things they want to talk about, we have a great community forum. So if you're running into authentication problems in JAMstack stuff, like definitely let us know because we're always kind of putting our ear to the ground and trying to figure out what problems people are having. So we can Try to solve them. Sam Julien 20:02 And then personally Yeah, the the Gatsby course on Thinkster. I'm really proud of it. I think it's a good course. And so that would be good. I'm also I just started, I'm starting this new project called Get a Job in Tech. I'm a self taught developer, I transitioned from finance. And I was lucky because I had some mentors that sort of shepherded me along the way, and not everybody has that. And so I'm starting this new, it's still really early, but basically, I plan on I'm already like, right, sending out emails and stuff and writing content for it, but it's basically to help people with the like, meta skills of getting your first job because I feel like a lot of people think, you know, they learned they learned some stuff on like, Free Code Camp or any any other great site on learning to code and then they sort of get stuck because they're like, okay, where's like, how do I actually get the Job, and you just sort of throw your resume up on a lot of places. And then you get these rejection letters that are like, you don't have any experience and you're like, no duh don't have any. Bryan Robinson 21:10 It's a Junior position, come on!Unknown Speaker 21:12 Yeah, like literally, like, that's what it is like. And so there's all these skills of like, like learning in public with GitHub and stuff like that, that like, not many people really teach you, you know, like, there's sort of an art to getting or getting a job and that kind of thing. So that I've been really thinking about that lately. And so I started that up as a sort of a labor of love. And where's that it's get a job in dot tech, basically, I'll, I'll paste in the link. Yeah. And then and then basically, everything I do is tracked at SamJulien.com so you can always go there and I have an occasional email list and stuff like that. So if you ever want to keep up with talks I'm doing or lessons I'm publishing on egghead or thinkest or anything like that. Bryan Robinson 22:00 Perfect. Yeah. Awesome. Well, thanks for taking the time to talk with us today and share your insights. And I hope that you keep doing awesome stuff at all zero and that your chickens eggs are delicious.Unknown Speaker 22:09 Thanks. Yeah. Thanks for having me. I really appreciate it. Bryan Robinson 22:12 Yeah, no problem. All right. Well take care. Bryan Robinson 22:18 All right, it is sponsored time, I want to take a second and thank this week's sponsor TakeShape. TakeShape calls, their offering a content platform. And that's, that's really the best description. They have a handy CMS, a static site generator, and a simple GraphQL API all ready to use on the JAMstack. Bryan Robinson 22:35 Beyond all that they also have new features coming in all the time, like their new Mesh product that allows you to mix and match data from multiple sources into one neat GraphQL interface. If all that sounds interesting, you be sure to go to takeshape.io/thatsmyjamstack to find out more. Bryan Robinson 22:53 And as always, I want to thank the JAMstack community for listening for responding on Twitter for talking about things in communities. Just for being an amazing place to work and to play and to spend my time. So if you like this podcast let me know by hitting the like, subscribe, all those good things and whatever podcast app you use, and until next week, keep doing amazing things and keep things jamming.Transcribed by https://otter.aiIntro/outtro music by bensound.comSupport That's my JAMstack by donating to their Tip Jar: https://tips.pinecast.com/jar/thats-my-jamstack

Thunder Nerds
234 –

Thunder Nerds

Play Episode Listen Later Oct 12, 2019 68:37


In this episode, we get to talk with Developer and Podcaster, Dave Rupert. We chat with Dave about his blog...

The Live Drop
Dave Rupert American Trucker, Traveler, and British Spy Who Brought Down the Real IRA

The Live Drop

Play Episode Listen Later Jul 3, 2019 58:33


A trucker from upstate New York, David Rupert spent seven years informing for the FBI and MI5 while working his way as high as the IRA war council. His lengthy testimony brought justice to several key players in the supply and terrorism networks of the Troubles, including Real IRA leader Mickey McKevitt who'd had a significant role in the Armagh bombing which killed 31 civilians and injured hundreds shortly after the Good Friday Peace Agreement in 1998. Rupert learned his spycraft as he went along, with no prior instruction, only taking occasional counsel from his MI5 handlers and his own instincts from a career in the rough and tenebrous world of interstate trucking. Although he provided a trove of information for the FBI and British Intelligence, Rupert had never agreed to testify against those he'd worked with daily in the IRA. But a PBS documentary about the consequences of the Omagh Bombing convinced him he had to take the stand, which we'll find out wasn't as easy as it sounds. An engaging and congenial Rupert shares his perceptions of the Irish on their northern border from his arrival with his wife and collaborator Maureen, to his testimony deep in the Republic of Ireland, where loyalties are often at odds with personal identity, and safety. Find out more about him in Sean O'Driscoll's book 'The Accidental Spy.' http://www.thelivedrop.comIf you've enjoyed this episode and would like to hear more, please consider signing up as a contributing patron and join the community for exclusive commentary, and content.  A $10 a month donation will really keep us going ---> https://www.patreon.com/thelivedropAlternatively, if you would like to help make Season Three operational you could offer a one time donation of any amount right here ---> https://www.paypal.me/thelivedropThank you for listening and your support,Mark Valleycreator/host Get bonus content on Patreon Our GDPR privacy policy was updated on August 8, 2022. Visit acast.com/privacy for more information.

Model View Conversation
Episode 18: Ways to Learn, Part I

Model View Conversation

Play Episode Listen Later May 13, 2019 46:30


Ben and Brian discuss many different ways you can get started and learn about programming. So many ways in fact, we had to break it up into two parts! In this one we talk about books, onine tutorials, and podcasts. If none of those work for you, fear not as we tackle several more learning methods in part II. Stay tuned for that. Follow us on Twitter @mvcpodcast (https://www.twitter.com/mvcpodcast). Chapters 00:00 - Intro 01:17 - Ways to learn: books 21:01 - Online Tutorials 30:54 - Pro tip: contribute to open source 34:58 - Podcasts as a learning tool 45:45 - Outro Links Books The Pragmatic Programmer (https://pragprog.com/book/tpp20/the-pragmatic-programmer-20th-anniversary-edition) by David Thomas, Andrew Hunt Don't Make Me Think (http://www.sensible.com/dmmt.html) by Steve Krug HTML & CSS: Design and Build Websites (http://www.htmlandcssbook.com) by Jon Duckett Apple Human Interface Guidelines (https://developer.apple.com/design/human-interface-guidelines/ios/overview/themes/) The C Programming Language (https://www.amazon.com/exec/obidos/ASIN/0131103628/lynnallain) by Brian Kernighan, Dennis Ritchie The Structure and Interpretation of Computer Programs (https://www.amazon.com/Structure-Interpretation-Computer-Programs-Engineering/dp/0262510871) by Harold Abelson, Gerald Jay Sussman, Julie Sussman The Non-Designer's Design Book (https://www.amazon.com/Non-Designers-Design-Book-4th/dp/0133966151/ref=sr_1_1) by Robin Williams Podcasts Syntax (https://syntax.fm) with Wes Bos and Scott Tolinski DevChat (https://devchat.tv) Podcast Network Under the Radar (https://www.relay.fm/radar) with Marco Arment and David Smith Accidental Tech Podcast (https://atp.fm) with Marco Arment, John Siracusa, and Casey Liss Full Stack Radio (http://www.fullstackradio.com) with Adam Wathan Shop Talk Show (https://shoptalkshow.com) with Dave Rupert and Chris Coyier The Art of Product (https://artofproductpodcast.com) with Ben Orenstein and Derrick Reimer

The Strong Web
Dave Rupert - Creator Series Part 3

The Strong Web

Play Episode Listen Later Feb 21, 2019 53:52


This is the third installation of my Creators Series where I interview web professionals who consistently create content for the web. I sat down one early Monday morning to chat with Dave Rupert about life in Austin and at his company, Paravel. Dave is also the co-host of the Shop Talk Show podcast which has been around for 8 years now. Dave is about as genuine as they come and it really shows in this interview. One of the most interesting things we talk about is open source projects. He details a few examples of how they can really be a time commitment. I also really enjoyed his take on learning web programming plus the trajectory of his company and the type of clients they get (which are incredible). Jeff Bezos 2 Pizza Rule Paravel Dave's personal website Shop Talk Show Fit Text Fit Vids

Show Me Your Mic
Can Podcasting Go Windows? - Dave Rupert

Show Me Your Mic

Play Episode Listen Later Dec 7, 2018


Dave Rupert stop by the show to talk about ShopTalk Show, Aside Quest, and figuring out the format for your podcast and sticking to it.

Goodstuff Master Audio Feed
Show Me Your Mic 123: Can Podcasting Go Windows? - Dave Rupert

Goodstuff Master Audio Feed

Play Episode Listen Later Dec 7, 2018


Dave Rupert stop by the show to talk about ShopTalk Show, Aside Quest, and figuring out the format for your podcast and sticking to it.

podcasting windows dave rupert shoptalk show show me your mic
Show Me Your Mic
Can Podcasting Go Windows? - Dave Rupert

Show Me Your Mic

Play Episode Listen Later Dec 7, 2018


Dave Rupert stop by the show to talk about ShopTalk Show, Aside Quest, and figuring out the format for your podcast and sticking to it.

Views on Vue
VoV 023: Unit Testing Vue components‌ with Edd Yerburgh

Views on Vue

Play Episode Listen Later Aug 7, 2018 87:01


Panel: Divya Sasidharan Chris Fritz Joe Eames Special Guests: Edd Yerburgh In this episode, the Views on Vue panel talks to Edd Yerburgh about unit testing Vue components. Edd is a software engineer for BBC in London and he maintains Vue Test Utils, which is a library to help make unit testing Vue components easier.  They talk about how you would use Vue Test Utils, examples of components you would test with Vue Test Utils, and good patterns to use when testing. They also touch on snapshot testing, the Vue Jest library, and more! In particular, we dive pretty deep on: Edd intro Maintains Vue Test Utils What is Vue Test Utils? Library to make unit testing Vue components easier What is a mounted component? Would you use Vue Test Utils by yourself? Jest, Jasmine, and Mocha Needs to be run in a DOM environment JS DOM Examples of components that you would use to test with Vue Test Utils What are good patterns to use when testing? Consider what and if you should test? Difficult to give a definitive answer as to when you should unit test vs you shouldn’t What you hope when you are writing unit tests Tests as a form of documentation Writing unit tests to pay off in the future What is a Snapshot test? When would you use a snapshot test? Leaning on Jest for snapshot tests Vue Jest library Testing in Vue Creating components within your test itself Testing a mixin And much, much more! Links: Vue Vue Test Utils Jest Jasmine Mocha Snapshot test Vue Jest Edd’s GitHub @EddYerburgh eddyerburgh.me Edd’s Medium Sponsors Kendo UI Digital Ocean FreshBooks Picks: Divya The React is “just” JavaScript Myth by Dave Rupert Bang Bang Con Moving Towards Dialogue: Collaborating with your computer using typed holes! by Vaibhav Sagar Chris Having a point to stop working at night ASMR Joe Rocketbook VS Code Top-Ten Pro Tips Edd Testing Vue.js Applications by Edd jscodeshift

Devchat.tv Master Feed
VoV 023: Unit Testing Vue components‌ with Edd Yerburgh

Devchat.tv Master Feed

Play Episode Listen Later Aug 7, 2018 87:01


Panel: Divya Sasidharan Chris Fritz Joe Eames Special Guests: Edd Yerburgh In this episode, the Views on Vue panel talks to Edd Yerburgh about unit testing Vue components. Edd is a software engineer for BBC in London and he maintains Vue Test Utils, which is a library to help make unit testing Vue components easier.  They talk about how you would use Vue Test Utils, examples of components you would test with Vue Test Utils, and good patterns to use when testing. They also touch on snapshot testing, the Vue Jest library, and more! In particular, we dive pretty deep on: Edd intro Maintains Vue Test Utils What is Vue Test Utils? Library to make unit testing Vue components easier What is a mounted component? Would you use Vue Test Utils by yourself? Jest, Jasmine, and Mocha Needs to be run in a DOM environment JS DOM Examples of components that you would use to test with Vue Test Utils What are good patterns to use when testing? Consider what and if you should test? Difficult to give a definitive answer as to when you should unit test vs you shouldn’t What you hope when you are writing unit tests Tests as a form of documentation Writing unit tests to pay off in the future What is a Snapshot test? When would you use a snapshot test? Leaning on Jest for snapshot tests Vue Jest library Testing in Vue Creating components within your test itself Testing a mixin And much, much more! Links: Vue Vue Test Utils Jest Jasmine Mocha Snapshot test Vue Jest Edd’s GitHub @EddYerburgh eddyerburgh.me Edd’s Medium Sponsors Kendo UI Digital Ocean FreshBooks Picks: Divya The React is “just” JavaScript Myth by Dave Rupert Bang Bang Con Moving Towards Dialogue: Collaborating with your computer using typed holes! by Vaibhav Sagar Chris Having a point to stop working at night ASMR Joe Rocketbook VS Code Top-Ten Pro Tips Edd Testing Vue.js Applications by Edd jscodeshift

Daily(ish)
An Introduction to Overwatch with Special Guest Dave Rupert

Daily(ish)

Play Episode Listen Later Dec 19, 2017


Dave Rupert joins me to discuss the fun of Overwatch and give some tips for anyone thinking of starting out on their Overwatch journey. (⚠️ This one goes a bit longer than the usual 10m Daily(ish) episode.)

Daily(ish)
An Introduction to Overwatch with Special Guest Dave Rupert

Daily(ish)

Play Episode Listen Later Dec 19, 2017


Dave Rupert joins me to discuss the fun of Overwatch and give some tips for anyone thinking of starting out on their Overwatch journey. (⚠️ This one goes a bit longer than the usual 10m Daily(ish) episode.)

Goodstuff Master Audio Feed
Daily(ish) 229: An Introduction to Overwatch with Special Guest Dave Rupert

Goodstuff Master Audio Feed

Play Episode Listen Later Dec 19, 2017


Dave Rupert joins me to discuss the fun of Overwatch and give some tips for anyone thinking of starting out on their Overwatch journey. (⚠️ This one goes a *bit* longer than the usual 10m Daily(ish) episode.)

The Frontside Podcast
072: Single Page Apps with Accessibility in Mind with Kris Van Houten

The Frontside Podcast

Play Episode Listen Later Jun 8, 2017 33:57


Kris Van Houten: @krivaten | krivaten.com | Q2 Show Notes: 00:55 - Kris' Interest and Passion for Accessibility 06:07 - Using Ember for Accessibility: Pattern Adoption 10:13 - Context Switch Awareness and Managing Focus 12:08 - Asynchrony and Desired Interaction 14:04 - Building a Form Input Component 19:05 - Things That Are Hard to Catch 22:41 - Assistive Browsers? 28:17 - Making Things Accessible From the Start Resources: Building for Accessibility by Nathan Hammond @ Wicked Good Ember 2015 The A11y Project: Web Accessibility Checklist WCAG 2.0 checklists Why Don't Screen Readers Always Read What's on the Screen? Part 1: Punctuation and Typographic Symbols Mozilla Accessibility Kris' Blog Post Series on Accessibility: Part 1: What is accessibility and why should we care? Part 2: A Primer on Accessibility Part 3: Getting Our Apps Ready for Accessibility Part 4: Building an Accessible Icon Component in Ember Part 5: Building an Accessible Input Component in Ember Part 6: Building an Accessible Alert Component in Ember Part 7: Building an Accessible Numbers Component in Ember Part 8: Building an Accessible Currency Component in Ember Transcript: CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode 72. My name is Charles Lowell, a developer here at The Frontside and podcast host-in-training. With me today is Wil. WIL: Hello. CHARLES: Hey, Wil. Today, we're going to be talking about accessibility in single page applications with Kris Van Houten who is a developer at Q2. Hey, Kris. Thank you for coming on the show. Today, we're going to talk about something that I know a lot of people's minds here and probably elsewhere on the internet, it's a topic that's getting a lot more attention, which is a good thing and that's accessibility. We're going to explore the niche of accessibility as it applies to single page applications. Now, you're a frontend developer at Q2, what initially got you interested in and passionate about accessibility in general? KRIS: I honestly feel my path to passion in this area has been a little bit unorthodox in a number of ways. I basically started out in total apathy of this topic and over the last year, it has turned into a genuine interest of mine. About three years ago, I remember listening to an episode of ShopTalk Show with Dave Rupert and Chris Coyier and they kind of went on this large rant about accessibility and why more developers need to be concerned and compassion about it. Dave Rupert was talking about his contributions to the accessibility project and I'm sitting back and thinking to myself and this is back then, obviously, "Why would anyone who is blind want to use anything that I'm working on." I basically balked at the idea and disregarded it entirely. At that time, I was just getting my feet wet with Ember working on an application with a company here in Cincinnati and we had these conversations about, "I notice that we put this action or a clickable event on a div element, should we not be doing that? Is it that not something that we should be doing?" I remember sitting back and having this conversation and saying, "The ads been crawled by SEO and Ember isn't yelling at us for doing it. It still works fine so what the heck? Let's just go with it." Basically, every single app that come into since then has basically adopted that same mindset even before I joined the team so I know it's not just me who is thinking this. A lot of developers that have been exercising the same way of doing their code. CHARLES: Right, it's the path of least resistance. Everybody's got a job to do. Everybody's got features to deliver so that practice can be very easily self-perpetuating, right? KRIS: Exactly and I think a lot of developers just don't understand the semantic difference between a div or a label or a button or a link and how browsers can actually treat these difference HTML attributes or HTML tags differently because of how assistive technology can utilize them for per person's benefit. That's where I was a little over a year ago basically. When I first started at Q2, that first week, I got pulled into a discussion about design patterns which is another passion of mine and somehow, that turned into me joining a group that was to establish to figure out how to tackle the task of making our large app accessible. Basically, we had a company come in, audit our application and we got a big fat F for accessibility so it's something that we said, "We need to start tackling this problem." Being that, I just started at the company that week, I was going to tell them no but internally, I was panicking and saying, "I got to figure out what is this whole accessibility thing is and why it's important." I started looking for books, articles on the topic and trying to basically flood myself with information. Two things that really transformed my way of thinking was actually a talk given by Nathan Hammond at that Wicked Good Ember in 2015, where he shows an example of building an application without accessibility in mind so basically, doing what I was doing before which is we're adding actions to div tags, we're not really caring about semantic HTML, we're just making the feature or the application work. But then what he does, which I think is super powerful is he pulled up a colleague of his who is blind and had him try to use the application. He just goes through and you can see the struggle and he's actually vocalizing and talking about where he's [inaudible] with this application. Long story short, Nathan comes back up and makes a few adjustments. DHTML has [inaudible] up again and it's night and day difference just by changing the markup and by dropping in the Ember A11y add-on which helps with focusing the browser in certain areas of the content. He's able to totally transform how's individuals able to use the app. For me, that was a super powerful to come in and see that and see someone actually struggle with a website that they were trying to use. I think, [inaudible] where I always saw accessibility was it will only affects people who can't see and I think that's the other area where I've really started to have that paradigm shift was when I realized that this isn't just people who can't see. It's for people who have motor difficulties, who can't use a mouse and how to use a keyboard instead. People who have various vision issues, whether that's cataracts, colorblindness, glaucoma, dyslexia, some in these effects, not just DHTML but also affects color contrast, the fonts that we're using that impacts every area of application design and development and that's where I started to realize that that was where the paradigm shift happened in my mind where I started thinking to myself we really need to start talking about this more and getting other developers on board in general on this. CHARLES: It can be intimidating, especially when it feels like on a single page application, your divs have to do more, so to speak in the sense that it feels that your HTML is fatter. It's not just a thin layer but your HTML is actually part of the UI. KRIS: Exactly, yeah. CHARLES: When it comes to having this paradigmatic shift that you're describing, when you're looking at your single page applications, are there any insights into the general structure of the application that you feel like you've gained that are foundational, they kind of transcend accessibility? I guess, what I'm saying is, is there any way that you become like a better developer or been able to recognize foundational patterns because of having these insights surrounding accessibility? KRIS: I've been working with Ember for about three or four years now, basically since it was still in beta. Over the last several years, I have started to accumulate a lot of knowledge as to how we can utilize Ember to do a lot of the heavy lifting for us. When I started getting more passionate about the area of accessibility, first question that came into my mind are how can we use Ember to do some of the heavy lifting for us. For example, some of the things that I had done was go through and start working on developing a couple of components that basically cover a lot of things that I find ourselves doing [inaudible] a lot. Whether that might be a component to just plain icon on a page or a component to display input on a page. What we're able to do is using Ember, we can say, "Here's the icon I want to display but if I don't happen to pass in an aria-label attribute, for example. The component will add the 'aria-hidden=true' for me. Being able to really utilize the power of Ember to do some of that stuff for us on the back side of things, I guess you could say it magically. CHARLES: Let me stop you there for a second and unpack that example. What you're saying is, if I'm going to put an input on the page, if I actually don't assign an ARIA role, it's going to hide it from me? KRIS: No. I was thinking of an icon components, say if I'm using Font Awesome, for example and I want this with the trash icon so I wrote a component for our specific icon library that we're using. We pass in the icon that we want to display, again that could be the trash icon and we can also pass in an aria-label attribute to add a label to that span that will be read to the user. But if we don't pass that attribute in, the component will automatically add the 'aria-hidden=true' attribute for us so basically it skips over it. CHARLES: Yes so it won't be just garbage for a screen reader or someone navigating with a keyboard. WIL: Yeah, otherwise the screen reader tries to read the content of the icon CSS which is just the Unicode. CHARLES: Right. KRIS: Yeah. What we really is trying to figure out and what I've spent a lot of my time, especially in writing my blog series on this was while we are using React or Vue or Angular or Ember or whatever, how can we utilize the power of the single page application frameworks to do some of that heavy lifting for us in the background without us needing to explicitly define everything. I'd say, especially when you work on a large team like what I work on currently, we can't expect everybody to be extremely well-versed in the area of accessibility so if we can do some of the work for them and just encourage them to adopt these components in their daily workflow, it does some of the work for us. That's what we're working on and talking a lot about at Q2 is basically this pattern adoption. CHARLES: Right so it sounds like to kind of paraphrase, whether you're working in any framework most of them have this concept of components so really leaning hard on that idea to make components at the very granular level aware of their own accessibility. Is that fair to say? KRIS: Yeah, obviously there's more I'm sure as we go for the conversation about some of the things that I've tackled in this area but long story short, being able to utilize and recognize, you have this extremely powerful JavaScript framework at your disposal to do some of work for you so why not equip to do just that. CHARLES: Yeah. I guess that falls into my next question, which is there are component level concerns and if there are other component level concerns, I definitely want to hear about them but what immediately leaps to mind is there are also cross-cutting concerns of any single page application, what's the state of your URL and if you're using a router. Some of the content on the page is going to be changing and others isn't like how do you cope with that? What are the cross-cutting concerns of an application that span components and then how do you cope with them? KRIS: I think one thing that comes to mind as you're talking is the whole area of context switch awareness. If I click a link, if I go from the home page of an application to my profile page, how does a screen reader know that that content has now changed to present this new information to the user? I know what we were able to do was we were able to drop in the focusing out with component that's put out by the Ember accessibility team, which basically whenever we render to an outlet, that's utilizing this focusing outlet component, it will focus the browser to that main area and start presenting that information back to the users. One area that was at the top of our list as we start tackling accessibility was we need to figure out this whole context switch awareness thing because -- this is back then obviously when we first got started -- back then there was no way for a user to know when the page changed so they would basically be sitting there, waiting for any kind of feedback or whatsoever to be presented back to them and it just wasn't happening. I would say, managing focus is probably one of the top level concerns when it comes to single page applications because it's a single page application so if you click a link, the page isn't completely refreshing, prompting the screen reader to present the information back to user. That's one of the key areas that I think of. CHARLES: What about things like asynchrony because a lot of times, these context switches are not boom-boom, one-two. The content on which you want to focus isn't available yet. Usually, the analog from a visual UI would be a loading spinner or a progress bar. How do you deal with those to say, "Your content is not quite ready. If you're made to wait it's because we want your content to be of the highest quality." KRIS: Sure, yeah. We were able to drop in the focusing outlet components in our application and it took care of a good chunk of the work but it seems like in our application, we're doing something that might not be as conventional as the rest of the Ember community would like them to be so we might not use the model hook as we should. It's hard for the page to know when the contents actually ready, when it's been rendered to the DOM to present back to the user. One thing that I'm currently trying to tackle right now, to figure out how we can remedy that problem. I probably say, honestly that's the challenge I'm working on right now. I don't have a solid answer to that one at the moment. CHARLES: Irrespective of how it plugs into the tool that you're using, what would just be the desired interaction there, regardless of how you make it work? KRIS: I guess, conceptually what I'd be thinking about is how can we notify the user we're loading content right now and whether that we have an alert box that has the ARIA alerts, basically attributes set on it, that we could pass in new, basically notifications to it to let the user know, "Loading content. Please wait," and then once that content resolves, focus them on that main outlet where the content has been displayed to read that content back to the user. That's how we're trying to think about tackling this issue but we haven't have a time to implement it to see how it's going to work across all the different avenues of application. CHARLES: I did want to come back at the component level. are there any other ways that you can lean on Ember or lean on React or lean on Vue, if you're using a component or in framework, just talk a little bit more about how you use those to unlock your application and make it more accessible. KRIS: One thing I can think of is a way that we can enforce better usage of the framework that we're using is one that comes to mind is a component that I worked out in the blog series that I wrote was building a form input component. Especially, when you're trying to write an accessible app, I think about how can we enforce certain patterns when other developers come in later on and want to add a field to a form or use this component somewhere else in the application. What are some ways that we can enforce that they're doing everything, using the component correctly so that way it renders accessible mark up? What I tinkered around with and we actually just landed in our application is basically a form group component to where we pass in, obviously the value that the input is bound to. But we also pass in a label that is tied to the input and whenever you hit save and the app goes to refresh, if you don't pass the label, there's an assert statement that basically fires up an error into the console and lets you know, "You're trying to use this component, you need to pass into label attribute for the purposes of accessibility and here's the instructions on how to do it." We've been kind of toying around with this idea of enforcing patterns because again, we have several dozen developers at Q2 that are working on this stuff and they're not all wizards when it comes to accessibility but how can we gradually start getting them to the place where they're adopting these patterns and best practices. I'd say, doing things like that, we are enforcing patterns in the usage of the components as well is really a key. One thing that we implement it in our testing framework is the use of a Deque Labs' aXe engine to basically go through, we can pass it a chunk of HTML and it will give us any suggestions that it has to make that content more accessible. We're using that in our test library right now, in our test build and encouraging developers as they write new components, as they go in and modify components to throw new snippets in to make sure that the content that's being spit out here is accessible and then submit your PR again. Just trying to be more hands on in that way. CHARLES: So you actually running a GitHub agent or something that's actually in the same vein as your test suite or if you're taking like snapshotting with Percy for doing visual diff so you're actually running a third check, which is an accessibility check? KRIS: Right now, we were able to land the aXe engine into our test build a couple months back so we're just slowly incrementing that over time. We have a couple challenges in the way of getting Percy implemented but that is in our list of goals to have that running as well. But one thing that I really like about aXe engine in particular is that if your check fails, it refines improvements that you should be making. The nice thing about it is also spits out a link to a page on Deque Labs website. They give an explanation of what have found and basically educates your developers for you. To me, I think that's huge because again, we can't educate every single developer and expect them to be pros at this but we can utilize tooling like the aXe engine or the [inaudible] Chrome extensions or stuff like that to do some education for us. As we work towards automating this further and further by using the aXe engine in our development side of things or using Percy on the test build as well. See, there's all kinds of stuff you can do but that's where we are right now. CHARLES: I really like that idea because in comparison with what we talked about at the top of the show, about how there's this path of least resistance that developers will follow quite naturally and quite rationally, which can lead to not accessible applications. It sounds to me like what you're doing is a establishing the same path of least resistance but having that path guide you towards accessible applications and saying, "This path of least resistance thing, it can be an asset or a liability so we might as well make it an asset." KRIS: Yeah, for sure. We sit down once a week and we talk about whatever challenges we're trying to work through in terms of accessibility. We have a weekly meeting where we sit down and talk about it. I thought one of the key topics to those conversations is how do we get the other developers that are not in these meetings more aware, more informed and more up to speed with this that they care about it, that they're working on it and it's part of their inner dialogue as they're writing out new features that are going to be deployed out to our clients. Lots of challenges there. CHARLES: Yeah. We've talked about some of these problems that you catch, you're actually writing some assertions there on the test build so you'll actually fail if there's certain requirements that aren't met but what are the things that are more intangible? How do those come up in terms of accessibility? What are the things that you can't catch through automated testing? KRIS: Right now, some of things that we're having a hard time testing which Percy will help once we get that implemented is contrast ratios and stuff like that. That's one of the key things that comes to mind for me when I think of the things that are a little hard to catch. I think another thing that's hard to catch, especially at the aXe engine and stuff like that, won't necessarily catch is the flow of your dialogue. When I turn on a screen reader and it starts reading back this page and content to me, sure we can make it so that it doesn't read out the icons character code and a lot of stuff. It presents the information we want back to us but I think, having that information presented back to the user in a way that's legible, that makes sense to them is probably one of the bigger challenges that I've been working on a little bit. One that comes to my mind is like the reading of currencies or numbers. One thing that I found way helpful was Deque put out a very thorough article on how the different screen reader like JAWS, NVDA, Apple's VoiceOver, how they read different types of punctuation, different types of graphics symbols, how they read [inaudible], $123.50, what does a screen reader actually read back to you. That's where I've actually been spending so much of time lately is building on some components that instead of reading back what the streaming will read back by default, which should be, "Dollar sign, one-two-three-five-zero," having actually read back, "One hundred twenty-three dollars and fifty cents," so basically, writing a series of components, I would do some of that, again heavy-lifting force, in that way, our developers don't have to go in and manually add-ons aria-labels obviously. That's been a nice little challenge where something that's we are working on just testing right now and making sure it works right if there is any downsides to doing this but I want a person using a screen reader or other types of assistive technology to hear the information as I'm thinking about it. When I see $123.50, I'm thinking in my head that's, "One hundred twenty-three dollars and fifty cents," not in single digits one right after the other. Those are things that a lot of the automated software isn't catching. It's not catching like, "Your grammar is bad," or, "This isn't making any sense to me." It is catching like are you passing in or applying the attributes to HTML elements that you should be. Are you using semantic structure in your headings and stuff like that?" I think that's one of the areas where developer is need to get their hand dirty, turn on the a screen reader or use any array of different voice-over tools to actually listen to the content being present back to them to see how it's presented. CHARLES: Yeah, it's almost a difference between a syntax error versus a runtime error like we've got a lot tools that can catch the syntax errors and you can put those in and catch where you have something that's malformed but some sentences can be perfectly formed but make no sense and it takes a human set of eyes to make sure if that content is coherent. One of the things that if you're going to ship applications to people, you need to be able to try and measure as closely as possible the environments in which the people will be using your software so you can actually have an accurate measure of whether it works or not. For example, in the Ember world lately in the stuff that we've been doing with acceptance testing in React, we admit people are going to be using a multiplicity of browsers to access this application so it's very typical to use Testem or use Karma to fire up five different browsers, which if you're using BrowserStack, you can do fifty. You know, people are going to be using IE8.1 on Edge or on a Surface. They're going to be using Safari. They're going to be using Chrome and those often surface those issues but I feel like there's no access to the actual screen reader and assistive technologies to be able to make real assertions against those things. I imagine that it would be cool if there was some way that in Testem or in Karma, you could have one of your browsers be like an assistive browser that you could actually assert, I want to assert that it read it as, "One hundred fifty-three dollars and twenty-five cents," and is that on the horizon? Is that even possible? But it seems like something that we have to shoot for if we actually want to measure that these things are working if we actually want to capture data points. KRIS: Yeah, I totally agree. If you look at the documentation on W3 for how these different HTML attributes should be treated by the browser or by the assistive technology, long story short is this is not how -- in several cases -- certain screen readers are presenting the information back to you. It's not how it's treating the content. That's again, one of the areas I thought was way interesting about that. Deque article on punctuation and typographic symbols, which is like we should expect that this software is operating at this level to present this information back to user in such a way where it understands what the dollar symbol in front of a series of numbers means but it just isn't there yet. There's still work to be done. I'm hopeful for the day where our screen readers are a lot more powerful in that capacity. One that makes me a lot more hopeful about that is I don't know if it's just because I've been more interested about this over the last year but it does seem like I'm seeing a lot more people talk about accessibility. I'm seeing Apple putting out videos, talking about the efforts that they're making to make their software more accessible. It does give me hope that there's a lot more visibility on this now. There's a lot more people fighting for this cause to cause these companies to come back and say, "We're going to put more effort into this. We not just going to make a standard screen reader and ship it and just leave it there for five years and no one was going to touch it," but, "We're going to start making improvements." One thing that I did notice just over the last couple months even was that out of nowhere, we use Apple VoiceOver in Chrome, which isn't typically how people use it. They typically use it with Safari. But if you use in Chrome, it will actually read back to you as, "One hundred twenty-three dollars and fifty cents." When I came across that, I was kind of dumbfounded but then I was thinking to myself, the vast majority of people who are using screen readers aren't using this browser but that's really interesting that they're doing this now. I dream of that day where we can basically run a series of mark up through in a test or into a function and basically have to spit back, here's how screen readers going to present this back to you. I'm hopeful for that day. CHARLES: I'm wondering now like why don't major browser vendors, why is this not just a piece of a puzzle that comes when I download Firefox. Firefox has access to my speakers, why isn't there a web standard for how screen readers will treat content? Maybe there's an effort under way. KRIS: I sure hope so. Looking through documentation, we know how things are supposed to work, how we've agreed that they should work and now basically, we're just waiting for the different browser vendors and Microsoft and Apple to make the updates to their streaming technology as well as JAWS and NVDA. I'm hopeful that these changes come soon. These are improvements to the interface. CHARLES: Yeah. Any time there's a gap, you can see that's an opportunity for someone -- KRIS: For sure. CHARLES: -- To write some software that has some real impact. I know certainly, I would love to see some way to roll these things into our automated test suites. KRIS: Yeah. I searched for it but with no avail and it's a little bit beyond my knowledge of how to build something of that caliber. I hope someone else does it because I don't know how. [Laughter] CHARLES: Well, maybe in a year, maybe in two years, maybe in 10, although hopefully a lot sooner than that. KRIS: Yeah. I would judge that at the speed of things were going right now, I'm optimistic that we're going to have some much better solutions within the next year or two on this field. Especially of how much I'm seeing people talk about it now, how much it's becoming a part of the regular conversation of web development, application development. I'm really optimistic that we're going to see some strides in this area over the next couple years. CHARLES: Okay. With the time that we have left, I'm going to ask one more question. Kris, there is something that I wanted to ask you, which is let's say that I am a developer who is working on a team that is maybe it's big, maybe it's small. I've got an application or I'm starting an application and I have a desire to make it accessible. How do I establish that path of least resistance? What advice do you have for someone who's just about to take the first step on that journey to make sure that they have the outcome that they're looking for which is the most accessible single page app that they can have? KRIS: I think it's a great question. I would start out that answer by simply saying to encourage you to be somebody who cares enough to speak up and become an evangelist, become an educator and become an enforcer in your workplace for this work. You don't have to be the most knowledgeable person in the world on the topic. God knows I'm not and I still there were people come to me, asking me, "How do I make this feature, make the guidelines, make it accessible to screen readers," but I'm passionate about this topic and I'm interested in learning as much as I can about those. Step one, just being an evangelists for it. Be interested in it, care about it. I'd say, the next thing is just learn more about semantic HTML. I would say from a lot of the things that I've been trying to tackle with the application that I'm working on, just simply writing semantic markup takes care about 80% of my challenges. In just understanding what are the different elements, what are the different tags are for and how screen readers and other assistive technology see those things. To get started, I would say there's beginner, intermediate and advance stuff. I would say go to the accessibility project, which is just A11yProject.com and read through the content there. It's very entry-level. You can probably read through most of the content within an hour or two and really start to get a grasp as to what level of effort you're looking at in terms of your application. Once you get through that, if you still want to learn more, I'd say go over to Mozilla's developer network -- MDN -- and read through their documentation. On the topic, there is a little bit more exhaustive but it's still really easy to read and really easy to grasp. Based on a content they have shared there, I'd say more of an advance level is actually go through all the documentation on the W3. It's a lot more verbose, it covers a lot more of use cases, it has a lot more suggestions and just stuff ready to go over. I'm still working through that information. There's so much of it but I would say that's as a good place to get started with understanding the different attributes, what they're for and just the importance of writing semantic HTML. I would say some definitely good things to start tinkering with to find some of the low-hanging fruit in your application would be to use some of the assessment tools that are already out there. You have the [inaudible] little JavaScript snippet that you can put in your Chrome favorite's bar or you can use the aXe engine or if you even have an aXe Chrome extension that you could pop up in your application to basically give you report on some of the areas that you should be looking to make some improvements. I think it's important to view accessibility kind of like how a lot of bloggers view SEO, is that there's always more work to be done, there's always improvements you can make but the key is to take those first steps and start making those improvements. One of the nice things about the accessibility project and there's a couple other websites out there that have some of the lists, they basically have a checklist for you to go down. If you're just getting started with accessibility, they have a checklist of all the first things that you should be covering to get your app started in that realm, to start making those improvements. I know you guys do links in the show notes. I can definitely send you those things to those items to get people started. Another thing I find myself doing a lot is while we're talking about something in our chat at work in or just go off in the code pin and mock something out in HTML and then see how the screen reader reads our content back to me and then kind of tinker with it and do a little bit of self-discovery in how this all works together. There's a lot of options out there. I know just threw a lot at your listeners but I'd say, it all starts with being someone who cares about the topic and cares enough to start asking others to care as well. CHARLES: I think that's a fantastic answer and a great note to end on. But before we go, obviously we will include those things in the show notes but also the other thing that we're going to include is a link that you actually, I understand, have a series of blog posts related to all of the things that you've been talking about, which we'll also include. KRIS: Awesome. Thanks. CHARLES: Everybody, go read it. Thank you so much Kris for coming and talking with us about accessibility. I think you're right. It is a topic that's gaining a lot more traction and a lot more mind share in the mainstream that can only be a good thing.

Daily(ish)
Artisanally Crafted Computers with Dave Rupert

Daily(ish)

Play Episode Listen Later Feb 9, 2017


I'm joined by Dave Rupert to talk about his move from Mac to Windows and why it's not such a scary idea after all. Or is it? (cue ominious music)

Goodstuff Master Audio Feed
Daily(ish) 199: Artisanally Crafted Computers with Dave Rupert

Goodstuff Master Audio Feed

Play Episode Listen Later Feb 8, 2017


I’m joined by Dave Rupert to talk about his move from Mac to Windows and why it’s not such a scary idea after all. Or is it? (cue ominious music)

Daily(ish)
Artisanally Crafted Computers with Dave Rupert

Daily(ish)

Play Episode Listen Later Feb 8, 2017


I’m joined by Dave Rupert to talk about his move from Mac to Windows and why it’s not such a scary idea after all. Or is it? (cue ominious music)

Between Players

Dave Rupert guests to talk about how to make time for games even when a full time job, two kids, marriage, and general adult life start to eat into game time.

Podcasting with Aaron
I Want to Start a Podcast, But…

Podcasting with Aaron

Play Episode Listen Later Jul 6, 2015 41:31


If you've thought about starting a podcast but haven't yet, this episode is for you. I want to address some of the reasons and fears you might have that are keeping you from starting a podcast or any kind of creative output that can help you grow an audience and establish you as an authority in your field. My goal is to break you out of the mindset that you might be in (the one that is keeping you from starting), and motivate you to start taking the steps towards launching your podcast. Key Takeaways: Start a podcast about whatever you are most passionate about. If you care about it, talk about it. You won’t run out of topics. The longer you podcast, the more things you’ll find to talk about. What community do you want to become a part of? What community are you already a part of, and do you want to become known as an expert? You don’t have to understand everything about making audio sound good before you start. You don’t have to get editing right the first time. Improve as you go. No one is going to kick you off the internet if you mess something up. After you get over the initial learning curve, you will get faster. Like anything else, the more you do it, the easier it becomes. We all have an equal amount of time in the day. It’s up to us to decide how to use it. In my brainstorming and research for this episode, I went through my email archive, searched Google, and asked folks what was keeping them from starting a podcast. Here’s the list of things I kept seeing pop up. 7 Reasons People Don’t Start a Podcast: I’m not sure what to podcast about, or what topics I should cover. I don’t know anything about recording or editing audio. I don’t have enough money to buy good gear. It seems like so many people are already podcasting. Why would anyone care what I have to say, and how do I stand out? I don’t have the time. I’m not good at speaking. I don’t know anything about making a website or podcast hosting. Roadblock #1. I’m Not Sure What to Podcast About, or What Topics I Should Cover. I get this. I was asking myself this question for about a year before I finally started my podcast. I was worried that after a few months I would run out of things to talk about. I was also worried that the topics I covered wouldn’t be interesting to my audience (more on that later). I have a few questions for you to help to you figure out what you should be podcasting about. First, what are you passionate about? What do you spend most of your time thinking about? What are you constantly excited about learning about? What do you love spending your time on? Start a podcast about whatever you are most passionate about. If you care about it, talk about it. There are so many examples of people make great podcasts that I could bring in, but I just want to mention a couple so you can see examples of people who have found success by podcasting about their passion. Chris Coyier has two podcasts; the Shoptalk Show and CodePen Radio. Both are focused around his passion, which is web design and development. He loves learning about web design, so he started the Shoptalk Show with another guy who loves web design, Dave Rupert. They talk about web design and interview people who love talking about web design. They invite their audience to ask questions about web design so they have more to talk about. This is one of the reasons their show is so successful: the hosts are passionate about web design and they’ve consistently shown up every week for the past three years to talk about what they love. Ryan Young (from the punk band Off With Their Heads) start a podcast called Anxious and Angry back in March of 2014 because he wanted to share his struggles with depression, anger, and the difficulties of being a independent touring musician. He’s obviously passionate about music, but like so many people (especially in punk rock, it seems), he struggles with self-destructive tendencies. So he talks about those things, and asks listeners to write in questions or share their struggles. He also interviews other musicians and highlights music from bands that he likes. Graham Cochrane from TheRecordingRevolution.com and Joe Gilder from HomeStudioCorner.com are both passionate about writing, recording, mixing and mastering music. They have created huge communities of people who share their passion because they share everything they learn and ask their audience what they’re struggling with. You won’t run out of topics. The longer you podcast, the more things you’ll find to talk about. What I’ve realized in my short time of producing a podcast is that the more I do it, the more topics I find to share. I feel like after ten shows, I’m just starting to see the tip of the iceberg of the topics that I could do podcasts about. I believe there are two reasons for this. Since I’ve committed to producing a show every week, I’ve started capturing topics as I come across them. I’m following and listening to people who share my passion for podcasting to see what they’re talking about. I get inspiration from them, I learn from them, and then I share what I’ve learned in my own words; through the lens of my experience. I’m becoming part of the broader conversation about podcasting. As I produce more and more content, people are beginning to see me as an expert in this field and they’ve started asking me questions. This keeps me grounded and connected to what my audience is struggling with and what they’re interested in. I encourage this by asking for questions and feedback. I want to know what other people are thinking and what their opinions are about the things I share on my show. What community do you want to become a part of? What community are you already a part of, and do you want to become known as an expert? If you start a podcast about whatever it is you’re passionate about, you’ll build relationships. You’ll make new friends. You’ll get new work opportunities. The same will be true for the people that become a part of your community through your podcast. Who is Your Audience of One? I heard a question the other day that I really liked. Who is your audience of one? The idea is that you should create your podcast for one other person. Have a clear idea in your mind about who that person is, and what they are interested in. Chances are, if you are passionate about something there are plenty of other people out there who are equally passionate about it. My audience of one is someone interested in learning about podcasting. So I ask myself, if I was hanging out with someone who was interested in podcasting, what kinds of questions would they ask me? What would we talk about? What would they be interested in hearing me talk about? If you have a business, or if you’re some kind of professional or aspiring professional, what can you talk about that would help potential clients? What stories can you share? What could you teach someone who is brand new to the field? What could you teach or share with someone who is at or around your level of expertise? These are the things I keep in mind when preparing for my shows, and I think if you think about those questions, they’ll help you find and shape the message of your podcast. Should I Create Content for Potential Clients or Other Professionals Who Share My Passion? Brent Galloway asked: With the content I produce, should I be concerned with it attracting two different audiences (other designers and potential clients)? Most of my content will be design oriented, but my site’s primary goal is to bring in client work. This is tricky: Should you podcast or create content for the other people who share your passion or for potential clients? I think creating for the other people that share your passion will attract clients that want to work with people who are known for being an expert. If the client skims your list of podcast or video titles and they see the wealth of knowledge you’ve shared, they will trust that you have experience, and they’ll feel confident that you are capable of solving their problems for them. This will help you attract the right kind of client as well: Clients who want to hire you for your expertise and not because you’re the cheapest option. Roadblock #2. I Don’t Know Anything About Recording or Editing Audio. I talk a lot about the importance of audio quality because I believe high-quality audio is one of the most overlooked factors in why some shows are more successful than others. I want you to have a successful show, and sounding great can help your show be successful and grow. What I don’t want is for you to wait to publish anything until you have the perfect setup and the perfect sound. You’re not ever going to get there. I know, because I’m already looking at upgrading microphones and I’m constantly looking for ways to improve my sound. You don’t have to understand everything about making audio sound good before you start. You don’t have to get editing right the first time. I’m going to share a short story here about my drumming career, how I got started, and how it relates to podcasting. When I started playing drums at 12 years old, it was because I was intrigued by them. I wanted to learn how to play this instrument that had so many different pieces and sounds. I wanted to participate in a band; be the guy who held down the rhythm. There were so many things I didn’t know. I didn’t know any of the brands of the companies that made drums and cymbals. I didn’t know anything about how the size of the drums affected the way they sound. I didn’t understand or have much control over the dynamics of my playing. I certainly didn’t have any idea of how to make a living as a musician, but that didn’t keep me from getting started. The very first step was pick up the drumsticks. After that, I learned a few common rhythm patterns (called rudiments), then I sat down behind a drum set and I learned how to play a couple of basic rock beats. Eventually, I learned how to play entire songs. Fast forward 13 years and almost 10,000 hours or practice later, and I was playing in front of hundreds of people, getting paid money to play drums. I’m telling you this because you have to take that first step if you want to get better. Then you have to take the next step, and the next step, and you have to keep taking steps. What is the First Step in Starting a Podcast? The first step to starting a podcast is deciding what you want your show to be about. The more specific, the better, as you'll need to be able to quickly describe what your show is about in order to convince people to listen to it. After you’ve decided on your show topic or focus, try recording a practice episode. Find a quiet room, pick up your iPhone (or whatever smart phone you have), open the voice recorder app, and hold it a foot from your face (microphone pointed at you). Talk for 3 minutes, 5 minutes, 10 minutes, an hour. If you aren’t used to talking out loud to your phone, it might feel a little weird at first, but it’ll get easier over time. Recording practice episode is a great way to get comfortable with recording. Roadblock #3. I Don’t Have Enough Money to Buy Good Gear. At some point, you might want to upgrade microphones, but you don’t need a $500 setup to be a podcaster. You can get started for almost nothing. When I started playing drums, I had a pair of sticks and a little practice pad. After a year, my parents bought me a used $300 drum kit (it was crap). After ten years, I had upgraded to over $2000 worth of professional gear, but that professional gear wouldn’t have made me a better drummer in the beginning. I had to learn how to play drums before the gear even mattered. Professional gear will not make you a professional podcaster. Improve as you go. No one is going to kick you off the internet if you mess something up. You don't have to get everything perfect the first time, or even the first twenty times. It’s a journey, not a pass/fail test. The important thing is to start and then keep going. If you care about getting better, you’ll find ways to improve and get better as you go. Roadblock #4. It Seems Like so Many People are Already Podcasting. Why Would Anyone Care What I Have to Say, and How Do I Stand Out? “No one is going to care” is just an excuse we tell ourselves because we are afraid of rejection or not receiving attention. There are tons of people out there that need the knowledge you can share. Maybe you won’t start off with thousands of listeners, but everyone has to start somewhere. If you clearly define the “why” of your podcast, other people who share your interests will find you. This is the beauty of the internet. When you start, you might be podcasting to no one. That’s ok. Keep going. Go out and find the questions that people in your audience are asking. Don’t have an audience yet? Think about what kind of people you want in your audience, and then find out what they’re asking or looking for. Roadblock #5. I Don’t Have the Time. This is true for all of us especially if you are motivated, if you have a lot of projects and passions, if you have a family or a full time job. It’s hard to find time. It’s hard to make time, but that’s what you have to do. Eric Friedensohn said: The main thing that is keeping me from starting a podcast is that I can see how much work goes into making a good one, and it’s pretty daunting. Lately I have been sticking to mediums and platforms that are working for me, rather than jumping into a whole new world and adding that onto my weekly plate. Podcasting does take time, but there are different levels of commitment and how much time each episode will take you. One of the guys I mentioned earlier, Joe Gilder (who does the Home Studio Corner podcast), gives himself an hour to produce each episode. 45 minutes to prepare and record, and then 15 minutes to edit, write basic show notes and publish. I know he can do each episode in an hour because he has experience and has his workflow down, but it is possible to record and publish an episode in less than a couple hours. After you get over the initial learning curve, you will get faster. Like anything else, the more you do it, the easier it becomes. Charli Prangley said: What’s holding me back from starting a design blog (which I really want to do to start trying to get client work) is all my other projects I’m committed to and LOVE doing. I thought this was interesting, so I just wanted to bring up a few questions: What if you could get better clients if you blogged consistently for a year? What if you could work with people you look up to and respect? Do you currently have any projects that you aren’t super stoked about? Do you foresee yourself wanting to transition into something else later down the line? I’m not here to convince you to start a podcast or a blog. If what you are doing is working well for you, that’s fine. Keep doing it. If you have plenty of money but are short on time, you can hire people to help you with editing, show notes, and admin work. A lot of people hire podcast editors and assistants to help with their podcasts. They spend maybe an hour each week preparing for their show, then they record, and after that, they don’t have to do anything else. The show gets fixed up and published. There’s no rule that says you have to record an hour long podcast and write 5,000 words of show notes. When you’re just starting out, it’s ok to limit your show to 15 minutes or less. As you get better and more experienced, you might find yourself wanting to do longer shows. Podcasting is a Good Investment of Your Time I heard a great story recently on the Mac Power Users podcast. The author of a popular blog about Apple called Daring Fireball – John Gruber – described how he got a full time job from someone who was a reader of his site. So if I told you that if you invested an hour or two of your time every week to create a podcast it would eventually lead to better job opportunities or new clients, would you invest that time? Something else to consider: Are there things that you could give up to create time for podcasting? How much time are you spending browsing social media or Reddit? How much TV do you watch every week? We all have an equal amount of time in the day. It’s up to us to decide how to use it. Roadblock #6. I’m Not Good at Speaking. Friend of the show Brent Galloway posted his first Youtube video today. We were talking about it in the chat earlier, and Sean said something to Brent that I thought was really profound, so I want to share it with you here. Sean said (to Brent): It’s crazy, you probably feel like you’re just sort of sticking your neck out there and you see all the things you need to improve and do better, but for every one Brent, there are 99 others who just sit back and passively listen. You are the 1% of people who are actually doing and you’re so far ahead. I know what it feels like to be dissatisfied with your voice. Recording a podcast is hard. You want to do a good job so you’re stressing about it. After you record, you listen back and you think, this is terrible. I can’t believe I messed up that word. I can’t believe I talked in monotone for 15 minutes. Sean is right. If we put ourselves out there, if we try, if we create stuff, there are going to be 100 other people that are going to consume what we make, but they aren’t going to be creating themselves because it is hard. It is a risk and it is scary putting yourself out there. If you feel like you aren’t a good speaker, I encourage you to go listen to episode 9 of this podcast, What If I Don’t Like My Voice? You find tons of useful information there. Also check out the work by Roger Love. He’s created a lot of great content about speaking publicly. Roadblock #7. I Don’t Know Anything About Making a Website or Hosting. The good news is that you don’t have to have a full website to start a podcast. Simplecast is $15/month and will give you everything you need. No coding, graphic design or complicated setup required. Q&A: Garrett asks: I’m afraid (the thing I make) will take off (because it will) and then people will start looking into my history and they’ll find my high school livejournal that I can’t remember the password for. I wouldn’t worry about it too much. I think we all have those old embarrassing blogs. The good news is that most people are not going to care enough to go digging around in your past. If they do, it’s probably because they really like you and they want a deeper connection. They probably have old embarrassing blogs of their own. I wouldn’t worry about the tiny number of people that might go snooping around just to dig up dirt; those people are jerks and no one likes them anyways. Ben Toalson asks: I don’t have time to do a podcast AND a weekly blog AND a weekly newsletter AND a weekly vlog. What should I focus on? Ben, you are already doing three of those four things, which is more than what most people do. For those of you who don’t know who Ben Toalson is, he’s the co-host of the seanwes podcast, and he does a show with his wife called In the Boat With Ben (a podcast on balancing family life with a creative pursuit). He does a weekly podcast, but he also writes extensive show notes (what I would call a blog post), and sends those show notes out to an email list. That’s how we do things on the seanwes network. You can do something similar with your show. It is a lot of work, but it’s easier than producing three separate pieces of content every week (podcast, blog post, email newsletter). Start with writing, then repurpose that content for different mediums as much as possible. Sarah asked: My husband and I did about 30 episodes of our podcast but now it’s at a standstill (because of me). Not sure if I want to continue with it. Not really gaining traction (that I know of) and also I’m not sure what I’m trying to get out of it. I think he was more into it than I was. How long should it take to start receiving feedback, comments and a little more traffic from a podcast if done regularly? If you create a show that isn’t gaining traction or resonating with anyone, I would take a hard look at the content. Are you addressing topics that your audience are interested in? Are you asking for feedback and questions? Are you having conversations with people about the topics? Regularly producing a podcast isn’t good enough if you aren’t creating content that resonates with people. If your podcast is extremely niche, there may not be that many people who share your passion and are also interested in listening to your podcast. You should also take a close look at audio quality and SEO. If you have a podcast and you’re doing a good job with your titles (they should be something your audience would want to click on), but you aren’t writing much in terms of show notes, you’re missing out on organic search engine traffic. I’d recommend checking out episode 5, How to Supercharge Your Podcast and Increase Its Value With Writing. There’s a lot of good advice in there about why show notes are important, and how you can create them. Let’s talk audio quality for a minute. Some listeners have a higher tolerance for poor audio quality than others. If you are recording with an iPhone or a built-in laptop microphone, you may lose listeners because your audio quality isn’t great. Most of those listeners probably won’t let you know, either. They are just going to turn off your podcast and forget about you. There are too many other podcasts out there with great content and great sound quality. You don’t have to have a super-expensive mic, a professional recording studio, or an audio engineer to mix your show, but you need to have a decent mic and know how to record at proper gain levels and do the basics of post-production (editing, mixing, noise removal, etc). Satvik asks: My clients are pretty specific: CEOs of growing startups with complex accounting needs. How do I figure out the best way to reach them? Should I focus on podcasts, blog posts, videos or referrals? First, word of mouth referrals are the best way to get new clients. Having your client’s friends recommend you is really powerful. As far as content goes, start by identifying what your clients are interesting in learning about. What problems are they having? What are they struggling with? What do they want to learn about? Can you create content that gives them some new insight or shows them how you solved a problem? Start with writing. Write a blog post about how you solved a problem for one of your clients. Write as many of those blog posts as you can, because that will attract clients that are searching online for those answers. Turn those posts into podcasts and then video. Cool Stuff to Check Out: Recommended Gear: https://kit.com/thepodcastdude Podcast: https://thepodcastdude.simplecast.com Twitter: https://twitter.com/thepodcastdude Youtube: https://www.youtube.com/c/thepodcastdude Successful Podcasting: http://successfulpodcasting.com Simplecast Blog: http://blog.simplecast.com/

Devchat.tv Master Feed
165 JSJ ShopTalk with Chris Coyier and Dave Rupert

Devchat.tv Master Feed

Play Episode Listen Later Jun 24, 2015 75:14


02:43 - Dave Rupert Introduction Twitter GitHub Blog Paravel 03:42 - Chris Coyier Introduction Twitter GitHub Blog CSS-Tricks CodePen 06:24 - The ShopTalk Show and Podcasting @shoptalkshow “What do I learn next?” => “Just Build Websites!” Question & Answers Aspect 23:19 - Tech Is A Niche Paul Ford: What is Code? 29:51 - Balancing Technical Content for All Levels of Listeners Community Opinion 38:42 - Learning New CSS Tricks (Writing Blog Posts) Code Golf 41:54 - The Accessibility Project Adventures in Angular Episode #027: Accessibility with Marcy Sutton Anne Gibson: An Alphabet of Accessibility Issues 56:02 - Favorite & Cool Episodes ShowTalk Show Episode #091: with Jamison Dance and Merrick Christensen ShopTalk Show Episode #101: with John Resig ShopTalk Show Episode #157: with Alex Russell   ShopTalk Show Episode #147: with Tom Dale ShopTalk Show Episode #123: Special Archive Episode from 2004 ShopTalk Show Episode #166: with Lisa Irish ShopTalk Show Episode #161: with Eric Meyer Picks FIFA Women's World Cup (Joe) Winnipeg (Joe) The Martian by Andy Weir (Joe) Zapier (Aimee) SparkPost (Aimee) dev.modern.ie/tools/vms (AJ) remote.modern.ie (AJ) Microsoft Edge (AJ) StarFox Zero for Wii U (AJ) Hot Plate (AJ) untrusted (AJ) Skiplagged (Dave) Judge John Hodgman (Dave) Wayward Pines (Chris) Sturgill Simpson (Chris) The Economic Value of Rapid Response Time (Dave) The Adventure Zone (Dave) React Rally (Jamison) Matsuoka Shuzo: NEVER GIVE UP (Jamison) DESTROY WITH SCIENCE - Quantum Loop (Jamison) Serial Podcast (Chuck) Ruby Remote Conf (Chuck)

All JavaScript Podcasts by Devchat.tv
165 JSJ ShopTalk with Chris Coyier and Dave Rupert

All JavaScript Podcasts by Devchat.tv

Play Episode Listen Later Jun 24, 2015 75:14


02:43 - Dave Rupert Introduction Twitter GitHub Blog Paravel 03:42 - Chris Coyier Introduction Twitter GitHub Blog CSS-Tricks CodePen 06:24 - The ShopTalk Show and Podcasting @shoptalkshow “What do I learn next?” => “Just Build Websites!” Question & Answers Aspect 23:19 - Tech Is A Niche Paul Ford: What is Code? 29:51 - Balancing Technical Content for All Levels of Listeners Community Opinion 38:42 - Learning New CSS Tricks (Writing Blog Posts) Code Golf 41:54 - The Accessibility Project Adventures in Angular Episode #027: Accessibility with Marcy Sutton Anne Gibson: An Alphabet of Accessibility Issues 56:02 - Favorite & Cool Episodes ShowTalk Show Episode #091: with Jamison Dance and Merrick Christensen ShopTalk Show Episode #101: with John Resig ShopTalk Show Episode #157: with Alex Russell   ShopTalk Show Episode #147: with Tom Dale ShopTalk Show Episode #123: Special Archive Episode from 2004 ShopTalk Show Episode #166: with Lisa Irish ShopTalk Show Episode #161: with Eric Meyer Picks FIFA Women's World Cup (Joe) Winnipeg (Joe) The Martian by Andy Weir (Joe) Zapier (Aimee) SparkPost (Aimee) dev.modern.ie/tools/vms (AJ) remote.modern.ie (AJ) Microsoft Edge (AJ) StarFox Zero for Wii U (AJ) Hot Plate (AJ) untrusted (AJ) Skiplagged (Dave) Judge John Hodgman (Dave) Wayward Pines (Chris) Sturgill Simpson (Chris) The Economic Value of Rapid Response Time (Dave) The Adventure Zone (Dave) React Rally (Jamison) Matsuoka Shuzo: NEVER GIVE UP (Jamison) DESTROY WITH SCIENCE - Quantum Loop (Jamison) Serial Podcast (Chuck) Ruby Remote Conf (Chuck)

JavaScript Jabber
165 JSJ ShopTalk with Chris Coyier and Dave Rupert

JavaScript Jabber

Play Episode Listen Later Jun 24, 2015 75:14


02:43 - Dave Rupert Introduction Twitter GitHub Blog Paravel 03:42 - Chris Coyier Introduction Twitter GitHub Blog CSS-Tricks CodePen 06:24 - The ShopTalk Show and Podcasting @shoptalkshow “What do I learn next?” => “Just Build Websites!” Question & Answers Aspect 23:19 - Tech Is A Niche Paul Ford: What is Code? 29:51 - Balancing Technical Content for All Levels of Listeners Community Opinion 38:42 - Learning New CSS Tricks (Writing Blog Posts) Code Golf 41:54 - The Accessibility Project Adventures in Angular Episode #027: Accessibility with Marcy Sutton Anne Gibson: An Alphabet of Accessibility Issues 56:02 - Favorite & Cool Episodes ShowTalk Show Episode #091: with Jamison Dance and Merrick Christensen ShopTalk Show Episode #101: with John Resig ShopTalk Show Episode #157: with Alex Russell   ShopTalk Show Episode #147: with Tom Dale ShopTalk Show Episode #123: Special Archive Episode from 2004 ShopTalk Show Episode #166: with Lisa Irish ShopTalk Show Episode #161: with Eric Meyer Picks FIFA Women's World Cup (Joe) Winnipeg (Joe) The Martian by Andy Weir (Joe) Zapier (Aimee) SparkPost (Aimee) dev.modern.ie/tools/vms (AJ) remote.modern.ie (AJ) Microsoft Edge (AJ) StarFox Zero for Wii U (AJ) Hot Plate (AJ) untrusted (AJ) Skiplagged (Dave) Judge John Hodgman (Dave) Wayward Pines (Chris) Sturgill Simpson (Chris) The Economic Value of Rapid Response Time (Dave) The Adventure Zone (Dave) React Rally (Jamison) Matsuoka Shuzo: NEVER GIVE UP (Jamison) DESTROY WITH SCIENCE - Quantum Loop (Jamison) Serial Podcast (Chuck) Ruby Remote Conf (Chuck)

Style Guide Podcast
Dave Rupert

Style Guide Podcast

Play Episode Listen Later Mar 19, 2015 44:19


Dave, and his soundboard, join us to talk about microsoft.com's redesign, modular CSS, and the quest for the holy grail of style guides.

Developer Tea
12: Chris Coyier, Part Two - Getting Good At Pretty Much Anything

Developer Tea

Play Episode Listen Later Jan 30, 2015 19:20


On this episode, I continue the interview Chris Coyier. Chris is the creator of CSS-Tricks.com, Codepen.io, and hosts Shoptalk Show with Dave Rupert. In this second part of a two-part interview, Chris and I talk about getting good at being a musician (or at cutting hair), why we rewrite code we've already written, and lots of other necessary things. Mentioned: ShoptalkShow.com Codepen.io css-tricks.com DeveloperTea.com Don't forget to subscribe, rate/review on iTunes, and get in touch! Twitter: @developertea - https://twitter.com/developertea) Email: developertea@gmail.com If you are enjoying the show, would you consider buying me some tea? http://www.developertea.com/buy-me-tea

Developer Tea
12: Chris Coyier, Part One - The Lifecycle of the Web and the Non-Evil of Doing Business

Developer Tea

Play Episode Listen Later Jan 28, 2015 15:50


On this episode, I interview Chris Coyier. Chris is the creator of CSS-Tricks.com, Codepen.io, and hosts Shoptalk Show with Dave Rupert. In this first part of a two-part interview, Chris and I talk about how he got started with CSS Tricks. We also talk about what it's like to make such a massive amount of freely available resources. Mentioned: ShoptalkShow.com Codepen.io css-tricks.com DeveloperTea.com If you are enjoying the show, would you consider buying me some tea? http://www.developertea.com/buy-me-tea

WordPress | Post Status Draft Podcast
Chris Coyier on WordPress, business, and building the web

WordPress | Post Status Draft Podcast

Play Episode Listen Later Jul 14, 2014 66:14


Chris Coyier is not a stranger to most of us web workers. He’s a designer at CodePen, a writer at CSS-Tricks, and a podcaster at ShopTalk. He uses WordPress on all three of his primary projects. For years, Chris has been a consistent advocate for the platform. He develops his own websites with WordPress, but his day-to-day interactions are as a user. Chris brings a unique perspective, I believe. He did some client work early in his career, but he’s been more involved in SaaS projects and membership websites; his current membership websites are on WordPress (CSS-Tricks) and Ruby on Rails (CodePen). I asked Chris about his projects, his perspective on various aspects of WordPress, and the community around it. I enjoyed learning from him, and I hope you do too: http://s3.amazonaws.com/PostStatus/DraftPodcast/chris-coyier-post-status-draft.mp3 Direct Download What have you learned from working on membership websites?  It’s just a good dang business idea. Chris was sold on the idea of membership websites from his tenure at Wufoo and SurveyMonkey (where he worked once they acquired Wufoo). He uses Pippin Williamson’s Restrict Content Pro for managing The Lodge on CSS-Tricks. At CodePen, they spend time thinking about pricing, churn, and other membership metrics. They talk about some of these things (and much more) on the CodePen Radio podcast — an awesome podcast for anyone interested in SaaS, not just CodePen. Delivering value Another aspect Chris noted about membership websites is how it makes you want to continually deliver value for customers. He always wants to make people feel like they’re getting excellent features and value for the price of their membership. Another thing he and the CodePen team are learning is prioritizing feature requests. When you are building for members, you want to build features members want; and sometimes that goes against other fixes that are less glamorous. So they are consistently trying to balance time spent on customer-facing features versus behind the scenes development. Build the feature, get the reward Chris talked about how important it is for him to build something, then be rewarded for the work he does, versus selling something and then having to build the feature for it. He experience this with his big Kickstarter project for a CSS-Tricks redesign a couple of years ago, and said that mentality was really difficult for him. What do you appreciate more now about WordPress, after using other software? WordPress comes with a lot of built-in features that many of us (I do at least) may take for granted. Need a user system? Check. Need comments? Check. Need categorization? Check. Building CodePen, Chris is able to appreciate (even more than before) just how powerful WordPress is and how much thought goes into every feature. We dove into something seemingly simple as an example: tags. It turns out that something even that simple takes a lot of thought, consideration, and user experience considerations. What it ends up as, is something you’ll have to iterate on for years to get anywhere close to how good the WordPress one works already. And that’s like the tiniest thing we could think about. Think about the login system, or something else. So his advice was to focus on simplicity and decisions when building features, because required effort grows rapidly as a feature gets more complicated. How would you compare the WordPress community to other web communities? Chris has exposure to a much broader web community than I do. I’m pretty locked into the WordPress bubble. He sees the Ruby on Rails world, the more generic web world, and attends and speaks at a slew of non-WordPress conferences every year. Even though he says he’s mostly in a WordPress bubble himself (he’s not exactly attending Drupal conferences, he notes), he thinks that the WordPress community is pretty top-notch, and hasn’t seen other communities that are “better” than the WordPress community. There’s definitely no other CMS that I’m jealous of that community. What questions about WordPress are you always seeing on the ShopTalk Podcast Chris and his co-host Dave Rupert (seriously, follow Dave and gain laughs and knowledge in life) get a lot of questions about WordPress on the ShopTalk Podcast. Some of these questions are repeated pretty frequently, and they see trends of common issues. Working locally and syncing remotely For WordPress, the most common questions tend to come around syncing the local development environment with the live environment. They’ve been recommending WP Migrate DB Pro for people trying to get around that, though Chris says he doesn’t think it’s perfect for huge websites like CSS-Tricks. I think, to a degree, the common confusion is logical. WordPress development is really centered around three different layers of “stuff”: the content (posts, pages, etc), the files in the directory, and the site management database options. I think there is plenty of room for confusion when it’s not easy to decouple website management with website content, from a database perspective. Learning more about WordPress through the lens of a different audience I used this segment to talk about other confusing aspects of WordPress. We talked about database management, the degree of PHP knowledge required for WordPress theming, using pre-processors in distributed versus custom themes, responsive images, and the asset-itis of many WordPress websites that utilize plugins that each load their own scripts and styles. Regardless of the specific issues people are having, I find tremendous value listening to ShopTalk — which is not as hardcore of a WordPress audience as I have here — where the trends of people’s struggles help reveal real struggles that perhaps we could build better tools for in WordPress. It’s also worth noting that some of the “struggles” we talked about are very modern struggles, and WordPress has been around for over eleven years. WordPress iterates pretty quickly and does a great job of supporting modern web features, but it’s rarely immediate, especially in terms of core support. But plugin support and the shear number of people innovating on top of WordPress is significant and awesome. Just build websites! So many people want to be told what to do and what to learn next. That’s for sure the #1 question on ShopTalk. In the face of lots of new and changing technology, Chris is often asked about what to do first, or what to do next. He and Dave have a core mantra at ShopTalk to encourage people to “just build websites!” The things that you learn will happen as a result of building those websites and things for other people. The degree of paralysis by analysis they see is significant, and Chris and Dave hope that people will let their experiences guide them versus a to-do list of things they must learn today. You’re desirable Another note is that pretty much everyone has something they can do to provide value to others. People surely know something from a tooling perspective that’s worthwhile; even sans-modern tools, basic knowledge of HTML and CSS — the building blocks of the web — could be a great asset to lots of business. Even more important than tooling though, is the ability to solve problems. Chris used an example of a business that sells wrenches. If you can help a business that sells wrenches to sell more wrenches, then you are able to provide that business a lot of value; so focus on helping businesses do what they do better. Learn by sharing I admire Chris’ degree of sharing what he’s learning, through ShopTalk, CodePen Radio, and for years on CSS-Tricks. He doesn’t do anything special to write about what he learns. He keeps his drafts right there in WordPress. He doesn’t take special notes. He just writes, and he often writes about what he’s learning. Over time he’s been able to refine his writing and learn what to expect, as far as feedback goes. But at the core he just writes, and through that writing he’s been able to grow his own audience and get better at everything else he’s doing professionally. Staying consistent and avoiding burnout I was curious what Chris has done to stay so consistent online and avoid burnout. It seems to me that a lot of people get temporarily motivated and quickly disenchanted. I’ve learned in my own experience with the web that any measure of success takes lots and lots of consistent effort. Chris hasn’t done a lot to think about avoiding burnout, but figures there are some things he subconsciously does to stay motivated. That may be taking extended breaks from the web and disconnecting for a trip to the woods, or shorter breaks just in the day like stopping and playing the banjo for a few minutes. Stay in touch with Chris At the end of every episode of ShopTalk, Chris and Dave give guests an opportunity to plug whatever they want. Chris’ plug for our interview was to advise folks to take some time off from building their own product and instead go into their issues list and clean up after themselves and their project — which is what Chris and team are doing at CodePen right now. He also noted that nothing would make him happier than folks going Pro on CodePen. If you teach, interact with others, or want a way to store private pens, you should definitely check it out. And it’s affordable too, at only $75 for the year. While he didn’t take the opportunity to plug much of his own stuff, you should definitely still check out his various projects. I’ve learned a ton from Chris since I started my own journey on the web. If my learning journey on the web were a university, I’ve definitely taken multiple classes from CSS-Tricks and the ShopTalk Show. Chris’ business is built on a three-legged stool right now. Check them out: CodePen – a playground for the front-end side of the web. ShopTalk Show – a podcast about front-end web design (and sound effects). CSS-Tricks – where the whole internet learns CSS. Also check out Chris’ fun about page with his life’s timeline and follow him on Twitter. I’d like to thank Chris for the time he spent with me, and I hope that if you enjoyed this interview and write-up, that you’ll share it!

Non Breaking Space Show
2013 Year End Spectacular with Dave Rupert

Non Breaking Space Show

Play Episode Listen Later Dec 20, 2013


For our annual year end spectacular we invited Dave Rupert, 1/3 of Paravel, over to chat with Christopher and Sam about what they saw in 2013 and what we can expect in 2014. We also check in with a couple of past guests, Rachel Nabors and Jonathan Snook, about the year that was and the year that will be. Pour yourself some rum and eggnog, find a mistletoe and kiss your podcast player while you bask in the 2013 Year End Spectacular from The Non-Breaking Space Show.

Goodstuff Master Audio Feed
Non Breaking Space Show 45: 2013 Year End Spectacular with Dave Rupert

Goodstuff Master Audio Feed

Play Episode Listen Later Dec 20, 2013


For our annual year end spectacular we invited Dave Rupert, 1/3 of Paravel, over to chat with Christopher and Sam about what they saw in 2013 and what we can expect in 2014. We also check in with a couple of past guests, Rachel Nabors and Jonathan Snook, about the year that was and the year that will be. Pour yourself some rum and eggnog, find a mistletoe and kiss your podcast player while you bask in the 2013 Year End Spectacular from The Non-Breaking Space Show.

Non Breaking Space Show
2013 Year End Spectacular with Dave Rupert

Non Breaking Space Show

Play Episode Listen Later Dec 20, 2013


For our annual year end spectacular we invited Dave Rupert, 1/3 of Paravel, over to chat with Christopher and Sam about what they saw in 2013 and what we can expect in 2014. We also check in with a couple of past guests, Rachel Nabors and Jonathan Snook, about the year that was and the year that will be. Pour yourself some rum and eggnog, find a mistletoe and kiss your podcast player while you bask in the 2013 Year End Spectacular from The Non-Breaking Space Show.

Show Me Your Mic

Chris Coyier stops by to chat about screencasting, podcasting and how he prepares for both. We chat sponsorship and getting to work with Dave Rupert.

Show Me Your Mic

Chris Coyier stops by to chat about screencasting, podcasting and how he prepares for both. We chat sponsorship and getting to work with Dave Rupert.

Goodstuff Master Audio Feed
Show Me Your Mic 31: Chris Coyier

Goodstuff Master Audio Feed

Play Episode Listen Later Nov 5, 2013


Chris Coyier stops by to chat about screencasting, podcasting and how he prepares for both. We chat sponsorship and getting to work with Dave Rupert.

chris coyier dave rupert show me your mic
Happy Monday
Episode 45: Dave Rupert

Happy Monday

Play Episode Listen Later Oct 20, 2013 36:38


Dave Rupert is a front end developer and one of our favorite people on the web (and in life).

josh long paravel dave rupert sarah parmenter brooklyn beta
Goodstuff Master Audio Feed
Show Me Your Mic 1: Dave Rupert

Goodstuff Master Audio Feed

Play Episode Listen Later Feb 12, 2013


For episode 1 of Show Me Your Mic, I’m joined by Dave Rupert of ShopTalk Show fame. We talk about planning a podcast, gear that Dave has tried and attempting to keep a low budget on a high quality podcast.

dave rupert shoptalk show show me your mic
PageBreak Podcast
Mo Pixels Mo Problems : Snippet #81

PageBreak Podcast

Play Episode Listen Later Oct 2, 2012 8:22


For this Snippet, we discuss Mo Pixels, Mo Problems by Dave Rupert. (http://www.pagebreakpodcast.com/snippets/web-design-for-retina-displays)

PageBreak Podcast
Front-End Design Conference 2012 (Part 2 of 3) : Snippet #67

PageBreak Podcast

Play Episode Listen Later Jun 19, 2012 12:46


This Snippets covers Day 1 speakers Dave Rupert and Sara Parmenter and the afterparty shenanigans. Tune in to next weeks show for our discussion on Day 2 Attendee Talks (including ours!) (http://www.pagebreakpodcast.com/snippets/frontendconf-2)

PageBreak Podcast
Things I Learned From Side Projects: Snippet #62

PageBreak Podcast

Play Episode Listen Later May 8, 2012 12:12


For this Snippet, we discuss 40 Things I Learned From Side Projects by Dave Rupert. (http://www.pagebreakpodcast.com/snippets/scared)