POPULARITY
8 episodes with emberconf
15 episodes with emberconf
3 episodes with emberconf
5 episodes with emberconf
2 episodes with emberconf
2 episodes with emberconf
2 episodes with emberconf
Fredrik talks to Balint Erdi about the web framework Ember. Where did Ember come from, what stands out about it today, how do new features get into the framework, and how is development being made more sustainable? Plus: Balint's experiences organizing Emberfest, and quite a bit of appreciation for the Ruby and Ember communities in general. The episode is sponsored by Cursed code - a half-day conference with a halloween mood taking place on October 31st, in central Gothenburg. Thank you Cloudnet for sponsoring our VPS! Comments, questions or tips? We a re @kodsnack, @tobiashieta, @oferlundand @bjoreman on Twitter, have a page on Facebook and can be emailed at info@kodsnack.se if you want to write longer. We read everything we receive. If you enjoy Kodsnack we would love a review in iTunes! You can also support the podcast by buying us a coffee (or two!) through Ko-fi. Links Balint JSP - Java server pages ZODB - Python object database Ruby Ruby on rails Convention over configuration ORM Active record Ember Angular Yehuda Katz Emberfest Balint's (first!) book - Rock & roll with Ember.js Ember data Support us on Ko-fi! Classes in Javascript Internet explorer 6 Handlebars Glimmer Controllers in Ember Ember addons Ember RFC:s Codemods React native Tree shaking Webpack Embroider Vite Cursed code - sponsor of the episode Poppels cursedcode.se - to read more and buy tickets The Embroider initiative The Ember initiative Ember CLI Ember core teams Emberconf devjournal.balinterdi.com Ember community links Ember guides Ember checkup - Balint's productized consulting service Titles These two decades I'm a web guy Just one thing It'a always useful Rails carried me over Ember was in flux Javascript didn't have classes Emberisms Nowadays I like explicitness more Everything needs to be imported A change they would like to see in the framework (The) Emberfesting Fellow emberino We don't do drama
Fredrik talks to Balint Erdi about the web framework Ember. Where did Ember come from, what stands out about it today, how do new features get into the framework, and how is development being made more sustainable? Plus: Balint’s experiences organizing Emberfest, and quite a bit of appreciation for the Ruby and Ember communities in general. The episode is sponsored by Cursed code - a half-day conference with a halloween mood taking place on October 31st, in central Gothenburg. Thank you Cloudnet for sponsoring our VPS! Comments, questions or tips? We a re @kodsnack, @tobiashieta, @oferlund and @bjoreman on Twitter, have a page on Facebook and can be emailed at info@kodsnack.se if you want to write longer. We read everything we receive. If you enjoy Kodsnack we would love a review in iTunes! You can also support the podcast by buying us a coffee (or two!) through Ko-fi. Links Balint JSP - Java server pages ZODB - Python object database Ruby Ruby on rails Convention over configuration ORM Active record Ember Angular Yehuda Katz Emberfest Balint’s (first!) book - Rock & roll with Ember.js Ember data Support us on Ko-fi! Classes in Javascript Internet explorer 6 Handlebars Glimmer Controllers in Ember Ember addons Ember RFC:s Codemods React native Tree shaking Webpack Embroider Vite Cursed code - sponsor of the episode Poppels cursedcode.se - to read more and buy tickets The Embroider initiative The Ember initiative Ember CLI Ember core teams Emberconf devjournal.balinterdi.com Ember community links Ember guides Ember checkup - Balint’s productized consulting service Titles These two decades I’m a web guy Just one thing It’a always useful Rails carried me over Ember was in flux Javascript didn’t have classes Emberisms Nowadays I like explicitness more Everything needs to be imported A change they would like to see in the framework (The) Emberfesting Fellow emberino We don’t do drama
Recorded at EmberConf from the heart of the Multnomah Whiskey Library with Jared Galanis, Software Engineer on the Ember Learning Team, and Preston Sego aka NullVoxPopuli, Software Artificer at AuditBoard, Chuck and Robbie delve into the evolution and future of the Ember framework. Though Ember isn't often in the spotlight for being cutting-edge, Jared and Preston unravel the exciting developments in the Ember ecosystem. The conversation centers around Ember Polaris, the eagerly awaited next edition of the Ember framework. Preston explains the concept of "editions" in semantic versioning and how Polaris aims to provide a cohesive story for integrating new features. They also discuss Ember's shift to Vite as a modern build system, resulting in improved performance, startup time, and enhanced plugin ecosystem. Jared sheds light on the Ember learning team and his background in front-end and back-end development. He reinforces Ember's commitment to offering smooth upgrade paths for applications over the years, giving developers a sense of security and longevity. In this episode, Jared and Preston talk to Robbie and Chuck about the upcoming release of Ember Polaris and its compatibility with Vite, the unique reactivity primitives of Ember, and how changes can modernize the Ember framework while ensuring long-term app stability. Key Takeaways [00:29] - Intro to Jared and Preston. [02:32] - A whiskey review: Willett Straight Rye Whiskey. [14:50] - Tech hot takes. [25:25] - Jared and Preston's favorite programming language. [27:29] - New developments in Ember, including Polaris. [39:44] - A whiskey review: Four Roses Single Barrel. [46:45] - Preston's opinion on Glimmer. [56:26] - Chuck, Robbie, Preston, and Jared discuss gaming. Quotes [18:58] - “One thing that I've appreciated about Tailwind is that it has done a better job of teaching people actually CSS than where people go to learn CSS.” ~ Preston Sego [30:07] - “It's exciting to see Ember moving towards being able to use standardized build systems that are used widely throughout Javascript.” ~ Jared Galanis [52:34] - “People in the React ecosystem are perfectly fine with half-baked things and are willing to try an idea and run with it in their production code.” ~ Preston Sego Links Jared Galanis Jared Galanis on LinkedIn Jared Galanis Twitter Preston Sego on LinkedIn Preston Sego Twitter Ember EmberConf Subway Netflix Willett Straight Rye Whiskey RC Cola React Angular Sagamore Rye Whiskey Google Semver Tailwind CSS The Primeagen Impossible Burger The JS Party Podcast Svelte Vue Preact Next.js Vite JS Jest Four Roses Single Barrel Chicken Cock Whiskey Glimmer.js Remix Steam Deck Asus FIFA 2023 Sunlight Moonlight NVIDIA Shield Tesla GitHub 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. --- Send in a voice message: https://podcasters.spotify.com/pod/show/whiskey-web-and-whatnot/message
Chuck and Robbie catch up with Chance Strickland, Senior Software Engineer at Replo, at the RenderATL conference. Chance kicks off the conversation by sharing that he is now working at a small startup after leaving the Remix core team. The trio discuss the benefits and drawbacks of using signals, a tool that helps manage asynchronous JavaScript. They explore how signals can enhance code readability and simplify complex workflows, but caution against potential performance issues and the learning curve involved. The conversation shifts to rebasing, with Chance providing insights into its usage and advantages. He explains how rebasing can help maintain a clean Git history and enable seamless collaboration in a team setting. In this episode, Chance talks to Robbie and Chuck about his experiences with tools like Tailwind, rebasing in Git, and the pros and cons of using signals in web development. Key Takeaways [01:57] - Introduction to Chance Strickland. [04:11] - A whiskey review: Chicken Cock Kentucky Straight Bourbon. [12:25] - Tech hot takes. [19:17] - Chance's opinion on Tailwind CSS. [37:07] - What Chance loves about Next.js. [45:59] - Why Chance is skipping leg day. Quotes [18:55] - “You can't just come in and swing a hammer at everything because you read someone somewhere said this. You have to think about all of that context and understand.” ~ Chance Strickland [20:47] - “Tailwind really is just a tool built on a CSS Principle.” ~ Chance Strickland [28:28] - “The thing that keeps me coming back is the very simple promise that React has always given, which is, your UI is a function of your state.” ~ Chance Strickland Links Chance Strickland Twitter Chance Strickland LinkedIn FrontToBack RenderATL 2023 EmberConf 2023 Replo Remix React Radix UI Chicken Cock Kentucky Straight Bourbon Nike Jack Daniel's Tennessee Whiskey DoorDash Buffalo Trace Distillery Skrewball Peanut Butter Whiskey Fireball Maker's Mark Kent C. Dodds Tailwind CSS Twitter BEM Astro GitHub Jason Miller Preact Next JS Vercel Ember WordPress GoDaddy AWS Shopify Deno Cloudflare Shake Shack In-N-Out Taco Bell Chi-Chi's Gus's Fried Chicken Cracker Barrel 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.
Conferences are one of the best ways to network with like-minded developers and find new insights to bring back to your team. Plus, you might even be able to build your entire wardrobe for the year out of free swag. Chuck and Robbie are no strangers to the conference scene, they've attended their fair share back when developers had to find them by word of mouth. Today, there are some aggregators out which apparently have every developer conference type of thing under the sun. Whether you're going with your team or flying solo, you're bound to learn something new and hopefully come away with a few takeaways. And let's not forget the cool locations some conferences are hosted in - definitely a plus. In this episode, Robbie and Chuck talk about upcoming tech conferences in 2023, the benefits of attending conferences and networking with other engineers, and how to convince leadership to invest in conference trips for their team's professional development. Key Takeaways [00:37] - A whiskey review: Nashville Barrel Company Straight Rye Whiskey. [04:49] - Upcoming tech conferences and why attendance is beneficial. [17:08] - Chuck and Robbie announce they will be recording WWW at EmberConf. [21:41] - How do you attend a conference without having to pay for it? [25:37] - Chuck's trip to Disney World. [40:19] - Better underwear options than MeUndies. Quotes [07:15] - “Going to any conference that's in a different area or potentially different subject matter than you're used to is going to help broaden the way you look at things.” ~ Robbie Wagner [17:11] - “We have been confirmed that we will be recording a live episode of this podcast at EmberConf.” ~ Robbie Wagner [25:27] - “It's important to develop your network, and in subject matters you're interested in is a great place to do it.” ~ Chuck Carpenter Links Reddit Nashville Barrel Company Javascript Confs.tech Dev Events Render ATL Slack Ember Discord VueConf US Nuxt EmberConf Portlandia LinkedIn Disney World The Villages Wes Bos ThePrimeagen Kinesis 360 Logitech Lif for Mac MeUndies Saxx My Package J. Crew Adidas Nike StockX Stadium Goods Puma Mugsy Jeans The Woman in the House Across the Street from the Girl in the Window Shrinking Play Station ChatGPT Hogwarts Legacy Zelda Diablo 4 Uniqlo Vans 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.
A few years into Preston Sego's coding career, a colleague working on increasing interactivity on the company's interface chose Ember for the endeavor. Years later, when Preston began developing his own project, he took his colleague's advice and began testing the waters with Ember as well. In 2019, Preston noticed interesting work brewing within Ember. Realizing Ember was adaptable to modern tools, Preston decided to dive back in and start building out a chat app to test the framework. That same year, Preston spoke at EmberConf and eventually landed a job at CrowdStrike where the framework of choice was Ember. In this episode, Preston talks with Chuck and Robbie about comparing Ember to React without angering either side, why he values Ember resources and has worked to create various libraries, what emerging tech Preston's thrilled to be working on, and what tech Preston's violently against. Key Takeaways [01:13] - The origin of Preston's alias. [03:13] - A whiskey review - Malahat Rye. [10:14] - How Preston got into Ember. [20:09] - The exciting tech projects Preston's working on. [26:21] - What Preston is looking forward to that's coming out soon. [29:13] - What tech Preston is violently against. [31:17] - A corn-themed whatnot. [35:04] - Why Preston loves pinochle and boring cereal. [43:09] - A deep dive on Starcraft. [47:54] - What retro games Chuck is playing. Quotes [15:04] - “I really like clinical comparisons between things because if you have any emotion whatsoever in a comparison article, you're going to upset one of the sides and you don't wanna do that.” ~ Preston Sego [23:10] - “I think the most obvious and beneficial use case [of resources] is for data loading. Just because loading anything Async is a pain.” ~ Preston Sego [26:50] - “The rfc is first-class component templates and it solves the biggest complaint that new hires have at my work where people are just like, ‘I don't know how to find this thing, how do you find it?'” ~ Preston Sego Links Preston Sego Preston on Twitter Malahat Spirits Co. Handcrafted 100% Rye FineCask Sagamore Spirit Jack Daniels React Glimmer Ember EmberConf EmberConf 2022 - Keynote Part 1 by Yehuda Katz Rails Slack Angular Twitter TypeScript CrowdStrike EmberConf 2019 - Comparing Patterns in React and Ember by Preston Sego Hooks Starbeam SolidJS Vue.js Remix Svelte WordPress Ember Could Get Used To This Ember Octane JavaScript Robert Jackson Ember Data Resources Ember Data runspired Yehuda Katz Polaris JSX Framework Laptop Apple Build-in essential ubuntu Pinochle Euchre GSAP - Green Sock Chris Coyier CSS-Tricks Trix Froot Loops Special K Wheaties Raisin Bran Crunch Starcraft Nintendo 64 Sonic Sonic 2 Genesis Conker's Bad Fur Day Raspberry Pi Analogue Recalbox The Elder Scrolls III: Morrowind Control 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 2022, the future of Ember is taking shape thanks to developers like Godfrey Chan. Alongside Yehuda Katz and other engineers, Godfrey's working on a new edition of Polaris. The project has three main goals: to align Ember with the modern npm packaging system, continue to invest and innovate in reactivity, and encourage universal design principles. Like many developers, Godfrey came to Ember from Rails. Months after chatting with Yehuda and Tom Dale at EmberConf, Godfrey was hired at Tilde and thrown into the Ember deep end. Today, Godfrey's focused on big picture developments, tackling lofty goals like developing an Ember model to navigate JavaScript classes. In this episode, Godfrey talks with Chuck and Robbie about what's to come for Polaris, solving major developer headaches, Godfrey's philosophy on frameworks, top use cases for solutions like Starbeam, and why these innovations are necessary in 2022. Key Takeaways [00:29] - A quick intro to Godfrey. [01:49] - A whiskey review. [09:27] - A sneak peek at Polaris. [16:15] - Why Polaris is about easy transitions. [20:11] - How Polaris plans to evolve. [24:54] - How Godfrey got into Ember. [27:30] - What Starbeam is. [32:50] - Use cases for Starbeam. [36:03] - Why Starbeam is necessary in 2022. [39:49] - A hobby and people-watching themed Whatnot. Quotes [14:54] - “Tools like TypeScript don't automatically just understand what's up within ember app. At least one of the things for Polaris is to figure out how we can transition to a world where we don't have those little tiny differences anymore so that when you open a project in VS Code, TypeScript just knows what's up.” ~ @chancancode [37:46] - “I think conceptually, a reactivity layer that is decoupled from the framework makes a lot of sense to me because there's just a lot of libraries and abstractions that you want to write that eventually, you want people to be able to use them in UI.” ~ @chancancode [39:31] - “I think having something like Starbeam where you can express those reactivity concepts or those annotations without making your library only usable in React or Vue or whatever is a good thing to have in 2022.” ~ @chancancode Links Godfrey Chan Ember Ember Core Team Rails Core Team Ruby on Rails Tilde Lyre's American Malt Multnomah Whiskey Library EmberConf Godfrey's EmberConf 2022 Keynote Slides Yehuda's EmberConf 2022 Keynote Slides Ember Octane Ember Inspector TypeScript JavaScript webpack Visual Studio Code Skypack ember-auto-import Embroider LinkedIn Yehuda Katz Tom Dale Starbeam React Polaris sketch JSNation Hooks Whiskey Web and Whatnot: RedwoodJS, Developer Experience, and Developing for Scale with Tom Preston-Werner GitHub RedwoodJS Hacker News Redux Google Maps YouTube First We Feast Hot Ones 90 Day Fiance Cities: Skyline Uncharted Twitch Discord ember-resources 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 2017, James C. Davis moved to Charlottesville, Virginia to work at a non-profit tech company that used Ember in their original Saas platform. While James had dabbled in Ember previously, an ask to reimplement the front-end in Ember, this time using TypeScript, proved challenging. At the time, a few engineers were using TypeScript in Ember, but the open source framework James worked on became the de-facto reference point for projects in Ember types. And the unofficial group of engineers collaborating on the project has become the official Ember TypeScript Core Team. Today, James works at e-commerce company Salsify with a front-end all in Ember TypeScript. Although setting the standard for using TypeScript in Ember, James believes there's a time and a place for types. Plus, he may have a solution for Robbie's monorepo grievances. In this episode, James talks with Chuck and Robbie about his struggles and triumphs perfecting Ember TypeScript, his real thoughts on monorepos and functional programming, keeping APIs private, and why developing Glint was a type checking necessity. Key Takeaways [01:46] - A whiskey review. [05:48] - Two truths and a lie. [12:28] - How James discovered Ember and open source. [16:28] - The purpose of the dot ember-cli file. [22:00] - When TypeScript isn't your best bet. [22:53] - How the Ember TypeScript core team is handling private API. [25:41] - How James feels about monorepos and functional programming in general. [28:57] - What tool James uses to link packages. [31:36] - How James created Glint. [39:03] - A camping, travel, and steak-themed whatnot. Quotes [17:58] - “One of the cool things about the way TypeScript is done now with Babel is we can write stuff in TypeScript and we can use Babel to basically strip out all of the type annotations and just produce JavaScript.” ~ @jamscdavis [19:38] - “Basically at this point, the only really useful thing that you need inside ember-cli-typescript is its blueprint which is different from the blueprints that generate components and Ember things.” ~ @jamscdavis [21:53] - “The bigger and more complex your project is, the more that [TypeScript] helps you.” ~ @jamscdavis Links James on Twitter GitHub Twitter Elon Musk Starlink Ragged Branch Virginia Straight Bourbon (Wheated Bourbon) It Might Get Loud Whiskey Web and Whatnot: Bringing Types to Ember with Chris Krycho Chris Krycho Ember TypeScript Core Team Center for Open Science The Open Science Framework Ember.js TypeScript ember-cli-typescript Salsify Dan Freeman Babel JavaScript Definitely Typed Peter Wagenet SemVer Glint yarn link Yalc Using Yalc for Ember Engine/addon Development Shepherd Lerna EmberConf James' EmberConf 2019 Talk Glimmer.js Blenheim Vineyards 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 episode, Robbie and Chuck talk with Melanie Sumner, web developer and member of the Ember Core Team. As a graduation gift from her Uncle, Melanie was handed a computer and told, “learn to write code,” because the future is tech. So that's what she did. With a love of language and puzzles, writing code became her thrill and, after years in the Navy, her profession. Today, Melanie is active in the Ember community, serving on the Ember Core Team and advocating for veterans entering web development. Melanie talks with Robbie and Chuck about the value of empty days, intentional productivity, Ember's evolution, React, and tips for making websites accessible. Key Takeaways [00:27] - A quick introduction to Melanie and her role in the Ember community. [01:38] - A whiskey review. [08:13] - Web dev “would you rather”. [12:36] - Why Melanie started learning to write code and her thoughts on work-life balance. [20:02] - The philosophy Melanie lives by and why she tracks the domains she buys. [24:25] - Robbie's tipping point with Ember and some shiny new toys. [29:05] - Why Ember shouldn't try to be React and the importance of accessibility. [32:29] - How to make a website more accessible. [35:54] - Today's gaming-themed whatnot. [43:07] - How Melanie survived the pandemic and news on the next EmberConf. [48:10] - What Melanie cares about outside of web development. Quotes [01:06] - “It's my philosophy to at least Buy A Coffee for people who work on open source projects that I use. I think if we all did that, the world would be a better place.” ~ @melaniersumner [14:13] - “I don't know why my brain has made this connection, but it has. I'm good at learning foreign languages and that kind of translated into me believing I was good at writing code and learning new code languages. Because it's all about learning what are you trying to say and how you want to say it.” ~ @melaniersumner [17:11] - “We develop this very unhealthy culture in web, in tech where it's like, ‘oh I have to be rockstar ninja core person who can do all the commits on all the days.' And it's like no, show me your empty days actually. I want to see where you took time off.” ~ @melaniersumner Links Melanie Sumner Ember Ember Core Team GitHub Buy Me a Coffee faker.js Microsoft Jos. A. Magnus & Co. Murray Hill Club Binny's Beverage Depot Buffalo Trace Distillery Sagamore Spirit Chris Manson Whiskey Web and Whatnot: Ember vs. React, Jamstack, and Holes in the Hiring Process with Chris Manson Raspberry Pi Touch Screen YAML Nokia AngularJS Adobe Dreamweaver Final Fantasy XI GET Lab Dracula Pro Gardener Robert Jackson ShopTalk Show ShopTalk Show on Patreon NHK WORLD-JAPAN Documentaries The Incredible Intelligence of Crows React Ember 4.0 Embroider Glimmer webpack Rollup Parcel Parcel CSS Next.js 12 Next.js JavaScript jQuery Genshin Impact Melanie's Gaming Twitter Melanie on Twitch Stardew Valley Minecraft The Last Campfire Job Simulator on Oculus Quest Echo VR Beat Saber Stadia EmberConf Vets Who Code 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.
This week we try Wild Turkey Kentucky Spirit, discuss EmberConf and Next.js and talk about Porsches vs Mustangs.
xg今年会在EmberConf会议演讲，今天赶完上传视频deadline之后我们录了一期节目聊一聊程序员参加conference的感受，以及平时工作中会遇到的各种技术性演讲。
Таймкоды: 04:40 - Opening Keynote by Yehuda Katz, Jen Weber, and Godfrey Chan (https://youtu.be/vUojP8DDPs0) 29:20 - The Power of Debugging by Samanta de Barros (https://youtu.be/d29kpZWvhQY) 36:40 - FastFlood: The Story of a Massive Memory Leak in... by Sergio Arbeo (https://youtu.be/NradLNmO9ec) 47:00 - Why JS is Coming to Ember Templates by Matthew Beale (https://youtu.be/p32zUgp4-_4) 50:50 - Closing Keynote by Nicole Sullivan (https://youtu.be/ffiDfGkZyhk) 57:00 - Why Contributing Seems Scary by Anne-Greeth van Herwijnen (https://youtu.be/5mg5ID_pIRc) 01:01:15 - Lessons Learned from Changing Careers by Kara Luton (https://youtu.be/PYZzMEfu2mo) 01:19:15 - Decorators in Depth by Marco Otte-Witte (https://youtu.be/E_grLMx7q6Q) 01:23:40 - EmberQuest: Building an Octane Role Playing Game by Dan Monroe (https://youtu.be/Ld1xnQWkqPU) 01:29:20 - Autotracking: Reactivity and State in Modern Ember by Chris Garrett (https://youtu.be/HDBSU2HCLbU) 01:40:50 - Investing in Ember by Jessica Jordan (https://youtu.be/NWcXObK2lQI) 01:55:30 - Octane: A Paradigm shift in EmberJS by Suchita Doshi (https://youtu.be/ukzyBxQ9Zsc) Мы в соцсетях: 1. Telegram: https://t.me/proConf 2. Youtube: https://www.youtube.com/channel/UCvasfOIImo7D9lQkb1Wc1tw 3. SoundCloud: https://soundcloud.com/proconf 4. Itunes: https://podcasts.apple.com/by/podcast/podcast-proconf/id1455023466 5. Twitter: https://twitter.com/ProconfShow
The panel dives into the pros and cons of writing PWAs versus writing React Native applications. We work out the definition (sort of) of a PWA and having a web application that works well on mobile and the availability and complexity tradeoffs between the two solutions. Panelists Jamon Holmgren Josh Justice Charles Max Wood Sponsors G2i Infinite Red CacheFly ____________________________________________________________ "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today! ____________________________________________________________ Links Google - Progressive Web Apps Progressive Web Apps: Escaping Tabs Without Losing Our Soul Apple's Refusal to Support PWA's Alexander Pope: ServiceWorkers Outbreak Why Was Service Worker Merged into Create React App? EmberConf 2016: Opening Keynote by Yehuda Katz & Tom Dale Picks Josh Justice: Sleeping Queens Sushi Go! Jamon Holmgren: Learn to code in 2020, get hired, and have fun along the way Charles Max Wood: Hiss King of Tokyo
The panel dives into the pros and cons of writing PWAs versus writing React Native applications. We work out the definition (sort of) of a PWA and having a web application that works well on mobile and the availability and complexity tradeoffs between the two solutions. Panelists Jamon Holmgren Josh Justice Charles Max Wood Sponsors G2i Infinite Red CacheFly ____________________________________________________________ "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today! ____________________________________________________________ Links Google - Progressive Web Apps Progressive Web Apps: Escaping Tabs Without Losing Our Soul Apple's Refusal to Support PWA's Alexander Pope: ServiceWorkers Outbreak Why Was Service Worker Merged into Create React App? EmberConf 2016: Opening Keynote by Yehuda Katz & Tom Dale Picks Josh Justice: Sleeping Queens Sushi Go! Jamon Holmgren: Learn to code in 2020, get hired, and have fun along the way Charles Max Wood: Hiss King of Tokyo
![Code[ish]](https://ivyfm.s3.amazonaws.com/i320/595618.jpg)
Leah organizes both RustConf and EmberConf, and has been organizing tech conferences for well over a decade. She talks about some of the lessons she's learned in building inclusivity and accessibility into the conferences, outside of the technical talks. Childcare, for example, is one feature she's introduced that has had a positive effect on both parents and children. Suddenly, workers don't need to fret between networking with their peers and finding quality day care. Leah cautions that the first few years she offered this space, there weren't many enrollments, primarily because attendees didn't know that the option was available. But year after year, more parents are participating. As ideas on gender are evolving, Leah has experimented with applying pronoun usage onto badges. At first, she made this mandatory, requiring attendees to provide their preferred pronoun while registering for the conference. She thought that this would help normalize the terminology, but she says her opinion has changed after speaking to several people. Instead, she provides pronoun stickers to attendees when they collect their badges at the conference. Some smaller opportunities, like building fitness activities into the schedule, also helps attendees maintain their routine and connect with other conference-goers in ways they might not otherwise be able to. Links from this episode Leah's book, Event Driven, is all about running tech conferences Leah's previous podcast, 35. Bringing Open Source to Work
Dave and Ilya kick off the Crash Log podcast with updates from EmberConf, explain how functional CSS frameworks like Tailwind might not be the best solution, talk about a new CSS linting project Ilya is working on, and explain how they use GraphQL in production at Crash.
Chase, Robert, and Jonathan discuss their experiences at EmberConf, Octane, and go in depth about Embroider in this episode of Ember Weekend.
Sam and Ryan continue their discussion from the end of Episode 54 about how much we actually rely on our test suites versus how much implicit trust we place in semver. They also talk about some new Ember Octane features as well as a data-fetching issue. Topics include: 2:00 – Do we trust our test suites? 10:00 – Breaking APIs in a changelog vs. in code 20:27 – Modifiers – they're kinda like mixins 37:17 – Named blocks 38:29 – Ember Octane & EmberConf trainings 43:15 – Fetching user-specific data in EmberMap's Video Views series Links: Chris Garrett's post on Modifiers Yehuda's Yieldable named blocks RFC Our Real-world Animations training repo Our Robust Data Fetching training repo
Chris recaps the best moments of EmberConf 2019 and why conferences are so good for teams. Brandon and Chris talk about the archetypes of developer that prefer feature work or infrastructure work, and dive into why this happens. Julia Donaldson: EmberConf keynote that talks as much about general software development as it does about Ember https://twitter.com/username_juliaD https://youtu.be/O3RKLHvpUAI?t=1152 Parsing RegEx with HTML https://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags http://www.eeemo.net/
Sam and Ryan discuss the wording behind the proposed "@tracked" syntax and how it shapes their understanding of Ember's new programming model. They also talk about 404 pages, data ownership, and their upcoming EmberConf trainings. Topics include: 0:00: Tracked properties 13:27: 404 pages 26:38: Smart components 41:00: EmberConf trainings Links: Ember Conf Component Side Effects EmberData Storefront Ember Animation Liquid Fire
Parent Driven Development Episode 013: Babies at Work?! 00:15 Welcome, Leah Silber! (https://twitter.com/wifelette) Leah is the CEO of Tilde Inc. (https://www.tilde.io/) She is also an organizer of EmberConf (https://emberconf.com/), RustConf (https://rustconf.com/) and RailsConf (https://railsconf.com/), and Ember.js Core Team (https://www.emberjs.com/team/) Member, a jQuery Core Team (https://jquery.org/team/) alum, author of Event Driven: How to Run Memorable Tech Conferences (https://leanpub.com/eventdriven/), and all around technophile. 01:08 KWu is Planning Her Son's 1st Birthday Party! + How Old Are They? Don't let first birthday parties get out of hand. Not worth it. Get a cake. Let the kid smash. Also, please stop referring to your child's age in months when they turn 2. 04:05 Babies at Work: It’s Weird that it’s Weird (https://hackernoon.com/babies-at-work-its-weird-that-it-s-weird-b285b070d456) In August 2017, Leah wrote this blog post and it was super well received. In the blog post, she talks about a lot of the objections and concern she had at first that turned out to be unfounded. It turns out, bringing her baby to work changed the mood and culture of Tilde in a positive way -- even among self-proclaimed "non-baby people". 09:26 What About The Fussy Days? Working from home can be an option especially on days like vaccination days. Having a quiet area like a conference room or an empty office gets people through short fussy spells. If that doesn't work, going home is encouraged. Leah says that having the babies at work made actually for a much happier baby! 17:56 Nursing Up to the mom! Breastfeeding in public is acceptable, and there are dedicated nursing rooms/spaces to keep it legal (and more private) It becomes normalized! People don't even notice Squatty Potty (https://www.squattypotty.com/) 23:53 Culture From The Core Stating expectations for parents/non-parents during the interview process Scaling as children age Bring the Nanny to work too! Older children must be up to date on vaccinations Becomes a routine 32:43 Does Company Size Matter? Just because there are 50 people in a company does not mean that the volume of babies is going to go up Setting a limit is an option: luck of the draw The bigger the company, the more space non-baby people have to stay away from the babies 35:02 Program Evolution Effects on Nannies Beneficial for dads too! 42:37 Avoiding Judgement Turns out, people (who aren't the child's parents) are more helpful than judgemental Pets are not babies...no, your dog can not come to work because my baby is here 48:31 Genius / Fail Moments KWu: Water coming out of the tub faucet is fascinating and acts as a baby magnet to draw them to the bathroom for a bath! (#Genius) Allison: Creating an insane schedule of hodgepodge childcare that involves massive amounts of logistics. (#Fail) Leah: Shoutout to the parents who think their kids will never walk. Her son started walking at 18 months! (#Genius) Follow & Support Please follow us @parentdrivendev (https://twitter.com/parentdrivendev) on Twitter or email us at panel@parentdrivendevelopment.com (mailto:panel@parentdrivendevelopment.com). Our website is at ParentDrivenDevelopment.com (https://parentdrivendevelopment.com). We are listener supported. Please consider Supporting us via Patreon (https://www.patreon.com/parentdrivendev) and gaining access to our our kind Slack Community. Panel Allison McMillan (https://twitter.com/allie_p) Katherine Wu (https://twitter.com/kwugirl) Special Guest: Leah Silber.
We're joined by Vaidehi Joshi to discuss her multimedia empire, conference talk prep, getting started with computer science, and the applicability of a computer science education in every day development work. We wrap the episode with live Q&A from our RailsConf audience. Vaidehi Joshi on Twitter Base CS – The Blog Posts Base CS - The Podcast Base CS - The Video Series RailsConf 2018: Re-graphing The Mental Model of The Rails Router by Vaidehi Joshi Deckset for Mac: Presentations from Markdown RustConf 2017 - Type System Tips for the Real World by Sean Griffin EmberConf 2018: Closing Keynote by Saron Yitbarek & Vaidehi Joshi Conway's Game of Life Understanding Computation: From Simple Machines to Impossible Programs: Tom Stuart Announcing Skylight for Open Source!
Organizing Technical Conferences TableXI is now offering training for developers and products teams! For more info, go to http://tablexi.com/workshops (http://tablexi.com/workshops). Get your FREE career growth strategy information and techniques! (https://stickynote.game) Summary I've been attending technical conferences for years, and I've always wondered about the hidden challenges involved in putting a conference together. In this show, four of the best conference organizers I know join me to share their secrets and stories. Marty Haught, organizer of many conferences including RubyConf and RailsConf, Jen Remsik and Jim Remsik, who organize the Madison+ family of conferences, and Leah Silber, who organizes EmberConf and RustConf. Learn about budgets, picking talks, and managing facilities and vendors. Guests Marty Haught (https://twitter.com/mghaught): President at Haught Codeworks (https://haughtcodeworks.com/), Director at Ruby Central (http://rubycentral.org/) organizing RailsConf and RubyConf Jen Remsik (https://twitter.com/jenremsik): Director of People Operations at Adorable.io (https://adorable.io/), Organizer of Madison Ruby (https://twitter.com/madisonruby) Jim Remsik (https://twitter.com/jremsikjr): President of Adorable.io (https://adorable.io/), Organizer of Madison Ruby (https://twitter.com/madisonruby). Leah Silber (https://twitter.com/wifelette): CEO at Tilde Inc. (http://www.tilde.io/). EmberConf (https://emberconf.com/), RustConf (http://rustconf.com/), and RailsConf (https://railsconf.com/) Organizer. Author of Event Driven: How to Run Memorable Tech Conferences (https://leanpub.com/eventdriven). Notes 03:12 - Getting Things Right and Having Empathy for Attendees 11:16 - Budgetary Aspects 14:53 - Planning Conferences in Other Cities 18:22 - Putting the Program Together and Selection Processes 29:25 - Crafting a Conference Proposal 31:12 - Encouraging and Enabling Attendee Interaction 40:03 - Conference Mentorship 41:26 - Words of Advice Special Guests: Jen Remsik, Jim Resmsik, Leah Silber, and Marty Haught.
Frontside alum and original podcast host, Brandon Hays, makes a special guest appearance to talk with Charles about the evolution of The Frontside as a company: where it's been, where it's going, and more hopes, dreams, and goals for the future! Transcript CHARLES: Hello everybody. Welcome to The Frontside Podcast Episode 100. Here we are. Episode 100. My name is Charles Lowell. I'm a developer here at The Frontside and I think it's safe to say, your official podcast host. With me to celebrate the 100th episode, he was also here a few episodes ago but also was here on our first episode I believe, is the [inaudible] Hays. Hello Brandon. BRANDON: Hi. CHARLES: Welcome back to the podcast. BRANDON: Actually, are you going to light your trainee badge on fire now in a bucket, in a ceremonial pyre? CHARLES: I live in New Mexico, so I think I'm going to just after this, grab my shotgun and give myself a 21 gun salute. Just in my front yard. BRANDON: There goes old man Lowell again, with the shotgun. CHARLES: I'm just going to [gun shot sounds] in my own honor. BRANDON: I was at the Alamo this weekend, actually. And I don't know if it was just because it was fiesta in San Antonio but they had a demonstration, like a musket firing demonstration where those things are basically little cannons. They're just small cannons. It's very interesting. They're very loud. CHARLES: Yeah. They're small, handheld cannons, yeah. So wait, were you – what is fiesta? Now, as someone who grew up in Central [inaudible], I feel like I ought to know this. BRANDON: I don't know. We found out by accident because we were planning a weekend to go hang out and get drunk on the riverwalk and we took our families down with some friends and then they're like, “Oh, it's fiesta,” which is like a 10-day celebration of the history and establishment of San Antonio – which I did not know is a 300-year-old institution. So, it's like one of the oldest things in this entire western United States. So, it's pretty neat. It's different. It's weird. It's like 90 minutes from Austin. There's nothing in Austin that's older than six months. Every six months we must demolish something and then build a condo skyscraper in its place. So, it's kind of neat to be in a city where it has – walking around the Alamo, I'm realizing, “Wow. Setting aside any of the historical significance of Texas independence or whatever, this is just like a really interesting very old building. This is hundreds of years old in an area where there's nothing that's hundreds of years old.” So yeah, it was pretty cool. It was a good weekend and we got to see muskets being fired. And we saw a doctor gross my kids out by talking about the medicine of the day, in full costume and showing all of the procedures and threatening my kids with amputation. And it was a good time. We all had a good time. My nine-year-old thought it was the coolest damn thing he'd ever seen. CHARLES: Really? Did the have bloody saws and everything? BRANDON: Oh, yeah. CHARLES: Was it like a reenactment of 300-year-old surgery? BRANDON: It wasn't a full reenactment. But it was a graphic description using the tools of the time. CHARLES: Wow. BRANDON: Highly recommend, check out the Alamo. Super fun. CHARLES: That does sound really cool. BRANDON: I did not expect to have a good time and it was a good time. CHARLES: Yeah. Yeah, I know the whole reenactment with the musket firing is fun. And it is, it's actually an incredible building. Although there's been a big kerfuffle about something about how they're going to preserve the lawn. But I haven't really followed that too much. BRANDON: Yeah. Yeah, I don't care about the lawn. I care about – no offense, lawn, if lawn is listening. This is not weird, how Stanley broke our brains with the word ‘lawn'. CHARLES: That's true. BRANDON: Yeah. He broke us real good. CHARLES: Yeah. I can't see a lawn without a beard. BRANDON: So yeah. So, life has been pretty good, man. Let's see. I left Frontside September, October. CHARLES: 2016. BRANDON: 2016. CHARLES: So, it's been months. BRANDON: 18. Yeah, thereabouts, right? So, I assume that nothing happened since then and if I came back to The Frontside now, everything would be exactly as I left it. My posters are still up in my room. My Bon Jovi poster. You left my bed just as I made it, like kind of unmade. Everything is just preserved as a shrine to me. CHARLES: Pretty much. I mean, we did give away the mics to Goodwill. BRANDON: No. CHARLES: We actually did not give away those mics. BRANDON: I never even got to use them. CHARLES: I know. Well, you know part of the problem is we don't even get to use them that much either. It looks really cool and it plays really well, like our podcast studio. But you know, I'm now spending 75% of my time in Corrales, New Mexico. And at any given time, people are either working from home, or working remotely. So, a lot of times the podcast room tragically does not get used. But it looks so cool. People come in there and they're like, “Wow, you guys must be really smart and technical people.” BRANDON: I realize this is probably a rote stereotype at this point, but I am assuming the only reason that you moved is that you are dabbling in the production of meth. CHARLES: Pretty much. BRANDON: It's like, I want to learn a new trade. Programming, it's just – programming, how interesting does it stay honestly for 25 years? CHARLES: Right. Yeah, and you know, we've got some good techniques. Continuous integration, deployment, things like that. Test-first. These are things that can be applied to different verticals. And I was looking… BRANDON: [Laughs] We ship meth to production on the first day. CHARLES: Right. [Laughter] Exactly. So, I figured it was a market ripe for disruption. BRANDON: [Laughs] It's probably true. So yeah, I wanted to ask you about that. You all kind of scattered to the four winds in some ways. You have Elrich in Boston and you're in New Mexico most of the time. CHARLES: Joe is in [inaudible]. BRANDON: Oh yeah, Joe moved to New York. CHARLES: Yup. And honestly, the traffic is so bad in Austin that I'd say 50% of the time, people stay home rather than drive into our centrally-located office. So, that's actually something that we're struggling with right now because the bulk of the team is still in Austin. But the office space is underutilized. Our team size now, we have eight engineers. And five of them are in Austin. Our other staff is also in Austin. So, what do we do with the office? It's a big question. BRANDON: And that's quite a cultural change, too. Because when I was there, we would tell people, “We want to be able to do remote someday. But we just don't know how to get into that culture to change the way that we do our meetings and change the way that we do standups and coordination and communication.” I didn't feel like we had the tooling at the time. So, something – I knew that at some point there would be probably a forcing function to basically catalyze something to allow that to work. And I'm curious to know what that process was like there. CHARLES: I wish I could say that there was a process other than experiencing the force of the forcing function and then being forced into it and then just kind of dealing with it. I have not taken a poll of the other remote employees of which now I am one, at least for the time being. So, I don't want to speak for them. But it was less painful than you might imagine. And the reason is because – and it's one of those things you actually gave me this analogy back, probably three or four years ago and I love it – is sometimes you're hanging off of a precipice and you don't realize that you're toes are two inches off the ground. And then all you can perceive is the precipice and you feel the weight of your own body concentrated on your fingers gripped to the ledge. And you don't focus on the fact that you're actually, the fall is only two inches long. And that's kind of what we experience with the remote culture. Now, I don't want to say we were Pollyanna about it and didn't realize that this was the step that we were taking and making sure to check in with the remote employees. But one of the things is our communication styles were already very asynchronous both for our client work, for our internal work, using mostly Slack and GitHub pull requests and issues – certainly for the development portion, very little changed. What we didn't realize is that because of our involvement in open source, we were already acclimated to a distributed work style. We just didn't really realize it. We didn't have to change much. I think where we have a lot more work to do is kind of integrating people socially and making sure that conversations don't happen that aren't available for other people to consume asynchronously. So, if you're having some architecture problem and you're sitting next to somebody, you'll take that avenue rather than let it play out in chat or over email. And there is definitely a certain portion of that, but I think we still do a lot of pair programming. That's still our major mode. I'd say 75% of our code gets written as people collaborating. And so, while those in-office discussions do happen, the ramifications circulate rather quickly. And most of those are in the context of people pairing inside the office. Does that make sense? BRANDON: Mmhmm. CHARLES: So, I don't think the office and the physical space were as much of a bottleneck as we thought they might be. And so, because of the – a lot of people did work from home already because of the traffic. And we were involved in open source. And our communication with our clients is usually – we don't currently have any clients in Austin. So, that's all to say that the transition was actually quite natural. And I think there's some strong analogies between collaborating in open source and having a remote culture in your office. I think what we need to get better about is making sure that we get the team together at least twice a year, everybody together. Making sure that people are able to understand their priorities and get to circulate around and get introduced to a bunch of different people. And yeah, I don't know. There's definitely a lot of work to be done on the non-development front. BRANDON: It's interesting. The agile approach to things is to try something. I'm starting to think the agile and the scientific method are related where it's like, “Here's a hypothesis. Here's the experiment. Here's what we think we want to learn,” and then you learn it and you take the next step based on that information. And that failure is an option. I think that's the point of agile, is to make failure safe because it's small and you're guaranteed to learn from it. Like, the point is to learn. And so, I really, I'm starting to think that those are just basically the same thing. That agile is like the application of the scientific method to product development. And it sounds like you're being agile or experimental about your work. And the trick is, like any scientific discovery, the trick is in coming back around to it and analyzing it and deciding whether this was successful or a failure based on feedback and finding what the measurement was that you were trying to improve. So, the lesson there was, “Oh, people become disconnected from each other. We need to gather everybody for an all-hands periodically.” We didn't use to have to do that because all-hands was every week, at least. CHARLES: Right. Yeah, everybody was constantly – there was a constant chatter and you could just kind of, the context was just all sitting at that one table, in that one room on 38th Street. And all you needed to do was dip your ear into that pool of context and you're set. Whereas that's just not an option right now. So yeah. I think the danger with agile is not being concentrated in your experimentation. I think what gave us our fear about saying we're going to do remote work – because I remember we always talked about it. We danced around the issue – was are we going to lose who we are? We have a set of way that we do things. And there is power in kind of sticking to the framework of the way that you do things. Because you understand it and you know it. So, when you're pushing and you're experimenting, being able to say, “We're going to – push and we're going to focus on this one area and we're going to iterate on it and we're going to keep everything else static,” it's going to be the wall that we can walk along. But we are going to push in this area. And so, I think the dangers of you doing that in all the areas of your business or all the areas of your project, you're iterating and refining, nothing ever gets done. And so, it's kind of like once you get to some ground that's solid, when you do start iterating it, you start introducing instability. So, when you go remote you have to start thinking about remote work, whereas we didn't have to think about that before. We were essentially, the feature of saying that we were a one-office company and an on-site company is we didn't have to think about that problem. BRANDON: One thing that you were just taking about is this idea of concentrating so that your experiments are happening one or two or maybe three at a time instead of trying to run five experiments at a time. And yeah, there's another danger I think in agile of seeking local optimization where you're basically like – it's like taking a bacteria and running it through many, many, many iterations that's targeting one thing and it mutates into this weird thing that only does this one thing. Or a dog breed that the whole – did you see that, I don't know where this came from but there was some scientific findings that there was a dog that was bred in ancient prehistoric times that was bred to turn a spit to roast meat over. So, they bread a dog that the whole point of this dog was to turn a spit so that people could roast meat and go to sleep and let their dog serve it, cook for them I guess? CHARLES: Wow. BRANDON: That's pretty impressive. CHARLES: I would say like their dystopia is in the past. Or certainly canine dystopias. I guess we live in a canine dystopia. BRANDON: Not in my house. CHARLES: Not at your house. BRANDON: This place is known as a canine paradise. So yeah, I think that's a really interesting point though, that limiting the number of concurrent experiments so that you can actually respond to them in a meaningful way instead of just being like, “Wow, we learned a bunch of stuff we're doing wrong. Anyway, back to the grind.” CHARLES: [Laughs] Yeah. BRANDON: Back to sucking at everything. CHARLES: Right, right. BRANDON: That kind of feeds into a lesson that I have learned very, very, very recently in the interview process for looking for my first real job in over a decade. And that process is very humbling. And one of the humbling experiences was being rejected for a job from a very notable larger former startup here in Austin. And their interview process is really buttoned up. I got really deep into the interview process and at the end of it they're like, “Oh, you're not technical enough.” And it was really, it was like, I don't know. It was hard for me to process at the time but it's super easy now to look back and go, “Oh, I was definitely not a fit for that type of job if being able to write JavaScript on a whiteboard without the aid of Google to solve problems and refactor code is like a fundamental part of what is valued in a manager there.” That's just not going to be me. But one thing I – and it wasn't a colossal waste of time. There was a ton of time and energy I invested into that specific process, but I actually derived a ton of value out of it. Because every person I met there was focused on the same thing: their culture of making experimentation inexpensive so that everything there is framed in terms of an experiment. What's the experiment here? What's the hypothesis? What's the expected outcome? How soon can we get to a place where we can validate that outcome? So, it's kind of like everything is really lean. And yes, it does – like I asked, “What's the dark side of that?” and it can lead to optimizing for a local maximum. So, you have to pause every once in a while and reflect at a larger scale. But it changed my attitude about a lot of stuff. I tend to walk around fearing failure. That's more my speed. I'm afraid of failing because failure can be catastrophic. But that's because I take big swings at stuff. When I go give a conference talk, it better be the best conference talk of my life. When somebody's like, “Oh, that was the best conference talk I have ever seen,” I'm like, “Ah. I'm so glad you said that because if you'd said literally anything else I would have collapsed internally.” You know? The stakes are so high for everything. And making it safe for yourself to fail by treating things like an experiment and working with my teammates. And so, two or three scenarios over the phone in a week when I was managing the team at my last company, somebody would bring something to me and I'm like, I instantly went to all the reasons this probably won't work. “Here's the problem with this.” And I thought, and I immediately turn around and went, “Wait a minute. Bring me a hypothesis and the experiment and how we can experiment with this thing.” And he's like, “Well, we could try this next week and we'll know whether or not this is a good idea.” And we tried it the next week. It was like organizing an architecture team because we were waiting to hire an architect. And the results were mixed for reasons I won't get too deep into. But the fact was, it gave us the freedom to try things. And I'm trying to carry that spirit around with me now. It's been really eye-opening. So, completely like, just a 4% alteration in the way that I think about problems, but it has the ability to dramatically alter the trajectory of how I solve things in the future. CHARLES: So, do you include now inside the planning process experiments? Like, a certain number. BRANDON: Absolutely. CHARLES: So, the typical “enterprise” development is we have our features, we're going to do them in this order because they're this priority. And then agile comes along and it's like, “You need to take these things and you need to break them up into small chunks so that they can be accomplished in small time slices,” so that you don't basically bark up wrong trees. Or explore [inaudible]. BRANDON: Yeah, but that's almost like a stupider version of waterfall. CHARLES: But exactly. That's exactly my point. Whereas the problem is, there's no avenue for experimentation in there. Rather than saying the entire team is marching in this one direction that meanders around and focuses in on the local maximum, which hopefully is relative to the market landscape is the absolute maximum, saying, “We're actually going to be marching in one major direction but we're going to be sending out scouts at all points.” If you were actually – I've actually been reading a lot of ancient military history. And It's just insane that an army, or even a detachment, would go all in one clump. They're constantly sending out people. Information is really, really, really important. BRANDON: That's an extremely, extremely good point. I've actually – it's so funny, because I've used a very similar description where we are trying to chart a course to this ocean of opportunity somewhere. And we can't just send the whole team in a direction hoping that the ocean is in that direction. We have to have our Lewis and Clark. Somebody has to be the cartographer. Somebody has to be the explorer. And that means that there has to be a little bit more freedom for those explorers. I don't yet know how to translate that into software terms. I just know that that's a collaboration usually at most companies between product and development. That product is doing some of the exploring of the space and then development is doing some of the exploring of the technical capabilities and possibilities there. CHARLES: So, you see it. What's interesting is you see it in product planning, kind of in the large, with the waterfall. You see it in huge organizations. They have a research and development department. And I wonder if agile kind of saw the Balkanization of your feature set into very small component parts. Can you take the exact same principle and Balkanize your research and development and integrate it into micro-iterations? We have this R&D but we're going to integrate it into our day-to-day and week-to-week process. BRANDON: I think that is a really noble goal and I think I see some people making progress toward that. The company I interviewed with does it almost to a pathological degree where there is a point of diminishing returns where you're sort of bound to this process of experimentation. And at a certain point you can only achieve incremental results. CHARLES: Some of these problems, you just need to be able to think about them for a long, long time. I actually didn't read, I actually didn't see the talk. But everything from the title, Rich Hickey's ‘Hammock Driven Development', just that title resonated with me so much. I was like, “Yes,” because sometimes you just need to be in the hammock for six hours at a time. Or in the shower. Or hiking. Or doing whatever it is that you need to do to put yourself in a zen state where you're just, your brain is slowly turning its wheels. And it can follow every lead to its conclusion without any interruption. And sometimes that process can take hours. Sometimes it needs to take weeks. BRANDON: Right. I want to kind of pivot on that. Because that's actually one of the biggest things that I've learned in the intervening time since leaving Frontside, which is creating space instead of trying to maximize – one thing that I did when I was at Frontside and then did again at my next place and I'm realizing is really has long-term negative implications is cram as much into a work day, as much output out as possible. I'm very output-oriented. I want to jam as much into my day as possible. I want to jam as much software out the door as possible. And people describe working at Frontside while I was there as one of the most intense work experiences they'd ever had. Literally, I can project that, literally just from my own intensity of trying to cram all that stuff. And providing that space for developers to ruminate on hard problems, on some of the harder problems they encounter, providing space for managers, I've learned that a big chunk of what it is to be a manager is to be available. And so, I actually want to write a sign – I was on the fence about doing this but I think I'm actually doing to do this – I have an office and I'm going to write a sign and put it up on the door that says, “If I look busy, interrupt me and remind me I'm not doing this right.” So, creating the space to ruminate or to be available for discussion, people that protect their breathing room sometimes are made fun of, especially in American corporate culture. I walked in and they were just reading a newspaper. What the heck are you doing at work if you're just going to read a newspaper? Like no, this is actually really important time. CHARLES: I think it's, yeah, it's something that I think about a lot. And I know I've shared this analogy with you before. I don't know if I've done it on the podcast. But I saw and I can't take credit for it. I actually saw it at DevOpsDays I think in 2013. There was a woman giving a talk and she was just talking about managing developers. But one of the things that she was saying was that if you looked at a microservices architecture or you looked at just even your operating system, and if your CPU was constantly pegged, you were squeezing out 100% of every time slice, instructions were just flowing through that, you're going to have a very unhealthy, very brittle, very prone to failure software system. If our microservices were not available to actually service requests, and service excess requests, and service spikes of requests, then something is fundamentally wrong. BRANDON: I want to add to that a little bit, because the thing that I noticed in managing a team where I received a ton of pressure to peg everybody out at 100% – and it jived with my philosophy at the time of, “Hey, I'm 100% guy. Everybody I work with is 100% type people. And then, let's peg everybody at 100%. This is a startup. Let's get everything going,” and I realized very, very quickly that if you don't preserve a little buffer, 20% buffer in that level of intensity, there is no ability to share resources. Everything is now a silo. So, if you're going to peg all your CPUs out, part of that thrashing is that there's no time for people to share things with each other. And people become very protective over their little silo all of a sudden. And it causes us – it's actually like the first stage of a catastrophic cultural collapse if everybody's pegged out at 100%. And literally, just dialing down the intensity is often the only thing that's necessary to get people to feel comfortable sharing some of their time with each other. You do a really good job of that with the lunch and learns. You mentioned that y'all are doing better thoughtful lunch and learns and stuff like that. It's one of those forcing ways that you can force that and say, “Hold on. Stop the development and do some stuff where you're actually sharing things with your teammates.” CHARLES: Yeah. And we do that. My biggest concern is that that actually increases the intensity. So, one of the things we've done is we used to actually be very formal about our lunch and learns. It's like, “We've got to generate content and put it out on the web so that people can see us.” We backed away from saying – we're not going to do them as often and make sure that people can actually do them. Yeah, making sure that people don't feel overwhelmed by, “I've got a lunch and learn coming up.” The point is to share something that you're passionate about and maybe introduce some really cool ideas to ferment in people's head. Rather, that's kind of the goal. There are certain things that we do very much feel interested in generating content. But I think, we've kind of been dancing around the ideas of distributed computing and IoT and what are some of the others? BRANDON: If you say blockchain, I'm going to just virtually punch you in the face. CHARLES: [Laughs] I actually didn't. Did I say blockchain? BRANDON: No. I just was waiting for you to say it. CHARLES: Okay, no. I haven't. Well, because that's – but it is distributed computing in Web 3.0, right? These problems – and we're actually going to be podcasting about this next, so in two weeks you can tune in to listen to us talk about blockchain but in the context of distributed computing – and one of the things that we're seeing is now we're starting to pay the price of outsourcing all of our lives to these central services like Facebook and Google and Amazon. And I think now they're starting to build a credible and more mainstream movement to wrestle back that control and say, “What would it mean to have software as a service that wasn't actually dependent on some central thing?” What would it look like to have Slack where it's Slack that looked like email? Where everybody had their own email server, maybe not a bad example. But you've got an email at Gmail or Microsoft or Yahoo or your company-run that's big enough its running its own Outlook client or something like that. Email is actually a really great example. Now probably people are going to crucify me for saying this, but I think it's actually a good example of a distributed system that's worked well. I own all of my email. All the messages that you send to me, I own, and all the messages I send to you, I also own. But you also own the messages that I send to you. Information is duplicated. And it's fine. If I send you an image, yes it's on your hard drive or it's on your Google Drive. You send a message to me, it's got an attachment, I also have that attachment. But the point is that we can each own our email and we each own our email service. And we can change it up. That's not possible with Slack. That's not possible with Facebook. That's not possible with all these other sharing platforms. All of them are controlled by this one thing. And so, I think that that's something that we've been exposed to through the lunch and learns and I'm actually certainly very excited about it. It's not something that we're going to be investing in immediately. We're kind of dancing around that idea. But that's something that's come out of that. So yeah, we've kind of refocused it on, what is something that you feel good about? But back to the original point, I think that this is something that applies on all fronts. If you have a business where you can't actually take opportunities because you don't actually have people – so there's maxing out at the individual level, filling up people's workspace with client work or filling it up with what have you or having them work nights and weekends. There's individual maxing out but then there's like maxing out of your business. So, if you have – we're a consultancy – if you have 100% utilization or you're shooting for 100% utilization, that everybody is placed on a project, that is a brittle and unsustainable system. BRANDON: I wish you would have told me that 18 months before I left there. There were like two years where we were at 100% for two solid years. CHARLES: Yeah, yeah. We're still at 100%. BRANDON: Yeah. I wonder what would have happened if we'd had a little, if we had figured out how to build in space. CHARLES: Part of the problem – so, here's the thing though. Space, nice space costs nice money. BRANDON: Yeah. CHARLES: And so, that's the thing, is you have to charge more. And you have to say, “We are going to be more expensive than other people.” You have to be dedicated to be at the forefront of a cultural battle, essentially. In the same way that people were with testing, where it was very [controversial]. BRANDON: Yeah. You were with CI. CI is a given now, right? CI is… CHARLES: Yeah, like [inaudible]. BRANDON: This idea was semi-revolutionary when you and I were talking about this in 2012, 2013, that we ship to production on the first day. We don't even start building software until the CI system is set up. The first thing we do is set up Jenkins and tests and get everything, the pipeline working. And now, that's just what people do. By and large, that's how software is expected to be built. And the tooling has really come up around that. But that was an expensive way to sell software five years ago, that, “Hey, this is going to cost more than bringing in Cowboy Bob and having them come jam in your console for 40 days and ship a bunch of stuff that then will most likely collapse and you won't know about it and Cowboy Bob has ridden off into Juarez, Mexico.” CHARLES: Right, with his saddlebag stuffed with your cash. BRANDON: Yup. CHARLES: Yeah, no. So, you have to – the problem is, you know when you pick these battles, you need to be prepared to fight the war of attrition of they're not going to be able to perceive the value for six months, a year, right? You're going to have to ask your clients to bet on this strategy. And it's a bet. And you're going to have to say, “It's going to pay off in six months. It's going to pay off in a year.” And you're really going to start raking in like five years. That's when… BRANDON: Yeah. Try making that pitch to a startup founder that is borderline, that is on the verge of an anxiety attack, and you can kind of just figure out what my last year was like. And the… CHARLES: So, that's one of the reasons we don't really work with startups anymore. They have a five-year plan, but not really. BRANDON: Yeah. CHARLES: They're fighting for their survival. And they're fighting for the opportunity to have a legitimate five-year plan. And so, in that sense, it's maybe not a good fit for the way that we develop software, because you either need an extraordinarily prescient founder who has been through this before, knows the true costs of software development, and is pretty well-funded so that they can actually – because we're more expensive upfront, like a lot more expensive upfront and so sometimes they flat out don't even have the cash. And that's something that you can make a quick, “It's not a good fit,” but then there also needs to be this understanding and an acknowledgment that what you're really shooting for is your five-year dividend. BRANDON: Yeah. It is really interesting, the turn that occurs when a company finds product/market fit. By then it's too late to fix the problems. So, it's really tricky to find the balance of: how much energy do you put into the success case for a company before they have product/market fit? How much time and energy do you invest in betting that this is going to be successful versus betting that if it is successful, hopefully we'll have the time, money, and resources to redo a bunch of the things that we are going to have to apologize for later? And I think that's what makes… CHARLES: Right. Like, where do those two lines cross on that graph? BRANDON: Yeah. Because you and I have both seen startups completely sunk by somebody who was overly focused on building a scaleable architecture in a company pre-product/market fit. That is a common story where an engineer that doesn't understand the business value of what they're doing and only focused on “quality” will absolutely torpedo, they'll chew up your first million and a half of funding and leave the place in just a smoldering pile of ashes at the end. So, it is tricky. It's totally a difficult thing. But I think coming back to your point of being sort of a vanguard of cultural, the tip of the spear on somebody's cultural changes – DevOps would be one. People that were really investing in DevOps culture in 2010, 2012 saying, “Hey, this, automation, is the future of how software gets shipped, maintained, observed, supported.” And so, now it sounds like, so what is your big bet for the future? CHARLES: Boy. That's a great question. There are two bets. One you're going to like, one you're going to vomit. BRANDON: [Laughs] CHARLES: But that's okay. BRANDON: Yeah. I don't work for you. CHARLES: You need to serve, what is it? You need to serve the spiny urchin with the yellow tail. BRANDON: Is that a Sonic the Hedgehog reference? CHARLES: It's just a sushi reference. BRANDON: Oh, okay. CHARLES: Some people don't like urchin. Or maybe they don't like eggs. What it like, the roe that come with sushi. But they're on the same plate. So, I would say the first one that I've been thinking about a lot is optimizing for capacity and being able to handle spikes and not being at 100% both for people and for utilization. I think that's something that is – I don't see how you could have a healthy software development process if people are completely spiked on delivering, heads down delivering features for product. That is something that I'm betting on. Essentially, you could call it the 25% time but it's really about having excess capacity to exploit opportunities as they arise. And then being protective of that excess capacity. Because you can exploit an opportunity. Your CPU has a spike load up to 100%. But then make sure you [inaudible] down to 50% at some point, or 75%. And so, I would very much like to see Frontside have a bench where people can rotate out and they're working on different stuff that are not even client-related. They can recharge their creative tanks. They're not going to be idle. BRANDON: Yeah, I've really come around on – and I really hated this at the time – but I've actually come around to the thoughtbot style of working on a product where – because owning and managing a product and developing it as a side quest, the goal is not necessarily for that product to catch fire and become the world's next big thing and to replace your consulting revenue. The goal is to give people a sense of – think about all the stuff that you've learned in your side projects that you went back and brought to your work. And some of my biggest gains as a developer have come from having a side gig of some kind, some side project that that's how I learned Ember. That changed my life. And I would never have gotten to try it if I was waiting for somebody at work to tell me it was okay to do it. So, it's about taking that permission back for yourself and giving yourself permission to try stuff. So, it could be something like that, or it could be the content stuff that y'all do. Or it could be conference talks. It could be whatever. But the goal isn't necessarily to produce things that have a direct return. It is to create the space to allow people to flex some muscles of creativity that you may not get in your day-to-day work. And that's very difficult to offer to people in any company. Now having explored startups and larger companies, but I would say especially in a consultancy where the exchange rate is dollars for days. It's sort of like when I was freelancing. I could feel every vacation I took draining both real money and opportunity money out of my bank account. That's such a hard, difficult thing to do. And so, you actually have to create the budget ahead of time and say, “This budget is allocated to these things and it's already spent.” Anyway, that's really tough to do. CHARLES: It is hard. BRANDON: If you can exercise the discipline necessary to do that and create the environment for that, I would say you're ahead of 90% of companies in the industry. CHARLES: Yeah. Yeah, so that's something I definitely want to bet on, because I think that's where the best things come from. BRANDON: Okay. So, what's the thing I'm going to hate? CHARLES: Functional programming. BRANDON: Oh, Charles. Okay, I have to stop you. Do you know what I'm doing? Did I tell you this yet? That I am participating. When I told them this, I was like, “Charles is going to have a field day with this,” but I am participating in a Haskell study group. CHARLES: No way. BRANDON: And I'm like four exercises into this thing. I have to do four more for next week. And I'm like, “This is bizarrely easy, actually,” after as much JavaScript as you and I did in sort of a functional style and then learning Elixir. And I was like, “Wait a minute. The case statement is, Elixir just stole Haskell's case statements.” So like, so far I'm not finding functional programming to be onerous. Or anyway, but we'll see when we get to the static typing. But so far, I'm not getting any of that in the earlier lessons of the book. CHARLES: Yeah, the static typing. But the thing is, you can do – it's not 100% necessary. It isn't in Haskell, for sure. But I'm surprised. What inspired you? BRANDON: We have an architect at the office that was like, “Hey, I want to do sort of a functional programming book club.” So, we have a Slack group for FP study group. CHARLES: Are you doing ‘Haskell: From First Principles'? BRANDON: No. That one was a little actually intimidating. CHARLES: Really? BRANDON: Yeah. It gets into the lingo a little early. And we're doing one called ‘Get Programming with Haskell' that is a little more – ‘Haskell: From First Principles' is kind of math-oriented. So, for somebody with a math background but not necessarily a programming background, it's perfect. But for somebody with a programming background that is just trying to understand functional programming principles using Haskell, ‘Get Programming with Haskell' is actually a really great option. CHARLES: Okay. Actually, I have not heard of that one. BRANDON: The stuff that I'm looking at looks just like Elixir. So, it's early. But it's very comfortable so far. CHARLES: Yeah. So, this is the thing. It's all a matter of messaging and marketing. Because I really feel – so, it is like there are a lot of behaviors that you see sometimes in currently entrenched functional programming communities that I think are, well I think they're objectively repulsive. But I think they're also pragmatically repulsive and that they repulse potential community members. But I think a lot of it too is people talk about these things that are, they use abstruse terminology. And they're kind of chattering back and it's very jargon-oriented. And there's just – people operate with a different set of concrete things. So, when you and I are talking, for example we might talk about a Rails controller and that's a very concrete thing. You know exactly what I'm talking about. It's something that you have held in your hand, literally. Remember when we got that Rails codebase that came as a thumb drive? BRANDON: Yes I do. CHARLES: But the point is you knew that this had a Rails codebase on it. There were any number of controllers. And when I say controller to you, a controller is an abstraction, but not really. Once you work with an abstraction long enough, it becomes concrete. And so, part of the problem is just a mismatch in language where people are talking in their world about concrete things, things that you can touch and you can feel and you can exchange and they're very relatable. But from another person's perspective, they're talking about something that's totally abstract and totally opaque and totally what have you. And so, I feel like yeah there's a huge mismatch there. And that's been one of the big bets. The other big bet that I'm making is on this trying to make what is currently abstract to JavaScript and Ruby developers be concrete. And I think that we're going to see type classes like functor and monoid and semigroup and all these things, they're abstract to you now, become concrete over the next five years. And so, that's something that I'm betting on. BRANDON: Check out this – and I know that you have a good relationship with the people that did the other book, but it really does tend to come from more of a mathematical background. And this one actually does speak to people with JavaScript, Ruby, Python experience. Like, “Hey, here is how you will perceive these things.” And so, it's much more approachable. I'm still in the first unit of the book. But having sort of tasted it a little bit, it's like, “Wait a minute. This is actually extremely familiar and not super intimidating.” CHARLES: Exactly. And that was kind of – so, I read the other book. And I think I was also aided by the fact that I tried to learn Haskell probably for five times in the past. And so, I also had the benefit of jumping against the wall with the velcro suit and bouncing off four times. And fifth time, it stuck. So, I had just temerity on my side and a general feeling. But that's definitely – the lesson that I actually came away from reading that book was like, “Oh, there's a mismatch in concrete concepts.” It's using concrete concepts that are concrete to people with a CS background or mathematics background, or people who are brand new. Honestly, people who are brand new to programming who don't actually have JavaScript or Elixir or Ruby or any other thing to lean on, I think that the First Principles book is actually pretty decent for them, too. Because they don't have anything to compare to. BRANDON: They don't have anything to unlearn. CHARLES: Yeah, they don't have anything to unlearn whereas one of the things I took away was I was like, “Oh, man. I'm using semigroups all the time. This is something that I do constantly.” When I'm coding, I might do it eight times in a day. I just didn't have a name for it. BRANDON: Right. They're like design patterns, just at a micro level. CHARLES: Yes, micro-design patterns. Yeah, it's like a RESTful architecture for your code. In REST you only get five verbs. There's five methods, man. That's all you got. BRANDON: Okay, so those are two bets. And I want to cover one more thing because I know we're super overtime. But the last thing I want to be able to say about talking about what we've learned since I left Frontside but I want to put a bow on that. So, the two things that you're betting heavily on are functional programming as a basis for solid architectures in the future, like the work that you all are doing. And… CHARLES: I would also like to say, and this is something – let me just add one more thought. What I don't understand, and this is in no way like, I don't understand people who do the, “Saying goodbye to framework X.” That's not me with object-oriented programming. BRANDON: Often abstractions are like oversimplifications but they're really useful, sort of like Rich Hickey's Simple versus Easy. Like, “Hey, there's a lot of promise with that metaphor. It's a leaky abstraction but it's a useful abstraction.” And Gary Bernhardt's ‘Functional Core, Imperative Shell' is a leaky abstraction but it's a useful abstraction. If people haven't seen or experienced that, it's pretty good. The subtlety is that these are tools that are suited to certain situations a little better. And those same situations can exist in the same codebase, can exist in the same program. CHARLES: Yeah. I still, I love Ruby. I adore it. And in some ways, I've been researching functional programming and it's been going on for the last four years. So many times, people are like, “Oh, I just can't stand this tool anymore.” And I'm like, “Man, I still love Java.” I don't understand how learning to love something decreases your love for something else. BRANDON: That happens the first two times that you fall in love, is that you feel like you have the old thing less in order to love the new thing. And then you start realizing, “No, you are allowed to fall in love with new things without falling out of love with the old things.” I would almost use that as an interview question. Is there some way to use that as a way to gauge somebody's actual real concrete maturity as a developer? Because that is a mark of maturity. CHARLES: Yeah. I mean, you could say, “What's some tool that you no longer use that still informs your day-to-day routine?” BRANDON: Yeah. I guarantee you, people that were doing Smalltalk in the 80s think about it all the time. CHARLES: [Laughs] Yup. Yeah, exactly. Exactly. BRANDON: Alright. So, I want to cover one last thing. CHARLES: It's part of growing, right? If you're going to grow as a developer, you can't be shrinking at the same time as you're growing. Otherwise, you're like the same size, just in a different place. BRANDON: However, you don't get any Medium think piece points. Nobody does the one clap, two clap, forty, for blog posts that are like, “Why I'm still using some programming language but using one a little more than I used to use and this one a little less.” CHARLES: [Laughs] Zero claps. BRANDON: Yeah, zero claps on that think piece. I just want to cover one last thing before we wrap this up, and it is the fact that Frontside, the biggest gift that Frontside gave me was the mission for the next 20 years of my career. I think it could change, but I'm pretty confident about this, at this point. Being approximately 20 years into my career, I feel like I kind of have a feeling for what the next 20 years is about. And the Frontside really drilled that into me and helped me focus it and helped me dial it in. And it is this idea that there is an incoming generation of programmer that thinks about things differently than the previous generation in a pretty radical way. Because the previous generation all came out of the same schools. They all look the same. They all have a similar shared set of values in general. They created the Sil- – you know, I'm not actually going to be overly critical of the Silicon Valley culture that exists now. It is a result of the type of people that came out at the time that value innovation over almost anything else. People talk about ripe for disruption. The fact is, that has been an engine of economic growth and progress for society in a lot of ways that has a lot of costs that weren't factored in by a bunch of people who all thought the same way. And now, with people coming through code schools and people coming from different backgrounds and people coming from different environments, they're looking at programming and software as either an economic opportunity or something they didn't see that they could possibly do. Those doors were not open to that group of people before. There is a natural influx of people but many of them are bouncing out because they're not finding that group of people, they don't have a shared enough set of values that the people that are new are coming in and finding job opportunities, finding promotions, finding leadership positions. And so, I know now that my mission over the next 20 years of my career is to create those opportunities for people that have different backgrounds from me and different experiences. The career tracks, the promotions, endorsing and supporting and kind of sponsoring this incoming group of freshmen into our industry that come from different places, different backgrounds, different problems that they care about solving. They want to figure out how to solve the Flint Michigan water crisis instead of delivering socks to people in Silicon Valley, you know? So, I feel like we're at the beginning of a seed change in the value system potentially of our entire industry. But that's going to require training up the next generation of technical leadership. And I felt like the best thing I could do right now is learn to be a better manager, because I really like that job. And it provides the opportunity to find, hire, sponsor, promote and encourage those people to move into their own leadership positions. There are lots of other things that a person, you could be a VC and care about that stuff. You could have lots of different positions and put yourself in a position to do that. You could be a consultancy owner. You know what I mean? There are jobs that you can do that you can accomplish that goal. But it gives me such a sense of direction that when I'm looking for a job, I was looking for a home for that mission rather than just the thing that I felt like doing. Like okay, this job is important to me because I need it to house me and this mission so that I can support my family but have enough emotional overhead to participate in community stuff, but enough ability to lead within an organization, enough influence to actually push that agenda. So that the next generation of people are making better companies. So anyway, all of that came out of my time at Frontside where you and I sat around talking about: how do we build a place that is like a monastery? These were your words. You remember this? We want a monastery for code where people can just focus on becoming better developers. And underneath that though was the sense that this was a place of opportunity for people that might go somewhere else and stagnate as a developer. This will be a place to accelerate them. And so, that kind of spun me out and accelerated me into my mission. So anyway, I just wanted to point out that that was like, with a bullet, is the most important thing that came out for me in my time at Frontside, was that it clarified for me what I was trying to accomplish with the next couple of decades of my career. CHARLES: Wow. Well, that's fantastic. You definitely did a lot of that both here at Frontside and I mean you're continuing to do that. I definitely want to see more public speaking from you. Maybe some [inaudible] perfect. [Inaudible] at EmberConf was actually fantastic. But I mean, you're also able to help people find their mission, too. Like the talks you have at Keep Ruby Weird and even really, the first talk you gave at LoneStarRuby about moving Ember. It's always, how do I adapt what I'm feeling to my overall mission and then relate that back to technology? Man, I just can't wait. I can't wait. When are you going to hit the road again? BRANDON: I think this is the year. I'm going to start thinking about this stuff. I'm looking at the stuff that I wanted to talk about on this podcast and I was like, “Oh no, wait. That's like a dozen podcasts.” Like, no. Absolutely not. Not possible. I will say, I miss so much, this time that I spend with you. I don't want to let it go. I really miss working with you. I really miss having these conversations whenever I want. This has been a very, very special privilege for me to be able to do this with you today. And congratulations on Frontside continuing to thrive and grow and become more of its own entity and more of its own special flavor. And it makes me really happy to see the people coming out of there, that it's still doing its mission of making great software by making great developers. It makes me real happy. CHARLES: Yeah, yeah. Hopefully we can keep on keeping on. I do miss working with you. I miss the conversations that we would have in the kitchen which are basically an extension of this podcast. But I also, man, I really, really, really, really like working with the group of people that are here today. I've just seen them producing just some absolutely amazing things. And honestly, there's a selfish aspect to it, too. I get stimulated. My own thinking and learning is stimulated by the people that I work with. And like I said, the whole side note we had about distributed systems and IoT and just a constant ferment of things. So, I still really, really, really enjoy it. BRANDON: That makes me happy. CHARLES: And I'm really glad that we got to kick it today. BRANDON: Yeah, me too. CHARLES: I thought you were going to say that your 20-year mission was to have your perfect Emacs initialization setup. BRANDON: Oh my gosh. Some of these days, I'm going to figure out RuboCop. CHARLES: Actually, do you want to pair on that? BRANDON: Yeah, let's do that. CHARLES: Alright, everybody. I'm going to sign off. If anyone wants to continue the conversation, obviously you can get in touch with Brandon. He is misspelled @tehviking on Twitter. T-E-H-V-I-K-I-N-G. Always come at him. BRANDON: Don't @ me. CHARLES: [Laughs] BRANDON: I work for a really cool company and if you ask me about it on Twitter, I'll tell you all about it. CHARLES: Awesome. And we of course are Frontside. You can get us on Twitter at @TheFrontside or just drop us a line to contact@frontside.io. And we would love to talk to you more about this podcast and all the wonderful things that we do here, which includes building custom software that you can stake your future on, that's going to be good for the five-year outlook. So with that, goodbye Brandon. Goodbye everybody. And we will see you… BRANDON: Bye Charles. I love you. CHARLES: Me too.
Oli Griffiths joins Sam and Ryan to talk about his experience using typed languages, what kinds of benefits static could bring to the Ember developer experience, and his upcoming EmberConf training on Broccoli.js.
Toran Billups: @toranb | GitHub | Blog Toran Billips joined us for an insightful conversation regarding glimmer-redux: Predictable state management for Glimmer apps. Resources: Glimmer Redux Demystified Talk from Tom Dale on glimmer internals (contrast with Preact made in this talk) ember-redux Glimmer progress report that mentions the migration to Glimmer 0.8 (Big Changes) Blog post following EmberConf 2017 that announced GlimmerJS (for the Ember dev) The Frontside Podcast 086: Routing in Ember with Alex Matchneer An ember-rideshare Blog Post A Rollup plugin for glimmer-redux RollupJS Transcript ELRICK: Hello and welcome to another Frontside Podcast, Episode 89. My name is Elrick Ryan, a developer here at the Frontside. I'm joined by Wil Wilsman, another developer here at the Frontside. Wil, how are you doing? WIL: I'm good. How are you? ELRICK: I'm great, man. I'm excited for this podcast that we have coming up here. Today we are fortunate to have with us a podcast elite member now, Mr Toran Billups. Toran, how are you doing? TORAN: Oh, man. I joined the elite platinum club or something? ELRICK: Yes, you are in the platinum club right now. I think this is probably what? Your third or fourth episode by now? TORAN: Oh, yeah. I think the fourth. ELRICK: Oh, yeah. You're in the elite club right now. You are a Midwest programmer and I hear there is a difference between a Silicon Valley programmer and a Midwest programmer. Could you tell us about what the difference is? Because it's the first time I've heard anything about this. TORAN: Admittedly, I stole this from a very popular developer, Justin Searls who spoke at length one time on a podcast, not too different in this one about his experiences in consulting for companies, who are more in the startup phase or a company that you'll find in Silicon Valley that is mostly just trying to test an idea and get to market, versus his experience for finance or insurance companies based out of the Midwest. I like that idea because my experiences have taught me. I'm a little bit happier when I'm working for companies that are interested in quality or attributes of quality and view the software longevity as mission-critical versus a software that is really just a byproduct of an interesting idea and if we validate that idea in a market, we can always rewrite the software later. Midwest, I guess the short version is we care about the work we're doing and we understand that rewrites are difficult, if ever possible. ELRICK: Interesting, so the Midwest seems to be concerned with long term goals. TORAN: Yeah, I think sustainable -- ELRICK: Sustainable software, at least. TORAN: Yep. ELRICK: Today, you are joining us to not only talk about the Midwest and the beautiful Midwest programmers. You're here to talk about Glimmer Redux. TORAN: Glimmer Redux is a little library I wrote, I think last month. I should start off by asking you guys if you're familiar with a Glimmer JS or if you've heard of that. ELRICK: I've heard of Glimmer JS. I haven't had an opportunity to play around or mess around with it yet. I don't know if that's good or bad because I'm just really busy but I really want to get into it. Wil, what about yourself? WIL: I've read through the docs but I haven't played with it at all. It looks really nice. TORAN: I think the joke that was off the air last time I was on, Wil you might remember this. You're on that podcast with Charles. I said something like, "I'm not young enough to actually be working with Glimmer," and I felt that way for a long time because one thing you should know is it's a pre-1.0 and if you guys have ever worked in a pre-1.0 ecosystem, myself the biggest experience I have to draw from is really pre-1.0 Ember and there were some big changes before 1.0. You can imagine back to that throwaway comment about being very young, there was actually a big change in Glimmer itself recently where they decided to... I don't know if the right word is Pascal Case but they've literally gone away from that 'dasharized' components. It used to have 'foo-bar' and in your template, you would actually see lower case of 'foo-bar' and now that would just be all uppercase. Well, not all uppercase but 'FooBar' and no dash, which is a big change recently. WIL: So a class case, kind of like React or JSX. TORAN: Yeah, exactly. They have a great blog post. Actually, we can reference that in the show notes, about some of these big changes in that release. It was Glimmer 0.8 so it's still, it's making its way to the 1.0 but I got interested in this really for two reasons in the last couple of months. The first was, if you actually go build something with Glimmer -- and this is my experience -- is for the novice programmer just taking a look at it, it's really just a way to use web components to build an application. There's no routing. There's no opinions, really. There's no services like you have in Ember or contexts like you have in React. The first challenge you run up against is when you get beyond a single component or two components and suddenly, you need to share some state across this application. How do you do that? If you guys have some experience, I know the Frontside, with React, if you're not using MobX or Redux or something like that, a lot of times you'll see this pattern where you're actually passing a piece of state through the entire tree or the shared state through a big part of the component tree. Of course, that becomes painful as the application gets to a certain size. One of the things I thought about is if I was to build a real application, the one in mind that was certainly not built yet because I'm not using Glimmer at work but I always think about the ember-rideshare. I know you guys had Alex Matchneer, recently talking about routing and Alex mentions in that episode this challenge for the Ember router today, to be reactive to server-sent events. In the case, imagine you have an Uber or a Lyft app and after the ride is over, the server wants to send an event, maybe and then the app needs to react to that event -- sending you maybe to a new route or sending you back to the map to pick a new ride. The gist of the ride share app is, and Alex, of course I would reference anyone to that podcast, he does a lot better job describing the routing challenges and those are a little bit out of scope for this discussion, but imagine you're going to build an app that ambitious and you're going to build a Lyft in Glimmer. What I found was missing is really what we take for granted in Ember, which is the Ember Service and that is like a singleton or an object that allows you to have a piece of state and then share that state around by injecting that service in only the components that need to reach up and grab that shared state. Redux, which I know your audience is pretty familiar with but a quick recap, Redux is just kind of a global JavaScript object that has state and there's often a library that lets you connect to that state so you can use it in your various components. Glimmer Redux is no different than that, actually. It just allows you, instead of having to create maybe one global JavaScript object and kind of pass it down the hierarchy, you can instead just connect the components that need to be aware of Redux. The ones that don't, of course they just don't connect. ELRICK: I know that you had a hand or build ember-redux and now you build Glimmer Redux. Were there any challenges between building those two different add-ons into two different ecosystems? TORAN: I should take one minor step back because that question is a great segue. I didn't want to touch on the second motivation for Glimmer Redux, which is actually really closely related here and that is, of course I did write ember-redux so with every open source project, there's a little selfish motivation here. I imagine last year when Glimmer was announced at EmberConf that there would be a story from Glimmer to Ember. The idea being you're a small startup, you just want to get your web application going, you don't necessarily like all the big conventions or you just don't think you need all of Ember when you get started but six months down the road, you're suddenly looking at tree shaking and lazy loading with engines and you're thinking, "I wish we had that." Realistically speaking, like today what would a transition for a Glimmer shop to Ember be. Honestly, I think it's tough without a library like Glimmer Redux. Of course, I wrote this with pretty much a mere of the connect API. If people were to check out the ReadMe of Glimmer Redux and ember-redux and you looked at a connected or redux-aware component in both of those cases, the best case scenario is the only difference would be in the import. Instead of import connect from a Glimmer Redux, you would be import connect from ember-redux. Everything else underneath, all the ecosystem of Redux that you can use and both are completely compatible. In fact, if you were to move, imagine you Ember new and you're thinking, "I got to move my Glimmer ride-share to ember-rideshare. Since Redux does a good job in encapsulating all of the state transformations in vanilla JavaScript, you don't have to really worry about the differences between a number object and not having Ember object. After you did Ember new, essentially you would copy over your components. For the most part, they're still template-driven. A lot of handlebars and a lot of TypeScript to JavaScript is the biggest mismatch you would have between Glimmer and coming over to Ember, of course but there is Ember CLI TypeScript or Ember TypeScript, I think. Long story short, you essentially copy the directories of your reducers or middleware from your Glimmer app over to Ember and there should be no changes necessary at all. ELRICK: I know that is the dream that you touched on, I think they phrase it as 'NPM installing your way up to Ember.' In your perspective, do you think that is going to be a thing? Is it going to get there? What are your feelings on that? TORAN: I would definitely be in trouble if I didn't say upfront that I'm not on the Ember core team. Sometimes, people get that confused for some reason but I don't speak for the core team and I'm not really privy to anything. But I do think that the core team has this in mind that there will be a set of NPM installable modules that eventually land you the full set of tools and abstractions that we see in Ember today. A big one that I'd hit on earlier is services. What will services or the Glimmer 0.5 version of services look like when it lands and what about routing and those sort of things? This was really my personal take on how could I make that migration right now without asking permission from the core team. In a Glimmer Redux, I think honestly it offers a good 80% of that. You still have the routing issue, which is a little challenging and you have the TypeScript issue, which you just have to be aware of some of the limitations of using TypeScript in Ember. ELRICK: That's an excellent point that you made because when people outside of the core team take it upon themselves to then try to implement different things around the ecosystem, that can then be motivation or an example for people outside of the core team to see like, "This is a possible solution to a goal we're trying to reach." Kudos to you. TORAN: Back to your original question about 15 minutes ago, what was different about the ecosystems writing ember-redux the add-on and Glimmer Redux, which is... I don't really even want to call it an add-on. I kind of label it as a Glimmer library but to your point just a second ago, when I got interested and saying, "I wrote Glimmer Redux, now I want to share it so other Glimmer authors don't need to copy/paste this file," and the first resistance I hit up on is there really is no Glimmer library or Glimmer add-on. You could write an Ember add-on because if you guys get into Glimmer, you'll find this as well. There are certain hooks that are used in the Glimmer build process where Ember add-ons like Ember CLI SASS can be used from Glimmer. But the challenge I had using an Ember add-on, of course is that this wasn't an Ember component or anything Ember related. It needed to really be test driven from a Glimmer apps. Really, if you went to NPM installers, what you're pulling in is effectively my Glimmer app that also exports publicly this connect function, which is not necessarily you're leading, maybe anything to core team that could happen. A big reason for that as well and one of the challenges building this, is that Glimmer right now, after to try to emulate my 'quasi-success' in doing this, is really bring your own build system, to actually share a Glimmer components or internals like this connect API that Glimmer components can use. What I mean by that is on the website, one of the challenges I faced was -- this isn't a knock against the core team, this is just my honest experiences -- when I read the Glimmer JS docs and it says right in the installing guide, "Glimmer uses Ember CLI, this battle-tested command line interface from the Ember project." Now, pause right there because again, not to beat up on the Ember core team or anything but assuming in that one sentence that they're using Ember app, what I noticed when I opened the Ember CLI build file is the project was actually a Glimmer app. Now, I did a little bit of digging here and I think this is validated, at least back when I worked on Glimmer Redux last month, that Glimmer app is not like inheriting or pulling in a bunch of shared code from Ember app. It's actually a completely separate build tool. As part of this process, I actually for the first time had to go through and learn Rollup and understand how the Broccoli process is kicked off, how both Rollup and Babel are used to build this and then how to apply some convention. If you guys are familiar with Ember, you have this add-on directory and an app directory. The guidance from the Ember team is around how to structure add-ons. Of course, you write all of your kind of private-ish or add-on code in the add-on directory and then whatever you think will be public, you export from the app directory and that sort of merges it into the tree when the application is built. People are allowed to use your code but then also, they can override that code. One of the challenges here is if I wanted that exact same API and I want people to make this migration from Glimmer to Ember using Redux, I had to actually invent that convention so I wrote a Rollup plugin and it's all listed in the docs here. One of the strange things people who are checking out Glimmer Redux hit me with first is, "I see a Yarn installed Glimmer Redux but then second step is installing this Rollup plugin. What's the deal?" I think it is because most people assume the Ember CLI you're using is identical and somehow, I should have written an Ember CLI add-on for this. I think that was the biggest learning curve and people should just be aware of that. If you're interested in sharing code right now, there is really not a baked story and that's okay. It allows people to innovate. Of course, the innovator's dilemma being that, I don't really know without [inaudible] some migrating RFC or getting involved with the core team, how to make that thing. I ultimately just hope the core team improves this and I'm sure they will but for right now, I don't really want to wait around for it. ELRICK: Got you. What is Rollup, for people that are not familiar with what Rollup is? I'm sure everyone is probably familiar with Babel by now because it's used everywhere but what is Rollup? TORAN: Embarrassingly, I don't know the technical... But I would say the role that you can see, if you actually step through the node process as your Glimmer app is being built, is it helps really condense the overall build size. What I see is it's essentially traversing like Browserify in some ways. This is, again just my primitive look but it traverses all the imports you have and it tries to pull in the bare minimum to keep the bundle size as small as possible. ELRICK: Toran, you have had a lot of experience with Redux and Redux is now being used in several different software platforms, I guess or software areas like Vue and they probably even have in Angular now. They have it in Ember and React. Redux is kind of spreading its wings and it seeds across every ecosystem. Do you feel that Redux has reached a state where people are just satisfied with the current state of Redux or do you think that people are going to be then, looking to build another abstraction on top of Redux? Do you have any thoughts on that? TORAN: The fact that Redux is so simple has allowed it to become so ubiquitous. I heard someone say this term the other today, which is like, 'ubiquity over consistency,' and that I think describes the both the growth of Redux and why it is kind of de facto for data management across all ecosystems. I think there's two camps that I hear about and I'm curious if you guys see this in your consulting work but there is certainly, the developer see this ubiquity but no consistency and see chaos in their experiences. I can totally relate to this. There are development shops I've seen where one team goes this direction because there's no strict guidance goes another and then when those teams meet up for a project in 12 months, they look at each other and the apps are, of course nothing alike, which is a big problem that Ember tries to solve. My biggest question here really is kind of curving us slightly back to the Glimmer story. If I can reframe your question, Ember is traditionally very big on convention and I think a lot of the community that is still in Ember today in large part is because of this convention, these guide rails about the community has set up but Glimmer being this NPM install your way to Ember, I think along the way, there's going to be either a new set of users that are coming just for the winds of the Glimmer VM and they happen to find themselves, not necessarily in love with some restrictions or opinions that would come with a migration directly to Ember and I'm curious if the Glimmer community that will show up for that is mostly Ember backed, meaning that they want to slowly build with RFC as a process that the entire community uses and there's one solution like we end up with often an Ember. If a community evolves more experimentally like you saw in React, where there was, of course Redux but then there was MobX and then there was various little wares for Redux that different teams would try out and eventually, there was no one proven way but there was always at the heart of it, Redux with some extensions or other add-ons around it that got teams to where they are today. I'm curious to see where this Redux, especially with the Glimmer influence, will end up. WIL: You touched on a little, I think one of the, maybe not a problem necessarily but one of the biggest barriers in Redux and React and maybe Glimmer -- I'm not sure -- is that it's almost too loose without any opinions at all so it kind of gives developers the freedom to mess things up big time. What's your opinion on that with Glimmer, like Glimmer is headed toward this NPM install? Is it too loose? TORAN: I guess that's the question, I wish we both had the answer to. It's funny. It's a double-edged sword. If it's loose, it seems like somebody is going to go create a mess but at the same time, if it's loose on the surface, it often seems like it has less surface area and as a result, a lower learning curve. React is a good example where most people, I think have gone to React or at least in my experience, I like React because it was so simple and there wasn't a huge amount of things to learn. There wasn't this full ecosystem, at least out of the gate but of course, what you find the moment you want to join a team or go build something ambitious is that you've got to make a bunch of decisions and that is certainly the calling card of Ember. What makes Ember special is they've settled on a handful of those decisions. I think ideally, I'd like to see the community in Glimmer check out Redux, get an idea of what problem it actually solves for them and if it is useful, then find a set of middleware or extensions from the wider ecosystem that actually solve the problems they face. Back to this Glimmer rideshare example, I think one thing that stands in the way as I play around with that is just a very basic routing story. Even if that is as simple as I have a component that I'll just call it route, what hooks in this Glimmer component are correct to fetch data. In the Ember ecosystem, we have a very special route object, essentially who has a set of hooks that are known for handling the asynchronous stuff in our Ember apps but there isn't anything like that yet, in Glimmer which is the next stumbling block for me to actually go build something big. I'm kind of messing around with the idea of this reactive router built out of Glimmer components but until that's actually kind of surface, mostly just spit balling here. ELRICK: With flexibility comes a lot of power but then there's also the case where our flexibility could lead to chaos. But being that something as flexible, it allows you to adapt it to whatever your particular needs are -- you know, the 'special snowflake' as everyone ends up being. Because Ember has been around for a while now and has proven itself and its battle-tested in a lot of areas, now as NPM install in our way from Glimmer up to Ember, do you think that they'll be able to then, extract some of those hardened pieces of Ember out of Ember and then give us a solution inside of the Glimmer ecosystem based off of the Ember ecosystem? Then not have so many varying different opinions or different packages or add-ons or libraries that you may need to pull from that you may just have like a set of Glimmer-approved libraries or add-ons to use to then, get your way up to this full Ember app. Do you think that that's a road they're taking? Or a possible road? TORAN: Yeah, I think for sure. A lot of the talk right now if you're in the Glimmer channel on Slack in the Ember community, I think the next big step here is having the ability to take a Glimmer component as it exists today and use that, extrapolate from there and the plan is to prove out things in a more experimental ecosystem as pre-1.0 Glimmer ecosystem. As they become more solid, we essentially just adopt them and then use them as a first class. In Ember actually, this isn't true but I envision a world where in the months ahead, we're essentially using Glimmer components in Ember so I'm already challenging myself with how would a library or add-on author help people make this progression from Glimmer to Ember if they don't do something like I've done here with Glimmer Redux because eventually, there will be this shared component world, at least in the middle ground, where Ember has both Ember components and Glimmer components. I think it's a road yet to be traveled and that's what I'm excited to be on the podcast and get people talking about building libraries for Glimmer, just because there is not a cow path or a paved road for you right now. I think if you learn just a little bit of Rollup or you dive in and take a look at the DI system built in a Glimmer right now, there is a lot you can actually do with it. I know there are certainly big named add-on authors already checking it out in preparation for such a migration. WIL: Besides the whole Rollup process, was there any other friction points in integrating Redux with Glimmer? TORAN: One that I want to call out but it is, I believe still Rollup related. It's mostly a PSA, to warn people. If you are building one of these little libraries like I talked about with Glimmer and you're going to do a Yarn link, which means that you're going to just work locally and not really publish to NPM until you're done, be aware that if you're Yarn linking and then going over to another project to test this Glimmer library, then you'll actually get temporarily two copies of Glimmer. In fact, that is how this Rollup plugin I wrote -- sort of 'bring your own build' for Glimmer -- became essential as I was like, "I'm getting two copies of the Glimmer component," so what was happening is example, I was playing with this connect API, it was always calling into the wrong Glimmer code so the code that I was expecting in my add-on was never firing. We come to find out when you're not doing Yarn link or you're not working locally, this isn't a problem. Actually, Tom Dale reached out and helped me a little bit later because my first version of the Rollup plugin had this little hack in there that said essentially, "I'm going to mask away this duplicate Glimmer problem," and it turns out it's not a problem. If you are working locally, be aware that you will have this problem as my guess. ELRICK: What gets you most excited using Glimmer? Are there any specific features or things within Glimmer to get you most excited? I guess the second question would be, what do you think Glimmer is going to unlock for the future of app development in Ember? TORAN: I think the first thing I get excited about was visible in this talk that Tom Dale gave a couple weeks ago. I'll try and dig that up for the show notes where he show the advantages of Glimmer over the competition today. The big thing that just blew me away was some of the advantages over, even Preact, which I was kind of surprised that a lot of times there's this rivalry for performance especially between React and Angular and Ember but no one ever really talks about Preact, which is known in a lot of ways as the thinner, lighter-weight React, if I'm not completely wrong. I'm sure somebody is going to be table flip on that definition. But my view was that if you were really performance-hungry, you could check out Preact, which was for performance reasons there was a smaller bundle size so you're just actually shipping less JavaScript, which means they're parsing less JavaScript and Tom went directly after this library in his talk and just showed a very interesting point at the end. I don't want to spoil it for people but let's just say, it appears to show Glimmer as just an order of magnitude better as a primitive for building web components. I think that is the big draw and how will that make Ember better. I think, mostly in the same way that I just described, where we'll essentially get a component for free in Ember that is just a better performing primitive for the web. ELRICK: I'm not too familiar with the guts of Glimmer but from what I understand, Glimmer compiles down and it has some opcodes that then compile down to binary. Is that correct? TORAN: Yeah, I think there is a binary format that they're shipping or they will soon be shipping. If you're really interested in the technical details of that, I'll definitely be sure you check out this talk from Tom because now the real magic behind this is they essentially boil it down to the ability to compile these templates down to 'byte code,' as they call it and Tom has a really funny part in his talk where he says, "You know, it's not a marketing term, this byte code word," and it becomes true because later in the talk, you hear that, essentially the Glimmer VM or the big value add of Glimmers VM is that you're just feeding it with byte code until the next 16 millisecond buffer comes up to paint, in which case you just pause and that allows, I think as he describes, less jank or allows less freezing up that main thread because you're releasing control back to the UI every 16 milliseconds, essentially. ELRICK: Yesterday, there was a meet up with a lot of the Ember core team. Ed Faulkner had made a point that since Glimmer compiled down to byte code that then is not too far of a stretch to then use that with something like Web Assembly, that with then give Glimmer an extreme performance boost. He sets up Glimmer to be used in what can be potentially the future of the web, which is Web Assembly, which I thought was really interesting and it kind of blew my mind to think, "Oh, yeah. That is true since it compiled down to byte code and Web Assembly compiles down to that." We can get that performance boost in that Glimmer is forward thinking in a sense. TORAN: Yeah, man. I totally agree. One of the things I honestly value about the Ember core team is they're very both tactical and visionary at the same time, where in the short term, they're doing things to accomplish real pain points we have but without anyone really realizing it, they're also setting up the stage to solve huge problems that we're all going to face in six, 12, 18 months. I definitely appreciate and love the work these guys are doing. They should hear about it. Obviously, this is all open source and most of this time is gifted, just given away so I really appreciate the core team. WIL: Speaking of performance, we know that the Ember has a run loop and basically, most of these libraries have some sort of loop that determines when they should batch things together or render things to the screen. Does the Glimmer have this concept? What do they take advantage of to make it as performant as you say? TORAN: Yeah, that's actually a really good question and I'm probably minimally equipped to answer it but the short version of it is there is no equivalent run loop for batching work that I've seen inside of Glimmer. Instead, you're more directly interacting with request animation frame, which we miss directly from Mozilla here but requests animation frame tells the browser you [inaudible] browser call specific function to update an animation before the next repaint. Where does this come in for Glimmer? Essentially when you call set or you decide to change a property that Glimmer is listening to and if anyone was not familiar with Glimmer, you designate this by using the tracked attribute. The tracked attribute, when you change a value, it fires this 'set property did change' and behind the scenes, 'set property did change,' if you are familiar with Ember, in my mind is close to 'notify property change,' which is what happens when you do Ember.set. If you've ever actually change something in Ember behind the scenes, there is a notify property change event fired and then we queue that work and it's a similar-ish process except that there is no run loop. What we do is we just call schedule rerender, I think in Glimmer and that just fires off request animation frame to try and rerender within that 16 millisecond window before the next repaint. WIL: From my understanding, the request animation frame is Glimmer's run loop essentially. TORAN: I think I saw actually a discussion between someone at Ember core kind of saying in the public channel that, if you're using Embers run loop, the equivalent-ish today would be request animation frame but the point came up that there's really no way to have a different set of cues because Ember itself has many different cues in the run loop and request animation frame, as far as I know really is just one function with a single callback, where you try and fit in as much work before that repaint as you can. I don't think there's prioritization that you would get in the Ember run loop. But at the same time, I'm not sure if that's actually a requirement. I don't think request animation frame was as mature as it is today back when backburner, which is behind the scenes of what Ember run loop is using, was built years ago. ELRICK: Since Glimmer is using requests animation frame and not the Ember run loop, is it going to continue to use requests animation frame in the future or they're going to develop like a run loop equivalency for Glimmer? TORAN: That's definitely out of my depth. I know from looking inside the code, the rerender work essentially calls like a 'begin,' to say begin doing your work, which I believe is like the reconciliation type work if you have a React background, I believe. I don't know what decides to end that. If the request animation frame is truly saying, "We're at the 16 millisecond budget and we're going to quit feeding the Glimmer VM byte code instructions now because we need to go back and paint." I would guess that that is the high level narrative but I actually don't know the implementation details. ELRICK: Since Glimmer is pre-1.0, it's a place for you to experiment, try out new things, really exciting area to play around in. What kind applications do you see people building today using Glimmer and what's the good application that's a good fit for Glimmer right now for you to experiment with? TORAN: The big application that I've seen that exists is being built with Glimmer in its current form is the Glimmer Playground. The Glimmer Playground is an area to go mess around with Glimmer, if you've never used it or you just want to go [inaudible] with the basics. As far as what is an ideal application, honestly I think we're at a point where we need to push the bounds of what a purely component based library can do. I think if you could come up with some kind of basic routing story and have a mechanism to share state and bubble events, whether that's Redux or some kind of home grown service layer at some point. That would allow you, in my opinion to build just about anything. The only caveat that you're going to be missing is a ton of opinions and you're going to be paving new grounds so just be aware that happy path for any pre-1.0 is be aware that they could change anything, anytime. But that shouldn't really restrict you from making a hobby project out of it. Back to your original question, I would say building any app that you're okay to go back and rework, not necessarily reinventing Facebook or something like that with it at this moment but at the same time, it would be great if someone did in a hobby way because we need to see some of the constraints and challenges. I got playing around with it myself and noticing if I'm going to build anything with Glimmer, I've got to have a way to share state and bubble events up to the single atom at the top that allows me to share all state. I think without some experimentation, we just won't know what apps are possible. ELRICK: You've been talking a lot about Glimmer today and using Glimmer. Since Glimmer is pre-1.0, are there any limitations that people should be aware of when they're going to be going into building a new Glimmer app? TORAN: For Glimmer Redux specifically, one of the challenges that people would see and they should know about if they're going to use this little Glimmer library, is that it doesn't yet allow you to write reducers in TypeScript, which would be a little counterintuitive because if you get into Glimmer, you'll notice the big differences -- everything is in TypeScript and not JavaScript. Luckily though, I think this is really just a build tool decision. Truthfully, the spike version of this that I have where you can use TypeScript, it doesn't require any change to the Glimmer Redux library at all. In fact it's completely unchanged. The difference here is that the Rollup plugin I use needs to see a change. It's kind of weird in that way, back to my point earlier where you kind of bring your own build chain and one of the things I don't like right now, which is the reason I haven't published this TypeScript version of it is that I'm actually doing a TypeScript compile of all the reducers or middleware in the Rollup plugin. With the mass confusion right now between Broccoli, Rollup and Babel, I just don't feel really great about it. Mostly because I have not truly been in the guts of the Glimmer app build tool or the application pipeline yet and I want to be a bit more educated there before ship something, back to being a Midwest developer here. I just don't feel good about shipping something and say, "Oops, we got it wrong." I take a lot of time and I also take a lot of pride in what I am shipping so I want to have a really good story about TypeScript. It does make for a little bit of a weird experience: bouncing between Glimmer components written TypeScript and flipping back to reducer file written in JavaScript. just be aware of it and at the same time, I didn't want to completely halt shipping it because again, I think we need to actually build apps with this and a concession here being that, of course you have to write reducers in JavaScript was still enough for me personally to get some value out of building Glimmer apps and honestly, it got me building them sooner. WIL: Is there a way to use Glimmer Redux without the Rollup? Can we import something into our Glimmer app to use it or this Rollup is required? TORAN: Yeah, that's a great point. You can omit the Rollup plugin entirely. What that results in is you'll have to do some hand wiring yourself. One of the upsides or one of the benefits of this Rollup plugin that I wrote is this conventionally provides a store and redux-thunk, kind of like a happy path for people who are just not familiar with wiring up their own Redux store. If you forego this plugin, you just have to do that yourself. You may actually have to do some kind of Rollup hacking in your Glimmer app, which is the thing I want to avoid. The one in particular that I know you'd have to do is there is a Node ENV that is looking for a production setting in Redux so the first thing you have to do is use a Rollup replace plugin to replace Node ENV with Ember ENV. If you can't do that, you actually get an error in just trying to stand up your Glimmer app with Redux. ELRICK: Toran, are you giving any talks or have any books or anything that you want to get out there and talk about? TORAN: I'm not actually on speaking circuit right now. I am certainly, probably like you guys are, thrown a talk or two together for the EmberConf proposals that are now out. I think they're open until November 21st. If anyone is thinking about submitting a talk to EmberConf, this should be in next March. Now is the time to get those in and I certainly have one out there but I've got one, off the top of my head that I would certainly like to find some time and submit that's related to Glimmer. ELRICK: Cool. We had a wonderful podcast today. We touched on Glimmer Redux and Glimmer and I want to thank Toran for coming on. Thank you, Toran. TORAN: Thanks for having me, guys. The fifth time I have to be on, I don't know if that will be in 2017, though. ELRICK: Yeah, we're going to bring you back for a fifth time and I would also like to thank Wil for coming on the podcast as well. Wil, thank you. WIL: Thanks for having us, Elrick. ELRICK: Anytime. Toran, if people want to reach you, is there a particular place on Twitter or anything that people can reach out to you or email or anything? TORAN: Yeah, at GitHub, I got my email out there but also on Twitter, of course. You can reply me there. If you have a question specifically about Glimmer Redux, of course you can got to GitHub and throw an issue up there or hit me in the Redux channel on the Ember Community Slack. ELRICK: Thank you all once again for listening. This is the Frontside signing off and if you want to reach out, you can always hit us up at the Frontside.io and we always want to hear about your new project that you're working on. Thank you for listening and that's peace from the Frontside. WIL: Everybody have a good Thanksgiving!
Alex Matchneer: @machty | FutureProof Retail Show Notes: 01:07 - The Introduction of ember-concurrency 02:15 - What is ember-concurrency? What are the problems it solves? 05:37 - Why not use observables or other alternatives? 09:49 - Could observables be used in conjunction with ember-concurrency? 12:16 - Simple Made Easy 14:23 - Coming Soon to ember-concurrency 16:04 - Communicating Changes in State; Glimmer Reference Primitives 23:09 - Using References 29:31 - Submitting RFCs; Adding Pipelines 32:10 - Pipeline Use Cases Resources: ember-concurrency The Frontside Podcast Episode 007: The Ember Router with Alex Matchneer The Frontside Podcast Episode 019: Origin Stories with Tom Dale and Alex Matchneer Introduction to ember-concurrency by Alex Matchneer from Global Ember Meetup RxJS Rich Hickey: Simple Made Easy Glimmer.js redux-saga Lauren Tan's RFC: Cancellable task pipelines Railway Oriented Programming Apache Kafka Transcript: CHARLES: Hello everybody and welcome to The Frontside Podcast, Episode 67. My name is Charles Lowell, a developer here at The Frontside and podcast host-in-training. With me today also is Elrick Ryan, a developer here at The Frontside. Hello, Elrick. ELRICK: Hey, what's going on, Charles. CHARLES: Now, we have with us today someone who we love to have on the show. Everybody probably already know him. I know the first time I actually heard about him was when we had him on the podcast the first time, I was like, "Who the hell is this guy?" But since then, he's become one of my favorite developers, just with all of the things that he's done, from Router.js to more recently ember-concurrency. We have Alex Matchneer on the program. ALEX: Hey, everybody. Thanks for having me. CHARLES: Hey, Alex and you know what? I pronounced your name right this time. First time out of the gate. Boom! ALEX: Nice. Which one did you go with? Matchnear? Matchner? [Laughter] ALEX: I really actually don't even know which ones correct anymore. CHARLES: Was it about a year ago that you first introduced ember-concurrency? ALEX: Yeah, I had a really embarrassing introduction of it at an Ember Meetup in January before it was really done and I just kind of botched it and didn't really introduce why it was even solving problems. Then a month later, I had some time to refine it, driven by the feel of that embarrassment. I guess around February of last year, it's been pretty much in its present state. CHARLES: I remember when it came out. I must've seen the non-botched version because I remember hitting the ground running with it and being able to refactor all of this code. I definitely know that I got the honed version because you provided in that initial blog post a whole host of examples like what are the symptoms, what are the cases where it solves and then before presenting the solution. I think that was great because I didn't even realize that I had a lot of pain. I didn't realize that at all. I didn't realize I had a problem but then you were very, very elegantly packaged the problem with the solution which is always great because otherwise, it's just complaining. Maybe we should talk a little bit about -- I don't think we've officially talked about -- ember-concurrency. Even though it's been out for quite a while, the way that you model these concurrent processes using the stack is just pretty incredible. Do you want to just very briefly touch on what the problem is and what have lead you to this solution? ALEX: Sure. It's a little bit difficult to sort of succinctly say what ember-concurrency is because it kind of hits them like five different separate but kind of related but not really pain points. At its core, it's just like a task primitive and it's definitely not the first library to ever introduce that the JavaScript, I think particularly when the generator function syntax was introduced into the spec, I think a few years back. Dave Herman who's also known as, I think a Little Calculist. I think he works on the TC39. I always get those groups a little confused in my head but he introduced a task.js library that let you use the generator function syntax and then lets you yield Promises to sort of pause where you were in that task and then continue when it resolved. It had some support for cancellation. It played well with Promises and I brought that to Ember in a way that fit really nicely with Ember more than it probably does or will with other frameworks like React or Vue. By bringing it to Ember, basically if you're implementing any feature that involves async, if it's a button that needs to show that it's been clicked while you're waiting for some response to come back from the server, instead of using Promises, instead of using actions, here's an ember-concurrency task. It makes it easier to express that operation you're trying to do and it makes it really easy to drive your UI with state that comes from the state of that operation -- Is the test still running? Is your form still submitting? -- Rather than having to manage a bunch of mutable flags and properties on a component or state yourself and likely get it wrong. CHARLES: Right. Essentially asynchronous processes is like a state machine and before, we were kind of managing that state machine by hand but I think what's so brilliant about this task-oriented programming, I guess is maybe a way to put it because I really think that some of these ideas are universal and not specific to ember-concurrency. But it almost like it uses the stack, just your normal programming stack to track where you are inside of a process, rather than what it felt like what we were doing before, which was managing this state machine by hand, if that makes any sense. ALEX: It does make sense a lot of sense. A lot of people ask me, if you're going to go into sort of async territory, why aren't you using something like RxJS? Rx is observables and kind of popularized by the Netflix crowd who did a bunch of presentations on them. It's super popular these days. But one of the things I really like about RxJS or at least one of the realizations I had is that I think you're still building a state machine. You're just expressing it using different primitives. In Rx, you're still building a state machine but in Rx, they make you think about it in terms of streams and events firing over time. In ember-concurrency, also you're still building a state machine but you're using the generator function syntax and the call stack like you mentioned as another way of expressing that state machine but with a lot less code. CHARLES: Right. I was actually talking to someone about ember-concurrency just a few days ago and they were saying the same thing, "Why not use observables," and at least from my perspective, maybe I didn't quite understand the question because I feel like observables are kind of only one of the concerns that ember-concurrency addresses. I'm curious when people talk about alternatives to ember-concurrency and put observables forward, maybe I don't understand it because I usually think you might be able to use observables to register the currently executing task state and every time it changes, emit a new state and is then observed by your observable subscribers. But modeling the actual process using observables does seem weird to me because with observables, they seem like very purely functional and not heavily stateful. I don't really have that much experience with it. What's meant by using observables as an alternative? Maybe we can get more into those like how you would construct a stream or something like that? ALEX: I think the canonical Rx example of something that's elegantly expressed in Rx that would be really hard to do in just normal JavaScript, if you weren't able to use observables, is that typeahead search where as you type characters into a text field, it's already beginning to hit the server and see what you might be searching for so it can drive the state of some drop down menu. That's probably the most popular example out there because one of the things it demonstrates is that if you want to debounce, you want to allow for the user to stop typing for like 200 milliseconds before it actually hits the servers so you don't overwhelm your server, then just add a debounce operator. You've basically transformed a stream of keyboard events into that text field into something that only kicks off after it hasn't gotten an event for 200 milliseconds. If you already had a working prototype in vanilla JS and you had to debounce it, you've got to move a bunch of stuff around, you've got extract something into a function, you've got to deal with cancellation. But all those things are kind of pretty elegantly built into Rx and if you can train yourself to think in terms of streams of events, that inspires you to think about where else you could apply that in your app. I think a lot of people have felt that it's like winning, most powerful abstraction that you could think about. That's why things like cycle.js are a thing or redux-observable or just anybody working with observables in the Netflix territory. I personally find [inaudible]. If you're going to express certain processes, Rx is the way to go but it has drawbacks which is it is really hard to learn. It took me a very long time and I'm pretty good at it but if you're going to adopt Rx in your code base, then a new developer comes on, it's going to be a pretty long time. In my experience, sharing some of the Rx code I've written with fellow very talented developer, it takes a really long time to explain how to invert your thinking and think of things in terms of events. If you can get to that point, more power to you but what I found with ember-concurrency stuff is you don't have to completely invert your thinking and think of everything in terms of events and streams of events. You can use this task primitive which feels really pretty close to the code you're already writing but gives you a lot of the safety guarantees and just makes it really easy to use this derived state to drive templates. Rx is a powerful paradigm and sometimes you need that sort of event-driven push based model but I think when people wonder why aren't you just using observables, they haven't really grasped how easy and familiar it is to use task and get it right on the first try and with a lot less code. CHARLES: Right. You're able to leverage the fact that I understand what a JavaScript function looks like and the sequencing is implicit by just the order in which you were numerate the steps, right? ALEX: Right. Because I think that Rich Hickey of Clojure popularized the divide between simple versus easy and Simple Made Easy is one of his popular talks that everyone should probably -- CHARLES: It's a great talk. Yeah. ELRICK: Do you see an area where observables could be used in conjunction with ember-concurrency? ALEX: It's kind of. It's been hard for me to find that use case. Probably, there's a handful of use cases where maybe it's a little awkward to think about to have something that would be elegantly handled in Rx would be model using tasks but it really hasn't struck me enough in some of the apps that I'm building, to really try and flesh that out. CHARLES: I would be curious to see a side by side comparisons. I build a lot of auto completes using ember-concurrency. I built a lot of asynchronous processes using ember-concurrency. What would that look like using nothing but Rx and just be able to have it on the left-hand side of the paper, then Rx on the right hand side of the paper are easy. ALEX: I'd be very surprised if you could find an Rx example that is less code than the task equivalent because as much as I think the autocomplete example is the best canonical example of Rx, once you actually start making something that's production-ready, you want to start driving the button state while it's running or to show a loading indicator. When you start deriving other observables off of the source observable which is the user typing into the text field, you start having to worry about, "I'm dealing with a cold observable. If I create another stream based on it, it might double subscribe and I might kick off two things. I actually want to use a published.ref version of the stuff." To actually get away from a toy example into something that's actually production-ready, requires a lot of code. From my own conversations with the people working on Rx, there's a lot of people that are working on it and they're pragmatic about it and don't think that you have to be just purist functional all the way. But when they actually ship production code, they usually resort to using like the do operator. With Rx observables, which is basically an escape hatch to let you do mutations and side effects in what is supposed to be this monadic functional thing. If the paradigm is breaking that quickly to do production code, I'd wonder if maybe there is something better out there. I just kind of keep that in mind but I'd definitely think there should be a bake-off or comparison of how you do things in both the task paradigm and observable paradigm but I think you'd find that in most cases, just do a lot more with a task, with a lot less code. CHARLES: I want to go back to the point you were about to make about Simple Made Easy. ALEX: On the divide, ember-concurrency is very easy. I still choose easy. In the case of reservable, I'm constantly choosing easy over simple and then it always helps me out because I've made that decision. I think most people inspired by Rich Hickey from the Clojure community, would look at ember-concurrency and be like, "At a task that combines derive state and does five different things seems kind of gross. Why don't you just use observables," and the result of that if you follow it through is that you end up writing a bunch of observable code that is a mess in streams and going in different directions and you've written something that's really hard to understand, even if it's seasons Rx developers looking at the code. It's just very easy to write things that are tangled. CHARLES: It's always good to have simplicity but also a system that simple without ease, I think is far less useful because like I said, it's always going to be a tradeoff between simple and easy but the problem is if your system is too simple, then it means that you're shouldering your day-to-day programming task or shouldering the complexity and you have this emergent complexity that you just can't shake because your primitives are just too simple. You could be programming in assembly language or something like that. That's really simple. You need to be able to construct simple primitives on top of simple primitives so for your immediate need, you have something that is both simple and easy, if that's ever possible. Certainly, ember-concurrency is easy and I think it just means there's maybe work to do in trying to tease apart the different concerns because like you said, there are five. But in real complex systems, there are five bajillions, maybe teasing apart those individual concerns that is composed out of simple primitives. I'm sure you've thought about that a little bit of how do I separate this and make these tasks compose a little bit better and things like that. ALEX: This is a nice segue because it might tie into some of the work that's going to be going into ember-concurrency in the next few months. A big theme of EmberConf is actually, a lot of people are joking that it should just be called GlimmerConf because a lot of it was talking about how Glimmer is going to be this composable subset of Ember, like Glimmer is going to be the rendering layer and then there might be a Glimmer router and a bunch of these Glimmer components that once you npm install them, you get Ember. Glimmers is a chance to think about Ember as a bunch of components working together under a really nice rendering layer. There's definitely some interest in bringing ember-concurrency in thinking what is so-called Glimmer-concurrency going to look like. Part of thinking about that is going to mean teasing apart some of these details as you were just saying. I don't have a lot of specifics to give right now, just that there is a lot of interest in making sure at the very early on, there is some sort of Glimmer-concurrency equivalent. Generally speaking, as part of that process is the question of how do we bring these magical ember-concurrency parameters to just Node or just vanilla JavaScript in general. Perhaps you could use these kinds of tasks on a server and in other environments. I think there's some questions of the way the ember-concurrency bundles together derived state with the actual tasks runner, are you actually going to use that derived state in the server setting? I think some of these pieces are going to have to come apart a little bit. I don't have very concrete ideas for how that's all going to look in the end. Just that I have faith that it will happen pretty easily and the result of it is going to be something that fits pretty nicely into Glimmer as well. CHARLES: Yeah, I hope so. It certainly seems like one of the core issues right because Glimmer-concurrency really should be universal. It should be some -- I don't want to prescribe your work for you -- ALEX: I don't mind. CHARLES: That wouldn't be cool. I mean, Glimmer is very stripped down. You have a very little bit on top of a raw JavaScript environment so if you're going to go there, it'll makes sense. What is this concurrent process builder look like using nothing but JavaScript? It seems like one of the hardest problems is to disentangle it from Ember object because the way that it currently computes that derive state is very intertwined with Ember object. You know the details of this more than I do but it seems like that's one of the biggest challenges is how do you communicate those changes in state without using that? That what I was thinking, it would be a good case for using observable for ember-concurrency, although not for probably the reason that people are thinking, which is for task composition and stuff but I'm very curious. ALEX: Likely the first stab at that direction would probably be using something similar, if not exactly these Glimmer reference primitives. Maybe it is worth talking about that. References are one of the core primitives that's used by Glimmer and it represents a value that might change over time and it's a value that can be lazily gotten, whereas observables, you have something that's firing events every time something changes and it makes the whole pipeline process it right then and there. With references, when something changes, you just tell the world like something's dirty. Then at a later time, maybe when in a request animation frame or some point where it actually makes sense to get the latest values, then it goes through and finds out everything that changes, does a single rerender. What it means is that you don't have the observe recode that's firing every time some value has changed. It's one of the guiding abstractions in Glimmer that makes it possible for it to be so fast and performant. It is very likely that a vanilla version of what ember-concurrency does uses references because those are already separate from the Ember object model and actually are used today in conjunction with Ember object model with the Glimmer that works with Ember today. I think that's probably, to me a first step. Clearly the reference attraction has worked wonders for Glimmer. I prefer to probably use that than observables and the push-based. CHARLES: Observables or something else. That is really, really interesting because there's nothing like vanilla JavaScript programming these days, like the equivalent of a Haskell thunk where you're just passing these things around but you're not actually using them until you actually want to pull a value. At that point, you kick off the whole chain of computation required to get that one value that you need. But it immediately brings to mind and I don't know if this is of concern to you but I was very, very enamored of Ember objects back in the day, in 2012. I was like, "Wow, this is amazing. This solves every problem that I've had." It has been a great companion and I've built some really great stuff on top of it. But now it's definitely turned into baggage. I think it's baggage for libraries that I've written and we're talking about it in the context of it being baggage here and being making it more available to the JavaScript community so I worry a little bit about Glimmer references. Would they possibly turn into something like that and could you counteract that by maybe trying to evangelize them to the wider JavaScript community like, "Here's a new reactive primitive," so that we don't end up in an eddy of the JavaScript community, do you think there's value in trying to say, "There should be some standard in the same way of observable, which is an emerging standard is for eager reactivity, have some lazy reactivity standard," or maybe it's too early for that. That might be a way of future-proofing or getting insurance for the future so you can say, "We can confidently build systems on top of this primitive." ALEX: If the worry is something based on Glimmer reference as it's going to turn into the same baggage or [inaudible] or whatever, that maybe Ember object has turned into some apps, some applications, some libraries. I'm not sure. I guess I don't really see that happening and I know that it's already gotten some validation from some of the people that have worked on Rx. In fact, a very useful primitives for certain kinds of workloads. As much as evangelism certainly helps. It's already off to a much better start than this all-powerful, god object that you can only interact with if you're using .get and .set functions. It's very lightweight. What I'm trying to say here is that there's UI workloads and then there's server-driven workloads and using Rx for both cases means that Rx suffers as a library because in the UI workload, you want something like references where you want to let a bunch of things change and then update stuff in one pass just a tick later or later in the micro task queue. But in Rx, they make you think about things in event-driven way, which might make sense for servers and stream processing but it's ugly when you want to actually build UIs with it. I think if we pay due respect to the fact these workloads are pretty different, I think the reference is way better of an abstraction for things that are UI-centric. They're simple and their performant and I think it's often much better foot than Ember object which is kind of bloated and huge and very hard to optimize. CHARLES: Right. I like that because you have to be precise with the server side things but ironically, with the references, you only care about the state at the point at which you observe it -- when the user observes it, not when the code observes it. The user observes stuff with every animation frame and there can be any number of intermediate states that you can just throw away and you don't care about. You don't need to compute them. I think what you're saying is Rx forces you to compute them. ALEX: Right and you wouldn't use a Glimmer reference for something if you're trying to batch. But in the end, keep all of the events that were fired on all the change events. You wouldn't use references because you're losing all that information until you do that poll and you get the latest value. But 99% of the time, when you're building UIs, that's what you want to use. CHARLES: Are Glimmer reference is their own standalone library or do they currently bundled with Glimmer? ALEX: I'm not sure. If they are not now, I believe the intention is for them to be at their separate repo. I was talking to Kris Selden at EmberConf and I got the impression that the intent, it might not be there now and if I want to start extracting ember-concurrency stuff into vanilla JS, I'd probably want to use a reference-ish thing, if not the official one from Glimmer. CHARLES: I know we talked about this so then, how will you able to use these lazy references to compute tasks state? How that might work or play out? ALEX: The fundamental problem right now is that everything in ember-concurrency is so glued to the Ember object model. What that means is that all ember-concurrency has to do is broadcast so the changes has happened to the state of a certain task so that you can, maybe put a loading spinner up on your template. All it has to do is use object.set and then the built in computed property observer change detection that is in Ember object model. It's going to sort of propagate these changes but that's a bunch of heavy Ember stuff that is going to exist and a lighter weight Glimmer or vanilla JS context. Instead of using .sets and expecting that the thing you're setting it on is a big, heavy Ember object model, you could just use references. Then whoever wants to get a reference to whether a task is running or not, it is running reference. Then just using the standard Glimmer abstractions. At the Glimmer-concurrency task runner, it would just basically kick those references and anyone who has one of those references can flush and get the latest value at some later point in time and then update the UI based on that. Already, as a maintainer at ember-concurrency, I see all the pieces work with that and I could probably just start working on that today. But there's just a handful of other things that I want to align with the vision of Glimmer and Glimmer-concurrency before I start working on that. ELRICK: What would be the referency equivalent in just plain JavaScript outside of Glimmer that you would use to build this on top of --? CHARLES: Like what would the API look like? If you're like, "I don't have a Glimmer. I don't have anything. I'm just --?" ELRICK: Yeah, you just have plain JavaScript. What would be the primitive that you will build this on top of? ALEX: Whether we use a standalone Glimmer references library or this separate reference thing, then I would use the term based on something Kris Selden said. In the end, the APIs is going to be pretty similar between those two but if one thing is requires, as far as I understand it, you've got to set up where in an event loop, your response is something that's changed and then you schedule at a later request animation frame, to actually do the rendering based on that. In order to use something like references, it implies that you've got to flush at a later tick or flush at a later call back. If you've got that in whatever app you're working on, it should be pretty easy to figure out where references fit in. CHARLES: I see, so you would basically say like new task, give it your task class or whatever -- I'm just making stuff up -- then you would just schedule, do a request animation frame and then just pull the task state or something like that? Or a new task reference or something like that? ALEX: You might have some function that's schedule render pass, if not yet scheduled. Then if it hasn't been scheduled, then use requests animation frame. If you call that function again, it's going to no op until that requests animation frame happened. CHARLES: Could you explain that again? ALEX: Sure. If you're actually thinking of a really low level vanilla JavaScript to your app, in the browser or something and you were just using references, then you probably have something where the thing that kicks off the reference or dirties the reference in some way, also run some function called 'schedule rerender', if one hasn't already been scheduled or something less verbose. That would just make sure that some request animation frame has been scheduled. When it flushes, then it will get all the changes but if more references are dirty at that mean time, it won't schedule additional request animation frames. I don't know, that's kind of blue-skying but that's when -- CHARLES: Right. Here's the other things, you see like being able to integrated with a third-party state management solution like Redux or something. Basically, I've got my ember-concurrency tasks and their state is then reflected inside a Redux store. How might that work, if at all? Or was that a crazy idea? ALEX: I don't know. I played around with Redux toy examples and Redux community and Ember is only stronger by the day. I'm not entirely sure how all those pieces fit together because in Redux, they really want you to propagate all of your state changes using the reducer in that single global atom. A lot of people asked me about redux-sagas, which is another generator function-driven way of firing these state mutating actions over some async operation and this is hugely popular but I don't think they have any concept of the derived state that I've been trying to do with ember-concurrency of just being able to ask a task if it's running. You can't just do that. You've got to reflect that into the global atom -- the global store --somehow and to be honest, I don't really know if that's fundamentally at odds with the Redux model, to take something like Ember or Glimmer-concurrency and make it work that way. But ideally, you wouldn't have to forward all that state into the global atom. You just be able to reference that task object. CHARLES: If the task object itself is immutable, it would have seemed like fairly trivial, like you could generate programmatically the reducer required to do that. If you had the state encapsulated, you could come and say, "Now, there's a new state here." It seems like you would be able to adapt that but you would need to be able to react to any time if that state changed to fire and action in the Redux store or fire the Redux action. ALEX: Actually, this will be an easier question to answer because in the Ember community Slack, there's a Redux channel and I know everyone there is already starting to talk about how are references, how is Glimmer is going to, how can we kind of tie these things to Redux and I think when they have some solutions lined up, a lot of the stuff that will be in so-called glimmer-concurrency will just fit in nicely. If they've got nice models for tying references to the state atom, if you will, then it's going to work with the new way. CHARLES: Okay, cool. One of the things that I wanted to talk about was a proposal that Lauren Tan, who put on to the ember-concurrency issues list, although it's an RFC. Are you accepting RFCs now for ember-concurrency? ALEX: I'm not pompous enough to have a separate RFCs repo. Issue approaches perfectly humble for me. CHARLES: But is this the first RFC or have there been a bunch of ember-concurrency RFCs? ALEX: There's been a few. It's definitely great that Ember have standardize on this boilerplate RFC model that everyone can fit their proposal into because it means that all the add-ons that people really like and really want to invest in, they get these high-quality RFCs versus like, "Hey man. It kind of nice if you can just like, have a pipeline." [Laughter] ALEX: Just because Ember invested in that process, the whole add-on community benefits from it and it's great. There's been a few RFCs that are like that. I'm not sure how many of them have made it but I've seen a few that are in that format but this one's definitely one of the nicer ones and a lot of effort was put into it and it looks really nice. ELRICK: I'm not familiar with the RFC. What was the brief overview of what was proposed? ALEX: Lauren was basically proposing that we add concept of pipelines, which is if you have a series of tasks that are stepping the pipeline of operations, then we should standardize that and then define all the steps in the pipeline so rather than having each step in the pipeline, call the next step in the pipeline. They just return some their portion of that work and then the pipeline infrastructure will automatically run the next step in that pipeline. CHARLES: It seems like also then you can derive state about the entire pipeline, rather than just the individual task. You have to manage that a little bit by hand. But the other thing, I guess I would add is it seems like if you're going to go with pipelines, rather than being a simple list, you might want to think about it as being a tree because can you have pipelines that are composed of sub-pipelines, so to speak? ALEX: Yeah. I believe the answer is yes. I'm not sure if it's spelled out in this RFC but really a pipeline just fits the task interface so if there's a task-ish thing or taskable object that you declare as a step of a pipeline or sub-pipeline, it should just work. I'm not sure if there's more work that needs to be done in spelling that out but that seems baked into it. There's a lot of due consideration for making sure these things compose really well and it's already in a really good state. CHARLES: Yeah. What are some of the use cases where you might want to use a pipeline? I'm sure, everyone who's been writing concurrent tasks has probably been maintaining their own pipeline so what is it that you're doing and how is this going to save your time and money? ALEX: Let's use the example that I've actually used in EmberConf, which is something based on my own app, which is in my app, you have to geolocate and find nearby stores that you could walk into and that process is four async steps in a row. One is getting your geolocation coordinates and then the next step is passing those the store, getting values and the third step is maybe some additional validation or just setting a timer so that your animations or any of these little async things that you have to do. But it's really a sequential operation where each time, fetch your geolocation or get it out of a cache and then step to the next thing, then the next thing. It looks okay as I have it in my production app code but it still feels a little gross that you can just look at this thing and be like, "What is the sequence of steps here?" You have to actually get the implementation of each task to see what happens next and where will it go after that. Basically, with ember-concurrency in general, there's a lot of opportunities for finding more conventions for building apps. I don't even know if we really talk about this so far but derived state is part of it. But generally speaking before ember-concurrency, there wasn't as much opportunity, I guess for some of these conventions for building these pretty standard UI flows without feeling that you're just building your own thing every single time, with chains of Promises and your own improvise cancellation scheme and all these things. I see pipelines as a next step. Well, we're pre-building lots of pipelines in our apps. We have these processes that go through these multiple steps and right now, the best we can do is set a bunch of Boolean variables and the derived state that comes with ember-concurrency helps but with pipelines, there's even more and it also structures your thinking so that if something like pipelines catches on, hopefully as an Ember developer, you'll see them in a few different places and already have that tool in how to visualize a problem, visualize a component, visualize the async flow. CHARLES: If I spent my entire morning reading the talk that Lauren referenced in RFC, which was the Railway Oriented Programming, which I think, maybe not quite but basically a visual explanation of a Maybe monad or the Either monad or whatever it's called. One of the greatest explanations of why monads are helpful and through explanation using like the Maybe, where you can have a computation that could have more than one result, either success or failure and how do I take these functions and compose them with functions that might always succeed or might not have a return value or whatever and show the tracks that move through a computation and be able to normalize every function to have the same number of tracks. I realized, I'm getting into the description of it without actually having the visuals in front of it so I'm just going to stop myself and say everybody go read it. It'll take you 35 minutes but it will eliminate so much like the chatter that you've been hearing in the background for a couple years. ALEX: I used to tell people that they should learn Rx because regardless of me liking the task primitive a little bit better, it's great. It just scrambles your brain and reorganize your thought processes and it's such an interesting library to learn. CHARLES: All right. I like it. I'm going to go learn Rx. ALEX: I've been getting, on the server side, the sort of Kafka-based architecture, Apache Kafka. Particularly, they've released some libraries in maybe the last year or so. It's a very Rx-familiar feeling library for composing new data and new aggregates and joins between different topics and streams of events. It just seems like they're at the forefront of solving these really hard problems in a very conventional way. You get into some of that stuff and you'll find that you're doing a lot of server side processing with step that just feels a lot like Rx and I find it very interesting. I haven't actually build anything with it yet but it is likely in my future and anybody that's into the event-driven model should definitely know what people are working on in this Kafka-streams world. CHARLES: That is cool. It's so interesting to see how all the problems that you encounter on working on the server side, you will encounter on the client and vice versa. You can build up a huge corpus of knowledge on one side of the API divide and you'd be surprised that if you were to go work on the other side for a time, you'll be able to leverage 99% of that knowledge. That's fantastic. I would love to get into Kafka but unfortunately, I think we're going to have to save that for another time. That's another one of those words like... I don't know. Is Kafka descended from Storm or something like that? Is it a similar concept? I remember everybody was big on Storm. ALEX: I think Storm process the events and decides what to do with them. Kafka is really just a giant storage that plugs into something, I think like Storm or [inaudible] or any of these things that actually process the events. CHARLES: Yeah, it's all Kubernetes to me. ALEX: Yeah. CHARLES: All righty. Well, with that, I think we'll wrap it up. Thank you so much, Alex for coming to talk to us. It's always enlightening. I love your approach to programming. I love how deeply you think about problems and how humble you are in approaching them because they are big. ALEX: Well, thank you. It's great to be on here. It's fun. CHARLES: All right, everybody. Take care. Bye Elrick, bye Alex.
Chase and Jonathan are back from EmberConf 2017! This weeks episode is all about Glimmer.js, how to get started with your first Glimmer app, and what to expect.
Balint Erdi: @baaz | balinterdi.com | Rock and Roll with Ember.js Show Notes: 01:58 - What is JSON API? Advantages 03:22 - Tooling and Libraries 05:49 - Relationship Loading 07:51 - Designing a Data Loading Strategy 11:23 - Pitfalls of Not Designing a Data Loading Strategy 13:53 - Ember Data 16:37 - Pagination & Sorting 23:06 - Writing a Book 25:48 - Implementing Searches with Filters 31:08 - What's next for Balint? Resources: Balint Erdi: Data Loading Patterns with JSON API @ EmberConf 2017 (Talk) Balint Erdi: Data Loading Patterns @ EmberConf 2017 (Slides) jsonapi-resources GraphQL JSON API By Example by Adolfo Builes ember-cli 101 by Adolfo Builes 33 Page Minibook + Coupon Code! Transcript: CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode 65. My name is Charles Lowell. I'm a developer here at The Frontside. With me, also from The Frontside is Elrick Ryan. Thank you for being with us, Elrick. I know this is your first podcast. ELRICK: This is my first podcast. It's great to be here. CHARLES: All right. Fantastic. Yes, we hired Elrick a little bit ago and it's been fantastic. I'm glad to get you on. With us today is a really awesome guest. His name is Balint Erdi. I actually like to tell a little bit of a story when I have an anecdote and I do have one about you that I think you might like, although you might not even remember it. But it was shortly after EmberConf. Last year you and I got on a pairing session remotely and I don't even remember what we were working on but I was struggling with this way to decorate objects without changing them, without touching them or mutating them in any way and you showed me this technique of actually decorating it by creating a new object with the old object as the prototype. Do you remember that? BALINT: Yes. I totally knew. How could I forget? CHARLES: Yeah. That one hot tip changed my life. It is one of the best techniques that I have discovered in the last five years of working with JavaScript. It really was great and I use it all the time. BALINT: Wow. Amazing. CHARLES: Thank you. I don't know if I ever said, "Thank you," but thank you, thank you, thank you. BALINT: Yeah, no problem. I also learned a lot from this pairing session actually. I didn't know that my small contribution made such an impact. I'm glad to hear that. CHARLES: Yeah, that was fantastic. We need to actually make that happen again. I don't know why we only did that once. BALINT: Yeah, we should. CHARLES: Anyway, we're here to talk about data loading, it's something that is absolutely critical to building good frontend and building UI and yet, it's something that the users never really see. Sometimes, it feels like it's 90% of the problem. BALINT: Exactly, yeah. ELRICK: Yeah, that's so true. CHARLES: We're going to talk about techniques that we use and you use and, in particular JSON API, what it is and what's so great about it. So, what is JSON API for folks who've never heard of it? BALINT: JSON API is a standard way to build APIs. I think the specification has reached 1.0, I would say two years ago or three years ago. I remember it was in June, I'm not sure which year. It basically lays down everything that's usually consider when you build an API: how do fetch relationships, how to paginate data, how to sort, all of these things that I think developers tend to invent again and again. I think probably the biggest advantage of JSON API is that it just declare a standard way to do that. It basically reduces the byte sharing going on at the start of the project. Well, not just at the start, later on too. In my talk at EmberConf, I coined a JSON API the conventional over configuration for APIs. CHARLES: I see. Pagination is something that everybody does. Why need to byte share over the syntax, like the actual data from it? BALINT: All of these things are things that everybody does. It's just that everybody does it differently. There's a lot of discussion going on which the best ways, for example when there's a team, at least every team that I was involved with had several discussions going on about what data formats to send data in and how to paginate and all these, I think details where it's more important to get to an agreement just to agree on something and move on than to get it perfectly, if at all there is a perfect way to do it. CHARLES: I guess my question is if you have the standard way of doing of everything, what kind of tooling can you build, that can you kind of inherit for free? At what level, both from the low level and then up to the top level? When I say top level, I mean what the user is seeing. BALINT: By low level, I guess you mean the actual libraries that implement JSON API in different frameworks, right? CHARLES: Exactly. Are there now a lot of libraries out there so whatever I'm using, if I'm using JSON API, is it available in a lot of different ecosystems now? BALINT: Yes. It definitely is. There is a full page on the JSONAPI.org, on the official JSON API page that just list all of the different libraries that are now implementing all these languages. I have experience with Rails, probably at Ruby too and there are three libraries and I think all of them are pretty good just for implementing JSON API. The one I use is called JSON API resources and it's very telling. Well, it's a rather simple application but I basically didn't have to write a single line of code. I've only had to write very little code in the server to implement a JSON API specific feature. Most of the relationships could be implemented with just declaring JSON API resources and then the name of the resource in the Rails application. For all the other things, I really didn't have to do that much so in every time, it was just adding one or two lines or changing a configuration value, then it was just there. CHARLES: Now, how do you choose then what relationship you want to load and which order? Is that controlled by JSON API? BALINT: It's controlled by the frontend. It is a frontend application that's going to send these requests to the backend so that's where you should consciously think about what relationships you are fetching and how. CHARLES: Right so part of the specification is a way of specifying which relationships you want to load. In my understanding, part of JSON API is an interface along with say, the user, "I want to load all of the posts that this user has made." BALINT: Yes. JSON API indeed has a keyword called 'included', which you can implement on your backend which does this. If you specify 'include' and then the name of the relationship or relationships for several ones, the backend must comply with that request and also send back those related resources. That is called compound document in JSON API parlance. ELRICK: Is that the reverse of what they doing in GraphQL because at GraphQL, I think you have to request the relationships you want on the frontend and then it kicks it off to the backend and it gives you the information back. Is it like JSON API that includes that same thing but in reverse? BALINT: I'm not sure because I'm very familiar with GraphQL but all the things it does is that you are normally fetching a resource and then if you specify 'include' then you are telling the backend, "Please also include these related resources with a primary source." CHARLES: I think it occupies a very similar concept that you want to have control on the frontend about which resources or what data gets fetched in addition. ELRICK: Yeah, it sounds very similar. CHARLES: Well, I'd love actually to do a comparison because I know there's a lot of overlap between GraphQL and this. Maybe we can get into that a little bit later. One of the things that you said back there is having this, gives you kind of fine-grain control over when and how you load your data because that always seems a pretty difficult problem to attack on your frontend because as you're rendering your application, you have to incrementally fetch little pieces of data here and there and make sure that it's already, at the time that you actually need to render something like a component and then it's got the right data at the right time. It seems like it's this constant dance of whack-a-mole and like, "I'm loading too much here. It's taking too long," versus, "I've got too many loads happening. I've got 20 requests to run the single page." How can I back those up into a single thing? How do you go about thinking and designing that data loading strategy, as you're ready to render pages? BALINT: That's a really good question. I think the short answer is how you load data has to be part of the design process. You really have to spend time thinking about how you're doing that based on the needs of the UI. I think the way you need to render the UI will suggest the way to do data loading. Especially in Ember, I think do I really need ways to, for example block the page from rendering too early so anything that you want to render first, you can fetch in this non-blocking way into model hook of Ember. Then anything else, if you're okay with rendering later, you can fetch in other ways like to set up controller hook or from the templates or from controllers or whatever way but not in the model hook. CHARLES: But if you are doing something outside of the model hook -- because this is something I feel like a pattern that comes up a lot -- and regardless of where you're operating, if you're using Ember, if you're using another framework, you have kind of this top level data loading. But then you have your nested components might need more data, how do you go about loading that data. I guess you have to think about that also. Upfront it's like, "I've got this component that might want to request more data," how do I actually design that and think about that of I've got this data that's going to come, who knows, maybe minutes after the initial route is rendered? BALINT: That would be different but I think that you can apply the same principle. You can fetch some data in the model hook in this blocking way and pass it all it down to your component if you don't want to render the component before the page renderers or you can just even fetch it from the component while the component is rendered. CHARLES: You're thinking maybe, in terms of streamlining, the rendering process so that you can begin rendering while your data is loading. Is that the use case? BALINT: Yes. If you, for example fetch the data from your component, then it's just going to fetch the data as needed. You have the whole page load as render and then when the component is render and it fetches the data, then you're going to see other requests go out to the backend. The data comes back and then the component is going to be rerendered with the new data. I think in most cases, that's totally fine but you might have a use case when you don't want to render the page before the component is all over the data that it needs. In that case, what you can do is once again, if the fetched data is needed in the model hook, it will just pass it all down to the component. ELRICK: What are some of the pitfalls that you would run into by not thinking about your data loading strategy beforehand that you can pull out and explain? BALINT: I think the classic one is what was known name in Rails and other framework is 'N + 1 problem' and it's when you fetch many related resources, then you might end up with doing end requests for a number of resources. In the case of Ember, you have for example a blog post as your model and then in your templates you write model.comments, then what's going to happen -- depending on actual library that you use on the backend but I ran into this myself -- is by default, if you are going to make those end requests. Ember solution is really, they just works. I mean, the default solution just works and you might not even run into this because you might not have the scenario. You might just have a few records. But if you have a great number of them, then it's going to be a bad experience. ELRICK: So someone that just dealing with Ember and then they go and make a request and then see all these requests come back, that would be something that they would then have to turn around and asked or fix within the backend to say like, "Only give me a certain set of this." BALINT: Yes, exactly. ELRICK: Or is there something on the Ember side with Ember data that you can say, "Only fetch X amount." BALINT: Right. I think both. I can speak about using Ember data and JSON API resources so what you can do to mitigate this case is to use links or cause relationship links instead of fetching the comments one by one, the backend can actually drive Ember data to fetch all the comments in one request from the link that it sends the frontend. You first ask for the blog post itself and then a JSON API compliant backend will send back the blog post resource but it's going to have a relationship link inside. An Ember data automatically records this so when it needs the comments for the blog post then it's going to fetch down from that provided URL. Actually, I haven't really talk about it in a lot of detail at EmberConf. CHARLES: Yeah, I see. I'm going to go off on a little bit of a tangent because I feel like this is a pattern that's coming up more and more. To give a little bit of context, I feel like the way that our data loading strategies have evolved is we're used to the page loads, then we kind of analyze the URL, we decide what data needs to be loaded to render our components and then we pull that data from the server based on a decision and then we do our render. But it seems increasingly more prevalent than we are having a combination of both pulling the data from the server and having the server push data onto us. One is what are the strategies for dealing with that? Given kind of certainly, at least in the Ember world, routes aren't reactive. Then does JSON API actually help with that at all? BALINT: Yeah, a good question. I don't think that JSON API specifies how [inaudible]. You are thinking about something like web sockets like pushing data from the server sockets. I don't think JSON API covers this summary. CHARLES: Yeah. It definitely seems like beyond the scope but I'm wondering if there are any thoughts about general strategies, about how to handle this model state that sitting at the top of your render tree. In Ember for example, in your route and how do you handle the fact that the route requests data and how do you handle data coming in after the initial render? BALINT: If you use Ember data, then you can push data coming in from a web socket, for example to the store. You probably do some massaging on the data that comes in and then you push it to the store and then depending on how you fetch the data, you might have a live collection. For example, if you do a store, find all notifications and then notification is coming in that is going to get displayed right away on your page because then your template is bound to a live collection. But not all of things in Ember data are live collections. CHARLES: Okay, it's mostly library dependent but if you're using Ember data, then you just push those directly into the store, those live collections. It kind of like a real time query. BALINT: Yeah, exactly. But what I'm saying is that not all Ember data query that you do are live collections. For example, relationships are probably not, depending on what method you use to fetch that data. You might have to do some additional footwork. CHARLES: Okay. Now, getting back into the area in which JSON API really does shine at things that can really shave off a lot of time and consequently money from your work, let's talk about those a little bit. For example, you mentioned pagination. How is JSON API going to help me if I want to have paginated data? What are the scenarios on the client where I would need paginated data? Then maybe we can walk back from here's this user interaction that I need paginated data for and how is JSON API going to help me with that? BALINT: Sure. I guess the typical scenario on the frontend is there is a long list of items and you don't want to overwhelm the user by showing them what it wants. You need to just show them page by page so JSON API recommends to use so it's agnostic about the exact paging strategy that you use. You can use the classic page-based approach or cursor-based one or start of pagination technique. It doesn't really force you to choose the way you want to do that. It also mentions that, I think the way it frames it, you might want to use the page for your parameter. I think that the libraries, at least at JSON API resources for sure, you use that page parameter to send back paginated data. You have a page and a square brackets number and then page size. The request variables are page number and page size. Then the server knows that I just have to send back the second page if the page size is 25 and they just set that [inaudible]. CHARLES: Then if you're using a library on the server side, then you don't have to do any extra work. BALINT: Yeah, exactly, depending on the library I guess. JSON API resources made this one really simple. CHARLES: I see. Then in terms of library support on the client, I assume that there are libraries, like Ember data that automatically will support this so when you're creating these live queries, you can include information about the page. BALINT: Yes. I'm very in to Ember so I'm not sure about the frameworks but I suppose that there are some ways that make this very easy for the developer in many of these frameworks like Angular and React. CHARLES: Right. Something that has just bit me on the butt so many times is when I have paginated sorted data. Imagine you've got some infinite scrolling table or not infinite scrolling but you've got some a bunch of table rows that are maybe 300 of them or 3000 of them so you don't want to load them all at the same time. But at the same time, you've got complex sorting that's happening on each column. You might have seven layers of sort. You want to sort by name, followed by ID, followed by date. One of the biggest problems I've encountered is trying to reconcile and sort on the client versus trying to sort on the server. Are there any facilities to help you deal with that? BALINT: Yes. I think the approach I usually take is if you do it on the server, then do it on the server. Do not mix the two things. In this case for example, if you are sorting and then you change just sort field, I would just send a request to the server to have the items returned according to the new sort criteria. I think that's the simplest approach because as you said, I've probably experienced things can get really messy, if you want to do that on the client. CHARLES: Then you've got the third page but when you do the sort, the contents of the third page could be anything. BALINT: Yeah, that's the other thing. I think if you change the sorting criteria, you'd probably want to go to the first page. I haven't thought through all of the scenarios but I think it's really rare that you want to stay on the fourth page while you change the sorting criteria to be created at descending. You probably want to see the first item the way it was created. CHARLES: Someone should seriously write a book about sorting and pagination and loading these data sets because seriously, I feel there's this tribal knowledge of things that people have learned from screwing it up. There's not a written down way of this is how you build the data loading layer for an infinite dataset so that you can sort, you can paginate and here are the problems that you'll encounter. BALINT: There's actually a book written by Adolfo Builes. CHARLES: He wrote a book on Ember CLI, too, right? BALINT: Exactly, Ember CLI 101. He's the same guy and he wrote JSON API By Example. I have it on my mental to-do-list to buy that book. I'm not sure if it covers these exact scenarios but he must cover several in that book. CHARLES: Well, I'll be sure to reach out from because certainly there are a couple of scenarios that have bit me too. The other one is where you have some collection that's paginated and sorted, then someone adds on the client side a thing to that collection. Say, you want to create a new row in that table, well then what do you do with that new row? chances are it's not going to be anywhere on the screen because who knows what the sort order is and the terms of the total sort, which is only the server knows and who knows what page it's going to be on? You get all these problems that compound and it would be great to have one place where people could reference them or have a little cookbook. BALINT: Sure, absolutely. I think in that scenario, the simplest thing, which I think probably works best like 99% of the cases is again, just to reset the sorting and the pagination. If I create a new record, I really want to see that new record. CHARLES: Yeah, maybe you put the new record up in a box up, at the top in a special new record place. BALINT: Sure you can go fancy and do that. That would be a good solution too. But probably you can just reset the page number and show the first page with the new record. CHARLES: Ah, yeah. I see. BALINT: It's tricky. It's going to get more complicated than this. CHARLES: You might have a problem where you don't want to lose that context to the records that you were looking at. BALINT: That's right. Somebody should write the book in this. I know somebody who wrote a book [inaudible]. CHARLES: It could be you. You haven't written a book in over a year, right? [Laughter] BALINT: It's been two years already. CHARLES: It's been two years. BALINT: Exactly. CHARLES: I'm never going to write a book again. I don't know. Do you think you might? BALINT: I think I might. I actually have this urge. CHARLES: If I recall correctly, you're one of the few people I've talked to who was like, "Yeah, you know, writing a book, it wasn't that bad. It was kind of an amazing experience." And literally, everyone else I talked to have been like, "Urgh!" ELRICK: That's really interesting too because his book keeps up with the releases of Ember so that makes it even harder. That's surprising to hear that like, "Oh, it wasn't that bad." BALINT: Exactly. Well, I kind of put off writing the second book for a while because if I just wrote a book, then I could just be done with it, I would be happy to start writing the second book. But if I have to maintain it for years, I don't have to do that but it's just so much extra work that I'd have to take this into consideration. CHARLES: Yeah. Essentially, what you've done is you've rewritten the book. In terms of absolute content, given how much everything has changed, you probably flipped over the content of the book in the same way that people flip over the atoms in their body. I think there was something like you don't have a single atom in your body three years from now that you have today. It takes about three years and you have all the matters completely and totally exchanged. It's kind of like that. BALINT: Yes, it's kind of like that. Well, I think maybe half of the book is still relatively as it was when I released it because since Ember 2 came out, Ember didn't change that much so in the 1.X series it did change a lot and I think my book originally came out when Ember was 1.10, I would say. There's a lot less work that require now to maintain that it was back then. But it had changed a lot for sure. ELRICK: Yeah, I think I bought the book on its first release. It was 1.10. I guess you automatically get assigned to the GitHub repo so you just see a constant barrage of updates, updates, updates and I'm like, "Wow, Balint is really killing it in updating this book." BALINT: Yeah. CHARLES: It is a good book and everybody should go buy it. The other thing that I want to cover to, as long as we're talking about scenarios that come up again and again, we talked about pagination, we talked about sorting, what about things like search? Is there a uniform mechanism to help you out there? BALINT: You can implement searches by using filters. It's a JSON API concept of using filters. You can pass a parameter called filter to your query and then a square bracket. You have the name of the field that you want to search and then just pass the value, the search term basically and then backend should return the items that matched according to some criteria. That's the simple case. CHARLES: It's a simple case but clearly, it's up to the backend to implement that API. BALINT: Yes. CHARLES: So I'm wondering what libraries are available if I'm doing something in Elixir or I'm doing something in Sinatra or I'm doing something using Express, how seamless is it because I feel like a lot of times you can run into problems where these leaky abstractions about the fact that one thing is a Mongo backend, then one is based on Postgres. Maybe that's a better example than a different server technology but more of sticking with a single server technology -- let's use Ruby -- but one is I'm using a Postgres backend and when I'm using, say MongoDB or some other key value store. In your experience, if you've seen this, how much does the backing store leak into the frontend? Is JSON API a good protection and the ecosystem around it from those leaks? BALINT: Yeah, that's a good question. I was about the say that the backend needs to be the abstraction that's use you from having to know what kind of persistence layer you use. The frontend shouldn't care about -- or any client of that backend -- whether you use MongoDB or Postgres. That's a responsibility of the API. You can still send, in this case for example, a filter query. However, the backend translates this to database queries. That's his job. I think the answer to your question is that JSON API does protect you from having to know the intricate details of the database. CHARLES: You might have some work to do but it's possible. BALINT: Sure. You might have a lot of work to do on the backend but it's possible. But it's not just JSON API that protects you. Any kind of API should protect you from this kind of knowledge. CHARLES: Right, unless you're using GraphQL. BALINT: Could be. I don't know exactly how GraphQL works. CHARLES: Yeah. I think there would be actually nice to read something from somebody who's got a lot of good experience with all of these, like different technologies to make a comparison. I feel kind of in the dark. Unfortunately, the problem with any technology, I feel like most of the comparisons out there, if you're going to compare, most people have a huge implicit bias for one tool and a little bit of experience with the other, maybe dangerous of like, "I don't definitely want to render opinions on my GraphQL and certainly not versus the API that I'm used to because I feel like I can't make a good comparison." BALINT: Yeah, absolutely. That's a good one. CHARLES: But it is something that I'm so intrigued because I feel like there's a lot of overlap there but who knows. BALINT: Yeah. ELRICK: They need that to do API like how they had to do MVC, they need to do API comparison. CHARLES: Yeah. One thing we could do, we could implement JSON API over GraphQL and kind of just move your backend on to the frontend. BALINT: I think you could but you just said that with GraphQL, you have to know the client on the frontend, like feels the database. CHARLES: Right. You could technically have a JSON API on top of your GraphQL backend because I think the thing that kind of freaks me out -- this is a crazy idea that no one should ever do it but I hope someone does -- about GraphQL is being as old as I am, I saw so many projects ruined by the visual basic kind of mantra of just like, "Just query your database right inside your components," and that was literally the rope that hung ten thousand projects and just made people despise visual basic development because there was no shield and then literally every button was coupled to your database. But you could theoretically have the best of both worlds where you're sitting on an abstraction that's also on your client but just moving your query language from your server over to your client or something like that. BALINT: Yes something like that could work, in theory. CHARLES: In theory. Like I said, no one should ever do that unless they really want to. BALINT: Yes. CHARLES: Fantastic. The other thing I want to ask you is kind of what do you have cookin'. You got your book, you wrote but you keep updated, you recently have been evangelizing data loading patterns most recently at Ember Conf. What's next? What's now? Or you're just kind of taking a break? BALINT: I already have published book a mini-book about these data loading scenarios. Actually, I just cover the things I told them out at EmberConf then add some more but I might make this into a full-fledged book, providing I don't have to update it. [Laughter] CHARLES: I'm going to write this book -- BALINT: But just once. CHARLES: -- But just once. BALINT: Yeah, I still have to find a way of doing that. CHARLES: All right. We will look for all of those things. One thing that just occurred to me is just how much of actually building UI and building frontend really is about thinking about the structure and flow of how you load your data and how much the user doesn't see that but how important that is to provide a good experience to that user. That's one of the things that sometimes we, as UI engineers don't like to think about but I think it is absolutely true and crucial and foundational. Thank you so much, Balint for coming by and talking with us about these important topics. We will see everybody next week with that. I will bid everybody to do. Good bye, Elrick. Good bye, Balint. BALINT: Yeah, thank you very much for having me. Goodbye.
Chase and Jonathan discuss their upcoming EmberConf festivities, a new GraphGL ember addon, and some node debugging.
Jonathan Jackson: @rondale_sc | Ember Weekend | 201 Created Show Notes: 01:01 - 201 Created 03:09 - 2017 Ember Community Survey 14:06 - Handling Changes and Churn 27:53 - FastBoot Resources: Boots and Shoeboxes [SlideShare] Typeform EmberConf JSX Isomorphic JavaScript Ember Weekend Episode #66: Bug Integrat (with Charles Lowell) Transcript: CHARLES: Hello, everybody. Welcome to The Frontside Podcast Episode 60. My name is Charles Lowell. I'm a developer here at The Frontside. With me is Robert De Luca, also a developer. Hello, Robert. ROBERT: Hello, hello. CHARLES: Today, we actually have a meeting of the podcast minds. We have with us a very special guest, Jonathan Jackson. You probably know him from the Ember Weekend Podcast. If that's your thing, it's a great podcast. I listen to it, you should definitely check it out. Hello, Jonathan. JONATHAN: Hey, how are you doing? I'm really excited to be on the podcast. I am an occasional listener. It's similar to my own podcast where if I don't edit it, I tend not to listen to it. It's when I have long trips you guys are number one, number two right behind The Adventure Zone which is a D&D podcast. CHARLES: You worked at 201 Created. Why don't you tell us a little bit about that? It's an interesting company. JONATHAN: Actually, when we book to this podcast, I was not at 201 Created. This is a very new thing for me. I think I started right around the time of Ember Conference out in San Diego and I'm just realizing that this is not exclusively an Ember podcast. This is the first podcast I've been on where I can't just assume blanket knowledge of Ember stuff. But it's an Ember conference out in San Diego. I actually gave a talk there about FastBoot which is a server side rendering technology. Right after that, the entire 201 company which I think is four. It's very small. The entire thing, the whole crew went to do a company event and basically camped out in the mountains for a few days, which was really, really fun. But I started working there and 201 is a consultancy based out of New York but I think it's more than half is remote. I think Matt's on the West Coast, two of them are in New York and I'm in Jacksonville right now. We do a lot of really cool stuff. We worked in a lot of different companies. You can actually see the website at 201-Created.com and you can see the different clientele we worked with. But we specialized in consulting, training as well. As well as a couple of other services that we offer. It's been a real great experience. It's been very fun and also I'm learning a ton which is really cool to be in a different environment. I have done consulting for a little over four years, previously at Hashrocket. I got to tell you, consulting will get your wheels turning. It's been nice to see how different consultancy takes a stab at things. It's been super fun. CHARLES: Yeah, it's a fantastic company. I've definitely known them for a while, certainly through my involvement in the Ember community and one of the things that always struck me is just how seriously they take the community aspect of it. We were talking about just a little bit ago, it was 201 that sponsors -- well, sponsor isn't really the right word for it. It does the Ember Community Survey which I think is a practice that we're now used to in the Ember community but I think it's something that I would love to see wider communities do. Maybe you could talk a little bit about that and explain what this community survey is, why it exists and what's the knowledge that's derived from it and how do we take action on that? JONATHAN: 201 also does contribute workshops and things like that. The idea is to make Ember a more inclusive space, a place where people feel comfortable being a part of our community and a big part of that is self-reflection and realizing where you have weak points and how you can actually mend areas that are being neglected or whatever. Basically, shining a light to figure out where we need to improve and a big part of that is the community survey so figuring out what technologies are being used, figuring out what demographics are represented or under-represented and trying to figure that out. It's actually been really cool. I think this is the third community survey and it's live right now. I feel like we could probably shed a little bit about some of the questions. This year, they did a really cool thing where they actually put all of the questions before they put the survey up live. They actually asked for a comment period which is very, very Ember thing to do. CHARLES: Because I was actually going to ask about that. Who is the final arbiter of the questions that get in because part of the survey is determining you're trying to get hard metrics on a set of questions but it's the questions that you don't know that you should be asking which are really the tricky ones. JONATHAN: It was really interesting to watch the document change over time. There was a committee discussion between some of the people in core team and Matt Beale and Tom Zalman who's been doing the organizational stuff as an intern at 201 and he's been doing a fantastic job of really staying on top of it. It's a surprising amount of work to get a survey together, especially when you have a comment period so there's tons of little adjustments here and there need to be made, to wording and phrasing and also like responses. Surprisingly enough, you can actually have biases in your questions based off of the responses that are allowed because multiple choice. It's been a really interesting effort and I think trying to weigh and balance that side of things, where you want things to be worded in a way to where people can answer more honestly and without a bias coming into the question. Because the questions change year over year, trying to get data that is historically relevant so we can see what versions were being used last year and versus this year, what was your experience level with Ember last year and this year. But still make those changes that are recommended. It's an interesting balancing act. I was very interested in the process. I was trying to stay as involved as possible but I think also, Isaac was working on that as well. It's been a team effort. The survey is a very interesting aspect of the Ember community and it's only been three years but it feels like longer. CHARLES: What I love is the work. Once you actually get the survey up, the work has just begun, which clearly a lot of thought went into it, not just the questions that is very beautifully presented -- ROBERT: But the survey, what's the software that you're using to do that? JONATHAN: I think Typeform is the thing that they're using. I feel like it actually works on mobile and I have a great analytics tools. If you're doing a survey, you should come talk to me. ROBERT: Does that like track people that half-fill out a survey and exit? JONATHAN: Yeah, it does. It actually does track like -- what's the word for that -- there's a word for that. Basically, the main metric that we're looking for is people who open the form then complete it and the percentage there, that's the respondent percentage. I've actually haven't seen the metrics yet. I think I might just wait until the conference. You're exactly right, this is only the first step so once everyone fills it out, then there's a bunch of data extraction because some of these questions are open-ended and allow users to directly input their own feedback and trying to sort that and make that useful information as a lot of work and a lot of effort. It's interesting to see, of course there's some obvious graphs that are going to happen like we see transitions. It's easy to graph out the number of people using things on a time axes or the X-axis or whatever. There's some kind that are obvious but I'm actually looking forward to seeing the results. I was only really involved in the actual administration of the survey in as far as I provided some feedback before the main feedback period. But it's been really a community effort which is great because it's a community survey. That's pretty neat. CHARLES: One of the questions that I have is how do you ensure, because the only people who hear about the survey are the people who are already involved. In order to get -- I don't want to say statistically valid -- a broad and more informative data set, how do you try and balance the concern of we want to make, maybe half people exposed to this who aren't inside my community or maybe sitting on the boundary somewhere or slightly over somewhere versus at some point, if someone's an attorney for example, then we don't really care if they hear about or participate in the survey. Certainly within the developer community, which is ill defined to begin with, how do you try and draw those lines to make sure that you get the best knowledgeable dataset possible? JONATHAN: You know, I don't really know. I guess, it's the meta point that I should probably make but it will prevent me from giving my opinion. Basically, I think that since this is a community survey, it makes quite a bit of sense for the community avenues for learning about Ember to be used to actually distribute the survey itself. For instance, these podcasts, like my podcast as mentioned in the survey and now, this podcast is going to mention in the survey. I want to say, "It's going to be in Ember Weekly." That's just a guess, I don't know. But there's really avenues: Reddit, Twitter, etcetera and then the Ember blog itself. Those are the means for dispersal within the Ember community. The one metric that we get from that is what can we reach or who can we reach? How many people can be reached through the normal means? That in itself a metrics. But I think it's kind of valuable to test that every once in a while. I believe over the first two, we saw 100% increase in respondents from Year 1 to Year 2 so it'll be interesting to see from two to three to see if that number continues to increase at a really rapid clip or if we're seeing some other trend there. It is an Ember survey so we are going to assume a lot of Ember-related things. We're trying to gain insight into the Ember community so it's probably not great to put it on JavaScript Weekly, for instance and get a bunch of React developers in that. They're going to be like, "I don't use this." Why are you using Redux, they don't understand. Oh, wait, Ember Redux, what's that? That sounds up my alley. ROBERT: I did feel that form out at the survey with my experience that I've had with React recently, things that I would like to see come over to Ember. I don't know... That'd be interesting to see or I wouldn't want them to fill it out because they would, obviously ruin the data set but I think another survey with more information from other communities to see like, "What's preventing you from utilizing Ember or what are the barriers to learning it?" Maybe from other communities might be interesting. That would be cool to do cross-pollinated surveys where you can be like, "We'll do it, if you do it and then React can provide us something and vice versa. I feel like the word homogenization is bad, usually but sharing ideas is good, I think. CHARLES: If you've never experienced this in your development community, the amount of work that goes into actually analyzing the survey and trying to draw and make inferences from it is just astounding. Who does that? Is that like Matt sitting up in an ivory tower? That's was just the wrong term. Basically, he can sequester himself for a month and put on his thinking cap and just come out with these mind-blowing deductions? JONATHAN: To be honest, I wasn't here last year at 201. My suspicion is that Tom will do quite a bit of the data munging, I think is the word. Then we'll go through phases where I think Isaac and Matt are working pretty closely with the survey stuff so they'll probably do feedback loops, then eventually before anything happens, I think with EmberConf, there's usually a survey blog that comes right alongside the EmberConf thing, where you share some of the results. I think that those things will go out to core and then core will start to pick it apart, toss that around exactly and then come back and basically, you're going to try to get as many people who are pretty smart, looking at it and trying to make sure the data makes sense and honest and doing the right things the survey needs to do, in relevant, I guess is the other metric. CHARLES: Now, as part of the survey, one of the things that you mentioned was the purpose is to surface weaknesses and gaps that need to be filled. When you think about your experience and the way that you filled out the survey, obviously it's anonymous, share what you're comfortable sharing but what were some of the things that you perceived as maybe holes that need to be filled and you're hoping that the survey will bring to light. JONATHAN: That's a very interesting question. I think, the thing that I'm interested in seeing is maybe different than what I've seen. One of the things I'd really like to see the survey that bring to light -- it's probably the most important metric in my mind -- is where people are at in the upgrade process because the cadence of releases an Ember is such a big facet of what makes Ember really powerful, especially for large companies and stuff like that. But I've personally seen people get stranded in certain spaces. Usually by the time they call a consultant to help them get un-stranded, they're at a point where they're going to try to work towards pushing past it. I think this is felt primarily around the 1.13 switch. People did get stranded there and some people are still working on very large apps to push past that and I would really like to see just where the community is at right now, in general. Especially as a consultant because you come into a project and I don't necessarily know what to expect. I think on certain teams, I am always shocked I see like, "Oh, you're using beta and everything. You guys are on top of this. That's really cool. Let's do some feature [inaudible]," and you're really excited. But then other times, you get called in and they're like, "We're still using 1.13 and we have bind others in our source and could you please help us?" CHARLES: Right and it's just that mountain is just too big to cross. That's something that you see in software development as the tools that you use tend to change and for lack of a better word, rot over time. In comparison to what's more newly available, it's the phenomenon of JavaScript churn, which is known in the community at large, scope down to just one framework where you've got different versions of the framework and you've got this churn. It's been somatic for Ember to try and it has been very aggressive attacking this problem and yet still, it manages to happen. How does that work, just given the amount of attention? JONATHAN: Ember, hands down handles this better than most other JavaScript projects that I've seen. I've gone to old backbone apps throughout my career and knock out in Angular one, etcetera. I've seen the rot that we're talking about here and usually, once it gets too bad, the authors of the JavaScript libraries are unable to push it forward at all. Either band in it or end of life it and you're going to have to invest your own time to get pushed past this point. In Ember, it really strenuously disagrees with that philosophy. They try super hard. All the people in core and really the community at large, the philosophy is like, "No, we're not going to break Ember. Ember is very serious here. We're not going to leave people stranded," yet it still happens. The reason I'm curious about seeing it is really about how do we make that story like a solved problem. Is it possible to do? Is it possible for us to basically make it to where the Ember community can very honestly say, "If you choose us if you choose this framework, it will be around. There will be a path forward for you for five to ten years and that's not something you can get a promise from anywhere else." I just want to see what are the ways that we can make that promise more strong. I think, the LTS was a big step in that direction. I think that was actually last EmberConf which the LTS was announced? ROBERT: Yeah, absolutely. Definitely all of our clients have moved to LTS as rather than trying to do every six weeks because they find that much easier to upgrade in between and they're more stable. JONATHAN: They're more stable and I think it's such an easier sell like if you actually start talking about going up the pipeline and you're like, "I have to talk to my boss and my boss just to clear money. We have to clear time, etcetera." We're going to put a [inaudible] aside every six weeks to upgrade seems a little untenable for a lot of companies. I think for larger companies, it's sometimes okay because they're actually utilizing some of the edge features which is cool and I think that's a big thing. I feel like I have no real insight here but I feel like that's what LinkedIn kind of does, where they're usually pushing the boundaries because they're utilizing features like engines were first brought into LinkedIn. I think it kind of pushing it at the edge. ROBERT: If you have the new LinkedIn Ember app, if you will crack open the inspector, when I last looked, I think the beginning of this week, they had two beta versions deployed. The Ember data version, that was beta and actual Ember, it was beta. CHARLES: Usually large companies are associated with big lumbering end piece that are in terrible condition. That's actually a breath of fresh air. Shout out to LinkedIn. ROBERT: Ember Data is 2.12 canary and Ember is 2.10 Beta 2 patch so it looks like they have a patch version. JONATHAN: It doesn't surprise me that Data is being pushed. I think last I spoke to [inaudible] right around December, he was doing a lot of perf work on there so I think he's really pushing that pretty hard. There's a lot of really cool stuff like that and I feel like it kind of runs the game. You see the smaller teams who choose Ember for stability, they sometimes get stranded so I want to see if some survey data can probably correlate. You could correlate the size of your company to the version of Ember you're on. Maybe, we'll see some trends around if it does it mean that smaller companies have more difficult time pushing forward. That would actually be a little counterintuitive. I would expect that smaller companies would be able to push forward at a faster clip because they usually have to support fewer browsers, etcetera. It'd be interesting to see information like that because I think that promise for ease of upgrade and there will be a path forward, that's a big part of what makes Ember really appealing to me. Especially as a consultant for four years, you see so many projects. I don't ever really want to advocate a rewrite but we're going to have to spend a significant amount of time fixing this and it's because you went with Mootools or something. Everybody guess Mootools wasn't so bad. CHARLES: But the point is that you didn't go with a holistic solution so you basically had to write your own framework. JONATHAN: Yeah. ROBERT: Yeah, in Ember, it is a feature that you will not be left behind and you can upgrade. That is something that is really nice. I have upgraded a lot of Ember apps. JONATHAN: I think Mike North calls that the patchwork app application. It's not just like React apps where you have React-Redux and Preact and all of this other stuff that you kind of piece together and make your own little quilt and that's your application. But this also happened in Backbone. It happened in jQuery before that and it was just like take this thing, take that thing, then I have this custom quilt, which is not bad. There are some advantages -- pros and cons. CHARLES: Ember is giving you a blanket. JONATHAN: And it's going to be a comforter. It's going to probably all look the same and be right. ROBERT: My experience is I love Ember and I love the convention over configuration but whenever you hit that wall of the convention is actually getting in the way now, that is a very tall wall to scale in Ember. CHARLES: Yeah, I think the flip side of it is like you say, Rob because everything does have to mesh, because that blanket has to be one solid weave, it means that you've got a hole in the blanket, the surgery required to excise that hole and then patch it -- ROBERT: I love his metaphor. His metaphor is -- [Laughter] ROBERT: It's so good. CHARLES: It takes a lot of effort. ROBERT: Today, I'm quilting daily. CHARLES: That's right. Next topic, crochet. [Laughter] CHARLES: But, yeah in order to make that surgery on the blanket to mix metaphors, which I love to do so freely, you have to make that cut and then make sure that the weave is again, seamless. I think that takes a lot of thought, it takes a lot of effort and it takes a lot of time. It means that there are shiny things out there that you might not be able to have. I think, one of the ways that the community and the technology is mitigated is with the add-on ecosystem, which is very, very strong and allows you to riff and experiment and push those boundaries. But there are core pieces, things like the rendering engine, which can't really be modified or hooked with an add-on. They can but not in deeply fundamental ways or the templating. We saw that happened. There was a big kind of shift from first, the old handlebars to -- ROBERT: HTMLbars? CHARLES: HTMLbars and then Glimmer 2, which there's been a flurry of activity around there but that was definitely one area where there was a hard wall right now. I feel like for me it's around the handlebars itself. I would like to see that environment become more powerful because certainly, with the React Native work that we've been doing around here, you get to see just how simple like the JSX model is, React aside because like Vue, you can do with JSX. I think JSX is a separate technology. It's certainly integral to React but there are a lot of other frameworks now that are using just the JSX part for the templating. Seeing that there is real power in being able to have the functional programming aspects of JavaScript right there inside your templates. From my perspective, I think that in Ember, there's a wall there that needs to be scaled. ROBERT: To be clear to the Ember developers that are listening like us kind of advocating JSX, if you are having like, "No, that's a terrible idea. I hate JSX," I had that very exact reaction about a year and a half ago. If you go look at my Twitter feed, you would see me ranting about how much JSX is a bad idea. After I actually played with it, I'm on the opposite side. I think JSX is really awesome and I think there are things to learn from it. CHARLES: I definitely love having templates. I love having the separation. I like having it in a different file but at the same time, I don't want to lose sacrifice the power that comes. I think that for people who are kind of sitting on the fence or have played with it, if you actually are strict about not having side effects and things in your templates, it really is a great experience. I think there's a lot of people who have scars from doing ERB or liquid templates, where you can have all kinds of crazy side effects -- ROBERT: That's where my scars came from -- ERB. CHARLES: Yeah, I can show. I can roll up my sleeves. I will be like, "You see this? I got that back in aught-seven with an ERB app, where they were calling out to a service from inside the template." ROBERT: Setting the variable and modifying everything. CHARLES: Yeah. There's definitely that tradeoff. One of the things that is great about the Ember community in particular is when there is, it takes a while to generate the will to recognize that this is a major problem but then the solution that you do get does, eventually match the weave of the entire blanket, which is really, really nice. But it can be frustrating when you have those core pieces of infrastructure that are presenting those walls to you. ROBERT: I'm excited for Angle Bracket components because that's actually a lot of the gripes that I had with handlebars. Whenever I got a bunch of the curlies next to each other, like a bunch of components around each other, they all kind of just mold together and seeing the brackets and just looking like HTML, it makes it so much easier to grip. CHARLES: Yeah, it's weird because you think that small things won't have big impact and you think that big changes ought to have a big impact. An example of this, I was kind of derisive of the whole Angle Brackets syntax. I was like, "Urgh! Angle Brackets, dah-dah-dah..." Then we started doing more JSX and you start seeing like, "I want to have my templating construct separate from my JavaScript and scripting constructs," and it actually makes a huge difference in clarity there. Obviously, the change to make all that happen is big but it's a small difference in the syntax. Tiny but I think it has a huge impact in the readability and the clarity of the templates and by the same token, all the performance increases. At this point, I couldn't even give a flip. It's nice. It's great but there's a barrier, there's a threshold that has been crossed, actually some time ago. Performance of rendering is -- I can't even remember the last time it was a problem. What about you? Have you run up against performance issues in your Ember apps? JONATHAN: Some performance issues but usually, they're a result of some rather inefficient rendering. Basically, a combination between user and keyboard or whatever. I wrote something really bad. It's not Ember getting in my way. I don't particularly mind the curly braces within my template but I think a big part of that is just editor choice. If your editor syntax highlights then it also knows how to indent handlebars correctly, that makes a huge difference. ROBERT: Are we about to start an Emacs versus Vim war here? [Laughter] JONATHAN: No, as a matter of fact, I suspect you would win that when the Vim -- there's no good solution for indentation in handlebar templates that I found in Vim. If anyone knows that [inaudible], "Oh, there's one plugin," please ping me on Twitter because that would be nice. CHARLES: Well, yeah. It's true. I can deal with it. I don't think it bothers me quite as much as it does Rob but I think what has been interesting is in our hypothetical code, you always like pay snippets in Slack. We started using Angle Bracket syntax just because it's so much clearer. Even though, none of us actually use it in any of our apps, when we're actually exchanging ideas, that's what we use. JONATHAN: Yeah, there's some cool things that come with Angle Brackets that aren't just aesthetic. The container element is like you don't have to deal with the tag lists stuff anymore. I feel like there's a few tradeoffs that are going to be really interesting to see when those start becoming the norm. CHARLES: Yeah, I like also the separation of what they did from JavaScript attributes to HTML attributes. It's really clear. JONATHAN: Totally. I think it's [inaudible] cool stuff. CHARLES: It's exciting. I remember being derisive of it -- not divisive, that's not the right word -- but I'm thinking like, "Why are they spending so much time on this," but I actually think it is going to have a big impact, small change. JONATHAN: Totally. CHARLES: No dis to the people who are working on it. I know it doesn't feel like a small change at all. ROBERT: Yeah, it only took a year and a lot of really hard work. [Laughter] ROBERT: Like I peek in there and I'm like, "Hmmm... Nope, not smart enough yet." CHARLES: One of the things that I want to ask you, you mentioned that at SO Ember, you gave a talk on FastBoot. You've actually got a lot of experience around the subject so I'm just curious. First of all, what were you talking about? JONATHAN: I think my talk was actually called Boots and Shoeboxes, which there's a little library function into the FastBoot suite called the Shoebox where you can communicate between node and the browser. It's not like well-known enough to where that title resonated with people. I got up on stage and I was like, "You know, we don't have any descriptions on the speaker note like website. He just talks about FastBoot. I hope that I don't disappoint you," because they had no idea what I was talking about. Actually, I feel like the problem that's the FastBoot solves is a persistent thorn in people sides. CHARLES: So what is the problem just to give full context? I think is it called like Isomorphic JavaScript for something -- JONATHAN: Yeah, I don't like using that word. CHARLES: Yeah, there's like server side, SSR -- JONATHAN: Yeah, SSR, you'll see that a lot. CHARLES: I guess the question is why would you even? JONATHAN: That's a multi-faceted question. I think the first section of it would be what's the problem? I think for a lot of people, the biggest problem is SEO. A lot of JavaScript frameworks are not search engine friendly, then that affects a lot of different things. It means that they're not archivable either so it's not like you can have this on archive. They're not very crawable. This is becoming less of an issue because Google Crawler, for instance will actually parse JavaScript now. But I feel like that's still limited. Also you have to then think about how the Crawler is going to like actually execute your JavaScript. You're like, "Wait a second, so now I have to have a compatibility table for Google Crawler? That sounds madness." I think that's a big component. There's also the idea of speed downloading as low as poor connectivity devices or locations, I guess. Having to download all the JavaScript before you see the first meaningful thing is not a very good experience. Especially for a huge swaths of different types of sites like Discourse, I think is a big Ember forum software. Forums are mostly just static text, like you just want to read the text so time in First Meaningful Paint could be like as soon as you get text onto the page, that's could be really fast. Some sites that doesn't make sense for it like if you're posting a video game or something like that, like you need interaction for that site to be meaningful. There's still tradeoffs there but there's a whole host so I guess that's the need. Then the solution for a lot of people is to start rendering JavaScript on their backend software and presenting full HTML along with a JavaScript source tag so that you get a Meaningful Paint first and then you get the JavaScript a little afterwards. The whole point of my talk, which I was basically like -- CHARLES: That's a hard problem. JONATHAN: Oh, it's a very difficult problem. CHARLES: Unlike anyone who says they have a solution, you should look at them with extreme mistrust. JONATHAN: Yeah and there's a whole bunch of different solutions that people have tried. You could actually have prerender.io, I think is the service that will actually render it for you and you put it in front of your CDN and they'll actually do that and create static files for you, which is a solution or no script tags. You basically render all of your stuff as much as you can on the server side and you put everything into no script tags and that will presents its own problems. There's a bunch of different solutions that people have tried. In FastBoot, the solution that Ember went with and I think that it's really cool because server side rendering and this is the big reveal of my talk. I think it's recorded so you can check it out. But the bigger reveal is that the server side rendering is not just about rendering. It's also about routing and data fetching and authentication and etcetera. There's a whole bevy of things that you also have to handle very well. It's not just taking a component, the view layer to component and rendering it to HTML and then serving that. It's much more than that. You want your app to basically run in node. FastBoot does that remarkably well. There are some spots where it's a little fuzzy but does it remarkably well. CHARLES: What's an example of how you would might need to handle authentication? That sounds terrible. ROBERT: One of the problems for a lot -- JONATHAN: That's exactly the problem. You actually have access to headers and stuff and FastBoot land so you can do authentication by using traditional token off, which is pretty cool. There's a lot of really cool things and routing is obviously handled quite well so the request comes in and it does the normal Ember router. The Ember app instance itself is running in node so all of the things you expect to work in the browser, work in Ember and node, with the exception of any time you need to access the DOM because the DOM is expensive like very, very, very oddly expensive. Like JSDOM is just expensive and unreliable, then you have to deal with compatibility tables for that. Anyone who has written tests for Phantom and tried to bind a function or something, they know the pain. I think it's fix now but I was always bitten by that so many times. It doesn't even give you the right error. Forget about it. CHARLES: You have all these things. It's basically authentication. It's data. It's making sure that you have in your, so to speak, headless environment as an authentic replica of your application running in the user's browser, as you can possibly retain. JONATHAN: Yeah. CHARLES: How feasible is that? Like what you're saying is that Ember takes that whole approach and says, "Okay, we're going to make sure we handle all of these cases?" JONATHAN: Yeah, I think Ember has done a phenomenal job of this. It's still alpha software, although I believe that the path to 1.0 is basically paved. It just needs some documentation. I think FastBoot hits the nail right on the head and gets a lot of the stuff really in a good place. It's also a big part of FastBoot's call to action where this stuff is possible elsewhere. You can do all of these things. You can make all of the stuff work in the React ecosystem or Vue ecosystem, etcetera. But in Ember, it's Ember install, Ember FastBoot, I think or Ember CLI FastBoot which is a really compelling sell because I've looked at some of the alternative approaches and in other ecosystems, they're very complicated. It's not possible. It's just their ad hoc -- ROBERT: And it's usually a 10,000 line medium posts that you have to follow line by line -- [Laughter] CHARLES: Right so instead of giving you actually a working code, what you get is a treasure map. JONATHAN: Yeah, exactly. It's like you just shop at Ikea. Here you go, build it. There's some really cool stuff that it unlocks and the fact that it's so low-hanging fruit, for instance Ember Weekend, which by all accounts does not need to be on FastBoot, isn't on FastBoot because it's ostensibly free and it's a good testing ground for me to learn about FastBoot. But the future -- ROBERT: It's interesting in handling audio on a FastBoot, how was that? JONATHAN: Since the user doesn't actually can't listen in node land, the user can only listen in a browser, we don't do anything with the player in FastBoot land, which is fine. There are some weird things like you have to basically have guards around like key events, for instance. Because Mousetrap relies on, I believe in jQuery to bind its events, you have to basically say, "In node land, we're not going to bind any of these Mousetrap events because they will not work," but there are some things you have to learn about the ecosystem but by and large, it's a solution that you just drop in and you just get for free. I think that's a huge sell. That's another thing with the convention over configuration argument, the model is that eventually, once the solution arrives, most of the people who are using Ember can just use it right away. It really does help with [inaudible] activity devices. There are some really interesting things about how time to first paint, I think Martin [inaudible] just released an add-on that basically says, "I'm going to take all of your JavaScript files and mark them as async and then when you download, the time to first paint becomes almost immediate," because it's just going to say, "I have HTML. Here's the HTML and serve it." Then in the background, because of script tags or whatever, it just goes and fetches the stuff in the background and you end up like time to First Meaningful Paint is really cool so it'll perform software that is super neat. If Discourse wanted to say, "Here's the stuff and we're going to make it work later," like as soon as the JavaScript has download, that's a really cool sell too. There's a lot of weird edge cases and describing the interactions is I think the hardest part about FastBoot. It's just like describing why this might be really good for you is the hardest part because a lot of people don't have these problems. If you're doing a marketing site, you're probably going to use Squarespace or something. ROBERT: Yeah, like a static site generator or something? JONATHAN: Yeah, exactly. ROBERT: Something that will give you great SEO results. JONATHAN: Exactly. ROBERT: You want to play around with that. JONATHAN: This dovetails into something Edward Faulkner was talking about eight or nine months ago when he was working on the inline content editor for Ember. It's really, really neat. I actually like to see where that's at now. I think it was Cardstack that funded a lot of the stuff for it. But if you combine things like that, then also FastBoot, you're starting to talk about something that could do what WordPress does, which is a really interesting thing like the really, really low hanging fruit. Type these few commands and you're point clicking your way to a website which is really, really cool. CHARLES: All right everybody, thank you so much for listening. Thank you, Jonathan for coming on by and talking with us today. JONATHAN: Yeah, thank you so much for having me on. This podcast is super awesome. I'm really excited to actually be able to be a part of it. I feel like you are at Ember Weekend that one time and you were in Norway? CHARLES: Finland. JONATHAN: Yeah, Finland and we weren't able to actually have a video open at the same time because of the data problem. It's been actually kind of cool to actually have a real conversation. That's been really great. CHARLES: Yeah, that has been awesome. That was a good conversation and that, your podcast obviously is EmberWeekend.com. Everybody go and check it out. Thanks for listening.
Liz Baillie @_lbaillie | GitHub | Blog | Tilde Inc. Show Notes: 01:32 - Becoming a Developer 07:54 - Website Building 12:03 - Understanding Programming 17:34 - Coming to Peace with Ignorance 22:25 - Systems Programming 26:46 - Making Goals for Yourself 28:57 - Math and Programming 38:08 - Open Source Resources: Wicked Good Ember Liz Baillie: Journey to the Center of Ember Test Helpers Fibonacci Number Freewheel: Volume One by Liz Baillie The Flatiron School Skylight Impostor Syndrome Twilio Letter to a Young Haskell Enthusiast Hello, Con! OSCON Transcript: CHARLES: Hello, everybody and welcome to The Frontside Podcast Episode 57. My name is Charles Lowell. I am a developer here at The Frontside and with me is Stephanie Riera, also a developer at The Frontside. Today, we have with us Liz Baillie, who is a developer at Tilde. I am actually really excited to have Liz on the show. I saw her at Wicked Good Ember back in June of 2016 and her talk was definitely one of the more memorable ones. You come away from a conference kind of only remembering a certain number of talks that stick in your mind and as time passes, the messages may fade but some of the message just stick with you and the one I got from her talk was a feeling of empowerment that, even though I have a lot of experience, I could approach any code base and try and grapple with it and understand it. I came away thinking, "There are a lot of code bases out there that I don't understand but if I apply a certain set of techniques and a certain level of fearlessness, I will actually get there." You know, if I want to go attack something like I don't know like Kafka or something like that, I would feel better about that. That was actually a great feeling coming away from that, a feeling of great power so thank you very much for that, Liz. LIZ: Yeah, no problem. CHARLES: Why don't we start with a conversation of how you came to be a developer? Everybody's got kind of a unique path. What's yours? LIZ: Well, I went to art school and I studied comic books. I actually have a bachelor's degree in comic books. I was a cartoonist for a number of years and at some point, maybe like 10 years ago, I had a friend who was a programmer. He's a web developer. But I didn't even what's a web developer was. But I knew he worked at home and he made his own hours and he made a lot of money. It seemed like an awesome job so I was like, "How did you get into that?" And he's like, "I don't know. I just kind of mess around and figured it out." And I was like, "Uh... I don't know what that means." Like how do you start? I have no idea. I went to the bookstore and I look at the For Dummies books and I got Programming for Dummies or something and it was like Visual Basic, I think. CHARLES: All right. What year was this? LIZ: That's 2004. I guess, it was a little more than 10 years ago. But it didn't say that on the cover. It was like 'Programming' and I was like, "Oh, cool. I'll learn programming." I don't even know what the difference of languages was or anything like that. I did a couple of exercises in that book and I had no concept of how this would become a website ever. I was making 'Hello, World' and little things that spit out Fibonacci numbers or whatever. I kind of gave up on that and I was like, "I don't care. I don't mind being poor." I'm used to it so I kept being a cartoonist, putting out books and stuff. I did a little PHP and HTML type of stuff in making websites for myself in between but I don't really consider that programming. It didn't feel like programming. CHARLES: Did you ever put any of your cartoons on the web? LIZ: Oh, yeah. Google me. They're there. [Laughter] LIZ: I might have some stuff like my web comic, I'm not sure if it's still up. But I had a web comic called Freewheel, which was about this girl who runs away from home and joins a band of magical hobos. CHARLES: That sounds like a career change to programming. It was oddly prophetic. LIZ: Yeah. It's out there. Anyway, I got to a point where, long story short, I was tired of being broken for all the time and I have to figure out some way to make money that I like doing so I thought, "I would go back to school," so I went back to school. I didn't start out with computer science but I took some math and science classes and I got really into math a lot. I really enjoyed math so I started looking into what careers can I do that are math-y. Somebody said, "If you enjoy the problem solving aspects of math, you'll love computer science," so I took a Computer Science 101 class or something like that and I got really, really into it like I just killed it. I just loved it. It was awesome. But I still didn't understand how you made that a website. In the back of my mind, I was like, "We did this thing --" We learned Python in my class so there's some program we had that like move a little turtle around and do pictures or something. I was like, "I don't understand how this makes a website." CHARLES: You got to move that turtle around a lot, especially like account for the kerning in the fonts and stuff. LIZ: Yeah. I have no idea how you make that a job, like the stuff that we were doing like spitting out Fibonacci numbers and making a little adventure game or something but how does that translate into anything else. That was in 2014 and that was around the time that web development bootcamps were starting to be more of a thing. I heard about a school called the Flatiron School in New York which is right at the time and I thought, "This sounds great. In three months, they'll actually teach me how this makes a website and finally know how does this make a website?" I applied in kind of like on a lark. I don't think I'll get in, I didn't know how can I afford it or anything and I applied and I got in. I was really lucky that my stepdad help me pay for it so I don't have to worry about it. I did that in three months and then I got a job. In November 2014, my first web job and now I know how those codes make a website so here I am today. CHARLES: What a journey. LIZ: Now, I live in Portland, Oregon and I make websites. Not really, I work on web apps, I guess is more accurate. CHARLES: So you actually went straight from the Flatiron School to working at Tilde? LIZ: No. I was in New York at the time and my first job was at an ad tech company called SimpleReach and I worked there for a little over a year before I got the job at Tilde, then I move to Portland. A year ago yesterday was my first day at Tilde. CHARLES: Fantastic. Knowing that company and knowing what they do, they must have you doing some really, really fascinating stuff. LIZ: Yeah, I do a lot of typical web stuff. I work on the Ember side of our app, Skylight. I also, more recently have been working on Rails engine that's also a gem that spits out documentation automatically, which is pretty cool. CHARLES: Now, is this documentation for the product or is it just documentation for any real site? LIZ: No, it's for our products specifically but I don't think it would be very difficult to alter for someone's personal needs, other than ours. But it's basically like if someone can write a markdown document, then we'll parse it and spit it out into HTML and all these different places so that it just updates the whole documentation site around our products. CHARLES: Basically, there's an infinite amount of stuff that has to happen to make a website because there are literally so many moving parts. What's been your favorite kind of area, I'll just say the whole website building because that really is like the tip of the iceberg. The actual iceberg goes way, way, way beneath the surface. But what's your favorite location on the iceberg so far? LIZ: I kind of like the middle, I guess. I always feel bad saying it because everybody talks badly about CSS but I just don't like it. I tried it really hard. One of my resolution this year was I'm going to try really hard and I'm going to like it more. But what I like the most is whenever I get to do pure Ruby. I learned Rust in the last year or two and anytime I get to make the stuff behind the visual aspect work or kind of like meta stuff. I'm saying this and it's totally wrong but I did my first meta programming the other day or last month. The metaprogramming that I did ended up getting cut out of [inaudible] but I got to do it before it got deleted. It was pretty cool. CHARLES: That's generally how it works. Metaprogramming is the program we do that we end up hating ourselves later for but it's really fun. LIZ: Yeah, they're like, "This is cool but this is not the most efficient to do this." It's like, "I guess, we don't have to dynamically create methods based on all our filenames. CHARLES: As far as the CSS goes, I actually see CSS like raw kale. It's actually really good for you, if you like to it eat in large quantities and it's like fantastic but it's not always the most pleasant going down. LIZ: It tastes bad. It has a terrible feel. It's like eating rubber. I am really lucky, though that I worked with a couple of people who are incredible at CSS and when I get to pair with them, it's like watching magic happen. CHARLES: Yeah, you realized, for all its quirks and strange ways that you approach it, is an outlier but it is kind of a fully-formed programming model that has a lot of depth and a lot of people have really, really generated some pretty neat abstractions and ways of dealing with CSS. But it is like, "I just want to fix this one thing," and it's basically a sea of things that I have no idea how to navigate. LIZ: It's one of those things. I always think it's funny, anyway that I come from a visual art background but the thing I like about programming is anything visual. CHARLES: That is actually really is fascinating. LIZ: Yeah, when they hired me here they're like, "You're going to be really good at design," and I'm like, "I just want to do programming." CHARLES: Like never the temptation, like this is just because you've actually kind of drank your fill of that in a past life? LIZ: I think I've talked to my coworker, Kristen about this because she actually has a design background and we paired together all the time. She's one of the people that I was talking about who are geniuses at CSS. She's a genius at it. She has a design background. We've talked about this how art and design are kind of different, like the brain stuff that I use to make a comic is really different from designing a book cover or designing an experience. It's all part of the art side of the brain but it's different compartments of the art side of the brain. I don't really have a design background as much as I have like a narrative and a drawing background. STEPHANIE: That and your interest for math that probably has a factor. LIZ: Yeah. STEPHANIE: Going back to your journey, I wanted to ask about it seems like it took you awhile to knock on different doors and finally feel like, "Now, I understand. How do I work with what I have to create a website?" We have similar backgrounds in that. We didn't start off in programming and I also went through a code boot camp. But mine was a little different where when I finish, I didn't really feel I understood what programming really was. I still felt like I understood a primitive level like just building something, just a 'Hello, World' using HTML CSS. When I finished, it took me a year and a half to actually get a full time programming job, like a legit job. Before that, I was scrambling doing three part time jobs and lots of WordPress grunt work. Even though I thought it was actual experience, it was enough experience but I feel like a lot of the programming concepts that I've had to learn and just basic functional programming, I've learned it on the job. I don't yet feel like I am a legit 'real programmer'. We were talking about the Pinocchio thing like, "I'm a real boy." But I want to be a real programmer. [Laughter] STEPHANIE: What I'm curious about is at what point did that happen? When did that click and when did you stop having -- I'm sure at some point you had -- impostor syndrome? When did that just evaporate and you're okay? LIZ: I still have impostor syndrome all the time. It's weird that it's like I have a sense of, "Oh, I can figure anything out." At this point, I know who to ask or where to look and I could figure anything out if I really wanted to. But I also feel like everyone else is better than me. I get impostor syndrome in that sense, not that I'm not a programmer but that everyone else is better than me. When did I start feeling like I was a real programmer? Definitely not at my first job. When I started my first job at SimpleReach in November 2014, I had two months in between bootcamp and the job. In that time, I made some weird little apps but nothing super serious. I made an app that I use the Twilio API to anonymously text Seal lyrics to people. It sends either lyrics from Kiss From A Rose or a fact about Kiss From A Rose. You can choose which one. I made stuff like that. CHARLES: [Singing in the tune of Kiss From A Rose] There's was so much in app can tell you so much it can touch. Okay, I'll stop. I'll stop right there. I promise. LIZ: Yeah, so I did stuff like that and I sort of wrote my own crowdfunding to go to RubyConf because I gotten an opportunity scholarship ticket that year. But I couldn't afford to go otherwise. I did a little crowdfunding thing but I did little things like that. I didn't really feel like I understood everything so I was looking on other people's code and forking stuff to make all that happen. Then I got my job and it was small-ish start up at the time and they didn't have a whole lot of on-boarding at all. It's kind of like I showed up, they gave me a computer and it took me three or four days to get their app running locally. It was just a lot of leaving me to my own devices a lot of the time in the beginning and I was kind of like, "I don't know what I'm doing. What do I do?" It took a while. As the company matured and as I matured as a programmer, they kind of develop a little more infrastructure, I guess for supporting junior engineers. As time went on, I became better and they became better at mentoring me. I don't know when I felt like a real programmer, probably sometime in the middle of that job. I gave my first technical talk, I guess or conference talk at EmberConf in 2015. I gave a lightning talk at the behest of the Leah who is now my boss. It was a five-minute talk on why testing an Ember sucked at that time. It sucked for me to learn and it was really hard. I wanted to learn it but it was really hard. Then after that, people started talking to me. They came up to me after and they are like, "Oh, my God. Blah-blah-blah." I was like, "I don't know half the stuff these people are saying. I don't understand what you're talking about." I'm going to smile and nod. But maybe a little bit after that, I kind of started feeling more that I could solve problems. I think public speaking actually helped me a lot with that like when I realized that I had something to say and that people want to hear it, then I could help other people feel empowered to learn stuff, I think that was part of it as well. CHARLES: Yeah, I really like that. Obviously, I'm going to push back a little bit on Stephanie, just in terms of the day-to-day. You definitely deliver daily as a programmer so you can look at that. You've mentioned this at the very beginning of your answer and it almost really sounds like what you came to be was more of a kind of a peace with the things that you didn't know, rather than feeling confident about the things that you did. You said something and I'm going to paraphrase it but it's like, "I got to the point where I became sure that I would be able to figure it out." Or, "I had strategies for being able to figure it out." Maybe we can unpack that a little bit because I feel that's actually very, very important and that's a skill that's important to have at any level of experience in your career, whether it's one year or whether it's 20. Certainly, that message when I saw you speak that's something that I took away as a very experienced developer. I felt actually empowered by it. What are some of those mechanisms to feel at peace with your own ignorance? LIZ: I think part of the problem for me, I started learning how to program before I went to dev bootcamp or whatever, that I was really good at stuff. I actually think that was a problem because I was used to succeeding immediately or like always doing everything right so it's hard when you start learning something and you don't realize when you first start learning programming and it's not supposed to work immediately, like you're starting with something that's broken and you're making it work. CHARLES: Right. In fact, 99% of the experience is like every time I look at a piece of software, I'm like, "Someone sat with the broken version of this for a year and then it work and that's what I got." They got to live with the working version for two seconds before it came to me and they spent the rest of the time, totally broken. LIZ: Yeah, totally. It's hard when you're used to creating something from scratch like doing comic books and like writing stories and stuff. It's never broken it's just blank and then you add to it so I'm used to that sort of workflow. Then I started in this new field where Rails is new or whatever then it's just errors as far as the eye can see until you fix it, until you configure it, you made it work. It's hard to change your mindset into that. It's easy to feel like a failure when all you see is errors and you don't know that that's normal. I helped a couple of my friends to learn to program and I think the biggest hurdle is just mentally overcoming that it's not you, you're not a failure. It's just that everything's broken until it's done. STEPHANIE: I can definitely relate to that. I was always one of those overachievers, straight A, AP class. I'm not even kidding. In my high school, they called me Hermione, which for those that don't know, that's the girl from Harry Potter. It's like you take it really personally when you feel like you're a failure. You feel like you can't deliver, you don't pull your own weight. For me, it's actually so overbearing that it can even inhibit you from doing things like public speaking or other activities. But one of the reasons why I do like to teach whenever I can is because that's when you realize, "I do know a lot of things," like how to do stuff on Git and just basic things that you don't even think twice about. I volunteered for this these high school girls and no one really gave me any instructions and I just rolled out of bed for this thing and just have them build a basic cute little web page with their picture and this and that. I had to really think hard to how do I put just a regular image tag and I had to peel back all the old layers of stuff that I don't do anymore. You don't think about those kind of things in Ember or JavaScript frameworks. I caught myself in keep on saying dom and this and that and they were like, "What is a dom?" And I'm like, "Urghh." But then I realized, I do have all this context, I guess I don't appreciate it or something. LIZ: I think talking to beginners when you're slightly above beginner-level in helping other fresh beginners is one of the best things for you as a new developer because you realized, you're like, "I actually know stuff." STEPHANIE: Yeah, that's usually the type of advice I like to give to other aspiring junior programmers. I also wanted to ask about it seems like now you're going through something similar because you tweeted or you're asking about systems programming. What's that like? LIZ: I'll start at the beginning. When I started at Tilde about a year ago, I knew that we use Rust, which is a systems programming language, a lower level language than Ruby or JavaScript. We use it for some aspects of our stacks. I thought, "That's really cool. I want to get into that nitty-gritty type of stuff so how do I learned that?” I started learning Rust but I didn't really know how to apply that knowledge. I wrote like a little adventure game in Rust and it was almost exactly the same as when I first started learning about web development, it's similar to how does this become a website, instead of like, "How does this become a computer thing?" I don't even know what systems programming is but I hear Rust is a systems programming language so I want to learn that stuff, like what is that stuff? A couple months ago, I think it was, I tweeted like, "Anybody have any probably three systems programming resources so I could learn more about systems programming?" And I got huge amount of responses. Everybody was super kind and helpful but a third of the responses were like, "Well, what kind of systems programming?" And I was like, "I..." [Laughter] CHARLES: "The kind that happens on a system?" [Laughter] LIZ: I don't know. It was kind of the same thing. I think I used this metaphor earlier but it's similar to when I first started learning programming it was like I was standing at the front of a forest and I knew that the stuff I want is in the forest but I don't even know what a tree is, you know what I mean? Eventually, I learned what a tree was then I learned what a map was and I learned how to get through that forest. But then in the middle of that forest, I was like, "Oh, there's a tunnel," like there's another stuff. "I want to get on to this tunnel," but I don't know anything about living underground, you know what I mean? Like, "What do I need? What even is there?" I have no idea so that's kind of how I feel about systems programming. At the moment, I'm trying to go into this tunnel but can I breathe down there? I don't know. Where does it lead? CHARLES: I feel like at that point when you're about to enter into the tunnel, can you intentionally apply filters for information that at that point is not useful like the difference between a stalactite and stalagmite is not useful when you haven't even gone into the cave yet and you're just like, "How do I actually just get down there with a flashlight?" How do you go about deciding which information is useful and which is not at your particular stage? Because obviously, it's all going to be useful at some point but at what point it becomes useful and what point do you just catalog it and put it for later? I feel like that's very, very hard thing to do. Do you feel like you're able to do that? LIZ: I'm not sure. I think I said this earlier but I feel like I can figure most things out at this point like if I really want to. One of the things I learned just from talking to people on Twitter about systems programming is like, "Oh, some examples of systems programming are operating system," or like a browser engine because I'm still learning Rust and I gotten to write as much lately but I know that there is servo which I believe is a browser rendering engine written in Rust, it's something like that. CHARLES: Supposedly it's going to powering Firefox at some point. LIZ: Yeah, stuff like that, I think is really interesting but now I know a little more about what to look at in terms of as far as I understand, there is probably an infinite amount of different kinds of systems: operating systems is one, maybe a browser engine is another. I can't remember the others but I'm sure people tweeted it out to me. STEPHANIE: I feel like we touched on something which is it can get overwhelming when you're starting off in something new. Trying to understand what you don't know that you don't know. LIZ: Yeah, that's the hardest thing. STEPHANIE: How can you make tangible goal marks for yourself if you don't even know what you don't know? When I first started off, when I would pair with someone that was more advanced, I remember having a realization that every time I would look for an add-on or I'm looking at someone's repo, I would take my time to read everything about it, all of the Ember documentation and I need to know everything. Then later I realized that is totally not the case. Like Charles said, people develop this filter for noise and only focusing on not the entire tool box but that one tool that they need for that one specific thing that they're doing and I realized it only when I was pairing with people and seeing that. They go to this repo, skim it, "No, this is not what we need. Let's go to the next one. Let's try to find a method that what we need," and then they would just search on the page. "Oh, this looks kind of similar. Let's plug this in," and I'm just like, "What? You can do this? You can just copy/paste someone else's stuff?" and it was amazing. But when you're starting out, you don't know all of these things and unfortunately, kind of waste a lot of time thinking that you need to know everything and you don't. CHARLES: Yeah, Cheating is totally a virtue in so many cases. [Laughter] LIZ: Totally, for sure. CHARLES: Just being like, "I don't need to understand this," but I just know that it works. You pushed at what point that happens like further and further back but that boundary of understanding is just simply always going to be there. No matter where you are, that kind of veil of ignorance, you can push it out but it's just can be further away. I am actually curious, you mentioned you got really into math, this is when you went back to school. What drew you to that and how have you applied, if you've applied? Have you found it to be an asset in your development career? LIZ: For sure. When I first went back to school, it was with the idea that this is totally different now, obviously. I thought I might become a veterinarian -- CHARLES: You need a lot of math for that, right? LIZ: Well, it's like a lot in biology and there's a lot of math and science and stuff. I had to take a bunch of science classes and take biology and chemistry so that involved taking some pre-calculus and calculus and more calculus. What I realized, though was that I hated biology and chemistry but I love the math that I was learning. I loved the process of problem solving and just figuring out puzzles. When you get into calculus, how you solve problems, they're similar to how you solve problems in programming where you have sort of a framework like I have this certain language which would be the different theorems or whatever in math and you can just pick and choose which ones will fit your problem and if you're taking a calculus test, you could be sitting next to the same person and you might come to the same answer in different ways so it's similar in programming where you have all of this documentation, you have these languages, you have use other frameworks and you can solve the same problem in a million different ways. But in terms of how people talk about needing math for programming, I don't necessarily think you need math for programming but if you already like math, it's definitely sort of a happy path, I guess because you get the same joy out of programming that you get out at solving calculus problem. But if you don't like calculus, it's okay. I don't think it's necessary. CHARLES: One of my favorite blog posts of all time is this letter to young Haskeller, I don't know if any of you guys have ever read that. It's fantastic and it's an experienced person in the Haskell community talking to someone who's just coming in and it's incredibly empathetic and wonderful. I think it's a message that needs to be heard more generally. I think it's ironic coming out of the Haskell community as it does because they definitely have a reputation for being a little bit salty and a little bit exclusive. But it's actually a very inclusive message. One of the great points they make is they say we've got the whole equation reversed. It shouldn't be, "Math is hard, therefore programming is hard." It should be, "Programming can be really fun, therefore math on which programming is based, can also be really fun." You can go both ways. If you find math fun, you can find programming fun and if you find programming fun first, you can later go and have fun with math. You can pick and choose which parts you want. I think it's a great message that needs to get out there. LIZ: I think it's also really, really important to note for anyone who might be listening that is getting in to programming, that is scared of math or has had a bad experience with math that it is not necessarily to love math. I think that scares a lot of people away and a lot of the stuff that people learn when they're first learning programming are math based. When I was in the Flatiron School, Some of the exercise we did in the beginning with just pure Ruby were Fibonacci sequence. They were sort of math-y and that turns a lot of people off and makes people scared. If someone is hearing this and has experienced that, don't be scared. You don't need to worry about it. But if you love math, then it's great but you don't have to. STEPHANIE: I'm one of those people that always had this mental block of like, "I'm not good at math." I was good at everything in school. I excelled at everything except math. I think a lot of it came from my struggle when I was a kid so you have this self-perpetuating thought that you aren't good at something. Every time you take a final or something, you blank out because you have this mental wall in your mind. What I found weird was I was doing the exact same thing. I was taking calculus for bio-sciences and physics too at the same time. In physics, I loved that class. It was so awesome and I realized that half the stuff I was doing was going backwards in all of my problems and it was fun for me. Eventually, I was taking a final for my calculus class and I didn't remember the equation that we needed for that class so I took out all the variables and I solved it as if it's a physics problem and I got the same answer and I was correct. I realized at that moment, if you just remove the negativity from your mind and you try to apply yourself in the same fashion as you would in something that you enjoy, you'll just forget for the moment that it's math, that it's something that you 'suck at'. You actually could do good in it and not get stuck. I realized I actually do like math when it's veiled as chemistry or physics. LIZ: I think a lot of people have that experience with math. They have a really bad experience when they're young and then they get stuck and they feel like they're just not good at it like somehow, on this subatomic level, you just can't change it or you're not good at it. It's not really true. STEPHANIE: Yeah. CHARLES: I actually love that example because it is, it's all integrated. We are constantly doing things like math without even realizing it. Actually, one of the things I love about the Montessori education is that's the way they actually teach it. They have all of the different great lessons, they want to convey to the children which is things like courtesy and grace, things like taking care of your things, things like music. But for all, I think they've got a bunch of different categories but they make sure that they always intersect with each other and you get that in surprising ways to make sure that if a child likes music, use the music as a way to introduce them to arithmetic. If they like arithmetic, use that as a way to introduce them to music. If they have things doing design, I don't want to say, interior designer or clothing design but practical life stuff and if that's something that a child really is drawn to, then they'll use that as an introduction to music or geography. There's all these parallels that are constantly there and you can ride whichever rail works for you to whatever area that you want to go. There is no set way to approach math. You literally can find a way that works for you. STEPHANIE: The subjects aren't mutually exclusive, "Because you're not good at this, probably you shouldn't become a programmer." CHARLES: It's not expected that every child will grow in one subject at the same rate that they'll grow in every other subject. They just let the children explore the area that they're interested in and let them go crazy. If they're really into art, they just let them explore and learn as much as they can and then slowly entice them and just show them the connections that art has to courtesy and grace to math to music to other things and let them see those connections and then follow them on their own. That's why they call it -- the kind of grown up in there -- the guide. It's really there. The way that they push is by showing them the connections but then using the kind of internal motivations of the children to move. I actually have some pretty strong feels on this. I feel like our education does leave a lot of people behind because there's this expectation that in every single subject, everybody will goose step forward at exactly the same rate and that's just a fable. It's not real. It's not how the human mind works. LIZ: Yeah. CHARLES: But yeah, I actually think, certainly for me and my connection to math has been helped by the fact of programming and now, later on after having done a lot of programming, so much more is interesting to me about math and I can see beauty in it, I think where I didn't see beauty in it before. STEPHANIE: For one of the projects that we've been working on, we have been doing an Ember upgrade. I basically needed to get some changes for one of the dependencies and I have no experience in open source, whatsoever. That happened for the past two weeks. I was making a lot of PRs to two different dependencies and that was my first experience with open source. It was less scary than I had imagined and I actually got a lot of great feedback from it. Now, I realized that it wasn't as hard as I thought it would be and most people are very receptive to your PRs or if you have questions about their open source because they need help, they need people to help them tackle all the issues that they have so I'm curious, do you have any advice for people that are interested in contributing to open source but they may find it daunting and they don't want to look dumb or do things the wrong way? LIZ: One of the things I've been interested in since I started learning programming is open source because I enjoy collaborative atmospheres and just the idea of a big group of people coming together to solve problems. It was something that I wanted to do since the beginning but it's super intimidating because when you think of people who are open source maintainers, at least to me in the beginning, they seemed way above me like Gods so I'm like, "How can I possibly be useful to these Gods?" At my last job, my manager was like, "I got a couple of goals for you and for your career." One of my goals was I want to contribute To Ember CLI Mirage. That was a goal. I just thought, "This is a great add-on. This is a great project and everyone uses it and I love it and I would love to contribute to that." I made it a goal but then in that in the middle of that time period, I got a job here at Tilde and I went to Portland. Shortly after that, I went to the repo and I was like, "I'm going to do this thing," because one of the reasons why I chose it as a project to contribute to is because I heard Sam is a really nice guy. One of the things was that I was really intimidated by the people maintaining projects is like, "Well, he's not intimidating." I feel okay about this so that's a good first step. The second step is let's find a thing to do so I look at all the issues on the repo and I find something super simple which is just adding in-line documentation. That's what I did and I was like, "Can I pick this up?" I was feeling super shy so I didn't even want to put it on the issues so I think I just pinged him on the Ember Slack and just like, "Can I help with this?" He's like, "Yeah, yeah. That's great," so I made a bunch of in-line documentation additions to the project and I made my first PR and it felt like such a way that it's not as scary at all as I thought it would be so I started contributing to other projects, things that just came up. Not so much like in your situation where it was a dependency I was using but more like I saw somebody tweet about it and like, "I just made this project and I think there's a bunch of typos. Can somebody just spell-check this for me?" I'll go in and do a couple of typo fixes. Another situation when I was reading through a repo because I want to learn and there's a project called intermezzOS which is Rust operating system, like a tiny operating system. I was just reading the code and I was like, "There's a couple of typos. I can fix this," and stuff like that and I found, through that experience, that open source maintainers are super happy to have you help in any way that you can, even if it's a little things. In the last couple of months, I started my own project which is like an app -- it's not an add-on or anything. I actually got my first couple of PRs from other people and other people are helping me build it. I don't think I've ever met but every time I get a PR, I feel like I won a prize. Every time someone contributes and I'm like, "Thank you." I cannot give you another -- [Laughter] LIZ: I love that you're helping me. You know, like I only have one hour a day to work on this thing so anything, anyone people can do to help me is so great. Now I have the experience of being on the other side and I can attest to the fact that most open source maintainers are incredibly stoked for any help they can get. Even if you're new, just find someone who's nice and ask them how you can help. STEPHANIE: Yeah, that was a realization that I had because I was communicating directly with this person in the Ember Slack as well. I had submitted a PR and later he was like, "Hey, while you're at it, do you mind adding in this one property that's missing?" And I'm just like, "All right. Sure." Later he offered if I wanted to become a collaborator because I was putting in so many PRs and like you said, he hasn't had the time to cut out a new version or to fix the things that you keep in your head, "Okay, I'm going to go back and fix this," and then someone else is like, "I want to fix this thing," go for it. That's the best. LIZ: Yeah, totally. It's a great way to learn more stuff too. CHARLES: I like the point about choosing a project that you know is not intimidating because unfortunately, there is a lot of negativity that happens out there. LIZ: Totally, I knew that and that was a big blocker for me, for a long time. CHARLES: Yeah but knowing that there are actual, I would like to say, a majority I don't know if that's true but it can feel like it's enclaves, just because negativity has a way of clouding everything and propagating but there are certainly areas where we put that way and it's very healthy, it's very collaborative and welcoming and making a definitive effort to first know that they're out there because if you have a negative experience, you make sure that you don't bounce off of that and then define them. I really like that, how you were deliberate about that. LIZ: Yeah, it seems like the most important thing, if you're a new programmer and they're like, "How do I get involve in open source," and your first advice is like, "Find someone who's really nice." It doesn't sound like the right advice but I think it is the right advice. CHARLES: That's because that's where you'll stick. LIZ: Yeah and you'll want to collaborate with that person and that project because you're not scared of being insulted or something. CHARLES: Well, that was fantastic. We can wrap it up. LIZ: I have two talks this year so far coming up. One is going to be in Toronto at the end of this month at a new conference called 'Hello, Con!' I built a type space adventure game in Rust and I built it side by side with the same game in Ruby so I can learn Rust by doing the same thing on both sides. I'm going to be talking about the similarities and differences and things I came across learning Rust as a Rubyist. I also have a similar talk in May at OSCON in Austin about learning Rust as a Rubyist but at a slightly different, longer talk. I did a version of it at RustConf last year. It's kind of in comic book form so it's all of drawings and it's sort of a story about going to a place called Rustlandia as a Ruby person and how you literally navigate that world, not just everything is sort of a metaphor. I'm getting that talk again in a longer form at OSCON in Austin in May. CHARLES: Well, fantastic. You have to stop by the office and come see us. LIZ: Yeah. CHARLES: But thank you so much -- LIZ: Thank you. CHARLES: -- Liz for taking the time to talk with us. This is a great conversation again. You know, I feel like I'm going to come away feeling that I've got more tools to deal, certainly with my daily struggles -- LIZ: Yeah, get pumped! CHARLES: -- In programming. Yeah. LIZ: Programming! Yeah! [Laughter] LIZ: -- One of the Mortal Kombat music comes in -- Tun-tun-tun-tun-tun-tun-tun-tun-tun... [Laughter] CHARLES: I remember actually seeing Mortal Kombat in a theater and I actually getting up and dancing in the theater and then the rest of the movie just sucked. It was like they spent the whole budget on the first 20 seconds of that movie. Anyhow, all right. That's it from The Frontside. Remember to get in touch with us at Frontside.io, if you're interested in UI that's engineered to make your UX dreams come true.
Toran Billups @toranb | GitHub | Blog Show Notes: 02:23 - Ember 2.0; Data Down, Actions Up 08:28 - redux and State 16:39 - Dispatching Actions/Patterns 24:00 - Components and Routing 31:00 - ember-redux and Cloning the react-redux API 35:22 - Hot Reloading 41:22 - Audience 47:02 - Motivation 50:25 - Building Component Trees Resources: Toran Billups: Test-Driven Development By Example @ EmberConf 2015 Dan Abramov: Live React: Hot Reloading with Time Travel @ react-europe 2015 react-redux Charles Lowell: Immutability is for UI, You and I @ EmberConf 2016 redux-thunk Ryan Toronto: Safety of the herd EmberMap: Component side effects Functional Programming Browserify More Toran Billups Talks Transcript: CHARLES: Hello everybody. Welcome to The Frontside Podcast. This is Episode 55. We're broadcasting and everybody's here in Austin, although we're still remote. I am here with a really special panel today. There's me, which makes it special by default. My name is Charles Lowell. I'm a developer here at The Frontside. I'm also here with Robert De Luca, who also develops JavaScript codes at The Frontside and we have today [drum roll sound] -- I'm really, really going to work that drumroll -- Toran Billups. What's up, man? TORAN: Hey, man. Thanks for having me. I'm really excited to be here. CHARLES: Toran is with us today and he's going to be talking about a lot of things. He's going to be talking about today mostly about Redux and his efforts to meld Redux and make it useful within the Ember community. But first, if you have not heard of Toran, I think the first time we'd interacted over email, Slack briefly but then when I really, really saw you for the first time was at EmberConf, I think in 2015 and he just gave the most amazing talk on Test Driven Development and really kind of the focus on you can set up your acceptance tests from the outside into really define that behavior and set out that firm shell and then actually build your application from the outside in. You've really kind of been talking about that message. We like to have people on here who all about walking the walk. That's certainly the first thing that I've noticed that you were doing in the community but then more recently, you've been playing with Redux. Not playing with Redux, actually making a concerted effort to bring this kind of pattern into Ember. I just wanted to start out, how did you jump onto that track? TORAN: Some months after EmberConf in 2015, as you mentioned that talk was not only, probably the most well-rehearsed talk I've ever given but definitely the most well-received. I got a lot of people excited and really gave me a lot of opportunities that weren't there before that was also believe in that keynote in 2015 as when Ember 2.0 was announced. The interesting part of Ember 2.0, of course was we were using it, and it was called Ember 1.13, which actually made it really great. At the time, I was very much excited about the stability that offered. Other folks were not as much as interested in that idea or those values, in the JavaScript community so it's really exciting. Yet at the same time, there was this new mantra that was being talked about more that I knew nothing about. It was this 'data down, actions up' idea. I still remember as much as the stability was awesome, I also started to doubt not Ember core in particular but the ideas that were being espoused by other folks around the Ember core team because I didn't really understand the value. For instance, if I had the tree of components back then in early Ember 1.13 or 2.0 days and I had an Ember model or some kind of Ember object at the bottom of this tree, why would I not just do Ember.set. I remember, actually you may recall conversations you had with people at EmberConf around that time but there was actually varying definitions of what 'data down, actions up' meant to different people and actually never met the same thing to anyone. It was funny enough. Because of that, it sort of drove this fear in me that I didn't know what I was talking about. I was consulting at the time so I wanted to sound like I knew what I was talking about as you probably should. You guys are in that business so you know what I mean. Because of that doubt, eventually I sort of become apathetic to really trying to understand better what 'data down, actions up' meant or how components should be constructed and really what the wider impacts of Ember 2.0 meant. Because of that, I just found myself, not really loving learning. I felt like everything else in learning was a hyped up thing that would never happen or a hyped up thing that I didn't really understand or didn't make sense in the context of Ember at that time so I just kind of floated by. Everybody has their ebb and flows in the journey of excitement or not. For me, this was just the down moment. One of the things, like an analogy to this is when you lose your hunger in real life, you'd be very much like losing your hunger for learning. There's this interesting hormone that your body produces when you're actually physically hungry that kind of gives you the physical symptoms like your stomach cramps that tells your brain probably should eat somewhere. When those things aren't happening or that hormones not being produced, it's often because you've quit eating yourself. If you've ever gone on a fast or something weird like that on day three, your body quits secreting this hormone so you just sort of or not hungry at all, which is kind of weird. The same sort of thing was happening to me. If you ask a doctor or a physician, "What's the first thing I should do? I'm not hungry anymore." They'll tell you, "You just start eating." But I'm not hungry now so the same thing applied in my life and I think the first step really is just eat anyway. In this case, it was just learn something anyway even if you're not in love with learning right now. Eventually, your body will start producing this hormone, in the hunger example and for me, I just sort of got back in the flow and what came from this was a routine, which is really the second part of how you get your hunger back, not just eating once a day. I was eating three meals a day or more, especially if you haven't been eating. For me, I just set aside an hour a day, in addition to consulting work and things that would get me interested in loving learning again. The third component to this was trying something different. At the time, of course I was just doing Ember, I pretty much had done Ember since 2012 like some of you guys and I feel like there wasn't a lot of new. There was patterns and ideas but there was anything really challenging me. That's when I sort of looked around at the React community and I had done some React in the early days when I was super hyped up but I still feel vaguely different. Not that it's jQuery or any way but I didn't feel like this fully encompass single page out framework. The reasons I got into Ember very early on were that I wanted to build rich single page apps. If you guys remember from the early React days, that also wasn't really the messaging with React and maybe today with View. In fact, that's kind of one of the benefits or they speak to in those communities about why you use React because you don't have to use it for your whole app. You could kind of piecemeal it in, which totally cool. You got to see it out with Ember too. But in my mind, I just wanted to build a rich JavaScript lines that could compete with the iPhone or the iPhone apps that were popular in that day. Through this process, I started looking at React and really just kind of get back into it again, get going again. I wasn't really in love with it but I needed to try something outside of the realm I was used to. As part of that, I noticed there was this talk by Dan Abramov, I think he works for Facebook now, big in the React community, of course and he gave this talk at a conference in Europe that introduced Redux. What's funny, if you find out or dive deeper into that story is he actually pitched the talk, not really having built any of this and just thought, "This sounds like a great idea," and then of course the talk was accepted. Like most, he delivered on that promise and made a great talk. There are definitely courage folks to check out and I should link it to you here. We can show noted that, I'm sure. That talk make me excited mostly because there was a lot of whiz-bang. If you guys remember any great talk you've ever seen, the talk even that I gave at EmberConf that you mentioned, Charles the thing that blew people away was this very end moment that, of course I had produced to be a great moment. In the same way, Dan during this talk introduced some new ideas or new to the JavaScript community. One of those was the tooling that can change when the state doesn't change in your application. That got me sort of piqued my interest, in part because I was actually big test driven guy and I thought, "I won't use any of this stuff. It just seems cool. It's a gimmick. Tester development is how you really build app." If anything I thought to disprove it by getting involved and learning a little bit more but what I instantly found was the simplicity of data changes rerender. That sounds very high level, of course but it was almost just that simple, instead of being like how does this change to an object in my array, bubble out through notifications on the Ember side and notify the Ember change detection to rerender. Well, I'm not entirely sure so when I was start debugging that, I noticed a lot of framework code between me and the rerender. It's that's how Ember is, right? When I boiled that down in jQuery with vanilla Redux, not even using React at all, I was like, "Wow, there's just a call back. I wonder why I haven't been doing this." CHARLES: As a single callback for a global state? TORAN: Correct. CHARLES: So there's no call back for every single path in your tree. You just used that one call back? TORAN: I'll fill in for Rob here. I know he's jumping at it. You should probably define a Redux is. He's really good at asking that question. Redux in this case, for me is just a global JavaScript object to use to hydrate your templates. They'll give you some big spiel about state container, if you go check out the website. But for me and in this context of being on an Ember-centric sort of podcast, we already use this idea in Ember today. If you're just feeding your templates from some high level service, it's a very similar idea in that Redux is just a single service. In the Ember case, especially you can talk about the add-on, I maintain later, but really it's just a service with a single object that will help you populate all of your components. ROBERT: Yeah, I love Redux. I actually sort of coming into the Redux world, probably to about six to eight months ago and it was around the same thing like exploring React stuff. I share similar opinions to you as nobody really can define 'data down, actions up'. I also think that 'data down, actions up' cannot just live in the component. In a lot of the Ember apps I worked on, there's times where I'll be looking up to get a new state and it comes in from the side and something's mutating, something that I have no idea why and where it was mutated and Redux does a really good job at helping you manage what changes and why it changed. CHARLES: I have a question too. When you're actually using Redux, you said you got a single tree that you used to hydrate your templates. In the context of Ember, where do you maintain that single object? I assume you have one store, one instance of your Redux state per application? TORAN: Correct. There's just a service like you imagine in the Ember data service and that holds on to really just an identity map or a single graph object that will let you pass or pull that in by injecting the service into your components if you want to do that or your route then just asking for that state. CHARLES: Because I think that for a lot of people in the Ember community certainly, when I was kind of grappling with these ideas, the idea of having a single global object as your state seems so counterintuitive, so going to go against everything that we learned, that you have to decompose a problem into its component parts. Obviously, Redux has an answer for that so how does that work? How do you decompose that state into saying, "I'm just interested in this kind of local state." How does local state work in Redux? TORAN: I should define local state is state specific to the component. It doesn't need to bleed up and has no value at the global level. CHARLES: Usually, I got two components. Let's say, I want to store both of their states in the Redux store. Obviously, component one is not interested in seeing any state that's not related to it so it's only interested in its own state and it's not interested in any of the surrounding context. How does that work? How do you connect a single component or connect a route to the store? TORAN: There's really just a simple method on Redux -- the Redux store itself, which it says, "Give me the state." What may not sound great at first is that it say, "I will give you all the state and that is your job to pull from that or map three attributes from that whole tree into my component." Then by side effect if you're using our add-on or if you don't React-Redux, you actually subscribe then to call backs on any of those changes so if something were to be bumped, then your component is given the opportunity to rerender during that call back. CHARLES: Now, in terms of Ember-Redux, that kind plumbing is hidden from you. You don't actually have to explicitly map that state. You can say, "I want to connect this component into the Redux store," and you're just off to the races. ROBERT: Is there a mapStateToProps or... I don't know what that would be called in Ember-land. TORAN: That brings about interesting point. I literally copied this API that you guys are probably looked at from the readme from this very popular project in React called React-Redux. The word that you're using, Charles is this word connect. Actually, I like that word because that's how I think about it. I want to connect the components to the single source of truth and then respond by rerendering when something changes. The API is actually very similar on what you said, Rob. In fact, the set of mapStateToProps is just map states to computed, which is very much the same idea so instead of really defining the component like you might normally, this is where it gets a little weird for your classic Ember developer, you actually just write two functions and really only one is require. The first one is what you're hinting at Charles, which is I want to pull from the state a set of properties and as you mentioned, the plumbing is sort of hidden, magically those are actually created as CPs or Computed Properties on your component so you can go to your HPS file, your handlebars template and say, "Oh, I took number from the global state and I'm just going to map it in this function and now I can go to my handlebars template and number," and there it is. Every time you bump number up or down, you'll get a rerun in your callback and the HPS will update. The other function, as sort of glossed over is really just for your closure actions. If you would like to ask the store to do something and saying, "I would actually like to increment the number," then you can fire an action and the second block just does also additional magic, which just maps a closure action by letting you get this dispatched keyword. Dispatch in a Redux context is just, "I'm going to send an action," and you can think of it almost in vanilla JavaScript terms as, "I have an event. Someone will handle this event and I'm just going to throw it up." ROBERT: It makes its way to reducer then from there, right? TORAN: Correct. We haven't talked too much about that process. The reducer really says, "I'm going to be given a state or the initial state, if you haven't done this yet," which would be maybe in the number scenario. I'm going to start with zero as a sensible default and then I'm going to have an action, whether that's add or subtract in this simple example and in add, I'm just going to take the state coming in, even if it starts out at zero and then do something, transform it to a new state. Actually the important word here is that -- I know you guys are big in the functional world, functional programming and that's the word actually got me interested and really excited about programming again as well, in the most perfect sense -- a pure function, which just means that there are no side effects. There's no mutation or changing of the state that comes in when you do it correctly. In this case, actually instead of mutating something I'm actually returning to number two or to number one and you're like, "Now, we have both zero and one in kind of a timeline." If you think about this almost as the realistic stories, we're just kind of kicking a pointer to a new block of state. Every single time you come to reducer, we still have the old state and we can still walk backwards, which is how the time travel debugging works as we just flip the pointer back in time. As you guys have talked about and I think, Charles you mentioned last year in EmberConf, the immutability story has of course a whole slew of great properties that come with it and those we haven't even obviously talked about. But hopefully I gave people a broad overview of what the reducer does. In its most simplest form, state comes and action returns a new state. ROBERT: Yeah, in Charles's talk and his research, I got to sit next to him and watched him do that actually kind of shaped a lot of my thinking and hunger, if we want to keep that going towards doing like something that's immutable and state management in Ember. I would like to thank you, Toran for building that add-on and spearheading Redux because Redux is pretty awesome for state management. CHARLES: By the way, you did in that call out the analogy for hunger. I really, really, really like that. It's an important tidbit not to miss is that when you are feeling those kind of doldrums of development. I know I was actually ironically feeling that about the same time in 2015, feeling of in a funk because I feel like there was a lot of stuff coming down the pipe like with 'data down, actions up' but no good examples of where we've actually seen this in practice. I think Redux is an actual implementation of 'data down, actions up' so I think it's fantastic that you were able to go and seek inspiration there like, "We've got this message of the way things that ought to be doing with the applications ought to be built." But we don't actually have any concrete examples that we can look to. I think the Redux actually is almost the most pure version of that 'data down, actions up'. I guess my next question is given that you've got this global store, you've got a way to connect components. I assume there are other ways to dispatch actions from within your Ember application like what are the patterns that you're seeing emerge around this? We've talked about how you would use them in components. Suppose my tree of components gets pretty complex, how do I manage that to kind of the passing of data down? Do parent components play any role in the data that their subcomponents see? Is each component connecting directly to the store? I'm just kind of curious where that balance lies and how things are kind of playing out? TORAN: There's really two points in your bigger question. One that I was going to try out of you but then you kept going. That was really around side effects. How do you actually dispatch or make changes, requests changes and see the flow and we could talk about that really starts out briefly with a Promise based approach. With Redux, most people don't know but it's basically like asynchronous flow. Dispatch would normally be like asynchronous action where you're sort of blocking and then doing, transform and getting it back. In the simplest ways, you see there is this tool or this add-on, Redux-thunk, which you can use Promises now and async will still work as if it were synchronous essentially by firing dispatch up and letting your reducer do the work. I think that is a great introductory because especially as Ember developers, we've got a lot of experience with Promises so this is just the same thing. In most of the demos I've done and if you check out the read me, there's like a full Yelp Clone example. It's using this approach because it's a little bit more familiar to most folks. CHARLES: Just to clarify what would happen there is you're essentially getting a new state transition when every Promise resolves or rejects. If it's rejects, that's a state transition. If it resolves, that's a state transition. The next Promise that resolves is another state transition. Is that fair to say? TORAN: Assuming you want to alter and use that top level state, of course you could reject or resolve and just not even bother with the top level store. We kind of skipped over some of the benefits and we could just roll back to that briefly. Why would you use top level stores at all? You mentioned earlier and it kind of seems counterintuitive. This is basic global variable. That's what we're talking about. In the Ember example, I think it's actually sort of not weird because if you guys, your Ember data in its earlier form or even today, it really very much is that. We have this one cache of objects related or otherwise and we pass those around. They are a global object or almost like a global variable. The downside of that in my experience has been that is truly mutable and actually everything is driven by mutating those and then having callbacks or denotify property change drive your template updates. That is not the process with Redux, of course. It feels more explicit, where I can actually go look up kind of a tree or look up table of actions and see exactly what's going to happen. Then also to your second half of the question, which is like how was the components wired up? How do they map? I actually uses an interesting pattern which isn't specific to Ember-Redux or Redux, which is to create a seam in my components now where I have truly HTML CSS components. Separating those from the components and know about the data and the closure action story. Forgetting Redux for a moment and all of this actually made my regular Ember much better because I started to produce this component that would connect to a Ember data store, provide closure actions to send up in the most pure 'data down, actions up' sense and then I would connect it using the yield block, which credits to you and other folks at EmberConf that you, Charles kind of talked me into this because I was a espousing this idea but I didn't really understand that I would actually nest within this parent, the HTML component that would just be handed the properties to render. When we do this, again it still is I think a better pattern even if you're not using Redux but when we did it and I when I started with Redux, the only thing that really gets me in hot water is when people see this and they're like, "Oh, so this is the first thing that comes down from the routed controllers template. Then there's always this brief moment of like, "I'm not sure what to say. I don't want to predict the future and I'm not trying to be Mr Routable Components here." But for me, most of my controller templates are just a landing page for the component tree to begin. Again, that's not me trying to hacking the route or anything to say, "I want to use this controller as a routed to component. I think eventually when that RFC lands, this will look different, anyway so I'm not trying to have people do things really outside of the Ember ecosystem or outside of the norm." But from there, I feel like still just landing into a component, allows you this composition which is supposed is the real value of the components structure. They are too primitive to build pages and then eventually full apps. ROBERT: So if we want to drop parallel, it's container versus presentation components, right? TORAN: Yes and that of course, again stolen from, not me probably stolen from someone else in the 70s. But you know, Dan Abramov is accredited to bringing that idea about in React. Actually I like the idea because let's pretend I had done this pattern in 2013. Now, it's using Ember data or simple store or Erik Bryn's Ember model, something like that. Then eventually, the community start shifting to something else. It could be MobX, it could be Redux and whatever the case, I could just very easily swap out those connected components that have no HTML CSS. The data source changes and all the presentation components do not know. They do not change. There is actually an iterable story to refactor through, an update like that normally is kind of a [inaudible]. If you have ever done PHP in the early days or at least my PHP experience in 1999 -- no offense to PHP today -- was that everything was so stuck together or so couple that I could never refactor anything out of it. Of course, you probably do this in a consulting space as I have, where he first thing on a messy project is actually making those scenes in the application anyway to allow you to upgrade incrementally. This process is just more of an upfront thought and I don't think it's really taken hold than it needs to in the Ember community. It's just something I was experimenting with and I'm finding a lot of value because I think the connection of the data source is a different activity than HTML. ROBERT: I think it also holds a lot of value. CHARLES: I think it holds a lot of value. I think there's a dawning awareness of this. In your comment, I actually thought of two blog posts for EmberMap, which I was just reading this morning. One was talking about kind of the safety of the herd and don't worry so much about controllers versus radical components like use your controllers, use your components. Don't worry about it too much. It'll get sorted out. I definitely agree with that. Although, you definitely want to experiment when you're experiencing particular pain around something. But then, the next thing which I think came out yesterday was talking about basically components for managing side effects, which I think is an unfortunate name because I think side effects is a tainted word. But basically, the idea is having presentation components and container components and the container components are responsible for managing the state. I think that idea is valuable in of itself and I hope that it takes root. I think that's something that you're doing, something that we're doing and as people kind of realize it, it does take root, just kind of by virtue of its own value. Let me summarize if I understand it correctly. As part of these job, you've got these container components and their job is, I like the term that you used, creating a seam. Their job in the Redux world is to take a slice of that global state. You have these components whose responsibility is taking a slice of that global state and presenting that global state to HTML CSS aka presentation components that lie underneath them. Is that a fair assessment? Then if that's so, I've got a second part to that. I just want to make sure I'm understanding it correctly. For components that are further downstream on that tree, do you ever switch back to data containers like you switch between data components and presentation components and then back to data components and then to presentation components and kind of back and forth and back and forth on down the tree? Or do you mostly see it as one-kind of container component on top and then presentation components all the way down? TORAN: It's a great question. I think that still needs a fair bit of experience in the Ember community because the patterns I pulled from the source code I read a lot is mostly from the React ecosystem. Because of that, there's a very split view or a different view in that community on routing. We may share some of those views in Ember but I think for the most part, we assume routing actually and that's one of the tricky part to answer your question. This is a broad statement so I'm likely wrong in every context but I don't love to be creating these data components that don't get routed to if I can help it. I'm sure there are situations that have been really complex, places where you just have to make, no route here because I don't want change the URL for instance and I'm just going to make this thing like a routed to component with no URL to get me here. But for the most part, I treat the entry point to this route and when I land on this route at this time, it's appropriate to ask for the data likely coming from the model hook in the route. In fact, all that's still the same. That's also where it's a little weird. If you've ever seen a full component tree in a React app, they may not have a router at all. In that situation I think, Redux was in particular even better because you don't have to pass from the top app component, the same props or the same data all the way down that tree. In fact, if you read documentation about why Redux in the React ecosystem they'll say, "It gives you this place where we can create a little shim and then ask for the data down here in the [inaudible] mode. You don't have to pass it from the app to that, to that." I see those benefits but in Ember we don't really get as much from that. In fact, they still tell people who challenged the global state idea that not everything maybe should be a global state but you give up some things by doing that. The first one I would say, which I think is the most valuable for anyone doing vanilla Ember with Ember data or someone experimenting with React or Redux. Or the case I'm most interested in, the audience I'm after which is Redux in Ember, which is do you actually need to have that state in one place. The prime example of this that is the greatest use case is master detail. What I mean by that is you have a list of things and when someone drills into one of those, you can also see that at the same time. There's really two choices you can make here. One is I'm going to have two separate data sources to feed two separate components so the list will go get its data and then the detail won't even use that data at all. Just go get its own data. In that case, you may up against a problem where you need to synchronize at some point and here's the tradeoff. Either synchronize the two separate states or you have a single source of truth. That's a real benefit I think of Redux for the most part. It's like the broad, "Do I want deterministic rendering?" We've all heard the joke about the Facebook nav bar that's like, "You have one message," and you're like, "No, I just answered it down here." Well, that's a different component so the joke is like, "Oh, Redux must be working. We have one up here but I've already read the message." You know? Someone obviously is in charge of synchronizing in those sort of examples. Maybe not just doing it well or they run up against an issue synchronizing that. My experience doing back end development, colors this for me. What I rather have three databases and they kind of synchronize the state across them or I rather have the one postgres or SQL server database that is the source of truth so that when I render something to a customer, I can guarantee that it's not in a transition to be synchronized. It is the source of truth. CHARLES: Right, I really like that and I think the point that I take from that is that, and again this speaks to people who might be internally reacting to this idea of a global state is that you actually do have a global state always in your UI, whether you acknowledge it or not. It's composed of all the other distributed states that are sprinkled around your application so if you take an approach like Redux, you're kind of acknowledging that upfront that at any given time, I do in fact have a global state. I might as well deal with that explicitly. That's kind of a key innovation. I also like what you said too about kind of treating the router in Ember really leaning on the router as a good way to partition your data or drill down into a sub-piece of that global state. Inside Ember-Redux, are there explicit hooks for dealing with the Redux store inside your routes? TORAN: Yeah, that's that one that gets me the most trouble. When I see a blog post and memes that are all about the herd lately, can't help but feel like they're pointed directly at me because of some of these new ideas. CHARLES: Toran, I'm just telling you. This is a safe space. We believe in innovation here. You're okay. TORAN: Yeah. CHARLES: Let me add-on that. I didn't mean that as a knock to you. I do think they call this out of the end of the blog post. I think acting in concert with the community for the most part, actually fosters innovations and an innovative journeys like the one on which you're currently embarked because you don't have to worry about CLI tools and you don't have to worry about this. You can focus on the problem of like how does an Ember application work with a global atom as its state. TORAN: That is the idea. I mean the route is interesting. I have a little helper to your point, Charles if you've seen some of the docs or any of the examples. There is a little helper for routes and all it really does is provide dispatch as an argument. For instance, a lot of times I just want a model to be a regular function and dispatch to be an argument so I can return a Promise or do some Generator stuff as a side effect. In that way, I sort of create a shorthand which is just really simple. It allows me to say [inaudible] model and then have dispatch as an argument and run my code then just providing that to this special little helper. It's a functional type helper called route and what it does behind the scenes is it injects the Redux service for me, which is again something you can do by hand. If you really just don't like that or you want to be more in the herd, you can just have a regular route, inject the service and then get dispatched from that service and use it. ROBERT: It looks like you just dropped the version 2.0, like three hours ago. I would like to ask, we heard about your journey like you were feeling like you weren't hungry for learning. I want to know more about where you actually sat down and wanted to write this add-on on and why you chose to clone the React-Redux API and what took you on that path? TORAN: Yeah, that's a good question. Back to benefits or the reasons I got excited about, of course I mentioned during the talk that Dan Abramov did. There was some interesting dev tools. First of which was this thing Time Travel Debugging which it allows you to sort of move backwards in time and pretend as if actions and mutations or what looked like mutations that never occurred. That was very interesting. I wasn't really sure of the value, especially at the time. I told you guys around 2015, I was consulting which lucky me, I was doing Greenfield. Thankfully, I was working with a really great team and some great people, built an amazing product. I don't really understand the pain of this. For the most part Ember-set was doing its job and I didn't really have a lot of interest in learning this. But as I got more into it, also started a full time job last year, I pretty much just fix bugs for a year. Anyone who's been on one side of the fence or the other knows that the bug fixing side will sort of expose, maybe the weaknesses of the application or patterns or choices made. For me, that was really mutation or shared mutable stake aka the root of all evil. If you've ever looked at your Elm ClojureScript, Elm next is the same vein where immutability is very much there. Charles, of course gave his talk on immutability and trying to get people interested in that or more interested in the Ember community. That was really all I wanted to do to your point, Rob was provide really an outlet for people to use this and I wanted to keep the messaging away from the things I didn't like, which I think was actually something I screwed up to be fair early on. I think I was very vocal in the microcosm that I would talk to people about like, "These are the things I don't like about Ember," or I would use the word 'Ember the good parts' plus 'Ember the bad parts' and I was told not to say that anymore on the Slack channel. Once I started getting too much needed feedback -- I don't want to be negative about it -- I changed my messaging and as part of that, you mentioned Rob I basically cargo-culted or copied this API from React-Redux called connect and excluding the brief route helper that I mentioned, Charles a minute ago, the real idea here is you just call disconnect function with two other functions: mapping state and closure actions. Everything else becomes then vanilla JavaScript in this reducer function we talked about briefly where I have state coming in and I need to transform it into a new state. One interesting benefit of that -- I wasn't overly critical about until I really saw the difference is that -- I'm no longer using the Ember object. I'm not doing Ember.get and set, which immediately start to open the door some time last year for TypeScripts interest. I'm actually not a super type friendly person. I sort of left Objective C and C# and Java in my background and have like this Vietnam experience when people ask me about types. But I do understand one very critical fact that I can't dispute about types is that there are more information for the next programmer than you have without them. Again, my experience this last 12 months has been, as a maintenance programmer, I need more information. Tests are great when they're there but they also don't provide the interface or all the information about those and certainly the compiler may help as well. I don't know yet. I'm not doing any TypeScript. What I started notice is also more functional programming and maybe just not in our core yet but also things I wanted to steal from other ecosystems because I also found is very interesting. I started to study functional programming. I know like nothing about it, of course. I don't think anyone does because I can't describe a monad without getting in trouble or being wrong. For me, the real value is the separation of the data structure and the function. I'm preaching to the choir here but that was so much like an interesting idea to me and actually spurred on some of the further patterns or adoption of those in my work in Ember-Redux because this presentation and container component idea was really that I was separating the data structure from the function of the view. I think you mentioned this in your talk at EmberConf where the actual HTMLbars template is really just a function that has data in, HTML out. I started to internalize that and think about that and what were the properties I got from that, as well as I enjoyed functional programming. Some other great benefits that we've already touched on briefly are just how much more of this I felt explicit, not that Ember-set is inherently implicit but when you do a Ember-set for mutation to chase down every single place in a complex system to determine why they something render this way? It does feel a little more implicit than something like React-Redux with this connect function where I was like, "Wow," when I was doing React. Especially, I was like, "I bet I could just put a breakpoint at every connection so when that callback happens, I can know exactly what action spurred on this new callback to rerender," and that was something that was very new and interesting. Then of course, falling out of all this was another hyped tooling thing that I thought was really cool, not explicit to Redux, again but it got me interested because that's hot reloading. All hot reloading of CSS and Ember CLI, which I've never done design work which I'm not good at. But I do write some CSS or hack-on it when friends show me what to write. Then writing HTML was a separate experience. Once you wrote the CSS, you would hot reload in that course, what do you do every time you change CSS, you also change HTML, which would incur a full-page reload with a live reload tool, if you're familiar with that in Ember CLI. This tooling allowed the Redux store itself because it's stored the state, allow me to really throw the component away in the page without refreshing it and then providing a new one and just go rerender because the state was instantly mapped in and then rerendered. I actually did a demo sometime last year and like, "I'm going to build a star rating component and here it is with live reload. Here it is with hot reload. I'm not going to make a decision about which one is better. You decide," and overwhelmingly people were like, "This is a much nicer feedback loop to make HTML and CSS changes in real time." ROBERT: Agreed. Let's pedal back the hot module reloading because that is pure awesomeness. But that has a little bit of setup they have to do and changing your application. I remember we were talking about this. When you did that demo, I remember this. But there's a little bit they have to do to make your components stateless. They have to come down from the Redux store. TORAN: Correct and this actually still applies if you are, I think using Ember data as well, as you just can't pull the state to reload it anything local, which may go against what you're trying to do with your component. ROBERT: Right. That's cool but I do want to highlight a little bit something that was cool about the Redux dev tools as with all the state that you have since it's in a centrally managed place, you can take your state and then play it back over the top of something like if it did live reload and it'll just pop you right back down to where you were when you were debugging. When that page refresh happens, if you're not doing hot module reloading, you still won't lose all your state which is really cool. You just play it right back down on top and you're exactly where you were before. It's almost like you would throw a specific test that puts you into that state that you're trying to debug. TORAN: Yes, it's like git rebase. It lets me pull off my state, replay the new component function and then drop my changes on top of it and see it all viewed together. ROBERT: Yeah, I think that's massively powerful. CHARLES: Yeah, it is fantastic and that's where you get into that power. I can get on my immutability soapbox. But it turns out that as programmers, we deal in information and not throwing information away, not just flushing it down the toilet is hugely powerful. I think the thing that's so fantastic is that Redux takes this concept and then all of the tools to leverage it are there for you. I think that it is something that is missing from the Ember development story and people don't realize that it's missing, that we have all these wonderful tools, we have this conventional way of building our applications, of deploying our applications, of rendering our applications, of marshalling the data in our applications in the form of routes. But what we're lacking is this unified atomically based state management solution. I think that, Toran it's been fantastic that you have pioneered this and trying to bring what I see as a glaring gap in the developer experience to the community. I'm curious then to ask you what do you see as the future. You know, 2.0 just dropped and there's this need. I feel very strongly that Ember 3.0, 4.0 or Ember 'dot future' at some point should have a unified state management solution. How do you see the road that you're on intersecting with that future if it does in fact exist? ROBERT: Also how can I help or how can we help? TORAN: Just real brief before I dive into some of those questions. I just want to mention that 2.0, as awesome as that sounds, of course I dropped that this morning just so we could say that on podcast, really. We've had a beta in the works for Ember. The only change really, if you're like, "I just got into an Ember-Redux last week. Is it all garbage?" No, this isn't Ryan Florence 2.0 -- it was a joke for any [inaudible] router folks in here. Actually, just us removing Browserify because if you are familiar with Browserify in the Ember ecosystem, talk to Robert Jackson or Stef Penner, folks familiar with that in Broccoli, they'll tell you that one of the harder things to optimize and although, it created a great entry point to how do I use Redux? Boom! Ember Browserify, install Redux, I'm done. If you've ever seen an [inaudible] in Ember that has 'npm:', you're using Ember Browserify to pull in, either a common JS module or some kind of node module and use that in the Ember ecosystem without an additional shim. Now, what we found or learned was that bigger teams that are using this, paid a little bit of a cost and not just cold rebuilds. I'm talking hot rebuilds because Browserify just isn't friendly to get those to be optimized, I guess is the word, so we removed it completely or just use some smaller simpler shims. You actually get the performance improvements hopefully -- ROBERT: That is awesome. TORAN: -- Which is big win. Back to your question, Charles. The audience that's intended, of course is a little different than most people like me to talk about. In fact, the API itself, I think was a bit rejected. You're sort of asking like, "What does this mean in the future?" I don't really feel that the traditional Ember audience has picked up around with it because of something that's missing. You said the 'C word' earlier so convention is certainly still missing from this and even in the React ecosystem, they're just barely thinking about, "Look at all this great stuff we can do with one-way data flow and immutability and functional programming," but guess what we're giving up. No one's really come around with this perfect pattern and conventionalized it as Ember did in its early days so there's a lot of churn, I wouldn't say overly so much that you're not going to getting work done but more than the average Ember developer is aware of. My audience is actually not the average Ember developer, which may be bad for what you're asking about, Charles. Instead, it's actually the person who maybe has done React and maybe Redux or Backbone in the last two years. They love some of those patterns. They're not in love with the Ember-object because of getting set. Maybe they love TypeScript and they say, "I want to use this in Ember." They joined a new company that's a little larger than the startup they'd been on the last two years and they are using Ember. They love a lot of Ember but they would also like to use some of the predictable state patterns that you get with Redux. As well as maybe the dev tooling, things like that so they have adopted this. I feel like that really is the new audience that I aim to please or I'm falling in line with, which is a little bit outside. I feel like there's room for some fragmentation and a good beat up on me for that because when the realities of this herd conversation that we're kind of talking around a little bit is that the herd is great until something innovative needs to happen. Innovation, obviously takes some risk and I feel like that's sort of what I did last year and said, "Here's some interesting ideas. I have not shipped Facebook with it yet so let's just check this out." Of course, Ember add-ons are a great way to enable someone to try a new idea. But I think most people got into it, saw this funky connect thing and they're like, "What the heck is this?" It's a function and returns a component. All right, that's not doing that so most people bailed out. But I do hope people still and I know great folks at LinkedIn, Chris [inaudible], of course. We chat occasionally. Mostly he just tells me what I'm doing wrong. Shout out for Chris. But he knows a lot more about some of the stuff than I do and I think he is fully aware of the values that are in Redux that are great and then working hard, of course during his full time gig to apply these to Ember data and hopefully these do make their way in naturally. I just wanted to be a bit more radical. I don't want to wait around and I wasn't really involved in the Ember data project. My own fault there but I think if nothing else, the ideas will come out of it because the developers want this. Whether you're the audience I'm talking about, which is a React developer from two years ago, you're in Ember, you're eventually going to really understand and want this and then those 'data down, action up' ideas that were pretty unclear to me in 2015, will be very clear. In fact, if anyone seen or heard of this Project MobX, which is like an alternative in a way, popularity-wise to React ecosystem. It kind of looks like Ember in a way where you get sort of some more magic and what I found quickly in playing around MobX is that you can very much fall into the shared mutable state problems. The interesting part about MobX is you can opt into a strict 'data down, actions up' approach. But if you don't have the Ember battle scars like we do, you're just going to come in and say, "What's less work?" Just like in Ember when I can do a set in the [inaudible] node, why would I do 'data down, actions up' and that's the transition I want to see folks make. Hopefully they learn something from that. CHARLES: Right, I agree with you. Although, I think the time has definitely come, I think the term 'herd-mentality' is an unfortunate one. I prefer to think of it as like a pack. If you travel as a pack, you can bring down moose that are bigger than you are individually. But every once in a while, like a gigantic moose with laser horns shows up and then what are you going to do? If you're hunting as a pack, you have to introduce new things because I like that analogy a little bit better than a herd because the job of the herd is just to not get eaten, where is the pack has this idea of these entities that have to stick together. They're hunting and they're tackling different problems as they come but sharing in the benefits. But I think that there has to be room for innovation inside that herd/pack-mentality, whatever you choose. I do think this idea needs to be introduced so what I would say is that if you're listening to this podcast, you should actually go and you should try and use Toran's add-on and you should try and build something with it so that if you have opinions about how it should fit into Ember, then we can hear them. It sounds like you're taking a minimalist approach, you're emulating patterns that are proven to work in the React community so kind of enabling that seed cross-pollination right there. I would say go build something with it, experience what it's like to have your state as a single atom, experience what it's like to have incredible development tools that come along with that. I think that if you're in the Ember community today, you need to go build something with React, you need to go build something with Redux and you actually have made it one step easier to do. You don't even have to leave Ember to do that. You can build something of node with production quality code using Redux and you can experience what it's like. That's my challenge, I think to the Ember community. Go try it, go experience it because you'll come back, I think like I did. You'll come back with superpowers just from having tried that. ROBERT: Managing state becomes so easy. TORAN: Yes. I want to jump in briefly and just cover one point that we haven't talked about that's very controversial so why not drop it at the end here. I think, Rob you might have asked about it earlier and I just didn't feel brave enough to talk about it at that time. But you guys keep going back to this idea and I have to talk about a little bit too. One of the motivations is I live in Iowa. I work in Texas. Thankfully, this great company, Q2 employs me and I don't know why I'm being paid. I'm lucky to be writing JavaScript for money, probably we all are. But in the Ember local community that I'm in, a very little folks writing Ember and that was even years ago. I was like the only voice in the middle of the Midwest screaming and then folks in Minnesota would tell me that wasn't true so I went up there and did a conference as well. But for the most part, I looked around the job market too and thought, "It be really great if I understand some of the more JavaScript-centric parts of building web apps today," and when I looked at Redux functional programming, the way the reducer worked and structured, the way to React-Redux project was structured and thought, "I bet I could emulate that an Ember," such that I could actually and I believe this is to be true, that if you were in a React-Redux project or even an Angular like ‘ngRedux', which is a very similar connect binding, you could copy a whole directory of your reducer code, which is all vanilla JavaScript. If you're doing generators, which we didn't talk about but if you're doing you know any additional side effects, you copy all that vanilla JavaScript, drop it into your Ember app and it all works because it doesn't matter if it's in React or Ember or even Angular, even View if View has some connect API like this. We all share this common API that is just give me the functions that enumerate over the data and return new states of the data and call back to rerender. There's something really powerful about that but the tradeoff being there are not a lot of strong conventions, Charles that I have adopted. That's kind of what I'm cautioning here a little bit is that I'm still also just watching the other communities to see what eventually turns out not. This is going to be am Ember add-on and I don't care what everyone else is doing. This is my vision because really my vision was to make a drop in for anyone already doing Redux on any platform. CHARLES: You know, to the point, there's a pack that extends beyond the Ember community and it sounds like you're also leveraging and being a part of that. TORAN: There's an interesting idea about the hunger thing, which just tied us in and there's where the fourth thing that a doctor will tell you to get your hunger back is go experience eating with other people. There's actually a statistic that when you sit down to eat with someone else or many people, you're likely going to eat 44% more food than you did on your own. That's just, I guess a statistic that's true. I just made it up for this podcast. No, I think it's true. If that is the case, then I think that very much translates to programming as well where when I'm developing code with other folks and I'm on like the React channel and we're just talking about vanilla JavaScript, it doesn't have to be me being an Ember developer anymore, which has been a large part of what's blocked me from being, I think an asset in my local community in the broader JavaScript community. At large is every time I get a conversation it's like, "I have to do it the Ember way," and that's changing actually. The Ember has credit a lot of deprecation if you guys have seen or follow the RCs and other just Ember upgrade deprecation. We're kind of getting away from being Ember and writing just more JavaScript and even maybe sometime this year beginning ES6 classes, instead of Ember object extend. I think Ember is heading in that direction. I just went there, rather rapidly because I also was again experiencing vanilla JavaScript with other communities, View and React. ROBERT: I think we're walking on this very similar path. I'm following your footsteps right now, it sounds like. TORAN: My last point which was that third bullet about building component trees, it didn't sound like either of you guys really contest that and I'm friends with, obviously Chris Freeman, formerly The Frontside and Chris tells me, "You're trying to build full component trees once you're injected at the route level and you're not doing like a ton of HTML in your controller HPS files." Is that true? CHARLES: We treat our controller basically as a component. Sometimes, we'll be like, "This is the controller and if we ever use it in more than one place, we'll take out its component." We're not super dogmatic but we definitely see the clear separation of the route is for maintaining the data and everything else is just one tree of components just below that. ROBERT: The more I think about it though, I'm so conflicted because I really like routes in Ember and they do a lot for you. I like having the data be maintained in one spot but I don't know a single store with Redux maintaining that and using like Redux-thunk or Redux-saga. I got some exploring to do. CHARLES: I don't think those are mutually exclusive propositions. That's what you were saying at the beginning, right Toran? You still do all of your data munching in the route. There's two kind of subjects that I wanted to broach briefly, although I don't think brief is possible with them is actions, like how we talked about data down, we talked about where you draw the seams in your application, where you're loading your data, where you're mapping it to your components and having that separation into your presentation components. We didn't get to talk about reducers so much and how you map. You touched on it like the mechanics but suppose I have a to-do list and I want to delete an item and I've got some button to delete an item, that's down my component tree. How do I map that action back up to the store? I don't know if we actually have time to cover that because it is meaty-meaty subject. ROBERT: Redux part two? TORAN: Yeah, we have to follow up because really that is a little bit more of an advanced segment not that folks shouldn't hear about it. But one thing that's a radical shift, Charles that we would have to go into and talk about, which is controversial as well as most folks want to operate in one structure, one dictionary not in the array. Then immediately, everything flips to being a Lodash operation. I didn't really use Lodash at all until I got into this. You guys probably actually are smart folks to do. But for me, this store is not in array now. When I'm doing array operations like remove or filter, I'm actually operating with Lodash on an object to produce those new states and most of it is just learning the Lodash operators because I didn't actually know them so the Yelp Clone that I have out there is a very simplistic look at using Lodash with Ember. But it accomplishes some of that. Then also, the secondary piece that would also consume a ton of time that we should go into but maybe not today is switching from Thunk to Generators with Saga and then maybe even observables with RxJS, which seems like possibly the future. Those all sounds cool but I think they're going to blow the heck out of scope on this thing. CHARLES: All right. Well, thank you so much for coming by Toran. As always, our conversations are too big to fit into a single podcast. I really want to have you on again. There are so many things that we haven't even touched on. We haven't touched on the subtleties of how action dispatching works. We haven't touched on using Ember-data -- I'm just [inaudible] out there and say it. With Redux, we haven't open that can of worms and who doesn't want to just sift through a can of worms on a podcast? We are going to have you on again. I am positive of that. ROBERT: We're going to paint that bike shed. CHARLES: Yeah, we're going to paint that bike shed. It's a bike shed that needs to be painted. It's something that the community, I think needs to face head on. Thank you so much for coming by and talking with us about Ember-Redux. Everybody, go and check it out. Toran, you've got some talks coming up, if you want to mention those real quick. TORAN: Yeah, I just wanted to plug. There's possibly going to be a talk, we're still lining up the official date with the Washington DC Ember Meetup sometime in April. I planning out to fly out there actually and give this talk on Ember-Redux. I want to thank just publicly the RSA team for kind of helping sponsor me to fly out and check it out. As well as give a more in-depth talk on Ember-Redux in the Meetup setting. CHARLES: Fantastic. If you're in the area, be sure to go check that out. If not, watch it on video and then unrelated Ember-Redux, if you haven't watched Toran's EmberConf talk on Outside-In development. TORAN: That's out actually global Ember Meetup, I think. CHARLES: Okay, that one. Actually, just go watch all Toran's talks. The thing that I didn't mention at the beginning of the podcast is that you do a lot of live coding, which is just makes my bowels freeze when I think about doing it. You just pull it off so effortlessly so it's definitely, definitely worth a watch. With that we, will take it out. We'll see you guys later. That's it from The Frontside. Remember to get in touch with us at Frontside.io. If you're interested in UI, that's engineered to make UX dreams come true.
Katie Gengler @katiegengler | GitHub | Code All Day Show Notes: 01:23 - Testing 06:20 - ember-try 14:11 - Add-ons; Ember Observer 17:43 - Scoring and Rating Add-ons 25:25 - Contribution and Funding 27:41 - Code Search 30:59 - Data Visualization 32:27 - Change in the Ember Ecosystem Since Last EmberConf? 34:35 - Code All Day 35:39 - What's Next? Resources: ember-qunit liquid-fire capybara Selenium appraisal emberCLI Bower Transcript: CHARLES: Hello everybody and welcome to The Frontside Podcast Episode 54. I am your host, Charles Lowell, with me is Alex Ford. Today, we're going to be interviewing Katie Gengler. I remember very distinctly the first time that I met Katie, it was actually at the same dinner, I think that I met Godfrey at EmberConf in 2014. That was just a fantastic conversation that was had around the table and I did not realize how important the people that I was meeting were going to be in my life over the next couple of years. But Katie has gone on to do things like identify a hole in Ember add-on ecosystem so she created Ember Observer. There's a huge piece missing from being able to test this framework that spans multiple years and multiple versions and being able to make sure that your tests, especially for add-on authors, run against multiple versions so she created and maintains Ember-try. She's a part of the EmberCLI core team. She's a principal at Code All Day, which is a software consultancy and just an all-around fantastic woman. Thank you, Katie for coming on to the show and talking with us. KATIE: Thanks for having me. CHARLES: One of the things I wanted to start out the conversation with is something that's always struck me about you is there's a lot of people when it comes to testing, they talk the talk but you have always struck me as someone who walks the walk. Not just in terms of you make sure that your apps have tests in them, where your add-ons have tests in them but talking to people about testing patterns, making sure that when there are huge pieces of the ecosystem missing like Ember-try. I remember this as something that I struggled with. I was running up against this problem and all of the sudden, here comes Ember-try and you've been such a huge part of that. I want to know more about kind of your walk with testing and how that permeates so much of what you do because I think it's very important for people to hear that. KATIE: I got really lucky right out of college. My first job was at a place that where people think of mythical themes, XP-focused developers so the first thing I was told is everything is test first, everything is test-driven. I was primarily doing Ruby in Rails at the time but also JavaScript. At the beginning, we didn't have a way to test JavaScripts and there was a lot of missteps in the way of testing JavaScript until we came right around to QUnit. I was QUnit long before Ember even came along. It's kind of bit ingrained in my whole career. Michelle as well. Michelle is my partner in Code All Day. We're both very test focused. I think that's what drew us to start a company together and working together. Every project we're on, we try to write encompassing tests: test drive everything, if we're on it, projects upgrade or any project to fix. We try to write tests as a framework for everything that we're doing so we know whether we're doing something right or not. When it comes to Ember-try, that wasn't entirely my own idea. That was something that Robert Jackson and Edward Faulkner were looking for something right. I remembered that appraisals gem from Ruby. I really enjoyed being [inaudible] gems that I had written Rails so I wanted it to exists for Ember so I just kind of took a promise of to do it. It was extracted from Liquid Fire. I had some scripts that would sort of test multiple versions but it was rough. It wasn't as easy as it is today. CHARLES: Yeah, it does speak to a certain philosophy because if you're coming to a problem and it's difficult to test, you often come to a crossroads where you say, "You know what? I have a choice to make here. I can either give up and not write a test or trying and test some subset of it," Or, "I can write the thing that will let me write the test." It seems like you fall more into that second category. What would you say to people who are either, new to this idea or new in their careers and they butt up against this problem of not knowing when to give up and when to write the thing to write the test. KATIE: I almost never don't write the test so if you're suspicions are true, I will write something to be able to write the test. But there are times that I'm [inaudible] and sometimes I'm just like, "This is not going to be tested. This is not going to happen." Finding that line is pretty hard but it should be extremely rare. It's not when people come to me, I work with a client and they're telling me, "No, it's too hard to write the tests." A lot of times, it's not only how you write the test, spreading the test and learning how to write a test. It's the code you're trying to test that could be a problem. If you have a very complicated code, very side-effect driven code, it's very hard to write the easier sell, which might Ember acceptance tests. What you're really kind of on a level of integration because you do have a little bit of knowledge of what's going on and you have to be within the framework of what Ember tests wanted you to do, which is async is all completed by the time you want to have this assertions and test. That means to look different tools like going back to something like Capybara or Selenium and have some sort of test around on what you're doing in order to replace the code that makes it hard to test it at a lower level to begin with. I think a lot of people are just missing the framework for knowing what to do when their code is intractable or not, necessarily that the testing and the guides that have you tested. I think most people could go through tutorial and do tests for a little to do MVC app perfectly fine. But that's easy when you [inaudible] size of the equation so if you're already struggling with code and you're not quite sure, either in Ember, it can seem very, very hard to write tests for that. I think that's true with Rails as well. I think people that begin in Rails don't understand what they're going to testing, especially if they have an existing app that trying to add test to but unfortunately, Rails not a long ago, kind of got into everybody's heads that your tests go with what you're doing. It's just ingrained part of the Rails community. Hopefully, that will become how it is with Ember. But a lot of people are kind of slowly bring their apps Ember so they really have a lot of JavaScript and they don't necessarily know what to do or they're write in JavaScript have always are written with jQuery and a little bit [inaudible]. They don't understand how to test that. ALEX: How does Ember-try help with that? Actually I want to roll back and talk about what is Ember-try and how does it fit into testing? You mentioned the appraisal gem which I'm not familiar with. I haven't done much Rails in my life or Ruby. But can we talk about what Ember-try is? KATIE: Sure. Ember-try, at the basis, let's you run different scenarios with your test. At some point, I would've said, let's run different scenarios of dependencies for your tests so primarily changing your Ember version and that's pretty much what add-ons do but a lot of people are using it for scenarios that are completely outside of dependencies so different environment variables, different browsers. They're just having one place to have all these scenarios, where if you just put it in travis.yml like your CI configuration, you want it as easily be able to run that locally. But with Ember-try, you can do that locally. I found that it's kind of beyond my intentions, expanded beyond dependencies. Primarily, it lets you run your test in your application with different configurations. I could see running it with different feature flags, it would be what something to be interesting to do, if that's something you use. Primarily, it just lets you try the conversions and appraisal gems let you run test with different gem sets so you have a different gem file for each scenario you possibly had. That was definitely dependency-focus. CHARLES: That sounds really cool. It's almost sounds like you could even get into some sort of generative testing, where you're kind of not specifying the scenarios upfront but having some sort of mechanism to generate those scenarios so you can try and surface bugs that would only occur outside of what you're explicitly testing for, which is kind of randomly choosing different versions of environment, variables, feature flags, dependencies and stuff like that. They didn't thought of that? KATIE: Randomization [inaudible] but Ember-try really does have a kind of general route way of working on and that's we're leading to that. If you wanted to, especially for add-ons, you can specify this version compatibility keyword and your packet at JSON and give Ember and give an Ember string a version and it will generate the scenarios for you and test all those versions. These Ember strings are pretty powerful so you can say specifically versions you want. You can do a range of versions and it will take the latest patch release and a reminder, at least you don't want to be too crazy and test each of those for that add-on. But I can definitely see something random, they're really cool. Some testing thing that's like just tries to do random input into all of your inputs on a page. I've really been meaning to try that out. Sounds like [inaudible]. CHARLES: Yeah, just like to try and break it. I remember a world before Ember-try and I can't speak highly enough about it and the fact that how many bugs it has caught in the add-ons that we maintain because you're always working on the latest, hottest, greatest version of Ember and you're not thinking what about two-point releases back. They're might be not a deal breaker but some subtle bug that surfaces and break your tests and the coverage has just gotten so much better. In fact, I think that they're as brilliant as it is bundled with EmberCLI when you are building an add-on. It's like you now you get it for free. It's one of those things where it's hard to imagine what it was like, even though we lived it. KATIE: And it was less than a year ago. [Laughter] KATIE: Ember-try existed for more than 15 bundle with EmberCLI so since last EmberConf or so. CHARLES: Yeah, but it's absolutely a critical piece of the infrastructure now. KATIE: I'm glad it caught bugs for you. I don't think I've actually caught a bug with it. CHARLES: Really? KATIE: Yeah, but I don't do a lot of Ember re-add-ons. I do a lot of EmberCLI-ish add-ons. It can't change versions of EmberCLI. Not yet, we're working on that. I get some weird npm errors when I tried it but I haven't dug into it much yet. CHARLES: I don't want to dig too much into the mechanics but even when I first heard about it, I was like, "How does that even work?" Just replacing all the dependencies and having a separate node modules directory and bower and I'm like, "Man, there's so many moving parts." It was one of those things where we're so ambitious. I didn't even think it was possible. Or I didn't even think about writing it myself or whatever. It's one of those like, "Wow, okay. It can be done." ALEX: This exists now. CHARLES: Yeah. ALEX: Add-on authors are accountable now for making their add-ons work with revisions or versions a few points back like you said but it makes it so easy. The accountability is hardly accountability, turning Ember-try. It's really amazing. KATIE: What I'm laughing about is that what it actually does is not very sophisticated or crazy at all. For instance, for bower, it moves your existing bower components structure. It's a placeholder. It changes the bower.json run install. Then after the scenario, it put's everything back. CHARLES: But I don't know, it sounds so hard. It's intimidating. You got all this state and you got to make sure you put it all back. What do you do with if something hit you and abort midway. I'm sure you had to think about and deal with all that stuff at some point. ALEX: I kill my tests all the time in Ember-try and I was like, "Oops." I forgot I shouldn't do that just like for this. KATIE: Yeah, it doesn't recover so well. It's pretty hard to do things on process exit in node correctly, at least and I don't think I gotten it quite right. But there is a clean up command. Unfortunately, with the way it interacts with EmberCLIs dependency tracker so when you run an Ember command, Ember checks them to make sure all your dependencies are installed. If you still have the different bower.json and install haven't run, you have to run install before you can run the cleanup command which is kind of a drag. CHARLES: I have one final question about Ember-try. Have you given any thought to how this might be extracted and more generally applicable to the greater JavaScript ecosystem because I see this is something that Ember certainly was a trailblazer in this area. Some of these ideas came from Rails and other places. This is going to be more generally applicable and had you given thought to extracting that? KATIE: Yeah, some of [inaudible] since we first did it because we realized very early on that it doesn't depend on EmberCLI. I didn't even using it as a command line arguments parser which doesn't seem too important. But there are some assumptions we get to make. For it being an Ember app, we know how EmberCLI was structured. Some of those assumptions, I wouldn't really know with the greater node community and I gotten those assumption might not be possible at all because they don't have the standards we have on EmberCLI. It generated EmberCLI. There's generally certain things that are in place in Ember [inaudible] works for [inaudible] so there's no part of it that could be extracted. But I worry about some assumptions about no modules always being in the directory that they are in because then can be link the node modules above it. In EmberCLI, it usually doesn't support that. But other places, obviously have to. I realized that it could definitely happen but I'm not so sure that I'd want to personally support that because it's a little bit time commitment. CHARLES: Right. Maybe if someone from the outside want to step in involuntarily, you might work with it but not to personally champion that cause. KATIE: Definitely. I think it would be really cool and I do think it will end up having its own [inaudible] parser eventually, just to be able to do things like different EmberCLI versions. As long as it's not part of EmberCLI, I think that would be less confusing, though. In theory, that can be done with an EmberCLI still but I'm not clear on that. I've had people talk to me about that and I haven't fully process it yet. CHARLES: Right. Alex you mentioned something earlier I had not thought about but that was the technologies like Ember-try keep the add-on community accountable and keep them healthy by making sure that add-ons are working across a multiplicity of Ember versions and working in conjunction with other add-ons that might have version ranges. Katie, you've been a critical part of that effort. But there's also something else that you've been critical part of that you built from the ground up and that is Ember Observer. That is a different way of keeping add-ons accountable. But I think perhaps, even in a more valuable way, more of a social engineering way and that's through the creation of Ember Observer. Maybe we can talk about Ember Observer a little bit. What it is and what gave you the insight that this is something that needs to be built so I'm going to step forward and I'm going to build it? KATIE: I'm definitely going to refer again back to the Rails community. I'm a big fan of Ruby Toolbox. Whenever I needed to jam, I would go there and try to see what was available in that category kind of way. There's variables that have on there. It will have something like the popularity in the number of GitHub stars and the last time it was updated. You can see a lot of inspiration for Ember Observer in there so maybe I should step back and explain the Ember Observer. Ember Observer is a listing of all of the add-ons for the Ember community. Anything that has the Ember add-on keyword will show up there. We pull it off from npm and it all show you all that kind of information: the last updated, the number of GitHub commits, the number of stars, the number of contributors and we put all of that information and a manual view together to put a score on each add-on. You can look at it and we categorized them as well. If you look at a category, say, you're looking at a category for doing models. You would see all of a different model add-ons and be able to look between them and compare them, decide which ones to use. Or if you're thinking of building something, you can go in there and be like, "This already exists. Maybe I should just contribute to an existing thing." What gave me the idea for is I was looking at Ember add-ons, which just shows you the most recently published add-ons for that Ember add-on keyword everyday and every time I was clicking on these add-ons I go, "They did the same thing," and it just seemed like such a waste in [inaudible]. People were creating the same things and then they started clicking into and I was like, "Why they bother clicking into this. It doesn't have anything. It's just an empty add-on." We're pushing add-ons just to try that out so I thought I'd be nice if something filtered that out and I happened to have some time so I got started and dragged my husband, Phil into it. He's also an Ember and Rails developers so that's pretty convenient and my friend, Lew. Now, Michelle works on it a little bit as well. That's what drove us to build it and it's been pretty cool. I like looking all the add-ons when they come up anyway. I feel like it's not any actual work for me. It's quicker than my email each day to look at the new add-ons. ALEX: How many new add-ons are published every day on average? KATIE: On average, it's probably four to six maybe but it varies widely. If you get a holiday, you'll get like 20 add-ons because people have time off. You know, if somebody just feeling the grind at two and you'll notice that the add-on struck commeasurably too. It would be else that come on the same kind of week. ALEX: You mentioned that an add-on gets a score. Can you explain that score and how you rate at add-ons? KATIE: Sure. The score is most driven by details about the add-ons. There's Ember factors that go into it and it's out of 10 points. Five of them are from purely mechanical things, whether or not there's been more than two Git commits in the last three months, whether or not there's been a release in the last three months, whether or not they're in the top 10% of add-ons, top 10% of npm downloads for add-ons, whether they're in the top 10% of GitHub stars for add-ons. ALEX: I know that I'm a very competitive person but it also applies to software. Not just on sports or other types of competition. But I remember a moment and I'm an add-on author and my add-on had a 9 out of 10. I was just about to push some code and just about to get a release. Even before that happened, it went to a ten. The amount of satisfaction I got is kind of ridiculous. But I like it. I like the scoring system, not just for myself but also for helping me discover add-ons and picking the ones that might be right for me. I'll check out any add-on basically that might fit the description. As long as there's a readme, I'll go check it out. But it still helps along with the categorization. CHARLES: Correct me if I'm wrong but I believe you can achieve an 8 out of 10 without it being a popularity contest. By saying there's a certain concrete steps that you can take to make sure that you have test and you have a readme, that's a thing of substance. I don't remember what all the criteria are but you can get a high score without getting into the how many stars or if you're in the top 10%. I think that's awesome. But it does mean that if I see an add-on with a five or something like that, it means that they're not taking my concrete steps or it might not be as well-maintained. You know, that's definitely something to take into account. I'm curious if there are any different parameters you've thought, tweaks you thought of making to the system. Because this gets to second part of that, what things had you considered just throughout out of hand, as maybe not good ways to rate add-ons. KATIE: We haven't thought about everything. I don't particularly like the popularity aspect of it. It did feel necessary to include it in some way. The stars and theory are representative of interest, not as much as popularity but it probably gets into popularity as well then downloads are inferior for popularity. But the problem downloads and I found this happening more and more frequently is that if large companies start publishing their own add-ons, then they have a lot of developers, they are going through the roof on those downloads so they're getting that to a point that just from their own developers and I have no way of knowing if anybody else is using this. CHARLES: Probably their continuous integration with containers, right? Like if it's running on Travis or Circle, it's just sitting there spinning like pumping the download numbers. KATIE: Yeah and that frustrates me quite a bit. But I haven't found another thing that really representative popularity. Unfortunately, with npm you can get the download counts but you can't tell where they came from. There's no way to do that. I simply would like to see the things that are popular, they rate higher than the they currently do, like you said either, it's 10 points go without the popularity coming to affect it. But you do need a collaboration with at least one of the person to get eight points. If you give seven by yourself, you need to have another contributor. If you only have one contributor, you don't get that point because that's trying to be representative of sort of a bust factor but it's not truly there. You can just have one commit from somebody else to get that. CHARLES: Of all the pieces, I think that's totally fair. KATIE: Yeah, there's definitely a few other things I have in mind to bring in to the metrics but we're not quite there yet. I need to entirely refactor how the score is given so it's not exactly out of 10. The idea is to have some questions and some points that are relevant only to certain categories about us. Whether or not in add-ons testing its different versions of Ember, it might have matters for add-on but it's only adding 10 for CLI or whether or not they have a recent release. Might not matter if it's kind of a one-off with the sass plugin or something more of the build tool that doesn't change for everyone. CHARLES: Yeah, I've noticed we have that happened a couple times where we've got a component that just wraps a type of input. Until the HTML is back changes or a major API changes happens in Ember, there's no need to change it. I can definitely see that. How do you market it is like something that changes infrequently. Is it just that add-on author says it's done? You give them a bigger window or something like that? KATIE: There are probably some sort of categories that fall under that. For the input, I think if it's doing something that Ember producing components, it probably want to be upgrading every CLI, at least every three months. I think in that case, it's probably fair to require an update within that period of time. But some of the things that are more close to Broccoli like as they are in Ember add-ons, that make sense to not have that requirement. Maybe not that's the [inaudible] exact example of the kind of questions that [inaudible]. ALEX: In Ember add-on was the first time that I gave back to the open source community. It was my first open source project and Ember Observer really helped me along the way to say what is an open source best practice and I thought that was really cool. Now, it sounds like with some of the point totals, you're leaning towards Ember best practices to help Ember add-on authors along that way. I think that's really awesome and very, very useful. I would not like to see what the Ember add-on ecosystem would look like without Katie. It would be a very different place. KATIE: Thanks. I'm glad it had some help on that and I'm affecting add-on authors. I actually didn't originally think about it when I was first building it and I was really hoping to help consuming of add-ons but it really has kind of driven out people finding add-ons to not build because they contribute to existing ones. Also, driving them for the score because as you said, people get very competitive. I really didn't realize what kind of drive the score to be because to me I'm like, "Somebody else's score me. How dare you?" [Laughter] KATIE: I have had people say that to me, "How dare you score me? How dare you score my add-ons?" Well, it's mostly computerized. Even the review was manual but only thing about it has any sort of leeway is are there meaningful tests. That's really the only thing when I go through an add-on is whether or not that has any sort of leeway for the judgment of the person that's doing the reading. If there's a readme and we're kind of a rubric so that goes if you have anything in there that's other than the default Ember [inaudible] readme. Whether or not there's a build that is based entirely whether or not there's a CI tag in readme, these are for the owner to go look for them [inaudible]. We hope to automate that so I don't have to keep looking for those. A lot of add-ons turned out have to have builds when they didn't have any meaningful tests. They just had tests so that's kind of confusing. CHARLES: What do you do in that situation? You actually manually review it so that add-on would not get the point for tests. KATIE: No, they don't get the point for test and if they don't get the point for test, I put 'N/A' for whether or not, they have built so it doesn't apply. It doesn't mean anything to me if they haven't build their own test. CHARLES: Right, that makes sense. A lot of it is automated but it still sounds like consume some of your time, some of Phil's time, some of Michelle's time. I guess, my question is do you accept donations or a way that people can contribute because I see this as kind of part of the critical infrastructure of the community at this point. There might be some people out there who think, "Maybe, I could help in some way." Is there a way that people can help? If so, I'd love to hear about it. KATIE: We don't have any sort of donation or anything like that. I mean, we should. We consider it primarily just part of our open source works, part of our contributions to the community because we also make a great deal of use out of the community. Fortunately, it's not very expensive to run. It's only $20 a month VPS. Other than time, it's not really consuming very many resources. That may change over time. The number of hits is increasing and we're doing some more resource-intensive things like Code Search and we're running Ember-try scenarios from the top 100 add-ons to generate compatibility tables. It hasn't been the most reliable. Think about if you're trying to do nvm-installed times 100 add-ons, times every day, times the different Ember dependency settings so it's been very much like a game of whack-a-mole but for now, it's not bad. But we probably should think about some sort of donation by then. Maybe something that writes out the exact numerical cost of something like Ember Observer. The API is getting about 130,000 hits a month but that's the API so that's some number of quests per person. [inaudible] tells me something about 12,000 visitors each month. CHARLES: Does Ember Observer has an API? Are there any the third-party apps that you know about, that people built on top of the Ember Observer? KATIE: None that have been kind of public. I know a couple of private companies seem to be hitting the API but it's not a public API. It's really not public yet. I'm literally process of switching over to JSON API and at some point, I'll make some portion of that -- a public API -- but it's pretty hard to support that at the same time. It change Ember server pretty frequently and do any kind of migrations we need to do. Ember add-ons does all the scores from us from API end point. CHARLES: I actually wasn't aware. I remember the announcement of Code Search but how do you kind of see the usage of that? What's the primary use case when you would use Code Search on Ember add-on or Ember Observers? KATIE: I think the primary use case is if you're looking for how to use a feature. If you're creating an add-on and you want to know how to use certain hooks like [inaudible] or something like that. You can do the Code Search for that and see what other add-ons are doing. It's only searching Ember add-ons that have the repository are all set so you'll only find Ember results. That will be nicer compared to searching GitHub. Then I find another use case is more by the core team to see who is using what APIs and whether or not they can deprecate something or change something or something has become widely used since we're pretty excited about that possibility, we've never ever been searching. ALEX: That is brilliant. CHARLES: Yeah, that's fantastic. The other question that I had was this running Ember-try scenarios on the top 100 add-ons and that's something that you're doing now. Are you actually reflecting that in the Ember Observer interface? Is that an information or is that an experimental feature? Or is that reflected all the way through so if I go to Ember Observer today, I'll see that information based on those computations? KATIE: I start playing in the Ember Observer interface. It's only for the top 100 add-ons currently but hopefully expanding that to all add-ons. Especially, for few months but maybe it's not easy to notice. The only on top 100 add-ons would be on the right side bar and there will be a list of the scenarios we ran it with and whether or not it pass or not. There's add-on information there. The top 100, I'll link to right on the main page of Ember Observer so you can see in the front. CHARLES: How do you get that information back to the author of that top add-on? KATIE: We haven't actually done that. It's just on Ember Observer. It's more meant for consumers to be able to see that this add-on is compatible with all these version. We're not using their scenarios. We're using our own scenarios saying Ember from this version to this version, unless they have specified that version compatibility thing and then we'll use those auto-generated scenarios. This might get harder for add-ons that have complex scenarios so it need something else to vary along with the versions like Ember Data or maybe they're using Liquid Fire and Liquid Fire have these three different version and for each versions, it's being used. For those, we'll just have things which are unable to test this. But hopefully, this is still providing some useful information for some add-ons. A lot of add-ons, their build won't run unless they commit. In this case, this is running every night so new Ember versions released will see if that fails. On other side of it, we have a dashboard where we can see which add-ons failed and maybe see if a new commit to something broke a bunch of add-ons. It commits to something like Ember and for CLI Ember-Gate, one of the main things. CHARLES: I know that certainly that right after we get over this podcast, I'm going and running or checking up all add-ons that we maintain and making sure everything is copacetic. If you guys see me take off my headphones and dash out the door, you know where I'm going. KATIE: Got you. ALEX: I just have a further comment that I'm excited for the public API of Ember Observer just because I've been thinking a lot about data visualization lately. I think it would be really cool tool to do a deprecated API, like one of those bubble charts where like the area that's covered by this deprecated API -- I'm doing a bad job of explaining this -- just like the most use deprecated API methods and visualizing that, I think they'll be really interesting to see it. CHARLES: Right, seeing how they spread across the add-on. ALEX: Yeah, or just all add-ons in general. KATIE: I am most nervous about a public API for Code Search, though because it's a little bit resource-intensive so just freaking out a little bit about the potential of a public API for it. But an Ember Observer client is open source. If you want to add anything to the app, that I consider as public think it is. Adding to that, I really do want to figure out some way to have like a performance budget for when people add to the client because sometimes I'll get people who want to add features and I'm like, "That's just going to screw all of it. It's going to be a problem for all Ember Observer and it's going to make everything slower and it's really little slow. But JSON API fortunately, I have kind of a beta version that running and it's going to be much faster, thank God. I probably shouldn't said that either. CHARLES: Definitely we want to get that donation bin set up before the API goes public. Okay, let's turn to the internet now and we'll answer some of the questions that got twitted in. we've got a question from Jonathan Jackson and he wanted to ask you, "Where have you seen the most change in the Ember ecosystem since last EmberConf?" which was March of 2016. KATIE: There was definitely fewer add-ons being published but the add-ons that are being published are kind of, say more grown up things. We've got... I don't know if engines was before or after March. I have no idea. Time has one of those things that engines and then people doing things related to Fastfood so things are coming from more collaborative efforts, I think. This is just my gut-feeling. I have no data on this. Isn't a gut-feeling from looking at add-ons and then there's a lot of add-ons that are coming out that are specific to a particular company. I think that maybe, I hope representative of more companies getting it to Ember but hopefully, they'll make things more generic and share them back. The other problem with the popularity is like about before, where big company is getting itself into the top 100 list, probably with just its own employees only appear over the summer. I tried a few different ways to mutate the algorithm to try to get them out of there but there was no solution there. It's much fewer, novel things. Very rarely do I look at Ember add-ons and I'd be like, "Oh, that's great," but when I do, it's something very exciting. CHARLES: Right so there's a level of maturity that we're starting to see. Then I actually think that there is something in the story too, of there are now larger companies with big, big code bases that have lots of fan out on their dependency tree that just weren't there before. KATIE: Definitely. I don't think some of the large companies were there before but I think some of the largest companies are probably keeping most of their add-ons private so there's kind of mid-range of company that's big enough to donate things or willing to put things open source. A few of these companies that can have a lot of add-ons now and a lot of them are very similar to things that have already existed so you're going to be like, "I don't know why I use this," but they obviously make changes for some reason. CHARLES: The other thing that I want to talk to you about, before we wrap up, is you actually are in partnership in Code All Day. What kind of business is that? What is it you guys do? What's it like running your company, while on the same time, you're kind of managing these large pieces of the Ember ecosystem? KATIE: Code All Day is very small. It's just me and Michelle. It's a consulting company, we kind of partnered together after we left to startup and decided to do consulting together. We primarily do Ember projects, also some Rails and we try to work together and we love test-driven things. It's pretty kind of loose end. We ended up running it since it's just a partnership. We don't have any employees. But Ember Observer will take up a lot of our time and we really had an idea that it might help us get clients that way so I suppose it kind of helps our credibility but it hasn't really been great for leads so much. But fortunately, there hasn't been a big problem for us. We really enjoys spending our time. We enjoy the flexibility that consulting gives us and while that flexibility is what's going to making these things keep running. CHARLES: All right-y. Well, are there any kind of skunkworks, stealth, secret things you've got brewing in the lab, crazy ideas that you might be ready to give us a sneak preview about for inquiring minds that may want to know? KATIE: Some of them are really [inaudible] which is redoing Ember Observer with JSON API instead of currently, it's using ActiveModel serializers, which is a kind of custom API to Rails and [inaudible] fortunately, it's an API now. They're removing something called JSON API Resources so that will get the performance of Ember Observer much better and that's pretty much my primary focus at the moment. I don't really have any big skunkworks, exciting projects. I have far off ideas that hopefully will materialize into some sort of skunkworks projects. CHARLES: All right. Well, fantastic. I want to say thank you, Katie for coming on the show. I know that you are kind of a hero of mine. I think a lot of people come to our community and they see like, "Where's the value in being a member of this community, in terms of the things that I can take out of it? What does it provide for me?" And you demonstrate on a day-to-day basis, asking what you can do for your community, rather than what your community can do for you, to paraphrase JFK. I think you live that every day so I look up to you very much in that. Thank you for being such a [inaudible] of the community which I'm a part of and thank you for coming on the show. KATIE: I'm very happy that I've been here and thank you. I use a lot of your guys add-ons and it's really the community has given so much to me, which is why I ever want to participate in it. It's really great group of people. CHARLES: Yep, all right-y. Well, bye everybody. ALEX: Bye.
Godfrey Chan @chancancode | GitHub | Tilde Inc. Show Notes: 02:27 - What is Glimmer 2? 11:24 - Key Changes for Glimmer 2 12:54 - How do these libraries (i.e. handlebars.js; htmlbars) work together? 18:02 - Maintaining Compatibility 24:38 - Components 27:55 - Looking Forward to Non-Performance-Related Features 34:43 - Animations and Visualizations 39:09 - Glimmer 2 For an End User 41:33 - Stand-alone Glimmer? 46:12 - What are the performance gains on mobile? How does it better position Ember for mobile devs? 49:23 - Bubble Tea 50:37 - Contributing to Glimmer 2 Resources: Godfrey Chan: Hijacking Hacker News with Ember.js @ EmberConf 2015 Announcing The Glimmer 2 Alpha Isemberfastyet The Quest Issue (#13127) D3.js EmberConf Yehuda Katz & Tom Dale: Opening Keynote @ EmberCamp London 2016 TypeScript Ember Community Slack Transcript: CHARLES: Hello, everybody and welcome to The Frontside Podcast Episode 53, brought to you by The Frontside where we engineer user experience that is just so. If that's something that you're interested in, please feel free to reach out to us on either Twitter or at contact at the Frontside.io. Today we have a really fun episode. Again, we're second week in a row, we've got a nice fat panel. Jeffrey Cherewaty and Chris Freeman, who are developers here at The Frontside and we're also here with Godfrey Chan. Just a little bit of background on Godfrey, from my perspective, I remember very distinctly back in EmberConf 2014, I went out to dinner and I sat across from this guy who was the organizer of the Vancouver Ember Meetup. Was it Vancouver? GODFREY: Yeah, that is correct, Vancouver, BC. CHARLES: Yeah, Vancouver, BC. You know, I was struck at the time and I was like, "Wow, this guy is really smart and insightful and actually making me laugh a lot." GODFREY: You're very kind. CHARLES: I don't know if you remember that but that was borne out at the next EmberConf in 2015 where he gave this fantastic talk on the power of Ember Data's adapter and serializer layer, where he repeated the same trick except at scale in front of the audience. I think we were all rolling in our chairs with laughter but also learning a lot about this really, really powerful pattern and you had written serializer and adapter layer to basically build without a back end at all, a completely new UI for Hacker News. It was really a fantastic talk. Since then, you've just been going on to do a bunch of other great things: you joined the Rails core team, the Ember core team, and most recently, it sounds like the major thrust of what the last year or so has been giving birth to Glimmer 2, which is the next generation of the rendering engine in the Ember.js framework. It's a really fascinating topic. Thanks, Godfrey for coming on and talking with us about this. GODFREY: Thank you for having me. CHARLES: Yeah, it's a huge deep topic so we're just going to scratch the surface. Obviously, can't cover a year of life in just under an hour but we're going to do our best. Why don't we talk just a little bit about what Glimmer 2 is? For our audience members who are deeply involved with Ember community, it probably is not going to come as a surprise but we actually do have other listeners. What is it and why is it important? GODFREY: Like all good software, Glimmer 2 was basically born out of an accident. Glimmer 2 on a very high level is the new rendering engine for Ember. That's pretty vague but I guess, we'll go back a little bit in terms of the timeline and maybe that would become more clear. The time frame was pretty much when I first joined Tilde, we shipped 1.14 for a while and we just about to ship 2.0. That's when the original Glimmer planned it. That year at EmberConf, I believe it summer of 2015, like Tom and Yehuda talk about this new Glimmer thing on stage that has promised to basically renew the Ember programming model to better match the data down, actions up paradigm as opposed to very reliant on to a bindings and stuff like that. On one hand, it gives you better programming model and on the other hand it's promised to be much faster at rerendering. It's more or less inspired by React so you can just treat your component as if it's refreshing a page on a server-rendered HTML or something like that. You can just update your data and then rerender a component and that's going to be efficient enough that you can just basically rely on that as the main fully-rendered model. That ship in 1.14, for most part it was great so we were planning to start working on the next thing and at that time, the plan was to work on rehydration. If you're not very familiar with it, it's basically the next iteration of FastBoot where today when you have a FastBoot render page, when it goes [inaudible] has to then download JavaScript the data and rerender the page basically for the DOM then re-insert the newly rendered content into the page. There are several problems with that. First of all, it's a lot of wasted work because you already rendered all the HTML on the server side and now you're re-doing the work and you're framing them away. Also your users will probably see a brief flash because you're deleting the old DOM and you're replacing with a new DOM. You probably lose important things like [inaudible] position and probably not the most performant way to do that also. That's what we're going to work on next. Basically, allow the rendering engine to instead of rendering a new DOM, just rehydrate the existing markup that was sent by the server and just wire up the thing so it can be updated further on the client side. CHARLES: What I'm hearing is that the original Glimmer that was introduced in 2015, it had to always assume starting from a zero state. It couldn't take an existing DOM and kind of converge. GODFREY: Right. That's still true today. I wouldn't say that the rendering engine is not capable. It's just that the feature was not written yet, at the time we were about to start writing that feature. It took us maybe a week or two spiking on it. We got something working like as we go for that exercise, I was basically new to the code base at the time so Yehuda was explaining a lot of things to me. We were pairing basically full time at that time. If you know Yehuda, he also travels a lot. He has a lot of other responsibility like [inaudible]. We basically paired for a few days and then he might go on a short trip or I might go on a short trip for a conference or whatever. Then we'll come back and then it was like, "Wait a minute." I basically forgotten most of the things so we have to go through the concepts again. That was a little bit painful. On the other hand, the code was not really that well-rationalized or well-structured. It's a relatively old code base or at least in terms of JavaScript age, the original Glimmer 1 was basically bolted on top of what we were using at the time, which is HTMLbars engine where we can perhaps go into a little bit more details on that later. But basically, the engine was not really designed for a lot of those so it was getting a little bit difficult. Separately on another fret, a lot of things is going on at the same time, we're getting more reports on performance regression on Glimmer 1, which is probably a little bit surprising because the whole point of Glimmer 1 was introduce a new algorithm to make things faster. That's the big promise of the original Glimmer but it turns out that, indeed we rerender performance a lot faster. However, because it was so slow before, basically a no one used that feature ever so the existing apps are not getting any of the benefits because you would have to do a lot of refactor to take advantage of new programming model. However, you have existing code that you're using in production. Those code did not used new programming model, did not get any of the benefit. On top of that, it turns out that even though we have this superior algorithm in Glimmer 1, we inadvertently regressed it the initial render performance for components. That's not a tradeoff that we explicitly made. It's just that we wrote a lot of new code and we were mostly focusing on making the rerender pass as fast as possible. By the time were done, everything seems fine, we shipped but in the wild, people reported, "It turns out the thing I care about just got slower," and because it's not like a design decision that trade off that would made, we don't actually know what's going on like we have a lot of new codes somehow, that made thing slower when you do investigate. Basically, at that time, we had to polish our work on rehydration and focus more on performance. As we dug deeper into this rabbit hole, it turns out one of the main thing that happened was how we handle blocks. In the handlebars template, you have a pound or a hash, like let's say, '#if' and then if something and there's a block in there then you do slash if, that's blocked in handlebars. It turns out we made some significant changes in how that works and blocks got significantly slower for some reason and you can see that by comparing the performance between the block form of the if-helper, like #if, blah-blah-blah, versus the equivalent of the inline form just the curly-curly, if something then show render a string, otherwise render some under string so if you compared to those two versions, they really should be the same thing. They are not functionally any different but if you compare the render and performance between the two versions, it turns out the block version is like in order of magnitude slower, for some reason. That's bad because it turns out we also made some changes to how components work and each component has at least two hidden blocks that you can't see. It were like basically, how the tech name and stuff were rendered so these components, some blocks and blocks got a lot slower so the end result is component initial rendering got slower. That's unfortunate because that's probably one of the most useful feature of Ember or any view [inaudible]. Like on a client side, the way I like to think about it is like if you're writing code and if you've a really long function you probably want to break it down to smaller function for your own sanity. I think components serve a similar role in your templates, like when your template are really big, you probably want to split them into some more modular or hopefully reusable components. If nothing else, just break it down to smaller chunks so you can reason about it. Components are really important and the community is really starting to pick up the idea of components around that time. Unfortunately, we made a change that made components slower so we have to do something about it. That's more or less why Glimmer 2 happened like you're starting out as an investigation into why components got slower, what can we do to make it faster and deeper? We take down on that rabbit hole. We found more things about the HTMLbars engine that is not very aligned with the way we want things to work, which makes it more inefficient than we will like. Basically, it turns out as an effort to realign how the engine actually works with who we actually do with the engine. It start up very incremental and at some point, several things happen that basically cost it to become a complete rewrite. That's basically the backstory of Glimmer 2. CHARLES: Now, here we are, there are these fundamental problems with Glimmer 1 that you can't get to where it is that you want to go, which sounds like these set of optimizations so a rewrite is underway. What were the key things that needed to change in order to make this happen? GODFREY: The overarching theme is basically the original rendering engine. There's not much of a rendering engine to speak off. I think at the time, we don't really fully understand what our requirements are. We don't really know what our needs are so we built something very, very flexible. That's basically HTMLbars and it's kind of self-evident at this because we could take HTMLbars and retrofit the Glimmer 1 [inaudible] from on top. HTMLbars is literally just handlebars plus HTML. It's capable of rendering static HTML and every time it sees a double curly or a mustache, as we would call in handlebars, like every time you see open double curly braces, it provides a set of hooks for you to hook into that process. Every time you see curly-curly, what happens? It says, "This is a block or this is an inline helper," and it just delegate to Ember to, "Please tell me what to do next." That's basically handlebars. CHARLES: If I can kind of interject a question because I think this is kind of a source of confusion, certainly for me. What is exactly the relationship between handlebars.js, like if you go to handlebars.js, the GitHub organization, it is a separate code base, is that just a parser and a syntax? What exactly do the individual libraries contribute? Because we have handlebars.js, HTMLbars, Glimmer 1, Glimmer 2. I think it's a source of confusion that's how are these composed to work in tandem or in tridem when I actually use Ember. Because I know there's people who use handlebars.js that have nothing to do with the Ember community so what's the relationship there? GODFREY: Right. There's handlebars, the language, so to speak and there's handlebars.js, the library. Handlebars is basically just a string templating language. The word 'templating' is probably more confusing than it helps in this context but it's a fancy string interpolation. In JavaScript now, I guess in ES6 you can do it or in Ruby, you have special notations and string to interpolate things. Handlebars is a platform independent language for writing interpolated strings. It has some fancy features like helpers and stuff. But at the very core, it's a way to write really long interpolated strings. Handlebars.js is the JavaScript bindings for that language. As I said, handlebars itself is platform independent but if you have a helper and handlebars like you need to be able to write code for that helper somehow and handlebars.js is the binding that let you write those helper functions in JavaScript. Handlebars.js indeed has a parser in there so you can give it a handlebars template and it would parse into NAST for you. It also has a small runtime library that allow you to register helpers and stuff like that. That's handlebars.js. CHARLES: And HTMLbars is using handlebars.js? GODFREY: In some sense, yes. The original Ember up to 1.10 or something like that, actually uses handlebars.js. It used to be that. We actually do everything as string templates. We just interpolate the string and more or less, just set 'element.' in HTML equals '.string' and that's how Ember used to render things on a screen. Now, HTMLbars does use a part of that pipeline, specifically uses the handlebars parser. How it actually works is there are two possible orders and maybe in the middle of this, I realized I was wrong and it's actually the other order. But I believe how it works, let's say you have an a HTMLbars template or just .hps file in your Ember app, you basically run that through the handlebars parser so you get this some string and then there's some curly mustache here and maybe this is a helper, this is a block, this is whatever. Then I believe we then take all the text notes in the handlebars-jst and then we parse that as HTML tokens. Basically, if you have user.firstname, let's say, and close curly-curly, closed diff, that will basically end up being parsed into a combine jst of this open element of diff and then there's a mustache of user.firstname and then there is a close element of diff. That's the extent that HTMLbars uses handlebars so basically, it uses the handlebars parser to help with some of the work. Now, the part I said I always get wrong is either, you parse it through your handlebars first and then you parse the HTML inside the handlebar-jst or you parse the HTML first and then you use handlebars to parse the curlies inside the HTML-jst. I'm pretty sure we do the handlebars thing first but I'm still not 100% sure. One way or the other, if it turns let's say it parses handlebars first, if it turns out that I'm wrong, I'll probably sent a tweet or something after the show. Does that answer your question? Does that make it more clear? CHARLES: It does because I was always kind of wondering, does Glimmer and Glimmer 2 include its own completely separate implementation of handlebars or not and I think it answer the question of where that boundary lies. GODFREY: Right. Actually, there's a minor detail. I think we're actually on the older version of handlebars. I think there are some new handlebars feature that we need to reconcile. But for the most part, yes, we use the handlebars parser and that's basically the part of the handlebars.js we actually use. JEFFREY: That leads to talking about we used the handlebars parser at the bottom layer. How do you maintain that compatibility? Do you want to have a really great upgrade path from using HTMLbars as the renderer to using Glimmer 1 or 2 as the renderer? Would you talk a little bit about how you maintain that [inaudible] and compatibility? GODFREY: Actually, the handlebars parser part is probably the least interesting part in terms of compatibility. When we did Glimmer 1, I'm kind of speaking as outsider person here because I was not super involved at that time. But from what I hear, after EmberConf 2015, there was a website called IsEmberFastYet.com. It basically count down the number of failing test. Glimmer 1 was kind of a similar situation in that. It was still using the same HTMLbars library and it was part of 1.14 so it still maintained support for a lot of the legacy features like Ember.View and things like that. It's 'easy' in a sense that most of the test are still applicable so more or less, you just rewrite the code and you keep running to test and see what passes or what fails. Then when everything is green, you ship. That's the Glimmer 1 story. However, the devil is in the details. The tricky thing is at the time the test coverage is not very good. As it turns out passing on to test isn't really mean a whole lot so the difficulty in Glimmer 1 is you don't even know who your enemy is really. Not a lot of ways to find out if it actually did the job or not, other than actually just shipping it. As you ship, people start to report a lot of bugs and we're like, "Oh, crap. Actually, this is not tested at all so now we need to fix it." That went on for a long time really. If you actually look at the release history of 1.14, probably have the most number of point releases and that's probably the biggest divergence we ever had from the six weeks release cycle. Unfortunately, what the software is supposed to do is it's unspecified at the time, at least in terms of actual tests so it was a long process and somewhat painful process for the community to figure out what we actually need to support. That was the 1.14 transition. Unfortunately, some apps are still stuck on 1.14 today because of that, because some add-ons or some part of the code bases using some of the features that were previously undocumented or unspecified and it doesn't work on Glimmer 1 anymore. That's Glimmer 1. After that transition, we have a much better test coverage story to work with when we did Glimmer 2. However on the other hand, we actually rewrote the entire engine and also in leading up to that, we actually drop a lot of the legacy Ember features. The test coverage we previously have is useful to have but they're also pretty outdated. Concrete example of that is most of the tests previously written was written in terms of [inaudible] that's no longer a thing in [inaudible] Ember but all of the tests use views internally to test things. The first thing we actually need to do when we try to integrate Glimmer 2 is to port all of those tests, update all these tests and make sure they're still meaningful and modernized them. That was actually a huge task. Thankfully, it's also a task that's very paralyzable. The first thing we did, Yehuda and I spend some time porting those tests and Yehuda being Yehuda we actually spend some time making a really nice abstraction, a really nice test harness for doing that so we started porting some of those tests. But as we start doing that, we realized this is a lot of test to port. Fortunately, it's very paralyzable so what I did was I spent some time writing this really long issue and now are known as The Quest Issue for Glimmer 2, which outline, I for one, this is what we are trying to accomplish. This is going to be a lot of work but fortunately, the work is pretty mechanical or at least the transformation is pretty easy to describe in words. I did that. I described the work that needs to be done and we invited the community to help along. Let's see, that Issue# 13127 on the Ember report. That's known as The Quest Issue and basically, it have a checklist of all the test that still needs to be ported. Surprisingly, a lot of people were really into that, like a lot of people turns out were interested in contributing to Ember but didn't know where to start. This Quest Issue end up being a very good place for someone new to Ember to start contributing. We got a lot of response from that and within a relatively short amount of time, certainly much less than what we would have spent time doing it ourselves. In the relatively short amount of time, all tests were ported. I think that was one of the most successful call-for-help in the history of Ember or even in the history of open source software that I am personally involved with. As part of that too, by doing the harness, we actually introduced much more rigorous approach to testing things. In that process, the test coverage is probably increased several faults as well. With that, we were able to have a relatively high confidence that once all the tests are passing, that we are certainly in a very, very good shape. There might still be some unspecified behavior like there will always be some of them. But I think given the Glimmer 1 transition and also given the new style of testing, that is a lot more rigorous than before, we certainly did that much, much better compared to a Glimmer 1. After doing the original Glimmer 1 and even further back, we start with handlebars and then we wrote HTMLbars, then we wrote Glimmer 1, by now we're actually have a pretty good picture of what we actually trying to accomplish here. The requirements is becoming more clear and at the same time, we have a much better or much clearer model to work with on the Ember side because we got rid of a lot of the legacy features in the transition into Ember 2.0. HTMLbars started off as a very generic library that allow you to add behavior on top of HTML and handlebars. Glimmer 1 was basically loaded on thing using those very generic infrastructure to implement the algorithm we actually want. It turns out that we actually know what we're doing now. We don't need a super generic infrastructure for this so let's make it more tailor-fit thing for the requirements we actually have. An example of that is in HTMLbars, there is no concept of components. There's only thing called block helpers or either inline helpers or block helpers and what happens is every time you see curly-curly something and then you call into Ember, "I found a curly-curly, please do whatever you wish with this," and then we checked and, "It turned out this thing has a dash in there so probably a component. Let me try to resolve that. It turns out it actually is a component so now please synthesize some things and callback into HTMLbars library. This is the thing I actually want to render. Please do it." In Glimmer 2, actually component is pretty fundamental feature so let's build it into the rendering engine. Hopefully that would give you a better idea of what I actually mean by relying the engine with what we actually want. We know we have a pretty good specification of the problem now so we will build the thing that solves that specific problem. When I say, let's build components into Glimmer, it's not even a very concrete thing, like I don't mean the current syntax that happens to be Ember or the hypothetical angle bracket component syntax that's coming to Ember. It is just a very generic concept like there's a thing called component. It's like function calls but in templates. Let's make sure we have a good support off that. Basically, the more the engine knows, the better we are able to optimize that. Previously it's like, it turns out there's a helper-ish thing here so I guess the only thing we need to do is to hand it back into Ember and let it do whatever it wants. Now, the engine actually knows that this is a component so let's try to figure out how we can optimize this component invocation based on what else we know about the arguments and things like that. That's basically the motivation or the design behind Glimmer 2. CHARLES: Right. It's amazing that you find this pattern, kind of cropping up again and again in software where less really is more. The more assumptions that you can make, you can often make the underlying system more powerful. It's kind of counterintuitive because we want to think we want to make everything super flexible and can handle every single case. But it turns out that if you can eliminate a bunch of cases just out of hand, then you're going to have more power. One of the things that I'm curious about is it sounds like a lot of the motivation has been around performance, making sure that initial render is performant and not just a rerender. I'm kind of curious, what nonperformance related features is this going to unlock? This has been a while coming, Glimmer 2 land in what? 2.10? GODFREY: That sounds about right. CHARLES: Looking forward, what are some of the things that we can expect or what are the kind of cool features that this is going to unlock? What's the potential that we're going to see and realized kind of over the next few years based on this work that's been done? GODFREY: In a very technical sense, there are not necessarily a lot of features that are absolutely blocked in a very narrow sense of the works. However, as I mentioned before, everyone kind of felt the same way about the previous code base. Basically, the complexity is getting a little bit out of control like it's so super generic that the things are so spread out across different libraries that's really hard to work with. It's really hard to add new features. All the rendering related features are kind of put on hold as we work on Glimmer 2 because everyone knew that this better code base that's going to come along pretty soon. If we were to do anything significant, we should probably wait for that to finish. The good news is that has finished now and I think most people would agree that code base is in a much, much better shape now. In that sense, it unblocks a lot of work, both in terms of this lock that has been released but it's also in the sense that as we design Glimmer 2, we have all those things in the back of mind and we basically make sure the engine has good support for building out those features. Some of the things that are in the pipeline is I guess rehydration. We basically paused like Glimmer 2 spun off that but we never got back to finishing that work. I would say that's coming. There is angle bracket components. This is actually interesting in that. I think the plan for it to land has changed a little bit. I don't know how much I'm supposed to- Well, there are actually not a lot of secrets but just that someone's in the middle of writing out those RFCs. I don't know if I should [inaudible] shout too much of that. But as I mentioned before, Glimmer 2, the engine has pretty good support for components out of the box, like it's a pretty generic concept of component that's not necessarily tied to a particular syntax and even particular feature set. It's not tied to a particular component API, like this is not forcing you to have a specific base class and stuff. A lot of the features in Ember, like the mount keyword for engines or outlets in Ember or the render helper in Ember, all of those are actually implemented as 'components' under the hood, inside the engine even though they're pretty different things from the curly bracket component that you're used to in Ember today. I think there's a rough consensus on this, like I said, the RC is still in progress so a lot of these things can change but I believe the plan is we'll try to stabilize the core component primitive in the Glimmer 2 engine, that basically let you implement your own component API however you want as a very low level feature. If you remember how we implement the engine, it's kind of similar. We stabilized the core primitives for making engines work under an Ember and then we have an official Ember engines add-on that uses those primitive to provide the actual user-facing API when you want to support. I believe angle bracket component would be similar in that. We would try to stabilize the core primitive of implementing components in the Glimmer engine, then we'll iterate on the new Ember component API, probably as an add-on or something like that. We can get more people to try it and improve the API before actually land that as a core feature in Ember. CHARLES: What I'm hearing is there's actually the potential here to treat the kind of the core component API as an extension point like if I want to define my own different set of semantics and lifecycle hooks and what have you for my special components within my add-on or my Ember application, I could do that and yet have it exist alongside kind of standard components. GODFREY: Exactly. It's a pretty low-level API and I don't think most users would want to go for that. But I think it unlocks a lot of potential for add-on and things like that. Because as I previously mentioned, the [inaudible] in Ember is implemented using that API to render helpers, implement using that API so hopefully you can imagine there are probably something that people really wanted to do and add-on step could be made possible with that low-level API. It might not even look like a component. It could be things like you do in Liquid Fire. I think, [inaudible] has a suite of add-ons that provide some pretty events rendering features that could fall under that umbrella. Basically, it's just opens up a pretty powerful low-level primitive that add-on authors can use to implement the features they want but at the same time, also allow us to iterate on that. I don't imagine a future where literally everyone is building their own component API. I think we would still, as a community have basically this system main kind of component you use in Ember but for whatever special case you have, you can drop down to the low-level and do whatever you want. CHARLES: Right, and at least that area for experimentation and innovation is at least there. GODFREY: Right. CHARLES: That actually kind of brings to mind a very specific case that I was thinking about so I kind of throw this at you as a very friendly curveball that like this is something that you could conceive of being possible. I recently was working on an Ember application with my dad and there were some visualizations. Originally, I was doing these visualizations in D3 and it was cumbersome as D3 code can actually get. The part where you actually compute the D3 scales and the SVG attributes in D3 is very concise but the actual D3 rendering code can be very verbose and can kind of degenerate into this jQuery type like soup. What I did as kind of a first pass is I separated the computations and the slicing and the dicing of the data in D3 and presented those to a simple HTMLbars template as computed properties of a component so I had done all the computation around the visualisation in my Ember component. But then for the template, I used just a simple SVG template and it was beautiful. It was this pretty complex SVG visualization fit into, I want to say, less than 20 lines so you could perceive the entire visualization in one standard editor window, which if you've done a lot of D3 code is actually hard to achieve. When I saw that and I promise I'm going to make a point here, I was like, "Wow, this is like a powerful concept." I feel like this is the way that we ought to be doing SVG visualizations. But the thing that I lost was the thing that kind of this special sauce of D3, which is I wasn't using D3 to actually do the rendering. I was just doing it for the computation so I didn't get those really sweet transitions. One of the sweetest concepts the D3 has is this join model where when you make a change and you push a new set of elements onto the visualization, it computes for you the SVG, the actual DOM elements that are leaving, the ones that are entering and the ones that are updating. I was thinking, "Gosh, it would be really great if there was some way to hook into that inside of Ember," and I'm just kind of curious would such a thing be possible to actually get hooks on the low-level elements? Because essentially, that's what a dom-diff is, which elements are leaving, which ones are coming in, and which ones are changing. Would it be possible to have those hooks with Glimmer 2? GODFREY: I think it's definitely possible. I don't know how much of that you can actually do right away in the current code base but I think conceptually, that makes a lot of sense and that's definitely something that we should have support for, if we can already do that today. What can be adapt was I haven't spent a lot of time doing animations myself, but I would say that makes a lot of sense. I hope most of that is already achievable today. But if not, we should definitely make it happen. I think a lot of people didn't realize but we actually spend a significant amount of time on our end, making sure that we have good support for SVG. We do have a spec compliant HTML parser and stuff so it's actually rendering SVG with Glimmer or with Ember, which is actually really nice. We have some of those animations or visualization stuff in Skylight and we actually take a similar approach where we actually have SVG templates and we just use Ember to fill in the dynamic data and we have some, I believe, JavaScript code to do the animation but we should definitely talk more about that topic and making sure it's solid. CHARLES: You know, I can't reiterate how sweet it feels to do as SVG. Really, when I kind of stumbled upon it, I was like, "Wow, man. Someone needs to do this more." GODFREY: I believe in the latest iteration of D3, they actually broke up the library into pieces that makes some of those things much more easier. I think that's definitely at direction that everyone wants to have to work. CHRIS: I know that you talked about that there are people writing RFCs and EmberConf is coming up so I'm assuming that there are possibly some things that are going to be talked about there. But one of the things that has really kind of floated around Glimmer 2 ever since last year's EmberConf is that in terms of the next leap forward for Ember, Glimmer 2 was often pointed to as the blocking thing. You know, angle bracket components, a lot of other features that people would like to see in Ember, a lot of it seemed to be bound up and Glimmer 2 was going to unlock a lot of these things for us. I'm curious for an end user of Ember, what is Glimmer 2 really mean for them in terms of the next six months to a year? Are there a lot of things that are planning to be unlocked by Glimmer 2? Or is it going to be much more of an incremental progress? Or do we actually know everything that's going to be unlocked at this point? GODFREY: I think it's a combination of all of those. Like I said earlier, there are probably features that along the lines of the angle bracket component or the low-level component primitives rehydration. There is also this concept of chunk rendering in that, basically, do as much rendering as possible without making a significant pause on the UI [inaudible] and then yields expected browser for user interaction and then go back to rendering more stuff and repeat that until you're done. The net effect is you basically, don't block scrolling and things like that for a significant amount of time. Even though, your initial render might actually take more than the 60 FPS or whatever time frame you have allocated. Also, performance in general, I think we're very much not done here. We're just getting started. We have a much better engine to work with and there are a lot of further optimizations that we want to do so now, that we've shipped with completed compatibility, we climb in, more or less I think everyone is excited to get back on to those things that they were previously working on. CHRIS: Another one I have seen kind of reference a couple times, especially by Tom is Glimmer components and Ember CLI as kind of like a lightweight Ember without all of Ember. Even if you poke around the Glimmer repos, a lot of benchmarks that you can see a version of [e] components that don't yet exist, you see TypeScript, you see ES6 extends Glimmer component. A lot of things that I know people would be absolutely thrilled to see in Ember, a standalone Glimmer like planned to be a thing at all and like [inaudible] syntax, like ES6 class components is that as they make Glimmer 2 unlocks it all or are there other things that are blocking that? GODFREY: Yes, all of those are definitely in the pipeline. Standalone Glimmer is interesting. As you mentioned, Tom and several other people have started experimenting with that today. I think Tom talked about it in his EmberCamp London keynote this year or last year -- 2016. If you haven't seen that, you can definitely go check that out. It's not something I would recommend doing today in production just because there are a lot of [inaudible] in the code base still so we need to stabilize that. Literally, when I went on vacation for the last three weeks, you could basically rewrote the entire VM. It's some work that we have been talking about for a long time and he basically end up having some free time to check on that. Everyday changed after I came back from vacation so if you do that today, that's probably what you would have to deal with in the foreseeable future in the next few months. But I think we are definitely working towards making that more stable so we can enable the kind of things that Tom is doing. Part of it is definitely we need to make it easier. Currently, Tom has to do a lot of work to make that happen and Ember CLI has to be a core part of the story and etcetera, etcetera. But I think a lot of people were definitely working towards that goal. In terms of TypeScript ES6, TypeScript is actually pretty interesting. It's kind of another happy accident that came out of the Glimmer 2 rewrite. As I mentioned at the beginning, when I was new to HTMLbars code base, there are so many concepts and Yehuda and I both travelling a lot at the time so every time we reconvene, it was like, "Wait a minute. I forgot to read things so let's actually take the whiteboard and write down all these things here permanently so I won't forget them." As we start to do that, it was like, "Actually this is very complicated to write on the whiteboard so let's just write out the types somewhere," not in a very rigid sense but just, "Oh, there's this thing called render node and this is basically the responsibility. These are the methods on that thing and these are the fields on that thing." As you write that you would probably want to remember, "Oh, this is actually a string or this is an object with these sub-properties," and as we actually tried to do that, it was like, "Wow, we should not actually invent." We either have to invent a notation for that or we could just use a notation that people have made for this purpose already so let's just go to the TypeScript playground and type it out there. Then that turned out to be great but it's not that amazing to write. Many interfaces in the browser so let's just go back to the editor window and type in there and it turns out TypeScript is written in a way that all [inaudible] JavaScript is fellow TypeScript. Basically, a superset of JavaScript. Eventually what we ended up doing is we just went through an entire code base and renamed all of the JavaScript file to .ts, then we made a commit of that. Incrementally, we end up switching the entire code base to TypeScript and that's actually how it happened. In terms of using TypeScript and ES6 classes and Ember is probably block by few RFCs. There are probably some design work needed there but I would say that's happening. I don't know how close it is but just because there are a lot of things in the pipeline right in it. But I think it's a relatively high [inaudible]. CHARLES: Before we wrap up, we had some great listener questions that came in over Twitter. I want to put those to you. The first one comes from Elrich R and the question is, "What are the performance gains on mobile for Glimmer 2? How does this better position Ember for mobile development? GODFREY: I think the short answer is it's faster. As far as how much faster, unfortunately, a really hard question to answer just because it vary so much from app to app. We have some numbers that we have been looking as we develop it but at the end of the day, each app is very, very different and the kind of things that slows your app down might not be very obvious. There's a pretty interesting thing that happened when we were [inaudible] Glimmer 2. One day I was checking the Ember communities Slack and someone reported, "I have this list of 1500 items that I'm rendering. I know that's not ideal but it is what it is for now. But I just tried Glimmer 2 and it's really slow. It's taking three seconds to render that list of 1500 rows. Is there something wrong?" I was like, "That sucks." We tried to make this thing faster but I agree, three seconds is still really slow. I was like, "Can you share your app? Can you check what is the delta? What was the number pre-Glimmer 2?" He's like, "Let me go and check. Actually, it turns out it was 14 seconds pre-Glimmer 2 and it was now three seconds." I was like, "Yeah, okay. I agree that's not great but with 1500 items and we went from 14 seconds down to three seconds, I think I would take that as a win." Part of it is difference like that, really is how complicated your page is. Also there are a lot of factors that are actually unrelated to rendering, perhaps surprisingly, all of which we're working on but for example, how many routes do you have in your app, actually for some reason, plays a pretty significant role on the initial render timing and also how big your app is and things like that. I think across the board, it's pretty much faster. As you can see sometimes, it's 14 seconds, three seconds for small apps. It might be from 500 milliseconds to 400 milliseconds. In Skylight I think, we're seeing anywhere from 7% to 40% overall and we're talking about micro numbers just like everything from download in JavaScript to everything up until the page is interactive. There's a lot more than rendering going on there but I don't have a good one-size fits-all number for you here. But I think overall it's faster and we'll make it faster still and we'll continue to make it smaller. Hopefully all of that would be meaningful improvement for mobile or even just performance in general, if that's something you care about in your apps. CHARLES: Yeah, because I understand that the payload size is a lot smaller and that ought to make a huge difference there. The final question is and this one comes from Lauren T, "What is your favorite flavor of Bubble Tea?" GODFREY: Interesting. I love Bubble Tea but for whatever reason, I'm just not really into milk teas. I know that's what most people go for when they get Bubble Tea and my personal favorite is probably Honey-Lemon Green Tea. That's probably my go to. CHARLES: That's delicious. I think, I subsisted wholly on those AriZona Iced Tea in 20-ounce cans from about the age of 17 to 18. There might have been a few months where that represented all of my caloric intake. GODFREY: I think I once bought a one-gallon pack of those from Wal-Mart and unfortunately, the bottle broke in my trunk on my way home so I basically stopped buying those after that. CHARLES: You get the nice smell of rancid tea. All right-y. We'll thank you so much for coming by Godfrey. GODFREY: Thank you again for having me. CHARLES: Yeah, it had been very enlightening. A deep dive into the what the Glimmer 2 is all about, the challenges that you faced of getting there and where we can expect to go now that it's here. Oh, let me ask one final question before we send it out. Glimmer 2 has been a long process. There's been a lot of hills to climb and I know a lot of people that I've talked to, as part of the community, one of the biggest questions I have is how can I get involved? How can I help? Where can I throw my weight to see this technology blossom and become really, really useful and widely applicable to everybody inside the Ember community? Just in general, where are more of those quests that you just described? Where can people go to find out more to contribute more? GODFREY: There are several places. First of all, there is the Ember communities Slack and there's [inaudible] Ember channel and there's also a [inaudible] Glimmer channel. I think we might merge them back into a single channel at some point. But currently, those are where people hang out. In terms of quest issue, actually really counting to it in terms of the time investment versus the payoff. If there's one thing that I wish I did earlier and wish I did more is probably I would have started these quest issues earlier and do more of them. I guess we have to write more of them. But basically, hang on those channels. A lot of times, people asked questions then we try to help them out. A lot of times those end up turning into opportunities for contributions. It's kind of like documentation. I don't actually hate writing documentation but it's not the first thing that comes to mind, in terms prioritization. I think writing Quest Issue is kind of like that one. You actually do it, you realized, "Wow, this is actually really helpful and I should do it more," but it's just so counterintuitive that it's often not the first thing in trying to do when I try to prioritize my day. It's just something I have to keep reminding myself and I appreciate the reminder here that I need to write more on these issues and get more people, empower more people to be able to help. CHARLES: Alright-y. Well, you heard it folks. Thank you very much and we will see you all next week.
In this episode, Leah Silber, CEO of Tilde, Inc. and Ember.js core team member talks about what she's learned building communities, organizing events, and running a business. We talk about how people can move from "observer" to "participant" and grow their own healthy communities and companies. Links: Leah Silber: EmberConf 2016: The Morning-After Post-Mortem Event Driven: How to Run Memorable Tech Conferences Transcript: CHARLES: Hello everybody and welcome to the Frontside Podcast, Episode 43. I am Charles Lowell. I'm here with Brandon Hays, and a very, very special guest. Brandon, do you want to introduce her? BRANDON: Yeah, we're here with Leah Silber. She runs Tilde? 'Tild'? I always say this incorrectly. LEAH: You can't be saying it incorrectly. When we named the company, we knew we were choosing one of those names where people are going to say it and you just have to accept it. That's fate and that's how it goes. We usually say 'til-de' here. BRANDON: Okay, I'll say Tilde, and you can say 'Frontsi-de'. CHARLES: The way you say Tilde says more about you, than it does about us. BRANDON: Yeah, it's a verbal Rorschach test. We were really, really glad to have your time. We know that people actually work with you as a consultant for these kinds of things to help with communities, conferences, build their businesses. So, you have a lot of gathered expertise around these things. Would you tell us a little bit about yourself, about your background, what you do and kind of how you got involved in tech and running businesses? LEAH: Sure, not unlike an elevator pitch but I have been working in open source startups and companies, I want to say it's probably been like 10 years now or crazy something like that. But my first open source project that I was seriously involved in was jQuery, and that was a long time ago and it was pretty magical in retrospect because jQuery was, at the time, it was like coming out of nowhere. Nobody thought it was going to really make a dent in technology. John Resig was this clearly brilliant but still this nobody, sort of working on this project in his spare time, and Yehuda Katz jumped in and a bunch of other people earlier at the beginning. It was a time in the ecosystem where they were a little bit laughed at the room. In retrospect, there was a time when the ecosystem was a little more rude, like some of the competitive behaviors that happened back then. Thankfully, it just wouldn't fly right now. But it's been super cool to be involved with something and be able to witness something at the ground floor where this little idea and project that nobody takes seriously because there are these seemingly massive projects and landscape, and then just sort of watch it take over the world. It was a process obviously that took a little while. But again, in retrospect, it didn't take all that long, so that was really an amazing experience to watch. It was also my first really intense open source community learning experience. Everything from witnessing what kind of personalities got involved and how they did it, to watching John who sort of -- I want to say he's a consummate politician, but he's not a political person. I guess what I mean, he's just really good at people. CHARLES: He's like a diplomat? LEAH: He is. But like the sort of diplomat where you're in a battle and then suddenly a treaty happens and you just don't even know what happened but everybody's happy and you vaguely remember that you all hated each other a few minutes ago. He's really talented. Obviously, also having the technical chops to build something impressive helps with that. But watching how different personalities in open source interacted with each other, and even just for myself, like learning how to be a good open source citizen and learning how to contribute to a project and finding a way as a non-coder at the time to be useful in an open source project was really amazing. That was something I was involved with for a number of years. Then, slowly as time went on, I got involved in other projects and other events. And along the way, I was like, "This is really fun. Why am I working not in technology but doing this at night." Well pretty early on, I moved out from New York to California which is, I guess, the rite of passage or at least was. Got a job at my first startup, spent a couple years there, sort of again learning everything in fast forward because that's how startups work. I've done that a couple of different times over the years, thankfully not that many. I've managed to have what I consider impressive stability in a startup land where people can end up needing to change jobs, projects and positions very rapidly. Nowadays, I mostly focus on Ember work. There was a big chunk of time in the middle where I was focused on Ruby on Rails work. I do events, conferences, meet up groups, community management. A lot of the less glamorous stuff involved in once a project does become more successful, like figuring out a governance strategy, and figuring out how you protect your brand and what happens when lawyers and PR people and all these other different industry people start coming at you with all these questions that you hadn't thought about. How much infrastructure is too much infrastructure? What happens when the project starts having money? All these sorts of things. I feel like I've lived through a bunch of projects and their growing pains, and have a really solid understanding of the different routes. I'm still learning every day, and that's kind of why I love it. I started with my co-founders, I started my own company about five years ago which I'm always pleased and astonished to still be existing. Obviously, I watched companies spin up and die down overnight in the fast-paced technology sector. So, I'm a fan of stability and continuing to exist, is basically the top of my list. But that was about five years ago now, and it's been really great. I would never previously have identified myself as an entrepreneur. I had this, I want to say now, misconception that I was a support person, that I was the perfect second-in-command that I needed somebody at the top of the food chain who had these brilliant ideas and then I would be the person who would come in and say, "Great idea. Let me make it happen for you," and like operations and execution. At some point, I realized that that's not real. There's no reason that the person who has ideas has to be more in-charge than the person who makes ideas happened, like these two skill sets, if they're not in the same person are equally necessary. I think that was probably a little bit of standard sort of impostor syndrome kind of stuff. And also, there's a lot of pressure involved in thinking about yourself as in-charge of something important with high stakes. But I don't know. At some point, I think I watched enough people do the job and I served as that second-in-command or upper management kind of role for a lot of people. I realized that primarily, the difference between the people who were running the show as figureheads and the people who were actually running the show day to day, the difference primarily was just boldness. Like one of them had the audacity to say, "I can be in charge. I'm going to start a company. I'm going to do this." And that's not actually that big of delta so 'fake it until you make it'. BRANDON: I kind of want to lock in on that concept a little bit. I don't want to let that just float by on the river. That is something that has been such a profound lesson in my life over the last six months or a year that I think, a lot of us that wind up running companies kind of fall into that by accident or happenstance or something. You always have this weird left over hope from times where you work for other people, that somebody will step in and be in charge. It's a deal where everybody stands on the line and like, "Okay, whoever wants to step forward, step forward, and everybody steps back but you." And that feeling of being the last person standing when everybody else has backed, just by nature of not stepping back, you realized, "Oh, you know what --” Like there is such a thing as an operationally oriented CEO. So it really is the idea that you just said, it really is a matter of boldness and being willing to be the person, where the buck stops, is really the only difference between a person that feels like a really great second-in-command versus the person that feels like they could be running things. LEAH: There's just this magical myth of the big important idea person. Anything that's going to be successful or most things are going to be successful I guess, they're rarely just one person sitting on a mountain. One person starts with a shred of an idea, and then everybody around them sort of helps turn it into something real. So it could really be anybody who has that first instinct that it doesn't mean that that person has to be in-charge. CHARLES: I'm wondering, if there's any parallels there between, "Have you borrowed any of that boldness through community?" Or has there been any bouncing back and forth about lesson in terms of somebody has to take the lead on something. LEAH: Actually, it's harder a little bit in community stuff because taking a lead typically means or we think it typically means making a decision. I think that's where in open source, a lot of people go wrong, and a lot of open source projects end up with a top down management strategy where somebody is in-charge and that person tells them what's going to happen and then everybody, for example, freaks out about backwards compatibility. Then they're like, "Oh, yeah. I got a plan for this." But part of that is like you see a power vacuum and you think like, "Okay, I can step up and take this." But in open source, that's not really the ideal way or at least not in the philosophy of most of the projects that I've been in which is you only need to ask people what they think along the way, differently than in a professional environment. Like in Ember, we have the RFP process where we source a feedback before we make massive changes. That just makes everything, like you can even really say, "This is the exact thing I want to do," and you can lay out a really great plan and take that leadership role. But in a framework where it's not an edict, in a framework where it's like, "Okay, now everybody else, what do you think about it? How can you improve my idea?" And there's a whole bunch of things that happen. The first and most obvious is your idea gets better because people point out things that you didn't think of or don't necessarily personally have the experience or have noticed. But also, people just feel consulted in a way that is more critical. I like to think people want to feel consulted in work environments also. But I guess when you're the boss, you can get away with just saying, "This is the policy. I made the policy." In open source, people won't really let that fly. You can't just say, "This is a feature set. I've made this. That's the rule." Certainly not if you want them to use your project and contribute to your project and help you be successful. There are some similar things to think about when running a company versus running an open source project. But essentially, the project has to be a significantly more collaborative environment that makes people feel invested in the project and want to stick around and want to become other contributors so that the project can grow, succeed, and have a lot of people involved rather than just one-idea person. BRANDON: I was listening to a podcast recently that I can't remember which one it was but the people were talking about a different tech community and their definition of community really surprised me and it made me realize that people have different definitions for what a community is. LEAH: Wildly. BRANDON: Yeah, and so I'm curious about what your definition, in terms of an open source community, what it is and what it's job is for that open source project? LEAH: I don't have a dictionary definition and in a lot of cases, it's kind of a feel. Like I like to talk about sometimes how the different communities I've been involved with had a different feel. In an indirect fashion, a lot of what your community is comes from the people who are theoretically in charge, be that your core team, or your benevolent dictator, or whoever sort of the thought leader. That person or people really influence the kind of community that you create with their behavior. For example, the kind of community where the person in charge just tells you what the project is going to do next and does it, has a very different feel where the person in charge says, "Here are my thoughts. What do you guys think about it? How do you want us to do this? Do you have suggestions? Did I miss anything?" I think if there's enough premeditation and consideration that goes into the decisions that that person makes, that he or she can really shape a positive community, a collaborative community, and a supportive community. In Ember, we have managed to collect a group of amazing people who want to help each other, want to support each other, and who are enthusiastic about what's happening, and on most good days who don't freak out when they get a little worried that something isn't happening the way they want it to because they can trust that they're going to have a period of input and their needs are going to at least be considered. You don't always get the exact thing that you want. But it's a lot better if you know that your concerns were heard, evaluated, and maybe there's some other plan or way to sort of not completely screw you, basically. Ember's been really good at taking care of people and their needs even as the user base is more needy in different changing ways. I guess a community is a living breathing thing. For sure, it changes. I'm oftentimes sort of paying attention to the undercurrent of what happened, what's going to be the outcome of this? Having chats with people, especially people in theoretical leadership roles, about different ways to handle different situations that will keep as many people as possible, happy and supported. BRANDON: As you were describing that, to me, it feels like you've highlighted something interesting about communities, which is, you can use a theme and not be a part of its community. Somebody could use Ember and not choose to be a part of the Ember community. But participating in a community is kind of the desire to influence that thing in some way. Like, when you say they want to have their needs represented and they want to be a part of the RFC process, there is some part of it where I guess a lot of it has to do with just any kind of connection with other people who do the same thing or probably do the textbook one. But I also feel for a lot of people, there's a desire to be able to have their needs represented and met and feel like they are somehow a part of the direction of this thing, as well. LEAH: Yeah. It totally varies based on your personality. Some people just want to feel like they are a part of it. Even if they feel like their interests are well represented, you see people all the time looking for small ways to contribute because it's fun. It's exciting. There's progress happening, there's success, it's something that isn't like a lot of other opportunities that you have especially if you've been in some other industry, or some other kind of job. You don't always have this thing where you can sort of be part of an organism and a community and watch something evolve and maybe even have input in it, or just have 40 friends around the world who want to chat with you about it at any given time. It's fun. BRANDON: A question that I have in terms of following up on that is your role on the Ember side of things, I'm assuming and I want you to clarify if I'm not hitting it properly. My understanding of your role in the Ember ecosystem, in addition to handling a lot of the unglamorous logistical components is to help kind of grow and foster that style of community and Ember's become pretty well-known for having a unique focus on quality of community. I'm wondering if that's intentional or if there are things that you do or if it's sort of been luck. I don't know how much intentionality has gone into that or how much the community design has gone into that. LEAH: For sure, it's mixed. There's a lot of things where select events are really good example of setting the tone. And there's like an evolution of events that I like to follow in some of my newer growing communities that I'm focusing on where you start out with a little more of a campy feel, it's a little scrappy. And slowly, you iterate to get into a much more professional feel. But all along the way at those stages, having that event, the logistically top quality really sort of changes the tone of everything. If you show up to an event and it sort of haphazard and no one knows what's happening, you might all love each other and you probably will have a good time. But it's a different experience than one where it's sort of run like a well-oiled machine where you get a sense of people take this seriously. This is real. This is impressive. We're building big, amazing things together. We can accomplish together. So some of it is just on all the little things. Event is just one sort of example. But all the little things that go into the well-rounded ecosystem, I try and focus on quality so that obviously, there's a whole bunch of people focusing on the quality of the code. But I also want to focus on the quality of the events and the website and helping meet ups run quality events around the world and helping people show off that they use Ember and are proud. Any sort of these peripheral things -- the better you execute them, the more of an overall, "Wow! This is real. This is serious. I can stake my professional future on this." The more of that kind of a feeling that you're going to get. Community growth is organic in a lot of ways, obviously. But there are certainly things that you can do along the way to help foster the community growth. There's like personality things like making sure everyone's actually welcoming, and that people want to come and get to know you and work with you and get involved in your technology. There's things like the tactical processes of our RFC. Making sure there are ways for people technically to get involved. There's things like a focus on documentation, which again just makes it easy. So, it's really an overall quality thing every step along the way, and a lot of community overlook the parts of building community that aren't code. You can do that but you end up on a different trajectory than a project where you pay attention to all the peripheral things. CHARLES: So, I'm actually curious because I've witnessed the things that you've done like on a grand scale which definitely have had that air of quality that you're talking about. But I'm curious about these kind of nascent communities that you're talking about and kind of just, one, just curious about what they are because I'm curious. Then the second is, for people who might be speaking of doing something similarly, like starting something small that they want to grow into something huge, but actually that concrete, small scope. What are the things you can do with limited resources, if you have limited resources and you've got a small scope, what can you do to imbue it with that sense of quality that will carry you to higher places? LEAH: I guess the first thing to think about, and I hope this does not sound bad, but is whether or not your project actually needs a community. By that I mean I certainly think open source projects should all be actual open source projects. So you should accept pull requests, you should let people file issues, you should have collaborators, etcetera. But there have been a lot of projects along the way that I've been involved with helping with where we looked at it and said this doesn't need to be a community. This doesn't need to have a conference every year, or it'll have some sort of community right just amongst people who contribute but it doesn't need to be like Ember, like Rails. We're a whole giant ecosystem that spins up. For example, over the years, there have been projects like Handlebars, Bandler, and Thor. These are projects that tremendous numbers of people use. You don't run into anyone who says like, "I'm a member of the Thor community." And that's perfectly fine, right? There's sort of a version of a project where you have an MVP, you have a good website, you have good docs, you have a bunch of contributors, and that's all you really need. Then there's the version where you want it to be a much bigger, more involved setup. So one community that, I would say, in a nascent stage right now is the Rust community, which I've been peripherally involved with. I'm not on the team. I'm not doing significant community masterminding but I have been working with some people in the project to do agree with me on the value of this quality. And so, I've helped them. We just ran Rust Conf this last weekend which was their first conference. It was 250 people in Portland. It was really, really fantastic. I've worked with them on, for example, making quality swag over the years and trying to figure out what level of control over their brand. It's not too much but still protects the brand enough, things like that. They've also modeled some of their governance kind of stuff after the Ember community which makes sense. Yehuda is involved in both projects and he's a big proponent of a lot of that stuff. But it's been really cool to watch. Like first Rust was saying, "Oh, this how Ember does it. Let's crib some of that stuff." Now, in a lot of cases, Ember is saying, "Oh, wow! Look how Rust is doing that. Let's take that back." It's been a very good symbiotic back and forth relationship. But it really just does take the people who are leading intellectually to decide that they care about quality, to decide that they care about a collaborative community environment, to decide that they care about diversity, to decide that they care about all of these little things along the way. The earlier people recognize that these are things you need to care about, the better job that you can do. You can always sort of ride the ship most of the time. But if you start out on the right path to begin with, you're going to be able to accomplish so much more because you don't have that much course correcting to do. There is obviously, also always course correcting in Ember, in Rust, in Rails, everywhere, where somebody not speaking about code but somebody takes a misstep and the whole community sort of has to figure out like, "Okay, this is not the way we want. This is the kind of interaction to go. How are we going to fix this?" Or, "This is not the way we want. There's kind of major technical decisions to be made. How are we going to fix this?" It's an evolution. It's a collaboration. I'm absolutely a fan of the core team entity and of that core team being a medium sized group. Not tiny but a medium sized group of people who bring really, really different things to the table in terms of who they are, their backgrounds and their skills. For example, this serves me well but I am a fan of core teams that have non-coders on the core team. There's a lot of stuff that can get done for a project that doesn't involve writing a line of code. Now, obviously you want to have somebody around who understands open source and the strategy. It is in fact challenging to find people who don't have to be coders but also appreciate all this other stuff and want to be involved in it. But when you can find people like that, that's the really magical key to this more well-rounded community. I like to say, engineers are basically superheroes. They can sort of think of something and then create it and that is the power that most other kinds of people don't have. I mean, maybe contractors and welders, but if you are working at a desk job somewhere, there's not really much that you can conceive of where you have an idea, you write it down, you spend a couple months then it exists, it works, it actively changes your life. One of the downsides of that amazing superpower is that engineers can oftentimes get into a position where they think anything is possible and they don't recognize that just because they can figure out how to do something doesn't necessarily mean that they are the best people to do that thing. That comes into play a lot with these other qualitative things in an ecosystem. So, you can go to a lot of technical conferences and wonder, sort of, why is the quality not quite there? In a lot of cases, the answer is because the person in charge is not particularly skilled in this area. They are coder. They can write brilliant code but do they know how to think about where the lunch line is going to queue up and make sure that it's going to go through the phase, and that there's enough bathrooms and stuff like that. These are very vastly different skill sets. One of the past successes there is to sort of realize, "Yes, I can probably pull this off." But if I can find somebody for whom this is a natural area of expertise and I can focus on my area of expertise. Like, wow. We'll be able to accomplish so much more and everything will be better all around. BRANDON: I think you've hit on something there again that I've seen since moving into technology from -- I come from a non-technology background and there is a sense outside of this industry that people kind of have different areas of expertise. When you are an engineer, your job -- I actually think a lot of it stems from the fact that your job is to become an expert in the field of other people's jobs. So, your job is to automate something so you have to know enough about marketing to do marketing software. Then you have to know about enough about this other thing to do this other thing. So you think that you can learn anything and it's true that you can learn anything but there's a skill tree associated with each of those things. You don't realize, you're a junior level conference organizer, and maybe it might be worth talking to a senior level conference organizer. We've definitely fallen victim to that many times where we thought, "Oh, you know what? I'm pretty good at the technology side. I can give a conference talk. I must be probably pretty good at education." And it turns out that education is a multi-thousand year old skill tree that is pretty well-defined. LEAH: One of the hard parts in thinking about this for me is, I really like the MVP concept that I have taken from technology, which is you don't have to get it right. Get something out there. Figure out what the bare minimum version of whatever it is you're trying to accomplish is. Ship it, iterate. I like that and I talk about a lot of things in my life in that frame which is kind of weird when I talk to my parents about iterating on things and what not. For example, in a decision about child rearing. "Oh, my God. The first one is this way." It's a very useful way of thinking about things and I am a fan in many things of actually applying it to areas all over your life. But for something like how to run a small conference, you oftentimes don't need an MVP. You don't need to go through the stage of that level of quality because you can just work with somebody who's already learned all those lessons and already done those things. It's not like a greenfield code project where somebody has to actually start from the baseline every time it's a new project and build up all the infrastructure. You can just skip right to the front of the line. Find someone who's good at this and start out initially at a much higher level of quality. BRANDON: I want to kind of dig into that a little bit and ask about you wrote a really great blog post earlier this year about your experiences running Ember Conf. It's so obvious the amount of effort and kind of thought, not just effort, but like directed effort and thought that goes into building a really great experience for people. I'm wondering if you have like certain areas that you look for and noticing whether somebody has really put a lot of thought into designing a good conference experience for somebody. If somebody were hoping to do something like that, what are some of the areas that tell you that you're dealing with like a really good, thoughtfully designed conference? Or where does that effort go basically when you run through the process? You only have so much time and effort you can put into this thing to create that experience, not the minimum viable conference, but the conference when you look at the division of your time and doing conference stuff. I think people wind up being surprised how much goes toward one thing or another. LEAH: I'm not entirely sure how to answer that question because you don't usually get insights into what people are doing along the way. I go to fewer conferences these days because I find myself irritated. I don't even like the way it sounds but it's kind of true, where I go to a conference and I'm really trying to focus on the content and I'm really trying to focus on the goodwill of the people who are organizing it. Oftentimes, it's just so many moments where I'm like, "That should be better quality." Like it is very easy to get that right. You just need to have thought about that. You just need to plan for that. I don't think there's many opportunities to sort of figure out those things ahead of time from somebody else to make an assessment of how a show is going to go. I can say that there are sometimes things that I see on just the websites where I'm like, "Oh, that is not a good sign." There are tools around for most of the things that you would want to do like selling your tickets and collecting information, and the online pre- event functionality. It's rarely a good sign when you see someone build their own. It's sort of another engineer foible kind of thing. You don't need to reinvent the wheel. It takes substantial energy to reinvent the wheel. If you go with something that already exists, you can focus for example, on all this other quality stuff. But there's also sort of the way in which people build the content of their conference, like that's super telling. Maybe not even so much about logistics but it is pretty telling about the community or at least the people running a show as a representation of the community. For example, I think it's pretty much conventional wisdom these days that you want to have blind call for papers. It's not reasonable to me when I see someone not do it that way. I understand that small events maybe just go invitation in the first year or two. I think that's actually a pretty justifiable thing. We don't have the critical mass yet to get enough submissions in for a program, or we're not really sure how to execute on that, and our community has these specific people who we know are really talented and will do a good job. I think you end up with usually a subpar roster that way because you don't have the variety of experience that you'd be able to attract in a call for papers. But what's super weird to me is, yes, we're going to do a call for papers but we're not going to go the classic extras steps that open source and technology as a whole has learned that will really help this task go better and help eliminate latent biases and things like that. That's kind of weird. I still see it sometimes. I find myself confused by it. I suspect more than anything that people just haven't thought of it or don't know how to execute on the strategy that a lot of other conferences has figured out a successful. I don't know, part of the reason I don't like to go to conferences so much is I remember when I was making all these mistakes, and I don't want to be that person who's really critical of someone who's trying to do something good but it's hard. Once you have that experience and once you sort of know better, it's hard to watch somebody else stumble over the same things you stumbled over. You feel like, "You should know that. I know that." CHARLES: So, is there a community of conference organizers? It seems like they need to be some sort of meta conference or some sort of meta community of community organizers. BRANDON: There is Conf Conf. CHARLES: Are you serious? LEAH: I might not be impressive enough to go to something called Conf Conf. I don't know. A lot of those things actually when you get to, "Oh, it's industry, upper-tier collaborator events." They're often times invitation kind of things and I'm not very cool. I don't know. I see things like that sometimes. There's this conference about speakers. It's like speakers conf – CHARLES: Oh, speakers conf, yeah, and it's like in Aruba. LEAH: It seems cool but I'm always like, "How do you get invited to that?" CHARLES: Yeah, that's the part -- BRANDON: How do you get into that club? LEAH: I know people who should be there and don't know it exists, or people who should be there but just - I don't know, no one has invited them, and it's invitational. It's hard to say. But I guess what I was going to say is over the years, I have at times belonged to different online forums that were trying to scratch that itch. The most successful one was probably for a good five, six years. There was a very active community of conference organizers in the Ruby space. But I think most of those people have either stopped doing conferences or gotten to a place where they just don't need that much help anymore, and there hasn't been like an influx of new people doing it. So there isn't really any strong community like that that I belong to today. That's a challenge in anything you face, where once you don't need the help anymore, people don't stick around to help the other people and it's hard to sort of organize that way. BRANDON: That sounds like a big opportunity to me. But it sounds like an opening or a hole for providing something like that. Do you do any consulting for people on this? Do people hire you to help design a conference experience? Because I know that the ones you've put together -- you're pretty well-known for being one of the best in the business for this. LEAH: Thank you, I think. No pressure at all. I do consulting, though obviously, that's mostly for companies and not communities because communities don't typically have money for that sort of thing. In communities, you need to create your own experts, and in an ideal world, there are people who recognize that when they're at the beginning of the learning curve, they should reach out to people who are further along and benefit from their experience and do things like read blog post and books and what not. The blog post that you mentioned earlier, it was absurdly long. I was surprised that anybody read it and then a lot of people read it. I was surprised because of the length but I was also surprised in the way that it's difficult to come up with a conference talk where you're sort of like, "I know all this stuff," but I don't know what amongst this knowledge base is interesting to other people, and I don't know what other people don't know and I know the stuff so obviously, it's not impressive. But I sort of forced myself to write it anyway because it was just such a big endeavor and there were thoughts even for myself that I wanted to preserve for later. Then I was pleasantly surprised by how many people read it and had comments and had useful things to say, or even just like, "I appreciate how much thought went into XYZ. I wouldn't have thought that. It was value that came out of that blog post that I didn't think of at the beginning. The value of other people getting a chance to recognize what kind of thought and planning needs to go into having something like that execute flawlessly, or dealing with things when they don't execute flawlessly. BRANDON: One thing that that was an obvious expenditure of effort, because you started so early in the process, many months before the conference was the Women Helping Women Initiative. I saw that really early on. I actually don't think that was precedented in conference organizing. Can you tell us a little bit about that? I don't remember how far in advance it was, I just remember thinking it was absurdly far in advance and very well thought out and very well designed. LEAH: Well, it was early. For example, I actually have to email the Women Helping Women group today with a long list of thoughts and activities for next year. I feel like I'm super behind because it's September 15th and the conference is at the end of March. Last year, I think we were already talking basically like 2, 3 weeks after the previous year's conference had ended. So basically, I looked at the conference in 2015 and it was great. I was really happy with most areas of it but I was not happy with the representation of women. There's so many groups that in fact, the conference would benefit from that representation of, but women was obviously a target that I thought I could potentially bring something to the table on being a woman in technology and in Ember. I spent some time thinking about all the various women in tech efforts. I have been involved over the years in a lot of things that felt good and said good things but at the end of the day didn't seem to accomplish very much. Right from the beginning, I wanted it to be a tactical effort. I wanted it to be like a short term pipeline of, "We put this in one end and we get this out the other end, and we have accomplished XYZ." Because it's important to have lots of organizations that make people who are under-represented in any community feel good and feel welcome. But it's also just as important and a little bit less prominent, in most cases, to have those same people then become leaders in that community. That' sreally sort of a signal to everybody else that they're welcome and that they can accomplish things. I looked at our community and I thought there are already, actually, really awesome women here. Not as many as I'd like. But I know a lot of women who are impressive and who are like, "Why aren't they on stage?" So, I sort of approached the effort last year from the perspective of there's a lot of organizations out there working on the women in technology pipeline problem, and it's a very real problem. Hopefully, they're going to do a solid job. There's a lot of insights and I'm watching and it's cool. But I want to focus on the problem of -- let's not call it a problem -- but I want to focus on the situation of the people who are already here and helping them take those leadership roles and step up and really join the community at every level. Not just at the entry level. We've come in through the fix the pipeline problem setup. CHARLES: And then hope everything kind of magically works itself out from there. LEAH: Yeah, which shockingly, it doesn't. I don't know... We spent many, many months basically supporting people at every step along the way from, "I want to go to this conference," to, "I'm a speaker at this conference." And we did things like brainstorming about what kind of proposals people could submit. We helped each other once we had a critical mass of a bunch of talented women. We helped each other with our proposals. We helped each other with our ideas. I organized podcasts where the program committee did question and answer sessions with the women. We did some hangouts where women who had more experience than the rest of us came and talked about their first time speaking or their experience getting to know a community or their experience learning to code and we encourage each other in a lot of ways. It's just a really positively pushy support group. We encourage each other. It's funny because it was hard along the way sometimes because you don't want to be too pushy. I was always worried and sort of dancing on that line of, "I want to repeat to you, you can clearly do this. You have said things. You have accomplished things, look at your education, look at your career. You are obviously, obviously good enough and impressive enough to be on the stage and I want to keep reminding you of that so you do it. But I also don't want you to feel like you are being bullied into it." Not everybody wants to be a leader. Not everybody wants to be in a role of getting up on stage and giving a talk. I had a couple of the participants come talk to me or email me after the program saying, "That was really helpful. That was the nudge that I needed." So that made me feel good about the various interactions along the way and it's always just going to be something that you have to do in a very sensitive manner. But there are women that I knew that were here that were talented and then so many women that just came out of the woodwork where I was sort of like, "I know your name or I didn't know you at all," and like, "Why don't I know your name? You're incredible. You're better than half the people I see on stage at a conference." And so we worked on this for months and months and months. I got a bunch of women in the community who were in sort of transitional leadership roles which is I thought, "Hey, you're a community leader," but they weren't sure they were a community leader yet. I got a lot of people like that involved to help nudge along all the other people who could potentially be our next batch of community leaders. I don't know... It was really amazing and you have to pad the numbers every step along the way and at the end of the day, you actually want a conference with impressive representation of anyone. So you have to get significantly more than you need into the pipeline thinking about it, and then significantly more than you need actually submitting and then hopefully at the end of the tunnel when everything shakes out, you'll get a reasonable number of people right. Because obviously things get filtered out and at every step of the way. There's a lot of other people that you're competing with. Overall, the quality of the proposals from the women was astonishing. It was a blind call for papers process in terms of the program committee. But as the administrator, who doesn't get a vote in these things, I was managing the app that handle the voting during the process of picking our speaker and all that kind of stuff. I was just astonished by watching quietly in the background how all these ratings came in and nobody knew they were doing this but the proposals from the women were on average, like dramatically better than everybody else. I'm not like saying, "Oh, yay! We're better." I'm sure a lot of that had to do with the amount of thought that went into it because even a seasoned conference submitter who spoke in a lot of conferences might get to a point where they're sort of cranking out a proposal in a week or even a month, and a lot of these women spent six months thinking about it. But all that hard work showed in the proposals, all that hard work showed in the roster, and I really want that hard work to show around the community. Part of what I'm trying to focus on this year is how do we take that from being the EmberConf Women Helping Women program to being the general Ember Women Helping Women program. Because after EmberConf, I felt like I could really help other conferences change their way that their rosters grew. Specifically before that EmberConf, you did have a lot of well-meaning organizer saying, "I want more women represented at my conference but I can't find them." Now, I think there's certainly ways to do it and there's a lot of clever ways to meet people and encourage people. But when push comes to shove, and it's in that moment, you would just run into a lot of organizer saying, "Well, I don't know what to do. It's an open process. Anyone can submit." And now, they could look at our conference and see there's a dozen women who are clearly talented and capable. I'm going to go to all 12 of those people and ask them to submit to my conference. Maybe some of them will and maybe that will help. It's a small step but I started seeing the women who spoke at EmberConf who a lot of them hadn't spoken anywhere beforehand, pop up at conferences all over the place. So, I sort of felt like the effect was magnified and we were able to really... I don't want to say like we, all of us women together, were able to help each other not just at Ember Conf but in a larger way. We're focusing a lot on that this year or I should say, we're going to start on how can we expand the program to be a resource that helps women take leadership roles and speaking opportunities across the JavaScript ecosystem so that Ember is really truly well represented by the people who actually make up the community. BRANDON: I think it's super clear that the thought process that you put into this was well designed enough and the work that went into it was consistent enough that you both got a huge uptick in the number of women represented at the conference. But also actually overall, the quality of conference talks went up year every year as a result of all of that additional preparation. And the encouraging people from backgrounds that had something to say that maybe felt like they didn't have something to say, instead of seeing the same faces over and over again, they went all the way across the board and it ended up showing and being a better quality conference experience for attendees for that. LEAH: It turns out the diversity is actually awesome. It's not just the thing that you should talk about and put on a list because it's politically correct. But in fact, things will be better if there are more people represented from different backgrounds with different experiences, different skills, different everything. You felt it everywhere you went and felt like you were hearing new things, interesting things, and perspectives that maybe weren't always as well represented. My biggest sad point about things is I'm trying to tackle the community of women but there are so many other communities that could also be better represented in Ember and in technology at large. And I would really love for more people to step up and sort of focus. It's hard to get involved in an effort like this because it's hard to get any traction and also because honestly, there's a lot of concern about, "Am I going to do it right? Am I going to make the problem worse?" All those sorts of self-doubt issues that are legit and based on having seen other people out in the world make a good faith effort trying to fix a problem but like say something wrong and get in huge trouble. It's just challenging and it requires a lot of thought. Even me, as I talk about this right now, I'm stressed out and I'm like, "Am I using the right words? Am I going to say the wrong thing?" But it's still worth doing. And if you're persistent and you work hard, you can really, really change things and have a positive impact. BRANDON: Well, I think it sets forward a lot of good patterns for other people trying to do this thing and I think when you talk about this being scary, the point is that it's not going to be scary. It's very scary so it makes it super brave that you're attempting that stuff. I think the impact is certainly on me. I found that pretty inspiring. Certainly at the Frontside, we found it inspiring. I hope it inspires other people in other communities to follow the same patterns. LEAH: Yeah, I hope so. I mean if there are women or anybody else that feels like they have something to contribute to really improving the landscape of who our leadership is and making sure each they are represented, I guess I would encourage those people to step up. It's the same thing as being a CEO or being the second-in-command. You just need to have the boldness to decide that you're going to try and make a difference. In the Women Helping Women program specifically, I've been talking to a lot of the women that I met last year about how can you take more of a leadership role in the program? For example, I was talking a week ago to somebody who's a student in the Women Helping Women program and I was like, "I can't represent your concerns as well as you can." I was in college at some point but that was a very long time ago, and there are just perspectives that you're going to have that I'm not going to have. Even within the women's group, there's like different perspectives and I've been working with people and encouraging them to try and work with me on taking leadership roles within the program itself. So many well-meaning programs like this, by the way, like spin up, have some success and then go away because the person-in-charge got busy and that's the end of that. It's similar to a community in that if it's going to be a long term successful effort, or at least as long term as it's necessary, I'm really going to need other people in the community to step up and find ways to be involved so that I'm not actually important to the success of this anymore. Instead, it's a whole group of people and there's no one single point of failure. BRANDON: When that happens, I can't wait to read that particular blog post. When you're able to kind of demonstrate the process for other people to be able to follow and, "Hey, look at this thing. It kind of runs itself now." That sounds really awesome and you're definitely -- LEAH: Fingers crossed. BRANDON: Yeah, you're kind of off road because you're helping to find some of the things that may influence other communities, as well. So, I think that's super cool. LEAH: I hope so. BRANDON: All right. We need to get let you get back to CEO-ing. You have a company to run and you have a whole life and everything. LEAH: I'm going to put on my business jacket as soon as I hang up on you and get back to work. BRANDON: You're in Portland. It would be a like a business hoodie probably, right? LEAH: Sort of. I have this really nice blazer. It literally changes my mind some days. I'm like, "Oh, I'm not getting enough done." I'm going to put out my business blazer. Then, they shift into over drive. BRANDON: All right. We'll get your business blazer and get to business-ing. That actually sounds like a cool little business life hack. LEAH: Yeah. BRANDON: Well, thank you so much for your time on this stuff. We got about halfway through the questions I want to talk to you about so I hope we get a shot at doing this again. I really love learning from you on this stuff. I've learned a ton from your writing. I've learned a ton from watching you work and I really appreciate all you do for the Ember community, the JavaScript community, all the stuff you've done for the Ruby community. You've had a really big impact, and so it's really great to talk to somebody that kind of sets a pattern of how these things are possible. I hope that good fortune continues to follow you as you're bold in doing these things. So, thank you for all the stuff that you do. LEAH: Thank you. I hope so, as well. It's been fun. CHARLES: Thank you. All right, goodbye everybody. BRANDON: So, bye everybody. If you have any questions or anybody else that you'd like us to talk to, let us know. If you have any additional questions for Leah, hit us up on Twitter at the Frontside. CHARLES: We usually ask for people's contact information. Where can youl be found on Twitter? LEAH: I do have a Twitter account. I'm not super active because I'm busy wearing my business blazer. But my handle is @Wifelette and I try to be as responsive as I can certainly to people who reach out to me, even if I'm not broadcasting all that much. BRANDON: Awesome. Okay, well thank you again Leah, and thanks Charles. I hope everybody listening has an awesome week.
02:22 - Michael North Introduction Twitter GitHub Levanto Financial 04:10 - Ember vs React or Angular JavaScript Jabber Episode #203: Aurelia with Rob Eisenberg 07:13 - Convention Over Configuration 09:39 - Changes in Ember SproutCore iCloud Ember CLI Performance glimmer 16:04 - Ember FastBoot Building a performant real-time web app with Ember Fastboot and Phoenix 18:53 - EmberConf Opening Keynote by Yehuda Katz & Tom Dale 22:47 - Mobile/Native Experience & Optimization Service Worker Hybrid Apps 29:52 - Electron 30:46 - Open Source Empowerment; The Ember Learning Team 33:54 - Michael North's Frontend Masters Ember 2 Series 37:11 - The Ember Community Picks React Rally (Jamison) Embedded (Jamison) Remy Sharp: A debugging thought process (Jamison) NashDev Podcast (Aimee) JS developers who don’t know what closure is are fine. (Aimee) Sublime Text (Chuck) DesktopServer (Chuck) MemberPress (Chuck) Frontend Masters (Mike) Wicked Good Ember Conf (Mike) Debugging Node.js with Visual Studio Code (Mike)
02:22 - Michael North Introduction Twitter GitHub Levanto Financial 04:10 - Ember vs React or Angular JavaScript Jabber Episode #203: Aurelia with Rob Eisenberg 07:13 - Convention Over Configuration 09:39 - Changes in Ember SproutCore iCloud Ember CLI Performance glimmer 16:04 - Ember FastBoot Building a performant real-time web app with Ember Fastboot and Phoenix 18:53 - EmberConf Opening Keynote by Yehuda Katz & Tom Dale 22:47 - Mobile/Native Experience & Optimization Service Worker Hybrid Apps 29:52 - Electron 30:46 - Open Source Empowerment; The Ember Learning Team 33:54 - Michael North's Frontend Masters Ember 2 Series 37:11 - The Ember Community Picks React Rally (Jamison) Embedded (Jamison) Remy Sharp: A debugging thought process (Jamison) NashDev Podcast (Aimee) JS developers who don’t know what closure is are fine. (Aimee) Sublime Text (Chuck) DesktopServer (Chuck) MemberPress (Chuck) Frontend Masters (Mike) Wicked Good Ember Conf (Mike) Debugging Node.js with Visual Studio Code (Mike)
02:22 - Michael North Introduction Twitter GitHub Levanto Financial 04:10 - Ember vs React or Angular JavaScript Jabber Episode #203: Aurelia with Rob Eisenberg 07:13 - Convention Over Configuration 09:39 - Changes in Ember SproutCore iCloud Ember CLI Performance glimmer 16:04 - Ember FastBoot Building a performant real-time web app with Ember Fastboot and Phoenix 18:53 - EmberConf Opening Keynote by Yehuda Katz & Tom Dale 22:47 - Mobile/Native Experience & Optimization Service Worker Hybrid Apps 29:52 - Electron 30:46 - Open Source Empowerment; The Ember Learning Team 33:54 - Michael North's Frontend Masters Ember 2 Series 37:11 - The Ember Community Picks React Rally (Jamison) Embedded (Jamison) Remy Sharp: A debugging thought process (Jamison) NashDev Podcast (Aimee) JS developers who don’t know what closure is are fine. (Aimee) Sublime Text (Chuck) DesktopServer (Chuck) MemberPress (Chuck) Frontend Masters (Mike) Wicked Good Ember Conf (Mike) Debugging Node.js with Visual Studio Code (Mike)
The gang talks to Nick who is live at EmberConf. LeftPad destroys the internet and more! The post SitePen Podcast Episode 013 appeared first on TalkScript.FM.
The gang talks to Nick who is live at EmberConf. LeftPad destroys the internet and more! The post SitePen Podcast Episode 013 appeared first on SitePen.
The Frontside crew recaps the EmberConf 2016 experience and share their biggest takeaways and lessons learned. Show Links: EmberConf Ember Freestyle Matthew Beale - Interoperable Component Patterns Jade Applegate Estelle DeBlois Brigitte Warner Kelly Senna Katie Gengler Leah Silber - EmberConf 2016: The Morning-After Post-Mortem
伊藤直也さんをゲストに迎えて、Kindle, フロントエンド開発、テスト、チームビルディングなどについて話しました。 Show Notes Amazon will announce a new Kindle next week LOGICOOL ワイヤレス ソーラーキーボード k760 液晶ディスプレイの「色温度」を究める Rebuild: 114: Rebuildersland (Shu Uesugi) Redux kik, left-pad, and npm Emails between kik and Azer isarray Plugins · Babel フロント界隈におけるJavaScript開発環境 npm@3 Flat Module Installation axios: Promise based HTTP client vue.js EmberConf 2016 Dan Abramov joined Facebook アプリ開発と状態遷移の管理 テストなんか書かなくて良い チームが機能するとはどういうことか フレーミング効果 心理的安全性 タックマンモデル RubyConf Soft Talks
Chase and Jonathan discuss goings on in Ember land post EmberConf.
Sean and Kyle cover all the topics. GraphQL, missing EmberConf, rupbyonrails.org demo app doubts, Echo v Siri, Moscow Mules, Tiki cups, when to ship, and so-much-more. Hold your piece!
Sean and Kyle cover all the topics. GraphQL, missing EmberConf, rupbyonrails.org demo app doubts, Echo v Siri, Moscow Mules, Tiki cups, when to ship, and so-much-more. Hold your piece!
Chase and Jonathan discuss the new testdouble.js library, A vim workshop, gush over Emberconf events, and then have a long winded discussion about the Ember Weekend Site.
Charles, Brandon and Stanley are joined by Luke Melia to discuss being early adopters of Ember, Ember CLI Deploy, and growing the Ember community. Show links: Luke Melia Luke on Twitter Yapp Ember CLI Deploy RailsConf 2012: Lightning Fast Deployment of Your Rails-backed JavaScript app EmberConf 2015: The Art of Ember Deployment
Kenneth joins us to discuss EmberJS. His breadth and depth of knowledge on the topic of ember is not only impressive but very immersive. Although we generally try keep episodes under 45 min, this was too good to cut short. Panel: @stevenMcD_code @pgermishuys @kennethkalmer Picks: Kenneth 1 - Ember.land podcast (http://www.ember.land/) 2 - EmberConf Keynote - https://youtu.be/o12-90Dm-Qs 3 - EmberConf 2015 TDD by example - https://www.youtube.com/watch?v=2b1vcg_XSR8 4 - Rock 'n Roll with Ember.js - http://balinterdi.com/rock-and-roll-with-emberjs/ 5 - Untappd - https://untappd.com/ Pieter: 1 - https://zadevelopers.slack.com/ Steve: 1 - Rob Conery's Mastering your own Domain course - http://www.pluralsight.com/courses/master-domain
Charles, Brandon and Stanley wrap up part two of their discussion about their favorite talks and technologies from EmberConf 2015. Stanley sings a Staind song, and proposes to the entire internet. Show Links: Ember CLI Deploy Aaron Patterson (Tenderlove) Orbit.js Jamie White - Growing Ember One Tomster At A Time Ember Community Guidelines Brittany Storoz - Building Custom Apps With Ember CLI Edward Faulkner - Physical Design Liquid Fire Bryan Langslet Mitch Lloyd - Ember Islands Ember Observer
Charles and Brandon share their foodie weekend experiences, and discuss EmberConf 2015; highlights and what they learned. Show Links: Black's BBQ Smitty's Market, Lockhart Charleston Wine & Food EmberConf 2015 Godfrey Chan - Hijacking Hacker News HTMLBars Lauren Tan - Ambitious UX for Ambitious Apps Toran Billups - Test Driven Development by Example
Ember JS Conference Recap. This week we discuss last month's EmberConf, what's going on with components, and the current state of testing in Ember and how developers are working towards making it easier. Show Links: Brandon's MountainWest JS talk Brandon's slides EmberConf talks Jeremy Mack on Fnd.io Fnd.io DeVaris Brown: Ember is for the Children Rails Girls Rails Bridge Code Rush
© 2020-2025 Ivy Podcast Discovery LLC
