Podcasts about JSON

2022-09-27 Weekly News - Episode 165Watch the video version on YouTube at https://youtu.be/Lhdpv7y_LPI Hosts: Gavin Pickin - Senior Developer at Ortus SolutionsBrad Wood - Senior Developer at Ortus SolutionsThanks to our Sponsor - Ortus SolutionsThe makers of ColdBox, CommandBox, ForgeBox, TestBox and all your favorite box-es out there. A few ways  to say thanks back to Ortus Solutions: Like and subscribe to our videos on YouTube.  Help ORTUS reach for the Stars - Star and Fork our ReposStar all of your Github Box Dependencies from CommandBox with https://www.forgebox.io/view/commandbox-github  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 BOXLife store: https://www.ortussolutions.com/about-us/shop Buy Ortus's Book - 102 ColdBox HMVC Quick Tips and Tricks on GumRoad (http://gum.co/coldbox-tips)  Patreon Support (IMPECCABLE)Goal 1 - We have 40 patreons providing 100% of the funding for our Modernize or Die Podcasts via our Patreon site: https://www.patreon.com/ortussolutions. Goal 2 - We are 33% of the way to fully fund the hosting of ForgeBox.io News and AnnouncementsCF Summit AMA SessionAsk Dave Ferguson and Matt Gifford anything, literally!Post your questions here: https://docs.google.com/forms/d/e/1FAIpQLScRgS7UKySpVyf8Q5SAd6_gM3xKgh-D14_TjnZnkpyzo2qYeg/viewform?usp=send_form  and select questions will be answered live on stage by the experts. Only at the Adobe ColdFusion Summit 2022.Register now: https://cfsummit.adobeevents.com/ Hacktoberfest 2023HERE'S WHAT YOU NEED TO KNOW TO PARTICIPATE AND COMPLETE HACKTOBERFEST:Register anytime between September 26 and October 31Pull requests can be made in any GITHUB or GITLAB hosted project that's participating in Hacktoberfest (look for the “hacktoberfest” topic)Project maintainers must accept your pull/merge requests for them to count toward your totalHave 4 pull/merge requests accepted between October 1 and October 31 to complete HacktoberfestThe first 40,000 participants (maintainers and contributors) who complete Hacktoberfest can elect to receive one of two prizes: a tree planted in their name, or the Hacktoberfest 2022 t-shirt.https://hacktoberfest.com/ New Releases and UpdatesLucee Announcing Lucee 5.3.10 RCThe first release Candidate for 5.3.10 is available, mostly bug fixes, there are some additional improvements relating to CFconfig.json importing which we will be publishing docs about this weekAvailable as usual via your local Lucee Admin, Commandbox and DockerJava 17 is still not supported, Java 11 recommendedhttps://dev.lucee.org/t/announcing-lucee-5-3-10-79-rc/11147Webinar / Meetups and WorkshopsThe Online ColdFusion Meetup - "Using Adobe's CFSetup tool: manage CFAdmin settings for ANY version", C ArehartThursday, September 29, 2022 at 9:00 AM - 10:00 AM PDTYou may (or may not) have heard that CF2021 added (in 2020) a new command-line tool called CFSetup--but first, did you know that it could be used with ANY CF version, not just CF2021? And perhaps you heard its main value is to export/import CF Admin settings via JSON: it can indeed do that, and while that may excite some, others may yawn if they've "seen that elsewhere". (To be clear, it can export/import either ALL settings or selected ones.)https://www.meetup.com/coldfusionmeetup/events/288734963/ Adobe Workshops & WebinarsJoin the Adobe ColdFusion Workshop to learn how you and your agency can leverage ColdFusion to create amazing web content. This one-day training will cover all facets of Adobe ColdFusion that developers need to build applications that can run across multiple cloud providers or on-premiseICYMI - WORKSHOP - WEDNESDAY, SEPTEMBER 21, 20229:00 AM CESTAdobe ColdFusion WorkshopDamien Bruyndonckxhttps://adobe-coldfusion-workshop-1day.meetus.adobeevents.com/ ICYMI - WEBINAR - THURSDAY, SEPTEMBER 22, 202210:00 AM PDTBuilding Custom Adobe Connect Pods with CF2021Mark Takatahttps://building-custom-adobe-connect-pods-cf2021.meetus.adobeevents.com/ WEBINAR - WEDNESDAY, NOVEMBER 23, 202210:00 AM PSTBuilding Native Mobile Applications with Adobe ColdFusion & Monaco.ioMark Takatahttps://building-native-mobile-apps-with-cf-monaco-io.meetus.adobeevents.com/ WEBINAR - THURSDAY, DECEMBER 22, 202210:00 AM PSTWinter Holiday Special: A preview of ColdFusion 2023Mark Takatahttps://winter-special-preview-of-cf2023.meetus.adobeevents.com/ FREE :)Full list - https://meetus.adobeevents.com/coldfusion/ CFCasts Content Updateshttps://www.cfcasts.comJust Released Every video from ITB - For ITB Ticket Holders Only - Will be released for Subscribed in December Ortus Webinars - Into the Box Recap https://cfcasts.com/series/ortus-webinars-2022/videos/into-the-box-2022-recap  2022 ForgeBox Module of the Week Series - 1 new Video https://cfcasts.com/series/2022-forgebox-modules-of-the-week 2022 VS Code Hint tip and Trick of the Week Series - 1 new Video https://cfcasts.com/series/2022-vs-code-hint-tip-and-trick-of-the-week  Coming Soon - Now that ITB is over we can get back to our Video Series More ForgeBox and VS Code Podcast snippet videos Box-ifying a 3rd Party Library from Gavin ColdBox Elixir from Eric Getting Started with ContentBox from Daniel ITB Videos will be released Dec for those who are not ITB Ticket Holders Conferences and TrainingCF Summit - OfficialAt the Mirage in Las Vegas, NVOct 3rd & 4th - CFSummit ConferenceOct 5th - Adobe Certified Professional: Adobe ColdFusion Certification Classes & Testshttps://cfsummit.adobeevents.com/ https://www.adobe.com/products/coldfusion-family/certificate.html Registrations are now open.Schedule has been announced!!!!AWSome Day Online ConferenceTHURSDAY, OCTOBER 20, 20229AM – 12PM PT | 12PM – 3PM ETWe're bringing the cloud down to EarthJoin us for a free virtual 3-hour AWS Cloud training event delivered by our skilled in-house instructors.https://aws.amazon.com/events/awsome-day/americas/ Into the Box Latam 2022Dec 7thMore information is coming very soon.Dev NexusApril 4-6th in AltantaSuper Early Bird will be on sale until October 9, 2022 (Approx 50% off)If you are planning to speak, please submit often and early. The CALL FOR PAPERS is open until November 15WORKSHOPS WILL BE ON JAVA, JAVA SECURITY, SOFTWARE DESIGN, AGILE, DEVOPS, KUBERNETES, MICROSERVICES, SPRING ETC. SIGN UP NOW, AND YOU WILL BE ABLE TO CHOOSE A WORKSHOP, LATER ON,https://devnexus.com/ Into the Box 2023 - 10th EditionMiddle of May - start planning.Final dates will be released as soon as the hotel confirms availability.CFCampNo CFCAMP 2022, we're trying again for summer 2023TLDR is that it's just too hard and there's too much uncertainty right now.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 Week9/27/22 - Tweet - Brad Wood - Ortus Solutions For anyone using CommandBox's new-ish ModCFML support, I've added a new trick to CFConfig to be able to load CFConfig JSON files into each Lucee web context on startup which makes managing multiple contexts much easier. #CFML #ColdFusion #CLIhttps://cfconfig.ortusbooks.com/using-the-cli/commandbox-server-interceptors/server-start#modcfml-support-for-lucee-contexts https://twitter.com/bdw429s/status/15748070734304256009/27/22 - Blog - Ben Nadel - Considering Control Flow And Transient Data Relationships In ColdFusionBack in the day, when I had no separation of concerns in my ColdFusion application architecture, some things were actually easier because I was always dealing with raw data. Which meant, if I had an optional or transient relationship between two entities in my database, I could query for a record and then simply check .recordCount on the CFQuery results to see if the relationship existed. Now, however, with a layered ColdFusion architecture that boasts a strong separation of concerns, that raw data is abstracted away; and, while many things have become easier, dealing with these transient relationships has become a bit harder. And, I'm still trying to figure out how to best handle this in ColdFusion.https://www.bennadel.com/blog/4328-considering-control-flow-and-transient-data-relationships-in-coldfusion.htm9/27/22 - Blog - Wil De Bruin - Quick create issuesToday one of my colleagues was working on some API project. He was creating some resources and just wanted to return the id of the value upon creation. So for example this call:https://shiftinsert.nl/quick-create-issues/  9/23/22 - Blog - Nolan Erck - My CF Summit 2022 ScheduleHotel confirmation is in hand, plane ticket has been booked, it's official…I'm going to the Adobe ColdFusion Summit in Las Vegas! Much like Into The Box earlier this month, the CF Summit is a must-attend event for anyone looking to stay up on CFML development practices. And the agenda includes enough content for non-CFML developers, that I'd also encourage Engineering Managers and other techies to attend. (Really, this is true of most tech content — a lot of it is easily applicable to different environments.) Not registered yet? https://southofshasta.com/blog/my-cf-summit-2022-schedule/ 9/23/22 - Discussion - Lucee - What do people think of cachedWithin=“instance” along the lines of cachedWithin=“request”thinking about this primarily for functions :: Lucee Documentationhttps://dev.lucee.org/t/what-do-people-think-of-cachedwithin-instance-along-the-lines-of-cachedwithin-request/11138/2 9/23/22 - Blog - Ben Nadel - Key Conflicts On INSERT Still Increment AUTO_INCREMENT Value In MySQLWhen it comes to database schema design, picking the right indexes is a critical part of how you architect your ColdFusion applications. Not only do indexes lead to greatly improved performance, they can also be used to enforce data integrity and drive idempotent workflows. Earlier this year, I looked at some of the techniques that MySQL provides for gracefully reacting to key-conflicts; but, one thing that I completely missed in that exploration was the fact that key-conflict errors still increment the table's underlying AUTO_INCREMENT value.https://www.bennadel.com/blog/4326-key-conflicts-on-insert-still-increment-auto-increment-value-in-mysql.htm 9/20/22 - Tweet - Grant Copley - Ortus Solutions - Want to learn CBWire for Free?We've got three videos up on CFCasts if you want to learn about building apps with #CBWIRE. Totally free. cfcasts.com/browse?q=cbwire #CFML #ColdFusion #Lucee #ColdBoxhttps://cfcasts.com/browse?q=cbwire CFML JobsSeveral positions available on https://www.getcfmljobs.com/Listing over 135 ColdFusion positions from 73 companies across 62 locations in 5 Countries.2 new jobs listed this weekFull-Time - Enterprise Sales Account Manager, ColdFusion (EMEA Shift) at.. - India Sep 22Full-Time - Lucee/ Coldfusion Developer – Freelance – Belgium at England.. - United Kingdom Sep 20Other Job Links Ortus Solutions https://www.ortussolutions.com/about-us/careers  Oak Ridge National Laboratory, TN: https://jobs.ornl.gov/job/Oak-Ridge-Systems-Engineer-and-Software-Developer-TN-37830/923356000/?fbclid=IwAR3te_Ttc_n69FYUFBVBYM9IJ2K8xMSspL_pL303Qv-vdqYmgVcqEtZPQX0  There is a jobs channel in the CFML slack team, and in the box team slack now too ForgeBox Module of the WeekcfScribeCFScribe is an extension of LogBox which allows for more fine tuned and sophisticated routing of errors based on a wide variety of factors including environment, presence of http headers, ColdBox variables, System and Env variables, UDFs and more. https://forgebox.io/view/cfscribe VS Code Hint Tips and Tricks of the WeekFile UtilsSteffen Leistner - 448k installs - 5 starsA convenient way of creating, duplicating, moving, renaming, deleting files and directories.Inspired by Sidebar Enhancements for Sublime.https://marketplace.visualstudio.com/items?itemName=sleistner.vscode-fileutilsThank 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/ortussolutionsDon't forget, we have 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 All Patreon supporters have their own Private Channel access BoxTeam Slack Live Stream Access to streams like “Koding with the Kiwi + Friends” https://community.ortussolutions.com/ Patreons John Wilson - Synaptrix Jordan Clark Gary Knight Mario Rodrigues Giancarlo Gomez David Belanger   Dan Card Jonathan Perret Jeffry McGee - Sunstar Media Dean Maunder Nolan Erck  Abdul Raheen Wil De Bruin Joseph Lamoree  Don Bellamy Jan Jannek  Laksma Tirtohadi  Brian Ghidinelli - Hagerty MotorsportReg Carl Von Stetten Jeremy Adams Didier Lesnicki Matthew Clemente Daniel Garcia Scott Steinbeck - Agri Tracking Systems Ben Nadel  Richard Herbet Brett DeLine Kai Koenig Charlie Arehart Jason Daiger Shawn Oden Matthew Darby Ross Phillips Edgardo Cabezas Patrick Flynn Stephany Monge Kevin Wright John Whish Peter Amiri Cavan Vannice You can see an up to date list of all sponsors on Ortus Solutions' Websitehttps://ortussolutions.com/about-us/sponsors Thanks everyone!!! ★ Support this podcast on Patreon ★

In this episode, Dave continues his chat with Danilo Poccia, Chief Evangelist, EMEA at Amazon Web Services. Amazon Web Services is focused on powering all operations with 100% renewable energy by 2025 and committed to achieving Amazon's goal of net-zero carbon by 2040. In this second part, Danilo shares specific guidance for developers around using storage and compute services, instance types, data retention, open-source libraries, and more to help maximize sustainability in their modern applications. You can listen to part one of this conversation in Episode 052. Danilo on Twitter: https://twitter.com/danilop Danilo on LinkedIn: https://www.linkedin.com/in/dpoccia/ Danilo's Website: https://www.danilop.net/ [CODE] Rust – Rayon, Data-parallelism Library: https://docs.rs/rayon/latest/rayon/ [CODE] Rust – Tokio, Async runtime for Rust: https://tokio.rs/ [GIT] Firecracker - Secure and Fast microVMs for Serverless: https://github.com/firecracker-microvm/firecracker [GIT] simdjson Library – Fast Parsing of Files in JSON: https://github.com/simdjson/simdjson [PORTAL] AWS Bottlerocket - Linux-based OS Purpose-built to Run Containers https://aws.amazon.com/bottlerocket/ [PORTAL] AWS Customer Carbon Footprint Tool: https://aws.amazon.com/aws-cost-management/aws-customer-carbon-footprint-tool/ [PORTAL] AWS Graviton Processor: https://aws.amazon.com/ec2/graviton/ [PORTAL] AWS Inferentia - High Performance ML Inference Chip: https://aws.amazon.com/machine-learning/inferentia/ [PORTAL] Sustainability at AWS and Across Amazon: https://aws.amazon.com/sustainability [PORTAL] Sustainability Resources: https://aws.amazon.com/sustainability/resources [PORTAL] Sustainability in the Cloud: https://sustainability.aboutamazon.com/environment/the-cloud [YOUTUBE] AWS re:Invent 2021 - Architecting for Sustainability: https://youtu.be/3-Zq2W1-odU [YOUTUBE] AWS re:Invent 2021 - Sustainability in AWS Global Infrastructure: https://youtu.be/Dmz45WhXENs Subscribe: Amazon Music: https://music.amazon.com/podcasts/f8bf7630-2521-4b40-be90-c46a9222c159/aws-developers-podcast Apple Podcasts: https://podcasts.apple.com/us/podcast/aws-developers-podcast/id1574162669 Google Podcasts: https://podcasts.google.com/feed/aHR0cHM6Ly9mZWVkcy5zb3VuZGNsb3VkLmNvbS91c2Vycy9zb3VuZGNsb3VkOnVzZXJzOjk5NDM2MzU0OS9zb3VuZHMucnNz Spotify: https://open.spotify.com/show/7rQjgnBvuyr18K03tnEHBI TuneIn: https://tunein.com/podcasts/Technology-Podcasts/AWS-Developers-Podcast-p1461814/ RSS Feed: https://feeds.soundcloud

2022 is going to be a busy year. Themes are super important for people who are starting their business, and for existing merchants, we know Q1 is the busiest time of year for theme updates and changes. In this article, we'll talk about what 2022 could have in store for you, including what the Online Store product team has been working on since June. Spoiler alert: there are some highly requested feature updates, and we'll introduce you to a new suite of Shopify's best free themes being released in January. First, let's recap what was released last year. New Online Store features in 2021 At Shopify Unite 2021, we announced some serious improvements to the way merchants can customize their online store without code, as well as new developer tooling for anyone building themes and apps for Shopify merchants. For merchants, we upgraded the theme architecture to support sections on every page and theme app extensions with app blocks and app embeds. Up until then, merchants were limited in how they represented their business on Shopify, with the flexibility of sections being limited to only the home page. Code edits, elaborate workarounds with blocks, or custom apps were needed to achieve a similar effect across other pages. Now, merchants can add sections to all pages, not just the home page, unlocking a range of new opportunities to personalize every aspect of a store. Previously, there was no structured, end-to-end solution for apps to easily integrate with themes. With theme app extensions, app developers can now build UI components that can be added, removed, and configured directly through the theme editor without touching a theme's code. This means uninstalls are also cleaner, with redundant code automatically removed. Lastly, the updated theme editor allows merchants to add metafields and properties without using APIs or code. That means merchants can now add custom content they need to the product page, like introducing a space for buyers to include a size chart or ingredient list. Anything that is unlikely to appear in the core store editor can now be added in via metafields. For a full recap of the new Online Store features and what they mean for developers, check out these resources: Read this blog article Catch the Shopify Unite recording Join our upcoming deep dive webinars for partners: Sections Everywhere and Metafields + Storefront Filtering. To accompany the launch of Online Store 2.0, we launched a brand new default theme that ties together all the new features. We call it Dawn. Dawn is Shopify's first source-available reference theme with OS 2.0 flexibility and a focus on speed. It's accessible, performant, and a great starting point to customize on. Installing Dawn isn't the only way to access the new Online Store features – merchants can install any theme labeled OS 2.0 in the Shopify Theme Store, or update their theme to use JSON templates. Migrating a theme to using JSON templates is likely the preferred approach for any merchant who has a lot of customizations on their theme already. Feature improvements Since the release of sections on every page, app blocks and embeds, and dynamic sources that support metafields, the Online Store team has been working through a backlog of outstanding feature improvements. Merchants will now also be able to: Add metafields on Collections, Orders and Customers. For example you can now add wishlists, shipping addresses, and favorite products associated with customers. For metafields with Orders, you can add barcodes, order IDs, serial numbers, notes, and even give an indication if an order is a gift. Create storefront filters and choice lists for metafields. For example, for a wine collection merchants might like to filter by country and region. The choice list for the country filter might include France, Italy, etc and the choice list for the region filter might include Southern Rhone or Tuscany. We got a lot of feedback on the template limit, so we're extended this limit ...

Nada nuevo bajo el sol con Joan Tolós episodio 98Exploro varias APIs gratuitas para poder crear vuestras propias aplicaciones. Uso una de ellas como ejemplo para representar gráficamente un JSON.Ah... y gatos... muchos gatosmail: info@joantolos.comSwag: http://store.joantolos.comOfficial web: http://www.joantolos.comApple podcast: https://podcasts.apple.com/es/podcast/nada-nuevo-bajo-el-sol/id1563220961Spotify: https://open.spotify.com/show/6BcHhm3wO3cvSIMZL6ssG8#json #api

Do you want to know an awesome way to learn more about test automation and, at the same time, help the environment? Looking for a super helpful way of debugging JMeter performance tests How was Uber recently hacked? Find out about these and other end-to-end full pipeline DevOps, software testing, automation testing, performance testing, and security testing in 10 minutes or less in this episode of the test guild news show for the week of Sep 18th. So grab your favorite cup of coffee or tea, and let's do this. Time News Title Rocket Link 0:27 Create a FREE Applitools Account https://rcl.ink/xroZw 0:52 launch our new Test Composer! https://testguild.me/jn7gw0 1:36 Sauce Labs is the first in the market to support #iOS16 on real devices! https://testguild.me/nceebj 2:20 How to Visualize your JSON https://testguild.me/i3wbuv 3:03 Testing for Good Web event https://testguild.me/29f8xo 3:44 LambdaTest, through this grant, looks to support open-source innovation https://testguild.me/dc7n8o 4:30 Copado launched its Quality Integration Framework https://testguild.me/0wlkgy 5:27 performance engineering toolbox https://testguild.me/aeu5w2 6:05 debugging JMeter performance & load testing https://testguild.me/08u865 6:58 Uber incident explained https://testguild.me/k2dxqs 7:34 AutoRABIT unveils security tools for Salesforce ecosystems https://testguild.me/2u09z1

