Podcasts about Bitbucket

Quasi alle Entwickler:innen da draußen nutzen Code-Versionierungssysteme. Alle haben einen GitHub-Account – manche nutzen Alternativen wie GitLab oder BitBucket. Die wenigsten machen sich aber Gedanken darüber, was es heißt, den eigenen (mitunter freien) Code einem kommerziellen Anbieter anzuvertrauen.Nicht so Andreas Shimokawa. Nachdem er mit einem Open-Source-Projekt einer falschen DMCA-Meldung zum Opfer gefallen war, beschloss er, eine freie Alternative zu den gängigen Code-Hosting-Plattformen aufzubauen. Nach europäischem Recht, mit Standort in Deutschland, getragen von einem gemeinnützigen Verein. Und schon war Codeberg geboren.Zusammen mit einigen Vereinsmitgliedern und Freiwilligen aus der Community betreiben sie nun eine Plattform mit hunderttausenden Mitgliedern und Projekten. Wir sprechen mit Andreas über seine ganz persönliche Motivation, die technischen und organisatorischen Herausforderungen, und überlegen gemeinsam, wo die Reise für Codeberg noch hingehen kann.PS: Das von Garrelt erwähnte Gewinnspiel ist zum Zeitpunkt der Veröffentlichung dieser Podcastfolge leider schon beendet.Schreibt uns! Schickt uns eure Themenwünsche und euer Feedback: podcast@programmier.barFolgt uns! Bleibt auf dem Laufenden über zukünftige Folgen und virtuelle Meetups und beteiligt euch an Community-Diskussionen. BlueskyInstagramLinkedInMeetupYouTubeMusik: Hanimo

Nesse episódio trouxemos as notícias e novidades do mundo da programação que nos chamaram atenção dos dias 18/01 a 24/01.

Nesse episódio trouxemos as notícias e novidades do mundo da programação que nos chamaram atenção dos dias 18/01 a 24/01.

Corey Quinn chats with Dylan Etkin, CEO and co-founder of Sleuth. He joins this episode of Screaming Into the Cloud to share his insights on reshaping engineering metrics to prioritize team success. Sleuth emphasizes team-level productivity over individual output, sidestepping controversial metrics like lines of code and focusing on alignment and iterative improvement. By aggregating data from tools like GitHub, Jira, and Datadog, Sleuth provides actionable insights, helping leaders reallocate resources for optimal impact without disrupting unique team workflows. Designed for collaborative review, Sleuth's slide deck-like interface supports meaningful discussions around DORA metrics and deploy tracking. Show Highlights(0:00) Intro(0:51) Sleuth sponsor read(1:12) What Sleuth is(2:02) How Sleuth evaluates engineers' work(5:41) The value that evaluations brings to a business(9:34) Who Dylan usually discusses results with(11:04) Sleuth sponsor read(11:30) The day-to-day experience of using Sleuth(14:23) The importance of meeting people where they are(18:21) The actual outcome of implementing Sleuth(20:27) Why engineering teams should care about metrics(24:27) The interface that people have when they're working with Sleuth(26:23) Where you can find more from SleuthAbout Dylan EtkinDylan was one of the first twenty employees of Atlassian, and a founding engineer and the first architect of Jira. He has led engineering at scale for Bitbucket and Statuspage. He has a Master's in Computer Science from ASU. Dylan is a bit of a space nut and has been seen climbing around the inside of a life-size replica of the Mir space station in Star City Russia.SponsorSleuth: https://www.sleuth.io/ 

Welcome back to our series on the developer journey. In this episode, we tackle one of the most crucial yet often neglected aspects of development: the power of documentation. While it might seem tedious, proper documentation is vital to enhancing your workflow and ensuring that your work is accessible and understandable for others. Why The Power of Documentation Matters Developer documentation is often the unsung hero in the software development lifecycle. Many developers overlook it, leading to frustration down the line when they or their colleagues struggle to understand undocumented code. Documentation is akin to testing: everyone acknowledges its importance, yet it frequently gets pushed aside due to time constraints. This negligence can result in messy, hard-to-navigate codebases. The truth is that high-quality documentation is indispensable. It's not just about creating records but ensuring that your code's functionality is clear and easily understandable for anyone who might work with it in the future. Good documentation reflects your professionalism and dedication, whether you're writing APIs or developing software. Leverage Modern Tools The good news is that documenting your work has never been easier. Today's tools have revolutionized how we approach documentation, making it more integrated and less of a chore. For instance, if you're building APIs, tools like Swagger (now known as OpenAPI) can auto-generate user-friendly and comprehensive documentation. Similarly, Postman not only helps with API testing but also assists in creating documentation. In addition, static code analysis tools can help highlight areas that may require documentation, but they're only part of the solution. Modern auto-generation tools like Javadoc have set a precedent for documentation in various languages. Whether you're working with Java, Python, or JavaScript, there's likely a tool available to auto-generate documentation for your code. The key is to explore and understand what's available for your specific environment. Integrate the Power of Documentation Throughout the Development Process Documentation should be seamlessly integrated into every phase of development. It's not limited to code comments or README files; it extends to comprehensive setup guides, deployment instructions, and user manuals. For instance, ensuring your README file includes details on how to set up and deploy the application can save a lot of time for those who come after you. Moreover, tools like GitHub, Bitbucket, and Atlassian provide robust platforms for managing documentation alongside code. With these tools, you can create wikis, track issues, and maintain up-to-date documentation that evolves with your project. This way, your documentation is accurate and consistently synchronized with your codebase. The Power of Documentation for Different Audiences Understanding your audience is crucial. Developer documentation must often cater to various stakeholders, including developers, testers, and end-users. Here's a breakdown of what each might require: Developers: Need detailed comments on functions, classes, and APIs. This includes input parameters, return types, and possible exceptions. Well-commented code makes it easier for other developers to pick up where you left off without digging through the entire codebase. Testers: Require information on how the application should behave under different conditions. This includes setup instructions, test cases, and expected outcomes. A clear test plan and test case documentation can streamline the quality assurance process. End-users: They need user manuals and release notes that explain how to use the application and what's new in updates. This documentation should be clear, concise, and tailored to the user's level of expertise. Embracing the Power of Documentation Good documentation is more than just a set of guidelines or instructions; it's essential to a well-oiled development machine. When done right, it transforms the way teams work together, reduces the likelihood of costly errors, and ensures that your code can be easily maintained and evolved. By prioritizing documentation, you're investing in the long-term health of your projects. It fosters collaboration, enhances understanding, and leads to more reliable and robust software. In a fast-paced development environment, where changes are constant, and the stakes are high, having thorough and accessible documentation is not just a best practice—it's a competitive advantage. So, as you continue your development journey, remember that documentation isn't a task to be completed and forgotten. It's an ongoing process that should evolve with your code, adapting to new features, updates, and changes. Embrace, champion, and make it a core part of your development process. In doing so, you'll improve your efficiency and contribute to a culture of clarity and excellence in software development. Stay Connected: Join the Developreneur Community We invite you to join our community and share your coding journey with us. Whether you're a seasoned developer or just starting, there's always room to learn and grow together. Contact us at info@develpreneur.com with your questions, feedback, or suggestions for future episodes. Together, let's continue exploring the exciting world of software development. Additional Resources Organizing Business Documentation: A Critical Challenge for Entrepreneurs Test-Driven Development – A Better Object-Oriented Design Approach SDLC – The software development life cycle is simplified Using a Document Repository To Become a Better Developer The Developer Journey Videos – With Bonus Content

Welcome to episode 265 of the Cloud Pod Podcast – where the forecast is always cloudy! This week, Jonathan, Ryan, and Justin are trying to keep cool in new WorkSpaces Pools, avoiding the Heatwave with Oracle's new LLM,  taking a look at AWS Jamba (hold the straw) and taking a look at the ever elusive Cloud Maturity.  All this news and more, this week on The Cloud Pod!  Titles we almost went with this week: The Cloud Pod takes a dip in the Workspaces Pool The Cloud Pod Lineage view is suspect A Gitlab, A BitBucket, and a Blueprint build a Workspaces Pool AWS goes for a Jamba Juice  Google Cloud Autokey does exactly what it sounds like Oracle LLM Heatwaves send us to the Amazon Workspace Pool Jonathan is unimpressed with this weeks show Highway to the DataZone  A big thanks to this week's sponsor: We're sponsorless! Want to reach a dedicated audience of cloud engineers? Send us an email or hit us up on our Slack Channel and let's chat!  General News 01:03 HashiCorp State of Cloud Strategy Survey 2024: Cloud Maturity is Elusive but Valuable Hashicorp just released the results of its State of Cloud Survey, and guess what? Cloud maturity is pretty elusive. Weird…  Hashicorp finds that 8% of organizations qualify as Highly Mature, this results that the biggest benefits are cloud is only going to a small group of truly mature organizations.  Justin wonders if this is part of the cloud repatriation push?  Are other listeners seeing some of this, especially on places like LinkedIn? We'd love to hear.  Trailblazers are finding faster development speed, lower costs and reduced risks while others continue to struggle to create haves and have nots with enterprises getting different business outcomes.  Hashicorp collected responses from almost 1,200 technology practitioners and decision makers at organizations with more than 1000 employees.  66% of respondents report that they have increased cloud spending in the last year, but 91% believe they are wasting money in the cloud, and 64% are experiencing a shortage of skilled staff. 45% of low maturity organizations are still waiting for their cloud strategy to pay off! One of the key takeaways from the survey is that the path to cloud maturity increasingly relies on platform teams to help automate and systemize cloud operations.  However, only half the respondents 42% say they rely on centralized platform teams to standardize cloud operations throughout their organization.  Platform teams help manage cloud, but also help address the skills shortage that has long plagued enterprise cloud adoption. If only they'd pay for training. 03:22 Jonathan – “The skill shortage thing really bugs me sometimes because there are plenty of skilled workers around and the reccs aren’t open for them. So I don’t think there aren’t qualified staff… yeah, it’s not a shortage because of the lac

✨Use this link for a free month of O'Reilly Learning and read Anna's book and any other resource on the platform! ✨ Meet Anna Skoulikari! She's a UX designer turned front-end developer, senior technical writer, and the author of "Learning Git" - a book published by O'Reilly Media that teaches Git in a simple, visual, and tangible manner so that you can build a solid mental model of how it all works.Anna started teaching Git because she had to understand it herself. It's powerful but not the most user-friendly of tools. Yet, Git is what we all have in common, whether we're working on back-end or front-end development, on Windows or a Mac. Even GitHub's lawyers use Git!If you're learning to code, you probably have many questions. Should you use GitHub, GitLab, or Bitbucket? What's the difference between a merge request and a pull request? Does it make sense to use Git from your command line, or is a GUI good enough? Where are all those files? And how, for the last time, does any of that work? This episode will help you understand Git and provide you with plenty of practical insights to navigate its complexities effectively.

In Elixir Wizards Office Hours Episode 2, "Discovery Discoveries," SmartLogic's Project Manager Alicia Brindisi and VP of Delivery Bri LaVorgna join Elixir Wizards Sundi Myint and Owen Bickford on an exploratory journey through the discovery phase of the software development lifecycle. This episode highlights how collaboration and communication transform the client-project team dynamic into a customized expedition. The goal of discovery is to reveal clear business goals, understand the end user, pinpoint key project objectives, and meticulously document the path forward in a Product Requirements Document (PRD). The discussion emphasizes the importance of fostering transparency, trust, and open communication. Through a mutual exchange of ideas, we are able to create the most tailored, efficient solutions that meet the client's current goals and their vision for the future. Key topics discussed in this episode: Mastering the art of tailored, collaborative discovery Navigating business landscapes and user experiences with empathy Sculpting project objectives and architectural blueprints Continuously capturing discoveries and refining documentation Striking the perfect balance between flexibility and structured processes Steering clear of scope creep while managing expectations Tapping into collective wisdom for ongoing discovery Building and sustaining a foundation of trust and transparency Links mentioned in this episode: https://smartlogic.io/ Follow SmartLogic on social media: https://twitter.com/smartlogic Contact Bri: bri@smartlogic.io What is a PRD? https://en.wikipedia.org/wiki/Productrequirementsdocument Special Guests: Alicia Brindisi and Bri LaVorgna.

If your IT and security teams think malware is bad, wait until they learn about everything else.In 2024, the modern cyberattack is a segmented, prolonged, and professional effort, in which specialists create strictly financial alliances to plant malware on unsuspecting employees, steal corporate credentials, slip into business networks, and, for a period of days if not weeks, simply sit and watch and test and prod, escalating their privileges while refraining from installing any noisy hacking tools that could be flagged by detection-based antivirus scans. In fact, some attacks have gone so "quiet" that they involve no malware at all. Last year, some ransomware gangs refrained from deploying ransomware in their own attacks, opting to steal sensitive data and then threaten to publish it online if their victims refused to pay up—a method of extracting a ransom that is entirely without ransomware. Understandably, security teams are outflanked. Defending against sophisticated, multifaceted attacks takes resources, technologies, and human expertise. But not every organization has that at hand. What, then, are IT-constrained businesses to do? Today, on the Lock and Code podcast with host David Ruiz, we speak with Jason Haddix, the former Chief Information Security Officer at the videogame developer Ubisoft, about how he and his colleagues from other companies faced off against modern adversaries who, during a prolonged crime spree, plundered employee credentials from the dark web, subverted corporate 2FA protections, and leaned heavily on internal web access to steal sensitive documentation. Haddix, who launched his own cybersecurity training and consulting firm Arcanum Information Security this year, said he learned so much during his time at Ubisoft that he and his peers in the industry coined a new, humorous term for attacks that abuse internet-connected platforms: "A browser and a dream." "When you first hear that, you're like, 'Okay, what could a browser give you inside of an organization?'" But Haddix made it clear: "On the internal LAN, you have knowledge bases like SharePoint, Confluence, MediaWiki. You have dev and project management sites like Trello, local Jira, local Redmine. You have source code managers, which are managed via websites—Git, GitHub, GitLab, Bitbucket, Subversion. You have repo management, build servers, dev platforms, configuration, management platforms, operations, front ends. These are all websites."Tune in today. You can also find us on Apple Podcasts, Spotify, and Google Podcasts, plus whatever preferred podcast platform you use.For all our cybersecurity coverage, visit Malwarebytes Labs at malwarebytes.com/blog.Show notes and credits:Intro Music: “Spellbound” by Kevin MacLeod (incompetech.com)Licensed under Creative Commons: By Attribution 4.0 Licensehttp://creativecommons.org/licenses/by/4.0/Outro Music: “Good God” by Wowa (unminus.com)LLM Prompt Injection Game: https://gandalf.lakera.ai/Overwhelmed by modern cyberthreats? ThreatDown can...

Megan Cook is the head of product for Atlassian's Jira software, which is used by 75% of Fortune 500 companies, has over 125,000 customers globally, over 15 different products, and is by far the most popular project management tool in the world. Megan has been at Atlassian for just under 11 years, and before this role, she was an analyst, a developer, and an Agile coach. In our conversation, we discuss:• How to get buy-in for your ideas• The value of starting small• How, and why, creating space for play is so essential• How Jira stays ahead of endless competition• Atlassian's approach to launching new product lines• Tactical tips for making remote work, work• A personal failure and the lessons learned from it—Brought to you by:• Teal—Your personal career growth platform• Sprig—Build a product people love• Vanta—Automate compliance. Simplify security.—Find the transcript for this episode and all past episodes at: https://www.lennyspodcast.com/episodes/. Today's transcript will be live by 8 a.m. PT.—Where to find Megan Cook:• X: https://twitter.com/meganwcook• LinkedIn: https://www.linkedin.com/in/cookmegan—Where to find Lenny:• Newsletter: https://www.lennysnewsletter.com• X: https://twitter.com/lennysan• LinkedIn: https://www.linkedin.com/in/lennyrachitsky/—In this episode, we cover:(00:00) Megan's background(03:50) Creating space for play and psychological safety on teams(07:36) Peer feedback groups(10:30) Sharing stories of failure(13:33) The “10 dollar” game for priorities(15:24) Advice on making remote work, work(24:16) Getting buy-in for your ideas(28:33) The importance of staying open-minded(34:05) A quick summary of how to get buy-in(36:45) Fighting the good fight(38:15) Identifying customer pain points(43:04) Starting small and showing success(46:08) Launching new product lines(53:35) Atlassian's gated process for new product ideas(58:00) How Jira stays ahead of competitors(01:04:28) Learning from failure(01:08:30) Fight club(01:10:08) Lightning round—Referenced:• Jira: https://www.atlassian.com/software/jira• Atlassian: https://www.atlassian.com/• Bitbucket: https://bitbucket.org/product• Ben Crowe on LinkedIn: https://www.linkedin.com/in/ben-crowe-67299714/• Ash Barty on X: https://twitter.com/ashbarty• Atlassian's blog, Work Life: https://www.atlassian.com/blog• Lessons learned: 1,000 days of distributed at Atlassian: https://www.atlassian.com/blog/distributed-work/distributed-work-report• New research: How to make time for the work that matters: https://www.atlassian.com/blog/distributed-work/calendar-redesign-experiment• Atlas: https://www.atlassian.com/software/atlas• Confluence: https://www.atlassian.com/software/confluence• Lenny's swag store: https://lennyswag.com/• What is CSAT and how do you measure it?: https://www.qualtrics.com/experience-management/customer/what-is-csat• The UX research reckoning is here | Judd Antin (Airbnb, Meta): https://www.lennyspodcast.com/the-ux-research-reckoning-is-here-judd-antin-airbnb-meta/• Charlie Sutton on LinkedIn: https://www.linkedin.com/in/charliesutton/• Nokia 6100: https://en.wikipedia.org/wiki/Nokia_6100• Compass: https://www.atlassian.com/software/compass• Jira Product Discovery: https://www.atlassian.com/software/jira/product-discovery• Canva: https://www.canva.com/• Inspired: How to Create Tech Products Customers Love: https://www.amazon.com/INSPIRED-Create-Tech-Products-Customers/dp/1119387507• Scaling People: Tactics for Management and Company Building: https://www.amazon.com/Scaling-People-Tactics-Management-Building/dp/1953953212• Foundation on AppleTV+: https://tv.apple.com/us/show/foundation/umc.cmc.5983fipzqbicvrve6jdfep4x3• Foundation book series: https://www.amazon.com/Foundation-3-Book-Boxed-Set-Empire/dp/0593499573• Traeger smoker: https://www.traeger.com/shop/wood-pellet-grills—Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email podcast@lennyrachitsky.com.—Lenny may be an investor in the companies discussed. Get full access to Lenny's Newsletter at www.lennysnewsletter.com/subscribe

Have you seen how to do prompt engineering with cucumber and AI to help create automated tests? What is the Automation Pyramid Model for performance testing? How can you use a new AI Bot to assist in "edge" testing. Find out in this episode of the Test Guild New Shows for the week of Jan 21st. So, grab your favorite cup of coffee or tea, and let's do this. Time News Title Rocket Link 0:21 Prompt Engineering in the Testing World https://links.testguild.com/blinq 2:23 Optimizing SQL Queries https://testguild.me/afzok7 3:32 Edge testing help with ai https://testguild.me/swb05x 4:27 PractiTest newest AI-powered feature https://testguild.me/sjrsr4 5:42 CogAgent's Visual Language Capabilities https://testguild.me/di8bu1 6:33 AlphaCodium, code generation tool https://testguild.me/6324be 7:45 Playwright with Bitbucket https://testguild.me/qrpmpt 8:32 Automation Pyramid for Performance Testing https://testguild.me/wsk1pr    

