Podcasts about tailwind ui

Join us as we unravel the inspiring journey of Tailwind CSS with its creator, Adam Watham. From its inception in 2017 as an open-source CSS framework to becoming a major player in web design, Tailwind has recently undergone a significant rebranding with the launch of Tailwind Plus. This episode provides listeners with insights into Adam's strategic choices, including the reasoning behind merging Tailwind UI into the broader Tailwind ecosystem. Discover the challenges and outcomes of balancing community-driven development with commercial viability, as Adam shares how feedback shapes product improvements. Learn about the launch of "Build UIs That Don't Suck," an initiative designed to foster user engagement and demonstrate Tailwind's quality. Adam also reflects on the importance of sustaining a business model while nurturing open-source passion, offering invaluable advice for anyone in the tech space. Whether you're a developer, designer, or just interested in entrepreneurship, this episode is packed with insights, revealing the artistry behind code and the business. Don't miss it! Subscribe, share, and let us know what you've learned!Send us some love.HoneybadgerHoneybadger is an application health monitoring tool built by developers for developers.JudoscaleAutoscaling that actually works. Take control of your cloud hosting.Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.Support the show

In Elixir Wizards Office Hours Episode 4, SmartLogic Product Designer Ava Slivkoff joins hosts Sundi Myint and Owen Bickford to discuss the product designer's role in software development. Ava shares her experience navigating client expectations, software design principles, and technical constraints. They explore the integration of design and development workflows and how designers and engineers can collaborate to meet a project's specific needs. The conversation emphasizes the value of cross-functional teams and the synergy that can arise when all team members work in harmony to bring a product to life. Key concepts discussed in the episode: The broad scope of the designer role in web app development The value of an MVP in the iterative software design process Challenges of aligning client expectations with design best practices Pros and cons of leveraging pre-built Tailwind CSS styled components Trends and evolution in web design aesthetics and patterns Leveraging open-source design systems like Tailwind UI Balancing technical constraints with design aspirations Communication and trust-building between designers and engineers Workflows for design handoffs and feedback loops Importance of user flows and mapping the product experience Challenges around the implementation of complex UI elements Benefits of regular design review meetings and syncs Fostering empathy and collaboration across disciplines Links mentioned Figma Dev Mode https://www.figma.com/dev-mode/ Tailwind CSS utility-first CSS framework https://tailwindcss.com/ Tailwind UI https://tailwindui.com/ https://devinai.ai/ Special Guest: Ava Slivkoff.

Scott and Wes explore UI Components, discussing functionality, styling, accessibility, and theming. From headless components to styled starters, they share valuable insights to elevate your UI game. Show Notes 00:00 Welcome to Syntax! 02:39 We're on YouTube. 03:14 The four categories of UI libraries or frameworks. 03:46 What does a UI component need to do? 04:14 Must be functional. 06:20 They must fit styling. 06:33 They must be accessible. 08:09 “Internationalizationable.” 09:29 They must handle theming and variants. 10:05 A few common UI components. 10:14 Date Pickers. 12:10 Dropdowns. 13:21 Toast message. Svelte French Toast 15:11 Some honorable mentions. 16:10 Headless components. 18:54 React Aria. Behavior, Accessibility, Internationalization 19:34 Radix UI Primitives. 20:16 Downshift JS. 21:29 Tanstack Table and Forms. 26:00 Unstyled components. 28:04 Shoelace. 32:47 React Aria Components. 33:00 Headless UI. 33:04 Radix UI. 37:12 Base UI. 38:23 What's up with Google's design? 40:22 Styled Starters. React Aria Components Starter ShadCN Tailwind Catalyst MeltUI 47:50 What is the process for overriding with custom elements. 51:10 UI Kits and Design Systems. 53:06 Some things to consider. JS Nation 55:41 A few more options to consider. Pigment CSS Base UI Shoelace BaseLayer JollyUI DraftUI Radix UI PenguinUI Tailwind CSS TailwindUI VerveUI DaisyUI ChakraUI Flowbite FloatingUI Downshift JS Mantine 59:02 Sick Picks & Shameless Plugs. Sick Picks Wes: Battery Daddy Scott: Lazy Susan, Rechargeable Batteries, Charger Shameless Plugs Scott: Syntax on YouTube 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

Building web UIs in Python has always been in interesting proposition. On one end, we have a the full web design story with artisanal HTML and CSS. On another end there are several Python platforms that aim to the bring RAD, rapid app development, style of building with Python. Those can be great, and I've covered a couple of them, but they usually reach a limit on what they can do or how they integrate with the larger web ecosystem. On this episode, we have Samuel Colvin to share his latest exciting project FastUI. With FastUI, you build responsive web applications using React without writing a single line of JavaScript, or touching npm. Yet designers and other tools can focus on React front-ends for a professional SPA like app experience. Episode sponsors bright data Sentry Error Monitoring, Code TALKPYTHON Talk Python Courses Links from the show Samuel on Mastodon: fosstodon.org Samuel on X: x.com FastUI: github.com FastUI Demos: fastui-demo.onrender.com FastAPI: fastapi.tiangolo.com Pydantic: pydantic.dev How Did REST Come To Mean The Opposite of REST Article: htmx.org Tailwind UI: tailwindui.com Dropbase: dropbase.io Anvil: anvil.works Flutter code example: github.com ReactJS code example: github.com Watch this episode on YouTube: youtube.com Episode transcripts: talkpython.fm --- Stay in touch with us --- Subscribe to us on YouTube: youtube.com Follow Talk Python on Mastodon: talkpython Follow Michael on Mastodon: mkennedy

In this episode, we're unwrapping the highlights from Laracon AU, with a special focus on Laravel Pulse leading our discussion. Taylor takes the reins to guide us through the origins and functionality of Laravel Pulse, a health monitoring tool for your Laravel applications.We then shift our discussion to Laravel first party packages.  Taylor openly shares insights into his decision-making process—revealing how he selects packages to join the Laravel family and when it's time to bid them farewell.Our conversation doesn't end there though.  We also look at the future of Laravel and examine the strategies used for continually injecting innovation and fresh ideas into the Laravel ecosystem. Taylor Otwell's Twitter - https://twitter.com/taylorotwell Matt Stauffer's Twitter - https://twitter.com/stauffermatt Laravel Twitter - https://twitter.com/laravelphp Laravel Website - https://laravel.com/ Tighten.co - https://tighten.com/ Laravel Pulse: https://pulse.laravel.com/ Laracon AU - https://laracon.au/ Bugsnag: https://www.bugsnag.com/ Cashier: https://laravel.com/docs/10.x/billing Docker: https://www.docker.com Forge - https://forge.laravel.com/ Herd: https://herd.laravel.com/ Horizon: https://laravel.com/docs/10.x/horizon Inertia - https://inertiajs.com/ Livewire: https://laravel-livewire.com/ Lumen: https://lumen.laravel.com/docs/10.x Mix: https://laravel-mix.com/ Next.js: https://nextjs.org/ Passport: https://laravel.com/docs/10.x/passport Pennant: https://laravel.com/docs/10.x/pennant Sentry: https://sentry.io/for/php/ Tailwind: https://tailwindcss.com/ Telescope: https://laravel.com/docs/10.x/telescope Tony Messias Twitter: https://twitter.com/tonysmdev Valet: https://laravel.com/docs/10.x/valet Vapor - https://vapor.laravel.com/  -----Editing and transcription sponsored by Tighten.

In this episode, Jason, Chris, and Andrew are live at Rails World 2023 in Amsterdam, where they are joined by Adam Wathan, creator of Tailwind CSS. Today, they discuss the well-organized event, their excitement about being part of the Rails community, and Adam's talk on making the most of Tailwind CSS for Rails developers. The conversation dives into topics like using Inertia with Rails, the challenges of creating accessible components, and the management of open source projects, all while shedding light on the nuances of web development. They also explore the pros and cons of using React and Vue.js in their projects, highlighting the flexibility and evolution of these frontend technologies.  Press download now to hear much more! [00:01:01] Adam talks about being at his first-ever Rails conference he's attending.[00:02:00] Adam discusses “Tailwind Connect,” an event that started as a team retreat and grew into a successful meetup. [00:04:38] Jason asks about Adam's upcoming talk at the conference. He discusses the content of his talk, focusing on helping Rails developers make the most of TailwindCSS.[00:06:19] Jason inquires about using Laravel with Inertia, and Adam explains the benefits of Inertia, including how it preserves the monolithic feel of Rails while using React or Vue for the view layer. [00:10:46] Chris and Adam discuss the history and challenges of using Inertia in Rails and its potential advantages. They talk about the limitations of web components and styling issues when using Tailwind CSS.[00:13:50] Adam discusses the need for unstyled primitives with Stimulus or similar solutions to support keyboard navigation and accessibility, and the complexities of handling various scenarios and the need for continuous maintenance.[00:16:07] Chris appreciates the high quality of Tailwind CSS, and they discuss the challenge of managing criticism and maintaining high standards for open source projects. [00:19:02] Adam shares the company's high standards for quality and handling GitHub issues, the ideal number of GitHub issues, and the importance of triaging effectively.  [00:21:15] We hear how issues are categorized, including bug reports and feature requests.  Chris and Adam discuss how to handle feature requests in GitHub repositories. The conversation shifts to the challenges of managing open source project, including handling issues and feature requests. [00:27:29] The discussion turns to implementing interactive frontend components without React, focusing on accessibility and keyboard navigation, and Adam brings up the “curse of React.” Then, Adam discusses the challenges of building frontend components in the context of a Rails project. [00:33:32] The conversation shifts to a comparison of React and Vue.js and why Adam leans towards using React in recent projects. Adam explains that his shift towards react began when they needed interactive components for Tailwind UI and React was chosen due to better support and expertise in the team. [00:35:35] Adam discusses the benefits of creating smaller components in React compared to Vue due to lower extraction costs. He also touches on the evolution of the React and Vue ecosystems, where it appears that Vue often follows in Reacts footsteps. [00:39:42] How much Laravel does Adam get to do these days? Adam mentions that while he doesn't work with Laravel much these days, it is still the main technology for their primary wHoneybadger Honeybadger is an application health monitoring tool built by developers for developers.Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.

Most people are way too comfortable letting a project run for 12 weeks before ever getting it into a shippable state. In this episode, Adam and Ben share the strategies they use to make sure the projects they work on are shippable within the first few days, and stay shippable until the decision is made to finally cut the release.Discuss this episode on Twitter →Timestamps(00:00) - If it's not done, it's not done (03:54) - Example: Building an example app for Catalyst UI (07:01) - Tracer bullets (11:11) - Tactic: Thinking from the perspective of "what could I demo" (11:43) - Example: How Tuple spins up standalone demos (13:00) - Feature flagging and continuous integration (14:19) - Example: Migrating the Tailwind UI website to React and Inertia (18:30) - Tactic: Derisking projects with "save points" (19:07) - The infamous "how to build an MVP" skateboard to car analogy (20:07) - Example: Shipping the Tailwind Connect event website (29:17) - Tactic: Don't be afraid of waste (31:41) - Tactic: Compare your work to what's in production, not your wildest dream (33:42) - Tactic: Do a great version of the simple solution (36:48) - Tactic: Make work in progress visible to avoid taking on too much (39:23) - Example: Designing the "Is it Tailwind" tool LinksAdam on TwitterBen on Twitter

Jake and Michael discuss all the latest Laravel releases, tutorials, and happenings in the community.This episode is sponsored by Honeybadger - combining error monitoring, uptime monitoring and check-in monitoring into a single, easy to use platform and making you a DevOps hero. (03:37) - Laravel 10.14 released (11:41) - Upcoming Livewire v3 features and changes (17:01) - Pines: An Alpine and Tailwind UI library (20:36) - JetBrains announced a bundle for Laravel Developers: PhpStorm + Laravel Idea plugin (24:03) - Download the response of an HTTP request in Laravel (28:11) - Raw query output with bindings is coming to Laravel 10 (30:00) - Generate code in Laravel with Synth (31:59) - Writing and debugging Eloquent queries with Tinkerwell (35:18) - Sponsor: Honeybadger (36:13) - ChatGPT mock API generator for Laravel (38:48) - Diving into Cross-Origin Resource Sharing (39:42) - API authentication in Laravel