About AllenAllen is a cloud architect at Tyler Technologies. He helps modernize government software by creating secure, highly scalable, and fault-tolerant serverless applications.Allen publishes content regularly about serverless concepts and design on his blog - Ready, Set Cloud!Links Referenced: Ready, Set, Cloud blog: https://readysetcloud.io Tyler Technologies: https://www.tylertech.com/ Twitter: https://twitter.com/allenheltondev Linked: https://www.linkedin.com/in/allenheltondev/ TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is sponsored in part by our friends at AWS AppConfig. Engineers love to solve, and occasionally create, problems. But not when it's an on-call fire-drill at 4 in the morning. Software problems should drive innovation and collaboration, NOT stress, and sleeplessness, and threats of violence. That's why so many developers are realizing the value of AWS AppConfig Feature Flags. Feature Flags let developers push code to production, but hide that that feature from customers so that the developers can release their feature when it's ready. This practice allows for safe, fast, and convenient software development. You can seamlessly incorporate AppConfig Feature Flags into your AWS or cloud environment and ship your Features with excitement, not trepidation and fear. To get started, go to snark.cloud/appconfig. That's snark.cloud/appconfig.Corey: I come bearing ill tidings. Developers are responsible for more than ever these days. Not just the code that they write, but also the containers and the cloud infrastructure that their apps run on. Because serverless means it's still somebody's problem. And a big part of that responsibility is app security from code to cloud. And that's where our friend Snyk comes in. Snyk is a frictionless security platform that meets developers where they are - Finding and fixing vulnerabilities right from the CLI, IDEs, Repos, and Pipelines. Snyk integrates seamlessly with AWS offerings like code pipeline, EKS, ECR, and more! As well as things you're actually likely to be using. Deploy on AWS, secure with Snyk. Learn more at Snyk.co/scream That's S-N-Y-K.co/screamCorey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Every once in a while I wind up stumbling into corners of the internet that I previously had not traveled. Somewhat recently, I wound up having that delightful experience again by discovering readysetcloud.io, which has a whole series of, I guess some people might call it thought leadership, I'm going to call it instead how I view it, which is just amazing opinion pieces on the context of serverless, mixed with APIs, mixed with some prognostications about the future.Allen Helton by day is a cloud architect at Tyler Technologies, but that's not how I encountered you. First off, Allen, thank you for joining me.Allen: Thank you, Corey. Happy to be here.Corey: I was originally pointed towards your work by folks in the AWS Community Builder program, of which we both participate from time to time, and it's one of those, “Oh, wow, this is amazing. I really wish I'd discovered some of this sooner.” And every time I look through your back catalog, and I click on a new post, I see things that are either I've really agree with this or I can't stand this opinion, I want to fight about it, but more often than not, it's one of those recurring moments that I love: “Damn, I wish I had written something like this.” So first, you're absolutely killing it on the content front.Allen: Thank you, Corey, I appreciate that. The content that I make is really about the stuff that I'm doing at work. It's stuff that I'm passionate about, stuff that I'd spend a decent amount of time on, and really the most important thing about it for me, is it's stuff that I'm learning and forming opinions on and wants to share with others.Corey: I have to say, when I saw that you were—oh, your Tyler Technologies, which sounds for all the world like, oh, it's a relatively small consultancy run by some guy presumably named Tyler, and you know, it's a petite team of maybe 20, 30 people on the outside. Yeah, then I realized, wait a minute, that's not entirely true. For example, for starters, you're publicly traded. And okay, that does change things a little bit. First off, who are you people? Secondly, what do you do? And third, why have I never heard of you folks, until now?Allen: Tyler is the largest company that focuses completely on the public sector. We have divisions and products for pretty much everything that you can imagine that's in the public sector. We have software for schools, software for tax and appraisal, we have software for police officers, for courts, everything you can think of that runs the government can and a lot of times is run on Tyler software. We've been around for decades building our expertise in the domain, and the reason you probably haven't heard about us is because you might not have ever been in trouble with the law before. If you [laugh] if you have been—Corey: No, no, I learned very early on in the course of my life—which will come as a surprise to absolutely no one who spent more than 30 seconds with me—that I have remarkably little filter and if ten kids were the ones doing something wrong, I'm the one that gets caught. So, I spent a lot of time in the principal's office, so this taught me to keep my nose clean. I'm one of those squeaky-clean types, just because I was always terrified of getting punished because I knew I would get caught. I'm not saying this is the right way to go through life necessarily, but it did have the side benefit of, no, I don't really engage with law enforcement going throughout the course of my life.Allen: That's good. That's good. But one exposure that a lot of people get to Tyler is if you look at the bottom of your next traffic ticket, it'll probably say Tyler Technologies on the bottom there.Corey: Oh, so you're really popular in certain circles, I'd imagine?Allen: Super popular. Yes, yes. And of course, you get all the benefits of writing that code that says ‘if defendant equals Allen Helton then return.'Corey: I like that. You get to have the exception cases built in that no one's ever going to wind up looking into.Allen: That's right. Yes.Corey: The idea of what you're doing makes an awful lot of sense. There's a tremendous need for a wide variety of technical assistance in the public sector. What surprises me, although I guess it probably shouldn't, is how much of your content is aimed at serverless technologies and API design, which to my way of thinking, isn't really something that public sector has done a lot with. Clearly I'm wrong.Allen: Historically, you're not wrong. There's an old saying that government tends to run about ten years behind on technology. Not just technology, but all over the board and runs about ten years behind. And until recently, that's really been true. There was a case last year, a situation last year where one of the state governments—I don't remember which one it was—but they were having a crisis because they couldn't find any COBOL developers to come in and maintain their software that runs the state.And it's COBOL; you're not going to find a whole lot of people that have that skill. A lot of those people are retiring out. And what's happening is that we're getting new people sitting in positions of power and government that want innovation. They know about the cloud and they want to be able to integrate with systems quickly and easily, have little to no onboarding time. You know, there are people in power that have grown up with technology and understand that, well, with everything else, I can be up and running in five or ten minutes. I cannot do this with the software I'm consuming now.Corey: My opinion on it is admittedly conflicted because on the one hand, yeah, I don't think that governments should be running on COBOL software that runs on mainframes that haven't been supported in 25 years. Conversely, I also don't necessarily want them being run like a seed series startup, where, “Well, I wrote this code last night, and it's awesome, so off I go to production with it.” Because I can decide not to do business anymore with Twitter for Pets, and I could go on to something else, like PetFlicks, or whatever it is I choose to use. I can't easily opt out of my government. The decisions that they make stick and that is going to have a meaningful impact on my life and everyone else's life who is subject to their jurisdiction. So, I guess I don't really know where I believe the proper, I guess, pace of technological adoption should be for governments. Curious to get your thoughts on this.Allen: Well, you certainly don't want anything that's bleeding edge. That's one of the things that we kind of draw fine lines around. Because when we're dealing with government software, we're dealing with, usually, critically sensitive information. It's not medical records, but it's your criminal record, and it's things like your social security number, it's things that you can't have leaking out under any circumstances. So, the things that we're building on are things that have proven out to be secure and have best practices around security, uptime, reliability, and in a lot of cases as well, and maintainability. You know, if there are issues, then let's try to get those turned around as quickly as we can because we don't want to have any sort of downtime from the software side versus the software vendor side.Corey: I want to pivot a little bit to some of the content you've put out because an awful lot of it seems to be, I think I'll call it variations on a theme. For example, I just read some recent titles, and to illustrate my point, “Going API First: Your First 30 Days,” “Solutions Architect Tips how to Design Applications for Growth,” “3 Things to Know Before Building A Multi-Tenant Serverless App.” And the common thread that I see running through all of these things are these are things that you tend to have extraordinarily strong and vocal opinions about only after dismissing all of them the first time and slapping something together, and then sort of being forced to live with the consequences of the choices that you've made, in some cases you didn't realize you were making at the time. Are you one of those folks that has the wisdom to see what's coming down the road, or did you do what the rest of us do and basically learn all this stuff by getting it hilariously wrong and having to careen into rebound situations as a result?Allen: [laugh]. I love that question. I would like to say now, I feel like I have the vision to see something like that coming. Historically, no, not at all. Let me talk a little bit about how I got to where I am because that will shed a lot of context on that question.A few years ago, I was put into a position at Tyler that said, “Hey, go figure out this cloud thing.” Let's figure out what we need to do to move into the cloud safely, securely, quickly, all that rigmarole. And so, I did. I got to hand-select team of engineers from people that I worked with at Tyler over the past few years, and we were basically given free rein to learn. We were an R&D team, a hundred percent R&D, for about a year's worth of time, where we were learning about cloud concepts and theory and building little proof of concepts.CI/CD, serverless, APIs, multi-tenancy, a whole bunch of different stuff. NoSQL was another one of the things that we had to learn. And after that year of R&D, we were told, “Okay, now go do something with that. Go build this application.” And we did, building on our theory our cursory theory knowledge. And we get pretty close to go live, and then the business says, “What do you do in this scenario? What do you do in that scenario? What do you do here?”Corey: “I update my resume and go work somewhere else. Where's the hard part here?”Allen: [laugh].Corey: Turns out, that's not a convincing answer.Allen: Right. So, we moved quickly. And then I wouldn't say we backpedaled, but we hardened for a long time before the—prior to the go-live, with the lessons that we've learned with the eyes of Tyler, the mature enterprise company, saying, “These are the things that you have to make sure that you take into consideration in an actual production application.” One of the things that I always pushed—I was a manager for a few years of all these cloud teams—I always push do it; do it right; do it better. Right?It's kind of like crawl, walk, run. And if you follow my writing from the beginning, just looking at the titles and reading them, kind of like what you were doing, Corey, you'll see that very much. You'll see how I talk about CI/CD, you'll see me how I talk about authorization, you'll see me how I talk about multi-tenancy. And I kind of go in waves where maybe a year passes and you see my content revisit some of the topics that I've done in the past. And they're like, “No, no, no, don't do what I said before. It's not right.”Corey: The problem when I'm writing all of these things that I do, for example, my entire newsletter publication pipeline is built on a giant morass of Lambda functions and API Gateways. It's microservices-driven—kind of—and each microservice is built, almost always, with a different framework. Lately, all the new stuff is CDK. I started off with the serverless framework. There are a few other things here and there.And it's like going architecting, back in time as I have to make updates to these things from time to time. And it's the problem with having done all that myself is that I already know the answer to, “What fool designed this?” It's, well, you're basically watching me learn what I was, doing bit by bit. I'm starting to believe that the right answer on some level, is to build an inherent shelf-life into some of these things. Great, in five years, you're going to come back and re-architect it now that you know how this stuff actually works rather than patching together 15 blog posts by different authors, not all of whom are talking about the same thing and hoping for the best.Allen: Yep. That's one of the things that I really like about serverless, I view that as a giant pro of doing Serverless is that when we revisit with the lessons learned, we don't have to refactor everything at once like if it was just a big, you know, MVC controller out there in the sky. We can refactor one Lambda function at a time if now we're using a new version of the AWS SDK, or we've learned about a new best practice that needs to go in place. It's a, “While you're in there, tidy up, please,” kind of deal.Corey: I know that the DynamoDB fanatics will absolutely murder me over this one, but one of the reasons that I have multiple Dynamo tables that contain, effectively, variations on the exact same data, is because I want to have the dependency between the two different microservices be the API, not, “Oh, and under the hood, it's expecting this exact same data structure all the time.” But it just felt like that was the wrong direction to go in. That is the justification I use for myself why I run multiple DynamoDB tables that [laugh] have the same content. Where do you fall on the idea of data store separation?Allen: I'm a big single table design person myself, I really like the idea of being able to store everything in the same table and being able to create queries that can return me multiple different types of entity with one lookup. Now, that being said, one of the issues that we ran into, or one of the ambiguous areas when we were getting started with serverless was, what does single table design mean when you're talking about microservices? We were wondering does single table mean one DynamoDB table for an entire application that's composed of 15 microservices? Or is it one table per microservice? And that was ultimately what we ended up going with is a table per microservice. Even if multiple microservices are pushed into the same AWS account, we're still building that logical construct of a microservice and one table that houses similar entities in the same domain.Corey: So, something I wish that every service team at AWS would do as a part of their design is draw the architecture of an application that you're planning to build. Great, now assume that every single resource on that architecture diagram lives in its own distinct AWS account because somewhere in some customer, there's going to be an account boundary at every interconnection point along the way. And so, many services don't do that where it's, “Oh, that thing and the other thing has to be in the same account.” So, people have to write their own integration shims, and it makes doing the right thing of putting different services into distinct bounded AWS accounts for security or compliance reasons way harder than I feel like it needs to be.Allen: [laugh]. Totally agree with you on that one. That's one of the things that I feel like I'm still learning about is the account-level isolation. I'm still kind of early on, personally, with my opinions in how we're structuring things right now, but I'm very much of a like opinion that deploying multiple things into the same account is going to make it too easy to do something that you shouldn't. And I just try not to inherently trust people, in the sense that, “Oh, this is easy. I'm just going to cross that boundary real quick.”Corey: For me, it's also come down to security risk exposure. Like my lasttweetinaws.com Twitter shitposting thread client lives in a distinct AWS account that is separate from the AWS account that has all of our client billing data that lives within it. The idea being that if you find a way to compromise my public-facing Twitter client, great, the blast radius should be constrained to, “Yay, now you can, I don't know, spin up some cryptocurrency mining in my AWS account and I get to look like a fool when I beg AWS for forgiveness.”But that should be the end of it. It shouldn't be a security incident because I should not have the credit card numbers living right next to the funny internet web thing. That sort of flies in the face of the original guidance that AWS gave at launch. And right around 2008-era, best practices were one customer, one AWS account. And then by 2012, they had changed their perspective, but once you've made a decision to build multiple services in a single account, unwinding and unpacking that becomes an incredibly burdensome thing. It's about the equivalent of doing a cloud migration, in some ways.Allen: We went through that. We started off building one application with the intent that it was going to be a siloed application, a one-off, essentially. And about a year into it, it's one of those moments of, “Oh, no. What we're building is not actually a one-off. It's a piece to a much larger puzzle.”And we had a whole bunch of—unfortunately—tightly coupled things that were in there that we're assuming that resources were going to be in the same AWS account. So, we ended up—how long—I think we took probably two months, which in the grand scheme of things isn't that long, but two months, kind of unwinding the pieces and decoupling what was possible at the time into multiple AWS accounts, kind of, segmented by domain, essentially. But that's hard. AWS puts it, you know, it's those one-way door decisions. I think this one was a two-way door, but it locked and you could kind of jimmy the lock on the way back out.Corey: And you could buzz someone from the lobby to let you back in. Yeah, the biggest problem is not necessarily the one-way door decisions. It's the one-way door decisions that you don't realize you're passing through at the time that you do them. Which, of course, brings us to a topic near and dear to your heart—and I only recently started have opinions on this myself—and that is the proper design of APIs, which I'm sure will incense absolutely no one who's listening to this. Like, my opinions on APIs start with well, probably REST is the right answer in this day and age. I had people, like, “Well, I don't know, GraphQL is pretty awesome.” Like, “Oh, I'm thinking SOAP,” and people look at me like I'm a monster from the Black Lagoon of centuries past in XML-land. So, my particular brand of strangeness side, what do you see that people are doing in the world of API design that is the, I guess, most common or easy to make mistakes that you really wish they would stop doing?Allen: If I could boil it down to one word, fundamentalism. Let me unpack that for you.Corey: Oh, please, absolutely want to get a definition on that one.Allen: [laugh]. I approach API design from a developer experience point of view: how easy is it for both internal and external integrators to consume and satisfy the business processes that they want to accomplish? And a lot of times, REST guidelines, you know, it's all about entity basis, you know, drill into the appropriate entities and name your endpoints with nouns, not verbs. I'm actually very much onto that one.But something that you could easily do, let's say you have a business process that given a fundamentally correct RESTful API design takes ten API calls to satisfy. You could, in theory, boil that down to maybe three well-designed endpoints that aren't, quote-unquote, “RESTful,” that make that developer experience significantly easier. And if you were a fundamentalist, that option is not even on the table, but thinking about it pragmatically from a developer experience point of view, that might be the better call. So, that's one of the things that, I know feels like a hot take. Every time I say it, I get a little bit of flack for it, but don't be a fundamentalist when it comes to your API designs. Do something that makes it easier while staying in the guidelines to do what you want.Corey: For me the problem that I've kept smacking into with API design, and it honestly—let me be very clear on this—my first real exposure to API design rather than API consumer—which of course, I complain about constantly, especially in the context of the AWS inconsistent APIs between services—was when I'm building something out, and I'm reading the documentation for API Gateway, and oh, this is how you wind up having this stage linked to this thing, and here's the endpoint. And okay, great, so I would just populate—build out a structure or a schema that has the positional parameters I want to use as variables in my function. And that's awesome. And then I realized, “Oh, I might want to call this a different way. Aw, crap.” And sometimes it's easy; you just add a different endpoint. Other times, I have to significantly rethink things. And I can't shake the feeling that this is an entire discipline that exists that I just haven't had a whole lot of exposure to previously.Allen: Yeah, I believe that. One of the things that you could tie a metaphor to for what I'm saying and kind of what you're saying, is AWS SAM, the Serverless Application Model, all it does is basically macros CloudFormation resources. It's just a transform from a template into CloudFormation. CDK does same thing. But what the developers of SAM have done is they've recognized these business processes that people do regularly, and they've made these incredibly easy ways to satisfy those business processes and tie them all together, right?If I want to have a Lambda function that is backed behind a endpoint, an API endpoint, I just have to add four or five lines of YAML or JSON that says, “This is the event trigger, here's the route, here's the API.” And then it goes and does four, five, six different things. Now, there's some engineers that don't like that because sometimes that feels like magic. Sometimes a little bit magic is okay.Corey: This episode is sponsored in part by our friends at Sysdig. Sysdig secures your cloud from source to run. They believe, as do I, that DevOps and security are inextricably linked. If you wanna learn more about how they view this, check out their blog, it's definitely worth the read. To learn more about how they are absolutely getting it right from where I sit, visit Sysdig.com and tell them that I sent you. That's S Y S D I G.com. And my thanks to them for their continued support of this ridiculous nonsense.Corey: I feel like one of the benefits I've had with the vast majority of APIs that I've built is that because this is all relatively small-scale stuff for what amounts to basically shitposting for the sake of entertainment, I'm really the only consumer of an awful lot of these things. So, I get frustrated when I have to backtrack and make changes and teach other microservices to talk to this thing that has now changed. And it's frustrating, but I have the capacity to do that. It's just work for a period of time. I feel like that equation completely shifts when you have published this and it is now out in the world, and it's not just users, but in many cases paying customers where you can't really make those changes without significant notice, and every time you do you're creating work for those customers, so you have to be a lot more judicious about it.Allen: Oh, yeah. There is a whole lot of governance and practice that goes into production-level APIs that people integrate with. You know, they say once you push something out the door into production that you're going to support it forever. I don't disagree with that. That seems like something that a lot of people don't understand.And that's one of the reasons why I push API-first development so hard in all the content that I write is because you need to be intentional about what you're letting out the door. You need to go in and work, not just with the developers, but your product people and your analysts to say, what does this absolutely need to do, and what does it need to do in the future? And you take those things, and you work with analysts who want specifics, you work with the engineers to actually build it out. And you're very intentional about what goes out the door that first time because once it goes out with a mistake, you're either going to version it immediately or you're going to make some people very unhappy when you make a breaking change to something that they immediately started consuming.Corey: It absolutely feels like that's one of those things that AWS gets astonishingly right. I mean, I had the privilege of interviewing, at the time, Jeff Barr and then Ariel Kelman, who was their head of marketing, to basically debunk a bunch of old myths. And one thing that they started talking about extensively was the idea that an API is fundamentally a promise to your customers. And when you make a promise, you'd better damn well intend on keeping it. It's why API deprecations from AWS are effectively unique whenever something happens.It's the, this is a singular moment in time when they turn off a service or degrade old functionality in favor of new. They can add to it, they can launch a V2 of something and then start to wean people off by calling the old one classic or whatnot, but if I built something on AWS in 2008 and I wound up sleeping until today, and go and try and do the exact same thing and deploy it now, it will almost certainly work exactly as it did back then. Sure, reliability is going to be a lot better and there's a crap ton of features and whatnot that I'm not taking advantage of, but that fundamental ability to do that is awesome. Conversely, it feels like Google Cloud likes to change around a lot of their API stories almost constantly. And it's unplanned work that frustrates the heck out of me when I'm trying to build something stable and lasting on top of it.Allen: I think it goes to show the maturity of these companies as API companies versus just vendors. It's one of the things that I think AWS does [laugh]—Corey: You see the similar dichotomy with Microsoft and Apple. Microsoft's new versions of Windows generally still have functionalities in them to support stuff that was written in the '90s for a few use cases, whereas Apple's like, “Oh, your computer's more than 18-months old? Have you tried throwing it away and buying a new one? And oh, it's a new version of Mac OS, so yeah, maybe the last one would get security updates for a year and then get with the times.” And I can't shake the feeling that the correct answer is in some way, both of those, depending upon who your customer is and what it is you're trying to achieve.If Microsoft adopted the Apple approach, their customers would mutiny, and rightfully so; the expectation has been set for decades that isn't what happens. Conversely, if Apple decided now we're going to support this version of Mac OS in perpetuity, I don't think a lot of their application developers wouldn't quite know what to make of that.Allen: Yeah. I think it also comes from a standpoint of you better make it worth their while if you're going to move their cheese. I'm not a Mac user myself, but from what I hear for Mac users—and this could be rose-colored glasses—but is that their stuff works phenomenally well. You know, when a new thing comes out—Corey: Until it doesn't, absolutely. It's—whenever I say things like that on this show, I get letters. And it's, “Oh, yeah, really? They'll come up with something that is a colossal pain in the ass on Mac.” Like, yeah, “Try building a system-wide mute key.”It's yeah, that's just a hotkey away on windows and here in Mac land. It's, “But it makes such beautiful sounds. Why would you want them to be quiet?” And it's, yeah, it becomes this back-and-forth dichotomy there. And you can even explain it to iPhones as well and the Android ecosystem where it's, oh, you're going to support the last couple of versions of iOS.Well, as a developer, I don't want to do that. And Apple's position is, “Okay, great.” Almost half of the mobile users on the planet will be upgrading because they're in the ecosystem. Do you want us to be able to sell things those people are not? And they're at a point of scale where they get to dictate those terms.On some level, there are benefits to it and others, it is intensely frustrating. I don't know what the right answer is on the level of permanence on that level of platform. I only have slightly better ideas around the position of APIs. I will say that when AWS deprecates something, they reach out individually to affected customers, on some level, and invariably, when they say, “This is going to be deprecated as of August 31,” or whenever it is, yeah, it is going to slip at least twice in almost every case, just because they're not going to turn off a service that is revenue-bearing or critical-load-bearing for customers without massive amounts of notice and outreach, and in some cases according to rumor, having engineers reach out to help restructure things so it's not as big of a burden on customers. That's a level of customer focus that I don't think most other companies are capable of matching.Allen: I think that comes with the size and the history of Amazon. And one of the things that they're doing right now, we've used Amazon Cloud Cams for years, in my house. We use them as baby monitors. And they—Corey: Yea, I saw this I did something very similar with Nest. They didn't have the Cloud Cam at the right time that I was looking at it. And they just announced that they're going to be deprecating. They're withdrawing them for sale. They're not going to support them anymore. Which, oh at Amazon—we're not offering this anymore. But you tell the story; what are they offering existing customers?Allen: Yeah, so slightly upset about it because I like my Cloud Cams and I don't want to have to take them off the wall or wherever they are to replace them with something else. But what they're doing is, you know, they gave me—or they gave all the customers about eight months head start. I think they're going to be taking them offline around Thanksgiving this year, just mid-November. And what they said is as compensation for you, we're going to send you a Blink Cam—a Blink Mini—for every Cloud Cam that you have in use, and then we are going to gift you a year subscription to the Pro for Blink.Corey: That's very reasonable for things that were bought years ago. Meanwhile, I feel like not to be unkind or uncharitable here, but I use Nest Cams. And that's a Google product. I half expected if they ever get deprecated, I'll find out because Google just turns it off in the middle of the night—Allen: [laugh].Corey: —and I wake up and have to read a blog post somewhere that they put an update on Nest Cams, the same way they killed Google Reader once upon a time. That's slightly unfair, but the fact that joke even lands does say a lot about Google's reputation in this space.Allen: For sure.Corey: One last topic I want to talk with you about before we call it a show is that at the time of this recording, you recently had a blog post titled, “What does the Future Hold for Serverless?” Summarize that for me. Where do you see this serverless movement—if you'll forgive the term—going?Allen: So, I'm going to start at the end. I'm going to work back a little bit on what needs to happen for us to get there. I have a feeling that in the future—I'm going to be vague about how far in the future this is—that we'll finally have a satisfied promise of all you're going to write in the future is business logic. And what does that mean? I think what can end up happening, given the right focus, the right companies, the right feedback, at the right time, is we can write code as developers and have that get pushed up into the cloud.And a phrase that I know Jeremy Daly likes to say ‘infrastructure from code,' where it provisions resources in the cloud for you based on your use case. I've developed an application and it gets pushed up in the cloud at the time of deploying it, optimized resource allocation. Over time, what will happen—with my future vision—is when you get production traffic going through, maybe it's spiky, maybe it's consistently at a scale that outperforms the resources that it originally provisioned. We can have monitoring tools that analyze that and pick that out, find the anomalies, find the standard patterns, and adjust that infrastructure that it deployed for you automatically, where it's based on your production traffic for what it created, optimizes it for you. Which is something that you can't do on an initial deployment right now. You can put what looks best on paper, but once you actually get traffic through your application, you realize that, you know, what was on paper might not be correct.Corey: You ever noticed that whiteboard diagrams never show the reality, and they're always aspirational, and they miss certain parts? And I used to think that this was the symptom I had from working at small, scrappy companies because you know what, those big tech companies, everything they build is amazing and awesome. I know it because I've seen their conference talks. But I've been a consultant long enough now, and for a number of those companies, to realize that nope, everyone's infrastructure is basically a trash fire at any given point in time. And it works almost in spite of itself, rather than because of it.There is no golden path where everything is shiny, new and beautiful. And that, honestly, I got to say, it was really [laugh] depressing when I first discovered it. Like, oh, God, even these really smart people who are so intelligent they have to have extra brain packs bolted to their chests don't have the magic answer to all of this. The rest of us are just screwed, then. But we find ways to make it work.Allen: Yep. There's a quote, I wish I remembered who said it, but it was a military quote where, “No battle plan survives impact with the enemy—first contact with the enemy.” It's kind of that way with infrastructure diagrams. We can draw it out however we want and then you turn it on in production. It's like, “Oh, no. That's not right.”Corey: I want to mix the metaphors there and say, yeah, no architecture survives your first fight with a customer. Like, “Great, I don't think that's quite what they're trying to say.” It's like, “What, you don't attack your customers? Pfft, what's your customer service line look like?” Yeah, it's… I think you're onto something.I think that inherently everything beyond the V1 design of almost anything is an emergent property where this is what we learned about it by running it and putting traffic through it and finding these problems, and here's how it wound up evolving to account for that.Allen: I agree. I don't have anything to add on that.Corey: [laugh]. Fair enough. I really want to thank you for taking so much time out of your day to talk about how you view these things. If people want to learn more, where is the best place to find you?Allen: Twitter is probably the best place to find me: @AllenHeltonDev. I have that username on all the major social platforms, so if you want to find me on LinkedIn, same thing: AllenHeltonDev. My blog is always open as well, if you have any feedback you'd like to give there: readysetcloud.io.Corey: And we will, of course, put links to that in the show notes. Thanks again for spending so much time talking to me. I really appreciate it.Allen: Yeah, this was fun. This was a lot of fun. I love talking shop.Corey: It shows. And it's nice to talk about things I don't spend enough time thinking about. Allen Helton, cloud architect at Tyler Technologies. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with an angry comment that I will reject because it was not written in valid XML.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

SAG Infotech Private Limited Company offers India's most popular software called Genius software. This software is India's most successful tool for tax return filing. It gives a very simple method of filing income and TDS returns with an e-payment option. Using the software, clients can complete their income tax, TDS, balance sheet, and AIR/SFT returns. Features of Genius return filing software such as importing pre-filled JSON data & previous year's full ITR data from the portal, calculation feature of reverse tax, MAT/AMT credit, etc. Let's follow more information given on the link: https://www.rajb2b.com/product/12051-genius-software.htm

This week John shares an uplifting update to his laptop endeavours from last week, a cycle based commuting story for the ages, and his recent work with using JSON, structured data and different layout systems. Scotty shares an update on the MoneyWell testing process including a syncing scheduling issue and a smart filter predicate issue and the ever long fight to keep your data off our servers. Ensembles Captionista John's Lyft Bike Rental | YouTube

Dans cet épisode, nous discutons bonnes pratiques Java, Groovy, WebAssembly, Micronaut. Nous discutons également le changement de licence de Akka entre autre. La suite de cet épisode parlera de changement d'étage gratuit chez Heroku et des vagues de licenciement dans le monde technologique. Pour rester sous les 1h d'écoute, nous avons découpé les deux derniers épisodes nouvelles en 2 parties chacun. Qu'en pensez vous ? Donnez-nous votre avis sur Twitter ou sur le Google Groups des cast codeurs. Enregistré le 9 septembre 2022 Téléchargement de l'épisode LesCastCodeurs-Episode–284.mp3 News Langages Jonathan Giles, un principal architecte de Java chez Microsoft, a un site qui partage des bonnes pratiques Java http://java.jonathangiles.net/ il couvre des bonnes pratiques Java de manière générale, mais également plus spécifiquement pour les développeurs de librairies Java Des conseils sur la bonne utilisation des dépendances, des BOMs, des versions LTS de Java, des modules Java, de la surface des APIs publiées, de faire attention à null ou au boxing, et de comprendre les interfaces fonctionnelles il y a beaucoup de contenu donc faites par petites doses Certains sujets sont plus controversés comme les modules Java les recommendations sont assez succinctes Je suppose que ce sont les recommendations que les équipes du Azure SDK suivent et qu'il a ouvert. Donc merci à lui Project Leyden https://www.infoq.com/news/2022/06/project-leyden-delays-aot/ Leyden n'a pas progressé en deux ans Accepté que GraalVM a déjà achevé les objectifs initiaux Donc vont explorer un spectre plus faible de contraintes (et probalbment d'optimisations Prochaine LTS en Sept 2023 et Leyden ne sera pas mature, donc Leyden sera utilse ~ Sept 2027 (en terme d'adoption) au plus tôt. SpringBoot pensent que CRaC (snapshot de la memoire sur disque pour demarrage plus rapide) sera très utile module-info dans Spring pourn jlink est dans la roadmap Lead de CRaC a fourni un prototype pour Quarkus: ameliore temps de demarrage pour OpenJDK mais pas la consommation memoire jlink pour Quarkus, dans un context Kube, les gains d'espace disque ne sont pas si interessant vs un layered image Micronaut a des issues ouverst pour CRaC José Paumard couvre Loom et Structured Concurrency dans sa vidéo de la série JEP Café https://inside.java/2022/08/02/jepcafe13/ Et cet article explique les problèmes classiques de concurrence comme les thread leaks et introduit la Structured Concurrency https://howtodoinjava.com/java/multi-threading/structured-concurrency/ Paul King montre l'utilisation de différents frameworks de tests avec Groovy (Spock, JUnit5, Jacoco, Jqwik et Pitest) https://blogs.apache.org/groovy/entry/testing-your-java-with-groovy Paul couvre aussi dans un autre article les comparateurs, et l'utilisation de l'API GINQ https://blogs.apache.org/groovy/entry/comparators-and-sorting-in-groovy La matrice spot est intéressante mais pas avec des noms de variable à, b, c, d :) L.article est super didactique et explique via un example concret quand utiliser quoi Je trouve les property base testing pas si simple à utiliser et avec un coup de réflection >> au truc testé. Mais peut être le cas est super simplistique pour l'usage Paul King continue de publier régulièrement des articles sur Groovy - https://blogs.apache.org/groovy/entry/working-with-sql-databases-with — accéder à des bases SQL avec Groovy et GraalVM - https://blogs.apache.org/groovy/entry/detecting-objects-with-groovy-the — détection d'objet avec le machine learning avec Deep Java Library et Apache MXNet Sortie de Spock 2.2, première version GA avec le support officiel de Groovy 4 https://twitter.com/spockframework/status/1564999285250326529 Bah la seule info intéressante est déjà dans le titre, càd c'est le support officiel de Groovy 4 Google lance un nouveau langage, appelé Carbon, comme un successeur de C++, mais en plus sympa ! https://github.com/carbon-language/carbon-lang interessant, ils veut Ceyloniser ou Scalaizer Rust avec Carbon's Kotlin-like strategy. Not a bad bet Rust n'est pas assez compatible avec C++, c'est problématique, surtout pour des boîtes comme Google avec d'énormes code bases en C++. Donc pour du green-field, Rust c'est bien. Ou c'est bien aussi pour de l'intégration avec du C. Mais pas avec du C++. State of WebAssembly https://blog.scottlogic.com/2022/06/20/state-of-wasm–2022.html On peut peut-être aussi rajouter l'utilisation de WebAssembly chez Figma https://neugierig.org/software/blog/2022/06/wasm-notes.html rust reste le langage de prédilection Python monte JavaScript est maintenant un langage viable Wasmtime est le runtime le plus populaire L'utilisation de WASM pour Serverless et la containérisation et en tant que hôte de plugin a beaucoup émergé Les api non browser sont ce dont a besoin web assembly En fait compilent pas JavaScript mais un moteur JavaScript et faire l'interprétation fonctionnalités très demandées : threads, exceptions, GC, type réflection etc Graal VM 22.2 https://medium.com/graalvm/graalvm–22–2-smaller-jdk-size-improved-memory-usage-better-library-support-and-more-cb34b5b68ec0 GraalVM JDK plus petit Plus petite conso mémoire lors de la création de native images Un travail de Quarkus, Micronaut et Spring Native pour ûblier des métadonnées partagées https://medium.com/graalvm/enhancing–3rd-party-library-support-in-graalvm-native-image-with-shared-metadata–9eeae1651da4 Possibilité de générer des heap dump dans des native images Différentes améliorations du compilateur Support de Apple Silicon Côté autres langages, GraalPython démarre plus vite et avec support étendu de librairie, et GraalJS avec une meilleurs interopérabilité Alex Blewitt un Java Champion est décédé prématurément https://www.infoq.com/news/2022/07/alex-blewitt/ notamment un contributeur à InfoQ Librairies Sortie de Micronaut 3.6 https://micronaut.io/2022/08/04/micronaut-framework–3–6–0-released/ Nouveau module Micronaut Test Resources avec une intégration TestContainers qui permet d'avoir des ressources de test externes, par exemple pour un Redis, un Elasticsearch ou autre Cédric Champeau qui a travaillé sur cette fonctionnalité a écrit un blog post complet sur le sujet https://melix.github.io/blog//2022/08/micronaut-test-resources.html Intégration avec OpenTelemetry (après Open Tracing et autre) Micronaut Data rajoute Hibernate Reactive comme intégration et plein d'autres mises à jour des différents modules existants Utiliser des serialiseurs. / deserialiseurs de messages Kafka dans votre application Quarkus https://quarkus.io/blog/kafka-serde/ explique quand on a besoin d'un serialisateur custom (hors des types fondamentaux) Explique que le support JSON existe par défaut Explique comment utiliser Avro mais avec un schéma registry Et la version full custom Akka change sa licence de ASL vers BSL (Business Source License) https://www.lightbend.com/blog/why-we-are-changing-the-license-for-akka comme MariaDB, Cockroach Labs, Sentry, Materialized BSL is source available et usage dev mais pas prod Après 3 ans, les commits en BSL se convertissent en ASL (donc pas les nouveaux commits) license commerciale disponible pour 2000$ par coeur due au fait qu'avec la maturiote de Akka les contributions ont diminué et le support est revenu a LightBend de plus en plus meme si des societes grosse utilisent Akka dans leur infra critique Gatling impacté Mécontentement de la communauté Akka et Scala, par exemple cet article d'Alexandru Nedelcu https://alexn.org/blog/2022/09/07/akka-is-moving-away-from-open-source Nous contacter Pour réagir à cet épisode, venez discuter sur le groupe Google https://groups.google.com/group/lescastcodeurs Contactez-nous via twitter https://twitter.com/lescastcodeurs Faire un crowdcast ou une crowdquestion Soutenez Les Cast Codeurs sur Patreon https://www.patreon.com/LesCastCodeurs Tous les épisodes et toutes les infos sur https://lescastcodeurs.com/

