Podcasts about javascript apis

Google's Maps JavaScript API is a fundamental web technology that's used to build dynamic and interactive map features in web apps. Matt Toon is a Solutions Engineering Manager for the Google Maps Platform. He joins the podcast with Josh Goldberg to talk about his background working with geospatial data, the development of Google Maps, bringing The post Google Maps Javascript API with Matt Toon appeared first on Software Engineering Daily.

Google's Maps JavaScript API is a fundamental web technology that's used to build dynamic and interactive map features in web apps. Matt Toon is a Solutions Engineering Manager for the Google Maps Platform. He joins the podcast with Josh Goldberg to talk about his background working with geospatial data, the development of Google Maps, bringing The post Google Maps Javascript API with Matt Toon appeared first on Software Engineering Daily.

While learning the technical ins and outs of ServiceNow are important for your career, there's more to being a great ServiceNow dev than knowing how to hack XML files or all the JavaScript APIs. In this episode, Lauren and I have a chat about some key moments in our lives that changed our careers. Topics 00:00 Welcome 03:50 Lauren's #5 08:26 Chuck's #5 11:31 Lauren's #4 16:49 Chuck's #4 21:09 Lauren's #3 26:26 Chuck's #3 31:14 Lauren's #2 35:21 Chuck's #2 38:51 Lauren's #1 43:39 Chuck's #1 48:16 Outro Links Book: The Art of Simple Living Manager Tools/Career Tools podcasts Check out the other ServiceNow podcasts.See omnystudio.com/listener for privacy information.

While learning the technical ins and outs of ServiceNow are important for your career, there's more to being a great ServiceNow dev than knowing how to hack XML files or all the JavaScript APIs. In this episode, Lauren and I have a chat about some key moments in our lives that changed our careers. Topics 00:00 Welcome 03:50 Lauren's #5 08:26 Chuck's #5 11:31 Lauren's #4 16:49 Chuck's #4 21:09 Lauren's #3 26:26 Chuck's #3 31:14 Lauren's #2 35:21 Chuck's #2 38:51 Lauren's #1 43:39 Chuck's #1 48:16 Outro Links Book: The Art of Simple Living Manager Tools/Career Tools podcasts Check out the other ServiceNow podcasts.See omnystudio.com/listener for privacy information.

Wes and Scott welcome Cameron McEfee, a seasoned creative director whose journey spans GitHub, Sentry.io, and the innovative realm of JavaScript plugins with his creation, GuideGuide. Cameron explores plugin building, iterating on the iconic Octocat for GitHub, and shedding light on the multifaceted roles of a creative director. Show Notes 00:00 Welcome to Syntax! 01:06 Who is Cameron McEfee? 03:00 What does a Creative Director do? 09:47 In a creative and collaborative field, how do you deal with hurt feelings? 12:32 Experiences at GitHub (404/500 pages). 15:35 Who is responsible for all the Octocat variations? GitHub Octodex 17:18 Did you ever get in trouble for using famous IP? 21:07 Working at Sentry.io. 25:08 What is your illustration process? 27:04 What is GuideGuide? GuideGuide Moo Tokenizer/Lexer 33:13 Grid Notation. 36:10 Can ‘good colors' be calculated, can good design be math'd? 40:46 What was the process of building your own plugin? 43:37 Adding guides with JavaScript APIs. 44:44 Recreating application UIs within plugins. GoodHertz 50:22 How are you architecting these plugins? 52:44 Sick Picks & Shameless Plugs. Sick Picks Cameron: Ember Mug Waterparks Spotify Execute Program Shameless Plugs Cameron: GuideGuide 50% off Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott:X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Uncover the future of Salesforce development with insights from Mohith Shrivastava in our latest episode, where we dissect the Spring '24 release highlights. From the time-saving beta feature Scratch Org Snapshots to the sleek new Null Coalescing Operator and the UUID system class in Apex, we're unpacking tools that promise to elevate your coding experience to new heights. These updates not only simplify workflows but also signify Apex's evolution towards contemporary programming standards. In this episode, we discuss the substantial enhancements within Lightning Web Components, like the now widely available Workspace API and the transformative Lightning Record Picker component. We also say goodbye to tools such as the Ant Migration Tool and Workbench. Meanwhile, Salesforce Data Cloud is upping its game with new features and updates that integrate data with unprecedented ease.  Don't miss out on the excitement for what the future holds for Salesforce releases — join us for an episode brimming with expert knowledge and tips straight from one of Salesforce's very own developer advocates. Show Highlights: Apex language enhancements, including the Null Coalescing Operator for streamlined null checks and default value assignments and the UUID system class. Updates to Lightning Web Components (LWC), along with performance improvements through component versioning and native JavaScript APIs. Retirement of the Ant Migration Tool in favor of Salesforce CLI for deployment and org management. Salesforce Data Cloud advancements with new features for data integrations. Resources: Read the blog: The Salesforce Developer's Guide to the Spring '24 Release Follow the trail: Spring '24 Release Highlights Browse the release notes Join the Salesforce Developers Trailblazer Community group to connect with the global developer community. Join Release Readiness Trailblazers to stay up to date on the latest and greatest product enhancements and innovations across the Salesforce ecosystem.  

In this episode of Syntax, Wes and Scott talk through new and proposed JavaScript APIs including ones related to regex, sourcemaps, structured clone, temporal, JSON modules, and more! Show Notes 00:10 Welcome 01:26 Syntax Brought to you by Sentry 02:55 RegExp Escaping Proposal tc39/proposal-regex-escaping: Proposal for investigating RegExp escaping for the ECMAScript standard 05:25 Intl.DurationFormat tc39/proposal-intl-duration-format 07:55 Standardized Sourcemaps tc39/source-map-rfc: RFCs for the source map debug format. 10:43 Structured Clone structuredClone() global function - Web APIs | MDN 12:54 Temporal Hasty Treat - Temporal Date Objects in JavaScript Tracking issue for syncing with IETF standardization work (req'd before implementers can ship unflagged) · Issue #1450 · tc39/proposal-temporal 20:59 FindLast and findLastIndex tc39/proposal-array-find-from-last: Proposal for Array.prototype.findLast and Array.prototype.findLastIndex. 22:27 JSON modules tc39/proposal-json-modules: Proposal to import JSON files as modules 24:46 Regex Modifiers RegExp Modifiers - June 2022.pptx - Microsoft PowerPoint Online 26:50 Array Grouping tc39/proposal-array-grouping: A proposal to make grouping of array items easier 30:48 Array Methods tc39/proposal-change-array-by-copy: Provides additional methods on Array.prototype and TypedArray.prototype to enable changes on the array by returning a new copy of it with the change. 6 or so New Approved and Proposed JavaScript APIs 32:12 Promise.withResolvers 35:08 Function.prototype.memo tc39/proposal-function-memo: A TC39 proposal for function memoization in the JavaScript language. 37:48 Node has a Proposed ESM Detection flag 39:54 Node has navigator.userAgent 41:29 Built in .env support 42:52 Permissions model & test runner continues to be worked on 44:06 HTML Web charts Proposal: Web Charts · Issue #9295 · whatwg/html 45:39 autopause Add autopause attribute to media elements to allow automatic pausing of media · Issue #9793 · whatwg/html 46:30 Meta Tag for AI generated content Proposal: Meta Tag for AI Generated Content · Issue #9479 · whatwg/html Schema.org - Schema.org Syntax × Sentry Swag Store – Syntax × Sentry Shop Syntax - A Tasty Treats Podcast for Web Developers. 50:13 Poster frame HTML Video Element: Proposal for adding [srcset] + [posterset] + [sizes] on video element as well [posterset] on source elements · Issue #9812 · whatwg/html 50:57 Popover invoker Popover does not know what triggered it · Issue #9111 · whatwg/html 51:25 Autocomplete on ‘contenteditable' Elements Autocomplete on ‘contenteditable' Elements · Issue #9065 · whatwg/html 52:17 Sick Picks Sick Picks Scott: Escaping Twin Flames cult documentary Wes: Lao Gan Ma spicy Chili Oil Shameless Plugs Scott: Sentry Wes: Wes Bos Courses Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads

In this episode of Syntax, Wes and Scott talk about new approved and proposed JavaScript API changes including Promise.withResolvers, .at(), Immutable Array Methods, Array.fromAsync, and more. Show Notes 00:10 Welcome 04:55 What are we going to cover? 06:10 Promise.withResolvers 09:40 .at() You probably knew about JavaScript's new .at() method for accessing array items. Did you know it works for strings too? @IAmAndrewLuca 15:59 Immutable Array Methods Wes Bos: "

Welcome to the newest episode of The Cloud Pod podcast! Justin, Ryan and Matthew are your hosts this week as we discuss all the latest news and announcements in the world of the cloud and AI - including what's new with Google Deepmind, as well as goings on over at the Finops X Conference. Join us!  Titles we almost went with this week:

In this episode I'm joined by GUN founder Mark Nadal to discuss GUN. GUN, also known as GUNDB, is a real-time, decentralized, offline-first, graph database. In practice, GUN provides a Javascript API that allows webapps to sync data between peers with no centralized server dependency. GUN peers use WebRTC and similar transport protocols to sync data to localStorage and IndexedDB in the client. GUN also provides access controls, which allow developers to store encrypted data on the network. The API can be used in browser tabs, on mobile apps, or run as a relay peer in a NodeJS process on a cloud instance. In this conversation, GUN's founding engineer Mark Nadal and I dive into the technical details to explain what makes GUN different from IPFS, WebRTC, and blockchains, and why so many devs are excited about GUN. I hope you enjoy the show. Topics Discussed · GUN in 100 seconds Youtube Video · Learn Cryptography in seven 1-minute videos · NERFs for photogrammetry · GUN for Metaverses · Comparison to IPFS · WebRTC, Gun Relays · Every Gun peer runs a WebRTC signalling peer · A GUN Instagram competitor by an early Bitcoin dev iris.to · Project built with GUN

Quick show notes Our Guest: Facundo Giuliani (Twitter) What he'd like for you to see: His musical Jam: The Meters Transcript Bryan Robinson 0:15 Welcome back to yet another episode of That's My Jamstack, the podcast where we ask the ever important question, what is your jam in the Jamstack? I'm your host, Bryan Robinson. And this week we had the amazing Facundo Giuliani. Facundo do is a developer relations engineer at story block, and an avid presenter and author about all things Jamstack. Bryan Robinson 0:46 All right, Facundo. Well, thank you so much for joining us on the show today. Facundo Giuliani 0:49 Thank you. Thank you very much for the invitation and the opportunity. Awesome. So Bryan Robinson 0:53 tell us a little bit about yourself. What do you do for work? And what do you do for fun? Facundo Giuliani 0:57 Cool. So Well, I started working as a developer when I was 18. While I was studying at college, because I finished high school on on a school that had a career that was like programming oriented, let's say so I, I learned how to program during the high school, I started to work with all programming languages that people don't know what they are about, like Visual Basic six, or those things that are like, I mean, I talk to people that this 20 years old, and they look at me, like what are you talking about? Right. Bryan Robinson 1:38 But luckily, I at least dabbled in those super early on. So I'm with you. That's fine. Facundo Giuliani 1:43 Okay, okay. So, um, yeah, I mean, I started working with Visual Basic seats. After that, while I was studying, I was also working as a developer, it was like, almost 1414 years, probably that I worked as a developer. And during the last couple of years, after working on on different companies on different positions, but all of them mainly related to the development, like, full stack back and, and etc. I started to, to be more involved with the community started to generate content to share starting to talk to other people and and meet other people. And I really enjoyed doing doing that. I did that during my free time. During these last couple of years, like after work, I started to generate content, engage with the community, like being involved in a Ambassadors Program in in different organizations and companies. And this opening a new door for me, because I started to learn about developer relations, developer advocacy, developer experience, some terms that probably I've read in the past, but I didn't know what they were about. And, and I started to get interested on that, like I, I mean, I felt like I was enjoying more the fact of generating content, or sharing content with the community, or communicating with the community, I really like to talk to other people. And I enjoy talking. And I felt like I was enjoying more doing that, instead of doing my daily job of developer, let's say, I mean, it's not that I don't like to, to develop, but I was enjoying more generating content, sharing content with the community engaging with other people. And well, I took like this, I made a decision, I started to read about developer relations and etc. I saw this opportunity on serverless, that they were looking for a developer relations engineer, I applied for the, for the job, and I was selected. I mean, I had a portfolio because in the past, I presented some talks, or events or conferences, I had some articles that I wrote before applying for the for the job, working with different technologies, and etc. So that was my, my presentation letter, let's say, and well, I had the chance to apply and to be and to be accepted for the position, let's say. And since June, I'm working as a developer relations engineer at serverless, my first developer relations position and experience, and I'm really enjoying it. So that's a little bit about me. Bryan Robinson 4:38 Sure, yeah. So So you're a developer relations engineer at storyblocks. So you're doing all that kind of content creation, education, talking with community there. Are you still doing that in your spare time? Are you actually able to like branch out and do other things now that you don't have to do that yet to your day job? Facundo Giuliani 4:56 Well, that's a good point. Because I mean, I did it Probably, I'm doing it but just a little bit like not so much. Because the cool part about being a developer relations engineer is that I found that that it was possible to do what I wanted to do or what I was enjoying, while doing it on my on working time, right, I mean, during the day, instead of using my free time to generate the content to do that, probably use my free time to set my mind free, right? That I mean, I'm not complaining, because I really enjoy doing that. And I enjoyed that at that moment when I was doing it after work. But I felt like it was it was cool to to enter to a company and start doing this during I mean, like, my, the tasks that I'm doing in my position are related to that. So I can use my free time on that on other things. So I enjoy doing that. But yeah, I'm trying to take the free time for other projects, probably not related to to developer relations or engaging with the community. I'm probably not even related to programming developer or technology Bryan Robinson 6:15 at all. What's your favorite thing to spend time on outside of development? Facundo Giuliani 6:19 Well, I really like I mean, I was I mean spending more time outside, I moved to a house, I was living in an apartment and I have a house with a backyard. So I'm trying to spend time there or I don't know walking around the neighborhood, I live in more than a situs Argentina, in the suburbs of the city, not in the city center. And the place where I live is like a calm neighborhood with a lot of trees and etc. So like when I, when I finished my, my, my day after working, I like to go and walk around the neighborhood and etc. but also talking with friends. So there are other projects like personal project related to, to their staff playing, playing sports with friends. I'm trying to do several activities, like to get out of my house. I mean, I enjoy being on my house with Mr. Gary Burger, and etc. But I also enjoy seeing other people spending time with other people. And these last couple of years were like We spent a lot of time inside our houses. So spending time like, I don't know, keep grabbing some fresh air and talking to other people is something that I enjoy doing. And I try to do as possible. Bryan Robinson 7:33 Awesome. I think there's something that we all do a little bit more of, especially in the past couple of years. Yeah. So. So moving on to talk about the Jamstack a little bit. You have a history in kind of full stack development, back end development, what was your entry point into the Jamstack, and static sites and that sort of thing. Cool. Facundo Giuliani 7:52 So Well, in my previous job, I mean, my last job before being a developer relations engineer, I was working mostly as a back end developer, I was working with Microsoft technologies like ASP, dotnet, dotnet, core and etc. But I, I mean, I felt like I was missing the the opportunity of learning about probably newer products or different products, let's say related to the front end. And when I started to read about the static site generators, the headless CMS is that I mean, for the products that we did in my previous job, I was not able to apply these technologies on them. So I was like, not super aware of all this new approach of creating study sites. And I started to read about the Jamstack different articles, watching different talks, or Devens, at conferences, and etc. And I started to learn about that and to learn about the approach. I really enjoyed that because at a certain point, as I said, I am I mean, I'm working as a developer for since I was 18. But before that, I was creating websites at home when I was even younger, with with products that again, they don't exist anymore, like Microsoft front page, or Macromedia Dreamweaver. And what you did in the past with Microsoft from page was like creating your own website. And when I was said, I mean, when I was a teenager, or probably even younger, I really enjoyed doing that. Because at that time, internet was not what it is now, right? I mean, at the beginning of this of the 2000 years, or the or the or the end of the 90s Probably, internet was like the super new things and being able to create your own web page was like, Man, this is NASA technology, right? So I tried to create like websites related to anything related to my friends related to us. Searching a football club or related to I don't know, my different interested interest is that I had in that moment. And and what I was doing at that moment were static sites. I mean, they had movement. They have awful MIDI sounds in the background, because that was so yeah, I mean, that was like any any site at that moment, that sound. So that is terrible, I think now about that. And he's like, Man, why do you need to listen to music while we're browsing? A web page was terrible. But well, it's what we did. Yes, exactly, exactly. So I enjoyed doing that. But the thing is that they had dynamism, let's say, or movement, or etc. But they were static. So while when, when I started to read about the new approach of having studied websites, I felt like, I mean, the Navy sidebar, but we are again, doing the same that what that what I did was when I was a young teenager, or probably pretty teenager, I don't know, how is it called the the concert when you are 12 years old, or 13 years old pro. But, I mean, I started to feel to feel like excited with this concept. And I started to read about different study site generators, like neck JS Gods B, I started to read about React, probably get more involved with React, and etc. And on the other hand, all the concepts that you have avoidable to generate the content at build time, ahead of the people visiting your website, I mean, the process of generating static assets, but not manually, right, not using Microsoft front page like we did at that time. So I mean, I felt that that was super fun. Because using new technologies, you were able to do something that probably reminded me to what I used to do when I started creating web pages. So I think that that was the first step that I took to to enter to the Jamstack work, let's say, Bryan Robinson 12:07 I like that concept of like, this is kind of how we did things in the late 90s. And now we do it. We have a similar output. But it's so much easier to like it just Yes, I'm not I'm not writing and copying and pasting 15 different HTML pages. I just, it generates for me, it's an amazing feeling to kind of see that come out. Yeah, exactly. Facundo Giuliani 12:28 I'm not only that, I mean, when you are using a study site generator, when you like, start a new project with the boilerplate that they offer you, you have a site up and running, and you run just like three comments in the console, or probably less. And that's all I mean, that's awesome. For me, the web development is evolving in, like, in all directions to make the work easier for the developers and to have the products up and running as fast as possible. And that's something that for me, it's awesome. Bryan Robinson 13:01 Yeah, and let's, let's try a whole bunch of stuff and like work closely with clients and with stakeholders and all that to, like, realize what they're looking for. And then we can make it better. Like we can do something simple and then add to it and add to it and add to it. I think that's a really powerful pattern that we get to have. Facundo Giuliani 13:18 Yes, yes, I agree. I mean, a lot of technologies appear during the last year, some being able to use these technologies, but also offering a great experience to the final users or the content editors. It's something pretty, pretty cool. I mean, I see that all the pieces are, like joining to offer a good experience, not only to the developers, but also to the people that is using your product on beseeching the websites that you create, right, Bryan Robinson 13:46 exactly. Yeah. Theoretically, if we can do things easier and simpler, we can pass on a whole bunch of really positive things to those end users. Facundo Giuliani 13:55 Yes, yes, I agree. Totally agree. So. Bryan Robinson 13:58 So you're at story block now. So how are you using? I mean, sorry, block is a headless CMS. So it's a very Jamstack company, how are you using Jamstack philosophies and kind of your day to day at story block. Facundo Giuliani 14:10 So what we were we tried to offer to the, to the customers to the users is that having a headless CMS is a way of generating faster websites, using cool technologies and cool frameworks, probably, but also offering a good experience not only to the end user, but also to the content editors, the Jamstack, we see that we have a lot of products available to create static sites, or offer great experiences and having like, sites up I mean, up and running that are working great. But the thing is what happens when we need to generate the content that is going to be exposed in our static sites, right? So story block has this real time visual editor, which I think it's probably the best feature that serverless is offering. Because there is this bridge that connects the the admin panel that Starbuck offers to generate the content with the front end of your application. And well, you can use it with environments that are already deployed, like your testing environment, or staging or production. But you can also connect that to your local host. And using like the preview mode of the different static site generators, you can also offer an experience to the content editors to see how the content is going to look like before it's deployed or published. So in that case, connecting the story blog application or the server admin panel to the front end of your application using the storybook bridge, you're offering the possibility of creating an experience very similar to a page builder, but not being tied to the styles or the components or their structure that the Page Builder probably feeds or probably sets for the developers that are going to use it. So you are able to create the front end and the code and the logic that you prefer for your application connecting to a headless CMS that is allowing the users to see that page and to like, create a unexperienced very similar to editing that page on the fly, and see how the content is going to look like. So I think that we are focused on on different technologies, frameworks, and tools, probably I will I work more with Node js, and react. And what we try to do is to get advantage of the static site generation process of these frameworks to generate static assets, but also work with a preview mode of these frameworks to connect to the headless CMS and offer the content editor the possibility of exactly creating the continent scene, the content that is going to be Publish when the build process run and generate the static Bryan Robinson 17:14 assets. Exactly. And that build process sometimes can be a minute or two. And so like if you're trying to iterate on content, and you're having to save, wait for the build, preview it and then preview it live, like snap previewing more, it's just a view that can really slow you down. Oh, no, I wrote one word too long. It's gonna break onto a line at the screen sizes. Like no, just use the Preview mode, use that visual editor to make sure it's exactly what you want it to be. It's kind of it's the best of both worlds kind of solution. Right? Facundo Giuliani 17:42 Yeah, exactly. Exactly. And not only that, I mean, talking about Nigeria, in particular, the framework offers cool features like incremental static regeneration, where you don't really need to generate the the run a build process for the complete site to generate probably only one page or two, apply the changes to only one page in your website, we can discuss about if using incremental study regeneration is really Jamstack or not, because you are breaking the atomic bill and etc. But you have the possibilities there, you can use it or not take it or leave it. Bryan Robinson 18:19 I actually like that that like thought process of I might not be Jamstack anymore. But it I mean, at the core, even though you lose the atomic deploy, you're still hosting the majority of it from the CDN, it's still much the majority of it's still pre built HTML, and you're updating pieces. It's a rehydration thing, which I I would say arguably, is still plenty within the idea of the Jamstack. I think it's it's a big umbrella. We can fit everyone underneath it, I think. Facundo Giuliani 18:46 Yeah, totally. I in fact, I think that, well, probably the concept of the Jamstack was originated by JavaScript API's and markup. But the thing is, I feel like the idea is always trying to generate the more static content that we can as possible at build time. And not, I mean, not having dynamic content to be generated whenever a user visits our website, right? Why are we Why will we generate content, that will be the same for probably all the users that will visit our web application or a lot of them, if we can do that ahead of time, and offering a better and faster experience to the user right there. Exactly. Bryan Robinson 19:27 And then just augmenting, augmenting is always the best way to go adding little bits of extras for for when you have the ability to do it. And it matters like what what, what pieces of content actually have to be dynamic. And let's make sure those are dynamic and keep everything else quick and secure, you know, as static as possible. Exactly. So we've talked about story block we've talked about next. Jas, we've talked a little bit about incremental static regeneration and whether or not that's Jamstack or not, what would you say is kind of your jam in the Jamstack? What's your fate? Have a product maybe story block or or framework or philosophy, what makes you love the Jamstack. So? Facundo Giuliani 20:06 Well before joining storybook, I was a user of a storybook, I've used terbuka and other headless CMS. So I mean, probably I'm biased on my feature now is like, but I really think that cerebral is a great product to generate content, probably. I mean, we as developers are used to work with things that are not super how to say that friendly for the users, or were used to work with code and etc. But having the possibility of giving the people that there is not super full into the technology, the possibility of creating the content and and exposing the content that they want to share. I think it's very, very cool. And having a visual editor to do that. I think he's pretty cool, too. So I think that sort of look is very, very good. I'm kind of like, I use NET Jas a lot. And I feel like when the the new versions that they released, I mean, version after version, I see that they create really cool things. So I will say that I really enjoy using Node js with with Node js 12. And all the announcement that they did was like, the possibilities that are appearing with these new features. And with these new products is really, really cool. I mean, enjoying, like the edge functions or the support for React 18 with the React server components, different features, like I think that are opening new doors or new windows for other possibilities to, again, what I think I mean, what I think it's important from the Jamstack, that is offering not only a good developer experience, which they are with the product, but also offering a great experience to the final user. So if I can offer a website that is working faster and better for the final user, I'm getting the advantages. So I will take it. Bryan Robinson 22:08 And the great thing on like next and again, like the the big surge of next Jas, in the past year and a half, two years. They're bringing so many new things to table. I mean, next next 12 is great. But we've talked about ISR, like that was pioneered in next and like all these different patterns that are coming out, are coming from the next open source team, the Vercel. Team, the community all around that. I think it's it's moving the ecosystem at a much faster pace than it did previously. I love to see that. Facundo Giuliani 22:40 Yeah, I agree. I totally agree. I mean, the the opportunities that are appearing, and yes, as you said, like an starting point, or a pioneer point of saying, hey, why don't we take a look at this possibility and discussing it and offering that to the developers. Bryan Robinson 23:00 I think it's also interesting, you know, we talked about ISR, maybe not being Jamstack. And I think the cool thing with next is the next doesn't care. Like they they look at it, and they say, Well, you can be completely Jamstack and just use, you know, static props and all that good stuff and render HTML and and send that down for the CDN. But you can use these other things, too. And whether or not that's Jamstack. It's still a nice website. And it's still like meeting all the user needs. So let's not even talk about it. Let's just have these features built in. Facundo Giuliani 23:30 Yeah, that's true. That's, I mean, I love the Jamstack. I like the approach. I enjoyed using it. Sometimes we have to think what's better for the users and for the developers, and probably not stick to too much to the theory like, Oh, I'm moving from the Jamstack. Like, what I was going to say millimeter but if the United State people is listening to me, they probably won't get what measure unit I'm using. But what I mean is that barely moving from the borders of the Jamstack, or the bounds of the Jamstack is not that bad. I mean, the final idea or the final goal is to offer a great experience not only to the final user, but also to the developer. So you have to think about that Bryan Robinson 24:15 make a good app or a good website with the best developer experience possible. Facundo Giuliani 24:20 Exactly. Bryan Robinson 24:21 All right. Well, let's let's do a kind of a hard pivot here and ask maybe the toughest question on the show, which is what's your actual jam right now? What what are you listening to what musician or album is really getting you going right now? Facundo Giuliani 24:33 I mean, I really enjoy listening to music. I'm listening to music all the time. Like, what I found out lately was that if I listen to music that they have like a singer and they are singing a lyric. I can't focus on the work that I'm doing. I don't know if that happened to me in the last time or not. I really don't understand because I really enjoy listening to music and I Listen, a lot of music of different genres, so of different types and etc. So while I was working or probably probably because with this developer relations engineer position, I need to focus more on writing, or I don't know speaking or generating content, I'm probably not doing some automatic thing, things, let's say, I need to focus more on the work and not not too much on the on the lyrics that I'm listening to. So what I what I was listening this last time was probably more like Lo Fi setlist in the background, I live Lo Fi music, and I enjoy listening to that while I'm working. But I also was listening to the meters, which is a band from I don't know, if they are from New Orleans, I really don't remember. But they did in the in the 70s. Music like it was it is funk music, but without singing, or at least, not all of the of the songs have had lyrics. I mean, the most of them are music only. And I enjoy that because they have this groove and this kind of music that I really like. And with the headphones with the, with the boost of the bass there is like it's a good experience while working. So I'm really enjoying that. Bryan Robinson 26:22 Awesome. Yeah, I totally like Lo Fi is definitely something that I usually have on in the background while I'm doing some writing or working through a hard code problem. So I get that. And I hadn't heard the beaters, which is surprising. So I'm going to check them out. And I could I could use some fun in my ears as well. Yeah, sure, sure. All right. So anything that you're doing that you would like to promote out to the Jamstack community as a whole, Unknown Speaker 26:45 no, I encourage the people to if they didn't try the Jamstack to take this step and to see I mean, probably it's a good experience. And it's very fun. I enjoy doing that. So I recommend that. But if if any person wants to talk about the Jamstack, front end development or anything, they will find me on Twitter, I'm while I'm FacundoGiuliani, my my Twitter handle is @facundozurdo. With so you can talk to me and we can discuss about the topic that you prefer. I am constantly like presenting talks at events or conferences. Well, I mean, all of them virtual now but but I will I have the hope that I will be in person in in in person, probably local meetup or conference soon. So we can probably meet in person in any country, some with with the people. But yeah, I mean, if you go to Twitter, and you talk to me, you will see I have my personal website where I announced the the events where I will be part of and I will be speaking Bryan Robinson 27:53 amazing. All right, cool. Well, thank you so much for being on the show with us today. I hope you keep doing amazing things at storyblocks and beyond. Facundo Giuliani 27:59 Thank you. Thank you very much. Thank you for the invitation again. Bryan Robinson 28:03 We'll see you around. Thanks again to our guest and thanks to everyone out there listening to each new episode. If you enjoyed the podcast, be sure to leave a review, rating, Star heart favorite, whatever it is, and your podcast app of choice. Until next time, keep doing amazing things on the web. And remember, keep things jammy Transcribed by https://otter.ai Intro/outtro music by bensound.com Support That's my JAMstack by contributing to their tip jar: https://tips.pinecast.com/jar/thats-my-jamstack

Steph has a baby update and thoughts on movies, plus a question for Chris related to migrating Test Unit tests to RSpec. Chris watched a video from Google I/O where Chrome devs talked about a new feature called Page Transitions. He's also been working with a tool called Customer.io, an omnichannel communication whiz-bang adventure! Page transitions Overview (https://youtu.be/JCJUPJ_zDQ4) Using yield_self for composable ActiveRecord relations (https://thoughtbot.com/blog/using-yieldself-for-composable-activerecord-relations) A Case for Query Objects in Rails (https://thoughtbot.com/blog/a-case-for-query-objects-in-rails) Customer.io (https://customer.io/) Turning the database inside-out with Apache Samza | Confluent (https://www.confluent.io/blog/turning-the-database-inside-out-with-apache-samza/) Datomic (https://www.datomic.com/) About CRDTs • Conflict-free Replicated Data Types (https://crdt.tech/) Apache Kafka (https://kafka.apache.org/) Resilient Management | A book for new managers in tech (https://resilient-management.com/) Mixpanel: Product Analytics for Mobile, Web, & More (https://mixpanel.com/) Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: CHRIS: Golden roads are golden. Okay, everybody's got golden roads. You have golden roads, yes? That is what we're -- STEPH: Oh, I have golden roads, yes. [laughter] CHRIS: You might should inform that you've got golden roads, yeah. STEPH: Yeah, I don't know if I say might should as much but might could. I have been called out for that one a lot; I might could do that. CHRIS: [laughs] STEPH: That one just feels so natural to me than normal. Anytime someone calls it out, I'm like, yeah, what about it? [laughter] CHRIS: Do you want to fight? STEPH: Yeah, are we going to fight? CHRIS: I might could fight you. STEPH: I might could. I might should. [laughter] CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. STEPH: And I'm Steph Viccari. CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? STEPH: Hey, Chris. I have a couple of fun updates. I have a baby Viccari update, so little baby weighs about two pounds now, two pounds. I'm 25 weeks along. So not that I actually know the exact weight, I'm using all those apps that estimate based on how far along you are, so around two pounds, which is novel. Oh, and then the other thing I'm excited to tell you about...I'm not sure how I should feel that I just got more excited about this other thing. I'm very excited about baby Viccari. But the other thing is there's a new Jurassic Park movie coming out, and I'm very excited. I think it's June 10th is when it comes out. And given how much we have sung that theme song to each other and make references to what a clever girl, I needed to share that with you. Maybe you already know, maybe you're already in the loop, but if you don't, it's coming. CHRIS: Yeah, the internet likes to yell things like that. Have you watched all of the most recent ones? There are like two, and I think this will be the third in the revisiting or whatever, the Jurassic World version or something like that. But have you watched the others? STEPH: I haven't seen all of them. So I've, of course, seen the first one. I saw the one that Chris Pratt was in, and now he's in the latest one. But I think I've missed...maybe there's like two in the middle there. I have not watched those. CHRIS: There are three in the original trilogy, and then there are three now in the new trilogy, which now it's ending, and they got everybody. STEPH: Oh, I'm behind. CHRIS: They got people from the first one, and they got the people from the second trilogy. They just got everybody, and that's exciting. You know, it's that thing where they tap into nostalgia, and they take advantage of us via it. But I'm fine. I'm here for it. STEPH: I'm here for it, especially for Jurassic Park. But then there's also a new Top Gun movie coming out, which, I'll be honest, I'm totally going to watch. But I really didn't remember the first one. I don't know that I've really ever watched the first Top Gun. So Tim, my partner, and I watched that recently, and it's such a bad movie. I'm going to say it; [laughs] it's a bad movie. CHRIS: I mean, I don't want to disagree, but the volleyball scene, come on, come on, the volleyball scene. [laughter] STEPH: I mean, I totally had a good time watching the movie. But the one part that I finally kept complaining about is because every time they showed the lead female character, I can't think of her character name or the actress's name, but they kept playing that song, Take My Breath Away. And I was like, can we just get past the song? [laughs] Because if you go back and watch that movie, I swear they play it like six different times. It was a lot. It was too much. So I moved it into bad movie category but bad movie totally worth watching, whatever category that is. CHRIS: Now I kind of want to revisit it. I feel like the drinking game writes itself. But at a minimum, anytime Take My Breath Away plays, yeah. Well, all right, good to know. [laughs] STEPH: Well, if you do that, let me know how many shots or beers you drink because I think it will be a fair amount. I think it will be more than five. CHRIS: Yeah, it involves a delicate calibration to get that right. I don't think it's the sort of thing you just freehand. It writes itself but also, you want someone who's tried it before you so that you're not like, oh no, it's every time they show a jet. That was too many. You can't drink that much while watching this movie. STEPH: Yeah, that would be death by Top Gun. CHRIS: But not the normal way, the different, indirect death by Top Gun. STEPH: I don't know what the normal way is. [laughs] CHRIS: Like getting shot down by a Top Gun pilot. [laughter] STEPH: Yeah, that makes sense. [laughs] CHRIS: You know, the dogfighting in the plane. STEPH: The actual, yeah, going to war away. Just sitting on your couch and you drink too much poison away, yeah, that one. All right, that got weird. Moving on, [laughs] there's a new Jurassic Park movie. We're going to land on that note. And in the more technical world, I've got a couple of things on my mind. One of them is I have a question for you. I'm very excited to run this by you because I could use a friend in helping me decide what to do. So I am still on that journey where I am migrating Test::Unit test over to RSpec. And as I'm going through, it's going pretty well, but it's a little complicated because some of the Test::Unit tests have different setup than, say, the RSpec do. They might run different scripts beforehand where they're loading data. That's perhaps a different topic, but that's happening. And so that has changed a few things. But then overall, I've just been really just porting everything over, like, hey, if it exists in the Test::Unit, let's just bring it to RSpec, and then I'm going to change these asserts to expects and really not make any changes from there. But as I'm doing that, I'm seeing areas that I want to improve and things that I want to clear up, even if it's just extracting a variable name. Or, as I'm moving some of these over in Test::Unit, it's not clear to me exactly what the test is about. Like, it looks more like a method name in the way that the test is being described, but the actual behavior isn't clear to me as if I were writing this in RSpec, I think it would have more of a clear description. Maybe that's not specific to the actual testing framework. That might just be how these tests are set up. But I'm at that point where I'm questioning should I keep going in terms of where I am just copying everything over from Test::Unit and then moving it over to RSpec? Because ultimately, that is the goal, to migrate over. Or should I also include some time to then go back and clean up and try to add some clarity, maybe extract some variable names, see if I can reduce some lets, maybe even reduce some of the test helpers that I'm bringing over? How much cleanup should be involved, zero, lots? I don't know. I don't know what that...[laughs] I'm sure there's a middle ground in there somewhere. But I'm having trouble discerning for myself what's the right amount because this feels like one of those areas where if I don't do any cleanup, I'm not coming back to it, like, that's just the truth. So it's either now, or I have no idea when and maybe never. CHRIS: I'll be honest, the first thing that came to mind in this most recent time that you mentioned this is, did we consider just deleting these tests entirely? Is that on...like, there are very few of them, right? Like, are they even providing enough value? So that was question one, which let me pause to see what your thoughts there were. [chuckles] STEPH: I don't know if we specifically talked about that on the mic, but yes, that has been considered. And the team that owns those tests has said, "No, please don't delete them. We do get value from them." So we can port them over to RSpec, but we don't have time to port them over to RSpec. So we just need to keep letting them go on. But yet, not porting them conflicts with my goal of then trying to speed up CI. And so it'd be nice to collapse these Test::Unit tests over to RSpec because then that would bring our CI build down by several meaningful minutes. And also, it would reduce some of the complexity in the CI setup. CHRIS: Gotcha. Okay, so now, having set that aside, I always ask the first question of like, can you just put Derek Prior's phone number on the webpage and call it an app? Is that the MVP of this app? No? Okay, all right, we have to build more. But yeah, I think to answer it and in a general way of trying to answer a broader set of questions here... I think this falls into a category of like if you find yourself having to move around some code, if that code is just comfortably running and the main thing you need to do is just to get it ported over to RSpec, I would probably do as little other work as possible. With the one consideration that if you find yourself needing to deeply load up the context of these tests like actually understand them in order to do the porting, then I would probably take advantage of that context because it's hard to get your head into a given piece of code, test or otherwise. And so if you're in there and you're like, well, now that I'm here, I can definitely see that we could rearrange some stuff and just definitively make it better, if you get to that place, I would consider it. But if this ends up being mostly a pretty rote transformation like you said, asserts become expects, and lets get switched around, you know, that sort of stuff, if it's a very mechanical process of getting done, I would probably say very minimal. But again, if there is that, like, you know what? I had to understand the test in order to port them anyway, so while I'm here, let me take advantage of that, that's probably the thing that I would consider. But if not that, then I would say even though it's messy and whatnot and your inclination would be to clean it, I would say leave it roughly as is. That's my guess or how I would approach it. STEPH: Yeah, I love that. I love how you pointed out, like, did you build up the context? Because you're right, in a lot of these test cases, I'm not, or I'm trying really hard to not build up context. I'm trying very hard to just move them over and, if I have to, mainly to find test descriptions. That's the main area I'm struggling to...how can I more explicitly state what this test does so the next person reading this will have more comprehension than I do? But otherwise, I'm trying hard to not have any real context around it. And that's such a good point because that's often...when someone else is in the middle of something, and they're deciding whether to include that cleanup or refactor or improvement, one of my suggestions is like, hey, we've got the context now. Let's go with it. But if you've built up very little context, then that's not a really good catalyst or reason to then dig in deeper and apply that cleanup. That's super helpful. Thank you. That will help reinforce what I'm going to do, which is exactly let's migrate RSpec and not worry about cleanup, which feels terrible; I'm just going to say that into the world. But it also feels like the right thing to do. CHRIS: Well, I'm happy to have helped. And I share the like, and it feels terrible. I want to do the right thing, but sometimes you got to pick a battle sort of thing. STEPH: Cool. Well, that's a huge help to me. What's going on in your world? CHRIS: What's going on in my world? I watched a great video the other day from the Google I/O. I think it's an event; I'm not actually sure, conference or something like that. But it was some Google Chrome developers talking about a new feature that's coming to the platform called Page Transitions. And I've kept an eye on this for a while, but it seems like it's more real. Like, I think they put out an RFC or an initial sort of set of ideas a while back. And the web community was like, "Oh, that's not going to work out so well." So they went back to the drawing board, revisited. I've actually implemented in Chrome Canary a version of the API. And then, in the video that I watched, which we'll include a show notes link to, they demoed the functionality of the Page Transitions API and showed what you can do. And it's super cool. It allows for the sort of animations that you see in a lot of native mobile apps where you're looking at a ListView, you click on one of the items, and it grows to fill the whole screen. And now you're on the detail screen for that item that you were looking at. But there was this very continuous animated transition that allows you to keep context in your head and all of those sorts of nice things. And this just really helps to bridge that gap between, like, the web often lags behind the native mobile platforms in terms of the experiences that we can build. So it was really interesting to see what they've been able to pull off. The demo is a pretty short video, but it shows a couple of different variations of what you can build with it. And I was like, yeah, these look like cool native app transitions, really nifty. One thing that's very interesting is the actual implementation of this. So it's like you have one version of the page, and then you transition to a new version of the page, and in doing so, you want to animate between them. And the way that they do it is they have the first version of the page. They take a screenshot of it like the browser engine takes a screenshot of it. And then they put that picture on top of the actual browser page. Then they do the same thing with the next version of the page that they're going to transition to. And then they crossfade, like, change the opacity and size and whatnot between the two different images, and then you're there. And in the back of my mind, I'm like, I'm sorry, what now? You did which? I'm like, is this the genius solution that actually makes this work and is performant? And I wonder if there are trade-offs. Like, do you lose interactivity between those because you've got some images that are just on the screen? And what is that like? But as they were going through it, I was just like, wait, I'm sorry, you did what? This is either the best idea I've ever heard, or I'm not so sure about this. STEPH: That's fascinating. You had me with the first part in terms of they take a screenshot of the page that you're leaving. I'm like, yeah, that's a great idea. And then talking about taking a picture of the other page because then you have to load it but not show it to the user that it's loaded. And then take a picture of it, and then show them the picture of the loaded page. But then actually, like you said, then crossfade and then bring in the real functionality. I am...what am I? [laughter] CHRIS: What am I actually? STEPH: [laughs] What am I? I'm shocked. I'm surprised that that is so performant. Because yeah, I also wouldn't have thought of that, or I would have immediately have thought like, there's no way that's going to be performant enough. But that's fascinating. CHRIS: For me, performance seems more manageable, but it's the like, what are you trading off for that? Because that sounds like a hack. That sounds like the sort of thing I would recommend if we need to get an MVP out next week. And I'm like, what if we just tried this? Listen, it's got some trade-offs. So I'm really interested to see are those trade-offs present? Because it's the browser engine. It's, you know, the low-level platform that's actually managing this. And there are some nice hooks that allow you to control it. And at a CSS level, you can manage it and use keyframe animations to control the transition more directly. There's a JavaScript API to instrument the sequencing of things. And so it's giving you the right primitives and the right hooks. And the fact that the implementation happens to use pictures or screenshots, to use a slightly different word, it's like, okey dokey, that's what we're doing. Sounds fun. So I'm super interested because the functionality is deeply, deeply interesting to me. Svelte actually has a version of this, the crossfade utility, but you have to still really think about how do you sequence between the two pages and how do you do the connective tissue there? And then Svelte will manage it for you if you do all the right stuff. But the wiring up is somewhat complicated. So having this in the browser engine is really interesting to me. But yeah, pictures. STEPH: This is one of those ideas where I can't decide if this was someone who is very new to the team and new to the idea and was like, "Have we considered screenshots? Have we considered pictures?" Or if this is like the uber senior person on the team that was like, "Yeah, this will totally work with screenshots." I can't decide where in that range this idea falls, which I think makes me love it even more. Because it's very straightforward of like, hey, what if we just tried this? And it's working, so cool, cool, cool. CHRIS: There's a fantastic meme that's been making the rounds where it's a bell curve, and it's like, early in your career, middle of your career, late in your career. And so early in your career, you're like, everything in one file, all lines of code that's just where they go. And then in the middle of your career, you're like, no, no, no, we need different concerns, and files, and organizational structures. And then end of your career...and this was coming up in reference to the TypeScript team seems to have just thrown everything into one file. And it's the thing that they've migrated to over time. And so they have this many, many line file that is basically the TypeScript engine all in one file. And so it was a joke of like, they definitely know what they're doing with programming. They're not just starting last week sort of thing. And so it's this funny arc that certain things can go through. So I think that's an excellent summary there [laughs] of like, I think it was folks who have thought about this really hard. But I kind of hope it was someone who was just like, "I'm new here. But have we thought about pictures? What about pictures?" I also am a little worried that I just deeply misunderstood [laughs] the representation but glossed over it in the video, and I'm like, that sounds interesting. So hopefully, I'm not just wildly off base here. [laughs] But nonetheless, the functionality looks very interesting. STEPH: That would be a hilarious tweet. You know, I've been waiting for that moment where I've said something that I understood into the mic and someone on Twitter just being like, well, good try, but... [laughs] CHRIS: We had a couple of minutes where we tried to figure out what the opposite of ranting was, and we came up with pranting and made up a word instead of going with praising or raving. No, that's what it is, raving. [laughs] STEPH: No, raving. I will never forget now, raving. [laughs] CHRIS: So, I mean, we've done this before. STEPH: That's true. Although they were nice, I don't think they tweeted. I think they sent in an email. They were like, "Hey, friends." [laughter] CHRIS: Actually, we got a handful of emails on that. [laughter] STEPH: Did you know the English language? CHRIS: Thank you, kind Bikeshed audience, for not shaming us in public. I mean, feel free if you feel like it. [laughs] But one other thing that came up in this video, though, is the speaker was describing single-page apps are very common, and you want to have animated transitions and this and that. And I was like, single-page app, okay, fine. I don't like the terminology but whatever. I would like us to call it the client-side app or client-side routing or something else. But the fact that it's a single page is just a technical consideration that no user would call it that. Users are like; I go to the web app. I like that it has URLs. Those seem different to me. Anyway, this is my hill. I'm going to die on it. But then the speaker in the video, in contrast to single-page app referenced multi-page app, and I was like, oh, come on, come on. I get it. Like, yes, there are just balls of JavaScript that you can download on the internet and have a dynamic graphics editor. But I think almost all good things on the web should have URLs, and that's what I would call the multiple pages. But again, that's just me griping about some stuff. And to name it, I don't think I'm just griping for griping sake. Like, again, I like to think about things from the user perspective, and the URL being so important. And having worked with plenty of apps that are implemented in JavaScript and don't take the URL or the idea that we can have different routable resources seriously and everything is just one URL, that's a failure mode in my mind. We missed an opportunity here. So I think I'm saying a useful thing here and not just complaining on the internet. But with that, I will stop complaining on the internet and send it back over to you. What else is new in your world, Steph? STEPH: I do remember the first time that you griped about it, and you were griping about URLs. And there was a part of me that was like, what is he talking about? [laughter] And then over time, I was like, oh, I get it now as I started actually working more in that world. But it took me a little bit to really appreciate that gripe and where you're coming from. And I agree; I think you're coming from a reasonable place, not that I'm biased at all as your co-host, but you know. CHRIS: I really like the honest summary that you're giving of, like, honestly, the first time you said this, I let you go for a while, but I did not know what you were talking about. [laughs] And I was like, okay, good data point. I'm going to store that one away and think about it a bunch. But that's fine. I'm glad you're now hanging out with me still. [laughter] STEPH: Don't do that. Don't think about it a bunch. [laughs] Let's see, oh, something else that's going on in my world. I had a really fun pairing session with another thoughtboter where we were digging into query objects and essentially extracting some logic out of an ActiveRecord model and then giving that behavior its own space and elevated namespace in a query object. And one of the questions or one of the things that came up that we needed to incorporate was optional filters. So say if you are searching for a pizza place that's nearby and you provide a city, but you don't provide what's the optional zip code, then we want to make sure that we don't apply the zip code in the where clause because then you would return all the pizza places that have a nil zip code, and that's just not what you want. So we need to respect the fact that not all the filters need to be applied. And there are a couple of ways to go about it. And it was a fun journey to see the different ways that we could structure it. So one of the really good starting points is captured in a blog post by Derek Prior, which we'll include a link to in the show notes, and it's using yield_self for composable ActiveRecord relations. But essentially, it starts out with an example where it shows that you're assigning a value to then the result of an if statement. So it's like, hey, if the zip code is present, then let's filter by zip code; if not, then just give us back the original relation. And then you can just keep building on it from there. And then there's a really nice implementation that Derek built on that then uses yield_self to pass the relation through, which then provides a really nice readability for as you are then stepping through each filter and which one should and shouldn't be applied. And now there's another blog post, and this one's written by Thiago Silva, A Case for Query Objects in Rails. And this one highlighted an approach that I haven't used before. And I initially had some mixed feelings about it. But this approach uses the extending method, which is a method that's on ActiveRecord query methods. And it's used to extend the scope with additional methods. You can either do this by providing the name of a module or by providing a block. It's only going to apply to that instance or to that specific scope when you're using it. So it's not going to be like you're running an include or something like that where all instances are going to now have access to these methods. So by using that method, extending, then you can create a module that says, "Hey, I want to create this by zip code filter that will then check if we have a zip code, let's apply it, if not, return the relation. And it also creates a really pretty chaining experience of like, here's my original class name. Let's extend with these specific scopes, and then we can say by zip code, by pizza topping, whatever else it is that we're looking to filter by. And I was initially...I saw the extending, and it made me nervous because I was like, oh, what all does this apply to? And is it going to impact anything outside of this class? But the more I've looked at it, the more I really like it. So I think you've seen this blog post too. And I'm curious, what are your thoughts about this? CHRIS: I did see this blog post come through. I follow that thoughtbot blog real close because it turns out some of the best writing on the internet is on there. But I saw this...also, as an aside, I like that we've got two Derek Prior references in one episode. Let's see if we can go for three before the end. But one thing that did stand out to me in it is I have historically avoided scopes using scope like ActiveRecord macro thing. It's a class method, but like, it's magic. It does magic. And a while ago, class methods and scopes became roughly equivalent, not exactly equivalent, but close enough. And for me, I want to use methods because I know stuff about methods. I know about default arguments. And I know about all of these different subtleties because they're just methods at the end of the day, whereas scopes are special; they have certain behavior. And I've never really known of the behavior beyond the fact that they get implemented in a different way. And so I was never really sold on them. And they're different enough from methods, and I know methods well. So I'm like, let's use the normal stuff where we can. The one thing that's really interesting, though, is the returning nil that was mentioned in this blog post. If you return nil in a scope, it will handle that for you. Whereas all of my query objects have a like, well, if this thing applies, then scope dot or relation dot where blah, blah, blah, else return relation unchanged. And the fact that that natively exists within scope is interesting enough to make me reconsider my stance on scopes versus class methods. I think I'm still doing class method. But it is an interesting consideration that I was unaware of before. STEPH: Yeah, it's an interesting point. I hadn't really considered as much whether I'm defining a class-level method versus a scope in this particular case. And I also didn't realize that scopes handle that nil case for you. That was one of the other things that I learned by reading through this blog post. I was like, oh, that is a nicety. Like, that is something that I get for free. So I agree. I think this is one of those things that I like enough that I'd really like to try it out more and then see how it goes and start to incorporate it into my process. Because this feels like one of those common areas of where I get to it, and I'm like, how do I do this again? And yield_self was just complicated enough in terms of then using the fancy method method to then be able to call the method that I want that I was like, I don't remember how to do this. I had to look it up each time. But including this module with extending and then being able to use scopes that way feels like something that would be intuitive for me that then I could just pick up and run with each time. CHRIS: If it helps, you can use then instead of yield_self because we did upgrade our Ruby a while back to have that change. But I don't think that actually solves the thing that you're describing. I'd have liked the ampersand method and then simple method name magic incantation that is part of the thing that Derek wrote up. I do use it when I write query objects, but I have to think about it or look it up each time and be like, how do I do that? All right, that's how I do that. STEPH: Yeah, that's one of the things that I really appreciate is how often folks will go back and update blog posts, or they will add an addition to them to say, "Hey, there's something new that came out that then is still relevant to this topic." So then you can read through it and see the latest and the greatest. It's a really nice touch to a number of our blog posts. But yeah, that's what was on my mind regarding query objects. What else is going on in your world? CHRIS: I have this growing feeling that I don't quite know what to do with. I think I've talked about it across some of our conversations in the world of observability. But broadly, I'm starting to like...I feel like my brain has shifted, and I now see the world slightly differently, and I can't go back. But I also don't know how to stick the landing and complete this transition in my brain. So it's basically everything's an event stream; this feels true. That's life. The arrow of time goes in one direction as far as I understand it. And I'm now starting to see it manifest in the code that we're writing. Like, we have code to log things, and we have places where we want to log more intentionally. Then occasionally, we send stuff off to Sentry. And Sentry tells us when there are errors, that's great. But in a lot of places, we have both. Like, we will warn about something happening, and we'll send that to the logs because we want to have that in the logs, which is basically the whole history of what's happened. But we also have it in Sentry, but Sentry's version is just this expanded version that has a bunch more data about the user, and things, and the browser that they were in. But they're two variations on the same event. And then similarly, analytics is this, like, third leg of well, this thing happened, and we want to know about it in the context. And what's been really interesting is we're working with a tool called Customer.io, which is an omnichannel communication whiz-bang adventure. For us, it does email, SMS, and push notifications. And it's integrated into our segment pipeline, so events flow in, events and users essentially. So we have those two different primitives within it. And then within it, we can say like, when a user does X, then send them an email with this copy. As an aside, Customer.io is a fantastic platform. I'm super-duper impressed. We went through a search for a tool like it, and we ended up on a lot of sales demos with folks that were like, hey, so yeah, starting point is $25,000 per year. And, you know, we can talk about it, but it's only going to go up from there when we talk about it, just to be clear. And it's a year minimum contract, and you're going to love it. And we're like, you do have impressive platforms, but okay, that's a bunch. And then, we found Customer.io, and it's month-by-month pricing. And it had a surprisingly complete feature set. So overall, I've been super impressed with Customer.io and everything that they've afforded. But now that I'm seeing it, I kind of want to move everything into that world where like, Customer.io allows non-engineer team members to interact with that event stream and then make things happen. And that's what we're doing all the time. But I'm at that point where I think I see the thing that I want, but I have no idea how to get there. And it might not even be tractable either. There's the wonderful Turning the Database Inside Out talk, which describes how everything is an event stream. And what if we actually were to structure things that way and do materialized views on top of it? And the actual UI that you're looking at is a materialized view on top of the database, which is a materialized view on top of that event stream. So I'm mostly in this, like, I want to figure this out. I want to start to unify all this stuff. And analytics pipes to one tool that gets a version of this event stream, and our logs are just another, and our error system is another variation on it. But they're all sort of sampling from that one event stream. But I have no idea how to do that. And then when you have a database, then you're like, well, that's also just a static representation of a point in time, which is the opposite of an event stream. So what do you do there? So there are folks out there that are doing good thinking on this. So I'm going to keep my ear to the ground and try and see what's everybody thinking on this front? But I can't shake the feeling that there's something here that I'm missing that I want to stitch together. STEPH: I'm intrigued on how to take this further because everything you're saying resonates in terms of having these event streams that you're working with. But yet, I can't mentally replace that with the existing model that I have in my mind of where there are still certain ideas of records or things that exist in the world. And I want to encapsulate the data and store that in the database. And maybe I look it up based on when it happens; maybe I don't. Maybe I'm looking it up by something completely different. So yeah, I'm also intrigued by your thoughts, but I'm also not sure where to take it. Who are some of the folks that are doing some of the thinking in this area that you're interested in, or where might you look next? CHRIS: There's the Kafka world of we have an event log, and then we're processing on top of that, and we're building stream processing engines as the core. They seem to be closest to the Turning the Database Inside Out talk that I was thinking or that I mentioned earlier. There's also the idea of CRDTs, which are Conflict-free Replicated Data Types, which are really interesting. I see them used particularly in real-time application. So it's this other tool, but they are basically event logs. And then you can communicate them well and have two different people working on something collaboratively. And these event logs then have a natural way to come together and produce a common version of the document on either end. That's at least my loose understanding of it, but it seems like a variation on this theme. So I've been looking at that a little bit. But again, I can't see how to map that to like, but I know how to make a Rails app with a Postgres database. And I think I'm reasonably capable at it, or at least I've been able to produce things that are useful to humans using it. And so it feels like there is this pretty large gap. Because what makes sense in my head is if you follow this all the way, it fundamentally re-architects everything. And so that's A, scary, and B; I have no idea how to get there, but I am intrigued. Like, I feel like there's something there. There's also Datomic is the other thing that comes to mind, which is a database engine in the Clojure world that stores the versions of things over time; that idea of the user is active. It's like, well, yeah, but when were they not? That's an event. That transition is an event that Postgres does not maintain at this point. And so, all I know is that the user is active. Maybe I store a timestamp because I'm thinking proactively about this. But Datomic is like no, no, fundamentally, as a primitive in this database; that's how we organize and think about stuff. And I know I've talked about Datomic on here before. So I've circled around these ideas before. And I'm pretty sure I'm just going to spend a couple of minutes circling and then stop because I have no idea how to connect the dots. [laughs] But I want to figure this out. STEPH: I have not worked with Kafka. But one of the main benefits I understand with Kafka is that by storing everything as a stream, you're never going to lose like a message. So if you are sending a message to another system and then that message gets lost in transit, you don't actually know if it got acknowledged or what happened with it, and replaying is really hard. Where do you pick up again? While using something like Kafka, you know exactly what you sent last, and then you're not going to have that uncertainty as to what messages went through and which ones didn't. And then the ability to replay is so important. I'm curious, as you continue to explore this, do you have a particular pain point in mind that you'd like to see improve? Or is it more just like, this seems like a really cool, novel idea; how can I incorporate more of this into my world? CHRIS: I think it's the latter. But I think the thing that I keep feeling is we keep going back and re-instrumenting versions of this. We're adding more logging or more analytics events over the wire or other things. But then, as I send these analytics events over the wire, we have Mixpanel downstream as an analytics visualization and workflow tool or Customer.io. At this point, those applications, I think, have a richer understanding of our users than our core Rails app. And something about that feels wrong to me. We're also streaming everything that goes through segment to S3 because I had a realization of this a while back. I'm like, that event stream is very interesting. I don't want to lose it. I'm going to put it somewhere that I get to keep it. So even if we move off of either Mixpanel or Customer.io or any of those other platforms, we still have our data. That's our data, and we're going to hold on to it. But interestingly, Customer.io, when it sends a message, will push an event back into segments. So it's like doubly connected to segment, which is managing this sort of event bus of data. And so Mixpanel then gets an even richer set there, and the Rails app is like, I'm cool. I'm still hanging out, and I'm doing stuff; it's fine. But the fact that the Rails app is fundamentally less aware of the things that have happened is really interesting to me. And I am not running into issues with it, but I do feel odd about it. STEPH: That touched on a theme that is interesting to me, the idea that I hadn't really considered it in those terms. But yeah, our application provides the tool in which people can interact with. But then we outsource the behavior analysis of our users and understanding what that flow is and what they're going through. I hadn't really thought about those concrete terms and where someone else owns the behavior of our users, but yet we own all the interaction points. And then we really need both to then make decisions about features and things that we're building next. But that also feels like building a whole new product, that behavior analysis portion of it, so it's interesting. My consulting brain is going wild at the moment between like, yeah, it would be great to own that. But that the other time if there's this other service that has already built that product and they're doing it super well, then let's keep letting them manage that portion of our business until we really need to bring it in-house. Because then we need to incorporate it more into our application itself so then we can surface things to the user. That's the part where then I get really interested, or that's the pain point that I could see is if we wanted more of that behavior analysis, that then we want to surface that in the app, then always having to go to a third-party would start to feel tedious or could feel more brittle. CHRIS: Yeah, I'm definitely 100% on not rebuilding Mixpanel in our app and being okay with the fact that we're sending that. Again, the thing that I did to make myself feel better about this is stream the data to S3 so that I have a version of it. And if we want to rebuild the data warehouse down the road to build some sort of machine learning data pipeline thing, we've got some raw data to work with. But I'm noticing lots of places where we're transforming a side effect, a behavior that we have in the system to dispatching an event. And so right now, we have a bunch of stuff that we pipe over to Slack to inform our admin team, hey, this thing happened. You should probably intervene. But I'm looking at that, and we're doing it directly because we can control the message in Slack a little bit better. But I had this thought in the back of my mind; it's like, could we just send that as an event, and then some downstream tool can configure messages and alerts into Slack? Because then the admin team could actually instrument this themselves. And they could be like; we are no longer interested in this event. Users seem fine on that front. But we do care about this new event. And all we need to do as the engineering team is properly instrument all of that event stream tapping. Every event just needs to get piped over. And then lots of powerful tools downstream from that that can allow different consumers of that data to do things, and broadly, that dispatch events, consume them on the other side, do fun stuff. That's the story. That's the dream. But I don't know; I can't connect all the dots. It's probably going to take me a couple of weeks to connect all these dots, or maybe years, or maybe my entire career, something like that. But, I don't know, I'm going to keep trying. STEPH: This feels like a fun startup narrative, though, where you start by building the thing that people can interact with. As more people start to interact with it, how do we start giving more of our team the ability to then manage the product that then all of these users are interacting with? And then that's the part that you start optimizing for. So there are always different interesting bits when you talk about the different stages of Sagewell, and like, what's the thing you're optimizing for? And I'm sure it's still heavily users. But now there's also this addition of we are also optimizing for our team to now manage the product. CHRIS: Yes, you're 100%. You're spot on there. We have definitely joked internally about spinning out a small company to build this analytics alerting tool [laughs] but obviously not going to do that because that's a distraction. And it is interesting, like, we want to build for the users the best thing that we can and where the admin team fits within that. To me, they're very much customers of engineering. Our job is to build the thing for the users but also, to be honest, we have to build a thing for the admins to support the users and exactly where that falls. Like, you and I have talked a handful of times about maybe the admin isn't as polished in design as other things. But it's definitely tested because that's a critical part of how this application works. Maybe not directly for a user but one step removed for a user, so it matters. Absolutely we're writing tests to cover that behavior. And so yeah, those trade-offs are always interesting to me and exploring that space. But 100%: our admin team are core customers of the work that we're doing in engineering. And we try and stay very close and very friendly with them. STEPH: Yeah, I really appreciate how you're framing that. And I very much agree and believe with you that our admin users are incredibly important. CHRIS: Well, thank you. Yeah, we're trying over here. But yeah, I think I can wrap up that segment of me rambling about ideas that are half-formed in my mind but hopefully are directionally important. Anyway, what else is up with you? STEPH: So, not that long ago, I asked you a question around how the heck to manage themes that I have going on. So we've talked about lots of fun productivity things around managing to-dos, and emails, and all that stuff. And my latest one is thinking about, like, I have a theme that I want to focus on, maybe it's this week, maybe it's for a couple of months. And how do I capture that and surface it to myself and see that I'm making progress on that? And I don't have an answer to that. But I do have a theme that I wanted to share. And the one that I'm currently focused on is building up management skills and team lead skills. That is something that I'm focused on at the moment and partially because I was inspired to read the book Resilient Management written by Lara Hogan. And so I think that is what has really set the idea. But as I picked up the book, I was like, this is a really great book, and I'd really like to share some of this. And then so that grew into like, well, let's just go ahead and make this a theme where I'm learning this, and I'm sharing this with everyone else. So along that note, I figured I would share that here. So we use Basecamp at thoughtbot. And so, I've been sharing some Basecamp posts around what I'm learning in each chapter. But to bring some of that knowledge here as well, some of the cool stuff that I have learned so far...and this is just still very early on in the book. There are a couple of different topics that Laura covers in the first chapter, and one of them is humans' core needs at work. And then there's also the concept of meeting your team, some really good questions that you can ask during your first one-on-one to get to know the person that then you're going to be managing. The part that really resonated with me and something that I would like to then coach myself to try is helping the team get to know you. So as a manager, not only are you going out of your way to really get to know that person, but how are you then helping them get to know you as well? Because then that's really going to help set that relationship in regards of they know what kind of things that you're optimizing for. Maybe you're optimizing for a deadline, or for business goals, or maybe it's for transparency, or maybe it would be helpful to communicate to someone that you're managing to say, "Hey, I'm trying some new management techniques. Let me know how this goes." [chuckles] So there's a healthier relationship of not only are you learning them, but they're also learning you. So some of the questions that Laura includes as examples as something that you can share with your team is what do you optimize for in your role? So is it that you're optimizing for specific financial goals or building up teammates? Or maybe it's collaboration, so you're really looking for opportunities for people to pair together. What do you want your teammates to lean on you for? I really liked that question. Like, what are some of the areas that bring you joy or something that you feel really skilled in that then you want people to come to you for? Because that's something that before I was a manager...but it's just as you are growing as a developer, that's such a great question of like, what do you want to be known for? What do you want to be that thing that when people think of, they're like, oh, you should go see Chris about this, or you should go see Steph about this? And two other good questions include what are your work styles and preferences? And what management skills are you currently working on learning or improving? So I really like this concept of how can I share more of myself? And the great thing about this book that I'm learning too is while it is geared towards people that are managers, I think it's so wonderful for people who are non-managers or aspiring managers to read this as well because then it can help you manage whoever's managing you. So then that way, you can have some upward management. So we had recent conversations around when you are new to a team and getting used to a manager, or maybe if you're a junior, you have to take a lot of self-advocacy into your role to make sure things are going well. And I think this book does a really good job for people that are looking to not only manage others but also manage themselves and manage upward. So that's some of the journeys from the first chapter. I'll keep you posted on the other chapters as I'm learning more. And yeah, if anybody hasn't read this book or if you're interested, I highly recommend it. I'll make sure to include a link in the show notes. CHRIS: That was just the first chapter? STEPH: Yeah, that was just the first chapter. CHRIS: My goodness. STEPH: And I shortened it drastically. [laughs] CHRIS: Okay. All right, off to the races. But I think the summary that you gave there, particularly these are true when you're managing folks but also to manage yourself and to manage up, like, this is relevant to everyone in some capacity in some shape or form. And so that feels very true. STEPH: I will include one more fun aspect from the book, and that's circling back to the humans' core needs at work. And she references Paloma Medina, a coach, and trainer who came up with this acronym. The acronym is BICEPS, and it stands for belonging, improvement, choice, equality, predictability, and significance. And then details how each of those are important to us in our work and how when one of those feels threatened, then that can lead to some problems at work or just even in our personal life. But the fun example that she gave was not when there's a huge restructuring of the organization and things like that are going on as being the most concerning in terms of how many of these needs are going to be threatened or become vulnerable. But changing where someone sits at work can actually hit all of these, and it can threaten each of these needs. And it made me think, oh, cool, plus-one for being remote because we can sit wherever we want. [laughs] But that was a really fun example of how someone's needs at work, I mean, just moving their desk, which resonates, too, because I've heard that from other people. Some of the friends that I have that work in more of a People Ops role talk about when they had to shift people around how that caused so much grief. And they were just shocked that it caused so much grief. And this explains why that can be such a big deal. So that was a fun example to read through. CHRIS: I'm now having flashbacks to times where I was like, oh, I love my spot in the office. I love the people I'm sitting with. And then there was that day, and I had to move. Yeah, no, those were days. This is true. STEPH: It triggered all the core BICEPS, all the things that you need to work. It threatened all of them. Or it could have improved them; who knows? CHRIS: There were definitely those as well, yeah. Although I think it's harder to know that it's going to be great on the way in, so it's mostly negative. I think it has that weird bias because you're like, this was a thing, I knew it. I at least understood it. And then you're in a new space, and you're like, I don't know, is this going to be terrible or great? I mean, hopefully, it's only great because you work with great people, and it's a great office. [laughs] But, like, the unknown, you're moving into the unknown, and so I think it has an inherent at least questioning bias to it. STEPH: Agreed. On that note, shall we wrap up? CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeee!!!!!!! ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

2022-01-11 Weekly News - Episode 130Watch the video version on YouTube at https://youtu.be/BkIKAlDLFkQ Hosts: Gavin Pickin - Senior Software Developer for Ortus SolutionsEric Peterson  - Senior Software Developer for Ortus SolutionsThanks to our Sponsor - Ortus SolutionsThe makers of ColdBox, CommandBox, ForgeBox, TestBox and almost every other Box out there. A few ways  to say thanks back to Ortus Solutions: Like and subscribe to our videos on YouTube.  Subscribe to our Podcast on your Podcast Apps and leave us a review Sign up for a free or paid account on CFCasts, which is releasing new content every week Buy Ortus's Book - 102 ColdBox HMVC Quick Tips and Tricks on GumRoad (http://gum.co/coldbox-tips) Patreon SupportWe have 37 patreons providing 97% of the funding for our Modernize or Die Podcasts via our Patreon site: https://www.patreon.com/ortussolutions.News and EventsUpcoming Ortus Webinar - cbwire + Alpine.js with Grant CopleyJanuary 28, 2022 - 11:00 AM CT - Central Time (US and Canada)In this webinar, Grant, lead developer for cbwire, will showcase how to build modern, reactive CFML apps easily using very little JavaScript.Register today: https://www.ortussolutions.com/events/webinars Log4j UpdatesLog4j-2.17.1 patch released. CommandBox images updates with the latest log4j patched jarsAdobe updated have an updated technote: https://helpx.adobe.com/coldfusion/kb/log4j-2-17-0-vulnerability-coldfusion.html Other libraries like Spreadsheet-CFML have updated as well.Note: ​Log4j2 Support in lucee 5.3 is coming along for 5.3.9‘Elephant Beetle' Lurks for Months in NetworksThe group blends into an environment before loading up trivial, thickly stacked, fraudulent financial transactions too tiny to be noticed but adding up to millions of dollars.This beetle adores Java. The group is “highly proficient” with Java-based attacks and often targets legacy Java apps running on Linux machines – primarily, the Java-based web servers WebSphere and WebLogic – as a means of initial entry to a target environment, the researchers explained. Beyond that, Elephant Beetle even deploys its own, complete Java web application to do the gang's bidding on compromised machines that are, meanwhile, chugging along, running legitimate apps.https://threatpost.com/elephant-beetle-months-networks-financial/177393/?fbclid=IwAR0ytUYx0IOxiNXIUE1jHvqDV0ltP_hBf7XCdEyLEYHfSaKadwf01xPkHLI Adobe WorkshopsMore Adobe #ColdFusion Workshops announced, lead by Damien Bruyndonckx2 dates announced:February 2, 20229.00 AM - 4.30 PM CET1.30 PM - 9.00 PM ISTMarch 09, 20229.00 AM - 4.30 PM CET1.30 PM - 9.00 PM ISThttps://cf-workshop.meetus.adobeevents.com/ AngularJS EOL'ed 12/31/2021As AngularJS is faced with an uncertain future, many teams are searching for answers to the current hot topic: if you are using AngularJS, do you continue to maintain your AngularJS applications or do you migrate your applications to another framework? This is not an easy (or cheap) question to answer.In this article, we'll go over some of the reasons why you should consider migrating your AngularJS applications, and some ideas on how to plan and budget for a successful migration.https://www.thisdot.co/blog/why-you-should-consider-migrating-from-angularjs-to-vue CFCasts Content Updateshttps://www.cfcasts.com Just ReleasedInto the Box 2021 are now all FREE - https://cfcasts.com/series/into-the-box-2021 Coming soonInto the Box LATAMSend your suggestions at https://cfcasts.com/supportConferences and TrainingVueJS Nation ConferenceOnline Live EventJanuary 26th & 27th 2022Register for Freehttps://vuejsnation.com/ More conferencesNeed more conferences, this site has a huge list of conferences for almost any language/community.https://confs.tech/Blogs, Tweets and Videos of the WeekTweet - Adam Cameron - TIL something new about CFOUTPUTI cannot go into details of why this is a good find, but I was unaware that one can pass an encoding algorithm name like `` (and a bunch of others) which will automatically escape the values in `#expression#`. Didn't know that.https://cfdocs.org/cfoutputhttps://twitter.com/adam_cameron/status/1480624980668915716https://twitter.com/adam_cameronTweet - James Moberg - Microsoft taking log4j stuff seriously.While performing some #coldfusion unit testing to identify #log4j exploit attempts (that my WAF may miss), I had to obfuscate the test strings or @msftsecurity would instantly quarantine & report the script. It's good to see that Microsoft is taking this seriously. #cfmlhttps://twitter.com/gamesover/status/1476347523245694984https://twitter.com/gamesoverBlog - James Moberg - Log4j Exploit Pattern Detection Using ColdFusion/CFMLHere are my initial attempts at trying to detect Log4j exploit attempts that may make it past our WAF/service provider protections. While our WAF stopped requests from Trend Micro's Log4j Tester, obfuscated requests made it through. At time of testing, Azure wasn't blocking requests. I had to be a little careful with the script as Windows kept instantly quarantining the CFM files and prevented ColdFusion from executing the template.2021-12-29: Updated rules based on Google Cloud article to additionally block rmi, ldaps & dns (in addition to stripping whitespace.)https://dev.to/gamesover/log4j-exploit-pattern-detection-using-coldfusioncfml-4l17 Tweet - Zac Spitzer - Show some love for the VS Code CFML ExtensionAwesome to see some activity on the vscode-cfml extension, a new minor release coming soon. If you use it, please show some love and star the repo https://github.com/KamasamaK/vscode-cfml #lucee #coldfusion #cfmlhttps://twitter.com/zackster/status/1476206001384828929https://twitter.com/zacksterBlog - Ben Nadel - Building An API Client With The fetch() API In JavaScriptIn my continued effort to modernize this blog, I'm thinking about trying to replace the jQuery library with more modern techniques. I don't personally have anything against jQuery; but, by replacing it, I'll have an opportunity to learn newer - and hawter - JavaScript APIs (at the expense of robust browser support). Case in point, I want to replace the jQuery.ajax() method with a fetch()-based API client. I've never used the fetch() method before; so, this will be an exciting exploration!When consuming an API, you should always create an API client…https://www.bennadel.com/blog/4179-building-an-api-client-with-the-fetch-api-in-javascript.htm Blog - Ben Nadel - Showing A Comment Preview As You Type On This BlogSince comments, on this blog, are authored using Markdown (and ColdFusion), there is a delta between what you write in the intake form and what is eventually rendered in the HTML. Much of the time, this delta is expected; however, if you have small errors in your markdown syntax, you can end up with HTML that does not reflect what you had intended to publish. To help narrow the gap between input and output, I've added a comment preview functionality to this blog.https://www.bennadel.com/blog/4178-showing-a-comment-preview-as-you-type-on-this-blog.htm Blog - Ben Nadel - Mitigating Cross-Site Scripting (XSS) Attacks With A Strict Content Security Policy (CSP) In ColdFusion 2021As I continue to evolve my blogging platform, bringing it into the modern ColdFusion era, I'm trying to catch up on best practices. Of course, I've always used SQL query parameterization to block SQL injection attacks. And, I use encodeForHtml() and encodeForHtmlAttribute() in as many places as is feasible. And when converting user-provided markdown into HTML, I use the OWASP Anti-Samy project to sanitize the HTML output. But, one thing I've never had is a Content Security Policy (CSP). A CSP is yet another line-of-defense in the war against Cross-Site Scripting (XSS) attacks.CAUTION: I Am Not A Security Experthttps://www.bennadel.com/blog/4176-mitigating-cross-site-scripting-xss-attacks-with-a-strict-content-security-policy-csp-in-coldfusion-2021.htm Blog - Ben Nadel - preserveCaseForStructKey Doesn't Work Inside Application.cfc In Adobe ColdFusion 2021Over the New Year's holiday, I ran into a rather peculiar behavior regarding the preservation of key-casing and the serializeJson() function in Adobe ColdFusion 2021. It appears that the serialization setting for preserveCaseForStructKey doesn't apply to code that resized physically within the Application.cfc life-cycle event handlers. To demonstrate this, we can setup a simple demo in which we serialize data across the event handlers and then dump-out the response:https://www.bennadel.com/blog/4175-preservecaseforstructkey-doesnt-work-inside-application-cfc-in-adobe-coldfusion-2021.htmBlog - Ben Nadel - Posting Comments Using Reply Emails And Postmark's Inbound Streams In ColdFusion 2021I've been a very happy Postmark customer for the last decade. Their SMTP and API services make sending and receiving emails absurdly simple. And, their Inbound webhooks allow you to treat Postmark as a reverse proxy that transforms inbound email delivery into API calls (webhooks) against your own servers. I've been wanting to use this feature on my blog forever; however, I was always afraid that it would lead to massive abuse. That said, in response to a recent spam attack, I was forced to add comment moderation. Which means, I can safely start playing with reply-based comment posting using Postmark's Inbound stream!https://www.bennadel.com/blog/4174-posting-comments-using-reply-emails-and-postmarks-inbound-streams-in-coldfusion-2021.htm Blog - Ben Nadel - Centralizing The Error Response Handling For My ColdFusion BlogIf you've noticed that my blog has been quite quiet over the last few weeks, it's because I've dedicated December to modernizing and upgrading my blogging infrastructure. The refactoring has been extensive, to say the least; and, on the list of things that I've wanted to for a long time is centralizing my error response handling in my ColdFusion code. It took me several days to find, factor-out, and normalize my errors; but, I think I have it at a point that I can easily refine and evolve going forward.https://www.bennadel.com/blog/4173-centralizing-the-error-response-handling-for-my-coldfusion-blog.htm CFML JobsSeveral positions available on https://www.getcfmljobs.com/Listing over 256 ColdFusion positions from 111 companies across 131 locations in 5 Countries.7 new jobs listedContract - CFML Developer at Remote - United States Jan 11https://www.getcfmljobs.com/viewjob.cfm?jobid=11407Full-Time - Software Developer - ColdFusion at Overland Park, KS - United States Jan 11https://www.getcfmljobs.com/jobs/index.cfm/united-states/Software-Developer-ColdFusion-at-Overland-Park-KS/11406Full-Time - IT Engineer Applications (Coldfusion developer/admin) : 19-0.. - United States Jan 11https://www.getcfmljobs.com/jobs/index.cfm/united-states/IT-Engineer-Applications-Coldfusion-developeradmin-1905340-at-Portland-OR/11405Full-Time - Senior Coldfusion Developer |LATAM| at Colon, PA - United States Jan 11https://www.getcfmljobs.com/jobs/index.cfm/united-states/Senior-Coldfusion-Developer-LATAM-at-Colon-PA/11404Full-Time - ColdFusion Developer at Virtual, US - United States Jan 10https://www.getcfmljobs.com/jobs/index.cfm/united-states/ColdFusionDev-US/11403Full-Time - Remote Software Developer (Cold Fusion) at Mississauga, ON - Canada Dec 31https://www.getcfmljobs.com/jobs/index.cfm/canada/Remote-CFDev-at-ON-CA/11401Full-Time - Fresh Software Engineer ( For ColdFusion Only) at Ahmedabad,.. - India Dec 30https://www.getcfmljobs.com/jobs/index.cfm/india/Fresh-Software-Engineer-For-ColdFusion-Only-at-Ahmedabad-Gujarat/11402 ForgeBox Module of the WeekJSON-DiffBy Scott SteinbeckAn ColdFusion utility for checking if 2 JSON objects have differencesCall JSONDiff.diff to get a detailed list of changes made between the JSON objects.Call JSONDiff.isSame to get a simple boolean true or false.https://www.forgebox.io/view/jsondiffVS Code Hint Tips and Tricks of the WeekExcel ViewerIf you're working with data, there's a high chance that you'll also encounter an excel spreadsheet in some form. Excel Viewer makes it easy to deal with excel data in your VS Code editor by formatting long and comma-separated strings into a tabled format. This can work wonders for your .csv, .tsv, and .tab extensions.https://marketplace.visualstudio.com/items?itemName=GrapeCity.gc-excelviewerFunny link: https://twitter.com/dawntraoz/status/1479490317766336518Thank you to all of our Patreon SupportersThese individuals are personally supporting our open source initiatives to ensure the great toolings like CommandBox, ForgeBox, ColdBox,  ContentBox, TestBox and all the other boxes keep getting the continuous development they need, and funds the cloud infrastructure at our community relies on like ForgeBox for our Package Management with CommandBox. You can support us on Patreon here https://www.patreon.com/ortussolutionsNow offering Annual Memberships, pay for the year and save 10% - great for businesses. Bronze Packages and up, now get a ForgeBox Pro and CFCasts subscriptions as a perk for their Patreon Subscription. All Patreon supporters have a Profile badge on the Community Website All Patreon supporters have their own Private Forum access on the Community Website https://community.ortussolutions.com/Patreons John Wilson - Synaptrix  Eric Hoffman Gary Knight Mario Rodrigues Giancarlo Gomez David Belanger Jonathan Perret Jeffry McGee - Sunstar Media6 Dean Maunder Joseph Lamoree Don Bellamy Jan Jannek Laksma Tirtohadi Carl Von Stetten Dan Card Jeremy Adams Jordan Clark Matthew Clemente Daniel Garcia Scott Steinbeck - Agri Tracking Systems Ben Nadel Mingo Hagen Brett DeLine Kai Koenig Charlie Arehart Jonas Eriksson Jason Daiger Jeff McClain Shawn Oden Matthew Darby Ross Phillips Edgardo Cabezas Patrick Flynn Stephany Monge Kevin Wright Steven Klotz You can see an up to date list of all sponsors on Ortus Solutions' Websitehttps://ortussolutions.com/about-us/sponsors★ Support this podcast on Patreon ★

We welcome Power Platform expertise in the form of Two Alex! Alex Dupler and Alex Powers both work at Microsoft. The organization they work for and their first names aren't the only thing that these two share! They also both have a lot of experience with and passion for the Power Platform. Alex Powers is a member of the Power BI Customer Advisory Team (PBICAT), and Alex Dupler is a Program Manager focused on BI & Data Infrastructure. These guys know data! Follow Two Alex: Alex Dupler Twitter Alex Powers Twitter Two Alex Youtube Channel References in this Episode: Raw Data with Brad and Kai from Agree Media Episode Timeline: 7:00 - The woes of Stack Ranking, Data storage options, more fun with names! 22:00 - What draws you to data?, The value (and drawbacks) of Excel, and the path to Power BI 36:40 - Two Alex-similarities and differences, Rob tells a story of someone crossing him, and one of Rob's favorites-the art of using BI to drive action 59:00 - When BI and IT collide, the 2 Alex's non-traditional BI path, the value of being an expert even if you aren't THE expert 1:16:00 - Two Alex LOVE helping people, is there value to documentation?, knowing the Business portion of Business Intelligence 1:37:00 - Advertising performance discussion Episode Transcript: Rob Collie (00:00:00): Hello friends. Today's guests are Alex Powers and Alex Dupler, collectively known as Two Alex. They're both Microsoft employees in very different roles, but both have their feet rooted firmly in the power platform. You might be familiar with their YouTube show. I interact with them primarily on Twitter and a little bit on Reddit. And this is the first time I've had really any conversation of length with Alex Powers. And it's the first time I've had any conversation at all with Alex Dupler. And no surprise here, really, really cool people. We had a lot of fun, really dynamic and inspiring, interesting conversation that wound through a number of topics, including some show favorites, like non-traditional backgrounds, and closing the action loop, and imposter syndrome. We talk about how years ago Alex Powers wrote a review of my book that called out the intermission in the book and how, what a delight that was at the time to read. Rob Collie (00:00:57): And that leads to a conversation about how we're always essentially at our own little intermission in our expertise curve. You're always in the middle somewhere. And if we started doing metrics on this podcast, you'd probably find that this one ranked very highly in opinions expressed per minute. Ooh. What could he mean? Let's get into it. Announcer (00:01:21): Ladies and gentlemen, may I have your attention please? Announcer (00:01:25): This is the Raw Data By P3 Adaptive podcast. With your host, Rob Collie, and your cohost Thomas LaRock. Find out what the experts at P3 Adaptive can do for your business. Just go to p3adaptive.com. Raw Data by P3 Adaptive is data with the human element. Rob Collie (00:01:49): Welcome to the show. Alex Powers and Alex Dupler. How are you today, gentlemen? Alex Dupler (00:01:54): I'm doing great. It's great to chat with you. Alex Powers (00:01:56): Rob, back-to-back meetings. I'm glad that Luke found us some time here. I was so hesitant about this podcast, just cause I love listening to it. I was like, "I don't know, should I do it? Should I do it? Should I do it?" Rob Collie (00:02:08): The answer is yes, you should do it. Alex Powers (00:02:10): I appreciate Alex D and Rob just pulling us all together. Yeah. Rob Collie (00:02:13): We've already backstage a little bit been laughing about this. So let's bring it out to the front stage. The two of you combined, what do we refer to you as? Are you the Two Alex's? Or something different? Alex Dupler (00:02:23): So we learned separately from our wives that the correct pluralization is two Alex. Rob Collie (00:02:30): See, I just don't buy this. I still think Alex's. I mean, we could get really funky and say, Alexi. Tom LaRock (00:02:36): I was going to say, that's what I think. Yeah, Alexa, Rob Collie (00:02:39): But I mean, think of it this way. There's fish, and that's plural. But even there, there's still fishes, which refers to different species of fish. Yes. I think. Is that what it is? Alex Powers (00:02:51): Yeah, that's right. Fishy. Yes. Rob Collie (00:02:53): I don't know. So the two Alex, are you guys seriously going to go by that now? Is that going to be the new thing, or? Alex Dupler (00:02:58): Well, the YouTube channel is called Two Alex. Rob Collie (00:03:01): How'd the two of you come to know one another? Is it just like, oh, we're both working in data and we're both named Alex. So you're like, you see each other from across the room and your eyes meet across the internet? Alex Powers (00:03:10): I would say across the internet, for sure there. Just because he's up in Redmond, I'm kind of located in St. Louis, Missouri. From there it was kind of this, I think natural, just both being active in the community. Alex D you can keep me honest there, I'm sure we were connecting on Twitter a little bit there before, definitely in the subreddits. One of my earliest memories of was, Hey, this thing isn't folding. And I was like, oh my gosh, it's Power Query. I've got to tackle this. I've got to answer this question. Reddit is where I hang out at. I would say from there that's when we really started coming chat more and more, but Alex D I'll let you kind of tell your side of the story. Alex Dupler (00:03:43): Yeah. Yeah. My recollection is that the first time we interacted with each other, where it wasn't just some random poster on Reddit, was side conversations on Microsoft teams within Microsoft. There's some internal discussions where salespeople can get their question answered and sometimes the questions are interesting. And so, yeah we had some side conversations. Plus back then, when Alex wasn't on the product team, he didn't always have full visibility into the roadmap. And so we would chat on the side about what we would do with the roadmap. Not that we would do a better job, just a different job. Rob Collie (00:04:19): Yeah, I get you. Yeah, I understand. I understand. What are the two of your roles at Microsoft today? Alex Dupler (00:04:25): I work for Microsoft advertising. We're the organization that sells the ads that go on Bing, as well as some partner websites like Yahoo search and AOL search and stuff like that. And I work in the business function of the sales org. So I do BI for a sales team. And it just happens to be at Microsoft, and that influences the technologies that we use. IPM are like data warehouse and big cube stuff. Rob Collie (00:04:50): Cool. We're going to have to circle back to that for sure. And Alex P what are you up to these days? Alex Powers (00:04:56): Yep. So senior program manager on the Power BI customer advisory team, so PBI CAT for maybe those out in the community. I'm called as kind of that last bastion of hope sometimes, where I'm not very close to the solution, not close to the architecture, just come in and fix it. Where Alex D, he owns the solution, he owns the finished product. That's a line of visibility that I completely lose in my day to day. But you get variety, you get to do different things. Some days it's maybe a DAX challenge, next day I'm writing C#. The next day, I'm writing kind of new report, kind of clicky, clicky, draggy droppy experiences. So a vast rich tapestry of Power BI. Rob Collie (00:05:32): So you're on the CAT team with a number of people that have already been on the show, right? Adam Saxton, Casper, Chris Webb. You're part of that crew? Alex Powers (00:05:41): Yep. Rob Collie (00:05:41): I hear that that crew continues to expand, it's like this great gravitational attractor. It's like just hoovering all of these people. Let's just have it on the record. Does the Power BI CAT team have ambitions of world takeover? Alex Powers (00:05:53): Every day. And I think what you're seeing right now is a lot of formality. Community contributors, experts, decades of experience. They're now turning into bosses, they're now turning into managers. So they're getting further away from the technology and kind of now being people managers. I'm enjoying our livestream here because Rob is laughing. He's like, oh, I know that exact feeling. Rob Collie (00:06:14): I do. I do, right. I got a request today from some media outlet to interview me for Power BI tips. And I'm like, gosh folks, I'm probably not that person. You want to talk about strategy, okay, that's different. But I have gotten further and further. I still build some Power BI stuff for sure, for my own purposes. But I don't have that day to day, like, this is my life. That's not how my day goes anymore. I'm back to the management game after years of being out of it. Yeah. Growing a company tends to keep you out of the actual hands-dirty data trenches that started the whole thing. Alex Dupler (00:06:52): Well, if you ever start stack ranking, that's when it's going to be time to sell it. Rob Collie (00:06:56): True story, stack ranking was the reason why I actually stopped being a manager at Microsoft. At one point, I just said, I'm done applying the system for you. I was sick of it. And I understand it's gone now. I found out the hard way that stepping back from a management position didn't just relieve me of that stack ranking thing that I found immoral and uncool. It also took me out of a lot of the important conversations. I just didn't have nearly the input or influence that I had before. And that was hard. If I was still at Microsoft today, my career at Microsoft would still have suffered like a multi-year setback because of this era where I just said, I'm done. I know that at this point, the whole stack rank thing has been gone for a long time, but it was still a number of years later after I left that it still persisted. No, we're never going to do that. We're never going to play lifeboat with human beings. I mean, it really sucked, right? Basically, if you built a really good team, either by recruiting or by development or both, you were punished for it. Alex Dupler (00:08:04): Yeah. Apply this to Alex's team. You want to stack rank Chris Webb and Casper and Adam? Tom LaRock (00:08:09): I will. I'll do it. Rob Collie (00:08:11): Which one of them gets told that they had a terrible year? Right? Tom LaRock (00:08:16): I'd be happy to do it. Rob Collie (00:08:20): Hey, listen. As long as we put that kind of phenomenal power in the hands of a benevolent tyrant, like Tom, it's perfectly safe. What could go wrong? Alex Dupler (00:08:29): That is what they said about solar winds. Tom LaRock (00:08:34): My first criteria, having known them for many years, is Jaeger consumption. So we'll just start with that and work our way down the stack. Rob Collie (00:08:44): Which way are we going to sort that list though? We sort it largest to smallest, or smallest to largest? I mean, I could see that list being sorted either way. Tom LaRock (00:08:50): We'll try it both ways and see how it shakes out. Rob Collie (00:08:53): Yeah. I mean, it could be like a honeypot, right? Put some Jaeger out there, see who goes for it? You're getting the 3.0. We won't be doing any of that, thankfully. Now, Alex P, you were previously in a different role, right? Alex Powers (00:09:10): Yes. So, here at Microsoft less than two years, came in through the premier field engineer side to support, really had a blast there kind of proactive engagements training, probably train like 4,000 Tableau users on the Power BI. So just like the grind of doing it day in, day out, talking about the product, I just absolutely loved that. Transitioned to kind of field sales roles. There it's competitor competes, a lot of disinformation where they're saying, well, Power BI can never do this. What do you mean it can't do that? Here's an article. Here's me, kind of the whizzbang demo. That's probably where I got my hyperlink chops for those that kind of know me on the community. Alex Powers (00:09:44): This is the good and bad of the pandemic is like, Hey, we're making some career advancements, we're working long hours, whatever else it may be. A lot of my goal whiteboard over here was, Hey, I want to be on the Power BI CAT team. Had that visibility, just kind of did those grinding over the fall and winter months when we're all stuck inside. But I'm sorry, Thomas. I don't know how good I would be at the Jaeger thing, just because I don't have that peer connection. I haven't met my coworkers. So that's tough for a lot of people that I think are just making career jumps during the pandemic right now. Rob Collie (00:10:16): Yeah. I mean, it's weird. I live in a completely altered reality where we've been a hundred percent remote, I've been a hundred percent remote for 11 years. Probably more closer to 12, actually. Our company was a hundred percent remote from the beginning, basically out of necessity. To me, it's shocking how many people who've been at this company for a long time have never met each other face to face. We did a gathering, a team gathering in 2019. We didn't do one in 2020. I don't remember why we didn't do that. We haven't done one this year, either. We're hoping to maybe do one in 2022. We've hired so many people in the last year that there's like half the company that I haven't ever been in person with. Alex Powers (00:11:02): It's tough. Rob Collie (00:11:03): It's different, isn't it? Alex Powers (00:11:04): Yeah. I think it was like the good meme the other day where it's like, Hey, here's your company culture, it's just like an empty cubicle. And it's like, well, people don't even have that anymore. It's just, here's your new job, here's your new email. Log in, welcome to the company. Great friend of mine, Mark Beedle, I know kind of joined T3 adaptive. I love that he's like, this is where I want to be. I think of the P3 of the past, where you take the group, I think, up to Seattle or some of the different areas. And then it was like, oh wow, they're all getting together and having fun. You know, I tried applying for the job, but unfortunately your Excel file was corrupt and I couldn't pass the test. Rob Collie (00:11:36): Oh, I see. I see how this [crosstalk 00:11:38]. Alex Powers (00:11:38): Yeah, what happened with that, Rob? Rob Collie (00:11:39): I don't know, man. Alex Powers (00:11:40): That's really what I wanted to corner you on today. Rob Collie (00:11:43): That might've been part of the test, Alex. Alex Powers (00:11:45): I literally thought it was, that responded that way. I was like, I don't know if they're testing me with a corrupted file. Alex Dupler (00:11:50): Yeah. You need to have mastered the Open XML format of the Excel file, and be able to track down the corruption in the Power Query. Rob Collie (00:12:00): I saw a joke or a meme on some social media a couple of years ago about cast iron, the hipsters with their cast iron and how you have to take care of it and everything like that. And then after you're done with that, you have to dry it in the sun for 24 hours. And someone goes, 24 hours? And they go, yeah, if you're not willing to go to the Arctic, you don't deserve cast iron. So it's like that kind of test. Yeah. Alex Dupler (00:12:23): We beat the crap out of our cast iron, it's just fine. Rob Collie (00:12:26): Okay. And now Alex Dupler. You're working in BI in the advertising wing, within Bing but also the affiliated networks like Yahoo and things like that. And so you mentioned that you're in charge of the data warehouse and you're in charge of, you said big cube. Alex Dupler (00:12:42): Yeah. Rob Collie (00:12:43): For a year I worked on Bing, and maybe this is a completely different dataset than what you actually end up caring about, but the state of the world back then was there was this giant distributed commodity hardware database system, data storage system called Cosmos. Alex Dupler (00:12:58): Yep. Rob Collie (00:12:58): One of the world's foremost write-only data stores. It was amazing at storing data. You could never get anything useful out of it. There was only one person in the entire organization, named Jamie Buckley, who was capable of actually running queries against this thing. And so if you wanted any information whatsoever about what searches were being run and things like that, yeah sure, you could try to write a query against this thing. And what would happen is you'd get syntax error after syntax error after syntax error, and then eventually you kick off a query and it wouldn't give you any errors. And you're like sweet. And it would run and run and run and you go away and you'd come back like a day and a half later and then you'd get a runtime error. Alex Dupler (00:13:38): Yeah. And when it works, you get a CSV. And so we still have that. I think when I was getting trained on it, which they said it had something like 5% of the world's data in it. Cause it's not just Bing, it's X-Box and a whole bunch of stuff. It's this really cool exabyte scale thing. But nobody knows how to use it, partially because it uses scope scripts, which the only commercial product they've ever been used in is the ATLS gen one analytics feature, which was not a successful product and is being deprecated. And so you can't hire people that know how to use it, there's just like a bunch of vendors that have learned it. And I can't write it either. Also, I don't know if this was your experience, but the engineers are allergic to writing documentation. It's got these petabyte sized tables with 400 columns and there'll be a data dictionary and it doesn't have any descriptions of any of the columns. Rob Collie (00:14:33): This does match my experience, yes. Alex Dupler (00:14:35): So we use that some, we also have other partners. I mean, it's a huge organization. We just missed getting touted in the quarterly earnings as having crossed $10 billion for the last fiscal year. I think the public number is like 9.95 or 9.5 billion. Yeah so it's a real business, even though the market share is pretty small. It turns out advertising is just a really, really good business. So we take a bunch of data out of there, and then also from partners that take data in there, and put it all in Databricks and make it available to folks that way. And we love Databricks because our analysts, they can come with whatever skills they have, and they can be successful on day one. Because they don't have to learn SCOPE or KQL or whatever. Alex Dupler (00:15:22): They can write Python, they can write R, they can write SQL, there's a cube so they can do Power BI, they can do Excel. They can do whatever they want, all in the same data. Now, if they want to do things that are super fancy, they may have a hard time using the cube. So they got to write something. Rob Collie (00:15:41): Yeah. Alex Dupler (00:15:42): But if you're a PM owning a project, you can drag and drop in that cube all day long and have a good time. And then the other thing that we like about the setup we have is, with the data in Data Lake, our partners that have their own generous Azure budgets, they're not running queries against our server. Whereas if we put it in Synapse or SQL, when they want to query our data, we're paying for this compute. But here they just mount it onto their own compute system, and they pay for it. And that's great. We like when other people pay to use our data. Rob Collie (00:16:15): So it's funny, I actually expected that the answer to the question was going to be, oh no, no, we fixed all that. That original system is completely straightened out, it's got a much more human friendly interface. But it turns out that you just have other systems that are human friendly. And those things have to... on the order of one-time investments to figure out how to populate those things from the great Oracle that is Cosmos. Alex Dupler (00:16:41): Yeah that's largely true. I mean, in Cosmos, they've implemented the ATLS APIs. So you can mount data in Cosmos directly to a Spark engine and do stuff that way, if you want. Yeah. Basically that's how they've done things. You will not be surprised to learn that Microsoft likes to reuse names. Maybe you've seen this phenomenon before in the word power, but yeah. Cosmos, the internal exabyte scale data platform is not the same as Cosmos DB, the Azure product, which is for, I couldn't even describe it. It's for, like, everything. Rob Collie (00:17:19): Yeah. I mean, there's only so many cool nouns. And furthermore, the set of cool nouns in the world is further refined by the ones that computer scientists gravitate to. So you end up with a really small population of words. And the chances... It's like the pigeonhole principle from math, right? You need 450 names, you only have 300 words. So you're screwed. And so you end up with things like the word dashboard being repurposed to mean something kind of niche in Power BI. That's one that I wish we could get a do-over on. And you know, I'm a sinner. I named some things poorly in my day. I'll give you an example. When PowerPivot V1, and actually several versions of PowerPivot, at least in 2010, there were those two drop zones, extra drop zones in the pivot table field list, for slicers. Rob Collie (00:18:11): Cause Amir insisted that we make slicer layout really easy as opposed to tedious. So we had these extra drop zones, and one drop zone put the slicers down the left-hand side of the pivot table and one put them across the top of the pivot table. What did I name those two zones? Horizontal and vertical slicers. For years after that, when I taught that product to classes, they go, oh, what does a horizontal slicer do that's different than a vertical slicer? And I just sit there with my head in my hands like, it should have been left and top, Rob. Why did you... Previous Rob, why were you so nerdy and stupid at the same time? Left and top. Alex Dupler (00:18:48): Well you see, in an indimensional cube, there are some things that are horizontal and some things that are vertical. Once you understand what the tubal is, it'll all make sense. Rob Collie (00:18:59): Yes. So let's go back to basics and... Yeah, no. It's just left and top. Yep. These are what you call own goals. Can't make these things up. It's even funnier, by that point in my career when I made that mistake, I was already kind of like this rabid high priest of naming. Like, we should be better. And here I was in the course of delivering those sermons, just committing tremendous sins out the back of the church. It's just like. Alex Dupler (00:19:31): Yeah, it turns out we should be better in, oh crap, I got an hour before this presentation, what am I going to call this thing? Those are two overlapping states of being. Rob Collie (00:19:41): You know, people's hearts are in the right place. So I still think that the two of you probably might've gravitated toward each other just a little bit, maybe like 1% more, because of the shared first name. Can I be allowed like an extra 1% gravity on this? Alex Powers (00:19:54): 99. I mean, a lot of Alex's within Microsoft that are doing Power BI, we've all kind of banded together. Rob Collie (00:19:59): There's like an Alex crew? Alex Powers (00:20:01): Hell yeah. Big time. There's multiple Two Alex's, too. Rob Collie (00:20:04): As we've established, once you get above like three or four Alex, it's suddenly Alex's. That's when it becomes plural. Alex Dupler (00:20:10): There are at least two Alex's working at Microsoft in the Power BI ecosystem that are smarter than either of us. Rob Collie (00:20:17): Well I mean, going back to something we were talking about earlier, every single person, every single consultant at P3 is a hell of a lot better at Power BI than I ever was. I can't even argue that it's like, oh, I'm off my peak. It's not that at all. They were always going to be much, much better. It's very humbling. Like in the real sense of the word, when you sort of get put in your place. Alex Powers (00:20:40): Is this like a time thing, Rob? Cause I feel it too. It's like the early days, Power Pivot and Power Query were something like, I'm digging, I'm learning all of these things. And then like everything else is kind of passing me by and it's like, yeah I'll catch up to that at some point. And I see the wild stuff that people are doing nowadays, like, I don't know what nights and weekends they're spending learning this product, but I'm working twice as hard and I'm still not catching up. Alex Dupler (00:21:00): Yeah. I was watching the other demo the other day. And he was talking about how you should have your report and your data model in two separate PBIX's. This was Mike Carlo. It was a great demo. But then he was like, and to make this really easy, what we're going to do is we're going to edit the PBIX. And I was like, hold on a second. You can't do that. That's not allowed. Rob Collie (00:21:22): [crosstalk 00:21:22] Like actually hacking the file? Like he got into the file structure? Alex Dupler (00:21:25): Yeah. Rob Collie (00:21:26): I do love me some file hacking. For me, I think it's not necessarily a question of time. It's actually that the universe has returned to its default state with respect to me. Which is, the whole time I worked at Microsoft, in all the years I was on the engineering teams, I worked with plenty of people who were super technical, but also enthusiastically technical. When VB.Net came out, and ASP.NET, I had some colleagues that just dove into that. They loved it, it was the most amazing thing. And I just could never... I was still at that point going like, okay, well I learned how to write my VBA, and I'm sticking with it. That's where the frontier of my coding, actual procedural coding, is still VBA six. Rob Collie (00:22:09): For some reason, DAX and data modeling, as technical tools go, DAX and data modeling really, really spoke to me. Like I freaking loved it and still do, still do to this day. And Excel formulas are kind of the same thing, right? This is the handful of exceptional technologies that really seem to appeal to my nervous system, and none of the others do. And by the way, M is another example that does not appeal to me at all. Alex Powers (00:22:38): I am the opposite. I love M. Rob Collie (00:22:39): Really? You love M? Alex Powers (00:22:40): I love, love, love. Hell yeah. Rob Collie (00:22:42): You're not my species then, you're something completely different. Alex Dupler (00:22:47): So I think one of the big things that drew me to data modeling, so there's a lot of constraints. And with programming, it's like, there's such an open world. Like the only programming I could ever really get my head around was VBA. That's where I started. You didn't have to have a big, complicated object model. There was just Excel. That was your object model. And it made everything so much easier. And you're like, okay, well, what I'm trying to do is move these cells to those cells. And with data modeling, especially in Power BI, it's like, well, I need one column for these relationships. And I need these relationships to flow in one direction. The constraints make it a much more manageable problem, but also opens up room for more creativity. Rob Collie (00:23:30): I agree. And also VBA comes with a macro recorder, the world's greatest set of training wheels. It's like, if I want to build an app from scratch, I can't like act out like pantomime what the app will do, and have something spit out code for it. Alex Dupler (00:23:48): Draw some stick fingers in Figma and just drag them around, and get some code from that. Rob Collie (00:23:51): Yeah. It's like, mock up the UI in Balsamiq or something, or Vizio, and then start mashing on the screen with your finger and say, okay. And then speaking out loud, what should happen at that... there's no macro recording for actual software developers. Alex Dupler (00:24:04): I think we got to tell Charles that, that's what he's got to do with his AI driven power apps development. Rob Collie (00:24:09): Yeah. It's we need to turn this into a LARPing thing, right? You just act out the application in the real world with these cameras... Holo lens. There it is. We've solved the world's problems. Take that for low code development. Alex Powers (00:24:26): Well, I like how Power Automate's now watching your points and clicks, and generating flows for you. Rob Collie (00:24:32): See, I didn't know that it did that. Alex Powers (00:24:33): Oh yeah. You're training the machine. You don't even have to write the code anymore. It's like, oh, automation is here. It's really here now. Rob Collie (00:24:41): It's always a feel good moment to meet a fellow VBA 6-er. The world used to be lousy with us. We were just everywhere. It's kind of a dying art. Office has got this new JavaScript API, Office Scripts. That's incredible. Again, in theory. I haven't touched it, because it's not reaching out and grabbing me by the eyeballs. I'm tempted though. It's sort of like, oh, a new VBA six and they have a macro recorder and I'm like, okay, maybe, maybe. This might be the way I learn JavaScript someday, is Office Scripts. Alex Dupler (00:25:09): Yeah, that sounds like how I'd learn it, except Excel is dead to me. I mean, I use Excel for note taking and PM stuff, but data work, I don't use it. Because first of all, Power Query is the way to go. And in Excel, when you have Power Query over, you can't save the Excel file. Rob Collie (00:25:28): Really? Alex Dupler (00:25:29): Yeah, Power Query takes a lock, like a lot of the old school windows. And you can't get back to the main- Rob Collie (00:25:34): Modal window. Alex Dupler (00:25:35): Yeah. So you can't save, you can't refer back to the data. You can't open stuff. And it's not like Excel ever crashes when you're working with lots of data. So saving, it's not that important. And if you want to say, first you have to evaluate your queries or set them to disable load. But if you've already loaded some, if you do something to disable load, it destroys the cells. I just said, I'll do it all in Power BI. No more Excel. Not because there's anything wrong with Excel. It's just that that user experience was just so unacceptable to me. I lost so many hours of work. Tom LaRock (00:26:10): Wait, what do you mean, not that there's something wrong... Clearly there's something wrong with Excel. Alex Dupler (00:26:14): Yeah. Rob Collie (00:26:15): Alex, you're cut from a cloth that I understand very well. Your sarcastic cynicism is, ooh, it speaks to me. Yeah, we've come to the right place. Even I, team Excel guy, I am really on team Excel. I haven't written any DAX in the Excel environment in several years. It's all Power BI, all the time now. Alex Dupler (00:26:38): The other big thing is why would you want to write DAX in an environment that you can't schedule to refresh? Unless you don't have pro licenses, like... Alex Powers (00:26:47): Hold on, let me challenge you now. Here we go, this is a little taste of Two Alex. So I love Ken Puls, where he's saying, Hey, I don't want the heavy weight of Power BI. If I can do as much as possible within Excel, be it Power Query or even Power Pivot. I would agree that. Alex Powers (00:27:03): Be it kind of power query or even power pivot. I would agree that the development experience is severely lacking. That's not to say that the power BI side is the best in the world, obviously Dax studio, et cetera. But I would much rather take a lightweight application over a heavy one every day and then just import that data model into power BI when I'm ready. Rob Collie (00:27:19): To me, the primary value of these technologies in Excel is as an on-ramp to the power BI universe for the authors. Tomorrow's power BI authors are today living in Excel. And the reason, I've said this multiple times on this podcast of multiple different people at Microsoft, but the reason why I'm, I don't want to use like the passive aggressive version of the word disappointed. Let's use the completely neutral version of the word disappointed. The reason why I'm disappointed that there isn't more investment there is because that is the gateway drug, and as a universe, as a community, like we really need to care about bringing those new people on. And that's where they're going to come to. To tell those same people, "No, put Excel down and start learning this in a completely new environment," their immune systems reject that because they've been sold a million times on the idea that something's going to replace Excel. They know better by now. Rob Collie (00:28:23): But no one in that category, like the V lookup and pivot route, none of them resist the idea of there being crazy, powerful new versions and features of the things that they're already doing. You get them 48 hours into that new world, and they're more than happy to switch to the power BI environment. They're excited about it. Those same people who would have rejected it 48 hours before. You got to take them on that path and this thing not getting the love that I think it deserves, I understand it's from the perspective of our real production environment is the power BI environment. I get that. But the on-ramp, they are doing some things about that, even things that I didn't know, because they're targeted at people who don't know about this stuff and I already do. Brian, when he was on the podcast, was talking about how they're using machine learning, advanced clippy generation seven, to detect the people who should be interested in this stuff and sort of pointing them to power BI. And there actually was really good uptake of that. That feature didn't fire for me because I don't use V Lookup or regular pivot tables anymore. Alex Dupler (00:29:23): That's almost exactly the journey that I went on. Like many of your guests, I did not go to school for power BI. I actually, I went to school for chemistry and I worked as a chemist for a couple of years. I was doing lab work and I was very bad at lab work. I mean, I understood the chemistry, but I would break glassware that was expensive and stuff like that. Which when you make $15 an hour, breaking expensive glassware is a good way to get in trouble. So I was like "Okay, well I grew up in a very computer centric family. Maybe I can do some of this Excel stuff." And so I was doing visual basic, and we were doing some dashboards, like operational reporting. And I had Excel in this company. I loved the people there, but it was not a successful business. We had maybe a hundred thousand dollars in revenue per employee with high CapEx, because we had these big, expensive instruments that we had to buy and chemicals and all sorts of stuff, lots of HVAC. So there was not enough money to pay people to live in Seattle, so every office license was a battle. Alex Powers (00:30:31): Wow. Alex Dupler (00:30:31): I was looking at, okay, what can I do with Excel 2007, because we had some of that I think we had enough licenses, but it didn't really check. So we didn't really pay too much attention. But then I was like wanting to use power query because I had sort of discovered it was easier, but I couldn't. So I was like, "Okay, how do I get this macro to run as a service so that I can refresh these dashboards on these dowels that we bought second hand?" Rob Collie (00:31:01): You know, if it weren't for the a hundred thousand dollars of revenue per employee, at a certain point, that story sounded like season two of Breaking Bad. The HVAC, the cap ex, oh you mean a hundred thousand dollars per employee per week? Okay. Alex Dupler (00:31:18): No, no, no, per year. Rob Collie (00:31:19): Then it's meth. Alex Dupler (00:31:20): Yeah, no. So this is the environmental testing industry. And the way it works is your tests have to be defensible to the EPA. So the EPA puts up a spec and says the test needs to be done this way. And when it's done, it has these parameters in terms of statistical reusability. And that means that one lab's product is a commodity compared to the other lab's product. And so you can't get outside profits. All you can do is compete on service and price. And if you take a high CapEx business and bolted to professional services, you're not going to get good margins. Rob Collie (00:31:59): Unintended consequences of everything, right? Alex Dupler (00:32:01): Yeah. I mean, Rob, can you imagine your business, if you are charging professional services business model, but you bolted on a whole, huge amount of consumable costs to every delivery? Rob Collie (00:32:14): Yeah. It sounds like we can safely not choose the wine in front of me. Alex Dupler (00:32:19): That's how I first encountered the 2017 standalone web, maybe it was 2016. The first time power BI was split out. I was doing office 365 admins and I got like a push notification. I was like, "This is cool." And I built some stuff and I showed it to my manager and he was like, "That's cool. How much is it?" "$10 a month." "Nope, can't afford it." And that's when I started looking for jobs anywhere where they had good Excel people. Rob Collie (00:32:46): Yeah, and to put that in perspective, this is the punchline to many jokes when people ask us how much it is. We go, "It's $10 a month per user." We all just start laughing. Like, "Oh my God, it's like stealing. It's so cheap." Alex Dupler (00:32:58): I didn't even have that many users. Rob Collie (00:33:02): I mean, this might be $30 a month. You know, like, nope. Alex Dupler (00:33:06): No. Rob Collie (00:33:07): It's like when we first moved to Cleveland back in the day, it was right in the middle of the financial crisis. We were looking at real estate and everything. And there were houses for sale in Cleveland for $10,000, like $10,000. And I started laughing. I'm like, imagine the deal going down. This house has been on the market for 180 days at $10,000. And you come in and say, "Look, I've got a cash offer. I'm willing to pay asking price. But the grill out back? You need to leave it." And the owner's like, "Mmmmm." Alex Dupler (00:33:43): My wife's best friend lives in Cleveland and they recently bought a house. And so we looked at a bunch of Zillow listings. I'm like, "Oh man, we could pay cash. Move next door." And they're sort of north of the Cleveland Clinic, that super nice neighborhood up in there. I was like, "Oh yeah, we could buy a very nice house, but our family is not there." Also, have you looked at the weather? It's not Seattle. Rob Collie (00:34:05): No, it's not Seattle, but I'll tell you what, here's an interesting description of statistics. When we moved to Cleveland, it wasn't because we wanted to, it was because basically my kids had been taken to Cleveland and so we're trying to console ourselves. We're like, "Okay, well, okay. It's going to be colder. There's going to be snow. Okay, okay. But at least it isn't going to be as overcast." And then we looked it up and Cleveland has more overcast days per year than Seattle. So we were like, "Damn, that sucks." However, it turns out that the definition of overcast days is very, very, very important. Because like an overcast day in Cleveland is like 75% of the sky is covered by clouds. That's an overcast day. At no point in time ever is Cleveland under a one mile thick, oppressive blanket that starves you, where you don't even have any idea where the sun is in the sky. So number of days is one of those misleading statistics. Total amount of oppressive cloud cover needs to be a different statistic. Trust me, there's more sun in Cleveland on an ongoing basis than there is in Seattle. Those winter and fall months, man, those are rough. Alex Dupler (00:35:16): That's not the part that bothers me. I was born and raised in Seattle. It's the shoveling your driveway in March, that part of it. Rob Collie (00:35:24): You could just be the delinquents that we were and just get a four wheel drive vehicle and say, "Screw it." Alex Powers (00:35:31): You don't shovel in March. After February, you don't shovel. It's in my contract. I don't shovel after March 1st. That's it. Because it's going to melt. Alex Dupler (00:35:40): Eventually. Alex Powers (00:35:40): It'll melt by the end of the month. Rob Collie (00:35:43): By the end of the month. Alex Powers (00:35:44): By the end of the month, it'll be gone. The rainstorm's coming. Sunshine's going to happen. I ain't shoveling. No, I put that in my contract years ago. Rob Collie (00:35:53): Cleveland's where I learned the rule, we do not adopt dogs that require walking. Alex Powers (00:35:58): Yes. Rob Collie (00:35:58): They need to be able to go out in the backyard and come back in. I fell so many times on ice. I eventually got, they're like crampons essentially. Alex Dupler (00:36:06): Yak tracks? Rob Collie (00:36:08): Yak tracks, that's what they are. Yak tracks or something else. You can't intentionally slip on yak tracks. It's crazy. But without them, just any day now broken hip. Alex Dupler (00:36:19): Our friends that lived there, they just got a golden retriever. We met the puppy when we were visiting with them this summer. Very cute, but I think they have some of those walks in their future. Rob Collie (00:36:29): So you start looking for a job, that's what led you into Mount Redmond? Alex Dupler (00:36:34): Yeah, I literally went looking for jobs good with Excel in Seattle. I found a contract position into Microsoft, making sure that the salespeople were assigned to the right customers and got paid on the right quota because advertising the agency model, it makes that much more complicated. Because we were in this model where we'd try and keep all the customers of an agency with the same salesperson which makes a lot of sense, especially when you're the underdog and you have relatively few sales resources, you get more leverage. But customer's change agencies all the time, have no respect for our compensation cycles, and so it was quite the nightmare. Rob Collie (00:37:15): Yeah, I love that. Like, so here's how we'll define the world for our benefit, "Oh world, you did not get the message. World, please don't change. Don't have your own things going on." Yep, that sounds like a software engineering problem from the nineties back before the industry kind of got wiser. So you start talking about the show. It seems like with a format like that, it's got to wander, which is what our show does too, by the way. So what are some of the most entertaining or valuable corners that you found yourself wandering into over time? Alex Powers (00:37:48): I'm still excited with our first episode where we talked about kind of beyond the desktop where it's no longer just development in [inaudible 00:37:56] desktop. It now almost takes like five different applications to build something at scale, which is like a good and bad thing. Well, you're getting more tools, seeing new things faster, more performing, et cetera, but why do I need 10 tools? Can we solve that within the desktop application? And we just had a really good conversation, a lot of attendees there, providing their own thoughts. And it kind of comes back to like this overwhelming feeling of learning power BI it's. Like I have to learn 20 new things all the time, learning, learning, learning. It's just never ending. That was my key episode. Alex Dupler (00:38:26): I agree. I mean, I think that's been the central theme of the whole show. I mean, we did that first episode and then we've talked, we've had the same conversation about these tools in so many different contexts. What are the different ways to do dev ops in power BI? What are different ways to measure how you're doing in terms of the effectiveness of your models? And so all of that is sort of external to the desktop application. Alex Powers (00:38:52): I think the best part, too, is that we're not from these traditional backgrounds of 20 years of BI or 20 years of kind of dev ops. We're learning this real time, sharing our experiences of, Rob, I think you call us power users or business users that find these tools, that get empowered by this technology. That is the seat in which we sit in. Hey, I found Excel 2010 power query add in 2013, 2016. I'm fighting with my IT admins. Can you please just upgrade to the next monthly release that will solve all my problems? Where Alex D is on the other series fighting tooth and nail for a 2007 license. It's kind of funny to hear that conversation. Rob Collie (00:39:32): $10 a month. We need those charity commercials like Sally Struthers used to do. This is Alex Dupler. For $10 a month, less than the price of a cup of coffee, you could get him an O 365 license. Alex Dupler (00:39:50): Yeah. So we ended up getting some E3 licenses and some E1 licenses, which meant I could work in power query, not using my personal license, but using the company's license. And then when I tried to share it with my coworkers, they only had E1. They couldn't use desktop. They had to use power query online or Excel online. And there was no power query online. And so even once we sort of modernized, we installed like a windows server 2012 and it was already 2015 and I was okay, this is our modernization. Alex Powers (00:40:26): So Rob, I'm going to steal one of your quotes here if you don't mind. Rob Collie (00:40:30): No, please do. We have an open source quote license at P3. Alex Powers (00:40:35): Well, I'll buy you a 2007 Excel license too, if I have to. Rob Collie (00:40:39): Fantastic. Alex Powers (00:40:39): But one of the items you had said a long time ago, I believe it was either in your book or maybe some of the video recordings you used to do in the studio with a nice button up shirt. You said, "There are two types of people when it comes to technology, those who can see the possibilities and bring about change and those who are about to be affected by it." And I always look at this and I look at things like had kind of talked about with the Excel users who haven't even gotten to this experience yet. There is still somebody out there today that is using Excel 2007 and their employer or their this, their that, or whatever their situation they're red is like, "I just see this little rectangle. It hasn't changed. Why do you want me to go invest in any of this stuff?" Like how often are you still seeing this? Rob Collie (00:41:17): Anecdotally in our public classes, which I haven't taught in a while, I've taught one as recently as let's say two years ago. And when I taught public classes for P3, I still stubbornly insisted on using the Excel version of this stuff to teach. Again, because of that onboarding effect. Alex Powers (00:41:34): Yep. Rob Collie (00:41:34): I think I was the only one left at our company that was still stubbornly doing that and I wasn't bothering to argue with others and whatever. So I did this for years, probably the first one of those classes I taught would have been like in 2011. So fighting with different versions of Excel, all the different students showed up with, for a long time, that was like a quarter of the class. The instructions for the class were very clear, show up with this version or don't bother. And they'd show up and no, they had a version, didn't even have power pivot and couldn't get power pivot. And so it was so bad for a while, we would bring spare laptops. If we traveled to another city, we'd be lugging spare laptops with us and they'd just be there ready to go like the hot swap with a student. That problem really went away though. I reached the point where I'd survey everybody at the beginning of class, "What version of Excel are you on," or whatever. And everyone, every single person in the class would be on the basically some version of recent 365. Rob Collie (00:42:32): I really do think that the person who's trapped on 2007 or hell even 2010 or 2013, they're out there, but they are really a tiny, tiny fraction of the world now. Whereas that used to be an overwhelming problem. So it's really testament to how successful O 365. Alex Powers (00:42:52): I would agree. Rob Collie (00:42:53): It's like, I was kind of like cynically betting against it forever, like the tortoise and the hare. Like I woke up one day and that's the world. The world is O 365. I think everyone's on the modern, not everyone, but it rounds to everyone, is on the modern wave of the tools. But they're still shocked when I show them, when we show them, "Did you know that this is in here?" And they're just like, "What?" Alex Powers (00:43:19): How is that in here? Rob Collie (00:43:20): They get angry because they start to realize how much of their life they have lost by not being told. Alex Powers (00:43:27): What I was always seeing was people had to live in two worlds. Like I went to some of the Excel boot camps, Michael Alexander, absolutely transformed on my personal laptop. I'm having the best time of my life in these three-day boot camps. I'm loving, loving, loving. At the very end though, I have to go back to work on Monday. I saw what could be, and I'm now back to what is. And it's just very difficult to kind of live in that middle space. For those that are still out there and listening to this, Hey, look at your surroundings. Hopefully Office 365 is coming within your organization. But if not, kind of like Alex D's story, I just went looked somewhere else. I saw the future that was coming, and I bet it all myself and I went for it. And I think that me and him both kind of share those stories, too. Alex Dupler (00:44:08): Inside of Microsoft, in my little corner of the Microsoft that most people in Microsoft don't even know about, I put together a class that I've given a couple of times, Modern Excel for Managers. And basically I would just show them power query and X Lookup. We didn't even talk about Dax. But just to like get them thinking like, "Hey, if you're doing some annoying thing in Excel, maybe there's a couple ways to make it a little bit better. Maybe you've never even seen the formula bar before." I had one person that I worked with who I was like, I didn't handle it very well at first. But she was like, "Can you add these numbers together for me?" And I was like, "Yeah." Alex Powers (00:44:52): Just a standard Excel formula bar? Is that what you're talking about? Alex Dupler (00:44:55): She was like, "Can you show me the difference between these two numbers?" "I can do that for you, but here, let me come over here and show you something." Rob Collie (00:45:04): So there was another program manager on being, because I was such an Excel, I'd come from the Excel team, I'm such an Excel zealot, that all someone had to do was say that they needed Excel help and I was there. Alex Powers (00:45:17): Oh yeah. Rob Collie (00:45:18): This person, they developed a habit of having me do all of their Excel work for them. This is one of my peers. And then of course passing off the work as their own. Fine, I wasn't that career minded, really. Six months after this is when I volunteered to no longer be a manager. So climbing the corporate ladder wasn't some voracious appetite of mine. So, okay, fine, fine. I knew what was happening, but I was still okay because the Excel problems were so fun. Keep them coming. Then one day this person asked me for Excel help. And there were these two columns of numbers. And this person had subtracted column two from column one to create column three and then added up column three to get the difference. Alex Powers (00:46:04): I'm waiting for the reveal, because there's a big story here and I'm loving it right. Rob Collie (00:46:09): I said, "Well, you know, you could have just summed column one and column two, and then taken the difference between the two sums." And they said, "But wouldn't the answer be different?" There was this moment of silence. I'm looking. I'm looking at them. They're looking at me. I'm looking at them. They're looking at me. At that moment, they realized that they couldn't use me anymore because I was now dangerous. I now knew that they didn't know math. They didn't just not know spreadsheets, they didn't know math. They were exposed. This person is now an executive at Google. Tom LaRock (00:46:48): This person being the executive at Google. I have no doubt probably doesn't know math. However, as somebody who uses technology and knows that data can be dirty and whatnot, I would actually, if it was me Rob, I would say do it both ways and make sure the answers match. Because you know what? We both seen it where it didn't work out. Rob Collie (00:47:10): That's true. But like when you see all the numbers in front of you, you physically see them all. You've got access. There's nothing hidden going on here. Oh, by the way, Tom, what's your degree in again? Tom LaRock (00:47:21): I have a master's in mathematics from Washington State University. Rob Collie (00:47:23): Masters, yep. Yeah, the masters in math is what allows Tom to say, "I'm not sure." Tom LaRock (00:47:29): Now hold on. Hold on. We've seen it. We've seen it. Rob Collie (00:47:35): There's a name for this. It's like the distributive property or associative property or something. There's some property that we learned in middle school. Tom LaRock (00:47:41): See, that's math with paper and pencil. Now we're talking about using Excel for math. So the tool, there could be something like, "Hey wait," and that's why we tell you, "well, just do it both ways." Even Wayne Winston would probably say, "Yeah, well have two columns. They should match. If they don't match..." Rob Collie (00:47:58): No, no he would not, not in this particular case. Tom LaRock (00:48:01): You're right. He wouldn't. Rob Collie (00:48:02): Every time I tell this story, someone always sort of like takes a sympathetic stance towards the antagonist and I end up feeling like a heel. Tom LaRock (00:48:09): You shouldn't. You shouldn't. Rob Collie (00:48:12): But come on. Tom LaRock (00:48:15): I'm with you. I have no doubt that they don't know math because I come across the same people. I do. Rob Collie (00:48:22): It's think it's the intersection of all of those things, That I was being used the whole time. Tom LaRock (00:48:27): Yes. Rob Collie (00:48:29): Which I had kind of made my peace with. But then on top of that, this incredibly aggressive ladder climber, the kind of person who really was kind of like willing to climb over the bodies of their colleagues. There's something delicious about, even though I was the rube in the whole story up until a certain point. I was being taken advantage of and I knew it. But even me in that situation, there was that moment of just like jaw dropping dumbstruck, like just looking at this person going, "Oh my God, you did not do that." Alex Powers (00:49:09): I'm going to lift us up from the depths here of career and everything else. I thought you were going to take us into that they didn't use cell references, which I've seen people type in column A plus column B's value in an equals. And it's like, "Well, why didn't you just do A1 plus B1?" Mind was blown. So I love that those moments still exist and you find them out in the wild every once in a while. And it's not massive warehouse MPP processing, et cetera, et cetera, that everyone's like, "Oh, this is the," I call it the BI bubble. Everyone's out here living in the BI bubble, writing C sharp, doing tabular and coding, blah, blah, blah. People are still excited about the very simple things that technology can achieve for them. Alex Dupler (00:49:56): My in-laws, they own a brewery in Rinton and they make great beer. I offered to help my mother-in-law with some of her bookkeeping that she does on inventory. And she was showing me how she was doing it. And she was like, "Okay, I get these numbers in Excel. And then I get out my calculator." And I was like, "Okay, let me show you how you can do this differently." And I showed her. She was like, "No, no, that's going to be too hard. I'm going to stick with the calculator." And I was like, "Okay, that's fine." Alex Powers (00:50:20): I still get the, "I don't trust Excel, so I double check with the calculator." Rob Collie (00:50:25): My first exposure to that, I was in college. I was working for a construction management firm that was building the new chemistry building on Vanderbilt campus and I was working in the management trailer. I was sort of all purpose ... we called me the lackey. I would just do whatever anybody needed. Sometimes I'd go out in the building and take measurements for things or whatever. But most of the time, I was just doing paperwork and stuff. They turned over the spreadsheet for this latest change order to the project to Vanderbilt management. And the price tag, it was an Excel spreadsheet and it had a column of values that were summed and there was a number at the bottom of it. And I remember the guy Tony who worked for Vanderbilt going, "Well, someone's going to have to double check these numbers. We can't just pay this contract." And my boss was just looking at him going, "Come on. That's what the spreadsheet is for is for doing that." And Tony's like, "Yeah, yeah, yeah, yeah, I know. But still, I mean, we can't just pay this number." I can understand that stance a little better, anyway, I just looked like a giant meany. But remember. This was someone who was taking advantage of me. Alex Powers (00:51:36): I agree. I agree. Alex Dupler (00:51:38): One of the things that I wanted to touch on in this conversation, something you've brought up a lot, which is going from BI to taking action within the report. And I got to tell you, this concept terrifies me. As a BIPM, I'm terrified of it. And I totally agree that the value is there, but in the BI space, we are really bad at testing. And if I think about how going from, Hey, I've got a report and these are the numbers to someone's going to click a button and it's going to change something in a system of record, the level of quality and testing goes up and I think really threatens the quick solution thing that you've also talked about is your bread and butter of like, Hey, we're going to do this really fast and it's going to blow your mind. But if I got to throw all that testing in there to make sure I don't blow up your source system instead, I don't know how those two things coexist. Rob Collie (00:52:39): Yeah. that's a fair point. I mean, for a moment there, when you were saying the taking action part and this terrifies you, before I understood the subtleties of your point, I was going to make the joke like, "Oh, you want this to be like the psychic hotline. It's for entertainment purposes only. Please don't use this report to take any action." Alex Dupler (00:52:57): It does make my job easier, I will admit, but it is a little bit more nuanced than that. Rob Collie (00:53:02): Okay, okay, fine. So anyway, I still managed to sneak the joke in there without ... it's not a joke at your expense because your point is different. Okay, there's escalating versions of this with escalating versions of responsibility and test implications and things like that. So you can just start with report design and working backwards from the types of action, your constituents, the users of your report. In classes what I would teach this concept on the end of the last day, as sort of like a religious sermon. I would encourage people to think of the users of their reports as each one of them sitting in front of like some gigantic cartoonish bat computer looking thing with these giant oversized 1960s, pop art colored buttons and they're labeled things like "open more stores" or "adjust hours of locations" or "increase head count, reduce head count" or "change product mix" or whatever. It's actually kind of interesting, when you imagine e ... Rob Collie (00:54:03): ... mixed or whatever, right? It's actually interesting when you imagine it that way to give it that physical manifestation, it actually becomes a little bit easier, for me anyway, to imagine what these people can do, because every role in a company really has a finite number of actions that they can take. Now, finite in terms of their categories of actions. It's certainly infinite when you get into the details of what are you going to do. And if you start to think of them from that perspective and you think, okay, what I should do is build reports that advise them or at least are helping inform them as to which control they should touch on their dashboard and directionally which way they should move it. Rob Collie (00:54:45): And it sounds like not that important of a trick, not that powerful of a trick, but if you actually apply that methodology faithfully, you end up with a vastly different portfolio of reports that you have built. Even I, very often, don't live up to my own principle in this regard. Because it's so easy. It's so seductively easy. It's the path of least resistance to grab all the data, load it up, make the model, that's fun, and then it's like flowing downhill. It's just like, oh, this is the easy and fun part, right? And then inevitably, you just start slapping together some reports. And those reports, in some ways, are just exposing the coolness of what you've built. Rob Collie (00:55:29): Now, that still leads to some very, very useful things. That's mind-blowingly better than what you ended up with in the old dark ages of Excel or even traditional BI. But I mean, oh my God, we were just talking about it on the last podcast. Some of the things that I have seen in the world that were supposed to be helping people make decisions were better described as their opponents in the process. This report was something that you had to fight to figure out what you should do at your dashboard. Rob Collie (00:55:59): So even before we start with any sort of actual software integration and taking action and things like that, that's a really, I think, important religion to develop. And again, when you're at your best, your absolute gold medal in the Olympics celebrated by the world best, maybe 30% of your output will live up to this. You just can't, you can't execute that way all the time. It's really, really hard. But it's software development. You are building software when you're building reports. You should have the same sort of mindset, if you can, as the Power BI team has when they sit down to design a new feature in their software. Alex Dupler (00:56:38): I totally agree. One of the questions I've been asking a lot, because I've been working on reports for the salespeople to take to the customers is, what is the conversation you're going to have with the customer? Not, what is the metric, but how does this fit into the conversation? And part of this is because my superpower and my career is going and building tools for the thing I used to do. And I think a lot of BI people come from that, where they were in the business and they were doing a thing, they just started making the reports for that thing. And somewhere along the line, they either work away from it for too long or they solve those problems. They had to learn how to make reports for something they haven't done for years. And I think that's a difficult transition and one I've been going through. Alex Dupler (00:57:26): But yeah, learning how to ask questions of the user, because they're not just going to tell you... what they tell you isn't what they need. You have to learn how to learn from what they say, what they actually want. Rob Collie (00:57:42): Yeah, it's a fine art. And by the way, when you've been in "BI", building the same reports for a long time, generally speaking, looking backwards anyway, those reports also sucked because they were constrained by what was possible at the time. And so they were never very ambitious. And most of those reports amounted to... A lot of times they just amounted to the data dump import that's used for something else. It's just, again, it's the opponent. It's better than nothing, but it's meager, meager help. And suddenly you're given this brand new tool set that's capable of so much more. Rob Collie (00:58:22): And unfortunately what I see a lot of times, when you give Power BI to an IT department, they go, "Oh hot damn, the new SSRS." This is the new reporting services. We're going to use it like reporting services. Load that big one flat wide table and pigeonhole it as visualization. It's just like, "Come on." Alex Powers (00:58:45): I'm telling you my favorite DAX is always written from the IT department. It's just written like a massive sequel statement, 400 lines. None of it makes any sense. It's like, "Can we just calculate, maybe another table here or there." Alex Dupler (00:58:59): The folks coming from the IT department, the one thing they do have going for them is that they did learn to format their code. Sometimes people coming from the Excel world, they learned that they can't format their code. And so I'm not sure that I would agree that the worst DAX comes from the IT department. Because you take a DAX statement and you take all the formatting out, and you've just made it 10 times worse. Alex Powers (00:59:21): From readability, yeah, I would agree. Rob Collie (00:59:24): I gave a talk one time where I asked the trick question of, what's the number one programming language in the world? And

It's not every day that you can hear a great conversation with the Head of Product of Excel. Brian Jones sits down with us and talks about the past, present, and very promising future of Excel. Rob and Brian go way back, and the stories and laughs abound!   Check out this cool World Orca Day Excel template for kids!   Episode Timeline: 4:00 - Brian's lofty title is Head of Product at Excel, The importance and magic of Excel, and people's a-ha moments with Excel 20:25 - The difficulty of not seeing your projects' impact on the world and how the heck does Bluetooth fit into the story?!, Rob and Brian reminisce with some funny conference stories 32:00 - The XML file format and some very neat XML tricks that everyone should know about 51:25 - The birth of the Excel Web App and Rob can't believe some of the things that Brian's team has done with Excel 1:05:00 - How to onboard the Excel, VLOOKUP, and Pivot crowd into data modeling and Power BI, and the future of Excel most certainly includes the Lambda function (maybe!) Episode Transcript: Rob Collie (00:00:00): Hello, friends. Today's guest, Brian Jones, head of product for this thing you might've heard of called Microsoft Excel. Brian and I go back a long way. We were both youngsters at Microsoft at the same time, and we both worked on some early features of Office apps, and we're friends. Really, really have sincerely warm feelings about this guy, as you often do with people that you essentially grew up with. And that's what we did. When Brian and I first worked together, he was working on Word and I was working on Excel. But even though Brian was on Word at the time, he was already working on what we would today call citizen developer type of functionality in the Word application. So even though we were essentially on different sides of the aisle within the Office organization, we were already finding ourselves able to connect over this affinity for the citizen developer. Rob Collie (00:00:55): Now we have some laughs during this conversation about how in hindsight, the things he and I were working on at the time didn't turn out to be as significant as we thought they were in the moment. But those experiences were very valuable in shaping both of us for the initiatives that came later. Rob Collie (00:01:11): Like almost everyone at Microsoft, Brian has moved around a bit. He's worked on file formats for the entire Office suite, which ended up enabling Power Pivot version one to actually function the way that it should. He's worked on Office-wide extensibility and programmability, back to that citizen developer thing again. And in that light, it's only natural that Excel's gravity reeled him in. And in that light, it's only natural that someone like that, someone like Brian, found his way to Excel, and it really is a match made in heaven. And if you permit me the Excel joke, that turned out to be a great match. Rob Collie (00:01:50): We took the obligatory and entertaining, I hope, walk down memory lane. We spent a lot more time than I expected talking about file format. And the reason why is that file formats are actually a fascinating topic when you really get into it. Lot of history there, a lot of very interesting history and challenges we walked through. And of course, we do get around to talking about Excel, its current state, where it's headed, and also the amazing revelation for me that monthly releases actually mean a longer attention span for a product and how we ended up getting functionality now as a result of the monthly release cycle that would have never fit into the old multi-year release cycle. We were super grateful to have him on the show. And as usual, we learned things. I learned things. I have a different view of the world after having this conversation than I did before it, which is a huge gift. And I hope that you get the same sort of thing out of it. So let's get into it. Announcer (00:02:56): Ladies and gentlemen, may I have your attention please? Announcer (00:03:03): This is the Raw Data by P3 Adaptive podcast, with your host Rob Collie and your cohost Thomas Larock. Find out what the experts at P3 Adaptive can do for your business. Just go to p3adaptive.com. Raw Data by P3 Adaptive is data with the human element. Rob Collie (00:03:26): Welcome to the show. Brian Jones, how are you, sir? Brian Jones (00:03:30): I am fantastic. Thank you for having me, Rob. I'm excited. Rob Collie (00:03:33): So let's start here today. Well, you and I go way back, but today, what's your job title and what are your responsibilities? Brian Jones (00:03:42): So today, my job is I'm the head of product for the Excel team. So I lead the team of product managers that are tasked with or given the honor of deciding the future of Excel, where we go with Excel, what are the set of things that we go and build Rob Collie (00:03:59): Head of product. That's a title that we didn't have back when I was still at Microsoft. We did at one point have something called a product unit manager. Is it similar to that? How does that relate? Brian Jones (00:04:11): That's a good question. So we're continuing to evolve the way that we use titles internally. So internally, we have titles that still for most folks externally don't make any sense, like program manager, group program manager, program manager manager, director of program manager. And so for externally, whenever I'm on LinkedIn or if I do PR interviews, things like that, I use the term head of product. Internally, we don't have the term head of product. Rob Collie (00:04:37): Okay. All right. So that's a translation for us. Brian Jones (00:04:40): Yes, exactly. Trying to translate the Microsoft internal org chart to something that makes more sense to folks. Rob Collie (00:04:49): Yeah. So things like, if we use the word orthogonal, what we're really saying is that's not relevant. Brian Jones (00:04:53): Exactly. Rob Collie (00:04:54): That kind of decoder ring. Brian Jones (00:04:57): I didn't realize orthogonal [inaudible 00:04:59] until you said it and I'm like, " Oh yeah, no. Of course, that is completely a ridiculous term to use." Rob Collie (00:05:03): Or I don't know if they still do this, but an old joke that Dave [Gayner 00:05:07] and I used to have, it was all his joke at the time. It was big bet. Do we still talk about big bet? We're going to place a big bet. Brian Jones (00:05:14): Yep. Big bet or big rocks. Big rocks. You know the- Rob Collie (00:05:17): Big rocks. Whoa. Brian Jones (00:05:18): Yeah. It's kind of an analogy. You've got a jar and you want to fill it with the big rocks first, and then you let the sand fill in the rest of the space. So what are the big rocks? Rob Collie (00:05:26): Okay. Yeah. But big bet was one that we used to always make fun of. Brian Jones (00:05:31): Especially when there'd be, "Here are the big bets," and there's 20 of them. Rob Collie (00:05:34): Yeah. The joke I think we used to make was we would call something a big bet when we really didn't have any good reason for doing what we were doing. Anyway, all right. So you're head of product for Excel. That is a pretty heady job. That's pretty awesome. Brian Jones (00:05:52): It's a pretty fun job. Absolutely. Rob Collie (00:05:54): I mean, you're not lacking for eyeballs in that business, are you? We're all friends here. We're all on the same side of this story. I mean, it is the lingua franca of business, Excel. It is the business programming tool. People don't necessarily think of it as programming, but formulas are a programming language. To be head of product for the platform, you could call it an application, but really it's probably more accurate to call it a platform that is, I think, is the single most critical platform to business in the world. That's pretty amazing. Brian Jones (00:06:30): Absolutely. And that's usually the way that we talk about it internally. It depends on who your audience is externally when you're talking about it. But yeah, Excel is a programming language. I remember even before, back when I was on the Word team, but I would go and meet with PJ, who ran program manager for Office all up. And he'd always referred to Excel more as an IDE. And that didn't totally resonate with me at the time because to me, Excel was just a list app, an app for just tracking things. I didn't totally understand what he meant by that, but I'd nod cause he was super important and smart. And it wasn't really until I started working on the team that I was like, "Oh, I totally understand all these things that PJ used to reference." Rob Collie (00:07:06): This one of the things I had been dying to ask you is when you and I first met, I was working on the Excel team, but still had... Gosh, this was year 2000 maybe, maybe 2001. And even though I was nominally part of the Excel team at that point, I still didn't really know Excel, and you were working on Word. So the thing we both had in common at that point is that we didn't know Excel. So I wanted to get your perspective. I know that you've done some things other than Word, but we were already sort of teasing this. So let's just get into it. What's it like to come from "outside" Excel and how's that transition? How do you view Excel differently today versus what you did before? We already started talking about that. The list keeper. That's very common way for people to view it. Brian Jones (00:07:53): When I first started, yeah, I was on Word, although I was working on more kind of end user developer type of pieces of Word. That's how you and I first interacted because we were talking about XML. The first feature I owned was a feature called easy data binding to Excel. And the whole idea was when you could easily bring content from Excel into Word, but then create a link back so that the content in Word would stay live. And a lot of this stuff that I did while I was on Word was all about trying to make Word a little bit more of a structured tool so that people could actually program against it because Word is completely unstructured. It's just free-flowing text. So trying to write a solution against that is almost impossible because you can't predict anything. So we did a lot of work to add structure, whereas Excel out of the gate has all that structure. So it's just much easier to go and program. Brian Jones (00:08:39): If I had gone straight from Word to Excel, it would have been a little bit more of a shock, but I actually had about eight years in between where I was running our extensibility team. So a lot of the work we would do was revving the add-in model and extensibility for Excel. So I got some exposure there. When we did all of the file format stuff and the whole file format campaign, That was a couple of years where I was working really closely with a bunch of folks in Excel, like Dan [Badigan 00:09:06] and folks like that. So I had a bit of exposure, but I'll tell you when I first joined, I had a similar job, but it was for the Access team and we were building up some new tech. Brian Jones (00:09:17): Some of it still is there today. Office Forms came out of some of the investments that we were doing in Access. But when I showed up into Excel, I was very much in that mode of, "Why don't the Excel folks, get it? Everything should be a table with column headings." And like, "That's the model. And why do they stick with this grid? Clearly word of it is eventually going to go away from the printed page as the key medium. Excel's got to go away from the grid. And they've got to understand that this should just be all tables that can be related." And thankfully, I was responsible when I joined and didn't try and act like I knew everything. So I took some time to go and learn. Brian Jones (00:09:52): And it didn't take me long. We have some crazy financial modeling experts on the team and stuff like that, where I'd say it was maybe six months in that it clicked for me where I understood those two key pieces. The grid and formulas are really the soul and the IP of Excel. The fact that you can lay out information really easily on a grid, you have formulas that are your logic, and you can do this step-by-step set of processes where each cell is almost like another little debug point for you. [Cal captain sub 00:10:20] second, and it's the easiest way to go and learn logic and how to build logic. Brian Jones (00:10:25): I didn't get any of that at that time, but you pick it up pretty quickly when you start to look at all the solutions that people are building. And now, obviously, I've been on the team now for five years, so I'm super sold around it. But I'd say it took me a little while and I'm still learning. It takes a while to learn the whole thing. Rob Collie (00:10:41): Yeah. It's funny. Like you said, Word's completely unstructured. You're looking in from the outside and you're like, "Well, Excel is completely structured." Then you get close to it. You're like, "Oh no. And it's not, really." Brian Jones (00:10:52): No. Not at all. Rob Collie (00:10:53): I mean, it's got the cells. Rows and columns. You can't avoid those. But within that landscape, is it kind of deliberately wild west? You can do whatever you need to. You're right. Okay. So tables, yes. Tables are still very important. But you've got these parameters and assumptions and inputs. And what do you do with those? I mean, they're not make a table for those. Brian Jones (00:11:19): Yep. Absolutely. I think that the thing that I started to get really quickly was the beauty of that. Like you said, it's unstructured. You have nice reference points. So if you're trying to build logic, formulas, you can reference things. But there's no rule about whether or not things go horizontally, vertically, diagonally, whatever. You can take whatever's in your mind that you're trying to make a decision around and use that flexible grid to lay it out. It's like a mind map. If you think about the beauty, the flexibility of a mind map, that's what the grid is. You can go and lay out all the information however it makes the most sense to you. Brian Jones (00:11:53): Really, that's what makes Excel still so relevant today. If you think about the way business is evolving, people are getting more and more data, change is just more constant, business processes are changing all the time. So there are certain processes where people can say, "This thing is always going to work the same way." And so you can go and get a vertical railed solution. That's why we use the term rail. That's kind of like if I always know I'm going to take this cargo from LA to San Francisco, I can go and build some rails, and I got a train, it'll always go there and do the same thing. But if business is constantly changing, those rails are quickly going to break and you're going to have to go off the rails. Excel is more like a car than a train. You can go anywhere with it. And so as the business processes change, the people who are using Excel are the same people who are the ones changing those business processes. Those are the business folks. And so they can go and evolve and adapt it and they don't have to go and find another ISV to go and build them another solution based on that new process that's probably going to change again in six months. Thomas Larock (00:12:52): So Brian's been in charge for five years of Excel, and he's sitting there telling us how there's still more to learn. And two weeks ago, we all got renewed as MVPs. And so I was on the MVP website, and I'm going through all the DLs I can join because that's all a manual process these days. I'm like, "Oh, there's the Excel MVP DL. I don't know why I haven't joined this yet." So I click. I'm immediately flooded with 100 emails a day. 100 emails a day. Now, I don't believe I am a novice when it comes to Excel. I don't. I know I'm not on you all's level at all when it comes to it. You build and work and live the product. But I know my way around enough that I can explain things to others when they say, "I'm trying to do this thing." "Oh, I think it's possible." Thomas Larock (00:13:40): But I read these passionate MVPs that you have and the stuff that they highlight, and it's not complex stuff. It's like, "Hey, this title bar seems to be wider in this." And I'm like, I might not even notice this stuff. And I see these features that aren't a complex feature, but I'm like, "I didn't even know that was there. I didn't even know you could do that. Oh, you can do that too." There's so much. And like you said, it's a programming language. It's an IDE. It's all these things. As [Sinopski 00:14:10] said, "It's the killer app for Windows." To have the head of product say that, there's just so much. He really means it. There is a lot to it. And it is something that is malleable and usable by hundreds of millions of people a day. Brian Jones (00:14:25): Yeah. Rob Collie (00:14:26): My old joke is, if you want to know how good someone is at Excel, just ask them, "How good are you at Excel?" And then take their answer and invert it. Brian Jones (00:14:37): That's absolutely true. Rob Collie (00:14:38): If someone says, "Yeah, I'm really good at it," You know they don't have any clue because they haven't glimpsed the depth of that particular mine shaft. And once someone has been to the show, they know better than to oversell their knowledge because they know they can't know everything. Rob Collie (00:14:54): You say you're good at Excel. And then the very next question is one that you're not going to be able to answer. So you got to be careful. [inaudible 00:15:00] person views Excel as Word with a grid. And that's not obviously what it is, but that's the oversimplification for... I don't know... maybe 80% of humanity. Brian Jones (00:15:10): Yeah. And the thing is, there's a lot more that we're doing in the app now to try and make it, one, more approachable, because there's a set of folks that just find it really intimidating, for sure. You open it up and it's this huge, dense grid. Like, "Hey, where do I start? What should I go and do? I've never even heard of this thing before." In the past, a lot of stuff that we would do, we never really thought about those first steps of using the app because we were always like, "Well, everybody knows our app. We're going to go and do the things for everybody that knows our app." And I think we're doing a better job now trying to think, "Well, there's a bunch of people who don't know about our app. Let's go and figure out what the experience should be like for them." Brian Jones (00:15:43): But we've done a lot with AI where we're trying to get a little bit better about... We look at your data. Recommend things to you. So we'll say, "If you've got a table of data, hey, here's a pivot table." You may not have even heard of the pivot table before. So really more like, "Hey, here's a summary of your data." You want to go and insert that. Brian Jones (00:16:00): In fact, those tests are always fun because then we get to work with people who've really haven't ever used a pivot table. So it's always fun to hear the words that they use to describe what a pivot table is. It's like, "Oh wow, you grouped my data for me." Or stuff like that like, "Wow. That's a nice name for it too." So we're trying to do more of that to expose people to really those higher-end things. But those things where for those of us that use it, once you discover that stuff, you're even more hooked on the product. You're like, man, that first experience of somebody built a pivot table for you and you realize, "Oh my God, I didn't know I could do this with my data. Look how much easier it is for me to see what's going on," and trying to get more people to experience that kind of magical moment. Thomas Larock (00:16:39): Now imagine being me and only knowing pivot through T-SQL and that magical day when you meet Rob and he's like, "You just pivot table [inaudible 00:16:49]." And you're like, "How many hours have I wasted? Why didn't someone tell me?" Brian Jones (00:16:56): Yeah. We get that a lot when we'll go and show stuff. Oftentimes, the reaction is more frustration. "I can't believe I didn't know about this for the past five years." Rob Collie (00:17:05): We get that all the time now with Power Pivot and Power Query and Power BI in general. The target audience for that stuff hasn't been really effectively addressed by Microsoft marketing. But even back, just regular pivot tables, such a powerful tool, and so poorly named. You weren't around on the Excel team, Brian, when I waged a six-month campaign to try to rename pivot table to summary table. Brian Jones (00:17:31): Oh really? Rob Collie (00:17:31): Yeah. Brian Jones (00:17:31): How long ago was that? Rob Collie (00:17:33): Oh, well, it was a long time ago. I mean [crosstalk 00:17:35]- Brian Jones (00:17:36): Pivot tables had already been out for quite a while. Rob Collie (00:17:37): Oh God. Yeah. I mean, they were long established. They were in the product. I didn't even know what they did. Believe it or not, I worked on the Excel team for probably about a year before I actually figured what pivot tables could do. People would just throw it around all the time on the team like, "Well, once you have the data, then you can chart it. You can pivot it," blah, blah, blah, blah, blah. And so I would fit in- Brian Jones (00:17:58): You would nod? Rob Collie (00:17:59): I would fit in... I would also author sentences like that, that had the word pivot in it. It was a pretty safe thing to do. There was no downside to it. But believe it or not, the time that I discovered what pivot tables are for... you'll love this... I was trying to figure out how to skill balance the four different fantasy football leagues that I had organized within the Excel and Access team. I wanted to spread it out. Levels of experience. I've got this table of data with the person's name and their level of experience and my tentative league assignment. And just this light bulb went on. I'm like, "Oh my God, I bet this is what pivot tables are for." Total expertise by league. Like, "Oh, look at that. It's totally it." That was a big change for me. That was during the release, Brian, where you and I were working together. Brian Jones (00:18:54): I think I played on one of those fantasy football leagues. Rob Collie (00:18:56): You might have. Brian Jones (00:18:57): I was one of the people with zero experience. I remember going into the draft not knowing... I knew football, but I didn't know anything about fantasy football. Rob Collie (00:19:03): That's right. We did loop you in. So let's do that way back machine for a moment. That release when you and I met was the first release on Excel. I was the lead at that point. It was my first time being a lead. It was the first time I was in charge of a feature set, and it was really my baby, this XML thing we were doing. And the reason for that was because no one was paying any attention. That was this weird release. For a whole release, Office went and tried to do cloud services without having any idea what that really was going to mean. And so we stripped all of the applications down to skeleton crews. And this is really the only reason why on the Excel side, some youngster like me was allowed to be a lead and come up with a feature, because no one cared. No one was paying any attention. There was no one minding the store. Rob Collie (00:19:48): I remember being so wild-eyed enthusiastic about how much this was going to change the world, this XML import export future. And I mean, you might as well just take it out. I can't imagine it's being used hardly at all today. I bet Power View is used more often than the XML import export feature. You all have done a pretty good job of hiding it. So kudos. But it was a good thing to cut my teeth on. I learned a lot of valuable lessons on that release. Rob Collie (00:20:24): How do you feel about the XML structure document work that you were doing in Word at the time? Do you kind of have the same feeling looking back at it that I do? Brian Jones (00:20:33): It was a similar thing. In fact, we did rip it out a couple of years later. I think that when you and I would talk about it, we would talk about these scenarios that were super righteous and great. And then we just start geeking out on tech. And then we would get way too excited about the tech and we kind of forget about those initial scenarios. We wouldn't stop and think, "Wait a minute. These users we're talking about, are they actually going to go and create XML files?" Because you need one of those to start with before any of this stuff makes sense. And no, of course, they're not. But for me, a lot of it started from that. Like I said, one of my first features was that easy data binding to Excel feature. And we thought, "Hey, maybe XML would be a good tech for us to use as a way of having Word and Excel talk to each other," because clearly they have different views on what formatting is and how to present information, but the underlying semantic information, that could be shared. Brian Jones (00:21:20): And so I could have a set of products show up in Excel as a table. And when they come into Word, they look more like a catalog of products. That totally makes sense. And we just did a lot of assumptions that people would make, do all the glue that was really necessary. And of course, they didn't. So I had the exact same experience. The other big thing that was different back then for us was we would plan something, meet with customers for six months, but then it'd take three years to go and build it. We had no way of validating that stuff with customers because we couldn't get them any of the builds. And then even after we shipped it, they weren't actually going to deploy it for another three-plus years. And so the reality is from when you had the idea to where you actually can see that it's actually not working and people aren't using it is probably about six years. So you've probably moved on to something else by then. Brian Jones (00:22:04): The only way you really as a PM got validation that your feature was great was whether or not leadership and maybe press got excited about your thing, but you didn't get a whole lot of signal from actual customers whether or not the thing was working, which is obviously completely different now, thank goodness. Rob Collie (00:22:18): Yeah. That Is true. It took some of the fun out of being done too, now looking back at it, like the day of the ship party, when we were done with the three-year release. "Okay, fine." We'd dunk each other in fountains and there'd be hijinks and stuff. But the world did not experience us being done. That was purely just us feeling done. And then it was like you take a week off maybe, and then the next week, you're right back to the grind at the very beginning. You never got the payoff. Even if you built something really good, by the time the world discovered it and it was actually really helping people at any significant scale, you're no longer even working on that product. Brian Jones (00:22:57): Yeah. You're doing something completely different. Rob Collie (00:22:59): You might be in a different division, both finding out the things in real time that Rob Collie (00:23:03): [inaudible 00:23:00] Both finding out the things, sort of in real time, that aren't working. That's the obvious advantage, right? But there's also this other emotional thing. Like you never got the satisfaction when you actually did succeed. Brian Jones (00:23:11): Right. You didn't see it actually get picked up, adopted. Millions and millions of people using it, which is what the team gets now. We no longer pick a project and say, "Okay, how many people and how long is this going to take?" You really just try and figure out what's critical mass for that project. And then you just let them run. And you'd be really clear around what are the goals and outcomes they're trying to drive. And they just keep going until they actually achieve that. Or we realized that we were wrong, right? And we say, "Hey, we thought people are going to be excited about this. It's not even an implementation thing. We were just wrong. We misread what people really were trying to do. Let's stop. Let's kind of figure out a way of moving off of that and go and figure out what the next thing is we should go and do." Rob Collie (00:23:50): That era that we're talking about right now. The 2003 release of Office. I was still very much a computer science graduate and amateur human. That's exactly backwards, it turns out, if you're trying to design a tool that's going to be used by humanity. Brian Jones (00:24:08): Well, it's what leads you to get really Excited about XML? Rob Collie (00:24:12): That's right. Yeah. That's right. Tech used to have such a power in my life. I'm exactly the opposite now. Every time I hear about some new tech, I'm like, "Yeah, prove it." I am not going to believe in this new radical thing until it actually changes the world around me. I'm not going to be trying to catch that wave. But XML did that to me. It was almost a threat. If we don't take this seriously, we're going to get outflanked. It got really egregious. Rob Collie (00:24:42): I had a coworker one time in that same release in the middle of one of my presentations asked me. This guy wasn't particularly, in the final analysis, looking back, not one of the stronger members of the team, but he had a lot of sibling rivalry essentially in his DNA. And he'd asked me in front of his crowded room, "Well, what are you going to do about Bluetooth?" And, we didn't know what Bluetooth was yet, right? It was like, unless I had an answer for what we were going to do about Bluetooth and Excel, right? Then I was not up on things. You know, the thing that we use to connect our headphones. At the time, Bluetooth was one of those things that might just disrupt everything. Brian Jones (00:25:29): It was funny. It was at that same time, I was asked to give a presentation to the Word team about Bluetooth. We were all assigned things to go and research as part of planning and that was one of the ones I was asked. And I gave a presentation that was just very factual. Here's what it is. And I was given really bad feedback that like, "Hey, I wasn't actually talking about it strategically and how it was going to affect Word. I was just being very factual." And I was like, "I don't understand. I don't understand what success looks like in this task." Right. Rob Collie (00:25:59): I remember going, a couple of years later, going into an offsite, those offsite big, I don't know if you all still do those things, big offsite, blue sky brainstorming sessions. There was this really senior development lead that was there with me. And he and I were kind of buddies. At one point, halfway through the day, he just leans over to me and says, "Hey, I'm going to the restroom and I'm not coming back." And I looked at him in horror, almost like "Thou dost dishonor the offsite!?" And he's like, "Yeah, you know, I've never really believed that much in this particular phase of the product cycle. It's never really meant anything to me. It's all just BS." It was just devastating. I just knew it was right. He was... Brian Jones (00:26:46): But you didn't want to, you didn't want to believe that. Rob Collie (00:26:52): I mean, I felt so special. I was invited to the offsite, the big wigs and everything. Brian Jones (00:26:57): They have nice catering too, Rob Collie (00:26:59): Yeah and he was totally right to leave. Brian Jones (00:27:04): I always remember getting super nervous to present stuff for those. Once it was actually, it was one of our XML ones where I was trying to convince, it was my attempt to get us to create an XML file format, which actually ended up, obviously, happening. But I got an engineer to go to work with and we had Word through an add-in, start to write to XML. And it was just a basic XML format. And then I built all of these... it was like asp.net tools that would go and then create an HTML version of the Word doc that was editable. And it also even created, I think it was called WHAP, I don't remember, like a tech for phones. It was back when you didn't have the rich feature phones, but these basic ones. Brian Jones (00:27:41): And so I created this thing that was almost like a SharePoint site. So you could take all your Word docs, go through this add-in, and then you could actually get an HTML view of them to edit it and a phone view of them to go and edit it. Brian Jones (00:27:51): I think it was probably 2002 or 2001, but I was so excited to go and show that at the offsite because I was like, "Okay, this is where I make it, man. Everybody's going to be so excited about me." But I don't know. I think everybody was excited about Bluetooth at that point or something. Yeah. Rob Collie (00:28:05): Oh yeah Bluetooth, WHAP was so 15 minutes ago. So there's a few, irresistibly funny or interesting things I want to zero in on from that era before we come back to present, and we're definitely going to come back to present, for sure. Rob Collie (00:28:21): First of all, we went to a conference like some W3C sponsor. I don't think it was necessarily W3C affiliated, but it was the XML conference. Brian Jones (00:28:31): The one in Baltimore? Rob Collie (00:28:32): Yes. Rob Collie (00:28:33): Okay. Now two very, very, very memorable things happened at that conference. I bet you already know one of them. But the other one was, and we're just going to make this all this anonymous person's fault. Okay. We're not going to abdicate any responsibility. And we're just going to talk about our one coworker from Eastern Europe who brought his wife and they had vodka in their hotel fridge, or freezer, or something like that. And every day I would wake up and say, "I am not going to get suckered into that again." Rob Collie (00:29:12): And then the next day I would wake up and say the same thing. That was a tough trip. Brian Jones (00:29:16): I definitely remember that. Rob Collie (00:29:18): Even on my young, relatively young, body at the time that... Trying to keep up with that, that was difficult. But the single most outstanding memory from that conference, and we will also leave this person anonymous. But there was an executive at Microsoft who was hotter on XML than either you or I, which is hard to believe, right. And we ended up with the sponsored after hours session at this conference. You remember this? You see... Brian Jones (00:29:45): I do. Rob Collie (00:29:46): You know where we're going. Okay. So this was a 30 minute sponsored by Dell or something. Right. It was a 30 minute session, at 5:00 PM, at the end of a conference day where everyone's trying to go back and get to the bars or whatever, right.? But, it's a Microsoft executive, it's Dell sponsored, we'll show up. And the plan was at the end of this 30 minute talk given by this executive, he was going to bring all of us up on the stage to show everyone the team that had done all of this, right? Great plan. Except it was the worst presentation in history. I remember it running for two hours. It was so bad that we started off with 200 people in the room and at the end of it, and I'm just like an agony the whole time cause like I'm associated with this, right? Rob Collie (00:30:31): At the end of these two hours, or what felt like two hours anyway, it was easily 90 minutes. There's five people left in this room of 200 and it's not like the presentation is adapted to the fact that it's a smaller audience. It's just continued to drone on exactly as if everyone was there, right? And I'm sitting here thinking, "Okay, he's not going to call us all up on this stage. There's been more people on the stage than in the audience. If he does this, he's clearly not going to do that." And then he did and we all had to parade up there and stand there like the biggest dodos. I've never been more professionally embarrassed I don't think, than that moment. Rob Collie (00:31:14): And we're all looking at each other as we get up out of our seats like, "Oh my god." Brian Jones (00:31:19): I definitely remember this. Rob Collie (00:31:22): I don't see how you could have forgotten. Brian Jones (00:31:23): Well, yeah. And the person that we're talking about is actually one of my favorite people on the planet. I totally... I love this guy. I view him as like a mentor and everything, but... Which makes me remember it even more. Brian Jones (00:31:34): I think it was just, there was so much excitement. There'd been so much build up to this and this was like a kind of crescendo right? Of bringing this stuff. We probably should have had it a little bit shorter. Rob Collie (00:31:46): I mean when it reaches the point where clueless, mid twenties, Rob Collie is going, "Oh no, this is not the emotional, this not the move." You don't do it. Brian Jones (00:31:58): I'm no longer excited about being called up. Rob Collie (00:32:04): So from my perspective, you kind of parlayed that experience of the XML and all that kind of stuff. I think you did a really fantastic job of everything you guys did on that product. Again, it was the relevance that ultimately fell flat for both of us right. I guess in the end, the excitement with XML wasn't really all that appreciably different from the excitement about Bluetooth. I mean, it's everywhere, right? XML is everywhere. Bluetooth is everywhere and neither one of them really changed things in terms of what Excel or Word should be doing. It seemed like you played that into this file format second act. And I think very, very, very effectively, actually there was a little bit of controversy. Rob Collie (00:32:43): Let's set the stage for people. This was the 2007 release of Office where all the file formats got radically overhauled. This is when the extra X appeared on the end of all the file names, right? Brian Jones (00:32:58): Yeah. Rob Collie (00:32:58): There was a controversy internally. Kind of starting with Bill actually. That we shouldn't make well-documented transparent file format specs, right. There was this belief that the opaque file formats of the previous decades was in some sense, some big moat against competition. And of course, a lot of our competitors agreed. Tailor out in the public saying, "Yes, this is a barrier to competition. It's a monopolistic, blah, blah, blah." We, Microsoft had just gotten its ass kicked in the Anna Truss case. So it was really interesting. I credit Brian, your crew, with really advocating this very effectively. That's a difficult ship to turn. First of all, you got all these teams to buy into all this extra work, which no one wants to do. But when it's not even clear whether you have top level executive support, in fact, you might actually have C-suite antagonism towards an idea. To get it done. That's a career making achievement. I'm sure you remember all of that. Right. But what are your reactions to that controversy? Do you remember being in the midst of that? Brian Jones (00:34:12): I do. It was definitely a long running project. It evolved over quite a number of years. The beginning of it was, in that previous release, the XML stuff you and I were talking about was more about what we called "Custom XML". Right? So people would go and create for themselves. But in that same release, we had Word, we outputted an XML format that was our definition, which we called "Word ML" and Excel did a similar thing. Words' we try to make full fidelity. So you could save any word document in the XML format. Excel's was kind of a tailored down, it was less about formatting, it was more, "Hey, here's like..." It's almost like, "Here's a better version of CSV, right. But we're going to do it as XML." And so we already had a little bit of that. Brian Jones (00:34:53): And the whole reason we were looking at that was, on the Word side, for instance, a lot of the customer issues that we'd get where people would have corrupt files, they were corrupt because they there'd be some add-in that they had running or some third party app that was reading and writing word files. The files were fairly brittle and complex. The binary format... The binary format was written back in the days of floppy disks, right? So the top priority was how quickly can you write to a floppy disk and read from a floppy disc, right? It wasn't about, how easy is this for other people to go and read and write? Not because it was on purpose, make it hard. It was just the primary bid is let's get this thing so it's really easy to read and write from floppy, right? Brian Jones (00:35:31): And so in Word, we were like, "Wow, I think that there's a bigger opportunity here for an ecosystem around Word if we make it easy for people to read and write Word docs and build solutions around them." And so then the next release, the Excel team was looking at doing some big changes around a lot of the limitations, like how many rows you could have in columns, right. Lengths of like formulas and things like that. Right. And so there was this thing where the Excel team was like, "We are going to need to create a new file format." And on the word side, we thought this XML thing was great. We want to move to that as our new format. Brian Jones (00:36:01): And so everything kind of came together and it was clear. Hey, this is going to be the release that we are going to go and rev our file format, which we hadn't done in a while. This is also the release of the ribbon. So there were two really big major changes in that product, right? It was the new file format and the ribbon. It's funny. I still refer to it as the new file format, even though it's 15 years old. Rob Collie (00:36:23): Yeah. It's the new file format it's still new, yeah. Brian Jones (00:36:25): I still call it that, which is kind of nuts. But I think that the controversies you were talking about was really more of a... Boy, this is a really big deal for the product. We had changed file formats before in the past and not necessarily gotten it right. And there were a lot of challenges around compatibility and stuff. And so there was just a lot of worry of let's make sure you all have your stuff together here, right? Like let's make sure that this doesn't in any way break, stop people from wanting to upgrade to the new version. But it went really well. The whole goal of it was let's get something that we think third parties can go and read and write, and this is going to help build an ecosystem. And a new ecosystem run Office. Office already had big ecosystem with VBA and COMM add-ons and stuff like that, right.? But we won't have this new ecosystem around our file formats as a thing. That's why we chose... There's a packaging layer, which is all zip based. So if people haven't played around with it that XLSX, you can just put a .zip at the end and double click it. And it's just a zip file. And you can see a whole bunch of stuff inside of it. Right? Rob Collie (00:37:23): Yeah. If you're listening, you haven't done that go right now, run don't walk, grab an Excel file or a Word file, whatever. Go and rename the XLSX or BPTX, go ahead and rename it so that it ends in .zip and then open it up and you'll be blown away. Thomas Larock (00:37:38): PowerPoint is my favorite when I have to find some unknown setting that I need and I can just search through the whole thing. Yep. Rob Collie (00:37:45): Or all the images. You want to get all the images out of the PowerPoint file. It's just a zip file that has a bunch of images in it. Right. Brian Jones (00:37:50): So I also did this for backpack. It's the same thing. You can crack open the backpack by renaming a zip file... Thomas Larock (00:37:58): An actual physical backpack? What are we... what are we talking about here? Brian Jones (00:38:03): Ah yeah. Rob Collie (00:38:03): This is the digital acetate that is over the top of the entire physical world that you aren't aware of. Thomas Larock (00:38:08): Digital acetate, that's it? That's it. That's where the podcast peaks. Right? Those two words. We're all going home now. Brian Jones (00:38:19): Yeah. No. A SQL server, there's DAC pack, which is just the, say database schema. Then there's a backpack which has the data and the schema combined. But you can, if you rename them . zip, you can crack them open to see the XML that makes up those forms. So it's not just office products. Rob Collie (00:38:37): We ended up standardizing the entire thing, but that packaging format, it was called OPC, Open Packaging Convention, or something like that. It was something that we did in partnership with a Windows team. It's part of the final ISO standard for our file format. And then there were a lot of other folks that went and used that exact same standard. Because it's a really easy way of you have a zip package. You can have a whole bunch of pieces inside of it, which are XML. And then there's this convention for how you can do relationships between the different pieces. So I can have a slide. That's an XML and it can declare relationships to all the images that it uses. And that way it's really quick, easy to know, okay, here's all the content I need to grab if I want to move pieces of it outside of the file. Rob Collie (00:39:16): So the single coolest thing I've ever done with, we'll just call it your file format Brian. We'll just pretend that it was only you working on that. Brian Jones (00:39:23): Just me yeah, I was pretty busy, but yeah. Rob Collie (00:39:27): So the very, very first version of Power Pivot, first of all, your file format, the new file format made Power Pivot possible. We needed to go and add this gigantic binary stream of compressed data and everything, everything about Power Pivot needed to be saved in the file. At the beginning of the project, everyone was saying, "Oh, no, we're going to save it as two separate files." And I'm like, "Are you guys kidding?" The Pivot cache, for instance, is saved in the same file. You can't throw a multi file solution at people and expect it to... This was actually like Manhattan project, just to get that stream saved into the same file. It was pretty crazy. However, when it was done, there was something really awesome I wasn't aware of until the very end, which was, first of all, you could open up a zip file and just tunnel down and you would find a file in there called item one.data. Rob Collie (00:40:21): Okay. That was the Power Pivot blob. That was everything about the Power Pivot thing. And it was by far the biggest thing in the file, like it was like 99% of the file size was what was there. However, as this backup, someone had decided, I had nothing to do with this, to save all of the instructions. I think it's called XML for analysis XMLA. All of the instructions that would be required to rebuild exactly that file, but without any of the actual binary data in it. So it was a very, very small amount of XML. Okay. So here's what we would do because there were no good automation, no interfaces, no APIs. If we needed to add like 500 formulas to a Power Pivot file, you could go through the UI and write those 500 formulas, type, click, type, click, type, click. Rob Collie (00:41:08): Okay. So what we would do, and my first job outside of Microsoft, is we would go in there and we would edit that XML backup and add all the formulas we wanted in it. And by the way, I would use Excel to write these formulas. I would use string concatenation and all of that kind of stuff to write these things. It was very, very, very sensitive, one character out of place in the whole thing fails. So you make those changes. You save the file, reopen it, nothing happens because it's just the backup. Okay. So then you've got to go and you've got to create a zero byte item one.data file on your desktop and you copy it into the zip file and overwrite the real item one.data, therefore deliberately corrupting the primary copy. So when you reopen the file it triggers the backup process and it rehydrates with all of your stuff, it was awesome. Rob Collie (00:41:57): And then a couple of releases of Power Pivot later, suddenly that didn't work anymore and I was really pissed. But it just really shows you, it opens up so many opportunities that you never would have expected. And even a hack like that, that's not the kind that you'd be really looking for, but the fact that something like that even happens as a result of this is really indicative of what a success it was. Brian Jones (00:42:19): Yeah. I mean, there's a lot of those things where, I love building platforms, like that's my favorite part of the job. It's all those things that you see people do that you never would have predicted. Right? That's just so exciting. PowerPoint had this huge group of folks that would go and build things like doc assembly stuff, right. Where they go and automatically build PowerPoint decks on demand, right? Based on who you're going to go and present to cause they've just shredded the thing. In fact, when we did the ISO standardization, it was a 6,000 page doc that we had to go. And we built and reviewed with a standards body and we did it over about a year. Which sounds nuts, a 6,000 page doc in about a year. And the way that we were able to do that is there was never really a 6,000 page doc. There's a database where there's a row for every single element and attribute in this, in the whole schema, that would then have the column which is the description, which would just be the word XML. Brian Jones (00:43:09): And so we could, on demand, at any point, generate whatever view or part of the doc we wanted. So we'd say, "Hey, we're going to go in now, review everything that has to do with formatting across Word, Excel and PowerPoint." And so we just click a couple buttons and the database would spit out a Word doc that was just that part. Everybody could go and edit it cause we were using the structured elements we'd added to Word, which is called content controls, which was the next version of that XML stuff that we had to deprecate. And then the process, as soon as you'd finish editing that Word doc, we just submit it back. The process would go back and shred that Word doc again and put it all back in the database. And so we really used the file format to bootstrap documenting the file format. Rob Collie (00:43:48): And then when you dump a 6,000 page document on someone, they have no choice. But to just say, yep, it looks good to us. Brian Jones (00:43:55): Well, there was a pretty, incredibly thorough review still. It was just pretty impressive. The final vote that we had in Geneva, the process leading up to that, the amount of feedback that we got. Cause basically the ISO, you can kind of think of it like the UN, you go and show up and every country has a seat, right? I mean, not everybody participates, but anybody that wants to can. And so yeah, we had to respond to thousands of comments around different pieces, things that people wanted to see changed. Rob Collie (00:44:22): Yeah. I can imagine, right. Think about it. You just said at the final vote in Geneva. That's a heavy moment man. Thomas Larock (00:44:29): Yeah. That threw me off for a second. I thought, for sure, you were talking Switzerland, but now thinking that was just a code name. Rob Collie (00:44:38): No, I think, I think he was actually in Switzerland. Brian Jones (00:44:40): In Switzerland. Rob Collie (00:44:41): Have you seen the chamber where they do these votes? It looks just like the Senate from episode one of Star Wars. It's just like that. It's pretty heavy. Brian Jones (00:44:51): The little levitating... Rob Collie (00:44:53): The floating lift. Yeah. I think they call that digital acetate. I think that's what they call that. By the way on the Excel team, the way I came to look at the new file format and the open architecture of it, again, this this will show you how quickly I had turned into the more cynic side of things. Well, okay. We're going to be changing file formats. And we're doing that for our benefit because we didn't have enough bits allocated in the 1980s version of the file format that was saved to floppy disc, as you pointed out, right. Who could ever imagine having more than 64,000 rows, it's just inconceivable or 250 columns or whatever, right.? Because we hadn't allocated that. We'd made an engineering mistake, essentially, we hadn't future-proofed. So we need to make a file format change for our benefit, right. To undo one of our mistakes. And the way I looked at it was, "Ooh, all this open file format stuff, that'll be like the 'Look, squirrel!'" To distract people and to sort of justify, while we went and did this other thing, which, ultimately it actually went pretty well. The transition for the customers actually wasn't nearly as bad, because we actually Took it seriously. Rob Collie (00:46:03): The transition for the customers actually wasn't nearly as bad because we actually took it seriously. We didn't cut any corners. We did all the right things. Brian Jones (00:46:07): Well, there were several benefits too. We were talking about all the kind of ecosystem development benefits, but the fact that the file was zipped and compressed right, it meant that the thing was smaller. And that was all of a sudden, it was no longer about floppy discs. People are sharing files on networks. And so actually being able to go and have a file that's easier to share, send over network because it's smaller was a thing. Brian Jones (00:46:26): There were a couple of things that we were able to go and highlight. There's also a pretty nice thing where it was actually more robust because it was XML, and we split it into multiple pieces of XML. It meant that even if you had bit rot, you would only lose one little piece of the file, whereas with old the binary format, you had some bit rot and the whole thing is impossible to open up.There are a couple of things that were in user benefits too, which helped. Rob Collie (00:46:50): And ultimately, on the Excel side, the user got a million row spreadsheet format and the ability to use a hell of a lot more than like 14 colors that could be used in a single spreadsheet or something. It was .like a power of two minus two, so many bizarre things. Like Excel had more colors than that, but you couldn't use more than a certain subset in a- Brian Jones (00:47:10): At a time, yeah. Rob Collie (00:47:10): -In a single file. So yeah, there were a lot of benefits. They just weren't- Brian Jones (00:47:15): It's not like it's an explicit choice. It's just that at the time somebody is implementing something, you're right in a way, assuming, "Oh, this is fine. This is enough. I'll never have to worry with this issue." Rob Collie (00:47:25): Why waste the whole byte on that? When you can cram four different settings into a single byte. If you read the old stories about Gates and Allen programming up at Harvard, they had these vicious head-to-head competitions to see who could write the compiler or the section of basic in the fewest bytes possible. This was still very much hanging over Microsoft, even the vestiges of it were still kind of hanging over us even when I arrived. But certainly in the '80s when the Excel file format was being designed for that rev, it was still very much like, "Why waste all those bits in a byte?" "Let's cap it at four bits". Thomas Larock (00:48:05): In that blog series from Sinofsky, he talks a lot about that at the early start. And I'm at a point now where he's talking a lot about the code reuse because the Excel team, the Word team, I guess PowerPoint, but all these other teams, were all dealing with, say, text. And they were all doing their own code for how that text would be displayed and shown. And Bill would be the one being like, " This is ridiculous". "We should be able to reuse the code between these products". And to me, that would just be common sense. But these groups, Microsoft just grew so rapidly so quickly, they were off on their own, and they have to ship. I ain't got time to wait around for this, for somebody to build an API, things like that. I'll just write it myself. Brian Jones (00:48:50): It's a general thing that you get as you get larger where the person in charge that can oversee everything is like, "Well, these are all my resources", and, "Wow, I don't want three groups all building the same thing". But then when you get down, there's also a reality of we're just going to have a very different view on text and text layout than Excel. And Excel is not going to say, "I want all of that code that Word uses to lay out all of their content to be running for every single cell". Right? That's just suboptimal. And so it's always this fun conversation back and forth around where do you have shared code and reuse and where do you say it's okay for this specific app to have this more optimized thing that might look the same, but in reality, it's not really the same. Rob Collie (00:49:33): Brian, do you remember the ... I'm sure you do, but I don't remember what company they were from. But at one point in this file format effort, these really high priced consultants showed up and went around and interviewed us a couple of times. Do you remember that phase? It was like- Brian Jones (00:49:51): Was that towards the end? There was a couple summary stories that were pulled together just to talk about the overall processes. It was actually after the standardization. Rob Collie (00:49:58): I remember this being at the point in time where it was still kind of a question. whether we should do it. Brian Jones (00:50:02): I don't remember that. Rob Collie (00:50:04): The thing I remember really vividly is a statement that Chris Pratley would make over and over again, this encapsulated it for me. I came around to seeing it his way, which was the file format isn't the thing. That's not the moat. The thing that makes Office unique is the behaviors of the application. It's not the noun of the file format. It's the verb of what happens in the app. It's instructed to think that even if you took exactly the Excel team today, every single person that's already worked on it, and said, "Hey, you have to go rebuild Excel exactly". There's no way that version of Excel would be compatible with the one we have now. It would drift so much. Rob Collie (00:50:43): You could even have access to all the same specs. We would even cheat and say, "Look, you can have access to every single spec ever written". So? It was clearly someone had thought it was time to bring in like a McKinsey. They were all well dressed. They were all attractive. They were all a little too young to be the ones sort of making these decisions. It was just really weird to have them show up, three people in your office. Like, "Okay, I'll tell you what's going on". Brian Jones (00:51:11): I can totally imagine. It's funny I don't remember that. There were several rounds of analysis on how we were doing it, what we're doing and making sure we were doing it the right way. But yeah, Chris is spot on. I mean, your point about rebuilding it, that's essentially what we've been going through for the past five plus years around our web app. It's a lot of work. Unfortunately, we can't let it drift. The expectation from everybody is, "Hey, I learned the Wind 32 version. When I go to the web, I want it to feel the same. I don't want to feel like I'm now using some different app." Rob Collie (00:51:44): What an amazing, again, like a Manhattan project type of thing, this notion of rewriting Excel to run on the web and be compatible. Brian Jones (00:51:55): Yeah, with 30 years of innovation. Rob Collie (00:51:56): Yeah. That started in the 2007 release. Excel services, the first release of Excel services was 2007. And this whole thing about shared code, like what features, what functions of Excel, what pieces of it were going to be rewritten to be quote unquote "shared code"? And shared code meant it was actually server safe, which none of regular desktop Excel written in the early '80s, still carrying around assembly in certain places, assembly code of all things, right? Excel was not server safe. It was about as far from server safe as you could get. And so to rewrite this so ambitious without breaking anything. Oh my God. What a massive ... This dates back, gosh, more than 15 years. Brian Jones (00:52:45): Yeah. I'd say like the first goals around it were a bit different, right? It wasn't a web version of Excel. It was like BI scenarios and how can we have dashboards and Excel playing a role in dashboards. But yeah, I'd say since I joined, it was probably maybe a half a year or a year into when I joined, we just made the decision to shift a huge chunk of our funding to the web app. It was just clear that we need to make even more rapid progress. If you go, we have a site where you can go and see all the features that are rolling out there. It's incredible. And it's just because of the depth of the product. "Wow that's so many features you've done. You must be almost done". But then you look at everything else that's still isn't done yet. Brian Jones (00:53:23): Now thankfully, we're getting to the point where we can look at telemetry and say, "Hey, we've got most people covered." Most users, when we look at what they do in Windows, they could use the web app and shouldn't notice a difference. But there still is a set of things that we're going to keep churning through. So that'll continue to be a huge, huge investment for us. But yeah, the shared code strategy, we have an iPhone version, an iPad version an Android version. We've got Excel across all platforms. And because of the shared code, when we add new features, the feature crew that's working on that, they need to have a plan for how they're going to roll out across all those platforms, clearly levered shared code. But they also need to think through user experience and stuff like that too. Clearly a feature on a phone is going to behave differently than it's going to behave on a desktop. Rob Collie (00:54:05): Part of me, just like, kind of wants to just say, "I don't even believe that you've pulled that off, there's no way". It's kind of like, I've never looked at the Android version, and until I look at the Android version, I'm just going to assume it's not real. This is why it's one of the hardest things imaginable to have a single code base with all these different user experience, just fundamental paradigms of difference between these platforms. Like really? Come on. Brian Jones (00:54:34): It was a massively ambitious project. Mac shifted over maybe three years ago. And that's when, all of a sudden, in addition to a bunch of just features that people have been asking for that we'd never been able to get to, the massive one there was we were able to roll out the co-authoring multiplayer mode for Excel. Rob Collie (00:54:50): Multiplayer. Brian Jones (00:54:52): That's the term I like for co-authoring. It's more fun. Rob Collie (00:54:55): Yeah. It's like MMO for spreadsheets. Brian Jones (00:54:57): Yes. We were able to get that for the Mac. I mean, all of our platforms. One of us can be on an iPad, an iPhone, the web app, and we'll all see what we're doing in real time, making edits and all of that stuff. That alone, if you want to talk about massive projects, 30 years of features and innovation, basically that means we had to go and teach Excel how to communicate to another version of Excel and be very specific about, "This is what I did." "Here's the action I took." And that is massive. There are thousands and thousands of things you can do in the product. So getting it so that all of those versions are in sync the entire time, and so we're all seeing the exact same results of calc and all of that. That itself was a huge, massive project. Rob Collie (00:55:37): Take this as the highest form of praise when I say I don't buy it. I can't believe it. Brian Jones (00:55:44): I hope everybody's okay that we just talked for like an hour on just like listening to somebody at a high school reunion, I think, or something. Is this like me talking about how great I played in that one game? And you're like, "Yeah, that was a great basket". Rob Collie (00:55:54): Yeah. "Man, my jumper was on". the thing that's hard to appreciate, I think, is that you got to come back to the fact that we're talking about the tools that everyone in the world uses every day, that we rely on. And I think being gone from Microsoft for the last 12 years, I'm able to better appreciate that sense of wonder. This isn't just you and I catching up, I don't think. People enjoy, for good reason I think, hearing the stories of how these things came to be. People don't know by default how hard it was to get to a million rows in the file format. If you're like a robot, you're like, "I don't care how I got here. I just care what it is", then you're not listening to this show. We call it data with a human element. Robots can exit stage left. I think you should feel zero guilt. This isn't just self-indulgence. Brian Jones (00:56:55): Well, on the off chance everybody else ... I've listened to a lot of Rob's other podcasts, and they're awesome. So if you're bored with this one, it's okay. Go check out some of the other ones. They'r

Listen the Frontend News #11 - the podcast about tech and front end innovations with our hosts - Chris and Tommy K. Looking for a team for your project? Ask us for free consultation on https://frontendhouse.com. What is Frontend News #11 about? 00:00 - Intro00:47 - Contents1:53 - Chrome 92 boosts PWAPWA is Progressive Web Application - basically it is an application which can run in a browser and looks like an application: https://blog.chromium.org/2021/06/chrome-92-web-apps-as-file-handlers-new.html5:18 - DevTools updatesDevTools is a set of tools for web developers built into Google Chrome. https://developer.chrome.com/blog/new-in-devtools-92/ 8:47 - Node - Another great releaseNode is the regular guest of Frontend News as a bellowed by Frontend House developers JavaScript runtime on Chrome's V8 JavaScript engine: https://nodejs.org/en/blog/release/v16.3.0/ 10:38 - Happy Birthday Node!https://twitter.com/nodejs/status/1397914989931864080 11:00 - Maps and WebGL - what's in common?Web Graphics Library is a JavaScript API for rendering 3D and 2D graphics. https://cloud.google.com/blog/products/maps-platform/using-new-webgl-powered-maps-featuresCheck the video about projects for Google Maps: https://www.youtube.com/watch?v=WaTS9jctwuE&t=2s 13:29 - Electrifying Electron ReleaseElektron is a framework which enables building native applications with JavaScript, HTML, and CSS. You can check releases here: https://www.electronjs.org/blog/electron-13-014:44 - React Components Librarieshttps://retool.com/blog/react-component-libraries/If you have any development issues or have an idea for application you can always contact our Frontend House experts and have a free consultation on https://frontendhouse.com/

About Patrick McFadinPatrick McFadin is the VP of Developer Relations at DataStax, where he leads a team devoted to making users of Apache Cassandra successful. He has also worked as Chief Evangelist for Apache Cassandra and consultant for DataStax, where he helped build some of the largest and exciting deployments in production. Previous to DataStax, he was Chief Architect at Hobsons and an Oracle DBA/Developer for over 15 years.Twitter: @PatrickMcFadinLinkedIn: Patrick McFadin DataStax website: datastax.comK8ssandra: k8ssandra.ioStargate: stargate.ioDataStax Astra: Cassandra-as-a-ServiceWatch this episode on YouTube: https://youtu.be/-BcIL3VlrjEThis episode sponsored by CBT Nuggets and Fauna.TranscriptJeremy: Hi everyone, I'm Jeremy Daly and this is Serverless Chats. Today I'm chatting with Patrick McFadin. Hey Patrick, thanks for joining me.Patrick: Hi Jeremy. How are you doing today?Jeremy: I am doing really well. So you are the VP of Developer Relations at DataStax, so I'd love it if you could tell the listeners a little bit about yourself and what DataStax is all about.Patrick: Sure. Well, I mean mostly I'm just a nerd with a cool job. I get to talk about technology a lot and work with technology. So DataStax, we're a company that was founded around Apache Cassandra, just supporting and making it awesome. And that's really where I came to the company. I've been working with Apache Cassandra for about 10 years now. I've been a part of the project as a contributor.But yeah, I mean mostly data infrastructure has been my life for most of my career. I did this in the dotcom era, back when it was really crazy when we had dozens of users. And when that washed out, I'm like, oh, then real scale started and during that period of time I worked a lot in just trying to scale infrastructure. It seems like that's been what I've been doing for like 30 years it seems like, 20 years, 20 years, I'm not that old. Yeah. But yeah, right now, I spend a lot of my time just working with developers on what's next in Kubernetes and I'm part of CNCF now, so yeah. I just can't to seem to stay in one place.Jeremy: Well, so I'm super interested in the work that DataStax is doing because I have had the pleasure/misfortune of managing a Cassandra ring for a start-up that I was at. And it was a very painful process, but once it was set up and it was running, it wasn't too, too bad. I mean, we always had some issues here and there, but this idea of taking a really good database, because Cassandra's great, it's an excellent data store, but managing it is a nightmare and finding people who can manage it is sort of a nightmare, and all that kind of stuff. And so this idea of taking these services and DataStax isn't the only one to do this, but to take these open-source services and turn them into these hosted solutions is pretty fantastic. So can you tell me a little bit more, though? What this shift is about? This moving away from hosting your own databases to using databases as a service?Patrick: Yeah. Well, you touched on something important. You want to take that power, I mean Cassandra was a database that was built in the scale world. It was built to solve a problem, but it was also built by engineers who really loved distributed computing, like myself, and it's funny you say like, "Oh, once I got it running, it was great," well, that's kind of the experience with most distributed databases, is it's hard to reason around having, "Oh, I have 100 mouths to feed now. And if one of them goes nuts, then I have to figure it out."But it's the power, that power, it's like stealing fire from the gods, right? It's like, "Oh, we could take the technology that Netflix and Apple and Facebook use and use it in our own stuff." But you got to pay the price, the gods demand their payment. And that's something that we've been really trying to tackle at DataStax for a couple of years now, actually three, which is how ... Because the era of running your own database is coming to an end. You should not run your own database. And my philosophy as a technologist is that proper, really important technology like your data layer should just fade into the background and it's just something you use, it's not something you have to reason through very much.There's lots of technology that's like that today. How many times have you ... When was the last time you managed your own memory in your code?Jeremy: Right. Right. Good point. I know.Patrick: Thank god, huh?Jeremy: Exactly.Patrick: Whew.Jeremy: But I think that you make a really good point, because you do have these larger companies like Facebook or whatever that are using these technologies and you mentioned data layers, which I don't think I've worked for a single company, I don't think I actually ... I founded a start-up one time and we built a data layer as well, because it's like, the complexity of understanding the transaction models and the routing, especially if you're doing things like sharding and all kinds of crazy stuff like that, hiding that complexity from your developers so that they can just say, "I need to get this piece of information," or, "I need to set this piece of information," is really powerful.But then you get stuck with these data layers that are bespoke and they're generally fragile and things like that, so how is that you can take data as a service and maybe get rid of some of that, I don't know, some of that liability I guess?Patrick: Yeah. It's funny because you were talking about sharding and things like that. These are things that we force on developers to reason through, and it's just cognitive load. I have an app to get out, and I have some business desire to get this application online, the last thing I need to worry about is my sharding algorithm. Jeremy, friends don't let friends shard.Jeremy: Right. That's right. That's a good point.Patrick: But yeah, I mean I think we actually have all the parts that we need and it's just about, this is closer than you think. Look at where we've already started going, and that is with APIs, using REST. Now GraphQL, which I think is deserving its hotness, is starting to bring together some things that are really important for this kind of world we want to live in. GraphQL is uni-fettering data and collecting and actual queries, it's a QL, and why they call it Graph, I have no idea. But it gives you this ability to have this more abstract layer.I think GraphQL will, here's a prediction is that it's going to be like the SQL of working with data services on the internet and for cloud-native applications. And so what does that mean? Well, that means I just have to know, well, I need some data and I don't really care what's underneath it. I don't care if I have this field indexed or anything like that. And that's pretty exciting to me because then we're writing apps at that point.Jeremy: Right. Yeah. And actually, that's one of the things I really like about GraphQL too is just this idea that it's almost like a universal data access layer in a sense because it does, you still have to know it, you have to know what you're requesting if you're an end developer, but it makes it easier to request the things that you need and have those mutations set and have some of those other things standardized across the company, but in a common format because isn't that another problem? Where it's like, I'm working with company A and I move to company B maybe and now company B is using a different technology and a different bespoke data layer and some of these other things.So, I think data as a service for one, maybe with GraphQL in front of it is a great way to have this alignment across companies, or I guess, just makes it easier for developers to switch and start developing right away when they move into a new company.Patrick: Yeah, and this is a concept I've been trying to push pretty hard and it's driven by some conversations I've had with some friends that they're engineering leaders and they have this common desire. We want to have a zero day dev, which is the first day that someone starts, they should be producing production code. And I don't think that's crazy talk, we can do this, but there's a lot of things that are in front of it. And the database is one of them. I think that's one of the first things you do when you show up at company X is like, "Okay, what database are you using? What flavor of SQL or GRPC or CQL, Cassandra query language? What's the data model? Quick, where's that big diagram on the wall with my ERD? I got to go look at that for a while."Jeremy: How poorly did you structure your Git repositories? Yeah.Patrick: Yeah, exactly. It's like all these things. And no, I would love to see a world where the most troublesome part of your first day is figuring out where the coffee and the bathroom are, and then the rest of it is just total, "Hey, I can do this. This is what I get paid to do."Jeremy: Right. Yeah. So that idea of zero day developer, I love that idea and I know other companies are trying to do that, but what enables that? Is it getting the idea of having to understand something bespoke? Is it getting that off of the table? Or not having to deal with the low-level database aspect of things? I mean because APIs, I had this conversation with Rob Sutter, actually, a couple weeks ago. And we were talking about the API economy and how everything is moving towards APIs. And even data, it was around data as well.So, is that the interface, you think, of the future that just says, "Look, trying to interface directly with a database or trying to work with some other layer of abstraction just doesn't make sense, let's just go straight from code right to the data, with a very simple API interface?"Patrick: Yeah, I think so. And it's this idea of data services because if you think of if you're doing React, or something like a front-end code, I don't want to have a driver. Drivers are a total impediment. It's like, driver hell can be difficult at large organizations, getting the matching right. Oh, we're using this database so you have to use this driver. And if you don't, you are now rejected at the gate. So it's using HTTP protocols, but it's also things like when you're using React or Angular, View, whatever you're using on the front-end, you have direct access.But most times what you're needing is just a collection or an object. And so just do a get, "I need this thing right now. I'm doing a pick list. I need your collection." I don't need a complicated setup and spend the first three days figuring out which driver I'm using and make sure my Gradle file is just perfect. Yeah. So, I think that's it.Jeremy: Yeah. No, I'd be curious how you feel about ORMs, or O-R-Ms, certainly for relational databases, I know a lot of people love them. I can't stand them. I think it adds a layer of abstraction and just more complexity where I just want access to the database. I want to write the query myself, and as soon as you start adding in all this extra stuff on top of it to try to make it easier, I don't know, it just seems to mess it up for me.Patrick: All right. So yeah, I think we have an accord. I am really not a fan of ORMs at all. And I mean this goes back to Hibernate. Everyone's like, "Oh, Hibernate's going to be the end of databases." No, it's not. Oh yeah, it was the end of the database at the other side because it would create these ridiculous queries. It's like, why is every query a full table scan?Jeremy: Exactly.Patrick: Because that's the way Hibernate wanted it. Yeah. I actually banned Hibernate at one company I was working at. I was Chief Architect there and I just said, "Don't ever put Hibernate in our production." Because I had more meetings about what it was doing wrong than what it was doing right.Jeremy: Right. Right. Yeah. No, that's sounds, yeah.Patrick: Is that a long answer? Like, no.Jeremy: No, I've had the same experience where certain ORMs you're just like, no. Certain things, you can't do this because it's going to one, I think it locks you in in a sense, I mean there's all kind of lock-in in the cloud, and if you're using a data service or an API or you're using something native in AWS, or IBM Cloud, you're still going to be locked in in some way, but I do feel like whenever you start going down that path of building custom things, or forcing developers to get really low level, that just builds up all kinds of tech debt, right? That you eventually are going to have to work down.Patrick: Well, it's organizational inertia. When you start getting into this, when you start using annotations in Hibernate where you're just cutting through all the layers and now you're way down in the weeds, try to move that. There's a couple of companies that I've worked with now that are looking at the true reality of portability in their data stores. Like, "Oh, we want to move from one to a different, from a key value to a document without developers knowing." Well, how do you get to that point?Jeremy: Right. Yeah.Patrick: And it's just, that's not giving access to those things, first of all, but this is that tech debt that's going to get in your way. We're really good, technologists, we're really good at just wracking up the charges on our tech debt credit card, especially whenever we're trying to get things out the door quickly. And I think that's actually one of the problems that we all face. I mean, I don't think I've ever talked to a developer who was ahead of schedule and didn't have somebody breathing down their neck.Jeremy: Very true.Patrick: You take shortcuts. You're like, "We've got to shift this code this week. Skip the annotations and go straight into the database and get the data you need." Or something. You start making trade-offs real fast.Jeremy: What can we hard code that will just get us past.Patrick: Yeah. Is it green? Shift it. Yeah.Jeremy: Yeah, no, I totally, totally agree. All right. So let's talk a little bit more about, I guess, skillsets and things like that. Because there are so many different databases out there. Cassandra is just one and if you're a developer working just at the driver level, I guess, with something like Cassandra, it's not horrible to work with. It's relatively easy once a lot of these things are set up for you.Same is true of MongoBD, or I mean, DynamoDB, or any of these other ones where the interface to it isn't overly difficult, but there's always some sort of something you want to build on top of it to make it a little bit easier. But I'm just curious, in terms of learning these different things and switching between organizations and so forth, there is a cognitive load going from saying, "I'm working on Cassandra," to going to saying, "I'm working on DynamoDB," or something like that. There's going to be a shift in understanding of how the data can be brought back, what the limitations are, just a whole bunch of things that you kind of have to think about. And that's not even including managing the actual thing. That's a whole other thing.So, hiring people, I guess, or hiring developers, how much do we want developers to know? Are you on board with me where it's like, I mean I like understanding how Cassandra works and I like understanding how DynamoDB works, and I like knowing the limits, but I also don't want to think about them when I'm writing code.Patrick: Yeah. Well, it's interesting because Cassandra, one of the things I really loved about Cassandra initially was just how it works. As a computer scientist, I was like, "This is really neat." I mean, my degree field is in distributed computing, so of course, I'm going to nerd out.Jeremy: There you go.Patrick: But that doesn't mean that it doesn't have mass appeal because it's doing the thing that people want. And I think that's going to be the challenge of any properly built service layer. I think I've mentioned to you before we started this, I work on a project called Stargate. And Stargate is a project that is meant to build a data layer on top of databases. And right now it's with Cassandra. And it's abstracting away some of the harder to understand or reason things.For instance, with distributed computing, we're trying to reduce the reliance on coordination. There is a great article about this by Pat Helland about how coordination is the last really expensive thing that we have in development. Memory, CPU, super cheap. I can rent that all day long. Coordination is really, really hard, and I don't expect a new programmer to understand, to reason through coordination problems. "Oh, yeah, the just in time race conditions," and things like that.And I think that's where distributed computing, it's super powerful, but then whenever people see what eventual consistency are, they freak out and they're like, "I just want my SQL Lite on my laptop. It's very safe." But that's not going to get you there. That's not a global database, it's not going to be able to take you to a billion users. Come on, don't cut ...Jeremy: Maybe you don't need to be.Patrick: ... your apps short Jeremy. You're going to have a billion users.Jeremy: You should strive for it, at least, is how I feel about it. So that's, I guess, the point I was trying to get to is that if the developers are the ones that you don't want learning some of this stuff, and there's ways to abstract it away again, going like we talked about data as a service and APIs and so forth. And I think that's where I would love to see things shifting. And as you said earlier, that's probably where things are going.But if you did want to run your own database cluster, and you wanted to do this on your own, I mean you have to hire people that know how to do this stuff. And the more I see the market heating up for this type of person, there is very, very few specialists out there that are probably available. So how would you even hire somebody to run your Cassandra ring? They probably all work at DataStax.Patrick: No, not all of them. There's a few that work at Target and FedEx, Apple, the biggest Cassandra users in the world. Huawei. We just found out lately that Huawei now has the biggest cluster on the planet. Yeah. They just showed up at ApacheCon and said, "Oh yeah, hold my beer." But I mean, you're right, it's a specialized skillset and one of the things we're doing at DataStax, we feel, yeah, you should just rent that. And so we have Astra, which is our database as a service.It's fully compatible with open-source Cassandra. If you don't like it, you can just take it over and use open-source. But we agree and we actually can run Cassandra cheaper than you can, and it's just because we can do it at scale. And right now Astra, the way we run it is truly serverless, you only pay for what you need, and that's something that we're bringing to the open-source side of Cassandra as well, but we're getting Cassandra closer to Kubernetes internally.So if you don't want to think about Kubernetes, if you don't want to think about all that stuff, you can just rent it from us, or you could just go use it in open-source, either way. But you're right. I mean, it should not be a 2020s skillset is, "Get better at running Cassandra." I think those days should be, leave it to, if you want to go work at DataStax and run Cassandra, great, we're hiring right now, you will love it. You don't have to. Yeah.Jeremy: So the idea of it being open-source, so again, I'm not a huge fan of this idea of vendor lock-in. I think if you want to run on AWS Lambda, yeah, most of what you can do can only run on AWS Lambda, but changing the compute, switching that over to Azure or switching that over to GCP or something like that, the compute itself is probably not that hard to move, right? I think especially depending on what you're doing, setting up an entire Kubernetes cluster just to run a few functions is probably not worth it. I mean, obviously, if you've got a much bigger implementation, that's a little different.But with data, data is just locked in. No matter where you go, it is very hard to move a lot of data. So even with the open-source flair that you have there, do you still see a worry about lock in from a data side?Patrick: Yeah. And it's becoming more of a concern with larger companies too, because options, #options. There was a pretty famous story a few years ago where the CEO of Target said, "I am not paying Amazon any more money," and they just picked up shop and moved from AWS to Google Cloud. And the CEO made a technical decision. It was like everybody downstream had to deal with that. And I think that luckily Target's a huge Cassandra shop and they were just like, "Okay, we'll just move it over there."But the thing is that you're right, I mean, and I love talking about this because back when cloud was first starting and I was talking about it and thinking about it, just what do the clouds promise you? Oh, you get commodity scale of CPU and network and storage. And that's what they want to sell you because that what they're building. Those big buildings in north Virginia, they are full of compute network and storage, but the thing they know they need to hook you in and the way that they're hooking you in, there's some services that are really handy, they're great, but really the hook is the data.Once you get into the database, the bespoke database for the cloud, one of the features of that database is it will not connect to any other database outside of that cloud, and they know that. I mean, and this is why I really strongly am starting to advocate this idea of this move towards data on Kubernetes is a way where open-source gets to take back the cloud. Because now we're deploying these virtual data centers and using open-source technology to create this portability. So we can use the compute network and storage, a Google, Amazon, Azure, OnPrem wherever, doesn't matter.But you need to think of like, "All right. How is that going to work?" And that's why we're like, "If you rent your Cassandra from DataStax with Astra, you can also use the open-source Cassandra as well." And if we aren't keeping you happy, you should feel totally fine with moving it to an open-source workload. And we're good with that. One way or the other, we would love for you to use a database that works for you.Jeremy: Right. And so this Stargate project that you're working on, is that the one that allows you to basically route to multiple databases?Patrick: That's the dream. Right now it just does Cassandra, but there's been some really interesting ... There's some folks coming out of the woodwork that really want to bring their database technology to Stargate. And that's what I'm encouraged by. It's an open-source project, Stargate.io, and you can contribute any of the connectors for underlying data store, but if we're using GraphQL, if you're using GRPC, if you're using REST, the underlying data store is really somewhat irrelevant in that case. You're just doing gets and puts, or gets and sets. Gets and puts, yeah, that's right. Gets, sets, puts, it's a lot of words.Jeremy: Whatever words. Yeah. Exactly.Patrick: That's what I love about standard, Jeremy, there's so many to pick from.Jeremy: Right, because there are ... Exactly, which standard do you choose? Yeah. So, because that's an interesting thing for me too, is just this idea of, I mean, it would be great to live in a perfect little cloud where you could say like, "Oh, well AWS has all the services I need. And I can just keep all my stuff there, whatever." But best of breed services, or again, the cost of hosting something in AWS maybe if you're hosting a Cassandra cluster there, versus maybe hosting it in GCP or maybe hosting it with you, you said you could host it cheaper than those could, or that we could host it ourselves.And so I do think that there is ... and again, we've had this conversation about multi-cloud and things like that where it's not about agnostic, it's not about being cloud agnostic, it's about using the best of breed for any service that you want to use. And APIs seem to be the way to get you there. So I love this idea of the Stargate project because it just seems like that's the way where it could be that standard across all these different clouds and onto all these different databases, well I mean, right now Cassandra, but eventually these other ones. I don't know, that seems like a pretty powerful project to me.Patrick: Well, the time has come. It's cloud native ... I work a lot with CNCF and cloud-native data is a kind of emerging topic. It's so emerging that I'm actually in the middle of writing a book, an O'Reilly book on it. So, yeah. Surprise. I just dropped it. This just in.Yeah, because I can see that this is going to be the future, but when we build cloud-native, cloud applications, cloud-native applications, we want scale, we want elasticity, and we want self-healing. Those are the three cloud-native things that we want. And that doesn't give us a whole lot ... So if I want to crank out a quick REACT app, that's what I'm going to use. And Netlify's a great example, or Vercel, they're creating this abstraction layer. But Netlify and Vercel are both working, they've been partnering with us on the Stargate project, because they're seeing like, "Okay, we want to have that very light touch, developers just come in and use it," in building cloud-native applications.And whenever you're building your application, you're just paying for what you use. And I think that's really key, not spinning up a bunch of infrastructure that you get a monthly bill for. And that bill can be expensive.Jeremy: It seems crazy. Doesn't it seem crazy nowadays? Actually provisioning an EC2 instance and paying for it to run even if it does nothing. That seems crazy to me.Patrick: There are start-ups around the idea of finding the instance that's running that's causing you money that you're not using.Jeremy: Which is crazy, isn't it? It's crazy. All right. So let's go a little bit more into standards, because you mentioned standards. So there are standards now for a lot of things, and again, GraphQL being a great example, I think. But also from a database perspective, looking at things like TSQL and developers come into an organization and they're familiar with MySQL, or they're familiar with PostgreSQL, whatever it is. Or maybe they're familiar with Cassandra or something like that, but I think most people, at least from what I've seen, have been very, very comfortable with the TSQL approach to getting data. So, how do you bring developers in and start teaching them or getting them to understand more of that NoSQL feel?Patrick: I think it's already happened, it's just the translation hasn't happened in a lot of minds. When you go to build an application, you're designing your application around the workflows your application's going to have. You're always thinking about like, "I click on this. I go there." I mean, this is where we wireframe out the application. At that point, your database is now involved and I don't think a lot of folks know that.It's like, at every point you need to put data or get data. And I think this is where we've taught could be anybody building applications, which makes it really difficult to be like, "No, no, no, start with your data domain first and build out all those models. And then you write your application to go against those models." And I'll tell you, I've been involved in a few of these application boot camps, like JavaScript boot camps and things, they don't go into data modeling. It's just not a part of it.Jeremy: Really?Patrick: And I think this is that thing where we have to acknowledge like, "Yeah, we don't really need that anymore as much, because we're just building applications." If I build a React app, and I have a form and I'm managing the authentication and I click a button and then I get a profile information, I just described every database interaction that I need and the objects that I need. And I'm going to put my user profile at some point, I'm going to click my ID and get that profile back as an object. Those are the interactions that I need. At no point did I say, "And then I'm going to write select from where." No, I just need to get that data.Jeremy: And I love thinking about data as objects anyways. It makes more sense, rather than rows of spreadsheets essentially that you join together, describing an object even if it's got nested data, like a document form or things like that, I think makes a ton of sense. But is SQL, is it still relevant do you think? I mean, in the world we're moving into? Should I be teaching my daughters how to write TSQL? Or would I be wasting my time?Patrick: Yeah. Well, yes and no. Depends on what your kid's doing. I think that SQL will go to where it originally started and where it will eventually end, which is in data engineering and data science. And I mean, I still use SQL every once in a while, Bigtable, that sort of thing, for exploring my data. I mean for an analytics career or reporting data and things like that, SQL is very expressive. I don't see any reason to change that. But this is a guy who's been writing SQL for a million years.But I mean, that world is still really moving. I mean, like a Presto and Snowflake and all these, Redshift, they all use Bigtable, they all use SQL to express the reporting capabilities. But ... And I think this is how you and I got sucked into this is like, well that was the database that we had, so we started using reporting languages to build applications. And how'd that work out?Jeremy: Yeah. Well, it certainly didn't scale very well, I can tell you that, going back to sharding, because that is always something that was very hard to do. So I guess, I get the point that essentially if you're going to be in the data sciences and you actually need to analyze that data and maybe you do need to do joins, or maybe you need to work with big data in a way, that's a specialized aspect of it and I think people could dabble in that if they were just regular developers and they didn't want to go too deep.But it sounds like the bigger, or the end goal here, maybe altruistic, is to just give people access to data. So even if they don't know SQL or they don't know something complex, just make it so that whatever data is there that anybody, with whatever level is, they can consume it.Patrick: Yeah. And move fast with the thing that you're building. Actually, I use a Facebook term, but Facebook does do this. Internally there's a system called Occhio that provides gets and puts for your data, but it abstracts things like geographics and things like that. But the companies that are trying to move quickly, they understood this a long time ago. If you have to reason through, "Am I doing a full table scan? Is that an efficient interjoin?" If you have to reason through that, you're not moving fast anymore.Jeremy: Right. Right. All right. Cool. All right, so let's talk about Astra a little bit more and this whole idea of, because Astra is the serverless version, the hosted version, the serverless version of Cassandra, right? Through DataStax?Patrick: Right. And ...Jeremy: Did I get that right?Patrick: You got it right. And so it gives you full access. You could do Port 9042 if you still want to use a driver, but it gives you access via GraphQL, REST, and there's also a document API. So if you just want to persist your JavaScript API or JavaScript and then pull it back out your JSON, it does full documents. So it emulates what a MongoDB or DocumenDB does. But the important thing, and this is the somewhat revolutionary side of this, and again, this is something that we're looking to put into open-source, is the serverless nature of it.You only pay for what you use. And when you want to create a Cassandra database, we don't even call it a Cassandra database on the Astra panel anymore. We just create a database. You give it a name. You click. And it's ready. And it will scale infinitely. As long as we can find some compute and network for you to use somewhere, it'll just keep scaling and that's kind of that true portion of serverless that we're really trying to make happen. And for me, that's exciting because finally, all that power that I feel like I've been hoarding for a long time is now available for so many more people.And then if you do a million writes per second for 10 minutes and then you turn it off, you only pay for that little short amount of time. And it scales back. You're not paying a persistent charge forever.Jeremy: I'm just curious from a technical implementation, because I'm thinking about PTSD or nightmares back of my days running Cassandra, and so I'm just trying to think how this works. Is it a shared tenancy model? Or is there a way to do single tenancy if you wanted that as a service?Patrick: Under the covers, yes, it is multi-tenant, but the way that we are created ... so we had to do some really interesting engineering inside. So my RCO's going to kill me if I talk about this, but hey, you know what, Jeremy? We're friends, we can do this. He's like, "Don't talk about the underlying architecture." I'm talking about the underlying architecture. The thing that we did was we took Cassandra and we decomposed it into microservices mostly. That's probably, it's still Cassandra, it's just how we run it makes it way more amenable to doing multi-tenant and scale in that fashion where the queries are separated from the storage and things that are running in the background, like if you're familiar with Cassandra because it's a log structure storage, you ask to do compactions and things like that, all that's just kind of on the side. It doesn't impact your query.But it gives us the ability to, if you create a database and all of a sudden you just hammer it with a million writes per second, there's enough infrastructure in total to cover it. And then we'll spin up more in the back to cover everything else. And then whenever you're done, we retract it back. That's how we keep our costs down. But then the storage side is separated and away from the compute side, and the storage side can scale its own way as well.And so whenever you need to store a petabyte of Cassandra data, you're just storing, you're just charged for the petabyte of storage on disk, not the thousandth of a cluster that you just created. Yeah.Jeremy: No. I love that. Thank you for explaining that though, because that is, every time I talk to somebody who's building a database or running some complex thing for a database, there's always magic. Somebody has to build some magic to make it actually work the way everyone hopes it would work. And so if anybody is listening to this and is like, "Ah, I'm just getting ready to spin up our own Cassandra ring," just think about these things because these are the really hard problems that are great to have a team of people working on that can solve this specific problem for you and abstract all of that crap away.Patrick: Yeah. Well, I mean it goes back to the Dynamo paper, and how distributed databases work, but it requires that they have a certain baseline. And they're all working together in some way. And Cassandra is a share-nothing architecture. I mean you don't have a leader note or anything like that. But like I said, because that data is spread out, you could have these little intermittent problems that you don't want to have to think about. Just leave that to somebody else. Somebody else has got a Grafana dashboard that's freaking out. Let them deal with it. But you can route around those problems really easily.Jeremy: Yeah. No, that's amazing. All right. So a couple more technical questions, because I'm always curious how some of these things work. So if somebody signs up and they set up this database and they want to connect to it, you mentioned you could use the driver, you mentioned you can use GraphQL or the REST API, or the Document API. What's the authentication method look like for that?Patrick: Yeah. So, it's a pretty standard thing with tokens. You create your access tokens, so when you create the database, you define the way that you access it with the token, and then whenever you connect to it, if you're using JavaScript, there's a couple of collection libraries that just have that as one of the environment variables.And so it's pretty standard for connecting the cloud databases now where you have your authentication token. And you can revoke that token at any time. So for instance, if you mistakenly commit that into your Git ...Jeremy: Say GitHub. We've never done that before.Patrick: No judging. You can revoke it immediately. But it also gives you our back, the controls over it's a read or write or admin, if you need to create new tables and that sort of thing. You can give that level of access to whatever that token is. So, very simple model, but then at that point, you're just interacting through a REST call or using any of the HTTP protocols or SQL protocol.Jeremy: And now, can you create multiple tokens with different levels of permission or is it all just token gives you full access?Patrick: No, it's multiple levels of protection and actually that's probably the best way to do it, for instance, if your CI/CD system, has the ability to, it should be able to create databases and tear them down, right? That would be a good use for that, but if you have, for instance, a very basic application, you just want it to be able to read and write. You don't want to change any of the underlying data structures.Jeremy: Right. Right.Patrick: That's a good layer of control, and so you can have all these layers going on one single database. But you can even have read-only access too, for ... I think that's something that's becoming more and more common now that there's reporting systems that are on the side.Jeremy: Right. Right. Good.Patrick: No, you can only read from the database.Jeremy: And what about data backups or exporting data or anything like that?Patrick: Yeah, we have a pretty rudimentary backup now, and we will probably, we're working on some more sophisticated versions of it. Data backup in Cassandra is pretty simple because it's all based on snapshots because if you know Cassandra the database, the data you write is immutable and that's a great way to start when you come to backup data. But yeah, we have a rudimentary backup system now where you have to, if you need to restore your data, you need to put in a ticket to have it restored at a certain point.I don't personally like that as much. I like the self-service model, and that's what we're working towards. And with more granularity, because with snapshots you can do things like snapshot, this is one of the things that we're working on, is doing like a snapshot of your production database and restoring it into a QA cluster. So, works for my house, oh, try it again. Yeah.Jeremy: That's awesome. No, so this is amazing. And I love this idea of just taking that pain of managing a database away from you. I love the idea of just make it simple to access the data. Don't create these complex things where people have to build more, and if people want to build a data access layer, the data access layer should maybe just be enforcing a model or something like that, and not having to figure out if you're on this shard, we route you to this particular port, or whatever. All that stuff is just insane, so yeah, I mean maybe go back to kind of the idea of this whole episode here, which is just, stop using databases. Start using these data services because they're so much easier to use. I mean, I'm sure there's concerns for some people, especially when you get to larger companies and you have all the compliance and things like that. I'm sure Astra and DataStax has all the compliance things and things like that. But yeah, just any final words, advice to people who might still be thinking databases are a good idea?Patrick: Well, I have an old 6502 on a breadboard, which I love to play with. It doesn't make it relevant. I'm sorry. That was a little catty, wasn't it?Jeremy: A little bit, but point well taken. I totally get what you're saying.Patrick: I mean, I think that it's, what do we do with the next generation? And this is one of the things, this will be the thought that I leave us with is, it's incumbent on a generation of engineers and programmers to make the next generation's job easier, right? We should always make it easier. So this is our chance. If you're currently working with database technology, this is your chance to not put that pain on the next generation, the people that will go past where you are. And so, this is how we move forward as a group.Jeremy: Yeah. Love it. Okay. Well Patrick, thank you so much for sharing all this and telling us about DataStax and Astra. So if people want to find out more about you or they want to find out more about Astra and DataStax, how do they do that?Patrick: All right. Well, plenty of ways at www.datastax.com and astra.datastax.com if you just want the good stuff. Cut the marketing, go to the good stuff, astra.datastax.com. You can find me on LinkedIn, Patrick McFadin. And I'm everywhere. If you want to connect with me on LinkedIn or on Twitter, I love connecting with folks and finding out what you're working on, so please feel free. I get more messages now on LinkedIn than anything, and it's great.Jeremy: Yeah. It's been picking up a lot. I know. It's kind of crazy. Linked in has really picked up. It's ...Patrick: I'm good with it. Yeah.Jeremy: Yeah. It's ...Patrick: I'm really good with it.Jeremy: It's a little bit better format maybe. So you also have, we mentioned the Stargate project, so that's just Stargate.io. We didn't talk about the K8ssandra project. Is that how you say that?Patrick: Yeah, the K8ssandra project.Jeremy: K8ssandra? Is that how you say it?Patrick: K8ssandra. Isn't that a cute name?Jeremy: It's K-8-S-S-A-N-D-R-A.io.Patrick: Right.Jeremy: What's that again? That's the idea of moving Cassandra onto Kubernetes, right?Patrick: Yeah. It's not Cassandra on Kubernetes, it's Cassandra in Kubernetes.Jeremy: In Kubernetes. Oh.Patrick: So it's like in concert and working with how Kubernetes works. Yes. So it's using Cassandra as your default data store for Kubernetes. It's a very, actually it's another one of the projects that's just taking off. KubeCon was last week from where we're recording now, or two weeks ago, and it was just a huge hit because again, it's like, "Kubernetes makes my infrastructure to run easier, and Cassandra is hard, put those together. Hey, I like this idea."Jeremy: Awesome.Patrick: So, yeah.Jeremy: Cool. All right. Well, if anybody wants to find out about that stuff, I will put all of these links in the show notes. Thanks again, Patrick. Really appreciate it.Patrick: Great. Thanks, Jeremy.

Добрый день уважаемые слушатели. Представляем новый выпуск подкаста RWpod. В этом выпуске: Ruby Ruby 3 JIT can make Rails faster A robust distributed locking algorithm based on Google Cloud Storage Automatically avoiding GraphQL N+1s Limit your automatic retries Hybrid iOS apps with Turbo Lamby - simple Rails & AWS Lambda Integration Generate Pixel Art Characters, Algorithmically RailsConf 2021 (videos) Web The future of Internet Explorer on Windows 10 is in Microsoft Edge Sublime Text 4 released Introducing WebContainers: Run Node.js natively in your browser JavaScript API to Recognize Humans vs Bots in Chrome Bottery - a conversational agent prototyping platform Harold - a simple tool that provides a ready-to-use template for creating your static websites and blogs DOM Events - a way to visualize and experiment with the DOM event system Doom Captcha RWpod Cafe 22 (05.06.2021) Сбор и голосование за темы новостей

This talk will discuss why we think that JavaScript is a good language option for IoT development by walking you through a loosely coupled end to end IoT system, from new device on-boarding to remote access via gateway. Technologies we have been used and/or contributed to for building the IoT system using JavaScript will be discussed. At each stage, GDPR compliance of these technologies will be looked into. To address the issue of resource restriction in embedded devices, we will introduce you to JerryScript, an ultra-light JavaScript engine by Samsung. It is followed by a comparison of popular JavaScript platforms based on JerryScript that provide direct JavaScript APIs to developers. The open gateway framework is node.js based and targets at decentralized ‘Internet of Things' with privacy and security in mind.

John: Welcome to Iteration, a podcast about programming, development, and design.John Intro — My name is John and I am a software developer for a home services startup.JP Intro — Hi, I'm JP and I am a software developer at a small analytics startuphttps://macwright.com/2020/05/10/spa-fatigue.htmlTopics / Guiding QuestionsWhat's a SPA?From the articleThe main UI is built & updated in JavaScript using React or something similar.The backend is an API that that application makes requests against.The more techincal one:https://developer.mozilla.org/en-US/docs/Glossary/SPAAn SPA (Single-page application) is a web app implementation that loads only a single web document, and then updates the body content of that single document via JavaScript APIs such as [XMLHttpRequest]() and Fetch when different content is to be shown.This therefore allows users to use websites without loading whole new pages from the server, which can result in performance gains and a more dynamic experience, with some tradeoff disadvantages such as SEO, more effort required to maintain state, implement navigation, and do meaningful performance monitoring.Why do developers choose SPAs? Do end-users care about SPAs?What SPAs have you worked on / maintained?0 —When should you reach for a SPA?That's the right use case: Desktop app to the web.Spotify, Figma, photopea.comBreaks REST might be a good time to considerCommunityWhat's wrong with this SPA's?Increased complexity — Development and deploymentOften times: 2 repositories, 2 languages or frameworks(Rails + Vue)(Node + Angular)(Rails + React)SEO + Speed — Have to do "Server Side Rendering"This reminds me of the light switches for "Smart" light bulbs. You've increased the complexity by a factor of 10 to get the exact same results.Maintainability? Stability?If not a SPA then what? (Is this a different Episode?)What's good about server rendered?How much you get for freeAsync fetchingState managementURL's just workStrong ConventionsStable minimal maintenanceWhat's bad about Server Rendered?Page ReloadCan feel clunkyLess ReactiveMobile App — Now what? SPA lays a stronger groundworkWhat's good about SPA'sBenefits are for the userDeveloper Ego'sData foundationsBreaks CRUDCommunityPushing technology forward is a good thing.What's bad about SPA'sHow much of a pain in the ass it is to Manage URL'sComplexity — Front end + Back endAuthenticationImage UploadMultiple API endpoints for a single pageState is way harder in a SPADebuggingClosing ThoughtsSPA's are great when you are breaking "REST / CRUD"SPA's are great when you need multiple consumers of the same dataThis is highly personal, you gotta go with what you love.WiFiPicksJohn — Distraction Free Phone from the book Make TimeMobile: Uninstall all "Infinity Pools" put "Parental controls" on for the rest. 3.5 hours down to 1 hour screen time. So much time back. Switched out twitter for Kindle.Other tip: Instagram Threads — only the shit you care about with no adsDesktop: https://selfcontrolapp.com/ —JP - https://railsnew.io/

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

Quick show notes Our Guest: Brad Garropy What he'd like for you to see: His Twitch Streams | His Discord Community His JAMstack Jams: Netlify | FaunaDB | The "A" in the JAMstack His Musical Jams: Kolby Cooper | Artists on his Daily Texas Country site Transcript Bryan Robinson 0:01 Welcome back, Jamstackers! It's been a bit of time since last we talked, but I'm so glad to be back with you. You're listening to That's My Jamstack the podcast where we asked a timeless, ageless and incomparable question. What is your jam in the Jamstack? I'm your host, Bryan Robinson. And this week on the show, we have Brad Garropy. Brad is a lead front end developer at Adobe by day and a live code streamer by night. Bryan Robinson 0:46 All right. Well, Brad, thanks for being on the show with us today. Can you tell us a little bit about yourself? Brad Garropy 0:50 Yeah, absolutely. I'm a recently promoted lead front end developer at Adobe. And the job description basically entails that I build SAS services for the Magento ecommerce platform, as you mean like Software as a Service things or another definition of SAS? Yeah, software as a service. So imagine things like product recommendations or search that can be kind of tacked on to the e commerce store. So what do you do for fun that if that's what you do for work? Yeah, well, definitely for fun, I do a lot of programming and side projects, but away from the computer, I really like to work out I'm into bodybuilding, powerlifting, running, all those types of things. Bryan Robinson 1:31 Awesome. So so what what kind of, is it like strength training? Is it are you doing like a Olympic league? Like overhead presses for your powerlifting? What what's that entail? Brad Garropy 1:41 Yeah, like my training splits are typically like this, they start off with one of those powerlifting movements like your, like your bench press, or your squat, your deadlift. And then the rest of the training session kind of focuses around bodybuilding movements like to, to really stress out and tear down the muscles. Bryan Robinson 1:59 That sounds awful from somebody who doesn't do a whole lot working. Brad Garropy 2:03 You know, it's funny, I found that a lot of developers actually take well to powerlifting. Because it's a it's usually a very structured program with progression and percentages and numbers. And I think developers just feel right at home when they have a lot of structure to training. Bryan Robinson 2:22 Yeah, that makes sense. It's kind of a logical, like I said, the progression is a logical thing. And that tends to play well with the way our brains work. Brad Garropy 2:29 Exactly. Bryan Robinson 2:31 Nice. So so this is a Jamstack podcast, let's talk about the Jamstack. A little bit, what was your entry point into this idea of other static sites or Jamstack? As we can know it today? Brad Garropy 2:40 Yeah, it was interesting. I, I started learning web development at a really volatile time, like create react app was just coming out. And this notion of front end frameworks was just really picking up and my entry point into Jamstack, was trying to make my first blog. And I had to think about, you know, how do I source data but still make hosting cheap and free and easy? Yeah. Right. So Gatsby was one of the first tools that I got to reach for I did run Jekyll for just a little bit there. But Ruby, Ruby is difficult to work with. Bryan Robinson 3:18 Yeah, definitely as a as if, especially if you're coming from like a front end development perspective. And you also often have to do Ruby work, like that just doesn't feel quite right. Brad Garropy 3:26 Yeah, like my learning path was like HTML, CSS. What is this Jekyll thing? You know? Yeah. So eventually, I kind of switched over to Gatsby and kind of hopped on the train with everybody else about like, this is kind of how you source data and and pre generate pages, which made hosting, you know, easy, simple and free, which is I'm a big proponent of free Bryan Robinson 3:51 Free is definitelya nice thing, especially especially in like side projects like that. Like, if you got a budget at work, like, that's cool. You can use that budget, but when you just want to blog, like, I don't want to pay $10 a month in hosting for that blog. Brad Garropy 4:03 Yeah, and, and Jamstack is really cool, especially with that philosophy, because there's so many services around the Jamstack, that the way they work is they offer free tiers and free tiers just good enough for my use case, you know, I haven't built anything that's kind of broken out of that free tier. Bryan Robinson 4:22 Yeah, I think it's one of those things where if a developer is using it on their personal projects, or their little side projects that like, they may then want to use that for bigger projects at work, and they may find more enterprise clients that way, something along those lines. Brad Garropy 4:36 Exactly, yeah, they they, they can bait you in with some really good premium features, or just essentially just like scalability. Yeah, definitely like that. The scaling is always a always a fun challenge to not have to worry about yourself. Absolutely. I I see my back end team at work constantly like thinking about how do we use Kubernetes to scale our API infrastructure and what happens when, you know, we released this to the public and there's 100,000 requests in, you know, 30 minutes. And they have so much to worry about with with us front end folks and the Jamstack technologies, you kind of make your HTML pages, add in a little JavaScript for interactivity and API calls, and they just get cached and served as kind of works in the end. So you talked about building a blog. So obviously, you've you've used Jamstack, a little bit personally, but how are you using these philosophies? professionally now, but also a little bit more on the personal side, too? Yeah. So the blog, it's Brad garrett.com, it was my entry point into kind of building a site with real data and content. But I built many other like side projects that stemmed from there that kind of gave me my my base as a front end developer. So I built like, a little website for my wife's photography business that was done on the Jamstack. I built daily, Texas country.com, which is like a Texas country music focused blog and community website, and that sources data from all sorts of different places, and it uses Gatsby for that data sourcing. And I've even built things on the Jamstack. Not using like Gatsby and react, I built a svelte application that, in my opinion, still very much adheres to the Jamstack to track workouts. Bryan Robinson 6:29 Okay, cool. So so it's like when you say, it still adheres to the kind of Jamstack philosophy? What do you kind of see as that as that philosophy? Because a lot of people have different definitions of it. Brad Garropy 6:40 They do. Yeah. So it folks listening to the show probably know, Jamstack stands for JavaScript API's and markup. And so this workout timer application is a single page application that I still believe falls into the realm of Jamstack. A single page application is still delivering HTML, which is your index dot HTML file just happens to be pretty blank, although you can kind of pre generate the shell of the application, and then populate data inside of there. So this application is just a timer that runs and you can go to a page, if you're logged in, where you can fetch your previous workouts, it saves it up to fauna, db. Bryan Robinson 7:29 Oh, nice. Very cool. So. So also, I'm kind of curious, you said that the daily Texas country it was a it was a Texas country music blog, but also a community. What's the community aspect? And how's that playing with the Jamstack? Brad Garropy 7:42 Yeah, I suppose what I mean is like, I'm trying to bring the community together on that website. So I make a bunch of different types of content. So I'll source YouTube videos that I make I'll source blog articles, and all sorts of playlists to try to get folks to gather at that website. There. I see that confusion there. There was no like, notion of a user or a member where there's comments or anything, I kind of use the other platforms for that. Bryan Robinson 8:07 I gotcha. And you're sourcing those and pulling them in. You said via the Gatsby source stuff. Right. Right. Unknown Speaker 8:13 Yeah. Bryan Robinson 8:13 Cool. Cool. So So we've talked a little bit about Gatsby, but what is kind of your jam in the Jamstack? What's your favorite service or philosophy framework, etc. Brad Garropy 8:24 Man, I think this is the really cool part about the Jamstack. And this is where the A in the Jamstack kind of plays an important role. So like, first of all, hosting on the Jamstack is great. Netlify is a tool that's universally loved. And I am no exception. They they make posting your files easy integrating with GitHub easy. It makes hosting serverless functions easy. And even doing things like DNS management easy. If you opt into their DNS servers, you can do like redirects very easily or sub domains. Just easy is the word that comes to mind. That's on the hosting side. Another thing that I really like about the Jamstack is that there are so many services that support it. So this kind of brings me to like the A in Jamstack, where, if you're coming at it from a front end developer point of view, you can build a front end, but you're looking for like, what is it that might happen does? How do I connect it to services or databases, and that's where you kind of go searching for the A, the API's. And I think it leaves developers in an interesting, interesting place, they have to kind of choose what services to stitch together. And for some folks, that might be like, a good thing or a bad thing, because at the end of the day, if you're choosing to integrate a bunch of services together to create a product, you have to write a bunch of like Glue Code and you might reach more of like a fatigue and trying to determine what's the best service for CMS or a payment processor or a database? Bryan Robinson 10:07 Yeah. And you haven't mentioned, like the fact that you've got, you have to string these services together, you have to figure out what is that string? How do I actually do the stringing of those services? Brad Garropy 10:18 That's right, yeah. And this is where a lot of confusion can come into play. Or if if, for instance, one service isn't as flexible as you want. And now you have to like migrate to a new one, or if one service changes their pricing model, there's so much to consider. So I think a and Jamstack is fairly overloaded. When when all the services work well together, you just kind of you're picking apples from the tree, and life is dandy. But when you kind of run into problems, you really have to, like, interact with those services, support teams, or dev roles, and try to find answers. Bryan Robinson 10:53 So do you have any kind of like, best practices to like, try to avoid some of those those hiccups? Or are there any any kind of tips or tricks that you that you've had to implement as you've been building some of these things? Brad Garropy 11:07 Yes. So one approach that I've started taking was, don't rely on CMS, if you don't have to, if you don't have somebody else, that's going to be modifying data on your website, I would opt not to use a CMS. First of all, that means you can generally bring your content right into the repository, where the front end code is hosted. And it's co located, which is a good thing, you own your content at that point. What that does is it kind of helps saves you from like, integration problems with your front end build tools. Like for instance, I was using contentful for a while, and I found that there, Gatsby source plugin was missing some fields that I really, really wanted. And after working with, like their, their dev rails and and submitting like some issues, it was clear that like, this stuff just wasn't going to be resolved. So that was one of the things that kind of forced me to move content into my repository. Another thing is like development environments, if you use Netlify, for hosting, every one of your GitHub branches, is actually turned into its own subdomain on Netlify. So that you can have like, immutable deploys two branches that have previews of content that's not actually published, which is so helpful. And sometimes getting a CMS to do that can be kind of difficult. Bryan Robinson 12:34 There's definitely some overhead that kind of comes into play when you have to do that from a CMS or from any kind of API layer at that point. For sure. Brad Garropy 12:41 So like, I think mitigation wise is like, own as much code as you can without reinventing the wheel. And then if you have to use a service, find one that's fairly popular, or one that clicks with your mental model. And it just takes trying different services out to figure that out. I've recently worked with fauna DB as like a serverless first database. And I found that after understanding their query language, it really clicked with my mental model of like, this is how my Jamstack site is going to work with serverless. First database. Bryan Robinson 13:16 Yeah, well, and the interesting thing for me fun is actually was the first, like, no SQL like, schema list database that really clicked with me. Like, I'd used Firebase and some other stuff in the past, but never, never felt quite right. And then something about fauna just just hit me in the right spot. And I built a couple small apps with it now. Brad Garropy 13:38 Yep, yep, I built my Murphy app with it. And I'm pretty happy with it. And actually chose not to go with their graph qL implementation, I'm doing just their, I guess, their JavaScript library implementation. Bryan Robinson 13:51 And there's a lot of interesting things that you can do kind of in the in the back how they work to where they've got their their SQL query language, their fun a query language, and you actually build out complex queries as functions that they have. And then you can actually just submit one like line of JavaScript, and it runs that function on their on their servers, which can be really, really handy. Brad Garropy 14:12 Yeah, and I found it like, super helpful to build up a utility folder, or like a utility file with like a bunch of CRUD operations written out in SQL. So if you want to read all posts, or read a single post, or edit a post, and you just kind of build out those CRUD operations, then they're like building blocks you can use in your serverless functions, that, you know, you might have route handlers for each one, and then you just call out to that specific utility function. It just, it almost felt like I wrote kind of an express app without having to set up, like, all of the boilerplate, you know, and it was just really easy to deploy things to Netlify. Bryan Robinson 14:53 Yeah. And like the interesting thing to me too, is that like, honestly, the SQL language kind of broke my brain. In a little bit, it was, it was very difficult for me to get into. But there was a moment. And it was like two days into working with it. Were all of a sudden, like, it was like the matrix, I get all sudden, like, see my queries happening and like understand exactly where it was coming from. So there's definitely a hurdle there. It's it's a new language, but it's a, it can be very, very beneficial, I think, Brad Garropy 15:19 yeah, I was very lucky in that I had the help of dev REL from fauna, I was actually streaming and tagging them and everything that I was doing. Next thing, you know, I got a dev REL sitting in chat. And then he joined up on a Discord server that I'm in. And he, he really worked with me side by side to like, improve my queries, discuss options, I even got invited to like a feedback call where I could, you know, talk to them about the decisions I made and how I use fauna and areas I see for improvement. And that's another thing about the Jamstack. I just feel like, all the companies are very much like developer experience first, and they're willing to engage and they, they hire Developer Relations people, and they do a really good job at reaching out. Bryan Robinson 16:06 I think I wonder if that has anything to do with kind of the, to your point on the A in the Jamstack, the API layer and how you really do kind of need developers on your team to be able to to utilize the Jamstack properly. And I wonder if that's, you know, the defining characteristic of a Jamstack company, is how well, they manage their developer community, because that's, that's who really buys in and makes all this work. Brad Garropy 16:33 Yeah, like if A is truly kind of just a bunch of services that you have to go utilize. They have to know who their customers are, they have to know who they're delivering to. Bryan Robinson 16:43 Cool. So let's talk music. What's your actual jam right now? What's your favorite song or musician or I know you run a website about music. So hopefully, you've got some some hot takes here. Brad Garropy 16:52 Yeah, so that daily, Texas country website is all based around a playlist that has like 1200, Texas country songs, and it's actually 1200 Texas country songs. Oh, yeah. This is only like a very select subset of the ones that are curated by me, you know, so it's a it's a big genre, because it's a big state. You know what I mean? Yeah, definitely. Anyways, there's a up and coming kind of artist, he's 21 years old, just turned 21. His name is Colby Cooper, and I love like, basically everything that he does, Bryan Robinson 17:26 so it was out of curiosity. So what is Texas country as compared to country with a capital C? Brad Garropy 17:36 Yeah. Okay. So I think the main difference is a country that kind of comes out of Nashville, you kind of do like there's a natural epicenter of country music, and there's like a Texas epicenter of country music. And the difference is, the giant labels like Sony and Columbia are producing records out of Nashville, that that sound over produced, they use drum machines, they use snap tracks, all these different pop music elements in country music that Texas country music fans don't view as like traditional country music. Whereas in Texas, you're typically recording in like, a very modest studio. You expect to have like a fiddle in the band. That's definitely true. And there's like a steel guitar like more rich natural instrumentation, and then you typically just have like, Guys being very honest in lyrics just talking about everyday stuff. Bryan Robinson 18:35 Is Texas country that the hipster country of the country world. Brad Garropy 18:39 So I think i think i think Nashville folks looking in would say that, but I think Texas people looking out would say no, this this is the original We are the one true country. Bryan Robinson 18:50 Gotcha. Mind you. I'm from Tennessee, so I don't actually like the Nashville the Nashville scene. But uh, but I guess I guess it's been it's flavored my my knowledge of the genre. Brad Garropy 19:00 I think the coolest part about Texas country music is that like, you can go to a concert on any given Friday or Saturday night for like 15 bucks, you know, you're not going to have to pay $70 for an arena. See, you can go see your favorite artist right around the corner. You know, any given weekend. Bryan Robinson 19:18 Nice. Very cool. So is there anything that you would like to promote anything that you're doing that you really want out to the Jamstack community right now? Brad Garropy 19:25 Yeah, I'm actually like, a much smaller content creator than the crowd I hang out with. And so I would love to like try to build up my my Twitch and my Twitter a little bit more. So I'm Brad Garrett at Twitch. tv slash Brad GaryVee. I stream like weeknights, like 10pm fairly late. So I'm a night owl and Twitter. It's twitter.com slash Brad Garrett up. I try to tweet out some tips every now and then and just keep you all informed about the projects that I'm working on. Bryan Robinson 19:56 So what are you what are you streaming most nights? What what kind of code Are you working on? Brad Garropy 20:00 Yeah, I work on react. I work on feltz. But lately, it's been a lot of felt because of this Murphy app. I've been live streaming the entire development process of the Murphy app written in spelt on the front end and serverless functions and fauna DB on the back end. Bryan Robinson 20:18 Very cool. Well, I appreciate you coming on the show with us today. And I hope you keep doing some amazing things both at Adobe as well as in all these awesome side projects you got going on. Brad Garropy 20:27 Thanks a lot for having me, Brian. Bryan Robinson 20:30 Thanks again to Brad for coming on the show this week. And thanks to you, our listeners for listening each and every week, week after a week. Now sponsor time and I'm really really excited to talk to you about a free course that our friends at auth zero have released. This course is going to cover building a full stack Jamstack application with next j s, air table off zero and tailwind CSS. Now next j s is going to be the front end framework. You'll learn all about designing with tailwind CSS air table is going to be for your database. And of course, for authentication, we're going to be using auth zero. So to watch this course, head on over to a zero to slash full stack Jamstack for all the details. And of course thank you for sticking around to the end, listening to our sponsors, visiting our sponsors, all that good stuff. Until next time, keep doing amazing things on the web and keep things jamming Transcribed by https://otter.ai Intro/outtro music by bensound.com Support That's my JAMstack by donating to their Tip Jar: https://tips.pinecast.com/jar/thats-my-jamstack

Chris Castle, a Developer Advocate with Heroku, is joined by Tobie Langel, a longtime web developer and member of the World Wide Web Consortium, or W3C. The W3C is an organization where the standards that define the web are being built. It's a consortium of different industry players, like browser vendors,universities, and governments. These different stakeholders come together and decide how HTML, CSS, and JavaScript API should behave. The W3C effectively lays the groundwork for browsers to agree on how a website should look and behave. They do this through long, thought out processes of standardization. If each browser ends up implementing its own HTML tags or CSS rules, then the web would become fragmented, as sites would require you to use a specific browser. For something to become a W3C recommendation, two different browsers with different code bases need to successfully implement a specification. This is done to build confidence around an idea, to ensure that browser vendors understand it, as well as to identify ways which frontend developer will make use of the new technology. Much of the conversation between Tobie and Chris goes over how, exactly, this timeline works in practice. Links from this episode W3C is the main international standards organization for the World Wide Web Specref is an open source database of web standards PR Preview adds preview and diff to spec pull requests.

Quick show notes Our Guest: Jenn Creighton What she'd like for you to see: Her Twitter feed | React Day NYC | Thinkster React Component Course (coming soon) | useReactNYC Her JAMstack Jams: Gatsby | Netlify Her musical Jam: Halsey's You Should Be Sad Our sponsor this week: TakeShape Transcript Bryan Robinson 0:04 Welcome, welcome everyone to a new episode of that's my JAMstack the podcast where we explore the deepest parts of the developer psyche by asking, what's your jam in the JAMstack. On today's episode we're chatting with Jenn Creighton, Jenn is a conference speaker and the organizer of useReact NYC. She's also the front end architect for The Wing. Bryan Robinson 0:23 Also, this week, we have our amazing sponsor TakeShape. Find out more about their JAMstack content platforms stick around after the episode or head over to takeshape.io/thatsmyjamstack. Bryan Robinson 0:36 All right. Well, thanks for joining us on the podcast today, Jenn. Jenn Creighton 0:38 Thank you for having me. Bryan Robinson 0:40 Thanks. So tell us a little bit about yourself. What do you do for work? What do you do for fun, that sort of thing? Jenn Creighton 0:45 Sure. So I am a front end architect at a company called The Wing. We work on building out co working spaces that are really geared towards women. So we're thinking a lot about what women need in those spaces, and also there's a lot of networking events and things like that in our spaces. Jenn Creighton 1:03 So I'm the front end architect there, I lead all of front end. I help ensure our system stays healthy. I work on our technical decisions there. You can already tell I'm a lot of fun because I really love tech. And honestly, like what I do for fun, I'm usually at a conference. I'm usually speaking at a conference, I really, really enjoy giving technical talks. So you will find that I'm often at a conference, I travel a lot to do that. I did 14 conferences last year, which I won't be repeating but it was a lot of fun. I had a good time. And if I'm genuinely not doing any tech related things, I am probably with my cats or my puppy or I am sewing. I really enjoy sewing. Bryan Robinson 1:53 So I saw and I think this is on like your Noti.st profile, is your dog's name really Sailor Moon because that's amazing Jenn Creighton 2:00 Her name IS Sailor Moon. She is named after the you know, Sailor Guardian Sailor Moon and she's a little blonde dachsund and, and I grew up watching Sailor Moon. I loved that show. I would watch it so much. And when I was thinking of names for her, I really want something kind of fun. So I picked out that it's really great too, because when you tell people her name, you can tell if they watch the show or not. Because they're either That is amazing. Or they're Wow, that's a lot of a name. Bryan Robinson 2:35 I'll be honest, do you just call her Sailor Moon all the time. Jenn Creighton 2:39 We usually call her sailor or if she's being a bit sassy Miss moon. Bryan Robinson 2:43 That works that work. And any fun sewing projects that you're working on. Jenn Creighton 2:48 I actually haven't sold in a long time because of the mentioned 14 conferences. So actually did not so I think anything last year. No, that's not true. Wait, I took a sewing class in November as my like, you're gonna do it and I sewed a pair of pants for the first time I took a sewing class to like force myself into a non tech hobby, which is a good thing to do once in a while. Bryan Robinson 3:17 Yeah, especially 14 conferences in 12 months. How many how many months were filled with more than two conferences? Did you did you group together and how exhausting was that? Jenn Creighton 3:28 Some months were grouped together. Um, let's see, I think I know at least I did, in September, I did two. And I traveled really far for them. So I did JS Conf Korea, and Components Comf in Australia together. And I think I had some some weeks and breaks there but a couple of them were like, in the same month and so I would knock out like two or three in the same month and then have like a little bit of a break which usually Wasn't a break. Like between Components Conf and React Conf. I actually had to write my React Conf talk. Bryan Robinson 4:09 The glamour of being a conference speaker! Jenn Creighton 4:11 It's so not glamorous, it's so exhausting. And yet, we can like people who enjoy it can't stop doing it. I don't know if you remember this, but there was a survey that came out many many years ago that said that people are more afraid of public speaking than they are of death. And so conference speaking is actually like a near death experience. As you get like this ridiculous rush, you're terrified you feel great afterwards. You're like, I'll just do it again. Bryan Robinson 4:44 I just watched the the Imagineering story the the story of all like the Disney theme park building and all that. And it talks about all the all the rides and how the goal is to make people feel like they're about to die without getting them actually all the way to death. So it's the same basic principle just with public speaking. Jenn Creighton 5:01 I think that happens with code too, Like, I just spent two days solving this issue of my tests failing on circle ci when they weren't failing locally. And I wanted to die. I want to lay down and die. I was like, take me, Lord, now and then I figured it out. I felt great. Bryan Robinson 5:20 So this is a JAMstack podcast, let's talk about the JAMstack a little bit. What's been kind of your introduction into that world or into static sites or wherever you kind of came to it from? Jenn Creighton 5:30 I think with static sites, the first time I remember seeing like a static site generator was Jekyll. And this was back at a startup many, many years ago. I remember we used it for I believe our marketing site, which was like pretty typical. And I really didn't know that there would be static site generators. It was kind of surprising to me. But I also didn't really play with it because I was just trying to learn JavaScript. I was like, this is where I'm like, trying to figure things out. The actual JAMstack, you know, JavaScript API's and markup, my introduction to that has come a lot later than I think a lot of people I actually just started, I'd say late last year getting interested in the concept and starting to learn about it. We use it at work for our marketing website. And then personally, we've used it for a meetup that I run here in New York called useReactNYC. Bryan Robinson 6:28 What's sort of technology stack are you messing with right now? Jenn Creighton 6:32 So both of them are using Gatsby, but the marketing site is Gatsby plus Contentful. So that of course, our marketing people can make their own changes to the site, and we don't have to be, you know, nudged. "Hey Can you do a thing?" Bryan Robinson 6:48 "Please deploy, please, deploy!" Jenn Creighton 6:49 "Please make this change." So it gives them the freedom to do that without having to wait on us to make changes. It gives us the freedom not to think about the marketing site, very much. Then for useReactNYC, we wanted to create a website for the meetup so that people could learn more about us what we're about, and also join our community, both by attending the meetups, but also by joining our slack community, and also by helping us to build the site. And since we're a React meetup, it made a lot of sense that this would be a static site, and that we would make it with Gatsby. Bryan Robinson 7:27 Very nice. And any sort of ... Is there any sort of like API integration? Are you pulling in like meetup information from a third party? Or is it all just manual entry into into Gatsby? Jenn Creighton 7:37 Right now let's just manual entry. We definitely want to expand it at some point. We're just not sure that we have the time right now between the five organizers that there are, we actually took on another organizer this year to make five of us Yuraima joined us and we have just all been really stretched thin. So even with the fifth organizer, we're still like "huuu", but we're hopefully gonna start recording the meetup soon and hopefully we'll also host them there so that people can view the content. Bryan Robinson 8:08 Pretty cool. I definitely understand that. That meetup organizer life where you're like, hey, PRs are accepted, and then no one submits a PR. Jenn Creighton 8:16 Yeah, we did have a particular member of the community, Nick, who came in and helped us really do a lot of work on the site, when we were all stretched very thin. And my very good friend Melissa, helped us actually by creating the design of the site, and it's really beautiful. She did a wonderful job. She also designed our stickers. So really, like all community events, it is really like we wouldn't have done it without the community like helping us out. That's was important. Bryan Robinson 8:45 Cool. So uh, are you You said that the marketing site at The Wing is currently built on Gatsby. What other sorts of projects do you work on at The Wing other than obviously getting the word out about these kind of co-working spaces? Jenn Creighton 8:58 So what what I personally work on is that I work on our single page application. So Gatsby is for our marketing site. But we do have a single page application that is for our members. That's our members portal as well as an admin site for us to handle things like applications or members, information, adjusting settings for them, so on and so forth. But our members portal is where everything really happens for them, they're allowed to find other people in the community and chat with them. There are job postings on the site as well. And there are a lot of events at The Wing that are very specific to what our members want to hear and see. And so they can RSVP for those as well on the site, as well as just the general thing of like adjusting settings or registering guests. So I work on all of that and as we try to build out new features that are going to help our members connect more and forum like real in life connections are putting a lot of those in this single page application. Bryan Robinson 10:01 Very cool. And so just like -- I have a degree in philosophy, so I have to sometimes dive into philosophy on the podcast -- So where would you kind of consider kind of breakpoint, because you said, you know, I'm using the JAMstack for the marketing site. And for the meetup site, I've always kind of thought of any SPA as having JAMstack asked qualities. Where do you kind of draw that line? Like, what what's JAMstack versus non JAMstack for you. Jenn Creighton 10:28 So the reason that I qualified as a single page application instead of anything to do with the JAMstack, is because it's built using create react app. And so it actually has a server. So nothing's actually served by CDN, which I think is an important component of JAMstack sites, you know, they have to be served statically through CDN or some means of static. So they're not pre rendered. They're not static. It's it's an actual serving of just an index.html, and then we fill in the JavaScript for everything. Bryan Robinson 10:59 I gotcha. Cool. That's the the kind of fun thing about running this podcast is that I hear lots of opinions. And they literally run the full gamut of like, everything's the JAMstack to like, even smaller like subsets. And it's just yeah, it's awesome. Jenn Creighton 11:15 Yeah, I mean, and when you hear like that it's JavaScript API's and markup, you're like, well, how is this not every single page application? And that totally makes sense. Definitely. I think the JAMstack has some really specific qualities to it, though, that are very different from something built with like create react app that actually does have a server that you're not actually serving at statically. And you're relying on the JavaScript to do all the heavy lifting of creating all the page. It's not pre rendered. You know, we certainly don't have the ability for... One of the things I really like about the JAMstack is that it closes that gap for the user, right like they get the stuff immediately. And also how your deploys go. You know, you can roll them back and there get based. But you don't have that with the single page application. And sometimes I was wondering with that I was like, does this need to be anyway, I was like, but I'm not rewriting the whole thing. And that decision was made before I came into the company. And I was like, You know what, it's, it's fine. Bryan Robinson 12:22 And still React. So you still get to work on react. Jenn Creighton 12:25 Yeah, and I love I love react. So that like, is a joy for me. Bryan Robinson 12:29 And so is there anything that you've that you've been learning based on your work in Gatsby that you're bringing back into the the server side and the Create React App side of all that Jenn Creighton 12:41 Not specifically? I think Gatsby comes with a lot of wonderful things that are not even technically part of JAMstack, right. Like I would say I would say that there is a great amount of focus on accessibility and Gatsby I really, really appreciate that. And that is something we're really focused on at work. So like many startups, so our product team is really new at the way. And like many startups, the first version of our product was built externally by a third party. And so we're now as a product team, picking it up and sort of changing the architecture and making it more of a long term scalable application. And that includes taking a look at our accessibility and realizing that we're really far off the mark right now. And we need to do something about that. I really appreciate that Gatsby, in addition to using JAMstack is actually really like moving forward with accessibility and giving you a lot of information about that along the way. Bryan Robinson 13:46 Yeah. And the great thing for me is that there's so many people jumping on Gatsby right now, just in terms of like, it is like probably one of the hotness is in the JAMstack right now. And to have that their focus so that people who might not have learned about accessibility in the are getting those tips and tricks just by having that in their code base by default. I think that's amazing. Jenn Creighton 14:05 Yeah, exactly. And that's one of the things I really enjoy about that project. And that's one of the things like, as you're working on that, you get to learn that you can bring that to all your future projects. It's not specific to the JAMstack. It is all about the web. Bryan Robinson 14:19 Best platform there is... the web. Jenn Creighton 14:21 Yes. Bryan Robinson 14:22 Cool. So So would it be fair to say that in the JAMstack, the Gatsby is your jam? Are there any other technologies that you're really interested in right now? Jenn Creighton 14:30 I think Gatsby is the main one. Obviously, we're really enjoying also Netlify and being able to like push things out really easy. So we use Netlify also for our preview links at work which is really great. So just definitely enjoying that. But yeah, I think definitely Gatsby considering that I've used it at work and now in this useReactNYC project. Bryan Robinson 14:54 Nice and so work when when people are saving into contentful, are y'all deploying Preview deploys to send them links at same time. So like they can see it live on the site before they publish it. Jenn Creighton 15:06 I think so. Yeah. I forget because I haven't worked with it in a hot second and if anyone's changed behind my back, but yeah. Bryan Robinson 15:14 You never know. Jenn Creighton 15:15 Honestly, with a startup you never know. Bryan Robinson 15:18 It's so easy to deploy, right? Jenn Creighton 15:20 Things happen in a startup that I'm like, wait a minute, you're doing what now? Can we just Can we just grab five really quickly and make sure this is a good idea? All the time. Bryan Robinson 15:30 Okay, gotta move fast, right? Jenn Creighton 15:32 Yes. Move fast break. Things. Break. ... Both of us are like "arrrrgh no!" Bryan Robinson 15:39 Yeah. Don't Don't tell QA that you broke it. It's fine. Jenn Creighton 15:44 Yeah. Bryan Robinson 15:46 Cool. So let's, let's talk about actual musical jams. Then what are you listening to right now? It's in your headphones. What's going on there? Jenn Creighton 15:53 So my number one thing right now is Halsey. Which is strange. I didn't listen to her before, but I actually so I'm a big fan of Saturday Night Live. I love Saturday Night Live. And she hosted not that long ago. And she was the host and the musical guests. And I wasn't familiar really with her music, but she had this song on there, You Should Be Sad. And I just fell in love with it. So I've actually been playing that on repeat for like a while. I love her vocals on it. It like just makes me feel really good. Bryan Robinson 16:28 Yeah, so specifically that song but then kind of the whole, her whole artistry. Jenn Creighton 16:34 I let I let that song play and then I'll listen to like a lot of the other ones on the album and I'm finding that I really enjoy her songs, which is really great. Jenn Creighton 16:44 And just depends on what mood I'm in. Bryan Robinson 16:47 What other moods strike you for, for other musical tastes. Jenn Creighton 16:51 And sometimes we like to go old school like country. Little little like kind of plucky banjo sound You know, really enjoy that sometimes. So I went through an Iggy Azalea phase. That was an interesting period of my life. Bryan Robinson 17:10 I think we've all been through that sort of phase. We've all been there. Jenn Creighton 17:14 Sometimes my my discover weekly on Spotify, I think is consistently confused. It's like, remember when you were sad? Well, here's all the sad songs and I'm like, oh, but Spotify. I'm not sad anymore. It's like, Okay. Here's poppy feminist music. I'm like, no, we're not in that mood. We're angry, now. Where's the angry? It's like, I cannot help you, I'm sorry. Sorry, Spotify. Bryan Robinson 17:39 The algorithm can only do so much for you. Cool. So is there anything that you would like to promote something you're doing something you want get out to the JAMstack community? Jenn Creighton 17:47 Well, first of all, if they're interested, they can follow me on Twitter. My handle is gurlcode girl with a "u". I'm also going to be speaking here in New York at React Day New York. Later in September, I'm going to be speaking about some things I have learned going from React to React Native, which is a whole new world for me. And then I'm also developing a course on React component architecture. That's my, my favorite sort of subject. I'm developing it for Thinkster. So that should be coming out, I think in a few months, if I have enough time to do all the recordings Bryan Robinson 18:24 Very cool. And also, I haven't watched it yet, but I'm super excited now that I've seen it to go watch your the "What happens next", the choose your own adventure with iterators. Like, I have to go watch that I saw that topic. I said, Okay, carving out the time for that one. Jenn Creighton 18:39 I love iterators I love them so much. They're wild. They're in so many things that we use in JavaScript, and we have no clue. And that's what that talk is about. And also it's like ridiculous and silly. You're on like an alien planet solving a mystery. And I had this artists do this beautiful work for it. So it's ridiculous, but yeah, Bryan Robinson 19:00 Ridiculous is the best way to go. Jenn Creighton 19:03 Yeah, it's like funny and weird. I enjoy it. Bryan Robinson 19:06 Well, I appreciate you taking the time to talk with us. And we'll be sure to link all those, all those amazing things that you're doing up in the show notes. And yeah, thanks for taking the time. Jenn Creighton 19:14 Thank you for having me really enjoyed it. Bryan Robinson 19:16 And as always, thank you to the amazing JAMstack community, your continued support via shares, likes favorites, and all those mechanisms is so incredible that I literally just don't have the words to deal with it. Bryan Robinson 19:29 With that it's sponsored time, and we're talking about the amazing content platform take shape. This week, I want to mention their amazing GraphQL API. It's not an afterthought, but a fully realized part of their platform. It means that whether you use their CMS or another platform entirely, you have an incredibly easy access to all your data in one simple API call. Do you want to see what that's like? Head on over to takeshape.io/that'smyjamstack to sign up. And with that, I'll take my leave of your ears. So until next week, Keep doing amazing things on the web and keep things JammyTranscribed by https://otter.aiIntro/outtro music by bensound.comSupport That's my JAMstack by donating to their Tip Jar: https://tips.pinecast.com/jar/thats-my-jamstack

Extensions API, JavaScript API, Webhooks etc. With the development of the Tableau Platform, we are releasing new APIs. More details @ datafam.net or https://tc19.tableau.com/learn/sessions/api-360-popular-use-cases-our-top-apis#recording

Philippe De Ryck joins the show to talk all things security: the importance and why you should be taking active steps, how to do it in your codebase effectively, and what can happen during a breach. Philippe De Ryck: Pragmatic Web Security Resources: OWASP Top 10 OWASP Top 10 Proactive Controls Please join us in these conversations! If you or someone you know would be a perfect guest, please get in touch with us at contact@frontside.io. Our goal is to get people thinking on the platform level which includes tooling, internalization, state management, routing, upgrade, and the data layer. This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. Transcript: CHARLES: Hello and welcome to The Frontside Podcast, a place where we talk about user interfaces and everything that you need to know to build them right. My name is Charles Lowell, a developer here at The Frontside. Joining me, also hosting today is Taras Mankovsky. Hello, Taras. TARAS: Hello, hello. CHARLES: And as always, we're going to be talking about web platforms, UI platforms, and the practices that go into them. And here to talk with us today about a pillar of the platform that I certainly don't know that much about, and so, I'm actually really happy to have this guest on to talk about it is Philippe De Ryck who owns his own company called Pragmatic Web Security. I understand you do trainings and are just generally involved in the small space. So, welcome, Philippe. PHILIPPE: Hi. Nice to meet you. CHARLES: Wow! I almost even don't even know where to start with this subject because I'm kind of like the hippie developer mindset where it's like, "LaÖlaÖlaÖlaÖlaÖ we're in this open land and nothing's ever bad going to happen and we're just going to put code out there," and nobody would ever take advantage of any holes or anything like that. And I think that a lot of developers share that mentality and that's how we end up with major, major security breaches. And so, like I said, this is something that I'm actually very eager to learn but I almost even don't know where to start. I need training, man. [Laughter] PHILIPPE: Well, that's good to hear. No, you're totally right about that. If you're not into security, it seems like this fast space for a lot is happening and you don't really know how or why and what really matters to you and should I even be worried about this. And let me start by addressing the very first thing. Yes, you should be worried because maybe you're not building something that somebody cares about but you always have something that somebody wants, even the simplest of attacks always targets a valuable resource. Just to give you a very simple idea today, cryptocurrency is all the hype and you have a taker that's just aiming to misuse your users' computers to mine crypto coins because it essentially saves them a bunch on electricity cost. So, there's always something to grab. Usually, it's data or services or worse. But even in the most minimal cases, you have hardware, you have devices, you have network capacity that somebody might want to abuse. So yes, security, I would say, always matters. CHARLES: What's the best way to get started? You said understanding that everything we do, we're holding onto resources that might be valuable, that someone might want to seize but I'm just getting started with my application. I don't know anything about security. Where do I get started on just understanding the space? And then before I even look at tools that I wantÖ PHILIPPE: You want the honest answer for that? [Laughter] PHILIPPE: The honest answer is probably hire someone who has security knowledge. I don't mean this in a bad way. I've come a very long way in my career doing what I do now. And if I look at that, if you are aiming as a developer with no knowledge about security to build a secure application, it's going to be very hard. There's a lot of things you need to know, intrinsic knowledge. These are not things you can simply read a small book in a week, you know all of these security things that you'll know what to do. So, if you have no previous experience at all, I suggest to find some help. CHARLES: Right. It's like saying, "Hey, you've never written a data layer before but you want to go out and you want to write a massively distributed system where you have all these notes talking to each other. You're not going to read the O'Reilly book 'How to Build Distributed Systems' in a week and go out and do the same thing." It's the same thing with security. You need to understand the entire context. And there's no substitute for experience. PHILIPPE: Sorry, I actually like that comparison because in a sense, you're right, it's like these other very complex topics you don't expect to learn that in a week or a month and right a functioning data layer. But the difference is if you fail at writing that data layer, your application is probably not going to work. While if you fail at securing the application or seeing potential vulnerabilities, it's still going to work just a bit more than you anticipated. It's going to result leaking all your data to an attacker or opening all doors so that they can gain access to your server, stuff like that. So, I would say that the consequences of not getting it right are, at least in the beginning, very invisible. It's only after things happened that it's like, "Oh, crap!" And you should pay attention to that. CHARLES: Yeah. And then you have these back doors and these leaks that are set in stone and may be very hard to change. PHILIPPE: Yeah, absolutely. And honestly, the worst part of the breach is for a company, it might be reputation damage. But what you really should be worried about is all that personal information that's being leaked to, most cases, publicly leaked to anyone but in other cases, it's sold on [inaudible] markets and actually abused by people looking for someone else's identity or credit card information or stuff like that. And the companies usually get away with some bad press, maybe a small dip in their stock price but eventually, they'll bounce back. But it's the users that suffer from these breaches for a very, very long time. TARAS: What do you see the kind of hot zones around concerns that companies have around security? Because I imagine it's hard to be concerned about everything, so they're probably thinking about specific things like this thing worries us. Like what kind of things do you see companies and teams need to worry about? PHILIPPE: That's an interesting question. You have all different kinds of companies and all different levels of security awareness and what they're worrying about. I would say if you have the companies that are not very good at or don't have very much security knowledge, they're probably not to worry about things because otherwise, they would have started investing in improving their practices. If you look at the companies that are at least very aware of the landscape, I'm not saying that anybody here is perfect, but some of the companies are actually doing quite a good job. One of the most interesting challenges today is dealing with dependencies. So, all of your packages, you depend on npm, Maven, Python packages, Ruby gems, and so on. All of them form a huge attack factor in most applications today. That's definitely a problem that a lot of companies struggle with and it's very hard to find good solutions. TARAS: GitHub recently, I saw their vulnerability alert service that I've been getting a lot of notifications from on some of the open source libraries that we use. They have a lot of dependencies. And a lot of projects have the same dependencies. So, the moment that one notification goes on, it like lights up on all of the GitHub repos that I have. So, I have been going through and like updating dependencies and all those libraries. PHILIPPE: Yeah, that's a very good example. Absolutely. A lot of the projects we build today usually start out by installing a bunch of dependencies. Even before you've written the first line of code, you already have a massive code base that you are relying upon. And a single vulnerability in a code base might be enough, it's not always the case, but it might be enough to compromise your application. And that leaves you, as a developer, in a very hard place because you haven't written any lines of code yet. You have built a vulnerable application and that starting point can be very terrifying. So, there's a lot of reports on this. And actually, if you want some numbers, 78% of the vulnerabilities discovered in existing applications like the ones you mentioned. If GitHub alerts you like, "Hey, there's a problem in one of your dependencies," it's often even an indirect dependency, meaning that you include a framework, if you include React or Express or whatever you're building, that one of your dependencies of one of those projects actually has a vulnerability. If you look at the trees of these packages, they get quite big that it's not dozens but it's thousands of packages that we're talking about. CHARLES: Yeah that's the other thing is how do you know how to interpret these security vulnerabilities because some of them, we get a lot of security vulnerabilities for node packages but we only use them for our development tools to build frontend. So, if we're building a React application and there's some security vulnerability in some node packages that we're using in our build tool, then that doesn't actually get deployed to the frontend. So, maybe it's not a concern but if we were actually using it to build a server, then it would be absolutely critical. And so, how do you evaluate because the same security vulnerability is not a vulnerability in one context, but might be in another or maybe I'm thinking about it wrong. You see what I mean? PHILIPPE: Yeah, sure. I totally get what you mean. Actually, I have observed the same things. I also get these security alerts on my projects, and sometimes it's devDependency, so it seems like we don't need to care about that. You're right in the sense that you have to assess the criticality of such a report. So, they will have a rating, a severity rating saying like, "This is a minor issue," or, "This is a major issue," that should be a first indication. And then a second thing to look at is, of course, how are these things used in practice. It's not because it's a devDependency that it's not exploitable because it all depends on what is the vulnerability. If there's an intentional malicious backdoor in the library and you're building that on your build server, it might give an attacker access to your build server. So, that might not be something you actually want to do. So in that case, it does matter. Of course, if it's only stuff you run locally, you can say like, "OK, this is less important." But usually, updating or fixing these vulnerabilities also requires less effort because there's no building and deploying to production servers either. So, it's a matter of staying up-to-date with these. And one of the things that people struggle with is handling this in a lot of different applications. You mentioned you had a lot of GitHub repos and the vulnerability starts popping up in all of them and you have to fix and update all of them. You can imagine that major companies struggle with that, as well, especially if you have quite a few different technologies. Managing all of that is insanely hard. CHARLES: Right, because you just usually look at it and you're like, "Oh, I've got to download this." And maybe, "I haven't used it this repo for a while. I've got to clone it up, I've got to update the dependency. I've got to make sure I run all my tests locally, then run all the tests in CI and make sure I didn't break anything by upgrading. I might have fixed closed security hole but broken my functionality." And so, make sure that that is all intact and then push it out to production. Even on the small, it's like I'm looking, "OK, maybe this is going to take me 30 to 45 minutes." But if you have four or five of those things, you're looking at half your day or maybe even the whole day being gone and that's if you have the processes in place to do those automated verification. If you have a very high confidence in your deployment pipeline which I don't think a lot of places have. So, it sounds like these are complementary, like you really need in order to keep a secure application, you have to keep it up-to-date because I think what I'm hearing is you should just evaluate all the threats. You should fix it if you can. The first part of my question is, am I kidding myself when I say, "Oh, I can ignore this one because it's just local or it's just a devDependency." PHILIPPE: The answer to that question is briefly, I would say they are less critical. CHARLES: That's cool. PHILIPPE: In general, the rule is update if you can. And actually some of the tools out there that monitor vulnerabilities, they will automatically create a pull request in your repo saying to upgrade to this version and then you can automatically run your tests if you have them, and you can very quickly see whether some conflicts are generated by updating that dependency - yes or no. And in most cases, if it's a minor version bump, it's going to work as expected and you can easily push out the new version without that vulnerability. So, I would say fix if you can. If it goes quickly, then definitely fix them. But I would focus on non-devDependencies first instead of devDependencies. CHARLES: Yeah. PHILIPPE: Second thing I wanted to add is you paint a very grim picture saying you have to spend a lot of time updating these issues and I can totally understand that happening the very first time you look into this. There's going to be some stuff in there, I can guarantee that. But if you do this regularly, the effort becomes less and less because once you have up-to-date libraries, the problem is bad but it's not like we have 50 new vulnerabilities every day, fortunately. CHARLES: Right. PHILIPPE: So, once you have done that, it's going to be a bit less intensive than you might anticipate at first glance. Of course, if you're using these projects, if you're reusing the same library, then you'll have to update them everywhere. That's the downside, of course. CHARLES: It's probably a little bit dangerous to be assessing the criticality of the security threats yourself if you're not an expert, and kind of in the same way, it's dangerous to be assessing an architecture if you don't have an expertise in our architecture, I guess is the thing, because you might not understand the threat. PHILIPPE: Yeah, that's, again, absolutely true. It again depends very much on how it's deployed and what it's used for. That's going to be one important aspect. Another thing that might be very useful is, how deep is the dependency that creates the vulnerability or has the vulnerability? Because for example, if you have your tree of dependencies, if you dependency is like five or six levels deep, the chances of malicious data are reaching that specific vulnerability, and that specific library is going to be fairly small. Because usually, libraries have a lot of features and you only use part of them in your application. So, the other one is address of the features is just sitting there and if it's never used and it's also not exploitable. So, that might play a role as well. I saw a presentation about a month or two months ago from how Uber manages these things and they struggled with a lot of those things as well. And they eventually decided that they really care about vulnerabilities going three levels deep. And something that goes deeper is considered to be less relevant or less urgent to update because chances of exploitability are going to be very small. CHARLES: That's actually really interesting. TARAS: One thing that got me thinking about something that is actually happening right now. A friend of mine has a WordPress site that was hacked. But what's interesting about WordPress, I think the fact that WordPress site was hacked is not really a surprise but I think what's interesting about that is that the frequency and the sophistication of these attacks has increased. The tooling has improved also in the WordPress ecosystem. But at the same time, I think there is actually more people that are aware of the kind of exploits that could be done. There are a lot of people going after WordPress sites, but it kind of makes me think that there's probably going to be a time when the vectors of attack for web applications are going to become pretty well known as well. Because of the architecture, there are a fewer of them. But as the awareness of the actual architecture becomes more common, I think the angles of attack are going to become more interesting. Like one of the things that I was reading about a couple days ago is that there are some researchers that found a way to attract users based on a combination of JavaScript APIs that are available in the browser. So, they are actually able to fingerprint users based on the kind of things that they're using, the application for [inaudible] extensions they have installed. I think people are going to get more creative. And that's kind of scary because we've seen this happen already in WordPress and people are greedy. So, there are going to be ways. I think there's going to be more people looking at how to get into and how to exploit these vulnerabilities. PHILIPPE: Yeah. That's actually a couple of very good examples that illustrate the underlying issue. So, this browser-based tracking of users, it's called browser fingerprinting and it's been going on for a while. Back when I did my PhD, I had colleagues working on those things and you have other people at universities doing research on this. And yes, you can use things like JavaScript APIs in the browser to identify a particular user with a very high probability. It's not perfect but it's usually enough to identify a user for ad tracking or those purposes. By the way, these things also have a legitimate purpose. So, they are also used to keep track of a particular user to prevent things like session hijacking or detect problem logins or stuff like that, so they can also have a legitimate use case next to tracking. But they very clearly show how security will always be a cat and mouse game. Tracking used to be easy. You just set a cookie in a browser and the cookie was there next time and you knew who the user was. And then, users became a bit more savvy. You had browser extensions trying to block listings because let's be honest, they're kind of shady. So, users probably don't want that. And then the attacker started moving towards other things and getting more advanced. And you see that in other areas of security, as well. So, I consider that a good thing because as we make things harder for attackers, they will have to get more creative and it will become more difficult to exploit or to take advantage of applications. That's the good side. The bad side or the dark side of that equation is that unfortunately, the vulnerabilities are not going away. It's not because we now have these somewhat more advanced attacks using advanced features or even CView-based vulnerabilities that the old things like SQL injection and [inaudible] have disappeared in applications. That's also not true and that means that it makes it just a bit more harder for everyone on the defensive side to build more secure applications. You're going to have to know about the old stuff and you have to learn about the new stuff. CHARLES: Again, we come back to that idea. It's all a bit overwhelming. Aside from the solution of like, "Hey, let's hire Phillippe. Let's hire some other security expert." We were actually in your training, and obviously, I don't want to divulge all the secrets or whatever. If we were to attend your training, what do you see is the most important thing for people to know? PHILIPPE: There's no secrets there. [Chuckles] What I teach is web security. I kind of like to think I teach that in a very structured and methodical way. But in the end, there's no secrets and I don't mind talking about this here on the podcast because I honestly believe that everyone should know as much as they can about security. What do I teach? I can talk about specifics but I can also talk about generic things. One of the general takeaways is that one of the best things in my opinion that a developer can do is realize when they don't know something and actually admit that they don't know something, instead of just doing something. Maybe having like a brief thought like, "Hmm, is this secure? Well, it's probably good. I'm going to deploy it anyway. We'll see what happens." That is not the right way of doing things. If you do something and you recognize like, "Hey, this might be security sensitive. We're dealing with customer information here. We're dealing with healthcare information. We might want to look at what plays a role here," and then you can go ask someone who does. You probably have a colleague with a bit more security knowledge, so you can ask him like, "Hey Jim, or whatever your name is, do you think that this is OK or should we do something special here?" Very much like you are doing, asking me questions right here. That's one important takeaway that I hope everyone leaves with after a training class because not knowing something and realizing that you don't know it allows you to find someone who actually does. That still leaves us with that point which you wanted to sidestep. CHARLES: [Chuckles] PHILIPPE: A second thing is to realize that security is not a target. It's not something you're going to hit. It's not a holy goal that after working really hard for two years, you're going to hit this security milestone and you're done. It's always going to be a cat and mouse game. It's always going to be a moving target but that's OK. That's how things are. And that's the same with all other things in the world essentially. It's an evolving topic and you'll need to be ready to evolve with that as well. TARAS: One of the challenges that I see into quite often in teams is that at the individual level, people really try to do their best, maybe the best of their abilities. But it's often, when it comes to being part of a group, it's often like they do best within the kind of cultural environment that exists. I'm curious if you've seen good or kind of environments or cultures for engineering teams that are conducive to good security. Are there kind of systems or processes the companies put in place that you've seen to be very effective in preventing problems? Have you encountered anything like this? PHILIPPE: Ideally, you have developers that are very well educated about security but honestly, it's going to be insanely hard to find these people because a developer not only has to be educated about security, they also need to know about UI design and JavaScript frameworks and other frameworks and all of these things. And it's virtually impossible to find someone up-to-date on all of these things. So, what most companies do today that seems to work quite well, even though it's very hard to judge whether it's working or not, is they work with security champions. So, you typically have a dev team and within a dev team, you would have a security champion, one or two or five, depends on how large your teams are, of course, that is knowledgeable about security. So, that developer has some knowledge. He's not an expert but he knows about common attacks and common dangers and how to potentially address them in the application. So, having that person embedded in the team allows the team to be security aware because when you have a team meeting like, "Hey, how are we going to solve this particular problem?" That person will be able to inject security knowledge like, "Hey, that seems like a good idea but if we're using SQL in the backend, we need to ensure that we don't suffer from SQL injection." Or if you're using a NoSQL database, it's going to be NoSQL injection and so on. And that already elevates the level of security in the team. And then, of course, security champions themselves are not going to be security experts. They're mainly developers just with a security focus. So, they should be able to escalate problems up to people with more knowledge, like a security team which can be a small security team within their organization that people can easily reach out to, to ask like, "Hey, we're doing something here and I know that this is security relevant and I'm not entirely sure what's happening here. So, can we get a review of this part of your application?" Or, "Can you guys sit on the meeting to see what's going on and what's happening there?" And I think that structure also makes sense. It's still going to be hard to build secure applications because there's still a lot of things to address, but at least, your teams get some awareness. And then of course, you can help your security champions to become better and they will get better over time. You can augment them with the security architects. You can train your security champions separately with more in-depth knowledge and so on. And that veteran or that setup seems to work quite well in many large organizations today. CHARLES: Yeah. I like that. It gets me to thinking, so having the having the security champions, having people who have this as part of, not their specialization, but at least part of their focus, being in the room, being part of the conversation because we try and do that and provide that service when it comes to UI but we also have a bunch of processes that kind of automate the awareness of quality. So, the classic one is your CI pipeline, your deployment pipeline. So, you're automating your advancement to production. You're automating your QA. It's still no substitute for having someone who's thinking about how to have that quality outcome but you still have some way of verifying that the outcome is quality. Are there tools out there that you can do to kind of keep your project on the security Rails. I'm thinking something that we we've done recently is having preview apps, so that we get a tight feedback loop of being able to deploy a preview version of your application that's on a branch but it's talking to a real backend. There's a lot of more software and services that are supporting this and it's kind of become an integral part of our workflow. So, testing automated deployment preview apps, there's this kind of suite of tools to make sure that the feedback loops are tight and that the quality is verified even though you have people, you also have people guiding that quality. It's just making sure that the standards are met. Is there a similar set of tools and processes in the security space so that we've got these champions out there, they're being part of the conversations. They're making suggestions but they can't be everywhere at once. And is there a way to make sure that the kind of the ways that they're guiding the application, just verifying that the application is going in that direction? Or an alarm bell has sounded. We mentioned one which is the automated pull request with the, "Hey, you got this dependency and there was a pull request." Are there more things like that, I guess, is what I'm saying. PHILIPPE: Yes, there are. But I would dare to say not enough. So yes, you have some security tools you can integrate in your pipeline that do some automated scanning and they tried to find certain issues and alert you of those issues. So, these things do exist but they have their limitations. A tool can scan an application. Some of the findings are going to be easy and fairly trivial, but it's good to have the check in place nonetheless. But some of the more advanced issues are very likely to be undetectable by those automated tools because they require a large amount of skill and expertise to actually craft and exploit to abuse that particular feature in an application. So, we do have some limitations but I like discretion because I do believe that we need to leverage these mechanisms to ensure that we can improve the security quality of our applications. A very simple thing you can do is you can run an automated dependency check when you build the application and you can use that to decide to halt deployment when it's a severe vulnerability or go ahead anyway when you consider this to be acceptable because if you automate all of those things, things can go wrong as well. We can talk about that in a second. So yeah, these things can be done. But what I strongly encourage people to do to ensure that they can kind of improve the code quality is to flag certain known bad code patterns. So if you're building an Angular or a React application, if you're using functions that output go directly into the template, that's going to be very dangerous. So, we know these functions in Angular, they're called bypassSecurityTrustHtml, bypass security should be kind of a trigger and this kind of security irrelevant. And in React, that property is called Dangerously Set innerHTML, also indicating like a 'developer watch out what you're doing'. So, what you could do is you could set up code scanning tools that actually flag these things whenever they appear in application because sometimes people make mistakes. You hire an intern and they don't really know the impact of using that property and they use it anyway which would cause cross-site scripting vulnerability. If you're code scanning to flag these things ensures that it doesn't get pushed to production unless it's a benign case which is actually approved to be in there, then you can definitely stop some of these attacks coming on for sure or some of these vulnerabilities happening. TARAS: I think the hardest thing to understand is when someone doesn't understand what they're doing that what they will create is so cryptic that I think any tool that tries to figure out what it is that person is doing I think will have a really hard time. The person making the thing doesn't understand what they're doing, then the system is not going to understand what they're doing which makes me think that one of the things that we think about a lot at Frontside is this idea of trying to understand the system from the outside as kind of looking at a system as a black box and wonder what kind of tools are available specifically for inspecting the application from the outside, like as if somehow understanding what the application is doing based on what's actually going on inside of the runtime and then notifying someone that there could be something off in the application, but through exercising the [inaudible] things like, for example, memory leaks is not something you can catch unless you have a test suite that has like a thousand tests and then you will see over time that your application is actually leaking memory. But if you run individual tests, you'll never see that. I wonder if there's anything like that for security where at runtime, there's actually a way to understand that there might be some kind of a pattern that's incorrect in the application. PHILIPPE: If only, if only. It depends on who you ask. There is such a concept that's called Dynamic Application Security Testing. Essentially, what you do there is you run the application, you feed it all kinds of inputs, and you monitor when something bad happens. And that means that you have detected vulnerability. So, these things do exist. But unfortunately, their efficiency is not always that good. It very much depends on what kind of security problems you're trying to detect. And they can, for example, detect some instances of things like cross-site scripting or SQL injection or things like that. But there will always be limitations. I've seen tools like that being run as an application where you actually know there's a vulnerability because it has been exploited. There is a manual written exploits and the tool still doesn't find any vulnerabilities which is not surprising, because these things are really hard to make an abstraction of to be able to find that in an automated way with a tool. If you would have such a tool that would be, I think, that [inaudible] would be a lot better. I think there's a lot of funders working on that. But at the moment, those tools are not going to be our savior to build more secure applications. CHARLES: Yes. I mean, it's kind of like linting, right? Or you can make tests. We've been through this kind of all the features or the aspects that we want our application to have, whether it be accessibility. There's certainly a very comprehensive suite of lint level checks that you can run to make sure that your application is accessible. You can run a suite of three thousand things and if it triggers any of these things, then yes, your application won't be accessible but it's not a substitute for thinking through the accessibility architecture. The same thing goes with code linting. You're not going to solve bugs with a linter that makes sure that it's formatted and that you're declaring your variables right and that you're not shadowing things. But you can definitely eliminate a whole classes of things that might be put in there just for maybe even you know what you're doing and you're just forgetful. PHILIPPE: Yes, these rules exist, as well. They're not extensive but there are linting rules for Angular used for security, for example. But the problem in linting is that they are very useful to find potential instances of security relevant features or security relevant functionality. But the linting rule alone cannot decide whether something is OK or not. Just to give you a very simple example, if you use the bypassSecurityTrustHtml function, if you give that function a static snippet of HTML, that's going to be fine unless you write your own attack essentially. But if you feed that function user inputs, you're going to be in a lot of trouble. And making that distinction with a linter is going to be difficult unless you have a static string in the arguments. But if once you start having that from variables to dynamically decide to have a different code path, then that's going to be very, very difficult to decide automatically. So, yes, you can use that to find the places in the application where you should be looking for, in this example, a cross-site scripting in Angular but the linting alone is not going to give you an answer whether this is OK or not. That still requires knowledge of how Angular handles this things, what happens, and how you can do things safely. TARAS: Sounds like we keep going back to nothing beats having knowledgeable developers. PHILIPPE: Yes. Unfortunately, that is true. However, with that said, I want to highlight that frameworks like Angular, well mainly Angular, make things a lot better for developers because yes, you still need knowledgeable developers but the ways to introduce a cross-site scripting vulnerability in an Angular application are actually very, very limited. It's not going to be one, but there's going to be maybe three or four things you need to be aware of, and then you should be set. While if you would have done the same for PHP, it's going to be 50,000 things you need to be aware of that are potentially dangerous. So, yes, frameworks and libraries and all of these abstractions make it a lot better and I really like that. That's why I always refer to abstract things away in a library so that you actually have the ability to look for this dangerous code patterns using linting rules in your code base and that you can, at least, inspect the go to see whether it's OK or not, even though you might not be able to make an automatic decision. You, at least, know where to look and what to approve or how to change in the code base. TARAS: I think that's one of the things that oftentimes is not taken into account that the frameworks are different. And I think of big differences in how much -- like right now, the most popular framework, I think, React. But it's such a thin layer, it's such a small part of the framework that you can hardly call it a framework. But it is something that companies rely on. But then when you consider how much of that code that you need to write, to make React into a complete framework for your company, the amount of code that your team has to write versus the amount of code that your team has to write when you use something like Angular or Ember, there's definitely a lot less parts of the framework that you need to write or a lot less parts of the framework you need to choose from what's available in the ecosystem. Like in Angler and Ember, and I'm not sure what the story is with the view, but the pieces, they come from kind of a trusted source and they've been kind of battle tested against a lot of applications. But I don't think that enters into consideration when companies are choosing between Angular or whatever that might be because they're thinking like what is going to be easiest for us. What is going be [inaudible] for developers? They're not thinking about how much of the framework are we going to need to put together to make this work. CHARLES: I can say it sounds, Taras, like almost what you're saying is by using the frameworks that have been battle tested, you actually get to avail yourself of code that actually has security champions kind of baked into it, right? Is that what you were saying? You keep coming back to 'you need developers who are knowledgeable about security', and if you're using kind of a larger framework that covers more use cases, you're going to get that. Do you think that that is generally true, Philippe? PHILIPPE: Yeah. I think it is and that's why I mentioned that I liked Angular before because Angular actually does offer a full framework. And because they do that, they made a lot of choices for developers and some of these choices have a very, very big and positive impact on security. On the other hand, if you make those decisions, you become an opinionated framework and some people don't like that. They actually want the freedom to follow their own paths and then a less full featured framework like React might be an easier way to go. CHARLES: But I think what happens is folks don't enter into that decision with their eyes open to the fact that they then now need to be their own security champion because they just don't even see it. We said the most dangerous thing is the things that you don't know. PHILIPPE: Yeah, absolutely. And I totally agree. That's something that's at least a couple of years and probably still today, many companies moving into this space struggle like, "Which framework do we choose and why do we choose one or the other and which one will still be there in three years because we don't want to switch to another thing in three years," which is risky to our developers. I like that you said that Angular has this security champion knowledge built in because in Angular 2 and every version behind it, but the new version of Angular essentially, they spent a lot of time on security and they learned from their mistakes in the first version because there were some and they took that and they built a more robust framework with security built in by design or by out-of-the-box. Angular offers, for example, very strong protection against cross-site scripting. It's just there, it's always on and unless you actively sidestep it, it's going to protect you. And that's one of the things I really like about Angular and how they did that. CHARLES: Yeah, that's one of the things that I really like too because I remember there was a blog post back, this is probably, I don't know, almost 10 years ago now, maybe seven or eight years, where someone was comparing why they were more interested in using, their servers were implemented in Ruby and why it was better to use Rails than just Sinatra which is just a very, very, very lightweight HTTP framework. And one of the things that he was pointing to was this new vulnerability was discovered and if you were using Rails, the middle way where the middle square stack is managed by the framework, you just upgrade a minor version of Rails. And now, by default, there's this middleware that prevents this entire class of attack. PHILIPPE: Was that a cross-site request forgery? CHARLES: I think it might have been. PHILIPPE: I think Rails was one of the first to offer built in automatically on support for that. So yeah, that was a very good early example of how that can work really well. CHARLES: And the advantage from the developers' standpoint, because the contrast that, if you'd been writing your application in Sinatra which is this is very, very low level based right on top of rack and you're managing the middleware stack yourself and there are no opinions, then not only do you have to like fix this security vulnerability, you have to understand it. You have to get to do a lot of research to really come up with what's going on, how is this going to affect my application and then I can deploy a fix. And that's like a huge amount of time, whereas you have the freedom to not even understand the attack. I mean, it's always better to understand but you can defer that understanding invariably knowing that you're kind of invulnerable to it. And I think for people who enjoy kind of pretending, not pretending, but that the security world doesn't exist and say, "Hey, I want to focus and specialize on these other areas and attain deep knowledge there." It's very reassuring to know that if a defense for a novel attack comes out, I can avail myself of it just by bumping a version number. PHILIPPE: Yeah, absolutely. If you have everything in place to actually upgrade to that version that fixes those, that's a preferable solution. Towards the future, I believe it's going to be crucial to ensure that we can actually keep things up-to-date because everything that's being built today is going to require continuous updates for the lifetime of the application. I definitely hope that the frameworks get better and more secure and start following these patterns of naming the potentially insecure functions with something that indicates that they are insecure. I think that's definitely a good way forward. CHARLES: Yeah. Can I ask one more question? Because this is something that is always something that I wonder about whenever you talk about any aspect of a system. And part of it is folks will not appreciate good architecture until they've experienced some sort of pain associated with not having that architecture in place. Their project fails because they couldn't implement a set of features without it taking months and years and they just ran out of runway, ran out of deadline. Those types of people who've been on those projects appreciate having a nimble system internally, good tooling. Folks who have experienced good tooling understand how much time they could save, and so, have a very low tolerance for bad tooling. A tool takes too long or is misbehaved or is not well put together, they just can't stand because they know how much time they're losing with security. Is there a way to get people to care about it without having some sort of breach, without having gotten smacked in the face? When you do your trainings, is it generally, "Hey, someone has experienced a breach here, and so they want to bring you in." Or is there some way to get people raise awareness of the problems they don't have to experience that pain but can just experience only the benefit? PHILIPPE: That's, again, a very good question and that's also a very good illustration of why security is so hard. Because if you get everything right, nothing happens. [Laughter] PHILIPPE: Or it might be if nothing happens, that nobody cares enough to actually try something against your application. So, there's no positive confirmation if you've done a good job. You can keep putting things off but eventually, there's going to be vulnerability and it's a matter of how you respond to it. We recently had a cross-site scripting in Google's homepage, one of the most visited pages on the web. And somebody figured out that there were some weird browser thing that could be abused and that resulted in a vulnerability on, let's say, such a simple page. So, even there, things can go wrong. So, what would be a good way to draw with some awareness about this is I would recommend following some simple new resources or some Twitter feeds. I have some security relevant articles there but plenty of other people in the industry have as well. And when you read such an article about security incidents, just think about whether this could happen to you or not. And that should probably scare the shit out of you. Simple examples like the Equifax breach, one of the biggest, most impactful breaches of the past few years happened because of an Apache library that was not updated. I think the Apache library, they had a known vulnerability in there. We knew about it. We had a patch, yet it took too long to install that patch and the attackers abused that vulnerability. This is something that probably can happen to each and every one of us because the attacks started, I think, 72 hours after the vulnerability and the patch had been published. So, ask yourself, "Would I have updated my servers in three days after I got that vulnerability report on GitHub?" Yes or no. And if the answer is no, then the same thing can happen to you. Other cases: Magecart is a very big problem, people injecting credit card skimming malware in the JavaScript library. Are you including third party JavaScript libraries? If yes, then chances are that this can happen to you. And there's nothing preventing someone from exploiting that. It's probably just because you got lucky that nobody tried to do that. And the same thing you see now with all these attacks npm packages where people actively try to get you to install a malicious package as one of your dependencies. And again, everybody can fall victim to these things. So, if you read the articles with that mindset, I probably guess that your security awareness will grow rapidly and you will start caring about that very fast. CHARLES: Yeah. TARAS: Lots to think about. CHARLES: Yeah, there's lots to think about because the next thing that occurs to me is how do you even know if you've been targeted. Because a good attacker is not even going to let you know. PHILIPPE: Yeah. CHARLES: It's just better to siphon off your blood, like you said, than to kill the -- you want to be a vampire bat and come to the same cow every night and just take a little bit of blood rather than the lion that kills the cow and then the cow's gone. PHILIPPE: I would say constant monitoring is going to be crucial and you need that data for all kinds of different purposes. You need to monitor everything that happens, first of all, for a post-mortem analysis. If something happens, you want to be able to see how bad it was. This user apparently got a full admin access and if you have decent monitoring, you will be able to retrace his steps to see what they did or did not get. So, that is one very good use case. A second use case is you can use that data to detect attacks. Usually when the attacks are noisy, it's an automated scanning tool but it might be an attacker trying to do things. Again, that may be something very useful for you to act on to see if there is a problem to prevent that user from connecting, or so on. And then, another very good use case of these things is actually inspecting the logs manually as an ops engineer or whatever, who is responsible for doing that, because that might again yield new insights. I've been talking to someone who said that they discovered an abuse of one of their APIs just by looking at the logs manually and detecting a strange pattern and looking and digging deeper into it. And the automated monitoring tools that they had installed that trigger on certain events like a mass amount of requests to the authentication and stuff like that, they did not catch this particular abuse. So, I would say monitoring there is absolutely crucial, for sure. TARAS: So, the takeaway is higher attentive knowledgeable developers who will learn about security. PHILIPPE: I would say the takeaway is security knowledge is essential for every developer. So, I encourage every developer to at least have a little bit of interest in security. I'm not saying that everyone should be a security expert. We should at least know about that the most common vulnerabilities in web applications, what they mean, what they might result in, and what to be on the lookout for. So yes, I think that's one of the crucial things to start with. And then within an organization, you should have someone to fall back on in case that there are security relevant things that you actually can talk to someone who does see a bigger picture or maybe the full security picture to decide whether these things are a problem or not. I think we're closing or nearing the end here, but one of the things we haven't talked about is how to actually get started in security. What if you are interested in security after hearing this podcast and you want to get started? I want to give you just a few pointers so that you actually know where to look. One of the first things to look at is OWASP. And OWASP is the Open Web Application Security Project. It's essentially a nonprofit that has the mission to improve the security posture or knowledge of developers, and they have a lot of resources on various different topics. They have a lot of tools available and things like that. What you want to start with as a developer is the OWASP Top 10, which is a list of the 10 most common vulnerabilities that exist in applications, just to open your eyes like these things exist in applications today and are definitely a problem. And then, there's a complementary Top 10 called the Proactive Controls and that's about how you, as a developer, can actually prevent these things. So, what should we know about implementing security, which guidelines should we follow. And these two documents are a very good place to start. And then there is a huge community that's actually mostly very eager to help people figure out the right way of doing things and solving these problems we have in our ecosystems. TARAS: Awesome. That's great. Thank you very much. CHARLES: Yeah. I'll take that in. That is really, really helpful. Well, thank you very much, Philippe, for coming on and talking about security. I actually feel a lot better rather than usually I'm thinking about securities kind of stresses me out. [Laughs] PHILIPPE: You can bury the problem but it's going to return in the future anyway, so you might as well get onboard and start learning. It's not that scary if you actually -- it's a lot of fun. So, you should learn about security. CHARLES: Well, I am looking forward to diving in. If anyone wants to get in touch with you, how would they do that on Twitter or Email? PHILIPPE: Yeah, sure. I'm on Twitter. I'm always happy to chat about security. You can reach me by Email as well. I'm very easy to reach. And I'll be happy to help out people with questions. Sure. CHARLES: All right. Thank you so much, Philippe. Thank you for listening. If you or someone you know has something to say about building user interfaces that simply must be heard, please get in touch with us. We can be found on Twitter at @TheFrontside or over just plain old Email at contact@frontside.io. Thanks and see you next time.

Panel: Charles Max Wood Guest: Nicholas Zakas This week on My JavaScript Story, Charles talks with Nicholas Zakas who is a blogger, author, and software engineer. Nicholas’ website is titled, Human Who Codes – check it out! You can find him on Twitter, GitHub, and LinkedIn among other social media platforms. Today, Nicholas and Chuck talk about Nicholas’ background, JavaScript, and current projects. In particular, we dive pretty deep on: 0:00 – Advertisement: Get A Coder Job! 1:00 – Chuck: Welcome! Give us a background, please, Nicholas! 1:14 – Guest: I am probably best known for making ESLint and I have written a bunch of books, too! (See links below.) 1:36 – Chuck: JSJ 336 and JSJ 075 episodes are the two past episodes we’ve had you on! (See links below.) Let’s go back and how did you get into programming? 1:58 – Guest: I think the first was written in BASIC, which was on a Laser computer. It was a cheaper knockoff version. I think I was into middle school when I got into BASIC. Then when I got into high school I did this computer project, which was the first time someone else used one of my programs. 4:02 – Chuck: Was it all in BASIC or something else? 4:13 – Guest: Just BASIC, but then transferred to something else when we got our first PC. 5:13 – Chuck: How did you get to use JavaScript? 5:18 – Guest: 1996 was my freshman year in college. Netscape 3 got into popularity around this time. I had decided that I wanted to setup a webpage to stay in-touch with high school friends who were going into different directions. I got annoyed with how static the [web] pages were. At the time, there was no CSS and the only thing you could change was the source of an image (on webpages). On the you could do... 8:35 – Chuck: You get into JavaScript and at what point did you become a prolific operator and author? 8:52 – Guest: It was not an overnight thing. It definitely was fueled by my own curiosity. The web was so new (when I was in college) that I had to explore on my own. I probably killed a few trees when I was in college. Printing off anything and everything I could to learn about this stuff! 10:03 – Guest (continues): Professors would ask ME how to do this or that on the departmental website. When I was graduating from college I knew that I was excited about the WEB. I got a first job w/o having to interview. 12:32 – Guest (continues): I got so deep into JavaScript! 13:30 – Guest (continued): They couldn’t figure out what I had done. That’s when I got more into designing JavaScript APIs. About 8 months after graduating from college I was unemployed. I had extra time on my hands. I was worried that I was going to forget the cool stuff that I just developed there. I went over the code and writing for myself how I had constructed it. My goal was to have an expandable tree. This is the design process that I went through. This is the API that I came up with so you can insert and how I went about implementing it. At some point, I was on a discussion with my former colleagues: remember that JavaScript tree thing I wrote – I wrote a description of how I did it. Someone said: Hey this is really good and you should get this published somewhere. Huh! I guess I could do that. I went to websites who were publishing articles on JavaScript. I went to submit the article to one of them. I think it was DevX or WebReference. 18:03 – Guest: A book is a compilation of different articles?! I can do that. I wanted to write a book that would fill in that next step that was missing. I didn’t know what the book was going to be, and I decided to start writing. Once I’ve had enough content I would take a step back and see what it was about. (Check out Nicholas’ books here!) 19:01 – Chuck: Oh you can turn this into a book! 19:10 – Guest: There was very little that I had planned out ahead of time. Anything that happened to me that was exciting had stumbled into my lap! 19:37 – Chuck: That’s how I felt about podcasting – it fell into my lap/life! 19:50 – Chuck: Listeners – check out the past episodes with Nicholas, please. Nicholas, what are you proud of? 20:10 – Guest: In 2006, I was at Yahoo and started off with My Yahoo Team. This was the first time that I was exposed to a massive amount of JavaScript in a single web application. 26:21 – Chuck: Can you talk about your health issues? People would definitely benefit from your example and your story. 26:44 – Guest: I think it is something important for people to understand. The guest talks about Lyme Disease. 35:49 – Chuck: Yep taking care of yourself is important! 36:00 – Guest: Yes to enjoy time with friends and explore other hobbies. Help yourself to de-stress is important. Cognitive work is very draining. When you aren’t getting the right amount of sleep your body is going to get stressed out. Take the time to do nonsense things. You need to let your brain unwind! I love these adult coloring books that they have! 38:07 – Chuck: I love to take a drive up the canyon. 38:12 – Guest. 38:24 – Chuck: Yeah to focus on ourselves is important. 38:36 – Guest: Your body will make it a point to say: pay attention to me! Your body goes into flight or fight mode and your systems shut-off, which of course is not good. You don’t want your body to stay in that state. New parents get sick frequently with newborns, because they aren’t getting enough sleep. 41:08 – Guest: Get some R&R! 41:20 – Chuck: This is great, but I have another call! Let’s do some Picks! 41:35 – Advertisement – Fresh Books! 30-Day Trial! END – Cache Fly Links: React Angular Vue.js JavaScript Ember Elm jQuery Node DevX WebReference Nicholas C. Zakas’ Books ESLint NPM – ESLint Signs and Symptoms of Untreated Lyme Disease Lyme Disease Nicholas’ Twitter JSJ 336 Episode with Zakas JSJ 075 Episode with Zakas Sponsors: Cache Fly Get A Coder Job Fresh Books Picks: Charles Max Wood Wall Calendars – 6 ft. x3 ft. Nicholas Zakas Book: The Better Angels of Our Nature: Why Violence Has Declined by Steven Pinker Adult Coloring Books

Panel: Charles Max Wood Guest: Nicholas Zakas This week on My JavaScript Story, Charles talks with Nicholas Zakas who is a blogger, author, and software engineer. Nicholas’ website is titled, Human Who Codes – check it out! You can find him on Twitter, GitHub, and LinkedIn among other social media platforms. Today, Nicholas and Chuck talk about Nicholas’ background, JavaScript, and current projects. In particular, we dive pretty deep on: 0:00 – Advertisement: Get A Coder Job! 1:00 – Chuck: Welcome! Give us a background, please, Nicholas! 1:14 – Guest: I am probably best known for making ESLint and I have written a bunch of books, too! (See links below.) 1:36 – Chuck: JSJ 336 and JSJ 075 episodes are the two past episodes we’ve had you on! (See links below.) Let’s go back and how did you get into programming? 1:58 – Guest: I think the first was written in BASIC, which was on a Laser computer. It was a cheaper knockoff version. I think I was into middle school when I got into BASIC. Then when I got into high school I did this computer project, which was the first time someone else used one of my programs. 4:02 – Chuck: Was it all in BASIC or something else? 4:13 – Guest: Just BASIC, but then transferred to something else when we got our first PC. 5:13 – Chuck: How did you get to use JavaScript? 5:18 – Guest: 1996 was my freshman year in college. Netscape 3 got into popularity around this time. I had decided that I wanted to setup a webpage to stay in-touch with high school friends who were going into different directions. I got annoyed with how static the [web] pages were. At the time, there was no CSS and the only thing you could change was the source of an image (on webpages). On the you could do... 8:35 – Chuck: You get into JavaScript and at what point did you become a prolific operator and author? 8:52 – Guest: It was not an overnight thing. It definitely was fueled by my own curiosity. The web was so new (when I was in college) that I had to explore on my own. I probably killed a few trees when I was in college. Printing off anything and everything I could to learn about this stuff! 10:03 – Guest (continues): Professors would ask ME how to do this or that on the departmental website. When I was graduating from college I knew that I was excited about the WEB. I got a first job w/o having to interview. 12:32 – Guest (continues): I got so deep into JavaScript! 13:30 – Guest (continued): They couldn’t figure out what I had done. That’s when I got more into designing JavaScript APIs. About 8 months after graduating from college I was unemployed. I had extra time on my hands. I was worried that I was going to forget the cool stuff that I just developed there. I went over the code and writing for myself how I had constructed it. My goal was to have an expandable tree. This is the design process that I went through. This is the API that I came up with so you can insert and how I went about implementing it. At some point, I was on a discussion with my former colleagues: remember that JavaScript tree thing I wrote – I wrote a description of how I did it. Someone said: Hey this is really good and you should get this published somewhere. Huh! I guess I could do that. I went to websites who were publishing articles on JavaScript. I went to submit the article to one of them. I think it was DevX or WebReference. 18:03 – Guest: A book is a compilation of different articles?! I can do that. I wanted to write a book that would fill in that next step that was missing. I didn’t know what the book was going to be, and I decided to start writing. Once I’ve had enough content I would take a step back and see what it was about. (Check out Nicholas’ books here!) 19:01 – Chuck: Oh you can turn this into a book! 19:10 – Guest: There was very little that I had planned out ahead of time. Anything that happened to me that was exciting had stumbled into my lap! 19:37 – Chuck: That’s how I felt about podcasting – it fell into my lap/life! 19:50 – Chuck: Listeners – check out the past episodes with Nicholas, please. Nicholas, what are you proud of? 20:10 – Guest: In 2006, I was at Yahoo and started off with My Yahoo Team. This was the first time that I was exposed to a massive amount of JavaScript in a single web application. 26:21 – Chuck: Can you talk about your health issues? People would definitely benefit from your example and your story. 26:44 – Guest: I think it is something important for people to understand. The guest talks about Lyme Disease. 35:49 – Chuck: Yep taking care of yourself is important! 36:00 – Guest: Yes to enjoy time with friends and explore other hobbies. Help yourself to de-stress is important. Cognitive work is very draining. When you aren’t getting the right amount of sleep your body is going to get stressed out. Take the time to do nonsense things. You need to let your brain unwind! I love these adult coloring books that they have! 38:07 – Chuck: I love to take a drive up the canyon. 38:12 – Guest. 38:24 – Chuck: Yeah to focus on ourselves is important. 38:36 – Guest: Your body will make it a point to say: pay attention to me! Your body goes into flight or fight mode and your systems shut-off, which of course is not good. You don’t want your body to stay in that state. New parents get sick frequently with newborns, because they aren’t getting enough sleep. 41:08 – Guest: Get some R&R! 41:20 – Chuck: This is great, but I have another call! Let’s do some Picks! 41:35 – Advertisement – Fresh Books! 30-Day Trial! END – Cache Fly Links: React Angular Vue.js JavaScript Ember Elm jQuery Node DevX WebReference Nicholas C. Zakas’ Books ESLint NPM – ESLint Signs and Symptoms of Untreated Lyme Disease Lyme Disease Nicholas’ Twitter JSJ 336 Episode with Zakas JSJ 075 Episode with Zakas Sponsors: Cache Fly Get A Coder Job Fresh Books Picks: Charles Max Wood Wall Calendars – 6 ft. x3 ft. Nicholas Zakas Book: The Better Angels of Our Nature: Why Violence Has Declined by Steven Pinker Adult Coloring Books

Panel: Charles Max Wood Guest: Nicholas Zakas This week on My JavaScript Story, Charles talks with Nicholas Zakas who is a blogger, author, and software engineer. Nicholas’ website is titled, Human Who Codes – check it out! You can find him on Twitter, GitHub, and LinkedIn among other social media platforms. Today, Nicholas and Chuck talk about Nicholas’ background, JavaScript, and current projects. In particular, we dive pretty deep on: 0:00 – Advertisement: Get A Coder Job! 1:00 – Chuck: Welcome! Give us a background, please, Nicholas! 1:14 – Guest: I am probably best known for making ESLint and I have written a bunch of books, too! (See links below.) 1:36 – Chuck: JSJ 336 and JSJ 075 episodes are the two past episodes we’ve had you on! (See links below.) Let’s go back and how did you get into programming? 1:58 – Guest: I think the first was written in BASIC, which was on a Laser computer. It was a cheaper knockoff version. I think I was into middle school when I got into BASIC. Then when I got into high school I did this computer project, which was the first time someone else used one of my programs. 4:02 – Chuck: Was it all in BASIC or something else? 4:13 – Guest: Just BASIC, but then transferred to something else when we got our first PC. 5:13 – Chuck: How did you get to use JavaScript? 5:18 – Guest: 1996 was my freshman year in college. Netscape 3 got into popularity around this time. I had decided that I wanted to setup a webpage to stay in-touch with high school friends who were going into different directions. I got annoyed with how static the [web] pages were. At the time, there was no CSS and the only thing you could change was the source of an image (on webpages). On the you could do... 8:35 – Chuck: You get into JavaScript and at what point did you become a prolific operator and author? 8:52 – Guest: It was not an overnight thing. It definitely was fueled by my own curiosity. The web was so new (when I was in college) that I had to explore on my own. I probably killed a few trees when I was in college. Printing off anything and everything I could to learn about this stuff! 10:03 – Guest (continues): Professors would ask ME how to do this or that on the departmental website. When I was graduating from college I knew that I was excited about the WEB. I got a first job w/o having to interview. 12:32 – Guest (continues): I got so deep into JavaScript! 13:30 – Guest (continued): They couldn’t figure out what I had done. That’s when I got more into designing JavaScript APIs. About 8 months after graduating from college I was unemployed. I had extra time on my hands. I was worried that I was going to forget the cool stuff that I just developed there. I went over the code and writing for myself how I had constructed it. My goal was to have an expandable tree. This is the design process that I went through. This is the API that I came up with so you can insert and how I went about implementing it. At some point, I was on a discussion with my former colleagues: remember that JavaScript tree thing I wrote – I wrote a description of how I did it. Someone said: Hey this is really good and you should get this published somewhere. Huh! I guess I could do that. I went to websites who were publishing articles on JavaScript. I went to submit the article to one of them. I think it was DevX or WebReference. 18:03 – Guest: A book is a compilation of different articles?! I can do that. I wanted to write a book that would fill in that next step that was missing. I didn’t know what the book was going to be, and I decided to start writing. Once I’ve had enough content I would take a step back and see what it was about. (Check out Nicholas’ books here!) 19:01 – Chuck: Oh you can turn this into a book! 19:10 – Guest: There was very little that I had planned out ahead of time. Anything that happened to me that was exciting had stumbled into my lap! 19:37 – Chuck: That’s how I felt about podcasting – it fell into my lap/life! 19:50 – Chuck: Listeners – check out the past episodes with Nicholas, please. Nicholas, what are you proud of? 20:10 – Guest: In 2006, I was at Yahoo and started off with My Yahoo Team. This was the first time that I was exposed to a massive amount of JavaScript in a single web application. 26:21 – Chuck: Can you talk about your health issues? People would definitely benefit from your example and your story. 26:44 – Guest: I think it is something important for people to understand. The guest talks about Lyme Disease. 35:49 – Chuck: Yep taking care of yourself is important! 36:00 – Guest: Yes to enjoy time with friends and explore other hobbies. Help yourself to de-stress is important. Cognitive work is very draining. When you aren’t getting the right amount of sleep your body is going to get stressed out. Take the time to do nonsense things. You need to let your brain unwind! I love these adult coloring books that they have! 38:07 – Chuck: I love to take a drive up the canyon. 38:12 – Guest. 38:24 – Chuck: Yeah to focus on ourselves is important. 38:36 – Guest: Your body will make it a point to say: pay attention to me! Your body goes into flight or fight mode and your systems shut-off, which of course is not good. You don’t want your body to stay in that state. New parents get sick frequently with newborns, because they aren’t getting enough sleep. 41:08 – Guest: Get some R&R! 41:20 – Chuck: This is great, but I have another call! Let’s do some Picks! 41:35 – Advertisement – Fresh Books! 30-Day Trial! END – Cache Fly Links: React Angular Vue.js JavaScript Ember Elm jQuery Node DevX WebReference Nicholas C. Zakas’ Books ESLint NPM – ESLint Signs and Symptoms of Untreated Lyme Disease Lyme Disease Nicholas’ Twitter JSJ 336 Episode with Zakas JSJ 075 Episode with Zakas Sponsors: Cache Fly Get A Coder Job Fresh Books Picks: Charles Max Wood Wall Calendars – 6 ft. x3 ft. Nicholas Zakas Book: The Better Angels of Our Nature: Why Violence Has Declined by Steven Pinker Adult Coloring Books

Guest: Dillon Kearns: @dillontkearns | GitHub | Incremental Elm In this episode, Dillon Kearns joins the show to talk about techniques for experimentation with Elm, making those experiments safe, the concept of mob programming, why you would want to experiment with Elm in the first place, and how you too can begin to experiment with Elm. Resources: Grant Maki's talk on experimenting in your team "Types Without Borders" by Dillon Kearns @ Elm Conf 2018 Dillon's Elm GraphQL library How Elm Code Tends Towards Simplicity by Dillon Kearns The CSS as ByteCode Talk by Richard Feldman This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. Transcript: CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode 114. My name is Charles Lowell. I'm a developer here at the Frontside. With me today as co-host on the show is David. Hello, David. DAVID: Hey, guys. CHARLES: David is also a developer here at Frontside and we are going to be talking about something that we've been talking, I guess a lot about recently and we're talking about Elm. I think we first started talking about this several years ago and then it kind of simmer down a little bit but recently, it's been top of tongue. With us to talk about Elm today is Dillon Kearns. Welcome Dillon. DILLON: Thank you so much for having me. CHARLES: I understand that you are a full time Elm consultant. You have a background as a Lean and Agile coach but have recently transitioned to doing Elm consulting full time. Now, what exactly does that mean in 2018 to be an Elm consultant. DILLON: Actually a lot of my motivation for getting into Elm consulting in the first place is I kind of realize that Elm to me is just an extension of the things that I was passionate about with Agile and software craftsmanship. I'm trying to help teams have a better experience with their code, make it more maintainable, make it easier to change, make it easier to drive things based on customer feedback and I really believe that Elm helps people do that. I used a lot of the background and experiences that I've had with Agile and Lean coaching and a lot of those same skills, in order to help organizations adopt Elm. One thing I've seen a lot of teams struggling with is trying out a lot of different frameworks. I've encountered teams that have spent months, very painfully trying out different frontend frameworks and having trouble coming to consensus about that. One of the things that I think really helps address that is having an experimental and iterative approach, that you can really use the scientific method to focus on learning, rather than getting it right the first time. I think that there's really a need to help teams through that process of introducing a new frontend framework like Elm, so that that's why I've gone into full time Elm consulting. CHARLES: That's an interesting process. It sounds like you really need to be constantly sending out spikes, doing research on whether it's Elm or some other technology to help you kind of bridge the chasm to the next generation. How do you actually do that as an organization? My guess, this kind of a question independent of Elm but maybe we can talk about how you see that play out in the context of Elm. DILLON: Right and actually, for any listeners interested in that question, I would really highly recommend Grant Maki's ElmConf talk from this year. He spoke about exactly that topic and it was at ElmConf that it's relevant whether your team is considering Elm or looking at other frameworks. I think that the key is you need to get good at experimenting in a way that's low risk and in a way that you can be constantly learning and seeing how these different technologies fit in your codebase and fit for your team. There's a quote that I really like from Woody Zuill. Have you guys heard of mob programming before? CHARLES: I heard of mob programming from a paper by Richard Garfield a long, long time ago, almost 20... I don't know if it's the same concept. DILLON: Yes. It gained a lot of momentum these days. Mob programming is essentially pair programming but with more people involved. I've really enjoyed that process actually. I think it's actually a great way to experiment with different technologies because you get all of the minds together and it's a very good way to kind of transfer knowledge and explore things together but Woody Zuill talks about mob programming and he likes to ask the question, "Why did we begin doing mob programming for the team at Hunter Industries that originally started mob programming?" People would give answers like, "Because it cuts out code review from the process because you have lots of eyeballs on it in real time," or, "Because it reduces bugs," or, "Because it gives you better quality code. It gives all the best ideas into the product in real time," and all those things are valid points that are really good benefits of mob programming. But he says those things may be true but actually, they're not why we tried mob programming. The reason we tried mob programming was because the team wanted to try it. That's a really important point. The team needs to be experimenting with things that they're passionate about and they need to be exploring things on their own terms. But with that said, another lesson from that story of kind of his team at Hunter Industries discovering mob programming is that the team didn't discover mob programming in a vacuum. Really, the team discovered mob programming because the team became really excellent at experimenting and evaluating those experiments and then, they like to talk about this phrase that Kent Beck coined, 'turn up the good.' When something is working well, we often focus on the negative things and trying to eliminate those things but what happens if we take the things that are working well and 'turn that dial up to 11.' CHARLES: Yeah, I love that. I remember in the kind of the original layout of extreme programming, talking about how I really just wanted to turn up all the things that were working for 11 or to 11, so testing, refactoring, incremental releases and things like that. DILLON: Exactly. CHARLES: I actually had one question that's maybe a little bit of a diversion. This is actually the first time I've heard of mob programming. It's definitely not the same sort of mob programming I learned about in Richard Garfield's paper. I think it was more referring to massively distributed open source in the form which is really kind of commonplace now that happens on GitHub. I think it's maybe, an obsolete definition of mob programming but how many people would be in a mob like two, three, four, five, six, seven, 10? DILLON: That's a great question. Really, the answer is of course, it depends. That's a consultant's favorite answer but it really does. My rule of thumb is I find it usually three people is a very nice size for a mob. I find that mobs tend towards around three or four people but that being said, it's important to note that mob programming is all about this idea that what is the true cost of programming. I think that often we look at programming as the act of writing code, initially and that's a very limited way of looking at coding. Because of course, 90% of our effort is spent maintaining code, making decisions around code, reproducing bugs, fixing bugs, communicating with customers about bugs -- bugs are extremely expensive -- the farther out they get, until eventually they get to the point of a customer discovering them, bugs are in extremely expensive part of software. If we can minimize bugs, that's very valuable. When you look at programming on this bigger scale and look at the bigger picture of programming, then you realize that you may be able to get one person to write the code faster but then, that person needs to code review it. That person needs to go and ask somebody question down the line when they don't have context because they weren't involved in the decision making. For example, maybe there's a UX person who doesn't have context on certain choices that were made, so there's a lot of churn, so you can kind of eliminate that churn by getting all the relevant people involved right away and that's the idea. In my experience with mob programming, it works really well to keep kind of a core of around three people. Sometimes, somebody goes up to have a conversation with somebody, take a break or answer somebody's question, maybe somebody from another team has a question that type of thing and so, the team can keep coding as a pair or whatever. But ultimately, the idea is that you get faster because you're building up this shared context and you're not spending as much time down the line answering questions, doing code reviews and things like that. CHARLES: Right. I see. DAVID: That kind of matches with my experience. Mob programming on previous teams, the way we had it set up is there was a regular mob programming chat session that the whole team was invited to but it was optional. You can just show up if you wanted to and really, that sort of made it so that there was a set of people who regularly attend -- three to five people in a session -- and they were the core group, essentially. DILLON: Right. That's another great point. Invitation is a powerful technique. If you're kind of mandating the people try an experiment or work in a certain way, ultimately it's much more powerful to let the team experiment on their own and follow their passion and they'll discover great things. It's about experimenting, rather than choosing specific experiments. While we're on this topic of kind of the real cost of coding, I think this is a good point to talk about this quality in Elm because, I think that this is one of the things that really motivates me to use Elm myself and introduce it to others is that, I think that Elm really get something about programming where there's a sort of superficial ease of certain techniques that Elm kind of goes beyond and says, "Actually, let's optimize for a different set of things that we think make code more maintainable and more delightful to work with in the long run." CHARLES: I wanted to also transition between, we were on a little diversions on mob programming but do you use mob programming as explicit technique for introducing Elm when a team is considering adopting it? DILLON: That's a fantastic question. I absolutely do. Of course, I honor the ways of working in a particular organization or team. I think that's important to do but I do strongly encourage using mobbing as a technique for knowledge sharing and when I'm on-site with a client, I find it extremely powerful as a technique for knowledge sharing and also, let's say you do an experiment, somebody is off in a corner and they're trying out Vue.js or they're trying out Elm or they're trying a particular coding technique. Then they come back to their team and they say, "Hey everybody, I tried this great thing," and now they have to spend this time convincing everybody and saying like, "Wait a minute. You didn't try this, you didn't try it that way. It wouldn't actually work in our context because of this." I think that it's very powerful to have everybody kind of involved in that process so that you can evaluate it together as a team. CHARLES: Because the thing is like, when you experience win or you experience fail, it's a very visceral feeling and that's the thing that sells you or turns you away. You can argue until you're blue in the face but words have a very limited capacity to convince, especially when compared with like physical and emotional feeling. It sounds like you can get everybody to have that shared experience, whether for the good or for the bad, you're going to arrive at a decision, orders of magnitude more quickly. They have to rely in conviction of that decision spread around the team. DILLON: Exactly. I think that hits the nail on the head and you say that we have this sort of skepticism of arguments from theoretical conversations, rather than 'show me the money,' but it's actually, try solving a real problem in this and that's exactly as it should be. I think that's one of the big antidote from this problem that I've seen in a lot of environments, where there's this analysis paralysis, especially with the state of the JavaScript ecosystem these days. I think that one of the keys to improving that situation is to get good at trying things, rather than theorizing about things. We have a tendency to want to theorize and when we do that, then we say, "Can it solve this problem? Can it solve this problem? Can it solve that problem?" You can talk about that until the cows come home but it doesn't get you anywhere and it doesn't really convince anybody of anything. The key is to find very small experiments and what I really recommend and what I'm dead focused on when I'm initially working with a client is getting something into production. Now, that doesn't mean that you need to have a road map for turning your entire application into Elm. In fact that's the whole point, is that you're not trying to do that. The point is you're trying to get as realistic of an experience as possible for what problems might occur if we do this? Will the team enjoy working with this language? Will it work well with our built pipeline? Will there be any unforeseen issues? You don't know until you actually try it, so you've got to try it and you've got to try it in tiny, tiny steps and low risk experiments. CHARLES: Right but you've got to try it for real. You don't want to try it with a TodoMVC. DILLON: Exactly. It needs to be meaningful, to really have a good understanding of what it's going to be like. CHARLES: I would say that I tend to agree but I've definitely encountered the counterargument and I also think this counterargument makes sense or perhaps where the pushback lies is if I'm constantly experimenting, then what I'm doing is I'm internally fragmenting my ecosystem and there is power in similarity. Any time you introduce something different, any time you introduce one fragment, you're introducing complexity -- a mental complexity -- like maybe I have to maintain my Elm app and I also have to have my Legacy... Or not Legacy, I've got my other JavaScript tool kit that does it in one way. Maybe I've got a couple of more because I've run these other experiments. I'm not saying that there is one way but there is power in uniformity. There is power in diversity. Where do you find the balance? DILLON: Those are all excellent points. To me, I think really the key is it's about the scientific method, you could say. The thing with the scientific method is that we often forget the last part. We get really good at hypothesizing about things. Sometimes people leave it at that, which we kind of just discussed. Sometimes, people go past the hypothesizing stage and they actually run the experiment and that's great. But then, the majority of people, if they get to that point, will forget to do the last step which is to evaluate the results. I think the key here is you need to be experimenting and this is what it means for it to be a low risk experiment. It means that you're not setting yourself off in a direction where you can't turn back. You want to set it up in such a way that you can turn away from it with minimal cost. One of the things that is really helpful for that is if you build a tiny, independent, little widget in your application, try building that in Elm. Some people will do that with a little sort of login badge in the corner of their application. One of the teams where I've introduced Elm at a Fortune 10 company, actually where we introduced Elm, we started out with just a tiny little table in one page and if we wanted to back that out, it would have been trivially easy but we decided that we wanted to go in further and invest more. CHARLES: That makes a lot of sense. Effectively, you need to have a Plan B. Don't sync all of the available time that you have to invest in an experiment. Make sure that you have a Plan B and if you need to do this widget or this table in Angular or React or Ember or whatever, you are thinking about that -- how would that work. DILLON: Exactly and the thing with experiments is the purpose of an experiment is not to build something. It's to learn. I really like this kind of ethos of lean startup, which I think is really getting much more into the mainstream in the software industry, which is a wonderful thing. The idea of lean startup, the kind of core concept is this idea of validated learning. Basically, in an environment where there's uncertainty, which is pretty much most of the things you're doing in software, the main goal is you're not shipping a product like you would be if you're trying to manufacture cars as quickly as possible. The main thing that you're producing is what they call 'validated learning' and so, you want to minimize the amount of time it takes to validate or invalidate your assumptions about something and then, you want to make it as cheap as possible to move on from that. CHARLES: I like that. So if you're going to organize your development process around this principle or maybe not organize it but integrate it into development process, how do you know that you're conducting a healthy number of experiments, versus I may be conducting too many experiments? Is there a metric that you can look at? We need to have this many experiments running at all times or this is just too many or something else. DILLON: That's a really interesting question. I think I would tend to think about that more again, as looking at the way the experiments are run, rather than 'are there too many experiments?' That's just not a problem that I've seen there being too many experiments. The pain that we tend to really see in environments where experiments are hurting teams is the way the experiments are being done. It's hard to backtrack from those experiments and as you were saying before, you kind of put yourself down this path where you can't walk it back and you create this sort of rift in the way the code is being written, which makes it more difficult to work in that codebase. The thing with experiments is they can have really big payoff. Now, you want to make sure that you're not just going in and picking up every shiny object that you see. One thing that can keep you honest with that is if you're kind of coming up with a hypothesis before you start. If you're saying, "This is the value to our business and to our team if we attempt this thing and this is what will prove that it seems to have that value and this is what will tell us, 'Actually, it doesn't have that value and we should drop it and cut our losses.'" CHARLES: That's a great heuristic. As you're saying and imagining how that might have saved my bacon in the past because I've definitely made the mistake of playing with too many shiny objects and picking things because I didn't fully evaluate what I thought the value. I was explicit with myself about what is the value that is going to bring to this project or this business. I have a theory about it but I am not thinking what is my hypothesis and how am I going to validate or invalidate? I'm thinking, I've got a short term pain that I'm experiencing and I'm grasping for this thing, which I think will solve it and I'm not properly evaluating how it's going to affect me long term. DILLON: Right and that could be a great team practice to play around with is often, teams will kind of come up with action items out of retrospectives. One thing that I think can be really beneficial for teams is to kind of flip that notion of doing action items which again, it's really just doing the middle part of the experiment where you're conducting the test but you cut out the hypothesis part and the evaluation part. Try to bring that into your team's retrospective and try to have explicit hypotheses in the retrospectives and then, in the next retrospective, evaluate the results. CHARLES: All right. I will definitely keep that in mind but this feels like a fresh take on kind of how you manage software development that I haven't encountered too much, being more scientific about it. It sounds like science-oriented development. DILLON: Right. DAVID: I like that. DILLON: There are a lot of buzzwords these days in software development, in general and it's really becoming a problem, I think in the Agile community but really, what it boils down to is these basic elements and basing decisions on feedback is one of those fundamental unit. You can call the scientific method, you can call it lean startup and validated learning, you can call it agile, you can call it whatever you want but ultimately, you need to be basing things on feedback. I think of it almost like our nerves. There's actually a disorder that some people have, which can be fatal, which is that their nerves don't tell them when they're feeling pain. I think this is a great analogy for software because that can happen to companies too. They don't feel the pain of certain decisions not landing well. Because they're not getting feedback from users, they're not getting feedback from metrics and recording, they're not getting feedback from doing that final evaluation step of their experiments, so when you fall on the ground, a small cut could be extremely harmful because you don't know the damage it's doing to you. CHARLES: I think that is a good analogy. One of the things that I'm curious about is we've been discussing a lot of techniques for experimentation and how you can integrate that into your process and how you can make your experiments safe, so let's talk a little bit about -- first of all, two things -- why would I want to experiment with Elm in the first place? Because ultimately, that's why we're here and why we're having this conversation. What's compelling about it that would make me want to experiment? And then how can I begin to experiment with Elm? DILLON: I actually just published a blog post yesterday. It's called 'How Elm Code Tends Towards Simplicity.' To your question of why would a team consider Elm, I kind of talk a little bit in this blog post about a case study at a Fortune 10 company where I introduced Elm to a few of the teams there. One of the teams there, we had actually seen an Angular project that they had worked on and often, in an enterprise environment, you have projects moving from one team to another. I actually had my hands on this Angular project. It kind of moved over to another team and we were experiencing some major pain trying to make changes in this codebase. Even making the simplest change, we were finding that there were a lot of bugs that would be introduced because there's some global variable. There's some implicit state. Sometimes, it was even reaching in and tweaking the DOM and really, the topic of conversation at our team lunches was how afraid we were to touch this codebase. Fast forward a few months and this team was asking my advice on picking a new frontend framework and I introduced them to Elm. They took a run with it and it was pretty remarkable to see this same team that had really struggled with AngularJS and they didn't really have a strong sense of what were the best practices. They weren't getting any guidance from the framework itself and the tooling around it and they actually loved the experience of working with Elm because they were saying, "This is amazing. Maybe it takes a little time to figure out how to solve a particular problem on Elm but once we do, we know that we've done it in a solid way." One of the things that I think is most powerful about Elm is that it keeps you from shooting yourself in the foot. I think that's a really good headline kind of summary of what I love about Elm. For example, tweaking the DOM. Now, it might seem like a pretty obvious thing that we just won't tweak the DOM and that's fair enough. That might not be a problem for a lot of teams. People wouldn't even reach for that technique because they're disciplined about it. But at a certain point, you start taking on enough things and then go from kind of those basic things that are going to make your code more unreliable and unsafe like tweaking the DOM and you start getting into the realm of best practices. There's so much discussion these days in the JavaScript community about best practices, which is great. It's great to discuss that but my concern is that there's a new best practice each week and the team has to agree on it, you have to find techniques for enforcing it, people have to make sure that these best practices are being followed in code reviews. Then when you look at a given piece of code, you have to trust that those best practices are being followed, so it requires a lot of work to make sure, in your reducers, in redux that you are not mutating anything. With Elm, data is just immutable. That's just how it is. There are a lot of these kind of things that are baked into the language and the expressivity of the type system allows you to bake in your own constraints. One of the things that I find really compelling about Elm is its design really prevents you from shooting yourself in the foot and it gives you tools for making sure that you take it even a step further and it helps you enforce these best practices at a compiler level. CHARLES: Now what's interesting here is it's almost like the opposite tension of experimentation is a work, right? like here, we have an example of uniformity being the more powerful track but then inside the actual macroscopic process, you want a lot of experimentation and diversity. But at the microscopic level, inside your application, it sounds like you want less experimentation and you derive a lot of strength from that but -- DILLON: That's a great point. CHARLES: -- Experiments that are possible, yeah. DILLON: I think that there is a lot of pain these days in the JavaScript community. We hear people talking often about JavaScript fatigue and it's a real thing. It takes a lot of work to stay on top of the latest best practices and frameworks and that can be a lot of fun. I love learning about the latest new frameworks and tooling but ultimately as you're saying, we don't want that experimentation so much about the fundamentals. We want some dependable, solid fundamentals and then we want the experimentation to happen within there. I think that's exactly what we see in the Elm ecosystem. We have a single kind of data store or way of managing state in Elm. It's called the Elm Architecture. In fact, it's what Redux is based on and it worked extremely well and you don't have to experiment with different data stores in Elm because that's just what Elm code looks like. Now, if you want to experiment in Elm, then there is a lot of innovation happening. One of my favorite things about Elm is that the compiler and its expressiveness has sparked a lot of creativity. One of my favorite things about Elm is the library called Elm UI. Actually, a client that I'm working with right now, it's a really interesting case study. They are kind of a very small startup. They just kind of branched off of a larger startup. They're building some tooling for this ecosystem. They were engineers at a company called Procore that does cloud document management for construction companies. They wanted to get a product-ready for a big conference for their potential clients. The reason they brought me in to help them was because they wanted to reach this ambitious target of being able to do a demo of this brand new product at this conference and they wanted to iterate very quickly. One of the things that really drew them into Elm in the first place is this library Elm UI. Elm UI essentially, Richard Feldman gives a talk on it, where he uses the analogy of it being treating CSS and HTML as bytecode for your views. I think that's a really apt way to put it. If you break down this idea of CSS -- Cascading Style Sheets, it removes the cascading part of CSS and it removes the sheets part of CSS. What you're left with is a way of expressing style and it's a way of expressing style that is able to part ways with all of the baggage of the entire history of backwards compatible decisions that CSS has ever made. If you want to vertically aligned something, then you just say, "Align vertically," you know, center vertically. If you want to center something horizontally, you say center X. It creates a high level language for expressing views. My experience with Elm UI, this may not be the right choice for every team but I love it. I use it on all of the projects that I maintain personally. I love using it because it gives you that same sense of invincibility refactoring that you get with Elm, which is remarkable that you could have that feeling with managing views. CHARLES: It's definitely something that feels like a dark art and it can't be called science. It's an art. It's a science for some people but it's historically been a dark art and something fiddly to work with. In terms of being able to make the experiment with Elm, when we talked a little bit about why you might want to experiment with it in the first place, what the business case is, I guess my next question is or a question that immediately comes to mind is supposing that we have decided to experiment with this, how do you mitigate that experiment? We talked about lowering the cost, having a way to turn away from it, having a way to make it inexpensive. For example, one of the things that I think of when evaluating a new technology is how well can I use it with old technologies. I have a lot about best practices in my tool bag. We all do. We got our all favorite libraries and pathways that are just familiar to us. One of the things that I've noticed is when adopting a new technology, one of the things that makes it easy to experiment with is how well it works with the existing technologies. I know that, we talked about Elm UI, kind of rethinking style in CSS and your views and Elm itself as a completely different language within JavaScript, that can be both liberating but it can also be limiting in the sense that I can't reach back for my existing tool if no tool exists in this new space. The kind of experience that I've had where this is really worked is systems like JRuby or Clojure, where there's a very clear pathway to be able to use Java libraries from those environments, so you always have kind of an escape hatch. What's that like in Elm? DILLON: This is a really interesting conversation because it highlights, in some ways some of the most defining features of Elm. In terms of how do you kind of pull Elm into an existing application, there are a lot of different techniques for that. It's pretty straightforward to create a little Elm app. We usually don't call them components for reasons that we can get into if we want to but that's a whole can of worms. But if you've got a little Elm application that you want to use to render a widget on your page, then it's as simple as just calling Elm.yourmodule.init and rendering it onto the page there. That's quite straightforward and if you want to interface with your existing code there are several ways to do that. There's something called port in Elm, which is how you kind of communicate by sending these messages and data back and forth between your Elm app and JavaScript. Now, this is one of the decisions, I think that defines Elm as the language and the reason this is important is because Elm decided not to make the choice that a lot of other compile to JS languages do. For example, if you look at ReasonML or PureScript or a more extreme example, TypeScript. TypeScript is a superset of JavaScript, so it's trying to allow you to gradually introduce this to get some incremental improvements for your JavaScript code, so it's extremely easy to experiment with it, which we've talked about the importance of experimentation. Now, the challenge with this technique, the tradeoff here is it's great, that it then becomes very easy to transition into it and that's an excellent strategy for the goals of TypeScript. Elm has a different set of goals, so the things that elm is focused on giving you is a truly type-safe experience. When you're working with Elm, if your Elm code says that this data is a float, then it is a float. Either, it is a float or that code is not being run and so, that's very different than the experience in TypeScript where you have these escape hatches. This is an inevitable choice for any compiled to JS language. Are you going to have escape hatches or not? Elm is really the only language out there, I think that chooses not to have escape hatches and that is actually the thing that that I love about the language because that's the only way you can truly have guarantees, rather than, "Yeah, I'm pretty sure that these type guarantees hold." DAVID: Yeah, wishes and dreams. DILLON: Yeah. CHARLES: What does it mean to have no escape hatches? because you talked about ports. Does it mean like it's impossible to use an external JavaScript library? DILLON: That's an excellent question. You absolutely can use JavaScript libraries. It means that it's being explicit and upfront about the fact that there's uncertainty in these areas. That's what it comes down to. Take for example dealing with JSON. In a JavaScript application, what we get when we're dealing with JSON is you make a request up to the server, you have some callback that passes in the data you get back and then you start pulling bits and pieces off of it and you say 'response.users subzero.firstname' and you hope that none of those things are null, none of those types are different than what you expected. In a way, it's kind of letting you pretend that you have certainty there when in fact, you don't and with Elm, the approach is quite different. You have to explicitly say, "I expect my response to have this shape. I expect it to be a list of things, which have a first name and last name which are strings," and then Elm says, "Okay, great. I'm going to check your assumptions," and if you're right, then here you go and you're in a well typed-space where you know exactly what the types are and if you're wrong, then that's just another type of data, so it's just a case statement where you say, "If my assumptions were correct, then do something and if my assumptions were incorrect, then you decide what to do from there." CHARLES: Right. For me, it sounds like there is some way because ultimately, I'm going to be getting unstructured but I'm going to be getting JSON back from the server and maybe, I have some library that's going to be doing that for me and enhancing it and adding value to that JSON in some way. But then at some point, I can present it to Elm but what you just saying is I need to be complete in making sure that I handle each case. I need to do or handle the case. Explicit about saying if the assumptions that Elm wants to make, turn out to not be true, Elm is going to make me handle the case where those assumptions were not true. DILLON: Exactly. I think that TypeScript of any type is the perfect illustration of the difference. TypeScript of any type is sort of allowing you to say, "Don't type check this. Trust me here," and Elm's approach is more kind of just be explicit about what you want me to do if your assumptions are incorrect. It doesn't let you kind of come in and say, "No, I know I'm going to be right here." CHARLES: Right but there is a way to pass data structures back and forth. DILLON: There absolutely is and actually, there's a technique that's starting to gain some traction now, which I'm really excited about, which is rather than using this sort of JavaScript interrupt technique we talked about, which is again, it's very much like communicating with a server where you're kind of sending messages and getting data back -- getting these messages with data back. But there's an alternative to that which is using web components. Actually, there's quite good support for assuming that you don't need to be compatible with Internet Explorer. Basically in a nutshell, if you can wrap a sort of declarative web component around anything, it could be a Google Maps API, it could be a syntax highlighting JavaScript library, something that you don't have an Elm library for but you want to use this JavaScript library, it's actually quite a nice experience. You just render that custom element using your Elm code just as you would any other HTML in Elm. CHARLES: Yeah I like that, so the HTML becomes the canvas or composition with other JavaScript and the semantics are very well-defined and that interface is actually pretty thin. DILLON: Exactly and the key again is that you wanted to find a declarative interface, rather than an imperative one where you're kind of just doing a series of statements where you say, "Do this and then set this value and then call this and then set this call back." Instead, you're saying, "Render this Google Maps custom element," which is centered around these coordinates and has this zoom level on. You declaratively give it the bit of information that it needs to render a particular view. CHARLES: Okay. Then I guess the final question that I have around this area is about being able to integrate existing tools and functions inside of an Elm application. Because it sounds like you could theoretically develop large parts of your application, is there a way that you can actually have other areas of your application that are not currently invested in Elm still benefit from it, in the sense for kind of need of JavaScript APIs that Elm can make available. DILLON: Right, so you're kind of talking about the reverse of that Elm reaching out to JavaScript. You're asking about, can JavaScript reach out to Elm and benefit from some of its ecosystem? CHARLES: Exactly. I say that is that another potential vector for experimentation. DILLON: It's a really interesting thought. I haven't given it too much thought, to be honest but I actually have heard it come up before and my gut feeling is that it's probably more fruitful to explore the inverse, reaching out to JavaScript from Elm and the reason is kind of the main appeal of Elm is that when you're operating within Elm, you have this sense that if it compiles, it works. Because again, this central decision to not allow escape hatches is what allows you to have that sort of robustness, so you have this feeling of bullet proof refactorings and adding new features seamlessly where you change your data modeling to say, "Here's this other case that can be represented," and then suddenly, the Elm compiler says, "Tell me what to do here, tell me what to do here and tell me what to do there," and you do it and your app is working. That's the real appeal of Elm, I think and you don't really get much of that by just calling out to an Elm library from within JavaScript. That's my gut feeling on it. CHARLES: Okay, that's fair enough. On the subject of interrupt and using tools like JSON, you actually maintain a GraphQL library for Elm. You probably have a lot of experience on this. Maybe we can talk about that as a concrete case that highlights the examples. DILLON: Yeah. I think to me this is one of the things that really highlights the power of Elm, to give you a really amazing refactoring and kind of feature creating experience. A lot of Elm libraries are prefaced by the author name, so it's still DillonKearns/ElmGraphQL. I spoke about it this year at ElmConf. In a nutshell, what it does is it actually generates code based on your GraphQL schema. For anyone who doesn't know, GraphQL is just kind of a language for expressing the shape of your API and what types of data can return. What DillonKearns on GraphQL does is it looks at your GraphQL schema and it generates an API that allows you to query that API. using this library, you can actually guarantee that you're making a valid query to your server. Again, you get this bulletproof experience of refactoring in Elm where you can do something like make a change in your API and recompile your Elm code and see whether you've made a backwards incompatible change. All of this effort of doing sort of this JSON decoding I was talking about earlier where you kind of have to explicitly say, "These are my assumptions about the shape of the JSON that I'm getting back." When you're using this library, you no longer need to make any assumptions because you're able to rely on this sort of schema of your API and so you know when you're requesting this data, you don't have to run it, see if it works and then tweak it and run it again -- this sort of cycle of checking your assumptions at runtime. It moves those assumptions that you're making from runtime to compile time and it can tell you when you compile your application, it can say, "Actually, this data you're requesting, it doesn't exist," or, "It's actually called this," or, "This is actually the type of the data." CHARLES: Right. I love that. How do you do that? Because it seems like you've got a little bit of a chicken and the egg problem because the schema is defined outside of Elm, so you have to be able to parse and understand the schema in order to generate the Elm types to be able to compile Elm code against them. Maybe I'm not -- DILLON: That's exactly right. That's exactly what it does. Now, the nice thing is that GraphQL is really designed for these types of use cases. It supports them in a first class way. If you have a GraphQL API, that means you have built into it whether you know about it or not, a way to introspect the schema. All of the queries for kind of interrogating that GraphQL server and asking what types of data does this return, what are all your queries that I can run, it's built into it by the framework, so that comes for free. Getting up and running with this package I built is as simple as running a little npm CLI, pointing it to either your URL for your server or the JSON form of your schema, if you prefer and then, it generates the code for you. CHARLES: Wow, that sounds fantastic. This is the exact kind of thing that feels like it would be cool if I could just start using this library to manage the GraphQL of my application but I'm consuming that GraphQL from other JavaScript but it's the Elm code that's managing it. Do you see what I mean? DILLON: I hadn't considered that. I guess you could. You're right. Maybe I'm so smitten with Elm that it's hard to see an in-between but I guess, you could get some benefits from that approach. CHARLES: Right and as an experiment of course. DILLON: There you go. There you go. CHARLES: All right. With that, I think we'll wrap it up. Thank you so much, Dillon for coming on and talking with us on the podcast. DILLON: My pleasure. I really enjoyed the conversation. CHARLES: I actually got so many great tidbits from so many different areas of software development in Elm but also, just in kind of other things that I'm interested in trying. It was a really great conversation. DILLON: I had a lot of fun and I love discussing these things. For any listeners who are interested in this stuff, feel free to reach out to me on the Elm Slack or on Twitter. I'm at @DillonTKearns. I'm also offering a free intro Elm talk for any companies that are kind of entertaining the idea of doing an experiment with Elm. If you go to IncrementalElm.com/Intro, you can find out about some of the talks that I'm offering. CHARLES: All right. Well, thank you very much and we, as always are the Frontside. We build software that you can stake your future on and you can get in touch with us at @TheFrontside on Twitter or Contact@Frontside.io on email. Please send us any questions you might have, any topics that you'd like to hear about and we look forward to hearing from you and we will see you next week.

This week, Keith and Paul talk The Hardest Problem in Application Security: Visibility. In the news, Google patches critical remote code execution bugs in Android OS, JavaScript API for face recognition in the browser with tensorflow.js, Social media apps are 'deliberately' addictive to users, and more on this episode of Application Security Weekly!   Full Show Notes: https://wiki.securityweekly.com/ASW_Episode23   Visit https://www.securityweekly.com/asw for all the latest episodes!   Visit https://www.activecountermeasures/asw to sign up for a demo or buy our AI Hunter!!   →Visit our website: https://www.securityweekly.com →Follow us on Twitter: https://www.twitter.com/securityweekly →Like us on Facebook: https://www.facebook.com/secweekly

This week, Keith and Paul talk The Hardest Problem in Application Security: Visibility. In the news, Google patches critical remote code execution bugs in Android OS, JavaScript API for face recognition in the browser with tensorflow.js, Social media apps are 'deliberately' addictive to users, and more on this episode of Application Security Weekly!   Full Show Notes: https://wiki.securityweekly.com/ASW_Episode23   Visit https://www.securityweekly.com/asw for all the latest episodes!   Visit https://www.activecountermeasures/asw to sign up for a demo or buy our AI Hunter!!   →Visit our website: https://www.securityweekly.com →Follow us on Twitter: https://www.twitter.com/securityweekly →Like us on Facebook: https://www.facebook.com/secweekly

Добрый день уважаемые слушатели. Представляем новый выпуск подкаста RWpod. В этом выпуске: Ruby Rails 5.2 uses AES-256-GCM authenticated encryption as default cipher for encrypting messages, Quest for Ruby Pattern Matching и Find the cause of randomly failing tests with RSpec bisect Frankenstein's ActiveRecord: How to stitch together complex ActiveRecord queries from simple parts и Understanding Boolean Operator Precedence in Ruby (&&, and, ||, or) JavaScript ECMAScript 2018 Language Specification Approved and Posted, Doing Vue after three years with React и I abandoned React in favor of Hyperapp — Here's why TensorFlow.js, Machine Learning and Flappy Bird: Frontend Artificial Intelligence, Face-api.js — JavaScript API for Face Recognition in the Browser with tensorflow.js, Lepto - automated image Editing, Optimization and Analysis via CLI and a web interface, Rabbit Ear - a creative coding javascript library for designing origami и Tenori-on✨ - a dope electronic music instrument sequencer thinkie that Yamaha made for a hot minute

Добрый день уважаемые слушатели. Представляем новый выпуск подкаста RWpod. В этом выпуске: Ruby Ruby's New JIT, Ruby 2.5 adds Process#last_status и Ruby 3x3 - What's News? Cleaning up: ActiveRecord::Dirty 5.2 API Changes, How to use Query Objects to refactor Rails SQL-queries и How to search by color in Elasticsearch Technical Tuesdays: Using GraphQL, a Ruby on Rails introduction и SingleCov - more actionable + faster than SimpleCov JavaScript React Native has been relicensed to MIT, Ember 3.0 Released, Parcel v1.6.0: Zero Config ES6+ and JSX, Node and Electron Targets, Bundle Statistics, and more! и Phaser 3.0 is out How to keep your JavaScript code simple and increase its readability и Handling long titles with truncation Face-verify.js: Monitoring who is physically looking at a website for additional security, Blotter.js - a JavaScript API for drawing unconventional text effects on the web и Front-end Job Interview Questions book

JSJ 268 Building Microsoft Office Extensions with Javascript with Tristan Davis and Sean Laberee This episode is live at the Microsoft Build 2017 with Charles Max Wood and AJ O’Neal. We have Tristan Davis and Sean Laberee from the Office Team at Microsoft. Tune in and learn more about what’s new with Microsoft Office Extensions! [00:01:25] – Introduction to Tristan Davis and Sean Laberee Tristan Davis and Sean Laberee are Program Managers on the Microsoft Office team, focused on Extensibility. Questions for Tristan and Sean [00:01:45] – Extending Office functionality with Javascript Office isn’t just an application on Windows that runs on your PC. It is running on iPhone, iPad, Android tablet, and apps on the browser with Office Online. The team needs a new platform, add-ins, which allow you to build apps that run across all places. It’s HTML and Javascript. HTML for all the UI and a series of Javascript module calls for the document properties. Sometimes we call it OfficeJS. [00:03:20] – This works on any version of Office? It works on Office on Windows, Mac, Online and iPad. [00:03:55] – HTML and CSS suck on mobile? There are things that you’re going to want to do when you know you’re running on a mobile device. If you look at an add-in running on Outlook for iPhone, the developer does a lot of things to make that feel like part of the iPhone UI. Tristan believes that you could build a great add-in for Office using HTML and JavaScript. [00:05:20] – Are these apps written with JavaScript or you have a Native with WebView? Office itself is Native. All of it is Native code but the platform is very much web. The main piece of it is pointing at the URL. Just go load that URL. And then, you can also call functions in your JavaScript. [00:06:35] – Why would you do this? How does it work? The add-in platform is a way to help developers turn Word, Excel and PowerPoint into the apps that actually solve user’s business problems. The team will give you the tools with HTML and JavaScript to go and pop into the Word UI and the API’s that let you go manipulate the paragraph and texts inside of Word. Or in Excel, you might want to create custom formulas or visualizations. The team also let people use D3 to generate their own Excel charts. And developers want to extend Office because it’s where a lot of business workers spend their days 0 in Outlook, Teams, Word, Excel. [00:10:00] – How did this get delivered to them? There are 2 ways to get this delivered. One, there’s an Office Store. Second, if you go into Word, Excel, and PowerPoint, there’s a store button and you can see tons of integrations with partners. For enterprises, IT can deploy add-ins to the users’ desktops without having stress about deploying MSI’s and other software deployments that the web completely rids off. The add-ins make a whole lot of pain the past completely go away. [00:11:00] – Everybody in the company can use a particular plug-in by distributing it with Office? That’s right. You can go to Office 365 add-in experience. Here’s the add-in and you can to specific people or everyone who’s part of a group. For the developer’s perspective, if you have the add-in deployed to your client, you could actually push updates to the web service and your users get the updates instantly. It’s a lot faster turn-around model. [00:14:20] – What about conversations or bot integrations? There’s the idea of connectors at Teams. You can subscribe to this web book and it’ll publish JSON. When the JSON is received, a new conversation inside of Teams or Outlook will be created. For example, every time someone posts on Stack Overflow with one of the tags that team cares about, it posts on Outlook. It’s a great way to bring all the stuff. Rather than have 20 different apps that are shooting 20 different sets of notifications, it’s just all conversations in email, making do all the standard email things. And in the connector case, it’s a push model. The user could choose what notifications they want. You’d also learn things like bots. You can have bots in Teams and Skype. The users can interact with them with their natural language. [00:18:40] – How about authentication? As long as you’re signed into Office, you can call JavaScript API to give you an identity token for the sign in user and it will hand you a JWT back. That’s coming from Azure Active Directory or from whatever customer directory service. That’s standard. If you want to do more, you can take that identity token and you can exchange that for a token that can call Microsoft graph. This app wants to get access to phone, are you okay with that? Assuming the user says yes, the user gets a token that can go and grab whatever data he wants from the back-end. [00:20:00] – Where does it store the token? That’s up to the developer to decide how they want to handle that but there are facilities that make sure you can pop up a dialog box and you can go to the LO-flow. You could theoretically cache it in the browser or a cookie. Or whatever people think is more appropriate for the scenario. [00:20:55] – What does the API actually look like from JavaScript? If you’re familiar with Excel UI, you can look at Excel API. It’s workbook.worksheets.getItem() and you can pass the name of the worksheet. It can also pass the index of the worksheet. [00:22:30] – What’s the process of getting setup? There’s a variety of options. You can download Office, write XML manifest, and take a sample, and then, side loads it into Office. You can also do that through web apps. There’s no install required because you can go work against Office Online. In the Insert menu, there’s a way to configure your add-ins. There’s upload a manifest there and you can just upload the XML. That’s going to work against whatever web server you have set up. So it’s either on your local machine or up in the cloud. It’s as much as like regular web development. Just bring your own tools. [00:24:15] – How do you protect me as a plug-in developer? There’s an access add-in that will ask your permission to access, say, a document. Assume, they say yes, pipes are opened and they can just go talk to those things. But the team also tries to sandbox it by iframes. It’s not one page that has everybody’s plug-ins intermingle that people can pole at other people’s stuff. [00:27:20] – How do you support backward compatibility? There are cases where we change the behavior of the API. Every API is gated by requirement set. So if a developer needs access to a requirement set, he gets an aggregate instead of API’s that he can work with but it isn’t fixed forever. But it’s not at that point yet where we end up to remove things completely. In Office JS, we’ve talked about API’s as one JavaScript library but really, it’s a bootstrap that brings in a bunch of other pieces that you need. [00:30:00] – How does that work on mobile? Do they have to approve download for all components? You can download components by using the browser that the operating system gives. It’s another one of the virtues of being based on the web. Every platform that has a web browser can have JavaScript execution run-time. It allows for the way that their app guidelines are written. [00:33:15] – How about testing? It’s a place where there’s still have work to do. There’s a bunch of open-source projects that partners have started to do that. What they’ve done is they’ve built a testing library. Whatever the mock is, it's just a thing on Github. It is open-source friendly. So the team could be able to contribute to it. “Here’s an interesting test case for this API. I want to make sure that it behaves like this. [00:35:50] – Could you write it with any version for JavaScript e.g. TypeScript? A Huge chunk of the team is big TypeScript fans. They’ve done a lot of work to make sure that TypeScript experience is excellence. Type is basically a collection of typing files for TypeScript. There’s a runtime process that parses your TypeScript, gives you feedback on your code, and checks for errors. You can also run it in the background. There’s an add-in called Script Lab. Script Lab is literally, you hit the code button and you get a web IDE right there. You can go start typing JavaScript code, play with API’s, and uses TypeScript by default. It’ll just actually load your code in the browser, executes, and you can start watching. [00:39:25] – Are there any limitations on which JavaScript libraries you can pull in? There a no limitations in place right now. There are partners that use Angular. There are partners that are big React fans. If you’re a web dev, you can bring whatever preferences around frameworks, around tools, around TypeScript versus JavaScript. [00:45:20] – What’s the craziest thing you’ve seen done with this API? Battleship was pretty cool. There’s also Star Wars entering credits theme for PowerPoint. [00:46:40] – If a developer is building a plug-in and get paid for it, does Microsoft take credit for that? There are 2 ways that folks can do it. You can do paid add-ins to the store. Either you do the standard perpetual 99 cents or you can do subscriptions, where it’s $2.99/month. Tristan encourages that model because integrations are just a piece of some larger piece of software. But Microsoft is not in the business of trying to get you to pay me a little bit of 10 cents a dollar. It’s really in the business of making sure that you can integrate with Office as quickly as possibly can. When the users go to the store, they can use the same Microsoft account that you use to buy Xbox games or movies in the Xbox, Windows apps in the Windows store. [00:52:00] – The App Model If folks are interested in the app model, they should go to dev.office.com to learn more about it because that’s where all the documentation is. Check out our Github. Right there in the open, there’s the spec. Literally, the engineers who are coding the product are reading the same marked-down files in the same repo that you, as a developer, can come and look at. And you can comment. You can add issues like you could have a dialogue with that PM. Under the OfficeDev, you’ll find a tunnel repository that contains samples. Our docs are there. Picks AJ O'Neal Lithium Charles Max Wood Miracle Morning by Hal Erod Clean Code by Uncle Bob Martin Ketogenic diet Tristan Davis Amazon Echo Microbiome Sean Laberee Running Garmin watch

JSJ 268 Building Microsoft Office Extensions with Javascript with Tristan Davis and Sean Laberee This episode is live at the Microsoft Build 2017 with Charles Max Wood and AJ O’Neal. We have Tristan Davis and Sean Laberee from the Office Team at Microsoft. Tune in and learn more about what’s new with Microsoft Office Extensions! [00:01:25] – Introduction to Tristan Davis and Sean Laberee Tristan Davis and Sean Laberee are Program Managers on the Microsoft Office team, focused on Extensibility. Questions for Tristan and Sean [00:01:45] – Extending Office functionality with Javascript Office isn’t just an application on Windows that runs on your PC. It is running on iPhone, iPad, Android tablet, and apps on the browser with Office Online. The team needs a new platform, add-ins, which allow you to build apps that run across all places. It’s HTML and Javascript. HTML for all the UI and a series of Javascript module calls for the document properties. Sometimes we call it OfficeJS. [00:03:20] – This works on any version of Office? It works on Office on Windows, Mac, Online and iPad. [00:03:55] – HTML and CSS suck on mobile? There are things that you’re going to want to do when you know you’re running on a mobile device. If you look at an add-in running on Outlook for iPhone, the developer does a lot of things to make that feel like part of the iPhone UI. Tristan believes that you could build a great add-in for Office using HTML and JavaScript. [00:05:20] – Are these apps written with JavaScript or you have a Native with WebView? Office itself is Native. All of it is Native code but the platform is very much web. The main piece of it is pointing at the URL. Just go load that URL. And then, you can also call functions in your JavaScript. [00:06:35] – Why would you do this? How does it work? The add-in platform is a way to help developers turn Word, Excel and PowerPoint into the apps that actually solve user’s business problems. The team will give you the tools with HTML and JavaScript to go and pop into the Word UI and the API’s that let you go manipulate the paragraph and texts inside of Word. Or in Excel, you might want to create custom formulas or visualizations. The team also let people use D3 to generate their own Excel charts. And developers want to extend Office because it’s where a lot of business workers spend their days 0 in Outlook, Teams, Word, Excel. [00:10:00] – How did this get delivered to them? There are 2 ways to get this delivered. One, there’s an Office Store. Second, if you go into Word, Excel, and PowerPoint, there’s a store button and you can see tons of integrations with partners. For enterprises, IT can deploy add-ins to the users’ desktops without having stress about deploying MSI’s and other software deployments that the web completely rids off. The add-ins make a whole lot of pain the past completely go away. [00:11:00] – Everybody in the company can use a particular plug-in by distributing it with Office? That’s right. You can go to Office 365 add-in experience. Here’s the add-in and you can to specific people or everyone who’s part of a group. For the developer’s perspective, if you have the add-in deployed to your client, you could actually push updates to the web service and your users get the updates instantly. It’s a lot faster turn-around model. [00:14:20] – What about conversations or bot integrations? There’s the idea of connectors at Teams. You can subscribe to this web book and it’ll publish JSON. When the JSON is received, a new conversation inside of Teams or Outlook will be created. For example, every time someone posts on Stack Overflow with one of the tags that team cares about, it posts on Outlook. It’s a great way to bring all the stuff. Rather than have 20 different apps that are shooting 20 different sets of notifications, it’s just all conversations in email, making do all the standard email things. And in the connector case, it’s a push model. The user could choose what notifications they want. You’d also learn things like bots. You can have bots in Teams and Skype. The users can interact with them with their natural language. [00:18:40] – How about authentication? As long as you’re signed into Office, you can call JavaScript API to give you an identity token for the sign in user and it will hand you a JWT back. That’s coming from Azure Active Directory or from whatever customer directory service. That’s standard. If you want to do more, you can take that identity token and you can exchange that for a token that can call Microsoft graph. This app wants to get access to phone, are you okay with that? Assuming the user says yes, the user gets a token that can go and grab whatever data he wants from the back-end. [00:20:00] – Where does it store the token? That’s up to the developer to decide how they want to handle that but there are facilities that make sure you can pop up a dialog box and you can go to the LO-flow. You could theoretically cache it in the browser or a cookie. Or whatever people think is more appropriate for the scenario. [00:20:55] – What does the API actually look like from JavaScript? If you’re familiar with Excel UI, you can look at Excel API. It’s workbook.worksheets.getItem() and you can pass the name of the worksheet. It can also pass the index of the worksheet. [00:22:30] – What’s the process of getting setup? There’s a variety of options. You can download Office, write XML manifest, and take a sample, and then, side loads it into Office. You can also do that through web apps. There’s no install required because you can go work against Office Online. In the Insert menu, there’s a way to configure your add-ins. There’s upload a manifest there and you can just upload the XML. That’s going to work against whatever web server you have set up. So it’s either on your local machine or up in the cloud. It’s as much as like regular web development. Just bring your own tools. [00:24:15] – How do you protect me as a plug-in developer? There’s an access add-in that will ask your permission to access, say, a document. Assume, they say yes, pipes are opened and they can just go talk to those things. But the team also tries to sandbox it by iframes. It’s not one page that has everybody’s plug-ins intermingle that people can pole at other people’s stuff. [00:27:20] – How do you support backward compatibility? There are cases where we change the behavior of the API. Every API is gated by requirement set. So if a developer needs access to a requirement set, he gets an aggregate instead of API’s that he can work with but it isn’t fixed forever. But it’s not at that point yet where we end up to remove things completely. In Office JS, we’ve talked about API’s as one JavaScript library but really, it’s a bootstrap that brings in a bunch of other pieces that you need. [00:30:00] – How does that work on mobile? Do they have to approve download for all components? You can download components by using the browser that the operating system gives. It’s another one of the virtues of being based on the web. Every platform that has a web browser can have JavaScript execution run-time. It allows for the way that their app guidelines are written. [00:33:15] – How about testing? It’s a place where there’s still have work to do. There’s a bunch of open-source projects that partners have started to do that. What they’ve done is they’ve built a testing library. Whatever the mock is, it's just a thing on Github. It is open-source friendly. So the team could be able to contribute to it. “Here’s an interesting test case for this API. I want to make sure that it behaves like this. [00:35:50] – Could you write it with any version for JavaScript e.g. TypeScript? A Huge chunk of the team is big TypeScript fans. They’ve done a lot of work to make sure that TypeScript experience is excellence. Type is basically a collection of typing files for TypeScript. There’s a runtime process that parses your TypeScript, gives you feedback on your code, and checks for errors. You can also run it in the background. There’s an add-in called Script Lab. Script Lab is literally, you hit the code button and you get a web IDE right there. You can go start typing JavaScript code, play with API’s, and uses TypeScript by default. It’ll just actually load your code in the browser, executes, and you can start watching. [00:39:25] – Are there any limitations on which JavaScript libraries you can pull in? There a no limitations in place right now. There are partners that use Angular. There are partners that are big React fans. If you’re a web dev, you can bring whatever preferences around frameworks, around tools, around TypeScript versus JavaScript. [00:45:20] – What’s the craziest thing you’ve seen done with this API? Battleship was pretty cool. There’s also Star Wars entering credits theme for PowerPoint. [00:46:40] – If a developer is building a plug-in and get paid for it, does Microsoft take credit for that? There are 2 ways that folks can do it. You can do paid add-ins to the store. Either you do the standard perpetual 99 cents or you can do subscriptions, where it’s $2.99/month. Tristan encourages that model because integrations are just a piece of some larger piece of software. But Microsoft is not in the business of trying to get you to pay me a little bit of 10 cents a dollar. It’s really in the business of making sure that you can integrate with Office as quickly as possibly can. When the users go to the store, they can use the same Microsoft account that you use to buy Xbox games or movies in the Xbox, Windows apps in the Windows store. [00:52:00] – The App Model If folks are interested in the app model, they should go to dev.office.com to learn more about it because that’s where all the documentation is. Check out our Github. Right there in the open, there’s the spec. Literally, the engineers who are coding the product are reading the same marked-down files in the same repo that you, as a developer, can come and look at. And you can comment. You can add issues like you could have a dialogue with that PM. Under the OfficeDev, you’ll find a tunnel repository that contains samples. Our docs are there. Picks AJ O'Neal Lithium Charles Max Wood Miracle Morning by Hal Erod Clean Code by Uncle Bob Martin Ketogenic diet Tristan Davis Amazon Echo Microbiome Sean Laberee Running Garmin watch

JSJ 268 Building Microsoft Office Extensions with Javascript with Tristan Davis and Sean Laberee This episode is live at the Microsoft Build 2017 with Charles Max Wood and AJ O’Neal. We have Tristan Davis and Sean Laberee from the Office Team at Microsoft. Tune in and learn more about what’s new with Microsoft Office Extensions! [00:01:25] – Introduction to Tristan Davis and Sean Laberee Tristan Davis and Sean Laberee are Program Managers on the Microsoft Office team, focused on Extensibility. Questions for Tristan and Sean [00:01:45] – Extending Office functionality with Javascript Office isn’t just an application on Windows that runs on your PC. It is running on iPhone, iPad, Android tablet, and apps on the browser with Office Online. The team needs a new platform, add-ins, which allow you to build apps that run across all places. It’s HTML and Javascript. HTML for all the UI and a series of Javascript module calls for the document properties. Sometimes we call it OfficeJS. [00:03:20] – This works on any version of Office? It works on Office on Windows, Mac, Online and iPad. [00:03:55] – HTML and CSS suck on mobile? There are things that you’re going to want to do when you know you’re running on a mobile device. If you look at an add-in running on Outlook for iPhone, the developer does a lot of things to make that feel like part of the iPhone UI. Tristan believes that you could build a great add-in for Office using HTML and JavaScript. [00:05:20] – Are these apps written with JavaScript or you have a Native with WebView? Office itself is Native. All of it is Native code but the platform is very much web. The main piece of it is pointing at the URL. Just go load that URL. And then, you can also call functions in your JavaScript. [00:06:35] – Why would you do this? How does it work? The add-in platform is a way to help developers turn Word, Excel and PowerPoint into the apps that actually solve user’s business problems. The team will give you the tools with HTML and JavaScript to go and pop into the Word UI and the API’s that let you go manipulate the paragraph and texts inside of Word. Or in Excel, you might want to create custom formulas or visualizations. The team also let people use D3 to generate their own Excel charts. And developers want to extend Office because it’s where a lot of business workers spend their days 0 in Outlook, Teams, Word, Excel. [00:10:00] – How did this get delivered to them? There are 2 ways to get this delivered. One, there’s an Office Store. Second, if you go into Word, Excel, and PowerPoint, there’s a store button and you can see tons of integrations with partners. For enterprises, IT can deploy add-ins to the users’ desktops without having stress about deploying MSI’s and other software deployments that the web completely rids off. The add-ins make a whole lot of pain the past completely go away. [00:11:00] – Everybody in the company can use a particular plug-in by distributing it with Office? That’s right. You can go to Office 365 add-in experience. Here’s the add-in and you can to specific people or everyone who’s part of a group. For the developer’s perspective, if you have the add-in deployed to your client, you could actually push updates to the web service and your users get the updates instantly. It’s a lot faster turn-around model. [00:14:20] – What about conversations or bot integrations? There’s the idea of connectors at Teams. You can subscribe to this web book and it’ll publish JSON. When the JSON is received, a new conversation inside of Teams or Outlook will be created. For example, every time someone posts on Stack Overflow with one of the tags that team cares about, it posts on Outlook. It’s a great way to bring all the stuff. Rather than have 20 different apps that are shooting 20 different sets of notifications, it’s just all conversations in email, making do all the standard email things. And in the connector case, it’s a push model. The user could choose what notifications they want. You’d also learn things like bots. You can have bots in Teams and Skype. The users can interact with them with their natural language. [00:18:40] – How about authentication? As long as you’re signed into Office, you can call JavaScript API to give you an identity token for the sign in user and it will hand you a JWT back. That’s coming from Azure Active Directory or from whatever customer directory service. That’s standard. If you want to do more, you can take that identity token and you can exchange that for a token that can call Microsoft graph. This app wants to get access to phone, are you okay with that? Assuming the user says yes, the user gets a token that can go and grab whatever data he wants from the back-end. [00:20:00] – Where does it store the token? That’s up to the developer to decide how they want to handle that but there are facilities that make sure you can pop up a dialog box and you can go to the LO-flow. You could theoretically cache it in the browser or a cookie. Or whatever people think is more appropriate for the scenario. [00:20:55] – What does the API actually look like from JavaScript? If you’re familiar with Excel UI, you can look at Excel API. It’s workbook.worksheets.getItem() and you can pass the name of the worksheet. It can also pass the index of the worksheet. [00:22:30] – What’s the process of getting setup? There’s a variety of options. You can download Office, write XML manifest, and take a sample, and then, side loads it into Office. You can also do that through web apps. There’s no install required because you can go work against Office Online. In the Insert menu, there’s a way to configure your add-ins. There’s upload a manifest there and you can just upload the XML. That’s going to work against whatever web server you have set up. So it’s either on your local machine or up in the cloud. It’s as much as like regular web development. Just bring your own tools. [00:24:15] – How do you protect me as a plug-in developer? There’s an access add-in that will ask your permission to access, say, a document. Assume, they say yes, pipes are opened and they can just go talk to those things. But the team also tries to sandbox it by iframes. It’s not one page that has everybody’s plug-ins intermingle that people can pole at other people’s stuff. [00:27:20] – How do you support backward compatibility? There are cases where we change the behavior of the API. Every API is gated by requirement set. So if a developer needs access to a requirement set, he gets an aggregate instead of API’s that he can work with but it isn’t fixed forever. But it’s not at that point yet where we end up to remove things completely. In Office JS, we’ve talked about API’s as one JavaScript library but really, it’s a bootstrap that brings in a bunch of other pieces that you need. [00:30:00] – How does that work on mobile? Do they have to approve download for all components? You can download components by using the browser that the operating system gives. It’s another one of the virtues of being based on the web. Every platform that has a web browser can have JavaScript execution run-time. It allows for the way that their app guidelines are written. [00:33:15] – How about testing? It’s a place where there’s still have work to do. There’s a bunch of open-source projects that partners have started to do that. What they’ve done is they’ve built a testing library. Whatever the mock is, it's just a thing on Github. It is open-source friendly. So the team could be able to contribute to it. “Here’s an interesting test case for this API. I want to make sure that it behaves like this. [00:35:50] – Could you write it with any version for JavaScript e.g. TypeScript? A Huge chunk of the team is big TypeScript fans. They’ve done a lot of work to make sure that TypeScript experience is excellence. Type is basically a collection of typing files for TypeScript. There’s a runtime process that parses your TypeScript, gives you feedback on your code, and checks for errors. You can also run it in the background. There’s an add-in called Script Lab. Script Lab is literally, you hit the code button and you get a web IDE right there. You can go start typing JavaScript code, play with API’s, and uses TypeScript by default. It’ll just actually load your code in the browser, executes, and you can start watching. [00:39:25] – Are there any limitations on which JavaScript libraries you can pull in? There a no limitations in place right now. There are partners that use Angular. There are partners that are big React fans. If you’re a web dev, you can bring whatever preferences around frameworks, around tools, around TypeScript versus JavaScript. [00:45:20] – What’s the craziest thing you’ve seen done with this API? Battleship was pretty cool. There’s also Star Wars entering credits theme for PowerPoint. [00:46:40] – If a developer is building a plug-in and get paid for it, does Microsoft take credit for that? There are 2 ways that folks can do it. You can do paid add-ins to the store. Either you do the standard perpetual 99 cents or you can do subscriptions, where it’s $2.99/month. Tristan encourages that model because integrations are just a piece of some larger piece of software. But Microsoft is not in the business of trying to get you to pay me a little bit of 10 cents a dollar. It’s really in the business of making sure that you can integrate with Office as quickly as possibly can. When the users go to the store, they can use the same Microsoft account that you use to buy Xbox games or movies in the Xbox, Windows apps in the Windows store. [00:52:00] – The App Model If folks are interested in the app model, they should go to dev.office.com to learn more about it because that’s where all the documentation is. Check out our Github. Right there in the open, there’s the spec. Literally, the engineers who are coding the product are reading the same marked-down files in the same repo that you, as a developer, can come and look at. And you can comment. You can add issues like you could have a dialogue with that PM. Under the OfficeDev, you’ll find a tunnel repository that contains samples. Our docs are there. Picks AJ O'Neal Lithium Charles Max Wood Miracle Morning by Hal Erod Clean Code by Uncle Bob Martin Ketogenic diet Tristan Davis Amazon Echo Microbiome Sean Laberee Running Garmin watch

JSJ 267 Node 8 with Mikeal Rogers, Arunesh Chandra, and Anna Henningsen On today’s episode of JavaScript Jabber we have panelists Joe Eames, AJ O’Neil, Amiee Knight and Charles Max Wood and we are talking about Node 8. To help us we have special guests Mikeal Rodgers, Arunesh Chandra, and Anna Henningsen. It’s going to be a great show. Tune in. [1:56] Is Node 8 just an update or is there more? More than just an update Two main points: Improved Prana support Native API Native APIs are helpful for Native Add-ons. For both the consumer and the developer side. Prior to update these Node Native modules ran in C++ and bound to specific to Node 8 APIs. Causes these modules to be updated or reconciled every time these modules are rereleased. Creates burden for module maintainers. Creates friction in upgrading Node versions in production departments. If you have a deployment depending on a certain Native module, some of the modules may not get updated in time when updating your Node versions. Keeping people from updating Node. Creates compatibility issues with Node users not using Node 8 Experimental support for a Native layer in Node 8 to eliminate these issues as much as possible. Important milestone for the module ecosystem. You can write extensions for Node in C++ and it decouples V8 so you can use something else on the front. Modules takes dependency on V8 API specific to a particular version. So if V8 changes your module will be extracted from that. As a side benefit, you can have another VM to take advantage of that. Major version upgrades mean updating Native modules and usually some of those modules haven’t updated to the newest version of Node and be complicated. Deep dependency wise, about 30% depends on a Native module somewhere In the future, with the Native API, you’ll be able to update Node without breaking modules. [5:51] What kind of work went into this? Most of the work was in C++ First thing that was done was, they looked at the top dependent Native modules in the ecosystem. Looked for what kind of V8 exposure they had and cataloged it Looked at how these APIs and what their purposes were Looked for a way to extract them so that they are part of Node Core Created neutral APIs, now part of the Node core. All C APIs Also has a C++ wrapper to improves usability of the API. [7:17] What’s an example of what you can do with these APIs? Native modules allows for tighter integration and better module performance Specific APIs that you can use in V8 that isn’t available through JavaScript If you have a C++ variable code and you want to expose a variable into JavaScript, that is V8 API note a Node 8 API Having it bound directly to the VM was something they wanted for a long time Google controls V8 and they bind to V8 Created a better relationship with Google starting in IOJS Also worked with Microsoft with their Node Shocker work. Same with SpiderMonkey SpiderNode is in the works [9:23] Have you guys done any testing for performance? Some. There is a performance working group. There is a need to stay on top of V8 V8 team has focused on new language features Many features have been added over the years Many didn’t come in optimized The performance profile has changed with these features If you’re using new language features, you will see a performance boost In core, still tracking down code that was specific to the old optimizer and rewriting i to work the new optimizer Turbo C compiler hasn’t landed yet, but is to come. Will have a completely different performance profile In most real world applications it will be faster Waiting on the release to take a version of V8 to make it easier to upgrade features in the future [11:28] Are the new features picked up from V8 or implemented in Node? It’s all in V8 Better longterm support Promises are made better in Node as a platform Added new method called util.promisify() Implementation comes from V8 Allows for more optimization for promises in Node core Promise support for the one-deprecated domains module. [13:02] Is there anything more than NMP 5? First off, delete your NMP cache. It’s in your home directory usually with a .npm extension [14:09] What are the new features in V8? Unlimited heap sizes, previously had a 4gb limit. No fixed limit. [14:09] Will you see things like chakra come out tuned for servers? Profiles of a server for application process are getting smaller Getting cut into containers and VMs and micro services Vms that have cold boot time and run quickly in a strained environment is looking more like what we will see in the future Yes, especially if you’re using cloud functions V8 is optimized for phones, but Chakra is even more so Looking for opportunities for VMs can be solely optimized for a device target Node take advantage of that VM VM neutrality is an interesting concept VM Vendors trying to optimize it based on workloads of a server Opens opportunities for Node Node Chakra has been proved to iOS. You can cut off jitting off which was a requirement to be able to be in the Apple App Store Node is not just for servers anymore Node doesn’t take a long time configuring it When a developer runs code on an IoT or a mobile app they don’t control the VM that is bundled, they run it on top of Node and it just works. VM neutrality gives a new vector, so you can swam a whole different VM [18:44] When running different engines like iOS vs Android, does the profile change? What it comes down to is if it’s eventive programming The browser is an eventive environment, is very efficient waiting for things to happen before it does something The way that we program servers and nodes are the same as well the basics are the same generally environmental differences exist but the programming model is usually the same What does impact it is memory and processor and hardware and things like that That is where tuning the VM comes into play [20:29] What is the new Async Hooks API used for? Node has been lacking for automated inspection of Async Hook No way for Node to tell you when scheduling and beginning of an Async operation. Hook helps with that it’s a way for developers to write debugging features Node tells the application that it’s working with Asynchronous way. The embedded inspector has been embedded since Node 6 Now has a JavaScript API to use it You can use things like Chrome debugger inside the running node process Old debugging protocol has been removed VM.run is still there but in the process of being deprecated [22:34] How like is the experimental Node API will change? Marked as experimental because it’s the first time in the open Hopefully out of experimental soon Soon can port API to the existing LTS Looking for more people to participate with the new API and give feedback Fix any concerns before it goes to LTS Some other experimental things are in the works like ASync Hooks and how it interacts with promises Renaming some features Another new feature - serializer and deserializer that comes with V8 experimental but will most likely stay [25:31] what is your standard for going to LTS? Major releases every 6 months Next Oct Node 9 will come out and then Node 8 will be LTS Documentation, updates, additions etc will be ready then Plan to do it for 2.5 years Every even releases come out to LTS as the odd release comes out Helps keeps a current line while having something new in the release line Node 6 is the current LTS version [27:26] What are you taking out or deprecating in Node 8? Use the word deprecate sparingly If many people use features, it’s hard to get rid of Security issue with Buffer, constructor argument was ambiguous Had added APIs that were more explicit over time and pushed those Now it will be deprecated [28:43] 21% - 33% Performance increase with some Node updates Someone online updated their React app to Node 8 and found an 21% - 33% increase Benchmarking group tests to make sure things are getting faster V8 is always getting faster as well Code changes fast and so there is a chance performance slows down so they have people to check Benchmark test are all automated by a team [30:47] Is it safe to just switch to Node 8? For front-end, yes clear your NPM cache Back use cases will usually wait until LTS [31:28] Where any of the features hard to implement? The API work took about a year It was a collaboration which made it interesting IBM, Intel, Google were involved The collaboration took a while Also Async hooks took at least a year. Async hooks used to be called async wraps and has been in the work for almost 3 years many of the changes were the accumulation of small chances [33:07] It’s the little things Letting people get small changes in accumulate into a big difference the product gets much better that way [33:57] What versions of Node are you actively updating? Current releases of Node 8 for a half of year Node 6 is LTS Additional year of maintenance of previous LTSs. Schedule is at http://github.com/node8js/lts in a chart Support for Node 4 with only critical updates, Node 6 minor updates, and Node 8 Node 7 doesn’t get much support unless it’s vital security supports. If you’re running 0.10 or 0.12 stop. Those do not get security fixes anymore [35:42] Where do you see things going from here? Mostly still working out Async hooks Maybe add some web worker or worker support for Node JS ES module support Working to make promises better Working on the performance profile and internal systems [20:29] What is the adoption like of Node 8? Node team gets better at getting people to adopt quickly but about 5% - 6% will not upgrade community doubles each year at 8 million users right now Here is a graph on Twitter posted by NPM Limiting breaks and softly deprecating things makes it’s easier to upgrade [40:11] How can people contribute and get involved? NodeToDo.org shows how to make contribution Occasionally major conferences have information on how to contribute Test it out and help make it stronger [42:08] If people install Node 8 and have issues what can they do? If it’s an NPM problem check with them clear cache! install newest version with: npm install -g npm@latest Report problems to either NPM or Node If you’re not sure where the problem is, check github.com/nodejs/help Links Node8 Node’s Twitter Node’s Medium Node Evangelism Group Mikael on Twitter and GitHub Arunesh on Twitter Anna on Twitter Picks AJ Overclocked Remix Super Mario RPG Window to The Stars Amiee Blogpost RisingStack on Node 8 2 Frugal Dudes Charles Homeland House of Cards Joe Shimmer Lake Mikael Blake2b-wasm Aremesh Current Nightly News

JSJ 267 Node 8 with Mikeal Rogers, Arunesh Chandra, and Anna Henningsen On today’s episode of JavaScript Jabber we have panelists Joe Eames, AJ O’Neil, Amiee Knight and Charles Max Wood and we are talking about Node 8. To help us we have special guests Mikeal Rodgers, Arunesh Chandra, and Anna Henningsen. It’s going to be a great show. Tune in. [1:56] Is Node 8 just an update or is there more? More than just an update Two main points: Improved Prana support Native API Native APIs are helpful for Native Add-ons. For both the consumer and the developer side. Prior to update these Node Native modules ran in C++ and bound to specific to Node 8 APIs. Causes these modules to be updated or reconciled every time these modules are rereleased. Creates burden for module maintainers. Creates friction in upgrading Node versions in production departments. If you have a deployment depending on a certain Native module, some of the modules may not get updated in time when updating your Node versions. Keeping people from updating Node. Creates compatibility issues with Node users not using Node 8 Experimental support for a Native layer in Node 8 to eliminate these issues as much as possible. Important milestone for the module ecosystem. You can write extensions for Node in C++ and it decouples V8 so you can use something else on the front. Modules takes dependency on V8 API specific to a particular version. So if V8 changes your module will be extracted from that. As a side benefit, you can have another VM to take advantage of that. Major version upgrades mean updating Native modules and usually some of those modules haven’t updated to the newest version of Node and be complicated. Deep dependency wise, about 30% depends on a Native module somewhere In the future, with the Native API, you’ll be able to update Node without breaking modules. [5:51] What kind of work went into this? Most of the work was in C++ First thing that was done was, they looked at the top dependent Native modules in the ecosystem. Looked for what kind of V8 exposure they had and cataloged it Looked at how these APIs and what their purposes were Looked for a way to extract them so that they are part of Node Core Created neutral APIs, now part of the Node core. All C APIs Also has a C++ wrapper to improves usability of the API. [7:17] What’s an example of what you can do with these APIs? Native modules allows for tighter integration and better module performance Specific APIs that you can use in V8 that isn’t available through JavaScript If you have a C++ variable code and you want to expose a variable into JavaScript, that is V8 API note a Node 8 API Having it bound directly to the VM was something they wanted for a long time Google controls V8 and they bind to V8 Created a better relationship with Google starting in IOJS Also worked with Microsoft with their Node Shocker work. Same with SpiderMonkey SpiderNode is in the works [9:23] Have you guys done any testing for performance? Some. There is a performance working group. There is a need to stay on top of V8 V8 team has focused on new language features Many features have been added over the years Many didn’t come in optimized The performance profile has changed with these features If you’re using new language features, you will see a performance boost In core, still tracking down code that was specific to the old optimizer and rewriting i to work the new optimizer Turbo C compiler hasn’t landed yet, but is to come. Will have a completely different performance profile In most real world applications it will be faster Waiting on the release to take a version of V8 to make it easier to upgrade features in the future [11:28] Are the new features picked up from V8 or implemented in Node? It’s all in V8 Better longterm support Promises are made better in Node as a platform Added new method called util.promisify() Implementation comes from V8 Allows for more optimization for promises in Node core Promise support for the one-deprecated domains module. [13:02] Is there anything more than NMP 5? First off, delete your NMP cache. It’s in your home directory usually with a .npm extension [14:09] What are the new features in V8? Unlimited heap sizes, previously had a 4gb limit. No fixed limit. [14:09] Will you see things like chakra come out tuned for servers? Profiles of a server for application process are getting smaller Getting cut into containers and VMs and micro services Vms that have cold boot time and run quickly in a strained environment is looking more like what we will see in the future Yes, especially if you’re using cloud functions V8 is optimized for phones, but Chakra is even more so Looking for opportunities for VMs can be solely optimized for a device target Node take advantage of that VM VM neutrality is an interesting concept VM Vendors trying to optimize it based on workloads of a server Opens opportunities for Node Node Chakra has been proved to iOS. You can cut off jitting off which was a requirement to be able to be in the Apple App Store Node is not just for servers anymore Node doesn’t take a long time configuring it When a developer runs code on an IoT or a mobile app they don’t control the VM that is bundled, they run it on top of Node and it just works. VM neutrality gives a new vector, so you can swam a whole different VM [18:44] When running different engines like iOS vs Android, does the profile change? What it comes down to is if it’s eventive programming The browser is an eventive environment, is very efficient waiting for things to happen before it does something The way that we program servers and nodes are the same as well the basics are the same generally environmental differences exist but the programming model is usually the same What does impact it is memory and processor and hardware and things like that That is where tuning the VM comes into play [20:29] What is the new Async Hooks API used for? Node has been lacking for automated inspection of Async Hook No way for Node to tell you when scheduling and beginning of an Async operation. Hook helps with that it’s a way for developers to write debugging features Node tells the application that it’s working with Asynchronous way. The embedded inspector has been embedded since Node 6 Now has a JavaScript API to use it You can use things like Chrome debugger inside the running node process Old debugging protocol has been removed VM.run is still there but in the process of being deprecated [22:34] How like is the experimental Node API will change? Marked as experimental because it’s the first time in the open Hopefully out of experimental soon Soon can port API to the existing LTS Looking for more people to participate with the new API and give feedback Fix any concerns before it goes to LTS Some other experimental things are in the works like ASync Hooks and how it interacts with promises Renaming some features Another new feature - serializer and deserializer that comes with V8 experimental but will most likely stay [25:31] what is your standard for going to LTS? Major releases every 6 months Next Oct Node 9 will come out and then Node 8 will be LTS Documentation, updates, additions etc will be ready then Plan to do it for 2.5 years Every even releases come out to LTS as the odd release comes out Helps keeps a current line while having something new in the release line Node 6 is the current LTS version [27:26] What are you taking out or deprecating in Node 8? Use the word deprecate sparingly If many people use features, it’s hard to get rid of Security issue with Buffer, constructor argument was ambiguous Had added APIs that were more explicit over time and pushed those Now it will be deprecated [28:43] 21% - 33% Performance increase with some Node updates Someone online updated their React app to Node 8 and found an 21% - 33% increase Benchmarking group tests to make sure things are getting faster V8 is always getting faster as well Code changes fast and so there is a chance performance slows down so they have people to check Benchmark test are all automated by a team [30:47] Is it safe to just switch to Node 8? For front-end, yes clear your NPM cache Back use cases will usually wait until LTS [31:28] Where any of the features hard to implement? The API work took about a year It was a collaboration which made it interesting IBM, Intel, Google were involved The collaboration took a while Also Async hooks took at least a year. Async hooks used to be called async wraps and has been in the work for almost 3 years many of the changes were the accumulation of small chances [33:07] It’s the little things Letting people get small changes in accumulate into a big difference the product gets much better that way [33:57] What versions of Node are you actively updating? Current releases of Node 8 for a half of year Node 6 is LTS Additional year of maintenance of previous LTSs. Schedule is at http://github.com/node8js/lts in a chart Support for Node 4 with only critical updates, Node 6 minor updates, and Node 8 Node 7 doesn’t get much support unless it’s vital security supports. If you’re running 0.10 or 0.12 stop. Those do not get security fixes anymore [35:42] Where do you see things going from here? Mostly still working out Async hooks Maybe add some web worker or worker support for Node JS ES module support Working to make promises better Working on the performance profile and internal systems [20:29] What is the adoption like of Node 8? Node team gets better at getting people to adopt quickly but about 5% - 6% will not upgrade community doubles each year at 8 million users right now Here is a graph on Twitter posted by NPM Limiting breaks and softly deprecating things makes it’s easier to upgrade [40:11] How can people contribute and get involved? NodeToDo.org shows how to make contribution Occasionally major conferences have information on how to contribute Test it out and help make it stronger [42:08] If people install Node 8 and have issues what can they do? If it’s an NPM problem check with them clear cache! install newest version with: npm install -g npm@latest Report problems to either NPM or Node If you’re not sure where the problem is, check github.com/nodejs/help Links Node8 Node’s Twitter Node’s Medium Node Evangelism Group Mikael on Twitter and GitHub Arunesh on Twitter Anna on Twitter Picks AJ Overclocked Remix Super Mario RPG Window to The Stars Amiee Blogpost RisingStack on Node 8 2 Frugal Dudes Charles Homeland House of Cards Joe Shimmer Lake Mikael Blake2b-wasm Aremesh Current Nightly News

JSJ 267 Node 8 with Mikeal Rogers, Arunesh Chandra, and Anna Henningsen On today’s episode of JavaScript Jabber we have panelists Joe Eames, AJ O’Neil, Amiee Knight and Charles Max Wood and we are talking about Node 8. To help us we have special guests Mikeal Rodgers, Arunesh Chandra, and Anna Henningsen. It’s going to be a great show. Tune in. [1:56] Is Node 8 just an update or is there more? More than just an update Two main points: Improved Prana support Native API Native APIs are helpful for Native Add-ons. For both the consumer and the developer side. Prior to update these Node Native modules ran in C++ and bound to specific to Node 8 APIs. Causes these modules to be updated or reconciled every time these modules are rereleased. Creates burden for module maintainers. Creates friction in upgrading Node versions in production departments. If you have a deployment depending on a certain Native module, some of the modules may not get updated in time when updating your Node versions. Keeping people from updating Node. Creates compatibility issues with Node users not using Node 8 Experimental support for a Native layer in Node 8 to eliminate these issues as much as possible. Important milestone for the module ecosystem. You can write extensions for Node in C++ and it decouples V8 so you can use something else on the front. Modules takes dependency on V8 API specific to a particular version. So if V8 changes your module will be extracted from that. As a side benefit, you can have another VM to take advantage of that. Major version upgrades mean updating Native modules and usually some of those modules haven’t updated to the newest version of Node and be complicated. Deep dependency wise, about 30% depends on a Native module somewhere In the future, with the Native API, you’ll be able to update Node without breaking modules. [5:51] What kind of work went into this? Most of the work was in C++ First thing that was done was, they looked at the top dependent Native modules in the ecosystem. Looked for what kind of V8 exposure they had and cataloged it Looked at how these APIs and what their purposes were Looked for a way to extract them so that they are part of Node Core Created neutral APIs, now part of the Node core. All C APIs Also has a C++ wrapper to improves usability of the API. [7:17] What’s an example of what you can do with these APIs? Native modules allows for tighter integration and better module performance Specific APIs that you can use in V8 that isn’t available through JavaScript If you have a C++ variable code and you want to expose a variable into JavaScript, that is V8 API note a Node 8 API Having it bound directly to the VM was something they wanted for a long time Google controls V8 and they bind to V8 Created a better relationship with Google starting in IOJS Also worked with Microsoft with their Node Shocker work. Same with SpiderMonkey SpiderNode is in the works [9:23] Have you guys done any testing for performance? Some. There is a performance working group. There is a need to stay on top of V8 V8 team has focused on new language features Many features have been added over the years Many didn’t come in optimized The performance profile has changed with these features If you’re using new language features, you will see a performance boost In core, still tracking down code that was specific to the old optimizer and rewriting i to work the new optimizer Turbo C compiler hasn’t landed yet, but is to come. Will have a completely different performance profile In most real world applications it will be faster Waiting on the release to take a version of V8 to make it easier to upgrade features in the future [11:28] Are the new features picked up from V8 or implemented in Node? It’s all in V8 Better longterm support Promises are made better in Node as a platform Added new method called util.promisify() Implementation comes from V8 Allows for more optimization for promises in Node core Promise support for the one-deprecated domains module. [13:02] Is there anything more than NMP 5? First off, delete your NMP cache. It’s in your home directory usually with a .npm extension [14:09] What are the new features in V8? Unlimited heap sizes, previously had a 4gb limit. No fixed limit. [14:09] Will you see things like chakra come out tuned for servers? Profiles of a server for application process are getting smaller Getting cut into containers and VMs and micro services Vms that have cold boot time and run quickly in a strained environment is looking more like what we will see in the future Yes, especially if you’re using cloud functions V8 is optimized for phones, but Chakra is even more so Looking for opportunities for VMs can be solely optimized for a device target Node take advantage of that VM VM neutrality is an interesting concept VM Vendors trying to optimize it based on workloads of a server Opens opportunities for Node Node Chakra has been proved to iOS. You can cut off jitting off which was a requirement to be able to be in the Apple App Store Node is not just for servers anymore Node doesn’t take a long time configuring it When a developer runs code on an IoT or a mobile app they don’t control the VM that is bundled, they run it on top of Node and it just works. VM neutrality gives a new vector, so you can swam a whole different VM [18:44] When running different engines like iOS vs Android, does the profile change? What it comes down to is if it’s eventive programming The browser is an eventive environment, is very efficient waiting for things to happen before it does something The way that we program servers and nodes are the same as well the basics are the same generally environmental differences exist but the programming model is usually the same What does impact it is memory and processor and hardware and things like that That is where tuning the VM comes into play [20:29] What is the new Async Hooks API used for? Node has been lacking for automated inspection of Async Hook No way for Node to tell you when scheduling and beginning of an Async operation. Hook helps with that it’s a way for developers to write debugging features Node tells the application that it’s working with Asynchronous way. The embedded inspector has been embedded since Node 6 Now has a JavaScript API to use it You can use things like Chrome debugger inside the running node process Old debugging protocol has been removed VM.run is still there but in the process of being deprecated [22:34] How like is the experimental Node API will change? Marked as experimental because it’s the first time in the open Hopefully out of experimental soon Soon can port API to the existing LTS Looking for more people to participate with the new API and give feedback Fix any concerns before it goes to LTS Some other experimental things are in the works like ASync Hooks and how it interacts with promises Renaming some features Another new feature - serializer and deserializer that comes with V8 experimental but will most likely stay [25:31] what is your standard for going to LTS? Major releases every 6 months Next Oct Node 9 will come out and then Node 8 will be LTS Documentation, updates, additions etc will be ready then Plan to do it for 2.5 years Every even releases come out to LTS as the odd release comes out Helps keeps a current line while having something new in the release line Node 6 is the current LTS version [27:26] What are you taking out or deprecating in Node 8? Use the word deprecate sparingly If many people use features, it’s hard to get rid of Security issue with Buffer, constructor argument was ambiguous Had added APIs that were more explicit over time and pushed those Now it will be deprecated [28:43] 21% - 33% Performance increase with some Node updates Someone online updated their React app to Node 8 and found an 21% - 33% increase Benchmarking group tests to make sure things are getting faster V8 is always getting faster as well Code changes fast and so there is a chance performance slows down so they have people to check Benchmark test are all automated by a team [30:47] Is it safe to just switch to Node 8? For front-end, yes clear your NPM cache Back use cases will usually wait until LTS [31:28] Where any of the features hard to implement? The API work took about a year It was a collaboration which made it interesting IBM, Intel, Google were involved The collaboration took a while Also Async hooks took at least a year. Async hooks used to be called async wraps and has been in the work for almost 3 years many of the changes were the accumulation of small chances [33:07] It’s the little things Letting people get small changes in accumulate into a big difference the product gets much better that way [33:57] What versions of Node are you actively updating? Current releases of Node 8 for a half of year Node 6 is LTS Additional year of maintenance of previous LTSs. Schedule is at http://github.com/node8js/lts in a chart Support for Node 4 with only critical updates, Node 6 minor updates, and Node 8 Node 7 doesn’t get much support unless it’s vital security supports. If you’re running 0.10 or 0.12 stop. Those do not get security fixes anymore [35:42] Where do you see things going from here? Mostly still working out Async hooks Maybe add some web worker or worker support for Node JS ES module support Working to make promises better Working on the performance profile and internal systems [20:29] What is the adoption like of Node 8? Node team gets better at getting people to adopt quickly but about 5% - 6% will not upgrade community doubles each year at 8 million users right now Here is a graph on Twitter posted by NPM Limiting breaks and softly deprecating things makes it’s easier to upgrade [40:11] How can people contribute and get involved? NodeToDo.org shows how to make contribution Occasionally major conferences have information on how to contribute Test it out and help make it stronger [42:08] If people install Node 8 and have issues what can they do? If it’s an NPM problem check with them clear cache! install newest version with: npm install -g npm@latest Report problems to either NPM or Node If you’re not sure where the problem is, check github.com/nodejs/help Links Node8 Node’s Twitter Node’s Medium Node Evangelism Group Mikael on Twitter and GitHub Arunesh on Twitter Anna on Twitter Picks AJ Overclocked Remix Super Mario RPG Window to The Stars Amiee Blogpost RisingStack on Node 8 2 Frugal Dudes Charles Homeland House of Cards Joe Shimmer Lake Mikael Blake2b-wasm Aremesh Current Nightly News

Bart gave me another two weeks to get my homework done on Programming By Stealth and brings us a case study of how to create a JavaScript API on Github. He uses a real life example of a small, open source library he released over the weekend called barfificer.linkTookit.js. This library includes many of the bits and pieces we’ve been working on in Programming By Stealth, how to add a rel of no opener on all links with a target of _blank (the ones that open in a new tab) and adding a little icon in the url to politely tell the reader that you’ll be navigating away from the page you’re on. It’s a great lesson in the structure of how Github works and even more importantly how it automatically creates beautiful documentation from Markdown comments in the code. Tutorial shownotes are available at bartbusschots.ie/...

In this week’s installment of Programming By Stealth, Bart teaches us how to create a JavaScript API up to and including an easy way to create professional documentation in order to publish our work as a JavaScript library. In order to get there we learn how to write reusable and sharable code, how “closures” help you keep your variables out of the global scope so they don’t mess up other people’s code, we learn one Ternary Operator), and my favorite, self-executing anonymous functions. Apologies for getting the episode number wrong in the audio – I said it was #460 when it’s actually #461. You can find Bart’s tutorial we follow in this episode at bartbusschots.ie/….

Materials Available here: https://media.defcon.org/DEF%20CON%2023/DEF%20CON%2023%20presentations/DEFCON-23-Hariri-Spelman-Gorenc-Abusing-Adobe-Readers-JavaScript-APIs.pdf Abusing Adobe Reader’s JavaScript APIs Brian Gorenc Manager, HP’s Zero Day Initiative Abdul-Aziz Hariri Security Researcher, HP’s Zero Day Initiative Jasiel Spelman Security Researcher, HP’s Zero Day Initiative Adobe Reader’s JavaScript APIs offer a rich set of functionality for document authors. These APIs allow for processing forms, controlling multimedia events, and communicating with databases, all of which provide end-users the ability to create complex documents. This complexity provides a perfect avenue for attackers to take advantage of weaknesses that exist in Reader’s JavaScript APIs. In this talk, we will provide insight into both the documented and undocumented APIs available in Adobe Reader. Several code auditing techniques will be shared to aid in vulnerability discovery, along with numerous proofs-of-concept which highlight real-world examples. We’ll detail out how to chain several unique issues to obtain execution in a privileged context. Finally, we’ll describe how to construct an exploit that achieves remote code execution without the need for memory corruption. Brian Gorenc is the manager of Vulnerability Research with Hewlett-Packard Security Research (HPSR). In this role, Gorenc leads the Zero Day Initiative (ZDI) program, which is the world’s largest vendor-agnostic bug bounty program. His focus includes analyzing and performing root-cause analysis on hundreds of zero-day vulnerabilities submitted by ZDI researchers from around the world. The ZDI works to expose and remediate weaknesses in the world’s most popular software. Brian is also responsible for organizing the ever-popular Pwn2Own hacking competitions. Prior to joining HP, Gorenc worked for Lockheed Martin on the F-35 Joint Strike Fighter (JSF) program. In this role, he led the development effort on the Information Assurance (IA) products in the JSF’s mission planning environment. Twitter: @maliciousinput Abdul-Aziz Hariri is a security researcher with Hewlett-Packard Security Research (HPSR). In this role, Hariri analyzes and performs root-cause analysis on hundreds of vulnerabilities submitted to the Zero Day Initiative (ZDI) program, which is the world's largest vendor-agnostic bug bounty program. His focus includes performing root-cause analysis, fuzzing and exploit development. Prior to joining HP, Hariri worked as an independent security researcher and threat analyst for Morgan Stanley emergency response team. During his time as an independent researcher, he was profiled by Wired magazine in their 2012 article, “Portrait of a Full-Time Bug Hunter”. Twitter: @abdhariri Jasiel Spelman is a vulnerability analyst and exploit developer for the Zero Day Initiative (ZDI) program. His primary role involves performing root cause analysis on ZDI submissions to determine exploitability, followed by developing exploits for accepted cases. Prior to being part of ZDI, Jasiel was a member of the Digital Vaccine team where he wrote exploits for ZDI submissions, and helped develop the ReputationDV service from TippingPoint. Jasiel's focus started off in the networking world but then shifted to development until transitioning to security. He has a BA in Computer Science from the University of Texas at Austin. Twitter: @wanderingglitch HP’s Zero Day Initiative, Twitter: @thezdi

In this episode, Jeremy Thake and Richard DiZerega talk to Dorrene Brown on the new File Handlers in Office 365.  Weekly updates Office UI FabricCreating Office add-ins with Yeoman by Andrew Connell Channel 9 Office Dev Show Episode 8 iPad Extensibility Matter Center OData Excel Office add-in Mail add-in for Outlook using Office 365 APIs (ADAL.JS, ANGULARJS, WEBAPI, AZURE AD) by Matej Vodopivc Developers: SharePoint isn’t a Platform, SharePoint is a Service by Andrew Connell Episode 092 – Identity Convergence, App Registration Portal and AppModel v2 with Microsoft’s Stuart Kwan 8 Characteristics of an ideal SharePoint customization by Doug Ware Web add-ins: Using Office Open XML to extend the JavaScript APIs by Cindy Meister Setting properties via EWS on a Draft message is a compose Mail App by Glen Scales OWA Voting Button Compose App for Office365/Exchange 2016 by Glen Scales Using Azure Machine Learning with SharePoint by Matthias Einig Show notes File Handler add-ins now available Got questions or comments about the show? Join the O365 Dev Podcast on the Office 365 Technical Network. The podcast RSS is available iTunes or search for it on “Office 365 Developer Podcast” or add directly with the RSS http://feeds.feedburner.com/Office365DeveloperPodcast. About Dorrene Brown Dorrene is a program manager at Microsoft currently focused on Office 365 extensibility. Prior to her stint at Microsoft, she worked a variety of odd jobs spanning from art preservation to aerospace systems with a bunch of other stuff in between. You can find her speaking at various Microsoft conferences and/or yelling about the Internet @dorreneb.    About the hosts Jeremy is a technical product manager at Microsoft responsible for the Visual Studio Developer story for Office 365 development. Previously he worked at AvePoint Inc., a large ISV, as the chief architect shipping two apps to the Office Store. He has been heavily involved in the SharePoint community since 2006 and was awarded the SharePoint MVP award four years in a row before retiring the title to move to Microsoft. You can find Jeremy blogging at www.jeremythake.com and tweeting at @jthake.   Richard is a software engineer in Microsoft’s Developer Experience (DX) group, where he helps developers and software vendors maximize their use of Microsoft cloud services in Office 365 and Azure. Richard has spent a good portion of the last decade architecting Office-centric solutions, many that span Microsoft’s diverse technology portfolio. He is a passionate technology evangelist and frequent speaker are worldwide conferences, trainings and events. Richard is highly active in the Office 365 community, popular blogger at www.richdizz.com, and can be found on twitter at @richdizz. Richard is born, raised and based in Dallas, TX but works on a worldwide team based in Redmond. In his spare time, Richard is an avid builder of things (BoT), musician, and lightning fast runner.  

The WWDC 2015 keynote has come and gone, but Eddy Cue’s dance moves will forever haunt us. Jake and Ben call in from San Francisco to talk about developer-y things that got announced during the keynote and the Platforms State of the Union, while Jelly, who watched from his lounge room, fills in the gaps on some of the new APIs and kits. Starting with the keynote, the couch quickly cover the general feeling of the presentation, the highlight of which was the inclusion of two female VPs presenting things on stage. Not to mention the brief inclusion of an app that Ben wrote in one of the videos shown as part of the presentation. Moving into development stuff, Jelly breaks down the addition of Search APIs which use NSUserActivity, and content indexed from the internet, to create indexable content that appears in the home screen search. This builds on a new feature from last year, and along with “universal links”, allows for easier access to content within apps. Another new feature is App Thinning, which is actually a handful of smaller features related to shrinking the size of your app’s install footprint. It includes things like splitting up assets that are specific to devices, separating out 32 and 64 bit code, and assets that are able to be downloaded as needed. This has some interesting and potentially crazy implications, and Ben and Jake aren’t sure that they’re that keen on the idea. CloudKit is also getting a huge addition with the release of a Javascript API for building web-based apps that run on CloudKit. Ben’s not convinced that this is any better than the competitor platforms, and Jake is concerned about how serious Apple are about the web, but Jelly has taken the approach that this is perfect for newcomers, and that its architecture highlights Apple’s preference for native apps. Everyone other than Jake has been expecting native apps for Apple Watch, which are also coming along with watchOS 2. This is a very simple change with a lot of implications, where the extension is simply moved to the watch itself. This leads the couch to question whether the watch was released too early. The release also adds custom complications, which allow you to show simple, time-based information on the watch face. It comes with a new feature called “Time Travel” which allows you to see the information as it changes over time, allowing you to see weather in the future, or the stock price as it varies over the day. Jake reveals that he’s using a new MacBook at this point, and his battery is running low. This prompts Jelly to quickly move on to new Xcode features, including the new Stack View, which lets you create simple, linearly-arranged sets of views, Storyboard references, which let you create properly modular Storyboard structures. After Jake disappears, Ben and Jelly continue on to talk about the new testing features in Xcode. The first of which is UI testing, which appears to be based on UIAutomation. The second is code coverage, which Ben had feared would be too overwhelming, but appears to have been implemented in a very useful way that doesn’t appear unless you actually want it to. And finally, they cover the highlights of the upcoming Swift 2.0, including the guard keyword, the try/catch error-handling system, the availability features, and finally the announcement that Swift 2.0 will be open-source. This causes them to reconsider Objective-C’s eventual demise, which seems more obvious now than it has been in the past.

In episode 7 of the web platform podcast, ‘'Web RTC and Designing Realtime Experiences”,  we talk with Agility Feat (http://agilityfeat.com/), a design and development firm in the US, Costa Rica, Nicaragua, and Honduras. Agility Feat has been not only building out real-time apps for a while now but they are also actively contributing back to the community around it as well by speaking at events, distributing a RealTime.com newsletter, and more.   Web RTC (http://www.webrtc.org/) is “a free, open project that enables web browsers with Real-Time Communications (RTC) capabilities via simple JavaScript APIs”. It is a peer-to-peer communication tool and its been around for a while. Contrary to popular belief Web RTC is not just video & chat in the browser. It is more than just that, it has data channels, screen sharing, streaming, and much more.   Web RTC is an evolving standard for realtime app development and is gaining popularity quickly in the realtime web community. More browsers are starting to implement it and Agility Feat has seen the capabilities & usefulness of Web RTC to assist in developing the user experience of realtime applications. In this episode Agilty Feat discusses how they approach designing for browsers that don't support it and how they use Web RTC effectively in their applications.   Christian Smith (@anvilhacks) and Erik Isaksen (@eisaksen) host this episode with guests Allan Naranjo (@OrangeSoftware), Mariana Lopez (@nanalq), & Arin Sime (@ArinSime) The AgilityFeat team talks with us about the user experience considerations in building realtime applications and the technologies involved.   Allan Naranjo (@OrangeSoftware) is a core member of the development team at AgiltyFeat. He is a leader in creating detailed mobile experiences with heavy client side frameworks. Allan was the winner of  ‘The  Access Innovation Prize' in 2012 for one of his Facebook Applications.   Mariana Lopez (@nanalq) is the UX lead at AgilityFeat. She designs real-time applications for clients across a variety of industries.  Mariana studied Human Computer Interaction at Carnegie Mellon University, and is also a professor of Interaction Design at the Universidad Veritas (Costa Rica) and Universidad de Costa Rica.   Arin Sime (@ArinSime) is co-founder of AgilityFeat. Arin has over 16 years of experience as a developer, entrepreneur, consultant, and trainer for everything from small startups to Fortune 100′s and federal agencies.   Resources http://www.realtimeweekly.com http://agilityfeat.com/blog http://iswebrtcreadyyet.com http://techcrunch.com/2014/06/27/google-hangouts-will-no-longer-require-a-plugin-for-chrome-users/ http://www.agilityfeat.com/blog/2014/05/real-time-ux-design-video/ http://www.nojitter.com/post/240168527/webrtc--the-good-and-the-bad https://plus.google.com/u/0/communities/106044262972906929746/stream/8faf729a-47a6-48d5-810f-e3f261ff585a https://www.accessnow.org/blog/2012/12/11/first-annual-access-innovation-awards-prize-winners-announced http://bloggeek.me/amazon-fire-phone-webrtc/ http://www.realtimeweb.co/ http://youtu.be/vvg_uFEu9Kk http://webrtchacks.com/ http://learnfromlisa.com/learn-webrtc/ http://www.html5rocks.com/en/tutorials/webrtc/basics/ http://www.html5rocks.com/en/tutorials/webrtc/infrastructure/ http://www.html5rocks.com/en/tutorials/webrtc/datachannels/ https://developer.mozilla.org/en-US/docs/Web/Guide/API/WebRTC/Peer-to-peer_communications_with_WebRTC https://github.com/html5rocks/www.html5rocks.com/tree/master/content/tutorials/webrtc

iWatch follow-up. Alex Eckermann on Bluetooth Low Energy and iWatch. Eric Welander's thoughts on Siri for iWatch. iWatch as a means of identity. How regular people use iOS devices, as witnessed by John. Multitasking-switcher implications in iOS 7. iCloud's priority within Apple. Dropbox Datastore API, including its JavaScript API. Does the Datastore API obviate the need for a web service? Nerd-targeted products. Sponsored by: Transporter: Private cloud storage. Use coupon code atp for 10% off. Audible: The leading provider of downloadable audiobooks.

In this session we will discuss key aspects of using non-JVM languages in the Hadoop environment with Microsoft HDInsight. First, we will show how we can reach to a much broader set of developers by enabling JavaScript support on Hadoop. The JavaScript API lets developers define Hadoop jobs in a style that is much more natural; even to those who are unfamiliar to the Hadoop environment. The second aspect is how we can bring Hadoop to .NET developers using C# and F# while taking advantage of language features like LINQ. The final aspect is showing how we have enabled developer tooling directly in the common environments developers are using, including a lightweight Web interface that leverages HTML5 for quick data analysis, and tooling inside the Visual Studio IDE to interact with a Hadoop installation.

HTML5 Canvas opens up a whole new world of opportunity of what a website can be. Rob Hawkes joins Jen Simmons to explain what's possible using the Canvas element and it's JavaScript API.

With three different audio and video codec formats each supported by the diverse HTML5 capable Web browsers, plus the need to deal with fallback for older browsers, HTML5 media is not the simple solution we have all been hoping for. But on the other hand, HTML5 media will make your life easier, since it offers some features that are hard to get with traditional Adobe Flash, such as a standardised JavaScript API, integrated CSS support, and built-in support for accessibility and internationalisation through captioning, subtitling, and audio descriptions. Additionally, devices such as the iPhone and iPad will only support HTML5 media and not Flash. So for any serious practitioner it's a technology you can no longer ignore. W3C invited expert Silvia Pfeiffer will talk through the big issues on this important topic. Dr Silvia Pfeiffer has worked on novel media technology for more than 15 years and is an internationally renowned expert in new Web video standards. Silvia completed her PhD in Mannheim, Germany, on audio-​​visual content analysis. She then spent 7 years at the CSIRO devel­oping new video technology for the Web in the "Annodex" project. In 2007, she co-​​founded Australian video company Vquence which offers consulting and technology services for Web 2.0 video. Silvia is now an invited expert on four W3C video-​​related working groups. She is making contributions to the new audio and video elements in HTML5, to media anno­tation standards, to media fragment addressing via URIs, and to video accessibility technology for hearing and seeing-​​impaired people (captions, audio annotations etc). Licensed as Creative Commons Attribution-Share Alike 3.0 (http://creativecommons.org/licenses/by-sa/3.0/).

HTML5 is all the rage with the cool kids, and although there’s a lot of focus on the new language, there’s plenty for web app developers with new JavaScript APIs both in the HTML5 spec and separated out as their own W3C specifications. This session will take you through demos and code and show off some of the outright crazy bleeding edge demos that are being produced today using the new JavaScript APIs. But it’s not all pie in the sky - plenty is useful today, some even in Internet Explorer! Specifically we’ll be looking at scripting the video media element, 2D canvas and some of the mashups we can achieve. How to take our web apps completely offline, going beyond the cookie and HTML5’s answer to threading: web workers. Remy Sharp is a developer, speaker, blogger, author of upcoming jQuery for Designers (Manning) and co-author of Introduction to HTML5 (New Riders). He also organises the Full Frontal JavaScript Conference and is one of the curators of HTML5 Doctor. jQuery team member (developer relations, formally evangelism) and the developer on a fistful of JavaScript related apps, Remy loves his JavaScript and he is keen as mustard to share it with other developers. Follow Remy on Twitter: @rem Licensed as Creative Commons Attribution-Share Alike 3.0 (http://creativecommons.org/licenses/by-sa/3.0/).

Discuss this episode in the Muse community Follow @MuseAppHQ on Twitter Show notes 00:00:00 - Speaker 1: What I think happened was that you got people who knew how to bend and to mold computers and software in the same place as people who were very efficient and effective and curious and playful around things like design and getting things done, and had real needs, right? And sort of that’s some biases there, I think is what drove Mac OS to become such a successful platform. 00:00:29 - Speaker 2: Hello and welcome to Meta Muse. Use as a tool for thought on iPad. This podcast isn’t about Muse product, it’s about Muse’s company and the small team behind it. I’m Adam Wiggins here with Mark McGranaghan. Hey, Adam. And joined today by Rasmus Anderson. 00:00:45 - Speaker 1: Hello, hello. 00:00:48 - Speaker 2: And Rasmus, I understand you’re an amateur gardener. 00:00:51 - Speaker 1: Yeah, that wouldn’t be very far from a lie. I do have a little front yard, tiny tiny one, and a tiny backyard, and it is a constant fight with nature, but, you know, it’s kind of fun. 00:01:07 - Speaker 2: And I always find it funny, weeds are not particularly a thing that there’s no like clear definition other than just a plant that you don’t want to be growing there. So one man’s weed is another person’s desired plant, is that about right? 00:01:22 - Speaker 1: I think that’s right, yeah. I mean, I grew up in Sweden and I remember my parents playing this like really smart game on me and my brother, where we would have these, they’re called mscruso, which are kind of pretty, but they’re definitely weed. There’s these beautiful kind of yellow flowers, and they can break through asphalt. They’re like really strong growers. You know, and as a kid, you know, parents would be like, hey, let’s do like an adventure thing, and like you find all these in the yard, and like for each of them, we line them up and count them and we would just like, Wow, this is cool. And we would go and pick them and light them up. And our parents would be like, you know, behind the corner, that would be like, we totally fooled them. So yeah, they' weeding as a kid without really knowing that I was doing that. 00:02:07 - Speaker 2: Nice one. We lived on a farm just for a little while, while my dad was stationed at a naval station that was kind of in the boonies, you might say, and my mom was a pretty serious gardener growing her own vegetables and fruits, and we had fruit trees and stuff like that. But I certainly remember that some things, the tomato plants grew fast and easy. There was the watermelon plants that we got one summer with me and my brother just ate watermelon and spit the seeds into a nearby garden bed, and then there were some others that were endless frustration for my mom trying to coax out of the ground. So yeah, I think my strategy if I’m ever in the position of being a yard owner, will be to just identify all of the hardiest plants that grow, even if you don’t want them to, and just say these are what I’m specifically cultivating. 00:02:51 - Speaker 1: I like this strategy. This someone once said this. I’m sure that there are like children books and stuff written around this. I’m not sure, but someone said this and I thought it was kind of interesting that there’s a gardening approach to like steering a system, right? And there’s sort of like more of the plan and design approach to steering a system, meaning that if you have this sort of like organic type of system, like a garden, right? Or maybe software. It’s going to just keep changing, and the gardener’s approach is that by doing something like Adam, what you were saying, you kind of identify the things that you want to cultivate, and you give them a better opportunities. And then you look at things like weed or things that you want to move, and you sort of like give them worse opportunities, right? You sort of steer the system like that and see where it goes, whereas the I don’t know if there’s a better word for it, but the planning and the signing of the system from scratch, you’re like constantly trying to hope that it evolves in the direction you want to, which is, I think, never really the case, right? 00:03:52 - Speaker 2: Yeah, I think that is I use gardening as a metaphor often for those kinds of organic growth things for something like a community where you just can’t directly direct what’s going to happen, what you can do is encourage and nurture and create opportunities, as you said, for the kinds of things you want to see and and discourage the kinds of things you don’t want to see. But that’s part of the joy maybe is you don’t know exactly how it’s going to turn out. If you come at it from a kind of a builder, engineer, architect perspective that I’m gonna plan down to every last little detail in the blueprint, and then I’ll make reality match that exactly, you’re likely to be frustrated and disappointed. 00:04:33 - Speaker 1: Yeah, that’s right. I think this somehow we just kind of slipped into this, and that’s interesting in itself, but this is kind of what I’m trying to do with my project Playbit. See, we can get into it a little bit more in detail in a few minutes, but I think that there’s this opportunity to encourage, sort of like a different way of building software, not like radically different, but sort of like somewhere in between big scale and tiny tiny scale software, kind of like personal software. But anyhow, I think that a cultural change, right? Sort of like creating this garden where interesting like plants and stuff can grow to kind of spin off this metaphor. It’s a really interesting idea, and that’s sort of like the core of playbit. That is the idea around it. That’s what I’m trying to do with it, rather than to build on a specific type of technology. Now, software is like part of, you know, my strategy to make the change happen, or at least I hope I can. But the goal of play but this is sort of like cultural change or really like offering and, you know, a different or a slightly different at least culture to software building. 00:05:39 - Speaker 2: Culture is so important, certainly for programming communities, but more broadly just creation of any end artifact comes not just from the tools and the materials and the intentions of the creators, but also this ineffable thing we call culture. Yeah, well, I’m really excited to hear more about Playbit, which is a brand new project you’re working on, just for the listener’s sake. It would be great to briefly touch on your background. You’ve got a very impressive resume fresh off of working at FIMA. Before that you did Dropbox. You were early at Spotify, and just looking down that list, you know, I find myself thinking, well, if you were an investor, that would be pretty impressive, and I would assume you’re just sort of leaving the things out that were misses. But as someone that goes to work for companies, you don’t have the ability to do such a portfolio strategy. I’m wondering if you feel like you have a particular knack for spotting high potential companies early on, or is it more a spot of luck or some combination? 00:06:35 - Speaker 1: That’s a good question. I think it’s probably the latter. It’s a little bit of a combination. Really, it’s this kind of idea of intuition, right? You have a lot of experience. I do have quite a lot of experience at this point, and I think that has put up these neurons in such a way that I have some sense at least, at least within this particular kind of industry that I’m in. Someone was asking me this the other day actually, this little Twitter like texting back and forth, but I think that there’s a couple of things you can do that don’t require experience to build up intuition. And one thing is just to like really understand what you like to do, right? And so this is not specifically around, you know, successful technology companies, but I think it’s like a foundational sort of like a cornerstone. To being successful with like, really anything, is to understand like what you really want, right? Not what your parents told you that you should want, or not what like your peers tell you that you should want, but what you really want. No, no, that’s really hard, and maybe that’s the hardest thing in life actually to know what you really want. 00:07:37 - Speaker 2: I’ll echo that as well, which is for me, I had this experience of growing up with video games and that being my passion, and I was just convinced I would go into the game industry, and that was my path, and I actually did that and then I was miserable and I didn’t like it and I what on paper you might say, or hypothetically, I thought I wanted to do in practice didn’t actually work for me. And then when I had an opportunity to join a company. Making basically from my perspective, pretty boring business software. I jumped into that and discovered I loved it and I was much better at a thing that I loved to do or fit with my natural passion somehow. So I think it’s also a maybe coming back to our gardening metaphor, a bit of a discovery and looking for opportunities and noticing what’s growing, what’s sprouting really naturally, and then encouraging. that rather than having some preconceived notion of what you think you should do, which might come from parents, certainly could come from, you know, the tech industry, which lionizes certain kinds of companies or certain kinds of people and instead kind of paying attention to your own internal compass for this is a thing that I could really see myself spending every minute thinking about for the next 5 years, 10 years, or career. 00:08:47 - Speaker 1: That’s just so interesting to hear you say that, but you had that experience, which I think a lot of us have, right? If we had this idea, maybe we want to be a chef or an astronaut, or, you know, a fire person or whatever when we’re kids, right? And like most of us end up not doing that, right? We end up doing something else. And I think that happens a few times in life where, like you, you know, We see this thing, it’s like very exciting, we pursue it, and then we stumble upon something else, and that just, you know, we stumble upon probably 100 different things, right? But one of those things where like, whoa, damn, this is really fun, and this is really interesting. Yeah, so getting back to your question a few minutes ago, I think that if you have that sort of like cornerstone idea of the learning about myself, it’s just something that I should always work on. Then on top of that, I think what you can do is To try to learn about the people that are working at various different companies or like looking for passion in people, like finding out what incentives are driving them to make a change. And with a change, I mean like a technology startup, right, usually exists for one of two reasons, and the first reason is that people want to make a change or want to see a change in the world, right? It can be a very small scale, a very big scale. And the second thing, I think that often you have these ulterior motives, you have power, fortune, you know, impressing other people, like all those things. There’s nothing bad about those things, right? But they are usually then hidden away that there’s this facade of like, no, we’re really trying to make a machine here with this YouTube for cats or whatever. And really like someone just wanted to like build a really cool thing so they can sell it and get rich, right? And again, there’s no judgment here if that’s your thing, that’s cool, but that’s not what I’m interested in. So that’s one of the things that I tried to see and figure out and really spend time on understanding when speaking with a company or a few people who want to make a change, right? Like, are they driven by passion for this change? Like, can they see this world and like, you know, in 3 years, if we have this thing, and people are using it, like, this is how their lives are different. This is how they can like do things that they can’t do before. Like that’s the sort of thing. To me it’s like, kind of rare. It might be surprisingly rare, actually, which is kind of weird. And to find that out, I think the easiest way is just to spend a little bit of time with a lot of different people. So if you’re interviewing for a company, ask if you can spend a few hours with 1 or 2 people on the team, rather than, can I spend half an hour with like 10 different people. 00:11:20 - Speaker 2: Interesting. So it sounds like you’re, you know, come back to that investor kind of analogy I made before where going to work for a company, you’re investing your time rather than your money, which in many ways is even a more scarce and valuable resource. You think of it as less in terms of let me a value. I don’t know, the market opportunity here, whether I think this has the potential to be something good or big or what have you, and instead more is kind of looking into the souls of the people who are working on it to understand their motivation and their drive and their passion. 00:11:52 - Speaker 1: For sure, yeah. This is probably a cliche at this point, but If you have a group of good people that you’re working on, it’s not that important what you’re working on. Right, I think that’s a very extreme way of looking at it. I think in reality it’s not as clear cut as that. It’s not as true as that. But I do think that it does hold true to some extent, right, that if you flip it around, right, if you do some sort of kind of Greek philosophy approach then, you know, you say sort of like, what if everything is good, right? So you start out in like ideal scenario. So it’s every person is amazing on the team. The business is doing great. The mission is something that is so close to my heart, like, I’m just thinking about it day and night, right? And so on. And now you start like taking things away, right? You have this kind of little thing in front of you, and now you start thinking that, OK, let’s see if I take away the mission, right? And I have all the other things still, like, does this feel like something I want to do for 4 years, right? Not in day, right? It’s like, oh maybe, you know, you start taking things away, and I think If you start out in the ideal case, right, you play these different stories out, and you take away the group of people, right? So you replace that with like, people who you would consider, like, not being good, right? Like, maybe they had a bad influence on you, maybe they create a lot of stress for you, maybe they’re just not good at the craft and so on, whatever that means to you. I think for most people, like, it stops pretty early in terms of like, yeah, I would still do this. Like you would be like, well, you know. With making such a big change, and I’m really involved emotionally in this mission and everything, but like the people I work with are paying, it’s like, I don’t wanna do that, right? Life is so tiny, it’s so short, and you look back in the past and the things you remember, it’s not the bugs you squashed in code or like the pixels you made. It’s gonna be the people and like. The change that the company is trying to make and the group of people are trying to make, I think it is very important, right? And this is where it really loops back the first thing that I was talking about a few minutes ago about like learning about yourself and knowing yourself. I have a few friends who are very concerned about the environment of Earth and stuff like that, and choose to leave their traditional tech jobs to go work for, you know, uh renewable energy companies and stuff like that. And for them, you know, the mission is very important, right? And the people are very important. So, I think you want to really like look at all of these different things, like, a group of people who are amazing, who are very unsuccessful at doing what they do, is not gonna be a fun experience anyways, right? So yeah, I don’t think there’s a magic bullet, there’s no sort of golden arrow or whatever metaphor here, but I think one really good thing to look for is this sort of like passionate people, and what drives them to make that change. 00:14:39 - Speaker 2: Yeah, I’m a fan of that. Seeking opportunities in my own career and when I’m in the position of giving career advice to others, I usually say something like optimize for the people, find the team that you have that collaboration magic with, and that will be just far greater return than the exact perfect mission. Um, I do think, you know, those things related, probably because if you share values and you share passions around a particular mission, that’s likely to be a team that you work really well with. But yeah, given the choice between a thing that’s slightly off from what I might actually be my ideal, the perfect team, and the other way around, I always go for the team. 00:15:16 - Speaker 1: I’m curious here, Adam and Mark, how you’re looking at this as well. You’re both experienced in the software industry, yes I am, like, kind of flipping the question back to you. What are some of the things you might do or look for in order to understand if this, you know, company group of people are gonna be successful. It’s just gonna be like a fun ride for me, so to speak. 00:15:38 - Speaker 2: Yeah, I’d love to hear from Mark on that since he’s actually, now that I think of it, picked some pretty good ones, including for Muse, he was at Stripe. And so, yeah, I guess I never asked, did you see that as, oh, these guys are gonna be huge, I really want to be on board early. My stock will be worth a lot, or was it more, this is an interesting domain, and I want to work with these people who knows the company will be successful, or that wasn’t part of your calculation. 00:16:00 - Speaker 3: Yeah, it’s tough for me to give an answer to that, because to my mind, there’s a lot of, you know, it, when you see it, and to your point about having experience and neurons and pattern matching. I feel like I’ve been lucky enough to work in the industry for a while, so I now I’m able to have perhaps some judgment of that. I do think as a tactical matter, if people actually want to have a better chance of working at a high potential company in the classic sense, you can get a lot of information by asking people whose job it is to know these things. So, Investors and hiring managers will often have a lot of data about companies that will do well. And then it kind of becomes like investors will always say, oh, it’s, it’s actually not hard to pick the company, it’s hard to get the deals. I think there’s a similar dynamic with joining companies where often a big part of it is actually getting hired. But yeah, I think it’s a tactical matter, if you do ask around, you can get a lot of good data points. But I also have similar sentiment in terms of, at a more personal level, what I look for in a company, and I would also say it’s about the people and the mission. And I always go back to this idea of You know, we don’t have a whole lot of mortal life, and it would be a shame to spend the next 2 to 4 years of it working with people you didn’t care for. And when you say it like that, oh wow, you know, really should, uh, make sure that the people that you trust and look up to and want to become more alike, because as you spend 124 years with this team, you are going to basically become more like them. So is that something that you would be proud and excited to do, or that you would be afraid and ashamed of? 00:17:18 - Speaker 2: There’s a great patio. I think it’s even in an article writing about the culture at Stripe. He says, when you’re choosing your colleagues, these are people you’re essentially giving right access in your consciousness to. We don’t realize it, but just the people you’re around all the time, you become like them, whether you like it or not. So surround yourself with people you admire and you want to become more like, and that will come true. 00:17:42 - Speaker 1: Absolutely, I really like that. 00:17:44 - Speaker 3: This also might connect a little bit to our topic of playful software, because to my mind, one aspect of playfulness is sort of undertaking the process and the work for its own sake, without a lot of accountability to the end result and just kind of enjoying the process, you know, doing it for the memes, if you will. And I feel like you can only do that well if you actually really love what you’re working on and the discipline, but I’m curious to hear Rasmus, what your perspective on playful software is. 00:18:11 - Speaker 1: Well, I think for most people playful software, the first that comes to mind is probably games, right? And games, they’re sort of like almost the purest type of playful software. That is their primary and often only goal, right? To just be playful, to just entertain. And so I think playful software that is not games have some amount of that sort of like entertainment that, you know, a privy guest of yours that Jason was saying sort of like fidget ability, you know, the idea that There’s some quality to the software that makes you want to just like, kind of toy around and play around with the software itself, not to produce something necessarily, although that might be the main reason for the software to exist. So I think if we’re looking for a definition of playful software, it’s probably something in the realms of game like entertainment like qualities that are kind of intertwined with some sort of utility. 00:19:09 - Speaker 3: Yeah, this is really interesting, this nexus of entertainment versus playfulness versus utility. So I feel like actually there’s some relations certainly between entertainment and playfulness, but I feel like they’re also somewhat separable. Like you can have a game where it’s sort of a mindless game where you just plan to get really good at it, like a competitive game. And the flip side, you can have playfulness that is more just about exploring and seeing what you can do and what you can make and perhaps the stuff in the middle, like Minecraft is kind of in the middle there, it’s both entertaining and it’s playful, and I do think people tend to go towards games, but I think there’s another important element around what we’re calling playfulness that’s really important. 00:19:42 - Speaker 1: Yeah, that’s good points. 00:19:44 - Speaker 2: I’m suddenly reminded of a book by one of my favorite authors, Virginia Postrell. And in there is a chapter where it asks the question of what actually is the difference between work and play. And it’s one of those things where you go, oh well, it’s obvious, and then when you try to come up with a definition like, well, you get paid to work and you don’t get paid to play, and really quickly, especially if you’re someone that’s, you know, in the tech industry, a designer, a developer, whatever, you find yourself doing things that look very, very similar, maybe in your free time that you do at your work, but it’s hard to pin down really what the difference is and She ends up defining it exactly as you said there, Mark, which is play is something that’s open ended, you don’t have a specific goal in mind, you can start out with, I’m gonna paint the painting of the sunset, and by the time you get to the end, you’ve decided instead to fold the canvas into an origami. Swan and, you know, you could do that if you want, whereas work you have this specific end goal that you need to get to, often in a particular time frame, and even if you find some interesting detour along the way, you kind of have to ignore that because you have made this commitment to deliver some specific result. 00:20:54 - Speaker 1: And I’d say that as a designer, like playing is often a very important part of the understanding part of design, which I think is like a really big chunk of design work, right? You know, you have this opportunity or this kind of problem, like there’s something you’re pursuing, right, with your design project and Before you can make any decisions and any changes, right, in terms of like getting closer to solving it or changing it, you have to understand it, right? And so you take things apart, you put them back together, right? You’ll learn about things as you take things apart, you’ll find new parts so you didn’t see before, right? You’ll find new constraints of the project, you’re like, oh shoot, oh I guess this material is different, right? And so, I think, as you were saying, Adam, if you take a step back and you think about like, well, this kind of looks like play, doesn’t it? And I think in many ways it is straight up play. But it is sort of a semi open ended, closed ended play, right? It’s sort of like play for the purpose of learning. And I think this is where most of us in the tech industry, like, Can relate to playfulness in like the way we use software. So maybe on a weekend you’re like, oh, I’ve heard about this new like rust thing. Maybe I should like take the first bit, right? And you put together a whole world thing and you find a rust compiler and you write some code and you’re like, oh, what is, why can’t I borrow this thing, right, whatever. And the goal here, right, is play. You might not call it play, but unless your goal is to actually like get an output in the end or make a change or something like that, really what you’re doing, right, is learning. And I think that is often the reward, so to speak, the outcome. The product of play is to learn something. 00:22:35 - Speaker 3: Absolutely. I think it’s a great point. And just to reiterate, I think it’s really important to have this play access be separate from work versus entertainment. So that is, you can play in a domain that we typically think of as work, whether that’s design, engineering. Another example that I might throw in there is Elon Musk sending the roadster to space. It’s like, why are you doing that? I don’t know, it’d be fun, I guess. That’s also in a very serious domain where he is in fact learning a lot by undertaking that activity. 00:23:02 - Speaker 2: Also connects a bit to just our humanity, which is, of course, we’re trying to achieve things, be productive in the broad sense of the word, in our pursuits in our work life, but at the same time, we’re all people, we like stuff that’s fun, we like stuff that’s playful, and if you can find ways to do that, that fit in with the work and fit in with accomplishing your ends, I think it makes it more fun and engaging and enjoyable for everyone who’s involved. 00:23:31 - Speaker 1: Yeah, there’s something naturally even about play for sure. We can’t imagine our like ancestors running around naked in the woods with clubs, you know, kind of finding a pine cone or something on the ground or a stick and be like, oh, this kind of looks like a goat, you know, and you start playing with those things, and there’s something I think is very interesting, like when I was a kid, so I grew up in the countryside and Me and, you know, the other like 5 neighbors or whatever, and the kids, we would, you know, go into the woods and that’s how we would play, we, you know, build a little like imaginary little airplanes out of a pine cone and stick through it and stuff like that, right? And as a kid, you see a stick, and the stick is like anything. It can be anything you want, it can be an airplane, it can be a rocket, right? It can be a person, right? And as an adult we lose that, and I don’t know why, but I see a stick today and I’m like, oh, that’s a stick, right? And I’m like, damn it. You know, I wanna see the stick and I wanna feel like, whoa, this could be a weird sort of creature, you know, from a different planet that has like multiple heads, that kind of looks like a stick, but it’s not a stick. At some point I listened to someone who was trying to make a point of the educational system, at least in sort of like most of the world. Takes in one end of a machine, right? Imagine people walking in one end of the machine and they come out in the other end and like, in the end you walk in, there’s all these color and difference and, you know, different voices and stuff. And the other end is like this marching uniformed people, right? School kind of prints this pattern onto us, right? This is real, that is not real. This is play, that is not play, this is serious, right? And I’m not sure that’s like good for us, especially not for people in sort of the creative industry. Which I think is like a growing industry generally. 00:25:15 - Speaker 3: Yeah, I think that’s a great point. Another way to articulate this might be as we get older and as we go through institutional education, we tend to get annealed, that is kind of solidified, optimized, focused, structured, and play in addition to a way to learn, is a way to kind of foam roll your mind, you know, get some plasticity, break up some connective tissue so you can think of some new stuff. And so now that you make that point, I see that as a second key outcome. You know, you learn some stuff and you have some more flexibility in your head. 00:25:46 - Speaker 2: It also occurs to me that that means that play and imagination have a strong relationship and maybe this, as you said earlier, Erasmus, that like, when you talk about in design, play is very important. You might even say, this isn’t quite solved yet, let me play with it and try some stuff. And that’s connected to a little bit of an open-ended divergent thinking, imagination, out of the box, you know, looking at the stick and seeing the person of the rocket ship, and that actually is what could potentially lead you to the more practical breakthrough in doing your work. 00:26:17 - Speaker 1: It’s so true, so true, I think. If you think about cool stuff that people have made, right, like art or tools or anything, what have you, that you think it’s like, wow, this is brilliant, you know, this is so fun, or this is really smart, whatever. And you start digging into like the history of that in pretty much every single case, you’ll find that it’s a remix of other things, right? And so I think imagination and playfulness. is sort of like at least partially a practice of just exploring things, right? It’s maybe that’s a play part, right? You explore stuff, you see new things, right? And then here comes the imagination part, which is like, oh, out of all these different things, there’s like a new thing that can emerge, right? Like the iPod is a remix of this like brawn handheld radio, right? And then the iPhone is a remix of the iPod. You know, those things are very obviously remixes, because they’re, you know, visually very similar, but I think that there’s also conceptual remixes, and there’s like straight up like the word I’m using a remix, right, like from audio, there’s like, that is a very common practice. 00:27:24 - Speaker 3: This is also reminding me that there’s an important element of intellectual humility in play. So we said perhaps play is when you don’t have accountability for the end work product, but wait a second, we’re in creative fields, our entire purpose is to come up with novel ideas by definition. You don’t know how to get to that work product yet. If you did, you just go right there. So really it’s taking away some of your constraints and preconceptions about what it takes to create a novel work product and and exploring for a bit and saying, you know, press on the other side, it’ll be clear that what you were calling play was in fact work or fed into work, but you don’t know what that path is yet, so who are you to say what is or isn’t gonna have a good result eventually. 00:28:01 - Speaker 1: That is really interesting. So Mark, what level of constraints, or what level of sort of like boundaries do you think you need to define in order for that to not be like this totally open ended sort of quick detour of what I’m talking about is to make sure this makes sense. So like, I’ve seen this happening a couple of times in tech companies where you have a couple of interesting smart people who are playful, and the company recognizes that, and it recognizes the value and innovation and stuff, right? So they say, hey, you know, Lisa and Robin. Would you be interested in sitting in this corner just coming up with crazy shit, right? Maybe we’ll ship it. And I think in most cases that is like a failure, right? That will come up with all these incredible stuff, but there’s never any sort of traction around it. Maybe the constraints are way too vague, similarly to an art class, you know, if you ask someone to just paint anything they want, there’s just this paralysis, right, of like where they even start. So within that framework, like looping back to my question to you, Mark, what and how do you think about like setting up the right amount of constraints to be able to play around within there? 00:29:01 - Speaker 3: Yeah, that’s a great question. I I don’t think there’s an easy answer, but One strategy that I like a lot is to follow the energy. So if you’re undertaking this project, let’s say we’re going to relax the constraint about classically measured business output, but we’re gonna maintain the constraint around there needs to be some energy here, which could be, you’re able to get other people excited about it, you’re able to get customers excited about it, you’re able to create something that’s aesthetically interesting. That to me is an important Source of energy. And so we’re not gonna kind of constantly inorganically add energy to the system. We’re gonna give you a little bit of spark and some initial fuel, but then you need to build it up from there and kind of find your own path. But you’re free to not go directly to this end destination. It could be that you go through basically an art project, or a recruiting project or a publication project, and then you go from there. That helps a lot with kind of the mechanics of keeping the project going but again people are living their short moral lives and not gonna want to work on something that doesn’t have a lot of energy on it. So as you have more success, you tend to attract more people and it goes from there. 00:29:59 - Speaker 1: So energy that makes a lot of sense, kind of sense of urgency in different words, the sort of like things are happening. Do you think that Results or milestones, or even just celebrating like discrete moments of success or progress are important as well. 00:30:15 - Speaker 3: So this is a classic atomism back from the Hiroki days to make it real. We can link to the full list of atomisms. But it’s this idea of, even if it’s just a prototype or even a CLI session mockup, something that makes it real and makes it concrete for people, really helps people understand what it is and again build that energy. I also, I mentioned it briefly, but I think this idea of aesthetics is really important. There are good threads to pull when you have an idea that’s aesthetically exciting or appealing. That’s the way that I often draw energy on projects, even like programming type projects. 00:30:45 - Speaker 1: There’s this thing I’m thinking about now, which is And this varies in different parts of the world, but I think the same thing is sort of the financial thing is true. Like, you look at a particular industry, like hairdressers, right, or pizza joints, and you look at like the topography and the colors and sort of like styling they put on their storefronts. And there seems to be these sort of like pretty tight clusters of style, right? You’re like, why are all the pizza joints in this town using hobo for the typeface, right? It will be so much more interesting if like someone used copper Gothic, you know, or comic sense or any of the other sort of, you know, funky typefaces or something, you know, stern like Helvetica. And I think what’s going on is this recognition or this thing to like make it real, right? Imagine that we were starting a pizza joint, right? And we have ambition, right? We want this to be like the freaking best pizza in our town, right? So, you know, we look at other pizza places, and we have this intuition that we talked about before, right? Of what is like a real pizza place, right? We have our heroes, right? And chances are that they use hobo, right? We might not be aware of this, this might be unconscious. So we go to, you know, our local printing press who make a sign for us, and they show us, you know, a bunch of different typefaces, they have an option, and we see the hobo one and we’re like, oh, that just feels right, you know. So you go with that and you reinforce this idea at a real pizza place to use hobo for a typeface. And so I think this connects directly to what we’re talking about with a static being important and to make it real and a good atimus, which I’m gonna start saying now, by the way, so you’re all kind of wow, is that same thing, right? Let’s say you’re building like a MacOS app. And you have this idea for it. If you create a design, just a picture, that’s like a fake screenshot that looks real, I think that there is a similar quality to that pizza you want. People are gonna look at it and they’re gonna feel like, oh damn, this can be real, you know, we can make this happen. That looks like a real thing. I didn’t think of that, right? So yeah, I think aesthetics and presentation, and that mapping that to like your heroes and your ambitions, I think it’s super important for people to feel that this is possible, you know, and to drive the energy you were talking about, Mark. 00:32:58 - Speaker 3: This reminds me of another quick story here of kind of aesthetic and emotionally driven play session. A long time ago at Hiroku, we had an issue with the command line client being very slow, and I was very frustrated with it, and I wanted to have a faster client. So I undertook this playful project of just trying to make a very fast Hoku client that kind of only does Hello World, like it just lists your apps, but does it fast. And that ended up not really going anywhere, but by undertaking that project, I discovered Go, and then eventually will go by example, and now we use Go for some of our server stuff, and that’s a whole world that I never would have been introduced to if I hadn’t just kind of followed my nose up. It would be cool if even with relaxing the constraint that eventually needs to shift to production. 00:33:36 - Speaker 1: Wait, are you behind Gobi sample? Oh yeah, man, I love that. Oh, that’s funny. Oh, that’s brilliant. Yeah. Oh, that’s fantastic, yeah. 00:33:44 - Speaker 2: Yeah, we actually use this as a bit of, I think of it as the mark publishing style, which is static HTML, maybe a little bit of, I don’t know, did you even have some kind of like template or build script for the basic site, but otherwise it’s this very almost I call brutalist HTML but a very effective design in the sense that it has the side by side code and description, if I’m remembering correctly. And yeah, it’s this very kind of sleek, it loads fast because it’s a static site, it probably still works fine now with zero maintenance, and we were certainly inspired by that, both for the you can switch articles and later all the muse stuff. I’m just basically seeing the way that Mark does kind of HTML publishing of these essentially kind of a mini book on the web, was very influential for me and everything I’ve done subsequently. 00:34:35 - Speaker 1: Hm. In an interesting way, I think go by example is playful, right? It seems to be very uniform, right? And I think that uniformity creates this, rather than create, I think it removes some anxiety around navigation. A lot of the web, I think, has this problem of creating anxiety around like, The user interface because everything is different, right? It’s like you you jumping between different planets. Anyhow, I think what makes go by example playful is that I’m guessing here and I’m extrapolating mostly from my own experience with using it. Like, when you’re in the mode of using it or visiting it, you are exploring, right? Otherwise you probably wouldn’t be visiting it, or you are there for entertainment, right, which is kind of playful too, as we talked about. So I think that there’s this category of things that They look and smell like pure utilities. They’re very uniform, they might seem boring, but they really are these like enablers or pieces of a puzzle for playfulness. 00:35:29 - Speaker 3: Yeah, and I also think that’s often an origin story, so maybe we can use this as a way to learn more about your project where, you know, one lens on these projects is, you know, it’s a way to learn a programming language. That doesn’t sound very interesting. But the other lens is it’s the result of a path that someone walked down around the change they wanted to see in the world. So likewise for your project Playbi, you could describe it as someone’s building a new operating system, another one of those, right? But there’s much more to it in terms of where you’re coming from and why you’re building this and how you’re approaching it. So maybe you can tell us a little bit about Playbit. 00:35:59 - Speaker 1: Yeah, so this, like many things, there was no eureka moments, which is interesting, I think you guys have talked about that on the show previously. The slow hunch, the slow hunch, yeah, exactly. So this very much is what happened with Playbit. So for years and years, probably over 10 years, you know, I’ve been interested in operating systems and systems. This is one of these things that I’ve learned about myself that what I find really fun and exciting to work on in terms of software are things that enable a lot of people to make things with them, right? So tools, in other words, I mean, you guys are there with me. And so I started thinking about MacO 9, it’s so tight, you know, it’s so nice. Windows 2000 came around, I was like, wow, it’s so snappy. Anyhow, fast forwarding a little bit. MacOS 10, I think is just like this wonderful amazing operating system. And this very interesting point in time in 2001 or 2002 or so, when Mac was 10.1 or so is the first kind of usable version of it, started getting some traction. I think what happened was that this is probably mostly accidental, but You got these people who were really interested in kind of moldable, malleable software and like poking at things, hacking at things, and they were using BSD and Linux and stuff, right? And they had to give up a good user experience and sure people have different opinions about this, but this is my opinion. 00:37:19 - Speaker 2: I was a Linux on the desktop user for many years and Many things I really loved about it, but I do not miss fighting with getting the Wi Fi chip working or wake from sleep or editing. I spent so many hours of my life editing XOg.com trying to get the resolution to match the refresh rate of my monitor or whatever. And that’s the kind of pain you’re willing to go through for this hackable interface. And yet, my experience was the same. I landed on Mac OS eventually because it gave me so much of that Unix underpinning that’s very kind of powerful and moldable uh with also good hardware integration. 00:37:57 - Speaker 1: Yeah, I think that’s right, that Linux traditionally and still today at least the Linux kernel is most distributions, right, is configuration over convention, whereas Mark, you were talking about Go briefly and Go is sort of like the opposite of that. I’m, I’m a huge fan of Go, like the way it’s designed as a programming language too, but in particular the way it went about the design, where it’s convention over configuration, and we can talk more about that later. But I think what happened was that you have that one part, right, of people who are really interested like you had um of the moldability of software and like the ability to fully customize your computing experience. And then on the other hand, you have people who want to use a computer and be efficient as users of a computer, right? And before MacOS 10, I think you had to make a choice. You had to say, I’m gonna use Windows or Mac OS 9. I’m not gonna be able to do this like multiple hackable stuff. I can do some basic programming or whatever, or I’m gonna do that stuff, but I’m gonna live with all this pain, right? And that quiz 10 came around and it’s like, hey, you know what, you can have both, right? And so, what I think happened was that you got people who knew how to bend and to mold computers and software in the same place as people who were very efficient and effective, and curious and playful around things like design and getting things done, and had real needs, right? And sort of that’s some biases there, I think is what drove Mac OS to become such a successful platform in terms of application quality, right? You just go and look at evidence of this, right? You go and look at a lot of web apps that are trying to mimic desktop apps. In most cases you will find them using metaphors and sometimes even a statics from Macan. It’s pretty rare that you find these things that are in the absence of a native host to mimic Windows, right? Anyhow, so that happened. I think that was very interesting. It’s clear to me now that that is a slowly dying thing, right? Macco is 10:15, you can’t use the VM Nets thing unless you have a special signed certificate from Apple that you can. To get if you’re like become a partner with them, right? You actually cannot run it, even as the owner of the computer, you cannot use it, right? Sure, you can be roots, right? You can pseudo and use it, whatever, but you can’t make any apps using it. And Mac OS 11, takes that to the next step, right? And that’s fine. Anyhow. So, in the context of all of these things, I think that there is going to be a need, right, in terms of like allowing people to keep being playful and exploring. Software at this sort of like more, I own a desktop computer. I want to be able to like do crazy shit with it, even if that means breaking it, right? And so I started thinking a few years ago, I was saying to myself that I’m gonna put a bet that in the next 10 years, there’s not gonna be a Mac OS 10 more, and Apple is just gonna be about iOS. And I think that’s, I’m still believing that. And what then, right? Is there gonna be sort of a Linux based desktop thing that emerges? Is Windows kind of like, finally. Start like a skunkworks team somewhere. They’re just like, let’s throw out like 95% of all the crap and build that. I don’t know. So I was like, should I try to do something about this? It’s really hard to build a business, I think, around the idea of an operating system, especially replacing Windows MacOs, which are just so good, right? They’re just so good and asking someone to just replace that with something is a big ask. 00:41:24 - Speaker 2: Well, maybe the way I would characterize it actually is less about good or not and more just the amount of stuff that needs to go into what people would consider a modern operating system today ranging from hardware support to networking to languages and various kinds of input devices and so on and APIs and the ability to run software and browse the web. and so on is just so huge that it is not something that an individual or even a startup can easily undertake. Hence, it’s only within reach of these incumbents that have these large existing platforms and the rare case of maybe something like Google and ChromoS being able to come in and throw quite a lot of resources and quite a lot of time at the problem. 00:42:09 - Speaker 1: But I think even in the case of Chromois, you would end up in the same place, I think, right? You would have business and money driving the main incentives, right, of like, well, if we make this work for everyone and anyone, we can just make a ton of money and then You have these competing incentives, and more importantly, competing sort of like constraints on those, right? You’re gonna need sandboxing, you’re gonna need all of these safety features, right? You’re not gonna allow people to like mess around with the OS because then most people are not gonna like know what they’re doing, right? And so I think the only way to go about this is to not trying to build an operating system or computing environment that fulfills all the expectations we have. But rather to just change our expectations or offer sort of like a, imagine like a picture on the wall, right? It’s a big picture is very complicated. And you’re very familiar with this picture, and now you’re putting a smaller picture, a much simpler picture next to it on the wall. And you say, you know, you can walk around, you can look at the simple picture, still have this big picture. And I think like, offering this idea of like, what if we shift our expectations a little bit, right? Maybe we do that just in the mode of playful software. So where Playbit started out was as more of an ambitious idea of an actual operating system. And ideas of, you know, I have like a GPU and stuff like that on a remote computer and people has time shared this because GPUs, there’s a kind of, I think a very important slightly concerning environmental impact. And right now we’ve seen this with all the foundry issues, right? And, you know, TSM and stuff like that, right? Like having issues creating ships, right? Because rare earth’s limitations, and this is mostly, you know, impacted by COVID and stuff like that, to my understanding, but still, you buy like an Nvidia high-end GPU today, and it’s very possible that a year from now, you’re gonna have to replace it with a new one, right? Because that industry has moved so quickly. And how often are you gonna use all that power, right? Probably not all the time, right? You’re gonna use that in virt a little here and there. So there’s this crazy shirt on hardware, especially if you’re in the PC world, right? Macs tend to have a longer lifetime, I think. And now I’m talking about like high end kind of high-end hardware. So this is kind of where I started and I got a lot of feedback from a lot of people who I was speaking with to try to understand, you know, and try to navigate what this would mean, and if this was crazy, and I think it was kind of like, it’s probably a little too early, and I think the approach to making this kind of change needs to happen differently. And so, through a pretty slow boil and slow process of just doing a lot of iteration, what is playbit sort of like just came out of this. So the very concretely, I think that Playbit is probably more similar to a web browser or Flash, technologically speaking. And, you know, jump in here if I’m taking this too far or there’s any curiosities to it, but I think the web is successful for a couple of different reasons, right? But one of the reasons is this uniform programming environment, this uniform runtime environment. You know, if I make this little like web program, right, and I tossed it over to you, you can use pretty much any OS, any web browser, and I have a pretty good idea that C is gonna run the same way for you. And this wasn’t always true. I think in the last 10 years this is kind of solidified to be like pretty much true. And I think that’s really remarkable, right? 00:45:32 - Speaker 2: I’ll add on to that, that, yeah, not only does it fulfill the right ones run anywhere, it was a dream of a lot of platform technologies including Flash and Java and so on, but it does it in a way that is sort of instantaneous to download and run. And then, by far the most important part of it, I think, is the sandboxing. It really gets that right. I can completely trust my program to download a program from a website. A website is a program now, a very sophisticated one potentially with all the JavaScript can do. And I can trust that I can just point my browser to URL that I don’t know who’s on the other side of that, and it will download and run that because the sandboxing is essentially perfect within that tab. It can’t go out and access the rest of my computing device. As far as I know, no other computing environment has achieved that. 00:46:23 - Speaker 1: Well, I’d say the Flash did achieve that, and I think that Flash was really brilliant in many different ways. The demise of Flash, I think, has reasons that are really unrelated to its user experience or development experience is mostly, you know, kind of a monolith owned by a single corporation, right? But the model, yeah, think about Flash or think about the web, I think it’s kind of the same thing. That model is really interesting to me and I think the one. Piece of the foundation for creating a culture where you feel empowered to play around with software and to make little fun programs is some sort of safety. And I think that’s what the sandbox does. The good part of a sandbox that you’re talking about Adam is I’m never writing perfect code, right? I’m gonna do something and I’m gonna run it and maybe like delete all the things, right? If I run it on a sandbox, it’s just gonna delete all the things in the sandbox, not, you know, my passport from a Dropbox or something like that. So, I think that’s the good part of the sandbox. The bad part, of course, is like, when you want to do something interesting, like, let’s say you have a photo sensor or something connected to a USB and you want to access that, you can’t, and you’re be damn it. And that’s why you have to jump out of if you’re like a web developer, you have to just be, well, I can’t use web for, right? And then usually you’re outside of a sandbox and there’s no sandbox. And in the last couple of years, there’s been this kind of advancement with virtualization, and virtualization sometimes is Mixed up or messed up with like emulation or the idea of like a virtual machine, right? It’s a virtual machine I would think of as a super set of emulation and virtualization. So emulation, when you run a program like let’s say like a Nintendo emulator, right? You have this program that appears to have the original Nest CPU and did they have a co-processor, I can’t remember. And DSP and all these like actual hardware things, right? So the program inside that you load it up things that is running on this hardware and stuff right there. Whereas virtualization is this idea of running the program in a way so that it’s environment, not necessarily it’s hardware, but it’s environment, appears to be that of a unique computer, right? And this is kind of how AWS and Google Cloud and all these things do it, right. And this has been around for quite a long time, probably about 20 years or so as a concept, and probably in the last 15 years it’s been increasingly like common to develop software doing this. Docker is like a popular kind of virtualization environment, right? And now you have these features built into Mac OS since 10.10. You have built into in Windows 10 with Hyper-V, you have it built in in Linux with KVM. And there’s similar things for a couple of other operating systems, right? And this has happened in the last few years. And so I was thinking that why not just make that the sandbox, right? So like, instead of making the sandbox be this, you know, there’s a DOM, right? And you have a JavaScript API and you have a fetch function, you have an array type, and so on, right? That’s sort of like the uniform runtime environment then, you know, you run that in Firefox or Chrome or Safari, that’s just kind of called completely different code, right? Implemented totally different ways, right? That’s sort of like the uniformity. Like what if that’s just like Linux and then, you know. So like when you run a program, instead of running it as JavaScript or something like that, you just run it as whatever programming language you want, you know, Mark can write in Go. And Adam, you can write in Ruby, and it’s like totally fine, you can interoperate. 00:50:01 - Speaker 2: Part of the appeal there is something like Flash. You have to use a very specific programming language and APIs through for the web as well. JavaScript is not a language a lot of people love and yet because you want to be on the web, you need to write things in JavaScript and using the web APIs. And so it sounds like this virtualization method lets you use more of the standard world of desktop computing or server computing tools, uh, but with some of those same benefits of the flash or web style sandbox. 00:50:32 - Speaker 1: Exactly. So you have the ability to think about it as this portable little box, right? As a zip file or whatever kind of metaphor you want to use. This little thing that you can copy, you can send to a friend, you can put it on a server, then you can suspend, and you can resume later. That I think is a very powerful concept. Like the idea that I can open a FIMA file or a notion document or something. And I can make some changes to it, and I just close it, right? I toss it away. I evicted from my computer, right? I clean up my work desk, and a week later I go back and it’s retains most of its state, right? I can pick up where I left off. Like, why can’t I have that on a lower level, like, in my experience on the computer? Why can’t that be like below where the windows are? Why is it just taps, right? Why is it not just entire apps or in my entire desktop? What if I had like, you know, 4 buttons on the side of my screen, right? And each button was like one of my different, this is not what I’m built, by the way, but I think this would be fun to have. What if, like, yeah, each button was mapped to one kind of VM in your computer. When you push the button, it’s instantly, like a millisecond swapped your entire computer to another one, then you have 4 computers at the reach of like a thumb, right? Yeah, so I think there now is a really good time to take this idea for a spin, and this is kind of like the technical approach to Playbit, what it is as a piece of software. And again, the goal of Playbit is not to build this piece of software. The goal of Playbit is to create and encourage like the development of small scale personal software. Maybe we can get into that more a little bit later. So like, when I’m building it right now and what I’m trying to get out in the next couple of months is kind of a Macintosh application, and I’m sure I can make a Windows app and Linux up and stuff. So Macintosh application, you start it up, and what it does is that it uses the the hypervisor of Mac OS and it boots up a Playbit OS which is this kind of based on the Linux kernel. It takes like 2 seconds or so to start it, and once it’s started inside there. You have this feature of Linux called namespaces, which you can use to create these kind of little isolated processes, right? So you can run a program and the program thinks that it’s like ha ha, I’m the operating system, I have all the power, and it kind of appears as that and it doesn’t have to be bothered about it and stuff like that. And those would be the little products that you would build and you would kind of play around with. They can crash, they can write stuff to disk, they can mess with the network. None of that is like leaking out to your real computer and not even to like the playbi OS. So the manifestation of it in the first attempt to creating a piece of software that encourages this playful thing, is this very resumable, very sort of like, Kind of stop and go, pick it up, leave it off type of software that you can play around with like today, like on your computer. And the runtime environment that you have is not the web platform, but it’s the Linux OS. So if you want to write things in in JavaScript, you can do that, right? If you want to write things and see, you can do that too. If you want interoperate between these two different things, you can just like write shit to the file system, right? You can use it as a database or you can build around an actual database if you want to. 00:53:47 - Speaker 3: Yeah, one of the reasons I was intrigued by Playbit is it seems to share this aesthetic I have around kind of collapsing the stack down. So I think it’s easiest to explain this in terms of its contrast. I feel like there’s this pathology with modern software systems where we keep adding layers and layers and layers, and that’s a few things. First of all, it tends to make it slower cause you’re going through a bunch of calls. It also tends to reduce your ability to do things because in order to have access to a feature as a programmer, that feature needs to thread through all the layers. So if any layer happens to drop or corrupt a feature, you’ve lost it. This happens a lot with graphics APIs because the original middle layers were designed for bitmaps, and then we changed it out to GPUs underneath. But then the middle layers haven’t kind of fully caught up, so you get this weird like impedance mismatch that means you don’t have access to the full power of the GPU. Anyways. And there’s also this element of you don’t understand what’s going on, because you’re kind of just casting the stone into 19 layers. Of libraries and, you know, who knows what it does, and that to me really interferes with my ability to play because I don’t kind of know what’s happening. I don’t have control over my environment. And I like these platforms, these operating system ideas where you squash that way down, you kind of start from scratch again. OK, we got name spaces and we got the GPU. What can you do now? Well, it turns out it’s a lot if you have a clean slate like that. I’m curious if that aesthetic sense resonates with what you’re trying to do with Playbit. 00:55:07 - Speaker 1: Oh, absolutely. It’s so fun to hear you talk about this, Mark. Yeah, I think that this is very, very real, and it’s something that I care a lot about. I was really early on working and using like no JS and I thought that was very exciting. And I think what ended up happening with MPM I think it’s still like fantastic, you know, both a fantastic group of people and culture and all of that stuff. But by making it really easy to pile stuff on top of stuff, people are gonna do that, path of least resistance, right? That’s why you have like someone who says, oh, look at my web server, it’s just 12 lines of code, wink wink, and the wink is like this package adjacent file that says dependencies, long freaking list, and each of those have a long freaking list of dependencies. And it’s a quick deter to the sandbox thing that we were talking about, like, isn’t it kind of bonkers that like, we don’t dare installing this program on our computer and just run it because, you know, it might just go and delete our hard drive, right? But we’re totally fine. We’re just pulling in some like random ass like MPM packages, right? One of those can just go and like delete your whole hard drive or upload all of