Last summer, Tailwind UI moved from selling individual content packages and upsells to a one-time purchase, lifetime access pricing model. Since then, the business has doubled. Having seen this in action, Adam recently convinced his friends Sam and Ryan to try lifetime pricing for their product Build UI, and the results are starting to come in. In this episode, Adam and Ben dive deep into the world of lifetime pricing, why it's not something to be afraid of, and how it can be an absolute game-changer for the right type of business.Discuss this episode on Twitter →Timestamps(00:00) - Intro (00:14) - Why are we talking about this? (03:28) - Moving from package pricing to lifetime all-access pricing for Tailwind UI (06:03) - What about when you run out of new customers? (10:17) - "Everything You've Learned at MicroConf is Wrong" by Chad DeShon (13:33) - The myth of starting from zero every month (16:04) - Would Tailwind UI work as a subscription model? (18:09) - Characteristics of a lifetime-suitable product (20:50) - Subscription LTV vs. lifetime pricing (22:47) - Subscription friction and the death of the impulse purchase (25:42) - The brutality of churn in content businesses (27:21) - Why your lifetime price can actually be higher than your subscription LTV (29:01) - Ben's experience running Upcase at thoughtbot (32:42) - The hidden costs of the content treadmill (36:20) - Hitting a subscription plateau with Upcase (38:34) - Cookie Clicker game — how to make perceived value go up over time (42:31) - Why aspirational, impulsive purchases are more likely with lifetime deals (45:22) - Pricing decisions aren't forever (49:13) - Turning Build UI from a grind into an instant success by flipping the switch on pricing (54:17) - Using lifetime pricing to buy yourself flexibility and time to focus LinksAdam on TwitterBen on TwitterTailwind UI all-accessEverything You've Learned at MicroConf is Wrong, Chad DeShon's lighting talk at MicroConf Growth 2018Build UI, Sam and Ryan's new UI training site that recently switched to lifetime pricing

Astro has once again become a hot topic, capturing the attention of developers and impressing them with its user-friendly features. Astro 2.0 introduced new and improved error overlays that are functional and well-designed, making debugging more efficient for developers.   Astro 2.0 is powered by the fast and efficient Vite 4, which has received high praise in the developer community. Robbie thinks Vite is the future of build tools and based on the State of JS results, many others seem to agree. Chuck shares his struggles with using material UI as a library for Tailwind, which has left him feeling frustrated. But, Robbie thinks using Tailwind UI and Headless UI makes material UI redundant. In this episode, Chuck and Robbie talk about the exciting new features of Astro 2, the pros and cons of using material UI, and their cleanse diets. Key Takeaways [01:42] - A whiskey review: Very Olde St. Nick Ancient Cask 8-Year-Old Rye Whiskey. [09:02] - New features in Astro 2.0. [15:35] - Asto 2.0 introduces Vite 4 as its bundler. [25:04] - The drawbacks of Material UI. [36:05] - Chuck speaks about his cleanse diet. [47:48] - Chuck's experience at NBC Sports Premier League Fan Fest. [52:37] - Robbie talks about his Ford Bronco Restomod.   Quotes [17:06] - “Everyone seems excited about building on top of Vite, and it unlocks so many things, so I think that would be a huge step forward for everyone.” ~ Robbie Wagner [19:46] - “I love how many JavaScript-supporting tools are written in other languages.” ~ Chuck Carpenter  [30:47] - “Solid is really great. If you know React, which 99% of people do, the syntax is the same.” ~ Robbie Wagner Links Very Olde St. Nick Ancient Cask 8-Year-Old Rye Whiskey Todd Snyder Pappy Van Winkle Preservation Distillery Astro 2.0 Next.js React Ember Nullvox Webpack Vite Nuxt State of JS Rollup Parcel Bun Deno Shop Talk Show Syntax Ryan Dahl Node Rust Tailwind CSS Post CSS Material UI Tailwind UI Headless UI Solid JS DietBet Adobe Photoshop Arnold Schwarzenegger Amazon NBC Sports Premier League Fan Fest Barclays Bank Cotton Bureau FedEx UPS Ford Bronco Pocket Casts Restomods Connect with our hosts Robbie Wagner Chuck Carpenter Ship Shape Subscribe and stay in touch Apple Podcasts Spotify Google Podcasts Whiskey Web and Whatnot Top-Tier, Full-Stack Software Consultants This show is brought to you by Ship Shape. Ship Shape's software consultants solve complex software and app development problems with top-tier coding expertise, superior service, and speed. In a sea of choices, our senior-level development crew rises above the rest by delivering the best solutions for fintech, cybersecurity, and other fast-growing industries. Check us out at shipshape.io.

In this all-panelist episode we discuss the promises of the BEAM, and how these hold up in reality. Is the BEAM truly resilient? Allen, Sascha and Adi discuss their experiences using the BEAM, how it compares to other options, and discuss why Elixir isn't a more prominent technology. Sponsors Top End Devs (https://topenddevs.com/) Coaching | Top End Devs (https://topenddevs.com/coaching) Links Tailwind CSS - Rapidly build modern websites without ever leaving your HTML (https://tailwindcss.com/) Tailwind UI (https://tailwindui.com/) Picks Adi- Masamune-kun no Revenge (https://myanimelist.net/anime/33487/Masamune-kun_no_Revenge) Allen- Tailwind UI (https://tailwindui.com/) Sascha- Metaprogramming Elixir (https://read.amazon.com/kp/embed?asin=B00U1VU2GA&preview=newtab&linkCode=kpe&ref_=cm_sw_r_kb_dp_4Y1E33VJTWB7RP9XTNTW) Sascha- studiominiboss (https://blog.studiominiboss.com/celeste) Sascha- Psycho-Pass (https://psycho-pass.com/)

Evan You's Twitter - https://twitter.com/youyuxiEvan You's Website - https://evanyou.me/Evan You's GitHub - https://github.com/yyx990803Become a Sponsor to Evan You - https://github.com/sponsors/yyx990803Vue.js Twitter - https://twitter.com/vuejsVue.js Website - vuejs.orgVite Twitter - https://twitter.com/vite_jsAnthony Fu's Website - https://antfu.me/Anthony Fu's GitHub - https://github.com/antfuTaylor Otwell's Twitter - https://twitter.com/taylorotwellTim Urban: Inside the mind of a master procrastinator | TED - https://www.youtube.com/watch?v=arj7oStGLkUWhy Procrastinators Procrastinate - https://waitbutwhy.com/2013/10/why-procrastinators-procrastinate.htmlTailwind UI - https://tailwindui.com/ 

Our favorite Canadian drops by to talk mobility, fancy A/V setups, what's next for Tailwind UI, and how we'll never find peace of mind.

We talk with host David Bernheisel about his Safe Ecto Migrations guide that was recently released. Intended as a resource for the community, it's a 4-part series covering how Ecto migrations work, running migrations on production, provides a set of common-task recipes and strategies for migrating data in addition to DB structure. We discuss ideas around migrations like avoiding table locks on production, how to safely add DB check constraints, separating data migrations from structure changes, painful learning experiences and much more! Show Notes online - http://podcast.thinkingelixir.com/76 (http://podcast.thinkingelixir.com/76) Elixir Community News - https://github.com/elixir-nx/nx/pull/558 (https://github.com/elixir-nx/nx/pull/558) – Implement hooks and tokens for Nx - https://twitter.com/josevalim/status/1463239485685129216 (https://twitter.com/josevalim/status/1463239485685129216) – José Valim's explanation and excitement for the Nx PR - https://twitter.com/chris_mccord/status/1462851686352015361 (https://twitter.com/chris_mccord/status/1462851686352015361) – Chris McCord teased a fully accessible Tailwind UI styled dropdown component along with something he's working on. - https://twitter.com/josevalim/status/1463605416861081602 (https://twitter.com/josevalim/status/1463605416861081602) – José shares what Philip Sampaio is doing with R&D towards precompiled NIFs - https://twitter.com/philipsampaio/status/1463602239558270980 (https://twitter.com/philipsampaio/status/1463602239558270980) – Philip Sampaio is working on precompiled NIFs using Rustler - https://www.empex.co/mtn (https://www.empex.co/mtn) – Empex Mountain Conference - Held in Salt Lake City, Utah on May 6th 2022 - CFP is open - https://www.twitch.tv/josevalim (https://www.twitch.tv/josevalim) – Advent of Code is getting started. Jose Valim will be live-coding solutions using Elixir on Twitch. Do you have some Elixir news to share? Tell us at @ThinkingElixir (https://twitter.com/ThinkingElixir) or email at show@thinkingelixir.com (mailto:show@thinkingelixir.com) Discussion Resources - https://github.com/fly-apps/safe-ecto-migrations (https://github.com/fly-apps/safe-ecto-migrations) - https://fly.io/phoenix-files/safe-ecto-migrations/ (https://fly.io/phoenix-files/safe-ecto-migrations/) - https://fly.io/phoenix-files/ (https://fly.io/phoenix-files/) - https://elixirmix.com/68 (https://elixirmix.com/68) – ElixirMix - Contributing to the Elixir Community with David Bernheisel & Cory Schmitt - https://elixirmix.com/92 (https://elixirmix.com/92) – ElixirMix - Managing Change with Ecto with David Bernheisel Guest Information - https://twitter.com/bernheisel (https://twitter.com/bernheisel) – on Twitter - https://github.com/dbernheisel (https://github.com/dbernheisel) – on Github - https://bernheisel.com/blog (https://bernheisel.com/blog) – Blog Find us online - Message the show - @ThinkingElixir (https://twitter.com/ThinkingElixir) - Email the show - show@thinkingelixir.com (mailto:show@thinkingelixir.com) - Mark Ericksen - @brainlid (https://twitter.com/brainlid) - David Bernheisel - @bernheisel (https://twitter.com/bernheisel) - Cade Ward - @cadebward (https://twitter.com/cadebward)

Steve and AJ catch up with Jonathan Reinink, the creator of InertiaJS, a utility for seamlessly connecting front end Javascript frameworks with back ends to create a seamless and performant web app monolith. They discuss TailwindCSS and Jonathan's work at Tailwind Labs, and then get into InertiaJS, how it works, and many of the different features. They also discuss the new SSR capability currently in private beta, and Inertia's growing inclusion into other frameworks, such as Laravel Breeze and Laravel Jetstream. Panel AJ O'NealSteve Edwards Guest Jonathan Reinink Sponsors Shortcut (formerly Clubhouse.io)Raygun | Click here to get started on your free 14-day trialTop End Devs Links JavaScript Jabber: JSJ 443: All About InertiaJS with Jonathan ReininkJonathanReinink - Web designer & developerTwitter: Jonathan Reinink ( @reinink ) Picks AJ- Laws of UXAJ- - HTML: HyperText Markup Language | MDNAJ- Creeds of CraftsmanshipJonathan- Tailwind UISteve- Dad Jokes by Pubity - InstagramSteve- Dad Jokes - Instagram Special Guest: Jonathan Reinink.

Steve and AJ catch up with Jonathan Reinink, the creator of InertiaJS, a utility for seamlessly connecting front end Javascript frameworks with back ends to create a seamless and performant web app monolith. They discuss TailwindCSS and Jonathan's work at Tailwind Labs, and then get into InertiaJS, how it works, and many of the different features. They also discuss the new SSR capability currently in private beta, and Inertia's growing inclusion into other frameworks, such as Laravel Breeze and Laravel Jetstream. Panel AJ O'NealSteve Edwards Guest Jonathan Reinink Sponsors Shortcut (formerly Clubhouse.io)Raygun | Click here to get started on your free 14-day trialTop End Devs Links JavaScript Jabber: JSJ 443: All About InertiaJS with Jonathan ReininkJonathanReinink - Web designer & developerTwitter: Jonathan Reinink ( @reinink ) Picks AJ- Laws of UXAJ- - HTML: HyperText Markup Language | MDNAJ- Creeds of CraftsmanshipJonathan- Tailwind UISteve- Dad Jokes by Pubity - InstagramSteve- Dad Jokes - Instagram Special Guest: Jonathan Reinink.