In this episode we sit down with engineers, Steve Morgan and Edward Morgan, to discuss how they use Trino at Raft. Raft provides consulting services and is particularly skilled at DevSecOps. One particular challenge they face is dealing with fragmented government infrastructure. In this episode, we dive in to learn how Trino enables Raft to supply government sector clients with a data fabric solution. Raft takes a special stance on using and contributing to open source solutions that run well on the cloud.- Intro: 0:00- Intro: 0:32- Releases: 5:14- Concept of the episode: Trino at Raft: 12:08- Concept of the episode: Software factory: 13:21- Concept of the episode: Standards and anatomy of a stack: 16:24- Concept of the episode: Data Fabric at Raft: 18:58- Concept of the episode: Security concerns around Trino: 22:01- Concept of the episode: Iron bank container repository : 29:27- Concept of the episode: Data Fabric user perspective : 36:13- Concept of the episode: Challenges for adoption : 45:52- Pull request of the episode: PR 13354: Add S3 Select pushdown for JSON files: 1:05:34- Demo of the episode: Running Great Expectations on a Trino Data Lakehouse Tutorial: 1:08:01- Question of the episode: How can I deploy Trino on Kubernetes without using Helm chart?: 1:13:55Show Notes: https://trino.io/episodes/39.htmlShow Page: https://trino.io/broadcast/

Знали ли вы, что требования вашего РФ работодателя не разглашать зарплату "потому что NDA" не имеют никакого юридического основания? Или то, что огромные штрафы, прописанные за нарушение NDA в РФ компаниях — это зачастую просто способ запугать сотрудника? Что, если вы работаете в оупен-спейсе, а кто-то подглядел ваш секретный алгоритм (парсинга JSON-а), который был коммерческой тайной? А что вообще может и не может составлять коммерческую тайну и какая ответственность грозит за ее разглашение? Так много вопросов! Найти на них ответы и прокачаться в знании своих прав нам помогли ведущий юрисконсульт EdgeCenter и эксперт в области data protection Татьяна Красногорская, а также лучший друг тимлидов и рекордсмен по выступлениям в Podlodka Виталий Шароватов. ​​«Золотое Яблоко» - №1 по выручке среди бьюти e-commerce России. А у приложения сейчас более 14 млн скачиваний. В команду нужны: product owner, UX/UI-дизайнеры, тестировщики, web-аналитики, online-мерчендайзеры и контент-менеджеры. Резюме присылайте на hr.it@goldapple.ru. Поддержи лучший подкаст про IT: www.patreon.com/podlodka Также ждем вас, ваши лайки, репосты и комменты в мессенджерах и соцсетях!
 Telegram-чат: https://t.me/podlodka Telegram-канал: https://t.me/podlodkanews Страница в Facebook: www.facebook.com/podlodkacast/ Twitter-аккаунт: https://twitter.com/PodlodkaPodcast Ведущие в выпуске: Катя Петрова, Евгений Кателла Полезные ссылки: Виталий Шароватов: https://github.com/sharovatov/teamlead? https://www.youtube.com/watch?v=oxHzIdpLjmc&list=PLFtS8Ah0wZvWS37oveJ0-D5K6V7GWUpqY https://t.me/vitaly19842 Татьяна Красногорская: https://instagram.com/krasnogorskaya.law?r=nametag https://instagram.com/ipitbox?igshid=Y2ZmNzg0YzQ= https://t.me/Tatyana_Krasnogorskaya

How do you plan Apache Kafka® capacity and Kafka Streams sizing for optimal performance? When Jason Bell (Principal Engineer, Dataworks and founder of Synthetica Data), begins to plan a Kafka cluster, he starts with a deep inspection of the customer's data itself—determining its volume as well as its contents: Is it JSON, straight pieces of text, or images? He then determines if Kafka is a good fit for the project overall, a decision he bases on volume, the desired architecture, as well as potential cost.Next, the cluster is conceived in terms of some rule-of-thumb numbers. For example, Jason's minimum number of brokers for a cluster is three or four. This means he has a leader, a follower and at least one backup.  A ZooKeeper quorum is also a set of three. For other elements, he works with pairs, an active and a standby—this applies to Kafka Connect and Schema Registry. Finally, there's Prometheus monitoring and Grafana alerting to add. Jason points out that these numbers are different for multi-data-center architectures.Jason never assumes that everyone knows how Kafka works, because some software teams include specialists working on a producer or a consumer, who don't work directly with Kafka itself. They may not know how to adequately measure their Kafka volume themselves, so he often begins the collaborative process of graphing message volumes. He considers, for example, how many messages there are daily, and whether there is a peak time. Each industry is different, with some focusing on daily batch data (banking), and others fielding incredible amounts of continuous data (IoT data streaming from cars).  Extensive testing is necessary to ensure that the data patterns are adequately accommodated. Jason sets up a short-lived system that is identical to the main system. He finds that teams usually have not adequately tested across domain boundaries or the network. Developers tend to think in terms of numbers of messages, but not in terms of overall network traffic, or in how many consumers they'll actually need, for example. Latency must also be considered, for example if the compression on the producer's side doesn't match compression on the consumer's side, it will increase.Kafka Connect sink connectors require special consideration when Jason is establishing a cluster. Failure strategies need to well thought out, including retries and how to deal with the potentially large number of messages that can accumulate in a dead letter queue. He suggests that more attention should generally be paid to the Kafka Connect elements of a cluster, something that can actually be addressed with bash scripts.Finally, Kris and Jason cover his preference for Kafka Streams over ksqlDB from a network perspective. EPISODE LINKSCapacity Planning and Sizing for Kafka StreamsTales from the Frontline of Apache Kafka DevOpsWatch the video version of this podcastKris Jenkins' TwitterStreaming Audio Playlist Join the Confluent CommunityLearn more on Confluent DeveloperUse PODCAST100 to get $100 of free Cloud usage (details)  

Generate e-Way Bills in tally at the time of the creation of invoices As soon as you finish #filling up details in an invoice, based on the #criteria settings (as mentioned above), Tally.ERP 9 will open up a subform in which you can provide #additional details of #transportation. After this, you can #export the data in a #JSON file. This JSON file can be uploaded on the e-Way Bill Portal and you can generate your e-Way Bill. Along with #transportation details, the #Bill will also display the e-Way Bill Number (EBN). The EBN can be typed in its corresponding #invoice, and you can take a print. For expert advice Call: +91-8882196405 Email: info@bpaeducators.com Private Facebook group: BPA mastery To get more updates join VIP COMMUNITY OF BPA EDUCATORS- https://www.facebook.com/groups/bpamastery/ Website: www.bpaeducators.com Instagram: https://www.instagram.com/bpaeducator/ Facebook: https://www.facebook.com/bpaeducator Twitter: https://twitter.com/EducatorsBpa Youtube: https://tinyurl.com/y9nb27xc Linkedin: https://www.linkedin.com/company/bpa-educators/ Address: C-8/13, Sector-7, Rohini, Delhi-110085 Call: +91-8882196405 Email: info@bpaeducators.com Private Facebook group: BPA mastery To get more updates join VIP COMMUNITY OF BPA EDUCATORS- https://www.facebook.com/groups/bpamastery/ Website: www.bpaeducators.com Instagram: https://www.instagram.com/bpaeducator/ Facebook: https://www.facebook.com/bpaeducator Twitter: https://twitter.com/EducatorsBpa YouTube: https://tinyurl.com/y9nb27xc LinkedIn: https://www.linkedin.com/company/bpa-educators/

About MattMatt is a Sr. Architect in Belfast, an AWS DevTools Hero, Serverless Architect, Author and conference speaker. He is focused on creating the right environment for empowered teams to rapidly deliver business value in a well-architected, sustainable and serverless-first way.You can usually find him sharing reusable, well architected, serverless patterns over at cdkpatterns.com or behind the scenes bringing CDK Day to life.Links Referenced: Previous guest appearance: https://www.lastweekinaws.com/podcast/screaming-in-the-cloud/slinging-cdk-knowledge-with-matt-coulter/ The CDK Book: https://thecdkbook.com/ Twitter: https://twitter.com/NIDeveloper TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. One of the best parts about, well I guess being me, is that I can hold opinions that are… well, I'm going to be polite and call them incendiary, and that's great because I usually like to back them in data. But what happens when things change? What happens when I learn new things?Well, do I hold on to that original opinion with two hands at a death grip or do I admit that I was wrong in my initial opinion about something? Let's find out. My guest today returns from earlier this year. Matt Coulter is a senior architect since he has been promoted at Liberty Mutual. Welcome back, and thanks for joining me.Matt: Yeah, thanks for inviting me back, especially to talk about this topic.Corey: Well, we spoke about it a fair bit at the beginning of the year. And if you're listening to this, and you haven't heard that show, it's not that necessary to go into; mostly it was me spouting uninformed opinions about the CDK—the Cloud Development Kit, for those who are unfamiliar—I think of it more or less as what if you could just structure your cloud resources using a programming language you claim to already know, but in practice, copy and paste from Stack Overflow like the rest of us? Matt, you probably have a better description of what the CDK is in practice.Matt: Yeah, so we like to say it's imperative code written in a declarative way, or declarative code written in an imperative way. Either way, it lets you write code that produces CloudFormation. So, it doesn't really matter what you write in your script; the point is, at the end of the day, you still have the CloudFormation template that comes out of it. So, the whole piece of it is that it's a developer experience, developer speed play, that if you're from a background that you're more used to writing a programming language than a YAML, you might actually enjoy using the CDK over writing straight CloudFormation or SAM.Corey: When I first kicked the tires on the CDK, my first initial obstacle—which I've struggled with in this industry for a bit—is that I'm just good enough of a programmer to get myself in trouble. Whenever I wind up having a problem that StackOverflow doesn't immediately shine a light on, my default solution is to resort to my weapon of choice, which is brute force. That sometimes works out, sometimes doesn't. And as I went through the CDK, a couple of times in service to a project that I'll explain shortly, I made a bunch of missteps with it. The first and most obvious one is that AWS claims publicly that it has support in a bunch of languages: .NET, Python, there's obviously TypeScript, there's Go support for it—I believe that went generally available—and I'm sure I'm missing one or two, I think? Aren't I?Matt: Yeah, it's: TypeScript, JavaScript, Python Java.Net, and Go. I think those are the currently supported languages.Corey: Java. That's the one that I keep forgetting. It's the block printing to the script that is basically Java cursive. The problem I run into, and this is true of most things in my experience, when a company says that we have deployed an SDK for all of the following languages, there is very clearly a first-class citizen language and then the rest that more or less drift along behind with varying degrees of fidelity. In my experience, when I tried it for the first time in Python, it was not a great experience for me.When I learned just enough JavaScript, and by extension TypeScript, to be dangerous, it worked a lot better. Or at least I could blame all the problems I ran into on my complete novice status when it comes to JavaScript and TypeScript at the time. Is that directionally aligned with what you've experienced, given that you work in a large company that uses this, and presumably, once you have more than, I don't know, two developers, you start to take on aspects of a polyglot shop no matter where you are, on some level?Matt: Yeah. So personally, I jump between Java, Python, and TypeScript whenever I'm writing projects. So, when it comes to the CDK, you'd assume I'd be using all three. I typically stick to TypeScript and that's just because personally, I've had the best experience using it. For anybody who doesn't know the way CDK works for all the languages, it's not that they have written a custom, like, SDK for each of these languages; it's a case of it uses a Node process underneath them and the language actually interacts with—it's like the compiled JavaScript version is basically what they all interact with.So, it means there are some limitations on what you can do in that language. I can't remember the full list, but it just means that it is native in all those languages, but there are certain features that you might be like, “Ah,” whereas, in TypeScript, you can just use all of TypeScript. And my first inclination was actually, I was using the Python one and I was having issues with some compiler errors and things that are just caused by that process. And it's something that talking in the cdk.dev Slack community—there is actually a very active—Corey: Which is wonderful, I will point out.Matt: [laugh]. Thank you. There is actually, like, an awesome Python community in there, but if you ask them, they would all ask for improvements to the language. So, personally if someone's new, I always recommend they start with TypeScript and then branch out as they learn the CDK so they can understand is this a me problem, or is this a problem caused by the implementation?Corey: From my perspective, I didn't do anything approaching that level of deep dive. I took a shortcut that I find has served me reasonably well in the course of my career, when I'm trying to do something in Python, and you pull up a tutorial—which I'm a big fan of reading experience reports, and blog posts, and here's how to get started—and they all have the same problem, which is step one, “Run npm install.” And that's “Hmm, you know, I don't recall that being a standard part of the Python tooling.” It's clearly designed and interpreted and contextualized through a lens of JavaScript. Let's remove that translation layer, let's remove any weird issues I'm going to have in that transpilation process, and just talk in the language it written in. Will this solve my problems? Oh, absolutely not, but it will remove a subset of them that I am certain to go blundering into like a small lost child trying to cross an eight-lane freeway.Matt: Yeah. I've heard a lot of people say the same thing. Because the CDK CLI is a Node process, you need it no matter what language you use. So, if they were distributing some kind of universal binary that just integrated with the languages, it would definitely solve a lot of people's issues with trying to combine languages at deploy time.Corey: One of the challenges that I've had as I go through the process of iterating on the project—but I guess I should probably describe it for those who have not been following along with my misadventures; I write blog posts about it from time to time because I need a toy problem to kick around sometimes because my consulting work is all advisory and I don't want to be a talking head-I have a Twitter client called lasttweetinaws.com. It's free; go and use it. It does all kinds of interesting things for authoring Twitter threads.And I wanted to deploy that to a bunch of different AWS regions, as it turns out, 20 or so at the moment. And that led to a lot of interesting projects and having to learn how to think about these things differently because no one sensible deploys an application simultaneously to what amounts to every AWS region, without canary testing, and having a phased rollout in the rest. But I'm reckless, and honestly, as said earlier, a bad programmer. So, that works out. And trying to find ways to make this all work and fit together led iteratively towards me discovering that the CDK was really kind of awesome for a lot of this.That said, there were definitely some fairly gnarly things I learned as I went through it, due in no small part to help I received from generous randos in the cdk.dev Slack team. And it's gotten to a point where it's working, and as an added bonus, I even mostly understand what he's doing, which is just kind of wild to me.Matt: It's one of those interesting things where because it's a programming language, you can use it out of the box the way it's designed to be used where you can just write your simple logic which generates your CloudFormation, or you can do whatever crazy logic you want to do on top of that to make your app work the way you want it to work. And providing you're not in a company like Liberty, where I'm going to do a code review, if no one's stopping you, you can do your crazy experiments. And if you understand that, it's good. But I do think something like the multi-region deploy, I mean, with CDK, if you'd have a construct, it takes in a variable that you can just say what the region is, so you can actually just write a for loop and pass it in, which does make things a lot easier than, I don't know, try to do it with a YAML, which you can pass in parameters, but you're going to get a lot more complicated a lot quicker.Corey: The approach that I took philosophically was I wrote everything in a region-agnostic way. And it would be instantiated and be told what region to run it in as an environment variable that CDK deploy was called. And then I just deploy 20 simultaneous stacks through GitHub Actions, which invoke custom runners that runs inside of a Lambda function. And that's just a relatively basic YAML file, thanks to the magic of GitHub Actions matrix jobs. So, it fires off 20 simultaneous processes and on every commit to the main branch, and then after about two-and-a-half minutes, it has been deployed globally everywhere and I get notified on anything that fails, which is always fun and exciting to learn those things.That has been, overall, just a really useful experiment and an experience because you're right, you could theoretically run this as a single CDK deploy and then wind up having an iterate through a list of regions. The challenge I have there is that unless I start getting into really convoluted asynchronous concurrency stuff, it feels like it'll just take forever. At two-and-a-half minutes a region times 20 regions, that's the better part of an hour on every deploy and no one's got that kind of patience. So, I wound up just parallelizing it a bit further up the stack. That said, I bet they are relatively straightforward ways, given the async is a big part of JavaScript, to do this simultaneously.Matt: One of the pieces of feedback I've seen about CDK is if you have multiple stacks in the same project, it'll deploy them one at a time. And that's just because it tries to understand the dependencies between the stacks and then it works out which one should go first. But a lot of people have said, “Well, I don't want that. If I have 20 stacks, I want all 20 to go at once the way you're saying.” And I have seen that people have been writing plugins to enable concurrent deploys with CDK out of the box. So, it may be something that it's not an out-of-the-box feature, but it might be something that you can pull in a community plug-in to actually make work.Corey: Most of my problems with it at this point are really problems with CloudFormation. CloudFormation does not support well, if at all, secure string parameters from the AWS Systems Manager parameter store, which is my default go-to for secret storage, and Secrets Manager is supported, but that also cost 40 cents a month per secret. And not for nothing, I don't really want to have all five secrets deployed to Secrets Manager in every region this thing is in. I don't really want to pay $20 a month for this basically free application, just to hold some secrets. So, I wound up talking to some folks in the Slack channel and what we came up with was, I have a centralized S3 bucket that has a JSON object that lives in there.It's only accessible from the deployment role, and it grabs that at deploy time and stuffs it into environment variables when it pushes these things out. That's the only stateful part of all of this. And it felt like that is, on some level, a pattern that a lot of people would benefit from if it had better native support. But the counterargument that if you're only deploying to one or two regions, then Secrets Manager is the right answer for a lot of this and it's not that big of a deal.Matt: Yeah. And it's another one of those things, if you're deploying in Liberty, we'll say, “Well, your secret is unencrypted at runtime, so you probably need a KMS key involved in that,” which as you know, the costs of KMS, it depends on if it's a personal solution or if it's something for, like, a Fortune 100 company. And if it's personal solution, I mean, what you're saying sounds great that it's IAM restricted in S3, and then that way only at deploy time can be read; it actually could be a custom construct that someone can build and publish out there to the construct library—or the construct hub, I should say.Corey: To be clear, the reason I'm okay with this, from a security perspective is one, this is in a dedicated AWS account. This is the only thing that lives in that account. And two, the only API credentials we're talking about are the application-specific credentials for this Twitter client when it winds up talking to the Twitter API. Basically, if you get access to these and are able to steal them and deploy somewhere else, you get no access to customer data, you get—or user data because this is not charge for anything—you get no access to things that have been sent out; all you get to do is submit tweets to Twitter and it'll have the string ‘Last Tweet in AWS' as your client, rather than whatever normal client you would use. It's not exactly what we'd call a high-value target because all the sensitive to a user data lives in local storage in their browser. It is fully stateless.Matt: Yeah, so this is what I mean. Like, it's the difference in what you're using your app for. Perfect case of, you can just go into the Twitter app and just withdraw those credentials and do it again if something happens, whereas as I say, if you're building it for Liberty, that it will not pass a lot of our Well-Architected reviews, just for that reason.Corey: If I were going to go and deploy this at a more, I guess, locked down environment, I would be tempted to find alternative approaches such as having it stored encrypted at rest via KMS in S3 is one option. So, is having global DynamoDB tables that wind up grabbing those things, even grabbing it at runtime if necessary. There are ways to make that credential more secure at rest. It's just, I look at this from a real-world perspective of what is the actual attack surface on this, and I have a really hard time just identifying anything that is going to be meaningful with regard to an exploit. If you're listening to this and have a lot of thoughts on that matter, please reach out I'm willing to learn and change my opinion on things.Matt: One thing I will say about the Dynamo approach you mentioned, I'm not sure everybody knows this, but inside the same Dynamo table, you can scope down a row. You can be, like, “This row and this field in this row can only be accessed from this one Lambda function.” So, there's a lot of really awesome security features inside DynamoDB that I don't think most people take advantage of, but they open up a lot of options for simplicity.Corey: Is that tied to the very recent announcement about Lambda getting SourceArn as a condition key? In other words, you can say, “This specific Lambda function,” as opposed to, “A Lambda in this account?” Like that was a relatively recent Advent that I haven't fully explored the nuances of.Matt: Yeah, like, that has opened a lot of doors. I mean, the Dynamo being able to be locked out in your row has been around for a while, but the new Lambda from SourceArn is awesome because, yeah, as you say, you can literally say this thing, as opposed to, you have to start going into tags, or you have to start going into something else to find it.Corey: So, I want to talk about something you just alluded to, which is the Well-Architected Framework. And initially, when it launched, it was a whole framework, and AWS made a lot of noise about it on keynote stages, as they are want to do. And then later, they created a quote-unquote, “Well-Architected Tool,” which let's be very direct, it's the checkbox survey form, at least the last time I looked at it. And they now have the six pillars of the Well-Architected Framework where they talk about things like security, cost, sustainability is the new pillar, I don't know, absorbency, or whatever the remainders are. I can't think of them off the top of my head. How does that map to your experience with the CDK?Matt: Yeah, so out of the box, the CDK from day one was designed to have sensible defaults. And that's why a lot of the things you deploy have opinions. I talked to a couple of the Heroes and they were like, “I wish it had less opinions.” But that's why whenever you deploy something, it's got a bunch of configuration already in there. For me, in the CDK, whenever I use constructs, or stacks, or deploying anything in the CDK, I always build it in a well-architected way.And that's such a loaded sentence whenever you say the word ‘well-architected,' that people go, “What do you mean?” And that's where I go through the six pillars. And in Liberty, we have a process, it used to be called SCORP because it was five pillars, but not SCORPS [laugh] because they added sustainability. But that's where for every stack, we'll go through it and we'll be like, “Okay, let's have the discussion.” And we will use the tool that you mentioned, I mean, the tool, as you say, it's a bunch of tick boxes with a text box, but the idea is we'll get in a room and as we build the starter patterns or these pieces of infrastructure that people are going to reuse, we'll run the well-architected review against the framework before anybody gets to generate it.And then we can say, out of the box, if you generate this thing, these are the pros and cons against the Well-Architected Framework of what you're getting. Because we can't make it a hundred percent bulletproof for your use case because we don't know it, but we can tell you out of the box, what it does. And then that way, you can keep building so they start off with something that is well documented how well architected it is, and then you can start having—it makes it a lot easier to have those conversations as they go forward. Because you just have to talk about the delta as they start adding their own code. Then you can and you go, “Okay, you've added these 20 lines. Let's talk about what they do.” And that's why I always think you can do a strong connection between infrastructure-as-code and well architected.Corey: As I look through the actual six pillars of the Well-Architected Framework: sustainability, cost optimization, performance, efficiency, reliability, security, and operational excellence, as I think through the nature of what this shitpost thread Twitter client is, I am reasonably confident across all of those pillars. I mean, first off, when it comes to the cost optimization pillar, please, don't come to my house and tell me how that works. Yeah, obnoxiously the security pillar is sort of the thing that winds up causing a problem for this because this is an account deployed by Control Tower. And when I was getting this all set up, my monthly cost for this thing was something like a dollar in charges and then another sixteen dollars for the AWS config rule evaluations on all of the deploys, which is… it just feels like a tax on going about your business, but fine, whatever. Cost and sustainability, from my perspective, also tend to be hand-in-glove when it comes to this stuff.When no one is using the client, it is not taking up any compute resources, it has no carbon footprint of which to speak, by my understanding, it's very hard to optimize this down further from a sustainability perspective without barging my way into the middle of an AWS negotiation with one of its power companies.Matt: So, for everyone listening, watch as we do a live well-architected review because—Corey: Oh yeah, I expect—Matt: —this is what they are. [laugh].Corey: You joke; we should do this on Twitter one of these days. I think would be a fantastic conversation. Or Twitch, or whatever the kids are using these days. Yeah.Matt: Yeah.Corey: And again, if so much of it, too, is thinking about the context. Security, you work for one of the world's largest insurance companies. I shitpost for a living. The relative access and consequences of screwing up the security on this are nowhere near equivalent. And I think that's something that often gets lost, per the perfect be the enemy of the good.Matt: Yeah that's why, unfortunately, the Well-Architected Tool is quite loose. So, that's why they have the Well-Architected Framework, which is, there's a white paper that just covers anything which is quite big, and then they wrote specific lenses for, like, serverless or other use cases that are shorter. And then when you do a well-architected review, it's like loose on, sort of like, how are you applying the principles of well-architected. And the conversation that we just had about security, so you would write that down in the box and be, like, “Okay, so I understand if anybody gets this credential, it means they can post this Last Tweet in AWS, and that's okay.”Corey: The client, not the Twitter account, to be clear.Matt: Yeah. So, that's okay. That's what you just mark down in the well-architected review. And then if we go to day one on the future, you can compare it and we can go, “Oh. Okay, so last time, you said this,” and you can go, “Well, actually, I decided to—” or you just keep it as a note.Corey: “We pivoted. We're a bank now.” Yeah.Matt: [laugh]. So, that's where—we do more than tweets now. We decided to do microtransactions through cryptocurrency over Twitter. I don't know but if you—Corey: And that ends this conversation. No no. [laugh].Matt: [laugh]. But yeah, so if something changes, that's what the well-architected reviews for. It's about facilitating the conversation between the architect and the engineer. That's all it is.Corey: This episode is sponsored in part by our friend EnterpriseDB. EnterpriseDB has been powering enterprise applications with PostgreSQL for 15 years. And now EnterpriseDB has you covered wherever you deploy PostgreSQL on-premises, private cloud, and they just announced a fully-managed service on AWS and Azure called BigAnimal, all one word. Don't leave managing your database to your cloud vendor because they're too busy launching another half-dozen managed databases to focus on any one of them that they didn't build themselves. Instead, work with the experts over at EnterpriseDB. They can save you time and money, they can even help you migrate legacy applications—including Oracle—to the cloud. To learn more, try BigAnimal for free. Go to biganimal.com/snark, and tell them Corey sent you.Corey: And the lens is also helpful in that this is a serverless application. So, we're going to view it through that lens, which is great because the original version of the Well-Architected Tool is, “Oh, you built this thing entirely in Lambda? Have you bought some reserved instances for it?” And it's, yeah, why do I feel like I have to explain to AWS how their own systems work? This makes it a lot more streamlined and talks about this, though, it still does struggle with the concept of—in my case—a stateless app. That is still something that I think is not the common path. Imagine that: my code is also non-traditional. Who knew?Matt: Who knew? The one thing that's good about it, if anybody doesn't know, they just updated the serverless lens about, I don't know, a week or two ago. So, they added in a bunch of more use cases. So, if you've read it six months ago, or even three months ago, go back and reread it because they spent a good year updating it.Corey: Thank you for telling me that. That will of course wind up in next week's issue of Last Week in AWS. You can go back and look at the archives and figure out what week record of this then. Good work. One thing that I have learned as well as of yesterday, as it turns out, before we wound up having this recording—obviously because yesterday generally tends to come before today, that is a universal truism—is it I had to do a bit of refactoring.Because what I learned when I was in New York live-tweeting the AWS Summit, is that the Route 53 latency record works based upon where your DNS server is. Yeah, that makes sense. I use Tailscale and wind up using my Pi-hole, which lives back in my house in San Francisco. Yeah, I was always getting us-west-1 from across the country. Cool.For those weird edge cases like me—because this is not the common case—how do I force a local region? Ah, I'll give it its own individual region prepend as a subdomain. Getting that to work with both the global lasttweetinaws.com domain as well as the subdomain on API Gateway through the CDK was not obvious on how to do it.Randall Hunt over at Caylent was awfully generous and came up with a proof-of-concept in about three minutes because he's Randall, and that was extraordinarily helpful. But a challenge I ran into was that the CDK deploy would fail because the way that CloudFormation was rendered in the way it was trying to do stuff, “Oh, that already has that domain affiliated in a different way.” I had to do a CDK destroy then a CDK deploy for each one. Now, not the end of the world, but it got me thinking, everything that I see around the CDK more or less distills down to either greenfield or a day one experience. That's great, but throw it all away and start over is often not what you get to do.And even though Amazon says it's always day one, those of us in, you know, real companies don't get to just treat everything as brand new and throw away everything older than 18 months. What is the day two experience looking like for you? Because you clearly have a legacy business. By legacy, I of course, use it in the condescending engineering term that means it makes actual money, rather than just telling really good stories to venture capitalists for 20 years.Matt: Yeah. We still have mainframes running that make a lot of money. So, I don't mock legacy at all.Corey: “What's that piece of crap do?” “Well, about $4 billion a year in revenue. Perhaps show some respect.” It's a common refrain.Matt: Yeah, exactly. So yeah, anyone listening, don't mock legacy because as Corey says, it is running the business. But for us when it comes to day two, it's something that I'm actually really passionate about this in general because it is really easy. Like I did it with CDK patterns, it's really easy to come out and be like, “Okay, we're going to create a bunch of starter patterns, or quickstarts”—or whatever flavor that you came up with—“And then you're going to deploy this thing, and we're going to have you in production and 30 seconds.” But even day one later that day—not even necessarily day two—it depends on who it was that deployed it and how long they've been using AWS.So, you hear these stories of people who deployed something to experiment, and they either forget to delete, it cost them a lot of money or they tried to change it and it breaks because they didn't understand what was in it. And this is where the community starts to diverge in their opinions on what AWS CDK should be. There's a lot of people who think that at the minute CDK, even if you create an abstraction in a construct, even if I create a construct and put it in the construct library that you get to use, it still unravels and deploys as part of your deploy. So, everything that's associated with it, you don't own and you technically need to understand that at some point because it might, in theory, break. Whereas there's a lot of people who think, “Okay, the CDK needs to go server side and an abstraction needs to stay an abstraction in the cloud. And then that way, if somebody is looking at a 20-line CDK construct or stack, then it stays 20 lines. It never unravels to something crazy underneath.”I mean, that's one pro tip thing. It'd be awesome if that could work. I'm not sure how the support for that would work from a—if you've got something running on the cloud, I'm pretty sure AWS [laugh] aren't going to jump on a call to support some construct that I deployed, so I'm not sure how that will work in the open-source sense. But what we're doing at Liberty is the other way. So, I mean, we famously have things like the software accelerator that lets you pick a pattern or create your pipelines and you're deployed, but now what we're doing is we're building a lot of telemetry and automated information around what you deployed so that way—and it's all based on Well-Architected, common theme. So, that way, what you can do is you can go into [crosstalk 00:26:07]—Corey: It's partially [unintelligible 00:26:07], and partially at a glance, figure out okay, are there some things that can be easily remediated as we basically shift that whole thing left?Matt: Yeah, so if you deploy something, and it should be good the second you deploy it, but then you start making changes. Because you're Corey, you just start adding some stuff and you deploy it. And if it's really bad, it won't deploy. Like, that's the Liberty setup. There's a bunch of rules that all go, “Okay, that's really bad. That'll cause damage to customers.”But there's a large gap between bad and good that people don't really understand the difference that can cost a lot of money or can cause a lot of grief for developers because they go down the wrong path. So, that's why what we're now building is, after you deploy, there's a dashboard that'll just come up and be like, “Hey, we've noticed that your Lambda function has too little memory. It's going to be slow. You're going to have bad cold starts.” Or you know, things like that.The knowledge that I have had the gain through hard fighting over the past couple of years putting it into automation, and that way, combined with the well-architected reviews, you actually get me sitting in a call going, “Okay, let's talk about what you're building,” that hopefully guides people the right way. But I still think there's so much more we can do for day two because even if you deploy the best solution today, six months from now, AWS are releasing ten new services that make it easier to do what you just did. So, someone also needs to build something that shows you the delta to get to the best. And that would involve AWS or somebody thinking cohesively, like, these are how we use our products. And I don't think there's a market for it as a third-party company, unfortunately, but I do think that's where we need to get to, that at day two somebody can give—the way we're trying to do for Liberty—advice, automated that says, “I see what you're doing, but it would be better if you did this instead.”Corey: Yeah, I definitely want to spend more time thinking about these things and analyzing how we wind up addressing them and how we think about them going forward. I learned a lot of these lessons over a decade ago. I was fairly deep into using Puppet, and came to the fair and balanced conclusion that Puppet was a steaming piece of crap. So, the solution was that I was one of the very early developers behind SaltStack, which was going to do everything right. And it was and it was awesome and it was glorious, right up until I saw an environment deployed by someone else who was not as familiar with the tool as I was, at which point I realized hell is other people's use cases.And the way that they contextualize these things, you craft a finely balanced torque wrench, it's a thing of beauty, and people complain about the crappy hammer. “You're holding it wrong. No, don't do it that way.” So, I have an awful lot of sympathy for people building platform-level tooling like this, where it works super well for the use case that they're in, but not necessarily… they're not necessarily aligned in other ways. It's a very hard nut to crack.Matt: Yeah. And like, even as you mentioned earlier, if you take one piece of AWS, for example, API Gateway—and I love the API Gateway team; if you're listening, don't hate on me—but there's, like, 47,000 different ways you can deploy an API Gateway. And the CDK has to cover all of those, it would be a lot easier if there was less ways that you could deploy the thing and then you can start crafting user experiences on a platform. But whenever you start thinking that every AWS component is kind of the same, like think of the amount of ways you're can deploy a Lambda function now, or think of the, like, containers. I'll not even go into [laugh] the different ways to run containers.If you're building a platform, either you support it all and then it sort of gets quite generic-y, or you're going to do, like, what serverless cloud are doing though, like Jeremy Daly is building this unique experience that's like, “Okay, the code is going to build the infrastructure, so just build a website, and we'll do it all behind it.” And I think they're really interesting because they're sort of opposites, in that one doesn't want to support everything, but should theoretically, for their slice of customers, be awesome, and then the other ones, like, “Well, let's see what you're going to do. Let's have a go at it and I should hopefully support it.”Corey: I think that there's so much that can be done on this. But before we wind up calling it an episode, I had one further question that I wanted to explore around the recent results of the community CDK survey that I believe is a quarterly event. And I read the analysis on this, and I talked about it briefly in the newsletter, but it talks about adoption and a few other aspects of it. And one of the big things it looks at is the number of people who are contributing to the CDK in an open-source context. Am I just thinking about this the wrong way when I think that, well, this is a tool that helps me build out cloud infrastructure; me having to contribute code to this thing at all is something of a bug, whereas yeah, I want this thing to work out super well—Docker is open-source, but you'll never see me contributing things to Docker ever, as a pull request, because it does, as it says on the tin; I don't have any problems that I'm aware of that, ooh, it should do this instead. I mean, I have opinions on that, but those aren't pull requests; those are complete, you know, shifts in product strategy, which it turns out is not quite done on GitHub.Matt: So, it's funny I, a while ago, was talking to a lad who was the person who came up with the idea for the CDK. And CDK is pretty much the open-source project for AWS if you look at what they have. And the thought behind it, it's meant to evolve into what people want and need. So yes, there is a product manager in AWS, and there's a team fully dedicated to building it, but the ultimate aspiration was always it should be bigger than AWS and it should be community-driven. Now personally, I'm not sure—like you just said it—what the incentive is, given that right now CDK only works with CloudFormation, which means that you are directly helping with an AWS tool, but it does give me hope for, like, their CDK for Terraform, and their CDK for Kubernetes, and there's other flavors based on the same technology as AWS CDK that potentially could have a thriving open-source community because they work across all the clouds. So, it might make more sense for people to jump in there.Corey: Yeah, I don't necessarily think that there's a strong value proposition as it stands today for the idea of the CDK becoming something that works across other cloud providers. I know it technically has the capability, but if I think that Python isn't quite a first-class experience, I don't even want to imagine what other providers are going to look like from that particular context.Matt: Yeah, and that's from what I understand, I haven't personally jumped into the CDK for Terraform and we didn't talk about it here, but in CDK, you get your different levels of construct. And is, like, a CloudFormation-level construct, so everything that's in there directly maps to a property in CloudFormation, and then L2 is AWS's opinion on safe defaults, and then L3 is when someone like me comes along and turns it into something that you may find useful. So, it's a pattern. As far as I know, CDK for Terraform is still on L1. They haven't got the rich collection—Corey: And L4 is just hiring you as a consultant—Matt: [laugh].Corey: —to come in fix my nonsense for me?Matt: [laugh]. That's it. L4 could be Pulumi recently announced that you can use AWS CDK constructs inside it. But I think it's one of those things where the constructs, if they can move across these different tools the way AWS CDK constructs now work inside Pulumi, and there's a beta version that works inside CDK for Terraform, then it may or may not make sense for people to contribute to this stuff because we're not building at a higher level. It's just the vision is hard for most people to get clear in their head because it needs articulated and told as a clear strategy.And then, you know, as you said, it is an AWS product strategy, so I'm not sure what you get back by contributing to the project, other than, like, Thorsten—I should say, so Thorsten who wrote the book with me, he is the number three contributor, I think, to the CDK. And that's just because he is such a big user of it that if he sees something that annoys him, he just comes in and tries to fix it. So, the benefit is, he gets to use the tool. But he is a super user, so I'm not sure, outside of super users, what the use case is.Corey: I really want to thank you for, I want to say spending as much time talking to me about this stuff as you have, but that doesn't really go far enough. Because so much of how I think about this invariably winds up linking back to things that you have done and have been advocating for in that community for such a long time. If it's not you personally, just, like, your fingerprints are all over this thing. So, it's one of those areas where the entire software developer ecosystem is really built on the shoulders of others who have done a lot of work that came before. Often you don't get any visibility of who those people are, so it's interesting whenever I get to talk to someone whose work I have directly built upon that I get to say thank you. So, thank you for this. I really do appreciate how much more straightforward a lot of this is than my previous approach of clicking in the console and then lying about it to provision infrastructure.Matt: Oh, no worries. Thank you for the thank you. I mean, at the end of the day, all of this stuff is just—it helps me as much as it helps everybody else, and we're all trying to do make everything quicker for ourselves, at the end of the day.Corey: If people want to learn more about what you're up to, where's the best place to find you these days? They can always take a job at Liberty; I hear good things about it.Matt: Yeah, we're always looking for people at Liberty, so come look up our careers. But Twitter is always the best place. So, I'm @NIDeveloper on Twitter. You should find me pretty quickly, or just type Matt Coulter into Google, you'll get me.Corey: I like it. It's always good when it's like, “Oh, I'm the top Google result for my own name.” On some level, that becomes an interesting thing. Some folks into it super well, John Smith has some challenges, but you know, most people are somewhere in the middle of that.Matt: I didn't used to be number one, but there's a guy called the Kangaroo Kid in Australia, who is, like, a stunt driver, who was number one, and [laugh] I always thought it was funny if people googled and got him and thought it was me. So, it's not anymore.Corey: Thank you again for, I guess, all that you do. And of course, taking the time to suffer my slings and arrows as I continue to revise my opinion of the CDK upward.Matt: No worries. Thank you for having me.Corey: Matt Coulter, senior architect at Liberty Mutual. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice and leave an angry comment as well that will not actually work because it has to be transpiled through a JavaScript engine first.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