Oliver Jay is a sales and expansion specialist. Oliver was Chief Revenue Officer at Asana and led the company's global expansion. He grew the team from 20 to 450 people and increased international income to 40% of Asana's total revenue. Prior to this, Oliver built the first business sales team at Dropbox, and led the company's expansion into the Asia-Pacific region while tripling ARR. Oliver is now an advisor and leadership coach focused on assisting founders and executives in scaling their businesses. — In today's episode, we discuss: Common mistakes PLG companies make The “PLG trap” and how to avoid it The playbook for transitioning into enterprise How and when to build an enterprise sales team How PLG companies can break $10 billion market cap Why it's difficult to emulate Atlassian, Slack or Salesforce — Referenced: Airtable: https://www.airtable.com/ Asana: https://asana.com/ Atlassian: https://www.atlassian.com/ Bitbucket: https://bitbucket.org/product/ Confluent: https://www.confluent.io/ Daniel Shapero: https://www.linkedin.com/in/dshapero/ Datadog: https://www.datadoghq.com/ Dennis Woodside: https://www.linkedin.com/in/dennis-woodside-341302/ Dropbox: https://www.dropbox.com/ Dustin Moskovitz: https://www.linkedin.com/in/dmoskov/ Jay Simons: https://www.linkedin.com/in/jaysimons/ Jira: https://www.atlassian.com/software/jira Justin Rosenstein: https://www.linkedin.com/in/justinrosenstein/ Kim Scott: https://www.linkedin.com/in/kimm4/ Salesforce: https://www.salesforce.com/ Slack: https://slack.com/ The PLG Trap: https://www.linkedin.com/pulse/plg-trap-oliver-jay/ The seed, land, and expand framework: https://www.endgame.io/blog/seed-land-expand-framework Zendesk: https://www.zendesk.com/ — Where to find Oliver Jay: LinkedIn: https://www.linkedin.com/in/oliverjayleadership/ Website: https://www.oliverjayleadership.com/ — Where to find Brett Berson: Twitter/X: https://twitter.com/brettberson LinkedIn: https://www.linkedin.com/in/brett-berson-9986094 — Where to find First Round Capital: Website: https://firstround.com/ First Round Review: https://review.firstround.com/ Twitter: https://twitter.com/firstround YouTube: https://www.youtube.com/@FirstRoundCapital This podcast on all platforms: https://review.firstround.com/podcast — Timestamps: (00:00) Introduction (02:23) Differences between PLG and enterprise companies (05:56) Avoiding the “PLG trap” (07:39) Transitioning to enterprise feels like building two companies (10:57) Thinking about user value versus company value (13:58) The relationship between OKRs and executive champions (14:59) Dropbox had almost no company value (15:33) The strategy PLG companies should avoid (18:30) Why Dropbox is worth $10b, not $50b (19:41) The story of Asana's expansion (21:16) Asana's unique customer success team (23:27) How product strategy relates to finding champions (25:03) How Asana structured its GTM org (27:11) What Oliver would have done differently with Asana's GTM (29:45) Getting executive-level buy-in (31:49) Asana's concept of “selling clarity” (33:18) An inside look at Asana's transition into enterprise (37:59) The champion tree framework (40:43) Structuring Asana's early enterprise sales team (44:27) The impact of company size on GTM (47:20) Common sales mistake (48:29) The seed, land, and expand framework (51:43) Oliver's advice to founders (54:13) Why building horizontally may be a mistake (55:32) Common challenges faced by PLG companies (58:30) How PLG companies can break the $10b market cap (60:17) Why emulating Atlassian's playbook is difficult (63:21) People who had an outsized impact on Oliver

In the final episode of Workspace Recap, Jesse and Steve reflect on their three-year journey of producing the show and announce a break to relax and explore new formats. They express gratitude for their listeners and invite feedback on how to improve the show. The episode then covers various updates, including the enforcement of two-step verification, an increase in the dynamic group limit, the Meet Add-on SDK in developer preview, continuous framing in Google Meet Series 1 room kits, and the ability to record and share name pronunciation. Other updates include easy access to people, documents, and building blocks in Google Docs, excusing assignments in Google Classroom, interactive questions for YouTube videos in Google Classroom, the Bitbucket app for Google Chat, and the profile discovery setting in Google Workspace. The episode concludes with a mention of the pause in the rollout of chat bubbles and a reminder to stay tuned for future updates. Don't miss Google Cloud Next '24, April 9–11, 2024, at Mandalay Bay Convention Center in Las Vegas. We're gearing up to go bigger in 2024 with a new location, fresh programming, and exciting surprises. Register now to take advantage of the $999 USD early bird price* – that's 50% off the full ticket price of $1,999 USD.

Free, ungated access to all 290+ episodes of “It's 5:05!” on your favorite podcast platforms: https://bit.ly/505-updates. You're welcome to

Is your brand strong enough that you can release logo-less content and people still know it's from your company? Are the visuals, the font, the tone and voice so clearly yours? Brand is so nuanced. But when done well, your name will be the first in the buyer's mind when they're ready to make a purchase. In this episode, we're taking tips from a show that has super strong branding: White Lotus. We're discussing Season 2 with Atlassian's Head of Brand Content, Natalie Mendes. Together, we're talking about how to cultivate a brand that will take you from season to season, investing in the heroes of your brand, and much more. Now, you can put on your bathing suit, but we wouldn't recommend getting in the water for this episode of Remarkable.About our guest, Natalie MendesNatalie Mendes is Head of Brand Content at Atlassian. She is an award-winning marketing leader with a wealth of experience in content marketing spanning over a decade. At Atlassian, she started and grew the brand content team, with a track record of building successful content strategies that drive traffic, engagement, and conversion. She has  won several awards, including Best B2B Content Site from Digiday and Best Digital Publication from Content Marketing Institute. She has experience in SEO strategy and content development, paid and organic social media, email marketing, website development, and PR.At Atlassian, she leads strategy and execution of content on their website, blog, podcasts, video, and social media. She has grown a team of skilled and motivated content marketers that serve and support their brand and product marketing strategies, as well as managing external agencies for social media and web development. They have grown organic monthly pageviews by 1000% in the past 3 years and proved out paths for sales. She has grown a thriving and engaged following for Atlassian brand and won multiple excellence awards in B2B Content Strategy and Podcasting.About AtlassianAtlassian is a portfolio of products that enable teams, increase collaboration and communication, and help businesses obtain their desired business goals. They connect teams to share work and drive higher productivity and outcomes. The teams they support include software, IT, business, marketing and more. Their team of 7000+ Atlassians supports an international group of 250,000+ customers. They build tools like Jira, Confluence, Bitbucket, and Trello to help teams across the world become more nimble, creative, and aligned.About White LotusWhite Lotus is about the guests and employees of a fictional resort chain of the same name, White Lotus. While initially everything is beautiful and picture-perfect on the surface, there's a darkness underneath that reveals itself more and more as time goes on. The second season is set in Sicily and stars Jennifer Coolidge as Tanya McQuoid-Hunt, F. Murray Abraham as Bert Di Grasso, Michael Imperioli as Dominic Di Grasso, Adam DiMarco as Albie Di Grasso, Aubrey Plaza as Harper Spiller, and her husband, Ethan Spiller is played by Will Sharpe. It starts off with the death of a guest at the White Lotus resort and revolves around the sex lives of the characters from cheating to addiction. This is different from the first season, which focused on money and privilege. The series was created by Mike White for HBO and premiered in 2021. There are now two seasons and a third in production, which will reportedly be filmed in Thailand. Each season is set at a different White Lotus resort. The first season was set in Hawaii. It has won ten Primetime Emmy Awards and two Golden Globes.What B2B Companies Can Learn From White Lotus: Cultivate a brand that can carry you from season to season. And piece of content to piece of content. You should be able to use your brand voice across channels. The key is that your content has to be of high value to your audience. They learn to look forward to your content and trust the quality of it. Natalie says, “It's so much easier and efficient in a lot of ways to build on something that's working than to try to change up your story every single year and try new marketing formats just for the sake of it. When you can build on something over time, that's where you see the benefit and the growth, even from an organic SEO standpoint, we still see lots of great traffic coming to our old content. It's not all about the new stuff every time.” It's like how we know that each season of White Lotus takes place in a different luxury resort. And it sets the stage for drama to unfold. So the audience learns to trust the quality of the storytelling and looks forward to a dark, complex plot that is undeniably White Lotus.Highlight the “heroes” of your brand. Whether it's a character in your marketing or a fan favorite product, give your audience more. Natalie says, “Find your darlings and really invest in them.” She says, “Whether that's something that starts in your digital world and becomes an event in the real world, or your customers rally around one of your products or a new feature, letting that take off and knowing that that is gonna be good for your brand and good for your customers, while still having the regular cast of characters in the mix.” In White Lotus, it was Jennifer Coolidge's character, Tanya, who became very popular. And references to her, including memes, are all over the internet. At Atlassian, they unleashed evangelists with resources and messaging to consult with customers. These evangelists, or heroes, strengthen their brand and accelerate the business.Quotes*”It's a show where there is no hero. Nobody really wins. And I think that's sort of what I like about it too, is it's more of a character study in these people and what's driving them to do things and what's holding them back and what are their secrets.” - Natalie Mendes*”Once I started watching White Lotus, I just got immediately hooked on the story and the intrigue. So it's a show where you know the ending but then the whole show is about figuring out how it happened. And so I love how that storytelling device hooks you immediately and then you become part of the show.” - Natalie MendesTime Stamps[0:53] Meet Natalie Mendes, Head of Brand Content at Atlassian[2:40] What is Natalie responsible for in her role at Atlassian?[4:31] What is White Lotus about?[8:11] Why is White Lotus remarkable?[23:02] How does Natalie think about brand?[25:54] What B2B marketing lessons can we learn from White Lotus?[34:59] What's Natalie's content strategy?LinksWatch White LotusConnect with Natalie on LinkedInLearn more about AtlassianListen to TeamistryListen to Work CheckAbout Remarkable!Remarkable! is created by the team at Caspian Studios, the premier B2B Podcast-as-a-Service company. Caspian creates both non-fiction and fiction series for B2B companies. If you want a fiction series check out our new offering - The Business Thriller - Hollywood style storytelling for B2B. Learn more at CaspianStudios.com. In today's episode, you heard from Ian Faison (CEO of Caspian Studios) and Meredith Gooderham (Senior Producer). Remarkable was produced this week by Jess Avellino, mixed by Scott Goodrich, and our theme song is “Solomon” by FALAK. Create something remarkable. Rise above the noise.

Bienvenue dans ce nouvel épisode du podcast

Elastyczne godziny pracy, brak obowiązku przychodzenia do biura i praca z dowolnej lokalizacji to w branży IT od jakiegoś czasu już standard. Wielu z nas bardzo sobie chwali takie rozwiązania i skupia się głównie na ich zaletach, ale rzeczywistość nie jest taka różowa. Praca w zespole rozproszonym niesie ze sobą wiele wyzwań, takich jak ograniczone możliwości w zakresie dzielenia się wiedzą i współpracy w czasie rzeczywistym oraz wolniejsze rozwiązywanie problemów. Na szczęście nie wszystko stracone. Można wdrożyć pewne rozwiązania, które sprawią, że wydajność wzrośnie, a poziom frustracji zmaleje. Informacje dodatkowe: "#56 Tech Writer robi inżynierię oprogramowania, czyli dobre praktyki prosto od Google", Tech Writer koduje: https://techwriterkoduje.pl/blog/2023/8/1/56 "Why Meetings Suck and How to Fix Them", WorkLife with Adam Grant: https://open.spotify.com/episode/7qVywKBTNnNmuNTKZKwin0?si=43474d5baa734141 Jira: https://www.atlassian.com/software/jira Bitbucket: https://bitbucket.org/ No Hello: https://www.nohello.com/ "Standard DITA (Darwin Information Typing Architecture)", Wikipedia: https://en.wikipedia.org/wiki/Darwin_Information_Typing_Architecture Markdown: https://daringfireball.net/projects/markdown/syntax Visual Studio (VS) Code: https://code.visualstudio.com/ IntelliJ IDEA: https://www.jetbrains.com/idea/ GitHub: https://github.com/

В этом выпуске: очередная порция невероятных тем. Шоуноты: [00:04:11] Чему мы научились за неделю But what is the Fourier Transform? A visual introduction. — YouTube TodayTix | Theater Tickets to Musicals, Plays, Broadway, More [00:25:07] HiFiMan Sundara [00:41:09] 28 дней спустя: какова же судьба Сашиных репок на BitBucket? [00:47:49] Qdrant [01:02:10] Unity стреляет себе в… Читать далее →

Time to go through the updates from the @atlassian ecosystem #BitbucketCloud #TeaWithRavi #AtlassianUpdates https://www.ravisagar.in/videos/atlassian-updates-bitbucket-cloud-new-features

Time to go through the updates from the @atlassian ecosystem - #EnhancedJiraBoard #CustomDomainsJSM #BitbucketComments #TeaWithRavi

Brian Douglas, Founder and CEO at OpenSauced, learned to code while pursuing his MBA and stayed up-to-date with the latest trends and technologies by tuning into podcasts and blogs. Brian's passion eventually caught the attention of Netlify, where he joined as an advocate. Later, he became the first advocate at GitHub, building out a developer relations team. Brian shares insights into the open-source world and the challenges faced by maintainers. He introduces his current venture, OpenSauce.pizza, which aims to improve GitHub insights and provide valuable knowledge about open-source contributions and tech debt. Brian mentions plans to expand the platform's support to include other Git host providers like GitLab and Bitbucket.In this episode, Brian talks to Robbie and Chuck about his journey from developer to developer advocate, the importance of developer experience, and his current project, OpenSauce.pizza, focusing on GitHub insights with plans to expand to support other Git host providers. Key Takeaways [00:31] - Introduction to Brian Douglas. [01:59] - A whiskey review: Teeling Whiskey Wonders of Wood Single Pot Still. [08:42] - Tech hot takes. [15:03] - How Brian got into developer advocacy. [25:39] - Brian talks about OpenSauced. [32:15] - Future plans for OpenSauced. [37:09] - Chuck asks Brian to teach him how to Dougie. [38:06] - Brian explains how to start a podcast. [42:40] - What Brian is most excited about with AI. Quotes [21:08] - “Everyone complains about how many Spidermans have we seen or Batman origin stories we've seen, but it's the same thing on the web.” ~ Brian Douglas [26:53] - “We want to move away from the big brother-like tools that exist.” ~ Brian Douglas [39:11] - “My thing is, just do it. If it doesn't work out, use all that to start a new one.” ~ Brian Douglas Links Brian Douglas Twitter Brian Douglas LinkedIn Github OpenSauced Little Caesars Teeling Wonders of Wood Single Pot Still Jameson Irish Whiskey World Drinks Awards Josh Goldberg Tailwind CSS Angular React Netlify Jamstack Radio Supabase Firebase Google Flutter Apple Vision Apple Microsoft Netflix GitLab Chris Coyier Pizza Hut Spotify GitHub Copilot Alexa Stack Overflow RenderATL SXSW Ember Sauced Newsletter Connect with our hosts Robbie Wagner Chuck Carpenter Ship Shape Subscribe and stay in touch Apple Podcasts Spotify Google Podcasts Whiskey Web and Whatnot Top-Tier, Full-Stack Software Consultants This show is brought to you by Ship Shape. Ship Shape's software consultants solve complex software and app development problems with top-tier coding expertise, superior service, and speed. In a sea of choices, our senior-level development crew rises above the rest by delivering the best solutions for fintech, cybersecurity, and other fast-growing industries. Check us out at shipshape.io.

En Web Reactiva podcast de programación hablamos sobre cómo elegir librería de JavaScript (aunque puedes aplicarlo a cualquier otra)Este episodio nace despues de publicar la Guía con 66 librerías de JavaScript Y recuerda que cada domingo puedes recibir 12 recursos para developers.Estos son algunos puntos que vemos en el episodio:

06-17-23Support the show: https://www.loveneverfailsus.com/donateSee omnystudio.com/listener for privacy information.