[00:00:28] The panelists introduce themselves.[00:01:37] We hear what everyone is most excited about being at RubyConf and the talks they are most excited about going to.[00:04:11] Jason Swett shares how he prepped for the workshops, and Nick and Emily tell us about their talks. [00:08:13] Jemma asks the panelists why they come to conferences and what brings them here.[00:11:12] Everyone here is a podcaster, so we find out why they do these podcasts.[00:15:11] The panelists share what is so special and unique about the Ruby community.[00:18:59] Find out which podcast episodes the panelists are most proud of that they put out. [00:22:42] What do the panelists think about the diversity of people they bring on to their podcasts? [00:26:33] The panelists all share some great stories about Brittany Martin, how awesome she is, how she's one of the best interviewers, and what a GEM she is!   [00:29:49] Jemma wonders how the panelists stay on top of what's going on in the Ruby community.[00:32:01] The panelists talk about how they, as podcasters, think through what might be interesting to talk about on their podcasts.[00:37:10] Find out who the panelists call their “Ruby Heroes.” [00:44:34] The panelists tell us how they find themselves consistently producing podcast episodes without suffering from burnout. Panelists:Jemma IssroffAndrew MasonJason CharnesEmily GiurleoNick SchwadererJason SwettSponsor:HoneybadgerLinks:Ruby Radar NewsletterRuby Radar TwitterAndrew Mason TwitterJason Charnes TwitterChris Oliver Twitter Jemma Issroff TwitterEmily Giurleo TwitterNick Schwaderer GitHubJason Swett TwitterRemote Ruby PodcastThe Ruby on Rails PodcastThe Code with Jason PodcastRuby WeeklyPeter Cooper TwitterWNB.rb TwitterRemote Ruby Podcast-Episode 139: Learning in Public | Alpine & Inertia (our mental health episode)Remote Ruby Podcast-Episode 100-Upgrading Rails with Ernesto TagwerkerRemote Ruby Podcast-Episode 97-Joined by Adam Wathan: TailwindCSS, Tailwind UI, and ActionView ComponentsThe Code with Jason Podcast-Episode 28-Sandi Metz, Author of POODR (with Special Guest TJ Stankus)The Ruby on Rails Podcast-Episode 271: MEGA RailsConf 2019 Recap with Chris OliverThe Ruby on Rails Podcast-Episode 385: Minimal Flame Wars (Prettier, Parsing and Regex) with Kevin NewtonObie Fernandez TwitterThe Rails 5 Way (Addison-Wesley Professional Ruby Series) by Obie FernandezAaron Patterson TwitterCollin Jilbert TwitterBrittany Martin TwitterBrandon Weaver Twitter

Jonathan Reinink joins us to get us up to speed on Tailwind CSS, Tailwind UI, and Inertia.js. Links https://tailwindcss.com (https://tailwindcss.com) https://tailwindui.com (https://tailwindui.com) https://inertiajs.com (https://inertiajs.com) https://twitter.com/reinink (https://twitter.com/reinink) https://github.com/reinink (https://github.com/reinink) Contact us https://podrocket.logrocket.com/contact-us (https://podrocket.logrocket.com/contact-us) @PodRocketpod (https://twitter.com/PodRocketpod) 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: Jonathan Reinink.

Willkommen in einer neuen Woche voller Updates: Bei Vite 2.5 wird es jetzt noch schneller: 6-fache Geschwindigkeit beim CSS-Minifizieren und viele weitere Optimierungen sind in dem Update vorhanden. Es gibt ein wichtiges Sicherheitsupdate für node.js. Tailwind UI hat eine große Palette neuer Templates für den E-Commerce Bereich vorgestellt. Im Edge-Browser gibt es einen Super Duper Secure Mode, der neben einem lustigen Namen den Just-In-Time Compiler von JavaScript deaktiviert was das Browsen deutlich mehr vor Sicherheitslücken schützt. Interessanterweise wurde dabei auch festgestellt, dass weniger Energie genutzt wird und die User keinen spürbaren Unterschied in der Performance merken. Die Google Identity Services haben eine neue Schnittstelle, die es Nutzer:innen noch einfacher macht, sich mit ihrem Google-Konto bei 3rd-Party Diensten anzumelden. Wir reden außerdem noch über die Statements, die Apple gemacht hat, nachdem es viel Diskussionen zum Thema CSAM Scanning gab.Schreibt uns!Schickt uns eure Themenwünsche und euer Feedback.podcast@programmier.barFolgt uns!Bleibt auf dem Laufenden über zukünftige Folgen und virtuelle Meetups und beteiligt euch an Community-Diskussionen.TwitterInstagramFacebookMeetupYouTube

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

[00:00:42] Andrew gives us an update if he finished his JavaScript framework he was working on, and he tells us why he chooses to use Alpine over Stimulus.  [00:03:45] Find out about a method that Bridgetown has called jsonify and what it does. [00:04:55] Jason tells us since he's been low key back in action this week and he's been trying out Inertia.js. The creator of Inertia, Jonathan Reinink was on a previous episode that you should listen to. Also, Jason talks about how he likes using Tailwind.[00:06:06] Learn more about a JavaScript package called Headless UI that Tailwind has and what Inertia does. Andrew brings up an episode of The Bike Shed podcast called “All Things Inertia” that's worth a listen, where Jonathan explains Inertia, the integrations with Rails, and how and why you would use it with Rails.[00:08:48] Jason talks about something else that's appealing to him about Inertia. He also tells us about working with data, making a project model, and how things started to get really cool using Pagy and its Metadata mode. [00:13:04] Andrew shares something he sees people missing the point about in View Component. He also goes in depth about a great component library from Seek-oss called, “Braid Design System.”[00:18:58] Jason tells us his struggles with components and how having the React pre-built it's like a lesson in how to structure things. [00:22:09] Andrew gives a shout-out to ADHD, our constant friend and protector of all things happy, and goes into having a weird perfectionism around things he built. Jason chimes in and talks about having the same issue.  They also talk about their ADHD meds they're taking and how it's changed their lives. [00:27:41] Andrew shares one of the best things he's ever done for his ADHD, which was getting an ADHD coach he met on Twitter, Dusty Chipura, and how helpful she was.[00:29:04] We have a Ruby announcement! Check out the article linked below! Panelists:Jason CharnesAndrew MasonSponsor:HoneybadgerLinks:Ruby RadarRuby Radar TwitterHeadless UIAlpine.js-GitHubInertia.jsInertia.js Rails AdapterRemote Ruby Podcast-Joined by Jonathan Reinink, Creator of Inertia.js-Episode 66The Bike Shed Podcast Episode 291: All Things Inertia.js with Jonathan ReininkPagy Metadata Extra-GitHubSEEK-OSS Braid Design SystemRemote Ruby Podcast Episode 97: Joined by Adam Wathan: TailwindCSS, Tailwind UI, and ActionView ComponentsDusty Chipura Twitter“Adding support for cross-cluster associations to Rails 7” by Eileen M. Uchitelle (The GitHub Blog)

Topics this week: Tyler had fun with a once-per-year football bet, and Rick had to put in a full day of dad duty. Tyler is considering taking the ShiftNudge design course to get better at design. He also purchased a license to Tailwind UI so he can copy from better designers. LACRM is tweaking it's policy that everyone at the company must do an hour or support each week. Rick reflects on the value he gets from both writing and reading personal newsletters. LACRM is tweaking it's policy around employee conversation, partially based on a conversation we had on this podcast a couple weeks ago. Tyler's Mixergy interview is live. Now that Rick has a sense of what is and isn't working at his business, he wants to simplify which will mean cutting some current complexity away.

Let's dive deep into the pros and cons of Utility First CSS and Tailwind CSS in particular as Jack plays defense and Paige and TJ play devils advocates. Let's see who comes out on top and give you some insights into whether or not Tailwind CSS is the right choice for your next project. Panel Jack Herrington Paige Niedringhaus TJ VanToll Sponsors React Error and Performance Monitoring | Sentry Dev Influencers Accelerator Links Tailwind CSS Tailwind UI Tailwind CSS IntelliSense clsx - npm classnames - npm GitHub | ben-rogerson/twin.macro Chakra UI Headless UI Picks Jack- Willy's Wonderland Paige- myQ | Smart Home & Smart Garage TJ- The Last Dance Contact Paige: The Home Depot Paige Niedringhaus Paige Niedringhaus – Medium Twitter: Paige Niedringhaus ( @pniedri ) GitHub: Paige Niedringhaus ( paigen11 ) Contact TJ: TJ VanToll's Blog Progress Software KendoReact Twitter: TJ VanToll ( @tjvantoll ) Contact Jack: Jack Herrington – YouTube Blue Collar Coder Twitter: Jack Herrington ( @jherr )

Let's dive deep into the pros and cons of Utility First CSS and Tailwind CSS in particular as Jack plays defense and Paige and TJ play devils advocates. Let's see who comes out on top and give you some insights into whether or not Tailwind CSS is the right choice for your next project. Panel Jack Herrington Paige Niedringhaus TJ VanToll Sponsors React Error and Performance Monitoring | Sentry Dev Influencers Accelerator Links Tailwind CSS Tailwind UI Tailwind CSS IntelliSense clsx - npm classnames - npm GitHub | ben-rogerson/twin.macro Chakra UI Headless UI Picks Jack- Willy's Wonderland Paige- myQ | Smart Home & Smart Garage TJ- The Last Dance Contact Paige: The Home Depot Paige Niedringhaus Paige Niedringhaus – Medium Twitter: Paige Niedringhaus ( @pniedri ) GitHub: Paige Niedringhaus ( paigen11 ) Contact TJ: TJ VanToll's Blog Progress Software KendoReact Twitter: TJ VanToll ( @tjvantoll ) Contact Jack: Jack Herrington – YouTube Blue Collar Coder Twitter: Jack Herrington ( @jherr )