This episode originally aired on Software Engineering Radio.Randy Shoup is the VP of Engineering and Chief Architect at eBay. He was previously the VP of Engineering at WeWork and Stitch Fix, a Director of Engineering at Google Cloud where he worked on App Engine, and a Chief Engineer and Distinguished Architect at eBay in 2004. Topics covered: eBay's origins as a single C++ class The five-year migration to Java services Sharing a database between the old and new systems Building a distributed tracing system Working with bare metal Why most companies should stick to cloud Why individual services should own their own data storage How scale has caused solutions to change Rejoining a former company The Accelerate Book Improving delivery time.  Related Links:@randyshoupOpenTelemetryLightStepHoneycombAccelerate BookThe MemoValue Stream MappingThe Epic Story of Dropbox's Exodus from the Amazon Cloud EmpireTranscript:[00:00:00] Jeremy: Today, I'm talking to Randy Shoup, he's the VP of engineering and chief architect at eBay.[00:00:05] Jeremy: He was previously the VP of engineering at WeWork and stitch fix, and he was also a chief engineer and distinguished architect at eBay back in 2004. Randy, welcome back to software engineering radio. This will be your fifth appearance on the show. I'm pretty sure that's a record.[00:00:22] Randy: Thanks, Jeremy, I'm really excited to come back. I always enjoy listening to, and then also contributing to software engineering radio.Back at, Qcon 2007, you spoke with Markus Volter he's he was the founder of SE radio. And you were talking about developing eBay's new search engine at the time.[00:00:42] Jeremy: And kind of looking back, I wonder if you could talk a little bit about how eBay was structured back then, maybe organizationally, and then we can talk a little bit about the, the tech stack and that sort of thing.[00:00:53] Randy: Oh, sure. Okay. Yeah. Um, so eBay started in 1995. I just want to like, you know, orient everybody. Same, same as the web. Same as Amazon, same as a bunch of stuff. So E-bay was actually almost 10 years old when I joined. That seemingly very old first time. Um, so yeah. What was ebay's tech stack like then? So E-bay current has gone through five generations of its infrastructure.It was transitioning between the second and the third when I joined in 2004. Um, so the. Iteration was Pierre Omidyar, the founder three-day weekend three-day labor day weekend in 1995, playing around with this new cool thing called the web. He wasn't intending to build a business. He just was playing around with auctions and wanted to put up a webpage.So he had a Perl backend and every item was a file and it lived on this little 486 tower or whatever you had at the time. Um, so that wasn't scalable and wasn't meant to be. The second generation of eBay's architecture was what we called V2 very, you know, creatively, uh, that was a C++ monolith. Um, an ISAPI DLL with essentially well at its worst, which grew to 3.4 million lines of code in that single DLL and basically in a single class, not just in a single, like repo or a single file, but in a single class.So that was very unpleasant to work in. As you can imagine, um, eBay had about a thousand engineers at the time and they were, you know, as you can imagine, like really stepping on each other's toes and not being able to make much forward progress. So starting in, I want to call it 2002. So two years before I joined, um, they were migrating to the creatively named V3 and V3 architecture was Java, and.you know, not microservices, but like we didn't even have that term, but it wasn't even that it was mini applications. So I'm actually going to take a step back. V2 was a monolith. So like all of eBay's code in that single DLL and like that was buying and selling and search and everything. And then we had two monster databases, a primary and a backup big Oracle machines on some hardware that was bigger, you know, bigger than refrigerators and that ran eBay for a bunch of years, before we changed the upper part of the stack, we, um, chopped up the, that single monolithic database into a bunch of, um, domain specific databases or entity specific databases, right?So a set of databases around users, you know, sharded by the user ID could talk about all that. If you want, you know, items again, sharded by item ID transactions, sharded by transaction ID... I think when I joined, it was the several hundred instances of, uh, Oracle databases, um, you know, spread around, but still that monolithic front end.And then in 2002, I wanna say we started migrating into that V3 that I was saying, okay. So that's, uh, that was a rewrite in Java, again, many applications. So you take the front end and instead of having it be in one big unit, it was this, uh, ER file, EAR, file, if run and people remember back to, you know, those stays in Java, um, you know, 220 different of those.So like here is the, you know, one of them for the search pages, you know, so the, you know, one application be the search application and it would, you know, do all the search related stuff, the handful of pages around search, uh, ditto for, you know, the buying area, ditto for the, you know, checkout area, ditto for the selling area...220 of those. Um, and that was again, domain, um, vertically sliced domains. And then the relationship between those V3, uh, applications and the databases was a many to many things. So like many applicants, many of those applications interact with items. So they would interact with those item databases. Many of them would interact with users.And so they would interact with a user databases, et cetera, uh, happy to go into as much gory detail as you want about all that. But like, that's what, uh, but we were in the transition period. You know, when I, uh, between the V2 monolith to the V3 mini applications in, uh, 2004, I'm just going to pause there and like, let me know where you want to take it.[00:05:01] Jeremy: Yeah. So you were saying that it was, um, it started as Perl, then it became a C++, and that's kind of interesting that you said it was all in one class, right? So it's wow. That's gotta be a gigantic [00:05:16] Randy: I mean, completely brutal. Yeah. 3.4 million lines of code. Yeah. We were hitting compiler limits on the number of methods per class.[00:05:22] Jeremy: Oh my gosh.[00:05:23] Randy: I'm, uh, uh, scared that I have that. I happen to know that at least at the time, uh, Microsoft allowed you 16 K uh, methods per class, and we were hitting that limit.So, uh, not great.[00:05:36] Jeremy: So it's just kind of interesting to think about how do you walk through that code, right? You have, I guess you just have this giant file.[00:05:45] Randy: Yeah. I mean, there were, you know, different methods. Um, but yeah, it was a big man. I mean, it was a monolith, it was, uh, you know, it was a spaghetti mess. Um, and you know, as you can imagine, Amazon went through a really similar thing by the way. So this wasn't soup. I mean, it was bad, but like we weren't the only people that were making that, making that a mistake.Um, and just like Amazon, where they were, uh, they did like one update a quarter (laughs) , you know, at that period, like 2000, uh, we were doing something really similar, like very, very slow. Um, you know, updates and, uh, when we moved to V3, you know, the idea was to get to do changes much faster. And we were very proud of ourselves starting in 2004 that we, uh, upgraded the whole site every two weeks.And we didn't have to do the whole site, but like each of those individual applications that I was mentioning, right. Those 220 applications, each of those would roll out on this biweekly cadence. Um, and they had interdependencies. And so we rolled them out in this dependency order in any way, lots of, lots of complexity associated with that.Um, yeah, there you go.[00:06:51] Jeremy: the V3 that, that was written in Java, I'm assuming this was a, as a complete rewrite. You, you didn't use the C++ code at all.[00:07:00] Randy: Yeah. And, uh, it was, um, we migrated, uh, page by page. So, uh, you know, in the transition period, which lasted probably five years, um, there were pages, you know, in the beginning, all pages were served by V2. In the end, all pages are served by V3 and, you know, over time you iterate and you like rewrite in parallel, you know, rewrite and maintain in parallel the V3 version of XYZ page and the V2 version of XYZ page.Um, and then when you're ready, you start to test out at low percentages of traffic, you know, what would, what does V3 look like? Is it correct? And when it isn't do you go and fix it, but then ultimately you migrate the traffic over, um, to fully take, get fully be in the V3 world, and then you, you know, remove or comment out or whatever.The, the code that supported that in the V2 monolith.[00:07:54] Jeremy: And then you had mentioned using Oracle databases. Did you have a set for V2 and a separate V3 and you were kind of trying to keep them in sync?[00:08:02] Randy: Oh, great question. Thank you for asking that question. No, uh, no. We had the databases. Um, so again, as I mentioned, we had pre-demonolith that's my that's a technical term, uh, pre broken up the databases starting in, let's call it 2000. Uh, actually I'm almost certain that's 2000. Cause we had a major site outage in 1999, which everybody still remembers who was there at the time.Uh wasn't me or I wasn't there at the time. Uh, but you know, you can look it up. Uh, anyway, so yeah, starting in 2000, we broke up that monolithic database into what I was telling you before those entity aligned databases. Again, one set for items, one set for users, one set for transactions, you know, dot dot, dot, um, and that division of those databases was shared.You know, those databases were shared between. The three using those things and then V sorry, V2 using those things and V3 using those things. Um, and then, you know, so we've completely decoupled the rewrite of the database, you know, kind of data storage layer from the rewrite of the application layer, if that makes sense.[00:09:09] Jeremy: Yeah. So, so you had V2 that was connecting to these individual Oracle databases. You said like they were for different types of entities, like maybe for items and users and things like that. but it was a shared database situation where V2 was connected to the same database as V3. Is that right?[00:09:28] Randy: Correct and also in V3, even when done. Different V3 applications, were also connecting to the same database, again, like anybody who used user, anybody who used the user entity, which is a lot we're connecting to the user suite of databases and anybody who used the item entity, which again is a lot, um, you were connecting to the item databases, et cetera.So yeah, it was this many to many that's, I'm trying to say many to many relationship between applications in the V3 world and databases.[00:10:00] Jeremy: Okay. Yeah, I think I, I got it because[00:10:03] Randy: It's easier with a diagram.[00:10:04] Jeremy: yeah. W 'cause when you, when you think about services now, um, you think of services having dependencies on other services. Whereas in this case you would have multiple services that rather than talking to a different service, they would all just talk to the same database.They all needed users. So they all needed to connect to the user's database.[00:10:24] Randy: Right exactly. And so, uh, I don't want to jump ahead in this conversation, but like the problems that everybody has, everybody who's feeling uncomfortable at the moment. You're right. To feel uncomfortable because that wasn't unpleasant situation and microservices, or more generally the idea that individual services would own their own data.And only in the only are interactions to the service would be through the service interface and not like behind the services back to the, to the data storage layer. Um, that's better. And Amazon discovered that, you know, uh, lots of people discovered that around that same, around that same early two thousands period.And so yeah, we had that situation at eBay at the time. Uh, it was better than it was before. Right, right. Better than a monolithic database and a monolithic application layer, but it definitely also had issues. Uh, as you can imagine,[00:11:14] Jeremy: you know, thinking about back to that time where you were saying it's better than a monolith, um, what were sort of the trade-offs of, you know, you have a monolith connecting to all these databases versus you having all these applications, connecting to all these databases, like what were the things that you gained and what did you lose if that made sense?[00:11:36] Randy: Hmm. Yeah. Well, I mean, why we did it in the first place is develop is like isolation between development teams right? So we were looking for developer productivity or the phrase we used to use was feature velocity, you know, so how quickly would we be able to move? And to the extent that we could move independently, you know, the search team could move independently from the buying team, which could move independently from the selling team, et cetera.Um, that was what we were gaining. Um, what were we losing? Uh, you know, when you're in a monolith situation, If there's an issue, you know, where it is, it's in the monolith. You might not know where in the monolith. Um, but like there's only one place that could be. And so an issue that one has, uh, when you break things up into smaller units, uh, especially when they have this, you know, shared, shared mutable state, essentially in the form of these databases, like who changed that column?What, you know, what's the deal. Uh, actually we did have a solution for that or something that really helped us, which was, um, now 20, more than 20 years ago, we had something that we would now call distributed tracing where, uh, actually I talked about this way back in the 2007 thing, cause it was pretty cool, uh, at the time, uh, You know, just like the spans one would create using a modern distributed tracing, you know, open telemetry or, you know, any of the disruptive tracing vendors.Um, just like you would do that. We, we didn't use the term span, but that same idea where, um, we could, and the goal was the same to like debug stuff. So, uh, every time we were about to make a database call, we would say, Hey, I'm about to make this data, you know, we would log we about to make this database call and then it would happen.And then we would log whether it was successful or not successful. We could see how long it took, et cetera. Um, and so we built our own, you know, monitoring system, which, which we called central application logging or CAL, uh, totally proprietary to eBay. I'm happy to talk about whatever gory details you want to know about that, but it was pretty cool certainly way back in 2000.It was, and that was our mitigation against the thing I'm telling you, which is, you know, when something, when not. Something is weird in the database. We can kind of back up and figure out where it might've happened, or things are slow. What's, you know, what's the deal. And, uh, you know, cause sometimes the database is slow for reasons.Um, and what, which, what thing is, you know, from an application perspective, I'm talking to 20 different databases, but things are slow. Like what is it? And, um, CAL helped us to, to figure out both elements of that, right? Like what applications are talking to, what databases and what backend services and like debug and diagnose from that perspective.And then for a given application, what, you know, databases in backend services are you talking to? And, um, debug that. And then we have the whole, and then we, um, we, we had monitors on those things and we would notice when databases would, where be a lot of errors or where, when database is starting in slower than they used to be.Um, and then. We implemented what people would now call circuit breakers, where we would notice that, oh, you know, everybody who's trying to talk to database 1, 2, 3, 4 is seeing it slow down. I guess 1, 2, 3, 4 is unhappy. So now flip everybody to say, don't talk to 1, 2, 3, 4, and like, just that kind of stuff.You're not going to be able to serve. Uh, but whatever, that's better than stopping everything. So I hope that makes sense. Like, you know, so all these, all these like modern resilience techniques, um, we always had, we had our own proprietary names for them, but you know, we, we implemented a lot of them way back when,[00:15:22] Jeremy: Yeah. And, and I guess just to contextualize it for the audience, I mean, this was back in 2004. Oh it back in 2000.[00:15:32] Randy: Again, because we had this, sorry to interrupt you because we have, the problem is that we were just talking about where application many applications are talking to many services and databases and we didn't know what was going on. And so we needed some visibility into what was going on.Sorry, go ahead.[00:15:48] Jeremy: yeah. Okay. So all the way back in 2000, there's a lot less, Services out there, like nowadays you think about so many software as a service products. if you were building the same thing today, what are some of the services that people today would just go and say like, oh, I'll just, I'll just pay for this and have this company handle it for me. You know, that wasn't available, then[00:16:10] Randy: sure. Well, there. No, essentially, no. Well, there was no cloud cloud didn't happen until 2006. Um, and there were a few software as a service vendors like Salesforce existed at the time, but they weren't usable in the way you're thinking of where I could give you money and you would operate a technical or technological software service on my behalf.Do you know what I mean? So we didn't have any of the monitoring vendors. We didn't have any of the stuff today. So yeah. So what would we do, you know, to solve that specific problem today? Uh, I would, as we do today, I would, uh, instrument everything with open telemetry because that's generic. Thank you, Ben Siegelman and LightStep for starting that whole open sourcing process, uh, of that thing and, and, um, getting all the vendors to, you know, respect it.Um, and then I would shoot, you know, for my backend, I would choose one of the very many wonderful, uh, you know, uh, distributed tracing vendors of which there are so many, I can't remember, but like LightStep is one honeycomb... you know, there were a bunch of, uh, you know, backend, um, distributed tracing vendors in particular, you know, for that.Uh, what else do you have today? I mean, we could go on for hours on this one, but like, we didn't have distributed logging or we didn't have like logging vendors, you know? So there was no, uh, there was no Splunk, there was no, um, you know, any, any of those, uh, any of the many, uh, distributed log, uh, or centralized logging vendor, uh, vendors.So we didn't have any of those things. We didn't. like caveman, you know, we rent, we, uh, you know, had our own data. We built our own data centers. We racked our own servers. We installed all the OSS in them, you know, uh, by the way, we still do all that because it's way cheaper for us at our scale to do that.But happy to talk about that too. Uh, anyway, but yeah, no, the people who live in, I don't know if this is where you want to go in 2022, the software developer has this massive menu of options. You know, if you only have a credit card, uh, and it doesn't usually cost that much, you can get a lot of stuff done from the cloud vendors, from the software service vendors, et cetera, et cetera.And none of that existed in 2000.[00:18:31] Jeremy: it's really interesting to think about how different, I guess the development world is now. Like, cause you mentioned how cloud wasn't even really a thing until 2006, all these, these vendors that people take for granted. Um, none of them existed. And so it just, uh, it must've been a very, very different time.[00:18:52] Randy: Well, we didn't know. It was every, every year is better than the previous year, you know, in software every year. You know? So at that time we were really excited that we had all the tools and capabilities that, that we did have. Uh, and also, you know, you look back from, you know, 20 years in the future and, uh, you know, it looks caveman, you know, from that perspective.But, uh, it was, you know, all those things were cutting edge at the time. What happened really was the big companies rolled their own, right. Everybody, you know, everybody built their own data centers, rack their own servers. Um, so at least at scale and the best you could hope for the most you could pay anybody else to do is rack your servers for you.You know what I mean? Like there were external people, you know, and they still exist. A lot of them, you know, the Rackspaces you know Equinixes, et cetera of the world. Like they would. Have a co-location facility. Uh, and you, you know, you ask them please, you know, I'd like to buy the, these specific machines and please rack these specific machines for me and connect them up on the network in this particular way.Um, that was the thing you could pay for. Um, but you pretty much couldn't pay them to put software on there for you. That was your job. Um, and then operating. It was also your job, if that makes sense.[00:20:06] Jeremy: and then back then, would that be where. Employees would actually have to go to the data center and then, you know, put in their, their windows CD or their Linux CD and, you know, actually do everything right there.[00:20:18] Randy: Yeah. 100%. Yeah. In fact, um, again, anybody who operates data centers, I mean, there's more automation, but the conceptually, when we run three data centers ourselves at eBay right now, um, and all of our, all of our software runs on them. So like we have physical, we have those physical data centers. We have employees that, uh, physically work in those things, physical.Rack and stack the servers again, we're smarter about it now. Like we buy a whole rack, we roll the whole rack in and cable it, you know, with one big chunk, uh, sound, uh, as distinct from, you know, individual wiring and the networks are different and better. So there's a lot less like individual stuff, but you know, at the end of the day, but yeah, everybody in quotes, everybody at that time was doing that or paying somebody to do exactly that.Right. Yeah.[00:21:05] Jeremy: Yeah. And it's, it's interesting too, that you mentioned that it's still being done by eBay. You said you have three, three data centers. because it seems like now maybe it's just assumed that someone's using a cloud service or using AWS or whatnot. And so, oh, go ahead.[00:21:23] Randy: I was just going to say, well, I'm just going to riff off what you said, how the world has changed. I mean, so much, right? So. Uh, it's fine. You didn't need to say my whole LinkedIn, but like I used to work on Google cloud. So I've been, uh, I've been a cloud vendor, uh, at a bunch of previous companies I've been a cloud consumer, uh, at stitch fix and we work in other places.Um, so I'm fully aware, you know, fully, fully, personally aware of, of all that stuff. But yeah, I mean, there's this, um, you know, eBay is in the, uh, eBay is at the size where it is actually. Cost-effective very, cost-effective, uh, can't tell you more than that, uh, for us to operate our own, um, uh, our own infrastructure, right?So, you know, you know, one would expect if Google didn't operate their own infrastructure, nobody would expect Google to use somebody else's right. Like that, that doesn't make any economic sense. Um, and, uh, you know, Facebook is in the same category. Uh, for a while, Twitter and PayPal have been in that category.So there's like this clap, you know, there are the known hyperscalers, right. You know, the, the Google, Amazon, uh, Microsoft that are like cloud vendors in addition to consumers internally have their own, their own clouds. Um, and then there's a whole class of other, um, places that operate their own internal clouds in quotes.Uh, but don't offer them externally and again, uh, Facebook or Meta, uh, you know, is one example. eBay's another, you know, there's a, I'm making this up. Dropbox actually famously started in the cloud and then found it was much cheaper for them to operate their own infrastructure again, for the particular workloads that they had.Um, so yeah, there's probably, I'm making this up. Let's call it two dozen around the world of these, I'm making this term up many hyperscalers, right? Like self hyperscalers or something like that. And eBay's in that category.[00:23:11] Jeremy: I know this is kind of a, you know, a big what if, but you were saying how once you reach a certain scale, that's when it makes sense to move into your own data center. And, uh, I'm wondering if, if E-bay, had started more recently, like, let's say in the last, you know, 10 years, I wonder if it would've made sense for it to start on a public cloud and then move to, um, you know, its own infrastructure after it got bigger, or if you know, it really did make sense to just start with your own infrastructure from the start.[00:23:44] Randy: Oh, I'm so glad you asked that. Um, the, the answer is obvious, but like, I'm so glad you asked that because I love to make this point. No one should ever, ever start by building your own servers and your own (laughs) cloud. Like, No, there's be, uh, you should be so lucky (laughs) after years and years and years that you outgrow the cloud vendors.Right. Um, it happens, but it doesn't happen that often, you know, it happens so rarely that people write articles about it when it happens. Do you know what I mean? Like Dropbox is a good example. So yes, 100% anytime. Where are we? 2022. Any time in, more than the last 10 years? Um, yeah, let's call it. Let's call it 2010, 2012.Right. Um, when cloud had proved itself over and you know, many times over, um, anybody who starts since that time should absolutely start in the public cloud. There's no argument about it. Uh, and again, one should be so lucky that over time, you're seeing successive zeros added to your cloud bill, and it becomes so many zeros that it makes sense to shift your focus toward building and operating your own data centers.That's it. I haven't been part of that transition. I've been the other way, you know, at other places where, you know, I've migrated from owned data centers and colos into, into public cloud. Um, and that's the, that's the more common migration. And again, there are, there are a handful, maybe not even a handful of, uh, companies that have migrated away, but when they do, they've done all the math, right.I mean, uh, Dropbox has done some great, uh, talks and articles about, about their transition and boy, the math makes sense for them. So, yeah.[00:25:30] Jeremy: Yeah. And it also seems like maybe it's for certain types of businesses where moving off of public cloud. Makes sense. Like you mentioned Dropbox where so much of their business is probably centered around storage or centered around, you know, bandwidth and, you know, there's probably certain workloads that it's like need to leave public cloud earlier.[00:25:51] Randy: Um, yeah, I think that's fair. Um, I think that, I think that's a, I think that's an insightful comment. Again, it's all about the economics at some point, you know, it's a big investment to, uh, uh, and it takes years to develop the intern, forget the money that you're paying people, but like just to develop the internal capabilities.So they're very specialized skill sets around building an operating data centers. So like it's a big deal. Um, and, uh, yeah. So are there particular classes of workloads where you would for the same dollar figure or whatever, uh, migrate earlier or later? I'm sure that's probably true. And again, what can absolutely imagine?Well, when they say Dropbox in this example, um, yeah, it's because like they, they need to go direct to the storage. And then, I mean, like, they want to remove every middle person, you know, from the flow of the bytes that are coming into the storage media. Um, and it makes perfect sense for, for them. And when I understood what they were doing, which was a number of years ago, they were hybrid, right. So they had, they had completely, you know, they kept the top, you know, external layer, uh, in public cloud. And then the, the storage layer was all custom. I don't know what they do today, but people could check.[00:27:07] Jeremy: And I'm kind of coming back to your, your first time at eBay. is there anything you felt that you would've done differently with the knowledge you have now?but with the technology that existed, then.[00:27:25] Randy: Gosh, that's the 20, 20 hindsight. Um, the one that comes to mind is the one we touched on a little bit, but I'll say it more starkly, the. If I could, if I could go back in time 20 years and say, Hey, we're about to do this V3 transition at eBay. I would not. I would have had us move directly to what we would now call microservices in the sense that individual services own their own data storage and are only interacted with through the public interface.Um, there's a famous Amazon memo around that same time. So Amazon did the transition from a monolith into what we would now call microservices over about a four or five-year period, 2000 to 2005. And there was a famous Jeff Bezos memo from the early part of that, where, you know, seven, you know, requirements I can't remember them, but you know, essentially it was, you may, you may, you may never, you may never talk to anybody else's database. You may only interact with other services through their public interfaces. I don't care what those public interfaces are, so they didn't standardize around. You know, CORBA or JSON or GRPC, which didn't exist at the time, you know, like they didn't standardize around any, any particular, uh, interaction mechanism, but you did need to again, have this kind of microservice capability, that's modern terminology, um, uh, where, you know, the only services own their own data and nobody can talk in the back door.So that is the one architectural thing that I wish, you know, with 2020 hindsight, uh, that I would bring back in my time travel to 20 years ago, because that would help. That does help a lot. And to be fair, Amazon, um, Amazon was, um, pioneering in that approach and a lot of people internally and externally from Amazon, I'm told, didn't think it would work, uh, and it, and it did famously.So that's, that's the thing I would do.[00:29:30] Jeremy: Yeah. I'm glad you brought that up because, when you had mentioned that, I think you said there were 220 applications or something like that at certain scales, people might think like, oh, that sounds like microservices to me. But when you, you mentioned that microservice to you means it having its own data store.I think that's a good distinction.[00:29:52] Randy: Yeah. So, um, I talk a lot about microservices that have for, for a decade or so. Yeah. I mean, several of the distinguishing characteristics are the micro in microservices is size and scope of the interface, right? So you can have a service oriented architecture with one big service, um, or some very small number of very large services.But the micro in microservice means this thing does, maybe it doesn't have one operation, but it doesn't have a thousand. The several or the handful or several handfuls of operations are all about this one particular thing. So that's the one part of it. And then the other part of it that is critical to the success of that is owning the, owning your own data storage.Um, so each service, you know, again, uh, it's hard to do this with a diagram, but like imagine, imagine the bubble of the service surrounding the data storage, right? So like people, anybody from the outside, whether they're interacting synchronously, asynchronously, messaging, synchronous, whatever HTTP doesn't matter are only interacting to the bubble and never getting inside where the, uh, where the data is I hope that makes sense.[00:31:04] Jeremy: Yeah. I mean, I mean, it's a kind of in direct contrast to before you're talking about how you had all these databases that all of these services shared. So it was probably hard to kind of keep track of, um, who had modified data. Um, you know, one service could modify it, then another service control to get data out and it's been changed, but it didn't change it.So it could be kind of hard to track what's going on.[00:31:28] Randy: Yeah, exactly. Inner integration at the database level is something that people have been doing since probably the 1980s. Um, and so again, I, you know, in retrospect it looks like caveman approach. Uh, it was pretty advanced at the time, actually, even the idea of sharding of, you know, Hey, there are users and the users live in databases, but they don't all live in the same one.Uh, they live in 10 different databases or 20 different databases. And then there's this layer that. For this particular user, it figures out which of the 20 databases it's in and finds it and gets it back. And, um, you know, that was all pretty advanced. And by the way, that's all those capabilities still exist.They're just hidden from everybody behind, you know, nice, simple, uh, software as a service, uh, interfaces anyway, but that takes nothing away from your excellent point, which is, yeah. It's, you know, when you're, again, when there's many to many to relations, when there is this many to many relationship between, um, uh, applications and databases, uh, and there's shared mutable state in those databases that when is shared, like that's bad, you know, it's not bad to have state.It's not bad to have mutable state it's bad to have shared beautiful state.[00:32:41] Jeremy: Yeah. And I think anybody who's kind of interested in learning more about the, you had talked about sharding and things like that. If they go back and listen to your, your first appearance on software engineering radio, um, yeah. It kind of struck me how you were talking about sharding and how it was something that was kind of unique or unusual.Whereas today it feels like it's very, I don't know, if quaint is the right word, but it's like, um, it's something that, that people kind of are accustomed to now.[00:33:09] Randy: Yeah. Yeah. Um, it's obvious. Um, it seems obvious in retrospect. Yeah. You know, at the time, and by the way, he didn't invent charting. As I said, in 2007, you know, Google and Yahoo and, uh, Amazon, and, you know, it was the obvious, it took a while to reach it, but it's one of those things where once, once people have the, you know, brainwave to see, oh, you know what, we don't actually have to stop store this in one, uh, database.We can, we can chop that database up into, you know, into chunks. And that, that looks similar to that herself similar. Um, yeah, that was, uh, that was, uh, that was reinvented by lots of, uh, Lots of the big companies at the same time again, because everybody was solving that same problem at the same time. Um, but yeah, when you look back and you, I mean, like, and honestly, like everything that I said there, it's still like this, all the techniques about how you shard things.And there's lots of, you know, it's not interesting anymore because the problems have been solved, but all those solutions are still the solutions, if that makes any sense, but you know,[00:34:09] Jeremy: Yeah, for sure. I mean, I think anybody who goes back and listens to it. Yeah. Like you said, it's, it's, it's very interesting because it's. it all still applies and it's like, I think the, the solutions that are kind of interesting to me are ones where it's, it's things that could have been implemented long ago, but we just later on realized like, this is how we could do it.[00:34:31] Randy: Well part of it is, as we grow as an industry, we just, we discover new problems. You know, we, we get to the point where, you know, sharding over databases has only a problem when one database doesn't work. You know, when it, when you're the load that you put on that database is too big, or you want the availability of, you know, multiple.Um, and so that's not a, that's not a day one problem, right? That's a day two or day 2000 and kind of problem. Right. Um, and so a lot of these things, yeah, well, you know, it's software. So like we could have done, we could have done any of these things in older languages and older operating systems and with older technology.But for the most part, we didn't have those problems or we didn't have them at sufficiently enough. People didn't have the problem that we, you know, um, for us to have solved it as an industry, if that makes any sense.[00:35:30] Jeremy: yeah, no, that's a good point because you think about when Amazon first started and it was just a bookstore, right. And the number of people using the site where, uh, who knows it was, it might've been tens a day or hundreds a day. I don't, I don't know. And, and so, like you said, the problems that Amazon has now in terms of scale are just like, it's a completely different world than when they started.[00:35:52] Randy: Yeah. I mean, probably I'm making it up, but I don't think that's too off to say that it's a billion times more, their problems are a billion fold. You know, what they, what they were[00:36:05] Jeremy: the next thing I'd like to talk about is you came back to eBay I think about has it been about two years ago.[00:36:14] Randy: Two years yeah.[00:36:15] Jeremy: Yeah. And, and so, so tell me about the experience of coming back to an organization that you had been at, you know, 10 years prior or however long it was like, how is your onboarding different when it's somewhere you've been before?[00:36:31] Randy: Yeah. Sure. So, um, like, like you said, I worked at eBay from 2004 to 2011. Um, and I worked in a different role than I have today. I've worked mostly on eBay search engine. Um, and then, uh, I left to co-found a startup, which was in the 99%. So the one, you know, like didn't really do much. Uh, I joined, I worked at Google in the early days of Google cloud, as I mentioned on Google app engine and had a bunch of other roles including more recently, like you said, stitch fix and we work, um, leading those engineering teams.And, um, so yeah, coming back to eBay as chief architect and, and, you know, leading. Developer platform, essentially a part of eBay. Um, yeah. What was the onboarding like? I mean, lots of things had changed, you know, in the, in the intervening 10 years or so. Uh, and lots had stayed the same, you know, not in a bad way, but just, you know, uh, some of the technologies that we use today are still some of the technologies we used 10 years ago, a lot has changed though.Um, a bunch of the people are still around. So there's something about eBay that, um, people tend to stay a long time. You know, it's not really very strange for people to be at eBay for 20 years. Um, in my particular team of let's call it 150, there are four or five people that have crossed their 20 year anniversary at the company.Um, and I also re I rejoined with a bunch of other boomerangs as the term we use internally. So it's, you know, the, um, including the CEO, by the way. So sort of bringing the band back together, a bunch of people that had gone off and worked at it, but at other places have, have come back for various reasons over the last couple of.So it was both a lot of familiarity, a lot of unfamiliarity, a lot of familiar faces. Um, yup.[00:38:17] Jeremy: So, I mean, having these people who you work with still be there and actually coming back with some of those people, um, what were some of the big, I guess, advantages or benefits you got from, you know, those existing connections?[00:38:33] Randy: Yeah. Well, I mean, as with all things, you know, imagine, I mean, everybody can imagine like getting back together with friends that they had from high school or university, or like you had some people had some schooling at some point and like you get back together with those friends and there's this, you know, there's this implicit trust in most situations of, you know, because you went through a bunch of stuff together and you knew each other, uh, you know, a long time.And so that definitely helps, you know, when you're returning to a place where again, there are a lot of familiar faces where there's a lot of trust built up. Um, and then it's also helpful, you know, eBay's a pretty complicated place and it's 10 years ago, it was too big to hold in any one person's head and it's even harder to hold it in one person said now, but to be able to come back and have a little bit of that, well, more than a little bit of that context about, okay, here's how eBay works.And here, you know, here are the, you know, unique complexities of the marketplace cause it's very unique, you know, um, uh, in the world. Um, and so, yeah, no, I mean, it was helpful. It's helpful a lot. And then also, you know, in my current role, um, uh, my, my main goal actually is to just make all of eBay better, you know, so we have about 4,000 engineers and, you know, my team's job is to make all of them better and more productive and more successful and, uh, being able to combine.Knowing what eBay, knowing the context about eBay and having a bunch of connections to the people that, you know, a bunch of the leaders there, uh, here, um, combining that with 10 years of experience doing other things at other places, you know, that's helpful because you know, now there are things that we do at eBay that, okay, well there, you know, you know, that this other place is doing, this has that same problem and is solving it in a different way.And so maybe we should, you know, look into that option. So,[00:40:19] Jeremy: so, so you mentioned just trying to make developers, work or lives easier. you start the job. How do you decide what to tackle first? Like how do you figure out where the problems are or what to do next?[00:40:32] Randy: yeah, that's a great question. Um, so, uh, again, my, uh, I lead this thing that we internally called the velocity initiative, which is about just making us, giving us the ability to deliver. Features and bug fixes more quickly to customers. Right. And, um, so what do I figure for that problem? How can we deliver things more quickly to customers and improve, you know, get more customer value and business value?Uh, what I did, uh, with, in collaboration with a bunch of people is what one would call a value stream map. And that's a term from lean software and lean manufacturing, where you just look end to end at a process and like say all the steps and how long those steps take. So a value stream, as you can imagine, like all these steps that are happening at the end, there's some value, right?Like we produced some, you know, feature or, you know, hopefully gotten some revenue or like helped out the customer and the business in some way. And so value, you know, mapping that value stream. That's what it means. And, um, Looking for you look at that. And when you can see the end-to-end process, you know, and like really see it in some kind of diagram, uh, you can look for opportunities like, oh, okay, well, you know, if it takes us, I'm making this effort, it takes us a week from when we have an idea to when it shows up on the site.Well, you know, some of those steps take five minutes. That's not worth optimizing, but some of those steps take, you know, five days and that is worth optimizing. And so, um, getting some visibility into the system, you know, looking end to end with some, with a kind of view of the system systems thinking, uh, that will give you the, uh, the knowledge about, or the opportunities about we know what can be improved.And so that's, that's what we did. And we didn't talk with all 4,000, you know, uh, engineers are all, you know, whatever, half a thousand teams or whatever we had. Um, but we sampled. And after we talked with three teams who were already hearing a bunch of the same things, you know, so we were hearing in the whole product life cycle, which I like to divide into four stages.I'd like to say, there's planning. How does an idea become a project or a thing that people work on a software development? How does a project or become committed code software delivery? How does committed code become a feature that people actually use? And then what I call post release iteration, which is okay, it's now there are out there on the site and we're turning it on and off for individual users.We're learning in analytics and usage in the real world and, and experimenting. And so there were opportunities that eBay at all, four of those stages, um, which I'm happy to talk about, but what we ended up seeing again and again, uh, is that that software delivery part was our current bottleneck. So again, that's the, how long does it take from an engineer when she commits her code to, it shows up as a feature on the site.And, you know, before we started the work. You know, two years ago before we started the work that I've been doing for the last two years with a bunch of people, um, on average and eBay was like a week and a half. So, you know, it'd be a week and a half between when someone's finished and then, okay. It gets code reviewed and, you know, dot, dot, dot it gets rolled out.It gets tested, you know, all that stuff. Um, it was, you know, essentially 10 days. And now for the teams that we've been working with, uh, it's down to two. So we used a lot of, um, what people may be familiar with, uh, the accelerate book. So it's called accelerate by Nicole Forsgren. Um, Jez humble and Gene Kim, uh, 2018, like if there's one book anybody should read about software engineering, it's that?Uh, so please read accelerate. Um, it summarizes almost a decade of research from the state of DevOps reports, um, which the three people that I mentioned led. So Nicole Forsgren, you know, is, uh, is a doctor, uh, you know, she's a PhD and, uh, data science. She knows how to do all this stuff. Um, anyway, so, uh, that when your, when your problem happens to be software delivery.The accelerate book tells you all the kind of continuous delivery techniques, trunk based development, uh, all sorts of stuff that you can do to, to solve that, uh, solve those problems. And then there are also four metrics that they use to measure the effectiveness of an organization, software delivery. So people might be familiar with, uh, there's deployment frequency.How often are we deploying a particular application lead time for change? That's that time from when a developer commits her code to when it shows up on the site, uh, change failure rate, which is when we deploy code, how often do we roll it back or hot fix it, or, you know, there's some problem that we need to, you know, address.Um, and then, uh, meantime to re uh, meantime to restore, which is when we have one of those incidents or problems, how, how quickly can we, uh, roll it back or do that hot fix? Um, and again, the beauty of Nicole Forsgren research summarized in the accelerate book is that the science shows that companies cluster, in other words, Mostly the organizations that are not good at, you know, deployment frequency and lead time are also not good at the quality metrics of, uh, meantime to restore and change failure rate and the companies that are excellent at, you know, uh, deployment frequency and lead time are also excellent at meantime, to recover and, uh, change failure rate.Um, so companies or organizations, uh, divided into these four categories. So there's a low performers, medium performers, high performers, and then elite performers. And, uh, eBay was solidly eBay on average at the time. And still on average is solidly in that medium performer category. So, uh, and what we've been able to do with the teams that we've been working with is we've been able to move those teams to the high category.So just super brief. Uh, and I w we'll give you a chance to ask you some more questions, but like in the low category, all those things are kind of measured in months, right. So how long, how often are we deploying, you know, measure that in months? How long does it take us to get a commit to the site? You know, measure that in months, you know, um, where, and then the low performer, sorry.Uh, the medium performers are like, everything's measured in weeks, right? So like, if we were deploy, you know, couple, you know, once every couple of weeks or once a week, uh, lead time is measured in weeks, et cetera. The, uh, the high-performers things are measured in days and the elite performance things are measured in hours.And so you can see there's like order of magnitude improvements when you go from, you know, when you move from one of those kind of clusters to another cluster. Anyway. So what we were focused on again, because our problem was software delivery was moving a whole, a whole set of teams from that medium performer category where things are measured in weeks to the, uh, high-performer category, where things are missing.[00:47:21] Jeremy: throughout all this, you said the, the big thing that you focused on was the delivery time. So somebody wrote code and, they felt that it was ready for deployment, but for some reason it took 10 days to actually get out to the actual site. So I wonder if you could talk a little bit about, uh, maybe a specific team or a specific application, where, where, where was that time being spent?You know, you, you said you moved from 10 days to two days. What, what was happening in the meantime?[00:47:49] Randy: Yeah, no, that's a great question. Thank you. Um, yeah, so, uh, okay, so now, so we, we, we looked end to end of the process and we found that software delivery was the first place to focus, and then there are other issues in other areas, but we'll get to them later. Um, so then for, um, to improve software delivery, now we asked individual teams, we, we, we did something like, um, you know, some conversation like I'm about to say, so we said, hi, it looks like you're deploying kind of once or twice.If I, if I told you, you had to deploy once a day, tell me all the reasons why that's not going to work. And the teams are like, oh, of course, well, it's a build times take too long. And the deployments aren't automated and you know, our testing is flaky. So we have to retry it all the time and, you know, dot, dot, dot, dot, dot.And we said, great, you just gave my team, our backlog. Right. So rather than, you know, just coming and like, let's complain about it. Um, which the teams work it's legit for them to complain. Uh, I was a, you know, we were able, because again, the developer program or sorry, the developer platform, you know, is as part of my team, uh, we said, great, like you just gave us, you just told us all the, all your top, uh, issues or your impediments, as we say, um, and we're going to work on them with you.And so every time we had some idea about, well, I bet we can use Canary deployments to automate the deployment which we have now done. We would pilot that with a bunch of teams, we'd learn what works and doesn't work. And then we would roll that out to everybody. Um, So what were the impediments like? It was a little bit different for each individual team, but in some, it was, uh, the things we ended up focusing on or have been focusing on our build times, you know, so we build everything in Java still.Um, and, uh, even though we're generation five, as opposed to that generation three that I mentioned, um, still build times for a lot of applications we're taking way too long. And so we, we spend a bunch of time improving those things and we were able to take stuff from, you know, hours down to, you know, single digit minutes.So that's a huge improvement to developer productivity. Um, we made a lot of investment in our continuous delivery pipelines. Um, so making all the, making all the automation around, you know, deploying something to one environment and checking it there and then deploying it into a common staging environment and checking it there and then deploying it from there into the production environment.And, um, and then, you know, rolling it out via this Canary mechanism. We invested a lot in something that we call traffic mirroring, which is a, we didn't invent. Other T other places have a different name for this? I don't know if there's a standard industry name. Some people call it shadowing, but the idea is I have a change that I'm making, which is not intended to change the behavior.Like a lots of changes that we make, bug fixes, et cetera, uh, upgrading to new, you know, open source, dependencies, whatever, changing the version of the framework. There's a bunch of changes that we make regularly day-to-day as developers, which are like, refactorings kind of where we're not actually intending to change the behavior.And so a tra traffic mirroring was our idea of. You have the old code that's running in production and you, and you fire a request, a production request at that old code and it responds, but then you also fire that request at the new version and compare the results, you know, did the same, Jason come back, you know, between the old version and the new version.Um, and that's, that's a great way kind of from the outside to sort of black box detect any unintended changes in the, in the behavior. And so we definitely leveraged that very, very aggressively. Um, we've invested in a bunch of other bunch of other things, but, but all those investments are driven by what does the team, what do the particular teams tell us are getting in their way?And there are a bunch of things that the teams themselves have, you know, been motivated to do. So my team's not the only one that's making improvements. You know, teams have. Reoriented, uh, moved, moved from branching development to trunk based development, which makes a big difference. Um, making sure that, uh, PR approvals and like, um, you know, code reviews are happening much more regularly.So like right after, you know, a thing that some teams have started doing is like immediately after standup in the morning, everybody does all the code reviews that you know, are waiting. And so things don't drag on for, you know, two, three days, cause whatever. Um, so there's just like a, you know, everybody kind of works on that much more quickly.Um, teams are building their own automations for things like testing site speed and accessibility and all sorts of stuff. So like all the, all the things that, you know, a team goes through in the development and roll out of their software, they were been spending a lot of time automating and making, making a leaner, making more efficient.[00:52:22] Jeremy: So, so some of those, it sounds like the PR example is really, on the team. Like you're, you're telling them like, Hey, this is something that you internally should change how you work. for things like improving the build time and things like that. Did you have like a separate team that was helping these teams, you know, speed that process up? Or what, what was that [00:52:46] Randy: like?Yeah. Great. I mean, and you did give to those two examples are, are like you say, very different. So I'm going to start from, we just simply showed everybody. Here's your deployment frequency for this application? Here's your lead time for this application? Here's your change failure rate. And here's your meantime to restore.And again, as I didn't mention before. All of the state of DevOps research and the accelerate book prove that by improving those metrics, you get better engineering outcomes and you also get better business outcomes. So like it's scientifically proven that improving those four things matters. Okay. So now we've shown to teams, Hey, you're we would like you to improve, you know, for your own good, but you know, more broadly at eBay, we would like the deployment frequency to be faster.And we would like the lead time to be shorter. And the insight there is when we deploy smaller units of work, when we don't like batch up a week's worth of work, a month's worth of work, uh, it's much, much less risky to just deploy like an hour's worth of work. Right. And the, and the insight is the hours worth of work fits in your head.And if you roll it out and there's an issue. First off rolling backs, no big deal. Cause you only, you know, not, you've only lost an hour of work for a temporary period of time, but also like you never have this thing, like what in the world broke? Cause like with a month's worth of work, there's a lot of things that changed and a lot of stuff that could break, but with an hour's worth of work, it's only like one change that you made.So, you know, when, if something happens, like it's pretty much, pretty much guaranteed to be that thing anyway, that's the back. Uh, that's the backstory. And um, and so yeah, we were just working with individual teams. Oh yeah. So they were, the teams were motivated to like, see what's the biggest bang for the buck in order to improve those things.Like how can we improve those things? And again, some teams were saying, well, you know what, a huge component of our, of that lead time between when somebody commits and it's, it's a feature on the site, a huge percentage of that. Maybe multiple days, it's like waiting for somebody to code review. Okay, great.We can just change our team kind of agreements and our team behavior to make that happen. And then yes, to answer your question about. Were the other things like building the Canary capability and traffic mirroring and build time improvements. Those were done by central, uh, platform and infrastructure teams, you know, some of which were in my group and some of which are in peer peer groups, uh, in, in my part of the organization.So, yeah, so I mean like providing the generic tools and, you know, generic capabilities, those are absolutely things that a platform organization does. Like that's our job. Um, and you know, we did it. And, uh, and then there are a bunch of other things like that around kind of team behavior and how you approach building a particular application that are, are, and should be completely in the control of the individual teams.And we were trying not to be, not trying not to be, we were definitely not being super prescriptive. Like we didn't come in and we say, we didn't come in and say, alright, by next, by next Tuesday, we want you to be doing trunk based development by, you know, the Tuesday after that, we want to see test-driven development, you know, dot, dot, Um, we would just offer to teams, you know, hear it.Here's where you are. Here's where we know you can get, because like we work with other teams and we've seen that they can get there. Um, you know, they just work together on, well, what's the biggest bang for the buck and what would be most helpful for that team? So it's like a menu of options and you don't have to take everything off the menu, if that makes sense.[00:56:10] Jeremy: And, and how did that communication flow from you and your team down to the individual contributor? Like you have, I'm assuming you have engineering managers and technical leads and all these people sort of in the chain. How does it[00:56:24] Randy: Yeah, thanks for asking that. Yeah. I didn't really say how we work as an initiative. So every, um, so there are a bunch of teams that are involved. Um, and we have, uh, every Monday morning, so, uh, just so happens. It's late Monday morning today. So we already did this a couple of hours ago, but once a week we get all the teams that are involved, both like the platform kind of provider teams and also the product.Or we would say domain like consumer teams. And we do a quick scrum of scrums, like a big old kind of stand up. What have you all done this week? What are you working on next week? What are you blocked by kind of idea. And, you know, there are probably 20 or 30 teams again, across the individual platform capabilities and across the teams that, you know, uh, consume this stuff and everybody gives a quick update and they, and, uh, it's a great opportunity for people to say, oh, I have that same problem too.Maybe we should offline try to figure out how to solve that together. You built a tool that automates the site speed stuff. That's great. I would S I would so love to have that. And, um, so it, uh, this weekly meeting has been a great opportunity for us to share wins, share, um, you know, help that people need and then get, uh, get teams to help with each other.And also, similarly, one of the platform teams would say something like, Hey, we're about to be done or beta, let's say, you know, this new Canary capability, I'm making this up. Anybody wanna pilot that for us? And then you get a bunch of hands raised of yo, we would be very happy to pilot that that would be great.Um, so that's how we communicate back and forth. And, you know, it's a big enough. It's kind of like engineering managers are kind of are the kind of level that are involved in that typically. Um, so it's not individual developers, but it's like somebody on most, every team, if that makes any sense. So like, that's kind of how we do that, that like communication, uh, back to the individual developers.If that makes sense.[00:58:26] Jeremy: Yeah. So it sounds like you would have, like you said, the engineering manager go to the standup and um, you said maybe 20 to 30 teams, or like, I'm just trying to get a picture for how many people are in this meeting.[00:58:39] Randy: Yeah. It's like 30 or 40 people.[00:58:41] Jeremy: Okay. Yeah.[00:58:42] Randy: And again, it's quick, right? It's an hour. So we just go, boom, boom, boom, boom. And we've just developed a cadence of people. We have a shared Google doc and like people like write their little summaries, you know, of what they're, what they've worked on and what they're working on.So we've over time made it so that it's pretty efficient with people's time. And. Pretty dense in a good way of like information flow, back and forth. Um, and then also separately, we meet more in more detail with the individual teams that are involved. Again, try to elicit, okay, now, where are you now?Here's where you are. Please let us know what problems you're seeing with this part of the infrastructure or problems you're seeing in the pipelines or something like that. And we're, you know, we're constantly trying to learn and get better and, you know, solicit feedback from teams on what we can do differently.[00:59:29] Jeremy: earlier you had talked a little bit about how there were a few services that got brought over from V2 or V3, basically kind of more legacy or older services that are, have been a part of eBay for quite some time.And I was wondering if there were things about those services that made this process different, like, you know, in terms of how often you could deploy or, um, just what were some key differences between something that was made recently versus something that has been with the company for a long time?[01:00:06] Randy: Yeah, sure. I mean, the stuff that's been with the company for a long time was best in class. As of when we built it, you know, maybe 15 and sometimes 20 years ago. Um, there actually, I wouldn't even less than a handful. There are, as we speak, there are two or three of those V3. Uh, clusters or applications or services still around and they should be gone in a completely migrated away from, in the next a couple of months.So like, we're almost at the end of, um, you know, uh, moving all to more modern things. But yeah, you know, I mean, again, uh, stuff that was state-of-the-art, you know, 20 years ago, which was like deploying things once every two weeks, like that was a big deal in 2000 or 2004. Uh, and it's, you know, like that was fast in 2004 and is slow in 2022.So, um, yeah, I mean, what's the difference? Um, yeah, I mean, a lot of these things, you know, if they haven't already been migrated, there's a reason. And it's because often that they're way in the guts of something that's really important. You know, this is the, this is a core part. I'm making these examples up and they're not even right, but like it's a core part of the payments flow.It's a core part of, you know, uh, how, uh, sellers get paid. And those aren't examples. We have, those are modern, but you see what I'm saying? Like stuff that's like really core to the business and that's why it's kind of lasted.[01:01:34] Jeremy: And, uh, I'm kind of curious from the perspective of some of these new things you're introducing, like you're talking about, um, improving continuous delivery and things like that. Uh, when you're working with some of these services that have been around a long time, are the teams the rate at which they deploy or the rate at which you find defects is that noticeably different from services that are more recent?[01:02:04] Randy: I mean, and that's true of any legacy at any, at any place. Right? So, um, yeah, I mean, people are legitimately, uh, I have some trepidation that say about, you know, changing something that's