Kenneth Rose, CTO at OpsLevel, joins Corey on Screaming in the Cloud to discuss how OpsLevel is helping developer teams to scale effectively. Kenneth reveals what a developer portal is, how he thinks about the functionality of a developer portal, and the problems a developer portal solves for large developer teams. Corey and Kenneth discuss how to drive adoption of a developer portal, and Kenneth explains why it's so necessary to have executive buy-in throughout that process. Kenneth also discusses how using their own portal internally along with seeking out customer feedback has allowed OpsLevel to make impactful innovations. About KenKenneth (Ken) Rose is the CTO and Co-Founder of OpsLevel. Ken has spent over 15 years scaling engineering teams as an early engineer at PagerDuty and Shopify. Having in-the-trenches experience has allowed Ken a unique perspective on how some of the best teams are built and scaled and lends this viewpoint to building products for OpsLevel, a service ownership platform built to turn chaos into consistency for engineering leaders.Links Referenced: OpsLevel: https://www.opslevel.com/ LinkedIn: https://www.linkedin.com/company/opslevel/ Twitter: https://twitter.com/OpsLevelHQ 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, about, oh I don't know, two years ago and change, I wound up writing a blog post titled, “Developer Portals are An Anti Pattern,” and I haven't really spent a lot of time thinking about them since. This promoted guest episode is brought to us by our friends at OpsLevel, and they have sent their CTO and co-founder Ken Rose, presumably in an attempt to change my perspective on these things. Let's find out. Ken, thank you for agreeing to, well, run the gauntlet, for lack of a better term.Ken: Hey, Corey. Thanks again for having me. And I've heard, you know, heard and listened to your show a bunch, and really excited to be here today.Corey: Let's begin with defining our terms. I'm curious to know what a developer portal is. ‘What would you say a developer portal means to you?' Like it's a college entrance essay.Ken: Right? Definitely. You know, so really, a developer portal is this consolidated place for developers to come to, especially in large organizations to be able to get their jobs done more easily, right? A large challenge that developers have in large organizations, there's just a lot to do and a lot to take care of. So, a developer portal is a place for developers to be able to better own, manage, and run the services, they're responsible for that run in production, and they can do that through access, easy access to self-service tooling.Corey: I guess, on some level, this turns into one of those alignment charts of, like, what is a database and, like, how prescriptive you want to be. It's like, well is a senior engineer a database because you can query them and they have information? Would you consider, for example, Kubernetes be a developer platform, and/or would the AWS console?Ken: Yeah, that's actually an interesting question, right? So, I think there's actually two—we're going to get really niggly here—there's developer platform and developer portal, right? And the word portal for me is something that sits above a developer platform. I don't know if you remember, like, the late-90s, early-2000s, like, portals were all the rage.Like, Yahoo and AltaVistas were like search portals, they were trying to, at the time, consolidate all this information on a much smaller internet to make it easy to access. A developer portal is sort of the same thing, but custom-built for developers and trying to consolidate a lot of the tooling that exists. Now, in terms of the AWS console? Yeah, maybe. Like, it has a suite of tools and suite of offerings. It doesn't do a lot on the well, how do I quickly find out what's running in production and who is responsible for it? I don't know, unless AWS shipped, like, their, you know, three-hundredth new offering in the last week that I haven't, you know, kept on top of.But you know, there's definitely some spectrum in terms of what goes into a developer portal. For me, there's kind of three main things you need. You do need some kind of a catalog, like, what's out there who owns it; you need some kind of a way to measure, like, how good are those services, like, how well built are they; and then you need some access to self-service tooling. And that last part is where, like, the Kubernetes or AWS could be, you know, sort of a dev portal as well.Corey: My experience with developer portals—there was a time when I loved it. RightScale was what I used—at some depth—back in I want to say 2010, 2011 because the EC2 console was clearly not built or designed by anyone who had not built EC2 themselves with their bare hands and sweat of their brow. And in time, the EC2 console got better where it wasn't written in hieroglyphics, as best we could tell, and it became ‘click button to launch instance.' And RightScale really didn't have a second act and they wound up getting acquired by our friends over at Flexera years later. And I haven't seen their developer portal in at least eight years as a direct result of this.So, the problem, at least when I was viewing it purely in the context of AWS services, it feels like you are competing against AWS iterating forward on developer experience, which they iterate slowly, sometimes, and unevenly across their breadth of services, but it does feel like at some level by building an internal portal, you are, first, trying to out-innovate AWS, in some ways, and two, you are inherently making the trade-off of not using recent features and enhancements that have not themselves been incorporated into the portal. That's where the, I guess the start, the genesis of my opposition to the developer portal approach comes from. Is that philosophy valid these days? Not as much. Because I can see an argument for it shifting.Ken: Yeah, I think it's slightly different. I think of a developer portal as again, it's something that sort of sits on top of AWS or Google Cloud or whatever cloud provider use, right? You give an example for example with RightScale and EC2. So, provisioning instances is one part of the activity you have to do as a developer. Now, in most modern organizations, you have, like, your product developers that ship features. They don't actually care about provisioning instance themselves. There are another group called the platform engineers or platform group that are responsible for building automation and tooling to help spin up instances and create CI/CD pipelines and get everything you need set up.And they might use AWS under the covers to do that, but the automation built on top and making that accessible to developers, that's really what a developer portal can provide. In addition, it also provides links to operational tooling that you need, technical documentation, it's everything you need as a developer to do your job, in one place. And though AWs bills itself is that, I think of them as more, they have a lot of platform offerings, right, they have a lot of infra-offerings, but they still haven't been able to, I think, customize that, unless you're an organization that builds—that has kind of gone in-all on AWS and doesn't build any of your own tooling, that's where a developer portal helps. It really helps by consolidating all that information in one place, by making that information discoverable for every developer so they have less… less cognitive load, right? We've asked developers to kind of do too much that we don't… we've asked to shift left and well, how do we make that information more accessible?Regarding the point of, you know, AWS adds new features or new capabilities all the time and, like, well you have this dev portal, that's sort of your interface for how to get things done. Like, how will you use those? Dev portal doesn't stop you from doing that, right? So, my mental model is, if I'm a developer, and I want to spin up a new service, I can just press a button inside of my dev portal in my company and do that. And I have a service that is built according to the latest standards, it has a CI/CD pipeline, it already has a—you know, it's registered in PagerDuty, it's registered in Datadog, it has all the various bits.And then there's something else that I want to do that isn't really on the golden path because maybe this is some new service or some experiment, nothing stops us from doing that. Like, you still can use all those tools from AWS, you know, kind of raw. And if those prove to be valuable for the rest of the organization, great. They can make their way into the dev portal; they can actually become a source of leverage. But if they're not, then they can also just sit there on the vine. Like, not everything that eight of us ever produces will be used by every company.Corey: Many years ago, I got a Cisco pair of certifications because recession was hitting and I needed to be better at networking. And taking those certifications, in those days before Cisco became the sad corporate dragon with no friends we all know today, they were highly germane and relevant. But I distinctly remember, even now, 15 years later, that there was this entire philosophy of pretend that the entire world is Cisco only, which in networking is absolutely never true. It feels like a lot of the AWS designs and patterns tend to assume, oh yeah, you're going to use AWS services for everything. I have never yet found that to be true, other than when I'm just trying to be obstinate.And hell is interoperability between a bunch of different things. Yes, I may want to spin up an EC2 instance and an AWS load balancer and some S3 storage or whatnot, but I'm also going to want to monitor it with PagerDuty, I'm going to want to have a CDN that isn't CloudFront because most CDN these days don't hate you in quite the same economic ways and are simpler to work with, et cetera, et cetera, et cetera. So, there's definitely a story wherein I've found that there's an—the interoperability of tying these things together is helpful. How do you avoid falling down the trap of oh, everyone should be multi-cloud, single pane of glass at cetera, et cetera? In practice that always seems to turn to custard.Ken: Yeah, I think multi-cloud and single pane of glass are actually two different things. So multi-cloud, like, I agree with you to some sense. Like, pick a cloud and go with it, like, unless you have really good business reasons to go for multi-cloud. And sometimes you do, like, years ago, I worked at PagerDuty, they were multi-cloud for a reliability reason, that hey, if one cloud provider goes down, you don't want [crosstalk 00:08:40]—Corey: They were an example I used all the time for that story—Ken: Right.Corey: —specifically the thing woke you up was homed in a bunch of different places, whereas the marketing site, the onboarding flow, the periphery stuff around it was not because it didn't need to be.Ken: Exactly.Corey: Like, the core business need of wake you up was very much multi-cloud because once upon a time, it wasn't and it went down with the rest of us-east-1 and people weren't woken up to be told their site was on fire.Ken: A hundred percent. And on the kind of like application side where, even then, pick a cloud and go with it, unless there's a really compelling business reason for your business to go multi-cloud. Maybe there's something credits or compliance or availability, right? There might be reasons, but you have to be articulate about whether they're right for you.Now, single pane of glass, I think that's different, right? I do think that's something that, ultimately, is a net boon for developers. In any large organization, there is a myriad of internal tools that have been built. And it's like, well, how do I provision a new topic in the Kafka cluster? How do I actually get access to the AWS console? How do I spin up a new service, right? How do I kind of do these things?And if I'm a developer, I just want to ship features. Like, that's what I'm incented to do, that's what I'm optimizing for. And all this other stuff I have to do as part of my job, but I don't want to have to become, like, a Kubernetes guru to be able to do it, right? So, what a developer portal is trying to do is be that single pane of glass, bringing all these common set of tools and responsibilities that you have as a developer in one place. They're easy to search for, they're easy to find, they're easy to query, they're easy to use.Corey: I should probably have asked this earlier on, but let's disambiguate for a little bit here. Because when I'm setting up to use a new service or product and kick the tires on it, no two explorations really look the same. Whereas at most responsible mature companies that are building products that are—services that are going to production use, they've standardized around a number of different approaches. What does your target customer look like? Is there a certain point of scale, a certain level of complexity, a certain maturity of process?Ken: Absolutely. So, a tool like OpsLevel or a developer portal really only makes sense when you hit some critical mass in terms of the number of services you have running in production, or the number of developers that you have. So, when you hit 20, 30, 50 developers or 20, 30, 50 services, an important part of a developer portal is this catalog of what's out there. Once you kind of hit the Dunbar number of services, like, when you have more than you keep in your head, that's when you start to need tooling like this. If you look at our customer base, they're all you know, kind of medium to large-sized companies. If you're a startup with, like, ten people, OpsLevel is probably not right for you. We use all playable internally at OpsLevel, and you know, like, we're still a small company. It's like, we make it work for us because we know how to get the most out of it, but like, it's not the perfect fit because it's not really meant for, you know, smaller companies.Corey: Oh, I hear you. I think I'm probably… I have a better AWS bill analytic system running internally here at The Duckbill Group than some banks do. So, I hear you on that front.Ken: I believe it.Corey: But also implies to me that there's no OpsLevel prospect or customer deployment that has ever been greenfield. It's always you're building existing things, there's already infrastructure in place, vendors have been selected across the board. You aren't—don't to want to starting a company day one, they're going to all right, time to spin up our AWS account and we're also going to wind up signing up for OpsLevel, from the sound of it.Ken: Correct—Corey: Accurate? Inaccurate?Ken: I think that's actually accurate. Like, a lot of the problems, we solve other problems that come as you start to scale both your product and your engineering team. And it's the problems of complexity.Corey: What do those painful problems look like? In other words, what is someone sitting at home right now listening to this, or driving to work debating whether want to ram a bridge abutment or go into the office depending on their mental state today, what painful problem did they have that OpsLevel is designed to fix?Ken: Yeah, for sure. So, let's help people self-select. So, here's my mental model for any [unintelligible 00:12:25]. There are product developers, platform developers, and engineering leaders. Product developers, if you're asking questions like, “I just got paged for the service. I don't know what this does.” Or, “It's upstream from here. Where do I find the technical documentation?” Or, “I think I have to do something with the payment service. Where do I find the API for that?”You know, when you get to that scale, a developer portal can help you. If you're a platform engineer and you have questions like, “Okay, we got to migrate. We're migrating, I don't know, from Datadog to Honeycomb, right? We got to get these fifty or a hundred or thousands of services and all these different owners to, like, switch to some new tool.” Or, “Hey, we've done all this work to ship the golden path. Like, how to actually measure the adoption of all this work that we're doing and if it's actually valuable?” Right?Like, we want everybody to be on a certain set of CI tooling or a certain minimum version of some library or framework. How do we do that? How do we measure that? OpsLevel is for you, right? We have a whole bunch of stuff around maturity.And if you're engineering leader, ultimately, questions you care about, like, “How fast are my developers working? I have this massive team, we've made this massive investment in hiring all these humans to write software and bring value for our customers. How can we be more efficient as a business in terms of that value delivery?” And that's where OpsLevel can help as well.Corey: Guardrails, whether they be economic, regulatory, or otherwise, have to make it easier than doing things incorrectly because one of the miracle aspects of cloud also turns into a bit of a problem, which is shadow IT is only ever a corporate credit card away. Make it too difficult to comply with corporate policies and people won't. And they're good actors; they're trying to get work done. They're not trying to make people's lives harder, but they don't want to spend six weeks provisioning an EC2 cluster. So, there's always that weird trade-off.Now, it feels—and please correct me if I'm wrong—once someone has rolled out OpsLevel at their organization, where it really shines is spinning up a new service where okay, great, you're going to spin up the automatic observability portion of it, you're going to spin up the underlying infrastructure in certain ways that comply with our policies, it's going to build the CI/CD pipelines around it, you're going to wind up having the various cost instrumentation rolled out to it. But for services that are already excellent within the environment, is there an OpsLevel story for them?Ken: Oh, absolutely. So, I look at it as, like, the first problem OpsLevel helps solve is the catalog and what's out there and who owns it. So, not even getting developers to spin up new services that are kind of on the golden path, but just understanding the taxonomy of what are the services we have? How do those services compose into higher-level things like systems or domains? What's the whole set of infrastructure we have?Like, I have 50 AWS accounts, maybe a handful of GCP ones, also, some Azure. I have all this infrastructure that, like, how do I start to get a handle on, like, what's out there in prod and who's responsible for it. And that helps you get in front of compliance risks, security risks. That's really the starting point for OpsLevel building that catalog. And we have a bunch of integrations that kind of slurp all this data to automatically assemble that catalog, or YAML as well if that's your thing. But that's the starting point is building that catalog and figuring out this assignment of, like, okay, this service and this human, or this—sorry—team, like, they're paired together.Corey: A number of offerings in this space, which honestly, my exposure to it is bounded simultaneously to things that are ten years old and no one uses anymore, or a bunch of things I found on GitHub. And the challenge that both of those products tend to have is that they assume certain things to be true about a given environment: that they're using Terraform to manage everything, or they're always going to be using CloudFormation, or everyone there knows Python or something else like that. What are the prerequisites to get started with OpsLevel?Ken: Yeah, so we worked pretty hard to build just a ton of integrations. I would say integrations is are just continuing thing we have going on in the background. Like, when we started, like, we only supported a GitHub. Now, we support all the gits, you know, like GitHub, GitLab, Bitbucket, Azure DevOps, like, we're building [unintelligible 00:16:19]. There's just a whole, like, long tail of integrations.The same with APM tooling. The same with vulnerability management tooling, right? And the reason we do that is because there's just this huge vendor footprint, and people, you know, want OpsLevel to work for them. Now, the other thing we try to do is we also build APIs. So, anything we have as, like, a core integration, we also have kind of like an underlying API for, so that there's, no matter what you have an escape hatch. If like, you're using some tool that we don't support or you have some homegrown thing, there's always a way to try to be able to integrate that into OpsLevel.Corey: When people think about developer portals, the most common one that pops to mind is Backstage, which Spotify wound up building, internally, championing, open-sourcing, and I believe, on some level, turned into a product because if there's one thing people want, it's to have their podcast music company become a SaaS vendor, which is weird to me. But the criticisms that I've seen about and across the board have rung relatively true, including from people internal at Spotify who have used the thing, which is, well first is underestimating the amount of effort that is necessary to maintain Backstage itself, that the build versus buy discussion is always harder to bu—engineers love to build, but they shouldn't be building things outside of their core competency half the time, and the other is driving adoption within the org where you can have the most amazing developer portal in the known universe, but if people don't use it, it may as well not exist and doing the carrot and stick approach often doesn't work. I think you have a pretty good answer that I need not even ask you to elaborate on, “Well, how do we avoid having to maintain this ourselves,” since you have a company that does this, but how do you find companies are driving adoption successfully once they have deployed OpsLevel?Ken: Yeah, that's a great question. So, absolutely. Like, I think the biggest thing you need first, is kind of cultural buy-in and that this is a tool that we want to invest in, right? I think one of the reasons Spotify was successful with Backstage and I think it was System Z before that was that they had this kind of flywheel of, like, they saw that their developers were getting, you know better faster, working happier, by using this type of tooling, by reducing the cognitive load. The way that we approach it is sort of similar, right?We want to make sure that there is executive buy-in that, like, everybody agrees this is, like, a problem that's worth solving. The first step we do is trying to build out that catalog again and helping assign ownership. And that helps people understand, like, hey, these are the services I'm responsible for. Oh, look, and now here's this other context that I didn't have before. And then helping organizations, you know, what—it depends on the problem we're trying to solve, but whether it's rolling out self-serve automation to help developers, like, reduce what was before a ton of cognitive load or if it's helping platform teams define what good looks like so they can start to level up the overall health of what's running in production, we kind of work on different problems, but it's picking one problem and then you know, kind of working with the customers and driving it forward.Corey: On some level, I think that this is going to be looked down upon inherently just by automatic reflex of folks with infrastructure engineering backgrounds. It's taken me some time to learn to overcome my own negative reaction to it. Because it's, I'm here to build things and I want to build things out in such a way that it's portable and reusable without having to be tied to a particular vendor and move on. And it took me a long time to realize that what that instinct was whispering in my ear was in fact, no, you should be your own cloud provider. If that's really what I want to do, I probably should just brush up on you know, computer science trivia from 20 years ago and then go see if I can pass Google's SRE interview.I'm not here to build the things that just provision infrastructure from scratch every company I wind up landing at. It feels like there's more important, impactful work that I can do. And let's be clear, people are never going to follow guardrails themselves when they have to do a bunch of manual steps. It has to be something that is done for them. And I don't know how you necessarily get there without having some form of blueprint or something like that, provided for them with something that is self-service because otherwise, it's not going to work.Ken: I a hundred percent agree, by the way, Corey. Like, the take that, like, automation is the only way to drive a lot of this forward is true, right? If for every single thing you're trying—like, we have a concept called a rubric and it's basically how you measure the service health. And you can—it's very customizable, you have different dimensions. But if, for any check that's on your rubric, it requires manual effort from all your developers, that is going to be harder than something you can just automate away.So, vulnerability management is a great example. If you tell developers, “Hey, you have to go upgrade this library,” okay, some percentage [unintelligible 00:20:47], if you give developers, “Here's a pull request that's already been done and has a test passing and now you just need to merge it,” you're going to have a much better adoption rate with that. Similarly with, like, applying templates being able to [up-level 00:20:57], you know, kind of apply the latest version of a template to an existing service, those types of capabilities, anything where you can automate what the fixes are, absolutely you're going to get better adoption.Corey: As you take a look at your existing reference customers—which is something I always look for on vendor websites because, like, oh, we have many customers who will absolutely not admit to being customers, it's like, that sounds like something that's easy to say—you have actual names tied to these things. Not just companies, but also individuals. If you were to sit down and ask your existing customer base, “So, why did you wind up implementing OpsLevel and what has the value that's delivered to you been since that implementation?” What do they say?Ken: Definitely. I actually had to check our website because we, you know, land new customers and put new logos on it. I was like, “Oh, I wonder what the current set is out right now?”Corey: I have the exact same challenge. Like oh, we have some mutual customers. And it's okay. I don't know if I can mention them by name because I haven't checked our own list of testimonials [unintelligible 00:21:51] lately because say the wrong thing and that's how you wind up being sued and not having a company anymore.Ken: Yeah. So, I don't—I definitely, you know, want to stay [on side 00:22:00] on that part, but in terms of, like, kind of sample reference customer, a lot of the folks that we initially worked with are the platform teams, right? They're the teams that care about what's out there, and they need to know who's responsible for it because they're trying to drive some kind of cross-cutting change across the entire, you know, production footprint. And so, the first thing that generally people will say is—and I love this quote. This came—I won't name them, but like, it's in one of our case studies.It was like, “I had, like, 50 different attempts at making a spreadsheet and they're all, like, in the graveyard, like, to be able to capture what's out there and who's responsible for it.” And just OpsLevel helping automate that has been one of the biggest values that they've gotten. The second point, then is now be able to drive maturity and be able to measure how well those services are being built. And again, it's sort of this interesting thing where we start with the platform teams. And then sometime later security teams find out about OpsLevel, and they're like, “Oh, this is a tool I can use to, like, get developers to do stuff? Like, I've been trying to get developers to do stuff for the longest time.”And they—I file Jira tickets and they just sit there and nothing gets done. But when it becomes part of this, like, overall health score that you're trying to increase a part of the across the board, yeah, it's just a way to kind of drive action.Corey: I think that there's a dichotomy of companies that emerge. And I tend to see the world through a lens of AWS bills, so let's go down that path. I feel like there are some companies presumably like OpsLevel, whereas if I—assuming you're running on top of AWS—if I were to pull your AWS bill, I would see upwards of 80% of your spend is going to be on this application called OpsLevel, the service that you provide to people. As opposed to the other side of the world, which is large enterprises, where they're spending hundreds of millions of dollars a year, but the largest application they have is a million-and-a-half a year in spend because just, they have thousands of these things scattered everywhere. That latter case is where I tend to see more platform teams, where I start to see a lot of managing a whole bunch of relatively small workloads. And developer platforms really seem to be where a lot of solutions lead, whereas 80% of our workload is one application, we don't feel the need for that as much. Is that accurate? Am I misunderstanding some aspect of it?Ken: No, a hundred percent you'd hit the nail on the head. Like, okay, think about the typical, like, microservices adoption journey. Like, you started with, you know, some small company—like us—you started with a monolith. Ah, maybe you built out a second app—Corey: Then you read on Hacker News and realize, “Oh, if we want to hire people, we've got to be doing what all the cool kids are up to.”Ken: Right. We got a microservice all the thing—but that's actually you know, microservices should come later, right, as a response to you needing scale your org and scale your—Corey: As someone who started building some application with microservices, I could not agree more.Ken: A hundred percent. So, it's as you're starting to take steps to having just more moving parts in your production infrastructure, right? If you have one moving part, unless it's like a really large moving part that you can internally break down, like, kind of this majestic monolith where you do have kind of like individual domains that are owned by different teams, but really the problem we're trying to solve, it's more about, like, who owns what. Now, if that's a single atomic unit, great, but can you decompose that? But if you just have, like, one small application, kind of like the whole team is owning everything, again, a developer portal is probably not the right tool for you. It really is a tool that you need as you start to scale your engineer work and as you start to scale the number of moving parts in your production infrastructure.Corey: I tended to use to think of that in terms of boring companies versus innovative ones and I don't think that's accurate. I think it is the question of maturity and where companies lead to. On some level, of OpsLevel starts growing and becomes larger and larger in different ways and starts doing acquisitions and launching into other areas, at some point, you don't have just one product offering, you have a multitude of them. At which point having something like that is going to be critical. But I have to ask, given that you are sort of not exactly your target customer profile, what are the sharp edges been on using it for your use case?Ken: Yeah. So, we actually have an internal Slack channel, we call OpsLevel on OpsLevel. And finding those sharp edges actually has been really useful for us. You know, all the good stuff, dogfooding and it makes your own product better. Okay, so we have our main app, we also do have a bunch of smaller things and it's like, oh yeah, you know, we have, like, I don't know, various Hackaday things that go on, it's important we kind of wind those down for, you know, compliance, we have our marketing site, we have, like, our Terraform.Like, so there's, like, stuff. It's not, like, hundreds or thousands of things, but there's more than just the main app. The second though, is it's really on the maturity piece that we really try to get a lot of value out of our own product, right? Helping—we have our own platform team. They're also trying to drive certain initiatives with our product developers.There is that usual tension of our, like, our own product developers are like, “I want to ship features.” What's this security thing I have to go take care of right now? But OpsLevel itself, like, helps reflect that. We had an operational review today and it was like, “Oh, this one service is actually now”—we have platinum as a level. It's in gold instead of platinum. It's like, “Why?” “Oh, there's this thing that came up. We got to go fix that.” “Great. Let's go actually go fix that so we're back into platinum.”Corey: Do you find that there's often a choice you have to make internally, where you could make the product more effective for your specific use case, but that also diverges from where your typical customer needs or wants the product to go?Ken: No, I think a lot of the things we find for our use case are, like, they're more small paper cuts, right? They're just as we're using it, it's like, “Hey, like, as I'm using this, I want to see the report for this particular check. Why do I have to click six times to get?” You know, like, “Wouldn't it be great if we had a button?” Right?And so, it's those type of, like, small innovations that kind of come up. And those ultimately lead to, you know, a better product for our customers. We also work really closely with our customers and developers are not shy about telling you what they don't like about your product. And I say this with love, like, a lot of our customers give us phenomenal feedback just on how our product can be better and we try to internalize that and you know, roll that feedback into the product.Corey: You have a number of integrations of different SaaS providers, infrastructure providers, et cetera, that you wind up working with. I imagine that given your scale and scope and whatnot, those offerings are dictated by what customers say, “Hey, we're using this thing. Are you going to support that or are you not going to maintain our business?” Which is a great way to wind up financing a lot of product development and figuring out what matters to people. My question for you is, if you look across the totality of your user base, what are the most popularly used integrations, if you can say?Ken: Yeah, for sure. I think right now—I could actually dive in to pull the numbers—GitHub and GitLab—or… I think GitHub, like, has slightly more adoption across our customer base. At least with our customers, almost nobody uses Bitbucket. I mean, we have, like, a small number, but, like, it's… I think, single-digit percentage. A lot of people use PagerDuty, which you know, hey, I'm an ex-PagerDuty person [crosstalk 00:28:24] and I'm glad to see that.Corey: I have a free tier PagerDuty account that will automatically page me for my home automation stuff. Specifically, if you know, the fire alarm goes off. Like, yeah, okay, there are certain things I want to be woken up for, but it's a very short list.Ken: Yeah, it's funny, the running default message when we use a test PagerDuty was, “The server is on fire.” [unintelligible 00:28:44] be like, “The house is on fire.” Like you know, go get that taken care of. There's one other tool so that's used a lot. Datadog actually is used a ton by just across our entire customer base, despite its… we're also Data—we're a Datadog partner, we're a Datadog customer, you know? It's not cheap, but it's a good product for, you know, monitoring and logs and there are [crosstalk 00:29:01]—Corey: No other than cloud infrastructure providers, I get the number one most common source of inquiries is Datadog optimization. It has now risen to a board-level concern in many cases because observability is expensive. That's a sign of success, on some level. Meanwhile, I'm sitting here, like, Date-a-dog? Oh, my God, that's disgusting. It's like Tinder for Pets. Which it turns out is not at all what they do.Ken: Nice.Corey: Yeah.[audio break 00:29:23]—optimizing their Slack integrations, their GitHub integration, et cetera. Or are they starting with the spinning up the servers piece of it?Ken: A lot of the time—and again, that first problem they're trying to solve is just get me a handle on everything we have running in production. You know, if you have multiple AWS accounts, multiple Kubernetes clusters, dozens or even hundreds of teams, God help you if you're going to try to, like, build a list manually to consolidate all that information. That's really the first part is, like, integrate Kubernetes, integrate your CI/CD pipelines, integrate Git, integrate your Cloud account, like, will integrate with everything and will try to build that map of, like, here's everything that's out there, and start to try to assign it to, like, and here's people that we think might be responsible in terms of owning the software. That's generally the starting point.Corey: Which makes an awesome amount of sense. I think going at it from the infrastructure first perspective is where I've seen most developer platforms founder. And to be fair, the job is easier now than it was years ago because it used to be that you were being out-innovated by AWS constantly. Innovation has slow down there. And you know that because of how much they say the pace of innovation has only sped up.And whenever AWS says something in a marketing context, they're insecure about it. I've learned this through the fullness of time observing that company. And these days, most customers do not use the majority of features available for any given service. They have solidified to a point where you can responsibly build on top of these things. Now, it seems that the problem is all the ‘yes, and' stuff that gets built on top of it.Ken: Yeah. Do you have an example, actually, like, one of the kinds of, like, ‘yes, and' tools that you're thinking about?Corey: Oh, absolutely. We have a bunch of AWS environment stuff so we should configure CloudWatch to look at all these things from an observability perspective. No, you should not. You should set up Datadog. And the first time someone does that by hand, they enable all have the observability and the rest and suddenly get charged approximately the GDP of Guam.And okay, maybe we shouldn't do that because then you have the downstream impact of that on your CloudWatch bill. So okay, how do we optimize this for the observability piece directly tied to that? How do we make sure that we get woken up when the site is down or preferably before that, but not every time basically, a EBS volume starts to get a little bit toasty? You have to start dialing this stuff in. And once you've found a lot of those aspects, being able to templatize that and roll that out on an ongoing basis and having the integrations all work together feels like it's the right problem to be solving.Ken: Yeah, absolutely. And the group that I think is responsible for that kind of—because it's a set of problems you described—is really, like, platform teams. Sometimes service owners for like, how should we get paged, but really, what you're describing are these kind of cross-cutting engineering concerns that platform teams are uniquely poised to help solve in an [unintelligible 00:32:03] organization, right? I was thinking what you said earlier. Like, nobody just wants to rebuild the same info over and over, but it's sort of like, it's not just building an [unintelligible 00:32:09]; it's kind of like solving this, like, how do we ship? Can we actually run stuff in prod? And not just run it but get observability and ensure that we're woken up for it and, like, what's that total end-to-end look like from, like, developers writing code to running software in production that's serving traffic? And solving all the problems [unintelligible 00:32:24], that's what I think of was platform engineering.Corey: So, my last question before we wind up wrapping this episode comes down to, I am very adept at two different programming languages, and those are brute force and enthusiasm. What implementation language is most of what you find yourself working with? And why is it in invariably going to be YAML?Ken: Yeah, that's a great question. So, I think there's, in terms of implementing OpsLevel and implementing a service catalog, we support YAML. Like, you know, there's this very common workflow, you just drop a YAML spec, basically, in your repo, if you're a service owner. And that, we can support that. I don't think that's a great take, though.Like, we have other integrations. Again, if the problem you're trying to solve is I want to build a catalog of everything that's out there, asking each of your developers hey, can you please all write YAML files that, like, describe the services you own and drop them into this repo? You've inverted this, like, database that essentially you're trying to build, like, what's out there and stored it in Git, potentially across several hundreds or thousands of repos. You put a lot of toil now on individual product developers to go write and maintain these files. And if you ever had to, like, make a blanket update to these files, there's no atomic way to kind of do that, right?So, I look at YAML as, like, I get it, you know? Like, we use the YAML for all the things in DevOps, so why not their service catalog as well, but I think it's toil. Like, there are easier ways to build a catalog. By, kind of, just integrate. Like, hook up AWS, hook up GitHub, hook up Kubernetes, hook up your CI/CD pipeline, hook up all these different sources that have information about what's running in prod, and let the software, let the tool, automatically infer what's actually running as opposed to requiring humans to manually enter data.Corey: I find that there are remarkably few technical holy wars that I cannot unify both sides on by nominating something far worse. Like, the VI versus Emacs stuff, the tabs versus spaces, and of course, the JSON versus YAML folks. My JSON versus YAML answer is XML: God's language. I find that as soon as you suggest that, people care a hell of a lot less about the differences between JSON and YAML because their job is to now kill the apostate, which is me.Ken: Right. Yeah. I remember XML, like, oh, man, 2002. SOAP. I remember SOAP as a protocol. That was a thing.Corey: Some of the earliest S3 API calls were done in SOAP, and I think they finally just used it to wash their mouths out when all was said and done.Ken: Nice. Yeah.Corey: I really want to thank you for taking the time to do your level best to attempt to convert me, and I would argue in many respects, you have succeeded. I'm thinking about this differently than I did half an hour ago. If people want to learn more, where's the best place for them to find you?Ken: Absolutely. So, you can always check out our website, opslevel.com. We're also fairly active on LinkedIn. If Twitter hasn't imploded by the time this episode becomes launched, then they can also check us out at twitter.com/OpsLevelHQ. We're always posting, just different content on, like, how to be successful with service maturity, DevOps, developer productivity, so that you know, ultimately, that you can ship out to customers faster.Corey: And we will, of course, put links to that in the [show notes 00:35:23]. Thank you so much for taking the time, not just to speak with me, but also for sponsoring this episode. It is appreciated.Ken: Cheers.Corey: Ken Rose, CTO and co-founder at OpsLevel. I'm Cloud Economist Corey Quinn and this has been a promoted guest episode of 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 which, upon further reflection, you could have posted to all of the podcast platforms if only you had the right developer platform to pull it off.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.