Pre-order Michele's book! deployempathy.com/order/Michele Hansen  00:00Welcome back to Software Social. This episode is sponsored by the website monitoring tool, Oh Dear. Oh Dear does everything they can to help you avoid downtime like scheduled task monitoring, SSL certificate expiration notifications and more. But downtime happens. When it does, it's how you communicate in times of crisis that make the difference. Oh Dear makes it easy to keep your customers up to date during critical times. You can sign up for a 10 day free trial with no credit card required at OhDear.app. Colleen Schnettler  00:35So Michele, do you have a,  Michele Hansen  00:38Hey,  Colleen Schnettler  00:38Good morning. Do you have a numbers update for us on your book? Michele Hansen  00:43I do. So my presale went live about a week and a half ago, when our episode with Sean went live. That was my deadline. And, I've sold 43 copies right now. Yeah, it's kind of exciting. Um, it's not all people I know, which is exciting. Colleen Schnettler  01:06That's very exciting. Michele Hansen  01:08I love how supportive people have been. And it also, it makes me, it's just reassuring that people I don't know are buying it. But yeah, so that puts it right now, just, and this is just the raw, you know, number of times $29, which is $1,247. Colleen Schnettler  01:30That's amazing. Congratulations. Michele Hansen  01:33Yeah. Thank you. And I got my first payout yesterday, which after, like, taxes, and everything else, was $912. Colleen Schnettler  01:41Wow. Michele Hansen  01:42Which was kind of exciting, and gives me a little bit of budget to work with, with, like, you know, hiring a proofreader, and using some, like, layout tools, but, you know, so I was pulling these numbers, and because, you know, everybody loves numbers and whatnot. And I was thinking about it. So, so I got this, this message from someone yesterday, who had started reading the book, and it was actually someone I don't know. And if I can just kind of read what they, what they said. Colleen Schnettler  02:25Yes, please.Michele Hansen  02:26And so I had a personal aha moment reading distinction between sympathetic, empathetic and solution based responses. My sympathetic conclusion based responses are leaving no space for empathetic, something I need to address. I'm an engineer and an architect by trade, and I'm looking to do a better job interviewing the humans attached to our work. But I'm also thinking about your book from the sense that a better balance of empathy will help me be a better teammate as well. And, like, getting that was so moving for me because it made me think about how, you know, I'm not writing this book for the money. Like, yes, the book needs to make money, because I've been working on it for four months now and have, you know, there's a lot of time I haven't spent working on Geocodio. Oh, like, I've been a pretty bad Geocodio employee the past couple of months, like, full honesty, right? So like, I have to, like, it has to have been, you know, worth my time. But like, I am not, I'm not motivated by that, like, I am motivated by this, by like, you know, like, I have this like, secret dream goal. Well, I mean, it's not a secret cuz I've, like, tweeted about it, but like, whatever. You know, Mathias sometimes says to me, he's like, I know you were thinking about something because you tweeted about it. And I'm like, oh, I forgot to, like, verbalize that. Anyway, um, I have this dream that through the process of learning this for interviewing, and, like, product development and marketing reasons, people will understand how to be more empathetic and use that in their daily lives. Like, everyone has a capacity for empathy. Everybody can learn it, not everybody is taught it or shown it so they don't really learn it. But everyone has a capacity for it. And, but also, like, very few people, you know, put like, be more empathetic, like, learn how to learn how to use empathy, like on their to do list every day. But they put write a landing page, get more customers, build a feature, like, reply to all of those customers and intercom like, those are the things that end up on a to do list. And so I have this like, kind of, I don't know, like, naive dream that like people will read this and apply these skills to the things they're already doing, but in doing so, learn how to be more empathetic in their daily life or you know, as a as a team member or whatnot. And just getting this message really, it was so motivating, but also so soul-nourishing because it really made me feel like, like the book has done what I wanted it to do. Like, this is what I set out to achieve and, like, this message makes me feel like the book is a success, regardless of how many copies it sells. Like, so it was just like, it was kind of a, it was kind of a, like a moment, like it was, it also sort of like if you're having this effect, like you can, like, stop rearranging it, like, you know, I feel like I've done a rewrite every week for, like, the past eight weeks. Yeah, time to time to ship the gosh darn thing. Colleen Schnettler  05:57That is wonderful. So what I just heard you say is, this book is secretly teaching us how to be better humans, wrapped up in a book about customer interviews. Michele Hansen  06:09Yes, wrapped up in a book about which features you should prioritize, and how to, you know, pick a pricing model based on what people's usage patterns are, and, like, how to understand what people want and write better landing pages. All that stuff they're already trying to do. But then yeah, there's, there's this kind of bigger message. Like, I feel like so much of good UX practice is good human being practice. Colleen Schnettler  06:35Yeah. Michele Hansen  06:36Um, and, I mean, I, I really learned about empathy by doing interviews myself. So this, I mean, it's, it's, it's very personal for me in a way that, like, the book is, I don't know, it is very, very personal for me. And it's not just about showing empathy to other people. It's also about showing empathy to yourself, too, which is just as important. Colleen Schnettler  07:06So I have not read the book yet, unfortunately. Can you tell me briefly, what the difference is between empathy and sympathy that that writer wrote into you? Because we talk about it a lot, but we've never defined it, really. Michele Hansen  07:22Yeah, that's true. So empathy is when you, basically when you, when you try to understand the other person's context without judgment, and it doesn't mean that you agree with what they're saying. You're just trying to find the context behind what they're saying or what they're doing. Because, sort of, most of us, basically, we assume that our, there's this assumption that our actions make sense from our perspective. That is to say you wouldn't go out and do something if it didn't make sense to you, like, maybe very few people might, but like, for the most part, we have this underlying assumption that, that the things that we do make sense to us.  And so you're basically trying to find that internal context for why somebody does something, and then you reflect it back for them. So for example, if you came to me and started telling me about how, like, I don't, I don't know something you were struggling with, like, let's say, you felt like you were banging your head up against the keyboard all week on some, like, coding problem and it was really frustrating for you. An empathetic response to that would be man, that sounds really hard and like you were working really hard on it and it was super frustrating for you. A sympathetic response would be, oh, I'm sorry you went through that. So a sympathetic response creates distance between the person who is speaking and the person who has aired something, and that might not be a complaint or a frustration. It could be like something positive, but it creates distance. And sometimes it's called fake empathy. Like, I feel like this is what you see in a lot of, like, really bad public figures, celebrity apologies. It's like, I'm sorry, that offended you. It's like, no, that's wrong. Like, like, that's not, that's not actually apologizing. And then there's also kind of this other element that I feel like is this sort of, like, solution-based responses, which comes from a place of caring, and I think us as product builders, I know me, like, we really fall into this, is someone, like, if you came to me with some, some problem. If I just said, oh, well, have you tried this? Which, I'm trying to solve your problem, I'm showing care, right? Like, I wouldn't propose a solution to your problem if I didn't care about you and making that solution better. The problem is, is that it doesn't validate your experience and it doesn't acknowledge your experience. So, while it comes from a good place, it's not empathetic because it doesn't say, wow, like, that was really hard for you. Like it doesn't, it doesn't fake make you feel seen or heard. And it could end up being, through the course of a conversation, you end up explicitly asking me like, do you have any advice for how I could do this? Like, what should I try? I feel like I've tried all these other things. But an empathetic response starts with acknowledging what the other person has gone through.  Colleen Schnettler  10:25Okay. Okay  Michele Hansen  10:26And then also checking in with them, like, do you, do you want me to listen to you about this? Or do you want me to help you brainstorm ideas? Colleen Schnettler  10:33Okay. Michele Hansen  10:33Like, so but I think that's, that's like one of those that really, like, it took me a while to wrap my head around that because the other thing about a solution response, especially in the context of a customer interview, or whatnot, is that you need all the context behind, behind why someone does something and why they went through something in order to really build something that solves the problem for them in a way that they understand and they're capable of grokking. Right? Because we need all of the context behind it, not just the functional context, but also sort of the emotional and social context of things in order to build a product that someone feels like is speaking to their experience and the problem they have. Does that make sense? Colleen Schnettler  11:18Yeah, it, it does. It's, it feels like a subtle difference, though. Like, when I try to understand your problem in your context, in your context, the sympathy for versus the empathy, like, it feels very subtle to me. Michele Hansen  11:34It is subtle, but like, um, I mean, it's, it's subtle. You know, it's the difference between, I'm sorry, that was hard for you and that was hard for you. Like, those are a subtle difference between them, but there is a huge difference between that and what someone would receive. Colleen Schnettler  11:53Yeah, I can see that. Michele Hansen  11:55And because when you say, I'm sorry, that happened to you, it emphasizes that it didn't happen to me. Colleen Schnettler  12:01Right, okay. Michele Hansen  12:01It actually, like, Brené Brown talks about this a lot. I'm sorry, that happened to you. It, it makes the other person feel more alone because it emphasizes that they are the only one who experienced that, and it makes them feel isolated.  Colleen Schnettler  12:18Okay.  Michele Hansen  12:19And she has a great way of responding, I'm sorry, of phrasing this, and I don't know if I'm doing it justice. But basically it creates that distance, and feeling alone and feeling like you're the only person who went through something is a really, really hard feeling, especially when you have just gone through something frustrating, and it doesn't have to be a big thing. It could just be, you know, the fact that I spent my week fighting with Grammarly, like, like that could be the problem we're discussing. And, but if you said oh, I'm sorry, you went through that, like, it reminds me that you didn't go through that.  Colleen Schnettler  12:55Hmm. Okay.  Michele Hansen  12:57And it was like, oh, yeah, that was like, maybe it was just me, like, maybe I was doing something wrong, like, am I using it wrong? Like is like, like, you know, it creates all of that doubt and feeling of sort of loneliness in it. Colleen Schnettler  13:11And so tell me the empathetic response again. Michele Hansen  13:14That sounds really hard. Colleen Schnettler  13:15That sounds really hard. Okay, right. So you're not, you're trying not to create that distance where they're an individual isolated, Michele Hansen  13:23Right. Colleen Schnettler  13:24And you're over here. Michele Hansen  13:25And it doesn't start out with I, right? Like, the sympathetic response to start with, you know, like, I'm sorry, that offended you.  Colleen Schnettler  13:33Okay. Michele Hansen  13:34Versus the difference between like, that offended you. Because when you say it that way, you're sort of asking for elaboration. Colleen Schnettler  13:41Right. Right. Michele Hansen  13:42Versus I'm sorry, I offended you just shuts it off.  Colleen Schnettler  13:46Wow, I say that all the time. I'm sorry, XYZ happened to you. Michele Hansen  13:50I said it all the time, too, then I started learning about this stuff. And I was like, I'm accidentally like, a jerk, and I didn't even realize it. But so many of us speak this way. And we learn the way we speak from the people around us. And if the people around you, when you were learning to speak, didn't speak empathetically, even if they're otherwise nice people. like, then it would make sense why you think this way and don't realize it. Colleen Schnettler  14:15Interesting. Michele Hansen  14:16Like, it's totally normal to not realize that what you have been saying is actually not empathetic. Like, like, it is a, it is a learned skill for many people. I mean, the people who have it built in are the people whose, you know, parents really made it a focus when they, when they had their kid. Like, but for most of us, it's kind of oh, I guess I should stop saying that. Like, I remember how at one point, like, when I was in my early 20s, I was at a job and somebody was like, you know, you really shouldn't say well, actually. Like, I don't know if you realize how you are coming across. Like, I know you don't mean anything by it, but like, it's, it's kind of like, and I was like, oh, crap, I do that all the time. Okay, like, mental note, like, mental dictionary update: stop. Like, so it doesn't, you know, it doesn't mean that you're not a nice person or that you're not an empathetic person or that you're not, you don't have a capability for empathy, it simply means that you haven't learned it and all of the various implications of it and we can call learn. Colleen Schnettler  15:15Okay. Yeah. Well, thank you for, for telling me about that. Like, that's really interesting. I didn't know that. I find that like, this whole thing, empathy and psychology, as I'm trying to, as I'm talking to people and trying to sell my product, I have found that it really, and I already knew this, but like, now I'm seeing it, it really makes a difference. Can I just tell you about this one issue, which I find so interesting? Michele Hansen  15:42Yes.  Colleen Schnettler  15:43Okay. So the way my product works is you upload files to the cloud, and then I provide you a dashboard where you can see all of those files. I have gotten several requests now from people to allow them to tag the files. Michele Hansen  16:02Oh, yeah, like Drew asked for that. Right? Colleen Schnettler  16:04Yeah. So I've been trying to figure out why people want to tag the files. He's not the only one who asked for it. Some other people have asked for it. The reason these people want to tag the files is because they want to be able to mass delete all of the files they've uploaded in a development environment. Why did they want to do that? From what I'm understanding, they want to do that so those files, like, because those aren't production files, they're not, like, cluttering up their dashboard. So when those people have asked me about this, I said, well, look, if you exceed your storage, because I don't have a mass delete function right now, and I don't have that, I'll just give you more storage. But nobody likes that answer. It's like, and so I think it's like a mental psychological thing where they want, like, a nice, clean dashboard. I don't know, I just find this really interesting, because I'm like, storage is cheap. I'll give you more storage until I implement this. But, but it's like, it's, like, as human beings, they really want, like, to segment stuff. I don't know, it's like mental. That's kind of the way I've been, I've been thinking about it. Like, as human beings, they don't want files that they don't need on their dashboard, even if they don't have to pay for them. But I'm like, I don't know. So, so that's just kind of been an interesting one for me. I'm like, but you literally like, I'm not gonna make you pay for those files. It's fine. They can just be there in outer space. But no one, yeah, that's an interesting one that keeps coming up. Michele Hansen  17:25Yeah, it sounds like they, like, that clutter is creating a certain like,  Colleen Schnettler  17:33Mental clutter or something psychological clutter. Michele Hansen  17:36Nervousness, or something. And then there's also this element of wanting to, like, mentally, like to mentally separate things like, I'm sort of, I'm reminded of one of my favorite economics papers called Mental Accounting by Richard Thaler, which is basically on how people like, they create different jobs for different bank accounts and investment accounts, and like, you know, for example, people might have one brokerage account that's just for, like, they have like fun money versus they have their serious 401k. Or like, some people have many different bank accounts for, you know, for different purposes. And it, there's, there's probably a broader term for this, but since I come from an econ background, that's, but like, people wanting to create these different mental categories, and basically, like, it's almost like they want to go, sort of, it's like mentally going to IKEA and buying one of those room divider shelves with all the different boxes you can slide boxes in and, like, being able to look at it and see that everything is in all of its little different categories and is in its place. And they know like, you know which things are in which box, and it looks all nice and organized from the outside. Colleen Schnettler  18:51Yeah, I am going to do it because I have found I use my own product for my clients, and I have found I desire the same thing. But I think you're absolutely right. Like, from a purely practical perspective, it doesn't matter. But from, like, a human organizational mental box perspective, like, it seems to make people happy. Michele Hansen  19:11Yeah, like, there's that functional perspective of it. But then there's the emotional perspective of feeling like everything is organized. And then I also wonder if there's a social element where like, maybe they're afraid one of their coworkers will use a file that was only for development, or because there's so many files and they're all in one list, someone will use the wrong file or, like, I wonder if there's any, any sort of elements around that going on? Colleen Schnettler  19:41Yeah. Could be. I didn't ask that. That's, Michele Hansen  19:47So when someone asks you for that, what did you say back to them, exactly? Colleen Schnettler  19:52Well, the first time someone asked me, I said, that's a great idea. I'm totally gonna do that.  Michele Hansen  19:58Okay. That's an understandable response.  Colleen Schnettler  19:59I know you're over there thinking, like, have I taught you nothing, Colleen? You have taught me. That was before we were doing a podcast. Michele Hansen  20:06No, that was a starting point, and that's a perfectly understandable reaction to that. What did you start saying after that? Colleen Schnettler  20:15So the second request I got was via email. So I didn't really have the back and forth that I would have had when I'm talking to someone on the phone or on Slack. And, so this person, I asked them kind of what their use case was, and I also told them in the email that they, you know, I wasn't going to charge them for development files. So if storage became a problem, we could work something out until I had the, you know, a bulk delete API set up. And this person was looking to segment files so they could do a mass delete of the development files. And they also brought up they thought it would be great to be able to segment files, like via model. So you could have, here's all my avatar files over here, here's all my resumes over here, which would be really cool. I mean, that I can totally see the value because and then you're then in your admin, yeah, then in your admin dashboard, you could easily filter based on, you know, what your tag was. And it's really not hard to do, I just haven't done it. But I do like, I do like that idea. And that, to me, makes a lot of sense because I think people really like, like we just talked about, like, you like to have your stuff in the appropriate boxes. Michele Hansen  21:34I think it's hard sometimes when somebody proposes an idea that we get the value of because we would use it ourselves. It can be really hard to say, can you walk me through how you would use that?  Colleen Schnettler  21:46Yeah it is. Michele Hansen  21:47Like, because their reasons may be different. And we really, we need all of those reasons because the reasons I would do something might be different than the reasons why somebody else would do something. But when we understand something, it feels very unnatural to ask for clarification, even when we don't need it. But it's so reasonable.  Colleen Schnettler  22:08That's exactly what it is. It feels so weird, because I'm like, yeah, totally. That's a great freaking idea. Yeah, it is odd. Michele Hansen  22:16I sometimes feel like it's, I wonder if this comes from, like, conditioning in school where, like, I feel like the kid who asks a lot of questions is, you know, sort of branded as annoying. I was definitely that kid in math class. Like, I just always seemed to understand it two weeks after the test. And I wonder if it's like that fear that like, oh, God, like, am I going to be the person who asks questions. And then we have this like, sense that being the person who asks questions, even one that might be sort of a quote, unquote, like dumb question that's clarifying something. Get you like, like, I wonder if there's kind of this built in social conditioning around that, that makes us not want to ask those clarification questions. And we're like, okay, I think I can guess what they want, so I'm just not gonna ask further about that. But, but when we're building a product, you need to be able to, like, look in all the different nooks and crannies of how they're thinking. Colleen Schnettler  23:08Yeah, definitely. That definitely is valuable. To your point, you might use it one way, and they might want it for something totally different. So I really do think, like, throughout the course of this podcast, and since we've been spending a lot of time talking about customer interviews over the past several months, that I've gotten way better at it, because it's, it's my instinct, just to say, yeah, I totally agree, because I do totally agree. So why, I think for me, it's not like, I'm not I don't I'm not scared of asking clarifying questions. I think it's more like, I don't want to waste any more time. Like, I'm like, okay, cool. Let's not waste anyone's time, and let's just go do it. So I have, I do really think I've grown a lot in that, in that kind of sphere of pausing, slow down Colleen, because not really good at slowing down. And, you know, kind of dive into what they want and why they want it. So I think that's been good. Michele Hansen  24:02It can be kind of tough as like, I feel like we're both pretty enthusiastic and kind of like, like, have you ever been called bubbly? Colleen Schnettler  24:11Yeah, of course. Michele Hansen  24:11Yeah, I have been called bubbly, too. Yeah. So like, I like feel like enthusiastic people want to be like, yeah, that sounds awesome. Like, it's so, it's so counter,to like how I would interact with someone socially. Colleen Schnettler  24:25Yeah, I agree. So, so anyway, that was something, I was thinking about that when you were talking all about, you know, empathy and sympathy and psychology, is how much these kinds of factors play into product building.  Michele Hansen  24:41Yeah and building an intuitive product that, that makes sense to people. Like it's, it's really hard to build something that's intuitive because it requires understanding the user's mental model of how something works, and you can't understand their mental model unless you have, you know, really, you know, poked through every nook and cranny of how they think about it. And also seeing what are the similarities at scale across many different customers. You can't just build it for one particular person, right? Like this, I think this is like, do we want to do we want to do more definitions? Because now I'm excited to get into definitions between Human Centered Design versus activities under design. But if we are, we are feeling good on definition today, then, Colleen Schnettler  25:29I don't know what those are. Yeah, go ahead. Michele Hansen  25:32So like, you probably hear people talk about human-centered design, right? Colleen Schnettler  25:37I mean, no, but okay, I believe you, so not me.  Michele Hansen  25:40So like humans, I feel like this kind of came really into it, like, especially in, in tech in the past, like, I don't know, 10,10-15 years, like, you like, think about the human behind it. And like, this is where a lot of like, agile stories come from, is like, as an administrator, I would like to be able to update the billing page, whenever we get a new credit card, like, like, those kinds of stories that if you've worked in the corporate world, you have seen the ads of so and so like, those kind of stories. And like, creating personas, and maybe there's like a picture of a person, and there's their age, and there's like, you know, like, all of those kinds of things that's very, like human-centered designs, and you're designing for people and understanding what those people need. Then there's activity-centered design, which is designing for things that people might be trying to accomplish, but not for specific people, if that makes sense. So it's like, so if you're thinking, I just used an example of like, a billing administrator. The human-centered design approach with a persona might be you know, this is Susan, and she lives in Iowa, she has been working in insurance for 20 years, she has a dog named Charlie, like she prefers to use her iPad on the weekends, but during the week, she uses Windows like, it's like that kind of stuff. Activity-centered design would be like, when billing administrators are going through this process, they want to be able to, you know, these are the different kinds of things they're thinking about, these are the different functions that they need to be able to do. Here are the different things they might be feeling. Like, do they want to be updating a credit card? Like, how does that make them feel, like, is that, is that enjoyable for them? Is that frustrating? Like, are there other people they're working with on this? Do they need to go get a p-card from someone else? Like, what is this entire process they're going through that is independent of them as a specific person and independent of the product? And then how does the product help them get through that entire activity, either easier, faster, or cheaper.  I feel like I just dropped like,  Colleen Schnettler  27:54There's a lot.  Michele Hansen  27:54A lot.  Colleen Schnettler  27:55I'm gonna have to re-listen to that one.  Michele Hansen  27:56But basically,  Colleen Schnettler  27:57So what's the, Michele Hansen  27:58Activity-centered is kind of the approach that I take. And that's the, the approach in the book is designing a process that exists regardless of the person and regardless of the process.  Colleen Schnettler  28:10Okay. Michele Hansen  28:10The product, I think I messed that up. Colleen Schnettler  28:13Okay, so which one is better? Do you have all the answers, Michele? Tell us. Michele Hansen  28:18I am not going to throw bombs in the design world here. I mean, you know, there's, there's value in designing for specific people, right, and, and specific types of people, especially when you're talking about accessibility and whatnot. But fundamentally, you know, like, activity center design is okay, what it, what is the thing that someone's trying to accomplish? For example, 500 years ago, you may have solved, you know, entertain me at home, when I'm alone on a Saturday night with cards or dice, right. And now you might solve it with Netflix. But that fundamental process that you're going through to not be bored when you're in your house on the weekend, like, that process and that desire is relatively constant, which is the thing about activity-centered design approaches is that you're looking at a process that is consistent over time, because you're speaking to sort of broader, underlying goals. And this types of products, someone might use the different functional and social and emotional things that might be important to them are different, but the overall process is the same. And so this is what I think about a lot when we're like thinking about the process that someone is going through and designing something that's intuitive for them and building that mental model is understanding, okay, why do they need to be able to tag things and why do they need to be able to mass delete these things, and what is this overall thing they're trying to do? And it sounds like it's sort of, to feel like all of their files are organized and they can find things when they want to, and that desire to be organized is a relatively consistent desire. Colleen Schnettler  30:03Yeah, I think one of the things, one of the phrases we use at work is to surprise and delight the user. And I feel like this falls into the surprise and delight category. Like it's not necessary, but it's delightful.  Michele Hansen  30:19You just used the phrase ‘at work'. Does that mean when you are working? Or? Colleen Schnettler  30:26Oh, just when I'm, just this company that I've been contracting for for a while likes to use that phrase. Michele Hansen  30:31Okay, gotcha. Colleen Schnettler  30:32So this to me feels, Michele Hansen  30:34I didn't know if you'd suddenly gone off and gotten a full time job without telling me. Colleen Schnettler  30:39Well, I'll tell you if I do that. I may be considering that. That's like a whole ‘nother podcast episode. I feel like we don't have enough time to dive into that. Michele Hansen  30:50We'll do that in a future episode. Colleen Schnettler  30:52Colleen's life decisions. But yeah, so, this feature, I feel like, is delightful. And when we talk about like design, you know, in the context, you were just saying, I think it does fit into the, the latter category. Michele Hansen  31:10Yeah. And I can, I can understand how someone, or you might even, or probably, I feel like if we had talked about this, like, six months or a year ago, the reaction kind of would be like, this feels like we're really splitting hairs over something that's super obvious, and why don't I just go build it? Colleen Schnettler  31:29Well, yeah, Michele Hansen  31:30Which, I think it's a very understandable reaction. Colleen Schnettler  31:34Yeah, I mean, I think the problem I'm having, and I know everyone in my position has this problem. It's just, there's just not enough time to do all these things. Like, one part of me wants to take like six months and just do all the things, right? And then the other part of me wants to balance my life with building this business, and is trying to be patient with, with my constraints as a human. So I know, you know, everyone has those, that struggle, everyone who's working and trying to do this. But yeah, I'd love to add all these things. Like, I want to do all the things of course I do. Michele Hansen  32:10Speaking of which, building the business, we started this episode with my numbers update. Do you want to give us a little numbers update before we go? Colleen Schnettler  32:31So I do want to tell a little story about this. Storytime. So, someone who's kind of a prominent bootstrapper had a tweet the other day about how for his SaaS, he just implemented file uploading using some JavaScript library, and it took him like, I don't know, like a day. So not an insignificant amount of time, but not a huge amount of time. It's a long time if you're a developer to take all day. But I saw, so, like, I saw his tweet, and I was like, oh, like, why didn't he use Simple File Upload? Like, clearly my product is crap. Okay, so this happened at like 9am. So then, like, later in the day, this just happened a couple days ago, I went to see if I had any new signups. And as you know, like, I've been pretty flat for like two or three weeks now, signups have been pretty flat. So, in one day, I got $325 boost in my MRR. One day. Michele Hansen  33:19What? Colleen Schnettler  33:20That has never happened in the history of my product, like ever. I was like, whoa. Michele Hansen  33:25So did someone Tweet it, like, add it to that thread, or, like what happened? Colleen Schnettler  33:29No, no one added it to the thread. And I didn't add it to the thread because he was clearly looking for a non-paid solution. So it seems like it wasn't that he hated my product or it was bad, he just wasn't looking for this kind of solution I was offering. I don't really know what happened. But a whole bunch of people signed up. Michele Hansen  33:50These two things happened on the same day, and you don't have any conclusively linking them, but it feels suspicious that they wouldn't be linked. Colleen Schnettler  34:00It's super weird, right?  Michele Hansen  34:01Yeah.  Colleen Schnettler  34:02Um, so I am trying to like, I'm just really starting to try and get into, like, Google Analytics and understand that. Anyway, so that was, my point of that story is like, you know, this is, we're never bored. I'm never bored, right? Like one day, I'm like, this thing is miserable. The next day, I'm like, I'm the most brilliant person in the world. Like, it's never, it's never boring. I guess my point of that story was it's all over the place. I'm all over the place with, with this product. And some days I feel like it's just not, not as good as it should be. Some days I feel like I'm charging too much. And then other days I have, like I realized I have, there's all this power in this thing I built that no one is utilizing. So that's something I really want to spend some time getting some content going out there and spend some time, like, showing people why it's more powerful than, than, you know, other solutions they've been using. Michele Hansen  34:58You seem really fired up.  Colleen Schnettler  35:00I am. I, I've just had like, a, it's been, like, a really good week. I mean, from a work perspective. And although I didn't get to spend the time, you know, I got, okay. I don't have a lot of time to spend on the product the next month or so, so I'm just taking it in little bits, right. And so this week, it's a tiny thing, but someone pointed out to me, and I think this also plays into psychology. Okay, so my marketing site is built in Tailwind UI. My application site is built off of Bootstrap. Bootstrap and Tailwind are not friends. I can't just throw Tailwind into my Bootstrap site. Michele Hansen  35:37If it makes you feel better, the Geocodio dashboard was on Bootstrap, and the Geocodio marketing website was on Railwind for, like, a really long time, like, like, you, like, we were on the like, 2013 version of Bootstrap for, like, a very long time. And it wasn't until like maybe six months or a year ago that we actually got them both on Tailwind. So you're not the only one. Okay, so back to yours. Colleen Schnettler  36:06So this. Okay, so if you are on my marketing site, and you click through to sign up to get the free trial, here's the thing that happens. The nav bars are different. Michele Hansen  36:17Mmm.  Colleen Schnettler  36:18Yeah, it's not good, and someone pointed it out to me. They were like, oh, I had to click back and forth a few times to make sure it was still the same application. And I was like, oh, my goodness. And so I can't, but it was like, it was, so it's just this visual thing. But this he pointed out, he was like, you know, that's, that made me think I was at the wrong place, it might make me close the window. Michele Hansen  36:40Yeah it might make them think something was wrong, or, like, they accidentally got led off to another site that wasn't the right one. And like, maybe it's, like, phishing or something, like. Colleen Schnettler  36:50Exactly, that's exactly what this guy said. And I was like, oh, my gosh. And so, so my, my Simple File Upload technical accomplishment this week, was basically like, and because I can't, my application is pretty complicated. I can't just pull out Bootstrap and drop in Tailwind. That's gonna take me forever. So I actually, like, just stole, stole is the wrong word. I grabbed some of the Tailwind styles and just over, you know, and overrode my Bootstrap styles just for the navbar. So anyway, the point is, now the nav bars look the same. And it's like, it sounds like a small thing. But like, I think the mental block for, if you sign up and I drop you to a totally different site, you're like, wait, what?  Michele Hansen  37:29Like, yeah, it's like, something is, like, the brain is a little bit like, danger, something is different. Colleen Schnettler  37:34Yeah, exactly. So, so another, so it was another big CSS week for me, which is not my forte, but I got it.  Michele Hansen  37:41I wrote JavaScript this week, which is not my forte. Colleen Schnettler  37:46Oh, jack of all trades.  Michele Hansen  37:48Well, we wrote stuff that, that's not our forte, and you're going back and forth between feeling like it's amazing and you've built something super powerful. And then, also feeling like it's, really has a long way to go, and is it ever going to get there, which, honestly, is how I feel, like, I feel the exact same way about my book. Like, every day, it's like, oh, my God, this is a hot mess. And then I'm like, actually, this is amazing and I should just publish it now. Like, I think that's, I think that's just like part of building something, whether it's a book or you know, software. I mean, yeah. Colleen Schnettler  38:31And honestly, I think it's part of the fun. Like, I honestly do, like I, it makes it interesting. Like, I've worked jobs that are really boring, and they're really boring. Like, this is way more exciting.Michele Hansen  38:52I think that's the thing I love about being an entrepreneur is that it's always different. And sometimes it's different in ways that are super boring and require a lot of paperwork. And sometimes it's different in ways that are like, super awesome, and exciting. But the fact that it is so different all the time is, is what makes it fun and makes me feel like I get to, like, feel lucky that I get to do this as my job.  On that note, perhaps we should sign off for this week. Thank you so much for listening. If you enjoyed this episode, please leave us a review on iTunes or tweet at us. We love hearing what you think about it. Have a good one.