Gutenberg News Last week there was a bunch of new stuff with Gutenberg 13.8.0. Birgit Pauli-Haack discusses all the new features with Grzegorz Ziolkowski over on the changelog podcast. You can hear about Fluid Typography, updates to Block APIs, and WordPress 6.1 Planning. The Gutenberg Editor is testing On Tumblr and Day One Web Apps. Sarah Gooding over at WPTavern writes about the details of using the betas on Tumblr and Day One. Check that out. WooCommerce WooCommerce 6.8 has been released. Smart Shipping for new sites has been added to this release. You can see all of the recent updates by checking out the WooCommerce site. Events WordCamp Asia sold out of tickets on their first batch of standard and micro sponsor tickets in just 1 day. The second batch of tickets will be available soon. From Our Contributors and Producers The Free Rider topic around WordPress got a lot of discussion going in the WP Minute Slack channel. Joe Casabona published a podcast episode on why free riders are necessary and really not a problem that needs to be solved. If you really want to democratize publishing, then you can't expect everyone to contribute. You have to accept and welcome the free riders. Eventually, they may want to contribute and be part of the open source community. Joe was also interviewed by Brian Coords over on MasterWP. WordCamp US is right around the corner. If you are an introvert that will be attending, you may want to listen to the Matt Report podcast with Ken Elliott. Ken is a self-described “networking introvert” that built a WordPress agency with his co-founder and he will be emceeing WordCamp US next month. WordCamp US is sold out but you will be able to live stream for free. The first beta release of Advanced Custom Fields PRO 6.0. is now available. It has improved performance for Repeater fields with large datasets, and a new generation of ACF Blocks with block JSON support. Go check that out if you are interested.  Marie Comet shared on Twitter a little experiment of bulk converting Classic WordPress posts to Gutenberg posts. You can check out this tool for converting classic posts to blocks and provide feedback. Wordfence has looked at the threats to Ukrainian websites since the invasion of Russia. This cyber-war has been going on since mid-March and this blog post shows the statistics for the threats. For WordPress developers that have been using Desktop Server for many years, it was sad to see ServerPress is closing. If you are a Premium Subscriber, you will have support until your subscription is up. Check out the just-released int