Last week in security news: The ex-Ubiquiti engineer who stole a giant pile of their data gets a six year prison term, Bitbucket will be updating their SSH host keys, AWS Reported a GuardDuty Finding Issue, and more!Links: The ex-Ubiquiti engineer who stole a giant pile of their data gets a six year prison term Bitbucket will be updating their SSH host keys  Google has decided to free up inactive accounts after two years. Okay, that's their policy, but then they have the audacity to lie to our faces and say it's for "security." I have a bunch of Wemo devices at home that control lights. I found out that they've got a buffer overflow that Wemo "will not be fixing" because the devices are end of life. AWS Reported a GuardDuty Finding Issue The tool of the week: IAMbic lets you tailor AWS Identity Center permissions per account.

Today's guest is Ivan Galea, VP, Head of Data Science at Atlassian. Founded in 2002, Atlassian build tools like Jira, Confluence, Bitbucket, and Trello to help teams across the world become more nimble, creative and aligned. From medicine and space travel, to disaster response and pizza deliveries, Atlassian's products help teams all over the planet advance humanity through the power of software. With a team of 7000+ Atlassians supporting an international group of 250,000+ customers, it is their mission is to help unleash the potential of every team. Ivan is passionate about the power of data to create innovations, change lives and drive business forward. He has over 15 years of leadership experience working with engineering and business applications of new technologies, including at a startup technology firm. Ivan has a proven track record of building and mentoring high-performance teams, and has strong business development experience gained in the technology and financial services industries. In the episode, Ivan will discuss: Their mission at Atlassian, The day-to-day life of the Data Science team, Impact that their technology brings to customers, What excites him for the near future at Atlassian and Why Atlassian is a great place to work