This conversation covers: Mirage's role as an API mocking library, the value that it offers for developers, and who can benefit from using it. How Mirage empowers front end developers to create production-ready UIs as quickly as possible. How Mirage evolved into an API mocking library  How Mirage differs from JSON Server  Sam's relationship to Mirage, and how it fits in with his business. Sam also talks about open source business models, and whether Mirage could work as a SaaS offering. One interesting use case for Mirage, which involves demoing software and driving sales. Links Mirage Sam's teaching site Follow Sam on Twitter Subscribe to Sam's YouTube Channel TranscriptEmily: Hi everyone. I'm Emily Omier, your host, and my day job is helping companies position themselves in the cloud-native ecosystem so that their product's value is obvious to end-users. I started this podcast because organizations embark on the cloud naive journey for business reasons, but in general, the industry doesn't talk about them. Instead, we talk a lot about technical reasons. I'm hoping that with this podcast, we focus more on the business goals and business motivations that lead organizations to adopt cloud-native and Kubernetes. I hope you'll join me.Emily: Welcome to the Business of Cloud Native. My name is Emily, I'm your host, and today I'm chatting with Sam Selikoff. Thank you so much for joining us, Sam.Sam: Thanks for having me.Emily: Yeah. So, today, we're going to do something a little bit different, and we're going to talk about positioning for open source projects. A lot of people talk about positioning for companies, which is also really important. And they don't always think about how positioning is important for open source. Open source maintainers often don't like to talk about marketing because you're not selling anything. But you are asking people to give you their time which, at least for some people, is actually more valuable than their money. And that means you have to make a compelling case for why it's worth it to contribute to your project, and also why they should use it, why they should care about it? So, anyway, we're going to talk with Sam, about Mirage. But first, I should let you introduce yourself. Sam, thank you so much for joining me, and can you introduce yourself a little bit?Sam: Sure. My name is Sam Selikoff. These days, I spend most of my time teaching people how to code in the form of videos on my YouTube channel, and my website, embermap.com. Most of it is front end web development focused. So, we focus on JavaScript. I have a business partner who also works with me. And then we also do custom app development, you know, some consulting throughout the year.Emily: Cool. And then tell me a little bit about Mirage.Sam: Yeah, so Mirage is the biggest open source project I've been a part of since falling into web development, I'd say about eight years ago, I got into open source pretty early on in programming, kind of what made me fall in love with web development and JavaScript. So, I was starting to help out and just get involved with existing projects and things that I was using. Eventually, I made my way to TED Talks, the conference company where I was a front end developer, and that's actually where I met my business partner, Ryan. And we were using Ember.js, which is a JavaScript framework, and we had lots of different apps at TED that were helping with various parts of publishing talks, and running conferences, and all that stuff. And we were seeing some common setup code that we were using across all these apps to help us test them, and that's where Mirage came from. There was another project called Pretender, which helped you mock out servers so that you could test your front end against different server states. And we first wrapped that with something called Pretenderify, and then it grew in complexity. So, I was working on it on my learning Wednesdays, renamed it to Mirage, and then I've been working on it basically ever since. And then, the other big step, I guess, in the history is that originally was an Ember only project, and then last year, we worked on generalizing it so that it can be used by React developers, React Native developers, Vue developers, so now it's just a general-purpose JavaScript API mocking library.Emily: So, we would say that the position is an API mocking library. And—does that sound right?Sam: Yeah. If I had to say what it is, I would say it's a mocking library that helps front end developers mock out backend API's so that they can develop and test the user interfaces without having to rely on back end services.Emily: Why does that matter?Sam: It matters because back end services can be very complicated, there can be multiple back end services that need to run in order to support a UI, and if you're a front end developer, and you just want to make a change and see what the shopping cart looks like when it's empty. What does the shopping cart look like when there's one item? What does it look like when there's 100 items, and we have to have multiple pages? All three of those states correspond to different data in some back end service, usually in a database. And so, for a front end developer, or anyone working on the user interface, really, it can be time-consuming and complex to put that actual server in that state that they need to help them develop the UI. That can involve anything from running, like, a Rails server on their computer to getting other API's that other teams manage into the state they need to develop the UI. So, Mirage lets them mock that out and basically have a fake server that they control and they can put into any state they need. So, it's like a simplified version of back end services that the front end developer can control to help them develop and test the UI.Emily: And when you first started Mirage, did you think of it as an API mocking library?Sam: Not exactly. We used it mostly because of testing. So, in a test, it's usually a best practice to not have your test rely on an actual network. You want to be able to run your test suite of your user interface anywhere, let's say on an airplane or something like that. So, if your user interface relies on live back end services, that's usually where you would bring in a mocking library. And then you would say, okay, when the user visits amazon.com/cart, normally, it would go try to fetch the items in your cart from a real server, but in the test, we're going to say, “Oh, when my app does that, let's just respond with zero items. And then in this next test, when my app does that, let's respond with three items.” So, that's the motivation originally, is in a testing environment, giving the UI developer control over that. And then what happened was that it was so useful, we started using it in development as well, just to help during normal times, just because it was faster than working with the real back end services.Emily: Do you think there are any other projects that do something similar?Sam: Yeah, for sure. I think the most popular one is called JSON Server, which is a popular open source library that lets a front end developer put some data in a file, and then you point JSON Server to it, and then it just gives you an instant mock server you can use to help develop your app.Emily: So, what's the difference between Mirage and JSON Server?Sam: The difference is that JSON Server is made—it's really optimized for giving you a development—kind of a fake server as fast as possible, but it comes with a certain format that it gives you the data in. So, what ends up happening is that it can help you get feedback and build your UI faster, but eventually, you're going to need to point your app at a real API server, whatever you planning on using in production. And so the way JSON Server works might not correspond—in fact, often doesn't correspond with your actual API. So, Mirage fills that gap because Mirage is designed to be able to faithfully reproduce any production API; there's ways to customize how the data comes back so that it matches so that as you're developing your actual user interface against Mirage, you can have confidence that it'll work once you switch over to production.Emily: Is Mirage slower than other options?Sam: Not performance-wise because they're all JavaScript code that runs in the browser, but JSON Server is really optimized for just getting started as fast as possible because it comes with all of those pre-baked conventions about how the data is going to be moving back and forth. So, with Mirage—it can be faster, it depends—but with Mirage, you need to learn a little bit more in order to understand how to faithfully reproduce your production API. But I think it's faster because in the long run, if you're writing code against a mock server that doesn't match the interface of your production API, then you're just going to be having to change that application code that you're writing.Emily: How much do you talk to other people in the Mirage community, and talk about how they're actually using it?Sam: I felt more in touch with the users when it was an Ember project only because Ember is a more niche-type community. Whereas now, there's folks using it in React and Vue, like I was saying, and Angular. And so, we get issues almost every day on the project. It's not like a mega-popular project, but it does have enough people using it that people will ask questions, or open an issue almost every single day. And so I try to stay in touch with the users through that, basically. And then when I went to conferences—you know, before 2020—I would love to talk with people about it, or people would just bring it up. That's kind of how a lot of people know me on the internet. So, I would say that I do it in kind of a passive way. I haven't actively gone out to talk to them, partly because it's an open source project so it doesn't contribute to our revenue. We have some ideas for how that might happen one day, but as of right now, we can't justify doing proper product development on it in the sense of spending time doing customer interviews and stuff because it's a free project right now.Emily: That is my next question, which is, how does it fit in with your business in the larger sense? You know, how you put food on the table? And what are your goals for the project?Sam: A good question. I mean, it's really aligned with our overall mission of, of everything that we do because me and my business partner, Ryan, we really want to just help people get better at UI development, we want it to be easier, we want to help empower more people to do it because we think it's powerful tool in the world, and it's just too hard right now; there's so many things that are hard about it. So, that goes back to our consulting and our teaching; mainly our teaching. That's our main mission. And then Mirage is really—the purpose of Mirage is to enable front end developers to do more kind of with less, so they don't have to run a Docker container or get an SQL database up just to change some CSS for a given server state. So, it fits into that mission. I've been doing open source long enough to know the pattern, and it happens over and over again, where people work on something, it gets popular enough that they start opening issues, and it becomes a maintenance burden for the maintainers, and then they try to stay up late closing issues, they get burned out, and then the project kind of rots. So, that's something that happens a lot in open source. And so, over the last five years or so of working on Mirage, I've been more involved, or sometimes step back if I need to spend more time on other things, but I'm really interested in making it sustainable, and I know some people in the open source community who have made their projects sustainable financially, other with a pro plan, or support plan, or different related services. So, if we could snap our fingers, that would be what would happen, and that's what we're working on now.Emily: Which one of those open source business models do you think is most appropriate?Sam: At this point, we basically are trying to not guess that answer because we think the way to find out which one it is, is to get a critical mass of users and listen to what they're saying. So, on our podcast, we interviewed Mike Perham from Sidekick, who runs Sidekiq and Sidekiq Pro in the Rails community for about 10 years, and he makes really good money. Sidekiq Pro came about because the enterprise customers of Sidekiq were asking for more robust job servers and all this kind of stuff, so there was a natural path for him to making a pro version that he could sell to enterprise clients. And so that's worked out really well for him, and the rest of the community gets to use the base version for free. And I love that because I do love this zero-cost to entry to open source. And then my other friend, Adam Wathan who works on Tailwind, he's made money to help Tailwind be sustainable through education and courses, and then more recently, a project called Tailwind UI, which is pre-built UI components with Tailwind. And that, again, came about from people asking for that after he was working on Tailwind. So, I think the best way to do it is to get that critical mass of users to the point where you know what they're asking for, you hear over and over again, and then it makes sense to go forward with that.Emily: There's also a third option, which is a cloud service, and I'm just curious—like a complete SaaS offering—have you ever considered that?Sam: Absolutely. There's a really cool opportunity there for Mirage because your Mirage server usually lives alongside your front end code so that when every individual front end developer pulls the project down, starts working on it locally, they're running their own Mirage server. But some of the things that people have done organically with Mirage is, create a certain configuration of a server state—let's say for a demo—so let's say they create a shopping cart, or let's say they're working on a financial piece of software, and they need to show what it looks like with three clients and four contracts, and here are the products that we sold and how much money they are. People will make up a Mirage scenario with that specific set of data that their salespeople take and use on sales calls. And that way, again, the user interface looks fully realistic, it's a fully working UI that is talking to Mirage, but now you don't have to worry about the actual back end servers going down or anything like that. And so, we've had this thought of a hosted Mirage, basically like a Mirage cloud, where even non-technical people could tweak the data there, and then again, they don't have to get involved with ops people or anything like that. And that could be really powerful. So, there's a ton of ideas there. I think our hesitation with our company, Embermap, it's worked to some extent, but it's not grown to the point where it can sustain us, and so that's partly because of the market issue, Ember being a little smaller. So, we're nervous to jump into any particular solution before we feel there's a proven market need for it. And so that's why, even though we have a lot of these fun ideas that I think could really work out, we first want to wait until we get that critical mass, the audience size that we'd feel comfortable could sustain a business.Emily: How many people is that? What is the audience size?Sam: That's a tough question. Let's say Mirage cloud was the goal. I think instead of waiting to a certain point, and then trying to build Mirage cloud, we would do a few things in the interim that would be little experiments and lower risk. So, I think the first thing would be, let's say, a Mirage course. And if we can sell a course on Mirage—or even we make a free Mirage course—that gets enough attention, that would tell us that there is enough of a need there, that the positioning resonates, that people are seeing it's a valuable thing, and that would tell us, okay, let's try the next thing. So, we've been trying to do that. I make some YouTube videos over this last year, and I've been tweeting more about it and the work we've been doing, and so all of those are little experiments that I'm trying to pay attention to what resonates. Again, we have users who really love Mirage, and it's changed their workflow, but it's not at the point where I feel like it's a slam dunk and it makes sense to go on the next phase. So, I think there's been some frictions with Mirage, as we've brought it out to the wider JavaScript community. So, we have some things we want to tweak, and then ship a 1.0, and then I think maybe a 10 video course, would be a good next step, and just see the response to that, and basically take it from there.Emily: Yeah. It's always interesting to think like, how will that you have reached the critical mass?Sam: Yeah, I mean—Emily: Hard. Sam: It's really hard. And there's other strategies. I mean, a lot of businesses just have an idea and go try it out. There's this book I read, called Nail It and Scale It, and they talked about finding a problem. And we've have had some users of Mirage who use it at big, bigger companies, and it's really a big part of their workflow. And we've thought about, “Hey, what if we were to build something for them that we could generalize?” They actually have a need for something like a Mirage cloud because every time they develop a feature, they have to sit down with their product people, and their front end developer will basically run through all these different Mirage scenarios to show them how the feature works in every case, and they would love to be able to just send a link to a hosted version where they could do that. So, we've thought about building that kind of thing. But again, it's just a big risk. And then the market risk is there. So, what I've seen, I feel like, working in the past few years with a small circle of small business people and open source that I hang out with is this audience-first approach. So, it's like, if you're delivering a lot of value in the form of open source, and education, and talks, and you build an audience that believes what you have to say, and likes your opinion on things, likes your point of view, and again, resonates with the value of your work, then it becomes more and more obvious. You have a lot of people giving you feedback, you start seeing the same thing over and over. And that's just what we do with developing Mirage itself. We know a lot of what we work on next is driven by the same issues that come up, the same problems that come up in the issues, over and over again. So, I think it is hard to know, but it's one of those lukewarm things. And basically, right now, it feels too early. You know?Emily: And do you feel like, when you say to somebody, let's say, somebody who isn't involved with Mirage at the moment, maybe you're at a developer meetup or something, and you say, “I created Mirage. It's an API mocking library.” Do you have an aha moment? Are they like, “Oh, yeah. I know what that is. I know why you would use that.”Sam: Mm-hm. Sometimes yes, and sometimes no. There is a form of position I feel like, sometimes, really resonates well with people, which is like, “Don't get blocked by your back end developers.” So, if you're a front end developer, and the API is not ready, you can still build your app, including all the dynamic parts of it which would normally require a real server to be running. So, you're the front end developer, and you're trying to wire up the interface, and what happens when you click save on a cart, and it saves it in the back end, and then you show a success message. But your API is not ready, and you're working with another team that's working on the API, so you're kind of frustrated because you're stuck and you feel like you can't do anything, well, that's where Mirage can come in because you don't have to wait on them at all. You can just build it out yourself with Mirage. It's much simpler because it abstracts away all the complexity of a real server enough that you can actually build your UI against this kind of faithful reproduction of the back end. So, people really like that. And then people really like the testing use cases as well. They get confused about the best way to test user interfaces in this new distributed world we're living in where you're maybe working on a React app, and the back end is a separate API that's also serving up iPhone clients and things like that. So, there's really multiple apps involved with running a website like amazon.com. So, the question is, how do you test the front end? And Mirage is a great answer for that as well. And that's where it originally came from, so.Emily: Yeah. I can definitely see the positioning is sort of like a way for front end developers to decrease their dependence on their back end colleagues.Sam: Yeah, exactly. It's hard because there's a lot that it helps you with. And the people who use Mirage the most and have used it the most, it's really transformed their workflow because it lets the front end developer just move so much faster. So, it's really just, like, the fastest way to build a front end. That's really what the whole point of—every change we make to the library, every decision that went into it, it's how to empower a front end developer to build a production-ready user interface as fast as possible. And that includes accounting for all these different server states that are usually a pain in the butt to get.Emily: I'm just taking notes. I mean, that that actually sounded really powerful. Like, “Mirage lets front end developers work as fast as possible,” basically. It's fairly high level, but ultimately, that is a pretty compelling value statement.Sam: Yeah. And I believe it to be true, too. And I mean, that's how—I mean, I've been working on apps recently, and I still use Mirage because it's just faster than using a real server because it's right there in your code. It's right alongside your front end code, so you don't have to switch over to another process running, or open up a browser and see it; it's all right there. If you want to switch from being an admin to being a user, it's like you just uncomment a line alongside the code that you're already writing. So, I truly believe it is the best way to build a user interface. I think the positioning question is interesting because that is high-level. Sometimes developers in open source, they just want to know what it is, so there are some people who would see, “Just tell me what it is.” “It's an API mocking library.” “Okay, got it.” And that's what they want to know. “And what makes it different from other API mocking libraries?” Okay, we can talk about that. But then there's other people I think, who could stand to benefit from it, and if they saw, “Mirage is an API mocking library,” they're going to be like, “I don't really need that.” But then they go back to their job, and they have to work on their app, and they find themselves spinning up a Docker container, going to auth0 to sign in just so they can run their app in an authenticated state, and it's like, Mirage would actually be perfect for this. You could just mock all that stuff out in Mirage once, all your front end developers could use it. And now anytime you want to just work on your app in an auth state, it's just right there in Mirage, you don't have to deal with any of the complexities of the production services.Emily: Yeah. I mean, I also like the idea of sort of the fastest way to build a front end app.Sam: Yeah.Emily: Or to build a UI. The fastest way to build a UI.Sam: Yeah. That is, that's nice. I mean, it's interesting. It's a pretty interesting thing to say, and it's pretty compelling, and it's like, if you can back it up, that's a pretty strong claim.Emily: Yeah. And I mean, one of the things that I also talk to clients about—so I work with all technical founders, usually, and we're often really focused on features, all the cool features, but—you don't have to ignore the features, but you sort of use them to prove that the thing that you're talking about, that the value you say you provide is not BS. But you still want to connect the dots. Like you were saying, sometimes even the most technical person is like, “Oh, a mocking library. But I don't need that.” They're not going to necessarily connect the dots that, like, “Oh, that's going to make my workflow way simpler.” Sam: Right.Emily: Does everybody know what a mocking library is? Like, everybody who needs one?Sam: Mm, depends. If you're a front end developer. I mean, these days, people are becoming more and more specialized, so there's some front end developers who don't even deal with the data fetching side of an app at all. They're working on a part of the app that already has the data, and they're just working on maybe styling, layout, things like that, but they're never writing code or refactoring code that actually interacts with the server. And then even if you are doing that, you might not be writing tests. So, a lot of people just do the lowest friction thing, which is, just point their local UI at whatever server they can. Maybe their company has a staging server or maybe they run one locally in development and they just build it like that. But again, that's the lowest friction, but it's slow because now you're running a Rails server. If you want to change the data, you have to know how to do it in Rails, and you have to run different commands. And then it comes to testing, it's really hard, too. So, I think most people would know, if you were to say, “Yeah, it mocks out the API.” Most people would know that. But people might have different conceptions of what that means. So, there are some approaches to mocking—or stubbing, or faking, there's some technical difference between those terms, but for the purpose of this conversation, it's just faking out that functionality—there's some people who would hear that and say, “Oh, okay, I get it. A function that my code calls when it normally goes to the server, I'm going to replace it with a different function that returns this fake data.” But Mirage works differently because it operates at the boundary of the app. So, when you mock your API with Mirage, you don't have to change anything about your application because it intercepts the network request before it goes to the server. So, that's another big benefit of Mirage, that Mirage has over other solutions for mocking out network functionality is that your application code stays exactly the same. And that's an important point because the whole goal with Mirage is to be the fastest way to build a production-ready user interface. And by production-ready, I mean an interface that can be plugged into your production API and you'll have confidence that it works. So, that boundary thing is another important point of Mirage. So, that would maybe be the one thing that people could mean different things when they say ‘mocking.' But by and large, I would say most front end developers would understand if you said ‘API mocking,' what they mean.Emily: And do you think they generally are also able to figure out what that's used for, why they should care?Sam: Yeah, that's the thing is that that's where I think the real opportunity is because I think, if you were to say ‘API mocking,' people are going to immediately go to testing because that's the kind of environment where you would want to mock the API so you have control over it. But people who haven't used Mirage or something like Mirage, don't realize how powerful it can be, to mock it just during your normal development flow. So, again, once people use it and get it, they use Mirage for everything; it's just part of their workflow. I just start up my UI, I'm running Mirage in a specific scenario, and if I need to see the UI in a different state, I just changed my Mirage scenario, or put some new data in there, or empty out the database there. And so it totally affects your whole workflow because now you're just disconnected from the back end services. So, I think a lot of people aren't doing that. They are just stuck—you know, they're just used to the hassle of getting these three services up and running just so that they can run their UI, and it's a pain in the butt. I mean, I was just talking to someone on another podcast, and he was saying it's the same thing. And it's really hard when they onboard new people because they have to get them set up with all these auth keys just so they can run the front end, even though they don't really care about the auth setup, they just want to start working on this page. So, again, the companies that have used Mirage and adopted it don't have any of those problems because the Mirage server is right there with the user interface, and they don't have to worry about it. So, I think that is a big gap that we could probably do a lot better job of closing with information on the homepage, or examples, or something like that.Emily: So, Mirage also helps new hires get up to speed a lot faster, or get productive, I should say?Sam: So, yeah. If you were hired by Facebook, and you're a front end developer, and your first task is to update the way the colors look on the home feed, to get that running on your computer so you can make changes and see how it looks in the code, at many companies—probably most companies—it's going to involve a lot of moving pieces because you have this React app on the front end, but it has to fetch data from somewhere so you can see how it works. Maybe they have a server that is just used for development that the person can point to. But again, if you have this shared hosted server, you only get what's on there; maybe you don't have an easy way to change what data it gives you. So, usually, front end developers need to see a dynamic user interface in all these different states. But if you're using a shared server, you don't get all those different states. But it's easier to set up because it's already set up. So, the alternative is to say, “All right, Sam, you're new here. Let's get you set up so that you can run a copy of Facebook locally.” So, that usually involves a ton of steps. I mean, I've seen that take, like, a week just to get all the pieces that are required to run the back end up so that you can actually power your front end. So, yeah, companies definitely, definitely have a problem with this. They have a problem with shared staging servers, I've talked to tons of people over the years who hate their staging servers, the back end teams, the ops teams hate them because everyone's always trying to change it for the salespeople to go take demo calls or for people to test. And so basically a shared server like that is just a nightmare because it's basically another production server to maintain that your internal team is trying to use and people want it to do different things. So, that's why Mirage is nice because it's just local to the code, and every front end developer can just tweak it in exactly the way they need for what they're doing at that time. So, I think that's a big opportunity as well.Emily: One of the most interesting things, I think, about this conversation is that you've touched on this idea of salespeople doing demos, and I really like that because it's so different. It's such a different use case.Sam: Yeah. We had a thought about that, actually because we were talking to a handful of companies—did interviews with them, actually, a couple years ago—and we're like, this could be a cool product. And it's like, just the easiest way to show off your software. And again, we've even done consulting for companies that have had basically another server, just for the purposes of a demo. And again, it's just a pain in the butt because it's another production server to manage, you have to reset the database after each call you do, and with Mirage is not like that; it just restarts with the app. It's just heavier, it's a real server to manage, where again if you just need to show off the UI, you can do it with Mirage. So, we thought about doing that. It's an interesting use case, for sure.Emily: I think it's a really good illustration of how you can take the same technology, and reposition it, basically, to do something totally different, have a totally different set of value proposition. The people who would be actually benefiting from its use would be totally different. I mean, you have salespeople versus front end developers.Sam: Yep. We've thought about that. What would that look like to market to those people? And maybe one way you could do it would be, you know, the salespeople get frustrated because they want to just change the numbers in this part of the app on the spreadsheet summary because they know it's going to help them communicate the value to the people that they're talking to, but now they have to go and ask some back end developer or someone on the ops team, “Hey, can you change this database column so that my demo works better?” What if they had a Mirage-powered demo and they could tweak the Mirage data, maybe in some interface themselves, without having to involve anybody. And that's pretty compelling because Mirage, again, is designed to work with any API. So, no matter what your tech stack is on the back end, Mirage works for the front end team. And so now the back end team can do all their stuff, they can be switching from Rails to Elixir, they can be switching to Go or microservice architecture, and they have all this stuff going on, so they're the only ones who really know how to actually get this number from 100 to 200 in the system. Like, it's complicated. And so that's, again, a benefit of just having Mirage because, on the sales calls, the people are just wanting to show what it looks like when the data is a certain way. So, yeah, that was definitely a use case that we didn't anticipate at all.Emily: Yeah. And even you could have five salespeople trying to do calls at the same time and—Sam: Exactly.Emily: Wanting to have different data reflected, and I'm sure that's just like—Sam: A nightmare. I mean, people have told us just, it's the worst. Basically, the shared staging server is a—yeah, it's a huge problem for a lot of teams.Emily: It's so interesting. Well, anyway, taking us back from the rabbit hole, although it—I mean, it really is interesting, and just fascinating how you could change this to be something that's targeted at that totally different market.Sam: Right.Emily: To wrap up. I mean, I was thinking about how you're saying that the fastest way to build a production-ready UI, that possibly is the most powerful thing I think you've said.Sam: Yeah. We actually—I think that's how we had it when we first did the redesign of the site. And it was like, I don't know if that stuck in the sense of, what does production-ready mean? “Oh, I'm already writing production-ready code.” But then it's like, you have to—like you said, connect the dots and explain how you're not writing production-ready code unless the way you're mocking your API is matching your production API, so we kind of switched it to what it says now, which is, “Build complete front end features, even if your API doesn't exist.” Which basically came from the mouth of someone who was using it, and when they had their aha moment that was what they were saying. I've been thinking if we get to the 1.0 launch, I think I would want to go back to something like that because I do think it's compelling. So, “It's the fastest way to develop a UI, test it, and then share a working demo of it,” because that's is really the motivation for the library. So, yeah, it might be interesting to think about doubling down on that as the unique value proposition.Emily: Yeah. I'm curious what your immediate plans are.Sam: So, we've been working on this REPL playground area of the site where people can learn Mirage and see examples, and we can share them and stuff. So, that will hopefully—you'll see a lot of that kind of thing in the JavaScript community. If you go to Svelte, which is another front end framework, you can create little sandboxes and play around with Svelte and learn it. So, it's a really good way to learn things and just see how it works quickly right in the browser without having to install anything. So, we're about wrapping that up. And then I think it'll just be a matter of carving out the time to go through some of the issues and bugs that people have found, and getting it to a point where we feel good about slapping a 1.0 on it. At which point, we can take a look at all the feature requests and all the issues that people have run into and figure out okay, where do we want to focus our time? Again, considering, like, is there a story here where we can make it sustainable, and hopefully, dedicate more of our time to it? Because that's really, again, I think it's the biggest impact work I've done in my career so far, but it's just, sustainability in open source is tough. So, it's a matter of not jumping too early on any particular idea for how to sustain it and monetize it: if it's a pro version, if it's a support plan, people have asked for all these things, but not maybe in the strongest numbers that would make me feel comfortable diving in on that. But I do believe that it can work because I believe it's a really good idea and I know a lot of companies have gotten a lot of value from it. So, that's what our short term plan is.Emily: Well, fabulous. Thanks so much for talking about Mirage. This has been really interesting.Sam: Yeah, thanks a lot for having me, and I appreciate your input. It was fun to revisit the positioning stuff. It's been a while, so it's always good to be thinking about that.Emily: All right. I have one last question for you, which is what is an engineering tool you can't live without?Sam: These days, it's got to be Tailwind. It's a styling framework. And it's just really excellent. So, I would not want to work on a site without it because it would just be painful. So, [laugh] I love Tailwind. Yeah, it's a really good library.Emily: All right, cool. Well, thank you so much. And—oh, what—the very last thing it should be, how can listeners find you, follow you, keep up with you?Sam: Yeah, best place is Twitter, at @samselikoff. And I'm also making YouTube videos more and more these days: youtube.com/samselikoff. So, those would be the places to go.Emily: Right. Excellent.Emily: Thanks for listening. I hope you've learned just a little bit more about The Business of Cloud Native. If you'd like to connect with me or learn more about my positioning services, look me up on LinkedIn: I'm Emily Omier—that's O-M-I-E-R—or visit my website which is emilyomier.com. Thank you, and until next time.Announcer: This has been a HumblePod production. Stay humble.