¿Por qué habría que dejar atrás lenguajes de muchos años por muy asentados que estén en la industria? Hoy día usamos lenguajes de programación que tienen casi 30 años de vida, como Java o JavaScript. Incluso algunos con 40 o 50 años como C, C++ u Objective-C ¿Es esto correcto? ¿Están los lenguajes "dinosaurio" siendo un impedimento para la correcta evolución del software y el desarrollo? A través de unas declaraciones de Douglas Crockford, creador del estándar JSON e histórico defensor de Javascript, que ahora piensa que deberíamos retirar el lenguaje por su antigüedad y apostar por nuevos, nos hacemos esa pregunta y la analizamos. Enlaces de interés: - "Lo mejor que podemos hacer hoy con JavaScript es retirarlo": así habla el creador de JSON y autor de 'How JavaScript Works'" (Genbeta:dev) Descubre nuestro canal de Twitch en: twitch.tv/applecoding. Descubre nuestras ofertas para oyentes: Cursos en Udemy (con código de oferta) Apple Coding Academy Suscríbete a Apple Coding en nuestro Patreon. Canal de Telegram de Swift. Acceso al canal. --------------- Consigue las camisetas oficiales de Apple Coding con los logos de Swift y Apple Coding así como todo tipo de merchadising como tazas o fundas. Tienda de merchandising de Apple Coding. --------------- Tema musical: "For the Win" de "Two Steps from Hell", compuesto por Thomas Bergensen. Usado con permisos de fair use. Escúchalo en Apple Music o Spotify.

Pydantic has become a core building block for many Python projects. After 5 years, it's time for a remake. With version 2, the plan is to rebuild the internals (with benchmarks already showing a 17x performance improvement) and clean up the API. Sounds great, but what does that mean for us? Samuel Colvin, the creator of Pydantic, is here to share his plan for Pydantic v2. Links from the show Samuel on Twitter: @samuel_colvin Pydantic v2 plan: pydantic-docs.helpmanual.io Py03: pyo3.rs FastAPI: fastapi.tiangolo.com Beanie: github.com SQLModel: sqlmodel.tiangolo.com Speedate: docs.rs Pytests running on Pydantic in browser: githubproxy.samuelcolvin.workers.dev JSON to Pydantic tool: jsontopydantic.com Pyscript: pyscript.net Michael's Pyscript + WebAssembly: Python Web Apps video: youtube.com Watch this episode on YouTube: youtube.com Episode transcripts: talkpython.fm --- Stay in touch with us --- Subscribe to us on YouTube: youtube.com Follow Talk Python on Twitter: @talkpython Follow Michael on Twitter: @mkennedy Sponsors RedHat Microsoft AssemblyAI Talk Python Training

Guest InterviewAlberto Betella - CTO RSS.comShow NotesPodcast host RSS.com is to announce integration with Alby this week: enabling value 4 value for thousands of podcasts. You'll be able to activate and link your Alby account with your podcast in RSS.com's dashboard.  RSS has produced a video showing how it works on their platformMonetize your @CastosHQ podcast with @getAlby and @PodcastindexOrg value4value tag!  Castos has produced a video showing how it works on their platformFull List of  New Podcast 2.0 Apps  Full List of Podcast HostsHot on the heels of last week's acquisition by Acast. Podchaser announced this week that developers can now pull episode transcripts from the Podchaser API.  In this beta release, developers can retrieve JSON transcript files of episodes from the top 5k podcasts.  Spotify published its Q2/21 financial report. which out-performed market expectations. Ignoring currency fluctuations, ad-supported revenue (including podcasting) is up 31%; the platform now has 4.4m podcasts. “The number of (monthly active users) that engaged with podcasts grew in the substantial double-digits Y/Y and per user podcast consumption rates continued to rise,” though no numbers were given.Does podcasting have a privacy problem? Writing on his personal blog, our Editor highlights what the GDPR actually says, whether you can do privacy-friendly geo-targeting, and where things might be an issue. Was the much-loved comedian and actor Robin Williams the first podcaster? We've unearthed some compelling evidence that shows that yes, he might well have been.The British Podcast Awards 2022 winner's ceremony took place on Saturday. Podcast of the year was Dear Daughter from the BBC World Service - a show hosted by Namulanta Kombo, the Kenyan winner of the BBC World Service International Podcast. We've got a full list of the winners including a full video and photographs from the event.

TJ Littlejohn (mtnPay CEO) joins The Zeitgeist to discuss how mtnPay is enabling real-world crypto adoption by innovating on the payment user experience.Show Notes00:42 - Background                        01:53 - Story behind MtnPay              03:42 - Other participants at MtnDAO          05:53 - From white paper to actually building08:56 - Congressman interaction          10:22 - What is MtnPay?                    12:22 - Future Features for MtnPay14:40 - Winning Riptide's payments track                  15:33 - Developer resources              16:40 - The Photobooth                    20:34 - Solana's architecture            22:10 - The Future of Payments on Solana  24:33 - The future of MtnPay              25:40 - Builders TJ admires              27:18 - Where to learn more about MtnPay  Full TranscriptBrian (00:06):Hey, everyone and welcome to the Zeitgeist, the show where we highlight the founders, developers, and designers who are pushing the Web3 space forward. I'm Brian Friel, developer of relations at Phantom and joining me today is TJ Littlejohn. TJ is the founder and CEO of mtnPay. A Solana API for payments. TJ, how's it going today?TJ (00:24):What's up, dude. Thanks for having me on.Brian (00:27):Thanks for coming on. We're real excited to give you guys a little bit of spotlight here. You guys have built some great products that have integrated with Phantom and some really cool ways. Before we dive into all that, do you mind giving us a little background on who you are and how you became to be building on Solana?TJ (00:42):Yeah. So like you said, my name's TJ. Background's just as a developer historically, I'm an iOS developer. I did that in college, was really into hackathons, after school went out to SF and worked at Apple doing iOS development there. Kind of wanted to do something a little more impactful, joined some startups, found Solana maybe at the end of last year, I noticed there was an opportunity to build and I couldn't ignore it. There was a lot of foundational things popping up. I think Phantom had just got going within the last couple months. And NFTs were usable, but there was still a massive vacuum for other things and so it kind of jumped in and exploring what to build really.Brian (01:23):That's awesome. And so a lot of people when they hear the name mtnPay, the first thing that comes to their mind is mtnDAO. And for those that don't know, mtnDAO started originally as this small little co-working space in Salt Lake City for some Solana builders to come together. Now it's evolved, let's say it's basically a movement. It's kind of the epitome of Solana developer culture in a lot of respects. What is the kind of founding story there? How did you get involved in mtnDAO? And what was the original idea for what is now mtnPay?TJ (01:54):Yeah, mtnDAO like you said, it's a co-working space. Month long co-working space in Salt Lake City. I got involved to go there because of my friends that brought me into Solana. I had a couple good friends, Edgar and Barrett who were into this space a lot earlier than most people were. And they were just some really cool builders and had a lot of great friends that were developers and entrepreneurs. And so I think they had done this the year prior where it was called the mountain compound. And they just had a bunch of people come out, they rented a ski house and just kind of built for a week or so. And then naturally it was like, cool, they were going to do it the next year, and so that was what became mtnDAO.TJ (02:32):And everyone was invited, I was friends with them, I was definitely going to go. Kind of popped off and a lot of people showing up. And so we were there in this co-working space and there was just ... I was looking for stuff to do. And it was a random, fun idea to build a point of sale. Solana Pay had just came out, the spec and with being bored I was reading it. And it was a night before a party and I was grabbing a Red Bull because I was really tired and there was a point of sale there that was a self-service checkout thing. We were like, what if we just rebuilt this and added Solana Pay? And that was it. There wasn't much more past that, and it was oh, we can make this for our friends for the full month. And we jumped all over that.Brian (03:13):That's awesome. Starting small, now it's basically this whole movement. You guys have a couple really great integrations, but with the NFTs I saw, being able to just push transactions on the end users and Phantom. I guess before we dive into all that a little more, just to talk a little bit more about mtnDAO, you mentioned Edgar and Barrett. I believe that's Edgar and Barrett from Cipher Protocol and Margin Five. Is that right?TJ (03:33):Correct.Brian (03:34):What were some of the other builders there? Do you still keep in touch with folks who were in that early house and how has that kind of scene evolved on Solana?TJ (03:42):It's crazy. There's been so many wins that came out of that month. Nick from Cronos was there. They're an incredible project and he ended up winning the Riptide Hackathon. My friend Jeff spent the month there and he's been experimenting with a bunch of different Defi opportunities since. Cavy, now works at Genesis Go. I know that John now is at Coral. I don't know if there was any correlation of him up there, but just shows how sick we build, he was just hanging out there all month. All the people from Cashmere was there. They were awesome to have around. Jeremy Cardinal, literally everyone. I know [inaudible 00:04:29] came through the whole time, VCs like Alex from Delfi or Cal Samani was there. Just the raw crew, you know?TJ (04:36):So that was I think really cool and inspirational and you're around those people and it just makes you want to be better and elevate yourself and be around some sick builders. Mika, I think a lot of the Phantom people came in through too. I think that was the first time I met CK. And I think honest, meeting CK there enabled a lot of the mtnPay stuff because I had this open line of coms just to pester him when Solana Pay was coming out. The new versions of Solana Pay were coming out like dude, I need this. When's it coming? When's it coming was able to work in parallel. Ended up if I think getting connected to you through that probably, was pestering you a bunch. A lot of crazy opportunities came through man mtnDAO.Brian (05:16):Yeah. I wouldn't call it pestering, but no, it's a super organic developer movement here. It's something that definitely originally drew me to Solana in the first place. Just the positivity and the sheer number of people just show up to a house in Utah and start hacking on things. So you mentioned the founding stories. You're sitting in this house in Utah, there's this square terminal where you could check out maybe buy some snacks, buy some Red Bulls late at night. Was it just you who was working on this idea? How did this come together? You mentioned that the Solana Pay spec was released that day. How did you go from, Hey, I see this essentially a white paper, maybe a GitHub to actually deciding this was something you're going to actually spend some time on?TJ (05:53):Yeah, totally. So had the idea randomly. I was reading the spec early in the week, knew about it. Literally what you said was at the point of sale, like had the idea like, oh, it'd be sick to rebuild this, but add Solana Pay. But obviously there's more that kind of follows up there. That was on Friday night. And so my boy Scott was in town. We kind of knew we wanted to go out Friday, go skiing Saturday and then started hacking on some stuff because he was there through I think Wednesday maybe? And so we had floated a couple of ideas around on what we could possibly be working on. And that was just one of them. And then we ended up on Sunday, at the shop, which is the co-working space that mtnDAO was at.TJ (06:30):We probably were whiteboarding five to six ideas dealing with stuff with Game-Fi or tokens for Twitch creators or ... It's funny, like one of the early ideas was like tokens for merchants. And then another one was just this one of doing the point of sale for this. And we're like I feel this is the most digestible and that we could hack together and it fit our skill sets. I'm an iOS developer. Scott's done some stuff on the back end before. And so he could handle a lot of the integration, the square stuff and I can do the Solana front end stuff and it just made sense. And so we grinded it, we stayed up super, super late, most nights, but it was a 48 hour turnaround because we also didn't even start it on Sunday, like that actual idea until five, six o'clock. I actually looked the other day because I was going back to some of the mtnDAO tweets. We did it on February 8th. Which was sick. So a lot of it came out on the first. So it was really fast.Brian (07:27):And no inside knowledge to the time right? You basically found out the same time everyone else did.TJ (07:32):Yeah. No inside knowledge, but I think Jordan from Solana Pay will boast that there was no insider knowledge. The repo was public since November. So anyone could have known.Brian (07:43):Alpha hiding in plain sight there.TJ (07:45):Exactly. Obscurity by just putting it on GitHub. I did feel I had insider knowledge afterwards though. I remember Nick from Cronos, it was super on payments now, was super on my radar, we had that video go kind of viral. Then Nick from Cronos came back from the Seattle Hacker House and I think he met someone there and learned about the transaction request back. And I remember in between that is when I met CK and I was like, dude, if we can figure out how to make this work for any transaction on Solana, it's over. This changes everything. And I was so sure of that, but I had no idea how you could do that. And then I remember Nick coming back and showing me the spec and I never felt like I had such insider info in my life. But again, it was just probably on the GitHub. But man, I remember reading it and just being like, this is different. This changes things.Brian (08:41):Yeah. No that's super cool. I remember that video you mentioned, I think it was at three in the morning, you guys filmed it with Scott and he's there checking out his Red Bull on mtnPay. I think you guys even had somebody who was a governor or a Senator that came by and checked out with it. Who was that?TJ (08:56):John Curtis. I believe Congressman John Curtis. That was fun too. He came another time. We had a couple of minutes in between when he was meeting with people privately or something or had a small round table with some folks. And when he was going to do a larger chat and so just got to get down with the stuff to him, which was really cool because that's a lot of what mtnPay going to do in the near term is just demo what's possible. It's kind of like a chicken and the egg thing. And so I don't think there's a massive surplus of people waiting ready to pay, but I think we have an opportunity to demo and move conversations along. And so that was just a really good example of that is how we can show the decision makers, what is actually doable and what things look like and feel like.Brian (09:42):Yeah, it's kind of like you said, the whole protocol could be sitting there on GitHub for anyone to go see, but there's very few people in the world who are going to dig into that and actually build something. And you guys are actually building products that makes this tangible, make this real, you get someone like a Congressman to come in and actually use it and buy something for real and have it show up in Square. And as a line item ran right alongside using a credit card or something like that. You hit on a couple things earlier. You mentioned that originally at this point of sale integration, but then the second evolution of this spec came along that enabled transaction requests. And so you guys have built some really great products around that, how would you describe what mtnPay is today holistically?TJ (10:23):At our interface layer, we're an API, right? So we want to be able to be pinged by anyone that has an internet connection and can make rest API calls. On the back end what we're doing is we are doing the grunt work of integrating with a bunch of different protocols and tying their functionality together for use cases that make sense to consumers. I want to pay for this, please build the transaction that does that. Or I would like to use a coupon that I have in my account and get a discount on this item I am purchasing or it doesn't necessarily have to be payment stuff. Like you said, we have some cool stuff we do with NFTs. For another example, we integrate with Magic Eden this week and have a feature where you can have a QR code that sweeps the floor of a given NFT collection. And that was done by using like of their APIs that maybe weren't intended to be used exactly together. But then we did that and then we can open that up for other people to use in whatever way they want to compose with this product.Brian (11:31):Yeah. And so this is all leveraging at the end of the day that Solana Pay spec and that transaction requests are part of that. I feel like the Solana Pay is a bit of a misnomer at this point because, originally, it's a similar evolution you guys have took, starting out payments point of sale. Now you're able to scan a QR code, sweep the floor. I even saw that Greg, one of the mtnPay team members, actually printed this QR code and put it on a shirt and has been walking around. So you can scan a shirt live in person and sweep the floor. It's pretty cool. What are some of the things that you think people aren't maybe thinking about when it comes to transaction requests? Most people know transaction requests from either just a tutorial or sending someone an invoice or something that they can pay. You guys I think are pushing the envelope a little bit here. What are some of the things that you mentioned that the sweeping the floor, what are some others that you have in mind here?TJ (12:22):I think the mental model shift that you need to hit is that a transactional request can literally just do anything you can do on Solana. So anything dApps are doing today where they're building transactions, you can do that with transaction requests. But the cool thing is you can do that on a servered environment. And so you start to separate the entities that are involved, the group that's building the transaction doesn't have to be the group that's generating the QR code, which doesn't have to be on the same device that the user is trying to grab the transaction and sign it. When you start to break up this stuff, really cool interactions can happen. And so when I had that unlocked from seeing the spec, my mind was just running and I was like, what cool things can we do with this?TJ (13:10):One of the really early ideas that we had, and a lot of it centered around what can we do that's like fun here? What do we think is unique and whatever, and so one of the really early ideas we had was Degen coin flip. Could we wrap up Degen coin flip and put it on a projector at a party and just have people doing Degen coin flip and do a cool UI. And everyone can just like get hyped when someone wins a bunch of money, that's fun. Or the next idea there was the photo booth we built. Those ideas both came from the Austin community hacker house that happened in March. I wanted to build those out for that hacker house.TJ (13:50):But the timing didn't line up with when transaction requests was going to be live in the app store. And so we had to wait on that, but that was really fun. We did the Magic Eden sweeping thing. We've done candy machine minting, just wrapping up protocols. Notice how in here we didn't build any core protocol piece ourselves or even the way to interface with them. We just go on their open source repos and just look at their front end and try to grab the pieces that call into their smart contracts. Then wrap that up in some cool ways. And to me that was a big aha moment, it was like, oh shit, you can do some stuff here.Brian (14:28):Yeah. It's pretty unbelievable that you guys have built all this without even writing a single line of rust or deploying your own program on Solana. I think you guys even won the payments track of the last hackathon, is that right?TJ (14:40):Yeah. We won Riptide, of the payments part of Riptide, shout out Cronos, Cronos won the whole thing. But yeah, we won the payments track. We were super stoked about that. It's given us a couple of opportunities and some eyeballs, which has been really nice, but you know, it's starting to become old news. Solana summer camps here, I think a new wave of peeps with eyeballs and whatever's going to come up. And so we've just got to keep going, keep innovating, keep building. And we're stoked to do that. Just got to be like, what can we integrate with next?Brian (15:10):I think it's a great story though, for all those new builders who are coming up on the new hackathon that you can build this incredible company that does all these different things without even having to get into the whole program side of Solana. There's so much that's already out there. It's so composable with one another, you can do a lot of work just on the client. You can do a lot of work, building APIs, building wrappers around all this stuff that just makes this easier for everyday people.TJ (15:33):Yeah. And there's so many developer resources out there now, too. It's getting to a point where it's easier to just look stuff up and some actual solid answers are out there. Some of the resources being yours. I believe I've had that happen recently where I'll be looking for ... We've been trying to do some things onchain. There's some really cool stuff we can do when we start moving the infrastructure onchain, it gets safer and more powerful. And in trying to do that, I came up across a lot of your articles. And so I kind of wanted to shout those out, those are really cool to see.Brian (16:03):Appreciate that. It's great to hear they're still relevant after all this time. Some of those might be outdated, so listener beware. You mentioned the photo booth as one of the applications you guys have built. For those that haven't seen it, photo booth is this actual in person kiosk, you have an iPad, you could use any sort of device here, but what it basically lets you do is take a photo just like you would in a photo booth and in a few easy steps, you can mint this as NFT on Phantom Mobile, and your favorite wallet, all seamless, all running on mtnPay APIs. What was the inspiration for the photo booth? How did you guys originally even come up with this idea?TJ (16:39):I think it was a lot of things. I think people talk about, I don't know, there's that thing of founder fit or whatever, or hindsight's always 20/20 or whatever. But there were so many little things that had happened to me from January to March to get to the photo booth happening that it's crazy that it actually did happen. So the photo booth idea came about when I was thinking about what stuff can we do with Solana Pay? I think pretty early on, I was like, oh, you could mint NFTs. I had done stuff with ... Back in January, my passion project was a custom candy machine contract where instead of minting NFTs that were directly linked to a JSON file, that was on some CDN.TJ (17:31):I was going to point it at a serverless function. And then that serverless function was going to query onchain data and then return JSON back to the user there. And so would, it'd be this cool, dynamic NFT based on onchain data. And so that was the first time I learned serverless functions, which I needed for mtnPay the photo booth. That was the first time I was digging into the candy machine code. And then thinking about fun stuff I can do, it went from the Degen coin flip on the wall to an iPad up on the wall that took the picture, uploaded it, and then you could use Solana Pay to mint the NFT and all of that was only possible because I had those different pieces of context. And then the last thing being that my friend Nick just dropped the transaction request back in my DMs.TJ (18:22):And I don't know if I would've run into it other than that single moment. And so that was kind of how the idea started to come about. And then we built it out. It's actually funny, I was actually focusing super, super hard on the point of sale app, but I thought that was the thing we were going to do. And so I was trying to put all of my time there, we were trying to do a merchant pilot and get IRL merchants onboarded to this thing. So I felt I had so much to build, but I knew that the photo booth could be this fun thing. So at first I thought about just having someone else build it, I was reaching out to some people asking for grants or like, Hey, do you want to sponsor this thing?TJ (19:01):And I could get like 3000 dollars from someone then give it to a developer friend to help build it. And I could guide them how to build it, but I couldn't source any money. And so I just had to use one or two nights of my own time away from mtnPay and just build this thing. And then after I built the first version of it, I was like, oh shit, this is kind of crazy. The idea is one thing, but when you actually get to use it, I don't know again, I feel it's kind of like a mental unlock for some people myself included. It was like a big shift.Brian (19:37):Yeah. I would definitely say it's a bit of a light bulb moment. I think the first time I saw it was Solana Miami, I think you guys brought it out and I think it was the first time you guys had also bought this inflatable cover around the photo booth.TJ (19:50):The marshmallow.Brian (19:51):The marshmallow. Yeah. Since then, I think it's gone through a few different evolutions. I've seen some cool plans in the works too for how you guys thinking of upgrading this thing. But you know, personally, I love it. We've brought it around at Phantom to a couple different places. I know we sponsored at the hacker house in Austin and then on the Degen party and there's a couple other places as well. It's been a huge hit, we see even folks who maybe aren't necessarily crypto native. It's a great excuse for them to download Phantom, download a wallet and scan this thing, submit their first NFT, especially because a lot of folks don't even know but with Solana Pay transaction requests, this can be free mint to users, right? You guys can essentially make this so someone can just download a wallet, scan a QR code, and then next thing they know, they have an NFT in their wallet without paying any Sol.TJ (20:34):It's crazy. The architecture of Solana is very composable or gas has to be paid, but it doesn't have to be paid by the user that's minting. I think that's one of the problems honestly, or not the problems, but one of the challenges is a wallet, right? Phantom, it's such a productized thing. I think Phantom's done an incredible job productizing this wallet to be easy to use. And it makes sense for consumers and holds this stuff. But reality, a wallet just is your private key. It's the software that holds your private key and then it's the actions that a user can do when the private key exists. And so you think like, oh no, I'm sending this Sol, or I'm minting this NFT where really, it's an action is just requires my signature and the signatures here so I can do that. And so as part of our infrastructure, we can sometimes pay for NFTs, we can pay for rent, we have wallets on our backend that we can sign for transactions. There's really, really cool stuff there. So anyone out there listening, that's doing stuff for the Solana summer camp, you have questions on how that works. Please reach out. Happy to walk you through that. You can do cool stuff though, I guarantee I haven't thought of.Brian (21:45):I love it. That's awesome. You hit a lot here with transaction requests, what's capable across the Solana protocol, also the founding story of mtnPay really was in this point of sale app. What do you think is the future of payments on Solana? You mentioned that we're kind of in this still experimental phase. What do you think are some of the next big hurdles that we as an ecosystem need to conquer together to make payments more real?TJ (22:10):I think it's a couple things. I think a lot of things have to happen for payments to go to scale. I think the first thing that has to happen is something like mtnPay has to exist and we have to have infrastructure in the hands of the merchants that enable them to accept non-custodial funds that is not locked into any single platform. To me that's a given, which is why I'm so stoked to be building this. But I think there's a lot of other pieces. I think protocols just in general have to exist. I think novel ideas have to be created and people have to build them out stuff like dialect, right? Where it's just a raw messaging protocol. Stuff like Cardinal, where they're adding functionality on top of NFTs for anyone to use. Really cool lending protocols need to exist.TJ (22:59):And then our job is to kind of grab those and wrap those together for product use cases. And then I think just other things totally separate from payments have to exist. I think Game-Fi, to be honest with you is going to be a massive catalyst of payments on Solana going well. I think you need users here that have a balance in crypto for reasons other than payments. And then they can start using those balances for payments as well, which is why I'm so stoked about something like the Saga, because I think it's going to start to get a lot of those early users in the ecosystem doing things that just aren't related to payments.TJ (23:37):A lot of times I like to think about it in terms of how Apple, right, the Apple ecosystem's so great because your iMessage with your FaceTime works with your photos. It's how I think like Solana kind of goes, but people get to build the different pieces. And so that's what I think the world looks like if this goes well and it sounds like a fun world. And so I hope that it happens and we're going to do our best to see that.Brian (24:02):Yeah. Well, I would say that it's already a fun world here in the Solana developer ecosystem. You know, you've seen both the worlds. You mentioned Apple, but having worked on the inside Apple, they build incredible products, but I haven't seen an ecosystem quite like Solana has where it's just so open. I mean, you mentioned Nick from Cronos, you got the Cardinal guys, all in the same chats, all showing up the same house in Utah. It's a really awesome environment where we can kind of build this composable layer together. If you had to summarize, where do you see mtnPay going from here?TJ (24:33):Yeah. We're going to keep leaning on our infrastructure piece. We want to compose with more protocols, get some integrations. We have stuff in the pipeline with Dialect. We've spoken with the Cardinal folks a handful of times. I think we can compose with them without being super hands on with them and so we're going to do that in the near term. We're in a big integration phase, try to bring these things together. And then the other side of that is the distribution. So we have some cool distribution paths that we're not ready to talk about just yet. That's kind of both sides here that we need to be super careful about. It's making sure we have a really cool set of infrastructure, but how can we go and get that infrastructure out there to as many people as possible? And so that's the real two focuses that we have.Brian (25:15):Well, I look forward to inviting you back on the pod or you can unveil a little more news there about the distribution and all you guys are up to. TJ, we ask this of every guest at the end, we want to know who is a builder that you admire in the Solana ecosystem and I got to say that our last guest, Steven Laborer, gave you a shout out. Everyone knows your energy and the space is infectious. But everyone listening wants to know who is a builder that you admire in the Solana ecosystem?TJ (25:39):Can I just say Steven back? No, I'm just kidding. Love Steven. That's not who I'm going to shout out today. I'm going to shout out, I don't even know his last name, but his Twitter name's Jacob dot soul. Jacob's a sick developer. Have you met him before.Brian (25:52):Yeah, I've interacted with him on Twitter a little bit, but I don't think I've met him in person.TJ (25:55):He is really cool. He is an incredible developer. He is a lot of fun. He's part of the photo booth story where initially we were using candy machine for the photos, for the photo booth and Solana wasn't doing great that day. And so my program wasn't deploying to main net and so an hour or two before we went live, he sat down and helped me rewrite a bunch of the minting stuff for the back end. And I had interacted with him at mtnDao, but didn't know him super, super well. And so he's just a super giving dude, super talented. He's out there building. Have you seen Feeble Labs yet?Brian (26:33):Yep.TJ (26:33):The lambs or whatever. You have to interact with their Twitter or your NFT dies. It's incredible. That's where you get my respect is if you're out there doing something creative with no ask, right? They're giving these things away for free. They're doing Twitter spaces all the time. He's just one of the real, actual, creative builders out there. So I have a lot of respect for Jacob. I look up to him a lot.Brian (27:01):That's awesome. I think that encapsulates the spirit of Solana, pushing things forward, trying out new tech, experimenting, and then also being really open and helping others at the same time.TJ (27:11):Totally, totally, totally.Brian (27:13):TJ, this is really great. Thank you for your time. Where can people go to learn more about mtnPay?TJ (27:17):Yeah. So go to at @mtnPay on Twitter. M-T-N-P-A-Y. And you'll see that there. Or you can follow me TJ underscored Littlejohn, because I talk about it a lot as well. Those two spots you'll find all of our other stuff from there.Brian (27:31):Love it, TJ Littlejohn. Thanks for coming on the show.TJ (27:33):Dude, thanks for having me. Appreciate you. It was a lot of fun. 