Guest Derek Kozel | Abby Cabunoc Mayes Panelist Richard Littauer Show Notes Welcome back to another episode of Sustain! The podcast where we talk about sustaining open source for the long haul. Richard is at the State of Open Con 2023 UK in London, and he's excited to have his first ever in-person podcasts. On this episode he has two guests for us to enjoy. His first guest is the President of GNU Radio, Derek Kozel. Hear the moment Derek blows Richard's mind about all the uses for GNU Radio. Plus, Derek gets into how a 22-year-old project gets effectively run and funded. Interesting! Then, joining him on the second half is Abigail Cabunoc Mayes. Abby is a fellow Sustainer, a “prominent” (not somewhat) voice in open source community, and the Open Source Program Manager at GitHub. Phew. Abby is here today to talk about the importance of maintainers. Enjoy these great discussions now, just click the download button. [00:01:14] Derek explains what GNU Radio is and all its uses. [00:02:15] Richard's mind gets blown. (poof) [00:03:08] Derek tells us the size of the GNU Radio community. [00:04:10] This is a 22-year-old project, so grab some takeaways from this experienced community. Derek discusses how they've kept it going so smoothly. [00:05:50] Wait, What??!! Richard's mind gets blown 2.0. Derek tells us how the project all started from a court case. [00:07:12] We learn they are funded by GRCon. [00:08:31] Richard asks how GNU Radio is working to ensure inclusion and diversity. [00:10:34] Derek circles back to funding and how they use funds generated for the project. [00:11:58] Derek talks about his favorite workshop at State of Open Con 2023 UK and learning about succession planning. [00:17:04] Want to find out more about GNU Radio and Derek on the internet? He shares where to find him and GNU Radio. [00:19:09] Abby joins us for the second half and talks about her recent trip to FOSDEM and learning how GitHub IS a part of the open source community. [00:20:05] Succession Planning was a talk she gave at FOSDEM and was well received. [00:20:24] What were Abby's main takeaways from FOSDEM? [00:21:46] Richard circles back to Abby's succession planning talk and they deep dive into it. Take notes! [00:24:14] Abby gives advice for maintainers trying to get the right kinds of contributors for the future of your projects. [00:27:41] Not everyone wants to be a leader, and Richard wants to know how people can position themselves that way within a project. [00:29:02] Abby talks about what she's been working on, which is the GitHub Maintainer Community, a private GitHub repo. [00:30:24] Richard is interested to know if Abby has learned anything from talking to similar community leads at GitLab or Bitbucket. [00:32:35] Find out where to follow Abby on the web. Links SustainOSS (https://sustainoss.org/) SustainOSS Twitter (https://twitter.com/SustainOSS?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor) SustainOSS Discourse (https://discourse.sustainoss.org/) podcast@sustainoss.org (mailto:podcast@sustainoss.org) Richard Littauer Twitter (https://twitter.com/richlitt?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor) Derek Kozel Website (https://www.derekkozel.com/) Derek Kozel LinkedIn (https://www.linkedin.com/in/dkozel/) Derek Kozel Twitter (https://twitter.com/derekkozel?lang=en) Derek Kozel Mastodon (https://mastodon.social/@dkozel@social.coop) GNU Radio (https://www.gnuradio.org/) Abby Cabunoc Mayes LinkedIn (https://www.linkedin.com/in/abbycabs/) Abby Cabunoc Mayes Twitter (https://twitter.com/abbycabs) Abby Cabunoc Mayes GitHub (https://github.com/abbycabs) Abby Cabunoc Mayes Hachyderm (https://hachyderm.io/@abbycabs) FOSDEM 23 – Creating Pathways That Invest in New Maintainers (https://fosdem.org/2023/schedule/event/pathways_that_invest_in_new_maintainers/) Credits Produced by Richard Littauer (https://www.burntfen.com/) Edited by Paul M. Bahr at Peachtree Sound (https://www.peachtreesound.com/) Show notes by DeAnn Bahr Peachtree Sound (https://www.peachtreesound.com/) Special Guests: Abigail Cabunoc Mayes and Derek Kozel.

Se você precisa de mais segurança para seus códigos e plataformas como GitHub, Bitbucket e GitLab não conseguem suprir essa necessidade, está na hora de criar seu próprio servidor privado de Git com CodeCommit da AWS.E a melhor parte é que você nem precisa de um servidor, o CodeCommit te oferece toda a segurança de um servidor on-premises, mas com tudo em nuvem e gerenciado.Inscreva-se para o pré-lançamento do Curso AWS:https://www.uminventorqualquer.com.br/curso-aws/Canal Wesley Milan: https://bit.ly/3LqiYwgInstagram: https://bit.ly/3tfzAj0LinkedIn: https://www.linkedin.com/in/wesleymilan/Podcast: https://bit.ly/3qa5JH1

Subscribe to the Podcast in your player of choice Subscribe hereSimonG wants to do some clever stuff with GitHub for his new platform and has been diving into their API. SimonB spent many months working with the GitLab API and is excited to talk about that experience. This gives us a chance to talk about the differences between GitHub, GitLab and BitBucket and which one is better and for who.The GitHub API and GitLab API are very powerful and nearly let you make your own Git client for the platforms, if you want a good challenge and an interesting API to work with then either of these are worth spending a few afternoons with - they will also make you much better at Git and you will learn more about how Git works.Oh and we also look at a fun timeline website showing all the missteps Elon Musk has made since taking over at Twitter.Links Twitter Is Going Great Web3 Is Going Great GitHub API GitLab API BitBucket Want more from us? Find Simon B at All The Code Find Simon G at The Ionic Academy Subscribe to the Podcast in your player of choice Subscribe here

Bitbucket Patch, Cracked Cobolt Versions, Discord takeover, Meta internal threat & BEC Cybersecurity News CyberHub Podcast November 21st, 2022 Today's Headlines and the latest #cybernews from the desk of the #CISO: Atlassian Patches Critical Vulnerabilities in Bitbucket, Crowd 34 Cracked Versions of Popular Cobalt Strike Hacking Toolkit in the Wild New ransomware encrypts files, then steals your Discord account Omron PLC Vulnerability Exploited by Sophisticated ICS Malware Meta Reportedly Fires Dozens of Employees for Hijacking Users' Facebook and Instagram Accounts US charges BEC suspects with targeting federal health care programs Story Links: https://www.securityweek.com/atlassian-patches-critical-vulnerabilities-bitbucket-crowd https://thehackernews.com/2022/11/google-identifies-34-cracked-versions.html https://www.bleepingcomputer.com/news/security/new-ransomware-encrypts-files-then-steals-your-discord-account/ https://www.securityweek.com/omron-plc-vulnerability-exploited-sophisticated-ics-malware https://thehackernews.com/2022/11/meta-reportedly-fires-dozens-of.html https://www.bleepingcomputer.com/news/security/us-charges-bec-suspects-with-targeting-federal-health-care-programs/ “The Microsoft Doctrine” by James Azar now on Substack https://jamesazar.substack.com/p/the-microsoft-doctrine The Practitioner Brief is sponsored by: Your BRAND here - Contact us for opportunities today! ****** Find James Azar Host of CyberHub Podcast, CISO Talk, Goodbye Privacy, Digital Debate, and Other Side of Cyber James on Linkedin: https://www.linkedin.com/in/james-azar-a1655316/ Telegram: CyberHub Podcast ****** Sign up for our newsletter with the best of CyberHub Podcast delivered to your inbox once a month: http://bit.ly/cyberhubengage-newsletter ****** Website: https://www.cyberhubpodcast.com Youtube: https://www.youtube.com/c/TheCyberHubPodcast Rumble: https://rumble.com/c/c-1353861 Facebook: https://www.facebook.com/CyberHubpodcast/ Linkedin: https://www.linkedin.com/company/cyberhubpodcast/ Twitter: https://twitter.com/cyberhubpodcast Instagram: https://www.instagram.com/cyberhubpodcast Listen here: https://linktr.ee/cyberhubpodcast The Hub of the Infosec Community. Our mission is to provide substantive and quality content that's more than headlines or sales pitches. We want to be a valuable source to assist those cybersecurity practitioners in their mission to keep their organizations secure. Thank you for watching and Please Don't forget to Like this video and Subscribe to my Channel! #cybernews #infosec #cybersecurity #cyberhubpodcast #practitionerbrief #cisotalk #ciso #infosecnews #infosec #infosecurity #cybersecuritytips #podcast #technews #tinkertribe #givingback #securitytribe #securitygang #informationsecurity

Atlassian Bitbucket Exploit, Dell Exploit, Exchange Zero Day, Pentagon Bug Bounty & Espionage Cybersecurity News CyberHub Podcast October 3rd, 2022 Today's Headlines and the latest #cybernews from the desk of the #CISO: CISA Warns of Attacks Exploiting Recent Atlassian Bitbucket Vulnerability Hackers Exploiting Dell Driver Vulnerability to Deploy Rootkit on Targeted Computers Microsoft Links Exploitation of Exchange Zero-Days to State-Sponsored Hacker Group Pentagon bug bounty program turns up nearly 350 vulnerabilities Ex-NSA Employee Arrested for Trying to Sell U.S. Secrets to a Foreign Government Story Links: https://www.securityweek.com/cisa-warns-attacks-exploiting-recent-atlassian-bitbucket-vulnerability https://thehackernews.com/2022/10/hackers-exploiting-dell-driver.html https://www.securityweek.com/microsoft-links-exploitation-exchange-zero-days-state-sponsored-hacker-group https://therecord.media/pentagon-bug-bounty-program-turns-up-nearly-350-vulnerabilities/ https://thehackernews.com/2022/10/ex-nsa-employee-arrested-for-trying-to.html “The Microsoft Doctrine” by James Azar now on Substack https://jamesazar.substack.com/p/the-microsoft-doctrine The Practitioner Brief is sponsored by: Your BRAND here - Contact us for opportunities today! ****** Find James Azar Host of CyberHub Podcast, CISO Talk, Goodbye Privacy, Digital Debate, and Other Side of Cyber James on Linkedin: https://www.linkedin.com/in/james-azar-a1655316/ Telegram: CyberHub Podcast ****** Sign up for our newsletter with the best of CyberHub Podcast delivered to your inbox once a month: http://bit.ly/cyberhubengage-newsletter ****** Website: https://www.cyberhubpodcast.com Youtube: https://www.youtube.com/c/TheCyberHubPodcast Rumble: https://rumble.com/c/c-1353861 s Facebook: https://www.facebook.com/CyberHubpodcast/ Linkedin: https://www.linkedin.com/company/cyberhubpodcast/ Twitter: https://twitter.com/cyberhubpodcast Instagram: https://www.instagram.com/cyberhubpodcast Listen here: https://linktr.ee/cyberhubpodcast The Hub of the Infosec Community. Our mission is to provide substantive and quality content that's more than headlines or sales pitches. We want to be a valuable source to assist those cybersecurity practitioners in their mission to keep their organizations secure. Thank you for watching and Please Don't forget to Like this video and Subscribe to my Channel! #cybernews #infosec #cybersecurity #cyberhubpodcast #practitionerbrief #cisotalk #ciso #infosecnews #infosec #infosecurity #cybersecuritytips #podcast #technews #tinkertribe #givingback #securitytribe #securitygang #informationsecurity

Discussion this week around Chrome's Sanitizer API, and bypassing firewalls with webhooks and 0days (ModSecurity bypass), and a pre-auth BitBucket RCE. Links and summaries are available at https://dayzerosec.com/podcast/153.html [00:00:00] Introduction [00:00:31] Exploiting Web3's Hidden Attack Surface: Universal XSS on Netlify's Next.js Library [00:10:31] Breaking Bitbucket: Pre Auth Remote Command Execution [CVE-2022-36804] [00:16:25] [Chrome] Sanitizer API bypass via prototype pollution [00:23:02] How we Abused Repository Webhooks to Access Internal CI Systems at Scale [00:35:03] WAF bypasses via 0days [00:42:40] Cloning internal Google repos for fun and… info? [00:43:19] How to turn security research into profit: a CL.0 case study

Bitbucket Patch, Twilio Breach Expands in impact, LastPass Breach, Iran Log4j, Russia Cyberattack Cybersecurity News CyberHub Podcast August 29th, 2022 Today's Headlines and the latest #cybernews from the desk of the #CISO: Atlassian Ships Urgent Patch for Critical Bitbucket Vulnerability Twilio Breach Also Compromised Authy Two-Factor Accounts of Some Users DoorDash Discloses Data Breach Related to Attack That Hit Twilio, Others LastPass developer systems hacked to steal source code Iranian Hackers Exploiting Unpatched Log4j 2 Bugs to Target Israeli Organizations Montenegro Reports Massive Russian Cyberattack Against Govt Story Links: https://www.securityweek.com/atlassian-ships-urgent-patch-critical-bitbucket-vulnerability https://thehackernews.com/2022/08/twilio-breach-also-compromised-authy.html https://www.securityweek.com/doordash-data-compromised-following-twilio-hack https://www.bleepingcomputer.com/news/security/lastpass-developer-systems-hacked-to-steal-source-code/ https://thehackernews.com/2022/08/iranian-hackers-exploiting-unpatched.html https://www.securityweek.com/montenegro-reports-massive-russian-cyberattack-against-govt “The Microsoft Doctrine” by James Azar now on Substack https://jamesazar.substack.com/p/the-microsoft-doctrine The Practitioner Brief is sponsored by: Your BRAND here - Contact us for opportunities today! ****** Find James Azar Host of CyberHub Podcast, CISO Talk, Goodbye Privacy, Digital Debate, and Other Side of Cyber James on Linkedin: https://www.linkedin.com/in/james-azar-a1655316/ Telegram: CyberHub Podcast ****** Sign up for our newsletter with the best of CyberHub Podcast delivered to your inbox once a month: http://bit.ly/cyberhubengage-newsletter ****** Website: https://www.cyberhubpodcast.com Youtube: https://www.youtube.com/c/TheCyberHubPodcast Rumble: https://rumble.com/c/c-1353861 s Facebook: https://www.facebook.com/CyberHubpodcast/ Linkedin: https://www.linkedin.com/company/cyberhubpodcast/ Twitter: https://twitter.com/cyberhubpodcast Instagram: https://www.instagram.com/cyberhubpodcast Listen here: https://linktr.ee/cyberhubpodcast The Hub of the Infosec Community. Our mission is to provide substantive and quality content that's more than headlines or sales pitches. We want to be a valuable source to assist those cybersecurity practitioners in their mission to keep their organizations secure. Thank you for watching and Please Don't forget to Like this video and Subscribe to my Channel! #cybernews #infosec #cybersecurity #cyberhubpodcast #practitionerbrief #cisotalk #ciso #infosecnews #infosec #infosecurity #cybersecuritytips #podcast #technews #tinkertribe #givingback #securitytribe #securitygang #informationsecurity

### Topics GH Projects is on! Bitbucket + docker build Google + cookies CodeSandbox Projects Electron 20 Expo 46 Docosaurus 2.0 React Starting Kit + Vite Safari Technology Preview 150 ### Prowadzący Piotr i Sebastian https://www.linkedin.com/in/piotrzaborow/ https://www.linkedin.com/in/smysakowski ### Słuchaj jak Ci wygodnie Youtube https://youtu.be/xIxNKa9W5F4 Spotify http://bit.ly/devspresso_spotify Google Podcast http://bit.ly/devspresso_google_podcast iTunes http://bit.ly/devspresso_itunes SoundCloud https://soundcloud.com/devspresso/js-news-89 ### Timestamps 00:00 - Intro 01:00 - GH Projects is on! 03:39 - Bitbucket + docker build 06:16 - Google + cookies 09:10 - CodeSandbox Projects 14:29 - Electron 20 18:55 - Expo 46 23:33 - Docosaurus 2.0 25:31 - React Starting Kit + Vite 29:00 - Safari Technology Preview 150 ### Źródła GH Projects is on! https://github.blog/2022-07-27-planning-next-to-your-code-github-projects-is-now-generally-available/ Bitbucket + docker build https://bitbucket.org/blog/announcing-support-for-docker-buildkit-in-bitbucket-pipelines Google + cookies https://www.theregister.com/2022/07/28/google_postpones_thirdparty_cookie_phaseout/ CodeSandbox Projects https://codesandbox.io/post/open-beta Electron 20 https://www.electronjs.org/blog/electron-20-0 Expo 46 https://blog.expo.dev/expo-sdk-46-c2a1655f63f7 Docosaurus 2.0 https://docusaurus.io/blog/2022/08/01/announcing-docusaurus-2.0 React Starting Kit + Vite https://www.reddit.com/r/reactjs/comments/w9ki8d/react_starter_kit_21k_switched_from_webpack_to Safari Technology Preview 150 https://webkit.org/blog/13066/release-notes-for-safari-technology-preview-150/

Billionaire CEO's saving lives, Cloud updates, and new ScriptRunner for Bitbucket features, oh my!

Another toaster strudel debate?! Plus, the results are in for the most listened-to podcast in the RoR community! :: drum roll :: Steph has a "Dear Gerrit" message to share. Chris has a follow-up on mobile app strategy. The Bike Shed: 328: Terrible Simplicity (https://www.bikeshed.fm/328) When To Fetch: Remixing React Router - Ryan Florence (https://www.youtube.com/watch?v=95B8mnhzoCM) Virtual Event - Save Time & Money with Discovery Sprints (https://thoughtbot.com/events/save-time-money-with-discovery) Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: STEPH: thoughtbot's next virtual event "Save Time & Money with Discovery Sprints" is coming up on June 17th, from 2 - 3 PM Eastern. It's a discussion with team members from product management, design and development. From a developer perspective, topics will include how to plan a product's architecture, both the MVP and future version, how to lead a tech spikes into integrations and conduct a build vs buy reviews of third party providers. Head to thoughtbot.com/events to register, the event is June 17th 2 - 3 PM ET. Even if you can't make it, registering will get you on the list for the recording. CHRIS: We're the second-best. We're the second-best. Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. STEPH: And I'm Steph Viccari. CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? STEPH: I'm very happy to report that I picked up a treat from the store recently. So while I was in Boston and we were hanging out in person, we talked about Pop-Tarts because that always comes up as a debate, as it should. And then also Toaster Strudels came up, so I now have a package of Toaster Strudels, and those are legit. Pop-Tart or Toaster Strudel, I am team Toaster Strudel, which I know you're going to ask me about icing and if I put it on there, so go ahead. I'm going to pause. [laughs] CHRIS: It sounds like I don't even need to say anything. But yes, inquiring minds want to know. STEPH: I think that's also my very defensive response because yes, I put icing on my Toaster Strudel. CHRIS: How interesting. [laughs] STEPH: But it feels like a whole different class of pastry. So I'm very defensive about my stance on Pop-Tarts with no icing put Strudel with icing. CHRIS: A whole different class of pastry. Got it. Noted. Understood. So did you travel? Like, were these in your luggage that you flew back with? STEPH: [laughs] Oh no. They would be all gooey and melty. No, we bought them when we got back to North Carolina. Oh, that'd be a pro move; just pack little individual Strudels as your airplane snack. Ooh, I might start doing that now. That sounds like a great airplane snack. CHRIS: You got to be careful though if the icing, you know, if it's pressurized from ground level and then you get up there, and it explodes. And you gotta be careful. Or is it the reverse? It's lower pressure up in the plane. So it might explode. STEPH: [laughs] Either way, it might explode. CHRIS: Well, yeah. If you somehow buy a packet of icing that is sky icing that is at that pressure, and you bring it down, then...but if you take it up and down, I think it's fine. If you open it at the top, you might be in danger. If you open icing under the ocean, I think nothing's going to happen. So these are the ranges that we're playing with. STEPH: I will be very careful sky icing and probably pack two so that way I have a backup just in case. So if one explodes, we'll be like, all right, now I know what I'm working with and be more prepared for the next one. CHRIS: That's just smart. STEPH: I try to make smart travel decisions, Toaster Strudels on the go. Aside from travel treats and sky icing, I have some news regarding Planet Argon, who is a Ruby on Rails consultancy regarding their latest published this year's Ruby on Rails community survey results. And so they list a lot of fabulous different topics in there. And one of them includes a learning section that highlights most listened to podcasts in the Ruby on Rails community as well as blogs and some other resources. And Bike Shed is listed as the second most listened to podcast in the Ruby on Rails community, so whoo, golf clap. CHRIS: Fantastic. STEPH: And in addition to that, the thoughtbot blog got a really nice shout-out. So the thoughtbot blog is in the number two spot for the most visited blogs in the community. In the first spot is Ruby Weekly, which is like, you know, okay, that feels fair, that feels good. So it's really exciting for the thoughtbot blog because a lot of people work really hard on curating and creating that content. So that's wonderful that so many people are enjoying it. And then I should also highlight that for the podcast in first place is Remote Ruby, so congrats to Chris, Jason, and Andrew for grabbing that number one spot. And Brittany Martin, host of the Ruby on Rails Podcast, along with Brian Mariani, Jemma Issroff, and Nick Schwaderer, are in the number three spot. And some people say that Ruby is losing steam but look at all that content and all those highly ranked podcasts. I mean, we like Ruby so much we're spending time recording ourselves talking about it. So I say long live Ruby, long live Rails. CHRIS: Yes. Long live Ruby indeed. And yeah, it's definitely an honor to be on the list and to be amongst such other wonderful shows. Certainly big fans of the work of those other podcasts. We even did a joint adventure with them at one point, and that was a really wonderful experience, so yeah, honored to be on the list alongside them. And to have folks out there in the world listening to our tech talk and nonsense always nice to hear. STEPH: Yeah. You and I show up and say lots of silly things and technical things into the podcast. The true heroes are the ones that went and voted. So thank you to everybody who voted. That's greatly appreciated. It's really nice feedback. Because we get listener responses and questions, and those are wonderful because it lets us know that people are listening. But I have to say that having the survey results is also really nice. It lets us know people like the show. Oh, but I did go back and look at some of the previous stats because then I was like, huh, so I'm paying attention. I looked at this year's, and I was like, I wonder what last year's was or the year before that. And I think this survey comes out every two years because I didn't see one for 2021. But I did find the survey results for 2020, which we were in the number one spot for 2020, and Remote Ruby was in the second spot. So I feel like now we've got a really nice, healthy podcasting war situation going on to see who can grab the first spot. We've got two years, everybody, to see who [laughs] grabs the number one spot. That's a lot of prep time for a competition. CHRIS: Yeah, I feel like we should be like, I don't know, planning elaborate pranks on them or something like that now. Is that where this is at? It's something like that, I think. STEPH: I think so. I think this is where you put like sky frosting inside someone's suitcase, and that's the type of prank that you play. [laughs] CHRIS: The best of pranks. STEPH: We'll definitely put together a little task force. And we'll start thinking of pranks that we all need to start playing on each other for the podcasting wars that we're entering for the next few years. But anywho, what's going on in your world? CHRIS: Let's see, what's going on in my world? A fun thing happened recently. I had a chance to reflect back on some architectural choices that we've made in the Sagewell platform. And one of those specific choices is how we've approached building our native mobile apps. We made what some listeners may remember is an interesting set of choices. In particular, in Episode 328, which we'll include a link to in the show notes, I shared with you the approach that we're doing, which is basically like, Inertia is great, web user great. We like the web as a platform. What if we were to wrap it in a native shell and find this interesting and somewhat unique hybrid trade-off point? And so, at that point, we were building it. We had most of it built out, and things were going quite well. I think we maybe had the iOS app in the store and the Android app approaching the store or something like that. At this point, both apps have been released to the store, so they are live. Production users are signing in. It's wonderful. But I had a moment in the past couple of weeks to reassess or look at that set of choices and evaluate it. And thankfully, I'm happy with the choices that we've made. So that's good. But to get into the specifics, there were two things that happened that really, really framed the choice that we made, so one was we introduced a major new feature. We basically overhauled the first-run experience, the onboarding that users experience, and added a new, pretty fundamental facet to the platform. It's a bunch of new screens, and flows, and error states, and all of this complexity. And in the process, we iterated on it a bunch. Like, first, it looked like this, and then we changed the order of the screens and switched out the error messages, and et cetera, et cetera. And I'll be honest, we never even thought about the mobile apps. It just wasn't even a consideration. And interestingly, we did as a final check before going fully live and releasing this out to the full production audience; we did spot check it in the mobile apps, and it didn't work. But it didn't work for a very specific, boring, technical reason that we were able to resolve. It has to do with iframes and WebViews and embedded something, something. And we had to set a flag. Thankfully, it was solvable without a deploy of the native mobile apps. And otherwise, we never thought about the native apps. Specifically, we were able to add this fundamental set of features to our platform. And they just worked in native mobile. And they were the same as they roughly are if you're on a mobile WebView or if you're on a desktop web, you know, slightly different in terms of form factor. But the functionality was all the same. And critically, the error states and the edge cases and the flow, there's so much to think about when you're adding a nontrivial feature to an app. And the fact that we didn't have to consider it really spoke to the choice that we made here. And again, to name it, the choice that we made is we're basically just reusing the same WebViews, the same Rails controllers, and the same what are Svelte components under the hood but the same essentially view layer as well. And we are wrapping that in a native iOS. It's a Swift application shell, and on Android, it's a Kotlin application shell. But under the hood, it's the same web stuff. And that was really great. We just got these new features. And you know what? If we have to rip that whole set of functionality out, again, we won't need to deploy. We won't need to rethink it. Or, if we want to subtly tweak it, we can do that. If we want to think about feature flags or analytics, or error states or error reporting, all of this just naturally falls out of the approach that we took. And that was really wonderful. STEPH: That's super nice. I also love this saga of like, you made a choice, and then you're coming back to revisit and share how it's going. So as someone who's never done this before, in regards of wrapping an application in the manner that you have and then publishing it and distributing it that way, what does that process look like? Is this one of those like you run a command, and literally, it's going to wrap the application and then make it hostable on the different mobile app stores? Or what's that? Am I oversimplifying the process? What does that look like? CHRIS: I think there are a lot of platforms or frameworks I think would probably be the better word like Capacitor is something that comes to mind or Ionic or Expo. There are a handful of them that are a little more fully featured in what they provide. So you just point us at your React Views and whatnot, and we'll wrap that up, and it'll be great. But those are for, I may be overgeneralizing here, but my understanding is those are for more heavy client-side bundles that are talking to a common API. And so you're basically taking your same rich client-side application and bundling that up for reuse on the native app, the native app platforms. And so I think those do have some release to the store sort of thing. In our case, we went a little bit further with that integration wrapper thing that we built. So that is a thing that we maintain. We have a Sagewell iOS repo and a Sagewell Android repo. There's a bunch of Swift and Kotlin code, respectively, in each of them, and we deploy to the stores manually. We're doing that whole process. But critically, the code that is in each of those repositories is just the bridge glue code that says, oh, when this Inertia navigation event happens, I'm going to push a WebView to the navigation stack. And that's what that is. I'm going to render the tab bar of buttons at the bottom with the navigation elements that I get from the server. But it's very much server-driven UI, is the way that I would describe it. And it's wrapping WebViews versus actually having the whole client bundle wrapped up in the thing. It's unfortunately subtle to try and talk through on the radio, but yeah. [laughs] STEPH: You're doing great; this is helping. So if there's a change that you want to make, you go to the Rails application, and you make that change. And then do you need to update anything on that iOS repo? It sounds like you don't, which then you don't have to push a new update to the store. CHRIS: Correct. For the vast majority of things, we do not need to make any changes. It's very rare for us to deploy the iOS or the Android app is a different way to put it or to push new releases to the store. It happens we may want to add a new feature to the sort of bridge layer that we built, but increasingly, those are rare. And now it's basically like, yeah, we're just wrapping those WebViews, and it's going great. And again, to name it, it's a trade-off. It's an intentional trade-off that we've made. We're never going to have the richest, most deep platform integration, smooth experience. We are making a small trade-off on that front. But given where we're at as an organization, given how early we are, how much iteration and change, we chose an architecture that optimizes for that change. And so again, like what you just said, yeah, I can...you know how it's really nice to be able to deploy six times a day on a web app, and that's a very straightforward thing to do? It is not so straightforward in the native mobile world. And so, we now have afforded ourselves the ability to do that. But critically, and this is the fun part in my mind, have the trade-offs in the controls. So if we were just like, it's just a WebView, and that's it, and we put it in the stores, and we're done, that is too far of an extreme in my mind. I think the performance trade-offs, the experience trade-offs, it wouldn't feel like a native app like in a deep way, in a problematic way. And so as an example, we have a navigation bar at the top of our app, particularly on iOS, that is native iOS navigation. And we have a tab bar at the bottom, which is native tab UI element. I forget actually what it's called, but it's those elements. And we hide the web application navigation when we're in the mobile context. So we actually swap those out and say, like, let's actually promote these to formal native functionality. We also, within our UI on the web, have a persistent button in the top right corner of your screen that says, "Need help? Reach out to your retirement advocate." who is the person that you get to work with. You can send questions, et cetera, et cetera. It's this little help sidebar drawer thing that pops out. And we have that as a persistent HTML button in the top corner of the web frame. But when we're on native, we push that up as a distinct element in the native UI section. And then again, the bridge that I'm talking about allows for bi-directional communication between the JavaScript side and the native side or the native side and the JavaScript side. And so it's those sorts of pieces that have now afforded us all of the freedom to tinker, and we don't need to re-release where we're like, oh, we want to add a new weird button that does a thing in the WebView when you click on a button outside the WebView. We now just have that built-in. STEPH: Yeah, I really like the flexibility that you're describing. When you promoted those elements to be more native-friendly so, like the navigation or the footer or the little get help chat, is that something that then your team implemented in like the iOS or the Kotlin repo? Okay, I see you nodding, but other people can't see that, so...[laughs] CHRIS: Yeah. I was going to also say the words, but yes, those are now implemented as native parts. So the thing that we built isn't purely agnostic decoupled. It is Sagewell-specific; a lot of it is low-level. Like, let's say we want to wrap an Inertia app in a native mobile wrapper. Like, 90% of the code in it is that, but then there are little bits that are like, and put a button up there. And that button is the Sagewell button. And so it's not entirely decoupled from us. But it mostly is this agnostic bridge to connect things together. STEPH: Yeah, the way you're describing it sounds really nice in terms of you're able to get out the app quickly and have a mobile app quickly that works on both platforms, and then you're still able to deploy changes without having to push that. That was always my biggest mental, or emotional hurdle with the idea of mobile development was the concept of that you really had to batch everything together and then submit it for review and approval and then get it released. And then you got to hope people then upgrade and get the newest version. And it just felt like such a process, not that I ever did much of it. This was all just even watching like the mobile team and all the work that they had to do. And I had sympathy pains for them. But the fact that this approach allows you to avoid a lot of that but still have some nice, customized, more native elements. Yeah, I'm basically just recapping everything you said because I like all of it. CHRIS: Well, thank you, friend. Like I said, I've really enjoyed it, and similar to you, I'm addicted to the feedback loop of the web. It's beautiful. I can deploy ten times or however many I want. Anytime I want, I can push out a new version. And that ability to iterate, to test, to explore, to tweak, to not have to do as much formal testing upfront because I'm terrified that if a bug sneaks out, then, it'll take me two weeks to address it; it just is so, so freeing. And so to give that up moving into a native context. Perhaps I'm fighting too hard to hold on to my dream of the ability to rapidly iterate. But I really do believe in that and especially for where we're at as an organization right now. But, and a critical but here, again, it's a trade-off like anything else. And recently, I happened to be out about in the town, and I decided, oh, you know what? Let me open up the app. Let me see what it's like. And I wasn't on great internet. And so I open the app, and it loads because, you know, it's a native app, so it pops up. But then the thing that actually happened is a loading spinner in the middle of the screen and sort of a gray nothing for a little while until the server request to fetch the necessary UI elements to render the login screen appeared. And that experience was not great. In particular, that experience is core to the experience of using the app every single time. Every time you use it, you're going to have a bad time because we're re-downloading that UI element. And there's caching, and there's things that could happen there to help with that. But fundamentally, that experience is going to be a pretty common one. It's the first thing that you experience when you're opening the app. And so I noticed that and I chatted with the team, and I was like, hey, I feel like this is actually something that fixing this I think would really fundamentally move us along that spectrum of like, we've definitely made some trade-offs here. But overall, it feels snappy and like a native app. And so, we opted to prioritize work on a native login screen for both platforms. This also allows us to more deeply integrate. So particularly, we're going to get biometric logins like fingerprints or face scans, or whatever it is. But critically, it's that experience of like, I open the Sagewell native app on my iOS phone, and then it loads immediately. And then I show it my face like we do these days, and then it opens up and shows me everything that I want to see inside of it. And it's that first-run experience that feels worth the extra effort and the constraints. Because now that it's native mobile, that means in order to change it, we have to do a deploy, not a deploy, release; that's what they call it in the native world. [laughs] You can tell I'm well-versed in this ecosystem. But yeah, we're now choosing that trade-off. And what I really liked about this sort of set of things like the feature that we were able to just accidentally get for free on native because that's how this thing is built. And then likewise, the choice to opt into a fully native login screen like having that lever, having that control over I'm going to optimize for iteration generally, but where it's important, we want to optimize for performance and experience. And now we have this little slider that we can go back and forth. And frankly, we could choose to screen by screen just slowly replace everything in the app with true native WebViews backed by APIs. And we could Ship of Theseus style replace every element of the app with true native mobile things until none of the old bridge code exists. And our users, in theory, would never know. Having that flexibility is really nice given the trade-off and the choice that we've made. STEPH: You said a word there that I missed. You said ship something style. CHRIS: Ship of Theseus. STEPH: What is that? CHRIS: It's like an old biblical story, I want to say, but it's basically the idea of, like, you have the ship. And then some boards start to rot out, so replace those boards. And then the mast breaks, you replace the mast. And slowly, you've replaced every element on the ship. Is it still the same ship at that point? And so it's sort of a philosophical question. So if we replace every single view in this app with a native view, is it still the same map? Philosophers will philosophize about it forever, but whatever. As long as we get to keep iterating and shipping software, then I'm happy. STEPH: [laughs] Y'all philosophize. That's that word, right? CHRIS: Yeah. STEPH: And do your philosopher thing. We'll just keep building and shipping. CHRIS: I don't know if I pronounced it right. It's like either Theseus or Theseus, and I'm sure I said the wrong one. And now that I've said the other, I'm sure both of them are wrong somehow. It's like a USB where there's up and down, and yet somehow it takes three tries. So anyway, I may have mispronounced it, and I may be misattributing it, but that's the idea I was going for. STEPH: Well, given I wasn't even familiar with the word until just now, I'm going to give both pronunciations a thumbs up. I also really like how you decided that for the login screen, that's the area that you don't want people to wait because I agree if you're opening an application or opening...maybe it's the first time, maybe it's the 100th time. Who knows? But that feels important. Like, that needs to be snappy. I need to know it's responsive. And it builds trust from the minute that I clicked on that application. And if it takes a long time, I just immediately I'm like, what are y'all doing? Are y'all real? Do you know what you're doing over there? So I like how you focused on that experience. But then once I log in, like if something is slow to log me in, I will make up excuses for the application all day where I'm like, well, you know, maybe it's my connection. It's fine. I can wait for the next screen to load. That feels more reasonable. And it doesn't undermine my trust nearly as much as when I first click on the app. So that feels like a really nice trade-off as well, or at least a nice area that you've improved while still having those other trade-offs and benefits that you mentioned. CHRIS: To highlight it, you used a phrase there which I really liked. Like, it's building trust. If something's a little bit off in that first run experience every single time, then it kind of puts a question in the back of your head, maybe not even consciously. But you're just kind of looking at it, and you're like, what are you doing there? What are you up to, friend? Humans say to the apps they use on their phone. That's normal, right? When you talk... But to name it, we've also done a round of performance work throughout the app. And so there are a couple of layers to it. But it was work that we had planned for a while, but we kept deferring. But now that we're seeing more usage of the native apps, the native apps experience the same surface area of performance stuff but all the more so because they may be on degraded network connections, et cetera. And so this is another example where this whole thing kind of pays off. The performance work that we did affects everything. It affects the web. It's the same under the hood. It's let's reduce the network requests that we're making in the payloads that we're sending, particularly the network requests to upstream things, so like the banking partner that we're using and those APIs, like, collating all the data to then render the screen. Because of Inertia, we only have a single sort of back and forth conversation via the API as opposed to I think it's pretty common to have like seven different APIs and four different spinners on the screen. We're not doing that, none of that on my watch. [chuckles] But we minimize the background calls to the other parties that we're integrating with. And then, we reduce the payload of data that we're sending on each request. And each of those were like, we had to think about things and tweak and poke, but again it's uniform. So mobile web has that now, desktop web has that now. Android, iOS, they all just inherited it sort of that just happened one day without a deploy or release, without a release of either of the native mobile apps. We did deploy to the web to make that happen, but that's easy. I can do that a bunch of times a day. One last thing I want to share as we're on this topic of trade-offs and levers, there was a really great conference talk that I watched recently, which was Ryan Florence of remix.run also React Router fame if you're familiar with him from that. But he was talking about the most recent version of Remix, which is their meta framework on top of React. But they've done some really interesting stuff around processing data, fetching data, when and how to sequence that. And again, that thing that I talked about of nine different loading spinners on the screen, Remix is taking a very different approach but is targeting that same thing of like, that's not great for user experience. Cumulative layout shift being the actual number that you can monitor for this. But in that talk, there are features that they've added to Remix as a framework where you can just decide, like, do we wait for this or do we not? Do we make sure we have all of the data, or do we say, you know what? Actually, this is going to be below the fold. So it's okay to defer loading this until after we send down the first payload. And then we'll kick in, and we'll do it from the client-side. But it's this wonderful feature of the framework that they're adding in where there's basically just a keyword that you can add to sort of toggle that behavior. And again, it's this idea of like trade-offs. Are we okay with more layout shift, or are we okay with more waiting? Which is it that we're going to optimize for? And I really love that idea of putting that power very simply in the hands of the developers to make those trade-off decisions and optimize over time for what's important. So we'll share a link to that talk in the show notes as well. But it was very much in the same space of like, how do I have the power to decide and to change my mind over time? That's what I want. But yeah, with that, I think that's enough of me updating on the mobile app. I'll continue to share as new things happen. But again, I'm at this point very happy with where we're at. So yeah, it's been fun. But yeah, what else is up in your world? STEPH: I have a dear Gerrit message that I wrote earlier, so I want to share that with you. Gerrit is the system that we're using for when we push up code changes that then manages very similar in the competitive space of like GitHub and GitLab, and Bitbucket. And so the team that I'm working with we are using Gerrit. And Gerrit and I, you know, we get along for the most part. We've managed to have a working relationship. [chuckles] But this week, I wrote my dear Gerrit letter is that I really miss being able to tell a story with my commit messages. That is the biggest pain that I'm feeling right now. So for anyone that's less familiar or if you already are familiar with Gerrit, each change that Gerrit shows represents a single commit that's under review. And each change is identified by a Change-Id. So the basic concept of Gerrit is that you only have one commit per review. So if you were to translate that to GitHub terminology, every pull request is only going to have one commit, and so you really can't push up multiple. And so, where that has been causing me the most pain is I miss being able to tell a story. So like even simple stories that are like, hey, I removed something that's not used. I love separating that type of stuff into its own commit just so then people can see that as they're going through review. Now, before I merge, I'm likely to squash, and that doesn't feel important that it needs to be its own commit. That's really just for the reviewer so they can follow along for the changes. But the other one, I can slowly get over that one. Because essentially, the way I get around that is then when I do push up my code for review, is I then go through my change request, and then I just add comments. So I will highlight that line and say, "Hey, I'm removing this because it's not in use." And so, I found a workaround for that one. But the one I haven't found a workaround for is that I don't push up my local work very often because I love having lots of local, tiny, green commits so that way I can know the progress that I'm at. I know where I'm headed. Also, I have a safe space to roll back to, but then that means that I may have five or six commits that I have locally, but I haven't pushed up somewhere. And that is bothering me more and more hour by hour the more I think about it that I can't push stuff up because it makes me nervous. Because, I mean, usually, at least by the end of the day, I push everything up, so it's stored somewhere. And I don't have to worry about that work disappearing. Now I am working on a dev machine. So there is that aspect of it's technically...it's not even on my local machine. It is stored somewhere that I should still be able to access. CHRIS: What's a dev machine? The way you're saying it, it sounds like it's a virtual machine, not like a laptop. But what's a dev machine? STEPH: Good question. So the dev machine is a remote server or remote machine that then I am accessing, and then that's where I'm performing. That's where I'm writing all of my work. And then that's also kind of the benefit is everything is not local; it's controlled by the team. So then that also means that other teams, other individuals can help set up these environments for future developers. So then you have that consistency across everyone's working with the same Rails version, or gems, or has access to the same tools. So in that sense, my work isn't just on my laptop because then that would really worry me because then I've got nowhere...it's not backed up anywhere. So at least it is somewhere it's being stored that then could be accessed by someone. So actually, now, as I'm talking this through, that does help alleviate my concern about this a bit. [laughs] But I still miss it; I still miss being able to just push up my work and then have multiple commits. And I looked into it because I was like, well, maybe I'm misunderstanding something about Gerrit, and there's a way around this. And that's still always a chance. But from the research that I've done, it doesn't seem to be. And there are actually two very fiery takes that I saw that I have to share because they made me laugh. When I was Googling, the question of like, "Can I push up multiple commits to one single Gerrit CR? Or is there just a way to, like, can I have this concept of like a branch and then I have many commits, but then I turn it into one CR? Whatever the world would give me. What do they have? [laughs] I'm laughing just looking at this now. One of the responses was, have you tried squashing your commits into one commit? And I was like, [laughs] "Yeah, that's not what I had in mind, but sure." And then the other one, this is the more fiery take. They were very defensive about Gerrit, and they wrote that "People who don't like Gerrit usually just hack shit together. They cut corners and love squashing commits or throwing away history. And those people hate Gerrit. Developers who care love it. It's definitely possible and easy to produce agile software." And I just...that made me laugh. I was like, cool, I'm a developer that cuts corners and loves squashing commits. [laughs] CHRIS: So you don't care is what that take says. STEPH: I'm a developer who does not care. CHRIS: You know, Steph, I've worked with you for a while. And I've been looking for the opportunity to have this hard conversation with you. But I just wish you cared a little more about the software that you're writing, about the people that you're working with, about the commits that you're authoring. I just see it in every facet of your work. You just don't care. To be very clear for anyone listening at home, that is the deepest of sarcasm that I can make. Steph cares so very much. It's one of the things that I really enjoy about you. STEPH: I mean, we had the episode about toxic traits. This would have been the perfect time to confront me about my lack of caring about software and the processes that we have. So winding down on that saga, it seems to be the answer is no, friend; I cannot push up multiple commits. Oh, I tried to hack it. I am someone that tries to hack shit together because I tried to get around it just to see what would happen. [laughs] Because the docs had suggested that each change is identified by a Change-Id. And I was like, hmm, so what if there were two commits that had the same Change-Id, would Gerrit treat those as patch sets? Because right now, when you push up a change, you can see all the different patch sets, so that's nice. So that's a nice feature of Gerrit as you can see the history of, like, someone pushed up this change. They took in some feedback. They pushed up a new change. And so that history is there for each push that someone has provided. And I wondered maybe if they had the same Change-Id that then the patch sets would show the first commit and then the second commit. And so I manually altered the commits two of them to reference the same Change-Id. And I have to say, Gerrit was on to me because they gave me a very nice error message that said, "Same Change-Id and multiple changes. Squash the commits with the same Change-Ids or ensure Change-Ids are unique for each commit. And I thought, dang, Gerrit, you saw me coming. [laughs] So that didn't work either. I'm still in a world of where I now wait. I wait until I'm ready for someone to review stuff, and I have to squash everything, and then I go comment on my CRs to help out reviewers. CHRIS: I really like the emotional backdrop that you provided here where you're spending a minute; you're like, you know what? Maybe it's me. And there's the classic Seymour Skinner principle from The Simpsons. Am I out of touch? No, it's the children who are wrong. [laughs] And I liked that you took us on a whole tour of that. You're like, maybe it's me. I'll maybe read up. Nope, nope. So yeah, that's rough. There's a really interesting thing of tools constraining you. And then sometimes being like, I'm just going to yield control and back away and accept this thing that doesn't feel right to me. Like, Prettier does a bunch of stuff that I really don't like. It shapes code in a way, and I'm just like, no, that's not...nope, you know what? I've chosen to never care about this again. And there's so much utility in that choice. And so I've had that work out really well. Like with Prettier, that's a great example whereby yielding control over to this tool and just saying, you know what? Whatever you produce, that is our format; I don't care. And we're not going to talk about it, and that's that. That's been really useful for myself and for the teams that I'm on to just all kind of adopt that mindset and be like, yeah, no, it may not be what I would choose but whatever. And then we have nice formatted code; it's great. It happens automatically, love it. But then there are those times where I'm like; I tried to do that because I've had success with that mindset of being like, I know my natural thing is to try and micromanage and control every little bit of this code. But remember that time where it worked out really well for me to be like, I don't care, I'm just going to not care about this thing? And I try to not care about some stuff, which it sounds like that's what you're doing right here. [laughs] And you're like, I tried to not care, but I care. I care so much. And now you're in that [chuckles] complicated space. So I feel for you, Steph. I'm sorry you're in that complicated space of caring so much and not being able to turn that off [laughs] nor configure the software to do the thing you want. STEPH: I appreciate it. I should also share that the team that I'm working with they also don't love this. Like, they don't love Gerrit. So when I shared in the Slack channel my dear Gerrit message, they're both like, "Yeah, we feel you. [laughs] Like, we're in the same spot," which was also helpful because I just wanted to validate like, this is the pain I'm feeling. Is someone else doing something clever or different that I just don't know about? And so that was very helpful for them to say, "Nope, we feel you. We're in the same spot. And this is just the state that we're in." I think they have started transitioning some other repos over to GitLab and have several repos in Gitlab, but this one is still currently using Gerrit. So they very much commiserate with some of the things that I'm feeling and understand. And this does feel like one of those areas where I do care deeply. And frankly, this is one of those spaces that I do care about, but it's also like, I can work around it. There are some reasonable things that I can do, and it's fine as we just talked through. Like, the fact that my commits are not just locally on my machine already makes me feel better now that I've really processed that. So there are lower risks. It is more of just like a workflow. It's just, you know, it's crushing my work vibe. CHRIS: Harshing your buzz. STEPH: In the great words of Queen Elsa, I gotta let it go. This is the thing I'm letting go. So that's kind of what's going on in my world. What else is going on in your world? CHRIS: Well, first and foremost, fantastic reference and segue. I really liked that. But yeah, let's see, [laughs] what else is going on in my world? We had an interesting thing happen last week. So we had an outage on the platform last week. And then we had an incident review today, so a formal sort of post-mortem incident review. There are a couple of different names that folks have given to these. But this is a practice that we want to build within our engineering culture is when stuff goes wrong, we want to make sure that we have meaningful conversations around to try to address the root causes. Ideally, blameless is a word that gets used often in this context. And I've heard folks sort of take either side of that. Like, it's critical that it's blameless so that it doesn't feel like it's an attack. But also, like, I don't know, if one person did something, we should say that. So finding that gentle middle ground of having honest, real conversations but in a context of safety. Like, we're all going to make mistakes. We're all going to ship bugs; let's be clear about that. And so it's okay to sort of...anyway, that's about the process. We had an outage. The specific outage was that we have introduced a new process. This is a Sidekiq process to work off a specific queue. So we wanted that to have discrete treatment. That had been running, and then it stopped running; we still don't know why. So we never got to the root-root cause. Well, we know what the mechanism was, which was the dyno count for that process was at zero. And so, eventually, we found a bunch of jobs backed up in the Sidekiq admin. We're like, that's weird. And then, we went over to Heroku's configuration dashboard. And we saw, huh, that's weird. There are zero dynos processing this. That wasn't true yesterday. But unfortunately, Heroku doesn't log or have an audit trail around changes to those process counts. It's just not available. So that's unfortunate. And then the actual question of like, how did this happen? It probably had to be someone on the team. So there is like, someone did a thing. But that is almost immaterial because, again, people are going to do things, bugs will get shipped, et cetera. So the conversation very quickly turned to observability and understanding. I think we've done a pretty good job of instrumenting error reporting and being quite responsive to that, making sure the signal-to-noise ratio is very actionable. So if we see a bug or a Sentry alert come through, we're able to triage that pretty quickly, act on it where it is a real bug, understand where it's a bit of noise in the system, that sort of thing. But in this case, there were no errors. There was no Sentry. There was nothing; there was the absence of something. And so it was this really interesting case of that's where observability, I think, can really come in and help. So the idea of what can we do here? Well, we can monitor the count of jobs backed up in Sidekiq queue. That's one option. We could do some threshold alerting around the throughput of processed events coming from this other backend. There are a bunch of different ways, but it basically pushed us in the direction of doubling down and reinforcing the foundation of our observability within the platform. So we're just kicking that mini-project off now, but it is something we're like, yeah, we feel like we could add some here. In particular, we recently added Datadog to the stack. So we now have Datadog to aggregate our logs and ideally do some metric analysis, those sort of things, build some dashboards, et cetera. I haven't explored Datadog much thus far. But my sense is they've got the whiz-bang things that we need here. But yeah, it was an interesting outage. That wasn't fun. The incident conversation was actually a good conversation as a team. And then the outcome of like, how do we double down on observability? I'm actually quite excited for. STEPH: This is a fun moment for me because I have either joined teams that didn't have Datadog or have any of that sort of observability built into their system or that sort of dashboard that people go to. Or I've joined teams, and they already have it, and then nobody or people rarely look at it. And so I'm always intrigued between like what's that catalyst that then sparked a team to then go ahead and add this? And so I'm excited to hear you're in that moment of like, we need more observability. How do we go about this? And as soon as you said Datadog, I was like, yeah, that sounds nice because then it sounds like a place that you can check on to make sure that everything is still running. But then there's still also that manual process where I'm presuming unless there's something else you have in mind. There's still that manual process of someone has to check the dashboard; someone then has to understand if there's no count, no squiggly lines, that's a bad thing and to raise a concern. So I'm intrigued with my own initial reaction of, like, yeah, that sounds great. But now I'm also thinking about it still adds a lot of...the responsibility is still on a human to think of this thing and to go check it. Versus if there's something that gets sent to someone to alert you and say like, "Hey, this queue hasn't been processed in 48 hours. There may be a concern that actually feels nicer." It feels safer. CHRIS: Oh yeah, definitely. I think observability is this category of tools and workflows and whatnot. But I think what you're describing of proactive alerting that's the ideal. And so it would be wonderful if I never had to look at any of these tools ever. And I just knew if I got, let's say, it's PagerDuty connected up whatever, and I got a push notification from PagerDuty saying, "Hey, go look at this thing." That's all I ever need to think about. It's like, well, I haven't gotten a PagerDuty in a while, so everything must be fine, and having a deep trust in that. Similar to like, if we have a great test suite and it's green, I feel confident deploying the sort of absence of an alert being the thing that I can trust. But right now, we're early enough in this journey that I think what we need to do is stand up a bunch of these different graphs and charts and metric analysis and aggregations and whatnot, and then start to squint at it for a while and be like, which of these would I be really concerned if it started to wibble? And then you can figure the alerting around said wibble rate. And that's the dream. That's where we want to get to, but I think we've got to crawl, walk, run on this. So it'll be an adventure. This is very much the like; we're starting a thing. I'll tell you about it more when we've done it. But what you're describing is exactly what we want to get to. STEPH: I love wibble rate. That's my new measurement I'm going to start using for everything. It's funny, as you're bringing this up, it's making me think about the past week that Joël Quenneville and I have had with our client work. Because a somewhat similar situation came up in regards where something happened, and something was broken. And it seemed it was hard to define exactly what moment caused that to break and what was going on. But it had a big impact on the team because it essentially meant none of the bills were going through. And so that's a big situation when you got 100-plus people that are pushing up code and expecting some of the build processes to run. But it was one of those that the more we dug into it, the more it seemed very rare that it would happen. So, in this case, as a sort of a juxtaposition to your scenario, we actually took the opposite approach of where we're like; this is rare. But we did load up a lot of contexts. Actually, I was thinking back to the advice that you gave me in a previous episode where I was talking about at what point do you dig in versus try to stay at surface level? And this was one of those, like, we've spent a couple of days on getting context for this and understanding. So it felt really important and worthwhile to then invest a little bit more time to then document it. But then we still went with the simplest approach of like, this is weird. It shouldn't happen again. We think we understand it but then let's add a little bit of documentation or wiki page around like, hey, if you do run into this, here are some steps that will fix everything. And then, if you need to use this, let somebody know because this is so odd it shouldn't happen. So we took that approach in this case where we didn't increase the observability. It was more like we provided a fire extinguisher very close to the location in case it happens. And so that way, it's there should the need arise, but we're hoping it just never gets used. We're also in the process of changing how a lot of that logic works. So we didn't really want to optimize for observability into a system that is actively being changed because it should look very different in upcoming months. But overall, I love the conversations that you bring about observability, and I'm excited to hear about what wibble rates you decide to add to your Datadog dashboard. CHRIS: There's a delicate art and science to the selection of the wibble rates. So I will certainly report back as we get into that work. But with that, shall we wrap up? STEPH: Let's wrap up. CHRIS: The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeee!!!!!!!! ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Taylor Otwell's Twitter - https://twitter.com/taylorotwellLaravel Twitter - https://twitter.com/laravelphpLaravel Website - https://laravel.com/Laravel Socialite - https://laravel.com/docs/9.x/socialiteSocialite Providers - https://socialiteproviders.com/Atymic - https://atymic.dev/Laravel Scout - https://laravel.com/docs/9.x/scoutOAuth 2.0 - https://oauth.net/2/Elasticsearch - https://www.elastic.co/Algolia - https://www.algolia.com/doc/Meilisearch - https://www.meilisearch.com/Tighten.co - https://tighten.com/Laravel Sail - https://laravel.com/docs/9.x/sailVirtualBox - https://laravel.com/docs/9.x/homestead#provider-specific-virtualboxMindhive - https://mindhive.ro/en/home/Docker - https://www.docker.com/company/Docker Compose - https://docs.docker.com/compose/Homebrew - https://brew.sh/MySQL - https://www.mysql.com/Redis - https://redis.io/Takeout GitHub - https://github.com/tighten/takeoutTony Messias' Twitter - https://twitter.com/tonysmdev/Tony Messias' Blog - https://www.tonysm.com/Laravel Breeze GitHub - https://github.com/laravel/breezeLaravel Jetstream - https://jetstream.laravel.com/2.x/introduction.htmlLaravel Sanctum - https://laravel.com/docs/9.x/sanctumLaravel Fortify - https://laravel.com/docs/9.x/fortifyLaravel Cashier (Stripe) - https://laravel.com/docs/9.x/billingLaravel Passport - https://laravel.com/docs/9.x/passportLaravel Horizon - https://laravel.com/docs/9.x/horizonLaravel Telescope -https://laravel.com/docs/9.x/telescopeLaravel Dusk - https://laravel.com/docs/9.x/duskForge - https://forge.laravel.com/Laravel 9 - https://laravel.com/docs/9.x/releases#laravel-9Laravel Homestead - https://laravel.com/docs/9.x/homesteadLaravel Valet - https://laravel.com/docs/9.x/valet

Bitbucket 8.0, Developer Day 2022, and all the Atlassian Cloud news, with special guest host, industry veteran and Adaptavist CTO, Jon Mort. For show notes and full transcript, please visit https://www.adaptavist.com/blog/atlassian-ecosystem-podcast-ep-143-an-egregious-oversight

Chris and Andre tackle the latest news from around the globe in 10 minutes to help keep you up-to-date on what's happening, and also what's not. This week, they discuss: - Man whop aid $2.9m for NFT of Jack Dorsey's first tweet set to lose almost $2.9m (https://www.theguardian.com/technology/2022/apr/14/twitter-nft-jack-dorsey-sina-estavi) - Donald Trump Jr. Thinks His News App Will “Disrupt” Google and Apple (Really) (https://www.vanityfair.com/news/2022/03/donald-trump-jr-news-app-mxm) - Bitbucket was down and Andre was frustrated by this - The judge who tossed mask mandate misunderstood public health law, legal experts say (https://www.npr.org/sections/health-shots/2022/04/19/1093641691/mask-mandate-judge-public-health-sanitation) - 'Hypocrisy:' Tim Apple Scorches Zuck Over Metaverse Tax (https://gizmodo.com/apple-facebook-horizon-worlds-fees-fight-1848794749) Have a story you want us to cover next week? Send it to us at comments@chrisandandreshow.com. And be sure to visit chrisandandreshow.com for more content!

Kyle Teegarden, a Senior PM in the DevDiv group, gets us re-acquainted with the Redis offering on Azure and discusses all the latest features including the Enterprise tier. Media File: https://azpodcast.blob.core.windows.net/episodes/Episode423.mp3 YouTube: https://youtu.be/xKA-w7Icn00 Resources: Azure Cache for Redis | Microsoft Azure How to Improve Your Azure SQL Performance by up to 800% - Microsoft Tech Community Cache-Aside pattern - Azure Architecture Center Implement Redis Pub/Sub and Streams in Azure Cache for Redis - Learn Optimize your web applications by caching read-only data with Redis - Learn  Quickstart: Use Azure Cache for Redis in .NET Core Updates: Generally available: Node pool snapshot Generally available: Scale-down mode in AKS Public preview: Static Web Apps now supports Gitlab and Bitbucket for CI/CD Public preview: Azure Storage as share in Windows Code in App Service  Intelligent application protection from edge to cloud with Azure Web Application Firewall Customize your secure VM session experience with native client support on Azure Bastion  

Stormkit helps you can easily manage your frontend infrastructure. It integrates perfectly with your git flow. Simplify and automate complex processes over the entire life cycle of a Javascript application. Make building & delivering applications a delightful low-code-like experience. Deployment platform for JAMStack websites and node js applications, connect your app to GitLab, BitBucket. Vercel and Netlify are great products, we offer flexibility and you can host yourself and you can have full control over your served assets. It has been 3 years now and now we are 2 co-founders and we are bootstrapping. Over 2,000 users with little or no marketing and some paying customers.

Being pregnant is hard, but this tapas episode is good! Steph discovered and used a #yelling Slack channel and attended a remote magic show. Chris touches on TypeScript design decisions and edge cases. Then they answer a question captured from a client Slack channel regarding a debate about whether I18n should be used in tests and whether tests should break when localized text changes. This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. Emma Bostian (https://twitter.com/EmmaBostian) Ladybug Podcast (https://www.ladybug.dev/) Gerrit (https://www.gerritcodereview.com/) Gregg Tobo the Magician (https://astonishingproductions.com/) Sean Wang - swyx - better twitter search (https://twitter.com/swyx/status/1328086859356913664) Twemex (https://twemex.app/) GitHub Pull Request File Tree Beta (https://github.blog/changelog/2022-03-16-pull-request-file-tree-beta/) Sam Zimmerman - CEO of Sagewell Financial on Giant Robots (https://www.giantrobots.fm/414) TypeScript 4.1 feature (https://devblogs.microsoft.com/typescript/announcing-typescript-4-1/) The Bike Shed: 269: Things are Knowable (Gary Bernhardt) (https://www.bikeshed.fm/269) TSConfig Reference - Docs on every TSConfig option (https://www.typescriptlang.org/tsconfig#noUncheckedIndexedAccess) Rails I18n (https://guides.rubyonrails.org/i18n.html) This episode is brought to you by Studio 3T (https://studio3t.com/free). Try Studio 3T's full suite of features for 30 days, no payment details needed. Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. STEPH: And I'm Steph Viccari. CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, what's new in your world? STEPH: Hey, Chris. There are a couple of new things in my world, so one of them that I wanted to talk about is the fact that being pregnant is hard. I feel like this is probably a known thing, but I feel like I don't hear it talked about as much as I'd really like, especially in sort of like a professional context. And so I just wanted to share for anyone else that may be listening, if you're also pregnant, this is hard. And I also really appreciate my team. Going through the first trimester is typically where you experience a lot of morning sickness and fatigue, and I had all of that. And so I was at the point that most of my days, I didn't even start till about noon and even some days, starting at noon was a struggle. And thankfully, the thoughtbot client that I'm working with most of the teams are on West Coast hours, so that worked out pretty well. But I even shared a post internally and was like, "Hey, I'm not doing great in the mornings. And so I really can't facilitate any morning meetings. I can't be part of some of the hiring intros that we do," because we like to have a team lead provide a welcoming and then closing for anyone that's coming for interview day. I couldn't do those, and those normally happen around 9:00 a.m. for Eastern Time. And everybody was super supportive of it. So I really appreciate all of thoughtbot and my managers and team being so great about this. Also, the client team they're wonderful. It turns out growing a little human; I'm learning how hard it is and working full time. It's an interesting challenge. Oh, and as part of that appreciation because…so there's just not a lot of women that I've worked with. This may be one of those symptoms of being in tech where one, I haven't worked with tons of women, and then two, working with a woman who is also pregnant and going through that as well. So it's been a little bit isolating in that experience. But there is someone that I follow on Twitter, @EmmaBostian. She's also one of the co-hosts for the Ladybug Podcast. And she has been just sharing some of her, like, I am two months sleep deprived. She's had her baby now, and she is sharing some of that journey. And I really appreciate people who just share that journey and what they're going through because then it helps normalize it for me in terms of what I'm feeling. I hope this helps normalize it for anybody else that might be listening too. CHRIS: I certainly can't speak to the specifics of being pregnant. But I do think it's wonderful for you to use this space that we have here to try and forward that along and say what your experience is like and share that with folks and hopefully make it a little bit better for everyone else out there. Also, you snuck in a sneaky pro-tip there, which is work on the East Coast and have a West Coast team. That just sounds like the obvious correct way to go about this. STEPH: That has worked out really well and been very helpful for me. I'm already not a great morning person; I've tried. I've really strived at times to be a morning person because I just have this idea in my head morning people get more stuff done. I don't think that's true, but I just have that idea. And I'm not the world's best morning person, so it has worked out for many reasons but yeah, especially in helping me get through that first trimester and also just supporting family and other things that are going on. Oh, I also learned a pro-tip about Twitter. This is going to seem totally random, but it was relevant when I was searching for stuff on Twitter [laughs] that was related to tech and pregnancy. But I learned...because I wanted to be able to search for something that someone that I follow what they said but I couldn't remember who said it. And so I found that in the search bar, I can add filter:follows. So you can have your search term like if you're looking for cake or pregnancy, or sleep-deprived and then look for filter:follows, and then that will filter the search results to everybody that you follow. I imagine that that probably works for followers too, but I haven't tried it. CHRIS: I like the left turn you took us on there but still keeping it connected. On the topic of Twitter search, they apparently have a very powerful search, but it's also hidden, and you got to know the specific syntax and whatnot. But there is a wonderful project by Shawn Wang, AKA Swyx, on the internet, bettertwitter.netlify.com is the URL for it. I will share a link to his tweet introducing it. But it's a really wonderful tool that just provides a UI for all of these different filters and configurations. And both make discoverability that much better and then also make it easy to just compose one of these searches and use that. The other thing that I'll recommend is, I think it's a Chrome plugin. I'm guessing is what I'm working with here like a browser extension, but it's called Twemex, T-W-E-M-EX. And there's a sidebar in Twitter now, which just seems wonderful and useful. So as I'm looking at a Swyx post here, or a tweet as they're called on Twitter because I know that vernacular, there's a sidebar which is specific to Shawn Wang. And there's a search at the top so I can search within it. But it's just finding their most popular tweets and putting that on a sidebar. It's a very useful contextual addition to Twitter that I found just awesome. So that combination of things has made my Twitter experience much better. So yeah, we'll have show notes for both of those as well. STEPH: Nice. I did not know about those. This may cause someone to laugh at me because maybe it's easier than I think. But I can never remember that advanced search that Twitter does offer; I have to search it every time. I just go to Google, and I'm like, advanced Twitter search, and then it brings up a site for me, and then I use that as the one that Twitter does provide. But yeah, from the normal UI, I don't know how to get there. Maybe I haven't tried hard enough. Maybe it's hidden. CHRIS: It's like they're hiding it. STEPH: Yeah, one of those. [laughs] CHRIS: It's very costly. They have to like MapReduce the entire internet in order to make that search work. So they're like, well, what if we hide it because it's like 50 cents per query? And so maybe we shouldn't promote this too much. STEPH: [laughs] CHRIS: And let's just live in the moment, everybody. Let's just swim in the Twitter stream rather than look back at the history. I make guesses about the universe now. STEPH: [laughs] On a different note, I also discovered at thoughtbot in our variety of Slack channels that we have a yelling channel, and I had not used it before. I had not hung out there before. It's a delightful channel. It's a place that you just go, and you type in all caps. You can yell about anything that you would like to. And I specifically needed to yell about Gerrit, which is the replacement or the alternative that we're using for GitHub or GitLab, or Bitbucket, or any of those services. So we're using Gerrit, and I've been working to feel comfortable with the UI and then be able to review CRs and things like that. My vernacular is also changing because my team refers to them as change requests instead of pull requests. So I'm floating back and forth between CRs and PRs. And because I'm in Gerrit world, I missed some of the updates that GitHub made to their pull request review screen. And so then I happened to hop in GitHub one day, and I saw it, and I was like, what is this? So that was novel. But going back to yelling, I needed to yell about Gerrit because I have not found a way to collaborate with someone who has already pushed up changes. I have found ways that I can pull their changes which then took a little while. I found it in a sneaky little tab called download. I didn't expect it to be there. But then the actual snippet it's like, run this in your terminal, and this is then how you pull down the changes. And I'm like, okay, so I did that. But I can't push to their existing changes because then I get like, well, you're not the owner, so we're going block you, which is like, cool, cool, cool. Okay, I kind of get that because you don't want me messing up somebody else's content or something that they've done. But I really, really, really want to collaborate with this person, and we're trying to do something together, and you're blocking me. And so I had to go to the yelling channel, and I felt better. And I'm yelling again. [laughs] Maybe I don't feel that great because I'm getting angry again talking about it. CHRIS: You vented a little into the yelling channel; maybe not everything, though. STEPH: Yeah, I still have more to vent because it's made life hard. Every time I wanted to push up a change or pull down someone else's changes, there are now all these CRs that then I just have to go and abandon, which is then the terminology for then essentially closing it and ignoring it, so I'm constantly going through. And if I do want to pull in changes or collaborate, then there's a flow of either where I abandon mine, or I pull in their changes, but then I have to squash everything because if you push up multiple commits to Gerrit, it's going to split those commits into different CRs, don't like that. So there are a couple of things that have been pain points. And yeah, so plus-one for yelling channels, let people get it out. CHRIS: Okay, so definitely some feelings that you are working through here. I'm happy to work together as a team to get through some of them. One thing that I want to touch on is you very quickly hinted at GitHub has got a bunch of new things that are cool. I want to talk about those. But I want to touch [laughs] on an anecdote. You talked about pushing something up to someone else's branch. You're like, oh, you know, I made some changes locally, and I'm going to push them up. I had an interesting experience once where I was interacting with another developer. I had done some code review. They weren't quite understanding where I was. They had a lot of questions. And finally, I said, you know what? This will just be easier. Here, I pushed up a commit to your branch, so now you can see what I'm talking about. And I thought of this as a very innocuous act, but it was not interpreted that way. That individual interpreted it in a very aggressive sort of; it was not taken well. And I think part of that was related to I think of Git commits as just these little ephemeral things where you're like, throw it out, feel free. This is just the easiest way for me to communicate this change in the context of the work that you're doing. I thought I was doing a nice favor thing here. That was not how it went. We had a good conversation after I got to the heart of where we both were emotionally on this thing. It was interesting. The interaction of emotion and tech is always interesting. But as a result, I'm very, very careful with that now. I do think it's a great way as long as I've gotten buy-in from the person beforehand. But I will always spot check and be like, "Hey, just to confirm, I can just push up a commit to your branch, but are you okay with that? Is that fine with you?" So I've become very cautious with that. STEPH: Yeah, that feels like one of those painful moments where it highlights that the people that you work with that you are accustomed to having a certain level of trust or default trust with those individuals, and then working with someone else that they don't have that where the cup is half-full in terms of that trust, or that this person means well kind of feelings towards a colleague or towards someone that they're working with. So it totally makes sense that it's always good to check and just to be like, "Hey, I'd love to push up some changes to your branch. Is that cool?" And then once you've established that, then that just makes it easier. But I do remember that happening, and yeah, that was a bit painful and shocking because we didn't see that coming and then learned from it. CHRIS: I do think it's an important thing to learn, though, because for me, in that moment, this was this throwaway operation that I thought almost nothing of, but then another individual interpreted it in a very different way. And that can happen, that can happen across tons of different things. And I don't even want to live in the idealized world where it's just tech; we're just pushing around zeros and ones; there's no human to this. But no, I actually believe it's a deeply human thing that we're doing here. It's our job to teach the computers to be a little closer to us humans or something like that. And so it was a really pointed clarification of that for me where it was this thing that I didn't even think once about, no less twice, and yet someone else interpreted it in such a different way. So it was a useful learning situation for me. STEPH: Yeah, I totally agree. I think that's a really wise default to have to check in with people before assuming that they'll be comfortable with something that we're comfortable with. CHRIS: Indeed. But shifting back to what you mentioned of GitHub, a bunch of new stuff came in GitHub, and you were super excited about it. And then you went on to say other things about another system. [laughs] But let's talk about the great things in GitHub. What are the particular ones that have caught your eye? I've seen some, but I'm intrigued. Let's compare notes. STEPH: So this is one of those where I hadn't seen GitHub in quite a while, and then I hopped in, and I was like, this is different. But some of the things that did stand out to me right away is that on the left-hand side, I can see all of the files that have been changed, and so that's a really nice tree where I just then immediately know. Because that was one of the things that I often did going to a PR is that I would see what files are involved in this change because it was just a nice overview of what part of the applications am I walking through? Are there tests for this? Have they altered or added tests? And so I really like that about it. I'm sure there's other stuff. But that is the main thing that stood out to me. How about you? CHRIS: Yeah, that sidebar file tree is very, very nice, which I find surprising because I don't use a file tree in my editor. I only do fuzzy finding to jump to files. But I think there's something about whenever GitHub had the file list; these are all the files that are changed. I'm like, this is just noise. I can't look at this and get anything out of it. But the file tree is so much more...there's a shape to it that my brain can sort of pattern match on. And it's just a much more discoverable way to observe that information. So I've really loved that. That was a wonderful one. The other one that I was surprised by is GitHub semantic code analysis; stuff has gotten much, much better over time subtly. I didn't even notice this happening. But I was discussing something with someone today, and we were looking at it on GitHub, and I just happened to click on an identifier, and it popped up a little thing that says, "Oh, do you want to hop to the references or the definition of this?" I was like, that is what I want to do. And so I hopped to the definition, hopped to the definition of another thing, and was just jumping around in the code in a way that I didn't know was available. So that was really neat. But then also, I was in a pull request at one point, and someone was writing a spec, and they had introduced a helper just like stub something at the bottom of a given spec file. And it's like, I feel like we have this one already. And I just clicked on the identifier. I think it might have actually been a matcher in RSpec, so it was like, have alert. And I was like, oh, I feel like we have this one, a matcher specific to flash message alerts on the page. And I clicked on it, and GitHub provided me a nice little inline dialog that showed me all of the definitions of have alert, which I think we were up to like four of them at that point. So it had been copied and pasted across a couple of different files, which I think is totally fine and a great way to start, but they were very similar implementations. I was like, oh, looks like we actually already have this in a couple of places, maybe we clean it up and extract it to a common spec support thing, and ta-da, I was able to do all of that from the GitHub pull requests UI. And I was like, this is awesome. So kudos to the GitHub team for doing some nifty stuff. Also, can I get into the merge queue? Thank you. ... STEPH: [laughs] There it is. That is very cool. I didn't know I could do that from the pull request screen. I've seen it where if I'm browsing code that, then I can see a snippet of where everything's defined and then go there, but I hadn't seen that from the pull request. I did find the changelogs for GitHub that talk about the introduction of having the tree, so we'll be sure to include a link in the show notes for that too. But yes, thank you for letting me use our podcast as a yelling channel. It's been delightful. [laughs] Mid-roll Ad Hi, friends, and now a quick break to hear from today's sponsor, Scout APM. Scout APM is an application performance monitoring tool that's designed to help developers find and fix performance issues quickly. With an intuitive user interface, Scout will tie bottlenecks to source code so you can quickly pinpoint and resolve performance abnormalities like N+1 queries, slow database queries, and memory bloat. Scout also recently implemented external service monitoring, adding even more granularity when it comes to HTTP requests and API calls. So give Scout a try today with a free 14-day trial and experience first-hand why developers worldwide call Scout their best friend. And as an added bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. To learn more, visit scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. CHRIS: Well, speaking of podcasts, actually, there was an interesting thing that happened where the CEO of Sagewell Financial, the company of which I am the CTO of, Sam Zimmerman is his name, and he went on the Giant Robots Podcast with Chad a couple of weeks ago. So that is now available. We'll link to that in the show notes. I'll be honest; it was a very interesting experience for me. I listened to portions of it. If we're being honest, I searched for my name in the transcript, and it showed up, and I was like, okay, that's cool. And it was interesting to hear two different individuals that I've worked with either in the past or currently talking about it. But then also, for anyone that's been interested in what I'm building over at Sagewell Financial and wants to hear it from someone who can probably do a much better job of pitching and describing the problem space that we're working in, and all of the fun challenges that we have, and that we're hopefully living up to and building something very interesting, I think Sam does a really fantastic job of that. That's the reason I'm at the company, frankly. So yeah, if anyone wants to hear a little bit more about that, that is a very interesting episode. It was a little weird for me to listen to personally, but I think everybody else will probably have a normal experience listening to it because they're not the CTO of the company. So that's one thing. But moving on, I feel like today's going to be a grab bag episode or tapas episode, lots of small plates, as we were discussing as we were prepping for this episode. But to share one little thing that happened, I've been a little more removed from the code of late, something that we've talked about on and off in previous episodes. Thankfully, I have a wonderful team that's doing an absolutely fantastic job moving very rapidly through features and bug fixes and all those sorts of things. But also, I'm just not as involved even in code review at this point. And so I saw one that snuck through today that, I'm going to be honest, I had an emotional reaction to. I've talked myself down; we're fine now. But the team collectively made the decision to move from a line length of 80 characters to a line length of 120 characters, and I had some feelings. STEPH: Did you fire everybody? [laughs] CHRIS: No. I immediately said, doesn't really matter. This is the whole conversation around auto-formatting tools is like we're just taking the decision away. I personally am a fan of the smaller line length because I like to have multiple files open left to right. That is my reason for it, but that's my reason. A collective of the developers that are frankly working more in the code than I am at this point decided this was meaningful. It was a thing that we could automate. I think that we can, you know, it's not a thing that we have to manage. So I was like, cool. There we go. The one thing that I did follow up on I was like, okay; y'all snuck this one in, it's fine, I'm fine with it. I feel fine; everything's fine. But let's add that to the git-blame-ignore-revs file, which is a useful thing to know about. Because otherwise, we have a handful of different changes like this where we upgrade Prettier, and suddenly, the manner in which it formats the files changes, so we have to reformat everything at once. And this magical file that exists in Git to say, "Hey, ignore this revision because it is not relevant to the semantic history of the app," and so it also takes that decision out of the consideration like yeah, should we reformat or not? Because then it'll be noisy. That magical file takes that decision away, and so I love that. STEPH: I so love the idea because you took vacation recently twice. So I love the idea of there was a little coup and people are applauding, and they're like, while Chris is on vacation, we're going to merge this change [laughs] that changes the character line. And yeah, that brings me joy. Well, I'm glad you're working through it. Sounds like we're both working through some hard emotional stuff. [laughs] CHRIS: Life's tricky, is all I'm going to say. STEPH: I am curious, what prompted the 80 characters versus 120? This is one of those areas that's like, yeah, I have my default preference like you said. But I'm more intrigued just when people are interested in changing it and what goes with it. So do you remember one of the reasons that 120 just suited their preferences better? CHRIS: Frankly, again, I was not super involved in the discussion or what led them to it. STEPH: [laughs] CHRIS: My guess is 120 is used...I think 80 is a pretty common one. I think 120 is another of the common ones. So I think it's just a thing that exists out there in the mindshare. But also, my guess is they made the switch to 120 and then reformatted a few files that had like, ah, this is like 85 characters, and that's annoying. What does it look like if we bump it up? And so 120 provided a meaningful change of like, this is a thing that splits to four lines if we have an 80 character thing, or it's one line if it's 120 characters, which is a surprising thing to say, but that's actually the way it plays out in certain cases because the way Prettier will break lines isn't just put stuff on the next line always. It's got to break across multiple lines, actually. All right, now that we're back in the opinion space, I have a strong one. STEPH: This is The Bikeshed. We can live up to that name. [laughs] CHRIS: So I do want an additional configuration in Prettier Ruby. This is the thing I'll say. Maybe I can chase down Kevin Newton and see if he's open to this. But when Prettier does break method call with arguments going into it but no parens on that method call, and it breaks out to multiple lines, it does the dangling indent thing, which I do not like. I find it distasteful; I find it noisy, the shape of the code. I'm a big fan of the squint test. I know that from Sandi Metz, I believe, or maybe it's Avdi Grimm. I associate it with both of them in my mind. But it's just a way to look at the code and kind of squint, and you see the shape of it, and it tells you something. And when the lines break in that weird way, and you have these arbitrary dangling indents, the shape of the code is broken up. And I don't feel so strongly. I actually regularly stop myself from commenting on pull requests on this because it's very easy. All you need to do is add explicit parens, and then Prettier will wrap the line in what I believe is a much more aesthetically pleasing, concise, consistent, lots of other good adjectives here that are definitely just my preferences and not facts about the world. But so what I want is, Prettier, hey, if you're going to break this line across multiple lines, insert the parens. Parens are no longer optional for breaking across multiple lines; parens are only optional within a given line. So if we're not breaking across lines, I want that configuration because this is now one of those things where I could comment on this. And if they added the optional parens, then Prettier would reform it in a different way. And I want my auto formatter don't give me ways to do stuff. Like, constrain me more but also within the constraints of the preferences that I have, please, thank you. STEPH: I love all the varying levels there [laughter] of you want a thing, but you know it's also very personal to you and how you're walking that line and hopping back and forth on each side. I also love the idea. We have the idea of clean code. I really want something that's called distasteful code now [laughs] where you just give examples of distasteful code, yes. Well, I wish you good luck in your journey [laughs] and how this goes and how you continue to battle. I also appreciate that you mentioned when you're reviewing code how you know it's something that you really want, but you will refrain from commenting on that. I just appreciate when people have that filter to recognize, like, is this valuable? Is it important? Or, like you said, how can we just make this more of the default so then we don't even have to talk about it? And then lean into whatever the default the team goes with. CHRIS: Well, thank you. I very much appreciate that because, frankly, it's been very difficult. STEPH: I do have something I want to yell about but in a very positive way or pranting as we determined or, you know, raving, the actual real term that wonderful listeners pointed out to us. CHRIS: Prant for life. That's my stance. STEPH: We had a magic show at thoughtbot. It was all remote, but the wonderful Gregg Tobo, the magician, performed a magic show for us where we all showed up on Zoom. And it was interactive, and it was delightful, and it was so much fun. And so if you need something fun for your team that you just want to bring folks together, highly recommend. I had no idea I was going to enjoy a magic show this much, but it was a lot of fun. So I'll be sure to include some links in the show notes in case that interests anyone. But yeah, magic. I'm doing jazz hands. People can't see it, but magic. I like how you referred earlier, saying that today is more of like a tapas episode. And I'm realizing that all of my tapas are related to being pregnant, yelling, and magic shows, and I'm okay with that. [laughs] But on that note, what else is on your tapas plate? CHRIS: Actually, a nice positive one that came into the world...I always like when we get those. So this is interesting because I was actually looking back at the history, and I had Gary Bernhardt on The Bike Shed back in Episode 269. We'll include a link in the show notes. But we talked a bunch about various things, including TypeScript. And I was lamenting what I saw as a pretty big edge case in TypeScript. So the goal of TypeScript is like, all right, JavaScript exists, this is true. What can we do on top of that? Let's not fundamentally change it, but let's build a type system on top of it and try and make it so that we can enforce correctness but understand that JavaScript is a highly dynamic language and that we don't want to overconstrain and that we've got to meet it where it is. And so one of the design decisions early on with TypeScript is if you have an array and you say like it's an array of integers, so you have typed that array to be this is an array of int, or it will be an array of number in JavaScript because JavaScript doesn't have integers; they only have numbers. Cool. [laughs] Setting aside other JavaScript variables here, you have an array of numbers. And so if you use element access to say, like, say the name of array is array of nums and then use brackets and you say zero, so get me the first element of that array. TypeScript will infer the type of that to be a number. Of course, it's a number, right? You got an array of numbers, you take a number out of it, of course, you're going to have a number, except you know what's also an array of numbers? An empty array. Well, of course. So there's no way for TypeScript because that's a runtime thing, whether or not the array is full of things or not. Or imagine you get the third element from the array. Well, JavaScript will either return you the third element, which indeed is a number, or undefined because there's no third element in this array. So that is an unfortunate but very understandable edge case that TypeScript was like, listen, this is how JavaScript works. So we're not going to…frankly, we don't think the people embracing TypeScript and bringing it into their world would accept this amount of noise because this is everywhere. Anytime you interact with an array, you are going to run into this, this sort of uncertainty of did I actually get the thing? And it's like, yeah, no, I know how many things are in the array that I'm working with. Spoiler, you maybe don't is the answer. And so, we ran into this edge case in our codebase. We were accessing an element, but TypeScript was telling us, "Yes, definitively, you have an object of that type because you just got it out of an array, which is an array of that type." But we did not; we had undefined. And so we had, you know blah is not a method on undefined or whatever that classic JavaScript runtime error is. And I was like, well, that's very sad. But now we get to the fun part of the story, TypeScript, as of version 4.1, which came out like the week that I recorded with Gary Bernhardt, which was interesting to look at the timeline here. TypeScript has added a new configuration. So a new strictness dial that you can configure in your tsconfig called noUncheckedIndexedAccess. So if you have an array and you are getting an element out of it by index, TypeScript will say, "Hey, you got to check if that's undefined," because to be clear, very much could be undefined. And I was so happy to find this. We turned it on in our codebase. It found the error in the place that we actually had an error and then found a few others that I think probably had errored at some times. But it was just one of those for me very nice things to be able to dial up the strictness and enforce correctness within our codebase, and so I was very happy about it. Other folks may say that seems like too much work. And, you know, I get that, I get that take. I'm definitely on the side of I'm willing to go through the effort to have enforced correctness, but you know, that's a choice. STEPH: Yeah, that's thoughtful. I like that, how you said you can dial up the strictness so then as you are introducing TypeScript, then people have that option. There is an argument there in the back of my head that's like, well, if you're introducing types, then you want to start more strict because then you're just creating problems for yourself down the road. But I also understand that that can make things very difficult to then introduce it to teams in existing codebases. So that seems like a really nice addition where then people can say, "Yeah, no, I really want the strictness. This is why I'm here," and then they can turn that on. CHRIS: So TypeScript in the configuration has strict mode, so you say strict true. And that is a moving target with each new version of TypeScript. But it's their sort of [inaudible 28:14] set of things that are part of strict, but apparently, this one's not in it. So now I'm like, wait, can I have a stricter? Can I have a strictest option? Can I have dial it to 11, please? [laughs] Really rough me up and make sure my code is correct. But it is the sort of thing like when we turn any of these on; it will find things in our codebase. Some of them, we have to appease the compiler even though we know the code to be correct. But the code is not provably correct as it sits in our file. So I am, again, happy to make that exchange. And I like that TypeScript as a project gives us configurability. But again, I am on team where's the strictest button? I would like to push that as hard as I can and live that life. STEPH: Yeah, I like that phrasing that you just said about provably correct. That's nice. CHRIS: That's the world I want to live in, everything you own in the box to the left, which is probably correct. STEPH: [laughs] That's how that song goes. CHRIS: Yeah. This is a reference to move errors to the left, which I think I've referenced before. But now that I'm just referencing Beyoncé and not the actual article, it's probably worth referencing the article, but the idea of, like, if a user hits an error, that's not great. So let's move it back to QA, that's a little further to the left in sort of the timeline. But what if we could move it to an automated test in CI? But what if we could move it into your editor? What if we could move it even further to the left? And so, a type system tends to be sort of very far ratcheted up to the left. It's as early as possible that you can catch these. So again, to reference Beyoncé, everything you own in a box to the left. STEPH: [singing] Everything you own in the box to the left. CHRIS: Thank you for doing the needful work there. STEPH: [laughs] Mid-roll Ad And now a quick break to hear from today's sponsor, Studio 3T. When you're developing applications, it can often be a chore to work with your underlying data. Studio 3T equips you with a complete set of tools to work with MongoDB data. From building queries with drag and drop, to creating complex aggregation pipelines; Studio 3T makes it easy. And now, there's Studio 3T Free, a free edition of Studio 3T, which delivers an essential core of tools. This means you can get started, for free, with Studio 3T Free, and when you're ready, you can upgrade and enjoy even more features through Studio 3T Pro and Studio 3T Ultimate. The different editions unlock more tools and additional integrations with MongoDB, SQL, Oracle, and Sybase. You can start today by downloading Studio 3T Free, which also includes a 30-day free trial of all the features of Studio 3T Ultimate, so you can try out some of the enterprise features as well. No credit card required. To start your trial, head to studio3t.com/free that's studio3t.com/free. STEPH: I have a question for you that I'd really love to get your opinion on because I myself I'm waffling back and forth where someone brought up some really great points about a concern or just a question they had brought up around testing and i18n specifically. And I agree with the things that they're saying, but yet, there's also a part of me that doesn't, and so I'm Stephanie divided. And so, I'm trying to figure out where I stand on this. So let me dive in and give you some context; I'm going to share the statement/question that they had asked. So here we go. "One of my priorities has been I should be able to review a test without having to reference any other code. References to i18n means that I have to go over to YAML and make sure the right keys have the right values, and that seems error-prone. In some cases, a lack of a hit in the YAML defers to defaults. If the intent is to override the name of model attribute and error messages and it is coded incorrectly, the code fails silently without translating and uses the humanized attribute name, and that would go undetected. If libraries change structure, it might also fail silently as well, so to me, the only failsafe way is to be fully explicit in test." So this goes with the idea that if you're writing tests and then you're testing text, but it's on the screen or perhaps an email, that you're actually going to assert against that string that is shown to the user instead of referencing the i18n keys. And then that also backs up this person's idea that you really want to not have to jump around. If you're reading a test, everything you really need to know about that test should live very close by. And I really agree with that initial statement; I want everything that's very close to the test, especially if it's anywhere in that expectation line, I really want it close, so I can understand what's the expectation, what's under test, what are the inputs, what's the expected outcome. So I wholeheartedly support that idea. But yet, I am in the camp that I then will use YAML keys instead of providing that exact string because I do look at i18n as a helpful abstraction, and I want to trust that i18n is doing its job. And so that way, I don't have to provide that string that's there because then we're also choosing, okay, well, which language are we going to always use for our test? So this is the part where I feel divided. So I'm going to walk you through some of the reasons that I really support this idea and other reasons that I still use the i18n keys and then get your take on it. So there is a part of me that when I'm using the i18n YAML keys, it does make me sad because it reduces the readability in tests. Sometimes the keys are really well named where maybe it's a mailer.welcomemessage. And I'm like, okay, I understand the gist. I don't need to go see the actual string. I also think they highlighted a really good use case where if you're overriding behavior and it could default to something else, your test is still going to pass, and you don't actually know. So I could see the use case there where if you are overriding, then you want to be explicit about the string that you expect back. I also think there are some i18n messages that are fairly complex, and where then I really would like to see the string. So if you are formatting a date or a time or you're passing in just a lot of variables, then there's a chance that I do want to see how did that actually get generated for the person who's going to be reading it versus just maybe it's garbage text that came out? And I want to validate that the message that we think we're crafting is actually the one that the user is going to see. The case against actually being explicit, my biggest one is because then I do see i18n as a helpful abstraction. And I want to trust this abstraction that it's doing its job and it's doing it well. Because then if I do use explicit strings, it makes me sad if I change text from like hello to welcome, and now I have a failing test. I don't like that idea either. So I'm torn between these two worlds of it is very nice to have everything that you need in a test to be able to understand what is the expectation, but then I also lean into this abstraction and reference the i18n keys. So, Chris, with all of that, that was a bit of a whirlwind, [laughs] what are your thoughts? How do you test this stuff? CHRIS: Honestly, I'm surprised that you've got that much division in your own answer because for me, this is very obvious there's one...no, I'm kidding. This is obviously complicated. Similar to you, I think I'm going to have to give a grab bag of answers because I don't have a singular thought of like it is concretely this or that. I tend to go for explicit strings and tests all the way to...so like the readability of a test, and the conciseness of a test is interesting. I will often see developers extract. Say they're creating a user with a specific email, and then they log in with that email later, and then they expect something else. And so the email is referenced a few times, and they'll extract that into a variable called email. And I personally will tend to not do that. I will inline the literal string like user@example.com, and I'll do it in a few places. And I'm fine with that duplication because I like the readability of any given line that you're reading. So I will make that trade-off within tests. This is the thing I think we've talked about before, but the idea of DRY in tests is like I want to be careful applying that idea, Don't Repeat Yourself, to break apart the acronym. Those abstractions I will use them less than tests. And so I want the explicitness, I want the readability, I want to tell a little story, all of that feels true. That said, to flip it around, one of the things that I'm hearing...so I think I'm hearing a part of this that is around well, we can fail silently because we fail symmetrically in both the implementation and our test. Then an assertion may actually match even though it's matching on a fallback. I think that's a configurable thing. I would actually want my test to raise if I'm referencing an i18n key that is not defined. Now, granted, that's different for languages. And maybe this becomes a more complex story of like in production; in a different locale, it will fail because we don't have 100% parity across all our locale files. But fundamentally, I want to make sure that at least exists in our base, which I think typically would be en-US as the locale. I want to make sure all keys are looked up and found, and it's an error otherwise in our test. So that's a feeling. But am I misunderstanding that part of the story or how that configuration typically works? STEPH: No, I think you've got it. But just to make sure we're on the same page, so if you reference a key that doesn't exist, then it is going to fail. So at least you have your test failure is going to let you know that you've referenced something that doesn't exist. But if you are referencing, like if you want to override the defaults that Rails or i18n has provided for a model and say for an error message, if you reference that, but you want to override it, but then you've forgotten, that does exist. So you're not going to get the failure; you're going to get a different message. So it's probably not a terrible experience for the user. It's not going to crash. They're going to see something, but they're not going to see the custom message that you intended them to see. CHRIS: Gotcha. Okay, well, just to name it, the thing that I was describing, I don't know that that would be the configuration for every system. So I would strongly encourage any system where i18n just has a singular behavior which is we fall back to the key. I want my test to absolutely tell me if that's happening. And that should be a failure of the test. But to the discoverability documentation bit, I do wonder if tooling can actually help answer the question. And as I was describing the wonderful experience I had on GitHub the other day, viewing code as just static characters in a file is both true and also, I think increasingly, a limited view of it. We have editors, and we have code hosting tools that can understand semantically our code a little bit better. There's got to be like 20 Different VS Code plugins that, when you hover on an i18n reference, it will do the lookup for you. That feels like a thing that exists, and if it doesn't, well, now I've nerd-sniped myself, and I got a weekend project. JK, I'm definitely not building that this weekend. But that feels like can we use that to solve this? Maybe not. But that's just another thought of where we have these limitations where it's static, like those abstractions can be useful. But if we can very quickly dereference them, then the cost of the abstraction or that separation becomes smaller, and so the pain is reduced. And I wonder if that's a way to sort of offset it. STEPH: If I can poke at that a little bit more, because I think you're touching on something that I haven't expressed or thought through explicitly, but it's the idea of, like, why do I like the abstraction? What is it that's drawing me towards using these keys? And I think it's because most of the cases, I don't care. I don't care what the string is, and so that feels nice. Like, I understand that, yes, we're referencing something. If that key didn't exist, I'm going to see a failure. So I know that there's text there, and that's why I do lean into referencing the keys instead of the text because it feels good to not have to care about that stuff. And if we do make changes to the text, then it suddenly doesn't fail, and then I have to go update a test because we added a period or added a comma. I think that's the path of more sadness for me. And my goal is always a path of least sadness. So I think that's why I lean into it [laughs], I'm guessing. Is that why you lean into it as well? Or what do you like about referencing the keys over the explicit text? CHRIS: No, I think I share your inclination there, and the reason that you're in favor of it, and I think the consistency like if we're going to use i18n, then we should lean in because it's a non-trivial thing to do like porting to i18n projects, and they're tricky. Getting it right from the first step is also tricky. If you're going to do it, then let's lean in, and thus let's use that abstraction overall. But yeah, same ideas as you. STEPH: Cool. I think that helps validate where I'm at in terms of how I rationalize about this where ultimately, I do like leaning into that abstraction. And as you'd mentioned, some of those porting projects, I haven't been on one specifically, but I've seen that they are a lot of work. And so, if we have that in our system, then we want to continue to use it. It does reduce some of the readability. Like you said, maybe there's a VS Code plugin or some way that then we can help people be able to see if they want that full context in the test and not have to jump over to YAML. But yeah, otherwise, unless it's overriding default behavior or complex, then that's what I'm going to go with is with the keys. But I really appreciate this person's very thoughtful question and approach to testing because, normally or typically, I fully agree with I want full context in the test. And this one was one of those outliers that came up for me, and I had to really think through all the feelings and the reasons that I have for those feelings. On that note, shall we wrap up? CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey. STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeee!!!!!! ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Matthew Stublefield's last episode features discussions about updates to Atlassian cloud, as well as on-premise Jira, Confluence, and Bitbucket. For a transcript and full list of show notes, please visit https://www.adaptavist.com/blog/atlassian-ecosystem-podcast-ep-140-matthew-signs-off

This episode we're discussing software product development with Sean McCullough, Head of Engineering for Atlassian Compass. Atlassian is the development behemoth behind other products such as Jira, Confluence, Trello and Bitbucket. Prior to that, Seanworked as an engineer at Facebook and also at Groupon

Atlassian is the powerhouse behind popular productivity software brands including Jira, Confluence, Bitbucket, and Trello. Their solutions help more than 170,000 businesses, and in this episode of the Breakout Growth Podcast Sean Ellis and Ethan Garr are joined by Atlassian’s Senior Growth Product Manager, Andrea Ho. Today, Atlassian is one of the most respected and fast-growing companies in the world, but it took some time before the company was able to dial in growth. Andrea says she and many others in Australia have been attracted to this “homegrown unicorn” because the company is always innovating in its quest to create valuable, self-serve, low CAC, affordable enterprise software. Atlassian has done an artful job of capitalizing on its successes. Building and acquiring valuable products that help customers achieve their goals has helped create a strong brand and a powerful word-of-mouth engine. Andrea’s team is then tasked with the “expansion” part of the company’s “land and expand” growth approach. They focus on getting clients to adopt Atlassian solutions across the full organization as well as on driving customers from one product within the Atlassian ecosystem to another. This approach has helped create the company’s enormous value. Atlassian currently has a market cap of over $62 billion and a team of over 5000 employees. But Andrea explains there is always more work to be done, and the team is constantly working to evolve its growth process. So join us as we learn what’s driving Atlassian’s breakout growth success. We discussed: * What’s a growth product manager vs. a product manager? (4:01) * Atlassian’s rise to global success (9:30) * Why having a revenue goal has been a good challenge for Andrea (15:33) * The “why” behind Atlassian’s new North Star Metric (17:25) * Insights into the growth team structure (24:40) * The “land and expand” growth engine (27:52) And much, much, more . . .

GIT es la herramienta más utilizada para controlar versiones en proyectos de desarrollo web, programación, e Ingeniería de Software. Git es un sistema de Control de versiones open source creado por Linus Torvalds. Git te permite guardar el historial de todos los cambios en el proyecto y permite la colaboración en un equipo de programadores localmente

We continue our discussion with Jens Schumacher and Justen Stepka, long-time Atlassian vets who have seen the software sector inside and out. We take a broader focus in this discussion, looking at SaaS competition, the importance of integrated cloud stacks, and the broader COVID and macro set-up. This leads to us diving in on Atlassian, on PagerDuty, on Zoom, and on Snowflake, among other topics. Topics Covered 2:30 minute mark - The onset of competition - Asana for Atlassian, Microsoft for Twilio, and writ large 10:00 - The market's roving eye, excitement over IPOs or hot tickets vs. steady growing behemoths - Zoom vs. Cisco, Snowflake vs. Box vs. Salesforce, and the ongoing runroom for cloud growth and small/mid-caps like PagerDuty 14:00 - The value of having multiple revenue streams, and the importance of Rundeck to PagerDuty as a first step 17:00 - Microsoft's power move and Zoom's taking advantage of their position 20:00 - The commitment to your cloud stack for a decade, and the challenge for incumbents of diversifying - Hipchat vs. Slack and Bitbucket vs. GitHub 26:00 - Data Center redundancy and setting up your network 32:00 - Snowflake dive, and the echo with VMWare; its competitive position vs. Redshift, Teradata, etc. 46:15 - COVID-19 Status update around the world

We had a chat with Celina Zamora, who is the Senior Community Manager at Atlassian. Atlassian is known for its products like Jira, Bitbucket and Confluence. Today, Atlassian is serving over 135,000 customers across the globe.

We had a chat with Celina Zamora, who is the Senior Community Manager at Atlassian. Atlassian is known for its products like Jira, Bitbucket and Confluence. Today, Atlassian is serving over 135,000 customers across the globe.  Celina's job is all about building communities. She manages and supports Atlassian in-person communities within the Americas by working with community leaders, offering support and steer them. Her work involves engaging the online community by creating avenues for customers to easily connect with others like them.  With Celina onboard with us, we are going to learn how Atlassian built an online community where developers, content managers, project managers and others came together where they collaborate, connect and share valuable insights with each other.  It's not easy to explain the value of having a community and Celina understands this all too well since she saw how everyone was apprehensive towards the idea of having them.  But today, Atlassian product teams see great value in these communities where they get to enjoy actual face time with users, learn about their problems, offers them real time feedback and hear customer stories.  We will also be inquiring about the metrics they are using at Atlassians to gauge the effectiveness of these community events. Also, Celina shared with us how they are scaling their communities by building everything with heart and balance. They do this by focusing on where their customer is in terms of the platform they are using and how they are using it.

The Joel Test: 12 Steps To Better Code On Code Review GitHub: Pull Request Reviews BitBucket: Working with Pull Requests Phabricator Danger CI Reference with examples of some things Danger can do SwiftLint Twitter Jokes about Code Review: 1, 2