Adam Wathan's Twitter Account - https://twitter.com/adamwathanAdam's Blog - https://adamwathan.me/Tailwind - https://tailwindcss.com/Tailwind UI - https://tailwindui.com/Test Driven Laravel - https://course.testdrivenlaravel.com/Test Driven Laravel Laracon Talk - https://www.youtube.com/watch?v=MdApmmK71WM&ab_channel=AdamWathanDave Marshall - https://twitter.com/davedevelopment Mockery - http://docs.mockery.io/en/latest/Mail Thief - https://github.com/tighten/mailthiefStripe - https://stripe.com/Xdebug Video - https://www.youtube.com/watch?v=qVfqfJ7-grk&ab_channel=MattStaufferLies you've been told about testing - https://www.youtube.com/watch?v=LdUKfbG713MR Spec Book - https://www.amazon.com/RSpec-Book-Behaviour-Development-Cucumber/dp/1934356379Growing Object Oriented Software Guided by Tests book - http://www.growing-object-oriented-software.com/Practical object oriented design in Ruby book - https://www.poodr.com/Jason McCreary, Start Testing Your Laravel Applications - https://jasonmccreary.me/articles/start-testing-laravel/Laravel Docs: Testing - https://laravel.com/docs/8.x/testing#introductionLaracasts - https://laracasts.com/skills/testingGhosts of War, Slayer - https://www.youtube.com/watch?v=TU0RIt2TeSg&ab_channel=TheHeavyMetalHDThe County Medical Examiners - https://thecountymedicalexaminers.bandcamp.com/Fullstack Radio - https://fullstackradio.com/Jack McDade - https://twitter.com/jackmcdade Episode SponsorshipTranscription sponsored byLarajobsEditing sponsored byTighten