Cet épisode fait partie d'une série de quelques épisodes dédiés à l'animation. Dans cet épisode, nous recevons Charly Martin pour parler de Lottie, une solution pour créer des animations SVG très avancées Retrouvez la vidéo de l'enregistrement sur le Youtube de DoubleSlash Lottie Lottie est un format open source d'animation vectorielle basé sur un fichier JSON. Le format a été créé par le département design de AirBnB. Ils sont créés un plug-in pour After Effects (Bodymovin) qui permet d'exporter les animations créées dans ce dernier sous un format lisible par des librairies disponibles sous différentes plateformes. Pour le web par exemple, avec la librairie lottie-web installée dans votre projet, vous pourrez afficher l'animation qui provient du fichier JSON. Vous l'avez compris, il est nécessaire de passer par After Effects pour créer l'animation. Cela peut être un frein à l'utilisation de Lottie. Par contre, si vous avez un Motion Designer dans votre équipe, vous allez pouvoir faire des animations très avancées qui sont quasiment impossibles à faire autrement. Liens de l'épisode https://airbnb.io/lottie/#/ https://github.com/airbnb/lottie-web https://lottiefiles.com/ https://lottielab.com/ Retrouvez notre invité Charly Martin https://www.linkedin.com/in/charlymartin/ https://github.com/CharlyMartin https://lottiestudio.com/ https://charlymartin.me/ Bonne écoute ! Podcast présenté par : Alexandre Duval @xlanex6 Patrick Faramaz @PatrickFaramaz

About JeffJeff Smith has been in the technology industry for over 20 years, oscillating between management and individual contributor. Jeff currently serves as the Director of Production Operations for Basis Technologies (formerly Centro), an advertising software company headquartered in Chicago, Illinois. Before that he served as the Manager of Site Reliability Engineering at Grubhub.Jeff is passionate about DevOps transformations in organizations large and small, with a particular interest in the psychological aspects of problems in companies. He lives in Chicago with his wife Stephanie and their two kids Ella and Xander.Jeff is also the author of Operations Anti-Patterns, DevOps Solutions with Manning publishing. (https://www.manning.com/books/operations-anti-patterns-devops-solutions) Links Referenced: Basis Technologies: https://basis.net/ Operations Anti-Patterns: https://attainabledevops.com/book Personal Site: https://attainabledevops.com LinkedIn: https://www.linkedin.com/in/jeffery-smith-devops/ Twitter: https://twitter.com/DarkAndNerdy Medium: https://medium.com/@jefferysmith duckbillgroup.com: https://duckbillgroup.com TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is sponsored by our friends at Fortinet. Fortinet's partnership with AWS is a better-together combination that ensures your workloads on AWS are protected by best-in-class security solutions powered by comprehensive threat intelligence and more than 20 years of cybersecurity experience. Integrations with key AWS services simplify security management, ensure full visibility across environments, and provide broad protection across your workloads and applications. Visit them at AWS re:Inforce to see the latest trends in cybersecurity on July 25-26 at the Boston Convention Center. Just go over to the Fortinet booth and tell them Corey Quinn sent you and watch for the flinch. My thanks again to my friends at Fortinet.Corey: Let's face it, on-call firefighting at 2am is stressful! So there's good news and there's bad news. The bad news is that you probably can't prevent incidents from happening, but the good news is that incident.io makes incidents less stressful and a lot more valuable. incident.io is a Slack-native incident management platform that allows you to automate incident processes, focus on fixing the issues and learn from incident insights to improve site reliability and fix your vulnerabilities. Try incident.io, recover faster and sleep more.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. One of the fun things about doing this show for long enough is that you eventually get to catch up with people and follow up on previous conversations that you've had. Many years ago—which sounds like I'm being sarcastic, but is increasingly actually true—Jeff Smith was on the show talking about a book that was about to release. Well, time has passed and things have changed. And Jeff Smith is back once again. He's the Director of Product Operations at Basis Technologies, and the author of DevOps Anti-Patterns? Or what was the actual title of the book it was—Jeff: Operations Anti-Patterns.Corey: I got hung up in the anti-patterns part because it's amazing. I love the title.Jeff: Yeah, Operations Anti-Patterns, DevOps Solutions.Corey: Got you. Usually in my experience, alway been operations anti-patterns, and here I am to make them worse, probably by doing something like using DNS as a database or some godforsaken thing. But you were talking about the book aspirationally a few years ago, and now it's published and it has been sent out to the world. And it went well enough that they translated it to Japanese, I believe, and it has seen significant uptick. What was your experience of it? How did it go?Jeff: You know, it was a great experience. This is definitely the first book that I've written. And the Manning process was extremely smooth. You know, they sort of hold your hand through the entire process. But even after launch, just getting feedback from readers and hearing how it resonated with folks was extremely powerful.I was surprised to find out that they turned it into an audiobook as well. So, everyone reaches out and says, “Did you read the audiobook? I was going to buy it, but I wasn't sure.” I was like, “No, unfortunately, I don't read it.” But you know, still cool to have it out there.Corey: My theory has been for a while now that no one wants to actually write a book; they want to have written a book. Now that you're on the other side, how accurate is that? Are you in a position of, “Wow, sure glad that's done?” Or are you, “That was fun. Let's do it again because I like being sad all the time.” I mean, you do work Kubernetes for God's sake. I mean, there's a bit of masochism inherent to all of us in this space.Jeff: Yeah. Kubernetes makes me cry a little bit more than the writing process. But it's one of the things when you look back on it, you're like, “Wow, that was fun,” but not in the heat of the moment, right? So, I totally agree with the sentiment that people want to have written a book but not actually gone through the process. And that's evident by the fact that how many people try to start a book on their own without a publisher behind them, and they end up writing it for 15 years. The process is pretty grueling. The feedback is intense at first, but you start to get into a groove and you—I could see, you know, in a little while wanting to write another book. So, I can see the appeal.Corey: And the last time you were on the show, I didn't really bother to go in a particular topical direction because, what's the point? It didn't really seem like it was a top-of-mind issue to really bring up because what's it matter; it's a small percentage of the workforce. Now I feel like talking about remote work is suddenly taking on a bit of a different sheen than it was before the dark times arrived. Where do you land on the broad spectrum of opinions around the idea of remote work, given that you have specialized in anti-patterns, and well, as sarcastic as I am, I tend to look at almost every place I've ever worked is expressing different anti-patterns from time to time. So, where do you land on the topic?Jeff: So, it's funny, I started as a staunch office supporter, right? I like being in the office. I like collaborating in person; I thought we were way more productive. Since the pandemic, all of us are forced into remote work, I've hired almost half of my team now as remote. And I am somewhat of a convert, but I'm not on the bandwagon of remote work is just as good or is better as in person work.I've firmly landed in the camp of remote work is good. It's got its shortcomings, but it's worth the trade off. And I think acknowledging what those trade-offs are important to keeping the team afloat. We just recently had a conversation with the team where we were discussing, like, you know, there's definitely been a drop in productivity over the past six months to a year. And in that conversation, a lot of the things that came up were things that are different remote that were better in person, right, Slack etiquette—which is something, you know, I could talk a little bit about as well—but, you know, Slack etiquette in terms of getting feedback quickly, just the sort of camaraderie and the lack of building that camaraderie with new team members as they come on board and not having those rituals to replace the in-person rituals. But through all that, oddly enough, no one suggested going back into the office. [laugh].Corey: For some strange reason, yeah. I need to be careful what I say here, I want to disclaim the position that I'm in. There is a power imbalance and nothing I say is going to be able to necessarily address that because I own the company and if my team members are listening to this, they're going to read a lot into what I say that I might not necessarily intend. But The Duckbill Group, since its founding, has been a fully distributed company. My business partner lives in a different state than I do so there's never been the crappy version of remote, which is, well, we're all going to be in the same city, except for Theodore. Theodore is going to be timezones away and then wonder why he doesn't get to participate in some of the conversations where the real decisions get made.Like that's crappy. I don't like that striated approach to things. We don't have many people who are co-located in any real sense, nor have we for the majority of the company's life. But there are times when I am able to work on a project in a room with one of my colleagues, and things go a lot more smoothly. As much as we want to pretend that video is the same, it quite simply isn't.It is a somewhat poor substitute for the very high bandwidth of a face-to-face interaction. And yes, I understand this is also a somewhat neurotypical perspective, let's be clear with that as well, and it's not for everyone. But I think that for the base case, a lot of the remote work advocates are not being fully, I guess, honest with themselves about some of the shortcomings remote has. That is where I've mostly landed on this. Does that generally land with where you are?Jeff: Yeah, that's exactly where I'm at. I completely agree. And when we take work out of the equation, I think the shortcomings lay themselves bare, right? Like I was having a conversation with a friend and we were like, well, if you had a major breakup, right, I would never be like, “Oh, man. Grab a beer and hop on Zoom,” right? [laugh]. “Let's talk it out.”No, you're like, hey, let's get in person and let's talk, right? We can do all of that conversation over Zoom, but the magic of being in person and having that personal connection, you know, can't be replaced. So, you know, if it's not going to work, commiserating over beers, right? I can't imagine it's going to work, diagramming some complex workflows and trying to come to an answer or a solution on that. So again, not to say that, you know, remote work is not valuable, it's just different.And I think organizations are really going to have to figure out, like, okay, if I want to entice people back into the office, what are the things that I need to do to make this realistic? We've opened the floodgates on remote hiring, right, so now it's like, okay, everyone's janky office setup needs to get fixed, right? So, I can't have a scenario where it's like, “Oh, just point your laptop at the whiteboard, right?” [laugh]. Like that can't exist, we have to have office spaces that are first-class citizens for our remote counterparts as well.Corey: Right because otherwise, the alternative is, “Great, I expect you to take the home that you pay for and turn it into an area fit for office use. Of course, we're not going to compensate you for that, despite the fact that, let's be realistic, rent is often larger than the AWS bill.” Which I know, gasp, I'm as shocked as anyone affected by that, but it's true. “But oh, you want to work from home? Great. That just means you can work more hours.”I am not of the school of thought where I consider time in the office to be an indicator of anything meaningful. I care if the work gets done and at small-scale, this works. Let me also be clear, we're an 11-person company. A lot of what I'm talking about simply will not scale to companies that are orders of magnitude larger than this. And from where I sit, that's okay. It doesn't need to.Jeff: Right. And I think a lot of the things that you talk about will scale, right? Because in most scenarios, you're not scaling it organizationally so much as you are with a handful of teams, right? Because when I think about all the different teams I interact with, I never really interact with the organization as a whole, I interact with my little neighborhood in the organization. So, it is definitely something that scales.But again, when it comes to companies, like, enticing people back into the office, now that I'm talking about working from home five days a week, I've invested in my home setup. I've got the monitor I want, I've got the chair that I want, I've got the mouse and keyboard that I want. So, you're going to bring me back to the office so I can have some standard Dell keyboard and mouse with some janky, you know—maybe—21-inch monitor or something like that, right? Like, you really have to decide, like, okay, we're going to make the office a destination, we're going to make it where people want to go there where it's not just even about the collaboration aspect, but people can still work and be effective.And on top of that, I think how we look at what the office delivers is going to change, right? Because now when I go to the office now, I do very little work. It's connections, right? It's like, you know, “Oh, I haven't seen you in forever. Let's catch up.” And a lot of that stuff is valuable. You know, there's these hallway conversations that exist that just weren't happening previously because how do I accidentally bump into you on Slack? [laugh]. Right, it has to be much more it of a—Corey: Right. It takes some contrivance to wind up making that happen. I remember back in the days of working in offices, I remember here in San Francisco where we had unlimited sick time and unlimited PTO, I would often fake a sick day, but just stay home and get work done. Because I knew if I was in the office, I'd be constantly subjected to drive-bys the entire time of just drive-by requests, people stopping by to ask, “Oh, can you just help me with this one thing,” that completely derails my train of thought. Then at the end of the day, they'd tell me, “You seem distractible and you didn't get a lot of work done.”It's, “Well, no kidding. Of course not. Are you surprised?” And one of the nice things about starting your own company—because there are a lot of downsides, let me be very clear—one of the nice things is you get to decide how you want to work. And that was a study in, first, amazement, and then frustration.It was, “All right, I just landed a big customer. I'm off to the races and going to take this seriously for a good six to twelve months. Great sky's the limit, I'm going to do up my home office.” And then you see how little money it takes to have a nice chair, a good standing desk, a monitor that makes sense and you remember fighting tooth-and-nail for nothing that even approached this quality at companies and they acted like it was going to cost them 20-grand. And here, it's two grand at most, when I decorated this place the first time.And it was… “What the hell?” Like, it feels like the scales fall away from your eyes, and you start seeing things that you didn't realize were a thing. Now I worry that five years in, there's no way in the world I'm ever fit to be an employee again, so this is probably the last job I'll ever have. Just because I've basically made myself completely unemployable across six different axes.Jeff: [laugh]. And I think one of the things when it comes to, like, furniture, keyboard, stuff like that, I feel like part of it was just, like, this sort of enforced conformity, right, that the office provided us the ability to do. We can make sure everyone's got the same monitor, the same keyboard that way, when it breaks, we can replace it easily. In a lot of organizations that I've been in, you know, that sort of like, you know, even if it was the same amount or ordering a custom keyboard was a big exception process, right? Like, “Oh, we've got to do a whole thing.” And it's just like, “Well, it doesn't have to be that complicated.”And like you said, it doesn't cost much to allow someone to get the tools that they want and prefer and they're going to be more productive with. But to your point really quickly about work in the office, until the pandemic, I personally didn't recognize how difficult it actually was to get work done in the office. I don't think I appreciated it. And now that I'm remote, I'm like, wow, it is so much easier for me to close this door, put my headphones on, mute Slack and go heads down. You know, the only drive-by I've got is my wife wondering if I want to go for a walk, and that's usually a text message that I can ignore and come back to later.Corey: The thing that just continues to be strange for me and breaks in some of the weirdest ways has just been the growing awareness of how much of office life is unnecessary and ridiculous. When you're in the office every day, you have to find a way to make it work and be productive and you have this passive-aggressive story of this open office, it's for collaboration purposes. Yeah, I can definitively say that is not true. I had a boss who once told me that there was such benefits to working in an open plan office that if magically it were less expensive to give people individual offices, he would spare the extra expense for open plan. That was the day I learned he would lie to me while looking me in the eye. Because of course you wouldn't.And it's for collaboration. Yeah, it means two loud people—often me—are collaborating and everyone else wears noise-canceling headphones trying desperately to get work done, coming in early, hours before everyone else to get things done before people show up and distracted me. What the hell kind of day-to-day work environment is that?Jeff: What's interesting about that, though, is those same distractions are the things that get cited as being missed from the perspective of the person doing the distracting. So, everyone universally hates that sort of drive-by distractions, but everyone sort of universally misses the ability to say like, “Hey, can I just pull on your ear for a second and get your feedback on this?” Or, “Can we just walk through this really quickly?” That's the thing that people miss, and I don't think that they ever connect it to the idea that if you're not the interruptee, you're the interruptor, [laugh] and what that might do to someone else's productivity. So, you would think something like Slack would help with that, but in reality, what ends up happening is if you don't have proper Slack etiquette, there's a lot of signals that go out that get misconstrued, misinterpreted, internalized, and then it ends up impacting morale.Corey: And that's the most painful part of a lot of that too. Is that yeah, I want to go ahead and spend some time doing some nonsense—as one does; imagine that—and I know that if I'm going to go into an office or meet up with my colleagues, okay, that afternoon or that day, yeah, I'm planning that I'm probably not going to get a whole lot of deep coding done. Okay, great. But when that becomes 40 hours a week, well, that's a challenge. I feel like being full remote doesn't work out, but also being in the office 40 hours a week also feels a little sadistic, more than almost anything else.I don't know what the future looks like and I am privileged enough that I don't have to because we have been full remote the entire time. But what we don't spend on office space we spend on plane tickets back and forth so people can have meetings. In the before times, we were very good about that. Now it's, we're hesitant to do it just because it's we don't want people traveling before the feel that it's safe to do so. We've also learned, for example, when dealing with our clients, that we can get an awful lot done without being on site with them and be extraordinarily effective.It was always weird have traveled to some faraway city to meet with the client, and then you're on a Zoom call from their office with the rest of the team. It's… I could have done this from my living room.Jeff: Yeah. I find those sorts of hybrid meetings are often worse than if we were all just remote, right? It's just so much easier because now it's like, all right, three of us are going to crowd around one person's laptop, and then all of the things that we want to do to take advantage of being in person are excluding the people that are remote, so you got to do this careful dance. The way we've been sort of tackling it so far—and we're still experimenting—is we're not requiring anyone to come back into the office, but some people find it useful to go to the office as a change of scenery, to sort of, like break things up from their typical routine, and they like the break and the change. But it's something that they do sort of ad hoc.So, we've got a small group that meets, like, every Thursday, just as a day to sort of go into the office and switch things up. I think the idea of saying everyone has to come into the office two or three days a week is probably broken when there's no purpose behind it. So, my wife technically should go into the office twice a week, but her entire team is in Europe. [laugh]. So, what point does that make other than I am a body in a chair? So, I think companies are going to have to get flexible with this sort of hybrid environment.But then it makes you wonder, like, is it worth the office space and how many people are actually taking advantage of it when it's not mandated? We find that our office time centers around some event, right? And that event might be someone in town that's typically remote. That might be a particular project that we're working on where we want to get ideas and collaborate and have a workshop. But the idea of just, like, you know, we're going to systematically require people to be in the office x many days, I don't see that in our future.Corey: No, and I hope you're right. But it also feels like a lot of folks are also doing some weird things around the idea of remote such as, “Oh, we're full remote but we're going to pay you based upon where you happen to be sitting geographically.” And we find that the way that we've done this—and again, I'm not saying there's a right answer for everyone—but we wind up paying what the value of the work is for us. In many cases, that means that we would be hard-pressed to hire someone in the Bay Area, for example. On the other hand, it means that when we hire people who are in places with relatively low cost of living, they feel like they've just hit the lottery, on some level.And yeah, some of them, I guess it does sort of cause a weird imbalance if you're a large Amazon-scale company where you want to start not disrupting local economies. We're not hiring that many people, I promise. So, there's this idea of figuring out how that works out. And then where does the headquarters live? And well, what state laws do we wind up following on what we're doing? Just seems odd.Jeff: Yeah. So, you know, one thing I wanted to comment on that you'd mentioned earlier, too, was the weird things that people are doing, and organizations are doing with this, sort of, remote work thing, especially the geographic base pay. And you know, a lot of it is, how can we manipulate the situation to better us in a way that sounds good on paper, right? So, it sounds perfectly reasonable. Like, oh, you live in New York, I'm going to pay you in New York rates, right?But, like, you live in Des Moines, so I'm going to pay you Des Moines rates. And on the surface, when you just go you're like, oh, yeah, that makes sense, but then you think about it, you're like, “Wait, why does that matter?” Right? And then, like, how do I, as a manager, you know, level that across my employees, right? It's like, “Oh, so and so is getting paid 30 grand less. Oh, but they live in a cheaper area, right?” I don't know what your personal situation is, and how much that actually resonates or matters.Corey: Does the value that they provide to your company materially change based upon where they happen to be sitting that week?Jeff: Right, exactly. But it's a good story that you can tell, it sounds fair at first examination. But then when you start to scratch the surface, you're like, “Wait a second, this is BS.” So, that's one thing.Corey: It's like tipping on some level. If you can't afford the tip, you can't afford to eat out. Same story here. If you can't afford to compensate people the value that they're worth, you can't afford to employ people. And figure that out before you wind up disappointing people and possibly becoming today's Twitter main character.Jeff: Right. And then the state law thing is interesting. You know, when you see states like California adopting laws similar to, like, GDPR. And it's like, do you have to start planning for the most stringent possibility across every hire just to be safe and to avoid having to have this sort of patchwork of rules and policies based on where someone lives? You might say like, “Okay, Delaware has the most stringent employer law, so we're going to apply Delaware's laws across the board.” So, it'll be interesting to see how that sort of plays out in the long run. Luckily, that's not a problem I have to solve, but it'll be interesting to see how it shakes out.Corey: It is something we had to solve. We have an HR consultancy that helps out with a lot of these things, but the short answer is that we make sure that we obey with local laws, but the way that we operate is as if everyone were a San Francisco employee because that is—so far—the locale that, one, I live here, but also of every jurisdiction we've looked at in the United States, it tends to have the most advantageous to the employee restrictions and requirements. Like one thing we do is kind of ridiculous—and we have to do for me and one other person, but almost no one else, but we do it for everyone—is we have to provide stipends every month for electricity, for cellphone usage, for internet. They have to be broken out for each one of those categories, so we do 20 bucks a month for each of those. It adds up to 100 bucks, as I recall, and we call it good. And employees say, “Okay. Do we just send you receipts? Please don't.”I don't want to look at your cell phone bill. It's not my business. I don't want to know. We're doing this to comply with the law. I mean, if it were up to me, it would be this is ridiculous. Can we just give everyone $100 a month raise and call it good? Nope. The forms must be obeyed. So, all right.We do the same thing with PTO accrual. If you've acquired time off and you leave the company, we pay it out. Not every state requires that. But paying for cell phone access and internet access as well, is something Amazon is currently facing a class action about because they didn't do that for a number of their California employees. And even talking to Amazonians, like, “Well, they did, but you had to jump through a bunch of hoops.”We have the apparatus administratively to handle that in a way that employees don't. Why on earth would we make them do it unless we didn't want to pay them? Oh, I think I figured out this sneaky, sneaky plan. I'm not here to build a business by exploiting people. If that's the only way to succeed, and the business doesn't deserve to exist. That's my hot take of the day on that topic.Jeff: No, I totally agree. And what's interesting is these insidious costs that sneak up that employees tend to discount, like, one thing I always talk about with my team is all that time you're thinking about a problem at work, right, like when you're in the shower, when you're at dinner, when you're talking it over with your spouse, right? That's work. That's work. And it's work that you're doing on your time.But we don't account for it that way because we're not typing; we're not writing code. But, like, think about how much more effective as people, as employees, we would be if we had time dedicated to just sit and think, right? If I could just sit and think about a problem without needing to type but just critically think about it. But then it's like, well, what does that look like in the office, right? If I'm just sitting there in my chair like this, it doesn't look like I'm doing anything.But that's so important to be able to, like, break down and digest some of the complex problems that we're dealing with. And we just sort of write it off, right? So, I'm like, you know, you got to think about how that bleeds into your personal time and take that into account. So yeah, maybe you leave three hours early today, but I guarantee you, you're going to spend three hours throughout the week thinking about work. It's the same thing with these cellphone costs that you're talking about, right? “Oh, I've got a cell phone anyways; I've got internet anyways.” But still, that's something that you're contributing to the business that they're not on the hook for, so it seems fair that you get compensated for that.Corey: I just think about that stuff all the time from that perspective, and now that I you know, own the place, it's one of those which pocket of mine does it come out of? But I hold myself to a far higher standard about that stuff than I do the staff, where it's, for example, I could theoretically justify paying my internet bill here because we have business-class internet and an insane WiFi system because of all of the ridiculous video production I do. Now. It's like, like, if anyone else on the team was doing this, yes, I will insist we pay it, but for me, it just it feels a little close to the edge. So, it's one of those areas where I'm very conservative around things like that.The thing that also continues to just vex me, on some level, is this idea that time in a seat is somehow considered work. I'll never forget one of the last jobs I had before I started this place. My boss walked past me and saw that I was on Reddit. And, “Is that really the best use of your time right now?” May I use the bathroom when I'm done with this, sir?Yeah, of course it is. It sounds ridiculous, but one of the most valuable things I can do for The Duckbill Group now is go on the internet and start shit posting on Twitter, which sounds ridiculous, but it's also true. There's a brand awareness story there, on some level. And that's just wild to me. It's weird, we start treating people like adults, they start behaving that way. And if you start micromanaging them, they live up or down to the expectations you tend to hold. I'm a big believer in if I have to micromanage someone, I should just do the job myself.Jeff: Yeah. The Reddit story makes me think of, like, how few organizations have systematic ways of getting vital information. So, the first thing I think about is, like, security and security vulnerabilities, right? So, how does Basis Technologies, as an organization, know about these things? Right now, it's like, well, my team knows because we're plugged into Reddit and Twitter, right, but if we were gone Basis, right, may not necessarily get that information.So, that's something we're trying to correct, but it just sort of highlights the importance of freedom for these employees, right? Because yeah, I'm on Reddit, but I'm on /r/sysadmin. I'm on /r/AWS, right, I'm on /r/Atlassian. Now I'm finding out about this zero-day vulnerability and it's like, “Oh, guys, we got to act. I just heard about this thing.” And people are like, “Oh, where did this come from?” And it's like it came from my network, right? And my network—Corey: Mm-hm.Jeff: Is on Twitter, LinkedIn, Reddit. So, the idea that someone browsing the internet on any site, really, is somehow not a productive use of their time, you better be ready to itemize exactly what that means and what that looks like. “Oh, you can do this on Reddit but you can't do that on Reddit.”Corey: I have no boss now, I have no oversight, but somehow I still show up with a work ethic and get things done.Jeff: Right. [laugh].Corey: Wow, I guess I didn't need someone over my shoulder the whole time. Who knew?Jeff: Right. That's all that matters, right? And if you do it in 30 hours or 40 hours, that doesn't really matter to me, you know? You want to do it at night because you're more productive there, right, like, let's figure out a way to make that happen. And remote work is actually empowering us ways to really retain people that wasn't possible before I had an employee that was like, you know, I really want to travel. I'm like, “Dude, go to Europe. Work from Europe. Just do it. Work from Europe,” right? We've got senior leaders on the C-suite that are doing it. One of the chief—Corey: I'm told they have the internet, even there. Imagine that?Jeff: Yeah. [laugh]. So, our chief program officer, she was in Greece for four weeks. And it worked. It worked great. They had a process. You know, she would spent one week on and then one week off on vacation. But you know, she was able to have this incredible, long experience, and still deliver. And it's like, you know, we can use that as a model to say, like—Corey: And somehow the work got done. Wow, she must be amazing. No, that's the baseline expectation that people can be self-managing in that respect.Jeff: Right.Corey: They aren't toddlers.Jeff: So, if she can do that, I'm sure you can figure out how to code in China or wherever you want to visit. So, it's a great way to stay ahead of some of these companies that have a bit more lethargic policies around that stuff, where it's like, you know, all right, I'm not getting that insane salary, but guess what, I'm going to spend three weeks in New Zealand hanging out and not using any time off or anything like that, and you know, being able to enjoy life. I wish this pandemic had happened pre-kids because—Corey: Yeah. [laugh].Jeff: —you know, we would really take advantage of this.Corey: You and me both. It would have very different experience.Jeff: Yeah. [laugh]. Absolutely, right? But with kids in school, and all that stuff, we've been tethered down. But man, I you know, I want to encourage the young people or the single people on my team to just, like, hey, really, really embrace this time and take advantage of it.Corey: I come bearing ill tidings. Developers are responsible for more than ever these days. Not just the code that they write, but also the containers and the cloud infrastructure that their apps run on. Because serverless means it's still somebody's problem. And a big part of that responsibility is app security from code to cloud. And that's where our friend Snyk comes in. Snyk is a frictionless security platform that meets developers where they are - Finding and fixing vulnerabilities right from the CLI, IDEs, Repos, and Pipelines. Snyk integrates seamlessly with AWS offerings like code pipeline, EKS, ECR, and more! As well as things you're actually likely to be using. Deploy on AWS, secure with Snyk. Learn more at Snyk.co/scream That's S-N-Y-K.co/screamCorey: One last topic I want to get into before we call it an episode is, I admit, I read an awful lot of books, it's a guilty pleasure. And it's easy to fall into the trap, especially when you know the author, of assuming that snapshot of their state of mind at a very fixed point in time is somehow who they are, like a fly frozen in amber, and it's never true. So, my question for you is, quite simply, what have you learned since your book came out?Jeff: Oh, man, great question. So, when I was writing the book, I was really nervous about if my audience was as big as I thought it was, the people that I was targeting with the book.Corey: Okay, that keeps me up at night, too. I have no argument there.Jeff: Yeah. You know what I mean?Corey: Please, continue.Jeff: I'm surrounded, you know, by—Corey: Is anyone actually listening to this? Yeah.Jeff: Right. [laugh]. So, after the book got finished and it got published, I would get tons of feedback from people that so thoroughly enjoyed the book, they would say things like, you know, “It feels like you were in our office like a fly on the wall.” And that was exciting, one, because I felt like these were experiences that sort of resonated, but, two, it sort of proved this thesis that sometimes you don't have to do something revolutionary to be a positive contribution to other people, right? So, like, when I lay out the tips and things that I do in the book, it's nothing earth-shattering that I expect Google to adopt. Like, oh, my God, this is the most unique view ever.But being able to talk to an audience in a way that resonates with them, that connects with them, that shows that I understand their problem and have been there, it was really humbling and enlightening to just see that there are people out there that they're not on the bleeding edge, but they just need someone to talk to them in a language that they understand and resonate with. So, I think the biggest thing that I learned was this idea that your voice is important, your voice matters, and how you tell your story may be the difference between someone understanding a concept and someone not understanding a concept. So, there's always an audience for you out there as you're writing, whether it be your blog post, the videos that you produce, the podcasts that you make, somewhere there's someone that needs to hear what you have to say, and the unique way that you can say it. So, that was extremely powerful.Corey: Part of the challenge that I found is when I start talking to other people, back in the before times, trying to push them into conference talks and these days, write blog posts, the biggest objection I get sometimes is, “Well, I don't have anything worth saying.” That is provably not true. One of my favorite parts about writing Last Week in AWS is as I troll the internet looking for topics about AWS that I find interesting, I keep coming across people who are very involved in one area or another of this ecosystem and have stories they want to tell. And I love, “Hey, would you like to write a guest post for Last Week in AWS?” It's always invite only and every single one of them has been paid because people die of exposure and I'm not about that exploitation lifestyle.A couple have said, “Oh, I can't accept payment for a variety of reasons.” Great. Pick a charity that you would like it to go to instead because we do not accept volunteer work, we are a for-profit entity. That is the way it works here. And that has been just one of the absolute favorite parts about what I do just because you get to sort of discover new voices.And what I find really neat is that for a lot of these folks, this is their start to writing and telling the story, but they don't stop there, they start telling their story in other areas, too. It leads to interesting career opportunities for them, it leads to interesting exposure that they wouldn't have necessarily had—again, not that they're getting paid in exposure, but the fact that they are able to be exposed to different methodologies, different ways of thinking—I love that. It's one of my favorite parts about doing what I do. And it seems to scale a hell of a lot better than me sitting down with someone for two hours to help them build a CFP that they wind up not getting accepted or whatnot.Jeff: Right. It's a great opportunity that you provide folks, too, because of, like, an instant audience, I think that's one of the things that has made Medium so successful as, like, a blogging platform is, you know, everyone wants to go out and build their own WordPress site and launch it, but then it like, you write your blog post and it's crickets. So, the ability for you to, you know, use your platform to also expose those voices is great and extremely powerful. But you're right, once they do it, it lights a fire in a way that is admirable to watch. I have a person that I'm mentoring and that was my biggest piece of advice I can give. It was like, you know, write. Just write.It's the one thing that you can do without anyone else. And you can reinforce your own knowledge of a thing. If you just say, you know, I'm going to teach this thing that I just learned, just the writing process helps you solidify, like, okay, I know this stuff. I'm demonstrating that I know it and then four years from now, when you're applying for a job, someone's like, “Oh, I found your blog post and I see that you actually do know how to set up a Kubernetes cluster,” or whatever. It's just extremely great and it—Corey: It's always fun. You're googling for how to do something and you find something you wrote five years ago.Jeff: Right, yeah. [laugh]. And it's like code where you're like, “Oh, man, I would do that so much differently now.”Corey: Since we last spoke, one of the things I've been doing is I have been on the hook to write between a one to two-thousand-word blog post every week, and I've done that like clockwork, for about a year-and-a-half now. And I was no slouch at storytelling before I started doing that. I've given a few hundred conference talks in the before times. And I do obviously long Twitter threads in the past and I write reports a lot. But forcing me to go through that process every week and then sit with an editor and go ahead and get it improved, has made me a far better writer, it's made me a better storyteller, I am far better at articulating my point of view.It is absolutely just unlocking a host of benefits that I would have thought I was, oh, I passed all this. I'm already good at these things. And I was, but I'm better now. I think that writing is one of those things that people need to do a lot more of.Jeff: Absolutely. And it's funny that you mentioned that because I just recently, back in April, started to do the same thing I said, I'm going to write a blog post every week, right? I'm going to get three or four in the can, so that if life comes up and I miss a beat, right, I'm not actually missing the production schedule, so I have a steady—and you're right. Even after writing a book, I'm still learning stuff through the writing process, articulating my point of view.It's just something that carries over, and it carries over into the workforce, too. Like, if you've ever read a bad piece of documentation, right, that comes from—Corey: No.Jeff: Right? [laugh]. That comes from an inability to write. Like, you know, you end up asking these questions like who's the audience for this? What is ‘it' in this sentence? [laugh].Corey: Part of it too, is that people writing these things are so close to the problem themselves that the fact that, “Well, I'm not an expert in this.” That's why you should write about it. Talk about your experience. You're afraid everyone's going to say, “Oh, you're a fool. You didn't understand how this works.”Yeah, my lived experiences instead—and admittedly, I have the winds of privilege of my back on this—but it's also yeah, I didn't understand that either. It turns out that you're never the only person who has trouble with a concept. And by calling it out, you're normalizing it and doing a tremendous service for others in your shoes.Jeff: Especially when you're not an expert because I wrote some documentation about the SSL process and it didn't occur to me that these people don't use the AWS command line, right? Like, you know, in our organization, we sort of mask that from them through a bunch of in-house automation. Now we're starting to expose it to them and simple things like oh, you need to preface the AWS command with a profile name. So, then when we're going through the setup, we're like, “Oh. What if they already have an existing profile, right?” Like, we don't want to clobber that.SSo, it just changed the way you write the documentation. But like, that's not something that initially came to mind for me. It wasn't until someone went through the docs, and they're like, “Uh, this is blowing up in a weird way.” And I was like, “Oh, right. You know, like, I need to also teach you about profile management.”Corey: Also, everyone has a slightly different workflow for the way they interact with AWS accounts, and their shell prompts, and the way they set up local dev environments.Jeff: Yeah, absolutely. So, not being an expert on a thing is key because you're coming to it with virgin eyes, right, and you're able to look at it from a fresh perspective.Corey: So, much documentation out there is always coming from the perspective of someone who is intimately familiar with the problem space. Some of the more interesting episodes that I have, from a challenge perspective, are people who are deep technologists in a particular area and they love they fallen in love with the thing that they are building. Great. Can you explain it to the rest of us mere mortals so that we can actually we can share your excitement on this? And it's very hard to get them to come down to a level where it's coherent to folks who haven't spent years thinking deeply about that particular problem space.Jeff: Man, the number one culprit for that is, like, the AWS blogs where they have, like, a how-to article. You follow that thing and you're like, “None of this is working.” [laugh]. Right? And then you realize, oh, they made an assumption that I knew this, but I didn't right?So, it's like, you know, I didn't realize this was supposed to be, like, a handwritten JSON document just jammed into the value field. Because I didn't know that, I'm not pulling those values out as JSON. I'm expecting that just to be, like, a straight string value. And that has happened more and more times on the AWS blog than I can count. [laugh].Corey: Oh, yeah, very often. And then there's other problems, too. “Oh, yeah. Set up your IAM permissions properly.” That's left as an exercise for the reader. And then you wonder why everything's full of stars. Okay.Jeff: Right. Yep, exactly, exactly.Corey: Ugh. It's so great to catch up with you and see what you've been working on. If people want to learn more, where's the best place to find you?Jeff: So, the best place is probably my website, attainabledevops.com. That's a place where you can find me on all the other places. I don't really update that site much, but you can find me on LinkedIn, Twitter, from that jumping off point, links to the book are there if anyone's interested in that. Perfect stocking stuffers. Mom would love it, grandma would love it, so definitely, definitely buy multiple copies of that.Corey: Yeah, it's going to be one of my two-year-old's learning to read books, it'd be great.Jeff: Yeah, it's perfect. You know, you just throw it in the crib and walk away, right? They're asleep at no time. Like I said, I've also been taking to, you know, blogging on Medium, so you can catch me there, the links will be there on Attainable DevOps as well.Corey: Excellent. And that link will of course, be in the show notes. Thank you so much for being so generous with your time. I really do appreciate it. And it's great to talk to you again.Jeff: It was great to catch up.Corey: Really was. Jeff Smith, Director of Product Operations at Basis Technologies. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice or smash the like and subscribe buttons on the YouTubes, whereas if you've hated this podcast, do the exact same thing—five-star review, smash the buttons—but also leave an angry, incoherent comment that you're then going to have edited and every week you're going to come back and write another incoherent comment that you get edited. And in the fullness of time, you'll get much better at writing angry, incoherent comments.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

2022-07-26 Weekly News - Episode 158Watch the video version on YouTube at https://youtu.be/M8V2rQEwl6s Hosts:  Gavin Pickin - Senior Developer at Ortus Solutions Dan Card - Senior Developer at Ortus Solutions Thanks to our Sponsor - Ortus SolutionsThe makers of ColdBox, CommandBox, ForgeBox, TestBox and all your favorite box-es out there. A few ways  to say thanks back to Ortus Solutions: BUY SOME ITB TICKETS - COME TO THE CONFERENCE - Have a few laughs! Like and subscribe to our videos on YouTube.  Help ORTUS reach for the Stars - Star and Fork our ReposStar all of your Github Box Dependencies from CommandBox with https://www.forgebox.io/view/commandbox-github  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 BOXLife store: https://www.ortussolutions.com/about-us/shop Buy Ortus's Book - 102 ColdBox HMVC Quick Tips and Tricks on GumRoad (http://gum.co/coldbox-tips)  Patreon SupportGoal 1 - We have 37 patreons providing 100% of the funding for our Modernize or Die Podcasts via our Patreon site: https://www.patreon.com/ortussolutions. Goal 2 - We are 44% of the way to fully fund the hosting of ForgeBox.io News and AnnouncementsICYMI - Adobe Developer Week was last week! July 18-22ndThe Adobe ColdFusion Developer Week is back - bigger and better than ever! This year, our experts are gearing up to host a series of webinars on all things ColdFusion. This is your chance to learn with them, get your questions answered, and build cloud-native applications with ease.Gavin and Luis presented Monday - more great content to comeWhat are you waiting for? Register now!Site Link: https://adobe-coldfusion-devweek-2022.attendease.com/registration/form Recordings: Most recent videos https://www.youtube.com/c/adobecoldfusion/videos Blog - https://coldfusion.adobe.com/2022/07/all-devweek-2022-videos-now-posted-on-youtube/ ICYMI - How does CFML really perform compared to other languages?I've talked about the TechEmpower performance benchmarks before, but I wanted to highlight them again. They are the closest thing the internet has to a giant cage match between nearly every language and framework out there. The benchmarks have a suite of tests, such as run 20 queries on a page and output some data, and every language and framework implements the same logic in their syntax and style. The tests literally take days to run in full and spin up each combination of language and framework in docker containers where they are hammered with oodles of traffic and then the juicy stats are recorded for sweet graphical comparisons.https://community.ortussolutions.com/t/how-does-cfml-really-perform-compared-to-other-languages/9325 INTO THE BOX - Updates1 month left to the start of the Pre-Conf, the Workshop and 2 days of 2 track content. ITB In Person Schedule Finalized on the WebsiteWorkshops are starting to fill up - don't miss your chance.https://intothebox.org/ New Releases and UpdatesCFConfig - Now supports Scheduled Tasks in LuceeThanks to a sponsor, CFConfig now supports importing/exporting scheduled tasks for #Lucee Server (Adobe already had support)!  Please give it a test with the latest version and remember, tasks need imported into the web context of Lucee! #CommandBox #CFML #ColdFusionhttps://www.forgebox.io/view/commandbox-cfconfigWebinar / Meetups and WorkshopsICYMI - July 2022 Seattle ColdFusion User Group Meeting - Hello ColdFusion! by Leon O'Daniel - Cancelledhttps://www.meetup.com/seattle-coldfusion-user-group/events/286888783/ Ortus Webinar - July - Legacy Migration Follow Up: Using Coldbox with an Existing Code BaseJuly 29th 2022: Time 11:00 AM Central Time ( US and Canada )Dan Card will be presenting a follow up to his June webinar: Getting started with the Legacy Migration. Dan received some good questions, so July's Webinar: Legacy Migration Follow Up: Using Coldbox with an Existing Code Base with Dan Card. If you have a more traditional / legacy codebase, and are wanting to modernize with ColdBox, but don't know where to start, this webinar is just for you!with Dan Cardhttps://us02web.zoom.us/meeting/register/tZArde-srjgiGtUVIWhhVRmMpSgang6yqCzA Adobe WorkshopsJoin the Adobe ColdFusion Workshop to learn how you and your agency can leverage ColdFusion to create amazing web content. This one-day training will cover all facets of Adobe ColdFusion that developers need to build applications that can run across multiple cloud providers or on-premiseTUESDAY, AUGUST 9, 20229.00 AM - 4.30 PM AESTColdFusion WorkshopBrian Sappeyhttps://coldfusion-1-day-training.meetus.adobeevents.com/ WEBINAR - THURSDAY, AUGUST 18, 202210:00 AM PDTMaking Games with Adobe ColdFusionMark Takatahttps://making-games-with-adobe-coldfusion.meetus.adobeevents.com/FREE :)Full list - https://meetus.adobeevents.com/coldfusion/ CFCasts Content Updateshttps://www.cfcasts.comJust Released LogBox 101 - 1 new videos - https://cfcasts.com/series/logbox-101 Episode 9 - Tracer Appender - https://www.cfcasts.com/series/logbox-101/videos/tracerappender  Koding with the Kiwi + Friends2022-07-15 - Koding with the Kiwi + Friends - Wil De Bruin - Talking about Validation - https://cfcasts.com/series/koding-with-the-kiwi-+-friends/videos/20220719-koding-with-the-kiwi-+-friends-wil-de-bruin-validation 2022 ForgeBox Module of the Week Series - 1 new Video https://cfcasts.com/series/2022-forgebox-modules-of-the-week 2022 VS Code Hint tip and Trick of the Week Series - 1 new Video - https://cfcasts.com/series/2022-vs-code-hint-tip-and-trick-of-the-week  Coming Soon LogBox 101 from Eric Peterson Koding with the Kiwi + Friends More ForgeBox and VS Code Podcast snippet videos Box-ifying a 3rd Party Library from Gavin ColdBox Elixir from Eric Conferences and TrainingICYMI - Adobe Developer Week 2022 - Last Week!!!!July 18-22, 2022Online - Virtual - FreeThe Adobe ColdFusion Developer Week is back - bigger and better than ever! This year, our experts are gearing up to host a series of webinars on all things ColdFusion. This is your chance to learn with them, get your questions answered, and build cloud-native applications with ease.Speakers have been announcedAgenda has been announcedhttps://adobe-coldfusion-devweek-2022.attendease.com/registration/form https://www.youtube.com/c/adobecoldfusion/videos THAT ConferenceHowdy. We're a full-stack, tech-obsessed community of fun, code-loving humans who share and learn together.We geek-out in Texas and Wisconsin once a year but we host digital events all the time.WISCONSIN DELLS, WI / JULY 25TH - 28TH, 2022A four-day summer camp for developers passionate about learning all things mobile, web, cloud, and technology.https://that.us/events/wi/2022/ Our very own Daniel Garcia is speaking there Easier API Development and Testing - Use PostMan, Webhook.site, and ngrok to Enhance Your Workflowhttps://that.us/activities/sb6dRP8ZNIBIKngxswIt Into The Box 2022September 6, 7 and 8, 2022 in Houston, TexasOne day workshops before the two day conference!Sign up for the workshops before they fill up - couple are almost filledConference Website:https://intothebox.orgCF Summit - OfficialMirageOct 3rd & 4th - CFSummit ConferenceOct 5th - Adobe Certified Professional: Adobe ColdFusion Certification Classes & Testshttps://cfsummit.adobeevents.com/ https://www.adobe.com/products/coldfusion-family/certificate.html Registrations are now open.Ortus CF Summit Training WorkshopColdBox Zero to MegaHero : REST APIs + VueJS Mobile AppOct 5th and 6th - After CF Summit ConferenceLead by Luis Majano & Gavin PickinPrice: $799 - Early bird pricinghttps://www.eventbrite.com/e/ortus-cf-summit-training-workshop-tickets-375306340367Location: Aria - In the luxurious Executive Hospitality Suite like 2019The suite doubled it's prices but we're working hard to keep the costs to the attendees the sameInto the Box Latam 2022Dec 5th or 7thMore information is coming very soon.CFCampNo CFCAMP 2022, we're trying again for summer 2023TLDR is that it's just too hard and there's too much uncertainty right now.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 Week 7/26/22 - Blog - Charlie Arehart - All DevWeek 2022 videos now posted on YoutubeGreat news: the recordings for all 17 of the sessions from Adobe ColdFusion DevWeek 2022 are now posted on Youtube, in the AdobeColdFusion Youtube channel.https://coldfusion.adobe.com/2022/07/all-devweek-2022-videos-now-posted-on-youtube/ 7/26/22 - Blog - Ben Nadel - Pretty-Printing JSON Using GSON In Lucee CFML 5.3.9.141I'm currently working on a proof-of-concept (POC) for a feature flag system in Lucee CFML. And, for my POC data persistence layer, I've been using a simple, flat JSON (JavaScript Object Notation) text file. This works great; but, I found myself wishing that the JSON file was pretty-printed so that I could more easily debug my data persistence algorithms. ColdFusion's native serializeJson() function doesn't have a pretty-print feature; but, I was able to use Google's GSON library to generate pretty-printed JSON output in Lucee CFML 5.3.9.141.https://www.bennadel.com/blog/4302-pretty-printing-json-using-gson-in-lucee-cfml-5-3-9-141.htm 7/23/22 - Blog - Ben Nadel - Using Multiple Break Statements In A Single Case Clause In ColdFusionFor the last few weeks, I've been quasi-heads-down, noodling on a workflow that builds-up complex objects using form POSTs in ColdFusion; and, as part of that workflow, I have a switch statement that defines some mutations on the pending-object in question. The other day, my logic was getting a bit complicated and I went to see if I could use multiple break statements within a single case clause. Turn out, this totally works in ColdFusion.https://www.bennadel.com/blog/4301-using-multiple-break-statements-in-a-single-case-clause-in-coldfusion.htm 7/22/22 - Tweet - Brad Wood - Deep Dark HoleI've spent the last week climbing down into the deep, dark hole that is client cert authentication. I have a POC working in CommandBox now and I'm attempting to claw my way back out of the hole to figure out how to get it all implemented and tested